Picking a Forex Liquidity Provider: Evaluation Metrics, Test Design and Failover
Provider selection is an engineering evaluation: define metrics, design repeatable tests, record results and verify failover before you rely on a provider.
Define the metrics
- Spread by instrument and session.
- Fill ratio and rejection rate.
- Slippage distribution.
- Latency from order to acknowledgement.
- Quote update frequency and stale quote rate.
Define how each is measured and aggregated.
Design repeatable tests
Use the same instruments, order sizes and time windows for each provider, covering quiet and volatile sessions. Log raw data so results can be audited. Run long enough to cover varied conditions. See our liquidity provider guide.
Bridge and connectivity
Document the bridge architecture: aggregation, routing rules, monitoring and operator. Measure round-trip latency between the trading server and provider endpoints. See our hosting guide.
Failover
Test loss of feed, loss of connection and rejection storms. Define automatic and manual failover steps and measure recovery time.
Contract and risk inputs
Capture margin, settlement, rejection policy and termination terms as inputs to the risk model, and take legal advice. For payments, see the PSP evaluation guide.
Scorecard output
Produce a single scorecard per provider with the metrics, test dates and conditions, plus qualitative scores for support, stability and terms. Attach raw data.
Re-run the tests after a major change in volumes or technology, and use the scorecard in periodic reviews with the provider.
Metrics and test design
Define metrics: spread distribution by symbol and session, slippage distribution, rejection rate, last-look behaviour where applicable, latency percentiles, depth at size and fill ratio. Define test design: symbols, order sizes, sessions (quiet, busy, news), duration, and identical conditions across providers.
Record raw data. Summaries without raw data cannot be audited or re-run when conditions change.
Scorecard
| Criterion | Metric | Weight | Provider A | Provider B |
|---|---|---|---|---|
| Pricing | Median and P95 spread | |||
| Execution | Slippage, rejection rate | |||
| Latency | P50, P95, P99 | |||
| Depth | Fill at size | |||
| Stability | Disconnects, incidents | |||
| Terms | Minimums, margin, notice | |||
| Support | Response in test |
Score from data and keep the data attached. Review the weights with risk and operations.
Bridge, connectivity and failover
Specify protocol, hosting location, expected latency, throughput, session handling and reconnect behaviour. Define failover: secondary provider, automatic or manual switch, and the effect on pricing and risk. Test failover under controlled conditions.
Document the monitoring signals: connection state, quote age, rejection spikes and spread widening.
Contract and risk inputs
Review minimum volume, margin and funding, termination notice, change-of-terms rights, settlement and counterparty risk. Record which terms are negotiable and your position on each.
See our liquidity provider page for connection options.
Worked example: reading latency percentiles
Provider A has a median latency of 8 ms and P99 of 220 ms; Provider B has 12 ms and P99 of 40 ms. For clients who trade news, tail latency drives rejections and slippage, so B may serve better despite the higher median.
Select metrics that reflect your clients’ behaviour and weight them accordingly.
Ongoing performance review
After onboarding, monitor the same metrics continuously, compare monthly with the trial baseline and hold quarterly reviews with the provider. Escalate deviations with data.
Risk and exposure controls on the bridge
Configure risk controls at the bridge: exposure limits by symbol and in total, maximum order size, price validity checks and kill switches. Define who can change them and how. Test responses to price spikes and feed outages.
Document the settings and review them after significant market events.
Frequently asked questions
What metrics should be tested?
Spreads, slippage, rejections, latency, depth and stability across sessions.
Why keep raw data?
For auditability and for re-running comparisons later.
How should failover be tested?
Under controlled conditions with defined switch behaviour and monitoring.
Which contract terms matter?
Minimums, margin, notice, change rights and settlement.