Payments Academy
Real-time payment PAYMENT OPERATIONS STARTED LIVE 01 Real-time payment - moves from the sender account ACTIVE 02 Defining feature - not speed alone QUEUED 03 Real-time processing - validates it alone QUEUED 04 Party - If any party is slow QUEUED 05 Banks therefore invest heavily in confirmation - payee checks, which match QUEUED 06 Continuous operation architecture - Banks design for continuous operation QUEUED A real-time payment is a payment that moves from the sender account to the receiver account within seconds, with confirmation returned to the sender in the same session. Step 1 of 6 Real-time payment STARTED Real-time payment moves from the sender account ACTIVE Defining feature not speed alone QUEUED Real-time processing validates it alone QUEUED Party If any party is slow QUEUED Banks therefore invest heavily in confirmation payee checks, which match the account QUEUED Continuous operation architecture Banks design for continuous operation QUEUED A real-time payment is a payment that moves from the sender account to the receiver account within seconds, with confirmation returned to the sender in the same session.
Defining feature PAYMENT OPERATIONS IN PROGRESS LIVE 01 Real-time payment - moves from the sender account DONE 02 Defining feature - not speed alone ACTIVE 03 Real-time processing - validates it alone QUEUED 04 Party - If any party is slow QUEUED 05 Banks therefore invest heavily in confirmation - payee checks, which match QUEUED 06 Continuous operation architecture - Banks design for continuous operation QUEUED The defining feature is not speed alone, but the combination of speed, finality, and immediate confirmation for both parties. Step 2 of 6 Defining feature IN PROGRESS Real-time payment moves from the sender account DONE Defining feature not speed alone ACTIVE Real-time processing validates it alone QUEUED Party If any party is slow QUEUED Banks therefore invest heavily in confirmation payee checks, which match the account QUEUED Continuous operation architecture Banks design for continuous operation QUEUED The defining feature is not speed alone, but the combination of speed, finality, and immediate confirmation for both parties.
Real-time processing handles each instruction individually PAYMENT OPERATIONS IN PROGRESS LIVE 01 Real-time payment - moves from the sender account DONE 02 Defining feature - not speed alone DONE 03 Real-time processing - validates it alone ACTIVE 04 Party - If any party is slow QUEUED 05 Banks therefore invest heavily in confirmation - payee checks, which match QUEUED 06 Continuous operation architecture - Banks design for continuous operation QUEUED Real-time processing handles each instruction individually, validates it alone, and settles it alone, which means the system cannot hide a slow item inside a large file. Step 3 of 6 Real-time processing handles each instruction individually IN PROGRESS Real-time payment moves from the sender account DONE Defining feature not speed alone DONE Real-time processing validates it alone ACTIVE Party If any party is slow QUEUED Banks therefore invest heavily in confirmation payee checks, which match the account QUEUED Continuous operation architecture Banks design for continuous operation QUEUED Real-time processing handles each instruction individually, validates it alone, and settles it alone, which means the system cannot hide a slow item inside a large file.
Party: slow PAYMENT OPERATIONS IN PROGRESS LIVE 01 Real-time payment - moves from the sender account DONE 02 Defining feature - not speed alone DONE 03 Real-time processing - validates it alone DONE 04 Party - If any party is slow ACTIVE 05 Banks therefore invest heavily in confirmation - payee checks, which match QUEUED 06 Continuous operation architecture - Banks design for continuous operation QUEUED If any party is slow, the whole payment breaches its service level. Step 4 of 6 Party: slow IN PROGRESS Real-time payment moves from the sender account DONE Defining feature not speed alone DONE Real-time processing validates it alone DONE Party If any party is slow ACTIVE Banks therefore invest heavily in confirmation payee checks, which match the account QUEUED Continuous operation architecture Banks design for continuous operation QUEUED If any party is slow, the whole payment breaches its service level.
Banks therefore invest heavily in confirmation PAYMENT OPERATIONS IN PROGRESS LIVE 01 Real-time payment - moves from the sender account DONE 02 Defining feature - not speed alone DONE 03 Real-time processing - validates it alone DONE 04 Party - If any party is slow DONE 05 Banks therefore invest heavily in confirmation - payee checks, which match ACTIVE 06 Continuous operation architecture - Banks design for continuous operation QUEUED Banks therefore invest heavily in confirmation of payee checks, which match the account name before the payment is sent. Step 5 of 6 Banks therefore invest heavily in confirmation IN PROGRESS Real-time payment moves from the sender account DONE Defining feature not speed alone DONE Real-time processing validates it alone DONE Party If any party is slow DONE Banks therefore invest heavily in confirmation payee checks, which match the account ACTIVE Continuous operation architecture Banks design for continuous operation QUEUED Banks therefore invest heavily in confirmation of payee checks, which match the account name before the payment is sent.
Continuous operation architecture PAYMENT OPERATIONS COMPLETE LIVE 01 Real-time payment - moves from the sender account DONE 02 Defining feature - not speed alone DONE 03 Real-time processing - validates it alone DONE 04 Party - If any party is slow DONE 05 Banks therefore invest heavily in confirmation - payee checks, which match DONE 06 Continuous operation architecture - Banks design for continuous operation ACTIVE Banks design for continuous operation with redundant data centres, automated failover, and health checks that run every few seconds. Step 6 of 6 Continuous operation architecture COMPLETE Real-time payment moves from the sender account DONE Defining feature not speed alone DONE Real-time processing validates it alone DONE Party If any party is slow DONE Banks therefore invest heavily in confirmation payee checks, which match the account DONE Continuous operation architecture Banks design for continuous operation ACTIVE Banks design for continuous operation with redundant data centres, automated failover, and health checks that run every few seconds.

