How to add a second broker without a rewrite

The second broker is where home-built execution layers go to die. The first integration feels like an achievement. The second one reveals that what you built was never a layer. It was a client, and everything above it quietly took the client’s shape.

​

Why the second broker hurts so much

Your first broker shaped your whole codebase without you noticing. Order payloads match its formats. Error handling matches its error codes. Your order state machine mirrors its lifecycle, your position tracking mirrors its account model, and your event handlers expect its websocket messages. Broker two disagrees with all of it. Different field names, different order states, different ideas about what a partial fill looks like, different authentication, different rate limits. So you do what every team does: you start writing an adapter layer. One interface, two implementations, and a growing pile of special cases. Congratulations, you are now an infrastructure company. The adapter layer needs tests, monitoring, and maintenance every time either broker changes anything, and it still only covers two brokers.

​

The broker as a setting

Anthid takes a different path, and it starts above the broker rather than at it. Your strategy talks to one execution layer: you describe the outcome you want as an intent, in Anthid’s own terms, and Anthid records it before contacting any broker, checks it against your controls, routes it, streams back what happened, and keeps the record. The broker’s dialect is something the layer translates into at routing time, not something your code ever sees. That is why adding a second broker is a config change, not a rewrite. You connect the new account, and your strategy code stays exactly as it was. It never knew which broker it was talking to in the first place, so it has nothing to relearn. Lightspeed is connected today, with more on the roadmap, and each new integration arrives behind the same interface.

​

What stays the same

Everything you actually care about. Your strategy logic is untouched. Your event handling is untouched, because every broker’s events arrive in the same normalized stream regardless of where the fill happened. Your records stay coherent too: the durable ledger keeps intents, orders, and positions from every connected broker in one place, with dispatch state and fill state reported the same way for each, so “what happened yesterday” has a single answer instead of two logs in two formats. Your risk controls also carry over. Trading windows and order size limits are enforced by the platform before any order leaves, and they apply no matter which broker is on the other end. You do not rebuild your safety net per broker, and every refusal is recorded the same way whichever account it was headed for.

​

What to check before you flip the switch

One honest caveat. Brokers differ in what they accept, and Anthid does not paper over that: an unsupported combination of order type, destination, or time in force is rejected rather than routed. Lightspeed accepts the four intent order types, DAY, SMART routing, and its direct exchange routes today. Each integration publishes its own support matrix, and the choices it shares with the broker you already use are the portable set. Everything else is broker-specific. So the work is a review, not a rewrite: read your intents for values outside that portable set, and decide what the second broker should do instead. The matrices are in Supported Order Types, Supported Time In Force, and Supported Destinations.

​

A realistic rollout plan

Here is how this looks once the broker you want is connected. Start where you already are, with your strategy running against your first broker. Connect the second broker and point it at paper trading first, since Anthid’s free tier includes paper trading with no credit card and no sales call. Run the same strategy against both brokers side by side for a few sessions and compare fills, latency, and behavior in the normalized event stream, which reads the same for both. When you trust what you see, flip the second broker to live. Total code changes along the way: none. Compare that to the home-built route, where the same rollout starts with a month of adapter work before you can even begin testing.

​

The bigger point

Broker choice should be a business decision, not an engineering project. Maybe you want better fills, redundancy during outages, or an asset class your first broker does not cover. Those are good reasons to add a broker, and none of them deserve a quarter of engineering time. When the execution layer is above the broker rather than built around it, the decision shrinks to the size it always should have been: a setting.