Settlement Instruction Automation
Automatically generating and transmitting settlement instructions to custodians and CSDs using pre-loaded SSI data — replacing manual entry, enabling STP, and making T+1 compliance operationally viable.
Definition
A settlement instruction is the formal delivery order that tells a central securities depository (CSD) or custodian to move assets — transferring securities against cash at the agreed settlement date and price. It contains the counterparty's custodian BIC, account number, place of settlement, instrument identifier (ISIN or CUSIP), quantity, settlement amount, and value date. The instruction is distinct from the standing settlement instruction that feeds it: the SSI is the reusable template pre-agreed between counterparties; the settlement instruction is the trade-specific message generated from that template when a trade is ready to settle. A further distinction applies at the other end: a settlement instruction is the order to settle; a settlement confirmation is the CSD's acknowledgement that settlement occurred. In ISO 20022 messaging, these are separate documents — sese.023 (instruction) and sese.025 (confirmation) — and should not be conflated. Settlement instruction automation is the pipeline that connects SSI reference data to confirmed trade data, produces the correctly formatted instruction, and delivers it to the CSD without manual entry.
The Automation Pipeline
Automation begins at trade enrichment, the step immediately following trade confirmation and matching. The post-trade settlement engine queries the SSI database — primarily DTCC ALERT for institutional trades — for the record matching the counterparty, asset class, and market. If a valid SSI exists, the system populates all instruction fields: custodian BIC, account identifiers, ISIN, face value, settlement date, and currency. Once populated, the instruction passes through a validation layer — BIC format, account structure, instrument eligibility — before being released for transmission. SWIFT MT54x message types carry the instruction to the custodian or CSD: MT540 (Receive Against Payment), MT541 (Deliver Against Payment), MT542 (Receive Free), and MT543 (Deliver Free). These are being migrated to ISO 20022 sese.023 (settlement instruction) and sese.024 (instruction status) messages as part of the SWIFT ISO 20022 transition, which requires more complete reference data fields than the MT format. After transmission, the CSD returns status messages confirming receipt, matching, and settlement. A concrete example: a broker sells 100,000 shares, CTM confirms the match, ALERT returns the counterparty's DTC participant account, the system generates an MT541 Deliver Against Payment instruction, DTC receives it, and the position settles with DvP finality on T+1.
T+1 and the Operational Necessity of Automation
Under SEC Rule 15c6-1 (effective May 28, 2024), US equity trades must settle on T+1. Rule 15c6-2 requires broker-dealers and investment advisers to have written policies and procedures reasonably designed to achieve same-day affirmation as soon as technologically practicable. Affirmation requires settlement details — counterparty, settlement location, and amount — to be agreed between counterparties, and those details are sourced from the same SSI data used in instruction generation. In practice, institutional affirmation and instruction submission cutoffs cluster around 7:00–9:00 PM ET on trade date. A firm processing 500 trades per day has a window of approximately eight to ten hours after market close to complete enrichment, generate instructions, validate them, and submit them. Manual processing cannot sustain this volume within the T+0 window. DTCC's Match to Instruct (M2i) workflow captures the automation requirement mechanically: when a trade reaches matched status in CTM, M2i automatically converts it to a settlement instruction using ALERT SSI data — eliminating the step where operations staff previously initiated instruction creation manually. M2i works only when SSI data is clean and synchronized; this is the operational constraint that makes reference data quality the T+1 bottleneck, not technology.
Settlement instruction automation pipeline — stage, system, output, and T+1 constraint
| Stage | System | Output | T+1 Constraint |
|---|---|---|---|
| SSI Lookup | DTCC ALERT / reference DB | Matched SSI record | Required before enrichment |
| Trade Enrichment | Post-trade settlement engine | Populated instruction fields | T+0, before affirmation |
| Instruction Generation | Post-trade settlement engine | MT54x or sese.023 message | T+0 submission required |
| Validation | Maker-checker workflow | Approved instruction | Pre-SWIFT release |
| SWIFT / CSD Transmission | SWIFT gateway / CSD portal | Delivery order to CSD | Before CSD same-day cutoff |
| Status Monitoring | CSD feedback / SWIFT ACK | Settlement confirmation | T+1 DvP finality |
Industry Infrastructure: DTCC ALERT and SWIFT
DTCC ALERT is the industry-standard SSI database for institutional post-trade processing, maintaining SSI records for tens of thousands of financial institutions globally across equities, fixed income, and FX. ALERT distributes real-time SSI updates to subscribing firms, so when a counterparty changes custodians the change propagates to all subscribers without bilateral notification. The Broadridge DTCC ALERT SSI Automation interface and OSTTRA's settlement automation service both use ALERT as the SSI source — the model of maintaining a local SSI database updated manually from bilateral confirmations has become operationally untenable under T+1. For fixed income and FX, the SWIFT SWIFTRef SSI directory provides a complementary registry alongside ALERT.
Deterministic Enrichment: Real-Time SSI Synchronization
Legacy post-trade systems typically maintain static SSI tables updated periodically from bilateral counterparty notifications — often weekly or monthly. Under T+1, a static table is a liability: a counterparty custodian change that occurred after the last update produces an incorrect instruction that fails at the CSD, with no buffer day to recover. Modern settlement instruction automation requires deterministic enrichment — the post-trade settlement engine queries DTCC ALERT in real time at the moment the trade is enriched, not from a cached copy. The instruction is built from the SSI that exists at enrichment time, not the SSI that existed at last update. This distinction eliminates the most common SSI error class: stale routing data. The S&P Global January 2026 research on SSI automation in a T+1 environment identifies real-time ALERT synchronization as the primary differentiator between firms that achieved same-day affirmation rates above 90% and those that remained below 75% after the US T+1 transition.
Regulatory and Industry Standards
The December 2024 FMSB Standard for the Sharing of Standard Settlement Instructions establishes industry-wide expected practices for SSI distribution between counterparties: electronic transmission, standardized formats, out-of-band verification of changes, maker-checker authorization, and a complete audit trail of every modification. The September 2024 ISDA SSI Standard Operating Procedure sets equivalent governance for ISDA member firms. Both standards exist in response to SSI fraud — an attacker impersonating a counterparty representative to redirect settlement proceeds — which is one of the highest-impact attack vectors in post-trade operations and produces losses that look like normal settled transactions until the fraud is discovered.
The EU T+1 Industry Committee and UK Accelerated Settlement Taskforce have both named SSI automation as a baseline readiness requirement for the European T+1 transition (October 11, 2027). The UK AST requires all market participants to implement SSIs through a market-standard automated solution, with changes communicated in advance and where possible prior to trade execution. The EU Committee has recommended a centralized SSI database and automated messaging protocols — an ALERT-equivalent infrastructure for European markets. For cross-border firms, post-T+1 SSI automation must span DTCC ALERT (US equities), SWIFT SWIFTRef (FX and fixed income), and Euroclear/Clearstream-specific SSI formats.
EU Pre-Matching and Instruction Status Monitoring
Under CSDR Article 6, European CSDs are required to implement matching systems that check settlement instruction pairs against each other before the intended settlement date. If an instruction is sent but not matched by the Intended Settlement Date (ISD), the CSDR Article 7 cash penalty clock starts immediately. This creates an important operational obligation that extends beyond instruction generation: firms must monitor the match status of every outbound instruction in real time and take corrective action on unmatched pairs before the ISD. A settlement automation system that generates and submits instructions but does not track match status is incomplete under CSDR. Post-instruction monitoring — consuming sese.024 status messages and flagging unmatched pairs before penalty accrual begins — is a required component of the automation pipeline in European markets, not an optional enhancement.
Failure Modes and Fail Cost
When an SSI is absent, stale, or incorrectly mapped, enrichment fails and the trade enters an exception queue. Operations staff must locate the correct SSI, confirm it out-of-band with the counterparty, update the reference data, and resubmit the instruction — all before the CSD same-day submission cutoff. Under T+1, there is no recovery window equivalent to the T+2 framework's buffer day. A failed instruction that misses the T+0 cutoff produces a settlement fail. Under US T+1 rules, a short-sale fail-to-deliver position triggers a Reg SHO Rule 204 close-out by T+2; for long-sale fails, by T+4. Under CSDR Article 7, European settlement fails incur cash penalties accruing daily and, for persistent fails, mandatory buy-in procedures. The cost asymmetry is significant: SSI data quality investment is a predictable, fixed operational cost; fail penalties and operational impacts scale with trade volume and duration of the failure.
Settlement instruction automation — SSI to DvP finality
Devancore Glossary · devancore.com
Settlement instruction automation — SSI to DvP finality
Devancore Glossary · devancore.com
How it works
1. SSI lookup against DTCC ALERT
When a trade reaches the enrichment stage, the post-trade settlement engine queries DTCC ALERT in real time using the counterparty identifier (BIC or LEI), instrument type, and market. ALERT returns the matching SSI record: the counterparty's custodian BIC, account numbers, place of settlement (PSET), and any instrument-specific routing overrides. Deterministic enrichment queries ALERT at the moment of enrichment rather than from a cached static table — ensuring stale routing data cannot produce an incorrect instruction. If no ALERT record exists, the system falls back to the local SSI database; if neither source has a valid record, an enrichment exception is raised before any instruction is generated.
2. Trade enrichment
The confirmed and matched trade record is populated with the SSI data retrieved in step 1. The settlement engine combines the SSI fields (custodian BIC, account, PSET) with the trade fields (ISIN/CUSIP, quantity, settlement amount, value date, counterparty) to produce a fully populated settlement instruction record. Enrichment typically must complete on trade date (T+0) under T+1 — this is the step where standing settlement instruction coverage gaps and stale SSI data materialize as settlement fails.
3. Instruction generation and format selection
The settlement engine generates the instruction in the correct message format for the target CSD or custodian. For DTCC-eligible US equities, the instruction flows through DTC's settlement system via DTCC connectivity. For international trades, the system generates a SWIFT MT54x message — MT540 (Receive Against Payment), MT541 (Deliver Against Payment), MT542 (Receive Free), or MT543 (Deliver Free) — or an ISO 20022 sese.023 settlement instruction for counterparties on the migrated format. Where DTCC Match to Instruct (M2i) is active, the matched CTM record is automatically converted to a DTC settlement instruction without a separate instruction generation step — the fastest path from match to instruction.
4. Validation and maker-checker release
Before transmission, the instruction passes through a validation layer: BIC format, account structure, instrument eligibility at the target CSD, settlement amount range, and currency consistency. Instructions exceeding configurable value thresholds, or generated outside normal hours, route to a maker-checker review queue where a second authorized operator approves before release. Dual-control on instruction release is an expected control practice under the FMSB Standard and ISDA SSI governance standards for high-value or SSI-modified instructions.
5. SWIFT transmission and CSD submission
Validated instructions are released to the SWIFT gateway or CSD connectivity layer. SWIFT FIN messages are queued and transmitted to the counterparty's custodian within minutes; CSD-proprietary connectivity (DTCC, Euroclear, Clearstream) uses direct API or SWIFT MT channels depending on the market. CSD same-day submission cutoffs vary by market: DTC equity instructions must be submitted by 15:30 ET on settlement date; European CSDs have varying same-day cutoffs. Missing the CSD cutoff results in a settlement fail for that date, with no intraday recovery path.
6. Settlement status monitoring
After submission, the CSD or custodian returns status messages at each lifecycle stage: instruction received, instruction matched, securities ear-marked, and settlement confirmed. SWIFT sese.024 messages (or MT548 status messages in the legacy format) carry these updates back to the settlement engine, which updates the trade lifecycle record. In European markets, unmatched instructions must be flagged before the Intended Settlement Date to avoid CSDR Article 7 penalty accrual. Confirmed settlement updates the investment book of record position with finality and triggers the accounting book of record settlement-date booking.
In Devancore™
Devancore integrates with DTCC ALERT as the primary SSI source, querying the ALERT API in real time at the point of trade enrichment rather than from a periodic static cache. This deterministic enrichment model ensures that every settlement instruction is built from the SSI that exists at the moment of generation — stale routing data cannot enter the pipeline. SSI coverage gaps are surfaced in the operations dashboard immediately after trade matching, before the instruction generation step, giving operations teams time to resolve missing SSI coverage on trade date rather than discovering it as a settlement fail at the CSD.
M2i-Ready Instruction Generation
Devancore's settlement engine is built around the M2i model: when a trade reaches matched status in DTCC CTM, the system can automatically generate and submit the DTC settlement instruction using the ALERT SSI record without a manual initiation step. For international trades, the engine generates SWIFT MT54x messages and ISO 20022 sese.023 instructions, acting as the translation layer between FIX execution data from the OMS and the sese.023 format required at the CSD — eliminating the translation gap where data corruption historically occurred between middle and back office. The correct message type, CSD routing, and instruction format are determined by the trade and SSI data, not by per-trade configuration.
Maker-Checker and the Audit Thread
Settlement instruction release follows Devancore's maker-checker workflow — a proposer generates the instruction, a second authorized operator approves release, and every action is logged with actor, timestamp, and instruction state. Value-based thresholds and out-of-hours flags route instructions to review queues automatically. The complete instruction history — SSI source queried, ALERT record version, enrichment result, validation outcome, transmission timestamp, and CSD acknowledgement — is retained in the audit log as an immutable record. This lineage satisfies SEC Rule 17a-3 (records creation) and Rule 17a-4 (records retention) by providing the full provenance of every settlement decision: which SSI authorized it, who approved it, when it was sent, and what the CSD returned.
Status Tracking Through DvP Finality
Devancore consumes SWIFT sese.024 and custodian status messages and maps each instruction to its current settlement state: pending, matched, ear-marked, settled, or failed. In European markets, the instruction status dashboard surfaces unmatched pairs before the Intended Settlement Date to prevent CSDR Article 7 penalty accrual. The failed trade queue displays unresolved exceptions with Reg SHO close-out deadlines where applicable. Confirmed DvP settlement feeds the IBOR position update and transitions the position to ABOR-confirmed state, with the settlement date and instruction reference recorded in the audit log as the authoritative evidence of legal transfer — completing the settlement instruction lifecycle from ALERT query to finality.