Standing settlement instructions (SSIs) are pre-agreed, reusable instructions that specify the custodian, account number, and settlement location for each counterparty and asset class. Once established, SSIs apply automatically to every qualifying trade, removing manual instruction entry from the settlement workflow and reducing the risk of settlement failure caused by incorrect or missing instructions.

SSIs are the foundational reference data layer for settlement operations. Every settlement instruction generated by a post-trade system depends on SSI data being accurate, current, and retrievable at the moment the instruction is built. In that sense, SSIs are not a convenience feature — they are the mechanism that makes automated straight through processing of settlement instructions possible at scale. Without complete SSI coverage, trade enrichment automation cannot complete, and settlement instructions must be entered or corrected manually, introducing latency and error into a workflow where both are expensive.

The operational risk profile of SSI management is distinct from other reference data because SSI fraud — the unauthorized modification of settlement instructions to redirect securities or cash to a fraudulent account — is one of the highest-impact operational risks in post-trade operations. A successful SSI compromise does not look like a system failure; it looks like a normal settlement that completes correctly, delivering assets to the wrong destination. Detection depends entirely on out-of-band verification and maker-checker controls on SSI changes.

When a trade is confirmed between two counterparties, both sides must communicate where securities should be delivered and where cash should be received. For each counterparty and instrument type, the operations team registers the relevant custodian BIC (Bank Identifier Code), account identifiers, and place of settlement. These instructions are stored in the firm's reference data layer and retrieved automatically at the point of settlement instruction generation.

SSIs are transmitted via SWIFT or direct custodian connectivity. The SWIFT BIC uniquely identifies the receiving custodian and is the primary routing identifier in SWIFT MT 54x settlement instruction messages (MT540, MT541, MT542, MT543). These message types are being replaced by ISO 20022 sese.023 and sese.024 messages as part of the SWIFT ISO 20022 migration — the sese.023 format carries expanded SSI data fields that require reference data to be more complete than the MT format required. The SWIFT SWIFTRef SSI directory is the industry-wide utility for SSI distribution and standardization across financial institutions, providing a central registry that complements bilateral SSI exchange between counterparties.

SSI structure differs for FX settlement, where instructions involve correspondent banking chains, nostro accounts, and where applicable CLS membership rather than CSD routing and BIC/account pairs. An FX SSI specifies where the sold currency should be paid and where the purchased currency should be received through correspondent bank routing — a structurally different instruction type from a securities delivery SSI, requiring separate maintenance in the SSI database.

For digital asset settlement, the equivalent of an SSI is the wallet address and network identifier for the receiving account — carrying the same operational risk profile as a traditional SSI, with the additional characteristic that an incorrect on-chain address produces an irreversible loss rather than a failed settlement that can be recalled. The absence of a recall mechanism means the verification standard for digital asset SSIs should be treated as higher than for traditional rails, not equivalent — a cooling-off period and out-of-band confirmation that might catch a fraudulent change before it affects live settlement on a traditional rail will not recover funds that have already settled on-chain.

In a T+1 settlement environment, the window between trade execution and settlement instruction cutoff is narrow enough that SSI gaps cannot be resolved manually at scale. The T+1 affirmation deadline requires that settlement instructions be complete and matched before the 9:00 PM ET cutoff on trade date. An SSI that is missing, outdated, or mapped to the wrong instrument type will cause the enrichment step to fail, the instruction to be ungenerated or incorrectly generated, and the trade to miss affirmation — producing a preventable settlement fail. Industry data and DTCC post-trade analysis consistently identify missing or incorrect SSIs as a leading cause of settlement fails, alongside trade matching failures and position shortfalls.

SSI change management is where operational risk concentrates. The September 2024 ISDA SSI Standard Operating Procedure establishes the industry standard for SSI change management across ISDA member firms — and the December 2024 FMSB Standard for the Sharing of Standard Settlement Instructions addresses SSI distribution and sharing workflow between counterparties, specifically in the context of the fraud and operational risk the sharing process introduces. The workflow for establishing or modifying an SSI must satisfy two requirements that are in tension: it must be fast enough to onboard new counterparties and respond to custodian changes without delaying settlement, and it must be controlled enough to prevent fraudulent instruction modification. Both the ISDA SOP and FMSB Standard converge on the same core controls:

• Out-of-band verification of any new or changed SSI with the counterparty before activation — confirmation via a separate channel (phone, authenticated portal) rather than accepting changes through the same channel the request arrived on
• Maker-checker dual authorization on every SSI change, preventing single-operator modification of settlement routing
• Time-delayed activation for new SSIs — a cooling-off period between approval and activation that allows detection of fraudulent changes before they affect live settlement
• Complete audit trail of every SSI change with actor, timestamp, and verification record

SSI fraud typically follows a social engineering pattern: an attacker contacts the target firm's operations team posing as a counterparty representative, requests an SSI update citing a custodian change, and if the change is processed without out-of-band verification, the next settlement to that counterparty delivers to the attacker's account. The controls above exist to interrupt this pattern at each stage.