Payments Training Hub
Routing: decision about how payment 1 Routing NOW 2 Route choice priority 3 Clearing and settlement 4 Instruction 5 Treasury team Routing is the decision about how a payment leaves the bank and reaches the beneficiary. Step 1 of 5 Routing: decision about how payment 1 NOW Routing 2 Route choice priority 3 Clearing and settlement 4 Instruction 5 Treasury team Routing is the decision about how a payment leaves the bank and reaches the beneficiary. Step 1 of 5
Route choice priority 1 Routing 2 Route choice priority NOW 3 Clearing and settlement 4 Instruction 5 Treasury team Some payments have a choice of routes, and the routing table defines the priority, for example preferring the cheapest route that meets the value date, or preferring the fastest route for Step 2 of 5 Route choice priority 1 Routing 2 NOW Route choice priority 3 Clearing and settlement 4 Instruction 5 Treasury team Some payments have a choice of routes, and the routing table defines the priority, for example preferring the cheapest route that meets the value date, or preferring the fastest route for Step 2 of 5
Clearing and settlement 1 Routing 2 Route choice priority 3 Clearing and settlement NOW 4 Instruction 5 Treasury team Clearing and settlement are the steps where the payment actually moves value. Step 3 of 5 Clearing and settlement 1 Routing 2 Route choice priority 3 NOW Clearing and settlement 4 Instruction 5 Treasury team Clearing and settlement are the steps where the payment actually moves value. Step 3 of 5
Instruction travels through the SWIFT network 1 Routing 2 Route choice priority 3 Clearing and settlement 4 Instruction NOW 5 Treasury team For SWIFT payments, the instruction travels through the SWIFT network, and settlement happens through correspondent accounts, where banks hold balances with each other. Step 4 of 5 Instruction travels through the SWIFT network 1 Routing 2 Route choice priority 3 Clearing and settlement 4 NOW Instruction 5 Treasury team For SWIFT payments, the instruction travels through the SWIFT network, and settlement happens through correspondent accounts, where banks hold balances with each other. Step 4 of 5
Treasury team monitors settlement account balances 1 Routing 2 Route choice priority 3 Clearing and settlement 4 Instruction 5 Treasury team NOW The treasury team monitors settlement account balances and moves funds between accounts to cover expected outflows. Step 5 of 5 Treasury team monitors settlement account balances 1 Routing 2 Route choice priority 3 Clearing and settlement 4 Instruction 5 NOW Treasury team The treasury team monitors settlement account balances and moves funds between accounts to cover expected outflows. Step 5 of 5

Steps of this lesson, in order.

0:00 / 2:14 Step 1 of 5

Routing, Clearing and Settlement

Payment Hub Architecture, Lesson 5 of 8, Narration 2:14, D09 Payment architecture and technology

SettlementValue dateLiquidity

What you will learn

Your objective. By the end of this lesson, you will be able to explain routing, clearing and settlement. Routing is the decision about how a payment leaves the bank and reaches the beneficiary.

Why it matters. The hub's settlement handling also covers liquidity management, because the bank needs enough funds in the right accounts to settle its payments.

Chapter objective: Learner designs a payment hub architecture, explaining intake, validation, routing, transformation, screening, and settlement modules, and maps a payment through each module. Learner applies this skill in realistic banking scenarios, with clear examples and correct terminology throughout.

Key learning points

  • Routing: decision about how payment
  • Route choice priority
  • Clearing and settlement
  • Instruction travels through the SWIFT network
  • Treasury team monitors settlement account balances

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.

Value date: The date on which funds become available to the beneficiary and on which interest starts to accrue. It is the date used for settlement and for nostro posting.

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

Banking architecture diagram showing Routing, Clearing and Settlement.

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

Work out the net settlement position for the clearing cycle described in this lesson.

Use the clearing rules and the netting logic in this lesson.

  1. What to do. List the payments in the cycle, calculate the net position for each bank, and state what settles.

Correct result. Clearing validates, sorts, matches and nets the instructions, then produces a net position per bank. Only the net position settles, which needs far less liquidity than settling every payment individually.

Why. Netting is what makes high volume payments possible. Without it, every payment would need full liquidity at the moment it is sent.

Check your understanding

Practice question

Which of the following best describes routing, clearing and settlement?

Takeaway and next step

What to remember

Requirements in this area cover routing rules, cut off handling, settlement account selection, and the status updates that flow back to the customer, because a customer who can see that their payment has been delivered is far less likely to call the bank.

Send a payment through the hub and watch it pass each component named in this lesson.

Open the Payment Hub Architecture Simulator →

Builds on "Fraud, Sanctions and Compliance Services".

Transcript and full text

Show transcript

