OMS for Financial Services: Audit-Ready Agent Memory for Trading, Compliance, and Risk

Financial services AI agents operate under a unique combination of pressures. They make trading decisions in milliseconds, manage portfolios worth millions, analyze market data from dozens of sources, and execute orders through complex API chains. Every one of these decisions must be traceable, auditable, and defensible — often years after the fact. The regulatory environment is among the most demanding in any industry: Sarbanes-Oxley requires seven-year immutable retention of audit records, PCI-DSS governs payment card data handling, and Basel III imposes capital adequacy requirements that depend on accurate risk data.

Most financial AI systems today store their decision-making data in proprietary formats tied to specific trading platforms. When regulators ask "what did your trading agent know when it made this decision?", reconstructing the answer often requires ad hoc queries across multiple disconnected systems — logs, databases, message queues — none of which were designed for bi-temporal audit reconstruction.

The Open Memory Specification provides a structured approach. Every piece of financial knowledge — a market signal, a trading strategy, an order execution, a portfolio target — becomes an immutable, content-addressed memory grain with built-in provenance, temporal modeling, and compliance primitives. This post maps OMS to financial services workflows, from market analysis through trade execution to regulatory audit.

Memory types in financial context

Beliefs for market knowledge and trading signals

The Belief type (type byte 0x01, Section 8.1) models structured knowledge as semantic triples. In financial services, this covers both static market knowledge and time-bounded trading signals.

Static market data:

{
  "type": "belief",
  "subject": "AAPL",
  "relation": "sector",
  "object": "Technology",
  "confidence": 0.99,
  "source_type": "imported",
  "created_at": 1739900000000,
  "namespace": "market:reference",
  "structural_tags": ["reg:sox"]
}

The source_type: "imported" indicates this data came from an external authoritative source — a market data feed, an exchange reference dataset. The confidence: 0.99 reflects the near-certainty of externally sourced reference data.

Trading signals are Facts with temporal validity:

{
  "type": "belief",
  "subject": "AAPL",
  "relation": "signal",
  "object": "bullish_momentum",
  "confidence": 0.75,
  "source_type": "llm_generated",
  "created_at": 1739900000000,
  "valid_from": 1739900000000,
  "valid_to": 1739986400000,
  "namespace": "trading:signals",
  "structural_tags": ["reg:sox"],
  "provenance_chain": [
    {"source_hash": "abc123...", "method": "technical_analysis", "weight": 0.6},
    {"source_hash": "def456...", "method": "sentiment_analysis", "weight": 0.4}
  ]
}

The valid_from and valid_to fields define the temporal window during which this signal is considered actionable. A bullish momentum signal generated at market open with valid_to set to market close automatically becomes stale. The provenance_chain traces exactly which analyses — technical, sentiment, fundamental — contributed to the signal and with what weight. The confidence: 0.75 reflects the agent's assessed reliability of the signal.

This is critical for regulatory reconstruction: if a trade goes wrong, the audit trail shows exactly what signals existed, when they were valid, what analysis produced them, and at what confidence level.

Workflows for trading strategies

The Workflow type (type byte 0x04, Section 8.4) captures procedural memory — learned sequences of actions triggered by specific conditions. Trading strategies map naturally:

{
  "type": "workflow",
  "trigger": "RSI crosses below 30",
  "steps": [
    "Evaluate 30-day average volume against current volume",
    "Check current position limits for the symbol",
    "Verify margin availability for new position",
    "Submit limit order at current bid minus 0.5%"
  ],
  "created_at": 1739900000000,
  "namespace": "trading:strategies",
  "importance": 0.85
}

Each Workflow is immutable — the strategy as it existed when it was created is preserved as a content-addressed blob. If the strategy is refined, a new Workflow grain is created and the old one is superseded through the superseded_by field. The complete evolution of a trading strategy is preserved in the supersession chain.

Actions for order execution

Every order submitted to an exchange or broker API becomes a Action grain (type byte 0x05, Section 8.5):

