Stop Pricing Disputes Before They Start: Engineering a Forex Fee Schedule That Actually Reconciles

Brokerage fee schedules fail in predictable ways: the platform charges one thing, the statement shows another, and support ends up debating decimals with a client. Most “claims” aren’t fraud—they’re engineering gaps: ambiguous fee definitions, inconsistent rounding, missing timestamps, and fees that don’t reconcile across systems.

This post is a practical way to model spreads, commissions, swaps, and minimums so that (1) your rules are deterministic, (2) your reporting is explainable, and (3) your audit trail is defensible. Always check local regulations and your liquidity / platform agreements—fee disclosures and calculation methods can be jurisdiction-specific.

1) Start with a fee taxonomy your systems can share

Before you configure anything, define a shared vocabulary that your trading platform, CRM/back office, and reporting layer all agree on. Most disputes start when teams use the same word to mean different things (e.g., “commission” vs “fee,” “swap” vs “financing,” “markup” vs “spread widening”).

A clean taxonomy typically includes:

• Spread-related charges
  • Raw spread (LP/top-of-book)
  • Markup (your added spread, fixed or dynamic)
  • All-in spread (raw + markup)
• Commission charges
  • Per-side vs round-turn
  • Per-lot vs per-notional
  • Minimum commission rules
• Financing charges (swaps)
  • Long swap / short swap
  • Triple-swap day rules
  • Symbol-specific day-count conventions (where applicable)
• Non-trade fees (if any)
  • Inactivity, withdrawal, conversion—keep these separate from trade economics

Engineering tip: Write each fee as a function with explicit inputs and outputs (e.g., commission = f(symbol, account_group, volume, side, time)), then use the same function definition in both your statement logic and your reconciliation logic.

2) Model spreads as “price formation,” not a line-item

Clients rarely see “spread fees” as a line item; they experience it as execution price. That makes spread disputes harder—because you must explain why the price was what it was at that moment.

To reduce spread-related claims, define spread construction rules that are reproducible:

• Price source: Which feed(s) produce the raw bid/ask for each symbol?
• Markup method:
  • Fixed (e.g., +0.2 pips)
  • Percentage of raw
  • Tiered by account group, symbol, session, or volatility band
• Application point: Is markup applied before routing (affects execution) or after (statement-only, usually not recommended)?
• Precision and rounding: Quote decimals per symbol (e.g., 5-digit FX majors vs 3-digit JPY pairs) and define rounding direction.

Concrete example (fixed pip markup):

• Raw EURUSD at time T: 1.08400 / 1.08402 (0.2 pip)
• Markup: +0.6 pip
• All-in quote shown to client: 1.08397 / 1.08405 (0.8 pip)

If a client questions the fill, your audit trail should let you reconstruct: raw quote snapshot + markup rule + resulting quote + execution timestamp.

3) Engineer commission rules that survive edge cases

Commission disputes are usually caused by one of three issues: (1) side/round-turn ambiguity, (2) lot sizing and partial fills, or (3) minimums and currency conversion.

Define commissions with these fields (minimum viable “commission schema”):

• Charging unit: per lot, per 1M notional, per contract
• Charging timing: open, close, or both
• Rate: numeric value + rate currency
• Minimums: per order, per deal, per day, per ticket, per account
• Netting behavior: how to treat partial fills and multiple deals under one order
• Conversion rule: how a commission in USD is converted for an account in EUR (rate source + timestamp)

Edge-case checklist:

• Partial close (0.30 lots closed from a 1.00 lot position)
• Close-by / internal transfers (platform-specific)
• Symbol with non-standard contract size
• Commission charged in a currency different from account base

Concrete example (minimum commission):

• Commission: $6 per round-turn per lot
• Minimum: $2 per round-turn per ticket
• Client trades 0.10 lots
  • Calculated: $0.60
  • Minimum applies: $2.00

