Key points of this lesson, in order.
Choosing a Model for a Payment System
What you will learn
Your objective. By the end of this lesson, you will be able to explain choosing a model for a payment system. When a new payment system is designed, the settlement model is one of the earliest decisions, because it shapes everything else.
Why it matters. A business analyst working on such a project spends much of their time mapping these interfaces and confirming that the new system and the existing settlement system agree on timing, amounts and responsibilities.
Chapter objective: Learner compares gross settlement, net settlement, deferred net settlement, and real-time gross settlement, and explains finality, timing, and liquidity needs for each model. Learner practises this skill on realistic banking cases, explaining the reasoning clearly and using correct terminology throughout the work.
Key learning points
- New payment system
- Small banks and non bank payment firms
- Reusing existing settlement design
- RTGS: wrong model
- Analyst's design document
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.
Liquidity: Cash or assets that a bank can use immediately to meet payment obligations. Banks manage liquidity by forecasting inflows and outflows, funding nostro and settlement accounts, and using central bank...
Finality: The point at which a payment settlement becomes irrevocable and unconditional, so it cannot be reversed by the payer or the system.
Clearing and settlement timeline showing Choosing a Model for a Payment System.
Insights and practice scenarios
Worked insights and practice scenarios for this lesson. Each one is a reusable PaymentForge case, so the same case may appear in more than one lesson.
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.
- 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 choosing a model for a payment system?
Takeaway and next step
What to remember
Most of the analyst's time goes on that third section, confirming that the new system and the existing settlement system agree on timing, amounts, and responsibilities, because a mismatch there is discovered at the worst possible moment, on the first live settlement day.
Settle a payment like the one in this lesson and watch the liquidity and finality behaviour.
Builds on "Comparing the Three Models".
Transcript and full text
Show transcript
When a new payment system is designed, the settlement model is one of the earliest decisions, because it shapes everything else. The design team starts with the use case. Who are the users, what are they paying for, how large are the payments, how urgent are they, and what happens if a payment is delayed. A system for house purchases needs immediate finality and can justify high liquidity costs. A system for monthly utility bills does not need speed and benefits far more from low cost netting. The use case drives the model, not the other way round. The team also considers the participants. Small banks and non bank payment firms may struggle to fund large RTGS balances or large prefunds, so a model that demands heavy liquidity can become a barrier to entry. A well designed system balances safety with access, so that smaller participants can join without taking on risks they cannot manage. This is why many modern fast payment systems use prefunding with low minimums and easy top ups, and why some RTGS systems offer tiered access where smaller firms settle through a larger sponsor bank. Finally, the team considers what already exists. In most countries the central bank already operates an RTGS system, and a new retail system will settle its net positions through that RTGS system. The new system does not need to invent settlement from scratch. It needs to fit cleanly into the existing infrastructure, respecting cut off times, account structures and legal finality rules. A business analyst working on such a project spends much of their time mapping these interfaces and confirming that the new system and the existing settlement system agree on timing, amounts and responsibilities. Design a system from the use case up. A country with 40 banks wants a new instant payment system for retail customers. It will carry 12 million payments a day with an average value of EUR 85, and customers expect the money in seconds. RTGS is the wrong model. 12 million individual settlements a day would overwhelm the central bank system, and the liquidity cost would be enormous. Deferred net settlement is also wrong. It cannot deliver funds in seconds. The team chooses prefunding, with a minimum prefund of EUR 500,000, easy top ups through the RTGS system, and low barriers so small banks can join. Smaller firms that cannot prefund at all join as indirect participants through a larger sponsor bank, which settles on their behalf. If the team had chosen RTGS, the small banks would have been unable to fund the intraday balances and would not have joined, and the system would have launched with half the market missing. The analyst's design document for a new system has three sections that matter most. First, the use case, in numbers. Who pays whom, how much, how often, and how urgent it is. Second, the participants. Who can join directly, who needs a sponsor, and what the minimum liquidity requirement is for each. Third, the fit with what already exists. The new system will settle its net positions through the central bank RTGS system, so the document must map the cut off times, the account structure, and the legal finality point between the two systems. Most of the analyst's time goes on that third section, confirming that the new system and the existing settlement system agree on timing, amounts, and responsibilities, because a mismatch there is discovered at the worst possible moment, on the first live settlement day.
When a new payment system is designed, the settlement model is one of the earliest decisions, because it shapes everything else. The design team starts with the use case. Who are the users, what are they paying for, how large are the payments, how urgent are they, and what happens if a payment is delayed. A system for house purchases needs immediate finality and can justify high liquidity costs. A system for monthly utility bills does not need speed and benefits far more from low cost netting. The use case drives the model, not the other way round.
The team also considers the participants. Small banks and non bank payment firms may struggle to fund large RTGS balances or large prefunds, so a model that demands heavy liquidity can become a barrier to entry. A well designed system balances safety with access, so that smaller participants can join without taking on risks they cannot manage. This is why many modern fast payment systems use prefunding with low minimums and easy top ups, and why some RTGS systems offer tiered access where smaller firms settle through a larger sponsor bank.
Finally, the team considers what already exists. In most countries the central bank already operates an RTGS system, and a new retail system will settle its net positions through that RTGS system. The new system does not need to invent settlement from scratch. It needs to fit cleanly into the existing infrastructure, respecting cut off times, account structures and legal finality rules. A business analyst working on such a project spends much of their time mapping these interfaces and confirming that the new system and the existing settlement system agree on timing, amounts and responsibilities.
Design a system from the use case up. A country with 40 banks wants a new instant payment system for retail customers. It will carry 12 million payments a day with an average value of EUR 85, and customers expect the money in seconds. RTGS is the wrong model. 12 million individual settlements a day would overwhelm the central bank system, and the liquidity cost would be enormous. Deferred net settlement is also wrong. It cannot deliver funds in seconds. The team chooses prefunding, with a minimum prefund of EUR 500,000, easy top ups through the RTGS system, and low barriers so small banks can join. Smaller firms that cannot prefund at all join as indirect participants through a larger sponsor bank, which settles on their behalf. If the team had chosen RTGS, the small banks would have been unable to fund the intraday balances and would not have joined, and the system would have launched with half the market missing.
The analyst's design document for a new system has three sections that matter most. First, the use case, in numbers. Who pays whom, how much, how often, and how urgent it is. Second, the participants. Who can join directly, who needs a sponsor, and what the minimum liquidity requirement is for each. Third, the fit with what already exists. The new system will settle its net positions through the central bank RTGS system, so the document must map the cut off times, the account structure, and the legal finality point between the two systems. Most of the analyst's time goes on that third section, confirming that the new system and the existing settlement system agree on timing, amounts, and responsibilities, because a mismatch there is discovered at the worst possible moment, on the first live settlement day.
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.