Payments Training Hub
Insufficient settlement funds PAYMENT OPERATIONS STARTED LIVE 01 Insufficient settlement funds - When a bank does not have enough funds ACTIVE 02 Bilateral queue offsetting - If Bank A has a queued payment to Bank B QUEUED 03 Such as those related to monetary - Urgent payments QUEUED 04 Bilateral offsetting - pairs the first two and settles both using QUEUED 05 Four banks - Without it, the four banks would wait QUEUED 06 Audit trail - cancellation with the user and the reason QUEUED When a bank does not have enough funds to settle a payment immediately, the payment system does not necessarily reject it. Step 1 of 6 Insufficient settlement funds STARTED Insufficient settlement funds When a bank does not have enough funds ACTIVE Bilateral queue offsetting If Bank A has a queued payment to Bank B QUEUED Such as those related to monetary Urgent payments QUEUED Bilateral offsetting pairs the first two and settles both using QUEUED Four banks Without it, the four banks would wait QUEUED Audit trail cancellation with the user and the reason QUEUED When a bank does not have enough funds to settle a payment immediately, the payment system does not necessarily reject it.
Bilateral queue offsetting PAYMENT OPERATIONS IN PROGRESS LIVE 01 Insufficient settlement funds - When a bank does not have enough funds DONE 02 Bilateral queue offsetting - If Bank A has a queued payment to Bank B ACTIVE 03 Such as those related to monetary - Urgent payments QUEUED 04 Bilateral offsetting - pairs the first two and settles both using QUEUED 05 Four banks - Without it, the four banks would wait QUEUED 06 Audit trail - cancellation with the user and the reason QUEUED If Bank A has a queued payment to Bank B, and Bank B has a queued payment to Bank A, the system can settle both at once, using only the net difference. Step 2 of 6 Bilateral queue offsetting IN PROGRESS Insufficient settlement funds When a bank does not have enough funds DONE Bilateral queue offsetting If Bank A has a queued payment to Bank B ACTIVE Such as those related to monetary Urgent payments QUEUED Bilateral offsetting pairs the first two and settles both using QUEUED Four banks Without it, the four banks would wait QUEUED Audit trail cancellation with the user and the reason QUEUED If Bank A has a queued payment to Bank B, and Bank B has a queued payment to Bank A, the system can settle both at once, using only the net difference.
Such as those related to monetary policy PAYMENT OPERATIONS IN PROGRESS LIVE 01 Insufficient settlement funds - When a bank does not have enough funds DONE 02 Bilateral queue offsetting - If Bank A has a queued payment to Bank B DONE 03 Such as those related to monetary - Urgent payments ACTIVE 04 Bilateral offsetting - pairs the first two and settles both using QUEUED 05 Four banks - Without it, the four banks would wait QUEUED 06 Audit trail - cancellation with the user and the reason QUEUED Urgent payments, such as those related to monetary policy or to another payment system, can be given a higher priority and settle first. Step 3 of 6 Such as those related to monetary policy IN PROGRESS Insufficient settlement funds When a bank does not have enough funds DONE Bilateral queue offsetting If Bank A has a queued payment to Bank B DONE Such as those related to monetary Urgent payments ACTIVE Bilateral offsetting pairs the first two and settles both using QUEUED Four banks Without it, the four banks would wait QUEUED Audit trail cancellation with the user and the reason QUEUED Urgent payments, such as those related to monetary policy or to another payment system, can be given a higher priority and settle first.
Bilateral offsetting net difference PAYMENT OPERATIONS IN PROGRESS LIVE 01 Insufficient settlement funds - When a bank does not have enough funds DONE 02 Bilateral queue offsetting - If Bank A has a queued payment to Bank B DONE 03 Such as those related to monetary - Urgent payments DONE 04 Bilateral offsetting - pairs the first two and settles both using ACTIVE 05 Four banks - Without it, the four banks would wait QUEUED 06 Audit trail - cancellation with the user and the reason QUEUED Bilateral offsetting pairs the first two and settles both using only the EUR 2 million net difference. Step 4 of 6 Bilateral offsetting net difference IN PROGRESS Insufficient settlement funds When a bank does not have enough funds DONE Bilateral queue offsetting If Bank A has a queued payment to Bank B DONE Such as those related to monetary Urgent payments DONE Bilateral offsetting pairs the first two and settles both using ACTIVE Four banks Without it, the four banks would wait QUEUED Audit trail cancellation with the user and the reason QUEUED Bilateral offsetting pairs the first two and settles both using only the EUR 2 million net difference.
Four banks would wait for funds PAYMENT OPERATIONS IN PROGRESS LIVE 01 Insufficient settlement funds - When a bank does not have enough funds DONE 02 Bilateral queue offsetting - If Bank A has a queued payment to Bank B DONE 03 Such as those related to monetary - Urgent payments DONE 04 Bilateral offsetting - pairs the first two and settles both using DONE 05 Four banks - Without it, the four banks would wait ACTIVE 06 Audit trail - cancellation with the user and the reason QUEUED Without it, the four banks would wait for funds that could only come from each other, and the queues would stay blocked for hours. Step 5 of 6 Four banks would wait for funds IN PROGRESS Insufficient settlement funds When a bank does not have enough funds DONE Bilateral queue offsetting If Bank A has a queued payment to Bank B DONE Such as those related to monetary Urgent payments DONE Bilateral offsetting pairs the first two and settles both using DONE Four banks Without it, the four banks would wait ACTIVE Audit trail cancellation with the user and the reason QUEUED Without it, the four banks would wait for funds that could only come from each other, and the queues would stay blocked for hours.
Audit trail must record every reorder PAYMENT OPERATIONS COMPLETE LIVE 01 Insufficient settlement funds - When a bank does not have enough funds DONE 02 Bilateral queue offsetting - If Bank A has a queued payment to Bank B DONE 03 Such as those related to monetary - Urgent payments DONE 04 Bilateral offsetting - pairs the first two and settles both using DONE 05 Four banks - Without it, the four banks would wait DONE 06 Audit trail - cancellation with the user and the reason ACTIVE The audit trail must record every reorder and cancellation with the user and the reason Step 6 of 6 Audit trail must record every reorder COMPLETE Insufficient settlement funds When a bank does not have enough funds DONE Bilateral queue offsetting If Bank A has a queued payment to Bank B DONE Such as those related to monetary Urgent payments DONE Bilateral offsetting pairs the first two and settles both using DONE Four banks Without it, the four banks would wait DONE Audit trail cancellation with the user and the reason ACTIVE The audit trail must record every reorder and cancellation with the user and the reason

