Straight-Through Processing Workflow

The workflow starts with capture. The system receives a source trade event from an execution system, OMS, EMS, FIX feed, API, upload, or other controlled source. The first question is not whether the trade can settle. The first question is whether the firm has a clean source record: order reference, fill ID, account, instrument, counterparty, side, price, quantity, trade date, settlement date, and event timestamp. A duplicate, late amend, missing fill ID, or ambiguous instrument should stop the path before the trade becomes trusted operating state.

Validation and enrichment make the trade operational. A captured trade needs standing settlement instructions, account master data, security master attributes, custodian, CSD or depository route, currency, calendar, LEI, MIC, CFI, ISIN, CUSIP, and market-specific settlement data. If those fields are missing, stale, or manually overridden, the workflow should create a cause-coded exception. A trade that requires a human to choose an SSI or edit a settlement field may still be repaired, but it should not be counted as pure no-touch STP for that stage.

Agreement creates the external obligation. Allocation, confirmation matching, and affirmation test whether the account-level economics are complete and whether the counterparties agree. Under U.S. T+1 rules, broker-dealers in scope need agreements or written policies and procedures reasonably designed to complete allocation, confirmation, and affirmation as soon as technologically practicable and no later than the end of trade date. That makes workflow timing visible. A late allocation, unmatched confirmation, or unaffirmed trade is not only a queue item. It is a time-sensitive settlement risk.

Instruction converts agreement into movement. The workflow should generate the correct settlement payload only after the required data and approvals exist. In securities settlement, this may involve SWIFT MT54x, ISO 20022 securities messages, a custodian instruction, a CSD instruction, a DTC-facing delivery flow, or a CCP-linked net settlement path. Message format, market route, legal finality model, and internal ledger state should remain separate fields. A valid message is not the same as settled cash and securities.

Closure requires external proof. A transaction may be internally clean but still pending externally because of inventory, cash, collateral, counterparty action, receiver authorization, custodian status, CSD status, or depository controls. The STP workflow should map those external states back to the trade. Final cash, position, accounting, and reporting updates should be tied to finality evidence, not only to the fact that an instruction was sent.

The first discipline is measurement. A useful STP rate should define the scope clearly: capture-to-instruct, capture-to-affirm, capture-to-settle, or capture-to-books. The numerator should include only transactions that passed the defined scope without manual repair or discretionary override. Repaired items, assisted items, manually approved items, pending items, failed items, and reopened items should be tracked separately. This discipline also aligns with the regulatory attention placed on central matching service providers. SEC Rule 17Ad-27 requires CMSPs to maintain policies and procedures reasonably designed to facilitate straight-through processing and to report progress using defined metrics. A firm-side workflow should therefore avoid inflated internal STP numbers that hide manual repair behind later automated transmission.

The second discipline is reference data. Many STP failures begin before settlement date: stale SSI, wrong custodian account, missing CSD route, invalid security identifier, outdated market calendar, bad account mapping, or incomplete counterparty data. A workflow that discovers those defects after instruction release is not running true STP. It is pushing the break downstream.

The third discipline is agreement timing. Same-day affirmation depends on clean capture, enrichment, allocation, confirmation, and matching. DTCC guidance for U.S. T+1 processing highlights the operational importance of completing allocations early enough to support confirmations and affirmations by the trade-date cutoff used for DTC processing. The workflow should therefore show late allocation and affirmation risk before the cutoff arrives.

The fourth discipline is exception quality. A fast repair is useful only if it is evidenced. If a user changes an SSI, corrects a price, edits an allocation, accepts a fuzzy match, or releases an item past a warning, the workflow should preserve the original value, new value, reason, maker, checker, source evidence, approval time, and downstream impact. Reclassifying a break should not reset its first detection timestamp.

Fuzzy matching needs hard tolerance floors. If a model or matching engine proposes a soft closure based on similar text, partial identifier overlap, or near-match economics, the workflow should still block mismatched quantities, cash amounts, settlement dates, or account fields outside approved tolerances. If the item later reopens because a custodian, CSD, DTC, NSCC, or counterparty rejects the prior closure, the system should preserve original age, reduce confidence in that match pattern, and flag the reopened item for supervisor review.

The fifth discipline is message and status mapping. ISO 20022 supports structured securities settlement messages, including settlement instruction, status advice, and confirmation flows. Richer structured data can reduce ambiguity, but it does not remove the need for workflow controls. The system still needs to prove which instruction was sent, what status came back, what changed internally, and whether the item is settled, failed, pending, repaired, or held.

The final discipline is reporting. STP dashboards should not only show a percentage. They should show why trades fell out, which gate failed, how long the item aged, who repaired it, whether it re-entered the workflow, whether it reopened, and what final evidence closed the record. A high STP number with weak exception evidence is not a strong operating model.