Dealing Desk Playbook: Approvals & Audit Logs

A dealing desk isn’t “old-school”—it’s a control layer. For many brokers, manual intervention is the difference between a contained incident and a costly execution dispute, liquidity blow-up, or regulatory headache.

The key is to treat dealing desk actions as a governed workflow: clear triggers, defined approvals, and audit-ready logging. This playbook explains when a broker actually needs a dealing desk, what to control, and how to operationalize it without killing execution quality.

1. What “Dealing Desk” Means in 2026 (And What It Doesn’t)

A dealing desk is an operational function (and often a set of tools) that allows a broker to supervise, approve, reject, or modify execution decisions under predefined rules. It’s not automatically synonymous with “manual price manipulation” or “unfair execution.” In modern brokerage operations, it’s closer to an exception-handling and risk-control layer.

In practice, a dealing desk capability can exist in multiple places:

Inside the trading platform’s administrative layer (e.g., dealer/manager functions)
In a bridge/aggregator (execution controls, routing, last-look handling)
In a risk backoffice (exposure limits, hedging, toxicity flags)
In a CRM/backoffice workflow (approvals, case management, audit trails)

What a dealing desk is not: a blanket excuse to intervene on profitable clients. If intervention is opaque, inconsistent, or poorly logged, it becomes a liability—commercially and from a compliance standpoint.

The best mental model is: a dealing desk is a governed “manual override” for edge cases—and the governance is the product.

2. Why a Broker Might Need Manual Intervention (Even With Good Liquidity)

Even brokers with strong LPs, a reputable bridge, and decent spreads run into conditions where “pure automation” breaks down. Automation is great for the median case; the dealing desk exists for the tail risk.

Common drivers are operational rather than strategic:

A liquidity provider changes fill behavior during volatility
A bridge experiences partial outage or quote gaps
A client disputes execution during a news spike
A risk limit is breached and hedging must pause

There’s also a client-experience angle. If you can’t intervene, you often can’t resolve problems quickly. That leads to:

Longer support cycles (“we can’t do anything, it’s the platform”)
More escalations to compliance
Higher churn among serious traders and IB networks

Finally, regulators and auditors (and even sophisticated counterparties) care about controls and evidence. If you have no structured approvals and no tamper-resistant logs, you may struggle to demonstrate best execution processes, conflict management, and operational resilience. Always check local regulations and your license obligations, and consult compliance professionals for jurisdiction-specific requirements.

3. How a Dealing Desk Workflow Works (From Order to Audit Log)

A dealing desk workflow should be designed like an operational pipeline with clear states. The goal is not to “touch more trades,” but to ensure that when you do touch a trade, it’s justified and traceable.

A practical step-by-step model looks like this:

a) Pre-trade controls (before the order is accepted)

Pre-trade checks reduce the need for reactive intervention later. Typical controls include:

Symbol/session rules (e.g., trading hours, holiday schedules)
Max lot size / max notional per ticket
Max order rate per account (anti-abuse throttles)
Margin checks and account state validation

b) Routing decision (A-book/B-book/hybrid/C-book)

This is where your execution model and risk policy meet. The routing decision may depend on:

Client profile and historical behavior
Instrument liquidity and time-of-day
Current exposure and hedge costs
Toxicity signals (latency arbitrage, news scalping patterns)

c) Exception triggers (when manual approval is required)

Manual approval should be event-driven. Examples:

Order size exceeds threshold
Slippage tolerance exceeded
LP rejects repeatedly
Price feed deviation vs. reference feed

d) Intervention action + reason code

If a dealer intervenes, the action must be captured with a standardized reason code (not free-text only). Reason codes enable reporting, pattern detection, and audit defensibility.

e) Post-trade review + immutable audit logging

Every intervention should generate a case record that ties together:

Market data snapshot
Order lifecycle timestamps
Approver identity
Final outcome and client communication

4. Key Benefits of a Proper Dealing Desk (When Done Right)

