Payments Academy
No system eliminates settlement risk entirely PAYMENT OPERATIONS STARTED LIVE 01 No system eliminates settlement risk entirely - banks and payment system ACTIVE 02 Collateral - Collateral is another key tool. QUEUED 03 Tested default procedure - Finally, every system needs a clear default QUEUED 04 Payment system - holds a guarantee fund of EUR 200 million QUEUED 05 Additional loss sharing - surviving participants QUEUED 06 Procedure - least twice a year QUEUED No system eliminates settlement risk entirely, so banks and payment system operators manage the residual risk with a combination of limits, collateral, monitoring and contingency plans. Step 1 of 6 No system eliminates settlement risk entirely STARTED No system eliminates settlement risk entirely banks and payment system operators ACTIVE Collateral Collateral is another key tool. QUEUED Tested default procedure Finally, every system needs a clear default QUEUED Payment system holds a guarantee fund of EUR 200 million QUEUED Additional loss sharing surviving participants QUEUED Procedure least twice a year QUEUED No system eliminates settlement risk entirely, so banks and payment system operators manage the residual risk with a combination of limits, collateral, monitoring and contingency plans.
Collateral is another key tool PAYMENT OPERATIONS IN PROGRESS LIVE 01 No system eliminates settlement risk entirely - banks and payment system DONE 02 Collateral - Collateral is another key tool. ACTIVE 03 Tested default procedure - Finally, every system needs a clear default QUEUED 04 Payment system - holds a guarantee fund of EUR 200 million QUEUED 05 Additional loss sharing - surviving participants QUEUED 06 Procedure - least twice a year QUEUED Collateral is another key tool. Step 2 of 6 Collateral is another key tool IN PROGRESS No system eliminates settlement risk entirely banks and payment system operators DONE Collateral Collateral is another key tool. ACTIVE Tested default procedure Finally, every system needs a clear default QUEUED Payment system holds a guarantee fund of EUR 200 million QUEUED Additional loss sharing surviving participants QUEUED Procedure least twice a year QUEUED Collateral is another key tool.
Tested default procedure PAYMENT OPERATIONS IN PROGRESS LIVE 01 No system eliminates settlement risk entirely - banks and payment system DONE 02 Collateral - Collateral is another key tool. DONE 03 Tested default procedure - Finally, every system needs a clear default ACTIVE 04 Payment system - holds a guarantee fund of EUR 200 million QUEUED 05 Additional loss sharing - surviving participants QUEUED 06 Procedure - least twice a year QUEUED Finally, every system needs a clear default procedure that is tested regularly. Step 3 of 6 Tested default procedure IN PROGRESS No system eliminates settlement risk entirely banks and payment system operators DONE Collateral Collateral is another key tool. DONE Tested default procedure Finally, every system needs a clear default ACTIVE Payment system holds a guarantee fund of EUR 200 million QUEUED Additional loss sharing surviving participants QUEUED Procedure least twice a year QUEUED Finally, every system needs a clear default procedure that is tested regularly.
Payment system PAYMENT OPERATIONS IN PROGRESS LIVE 01 No system eliminates settlement risk entirely - banks and payment system DONE 02 Collateral - Collateral is another key tool. DONE 03 Tested default procedure - Finally, every system needs a clear default DONE 04 Payment system - holds a guarantee fund of EUR 200 million ACTIVE 05 Additional loss sharing - surviving participants QUEUED 06 Procedure - least twice a year QUEUED A payment system holds a guarantee fund of EUR 200 million, contributed by all participants in proportion to their volumes. Step 4 of 6 Payment system IN PROGRESS No system eliminates settlement risk entirely banks and payment system operators DONE Collateral Collateral is another key tool. DONE Tested default procedure Finally, every system needs a clear default DONE Payment system holds a guarantee fund of EUR 200 million ACTIVE Additional loss sharing surviving participants QUEUED Procedure least twice a year QUEUED A payment system holds a guarantee fund of EUR 200 million, contributed by all participants in proportion to their volumes.
Additional loss sharing calls PAYMENT OPERATIONS IN PROGRESS LIVE 01 No system eliminates settlement risk entirely - banks and payment system DONE 02 Collateral - Collateral is another key tool. DONE 03 Tested default procedure - Finally, every system needs a clear default DONE 04 Payment system - holds a guarantee fund of EUR 200 million DONE 05 Additional loss sharing - surviving participants ACTIVE 06 Procedure - least twice a year QUEUED Additional loss sharing calls on the surviving participants, in proportion to their volumes, collected within an agreed time. Step 5 of 6 Additional loss sharing calls IN PROGRESS No system eliminates settlement risk entirely banks and payment system operators DONE Collateral Collateral is another key tool. DONE Tested default procedure Finally, every system needs a clear default DONE Payment system holds a guarantee fund of EUR 200 million DONE Additional loss sharing surviving participants ACTIVE Procedure least twice a year QUEUED Additional loss sharing calls on the surviving participants, in proportion to their volumes, collected within an agreed time.
Procedure must be rehearsed PAYMENT OPERATIONS COMPLETE LIVE 01 No system eliminates settlement risk entirely - banks and payment system DONE 02 Collateral - Collateral is another key tool. DONE 03 Tested default procedure - Finally, every system needs a clear default DONE 04 Payment system - holds a guarantee fund of EUR 200 million DONE 05 Additional loss sharing - surviving participants DONE 06 Procedure - least twice a year ACTIVE The procedure must be rehearsed, at least twice a year, with a timed simulation. Step 6 of 6 Procedure must be rehearsed COMPLETE No system eliminates settlement risk entirely banks and payment system operators DONE Collateral Collateral is another key tool. DONE Tested default procedure Finally, every system needs a clear default DONE Payment system holds a guarantee fund of EUR 200 million DONE Additional loss sharing surviving participants DONE Procedure least twice a year ACTIVE The procedure must be rehearsed, at least twice a year, with a timed simulation.

