Skip to main content
Notional uses fast attribution for trading and reconciliation for final correctness. When an exchange event arrives, Notional attributes it to the relevant account so positions, PnL, margin health, and liquidation monitoring update quickly. Later, Notional compares its internal ledger against finalized exchange execution.

​
Why Reconciliation Exists

External exchanges are the source of execution truth. Notional is the source of account truth. Most of the time those views match directly: an order is placed, a fill is observed, and the ledger records the account impact. Reconciliation covers the edge cases where the exchange’s finalized history differs from the first fast-path attribution. Examples include:
  • An exchange fill or cancellation was observed late.
  • A WebSocket update was missed and later recovered from exchange history.
  • A funding, fee, transfer, or withdrawal event needs to be matched to ledger state.
  • A result reported by the exchange is ambiguous until follow-up checks complete.

​
Corrections Are Append-Only

Reconciliation does not rewrite history. If a material difference is found, Notional appends an explicit correction so the ledger remains auditable. That means the account history can show both:
  • the original fast-path event Notional acted on
  • the later correction that aligns the account with finalized exchange execution
This preserves the reason for the change instead of silently replacing old state.

​
Where Finality Matters

Fast state is used for trading responsiveness and risk monitoring. Finalized, reconciled state is used for custody-sensitive actions such as withdrawals. That split lets Notional stay close to exchange latency while still gating money movement on stricter checks.