Building a multi-broker algorithmic trading platform

What this is

A client's algorithmic trading platform, described here with every identifying detail removed. The platform lets its own subscribers run automated strategies across several brokers at once, all from one place. Our job is to build the core that does the trading. The client owns the platform, brings the strategies, and holds the compliance for running it, so none of that is shown here. What we can show is the engineering, because that is the part we are proud of and the part a future client is really asking about.

The shape of the system

The platform has three parts, and keeping them cleanly separated is what lets it grow without falling over:

• The web portal is the front of house. Subscribers sign up, choose the strategies they want, and watch how they are doing. The portal itself never places a trade.
• The central database is the single system of record. Everything the portal captures and everything the engine does is written here, once, in one place.
• The execution engine is the core. It runs the strategies, places and manages the orders, enforces risk, and talks to each broker. This is the part that actually trades.

An easy way to picture it: the portal is the showroom, the database is the office records, and the engine is the factory floor where the real work happens.

The architecture decision that mattered most

The first working version reached the brokers through a single bridge over a general web API. That is a fast way to get live, and it was the right way to start. But that approach has a ceiling. Some important brokers are hard to reach through a generic bridge, the round trip is slower, the setup is less reliable, and it leans on a third-party data feed that costs money every month.

The direction we recommended is a native execution engine that speaks to each broker through that broker's own interface, with its own market data. It is faster, steadier, and far more solid. It also takes more time to build, so the sensible path is to move one broker across at a time while the existing platform keeps running exactly as before. Subscribers never notice a thing. Underneath, one broker at a time is lifted onto the stronger engine. That way the business keeps operating while the foundation is rebuilt under it, which is usually the hardest part of any platform upgrade to get right.

Scaling across brokers and many accounts

Running a lot of accounts across serious brokers is where the real infrastructure questions appear. Two patterns show up, and they pull in different directions:

• With a master account that holds many sub-accounts, everything trades under one main login. That is one neat structure to support.
• With many separate accounts, brokers such as Interactive Brokers expect a fresh login each day, and once you push past a few dozen accounts on a single server you are paying for a lot more hardware.

The tidy answer we designed is a small executor that installs on each subscriber's own machine. The subscriber signs in to their own broker whenever they choose. That removes the need for the platform to hold anyone's broker credentials, it removes the daily login and logout problem, and it means the platform is not quietly absorbing the hardware cost of every single account. One design decision solves a compliance question, an operational headache, and a cost problem at the same time.

The hard problems live around the order, not the strategy

People assume the difficult part of a trading platform is the strategy. It rarely is. Most of the engineering is everything that surrounds an order, plus the discipline to add a new feature without breaking the ten that already work. The pieces that carry the real weight:

• Order reconciliation. If a subscriber asks for five and the broker fills three, the platform has to track that gap, so its own picture of a portfolio never drifts away from what the broker actually holds.
• A pre-trade risk check and a kill switch. If a strategy misfires and throws a hundred signals in a minute, something has to catch it before it does any damage.
• Signal freshness. An incoming signal that arrives late is checked, and if it is stale it is ignored, because acting on an old signal can be worse than doing nothing.
• An audit trail that cannot be edited. Every change to a bot's settings and every order is written down, so any question about what happened has a clear, honest answer.
• Sharing one database safely. The portal and the engine both use the same database, so we lean on careful locking and a strict order state machine, from pending, to sent, to acknowledged, to partly filled, to filled or rejected. The two sides never trip over each other, and removing a bot never erases its history or abandons an open position.

What it demonstrates

This is a working demonstration of building a real, multi-tenant trading platform end to end: a web front, a single source of truth, and an execution engine that trades across many brokers with the reliability a live market demands. The client runs the platform and brings the strategies. We build the technology. It is the same engineering we bring to the custom trading systems we build for other clients, and to the markets we help clients automate.

This is an anonymised account of client work. The client's identity, the strategy logic, and any figures have been removed. We build technology. We do not provide investment advice, we do not manage money, and we make no claim about how any strategy performs.

← All case studies