Key points of this lesson, in order.

0:00 / 3:38 Step 1 of 6

Liquidity Saving Mechanisms and Queuing

Liquidity Management, Lesson 3 of 7, Narration 3:38, D07 Clearing, settlement and liquidity

LiquidityRejectQueue

What you will learn

Your objective. By the end of this lesson, you will be able to explain liquidity saving mechanisms and queuing. When a bank does not have enough funds to settle a payment immediately, the payment system does not necessarily reject it.

Why it matters. The analyst's job is to specify the rules that govern the queue, because the rules decide who waits and who does not.

Chapter objective: Learner manages intraday liquidity, explains funding sources, queues, and gridlock, and calculates a bank liquidity position from opening balance, inflows, outflows, and reserves. Learner applies this skill in realistic banking scenarios, with clear examples and correct terminology throughout.

Key learning points

  • Insufficient settlement funds
  • Bilateral queue offsetting
  • Such as those related to monetary policy
  • Bilateral offsetting net difference
  • Four banks would wait for funds
  • Audit trail must record every reorder

Key terms

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

Reject: A payment instruction that is refused before settlement because it fails validation, screening or account checks.

Queue: A holding area in a payment system where payments wait for sufficient funds or for their turn to settle.

Payment flow diagram showing Liquidity Saving Mechanisms and Queuing.

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

Scenario: you are a settlement analyst at a clearing system. Four banks have payment obligations to each other for today. Calculate the net settlement position for each bank under bilateral netting and under multilateral netting. Then state how much cash each bank must actually pay or will receive, and how much liquidity is saved by multilateral netting.