A well-designed dealing desk is primarily a risk and governance tool. It can also improve client outcomes by enabling faster, more consistent incident handling.

a) Controlled exception handling during volatility

Volatility creates edge cases: widened spreads, partial fills, rejections, and price gaps. A dealing desk lets you apply consistent rules such as:

Temporary execution throttles
Symbol-level “review mode”
Size-based approvals

This is especially important around high-impact news when liquidity can thin out and LP behavior can change.

b) Reduced operational loss from execution incidents

Execution incidents are rarely one trade—they’re clusters. Without controls, a single misconfiguration can cause a cascade (wrong symbol settings, wrong markup, stale quotes). A dealing desk can:

Pause execution on a symbol
Force manual review above thresholds
Route around a failing LP

c) Better dispute resolution and compliance posture

When a client disputes a fill, the winning factor is evidence. If you can reconstruct the timeline with market data context and approvals, you can resolve disputes faster and more fairly.

This also supports internal governance: management can review intervention rates, identify abuse, and validate that policies are applied consistently.

5. Core Components You Need: People, Policy, and Systems

Dealing desk capability is not just a button in MT5 or a bridge feature. It’s a stack.

a) People and roles (segregation of duties)

At minimum, define:

Dealer/Operator: executes the intervention workflow
Approver (2nd line): authorizes high-risk actions (dual control)
Risk/Compliance reviewer: audits patterns and exceptions

Even in small brokerages, separation of duties can be implemented with role-based permissions and approval thresholds.

b) Policies and thresholds (written, versioned, enforced)

You need documented rules for:

When manual intervention is allowed
What actions are permitted (reject, requote, reroute, cancel, freeze)
SLAs (how fast approvals must happen)
Client communication templates and escalation paths

Policies should be version-controlled. If the policy changes, the system should reflect which version applied at the time of the action.

c) Systems: platform controls + workflow + logging

Operationally, most brokers end up with a combination of:

Trading platform admin controls (MT4/MT5/cTrader/etc.)
Bridge/aggregator controls (routing, LP health, execution rules)
Risk backoffice (exposure, hedging automation, toxicity)
CRM/backoffice workflow (cases, approvals, KYC-linked account context)

Brokeret’s modular approach (Forex CRM + RiskBO + platform management + APIs) is designed to support this kind of split: execution/risk decisions close to the market, and approvals/audit trails in backoffice workflows.

6. Dealing Desk Models: From “Break Glass” to Continuous Supervision

Not every broker needs the same level of manual intervention. The right model depends on your execution setup, client mix, and regulatory expectations.

a) Break-glass model (rare intervention)

Best for brokers with stable A-book routing and mature liquidity:

Manual actions only during incidents
Clear emergency permissions
Strong post-incident review

This model minimizes latency impact and client friction.

b) Threshold-based approvals (selective intervention)

Common for hybrid brokers:

Manual approval for large tickets
Manual review for flagged accounts
Symbol-based controls during volatility

This model is scalable if you keep triggers narrow and automate the queue.

c) Active market-making desk (continuous intervention)

More complex and higher risk operationally:

Frequent manual decisions on pricing/execution
Tight integration between risk, pricing, and dealer actions

If you operate this model, governance and conflict management become central. Check local regulations carefully and ensure your disclosures and execution policies match your actual practice.

7. Intervention Triggers: The “If This, Then That” Rulebook

Triggers should be measurable, testable, and tuned over time. Avoid vague triggers like “suspicious behavior” without definitions.

A practical trigger library includes:

Size triggers: e.g., tickets above X lots or notional require approval
Slippage triggers: if expected vs. executed price deviates beyond threshold
Rejection triggers: repeated LP rejects within a time window
Latency/toxicity triggers: abnormal order-to-fill times, pattern-based flags
Exposure triggers: net open position (NOP) breach per symbol or group
Market integrity triggers: reference feed deviation, stale quote detection

