A final position balance can be numerically correct while the record behind it remains incomplete. A useful reconciliation process explains how executions, allocations, confirmations and cash events produced the balance, including corrections and repeated messages.
Trace an event chain
FIX Trading Community’s post-trade guidance covers allocations, confirmations, settlement instructions and contract-lifecycle cash events. Its margin-information framework also distinguishes reporting at account, portfolio and instrument levels. Those are related views of activity, rather than substitutes for each other.
A systems mapping should identify the authoritative source for each event, the key used to match it and the owner responsible for exceptions. Timestamp format, units and message version belong in that mapping. Simply adding every received quantity is insufficient when a provider can replay or correct an earlier event.
Illustrative scenario: replay is not another fill
Assume a hypothetical order receives a 60-unit execution, E1, and a 40-unit execution, E2. E1 is then delivered again. A later correction withdraws E2 and replaces it with E3 for 35 units. The following simplified event ledger shows the expected quantity after each accepted change.
| Received event | Treatment in this example | Resulting quantity |
|---|---|---|
| E1 · 60 units | Accept new execution | 60 |
| E2 · 40 units | Accept new execution | 100 |
| E1 · replay | Recognize existing event; no new fill | 100 |
| Withdraw E2; E3 · 35 units | Apply linked correction | 95 |
A system that adds the replay reaches 160 units before the correction. A system that accepts the replacement without linking the withdrawal can retain another wrong balance. The control therefore needs both duplicate recognition and a documented correction relationship. The event log should retain the original receipt and its disposition rather than quietly overwriting the evidence.
Pair evidence with authorized visibility
A concrete implementation output can include the field dictionary, matching rules, correction tests, reconciliation report and named exception owners. For account data, the permissions must match the agreed scope. Kraken’s API guidance separates query, order-modification and withdrawal permissions; its newer funding-endpoint guidance also shows that read-only access can expose additional information when endpoint behavior changes.
The sample is an original simplified test case, not a universal FIX correction specification. A production interface must follow its provider’s identifiers, message definitions and replay rules, then reconcile against the designated statement. Read-only access still requires authorization, access review and a retention plan. The objective is an explainable record from source event to reported position, supported by tests that show what happens when the messages arrive more than once or change later.