Payments Academy
Prefunded settlement account PAYMENT OPERATIONS STARTED LIVE 01 Prefunded settlement account - model, participants deposit funds in advance ACTIVE 02 Customer expects money in seconds - fast payment system QUEUED 03 Intraday prefund top-up - Participants can top up their prefund during QUEUED 04 By 1 in the afternoon it - has sent EUR 17.5 million and received EUR 6 QUEUED 05 Prefund - runs out at eleven forty in the morning QUEUED 06 Operations runbook - who can approve an emergency top up and how QUEUED In a prefunded settlement model, participants deposit funds in advance into a settlement account, and payments are settled only to the extent that prefunded balance allows. Step 1 of 6 Prefunded settlement account STARTED Prefunded settlement account model, participants deposit funds in advance ACTIVE Customer expects money in seconds fast payment system QUEUED Intraday prefund top-up Participants can top up their prefund during QUEUED By 1 in the afternoon it has sent EUR 17.5 million and received EUR 6 QUEUED Prefund runs out at eleven forty in the morning QUEUED Operations runbook who can approve an emergency top up and QUEUED In a prefunded settlement model, participants deposit funds in advance into a settlement account, and payments are settled only to the extent that prefunded balance allows.
Customer expects money in seconds PAYMENT OPERATIONS IN PROGRESS LIVE 01 Prefunded settlement account - model, participants deposit funds in advance DONE 02 Customer expects money in seconds - fast payment system ACTIVE 03 Intraday prefund top-up - Participants can top up their prefund during QUEUED 04 By 1 in the afternoon it - has sent EUR 17.5 million and received EUR 6 QUEUED 05 Prefund - runs out at eleven forty in the morning QUEUED 06 Operations runbook - who can approve an emergency top up and how QUEUED In a fast payment system, the receiving customer expects to see the money in seconds, not hours, and the receiving bank credits the customer immediately. Step 2 of 6 Customer expects money in seconds IN PROGRESS Prefunded settlement account model, participants deposit funds in advance DONE Customer expects money in seconds fast payment system ACTIVE Intraday prefund top-up Participants can top up their prefund during QUEUED By 1 in the afternoon it has sent EUR 17.5 million and received EUR 6 QUEUED Prefund runs out at eleven forty in the morning QUEUED Operations runbook who can approve an emergency top up and QUEUED In a fast payment system, the receiving customer expects to see the money in seconds, not hours, and the receiving bank credits the customer immediately.
Intraday prefund top-up PAYMENT OPERATIONS IN PROGRESS LIVE 01 Prefunded settlement account - model, participants deposit funds in advance DONE 02 Customer expects money in seconds - fast payment system DONE 03 Intraday prefund top-up - Participants can top up their prefund during ACTIVE 04 By 1 in the afternoon it - has sent EUR 17.5 million and received EUR 6 QUEUED 05 Prefund - runs out at eleven forty in the morning QUEUED 06 Operations runbook - who can approve an emergency top up and how QUEUED Participants can top up their prefund during the day, and some systems allow a prefund to be used across multiple payment types. Step 3 of 6 Intraday prefund top-up IN PROGRESS Prefunded settlement account model, participants deposit funds in advance DONE Customer expects money in seconds fast payment system DONE Intraday prefund top-up Participants can top up their prefund during ACTIVE By 1 in the afternoon it has sent EUR 17.5 million and received EUR 6 QUEUED Prefund runs out at eleven forty in the morning QUEUED Operations runbook who can approve an emergency top up and QUEUED Participants can top up their prefund during the day, and some systems allow a prefund to be used across multiple payment types.
By 1 in the afternoon it PAYMENT OPERATIONS IN PROGRESS LIVE 01 Prefunded settlement account - model, participants deposit funds in advance DONE 02 Customer expects money in seconds - fast payment system DONE 03 Intraday prefund top-up - Participants can top up their prefund during DONE 04 By 1 in the afternoon it - has sent EUR 17.5 million and received EUR 6 ACTIVE 05 Prefund - runs out at eleven forty in the morning QUEUED 06 Operations runbook - who can approve an emergency top up and how QUEUED By 1 in the afternoon it has sent EUR 17.5 million and received EUR 6 million, so its balance is EUR 8.5 million. Step 4 of 6 By 1 in the afternoon it IN PROGRESS Prefunded settlement account model, participants deposit funds in advance DONE Customer expects money in seconds fast payment system DONE Intraday prefund top-up Participants can top up their prefund during DONE By 1 in the afternoon it has sent EUR 17.5 million and received EUR 6 ACTIVE Prefund runs out at eleven forty in the morning QUEUED Operations runbook who can approve an emergency top up and QUEUED By 1 in the afternoon it has sent EUR 17.5 million and received EUR 6 million, so its balance is EUR 8.5 million.
Prefund: rejected before treasury notices PAYMENT OPERATIONS IN PROGRESS LIVE 01 Prefunded settlement account - model, participants deposit funds in advance DONE 02 Customer expects money in seconds - fast payment system DONE 03 Intraday prefund top-up - Participants can top up their prefund during DONE 04 By 1 in the afternoon it - has sent EUR 17.5 million and received EUR 6 DONE 05 Prefund - runs out at eleven forty in the morning ACTIVE 06 Operations runbook - who can approve an emergency top up and how QUEUED The prefund runs out at eleven forty in the morning, and 400 customer payments are rejected before treasury notices and tops up. Step 5 of 6 Prefund: rejected before treasury notices IN PROGRESS Prefunded settlement account model, participants deposit funds in advance DONE Customer expects money in seconds fast payment system DONE Intraday prefund top-up Participants can top up their prefund during DONE By 1 in the afternoon it has sent EUR 17.5 million and received EUR 6 DONE Prefund runs out at eleven forty in the morning ACTIVE Operations runbook who can approve an emergency top up and QUEUED The prefund runs out at eleven forty in the morning, and 400 customer payments are rejected before treasury notices and tops up.
Operations runbook should name PAYMENT OPERATIONS COMPLETE LIVE 01 Prefunded settlement account - model, participants deposit funds in advance DONE 02 Customer expects money in seconds - fast payment system DONE 03 Intraday prefund top-up - Participants can top up their prefund during DONE 04 By 1 in the afternoon it - has sent EUR 17.5 million and received EUR 6 DONE 05 Prefund - runs out at eleven forty in the morning DONE 06 Operations runbook - who can approve an emergency top up and how ACTIVE The operations runbook should name who can approve an emergency top up and how fast it can be done. Step 6 of 6 Operations runbook should name COMPLETE Prefunded settlement account model, participants deposit funds in advance DONE Customer expects money in seconds fast payment system DONE Intraday prefund top-up Participants can top up their prefund during DONE By 1 in the afternoon it has sent EUR 17.5 million and received EUR 6 DONE Prefund runs out at eleven forty in the morning DONE Operations runbook who can approve an emergency top up and ACTIVE The operations runbook should name who can approve an emergency top up and how fast it can be done.

