How a Forex Dealing Desk Works With Liquidity Providers

Contents

• What the desk actually does day to day
• How an order reaches an LP
• The nature of LP relationships
• Discussing flow characteristics with providers
• Hedging in practice
• Monitoring price and execution quality
• Escalating an issue to a provider
• Thin liquidity, rollover and major events
• Pricing problem, routing problem or configuration problem
• Operational checklist
• FAQs

What the desk actually does day to day

A dealing desk's relationship with liquidity providers is not a one-off integration project; it is a continuous operational function. On any given day the desk reviews overnight fills and rejects, checks that spreads by symbol and session are behaving as expected, confirms that all configured LP sessions are logged in and pricing, and looks for any drift in hedge ratios against the book the broker intends to run. Where a broker runs a hybrid model, the desk also tracks which flow is passed through to the market and which is warehoused, a distinction covered in detail in A-Book vs B-Book vs Hybrid Brokerage.

None of this replaces automated monitoring. RiskMan calculates exposure, applies thresholds and can trigger automated hedging actions continuously and without fatigue. The desk's job is judgment: deciding whether an alert reflects a genuine liquidity or pricing problem, a temporary market condition, or noise, and deciding what to do about it when the answer is not obvious from a dashboard alone. That division of labour is described further in Inside a 24/7 Forex Dealing Desk.

How an order reaches an LP

Mechanically, a client order originates on the trading platform, is evaluated against the broker's routing rules, and is passed to a bridge & gateway component. The bridge or gateway normalises the order, applies any configured markup, symbol mapping or pre-trade checks, and forwards it over a FIX session to the selected liquidity provider or aggregator. The response — a fill, partial fill, reject or requote, depending on the execution model in use — travels back through the same path to update the client's position on the platform.

Where a broker aggregates several providers, the bridge or an aggregation layer within the liquidity solutions stack selects among competing prices according to configured logic: best price, a weighted preference toward certain providers for certain symbols or sizes, or fallback ordering if a primary provider is slow or unavailable. None of that routing logic is static — it is reviewed and adjusted by the desk as execution data accumulates.

                                CLIENT ORDER FLOW
                                       │
                                       ▼
                          ┌───────────────────────┐
                          │   Trading Platform     │
                          │   (MT4/MT5, other)     │
                          └───────────┬───────────┘
                                      │
                                      ▼
                          ┌───────────────────────┐
                          │  Bridge / Gateway      │
                          │  routing, mapping,     │
                          │  FIX session mgmt      │
                          └───────────┬───────────┘
                                      │
                     ┌────────────────┼────────────────┐
                     ▼                ▼                 ▼
              ┌───────────┐    ┌───────────┐     ┌───────────┐
              │  LP Sess.  │    │  LP Sess.  │     │  LP Sess.  │
              │  (Tier 1) │    │  (Tier 2) │     │  (backup) │
              └───────────┘    └───────────┘     └───────────┘

   ── AUTOMATED BAND ──────────────────────────────────────────────
   RiskMan: exposure calc · threshold alerts · configured auto-hedge
   ── HUMAN BAND ──────────────────────────────────────────────────
   24/7 Dealing Desk: judgment, escalation, manual hedge, LP contact

                                      │
                                      ▼
                     ┌───────────────────────────────┐
                     │  Execution Analytics           │
                     │  fills, rejects, slippage,     │
                     │  latency, spread by session    │
                     └───────────────┬────────────────┘
                                      │
                        feedback loop back into
                                      ▼
                     routing rules · LP weighting · session config

The nature of LP relationships

A broker's relationship with a provider is defined by a handful of structural elements that the desk needs to understand well, even though InfyTradeTech does not set or disclose their commercial terms:

• Tiering — providers are typically arranged in tiers, with primary sources for core symbols and secondary or backup sources used for redundancy or specific instruments.
• Pool composition — whether pricing comes from a single provider, a small curated group, or a broader aggregated pool, affects depth, spread consistency and the impact of any one provider's outage.
• Symbol coverage — not every provider prices every instrument equally well; exotic pairs, metals and indices often have narrower coverage or wider spreads with some sources than others.
• Session hours — some providers price thinly or not at all outside their principal trading hours, which matters for symbols with an Asia- or US-session bias.
• Credit and prime brokerage arrangements — generically, these govern how much exposure can be run with a given provider and how settlement is structured; the desk works within limits set by the broker's treasury and compliance functions, not around them.

Reviewing an existing provider set against these dimensions is the subject of Evaluating a Liquidity Aggregator: A Broker's Checklist.

Discussing flow characteristics with providers

Liquidity providers price and manage risk differently depending on the flow they receive. Brokers and providers have an ongoing, general dialogue about the nature of flow being sent — its overall size, symbol concentration, and whether it behaves in a way the provider finds manageable — because this affects the quality and consistency of pricing offered in return. This is a legitimate and routine part of the relationship; it is not the same as a broker disclosing individual client identities or trading strategies, and it does not involve InfyTradeTech sharing confidential dealing rules. Brokers concerned specifically with disruptive flow patterns should also see Managing Toxic Flow in a Forex Brokerage.

Hedging in practice

Hedging against LPs happens on a spectrum from fully automated to manually directed. Automated hedging, configured and executed through RiskMan, covers the bulk of routine exposure management: net positions crossing a threshold trigger a hedge order sent through the same bridge path shown above. The desk's manual role comes in around the edges — adjusting hedge ratios ahead of known events, intervening when automated hedging is rejected or partially filled by a provider, or temporarily changing which provider carries the hedge because of an observed quality issue. Because hedging execution quality depends on the same bridge, session and provider infrastructure as client execution, degradation in one is frequently visible in the other.

