Services
Production should not be the only place you can try something
Most platform incidents are changes that were correct in theory and wrong in practice. A place to prove them first, and a way to read your own data without asking anyone, are the two things desks add once they have been burned.
See it live
Four environments, one configuration history
A change moves from test to staging to production in one direction, and the export that feeds your reporting runs off to the side where it cannot disturb trading.
The environments
What each one is for, and what is actually in it
Real client money
Live accounts and live pricing
Changes reach it only after they have been made somewhere else first
A rehearsal of the change
A recent copy of production configuration
Where a symbol change, a group policy or a gateway swap is proven before anyone signs it off
Integration work
Synthetic accounts, synthetic flow
Where your developers and any third party you connect can break things without consequence
Clients and sales
Live pricing, no real settlement
Sized and monitored like a real server, because a demo that lags loses the client before onboarding
Getting your data out
Your records, in a place you already control
Reporting, reconciliation and audit should read from your own systems. None of them should require a request to us.
Your own database
Trades, orders, accounts and balances written on a schedule into a database you own, in a shape your analysts can query without asking us for an extract.
Scheduled files
The same records as dated files where a warehouse is not in place yet, delivered to storage you control rather than left in a portal to be collected.
Drop copy
Execution reports streamed to a risk or back-office system in real time, read-only, with no ability to submit an order.
History retention
How far back the platform keeps detail, and where the rest is archived, agreed up front rather than discovered when somebody asks for last year.
Added when you need them
Extensions to the standard footprint
Additional access servers
More client-facing capacity in front of the same trading core, added when concurrent sessions justify it rather than when the platform starts refusing logins.
Additional backup servers
A second backup target, often in a different location, for desks whose recovery position cannot depend on one site staying reachable.
Extended monitoring
Deeper signal coverage than the standard set — per-symbol quote health, per-group execution quality, custom thresholds your desk cares about.
Account group and routing sets
Additional group profiles, routing rules and execution configurations beyond the set defined at go-live, as your product range grows.
Three things worth saying plainly
Where this usually goes wrong
A demo server is not a spare server
It carries real clients forming a real opinion of your platform. Sizing it as an afterthought is why prospects conclude your execution is slow before they ever fund an account.
Copied data is still client data
A staging environment built from a production copy inherits every obligation that came with it. Where that is a problem, the copy is masked before it lands rather than after somebody notices.
An export is a dependency
Once your reporting reads from a scheduled export, a silent failure is a reporting outage. Export jobs are monitored and alerted on the same way the platform itself is.
FAQ
Environments and data: common questions
6 short answers to what teams ask before a demo.
If configuration changes are currently made directly on the live server, then yes. A staging environment is what turns a symbol or group change from something you hope is right into something you have already watched behave correctly.
Yes, and that is usually what makes it useful. Where client data cannot be replicated as-is, identifying fields are masked during the copy so the configuration is faithful while the personal data is not carried across.
It should be, and it is by default. Prospects judge your platform on the demo, so a stale feed or a slow fill there costs you the same client a production incident would.
Trades, orders, positions, accounts, balances and quote history, on whatever schedule your reporting needs — typically nightly, with intraday runs where a desk reconciles during the session. The destination is a database or storage you control.
They should not. Extracts are read from a replica or run outside the trading session, because a reporting job that competes with execution for resources is a reporting job that eventually causes an incident.
You do, and it lands somewhere you already control. The point of the export is that your analysts and your auditors do not have to go through us to read your own records.
Still have a question?
A specialist will answer it directly, with your set-up in mind.
Ask a specialistTell us where your changes are made today
If the answer is the live server, we will lay out what a staging environment would cost you and what it would have caught.