Routing is the decision about how a payment leaves the bank and reaches the beneficiary. The routing service looks at the payment type, the currency, the destination country, the value, the urgency and the cost, and selects the best clearing route. A domestic payment might go through the local real time system, a European payment might go through SEPA, and a cross border payment might go through SWIFT gpi or a correspondent bank. Some payments have a choice of routes, and the routing table defines the priority, for example preferring the cheapest route that meets the value date, or preferring the fastest route for urgent payments. Routing tables are configuration, not code, so operations can change them without a software release, which is essential when a clearing system changes its rules or a correspondent bank changes its pricing. Clearing and settlement are the steps where the payment actually moves value. Clearing is the exchange of payment instructions between banks, and settlement is the movement of money between their accounts, usually at the central bank. In a real time system, clearing and settlement happen together in seconds. In a batch system, instructions are exchanged during the day and settled at defined times. For SWIFT payments, the instruction travels through the SWIFT network, and settlement happens through correspondent accounts, where banks hold balances with each other. The hub must track the payment's status through each of these steps, so that operations can see whether a payment is still with the bank, with the clearing system, or already delivered to the beneficiary. The hub's settlement handling also covers liquidity management, because the bank needs enough funds in the right accounts to settle its payments. The treasury team monitors settlement account balances and moves funds between accounts to cover expected outflows. A BA working on routing should understand the trade offs between speed, cost and risk that drive routing decisions, and should be able to explain why a particular payment took a particular route. Requirements in this area cover routing rules, cut off handling, settlement account selection, and the status updates that flow back to the customer, because a customer who can see that their payment has been delivered is far less likely to call the bank. A worked example shows routing in action. A payment of GBP 450,000 for a property purchase is instructed at 14:30 on a Friday. The routing table reads the currency (GBP), the amount (above the Faster Payments limit of GBP 1 million? No, GBP 450,000 is below the limit, but the customer requested CHAPS because the solicitor requires same day guaranteed settlement), the value date (today), and the product (CHAPS). The engine routes the payment to CHAPS, debits the customer account, and sends the payment to the Bank of England. The payment settles at 15:12 and the solicitor confirms receipt. The same payment instructed at 17:30, after the CHAPS cut off, would be held for the next working day, and the customer would be told the payment will settle on Monday. The routing decision depends on the amount, the currency, the value date, the product, and the time of day, and a business analyst must specify the rule for each combination. A failure scenario tests the routing fallback. The CHAPS system is unavailable for 30 minutes due to a Bank of England outage. A payment of GBP 800,000 that was routed to CHAPS cannot be sent. The engine checks the fallback rules: the payment is below the Faster Payments limit of GBP 1 million, so it can be routed to Faster Payments instead, but the customer requested CHAPS for guaranteed same day settlement and Faster Payments does not guarantee it in the same way. The engine therefore holds the payment and alerts the operations team, who contact the customer and offer a choice: wait for CHAPS to recover, or send by Faster Payments now. The customer chooses to wait. The engine records the decision and the reason. A routing fallback that is automatic without customer consent is a defect; a fallback that is recorded and agreed is a control. Last reviewed 7 November 2026. Further reading: Bank of England CHAPS operating hours and contingency; Pay.UK Faster Payments scheme rules. Take a payment of EUR 25,000 from a German company to a supplier in France, submitted at 14:00 on a Tuesday. The routing table offers two routes: SEPA Credit Transfer, which settles the next business day through STEP2 and costs EUR 0.30, and SCT Inst, which settles in seconds through TIPS and costs EUR 0.50. The customer asked for same day value, so the routing service picks SCT Inst, sends a pacs.008 to TIPS, and the supplier is credited within 10 seconds. If the customer had asked for the cheapest route, the same payment would have gone as a standard SCT, the supplier would have been credited on Wednesday, and the bank would have saved EUR 0.20. The routing decision is therefore a trade off between speed and cost, and the table must record which factor won and why. When a route fails, the hub must decide quickly. Suppose the SEPA route is down for maintenance and a payment of EUR 100,000 is due to settle today. The routing service can try the next route in the table, such as a correspondent bank payment through SWIFT, but that route costs more, takes longer, and may need different message fields. The hub must either reroute automatically and tell the customer about the delay and the extra charge, or hold the payment and alert operations. The wrong choice is to silently drop the payment or to send it down a route the customer did not agree to. A BA should define the fallback order for each payment type and the customer message for each fallback, because a rerouted payment is a changed promise. Routing requirements are configuration, and the BA owns the configuration data. The routing table needs a row for each combination of payment type, currency, destination, value band and urgency, and each row needs a primary route, a fallback route, a cut off time, a value date rule and a charge. The BA should also specify how routing is tested: a payment just below a value threshold, a payment just above it, a payment submitted one minute before cut off, and a payment submitted one minute after. Those four cases catch most routing errors, and they are the cases that go wrong in production when they are not tested.

