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.
Definition
A trade capture system sits at the transition point between execution and trade lifecycle processing: the moment a commitment becomes a firm's official record. Before trade capture, a trade is an execution report from a venue or counterparty. After capture, it is a position in the firm's books, a record subject to regulatory retention, and the starting point for the post-trade processing workflow that ends at settlement.
The initial trade record created at capture includes:
- Instrument identifier (ISIN, CUSIP, SEDOL, or exchange ticker)
- Direction: buy or sell
- Quantity and price
- Counterparty and broker
- Account and portfolio
- Trade date and expected settlement date
- Execution venue and time
That initial record is incomplete. It does not yet contain the settlement instructions that tell the custodian where to deliver securities and from which account to pay. It may not yet have the tax lot assignment, commission calculations, or account-level allocation if it was part of a block order. Post-trade processing is the sequence of steps that transforms the incomplete capture record into an instruction the custodian or CSD can act on.
Under T+1 settlement, the accuracy of the initial capture record has become more consequential. In a T+2 world, a capture error had two days before it caused a settlement fail; under T+1, there is one day. What was once a recoverable mistake is now a time-critical exception.
Post-trade processing stages
Post-trade processing stages
| Stage | What Happens | Who Does It |
|---|---|---|
| Capture | Trade booked into firm's records from execution report | Unified Post-Trade Platform |
| Validation | Checked against limits, reference data, counterparty static | Unified Post-Trade Platform |
| Enrichment | SSIs, custodian account, settlement method, commissions added | Unified Post-Trade Platform |
| Allocation | Block trade split into individual account-level positions | Unified Post-Trade Platform |
| Matching | Details compared bilaterally with counterparty | DTCC CTM, MarkitServ, SWIFT |
| Affirmation | Buy-side confirms matched details and allocations are correct | DTCC ITP / TradeSuite ID |
| Confirmation | Both parties legally affirm the affirmed trade terms | DTCC / bilateral confirmation |
| Settlement instruction | CSD or custodian instruction generated and transmitted | Unified Post-Trade Platform |
| Settlement | Securities delivered, cash paid (DvP) | DTC, national or international CSDs |
The objective of the post-trade workflow is straight-through processing (STP): a trade that moves from execution to settled position without manual intervention at any stage. STP rate measures the percentage of trades that complete the full workflow automatically and is the primary operational efficiency metric in post-trade processing.
FIX and on-chain: two capture rails
Modern institutional operations now run two distinct capture rails in parallel. The traditional rail receives execution reports via the FIX protocol from exchanges, ECNs, and broker-dealers, then routes trades through the multi-step post-trade workflow described above. The on-chain rail captures settlement events directly from blockchain networks, where execution and settlement may occur in the same block.
FIX and on-chain: two capture rails
| FIX / Traditional Rail | On-Chain Rail | |
|---|---|---|
| Capture source | FIX execution report (4.2 / 4.4 / 5.0) | On-chain event monitor / block processor |
| Instrument types | Equities, bonds, FX, derivatives | Crypto, tokenized assets, stablecoins |
| Match method | DTCC CTM, MarkitServ, SWIFT | On-chain transaction verification |
| Settlement timeline | T+1 (US equities), T+2 (some instruments) | T+0 (seconds to minutes) |
| Settlement finality | CSD / custodian confirmation | Block confirmation |
| Settlement instruction | DTC format, SWIFT MT54x, ISO 20022 | Signed on-chain transaction |
| SSI equivalent | Standing settlement instructions | Wallet address and network routing |
| Fail risk | Counterparty fail, CSD processing error | Network congestion, gas limits |
On networks with deterministic finality, execution and settlement are the same event. There is no multi-step confirmation workflow because there is no settlement lag: one committed block is irreversible. The operational consequence is that the ABOR updates at the same moment as the IBOR, collapsing the IBOR-ABOR reconciliation gap to near zero for on-chain positions. This is a structural change to post-trade operations, not a marginal improvement.
Trade capture system versus OMS
An order management system (OMS) manages the pre-trade and execution workflow: order creation, routing to venues, execution, and order lifecycle tracking. A trade capture system receives the execution report from the OMS and handles post-trade processing: booking into official records, enrichment, allocation, matching, and settlement instruction generation. Trade capture may be a standalone system, a module within a broader post-trade management platform, or a function integrated directly within the OMS. At larger institutions, a dedicated post-trade management system sits downstream of the OMS and owns the workflow from booking through to settlement.
Why post-trade management software matters
The complexity of post-trade processing scales faster than trade volume. An institution that doubles its trade count more than doubles its operational exposure: more counterparties to match with, more SSIs to maintain, more settlement instructions to transmit, more custodian formats to support, more regulatory reports to file. Post-trade processing software automates each stage of the workflow, maintains the SSI database, connects to central matching utilities, generates settlement instructions in the correct format for each custodian, and surfaces exceptions that require manual resolution.
Without automation, the only alternative is headcount: operations staff manually enriching trades, calling counterparties to resolve matching failures, and transmitting settlement instructions by phone or fax. That model does not scale to institutional trading volumes and introduces the manual errors that cause settlement fails and regulatory risk.
In a hybrid environment, the trade capture system acts as the single ingestion point for both FIX messages and on-chain events, normalizing them into a unified audit trail before they reach the books of record.
How it works
1. Trade capture
At execution, the venue or counterparty generates an execution report. For traditional securities, the trade capture system ingests this report via FIX 4.2, FIX 4.4, or FIX 5.0. For OTC instruments, capture may come through proprietary APIs or manual entry. For digital asset trades on public blockchains, capture works differently: the system subscribes to block events and monitors on-chain transfer logs rather than waiting for a FIX message. The on-chain transaction hash becomes the trade identifier, and the block timestamp becomes the execution time.
Capture quality determines everything downstream. A trade captured with the wrong counterparty identifier, an incorrect settlement date, or a mismatched instrument code will fail at matching or enrichment, or generate a settlement instruction for the wrong instrument or account.
2. Validation
Immediately after capture, the trade is validated against:
- Reference data: does the instrument exist in the securities master? Is the ISIN, CUSIP, or identifier active and correct?
- Counterparty data: is the counterparty a recognized legal entity? Do their settlement details exist in the SSI database?
- Limit checks: does the trade fit within position, concentration, or risk limits?
- Account and portfolio: is the account active and authorized for this instrument type?
Validation failures caught within minutes of execution can be corrected before they cascade into enrichment or matching failures later in the day.
3. Enrichment
Trade enrichment adds the settlement-layer data not available at execution:
- Standing settlement instructions (SSIs): the counterparty's custodian account, depository participant IDs, and settlement method (delivery versus payment, free of payment)
- Custodian routing: which custodian will hold the securities on the firm's side, and the account at that custodian
- Commission and fee calculation
- Tax lot assignment
- FX conversion details for foreign-denominated instruments
For on-chain trades, enrichment adds wallet address and network routing rather than a DTC participant ID. Enrichment failures are the single largest source of settlement fails on the traditional rail. SSI database maintenance, keeping counterparty settlement details current across hundreds of relationships, is a significant ongoing operations function.
4. Allocation
Buy-side firms typically execute block orders on behalf of multiple accounts simultaneously. After execution, the block must be split into individual account-level allocations proportional to each account's share. Each allocation becomes its own trade record with its own settlement instruction to the relevant custodian.
Broker-dealers also perform allocations in related contexts: step-out transactions, give-up arrangements, and client-directed allocations where trades are executed by one broker but settled to accounts at another. Allocation introduces a second layer of matching: the executing broker must receive allocation details and confirm them against the block before generating individual confirmations.
5. Counterparty matching
Matching is the bilateral comparison of trade details between both counterparties. Both sides must agree on:
- Instrument, direction, quantity, price
- Settlement date
- Settlement instructions (which account delivers, which account receives)
In the US equity markets, institutional matching occurs through DTCC's Institutional Trade Processing (ITP) service via the Central Trade Manager (CTM). CTM compares trade details submitted by both sides and reports matched or unmatched status. For OTC derivatives, MarkitServ and Traiana handle bilateral matching. SWIFT matching is used in many cross-border securities transactions.
For on-chain trades, the match method is on-chain verification: the transaction hash provides an immutable, publicly verifiable record that both parties can reference. There is no bilateral dispute possible on a deterministic network.
Under T+1 settlement, matching failures that persist past the end of trade date cannot settle on time.
6. Affirmation
Affirmation is the step where the buy-side confirms that the matched trade details are correct and allocations are complete. In US institutional equity processing, affirmation occurs through DTCC's ITP platform via TradeSuite ID. An affirmed trade signals that the buy-side has verified the matched details and is ready for settlement instruction generation.
Affirmation has a defined cutoff under DTCC rules. Under T+1, the affirmation deadline for US equities is 9:00 PM ET on trade date. Trades not affirmed by the cutoff do not benefit from DTCC's guaranteed settlement. On-chain trades have no affirmation step: the block is the affirmation.
7. Confirmation
Confirmation is the legally binding step where both parties affirm the trade terms. For exchange-traded US equities, DTCC's affirmation and confirmation process serves this function. For OTC derivatives, ISDA-format confirmations are exchanged bilaterally or through electronic confirmation platforms.
A confirmed trade is locked: its terms cannot be changed without a novation or cancellation and rebooking. Confirmation triggers the final settlement instruction generation.
8. Settlement instruction and settlement
The settlement instruction is the directive sent to the custodian or CSD specifying the securities to be delivered and the cash to be received (or vice versa). Instructions are transmitted in the format required by the receiving institution: DTC format for US equities settled at DTCC, SWIFT MT54x messages for custodians, or ISO 20022 for modern CSD connectivity. For on-chain trades, there is no SWIFT or CSD instruction equivalent: the settlement instruction is the signed blockchain transaction itself, which is simultaneously the instruction, the execution, and the settlement evidence.
Settlement occurs when the CSD or custodian executes delivery versus payment: securities move from seller to buyer, cash moves in the opposite direction, simultaneously and irrevocably. For US equities, settlement occurs at DTCC's DTC subsidiary. For European securities, settlement occurs at national or international central securities depositories (CSDs) such as Euroclear Bank and Clearstream Banking, or through national CSDs within those groups. For on-chain assets, settlement occurs at block confirmation.
STP rate and exception management
Every stage produces either a straight-through outcome or an exception requiring human intervention. The STP rate is the ratio of trades that pass through all stages without manual touchpoints.
Common exception causes:
- Missing or outdated SSIs at enrichment
- Counterparty mismatches at matching (wrong price, wrong quantity, wrong settlement date)
- Affirmation deadline missed by buy-side
- Allocation instruction delays
- Reference data errors at validation
- Custodian format errors at settlement instruction transmission
Exception management is the core daily function of a post-trade operations team: reviewing the exception queue, identifying root causes, resolving issues before the settlement cutoff, and escalating persistent failures.
In Devancore™
Devancore captures trades from two rails within a single trade lifecycle workflow: FIX execution reports from traditional venues and on-chain events from blockchain networks. Both feed into the same position model, the same compliance controls, and the same books of record. The capture source is a property of the trade, not a separate operational silo.
FIX rail
FIX-sourced trades enter the capture layer from OMS integrations and direct FIX connections. Each trade is timestamped, assigned a unique identifier, and linked to the originating order and account before downstream processing begins. Enrichment runs automatically at capture: SSI lookup and validation convert the incomplete FIX record into a settlement-ready instruction without manual intervention. Enrichment exceptions surface immediately. A trade with a missing or ambiguous SSI is flagged at capture, not hours later at the settlement cutoff.
On-chain rail
On-chain trades are captured through a block processor that subscribes to the target network's RPC node and processes each new block as it is produced. For the Arc Network, Devancore uses Arc Feed, an open-source block processor that connects to an Arc RPC node, matches transfer events against tracked wallets, and emits structured transfer records into the post-trade workflow. Arc's Malachite BFT consensus delivers deterministic finality at the block level: one committed block is irreversible, with no confirmation depth to tune and no re-org risk to manage. The on-chain transaction hash is recorded as the settlement evidence in the ABOR entry, providing the same auditability as a custodian confirmation.
For on-chain trades, the FIX enrichment workflow (SSI lookup, custodian routing) is replaced by wallet address resolution and network routing. Matching is on-chain verification rather than bilateral CTM comparison. The settlement instruction is the signed on-chain transaction rather than a DTC or SWIFT message. Everything else in the post-trade workflow applies: the compliance check, the position update, the audit log entry.
Unified trade lifecycle
The trade monitor in Devancore shows both FIX and on-chain trades in a single view, with each trade's capture source, lifecycle stage, and settlement status visible in one place. A TSLA sell captured via FIX settles at DTCC on T+1 through the traditional multi-step workflow. A BTC/USD buy captured on-chain from a DEX settles at block confirmation with the same lifecycle controls applied. Both appear on the same operations dashboard, both flow through the same compliance layer, and both contribute to the same position record.
Straight-through processing
For trades that enrich and match without exception, the workflow is fully straight-through:
- Execution report received and captured (FIX or on-chain)
- Trade validated against reference data and limits
- Enriched with SSIs and custodian routing (FIX) or wallet address and network routing (on-chain)
- Allocated to individual account positions
- Settlement instruction generated and transmitted (traditional CSD or on-chain transaction)
- Position updates to IBOR immediately; ABOR updates at settlement confirmation
Exceptions route to the operations queue with context: the specific field that caused the failure, the counterparty, the expected settlement date, and how many hours remain before the settlement cutoff.
Audit trail and regulatory reporting
Every stage of the post-trade workflow is recorded in an immutable audit log across both rails. The log satisfies the trade record requirements of SEC Rule 17a-3, is retained in WORM-compliant storage per Rule 17a-4, and discharges CAT reporting obligations without a separate reporting system.