Payments Training Hub
Settlement system design PAYMENT OPERATIONS STARTED LIVE 01 Settlement system - Designing a settlement system ACTIVE 02 PFMI - provides the framework QUEUED 03 Settlement cycle specification - Two, the cycle: the number of cycles per QUEUED 04 Instant payment system - analyst specifies deferred net settlement QUEUED 05 Incomplete checklist incidents - system that launched without a stress test QUEUED 06 Checklist as the BA deliverable - most valuable thing you can do is to find QUEUED Designing a settlement system is a requirements exercise that spans business rules Step 1 of 6 Settlement system design STARTED Settlement system Designing a settlement system ACTIVE PFMI provides the framework QUEUED Settlement cycle specification Two, the cycle: the number of cycles per QUEUED Instant payment system analyst specifies deferred net settlement QUEUED Incomplete checklist incidents system that launched without a stress test QUEUED Checklist as the BA deliverable most valuable thing you can do is to find QUEUED Designing a settlement system is a requirements exercise that spans business rules
PFMI design framework PAYMENT OPERATIONS IN PROGRESS LIVE 01 Settlement system - Designing a settlement system DONE 02 PFMI - provides the framework ACTIVE 03 Settlement cycle specification - Two, the cycle: the number of cycles per QUEUED 04 Instant payment system - analyst specifies deferred net settlement QUEUED 05 Incomplete checklist incidents - system that launched without a stress test QUEUED 06 Checklist as the BA deliverable - most valuable thing you can do is to find QUEUED The PFMI provides the framework, but it does not write your requirements: it says you must manage credit Step 2 of 6 PFMI design framework IN PROGRESS Settlement system Designing a settlement system DONE PFMI provides the framework ACTIVE Settlement cycle specification Two, the cycle: the number of cycles per QUEUED Instant payment system analyst specifies deferred net settlement QUEUED Incomplete checklist incidents system that launched without a stress test QUEUED Checklist as the BA deliverable most valuable thing you can do is to find QUEUED The PFMI provides the framework, but it does not write your requirements: it says you must manage credit
Settlement cycle specification PAYMENT OPERATIONS IN PROGRESS LIVE 01 Settlement system - Designing a settlement system DONE 02 PFMI - provides the framework DONE 03 Settlement cycle specification - Two, the cycle: the number of cycles per ACTIVE 04 Instant payment system - analyst specifies deferred net settlement QUEUED 05 Incomplete checklist incidents - system that launched without a stress test QUEUED 06 Checklist as the BA deliverable - most valuable thing you can do is to find QUEUED Two, the cycle: the number of cycles per day, the cut-off times, and the settlement windows. Step 3 of 6 Settlement cycle specification IN PROGRESS Settlement system Designing a settlement system DONE PFMI provides the framework DONE Settlement cycle specification Two, the cycle: the number of cycles per ACTIVE Instant payment system analyst specifies deferred net settlement QUEUED Incomplete checklist incidents system that launched without a stress test QUEUED Checklist as the BA deliverable most valuable thing you can do is to find QUEUED Two, the cycle: the number of cycles per day, the cut-off times, and the settlement windows.
Instant payment system design example PAYMENT OPERATIONS IN PROGRESS LIVE 01 Settlement system - Designing a settlement system DONE 02 PFMI - provides the framework DONE 03 Settlement cycle specification - Two, the cycle: the number of cycles per DONE 04 Instant payment system - analyst specifies deferred net settlement ACTIVE 05 Incomplete checklist incidents - system that launched without a stress test QUEUED 06 Checklist as the BA deliverable - most valuable thing you can do is to find QUEUED The analyst specifies deferred net settlement with four cycles per day, cut-offs at 09:00, 12:00, 15:00 and 17:30, and a funding deadline 30 minutes after each cut-off. Step 4 of 6 Instant payment system design example IN PROGRESS Settlement system Designing a settlement system DONE PFMI provides the framework DONE Settlement cycle specification Two, the cycle: the number of cycles per DONE Instant payment system analyst specifies deferred net settlement ACTIVE Incomplete checklist incidents system that launched without a stress test QUEUED Checklist as the BA deliverable most valuable thing you can do is to find QUEUED The analyst specifies deferred net settlement with four cycles per day, cut-offs at 09:00, 12:00, 15:00 and 17:30, and a funding deadline 30 minutes after each cut-off.
Incomplete checklist incidents PAYMENT OPERATIONS IN PROGRESS LIVE 01 Settlement system - Designing a settlement system DONE 02 PFMI - provides the framework DONE 03 Settlement cycle specification - Two, the cycle: the number of cycles per DONE 04 Instant payment system - analyst specifies deferred net settlement DONE 05 Incomplete checklist incidents - system that launched without a stress test ACTIVE 06 Checklist as the BA deliverable - most valuable thing you can do is to find QUEUED A system that launched without a stress test discovered that its default fund was too small only when the regulator asked for the test results. Step 5 of 6 Incomplete checklist incidents IN PROGRESS Settlement system Designing a settlement system DONE PFMI provides the framework DONE Settlement cycle specification Two, the cycle: the number of cycles per DONE Instant payment system analyst specifies deferred net settlement DONE Incomplete checklist incidents system that launched without a stress test ACTIVE Checklist as the BA deliverable most valuable thing you can do is to find QUEUED A system that launched without a stress test discovered that its default fund was too small only when the regulator asked for the test results.
Checklist as the BA deliverable PAYMENT OPERATIONS COMPLETE LIVE 01 Settlement system - Designing a settlement system DONE 02 PFMI - provides the framework DONE 03 Settlement cycle specification - Two, the cycle: the number of cycles per DONE 04 Instant payment system - analyst specifies deferred net settlement DONE 05 Incomplete checklist incidents - system that launched without a stress test DONE 06 Checklist as the BA deliverable - most valuable thing you can do is to find ACTIVE The most valuable thing you can do is to find the missing item before go-live, because after go-live it will find you. Step 6 of 6 Checklist as the BA deliverable COMPLETE Settlement system Designing a settlement system DONE PFMI provides the framework DONE Settlement cycle specification Two, the cycle: the number of cycles per DONE Instant payment system analyst specifies deferred net settlement DONE Incomplete checklist incidents system that launched without a stress test DONE Checklist as the BA deliverable most valuable thing you can do is to find ACTIVE The most valuable thing you can do is to find the missing item before go-live, because after go-live it will find you.

