Trade Reconciliation

Trade reconciliation is the process of comparing trades recorded by a trading system with records from brokers, exchanges, clearing systems, custodians, or other external sources. The goal is to confirm that orders, fills, quantities, prices, fees, positions, and related identifiers agree across systems. When they don't, the difference becomes a reconciliation break that needs investigation.

This matters in algorithmic and automated trading because execution happens across several systems that don't always describe the same event in the same way. An order management system (OMS) may record an intended order, an execution management system (EMS) may receive several partial fills, and the broker may later report those fills with different identifiers or fee details. Reconciliation is the control layer that determines whether the internal trading state reflects what actually happened in the market.

How the Reconciliation Flow Works

A reconciliation process usually starts by collecting records from an internal trading database and at least one authoritative external source. The system normalizes those records, attempts to match corresponding trades, calculates differences, and routes unresolved breaks for review or automated correction.

1. Load internal orders, executions, allocations, fees, and position changes for the reconciliation period.
2. Import external records from broker APIs, FIX messages, clearing files, exchange reports, or custody statements.
3. Normalize symbols, timestamps, currencies, quantity conventions, side values, and identifiers.
4. Match records using exact identifiers where possible, then controlled fallback rules where necessary.
5. Calculate differences in quantity, execution price, fees, cash impact, status, or other required fields.
6. Classify unmatched or inconsistent records as breaks and send them through investigation or correction workflows.

The sequence matters. Matching before normalization can create false breaks simply because one system reports BTC-USD while another uses BTCUSD, or because one feed stores timestamps in UTC while another exports local exchange time.

Which Trading Records Need to Match?

Reconciliation can happen at several levels. A lightweight trading bot may compare completed fills and current positions, while an institutional workflow may reconcile individual execution events, allocations, commissions, cash movements, and settlement records.

These checks aren't interchangeable. Two systems can show the same final position even when one contains a duplicated fill and a compensating correction. Position-level reconciliation would appear clean, while execution-level reconciliation would expose the record-quality problem.

Matching Trades Without Creating False Breaks

The cleanest reconciliation key is a stable identifier shared by both systems, such as an exchange execution ID or broker fill ID. In practice, identifier chains are often messy. A strategy creates an internal order ID, the broker assigns another order ID, and each partial execution receives its own fill identifier.

Production systems therefore maintain a mapping between identifiers such as clientOrderId, broker order ID, execution ID, account, and venue. A common failure mode appears after reconnects or process restarts: the trading engine restores positions but loses part of the identifier mapping. The position may look correct, yet newly downloaded broker fills can no longer be tied confidently to the original internal orders.

Fallback matching may use account, symbol, side, quantity, price, and a timestamp window. That needs restraint. Two legitimate trades can have identical symbols, sizes, and near-identical execution times. Loose rules may silently match the wrong records, which is more dangerous than flagging an obvious exception.

Why Reconciliation Breaks Happen

Not every break means a trade was executed incorrectly. Many come from differences in timing, data models, or event handling. The useful question is: does the discrepancy represent real economic exposure, or merely a reporting mismatch?

• Partial fills: one internal order may correspond to several broker execution records.
• Cancel-replace activity: a modified order may receive a new external identifier even though the strategy treats it as one logical instruction.
• Duplicate events: reconnect logic or retry handling can ingest the same execution more than once unless fills are deduplicated by a stable key.
• Missing events: API disconnections or incomplete history requests can leave gaps between the live stream and downloaded records.
• Symbol mapping: futures contracts, option symbols, exchange suffixes, and broker-specific naming can prevent otherwise valid matches.
• Fee representation: commissions or exchange charges may arrive separately from fills or in a different currency.
• Timestamp differences: exchange time, broker time, local server time, and UTC can describe the same event differently.

Duplicate handling deserves special care. If a websocket reconnect causes an execution to be replayed, simply checking symbol and quantity isn't enough. Operators usually verify a durable execution identifier and persist processed IDs so replayed events remain idempotent rather than changing positions twice.

Building Automated Trade Reconciliation

Automated reconciliation is commonly implemented as a scheduled service, streaming process, or hybrid of both. Live checks can compare incoming executions as they arrive, while scheduled jobs re-query the broker or venue for an authoritative history and catch events missed during outages.

A robust design usually separates ingestion, normalization, matching, break classification, and remediation. Raw source records should remain available rather than being overwritten by normalized values. That makes an investigation auditable: an engineer can inspect what the broker actually returned, what transformation was applied, and why the matching engine accepted or rejected the record.

FIX-based environments may reconcile execution reports carried through the Financial Information eXchange protocol, while retail and crypto systems often work with REST APIs, websocket streams, CSV statements, or broker-specific reports. The transport doesn't change the core problem. Every execution needs a trustworthy path from external evidence to internal state.

When Position Checks Aren't Enough

Comparing current positions is useful, but it shouldn't automatically replace trade-level reconciliation. A matching net position tells you that current exposure agrees; it doesn't prove that every execution, fee, allocation, or cash movement was recorded correctly.

This distinction becomes important for P&L attribution, regulatory records, strategy analytics, and debugging. Suppose a strategy buys, accidentally records a fill twice, then later processes a correction that restores the right position. A simple position check passes. Historical turnover, fees, execution statistics, and realized P&L may still be wrong.

The trade-off is processing cost and complexity. Event-level reconciliation requires more storage, identifier mapping, and exception logic than a position snapshot. Systems handling modest retail automation may choose fewer controls, while higher-volume or multi-account trading usually benefits from retaining enough execution detail to explain every position change.

Keeping Reconciliation Reliable in Production

Reconciliation logic needs maintenance because broker APIs, symbol conventions, account structures, and reporting formats change. Monitoring should distinguish between genuine trading breaks and infrastructure failures such as an expired API token, truncated statement file, or history request that returned only part of the requested period.

Useful operational measures include the number of unmatched executions, aged breaks, automatically matched records, manually resolved exceptions, and repeated discrepancies by source or account. These measures are most useful as diagnostics rather than arbitrary targets.

One particularly dangerous state is a reconciliation job that reports no differences because its external feed stopped loading. A production design should therefore verify source completeness separately from matching success. Record counts, expected account coverage, retrieval timestamps, pagination completion, and data-source health can reveal that a suspiciously perfect reconciliation result is actually an empty comparison.