Skip to content

Kernel Model

The Meridian kernel is a single, event-sourced engine. OMS (Order Management), EMS (Execution Management), and BOR (Book of Record) are not separate systems. They are API surfaces over a shared kernel that tracks the full lifecycle of every order from creation through settlement and reconciliation.

This means an order created via the OMS API is the same entity that the EMS routes to venues and that the BOR records positions for. There is no internal reconciliation between subsystems because there is only one source of truth.

Core Principles

Principle Description
Single source of truth All API surfaces operate on the same data. No internal reconciliation.
Event-sourced state Every state transition is an immutable event. Current state is derived by replaying the event stream.
Positions from transactions Positions are never stored directly. They are always derived from the transaction history.
Multi-view projections IBOR, ABOR, and PBOR are query projections over the same event stream, not separate stores.
Compliance as lifecycle gates Compliance checks are state transitions within the order lifecycle, not external monitors.
Multi-currency native Every monetary amount carries its currency. Currency is never implicit.
Dual timestamps Every event records ts_event (when it happened at the source) and ts_init (when the kernel received it), both in nanosecond precision.

Entity Model

Entity Description
Order The full lifecycle from creation to settlement. Carries portfolio_id, instrument_id, direction, ordered_quantity, compliance status, and state.
Allocation Block-to-account assignment after a fill. Supports pro-rata, percentage, rules-based, hierarchy, average price, and step-down schemes.
Placement A child order sent to a venue via the EMS. Linked to a parent order. Carries broker, venue, strategy, and slice quantity.
Response A fill, rejection, or quote from a venue, reported by a CCM plugin. Linked to a placement.
Position Share quantity per instrument per portfolio. Derived from fills; never stored directly.
CashMovement A cash debit or credit. Types include settlement, dividend, interest, fee, margin, collateral, FX, and transfer.

Two-Level Order Hierarchy

The kernel implements a parent-child order hierarchy:

Order (investment intent -- OMS level)
  |-- order_id, portfolio_id, instrument_id
  |-- direction, ordered_quantity, order_type, time_in_force
  |-- allocation_scheme, compliance_status
  |
  +-- Placement[] (execution attempts -- EMS level)
        |-- placement_id, order_id
        |-- broker_id, venue, strategy, strategy_params
        |-- slice_quantity
        |
        +-- Response[] (venue replies -- CCM level)
              |-- response_id, placement_id
              |-- filled_quantity, filled_price
              |-- trade_id (venue-assigned, required for dedup)
              |-- ts_event, ts_init

The Order represents the investment intent. The Placement represents an execution attempt at a specific venue with a specific strategy. The Response represents what the venue returned: a fill, a rejection, a quote, or an amendment.

Order State Machine (18 States)

The kernel uses an 18-state lifecycle with explicit ownership handoffs between the portfolio manager, the trading desk, and operations.

Primary Path

CREATED
  -> PENDING_PRE_TRADE_COMPLIANCE
    -> PRE_TRADE_COMPLIANCE_PASSED
      -> SENT_TO_TRADER              (PM hands off to trading desk)
        -> ROUTED
          -> PARTIALLY_FILLED
            -> FILLED
              -> CLOSED
                -> SENT_TO_OPERATIONS  (trading desk hands off to ops)
                  -> PENDING_POST_TRADE_COMPLIANCE
                    -> POST_TRADE_COMPLIANCE_PASSED
                      -> CONFIRMED
                        -> SETTLED
                          -> RECONCILED  (terminal)

Branch States

PRE_TRADE_COMPLIANCE_FAILED   (from PENDING_PRE_TRADE_COMPLIANCE)
POST_TRADE_COMPLIANCE_FAILED  (from PENDING_POST_TRADE_COMPLIANCE)
CANCELED                      (from any non-terminal state, subject to cancel authority)
REJECTED                      (terminal, system-initiated)

Compliance Checkpoints

