A-Book vs B-Book vs Hybrid Brokerage: Technology, Liquidity & Risk Architecture

Contents

• A-Book: external execution and liquidity routing
• B-Book: internalised exposure and its obligations
• Hybrid: configurable segmentation and routing
• The technology layer: who owns what
• Decision variables: what actually determines the model
• Dynamic routing: classification and risk rules in practice
• Comparison: A-Book vs B-Book vs Hybrid
• Model neutrality: it depends on the book, not the marketing
• CTO and operations checklist
• FAQs

A-Book: external execution and liquidity routing architecture

In an A-Book (STP/agency) model, every client order is passed through to external liquidity for execution. The broker never holds the position; its revenue is the markup on spread or a fixed commission per lot, and its principal operational task is keeping the execution chain fast, reliable and cheap enough to remain competitive. That chain has several distinct components, and each one introduces its own failure modes.

Orders leave the trading platform and pass through a bridge & gateway or gateway, which normalises the order, applies any pre-trade checks the broker has configured, and forwards it over a FIX session (or a proprietary API) to one or more liquidity providers. Where a broker uses more than one LP — which is the norm once volume justifies it — an aggregation layer merges quotes from each source into a single consolidated book, so the platform shows one best price built from several underlying feeds. See our companion piece on what a forex bridge actually does for the mechanics of that layer.

LP tiering matters more than most new brokers expect. Providers are rarely offered on identical terms: tier-1 banks and non-bank market makers price differently by instrument, size band and time of day, and a broker's smart-order routing logic (or its dealer's manual overrides) decides which tier absorbs which flow. Execution cost in an A-Book model is not just the visible spread — it includes LP markup, aggregation and bridge licensing costs, and the commercial terms attached to volume tiers, which is why evaluating liquidity providers properly is its own discipline; our liquidity aggregator evaluation checklist covers this in detail.

A-Book execution is not frictionless. Slippage and rejections are real and measurable: a fast market can move price between order submission and LP fill, last-look practices at some providers can reject or requote orders, and network latency between platform, bridge and LP adds variable delay. None of this is a defect to be "fixed" so much as a set of trade-offs to be monitored — brokers running A-Book seriously track fill ratios, rejection rates and slippage distribution by LP and instrument, and use that reporting to rebalance routing over time.

B-Book: internalised exposure and the risk-management obligations that follow

In a B-Book model the broker becomes the counterparty to the client's trade. No order leaves the building; the broker's own book absorbs the position, and the broker's profit or loss is the inverse of the client's. This is a legitimate, widely used execution model, but it converts what was a connectivity problem in A-Book into a risk-management problem, and that shift has direct technology and capital consequences.

The core obligation is continuous exposure calculation: net position by instrument, by client, by group and across the whole book, recalculated as prices move and orders fill. Margin has to be tracked against that exposure in real time so that under-margined accounts are flagged or acted on before they become a solvency problem for the broker rather than just the client. Where the broker runs multiple B-Booked accounts trading against each other, netting logic determines how much of the gross exposure genuinely reaches the broker's book versus offsetting internally.

None of this is manageable on spreadsheets past a small number of active accounts. This is precisely the gap RiskMan is built to close — automated, continuous exposure and margin calculation, configurable thresholds by symbol, group or account, and alerting when positions approach limits the broker has defined. The software does not decide dealing strategy; it gives the people who do that job current, reliable numbers. Where a threshold is breached or a pattern looks unusual, a human dealer — through a 24/7 dealing desk & risk management — has to interpret it and decide whether to hedge externally, adjust internal limits or take no action. Running B-Book without that operational capability is a capital risk, not just an operational inconvenience: a broker that cannot see its net exposure in real time cannot know whether it is solvent under a stressed market move until after the fact.

Hybrid: configurable segmentation and routing

A hybrid model does not mean "sometimes A-Book, sometimes B-Book" as a matter of chance. It means the broker has built (or bought) a routing layer that classifies flow — by instrument, trade size, client history, account type or observed trading behaviour — and sends different segments down different paths: some flow to external liquidity, some retained internally, and in some architectures individual positions rebalanced between the two as conditions change.

This is why most brokers operating at any scale run hybrid in practice, even if their marketing describes a single model. A B-Book broker will typically A-Book its largest or most consistently profitable clients to cap tail exposure; an A-Book-branded broker will often retain very small retail tickets internally because externalising every micro-lot is not economically worthwhile once bridge and LP costs are accounted for. Hybrid is less a third category than an admission that flow is heterogeneous and a single routing rule rarely fits all of it.