Monitoring price and execution quality

Execution quality is judged against a consistent set of measures, tracked continuously and reviewed by the desk rather than left to occasional spot checks:

• Fill rates — the proportion of orders filled without rejection, by symbol, size band and session.
• Reject and requote rates — how often a provider declines or repricing an order, and under what conditions this increases.
• Slippage distribution — not just an average, but the shape of the distribution: whether slippage is occasionally large and skewed against the broker, or symmetrical and modest.
• Latency — round-trip time from order submission to confirmation, and how it changes under load or around news.
• Spread behaviour by session — whether quoted spreads widen predictably around rollover and news, or unpredictably at other times, which points to a provider- or feed-side issue rather than normal market behaviour.

Consistent, accurate reference pricing underpins all of this analysis; where the feed itself is suspect, see market data and price feeds. Server and network conditions on the broker's own side, covered under hosting and server support, can also distort latency figures if not ruled out first.

Escalating an issue to a provider

A well-formed escalation to a liquidity provider is specific and evidence-based. It typically includes the affected symbols and time window, the observed pattern (widened spreads, elevated rejects, delayed quotes), comparison against the provider's own historical baseline where available, and, where relevant, comparison against other providers pricing the same symbol over the same window. Escalations that are vague — "pricing feels off" without supporting data — are slower to resolve and harder for a provider to act on. Building this evidence trail is a standing responsibility of the desk, supported by the analytics layer shown in the diagram above.

Thin liquidity, rollover and major events

Certain periods are structurally different and are treated as such rather than judged against normal baselines. Thin liquidity around the New York close and into the Asia session, the rollover window itself, and scheduled high-impact events (central bank decisions, non-farm payrolls and similar) all typically bring wider spreads, reduced depth and a higher chance of rejects, even when every provider is functioning correctly. The desk's role here is to distinguish expected stress-period behaviour from a genuine fault, adjust client-facing parameters where the broker's policy allows, and confirm that automated risk controls are configured appropriately for the period rather than reacting to every session-driven spread widening as an incident.

Pricing problem, routing problem or configuration problem

A recurring diagnostic task is establishing which layer an execution quality issue actually belongs to before contacting anyone. The three are easily confused and require different responses.

• Pricing problem — the provider's own quotes are stale, wide or inconsistent with the wider market; the fix sits with the provider.
• Routing problem — pricing from providers is fine, but the bridge or aggregation logic is selecting a poor source, mishandling failover, or introducing delay; the fix sits in the bridge & gateway layer.
• Platform configuration problem — symbol settings, markup, execution mode or server-side parameters on the platform itself are producing the symptom, independent of anything upstream; the fix sits with platform administration, for example through MT4/MT5 administration.

Operational checklist

• Confirm all configured LP sessions are logged in and pricing before relying on any quality metric.
• Track fill rate, reject rate, slippage distribution, latency and spread behaviour by symbol and session, not as a single blended figure.
• Separate stress-period behaviour (rollover, news, thin sessions) from genuine faults before escalating.
• Build an evidence-based case, with comparison data, before raising an issue with a provider.
• Diagnose which layer — platform, bridge, feed or LP — is implicated before assigning an owner.
• Review routing rules and LP weighting periodically against accumulated execution data, not only when something breaks.
• Keep automated monitoring and human judgment distinct but connected, so alerts are investigated rather than only logged.

FAQs

Does the dealing desk negotiate directly with liquidity providers?

Day-to-day operational contact — raising execution quality issues, discussing flow characteristics in general terms, confirming session status — typically runs through the desk. Commercial negotiation, credit terms and prime brokerage arrangements are treasury and senior management functions; InfyTradeTech does not set or disclose those terms.

Is InfyTradeTech tied to particular liquidity providers?

No. InfyTradeTech is vendor- and provider-neutral. Our work covers the bridge, gateway, platform, monitoring and dealing operations that sit around whichever providers a broker chooses to work with, and we do not name specific providers as partners in this material.

How is a genuine LP pricing fault distinguished from normal market movement?

By comparing the provider's behaviour against other providers pricing the same symbol over the same window, and against that provider's own historical baseline for the same session and event type. An isolated deviation points to the provider; a shared deviation across all providers usually points to the market itself.

What role does RiskMan play in this relationship, if the desk is doing the judgment work?

RiskMan continuously calculates exposure and applies configured thresholds and automated hedging so that routine conditions are handled without waiting on a person. The desk's judgment is applied to the exceptions RiskMan surfaces and to the ongoing relationship management around providers, routing and escalation. See RiskMan for the software side of this pairing.

Can a broker running multiple providers see different execution quality between them for the same symbol?

Yes, and this is expected. Providers differ in coverage, session strength and pricing behaviour by instrument; this is precisely why fill rate, reject rate, slippage and latency are tracked per provider and per symbol rather than as a single broker-wide number.

What happens if a provider session drops entirely?

Well-configured routing fails over to a backup source automatically, with the desk confirming the failover behaved correctly and monitoring quality on the substitute session until the primary is restored. This is one of the reasons pool composition and backup coverage are reviewed rather than assumed.

Related Research

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

• A-Book vs B-Book vs Hybrid Brokerage: Technology, Liquidity & Risk Architecture
• 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