Key points of this lesson, in order.

0:00 / 6:24 Step 1 of 6

Designing a settlement system: a BA checklist from requirements to go-live

Settlement design and failure, Lesson 8 of 8, Narration 6:24, D07 Clearing, settlement and liquidity

Liquidity transferReconciliationSettlement

What you will learn

Your objective. By the end of this lesson, you will be able to explain designing a settlement system: a BA checklist from requirements to go-live and apply it to a real banking scenario.

Why it matters. For a business analyst, this checklist is your deliverable.

Chapter objective: How settlement cycles are designed, how liquidity is optimised, and what happens when settlement fails

Key learning points

  • Settlement system design
  • PFMI design framework
  • Settlement cycle specification
  • Instant payment system design example
  • Incomplete checklist incidents
  • Checklist as the BA deliverable

Key terms

Liquidity transfer: A movement of funds between accounts held by the same participant to manage liquidity, for example from a main cash account to a dedicated cash account.

Reconciliation: The process of comparing records from two sources, such as a bank statement and an internal ledger, to confirm they agree.

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.

Clearing and settlement timeline showing Designing a settlement system: a BA checklist from requirements to go-live.

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 designing a settlement system: a BA checklist from requirements to go-live?

Takeaway and next step

What to remember

For a business analyst, this checklist is your deliverable.

Follow EUR 20 through every stage, from instruction to beneficiary credit, and note where it can stop.

Open the Payment Lifecycle Simulator →

Builds on "The default waterfall: who pays when a participant fails".

Transcript and full text

Show transcript

