Infrastructure & Integration
Your trading platform, run by people who only run trading platforms
Building the server is a week of work. Keeping it correct is a job — swaps, sessions, corporate actions, gateways, patches, backups and the 3am alert. We take that job, for the platforms you already run.
See it live
Scoped credentials for every environment
Production and staging credentials are issued, scoped and rotated from one console, with rate limits and an audit trail on every key.

What happens when nobody owns it
A trading platform does not fail loudly. It drifts.
None of these are exotic failures. They are the four that show up on almost every environment we are asked to look at.
Swaps drift out of date
Rates get set once at launch and then follow nothing. Months later the desk is paying carry it never priced for, and nobody can say when it started.
Sessions miss the calendar
A holiday schedule changes, the trading session does not, and clients trade an instrument into a closed market. It is always found by a client first.
Backups are never restored
A backup job that has run nightly for two years is not a backup until somebody has restored from it. Most teams find out on the day it matters.
Alerts go to a dead channel
Monitoring gets set up by whoever built the server, wired to their inbox, and keeps firing there long after they leave the company.
What we run
The platforms, and what is different about each one
The rhythm of the work
Platform administration is a calendar, not a queue
Watch, and change nothing without a reason
Feed health, gateway state, rejection rates and resource pressure are checked continuously. Configuration changes go through a request with a rollback plan attached, not straight onto the live server.
The part everyone forgets until it hurts
Triple swap days, session boundaries and instrument expiries are handled on a calendar rather than reactively. Corporate actions on equity CFDs are applied before the market opens, not after a client asks.
Patching, restores and the things that need the market shut
Updates, certificate renewals and failover rehearsals happen in the window where nothing is trading. Restores are tested on a schedule so the backup is proven rather than assumed.
Services
The pieces of work, whichever platform you run
- 01
Setup & Migration
A first build, or a move that keeps every open position.
- 02
Configuration & Tuning
Groups, symbols, swaps and sessions, changed on purpose.
- 03
Monitoring & Alerting
Someone watching the feed at 3am so you do not have to.
- 04
Managed Hosting
Where the servers live, and what happens when one dies.
- 05
Environments & Data
Somewhere to test, and a way to get your own data out.
Engagement models
Three ways this usually starts
A new environment, done once and done right
Provisioning, symbol and group modelling, provider connections and go-live. You end up with an environment that matches your book rather than a default install.
Environment provisioning
Symbol and group modelling
Provider connections
Rehearsed go-live
The whole thing, continuously
Everything in Build, then ongoing configuration, monitoring, patching, hosting and a named engineer who knows your setup. The common shape for a desk with no platform team.
Ongoing configuration
24/7 monitoring
Managed hosting and failover
Named engineer
A second opinion on what you already run
We review the environment you have, document what we would change and why, and hand you the findings. No obligation to move anything to us afterwards.
Configuration review
Risk and exposure findings
Infrastructure assessment
Written recommendations
Against doing it yourself
The honest comparison
An in-house platform engineer is the right answer for some desks. This is what the trade-off actually looks like.
Business hours, one person deep
Continuous, with a rota behind it
The desk waits
Handover to a colleague on the same account
Whatever one hire happens to know
A team across several platforms
Months, then months to ramp
Days
Usually informal
Requested, reviewed, logged, reversible
Documented, rarely tested
Rehearsed on a schedule
Onboarding
Nothing changes until we understand what is there
- 1
Review
We go through your current environment, your provider connections and how your book is structured, and write down what we find.
- 2
Plan
You get a scoped plan: what changes, in what order, what carries risk, and what happens on the day of any cutover.
- 3
Transition
Access is handed over, monitoring is attached, and we shadow the environment before we start changing anything in it.
- 4
Run
Standing coverage begins, with a named engineer, an agreed escalation path and a change log you can read.
The infrastructure underneath
Most of what makes a platform reliable is decided before it ever goes live.
Redundant by default
A live server and a standby that is actually kept in step, rather than a second machine that has not been booted since the day it was provisioned.
Failover that has been used
Cutting over to the standby is rehearsed in a quiet window, so the first time it happens is not during a market event.
Network protection
Filtering in front of the platform, with access to administrative interfaces restricted to known addresses rather than left open to the internet.
Restores, not backups
Backup jobs are verified by restoring them into an isolated environment on a schedule, which is the only way to know they work.
Explore
Both sides of the engagement
FAQ
Platform integration: common questions
6 short answers to what teams ask before a demo.
Setup, configuration, monitoring and managed hosting for MetaTrader 5, MetaTrader 4, cTrader and third-party bridges, run by a dedicated platform team instead of your own staff.
MetaTrader 5, MetaTrader 4 and cTrader, plus bridge and aggregation software such as oneZero, PrimeXM and Centroid, with a managed path onto BridgeX if you want to consolidate.
Yes. A migration covers environment provisioning, symbol and group modelling, provider connections, data carry-over and a rehearsed cutover.
Configuration and tuning of groups, symbols, spreads, swaps and sessions, plus continuous monitoring of quote staleness, gateway state, rejections and latency, with escalation to a named engineer.
Yes. Demo, test and staging environments run alongside the live server, and trade, account and quote data can be exported on a schedule into your own database.
Running a platform well means safe configuration changes, plugin and gateway upkeep, monitoring outside office hours and tested failover. A team that does only this covers those without you hiring for every specialism.
Still have a question?
A specialist will answer it directly, with your set-up in mind.
Ask a specialistSend us the environment you already have
We will review the configuration, the provider connections and the infrastructure, and tell you plainly what we would change — whether or not you move it to us.