Key points of this lesson, in order.

0:00 / 3:26 Step 1 of 6

Prefunded Settlement Models

Settlement Models, Lesson 4 of 7, Narration 3:26, D07 Clearing, settlement and liquidity

SettlementLiquidityReturn

What you will learn

Your objective. By the end of this lesson, you will be able to explain prefunded settlement models. In a prefunded settlement model, participants deposit funds in advance into a settlement account, and payments are settled only to the extent that prefunded balance allows.

Why it matters. A business analyst designing a prefunded system needs to model the prefund sizing problem carefully, because getting it wrong directly affects customer experience, either through rejected payments or through wasted liquidity.

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

  • Prefunded settlement account
  • Customer expects money in seconds
  • Intraday prefund top-up
  • By 1 in the afternoon it
  • Prefund: rejected before treasury notices
  • Operations runbook should name

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...

Return: A payment that is sent back to the sender after settlement because it cannot be credited to the beneficiary.

Clearing and settlement timeline showing Prefunded Settlement Models.

Practise this lesson

Exercise

Scenario: you are a liquidity manager at a bank. Today is a high-value payment day. Your bank has a settlement account at the central bank with an opening balance of EUR 200 million. You have an intraday credit facility of EUR 100 million. You have outgoing payments queued and incoming payments expected. Identify whether the bank will face a liquidity shortfall, at what time, and what action to take.