{
  "type": "action",
  "tool_name": "submit_order",
  "input": {
    "symbol": "AAPL",
    "quantity": 100,
    "type": "limit",
    "price": 178.50,
    "side": "buy",
    "time_in_force": "day"
  },
  "content": {
    "order_id": "ORD-2026-78901",
    "fill_price": 178.45,
    "fill_quantity": 100,
    "commission": 0.65,
    "execution_venue": "NASDAQ",
    "fill_timestamp": "2026-02-19T14:30:22.456Z"
  },
  "is_error": false,
  "duration_ms": 23,
  "created_at": 1739900000000,
  "author_did": "did:key:z6MkTradingAgent001...",
  "namespace": "trading:execution",
  "structural_tags": ["reg:sox"]
}

The input map records exactly what was requested. The content map records exactly what happened — including the actual fill price, which may differ from the requested limit price. The duration_ms field captures execution latency, useful for best-execution analysis. The is_error flag and optional error field create an automatic record when orders are rejected.

Failed orders are equally important:

{
  "type": "action",
  "tool_name": "submit_order",
  "input": {
    "symbol": "AAPL",
    "quantity": 50000,
    "type": "market",
    "side": "buy"
  },
  "content": null,
  "is_error": true,
  "error": "Position limit exceeded: max 10000 shares per symbol",
  "duration_ms": 2,
  "created_at": 1739900000000,
  "author_did": "did:key:z6MkTradingAgent001...",
  "namespace": "trading:execution",
  "structural_tags": ["reg:sox"]
}

This creates an immutable record that the trading agent attempted an order, was rejected by position limits, and the rejection was captured with the specific error message. For compliance, this is as important as successful trades — it demonstrates that risk controls were active and functioning.

Goals for portfolio targets

Portfolio management objectives become Goal grains (type byte 0x07, Section 8.7) with machine-evaluable success criteria:

{
  "type": "goal",
  "subject": "portfolio-main",
  "description": "Achieve minimum 8% annual return on main portfolio",
  "goal_state": "active",
  "source_type": "user_explicit",
  "created_at": 1739900000000,
  "priority": 2,
  "criteria_structured": [
    {
      "metric": "portfolio_return",
      "operator": "gte",
      "threshold": 0.08,
      "window_ms": 31536000000,
      "measurement_ns": "portfolio:performance"
    }
  ],
  "namespace": "portfolio:targets",
  "structural_tags": ["reg:sox"],
  "allowed_transitions": ["satisfied", "failed", "suspended"]
}

The criteria_structured schema (Section 8.7) makes the success criteria machine-evaluable. The window_ms of 31536000000 (approximately 365 days in milliseconds) defines the measurement window. The measurement_ns field specifies which system namespace to query for the metric.

Risk constraints use Goal grains with locked invalidation policy:

{
  "type": "goal",
  "subject": "portfolio-main",
  "description": "Position limits must not exceed regulatory thresholds",
  "goal_state": "active",
  "source_type": "system",
  "created_at": 1739900000000,
  "priority": 1,
  "namespace": "risk:constraints",
  "structural_tags": ["reg:sox", "reg:basel-iii"],
  "invalidation_policy": {
    "mode": "locked",
    "protection_reason": "Regulatory position limit constraint - cannot be overridden by trading agents"
  }
}

The mode: "locked" setting (Section 23.2) means no agent can supersede or contradict this constraint. Any attempt returns ERR_INVALIDATION_DENIED. The fail-closed rule (Section 23.3) ensures that even if an implementation encounters an unrecognized protection mode, it defaults to locked behavior — the safe option for regulatory constraints.

States for trading session state

State grains (type byte 0x03, Section 8.3) capture the complete state of a trading session:

{
  "type": "state",
  "context": {
    "session_id": "trading-2026-02-19",
    "open_positions": "AAPL:500,GOOGL:200,MSFT:-300",
    "unrealized_pnl": "12450.00",
    "realized_pnl": "8320.50",
    "buying_power": "245000.00",
    "margin_used_percent": "34.2",
    "daily_trade_count": "47",
    "risk_exposure": "moderate"
  },
  "created_at": 1739900000000,
  "namespace": "trading:session",
  "structural_tags": ["reg:sox"]
}