Key points of this lesson, in order.

0:00 / 3:28 Step 1 of 6

Managing Residual Risk in Practice

Settlement Risk, Lesson 7 of 7, Narration 3:28, D07 Clearing, settlement and liquidity

Settlement

What you will learn

Your objective. By the end of this lesson, you will be able to explain managing residual risk in practice. No system eliminates settlement risk entirely, so banks and payment system operators manage the residual risk with a combination of limits, collateral, monitoring and contingency plans.

Why it matters. An analyst writes the default procedure as a runbook, not as a paragraph in a policy document.

Chapter objective: Learner identifies settlement risk, including Herstatt risk, principal risk, and replacement cost risk, and explains mitigations such as payment versus payment, netting, and limits. Learner demonstrates this skill using realistic banking examples, explaining each step clearly and using correct terminology throughout.

Key learning points

  • No system eliminates settlement risk entirely
  • Collateral is another key tool
  • Tested default procedure
  • Payment system
  • Additional loss sharing calls
  • Procedure must be rehearsed

Key terms

Settlement: The final movement of funds between banks to discharge obligations created by cleared payments. Settlement is usually made in central bank money or through correspondent accounts.

Payment flow diagram showing Managing Residual Risk in Practice.

Practise this lesson

Exercise

Decide which settlement model fits the scenario in this lesson and explain why.

Use the settlement models, the liquidity trade-off and the finality rules in this lesson.

  1. What to do. Name the model, state when settlement becomes final, and explain what happens if the sending bank does not have enough liquidity.

Correct result. Real time gross settlement settles each payment individually in central bank money with immediate finality, but it needs liquidity for every payment. Deferred net settlement nets payments and settles the net position, which needs less liquidity but leaves settlement risk until the net settles.

Why. Settlement is where money actually moves. The model decides the risk, the liquidity need, and when the payment is truly final.

Check your understanding

Practice question

Which of the following best describes managing residual risk in practice?

Takeaway and next step

What to remember

A rehearsal that finishes late is a finding, not a pass, because in a real default the market will not wait for the team to find the document.

Settle a payment like the one in this lesson and watch the liquidity and finality behaviour.

Open the T2/TIPS Simulator →

Builds on "CLS and Foreign Exchange Settlement".

Transcript and full text

Show transcript

