Engineering · TRUEFIX LABS

Order Management System (OMS) Architecture

Design an OMS around durable order identity, revisions, state transitions, allocations, provider receipts, and reconciliation.

Short answer. An OMS is the durable source of truth for order intent and lifecycle, not a thin wrapper around a broker API. It must retain the original order request, revisions, account and environment, provider identity, client order ID, receipts, state transitions, and reconciliation evidence.

Core records

Keep separate records for order intent, submission attempt, provider receipt, fill, cancellation or replacement request, and reconciliation observation. This makes retries and audits explainable.

State model

Created → Submitted → Accepted → PartiallyFilled → Filled
                 ↘ Rejected / Cancelled / Expired
                 ↘ Unknown → Reconcile

State transitions should be validated, append-only where possible, and idempotent when the same provider event is received twice.

OMS and strategy boundaries

Strategies can request an intent. They should not mutate order state or call a provider directly. The OMS and risk engine decide whether an intent can become an executable command.

Operational questions

Which account and environment owns this order?
Which exact instrument mapping was used?
Can a timeout be reconciled by native order ID?
What happens to a replacement when the original is partially filled?

Sources

Last verified: 2026-09-28. Provider capabilities can change by region, account, product, environment, and entitlement; verify the linked official documentation before production use.

Last updated: 2026-09-28