Key points of this lesson, in order.

0:00 / 3:18 Step 1 of 6

What Real-Time Really Means

Real-Time Payments Architecture, Lesson 1 of 7, Narration 3:18, D05 Domestic payment systems

FinalityClearingScheme

What you will learn

Your objective. By the end of this lesson, you will be able to explain real-time really means. A real-time payment is a payment that moves from the sender account to the receiver account within seconds, with confirmation returned to the sender in the same session.

Why it matters. A customer who sends EUR 1,000 to the wrong account in a SEPA Instant payment cannot recall it through the scheme in the same way as a standard transfer.

Chapter objective: Learner designs real-time payments architecture, covering 24 by 7 availability, instant clearing, liquidity, and failure handling, and explains how it differs from batch systems. Learner applies this skill in realistic banking scenarios, with clear examples and correct terminology throughout.

Key learning points

  • Real-time payment
  • Defining feature
  • Real-time processing handles each instruction individually
  • Party: slow
  • Banks therefore invest heavily in confirmation
  • Continuous operation architecture

Key terms

Finality: The point at which a payment settlement becomes irrevocable and unconditional, so it cannot be reversed by the payer or the system.

Clearing: The process of exchanging payment instructions between banks and calculating what each bank owes the others.

Scheme: A card or payment network that sets the rules, standards and fees for transactions between issuers and acquirers.

Banking architecture diagram showing What Real-Time Really Means.

Practise this lesson

Exercise

Work out what the beneficiary receives for a GBP 250 payment under OUR, SHA and BEN.

Use the charge arrangement rules in this lesson and the correspondent and beneficiary bank fees named in the lesson.

  1. What to do. Calculate the amount credited under each of the three arrangements and state who pays each fee.

Correct result. Under OUR the sender pays all charges and the beneficiary receives the full amount. Under SHA the sender pays the sending charges and the beneficiary pays the receiving charges. Under BEN the beneficiary pays all charges and receives the amount less all fees.

Why. The charge arrangement decides who pays and how much arrives. A customer who was promised the full amount and receives less will complain, and the complaint lands on the analyst.

Check your understanding

Practice question

Why do real time payment systems need 24 hour operation and immediate fraud checks?

Takeaway and next step

What to remember

A single hour of downtime can block millions of payments, so availability targets are often set at 99.99 percent, which allows less than one hour of unplanned outage in an entire year.

Follow GBP 250 through every stage, from instruction to beneficiary credit, and note where it can stop.

Open the Payment Lifecycle Simulator →

Now in Domain 03, Global Payment Rails. Builds on ch11, SCT Inst: instant euro payments, and on ch9 and ch12 for UPI, IMPS and Faster Payments. This chapter is the architecture view of real-time payments, not a rail introduction.

Transcript and full text

Show transcript