Designing a settlement system is a requirements exercise that spans business rules, operations, risk, technology and law, and a business analyst who owns it must work through a checklist that covers every decision the operator will have to make. The checklist starts with the settlement model, moves through the cycle and the liquidity arrangements, covers the default procedure and the waterfall, and ends with testing and go-live. Skipping any item does not make it go away: it reappears as a production incident, usually at the worst possible time. This lesson is the checklist, and it is written from the experience of systems that have gone live and systems that have failed. Why a checklist matters is that settlement systems are unforgiving of omissions. A payment system that forgets to specify the cut-off time will have payments arriving after settlement with nowhere to go. A system that forgets to specify the exclusion procedure will freeze when a participant fails. A system that forgets to specify the reconciliation will have breaks that nobody can explain. The PFMI provides the framework, but it does not write your requirements: it says you must manage credit and liquidity risk, but it does not tell you your cut-off time or your default fund size. Those are your decisions, and they must be written down, agreed, and tested before go-live. The parties are the business analyst, the product owner, the operations team, the treasury team, the risk team, the technology team, the legal team, and the regulator. Each one owns a part of the checklist. The business analyst owns the functional requirements, the operations team owns the procedures, the treasury team owns the liquidity arrangements, the risk team owns the default fund and the stress tests, the technology team owns the system design, the legal team owns the rulebook and the settlement finality opinion, and the regulator owns the approval. A settlement system cannot go live until the regulator is satisfied, and the regulator will ask for the checklist. In practice the checklist has ten items. One, the settlement model: real-time gross, deferred net, or prefunded, and why. Two, the cycle: the number of cycles per day, the cut-off times, and the settlement windows. Three, the liquidity: the intraday credit arrangements, the collateral eligibility and haircuts, and the queue optimisation. Four, the accounts: the settlement account structure and the liquidity transfer mechanism. Five, the messages: the settlement instruction format, the status reports, and the end-of-day statement. Six, the default procedure: the funding deadline, the grace period, the exclusion rule, and the recomputation logic. Seven, the waterfall: the margin, the default fund size and contribution formula, the assessment cap, and the replenishment deadline. Eight, the reconciliation: the clearing account, the settlement account, and the break management procedure. Nine, the testing: the gridlock scenario, the settlement failure scenario, the default scenario, and the stress test. Ten, the go-live: the participant onboarding, the dress rehearsal, and the rollback plan. A worked example shows how the checklist is used. A new instant payment system is being designed for a market with ten banks. The analyst specifies deferred net settlement with four cycles per day, cut-offs at 09:00, 12:00, 15:00 and 17:30, and a funding deadline 30 minutes after each cut-off. Intraday credit is available against government bonds with a 2 percent haircut. The default fund is EUR 20 million, contributed pro rata to payment volumes, with an assessment cap of one times the contribution. The reconciliation is a daily camt.053 statement matched to the ledger. The testing includes a gridlock scenario with three banks, a settlement failure scenario with the largest participant, and a stress test with the largest participant defaulting under a 20 percent fall in collateral values. The go-live is a dress rehearsal with all ten banks, followed by a phased launch with two banks, then all ten. What happens when the checklist is incomplete is predictable: the missing item becomes an incident. A system that launched without a defined exclusion procedure discovered the gap when its largest participant failed to fund on the second day of operation, and the operator had to improvise a recomputation while the settlement was already late. A system that launched without a stress test discovered that its default fund was too small only when the regulator asked for the test results. A system that launched without a rollback plan discovered that it could not return to the old system when the new one failed, and had to operate manually for three days. Every one of these incidents was preventable by a checklist review before go-live. The operational and accounting implications are that the checklist is a living document, not a one-off exercise. After go-live, the operations team must review it after every incident, the risk team must review it after every stress test, and the treasury team must review it when liquidity conditions change. The accounting team must ensure that every item on the checklist has a corresponding ledger treatment: the default fund contributions, the assessments, the intraday credit, and the settlement account must all be booked correctly, and the reconciliation must prove it every day. For a business analyst, this checklist is your deliverable. When you are asked to design or to review a settlement system, start with these ten items, work through each one with the owning team, and do not sign off until every item has a written requirement, a test case, and an owner. The most valuable thing you can do is to find the missing item before go-live, because after go-live it will find you. A settlement system is judged not by how it works on a normal day, but by how it behaves on the worst day, and the checklist is what makes the worst day survivable. Takeaway: settlement design is ten decisions, and the system is only as strong as the weakest one. Further reading: the BIS Principles for Financial Market Infrastructures (PFMI) as the design framework; the ECB TARGET documentation; the Bank of England CHAPS reference manual. Last reviewed 7 November 2026. A design review that skips one decision will find it again in production, usually at 03:00 on a Monday, when the operator is alone.

Designing a settlement system is a requirements exercise that spans business rules, operations, risk, technology and law, and a business analyst who owns it must work through a checklist that covers every decision the operator will have to make. The checklist starts with the settlement model, moves through the cycle and the liquidity arrangements, covers the default procedure and the waterfall, and ends with testing and go-live. Skipping any item does not make it go away: it reappears as a production incident, usually at the worst possible time. This lesson is the checklist, and it is written from the experience of systems that have gone live and systems that have failed.

