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.
Definition
The Financial Information eXchange (FIX) protocol is the global open standard for the electronic communication of securities transaction data. Every institutional equity trade, every block order, every fill — all of it traverses at least one FIX session before it becomes a post-trade record. The protocol is not a single message type but a framework: a tag-value encoding scheme, a session layer for connection management, and a library of message types that cover the full trade lifecycle from pre-trade negotiation through post-trade confirmation. For trade capture, one message type dominates: the Execution Report (MsgType 8), which fires at the moment of a fill and triggers every downstream post-trade process.
FIX was introduced in 1992 specifically to replace telephone-based order communication between Salomon Brothers and Fidelity Investments. Within a decade it had become the de facto standard for buy-side and sell-side electronic trading. The FIX Trading Community, a non-profit industry consortium with member firms spanning the world's major investment banks, broker-dealers, exchanges, and asset managers, maintains the specification and publishes extension packs. The protocol is free to use, non-proprietary, and deliberately open — the FIX Trading Community exists expressly to prevent any single firm from owning the standard that the global market depends on.
FIX message structure and the tag-value encoding
FIX messages are structured as sequences of tag-value pairs, where each tag is a numeric identifier and each value is the data for that field, separated by a delimiter. Every message has a standard header containing the message type (Tag 35, MsgType), sender identifier (Tag 49, SenderCompID), target identifier (Tag 56, TargetCompID), and a sequence number. The body contains the message-specific fields. An Execution Report (MsgType=8) body contains the fill price, fill quantity, instrument identifier, counterparty, and a set of tracking tags that enable the receiving system to link this fill to the original order and to every subsequent post-trade event.
The tag-value format is not self-describing — a parser must know the FIX specification to interpret a message. A system that receives a FIX Execution Report and does not parse Tag 453 (Parties) will not know who is clearing the trade. A system that does not extract and preserve Tag 11 (ClOrdID) loses the client-side audit thread to the original order. These are not edge cases; they are the most common source of capture breaks in production environments, because FIX parsers and tag extraction logic are often built to extract only the tags the original implementation required, and the extended tag set added in FIX 4.4 and 5.0 is silently dropped.
Critical FIX tags for post-trade trade capture
| FIX Tag | Field Name | Post-Trade Purpose | Failure Impact |
|---|---|---|---|
| 11 | ClOrdID | Client-assigned order ID — the Golden Thread linking fill to settlement | Lost thread breaks audit from fill to sese.023 |
| 37 | OrderID | Venue-assigned order ID — links execution report to venue fill record | Required for trade date venue reconciliation |
| 48 | SecurityID | Instrument identifier value (CUSIP, ISIN, SEDOL) | Wrong ID routes to wrong SSI; wrong position |
| 22 | IDSource / SecurityIDSource | Identifies which identifier scheme Tag 48 uses (1=CUSIP, 4=ISIN) | Missing scheme breaks reference data and SSI lookup |
| 453 | Parties | Repeating group: executing broker, clearing broker, counterparty (FIX 4.4+) | Missing clearing party breaks settlement routing |
| 528 | OrderCapacity | Agency (A), Principal (P), or Riskless Principal (R) | Misclassification creates Rule 15c3-3 P&C violation |
| 150 | ExecType | Execution type — fills only (1/2 in FIX 4.2; F in FIX 4.4+) | Non-fill reports must not trigger trade capture |
FIX versions: 4.2, 4.4, and 5.0 in production
FIX 4.2 (1998) remains the most widely deployed version for US equity trade capture. Most broker-dealer OMS systems, executing brokers, and exchange gateways support 4.2 as a minimum, and many production environments have never migrated beyond it for equity fills. FIX 4.4 (2003) added the post-trade infrastructure that 4.2 lacked: MsgType AE (Trade Capture Report) for regulatory and middle-office reporting, the Tag 453 Parties repeating group for multi-party identification, and expanded message types for fixed income, FX, and derivatives. FIX 5.0 (2006) and its service packs separated the session protocol (FIXT 1.1) from the application layer, enabling FIX message encoding over non-FIX transport, and introduced FIXML — an XML-based representation of FIX messages that aligns more naturally with ISO 20022 schemas. For most equity capture pipelines in 2026, the working version is still 4.2 or 4.4; FIX 5.0 is more prevalent in cross-asset and derivatives environments.
The semantic gap: where FIX data gets lost
The semantic gap is the information loss that occurs when a FIX Execution Report is translated from the FIX layer into the back-office representation — a database record, a batch file, a proprietary format. The gap is invisible at the point of translation: the trade appears in the post-trade system. The consequence surfaces hours or days later as a settlement fail, an unmatched confirmation, or a regulatory misclassification. The most damaging losses are Tag 11 (ClOrdID) not preserved past the OMS layer, breaking the audit thread from the original order; Tag 453 Parties incompletely parsed so the clearing broker is absent from the settlement routing; and Tag 528 OrderCapacity ignored so Agency positions are booked under Principal rules, creating a Rule 15c3-3 possession and control misclassification. Under T+1, the time between semantic gap at capture and settlement fail at DTC has shrunk from two days to one — a tag not preserved at 10:00 AM on trade date becomes a fail at 3:30 PM the next afternoon.
The "FIX for Post-Trade" initiative and why it stalled
The FIX Trading Community made significant efforts in the early 2000s to extend the protocol into post-trade: MsgType AE was added in FIX 4.4, allocation and confirmation messages were developed, and settlement-adjacent workflows were specified. The initiative stalled because SWIFT already owned the back office. The MT540-543 message family for settlement instructions and the MT544-548 family for settlement confirmations were embedded in every CSD, custodian bank, and clearing firm's infrastructure. Large post-trade software vendors had built their systems on SWIFT connectivity, and CSDs required SWIFT instructions. No firm had the market power to force the plumbing to change. The result was a hard boundary in every broker-dealer's architecture: FIX governed the front office; SWIFT governed from the trade instruction to settlement finality. That boundary persists in most systems today. ISO 20022 — specifically the sese.023 settlement instruction and sese.025 settlement confirmation — is the migration target that both the FIX community and SWIFT are converging toward, but the migration is still in progress across the industry.
T+1 and the cost of FIX capture latency
Under T+2 settlement, a broker-dealer that received its Drop Copy feed on a 30-minute lag had two business days to enrich the trade, match it with the counterparty, and generate a settlement instruction. Under T+1, the DTCC affirmation deadline for US institutional equity trades is 9:00 PM ET on trade date. A 30-minute lag in the Drop Copy feed at 3:45 PM — in the last hour of trading — leaves less than five hours to enrich, match, and affirm. For a firm running an end-of-day batch trade capture process, T+1 is not a shorter settlement cycle; it is an architecture incompatible with T+1 affirmation: the batch process runs after the affirmation window has closed. The operational response to T+1 is event-driven capture: every MsgType 8 triggers the post-trade pipeline immediately, without waiting for a batch run, an end-of-day file, or a scheduled reconciliation.
FIX protocol — execution to settlement pipeline
Devancore Glossary · devancore.com
FIX protocol — execution to settlement pipeline
Devancore Glossary · devancore.com
How it works
1. FIX session establishment and connectivity
A FIX session is a persistent TCP/IP connection between two FIX engines — typically the firm's OMS and the broker's or venue's FIX gateway — with session management handled by the FIX session protocol (FIX 4.x session layer or FIXT 1.1 for FIX 5.0). The session uses a sequenced message model: every message has an incrementing sequence number, and gaps trigger a Resend Request. The Logon (MsgType A), Heartbeat (MsgType 0), and Test Request (MsgType 1) messages maintain the session and detect disconnections. For post-trade trade capture, two sessions matter most: the primary order routing session between the OMS and the executing broker, over which MsgType 8 fills are returned; and the Drop Copy session, which receives a parallel stream of all fills transmitted simultaneously to the post-trade infrastructure.
2. Order routing and the NewOrderSingle
The FIX workflow begins before execution with the NewOrderSingle (MsgType D): the buy-side firm's OMS sends an order to the executing broker via FIX, containing the instrument (Tags 48/22), direction (Tag 54, Side), quantity (Tag 38, OrderQty), order type (Tag 40), time in force (Tag 59), and the ClOrdID (Tag 11) the firm assigns to this order. The ClOrdID is the client's tracking token from this moment forward. Every subsequent FIX message related to this order — partial fills, full fills, cancels — carries Tag 11, allowing the client system to correlate all events in the order's lifecycle.
3. Execution Report received — the MsgType 8 trade capture trigger
When the order fills at the venue, the executing broker generates an Execution Report (MsgType 8). The message contains: ExecType (Tag 150) indicating a fill, the fill quantity (Tag 32, LastQty), fill price (Tag 31, LastPx), the broker-assigned OrderID (Tag 37), the client's ClOrdID (Tag 11) echoed back, the instrument (Tags 48/22), and Tag 453 Parties identifying the clearing firm and counterparty. The receiving system's capture logic checks ExecType: only fill types (values 1/2 in FIX 4.2, value F in FIX 4.4+) trigger a trade capture event. Order acknowledgments (ExecType=0), cancels (ExecType=4), and rejects (ExecType=8) do not book a position. Critically, the system must extract and store Tags 11, 37, 48, 22, 453, and 528 at this step — they will not appear again in the trade record unless explicitly preserved.
4. The Golden Thread — preserving Tags 11 and 37
Tags 11 (ClOrdID) and 37 (OrderID) are the Golden Thread: the pair of identifiers that ties every downstream post-trade event — enrichment, confirmation, settlement instruction, settlement confirmation — back to the original execution. When the trade reaches DTCC's CTM for matching, the counterparty's record references the same execution using their own order identifiers. When the settlement instruction is transmitted as an ISO 20022 sese.023, the originating trade reference carries forward. When the trade settles at DTC and the sese.025 confirmation arrives, the confirmation can be reconciled against the original fill only if Tags 11 and 37 have been preserved through every system hop. A firm that strips Tags 11 and 37 at the OMS boundary — translating them into an internal trade ID without maintaining the mapping — loses this traceability and must manually reconcile exceptions by price, quantity, and timestamp: the worst possible approach under T+1.
5. Drop Copy session — real-time feed to post-trade infrastructure
A Drop Copy session is a parallel FIX session configured to receive a copy of every Execution Report as it is generated, routed to the post-trade infrastructure, risk system, or compliance monitor. Unlike the primary OMS session (which is a two-way session for order routing and fill reporting), the Drop Copy session is typically one-way: the executing broker pushes fills; the receiving system acknowledges but does not send orders. For trade enrichment automation, the Drop Copy feed is the ingestion point: each MsgType 8 arriving on the Drop Copy session triggers an immediate SSI lookup for the counterparty and instrument, beginning enrichment before the trading day ends. Drop Copy latency is measured in milliseconds in modern FIX engine implementations; legacy configurations that poll or batch the Drop Copy feed introduce the latency that makes T+1 affirmation unreliable.
6. MsgType AE — Trade Capture Report for regulatory and middle-office reporting
The FIX Trade Capture Report (MsgType AE), introduced in FIX 4.4, is used to report completed trades to parties who were not part of the original execution session. Key use cases: prime brokerage (the prime broker receives MsgType AE reports of all trades executed by the fund across multiple executing brokers); FINRA TRACE reporting (fixed income trades reported post-execution); CAT (Consolidated Audit Trail) reporting for equities; and middle-office centralized trade hubs that aggregate fills from multiple execution venues. MsgType AE contains structured trade data including TradeReportID (Tag 571), TradeReportTransType (Tag 487, distinguishing new reports from cancels and corrections), and the full instrument and party set. A firm that ingests MsgType AE for regulatory reporting but MsgType 8 for trade capture must ensure both paths preserve the Golden Thread tags — Tag 11 must link the regulatory report to the captured trade record.
For CAT reporting specifically, the original MsgType 8 is the execution timestamp source that drives the CAT submission: Tag 52 (SendingTime) provides the microsecond-precision execution time that CAT requires for event sequencing — it captures when the executing venue transmitted the fill, not when the receiving system processed it. Tag 11 (ClOrdID) maps to CAT's order identifier; Tag 37 (OrderID) carries the exchange-assigned execution identifier. Firms building CAT reporting pipelines from FIX should ensure Tag 52 is extracted and preserved at MsgType 8 capture without replacement. A system that overwrites SendingTime with its own receipt timestamp will generate CAT submissions with execution times that do not match the venue's records — a record-keeping discrepancy examiners can identify by comparing the firm's CAT submission against exchange timestamps.
7. FIX to settlement instruction — the pipeline from Tag 11 to sese.023
After capture, the enriched trade record must become a settlement instruction. For US equities, the instruction goes to DTCC's DTC participant system. For cross-border securities, it travels via SWIFT MT54x or ISO 20022 sese.023. The FIX tags captured at MsgType 8 ingestion drive every element of the instruction: Tag 48/22 drives the CUSIP/ISIN lookup that returns the instrument's DTC eligibility and settlement rules; Tag 453 Parties identifies the delivering and receiving DTC participants; Tag 528 OrderCapacity determines whether the instruction is an agency delivery or a principal trade; and Tags 11/37 provide the trade references that appear in the instruction's settlement reference fields. A settlement instruction generated from a fully preserved FIX capture is deterministic: given the same MsgType 8 input, the same instruction is always produced. A settlement instruction generated from a semantically degraded capture record requires manual enrichment to fill the gaps — and under T+1, manual steps introduce the latency that misses the settlement window.
FIX trade capture — MsgType 8 vs MsgType AE paths
Devancore Glossary · devancore.com
FIX trade capture — MsgType 8 vs MsgType AE paths
Devancore Glossary · devancore.com
In Devancore™
Devancore FIX pipeline — event-driven, no batch layer
Devancore Glossary · devancore.com
Devancore FIX pipeline — event-driven, no batch layer
Devancore Glossary · devancore.com
Most post-trade architectures impose a translation gap between the FIX layer and the back office: the fill arrives via FIX, is loaded into the OMS, and then — hours later, or at end of day — is extracted in a batch file, converted to a proprietary format, and handed to the settlement system. That translation gap is where the Golden Thread breaks, where tags get dropped, and where the semantic content of the original fill is reduced to price, quantity, and instrument code. Devancore eliminates the translation gap entirely. Every FIX MsgType 8 is an event that enters the system directly and triggers the post-trade pipeline immediately — no batch run, no end-of-day file, no intermediate format.
Direct FIX Ingestion and the Atomic Ledger
Devancore's FIX engine connects directly to executing broker Drop Copy sessions. When a MsgType 8 with ExecType indicating a fill arrives, the engine parses the full tag set — including Tags 11, 37, 48, 22, 453, and 528 — and writes an immutable event record to the atomic ledger within milliseconds. The atomic ledger entry is the first and authoritative record of the trade: it contains every FIX tag that arrived, the raw message payload, and the timestamp of receipt. Nothing is discarded. No tag is treated as "front-office only." The raw FIX message is the settlement evidence from which every downstream record is derived.
This is exactly what the industry's "FIX for Post-Trade" initiative attempted and failed to achieve in the 2000s — treating FIX as a primary source of record for the back office, not just a front-office routing protocol. The initiative stalled because SWIFT interests and legacy vendor architecture made it impossible to retrofit real-time FIX ingestion into existing batch back-office systems. Devancore achieves it architecturally: there is no legacy batch layer to work around. The FIX message goes directly into the settlement pipeline.
Preserving the Golden Thread — ClOrdID to sese.023
Tag 11 (ClOrdID) and Tag 37 (OrderID) are extracted from every MsgType 8 and persisted in the trade lifecycle record as the canonical identifiers that link the fill to every subsequent event. When the trade is enriched — SSI lookup driven by Tags 48/22, clearing participant identified from Tag 453 Parties, position type determined from Tag 528 OrderCapacity — the enrichment record references the original ClOrdID. When the settlement instruction is generated, the ClOrdID appears in the sese.023 trade reference field. When the sese.025 settlement confirmation arrives from DTC, it is reconciled against the ClOrdID in the atomic ledger. The complete audit thread — from the original NewOrderSingle to the final DTC settlement confirmation — is traceable through a single identifier that was present in the first FIX message.
This lineage satisfies the "evidenced in writing" requirement for trade records under SEC Rule 17a-3 without a separate audit system: the immutable atomic ledger entry for each MsgType 8, with the full tag set preserved, is the trade record. FINRA examiners reviewing the firm's books for a specific trade can trace from the settlement confirmation backward through the enrichment chain to the original FIX fill — with every intermediate step timestamped and attributed.
Tag 528 and the 15c3-3 P&C Connection
Tag 528 (OrderCapacity) is the FIX tag most consequential for compliance that is most frequently ignored in post-trade systems. Agency (A) trades are customer orders: the securities delivered or received belong to customers, and the firm's Rule 15c3-3 possession and control obligations apply immediately upon settlement. Principal (P) trades are firm proprietary positions: they go onto the firm's trading book, are subject to Rule 15c3-1 haircuts, and do not trigger P&C obligations. Riskless Principal (R) trades combine elements of both. Devancore reads Tag 528 at MsgType 8 ingestion and applies the correct account classification and P&C tagging before the position reaches the books of record. An Agency fill books to the customer-owned pool at the atomic ledger level; a Principal fill books to the firm's proprietary account. This structural classification — derived from a FIX tag, not from a manual rekeying step — is what prevents a Rule 15c3-3 violation from originating in the capture layer.
Drop Copy to IBOR Update — Sub-Second Position Visibility
When a MsgType 8 enters the Devancore FIX engine, the position update to the investment book of record occurs in sub-second latency. The IBOR reflects the fill immediately: portfolio managers, risk systems, and compliance monitors see the updated position the moment it is captured, not after an end-of-day batch reconciliation. For T+1 operations, this matters for two reasons: first, the T+1 settlement affirmation deadline at DTCC requires a clean, enriched, matched trade by 9:00 PM ET on trade date — a trade that is not in the IBOR until tomorrow cannot be affirmed tonight; second, intraday position accuracy drives real-time compliance checks, including net capital calculations under Rule 15c3-1 and possession and control monitoring under Rule 15c3-3 that cannot be done on yesterday's position data.