Devancore Inc.
Devancore Post-Trade Glossary
Glossary
Trading Platform Records
Trading platform records are the books-and-records layer around institutional trading activity: orders, executions, blotters, positions, cash, supervision, and retained evidence after the platform has generated the event.
Document source: https://devancore.com/glossary/trading-platform-records/
Devancore Post-Trade Glossary
Trading Platform Records
Trading platform records are the books-and-records layer around institutional trading activity: orders, executions, blotters, positions, cash, supervision, and retained evidence after the platform has generated the event.
Definition
Institutional trading platform books and records are the governed records a regulated firm must make and keep around trading-platform activity. The platform can generate orders, executions, blotter rows, and messages. That activity is not, by itself, the firm's books and records.
The practical control problem is memory. A reviewer needs to know what was originally entered, what filled, what was canceled or corrected, which account and instrument were used, how positions and cash changed, who approved an exception, and whether that history can still be produced. If those facts live only in a trading UI, a log file, or a reconstructed export, the operating record is weak even when the desk traded correctly.
Platform activity to statutory record
Platform activity to statutory record
The trading platform creates events. Books and records decide whether those events remain original, current, and retrievable.
| Record area | What must be kept | Control question |
|---|---|---|
| Order and ticket | Order terms, account, time of receipt or entry, instructions, and subsequent cancel or replace | Can the firm show the original instruction and every later change? |
| Execution | Fill price, quantity, time, venue or broker, partial remainder, and source message | Does the blotter match the FIX or API execution that created it? |
| Blotter and ledger | Daily purchases and sales, cash, positions, and original-entry identity | Is the official record current, itemized, and reconcilable? |
| Position and cash | Holdings, location, pending settlement, fails, and money balances | Do platform positions still agree with clearing, custody, and cash records? |
| Supervision | Exception review, cancel or correction approval, associated-person activity, and sign-off | Is there evidence that the required review actually occurred? |
| Preservation | Source payload, normalized record, change history, retrieval copy, and retention state | Can the firm produce an unaltered record for the required period? |
Execution ends when the platform has an accepted order or fill. Post-trade, clearing, settlement, positions, cash, supervision, and record retention begin there. A fill can later be DK'd, allocated, instructed, failed, repaired, or amended. Books and records have to follow that lifecycle, not freeze at the moment the OMS or EMS showed done.
The data needed for a clean operating record is specific. Order tickets and execution records need times, terms, accounts, and source messages. A FIX message audit trail for institutional compliance should preserve the payload that created the blotter row. Trade capture, allocation, confirmation, and settlement instruction connect the execution to the post-trade workflow. Positions and cash have to stay reconcilable to the same events. Electronic communications recordkeeping for broker dealers matters when chat, email, or other messages explain a cancel, a discretionary order, or a manual journal. Those artifacts should be retrievable with the trade, not stored as an unrelated archive.
SEC Rule 17a-3 names many of the records to be made: blotters, ledgers, order tickets, and related account records. SEC Rule 17a-4 WORM storage requirements for fintechs and other electronic brokers address how those records are preserved against alteration, including write-once media or an audit-trail alternative, and how long they remain retrievable. The trading platform does not finish that obligation by displaying current state.
Trading platform records — event to retention
Devancore Glossary · devancore.com
Trading platform records — event to retention
Devancore Glossary · devancore.com
How it works
Trading platform books and records work by converting platform events into original-entry records, then keeping those records current through change, lifecycle, supervision, and preservation. The workflow starts at order or fill capture and ends when the firm can retrieve an explainable record for the required retention period.
Books-and-records control points
Books-and-records control points
Breaks appear where platform logs are treated as finished statutory records.
| Step | Data required | Failure mode |
|---|---|---|
| Capture | Order, fill, cancel, replace, allocation, and source FIX or API payload | Activity exists in the platform UI but has no original-entry record |
| Normalize | Account, instrument, quantity, price, timestamps, and blotter identity | Official record cannot be traced to the platform event |
| Govern change | Cancel, correction, as-of, amendment, owner, and approver | A price or account change overwrites history |
| Connect lifecycle | Clearing status, settlement instruction, position, cash, and fail state | Books close on platform fills that later reject or fail |
| Supervise | Exception queue, associated-person action, review evidence, and WSP step | Supervision happened in email with no link to the trade |
| Preserve | Immutable or audit-trailed storage, retention clock, and retrieval format | Record exists but cannot be produced promptly or in readable form |
Capture is the first control. An order management system, execution management system, brokerage API, or FIX session can be the source. The books-and-records layer should store the source identity, timestamp, and payload reference with the ticket or blotter row. If capture waits for a nightly file, corrections and cancels may already have overwritten the original facts.
Normalization creates the official record. Account, instrument, quantity, price, currency, and dates have to resolve consistently so the blotter, position, and cash views are the same event. A platform symbol that does not map to the instrument master creates a record the firm cannot later defend.
Change control is where weak platforms fail. Cancel, correction, as-of, and amendment are different events. Each should keep the prior values, the new values, the reason, the actor, and the approver. Overwriting a price in place destroys original entry even if the latest economics are right.
Lifecycle connection keeps books aligned with clearing and settlement. A platform fill that the clearing firm rejects, a settlement instruction that fails, or a cash movement that posts later still belongs to the same record. Positions, stock-record location, and money balances should age with that state rather than remaining at trade-date optimism.
Exception and supervision points sit on the same chain. Manual account changes, cancel-replace bursts, associated-person overrides, and aged breaks need a workflow owner and a recorded review. Written supervisory procedures only help if the evidence of review is attached to the record being supervised.
Preservation is the last control. Records must remain retrievable in a usable form for the required period. WORM storage or an equivalent audit-trail method is a preservation design, not a substitute for complete capture. A firm can lock an incomplete blotter and still fail to explain the trade.
Trading platform — source to books-and-records map
Devancore · message matrix
| Rail | Message | Purpose | Record |
|---|---|---|---|
| OMS / EMS | order and route | intent record | order ticket, account, timestamp, instructions, and cancel or replace history |
| FIX / API | execution report | source lineage | raw payload, sequence, fill economics, and mapping into trade capture |
| Post-trade | blotter and settlement | operating record | allocation, confirm, SSI, position, cash, and fail or reject state |
| Communications | email, chat, or voice artifact | related evidence | message identity, time, associated person, and link to order or account |
| Preservation | retention package | statutory memory | original entry, change log, retrieval copy, owner, and retention status |
In Devancore™
Devancore — trading platform records evidence chain
Devancore · evidence stack
Source event
Orders, fills, cancels, replaces, allocations, and FIX or API payloads enter with identifier, timestamp, and source reference.
Official record
The event is mapped into ticket, blotter, position, cash, and account records the firm can treat as original entry.
Change control
Corrections, as-ofs, and amendments keep prior values, owner, reason, and maker-checker approval.
Supervisory evidence
Exception review, associated-person action, and close state remain attached to the same record.
Retention package
Operations, supervision, reporting, and exam production consume the same lineage rather than reconstructed logs.
Devancore supports institutional trading platform books and records as a post-trade operating record around platform activity. It can help teams capture source events, keep blotter and lifecycle state, retain correction and approval evidence, and feed supervision and reporting from the same chain.
Devancore does not act as a trading venue, broker-dealer, adviser, custodian, or clearing firm. It does not execute orders, carry customer accounts, or serve as the firm's designated archive vendor. Its role is to help keep the operating copy of trading-platform activity coherent: what happened, what changed, who approved it, and which downstream record used it.
In a Devancore-style workflow, an order, fill, cancel, replace, allocation, FIX or API payload, settlement update, or cash event enters as a source event. The record is mapped to account, instrument, quantity, cash, dates, and workflow state. Original entry, current state, correction history, supervisory review, and close state remain visible with owner, timestamp, reason, and source reference.
That structure is what operations and supervision actually use. The trading platform may know the live order book. Clearing may know the posted trade. Communications archives may know the related message. The books-and-records problem is whether those facts can still be assembled as one explainable record.
Conversational finance depends on the same chain. A user can ask which blotter rows lack source FIX messages, which corrections have no approver, which platform fills later failed at the clearing firm, or which aged exceptions have no supervisory close. The answer should resolve to source events, official records, status, owners, and evidence.
Related terms
- Rule 17a-3
https://devancore.com/glossary/rule-17a-3-books-and-records/
The SEC rule requiring registered broker-dealers to create and maintain current books and records for every securities transaction - including the blotter, general ledger, customer account ledgers, order tickets, and net capital computation.
- Broker-Dealer Audit Trail
https://devancore.com/glossary/broker-dealer-audit-trail/
The immutable, chronologically linked record of every trade lifecycle event — from order receipt through settlement — maintained to satisfy SEC Rules 17a-3 and 17a-4, FINRA clock synchronization requirements, and CAT reporting obligations.
- Trade Capture System
https://devancore.com/glossary/trade-capture-system/
The system that books an executed trade into the firm's official records and initiates the post-trade processing workflow from enrichment and matching through to settlement instruction.
- Regulatory Reporting — Securities
https://devancore.com/glossary/regulatory-reporting-securities/
The post-trade obligation to submit structured trade data — transactions, positions, and order lifecycle events — to regulators under MiFID II, EMIR, Dodd-Frank, and CAT to establish the supervisory record of each trade.
- RIA Trading Platform Post Trade
https://devancore.com/glossary/ria-trading-platform-post-trade/
RIA trading platform post-trade is the adviser workflow that verifies model-driven trades after execution across client accounts, allocations, restrictions, custodian feeds, corrections, reconciliation, and audit evidence.
- Fund Accounting Platform
https://devancore.com/glossary/fund-accounting-platform/
A fund accounting platform is the controlled operating layer that organizes fund-level records, NAV inputs, expenses, income, allocations, investor activity, reconciliation, approvals, and reporting evidence.
- OMS To Post Trade Integration
https://devancore.com/glossary/oms-to-post-trade-integration/
OMS to post-trade integration is the controlled handoff from order and execution records into allocation, confirmation, enrichment, settlement instruction, reconciliation, supervision, and reporting workflows.
- Trade Blotter Post Trade Workflow
https://devancore.com/glossary/trade-blotter-post-trade-workflow/
A trade blotter post-trade workflow turns blotter rows into governed operating records for allocation, enrichment, confirmation, settlement instruction, exception management, reconciliation, supervision, and audit evidence.
- Broker Dealer Clearing Connector
https://devancore.com/glossary/broker-dealer-clearing-connector/
A broker dealer clearing connector ingests clearing-firm activity, normalizes accounts and instruments, monitors settlement state, and preserves the audit trail used for reconciliation, books and records, and reporting inputs.
- FIX Protocol Trade Capture
https://devancore.com/glossary/fix-protocol-trade-capture/
Open financial messaging standard where MsgType 8 Execution Reports trigger real-time trade capture and settlement pipeline processing for broker-dealers.
- FIX Engine Connectivity for Broker-Dealers
https://devancore.com/glossary/fix-engine-connectivity/
The software layer managing FIX session state, message sequencing, heartbeats, and failover for broker-dealers connecting to brokers, venues, and ECNs.
- System of Record Securities Operations
https://devancore.com/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.
- Maker-Checker Workflow
https://devancore.com/glossary/maker-checker-workflow/
A two-person segregation of duties control requiring that any action entered by one operator must be reviewed and approved by a second before it takes effect.
- Written Supervisory Procedures
https://devancore.com/glossary/written-supervisory-procedures/
The compliance policies a broker-dealer must establish, maintain, and enforce under FINRA Rule 3110 to supervise all business lines and associated persons.
- FINRA Supervision Technology
https://devancore.com/glossary/finra-supervision-technology/
FINRA supervision technology is the software infrastructure broker-dealers use to implement, enforce, and document the supervisory controls required under FINRA Rules 3110 and 3120.
- DLT Books and Records Financial Institution
https://devancore.com/glossary/dlt-books-and-records-financial-institution/
The use of distributed ledger technology as books and records infrastructure for financial institutions, subject to the same substantive standards as traditional recordkeeping systems.
- Investment Book of Record
https://devancore.com/glossary/investment-book-of-record/
The IBOR — a real-time position record used by investment managers, capturing unsettled trades, accruals, and corporate actions ahead of custodian confirmation and ABOR settlement.
- Accounting Book of Record
https://devancore.com/glossary/accounting-book-of-record/
The ABOR: custodian-confirmed settled positions used as the authoritative basis for NAV calculation, financial statements, and regulatory reporting.
- Post-Trade Operations Software
https://devancore.com/glossary/post-trade-operations-software/
Technology automating post-execution back-office workflows — trade capture, confirmation, settlement, reconciliation, position management, and regulatory compliance.
- CAT Reporting (Consolidated Audit Trail)
https://devancore.com/glossary/cat-reporting-broker-dealer/
The obligation under FINRA Rule 6800 Series and SEC Rule 613 for broker-dealers to report every NMS and OTC equity order event to the CAT Central Repository by 8:00 AM ET on T+1, with customer account data updated daily through CAIS.
Contact
Request a briefing or platform walkthrough with the Devancore team.
Request access https://devancore.com/access/