The operational cost of hybrid is that it requires both technology stacks to be built properly at once: the connectivity discipline of A-Book (bridge, gateway, LP relationships) and the exposure discipline of B-Book (real-time risk calculation, thresholds, dealer oversight). A broker that adopts hybrid without genuinely resourcing both sides typically ends up with the worst of each — thin LP relationships and under-monitored internal exposure simultaneously.

The technology layer: what each component owns

Regardless of model, the same five layers recur, and confusing their responsibilities is a common source of both technical and governance mistakes.

• Trading platform (MT4/MT5 or another venue) — order entry, client-facing pricing, account structure. See our platform overview at trading platform services and the operational detail in MT4/MT5 administration.
• Bridge/gateway — order routing, normalisation, aggregation and the pre-trade checks a broker chooses to enforce at this layer; see bridge and gateway solutions.
• Liquidity providers — the external counterparties that actually fill A-Booked flow, priced and tiered under commercial agreements; see liquidity provider solutions and pricing context in market data and price feeds.
• Risk engine — continuous exposure, margin and threshold calculation across both A-Booked and B-Booked flow; this is RiskMan's role, and it is software, not a person watching a screen.
• Dealer environment — the humans who interpret what the risk engine surfaces, decide on hedging or limit changes, and handle the judgement calls no rules engine should be making unattended; this is the 24/7 dealing desk & risk management.

The diagram below separates these layers explicitly, because the most frequent architectural mistake we see is treating the risk engine and the dealing function as one thing. They are not: one calculates, the other decides.

                              CLIENT ORDER FLOW
                                     │
                         ┌───────────┴───────────┐
                         │   Trading Platform     │
                         │   (order entry, MT4/5) │
                         └───────────┬───────────┘
                                     │
                         ┌───────────┴───────────┐
                         │   Bridge / Gateway     │
                         │  routing & aggregation │
                         └─────┬─────────────┬────┘
                               │             │
           classified as              classified as
           EXTERNAL FLOW              INTERNAL EXPOSURE
                   │                         │
     ┌─────────────┴───────────┐   ┌─────────┴──────────────┐
     │   External Liquidity     │   │   Internal Book         │
     │   LP1 / LP2 / LP3 (FIX)  │   │   (broker as principal)│
     │   fills, rejects, cost   │   │   positions accumulate │
     └─────────────┬───────────┘   └─────────┬──────────────┘
                    │                          │
                    └───────────┬──────────────┘
                                 │
                   ┌─────────────┴─────────────┐
                   │   RiskMan (software layer) │
                   │   exposure, margin,        │
                   │   thresholds, alerts        │
                   │   -- automated monitoring  │
                   └─────────────┬─────────────┘
                                 │  surfaces alerts, not decisions
                   ┌─────────────┴─────────────┐
                   │  Human Dealing Oversight    │
                   │  (24/7 dealing desk)        │
                   │  interprets, hedges,        │
                   │  adjusts limits              │
                   │  -- separate operational    │
                   │     layer, not software     │
                   └────────────────────────────┘

Decision variables: what actually determines the model

Brokers rarely choose a model on ideology; the decision is normally forced by a combination of the following.

• Client flow characteristics. Flow that is statistically profitable to the broker over time is a candidate for internalisation; flow that consistently wins is a candidate for externalising, because retaining it concentrates losses on the broker's own book.
• Available capital. B-Book and hybrid retention require capital buffers sufficient to absorb adverse moves before a dealer or automated hedge can react; thin capital pushes a broker towards A-Book by necessity, not preference.
• Liquidity conditions. Wide, unstable spreads from available LPs can make A-Booking uneconomic for certain instruments or sizes, shifting the balance towards internal retention even for brokers with an A-Book-first policy.
• Risk appetite and governance. Some boards and regulators expect a demonstrably low-risk-appetite execution model; others accept internalisation provided controls are auditable.
• Operational capability. Running B-Book or hybrid responsibly requires a functioning risk engine and a resourced dealing function around the clock. A broker without either should not be running material internal exposure, regardless of how attractive the economics look on paper.

Dynamic routing: how classification and risk rules can influence flow

