A-Book, B-Book, Hybrid: How Execution Routing Logic Should Actually Be Modeled

Most conversations about A-Book and B-Book treat it as a question about the broker's business model: which clients does the firm trust, and which does it hedge against. That framing leads directly to the simplest possible implementation — a boolean flag on the account, maybe on the symbol. Client is A-Book, flow goes to a liquidity provider. Client is B-Book, the broker takes the other side.

That model works for exactly as long as the business stays simple. It stops working the moment risk management, not account classification, becomes the actual constraint — which is almost immediately, for any broker running real volume.

A static A/B flag answers one question — who is this client — and routing needs an answer to a different one: given current exposure, current liquidity conditions, and this specific order, where should it go right now?

Those two questions diverge quickly. A client flagged B-Book might place an order that, combined with existing B-Book exposure on that symbol, pushes the desk's net position past its risk limit — at which point some or all of that order needs to be hedged externally, regardless of the client's classification. A client flagged A-Book might place a small order inside the broker's existing risk appetite, where routing it externally only adds hedging cost and spread for no risk benefit.

The account-level flag has no way to represent either case. It was never designed to; it encodes a judgment about the client, not a decision about the order.

A more accurate model treats routing as a function evaluated per order, not a lookup against account metadata. The inputs to that function are things that change in real time: net exposure by symbol and by correlated group, remaining risk limit, current spread and depth from connected liquidity providers, and the cost of hedging the incremental position right now versus holding it.

The output isn't a single routing destination either. For any order above a trivial size, the realistic output is a split: some percentage filled internally against existing opposite-side flow or within risk appetite, the remainder routed externally. This is what 'hybrid' actually means in a well-built system — not a third static category alongside A-Book and B-Book, but the normal output of evaluating the same function on every order.

Implementing this requires the routing logic to sit close to a real-time, aggregated view of exposure — not a nightly reconciliation of positions, but a live number that updates with every fill. Without that, the routing decision is working from stale information by definition, and every claim of 'real-time risk-based routing' downstream of it is not quite true.

Three things have to exist for this to work in production, and all three are infrastructure problems before they're trading-logic problems.

First, real-time position aggregation across every venue and internal book the order could touch — if exposure is computed from batch data, the routing decision is always one step behind actual risk. Second, a feedback loop from execution quality monitoring back into the routing model: if a particular routing decision consistently produces worse fills than the alternative, that should show up in the model's inputs, not just in a monthly report someone reads after the fact. Third, an audit trail that records why a given order was routed the way it was — not just where it went, but what exposure, limit, and pricing state the decision was based on at that moment.

That last point matters beyond internal debugging. Brokers that treat A-Book/B-Book as a simple flag often can't answer, after the fact, why a specific order was handled a specific way — which is a difficult position to be in during a regulatory inquiry or a client dispute. A routing engine that evaluates a documented function per order, and logs its inputs, can answer that question directly.

None of this is exotic. It's the difference between treating A-Book/B-Book as a label and treating it as what it actually is: a real-time risk and execution decision that happens to produce, as a side effect, something that looks like a label when you zoom out far enough.

Building it correctly means the execution and risk layers have to share state continuously, not just at the start of a trading relationship. That's the part that's actually hard — not the concept, which is simple to describe, but the plumbing: aggregating exposure in real time, feeding it into a routing decision fast enough not to add latency that matters, and keeping a defensible record of every decision made along the way.