No system eliminates settlement risk entirely, so banks and payment system operators manage the residual risk with a combination of limits, collateral, monitoring and contingency plans. Banks set settlement limits for each counterparty, based on its credit quality and on the bank's own risk appetite, and they monitor exposures against those limits in real time. When a limit is approached, the bank may require prefunding, request collateral, or refuse new trades until the exposure falls. These limits are a basic control, and they must be enforced by systems, not just by policy documents. Collateral is another key tool. In some arrangements, a participant posts collateral that can be used to cover its settlement obligations if it fails. In others, the system itself holds a guarantee fund contributed by all participants, which can be drawn on to complete settlement if one participant defaults. The size of the fund, the contributions of each participant, and the rules for using it are critical design choices. A fund that is too small will not cover a large default, while a fund that is too large ties up capital unnecessarily. Stress testing is used to calibrate the fund against plausible failure scenarios. Finally, every system needs a clear default procedure that is tested regularly. The procedure should define who decides that a participant has defaulted, what happens to its queued and unsettled payments, how its collateral or guarantee fund contribution is used, and how other participants are informed. It should also cover communication with regulators and with the central bank. A procedure that exists only on paper is not enough. It must be rehearsed, so that when a real default happens, the team knows exactly what to do and can act quickly enough to prevent contagion. Size the safety net with numbers. A payment system holds a guarantee fund of EUR 200 million, contributed by all participants in proportion to their volumes. On a normal day the largest single net debit is EUR 90 million, so the fund covers it more than twice over. The stress test asks a harder question. What if the two largest participants fail on the same day, owing EUR 90 million and EUR 70 million, a total of EUR 160 million. The fund covers that too. What if a third participant fails as well, owing EUR 60 million, taking the total to EUR 220 million. Now the fund is EUR 20 million short, and the design must say where the rest comes from. Additional loss sharing calls on the surviving participants, in proportion to their volumes, collected within an agreed time. That is the point of the stress test, not to prove the fund is big enough, but to find the exact point where it is not, and to agree the answer before the day it happens. An analyst writes the default procedure as a runbook, not as a paragraph in a policy document. It should name the person who decides that a participant has defaulted, list the steps in order, state what happens to the defaulter's queued and unsettled payments, state the order in which margin and the guarantee fund are used, and state how and when the other participants and the regulator are informed. The procedure must be rehearsed, at least twice a year, with a timed simulation. A participant fails at 10 in the morning, the team follows the runbook, and settlement completes by the normal deadline. A rehearsal that finishes late is a finding, not a pass, because in a real default the market will not wait for the team to find the document.

No system eliminates settlement risk entirely, so banks and payment system operators manage the residual risk with a combination of limits, collateral, monitoring and contingency plans. Banks set settlement limits for each counterparty, based on its credit quality and on the bank's own risk appetite, and they monitor exposures against those limits in real time. When a limit is approached, the bank may require prefunding, request collateral, or refuse new trades until the exposure falls. These limits are a basic control, and they must be enforced by systems, not just by policy documents.

Collateral is another key tool. In some arrangements, a participant posts collateral that can be used to cover its settlement obligations if it fails. In others, the system itself holds a guarantee fund contributed by all participants, which can be drawn on to complete settlement if one participant defaults. The size of the fund, the contributions of each participant, and the rules for using it are critical design choices. A fund that is too small will not cover a large default, while a fund that is too large ties up capital unnecessarily. Stress testing is used to calibrate the fund against plausible failure scenarios.

Finally, every system needs a clear default procedure that is tested regularly. The procedure should define who decides that a participant has defaulted, what happens to its queued and unsettled payments, how its collateral or guarantee fund contribution is used, and how other participants are informed. It should also cover communication with regulators and with the central bank. A procedure that exists only on paper is not enough. It must be rehearsed, so that when a real default happens, the team knows exactly what to do and can act quickly enough to prevent contagion.

Size the safety net with numbers. A payment system holds a guarantee fund of EUR 200 million, contributed by all participants in proportion to their volumes. On a normal day the largest single net debit is EUR 90 million, so the fund covers it more than twice over. The stress test asks a harder question. What if the two largest participants fail on the same day, owing EUR 90 million and EUR 70 million, a total of EUR 160 million. The fund covers that too. What if a third participant fails as well, owing EUR 60 million, taking the total to EUR 220 million. Now the fund is EUR 20 million short, and the design must say where the rest comes from. Additional loss sharing calls on the surviving participants, in proportion to their volumes, collected within an agreed time. That is the point of the stress test, not to prove the fund is big enough, but to find the exact point where it is not, and to agree the answer before the day it happens.

An analyst writes the default procedure as a runbook, not as a paragraph in a policy document. It should name the person who decides that a participant has defaulted, list the steps in order, state what happens to the defaulter's queued and unsettled payments, state the order in which margin and the guarantee fund are used, and state how and when the other participants and the regulator are informed. The procedure must be rehearsed, at least twice a year, with a timed simulation. A participant fails at 10 in the morning, the team follows the runbook, and settlement completes by the normal deadline. A rehearsal that finishes late is a finding, not a pass, because in a real default the market will not wait for the team to find the document.

Full lesson text (all scenes)

Completing a lesson updates your progress dashboard on the homepage.

Scene timestamps are estimated by allocating the narration text proportionally across the real audio length. The audio playback position is the source of truth: pause freezes the visual, seeking restores the correct scene, replay restarts the scene animation.