Obligations: Bank A owes Bank B EUR 120 million. Bank B owes Bank A EUR 95 million. Bank A owes Bank C EUR 40 million. Bank C owes Bank A EUR 30 million. Bank B owes Bank C EUR 60 million. Bank C owes Bank B EUR 25 million. Bank A owes Bank D EUR 15 million. Bank D owes Bank A EUR 10 million. Bank B owes Bank D EUR 20 million. Bank D owes Bank B EUR 5 million. Bank C owes Bank D EUR 35 million. Bank D owes Bank C EUR 30 million.

  1. What to do. Calculate each bank net position under bilateral netting (each pair netted separately) and under multilateral netting (each bank netted against the system as a whole). Show the arithmetic. Then state the total cash that moves under each method and the liquidity saved.

Correct result. Bilateral netting: A versus B: A owes 120, B owes 95, net A owes B 25. A versus C: A owes 40, C owes 30, net A owes C 10. A versus D: A owes 15, D owes 10, net A owes D 5. B versus C: B owes 60, C owes 25, net B owes C 35. B versus D: B owes 20, D owes 5, net B owes D 15. C versus D: C owes 35, D owes 30, net C owes D 5. Total cash that moves under bilateral netting: 25 plus 10 plus 5 plus 35 plus 15 plus 5 equals EUR 95 million. Multilateral netting: Bank A total owes 120 plus 40 plus 15 equals 175, total owed to A 95 plus 30 plus 10 equals 135, net A owes 40. Bank B total owes 95 plus 60 plus 20 equals 175, total owed to B 120 plus 25 plus 5 equals 150, net B owes 25. Bank C total owes 30 plus 25 plus 35 equals 90, total owed to C 40 plus 60 plus 30 equals 130, net C receives 40. Bank D total owes 10 plus 5 plus 30 equals 45, total owed to D 15 plus 20 plus 35 equals 70, net D receives 25. Total cash that moves under multilateral netting: A pays 40 plus B pays 25 equals EUR 65 million, and C receives 40 plus D receives 25 equals EUR 65 million. Liquidity saved: 95 minus 65 equals EUR 30 million. Worked reasoning: bilateral netting reduces the number of payments from 12 gross to 6 net, but each pair still settles separately. Multilateral netting reduces it further to 2 payments, because each bank settles only its net position against the system. The total net positions sum to zero, which is the check that the calculation is correct.

Why. Hint 1: for bilateral netting, net each pair separately and take the difference. Hint 2: for multilateral netting, sum all amounts each bank owes and all amounts owed to it, then take the difference. Hint 3: the net positions must sum to zero; if they do not, the arithmetic is wrong. The worked explanation shows the netting discipline: gross obligations are large, net obligations are small, and multilateral netting saves the most liquidity because it nets across all counterparties at once.

Check your understanding

Practice question

A bank payment queue is stuck: Bank A waits for funds from Bank B, and Bank B waits for funds from Bank A. What is this, and what resolves it?

Takeaway and next step

What to remember

The audit trail must record every reorder and cancellation with the user and the reason, because a bank that reorders its own payments to the front is delaying another bank's payments, and that needs to be visible.

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

Open the T2/TIPS Simulator →

Builds on "Intraday Liquidity and Central Bank Accounts".

Transcript and full text

Show transcript

