SSI Fraud: The Silent Operational Risk in Financial Markets

Standard Settlement Instructions — universally abbreviated to SSIs — are one of the most unglamorous pieces of financial market infrastructure. They are the static reference data that tells a bank where to send a payment when settling a trade with a specific counterparty: which bank, which account, which BIC (Bank Identifier Code), which account number. Every time a securities trade settles or a derivatives coupon is paid, the bank's settlement system looks up the counterparty's SSIs and sends the payment accordingly.

Because SSIs are largely static and automated, they receive relatively little attention from front-office staff. That invisibility makes them a prime target for fraud. If a fraudster can alter an SSI in the database — changing the destination account for a counterparty's payments — the bank's automated settlement system will send real money to a criminal account with no human review in the loop.

An SSI is a set of payment routing details for a specific counterparty in a specific currency and instrument type. A complete SSI record for a USD cash payment might include:

• The counterparty's name and LEI (Legal Entity Identifier)
• The receiving bank's BIC (e.g., CITIUS33 for Citibank New York)
• The account number at the receiving bank
• Any intermediary bank details required for the routing
• The account name to verify the beneficiary

SSIs are maintained in the bank's static data system — a database that feeds into the settlement system. When a settlement instruction is generated for a trade, the system automatically populates it with the relevant SSI for that counterparty and currency. This automation is what creates the vulnerability: once an SSI is in the database, every subsequent payment to that counterparty in that currency uses those same routing details without further manual verification.

SSIs are shared between counterparties through several channels. Many banks use the SWIFT SSI database (known as the SWIFT BIC directory and SSI utility), where they publish their own SSIs and look up counterparties' SSIs. Third-party services such as Omgeo ALERT (now DTCC ALERT) also maintain SSI databases used by custody and settlement teams.

Social engineering attacks. The most straightforward SSI fraud involves convincing a bank's operations team to update an SSI record. Fraudsters pose as representatives of a legitimate counterparty — using spoofed email addresses, professional-sounding language, and knowledge of the counterparty's real name and account details — and request that the bank update the counterparty's SSIs to new account details. If the operations team processes the update without verifying the request through a separate, trusted channel (a phone call to a known contact number), the fraudulent SSIs enter the database and future payments route to the criminal account.

Man-in-the-middle attacks. More sophisticated attacks intercept legitimate communication channels. In an email man-in-the-middle attack, a fraudster compromises the email account of a counterparty and monitors correspondence. When an SSI update or payment instruction is legitimately communicated by email, the fraudster intercepts and modifies it — changing the account details to their own — before it reaches the recipient. The recipient sees what appears to be a legitimate email from a known sender, processes the instruction, and sends the payment to the fraudulent account.

SSI database manipulation. In rare but high-impact cases, attackers have gained access to internal systems and directly modified SSI records in the static data database. This requires a higher level of access but allows the fraudster to manipulate multiple counterparty records simultaneously, potentially redirecting a large volume of settlement flows.

While not strictly an SSI fraud, the 2016 Bangladesh Bank cyber heist illustrates the catastrophic consequences of manipulating payment routing instructions. Hackers gained access to Bangladesh Bank's SWIFT terminal and sent 35 fraudulent SWIFT messages to the Federal Reserve Bank of New York, instructing transfers from Bangladesh Bank's USD account to accounts in the Philippines and Sri Lanka. The attack exploited weaknesses in Bangladesh Bank's internal controls — a cheap, second-hand network switch and no firewall — to gain access to the SWIFT messaging system.

$81 million was successfully transferred before the fraud was detected. The case led to significant strengthening of SWIFT's customer security programme and a global reassessment of how banks protect access to payment systems.

The SSI fraud vector is analogous: instead of attacking the SWIFT messaging system, attackers manipulate the database that feeds into it — ensuring that legitimate, properly authenticated SWIFT messages route to criminal accounts.

Callback verification. The primary control against social engineering SSI fraud is mandatory callback verification. Any request to change an SSI record — regardless of how it is received (email, letter, fax) — must be verified by a telephone call to a known, pre-existing contact number for that counterparty. The call must not use a phone number provided in the change request itself (which may be fraudulent), but a number from the bank's existing records or from an independent directory.

Dual approval. SSI updates should require approval by two independent individuals — the four-eyes principle applied to static data. The person who receives and processes the change request should not be the same person who approves it. Dual approval limits the impact of both external fraud (requiring two people to be deceived) and internal fraud (requiring collusion).

SWIFT gpi (Global Payments Innovation). SWIFT gpi is a suite of enhancements to the SWIFT payment network that provides end-to-end payment tracking, confirmation of credit, and stop payment capabilities. The gpi Unique End-to-End Transaction Reference (UETR) allows a bank to track exactly where a payment is at any point in its journey. In the event of a suspected fraudulent payment, gpi's stop payment capability allows the sending bank to issue a payment recall request that is relayed instantly to all banks in the payment chain — dramatically improving the chances of recovery if a fraudulent payment is identified quickly.

SSI publication via authenticated channels. Using authenticated SSI publication services — such as DTCC ALERT or the SWIFT SSI utility — rather than bilateral email communications reduces the attack surface. These services require authenticated access and audit all changes, making it much harder to introduce fraudulent SSI records undetected.

Transaction monitoring. Banks monitor payment flows for anomalies — unusually large payments to new accounts, payments to accounts in unusual jurisdictions, or changes in the pattern of payments to a specific counterparty shortly after an SSI update. Automated transaction monitoring can flag potential SSI fraud before a large payment is made.

The fundamental challenge with payment fraud is speed. Once a payment has been sent and credited to the fraudulent account, the recipients typically move the funds immediately — transferring to multiple accounts in different jurisdictions, converting to cryptocurrency, or withdrawing as cash. Recovery through legal channels — freezing accounts, asset recovery proceedings — is slow and uncertain. Most SSI fraud victims recover little or none of the lost funds.

This asymmetry — fast attack, slow recovery — means that prevention is the only effective strategy. The controls described above (callbacks, dual approval, SWIFT gpi, authenticated SSI publication) must all be in place and actively enforced. A single gap in the control framework is all a sophisticated attacker needs.