There are two compliance checkpoints in the lifecycle:

  1. Pre-trade compliance -- evaluated after order creation, before the order is sent to the trading desk. The order transitions through PENDING_PRE_TRADE_COMPLIANCE and either passes or fails.
  2. Post-trade compliance -- evaluated after the order is closed and sent to operations. The order transitions through PENDING_POST_TRADE_COMPLIANCE and either passes or fails.

Both checkpoints are state transitions within the kernel. They are not external monitoring hooks.

Cancel Authority

Cancel authority is scoped by role and state:

Role Allowed States
PM CREATED, PENDING_PRE_TRADE_COMPLIANCE, PRE_TRADE_COMPLIANCE_PASSED, PRE_TRADE_COMPLIANCE_FAILED
Trader SENT_TO_TRADER, ROUTED (only if no fills exist)
Ops Cannot cancel orders

Dual Timestamps

Every event in the kernel carries two timestamps at nanosecond precision:

Field Meaning
ts_event When the event actually occurred at the source (e.g., when a fill happened at the venue)
ts_init When the kernel received and recorded the event

The difference ts_init - ts_event measures ingestion latency. If the source does not provide ts_event, the kernel sets it equal to ts_init.

This dual-timestamp model (adopted from NautilusTrader) enables accurate latency measurement, out-of-order event handling, and precise replay for backtesting.

Positions: Derived, Not Stored

Positions are never written to a store. They are computed on demand by replaying the transaction stream (fills, corporate actions, transfers). The kernel may cache materialized positions as projections, but the event stream is always authoritative.

A position includes:

Field Description
trade_date_quantity Includes unsettled trades
settle_date_quantity Only settled trades
available_quantity Settled minus encumbered
pending_receipt Buys awaiting settlement
pending_delivery Sells awaiting settlement
on_loan_quantity Securities lending
pledged_quantity Collateral
blocked_quantity Regulatory or operational hold

Multi-Basis Views

The same event stream supports three basis views:

Basis Name Description
IBOR Investment Book of Record Real-time, trade-date view. Includes all trades the moment they execute. Used by portfolio managers and risk.
ABOR Accounting Book of Record Settled view. Only includes trades that have completed settlement. Used by fund accounting and NAV.
PBOR Performance Book of Record Performance measurement view. Used for attribution, benchmarking, and return calculation.

All three are query projections over the same event stream. There is no separate data store per basis.

CloseOrder and CreateRemainderOrder

When execution on an order is complete (whether fully filled or partially filled), the EMS sends a CloseOrder command. This transitions the order to CLOSED and returns the executed quantity and the unfilled quantity.

If there is an unfilled quantity, the OMS can issue CreateRemainderOrder, which creates a new order linked to the original via an OrderLink of type remainder. The remainder order carries the unfilled quantity from the closed order and begins its own lifecycle from CREATED.

This pattern avoids modifying orders in place after execution begins. The original order is closed with its actual fill, and a new order is created for what remains.

Terminology

The kernel uses specific terminology that differs from some industry conventions:

Kernel term Not
direction side
instrument_id security_id, symbol
ordered_quantity quantity
executed_quantity cum_qty
filled_quantity last_qty (on a response)
Placement ChildRoute, child order
Response Fill, execution report

These terms are used consistently across all API surfaces and all SDK implementations.

API Surfaces

Surface Scope Key Operations
OMS Order management, compliance, allocation CreateOrder, UpdateOrder, CancelOrder, CloseOrder, CreateRemainderOrder, CreateAllocation, SendToTrader, SendToOperations
EMS Execution management, strategy, RFQ CreatePlacement, CancelPlacement, CreateResponse, SelectStrategy, RequestQuotes
BOR Positions, cash, settlement, reconciliation, journal GetPositions, GetCashBalances, SettleOrder, ReconcileOrder, CreateReconciliation, PostJournalEntry

All three share the same underlying kernel. All operations are invoked through the sidecar on localhost:9191.

Next Steps