Each trigger should map to an action set:

Route to alternate LP / alternate stream
Place the order into a manual approval queue
Temporarily freeze trading on a symbol (with time-bound expiry)
Reduce max order size dynamically

Operationally, the most important detail is SLA discipline. If manual approvals routinely take too long, clients experience worse execution and more disputes. Your workflow must define:

Maximum time in queue
Auto-fallback behavior (e.g., reject with reason vs. auto-route)
Escalation to on-call approver

8. Deep Dive: Designing Manual Approvals Without Breaking Execution Quality

Manual approvals are where good intentions often create bad trading conditions. The fix is to design approvals as rare, fast, and predictable.

a) Use tiered thresholds and dynamic sizing

Instead of “manual approval above 10 lots,” consider tiers:

0–X: fully automated
X–Y: automated with stricter controls (e.g., limited slippage)
Y+: manual approval

You can also use dynamic thresholds by session (Asia vs. London vs. NY) because liquidity depth changes.

b) Implement dual control only where it matters

Dual control (maker-checker) is excellent for governance but expensive operationally. Use it for:

Symbol freezes
Execution policy overrides
High-notional tickets
Changes to routing rules

Keep routine approvals single-operator with strong logging, and reserve dual control for high-impact actions.

c) Standardize reason codes and client-facing outcomes

Every approval/rejection should have:

Internal reason code (for reporting)
Client-facing message category (for support consistency)

This reduces “dealer discretion” risk and makes metrics meaningful.

9. Audit Logging: What You Must Capture to Be Defensible

Audit logging is not “store some notes.” It’s structured evidence that an action happened, who did it, why, and what data was available at the time.

At minimum, log these categories:

Identity & access: user ID, role, IP/device (where applicable), session ID
Action: approve/reject/reroute/freeze/override, with parameters
Reason codes: standardized taxonomy + optional free-text
Timing: order received, queued, approved, executed, reported (timestamps)
Market context: top-of-book snapshot, spread, volatility markers, reference feed delta
System context: LP/bridge status, rejection codes, connectivity events

Two practical requirements that brokers often miss:

Immutability: logs should be tamper-resistant (append-only design, controlled access)
Retention & retrieval: define retention periods, storage, and how fast you can retrieve evidence for disputes or audits

If your dealing desk actions live in one system and your case management lives in another, you need reliable correlation IDs (order ID, account ID, ticket ID) across platforms. Brokeret’s API-first approach is typically used to unify these records across CRM, RiskBO, and platform management layers.

10. Best Practices Checklist: A Dealing Desk That Scales

Use this checklist to operationalize dealing desk controls without creating chaos.

Define a trigger catalog (versioned): every trigger has an owner, threshold, and action.
Implement RBAC (role-based access control): dealers can act within limits; approvers can override; admins are tightly restricted.
Enforce maker-checker for high-impact actions: symbol freezes, routing overrides, policy changes.
Use reason codes + templates: reduce ambiguity and improve reporting.
Set SLAs and auto-fallbacks: if approval is not done in time, the system must behave predictably.
Create an incident playbook: who is on-call, escalation ladder, and communication steps.
Reconcile daily: compare execution reports, LP statements, bridge logs, and platform fills.
Monitor intervention rates: intervention % by symbol, session, account cohort, LP.
Run monthly governance reviews: sample interventions, verify policy adherence, tune thresholds.

The operational goal is simple: intervene less over time because your triggers and automation improve—while maintaining the ability to intervene when you must.

11. Common Misconceptions That Create Risk (Commercial and Regulatory)

Misconceptions lead to poor system design and inconsistent operations.

a) “If we have a dealing desk, we can fix any bad fill.”

You can’t “fix” market reality. You can only apply your execution policy consistently and resolve disputes with evidence. Over-correcting fills without a clear policy can create fairness issues and reputational damage.

b) “Manual intervention is always bad for clients.”