A real-time payment is a payment that moves from the sender account to the receiver account within seconds, with confirmation returned to the sender in the same session. The payer does not wait until the next business day, and the payee can use the funds immediately. In the United Kingdom, Faster Payments typically credits a GBP 250 transfer in under ten seconds. In India, UPI routinely settles an INR 5,000 person-to-person payment in about five seconds. In the United States, FedNow targets completion within seconds, twenty-four hours a day. The defining feature is not speed alone, but the combination of speed, finality, and immediate confirmation for both parties. Real-time differs from traditional batch payments in almost every operational respect. A batch file sent through Bacs in the United Kingdom takes three working days, while a CHAPS payment settles the same day but only during business hours. A SEPA credit transfer in Europe historically took one business day, while SEPA Instant Credit Transfer must complete within ten seconds. Batch processing groups thousands of instructions, validates them together, and settles them in a single net position. Real-time processing handles each instruction individually, validates it alone, and settles it alone, which means the system cannot hide a slow item inside a large file. Three parties share responsibility for every instant payment, and each one must perform inside a strict time budget. The sender bank validates the instruction, checks the balance, screens the payment, and debits the account. The scheme or clearing system routes the message, applies its own rules, and forwards it to the receiver bank. The receiver bank validates the beneficiary account, runs its own checks, and credits the funds. If any party is slow, the whole payment breaches its service level. A typical budget allows about five seconds for the sender, five seconds for the scheme, and five seconds for the receiver, with the remainder reserved for network travel. Finality is the second defining feature, and it changes how banks handle risk. Once a real-time payment is credited, the receiver bank cannot reverse it simply because the sender made a mistake. A customer who sends EUR 1,000 to the wrong account in a SEPA Instant payment cannot recall it through the scheme in the same way as a standard transfer. Banks therefore invest heavily in confirmation of payee checks, which match the account name before the payment is sent. In the United Kingdom, a mismatch warning gives the payer a chance to stop a GBP 2,000 payment to a mistyped account before the money leaves. Availability is the third defining feature, and it is the hardest to deliver. A real-time system must work at three in the morning on a public holiday, when no operations team is watching and no batch window is open. There is no overnight pause for maintenance, no end-of-day cutoff, and no weekend shutdown. Banks design for continuous operation with redundant data centres, automated failover, and health checks that run every few seconds. A single hour of downtime can block millions of payments, so availability targets are often set at 99.99 percent, which allows less than one hour of unplanned outage in an entire year.

A real-time payment is a payment that moves from the sender account to the receiver account within seconds, with confirmation returned to the sender in the same session. The payer does not wait until the next business day, and the payee can use the funds immediately. In the United Kingdom, Faster Payments typically credits a GBP 250 transfer in under ten seconds. In India, UPI routinely settles an INR 5,000 person-to-person payment in about five seconds. In the United States, FedNow targets completion within seconds, twenty-four hours a day. The defining feature is not speed alone, but the combination of speed, finality, and immediate confirmation for both parties.

Real-time differs from traditional batch payments in almost every operational respect. A batch file sent through Bacs in the United Kingdom takes three working days, while a CHAPS payment settles the same day but only during business hours. A SEPA credit transfer in Europe historically took one business day, while SEPA Instant Credit Transfer must complete within ten seconds. Batch processing groups thousands of instructions, validates them together, and settles them in a single net position. Real-time processing handles each instruction individually, validates it alone, and settles it alone, which means the system cannot hide a slow item inside a large file.

Three parties share responsibility for every instant payment, and each one must perform inside a strict time budget. The sender bank validates the instruction, checks the balance, screens the payment, and debits the account. The scheme or clearing system routes the message, applies its own rules, and forwards it to the receiver bank. The receiver bank validates the beneficiary account, runs its own checks, and credits the funds. If any party is slow, the whole payment breaches its service level. A typical budget allows about five seconds for the sender, five seconds for the scheme, and five seconds for the receiver, with the remainder reserved for network travel.

Finality is the second defining feature, and it changes how banks handle risk. Once a real-time payment is credited, the receiver bank cannot reverse it simply because the sender made a mistake. A customer who sends EUR 1,000 to the wrong account in a SEPA Instant payment cannot recall it through the scheme in the same way as a standard transfer. Banks therefore invest heavily in confirmation of payee checks, which match the account name before the payment is sent. In the United Kingdom, a mismatch warning gives the payer a chance to stop a GBP 2,000 payment to a mistyped account before the money leaves.

Availability is the third defining feature, and it is the hardest to deliver. A real-time system must work at three in the morning on a public holiday, when no operations team is watching and no batch window is open. There is no overnight pause for maintenance, no end-of-day cutoff, and no weekend shutdown. Banks design for continuous operation with redundant data centres, automated failover, and health checks that run every few seconds. A single hour of downtime can block millions of payments, so availability targets are often set at 99.99 percent, which allows less than one hour of unplanned outage in an entire year.

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.