Key points of this lesson, in order.
Comparing the Three Models
What you will learn
Your objective. By the end of this lesson, you will be able to explain comparing the three models. RTGS, deferred net settlement and prefunded settlement each solve a different problem, and the choice between them is a trade off between risk, liquidity and speed.
Why it matters. Understanding these regulatory drivers helps a business analyst explain why a system is designed the way it is, rather than simply describing its mechanics.
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
- Deferred net settlement and prefunded settlement each
- How large
- Central banks often mandate RTGS for systemically
- Through RTGS it settles in seconds
- Through deferred net settlement it costs almost
- Picks a model because it
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 Comparing the Three Models.
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 comparing the three models?
Takeaway and next step
What to remember
A design that picks a model because it is familiar, rather than because it fits the matrix, will be expensive to fix later.
Settle a payment like the one in this lesson and watch the liquidity and finality behaviour.
Builds on "Prefunded Settlement Models".
Transcript and full text
Show transcript
RTGS, deferred net settlement and prefunded settlement each solve a different problem, and the choice between them is a trade off between risk, liquidity and speed. RTGS offers immediate finality and minimal credit risk, but demands the most liquidity. Deferred net settlement offers the lowest liquidity cost and is ideal for bulk low value payments, but leaves an exposure window between clearing and settlement. Prefunded settlement offers certainty and speed, but ties up funds in advance and requires careful forecasting. No single model is best for every use case. A useful way to compare them is to look at three questions. First, how large is the typical payment and how serious would a failure be. High value payments justify the liquidity cost of RTGS. Second, how many payments are there and how small are they. High volume low value payments favour deferred net settlement. Third, how fast does the recipient need the funds. If the answer is seconds, prefunding or RTGS is needed, because deferred net settlement cannot deliver that speed. Real payment systems often use more than one model, with RTGS for high value and deferred net settlement for retail, running side by side. Regulators also influence the choice. Central banks often mandate RTGS for systemically important payments, because the failure of a large payment could threaten financial stability. They may also set rules for deferred net settlement systems, such as requiring prefunding or collateral to cover the largest single net debit, so that the system can still settle even if its largest participant fails. Understanding these regulatory drivers helps a business analyst explain why a system is designed the way it is, rather than simply describing its mechanics. Compare the models with the same payment. A bank needs to pay EUR 50 million to another bank for an interbank loan. Through RTGS it settles in seconds and is final immediately, but the bank must hold EUR 50 million of liquidity at that moment. Through deferred net settlement it settles at 4 in the afternoon with the rest of the day's payments, and the bank only funds its net debit for the day, say EUR 6 million, but the receiving bank waits hours and carries the exposure in between. Through a prefunded system it settles in seconds, provided the EUR 50 million fits inside the prefund the bank posted that morning. Now take the opposite payment. A EUR 250 salary payment. Through RTGS it would consume the same operational effort and liquidity machinery as the EUR 50 million loan, which is disproportionate. Through deferred net settlement it costs almost nothing, because it is one of millions netted together. The right model depends on the payment, not on the bank. An analyst turns the comparison into a decision matrix in the design document. The rows are the use cases, salary payments, supplier payments, house purchases, interbank loans, and the columns are the questions. How large is the typical payment, how many are there, how fast must the recipient have the funds, and how serious is a failure. The matrix is then checked against the regulatory requirements, because a central bank may mandate RTGS for systemically important payments regardless of cost, and may require prefunding or collateral for a deferred net settlement system so it can still settle if its largest participant fails. A design that picks a model because it is familiar, rather than because it fits the matrix, will be expensive to fix later.
RTGS, deferred net settlement and prefunded settlement each solve a different problem, and the choice between them is a trade off between risk, liquidity and speed. RTGS offers immediate finality and minimal credit risk, but demands the most liquidity. Deferred net settlement offers the lowest liquidity cost and is ideal for bulk low value payments, but leaves an exposure window between clearing and settlement. Prefunded settlement offers certainty and speed, but ties up funds in advance and requires careful forecasting. No single model is best for every use case.
A useful way to compare them is to look at three questions. First, how large is the typical payment and how serious would a failure be. High value payments justify the liquidity cost of RTGS. Second, how many payments are there and how small are they. High volume low value payments favour deferred net settlement. Third, how fast does the recipient need the funds. If the answer is seconds, prefunding or RTGS is needed, because deferred net settlement cannot deliver that speed. Real payment systems often use more than one model, with RTGS for high value and deferred net settlement for retail, running side by side.
Regulators also influence the choice. Central banks often mandate RTGS for systemically important payments, because the failure of a large payment could threaten financial stability. They may also set rules for deferred net settlement systems, such as requiring prefunding or collateral to cover the largest single net debit, so that the system can still settle even if its largest participant fails. Understanding these regulatory drivers helps a business analyst explain why a system is designed the way it is, rather than simply describing its mechanics.
Compare the models with the same payment. A bank needs to pay EUR 50 million to another bank for an interbank loan. Through RTGS it settles in seconds and is final immediately, but the bank must hold EUR 50 million of liquidity at that moment. Through deferred net settlement it settles at 4 in the afternoon with the rest of the day's payments, and the bank only funds its net debit for the day, say EUR 6 million, but the receiving bank waits hours and carries the exposure in between. Through a prefunded system it settles in seconds, provided the EUR 50 million fits inside the prefund the bank posted that morning. Now take the opposite payment. A EUR 250 salary payment. Through RTGS it would consume the same operational effort and liquidity machinery as the EUR 50 million loan, which is disproportionate. Through deferred net settlement it costs almost nothing, because it is one of millions netted together. The right model depends on the payment, not on the bank.
An analyst turns the comparison into a decision matrix in the design document. The rows are the use cases, salary payments, supplier payments, house purchases, interbank loans, and the columns are the questions. How large is the typical payment, how many are there, how fast must the recipient have the funds, and how serious is a failure. The matrix is then checked against the regulatory requirements, because a central bank may mandate RTGS for systemically important payments regardless of cost, and may require prefunding or collateral for a deferred net settlement system so it can still settle if its largest participant fails. A design that picks a model because it is familiar, rather than because it fits the matrix, will be expensive to fix later.
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.