Unstructured intervention is bad. Structured intervention can protect clients from outages, obvious mispricing, or technical incidents—if your policy is transparent and your actions are logged.

c) “Audit logs are just for regulators.”

Audit logs are also for:

Internal loss prevention
LP dispute resolution
Support efficiency
Proving that a bad outcome was due to market conditions, not negligence

d) “We can do this with spreadsheets and Slack.”

You can start that way, but it doesn’t scale. The moment you have volume, staff turnover, or an audit request, informal processes become a liability.

12. How to Evaluate Dealing Desk Tooling (Platform, Bridge, Backoffice, CRM)

When evaluating technology, focus on controls and evidence—not just features.

Key evaluation criteria:

Integration coverage: MT4/MT5/cTrader/MatchTrader, bridge/aggregator, LP connectivity, CRM
Workflow support: queues, approvals, SLAs, escalation, case linkage
RBAC depth: granular permissions, dual control, audit of permission changes
Audit quality: structured logs, correlation IDs, exportability, retention controls
Latency impact: ability to keep the median path fully automated
Reporting: intervention rate dashboards, reason code analytics, cohort analysis
Operational resilience: failover, redundancy, and clear incident modes

A practical approach is to map your current and target state:

What decisions must happen in milliseconds (execution path)
What decisions can happen in minutes (approvals, disputes)
What decisions happen in days/weeks (governance, policy tuning)

Brokeret implementations typically separate these layers: RiskBO handles real-time exposure and routing logic; the CRM handles approvals, case management, and audit-ready reporting; platform management and APIs connect the execution layer to the operational layer.

13. Modern Applications: Dealing Desk for Hybrids, Prop, and Multi-Asset

Dealing desk workflows are evolving beyond classic FX spot.

For hybrid brokers, manual intervention often centers on:

Toxicity management (protecting LP relationships)
Exposure limits and hedging pauses
Session-based execution rules

For prop trading firms, “dealing desk” is often less about pricing and more about:

Rule enforcement (max daily loss, consistency rules)
Payout approvals and risk events
Investigation workflows tied to trader analytics

For multi-asset brokers (FX/CFDs/crypto/equities), the challenge is heterogeneity:

Different market hours and liquidity profiles
Different reference pricing sources
Different volatility regimes

The operational pattern remains the same: define triggers, implement approvals where needed, and maintain audit evidence that ties decisions to policy.

14. Future Trends: What Dealing Desks Will Look Like Next

The next generation of dealing desk operations is less “manual trading” and more “supervised automation.”

Trends to plan for:

Policy-as-code: execution and intervention rules managed like software (versioning, approvals, rollbacks)
Better anomaly detection: statistical baselines for slippage, rejects, and feed deviations by session
Unified evidence packs: one-click export of a dispute file (order lifecycle + market snapshots + approvals)
Granular client segmentation: routing and controls tuned by cohort, not just by account labels

At the same time, expectations will rise:

Faster dispute resolution timelines
More consistent application of execution policies
Stronger internal controls (especially for brokers operating across multiple jurisdictions)

Investing early in workflow and logging architecture usually costs less than retrofitting after a major incident.

The Bottom Line

A broker needs a dealing desk when automation alone can’t reliably handle volatility, toxic flow, exposure breaches, platform incidents, or execution disputes. The goal isn’t to “touch trades”—it’s to enforce a governed exception process with clear triggers, fast approvals, and defensible audit evidence.

Treat dealing desk actions as a workflow: define measurable intervention triggers, implement tiered approvals (with maker-checker for high-impact actions), and standardize reason codes so you can report and improve. Most importantly, build audit logging that captures who did what, when, why, and what market/system context existed at that moment.

If you want to operationalize dealing desk controls across execution, risk, and backoffice—without degrading day-to-day execution—Brokeret can help you design the workflow and integrate CRM, RiskBO, and platform tooling into a single audit-ready operating model. Get started at /get-started.