Standing Settlement Instructions

Table of Contents

SSIStanding Settlement Instructions — are the pre-agreed settlement details counterparties use for all future trades of a specific type until explicitly changed. The "Standing" half of the acronym carries the weight: instructions are "on file", verified once during onboarding, and reused thereafter. Return to External knowledge / Knowledge.

Why "Standing"?

In high-volume trading, it would be risky and inefficient to negotiate bank account details for every single trade. Counterparties agree on SSIs once during onboarding instead.

  • Efficiency: when a trader executes, the back-office system automatically looks up the standing instruction for that currency and asset class.
  • Risk Mitigation: using standing instructions prevents man-in-the-middle attacks. A rogue trader can't tell you to "send the money to this new account just for this one trade." The money only goes to the pre-verified, standing account.
  • Automation: it enables Straight-Through Processing (STP). The system picks the SSI, generates the pacs.009, and sends it without human intervention.

The Anatomy of an SSI

An SSI is not just a bank account number; it's a specific "route." A single counterparty (e.g. JP Morgan) will have hundreds of different SSIs. To pick the right one, the system filters by:

  1. Currency — USD to one account, EUR to another.
  2. Asset Class — FX settlement goes to one bank, bond settlement to a custodian.
  3. Settlement Method — CLS, Gross, or Net.

SSI Selection as a Lookup

The system models SSI selection as a unique-key lookup:

// Pseudocode for SSI selection
SSI get_active_ssi(EntityID counterparty, Currency ccy, AssetClass asset) {
    // The 'Standing' instruction matching the criteria
    return db.query("SELECT * FROM ssi_table
                     WHERE entity_id = ?
                     AND currency = ?
                     AND asset_class = ?
                     AND is_active = true",
                     counterparty, ccy, asset);
}

The Four-Eyes Requirement

Because the standing nature of these instructions makes them so powerful, the Security surface in any UI that mutates them must be hard. If an attacker changes a standing instruction, they can divert every single future payment for that client to a fraudulent account.

  • Verification: SSI records carry a "Verified By" field; mutation requires a separate approver.
  • Effective Dates: SSIs carry an effective date so a new bank route can be staged weeks before a bank migration.

Emacs 29.1 (Org mode 9.6.6)