If the trading agent crashes or the session needs to be reconstructed, the Checkpoint provides a complete snapshot. The context map captures open positions, P&L, buying power, margin utilization, trade count, and risk exposure — everything needed to resume operations or audit the session state at a specific point in time.

Events for analyst reports and market commentary

Event grains (type byte 0x02, Section 8.2) store raw, unstructured text. In financial services, this captures analyst reports, earnings call transcripts, and market commentary:

{
  "type": "event",
  "content": "Q4 2025 earnings beat estimates by 12%. Revenue growth 18% YoY driven by services segment. Management guided for continued margin expansion in FY2026. CFO noted supply chain improvements reducing COGS by 3%. Stock up 4.2% in after-hours trading.",
  "created_at": 1739900000000,
  "namespace": "research:earnings",
  "importance": 0.8,
  "structural_tags": ["reg:sox"]
}

Like clinical Episodes in healthcare, these are the input to consolidation — the process of extracting structured Facts. The trading agent might process this Episode and generate Belief grains: (AAPL, earnings_surprise, +12%), (AAPL, revenue_growth, 18% YoY). The extracted Facts carry source_type: "llm_generated" and reference the Episode in their derived_from field.

Bi-temporal modeling for decision reconstruction

Section 15 of the OMS specification defines bi-temporal modeling with five timestamps per grain. In financial services, this capability is not a convenience — it is a regulatory necessity.

The critical question regulators ask after a trading loss or market manipulation allegation is: "What did the trading agent know when it made this decision?"

This is a bi-temporal query. The trade happened at a specific time (event time). The question is: what Facts, signals, and analyses were active in the system at that moment (system time)?

OMS provides four query patterns (Section 15.2):

The third query pattern is the one regulators need most. Consider this scenario: at 14:30 on February 19, the trading agent bought 100 shares of AAPL. At 14:25, a bullish momentum signal (Belief grain) was generated with system_valid_from: 14:25. At 14:35, a contradictory bearish signal was generated, and the 14:25 signal was superseded (its system_valid_to was set to 14:35 by the index layer).

The bi-temporal query "What did the agent know at 14:30?" returns the bullish signal — because at 14:30, that signal had system_valid_from <= 14:30 and system_valid_to was still null (it had not yet been superseded). The bearish signal, with system_valid_from: 14:35, does not appear because it did not exist in the system at 14:30.

This precision is what distinguishes OMS from a conventional log. A log can tell you that a signal was generated and later invalidated. The bi-temporal model tells you exactly which signals were active — in the system's knowledge — at any historical moment.

SOX compliance and audit trails

Sarbanes-Oxley Section 802, implemented by SEC Rule 2-06 of Regulation S-X, requires that records relevant to audits and reviews be retained for seven years. The statute imposes criminal penalties of up to 20 years imprisonment for altering, destroying, or concealing records with intent to obstruct a legal investigation. Records must be preserved in formats that prevent alteration — SEC guidance references non-rewritable, non-erasable storage.

OMS provides structural properties that align with these requirements:

Tamper-evident storage

Every .mg blob is content-addressed — its identity IS its SHA-256 hash. If any byte changes, the content address changes. This is not a feature layered on top of a mutable format; it is the fundamental identity mechanism of the format. A tampered grain is immediately detectable because its content address will not match the hash computed over its bytes.

Section 20.6 of the OMS specification explicitly addresses SOX: ".mg blobs are tamper-evident (content-addressed, immutable). provenance_chain traces derivation. Combined with hash-chained audit log, provides complete audit trail."

Provenance chain for derivation tracking

Every grain carries a provenance_chain — the full derivation trail showing where the grain came from and how it was produced. For a trading decision, this chain might trace from raw market data (Episode) through signal generation (Fact) through strategy trigger (Workflow reference) to order execution (ToolCall).

