Services
Hosting chosen for latency, not for a price list
The distance between your platform and your liquidity providers is not an infrastructure detail. It is a cost that appears in every fill, on every account, every day.
See it live
A cutover with a measured duration, not a guess
Placement, redundancy, protection and recovery move through the same phased sequence, rehearsed before it is ever run for real.
Four layers
What the arrangement underneath actually consists of
Close to where your prices come from
Servers sit in facilities chosen for network distance to your providers rather than for a monthly rate. On a margin book, the distance between your platform and your liquidity is a cost that shows up in every fill.
A standby that is actually in step
A second environment kept current, not a machine provisioned once and forgotten. If it has not been booted since the day it was built, it is not redundancy — it is an invoice.
Filtering in front, access restricted behind
Traffic filtering ahead of the platform, and administrative interfaces reachable only from known addresses rather than exposed to the internet with a password in front of them.
Backups proven by restoring them
Backup jobs are verified by restoring into an isolated environment on a schedule. A job that has succeeded nightly for two years tells you nothing until somebody has read the output back.
Sizing the environment
Four numbers decide the specification
Server specification is not a package you pick from a list. It follows from what your book actually does, and each of these drives a different part of it.
Access-server count and network capacity
Peak simultaneous logins, not registered accounts. The two numbers differ by an order of magnitude and only one of them decides whether clients can connect.
Processor and memory on the trading core
A few hundred instruments quoting continuously costs more than a few thousand that barely move. Sizing is done against your own feed, not a headline number.
Disk on the history server
How far back tick and trade detail has to stay queryable, and where the rest is archived, decided before the disk fills rather than during the incident.
Backup targets and standby footprint
How much data you can afford to lose and how long you can afford to be down. Every other hosting decision follows from those two answers.
The vendor publishes a floor, not a target
Every platform vendor states minimum server requirements. They describe the point below which the software will not run properly — not the point at which your book runs well. We size against your measured load and treat the published minimum as the floor.
Specification is written down before anything is bought
Processor, memory, disk layout, network capacity and operating system version are agreed in a document you keep, so what was provisioned can be checked against what was specified a year later.
Headroom is part of the specification
Capacity is chosen for the growth you expect within the term, not for today's peak. A server sized exactly to current load is a server that needs replacing during your busiest quarter.
The maintenance cadence
Scheduled, and proven rather than assumed
Continuous plus daily full
Restore test into an isolated environment on a fixed cycle
Scheduled, in a closed market
Timed cutover to standby and back, with the result recorded
In agreed windows
Applied to standby first, observed, then to the live environment
Ahead of expiry
Tracked on a calendar rather than discovered by an outage
Periodic
Headroom measured against actual growth, not assumed
Three things about failover that are usually left unsaid
Every hosting arrangement claims redundancy. Far fewer have ever used it.
The first failover should not be the real one
Cutting over is rehearsed in a window where nothing is trading, so its duration is measured and its surprises are found in advance.
Recovery time is a number, not an adjective
How long a cutover takes is measured during rehearsal and written down. Anything described only as fast has not been timed.
Failing over is not the hard part
Coming back afterwards, with both environments consistent and no divergence in account state, is where most untested arrangements fall apart.
FAQ
Managed hosting: common questions
6 short answers to what teams ask before a demo.
Yes. Hosting is a separate part of the engagement. If your infrastructure already sits where it needs to be relative to your providers, we administer the platform on it and leave the arrangement alone.
By network distance to the providers you actually trade with, then by the operational qualities of the facility. Choosing on monthly cost alone is how a desk ends up paying for the difference in every fill instead.
On a fixed schedule, in a window where the market is closed, with the cutover timed and the result recorded — including the return to the primary environment, which is the part that more often goes wrong.
Because they are restored on a cycle into an isolated environment and checked. A backup job that reports success is evidence that a job ran, not that the data can be read back.
In agreed windows outside market hours, applied to the standby environment first and observed before it reaches the live one. Emergency security patching is handled separately with notice to you.
The commercial arrangement is set out explicitly at the start, including what happens to the environment and its data if the engagement ends. It should never be a question you have to ask later.
Still have a question?
A specialist will answer it directly, with your set-up in mind.
Ask a specialistWhen was your failover last tested?
If the answer is that nobody is sure, that is the review worth having. We will check the topology, the backups and the recovery path, and tell you what we find.