When a bank does not have enough funds to settle a payment immediately, the payment system does not necessarily reject it. In most RTGS systems the payment enters a queue, where it waits until funds become available. Queuing is a basic liquidity saving mechanism, because it gives the bank time to receive incoming funds that can then be used to settle the queued payment. Without queuing, a payment that arrived a few minutes before a large incoming receipt would be rejected, even though the bank would have been able to pay it moments later. Modern systems go further with liquidity saving mechanisms that actively look for offsetting opportunities. If Bank A has a queued payment to Bank B, and Bank B has a queued payment to Bank A, the system can settle both at once, using only the net difference. This is called bilateral offsetting. Multilateral offsetting extends the same idea to a group of banks, finding a set of queued payments that can settle together with far less liquidity than settling them one by one. These mechanisms run continuously or at intervals, and they can resolve queues that would otherwise block the system for hours. Queuing also needs rules about order and priority. Most systems operate on a first in first out basis within each priority level, so that a payment cannot jump ahead of an earlier payment from the same bank. Urgent payments, such as those related to monetary policy or to another payment system, can be given a higher priority and settle first. Participants can also reorder or cancel queued payments, for example to prioritise a critical customer payment over a routine one. These controls give banks flexibility, but they also require careful governance so that one bank's reordering does not unfairly delay another bank's payments. See offsetting rescue a queue. At 10 in the morning the queue holds three payments. Bank A owes Bank B EUR 40 million, Bank B owes Bank A EUR 38 million, and Bank C owes Bank A EUR 25 million. Bilateral offsetting pairs the first two and settles both using only the EUR 2 million net difference. A multilateral run a little later takes all three together. Bank A is due EUR 25 million from Bank C and owes EUR 2 million net to Bank B, Bank B is due EUR 2 million, and Bank C pays EUR 25 million. The three payments settle with EUR 25 million of liquidity instead of EUR 103 million gross. Now take gridlock, where four banks each wait for the next one in a circle and none can pay first. The offsetting algorithm finds the circle and settles the whole group at once, using only the net differences. Without it, the four banks would wait for funds that could only come from each other, and the queues would stay blocked for hours. The analyst's job is to specify the rules that govern the queue, because the rules decide who waits and who does not. The requirements should state the ordering rule, usually first in first out within each priority level, which payments can jump the queue, such as those linked to monetary policy or to another payment system, and who is allowed to reorder or cancel a queued payment. The dashboard should show the queue depth, the oldest payment waiting, and the total value blocked, and it should raise an alert when a single payment has waited longer than an agreed threshold, say one hour. The audit trail must record every reorder and cancellation with the user and the reason, because a bank that reorders its own payments to the front is delaying another bank's payments, and that needs to be visible.

When a bank does not have enough funds to settle a payment immediately, the payment system does not necessarily reject it. In most RTGS systems the payment enters a queue, where it waits until funds become available. Queuing is a basic liquidity saving mechanism, because it gives the bank time to receive incoming funds that can then be used to settle the queued payment. Without queuing, a payment that arrived a few minutes before a large incoming receipt would be rejected, even though the bank would have been able to pay it moments later.

Modern systems go further with liquidity saving mechanisms that actively look for offsetting opportunities. If Bank A has a queued payment to Bank B, and Bank B has a queued payment to Bank A, the system can settle both at once, using only the net difference. This is called bilateral offsetting. Multilateral offsetting extends the same idea to a group of banks, finding a set of queued payments that can settle together with far less liquidity than settling them one by one. These mechanisms run continuously or at intervals, and they can resolve queues that would otherwise block the system for hours.

Queuing also needs rules about order and priority. Most systems operate on a first in first out basis within each priority level, so that a payment cannot jump ahead of an earlier payment from the same bank. Urgent payments, such as those related to monetary policy or to another payment system, can be given a higher priority and settle first. Participants can also reorder or cancel queued payments, for example to prioritise a critical customer payment over a routine one. These controls give banks flexibility, but they also require careful governance so that one bank's reordering does not unfairly delay another bank's payments.

See offsetting rescue a queue. At 10 in the morning the queue holds three payments. Bank A owes Bank B EUR 40 million, Bank B owes Bank A EUR 38 million, and Bank C owes Bank A EUR 25 million. Bilateral offsetting pairs the first two and settles both using only the EUR 2 million net difference. A multilateral run a little later takes all three together. Bank A is due EUR 25 million from Bank C and owes EUR 2 million net to Bank B, Bank B is due EUR 2 million, and Bank C pays EUR 25 million. The three payments settle with EUR 25 million of liquidity instead of EUR 103 million gross. Now take gridlock, where four banks each wait for the next one in a circle and none can pay first. The offsetting algorithm finds the circle and settles the whole group at once, using only the net differences. Without it, the four banks would wait for funds that could only come from each other, and the queues would stay blocked for hours.

The analyst's job is to specify the rules that govern the queue, because the rules decide who waits and who does not. The requirements should state the ordering rule, usually first in first out within each priority level, which payments can jump the queue, such as those linked to monetary policy or to another payment system, and who is allowed to reorder or cancel a queued payment. The dashboard should show the queue depth, the oldest payment waiting, and the total value blocked, and it should raise an alert when a single payment has waited longer than an agreed threshold, say one hour. The audit trail must record every reorder and cancellation with the user and the reason, because a bank that reorders its own payments to the front is delaying another bank's payments, and that needs to be visible.

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.