This is defensible only if the minimum is clearly disclosed and consistently applied across all tickets.

4) Swaps: define the calendar, the source, and the rounding

Swaps (financing) generate more “you changed the rules” complaints than spreads or commissions because they are time-based and can vary daily. You need three things: a reliable source, a clear accrual schedule, and consistent rounding.

Key design decisions:

• Swap source: LP-provided swap, platform swap table, or your own schedule (with governance)
• Accrual timing: when the platform posts swap (server time matters)
• Triple-swap day: define which day gets 3x (often Wednesday for FX spot, but confirm per symbol/asset class and your platform conventions)
• Rate unit: points, pips, annualized %, or currency per lot—don’t mix without explicit conversion
• Rounding: per position per day vs aggregate then round

Practical control: Version your swap tables and store effective timestamps. If you update swaps daily, keep history. When a client disputes a charge from last month, “current swap rates” are irrelevant—you need the exact rate table effective on that date.

5) Minimums and thresholds: make them deterministic and explainable

Minimum commissions, minimum spreads, minimum swap charges, and fee caps are where reconciliation often breaks—especially when different systems apply the threshold at different aggregation levels.

To avoid this, define (and implement) thresholds with these explicit rules:

• Aggregation level: per deal, per order, per position, per day, per statement period
• Trigger condition: e.g., “if calculated commission < minimum, charge minimum”
• Interaction with partial fills: apply minimum once per ticket, not per partial fill (or explicitly the opposite)
• Interaction with rebates/IB: does the minimum apply before or after rebates? (Document it.)

Example (threshold mismatch that causes claims):

• Platform charges minimum commission per deal
• Statement logic applies minimum per order
• Result: statement shows less commission than the platform ledger (or vice versa)

Pick one model and enforce it everywhere—including your reconciliation reports.

6) The reconciliation blueprint: what to log so disputes don’t become “opinions”

A fee schedule is only as defensible as your ability to replay it. When a complaint arrives, you want to answer with a reproducible calculation, not a screenshot.

Minimum audit trail for fee defense:

• Execution facts: order ID, deal IDs, symbol, side, volume, open/close price, timestamps (with timezone), account group
• Market data snapshot: bid/ask used for quote construction (or reference to stored feed tick)
• Fee configuration version: spread markup rule ID, commission schedule ID, swap table version
• Conversion rates: FX rate used for converting fees to account currency + timestamp
• Rounding metadata: precision per symbol and rounding direction used

Operationally, implement a daily (or intraday) reconciliation that ties together:

• Platform ledger totals (commissions, swaps)
• Back office/CRM computed totals
• LP reports (where applicable)
• Client statement totals

If any delta appears, you want it flagged before the client finds it.

7) Governance: change control, disclosures, and “claims hygiene”

Even a perfect model fails if pricing changes are unmanaged. Fee disputes often hinge on when a change took effect and whether the client was informed.

Simple governance that reduces risk:

• Versioned fee schedules: every change creates a new version with an effective timestamp
• Approval workflow: ops + compliance sign-off (check local regulations)
• Client-facing disclosure mapping: internal fee fields mapped to the exact language shown in T&Cs/specifications
• Exception handling: define what happens when data is missing (e.g., no conversion rate available)—don’t “guess” silently

Also align your support playbook with engineering reality:

• Provide a standard “fee breakdown” template per dispute
• Train support to request the right identifiers (order/deal IDs, dates, symbols)
• Escalate only when reconciliation shows an actual inconsistency

The Bottom Line

A brokerage fee schedule isn’t a PDF—it’s a set of deterministic functions that must reconcile across platform execution, back office reporting, and client statements. Model spreads, commissions, swaps, and minimums with explicit inputs, rounding, timestamps, and versioning. Log enough data to replay any charge months later, and run reconciliation before clients do.

If you want to implement fee schedule versioning, reconciliation-ready reporting, and configurable pricing logic across your stack, start here: /get-started.