What Settlement Risk Really Is

Settlement risk is the risk that a payment will not settle as expected, either because the sending party fails to deliver the funds or the asset, or because settlement happens at a different time or in a different amount than agreed. It is distinct from credit risk in the general sense, because it is specifically about the settlement leg of a transaction. A counterparty can be perfectly sound when a trade is agreed and still fail to settle, because of an operational error, a liquidity shortage or a sudden insolvency. Settlement risk is therefore present in every payment and every trade, even between the strongest institutions. The risk has two dimensions that analysts must separate. The first is the risk that settlement does not happen at all, which means the receiving party has delivered its side of the bargain but has not received what it was promised. The second is the risk that settlement is delayed, which may not cause a permanent loss but can create a liquidity problem for the receiving party, forcing it to borrow or to delay its own payments. Both dimensions matter, and systems are designed to manage both, through real time settlement, prefunding, collateral and guarantees. Settlement risk is also a system level concern, not just a bilateral one. If one large participant fails to settle, the banks that were expecting to receive its funds may themselves be unable to settle their own payments, and the problem can spread. This contagion effect is why central banks and regulators take settlement risk so seriously, and why they have pushed the industry towards RTGS, payment versus payment and other mechanisms that reduce or eliminate it. A business analyst who understands settlement risk can explain why a particular control exists, rather than simply documenting that it does. Put a number on the risk. A bank agrees a foreign exchange trade. It will pay EUR 10 million and receive USD 10.8 million, at a rate of 1.08. The euro leg settles at 9 in the morning in Frankfurt, and the dollar leg settles at 3 in the afternoon in New York. At 12 noon, between the two settlements, the counterparty fails. The bank has already paid EUR 10 million and will receive nothing, so its principal loss is the full EUR 10 million, not a fee or a delay but the entire amount. The second dimension of the risk is delay rather than loss. Suppose the counterparty does not fail but its dollar payment arrives two days late. The bank expected USD 10.8 million on Monday and must now borrow it for two days to meet its own obligations, paying interest and using up a credit line it had planned for something else. Both dimensions are settlement risk, and a system that only guards against one of them is half built. An analyst records settlement risk per channel, not in general. The risk register should have one entry per settlement channel and currency pair, stating whether the two legs settle together or apart, how long the gap is, and what the maximum exposure is on a normal day. For each pair the analyst should also record whether payment versus payment applies, because that single fact changes the risk from principal loss to replacement cost. The limit monitoring should be live, not end of day. A counterparty limit that is checked after settlement has already happened is a report, not a control. And every new product proposal should answer one question before it is approved. Which settlement channel will it use, and what happens if the other side does not settle.