Routing is the decision about how a payment leaves the bank and reaches the beneficiary. The routing service looks at the payment type, the currency, the destination country, the value, the urgency and the cost, and selects the best clearing route. A domestic payment might go through the local real time system, a European payment might go through SEPA, and a cross border payment might go through SWIFT gpi or a correspondent bank. Some payments have a choice of routes, and the routing table defines the priority, for example preferring the cheapest route that meets the value date, or preferring the fastest route for urgent payments. Routing tables are configuration, not code, so operations can change them without a software release, which is essential when a clearing system changes its rules or a correspondent bank changes its pricing.

Clearing and settlement are the steps where the payment actually moves value. Clearing is the exchange of payment instructions between banks, and settlement is the movement of money between their accounts, usually at the central bank. In a real time system, clearing and settlement happen together in seconds. In a batch system, instructions are exchanged during the day and settled at defined times. For SWIFT payments, the instruction travels through the SWIFT network, and settlement happens through correspondent accounts, where banks hold balances with each other. The hub must track the payment's status through each of these steps, so that operations can see whether a payment is still with the bank, with the clearing system, or already delivered to the beneficiary.

The hub's settlement handling also covers liquidity management, because the bank needs enough funds in the right accounts to settle its payments. The treasury team monitors settlement account balances and moves funds between accounts to cover expected outflows. A BA working on routing should understand the trade offs between speed, cost and risk that drive routing decisions, and should be able to explain why a particular payment took a particular route. Requirements in this area cover routing rules, cut off handling, settlement account selection, and the status updates that flow back to the customer, because a customer who can see that their payment has been delivered is far less likely to call the bank.

A worked example shows routing in action. A payment of GBP 450,000 for a property purchase is instructed at 14:30 on a Friday. The routing table reads the currency (GBP), the amount (above the Faster Payments limit of GBP 1 million? No, GBP 450,000 is below the limit, but the customer requested CHAPS because the solicitor requires same day guaranteed settlement), the value date (today), and the product (CHAPS). The engine routes the payment to CHAPS, debits the customer account, and sends the payment to the Bank of England. The payment settles at 15:12 and the solicitor confirms receipt. The same payment instructed at 17:30, after the CHAPS cut off, would be held for the next working day, and the customer would be told the payment will settle on Monday. The routing decision depends on the amount, the currency, the value date, the product, and the time of day, and a business analyst must specify the rule for each combination.

A failure scenario tests the routing fallback. The CHAPS system is unavailable for 30 minutes due to a Bank of England outage. A payment of GBP 800,000 that was routed to CHAPS cannot be sent. The engine checks the fallback rules: the payment is below the Faster Payments limit of GBP 1 million, so it can be routed to Faster Payments instead, but the customer requested CHAPS for guaranteed same day settlement and Faster Payments does not guarantee it in the same way. The engine therefore holds the payment and alerts the operations team, who contact the customer and offer a choice: wait for CHAPS to recover, or send by Faster Payments now. The customer chooses to wait. The engine records the decision and the reason. A routing fallback that is automatic without customer consent is a defect; a fallback that is recorded and agreed is a control. Last reviewed 7 November 2026. Further reading: Bank of England CHAPS operating hours and contingency; Pay.UK Faster Payments scheme rules.

Take a payment of EUR 25,000 from a German company to a supplier in France, submitted at 14:00 on a Tuesday. The routing table offers two routes: SEPA Credit Transfer, which settles the next business day through STEP2 and costs EUR 0.30, and SCT Inst, which settles in seconds through TIPS and costs EUR 0.50. The customer asked for same day value, so the routing service picks SCT Inst, sends a pacs.008 to TIPS, and the supplier is credited within 10 seconds. If the customer had asked for the cheapest route, the same payment would have gone as a standard SCT, the supplier would have been credited on Wednesday, and the bank would have saved EUR 0.20. The routing decision is therefore a trade off between speed and cost, and the table must record which factor won and why.

When a route fails, the hub must decide quickly. Suppose the SEPA route is down for maintenance and a payment of EUR 100,000 is due to settle today. The routing service can try the next route in the table, such as a correspondent bank payment through SWIFT, but that route costs more, takes longer, and may need different message fields. The hub must either reroute automatically and tell the customer about the delay and the extra charge, or hold the payment and alert operations. The wrong choice is to silently drop the payment or to send it down a route the customer did not agree to. A BA should define the fallback order for each payment type and the customer message for each fallback, because a rerouted payment is a changed promise.

Routing requirements are configuration, and the BA owns the configuration data. The routing table needs a row for each combination of payment type, currency, destination, value band and urgency, and each row needs a primary route, a fallback route, a cut off time, a value date rule and a charge. The BA should also specify how routing is tested: a payment just below a value threshold, a payment just above it, a payment submitted one minute before cut off, and a payment submitted one minute after. Those four cases catch most routing errors, and they are the cases that go wrong in production when they are not tested.

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.