← Glossary

System of Record Securities Operations

The authoritative single source of truth for a firm's positions, trades, and accounts — the system of record that all other systems, reports, and compliance functions derive from.

Definition

While the system of record (SOR) is a concept that applies across enterprise software — CRM systems are SORs for customer data, ERP systems for accounting and procurement data — in securities operations the system of record SOR carries specific regulatory and operational definitions that go beyond general data management practice. A system of record in securities operations is the designated authoritative source for a specific category of operational data: the single source of truth that resolves discrepancies when the same data appears differently in multiple systems. When a position appears differently in two systems, the SOR determines which version is correct. When a trade's settlement status is disputed, the SOR is the final answer.

For post-trade operations, the SOR holds trade captures, allocations, confirmations, settlements, positions, and cash balances. Every financial transaction flowing through the firm is recorded here, and the SOR updates in real time as trades execute, settle, and positions change — not in end-of-day batch cycles that leave intraday decisions unsupported by current data. Data integrity is the foundation of every downstream process: reconciliation, compliance monitoring, regulatory reporting, and client statements all depend on the SOR being complete, accurate, and tamper-evident. A system that can be silently modified after the fact — without an audit trail of who changed what and when — cannot serve as an authoritative SOR regardless of how current its data is.

Data governance defines which system holds authority for which data type and who has write access. Without data governance, multiple systems accumulate competing versions of the same data, and the SOR loses its authority through neglect rather than error. In securities operations, data governance for the SOR specifies: which systems are allowed to write to it, under what conditions, through what controls, and how discrepancies between the SOR and external records are adjudicated.

The SOR contains golden records — the reconciled, authoritative data entities that the system holds as definitive. In data management contexts, a golden record is the de-duplicated, validated version of a data entity that supersedes all other copies. The golden record for an instrument is the instrument master, the golden record for a counterparty is the counterparty master, and the golden record for a position is the settlement-confirmed holding in the operations SOR. The SOR is the system; the golden records are what it contains.

Regulatory requirements formalize the SOR concept for broker-dealers. SEC Rule 17a-3 specifies what records must be created, and SEC Rule 17a-4 specifies how long they must be retained and in what format — including the requirement that electronic records be stored in WORM (write once, read many) format to prevent post-hoc modification. A system that cannot produce a WORM-compliant audit trail does not satisfy the regulatory definition of a books and records system, regardless of its operational accuracy.

How it works

The system of record concept becomes critical when data exists in multiple places simultaneously — an OMS captures the trade, a risk system calculates exposure, a custodian holds the assets, and a reporting system generates client statements. Without a designated system of record, each system becomes an independent authority, and discrepancies between them have no resolution mechanism. The operations team then spends time determining which system is right rather than acting on the data.

In securities operations, the system of record sits within a three-layer data architecture that must be understood to avoid misattributing authority to the wrong system:

  • The operations system of record captures what actually happened in the market — what traded, what settled, what the custodian confirmed as held. It is the ground truth of completed market activity
  • The investment book of record (IBOR) reflects the portfolio manager's view of positions, including expected settlements and estimated values before custodian confirmation — a forward-looking layer that sits on top of the operations system of record
  • The accounting book of record (ABOR) reflects official accounting treatment, including accruals, valuations, and NAV calculations — the financial statement layer derived from the operations record

The SOR is what you reconcile against, not what you reconcile. Reconciliation validates that external records — custodian statements, counterparty confirmations, exchange reports — match the SOR. When they don't, the SOR is the reference point for identifying which external record is wrong, not for questioning whether the SOR itself is correct. If the SOR requires correction, that correction must go through the change management process with a full audit trail — not be applied directly to bring it into line with an external source without investigation.

Data integrity requirements for a system of record are more stringent than for an operational processing system. A processing system can tolerate corrections; a system of record must show that corrections happened. Every change to the system of record must be logged with the actor, timestamp, and reason, producing an append-only audit trail that regulators and auditors can reconstruct. A record that can be overwritten without trace is not a system of record — it is a current-state database.

Digital asset operations introduce an additional system of record challenge: the blockchain itself is an external, immutable record of on-chain transactions, but it does not constitute a Rule 17a-3 compliant books and records system on its own. The blockchain confirms that a transaction occurred, but it does not maintain the account-level, customer-level, and trade-level records that broker-dealer regulations require. The firm still needs an internal system of record that links on-chain transactions to the appropriate accounts, counterparties, and regulatory identifiers — and that system must maintain WORM-compliant records even when the underlying transaction is recorded on-chain.

In Devancore™

Devancore is built as the system of record for hybrid post-trade operations across traditional securities and digital assets. Every state change across all entities — orders, trades, allocations, confirmations, settlements, positions, and compliance events — is recorded in an append-only audit log with source attribution identifying whether the action was triggered by a FIX message, a UI action, an API call, or a system process. Nothing is overwritten; every correction creates a new record rather than replacing the old one.

The WORM Audit Vault enforces non-rewritable retention on all records, satisfying the format requirements of SEC Rule 17a-3 and Rule 17a-4 for both traditional and digital asset operations. For digital asset transactions, Devancore links on-chain settlement events to the corresponding internal trade, account, and counterparty records, and captures the on-chain transaction hash as part of the audit record. The hash provides independently verifiable, externally provable evidence of the on-chain event that cannot be fabricated or altered after the fact — strengthening the SOR's authority for digital asset positions beyond what an internal record alone can provide.

The practical consequence of this architecture: when a regulator, auditor, or counterparty disputes a position, settlement status, or trade event, Devancore produces the complete timeline — every state change, every actor, every timestamp — from trade capture through settlement finality and position update. The system of record is not the most recent version of the data; it is the complete history of how the data got to its current state. That distinction is what makes it authoritative.

Related terms