What is smart order routing (SOR) in forex?

Smart order routing (SOR) is a rules-driven execution layer that decides where and how to route an order across one or more liquidity sources. In OTC FX, SOR usually optimizes for execution probability, spread, reject rate, last look behavior, and latency while enforcing exposure and credit limits.

What is a liquidity aggregator for forex brokers?

A liquidity aggregator normalizes quotes from multiple LPs/venues, applies symbol and contract mapping, runs markups, and routes orders using deterministic rules. It also measures execution quality (fills, rejects, slippage) and provides monitoring for dealing and risk teams.

How do you handle last look and rejects in multi-LP routing?

You treat last look as a probability and latency problem: rank venues by expected fill, implement timeouts, define fallbacks, and measure reject rate and slippage per symbol, time window, and client group. Without observability, last look turns into random execution quality.

Liquidity & Routing & Execution Quality

Smart Order Routing & Liquidity Aggregation

for Forex Brokers

Multi-LP execution is not 'plug in two liquidity providers and pick the best spread'. You are optimizing a system under constraints: last look, reject probabilities, latency budgets, exposure limits, and credit.

Talk to Brokeret

What SOR means in OTC FX
Typical broker topology
Quote normalization and symbol mapping
Routing rules: spreads vs probability vs toxicity
Last look, rejects, re-quotes and fallbacks
Markups, A/B book logic and client group pricing
Execution quality metrics
Risk and exposure controls
Observability and runbooks
Go-live checklist for multi-LP routing

1) What SOR Means in OTC FX

Smart order routing (SOR) is the decision engine between an order and a set of possible execution paths. In OTC FX, you deal with bilateral streams, last look, varying reject behavior, and different execution policies per LP.

A good SOR does not chase the tightest quote. It routes based on expected outcome: probability of fill, expected slippage, expected latency, and the risk posture of the broker.

Core Objectives Brokers Optimize

Execution probability: Maximize fill ratio under time constraints
Execution quality: Minimize negative slippage and reject loops
Stability under volatility: Avoid cascading failures during news spikes
Partner outcomes: Maintain acceptable flow quality for LP relationships
Broker risk posture: Enforce exposure and credit limits deterministically

2) Typical Broker Topology

Client UI

Web/mobile/desktop (quotes, charts, tickets)

OMS / Risk

Account checks, margin checks, throttles

Bridge / Aggregator

Symbol mapping, quote normalization, routing rules, markups

LP / PoP / PB

Execution streams, sometimes market data and drop copy

Companion guides: Liquidity provider integration and FIX API for brokers

3) Quote Normalization and Symbol Mapping

Multi-LP routing starts with normalization. LPs do not agree on symbol naming, precision, contract sizing, trading sessions, or even what constitutes "the same instrument".

Symbol Mapping

e.g., EURUSD vs EUR/USD

Digits / Precision

4/5 digits, pip conventions

Contract / Lot Sizing

Not all venues match

Trade Sessions

Per symbol, per day, holidays

Min/Max Sizes

Venue restrictions enforced before routing

A "tight spread" that is only available for a tiny size is a trap if you are routing larger tickets. Your aggregator should represent quotes as a structured book so the routing engine can reason about size.

4) Routing Rules: Spreads vs Probability vs Toxicity

Routing by best spread alone is fragile. In OTC FX, the best quote is often the quote most likely to reject you. A production SOR ranks venues using a score.

Input	How It's Used
Quoted spread	Tighter is better, but not dominant
Reject rate	Penalize venues that reject frequently for this symbol/time
Last look latency	Penalize venues with longer hold windows
Fill ratio	Prefer venues that actually fill in your ticket sizes
Slippage distribution	Penalize venues with heavy negative tails
Flow quality policies	Some venues penalize "toxic" flow patterns

Client-Group-Aware Routing

Brokers typically segment clients: retail, professional, affiliates/IB flow, VIP, and house accounts. Routing can differ by group based on risk posture, expected behavior, and commercial rules. The critical part is making this deterministic and auditable.

5) Last Look, Rejects, Re-Quotes and Fallbacks

Last look is not a moral issue; it is a system constraint. The worst-case pattern is "reject ping-pong": sending the same order to multiple venues and receiving multiple rejects while the client experiences a frozen ticket.

Design Principles That Reduce Damage

Timeouts: Enforce a maximum time-to-decision for each venue
Fallback policy: Define what happens on reject, no response, or partial execution
Do not retry blindly: Retries should be conditional on market movement and risk limits
Capture evidence: Store venue response codes and timestamps for disputes

Volatility Mode

During news spikes, your SOR should shift behavior: stricter throttles, shorter timeouts, and potentially routing only to venues with historically stable behavior. Volatility mode should be explicit, measurable, and reversible.

6) Markups, A/B Book Logic and Client Group Pricing

An aggregator is often responsible for price construction. This includes markups and spread rules that differ by account group. Keep the conceptual model clear -- many operational mistakes happen when pricing logic and execution logic get mixed.

Maintain a record of the quote shown to the client and the quote used for execution
Separate markup configuration from routing configuration
Make account-group rules auditable and versioned

7) Execution Quality Metrics That Matter

You cannot improve what you cannot measure. Multi-LP routing without metrics turns into superstition.

Metric	What to Measure
Fill ratio	Filled orders / attempted orders
Reject rate	Rejected orders / attempted orders
Time-to-fill	Distribution, especially p95 and p99
Slippage distribution	Not just average; look at tails
Requote behavior	Frequency and magnitude when applicable
Cancel/replace rate	Can indicate flow patterns and strategy behavior

Execution quality is not uniform. One LP may be excellent for small retail tickets and poor for larger sizes. Segmenting metrics by ticket size and client group is a practical way to route better.

8) Risk and Exposure Controls

Your SOR is a control plane. It should enforce risk checks before routing, not after you are already exposed.

Per-account throttles

Max orders per second and max open orders

Exposure limits

Per symbol, per group, and total exposure caps

Credit checks

Ensure credit is available before routing

Kill switch

Immediate stop on a symbol or venue when anomalies detected

9) Observability and Runbooks

Execution systems fail in patterns. If you can detect the early signals, you avoid the outage.

Reject spikes per venue and symbol
Latency spikes (network vs processing)
Fill ratio degradation per client group
Quote quality anomalies (stale quotes, crossed markets, gaps)
Session churn if your execution is via FIX

A dealer or on-call engineer should have a deterministic playbook: which venue to disable, what routing weights to change, and how to validate recovery. If decisions live only in memory, you will repeat incidents.

10) Go-Live Checklist for Multi-LP Routing

Validate symbol mapping and precision across all venues
Implement deterministic timeouts and fallbacks for last look/rejects
Define routing rules per client group and make them auditable
Calculate execution quality metrics per LP and per symbol
Implement volatility mode and test it under simulated spikes
Build dashboards and alerts before you go live
Store evidence logs for disputes (timestamps, responses, venue identifiers)

Related Guides

Need multi-LP routing that works in production?

We can help you implement SOR rules, monitoring, and operational runbooks that survive volatility.