Where the platform, bridge and risk engine support it, routing does not have to be a static, once-configured rule. Classification logic can incorporate account-level flags, instrument or size thresholds, or exposure conditions calculated by the risk engine, and use those to influence which orders are externalised versus retained. Conceptually, this allows a broker's routing posture to shift as conditions change — for example, tightening what gets retained internally as net exposure on a given symbol approaches a defined limit.

This should be described carefully rather than sold as a universal feature. Not every bridge or gateway supports the same granularity of classification, not every platform exposes the account and order attributes needed to drive it, and the rules that determine routing are inherently broker-specific and commercially sensitive — this article does not, and should not, describe how any particular broker configures theirs. What is safe to say is that the architectural pattern — risk engine calculates, routing layer consumes that output as one input among several — is a legitimate and increasingly common design point, provided it is implemented on infrastructure that can actually support it and reviewed by people who understand both the technology and the broker's obligations.

Comparison: A-Book vs B-Book vs Hybrid

Model neutrality: it depends on the book, not the marketing

None of the above is an argument for one execution model over another. The right architecture depends on the broker's actual client book, the jurisdiction and regulatory expectations it operates under, its capital position and the operational capability it is willing to resource on an ongoing basis — not on which model is currently fashionable to advertise. A well-run A-Book shop with disciplined LP management can be a strong, low-risk business; a well-run B-Book or hybrid operation with a properly resourced risk engine and dealing desk can be equally sound. A poorly resourced version of either is a liability. InfyTradeTech implements the architecture a broker has chosen — connectivity for A-Book, risk technology and dealing support for B-Book and hybrid, or both together — rather than steering clients towards a single model.

CTO and operations checklist

• Map every order path from platform to fill, and identify exactly where classification (if any) occurs.
• Confirm which bridge/gateway and platform combination you run, and what routing granularity it actually supports before assuming a feature exists.
• Track fill ratios, rejection rates and slippage by LP and instrument, not just in aggregate.
• Ensure exposure and margin are calculated continuously, not on a batch or end-of-day basis, wherever any flow is retained internally.
• Define thresholds and escalation paths before volume grows, not after a breach has already occurred.
• Staff a dealing function capable of acting on risk-engine alerts around the clock if you retain any exposure outside market hours you can personally cover.
• Review LP agreements and tiering periodically — execution costs on an A-Booked or hybrid book change as volume and terms evolve.
• Keep the risk engine and the dealing desk as distinct functions with distinct accountability, even if the same vendor supplies both.
• Revisit your model annually against actual flow data, not assumptions made at launch.

FAQs

Is B-Book inherently riskier than A-Book?

B-Book carries direct market risk that A-Book does not, but "riskier" depends on whether that risk is properly measured and managed. An unmonitored B-Book is dangerous; a monitored one, with a functioning risk engine and dealing oversight, is a controlled and common business model.

Can a broker switch from A-Book to hybrid without rebuilding its platform?

Often yes, provided the existing bridge, gateway and platform expose the account and order data needed to classify flow, and the broker adds the risk-calculation and dealing capability required to manage whatever it starts retaining. The connectivity side rarely needs replacing; the risk and operational side usually does need building out.

Does hybrid always mean lower risk than pure B-Book?

Not automatically. Hybrid reduces concentration by externalising some flow, but the internally retained portion still needs the same rigour — real-time exposure calculation and dealer oversight — as a full B-Book. Hybrid without that rigour on its internal segment is not safer, it is just partially exposed.

What is the actual difference between RiskMan and a dealing desk in this context?

RiskMan is the software that calculates exposure, margin and thresholds continuously and raises alerts. The 24/7 dealing desk & risk management is the staffed function that reads those alerts and decides what to do — hedge, adjust a limit, or leave a position as is. One computes, the other decides; they are not substitutes for each other.

Do all bridges and platforms support dynamic, rule-based routing?

No. Granularity varies significantly between platforms and bridge vendors, and some setups only support static routing rules configured at account or symbol level. Confirm actual capability with your platform and bridge providers, covered in more depth in our bridge architecture guide and our MT5 platform guide, before assuming a given routing design is achievable.

Related Research

This article belongs to our risk and dealing research cluster — execution model, automated monitoring, human operations and market connectivity, read together:

• Managing Toxic Flow in a Forex Brokerage: Detection, Routing & Human Oversight
• Real-Time Exposure Monitoring for Forex Brokers
• Inside a 24/7 Forex Dealing Desk: What Dealers Actually Monitor
• Automation vs Human Judgment in Broker Risk Management
• How a Forex Dealing Desk Works With Liquidity Providers