Opening balance: EUR 200 million. Intraday credit facility: EUR 100 million, so the maximum available is EUR 300 million. Outgoing payments: 09:00 EUR 80 million to Bank B. 10:00 EUR 120 million to Bank C. 11:00 EUR 90 million to Bank D. 13:00 EUR 60 million to Bank B. 15:00 EUR 40 million to Bank C. Incoming payments: 09:30 EUR 50 million from Bank B. 10:30 EUR 70 million from Bank C. 12:00 EUR 100 million from Bank D. 14:00 EUR 60 million from Bank B. 16:00 EUR 30 million from Bank C.

  1. What to do. Build a timeline of the account balance through the day. Identify the lowest point, whether it goes below zero, and whether the intraday credit facility covers it. Then state the action to take and when.

Correct result. Timeline: opening EUR 200 million. 09:00 pay 80, balance 120. 09:30 receive 50, balance 170. 10:00 pay 120, balance 50. 10:30 receive 70, balance 120. 11:00 pay 90, balance 30. 12:00 receive 100, balance 130. 13:00 pay 60, balance 70. 14:00 receive 60, balance 130. 15:00 pay 40, balance 90. 16:00 receive 30, balance 120. Lowest point: EUR 30 million at 11:00, after the 90 million payment to Bank D. The balance never goes below zero, so there is no shortfall on this schedule, and the intraday credit facility is not needed. However, the margin is thin: if the 12:00 incoming payment of EUR 100 million from Bank D is delayed by one hour, the 13:00 payment of EUR 60 million would take the balance from 30 to minus 30, which would require EUR 30 million of intraday credit. Action: monitor the 12:00 incoming payment closely; if it has not arrived by 12:30, draw EUR 30 million of intraday credit pre-emptively and hold the 13:00 payment until the incoming payment arrives or the credit is confirmed. Worked reasoning: liquidity management is about timing, not just totals. Total outgoing is 390 million and total incoming is 310 million, so the day ends at 120 million, but the intraday low is what matters. A delay in one incoming payment can turn a comfortable day into a shortfall.

Why. Hint 1: build the timeline hour by hour; the lowest point is what matters, not the closing balance. Hint 2: compare the lowest point to zero and to the intraday credit facility. Hint 3: identify which single incoming payment, if delayed, would cause the shortfall. The worked explanation shows the liquidity discipline: track the balance through the day, find the low point, and have a contingency ready before it happens.

Check your understanding

Practice question

A BA is writing requirements for a new settlement report. A developer asks whether the report should show the message sent time or the settlement finality time. What is the right answer?

Takeaway and next step

What to remember

Funds sitting in the settlement account earn little or no return, so every extra million of buffer has a price.

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

Open the T2/TIPS Simulator →

Builds on "Deferred Net Settlement".

Transcript and full text

Show transcript