Each provenance entry records:

• source_hash — the content address of the source grain (cryptographically verifiable)
• method — how the derivation was performed (e.g., "technical_analysis", "frequency_consolidation")
• weight — how much the source contributed (0.0 to 1.0)

Hash-chained audit log

Level 3 conformance (Section 17.3) requires a hash-chained audit trail. This is a log where each entry includes the hash of the previous entry, creating a chain where any modification to historical entries breaks all subsequent hashes. Combined with the content-addressed grains and their provenance chains, this provides:

1. Per-grain integrity — each grain's content address proves its bytes are unmodified
2. Per-grain provenance — each grain's provenance_chain traces its derivation
3. System-level ordering — the hash-chained log proves the sequence of operations
4. Tamper detection — any modification to any layer (grain, provenance, or log) is detectable

For the seven-year retention requirement, the .mg format's immutability is a structural advantage. Grains do not need write-once media or special archival procedures to be tamper-evident — they are tamper-evident by construction.

COSE signing for trade attribution

When multiple trading agents operate on the same platform, each agent signs its grains with its own W3C DID using COSE Sign1 envelopes (Section 9). This creates cryptographic attribution: the author_did in the grain payload is backed by an Ed25519 signature that proves which agent created the grain.

COSE_Sign1 {
  protected: {
    1: -8,                           // alg: EdDSA
    4: "did:key:z6MkTradingAgent001..."  // kid: signer DID
    3: "application/vnd.mg+msgpack"  // content_type
  },
  unprotected: {
    "iat": 1739900000                // timestamp: epoch seconds
  },
  payload: <.mg blob bytes>,
  signature: <Ed25519 signature, 64 bytes>
}

For regulatory inquiries — "which agent made this trade?" — the answer is cryptographically provable. The DID resolves to a public key (for did:key, the key is embedded in the DID itself). The signature over the grain bytes proves the grain was created by the holder of the corresponding private key.

This is particularly important when an organization operates multiple AI trading agents with different strategies and risk profiles. COSE signing establishes non-repudiation: Agent A cannot claim that Agent B placed the trade, because the signature on the Action grain is verifiable.

Sensitivity classification for financial data

Financial data requires different sensitivity levels, and OMS provides both header-level and tag-level classification.

Header-level sensitivity

The 2-bit sensitivity field in byte 1 of the fixed header (Section 13.1) enables fast routing:

For most financial data, the 01 (internal) classification applies — trading strategies, position data, and market analysis are organization-internal but not personally identifiable. Client account data with personal information uses 10 (PII).

Structural tags for regulatory classification

The structural_tags field carries fine-grained regulatory tags using the vocabulary from Section 13.2:

• reg:pci-dss — grain contains or references payment card data subject to PCI-DSS requirements
• reg:sox — grain is part of the SOX audit trail requiring seven-year immutable retention
• reg:basel-iii — grain contains regulatory capital data subject to Basel III reporting requirements
• sec:api_key — grain contains or references trading API credentials

The reg: prefix identifies which regulatory storage or retention rules apply. As the specification notes (Section 13.2), reg: tags are routing and policy directives — they tell the storage system which rules to apply, not what the data contains. A grain tagged reg:sox should be routed to immutable, seven-year retention storage. A grain tagged sec:api_key should be routed to encrypted, access-controlled storage with key rotation policies.

At write time, the serializer scans tags and sets header sensitivity bits to the highest classification present. The presence of sec:api_key triggers PII-level classification (10). The reg: tags set a minimum of internal (01).

Selective disclosure for client data

When sharing trading analytics with clients, the firm may need to demonstrate performance without revealing proprietary strategy details. OMS selective disclosure (Section 10) enables this:

