Brokerage Liquidity Infrastructure: Gateways, Routing & Quote Policies
A practical look at FIX gateways, execution routing, dealer logic, quote policies and the architectural choices that sit between a broker, its liquidity providers and client trades.
For many new brokers, “liquidity integration” initially sounds straightforward: connect a liquidity provider through FIX, receive prices, send orders, and start trading.
In practice, that is only one part of the execution architecture.
A production brokerage has to make several independent decisions for every instrument and every trade. Where should the market price come from? Which source should be trusted if several providers are connected? What should happen if the primary feed stops updating? Should a client order be executed internally or sent to an external counterparty? Should some trades be reviewed by a dealer? And what should the platform do when the preferred execution path is temporarily unavailable?
These decisions are closely related, but they are not the same problem. A modern trading platform therefore needs more than connectivity. It needs a layer that connects liquidity, pricing, execution routing and dealing logic while keeping those functions independently configurable.
This is the approach used in ST Trader.
Liquidity connectivity is only the first layer¶
At the infrastructure level, a broker normally connects to external counterparties through gateways or bridges.
Those counterparties can include liquidity providers, prime-of-prime brokers, aggregators, exchanges or other trading systems. In ST Trader, this connectivity is handled through a gateway architecture, including integrations with environments such as Centroid, MetaTrader 5 and PrimeXM, as well as direct FIX-based connections.
The important architectural point is that the gateway is not simply a pipe between two systems. A gateway may provide market data, participate in execution routing, maintain provider-specific symbol mappings and communicate order execution results back to the trading server.
This separation becomes increasingly important as a brokerage grows. A small broker may begin with one liquidity provider and a relatively simple execution model. Later, it may connect another provider for certain instruments, add a separate crypto or futures venue, use an aggregator for Forex liquidity, or maintain different providers for different brands.
At that point, the problem is no longer simply how to connect to liquidity. The real question becomes how the platform should decide which connection to use and under what conditions.
Pricing and execution are two different decisions¶
One of the most important distinctions in brokerage infrastructure is the difference between the source of a price and the destination of a trade. They are often treated as if they were the same thing. They do not have to be.
A broker may receive the primary EURUSD quotation from one provider while routing selected EURUSD trades to another execution counterparty. A backup pricing source might never receive orders at all. Likewise, an execution provider can remain available even if the broker chooses not to use its prices as the primary client-facing market feed.
Separating these functions gives the broker significantly more control over the infrastructure. ST Trader handles this through two different layers: Quote Policies for market data and Execution Routing for trade flow.
That distinction matters because pricing has its own operational risks. A provider can remain technically connected while its market data becomes stale, spreads expand abnormally, timestamps drift or prices move sharply relative to other available sources. Execution connectivity alone does not solve those problems.
Core architectural distinction: pricing determines which market data becomes the live client-facing price; routing determines where a trade goes for execution.
Execution routing is where A-book, B-book and hybrid models become operational¶
Terms such as A-book and B-book are often discussed as business models, but technically they are execution decisions.
In an A-book scenario, selected client flow is directed toward an external liquidity venue. In a B-book scenario, the platform processes that flow internally. A hybrid broker uses both approaches depending on its own risk and execution policy.
The important question is therefore not whether the platform supports “A-book” or “B-book” as a checkbox. The more useful question is whether the broker can define which flow should follow which execution path.
ST Trader’s routing layer can evaluate conditions such as the symbol, account group, individual trading login, volume range and type of trading operation. Once a route matches, the platform executes an ordered sequence of routing steps. Routing targets can include external gateways, manual dealers, Virtual Dealer policies, internal execution and explicit rejection.
This allows execution policy to be much more granular than a global A-book/B-book setting. For example, a broker may decide that ordinary EURUSD orders from one retail account group are handled internally, while larger transactions are routed to an external liquidity provider. Professional accounts can follow another route entirely. A particular trading account can even have dedicated routing logic without changing the execution model for the rest of the client base.
The same principle can be applied across asset classes. A broker could operate one model for major FX pairs, another for cryptocurrencies and another for less liquid instruments.
This is what makes a hybrid execution model practically useful: the decision exists at the level of actual order flow rather than only at the level of the brokerage as a whole.
Routing should be treated as a sequence, not a single destination¶
Another useful concept is that execution routing does not necessarily have to be a binary choice between “internal” and “external”. A route can contain several stages.
An order could first pass through an automated execution policy, then proceed toward a gateway, while another class of trades could first require dealer intervention.
This type of sequence is useful because real-world execution infrastructure has failure states. A liquidity connection can be temporarily unavailable. A dealer may not respond within the expected time. A transaction may fall outside the range accepted by an automated policy.
Instead of leaving those situations undefined, the route can describe what happens next. ST Trader therefore treats routing as an ordered execution plan. Non-terminal steps can have timeouts, while the chain ultimately terminates in internal execution or rejection. Gateway failures or timeouts can advance the request to a configured fallback step rather than leaving the request in an ambiguous state.
For brokers operating several liquidity relationships, this deterministic behavior is more important than it may initially appear. Execution infrastructure is not only about finding the best route when everything works. It is also about defining what the platform should do when something does not.
Why manual dealing still exists in an automated brokerage¶
Automated routing does not eliminate the need for a dealing desk. Instead, it changes its role.
Modern dealing infrastructure generally benefits from automation for routine flow while allowing human intervention where the broker specifically wants it. That may include unusually large transactions, specific client groups, selected instruments or periods of abnormal market conditions.
ST Trader allows a route to send a trading request to a manual dealer pool. A dealer pool is effectively a group of authorized dealers capable of processing requests routed to that team.
This is operationally different from assigning every request to one specific person. A broker can organize dealers around teams, shifts or operational responsibilities and allow eligible dealers within the pool to handle the incoming request.
The manual dealing layer therefore becomes part of the routing architecture rather than a separate workflow outside the trading system. This is especially relevant for brokerages operating continuously across several time zones. Dealing responsibility can be distributed across a team while the underlying routing rule remains unchanged.
Virtual Dealer turns dealing rules into execution logic¶
Human review is useful for exceptional situations, but it is inefficient to manually inspect transactions that can be evaluated using objective rules.
That is where a Virtual Dealer becomes useful.
In ST Trader, Virtual Dealer is an automatic policy engine embedded directly into the routing process. It can evaluate an incoming trade using configured execution criteria and decide whether that trade should continue, be rejected or move to the next step in the route.
Current policy checks include trade volume, market spread and deviation from a requested reference price. The concept is more important than the individual parameters: instead of writing external dealing software or building a custom bridge for every execution rule, the broker can introduce decision logic directly into the trading flow.
Imagine that a broker wants orders below a certain size to continue automatically, provided that the current market spread remains within an acceptable range. When those conditions are satisfied, the request can proceed normally. If the conditions fail, the trade can move to another stage — for example, manual review or a different execution route.
This produces a useful separation between routine and exceptional order flow without introducing another disconnected system.
Quote management deserves the same attention as trade routing¶
Execution problems are visible because they directly affect orders. Pricing problems can be more subtle.
A price source may remain connected but stop sending updates. A backup provider may be available but significantly displaced from the primary feed. A source may begin publishing abnormal spreads or irregular price jumps.
A resilient trading platform therefore needs to evaluate not only whether a provider is connected, but whether its quotes should currently be used.
ST Trader addresses this through Quote Policies. A Quote Policy determines which provider is allowed to update a symbol’s live market price. Sources can be feeders, gateways or plugins, and the same policy can be reused across multiple symbols.
One particularly important mode is priority failover. The broker can define a preferred quote source and one or more alternatives. If the active source becomes stale, the platform can move to the highest-priority healthy source. If the primary provider later stabilizes, the platform can return to it according to the configured recovery rules.
The practical value is continuity. Instead of waiting for an operator to notice that a feed has stopped updating and manually change the pricing source, the failover logic exists inside the pricing infrastructure.
A backup feed is useful only if its prices are valid¶
Automatic failover creates another problem: not every available source should automatically be trusted.
Suppose the primary provider stops updating and a backup source is technically online, but its price differs significantly from the market currently displayed to clients. Switching immediately could create an artificial price jump.
For this reason, quote management needs validation rules as well as priority. ST Trader’s Quote Policies can apply controls around spread, price jumps, deviation during source switching, quote timestamps and crossed bid/ask prices.
These checks turn quote management from a simple source selector into a market-data control layer. That difference matters operationally. A broker does not merely want a price to exist. It wants a price that satisfies the conditions required for a stable trading environment.
What a real hybrid setup may look like¶
Consider a broker trading EURUSD with several client segments.
The broker receives pricing from a primary market-data source and maintains another provider as a backup. Under normal conditions, clients see prices based on the primary source. If that feed becomes stale, the Quote Policy moves pricing to the backup source once the relevant failover conditions are met.
Execution is handled separately. Standard retail flow may continue through the platform’s internal execution process. A professional account group may instead match a route that sends transactions through an external liquidity gateway. Large transactions could first pass through a Virtual Dealer policy. If the volume, spread and price-deviation conditions are acceptable, execution proceeds. If not, the request moves to a manual dealer pool.
All of this can occur while clients continue to see pricing controlled by an independent Quote Policy.
That is the core architectural idea: market-data selection, execution routing and dealing policy are separate layers that cooperate with each other without becoming the same layer.
This distinction makes the system easier to change as the brokerage evolves. A new pricing source can be introduced without redesigning every execution route. A new LP can be added without necessarily changing the client-facing quote source. A dealer policy can be adjusted without rebuilding the liquidity connection.
Routing and hedging should not be confused¶
There is another distinction worth making because the two concepts are sometimes mixed together.
Execution routing determines what happens to a trade before its execution path is completed. Post-trade hedging is a separate process in which exposure already held internally is subsequently offset with an external counterparty.
These are not identical workflows.
In the current ST Trader routing implementation, Internal is a terminal execution step. A workflow in which a position is first internalized and later automatically hedged through a gateway requires a separate hedge lifecycle rather than simply configuring Internal → Gateway as another routing sequence.
For an experienced brokerage team, this distinction is important when designing a risk-management architecture. Pre-trade routing answers “Where should this transaction execute?” Post-trade hedging answers “What should we do with the exposure that already exists on the broker’s book?” A mature brokerage infrastructure may use both, but they solve different problems.
Why infrastructure ownership changes the liquidity conversation¶
Liquidity management becomes even more important when the trading platform is deployed on infrastructure controlled by the broker.
In a self-hosted model, the broker controls the trading engine, configuration, logs, gateways and deployment environment rather than relying entirely on vendor-operated shared infrastructure. ScaleTrade’s self-hosted architecture places the trading engine, back office, APIs and liquidity gateways within the broker-controlled environment.
That can affect how the brokerage designs connectivity. Infrastructure can be positioned closer to a liquidity provider or exchange. FIX sessions remain inside the broker’s own environment. Execution rules and market-data policies are part of the broker’s infrastructure configuration.
For institutional brokers and firms with more complex execution requirements, this often becomes as important as the number of available LP integrations.
The central question changes from “Which liquidity providers can this platform connect to?” to “How much control do we have over what happens between the liquidity provider and the client trade?”
That is a much more useful way to evaluate brokerage technology.
Liquidity management is ultimately an orchestration problem¶
Connecting an LP through FIX is technically important, but connectivity alone does not define the quality of a brokerage execution architecture.
The more difficult challenge is coordinating several layers at once. Prices have to come from reliable sources. Failover needs to be deterministic. Orders have to follow the appropriate execution path. Exceptional flow may require either automated checks or human review. External liquidity needs to coexist with internal execution without forcing the entire brokerage into a single model.
For that reason, modern liquidity infrastructure is best understood as an orchestration layer between market data, risk policy and execution.
ST Trader’s gateway, routing, dealing and Quote Policy architecture is designed around that idea. Rather than treating liquidity as one connection at the edge of the platform, it makes connectivity part of a broader execution model — one that can evolve as the broker adds providers, asset classes, client segments and more sophisticated risk controls.
For a new brokerage this can simplify the initial infrastructure. For an established broker, it can provide something more valuable: the ability to change execution policy without rebuilding the entire trading stack.
Ready to explore what the stack looks like for your operation?Talk to the ScaleTrade team— we'll walk through the full infrastructure against your specific requirements, deployment model, and timeline.