Why a checklist matters is that settlement systems are unforgiving of omissions. A payment system that forgets to specify the cut-off time will have payments arriving after settlement with nowhere to go. A system that forgets to specify the exclusion procedure will freeze when a participant fails. A system that forgets to specify the reconciliation will have breaks that nobody can explain. The PFMI provides the framework, but it does not write your requirements: it says you must manage credit and liquidity risk, but it does not tell you your cut-off time or your default fund size. Those are your decisions, and they must be written down, agreed, and tested before go-live.

The parties are the business analyst, the product owner, the operations team, the treasury team, the risk team, the technology team, the legal team, and the regulator. Each one owns a part of the checklist. The business analyst owns the functional requirements, the operations team owns the procedures, the treasury team owns the liquidity arrangements, the risk team owns the default fund and the stress tests, the technology team owns the system design, the legal team owns the rulebook and the settlement finality opinion, and the regulator owns the approval. A settlement system cannot go live until the regulator is satisfied, and the regulator will ask for the checklist.

In practice the checklist has ten items. One, the settlement model: real-time gross, deferred net, or prefunded, and why. Two, the cycle: the number of cycles per day, the cut-off times, and the settlement windows. Three, the liquidity: the intraday credit arrangements, the collateral eligibility and haircuts, and the queue optimisation. Four, the accounts: the settlement account structure and the liquidity transfer mechanism. Five, the messages: the settlement instruction format, the status reports, and the end-of-day statement.

Six, the default procedure: the funding deadline, the grace period, the exclusion rule, and the recomputation logic. Seven, the waterfall: the margin, the default fund size and contribution formula, the assessment cap, and the replenishment deadline. Eight, the reconciliation: the clearing account, the settlement account, and the break management procedure. Nine, the testing: the gridlock scenario, the settlement failure scenario, the default scenario, and the stress test. Ten, the go-live: the participant onboarding, the dress rehearsal, and the rollback plan.

A worked example shows how the checklist is used. A new instant payment system is being designed for a market with ten banks. The analyst specifies deferred net settlement with four cycles per day, cut-offs at 09:00, 12:00, 15:00 and 17:30, and a funding deadline 30 minutes after each cut-off. Intraday credit is available against government bonds with a 2 percent haircut. The default fund is EUR 20 million, contributed pro rata to payment volumes, with an assessment cap of one times the contribution.

The reconciliation is a daily camt.053 statement matched to the ledger. The testing includes a gridlock scenario with three banks, a settlement failure scenario with the largest participant, and a stress test with the largest participant defaulting under a 20 percent fall in collateral values. The go-live is a dress rehearsal with all ten banks, followed by a phased launch with two banks, then all ten.

What happens when the checklist is incomplete is predictable: the missing item becomes an incident. A system that launched without a defined exclusion procedure discovered the gap when its largest participant failed to fund on the second day of operation, and the operator had to improvise a recomputation while the settlement was already late. A system that launched without a stress test discovered that its default fund was too small only when the regulator asked for the test results. A system that launched without a rollback plan discovered that it could not return to the old system when the new one failed, and had to operate manually for three days. Every one of these incidents was preventable by a checklist review before go-live.

The operational and accounting implications are that the checklist is a living document, not a one-off exercise. After go-live, the operations team must review it after every incident, the risk team must review it after every stress test, and the treasury team must review it when liquidity conditions change. The accounting team must ensure that every item on the checklist has a corresponding ledger treatment: the default fund contributions, the assessments, the intraday credit, and the settlement account must all be booked correctly, and the reconciliation must prove it every day.

For a business analyst, this checklist is your deliverable. When you are asked to design or to review a settlement system, start with these ten items, work through each one with the owning team, and do not sign off until every item has a written requirement, a test case, and an owner. The most valuable thing you can do is to find the missing item before go-live, because after go-live it will find you. A settlement system is judged not by how it works on a normal day, but by how it behaves on the worst day, and the checklist is what makes the worst day survivable.

Takeaway: settlement design is ten decisions, and the system is only as strong as the weakest one. Further reading: the BIS Principles for Financial Market Infrastructures (PFMI) as the design framework; the ECB TARGET documentation; the Bank of England CHAPS reference manual. Last reviewed 7 November 2026. A design review that skips one decision will find it again in production, usually at 03:00 on a Monday, when the operator is alone.

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.