In a prefunded settlement model, participants deposit funds in advance into a settlement account, and payments are settled only to the extent that prefunded balance allows. A participant cannot send more than it has prefunded, which means settlement is guaranteed as long as the prefund is in place. This model is used by many fast payment systems, where the promise to the customer is immediate availability of funds, and by some card and mobile money systems where the settlement risk must be kept to zero. Prefunding works well when speed and certainty matter more than liquidity efficiency. In a fast payment system, the receiving customer expects to see the money in seconds, not hours, and the receiving bank credits the customer immediately. That credit is only safe if the sending bank has already funded it. Prefunding provides that safety. The cost is that funds sit idle in the settlement account, earning little or no return, and participants must forecast how much they will need. If they prefund too little, payments are rejected or delayed. If they prefund too much, capital is tied up unnecessarily. Many systems combine prefunding with other features to reduce the cost. Participants can top up their prefund during the day, and some systems allow a prefund to be used across multiple payment types. Some central banks pay interest on prefunded balances, or allow the prefund to count towards reserve requirements, which softens the cost. A business analyst designing a prefunded system needs to model the prefund sizing problem carefully, because getting it wrong directly affects customer experience, either through rejected payments or through wasted liquidity. Follow the prefund through a day. Bank A starts at 8 in the morning with EUR 20 million prefunded in its fast payment settlement account. By 1 in the afternoon it has sent EUR 17.5 million and received EUR 6 million, so its balance is EUR 8.5 million. At one twenty in the afternoon a corporate customer sends a EUR 9 million payment, which is more than the balance, so the payment cannot settle from the prefund. The system either rejects it or holds it while treasury tops the prefund up by EUR 10 million, and the payment goes through minutes later. Now take the forecasting failure. Bank A sizes its prefund on an average day, EUR 12 million, but today is month end, when salary payments push its outflows to EUR 19 million by midday. The prefund runs out at eleven forty in the morning, and 400 customer payments are rejected before treasury notices and tops up. The customers see failed payments, the bank sees complaints, and the cause is not a system fault but a prefund sized for the wrong day. Sizing the prefund is the analyst's core modelling task for this model. The model should take the peak day outflow, not the average, add a buffer for unexpected large payments, and subtract the expected inflows for the same period. The requirements should state the auto top up rules, for example topping up automatically when the balance falls below 20 percent, and the alert thresholds, for example an amber alert at 80 percent usage and a red alert at 95 percent. The operations runbook should name who can approve an emergency top up and how fast it can be done. And the cost of the prefund should be stated honestly in the business case. Funds sitting in the settlement account earn little or no return, so every extra million of buffer has a price.

In a prefunded settlement model, participants deposit funds in advance into a settlement account, and payments are settled only to the extent that prefunded balance allows. A participant cannot send more than it has prefunded, which means settlement is guaranteed as long as the prefund is in place. This model is used by many fast payment systems, where the promise to the customer is immediate availability of funds, and by some card and mobile money systems where the settlement risk must be kept to zero.

Prefunding works well when speed and certainty matter more than liquidity efficiency. In a fast payment system, the receiving customer expects to see the money in seconds, not hours, and the receiving bank credits the customer immediately. That credit is only safe if the sending bank has already funded it. Prefunding provides that safety. The cost is that funds sit idle in the settlement account, earning little or no return, and participants must forecast how much they will need. If they prefund too little, payments are rejected or delayed. If they prefund too much, capital is tied up unnecessarily.

Many systems combine prefunding with other features to reduce the cost. Participants can top up their prefund during the day, and some systems allow a prefund to be used across multiple payment types. Some central banks pay interest on prefunded balances, or allow the prefund to count towards reserve requirements, which softens the cost. A business analyst designing a prefunded system needs to model the prefund sizing problem carefully, because getting it wrong directly affects customer experience, either through rejected payments or through wasted liquidity.

Follow the prefund through a day. Bank A starts at 8 in the morning with EUR 20 million prefunded in its fast payment settlement account. By 1 in the afternoon it has sent EUR 17.5 million and received EUR 6 million, so its balance is EUR 8.5 million. At one twenty in the afternoon a corporate customer sends a EUR 9 million payment, which is more than the balance, so the payment cannot settle from the prefund. The system either rejects it or holds it while treasury tops the prefund up by EUR 10 million, and the payment goes through minutes later. Now take the forecasting failure. Bank A sizes its prefund on an average day, EUR 12 million, but today is month end, when salary payments push its outflows to EUR 19 million by midday. The prefund runs out at eleven forty in the morning, and 400 customer payments are rejected before treasury notices and tops up. The customers see failed payments, the bank sees complaints, and the cause is not a system fault but a prefund sized for the wrong day.

Sizing the prefund is the analyst's core modelling task for this model. The model should take the peak day outflow, not the average, add a buffer for unexpected large payments, and subtract the expected inflows for the same period. The requirements should state the auto top up rules, for example topping up automatically when the balance falls below 20 percent, and the alert thresholds, for example an amber alert at 80 percent usage and a red alert at 95 percent. The operations runbook should name who can approve an emergency top up and how fast it can be done. And the cost of the prefund should be stated honestly in the business case. Funds sitting in the settlement account earn little or no return, so every extra million of buffer has a price.

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.