Straight-Through Processing (STP)
End-to-end automation of the post-trade lifecycle from execution to DvP settlement, with STP rate as the primary compliance KPI under T+1.
Definition
Straight-through processing (STP) is the end-to-end automation of the post-trade lifecycle — from trade execution through enrichment, matching, allocation, settlement instruction generation, and DvP settlement — with no manual intervention at any stage. In institutional markets, it is measured as STP rate: the percentage of trades completing each post-trade stage without a manual touchpoint. Industry practitioners and vendors also refer to this operational domain as institutional trade processing (ITP), a phrase that encompasses the workflow, the technology infrastructure, and the DTCC services that support it.
STP Rate as a Compliance Metric
Under the T+1 settlement cycle effective May 28, 2024, DTCC requires 90% of institutional trades to be affirmed by 9:00 PM ET on trade date. For a firm to meet this external benchmark consistently, internal STP must exceed 98% — the gap between 98% and 100% absorbs the trades that fall out to exception queues while still clearing the affirmation threshold. An 85% STP rate, broadly acceptable under the T+2 cycle when overnight resolution was feasible, constitutes a systemic risk under T+1. The compressed timeline provides insufficient opportunity for manual resolution before the affirmation window closes. Unaffirmed trades that miss the cutoff carry elevated settlement fail risk, and fails in equity securities trigger Reg SHO Rule 204 close-out obligations — mandatory buy-ins at the expense of the failing firm.
Six Fall-Out Points
STP failures cluster at six stages. Enrichment failures occur when counterparty standing settlement instructions (SSIs) are missing or stale, preventing the system from generating a valid settlement instruction. SSI mismatches occur when the SSI on file does not match the counterparty's current instructions — a common consequence of SSI data decay. Trade matching failures arise when execution details submitted by the broker do not reconcile with the investment manager's records in DTCC's Central Trade Manager (CTM). Affirmation misses occur when matched trades are not affirmed before the 9:00 PM ET cutoff due to system latency or workflow delays. Allocation errors — late, incomplete, or incorrect fund-level allocations — fragment account-level instruction generation. Settlement instruction rejections occur when DTCC or the CSD rejects a submitted instruction for format error, invalid account, or insufficient position.
STP pipeline — stage-by-stage failure modes and T+1 consequences
| STP Stage | Data Inputs Required | Failure Mode | Downstream Impact | T+1 Risk if Missed |
|---|---|---|---|---|
| Trade Capture | FIX execution report, instrument identifiers | Missing or incorrect identifiers | Enrichment cannot proceed | Affirmation window missed |
| Enrichment | SSI, counterparty standing data, account master | Stale or missing SSI | Instruction cannot be generated | Rule 204 buy-in exposure |
| Matching | Counterparty details via DTCC CTM | Trade detail mismatch | Affirmation blocked | 9:00 PM ET threshold missed |
| Allocation | Fund allocation file, account identifiers | Late or incorrect allocation | Per-account instructions fragmented | Instruction generation delayed |
| Instruction Generation | Validated SSI, DTC participant number | SSI failure or format error | Instruction rejected at CSD | Settlement fail on T+1 |
| Settlement | DvP instruction, securities position, funding | Position break or funding failure | Settlement fail | Reg SHO Rule 204 buy-in triggered |
FIX-to-ISO 20022 Interoperability
Front-office systems communicate execution data in FIX protocol, a message format optimized for order routing and execution confirmation. Post-trade infrastructure, central securities depositories, and settlement networks operate on ISO 20022 — a richer XML-based messaging standard used in the sese.023 settlement instruction and the camt.054 settlement notification. When a firm lacks a robust FIX-to-ISO 20022 translation layer, execution data arrives in back-office systems in formats that cannot be directly mapped to settlement messages. The result is manual re-keying or message reformatting, introducing latency and transcription errors at enrichment and instruction generation — the two stages where T+1 compressed timelines leave the least margin for intervention.
SSI Data Decay
Settlement standing instructions encode specific account identifiers, DTC participant numbers, BIC codes, and routing details that counterparties update when they change prime brokers, restructure custody arrangements, or migrate to new clearing accounts. Firms maintaining SSIs in static or infrequently refreshed reference databases will find a meaningful percentage of instructions on file are outdated at any given time. When an instruction generated from stale SSI data is submitted to DTCC or a CSD, it is typically rejected — requiring manual correction at precisely the most time-compressed stage of the T+1 workflow. SSI data decay is the single largest preventable cause of STP fall-out and settlement fails in institutional equity markets. An SSI golden source — a continuously validated, counterparty-confirmed SSI database refreshed against custodian and prime broker feeds — is the primary operational control.
Atomic STP and USDC Settlement
Traditional STP, even when fully automated, is technically pseudo-STP: the securities leg settles through DTC's DvP mechanism, but the cash leg is funded through a separate event — Fedwire transfer, CHIPS, or next-day bank funding. The two legs are linked by contractual convention rather than atomic execution, preserving a temporal gap during which principal risk exists. USDC-based settlement is full-stack STP: both the securities and cash legs settle in the same on-chain transaction, atomically, with no separate funding event. This eliminates principal risk at settlement and allows settlement to occur on a 24/7 basis independent of DTC and CLS operating windows — relevant for firms with cross-border and after-hours institutional flows.
Straight-through processing — end-to-end post-trade pipeline
Devancore Glossary · devancore.com
Straight-through processing — end-to-end post-trade pipeline
Devancore Glossary · devancore.com
How it works
1. Execution and Trade Capture
On trade date (T+0), the executing broker generates a FIX execution report confirming trade details — instrument, quantity, price, counterparty, and trade date. The investment manager's order management system (OMS) captures the execution report and submits the trade to the post-trade workflow. Accurate instrument identifiers (CUSIP, ISIN, SEDOL) and counterparty identifiers at this stage determine whether enrichment can proceed without intervention.
2. Enrichment Against Standing Data
The trade capture record is enriched with settlement-relevant data: counterparty standing settlement instructions (SSIs), DTC participant numbers, custodian account identifiers, and any special settlement conditions. Enrichment is the first major gate — if the required SSI is missing or outdated, the trade enters an exception queue and cannot advance. This stage is the primary leverage point for STP rate improvement; firms with a validated SSI golden source clear this gate at rates exceeding 99%.
3. Matching and Affirmation
Enriched trades are submitted to DTCC's Central Trade Manager (CTM), where broker-dealer and investment manager records are compared. Matched trades are eligible for affirmation. DTCC's T+1 affirmation service requires 90% of trades to be affirmed by 9:00 PM ET on trade date. Affirmed trades receive a DTC trade confirmation and proceed to instruction generation; unaffirmed trades remain at risk of settlement fail.
4. Allocation to Accounts
Block trades executed on behalf of multiple funds are allocated to individual account-level instructions. The investment manager submits allocation details — fund identifiers, share quantities, account numbers — to the custodian and, where applicable, to DTCC's Institutional Delivery (ID) system. Late or incorrect allocation files break the STP chain at this stage, causing each affected account-level trade to enter an exception queue independently.
5. Settlement Instruction Generation
Once allocation is complete and SSI data is validated, the system generates DTCC-format or ISO 20022 settlement instructions for each account-level trade. Instructions specify the securities to be delivered, the cash amount, the settlement date, and the relevant DTC accounts. Instructions failing SSI validation or format checks are rejected by DTCC and must be corrected manually — the most time-sensitive failure mode in the T+1 workflow.
6. Settlement
On settlement date (T+1), DTCC processes DvP settlement through the National Securities Clearing Corporation (NSCC) and the Depository Trust Company (DTC). Securities are transferred between accounts against simultaneous cash movement, achieving settlement finality. Failed trades — where a securities position or funding is unavailable — are reported by DTC and may trigger Reg SHO Rule 204 close-out obligations.
7. Exception Management and Repair
Trades that fall out at any stage enter an exception management workflow. Operations staff prioritize breaks by settlement risk — trades approaching the affirmation cutoff or settlement date are escalated first. The repair workflow includes SSI correction, resubmission to CTM, allocation amendment, and instruction regeneration. Documenting each exception, its cause, and resolution time is both an operational discipline and a supervisory record under Rule 17a-3 books-and-records obligations.
In Devancore™
Devancore STP pipeline — enrichment to instruction with exception fork
Devancore Glossary · devancore.com
Devancore STP pipeline — enrichment to instruction with exception fork
Devancore Glossary · devancore.com
Firms operating under T+1 face a narrow window between execution and the 9:00 PM ET affirmation cutoff. The operational risk concentrates at two points: enrichment, where SSI gaps prevent instruction generation, and matching, where unresolved trade details block affirmation. Both are addressable through automation before the cutoff — but only if exceptions are identified in real time rather than discovered during end-of-day reconciliation.
Automated Enrichment Pipeline
Devancore's post-trade engine ingests FIX execution reports from connected OMS and EMS systems and automatically enriches each trade against the firm's reference data — counterparty standing data, instrument master, and account master. The enrichment pipeline applies validation rules at each data field, flagging incomplete or conflicting data before the trade advances. Enrichment failures are surfaced as typed exceptions with resolution context, not generic error codes.
SSI Golden-Source Validation
Devancore maintains a continuously refreshed SSI golden source, reconciled against custodian and prime broker SSI feeds. Each SSI used in instruction generation is validated at the point of use — not at batch time — against the current golden-source record. Instructions built on unvalidated or stale SSI data are blocked from submission and surfaced as high-priority exceptions, preventing rejected instructions at DTCC or the CSD.
Hybrid Rail Routing
Devancore's settlement routing layer directs instructions to the appropriate settlement rail based on counterparty capability and instrument type. Standard institutional equity trades route through NSCC and DTC. Eligible digital asset and tokenized security trades route to on-chain atomic settlement, where the securities and USDC cash legs settle in a single transaction — eliminating the principal risk gap present in traditional two-leg DvP.
Real-Time Exception Management Before Cutoff
Exception queues in Devancore are live, not batch: as enrichment failures and matching breaks occur, they are surfaced immediately with countdown timers relative to the 9:00 PM ET affirmation window and the T+1 settlement date. Each exception includes the specific failure reason, the data field requiring correction, and the downstream stages blocked. Operations staff resolve exceptions in priority order — by time to cutoff and by settlement value — rather than working through a flat queue.