A portfolio performance Fact shared with a client might elide the provenance_chain (which reveals the firm's analytical methods) and namespace (which reveals organizational structure):

{
  "type": "belief",
  "subject": "portfolio-client-789",
  "relation": "annual_return",
  "object": "12.4%",
  "confidence": 0.99,
  "source_type": "consolidated",
  "created_at": 1739900000000,
  "_elided": {
    "provenance_chain": "sha256:9a8b7c6d...",
    "namespace": "sha256:1e2f3a4b..."
  },
  "_disclosure_of": "sha256:original_grain_hash..."
}

The client can verify the performance figure is authentic (the original grain is COSE-signed, the elision hashes prove the hidden fields exist), but cannot see the analytical methods that produced it or the firm's internal organizational structure. If regulatory review requires the full grain, the _disclosure_of field links to the original.

Grain protection for regulatory constraints

Section 23 of the specification defines grain protection through invalidation_policy. In financial services, this mechanism enforces constraints that trading agents must not override:

{
  "type": "goal",
  "subject": "trading-desk-equities",
  "description": "Maximum single-position exposure must not exceed 5% of portfolio NAV",
  "goal_state": "active",
  "source_type": "system",
  "created_at": 1739900000000,
  "priority": 1,
  "namespace": "risk:limits",
  "structural_tags": ["reg:sox", "reg:basel-iii"],
  "invalidation_policy": {
    "mode": "locked",
    "protection_reason": "Regulatory concentration limit"
  }
}

The mode: "locked" means the trading agent cannot supersede this grain — it cannot modify its own risk limits. Only a human risk officer, through a properly authorized process, can create a new Goal grain that supersedes this one.

For constraints that require multi-person approval (four-eyes principle), the quorum mode applies:

{
  "invalidation_policy": {
    "mode": "quorum",
    "authorized": [
      "did:key:z6MkRiskOfficer001...",
      "did:key:z6MkRiskOfficer002...",
      "did:key:z6MkChiefRiskOfficer..."
    ],
    "threshold": 2,
    "protection_reason": "Position limit change requires dual authorization"
  }
}

The threshold: 2 means at least two of the three authorized DIDs must co-sign the superseding grain. This maps to the dual-control and segregation-of-duties requirements common in financial risk management.

A complete trading workflow in OMS

Here is how a complete trading workflow maps to OMS memory types:

1. Market data ingestion: Raw analyst reports and earnings transcripts become Event grains. Market reference data becomes Belief grains with source_type: "imported".

2. Signal generation: The trading agent analyzes Episodes and market Facts, generating signal Belief grains with source_type: "llm_generated", temporal validity windows (valid_from/valid_to), and provenance_chain tracing the analysis inputs.

3. Strategy evaluation: Active Workflow grains define the trading strategies. When a trigger condition matches (e.g., "RSI crosses below 30"), the corresponding Workflow is activated.

4. Pre-trade checks: The agent verifies position limits and risk constraints against active Goal grains. If a locked Goal grain says "max 5% single-position exposure," the order is rejected before submission.

5. Order execution: The agent submits an order via the broker API, creating a Action grain with complete arguments, result, fill price, and execution time.

6. Session state: At regular intervals and after significant events, State grains capture the complete trading session state — positions, P&L, margin, risk exposure.

7. Regulatory audit: Years later, a regulator asks what the agent knew when it made a specific trade. The bi-temporal query reconstructs the exact system state at the moment of the decision. The provenance chain traces from the trade (ToolCall) back through the strategy (Workflow), the signals (Facts), and the raw data (Episodes). Every grain is content-addressed, COSE-signed, and immutable.

Every grain in this workflow carries structural_tags: ["reg:sox"], routing it to seven-year retention storage. Every grain is content-addressed, making any tampering detectable. Every grain carries author_did, making every decision attributable. And the bi-temporal model ensures that historical reconstruction is precise — what the system knew, when it knew it, and what it did with that knowledge.

The financial services industry has some of the most demanding requirements for data integrity, auditability, and regulatory compliance. OMS does not replace the policy engines, risk management systems, or regulatory reporting frameworks that financial institutions have built. It provides a standard, portable, cryptographically sound data format for the agent memory that feeds into all of those systems — a format where immutability, provenance, and temporal precision are not afterthoughts but structural properties of every grain.