Payments Academy
Instant payment in 10 seconds 1 NOW Instant payment in 10 seconds 2 Reservation and screening in seconds 3 TIPS settlement in central bank money 4 Failure at each second 5 Effects on bank customer and operations 6 Timeline test An instant payment is measured in seconds Step 1 of 6 Instant payment in 10 seconds 1 NOW Instant payment in 10 seconds 2 Reservation and screening in seconds 3 TIPS settlement in central bank money 4 Failure at each second 5 Effects on bank customer and operations 6 Timeline test An instant payment is measured in seconds Step 1 of 6
Reservation and screening in seconds 1 Instant payment in 10 seconds 2 NOW Reservation and screening in seconds 3 TIPS settlement in central bank money 4 Failure at each second 5 Effects on bank customer and operations 6 Timeline test At 10:00:02 the hub checks the customer balance and reserves EUR 4 Step 2 of 6 Reservation and screening in seconds 1 Instant payment in 10 seconds 2 NOW Reservation and screening in seconds 3 TIPS settlement in central bank money 4 Failure at each second 5 Effects on bank customer and operations 6 Timeline test At 10:00:02 the hub checks the customer balance and reserves EUR 4 Step 2 of 6
TIPS settlement in central bank money 1 Instant payment in 10 seconds 2 Reservation and screening in seconds 3 NOW TIPS settlement in central bank money 4 Failure at each second 5 Effects on bank customer and operations 6 Timeline test Bank A validates, screens, reserves and posts. Step 3 of 6 TIPS settlement in central bank money 1 Instant payment in 10 seconds 2 Reservation and screening in seconds 3 NOW TIPS settlement in central bank money 4 Failure at each second 5 Effects on bank customer and operations 6 Timeline test Bank A validates, screens, reserves and posts. Step 3 of 6
Failure at each second 1 Instant payment in 10 seconds 2 Reservation and screening in seconds 3 TIPS settlement in central bank money 4 NOW Failure at each second 5 Effects on bank customer and operations 6 Timeline test 002 with status RJCT and reason code AC04, and Bank A releases the reservation and tells the customer. Step 4 of 6 Failure at each second 1 Instant payment in 10 seconds 2 Reservation and screening in seconds 3 TIPS settlement in central bank money 4 NOW Failure at each second 5 Effects on bank customer and operations 6 Timeline test 002 with status RJCT and reason code AC04, and Bank A releases the reservation and tells the customer. Step 4 of 6
Effects on bank, customer and operations 1 Instant payment in 10 seconds 2 Reservation and screening in seconds 3 TIPS settlement in central bank money 4 Failure at each second 5 NOW Effects on bank customer and operations 6 Timeline test Ask what the system does at each second, what the customer sees, and what happens when the step fails. Step 5 of 6 Effects on bank, customer and operations 1 Instant payment in 10 seconds 2 Reservation and screening in seconds 3 TIPS settlement in central bank money 4 Failure at each second 5 NOW Effects on bank customer and operations 6 Timeline test Ask what the system does at each second, what the customer sees, and what happens when the step fails. Step 5 of 6
Timeline test for an instant product 1 Instant payment in 10 seconds 2 Reservation and screening in seconds 3 TIPS settlement in central bank money 4 Failure at each second 5 Effects on bank customer and operations 6 NOW Timeline test An instant payment that is not instant is a failed payment, and the failure must be visible, not hidden in a queue. Step 6 of 6 Timeline test for an instant product 1 Instant payment in 10 seconds 2 Reservation and screening in seconds 3 TIPS settlement in central bank money 4 Failure at each second 5 Effects on bank customer and operations 6 NOW Timeline test An instant payment that is not instant is a failed payment, and the failure must be visible, not hidden in a queue. Step 6 of 6

Flow of the explanation in this lesson.

0:00 / 8:08 Step 1 of 6

Minute-by-minute timeline for one instant payment

Lifecycle timelines and failure modes, Lesson 1 of 5, Narration 8:08, D03 Payment lifecycle

Execution datePayment hubSettlement

What you will learn

Your objective. By the end of this lesson, you will be able to explain minute-by-minute timeline for one instant payment and apply it to a real banking scenario.

Why it matters. Takeaway: an SCT Inst payment of EUR 4,500 moves from pain.001 to pacs.008 to pacs.002 with status ACCC in 10 seconds, with reservation, screening, TIPS settlement in central bank money, and a booking debit at the end.

Chapter objective: Minute-by-minute timelines for one instant, one batch and one cross-border payment

Key learning points

  • Instant payment in 10 seconds
  • Reservation and screening in seconds
  • TIPS settlement in central bank money
  • Failure at each second
  • Effects on bank, customer and operations
  • Timeline test for an instant product

Key terms

Execution date: The date on which the bank executes a payment instruction, debiting the debtor account and sending the message onward.

Payment hub: A central system in a bank that receives payment instructions from all channels, validates them, applies screening and routing rules, and sends them to the correct clearing system or correspondent.

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.

ISO 20022 XML explorer showing Minute-by-minute timeline for one instant payment.

Practise this lesson

Exercise

Trace the EUR 4,500 SCT Inst payment in this lesson second by second, from the pain.001 at 10:00:00 to the customer confirmation at 10:00:10.

Use the timeline: reservation, screening, pacs.008, TIPS reserve and settlement, pacs.002 with status ACCC.

  1. What to do. For each second state the actor, the message or posting, and the status, and state what happens if the step fails.

Correct result. 10:00:00 pain.001 submitted; 10:00:01 validated; 10:00:02 EUR 4,500 reserved; 10:00:03 screening and fraud checks clear; 10:00:04 pacs.008 sent; 10:00:05 TIPS receives and validates; 10:00:06 TIPS reserves; 10:00:07 Bank B accepts; 10:00:08 Bank B credits supplier and sends pacs.002 ACCC; 10:00:09 TIPS settles in central bank money; 10:00:10 Bank A posts the debit and confirms to the customer. A failure at any second rejects the payment and releases the reservation.

Why. An instant payment has a 10-second deadline, so every check must be automated and every failure must reject cleanly.

Check your understanding

Practice question

What is the maximum execution time for an SCT Inst payment under Regulation (EU) 2024/886?

Takeaway and next step

What to remember

Takeaway: an SCT Inst payment of EUR 4,500 moves from pain.001 to pacs.008 to pacs.002 with status ACCC in 10 seconds, with reservation, screening, TIPS settlement in central bank money, and a booking debit at the end.

Follow EUR 4,500 through every stage, from instruction to beneficiary credit, and note where it can stop.

Open the Payment Lifecycle Simulator →

Builds on "Value-date correction: camt.087 and camt.027".

Transcript and full text

Show transcript

An instant payment is measured in seconds, and the timeline below is for a real SCT Inst payment of EUR 4,500 from a customer of Bank A in Paris to a supplier at Bank B in Berlin, on Monday 9 November 2026, with the clock times as they would appear in the payment hub log. The payment must be executed within 10 seconds under Regulation (EU) 2024/886, and the SCT Inst rulebook maximum execution time is 10 seconds, so every step has a deadline in seconds, not minutes, and the timeline is written second by second. The messages are a pain.001 from the customer, a pacs.008 from Bank A, a pacs.002 status report from Bank B, and a camt.053 statement. Source: Regulation (EU) 2024/886; European Payments Council, SCT Inst Rulebook 2025, effective 5 October 2025; ISO 20022, pacs.008 and pacs.002. At 10:00:00 the customer submits a pain.001 payment initiation for EUR 4,500 to the supplier, with the supplier IBAN, the remittance reference for invoice INV-2026-1187, and the requested execution date of today. At 10:00:01 the Bank A channel validates the IBAN format and the amount, and the payment is accepted into the hub. At 10:00:02 the hub checks the customer balance and reserves EUR 4,500, so the available balance falls by EUR 4,500 while the ledger balance is unchanged, because the reservation is a non-booking hold. At 10:00:04 the hub creates a pacs.008 customer credit transfer, with the debtor, the creditor, the amount EUR 4,500, the currency, the end to end identifier and the remittance data, and sends it to the clearing system. At 10:00:05 the clearing system, TIPS, receives the pacs.008. At 10:00:06 TIPS reserves EUR 4,500 in the Bank A TIPS account, so Bank A cannot spend the same reserves twice, and forwards the pacs.008. At 10:00:07 Bank B receives the pacs.008. At 10:00:08 Bank B credits the supplier account EUR 4,500, so the supplier ledger balance rises, and Bank B sends a pacs.002. At 10:00:10 Bank A receives the pacs.002, posts the booking debit of EUR 4,500 to the customer account, releases the reservation, and sends a confirmation to the customer. The payment took 10 seconds from submission to confirmation, and the customer and the supplier both see the money. The parties and the systems that each step depends on are the customer, the Bank A channel and hub, the TIPS clearing system, and Bank B. Bank A validates, screens, reserves and posts. Bank B validates, credits and reports. If any one of these four fails, the payment fails, and the failure handling is defined by the SCT Inst rulebook: a payment that is not confirmed within 10 seconds is rejected, the reservation is released, and the customer is told the payment did not go through, so the customer can retry. The pacs.002 status codes are the evidence at each step: RCVD for received, ACTC for accepted, ACCP for accepted for customer payment, ACSC for settlement completed, and ACCC for creditor account credited, and RJCT for rejected, under ISO 20022. Failure at each second has a different cause and a different recovery. At 10:00:02, if the customer balance is insufficient, the payment is rejected immediately, no pacs.008 is sent, and the customer is told to fund the account. At 10:00:06, if TIPS cannot reserve, because Bank A has insufficient funds in its TIPS account, the payment is rejected, and treasury must fund the TIPS account. At 10:00:07, if Bank B rejects, because the creditor account is closed, Bank B sends a pacs.002 with status RJCT and reason code AC04, and Bank A releases the reservation and tells the customer. At 10:00:09, if settlement fails, the payment is not final, and the SCT Inst rulebook requires the payment to be rejected and the funds returned, not held in suspense. The effect on the bank, the customer and operations is that speed creates a new risk: there is no time to fix an error manually. For the customer, a 10-second payment that succeeds is a better experience than a next day payment, but a 10-second payment that fails without a clear reason is a worse experience, because the customer expected instant success. For the bank, the 10-second deadline means screening, fraud checks and liquidity must all be automated and must complete in milliseconds, and any manual step will cause a timeout. A business analyst must specify the timeout, the retry rule and the customer message for every second of the timeline. For a business analyst, product owner or subject matter expert, the test is to draw this timeline for any instant payment product and to name the message, the status, the posting and the deadline at each second. Ask what the system does at each second, what the customer sees, and what happens when the step fails. Ask how the reservation is released, how the pacs.002 is matched to the pacs.008, and how the settlement is proved in the camt.053 statement. Ask what the maximum execution time is under the scheme and the law, and how the bank proves it meets it. The SCT Inst rulebook and Regulation (EU) 2024/886 are the sources for the 10-second rule, and the ISO 20022 pacs.002 status code set is the source for the status codes, and both must be cited in the requirement. Two mistakes are common in instant payment design. The first is to promise instant credit to the customer before settlement, which creates a credit risk if the settlement then fails, because the bank has credited a customer for money it has not received. The second is to allow a manual review inside the 10-second window, which guarantees a timeout, because a human cannot review in seconds. The correct design is to automate every check, to reserve funds before sending, to settle in central bank money through TIPS, and to reject cleanly on timeout, with the reservation released and the customer told the payment did not go through. An instant payment that is not instant is a failed payment, and the failure must be visible, not hidden in a queue. Takeaway: an SCT Inst payment of EUR 4,500 moves from pain.001 to pacs.008 to pacs.002 with status ACCC in 10 seconds, with reservation, screening, TIPS settlement in central bank money, and a booking debit at the end. Every second has a deadline, a message, a status and a posting, and a failure at any second rejects the payment and releases the reservation. Further reading: Regulation (EU) 2024/886; European Payments Council, SCT Inst Rulebook 2025, effective 5 October 2025; ISO 20022, pacs.008 and pacs.002 message definitions. Last reviewed 7 November 2026.

An instant payment is measured in seconds, and the timeline below is for a real SCT Inst payment of EUR 4,500 from a customer of Bank A in Paris to a supplier at Bank B in Berlin, on Monday 9 November 2026, with the clock times as they would appear in the payment hub log. The payment must be executed within 10 seconds under Regulation (EU) 2024/886, and the SCT Inst rulebook maximum execution time is 10 seconds, so every step has a deadline in seconds, not minutes, and the timeline is written second by second. The messages are a pain.001 from the customer, a pacs.008 from Bank A, a pacs.002 status report from Bank B, and a camt.053 statement. Source: Regulation (EU) 2024/886; European Payments Council, SCT Inst Rulebook 2025, effective 5 October 2025; ISO 20022, pacs.008 and pacs.002.

At 10:00:00 the customer submits a pain.001 payment initiation for EUR 4,500 to the supplier, with the supplier IBAN, the remittance reference for invoice INV-2026-1187, and the requested execution date of today. At 10:00:01 the Bank A channel validates the IBAN format and the amount, and the payment is accepted into the hub. At 10:00:02 the hub checks the customer balance and reserves EUR 4,500, so the available balance falls by EUR 4,500 while the ledger balance is unchanged, because the reservation is a non-booking hold. At 10:00:04 the hub creates a pacs.008 customer credit transfer, with the debtor, the creditor, the amount EUR 4,500, the currency, the end to end identifier and the remittance data, and sends it to the clearing system.

At 10:00:05 the clearing system, TIPS, receives the pacs.008. At 10:00:06 TIPS reserves EUR 4,500 in the Bank A TIPS account, so Bank A cannot spend the same reserves twice, and forwards the pacs.008. At 10:00:07 Bank B receives the pacs.008. At 10:00:08 Bank B credits the supplier account EUR 4,500, so the supplier ledger balance rises, and Bank B sends a pacs.002. At 10:00:10 Bank A receives the pacs.002, posts the booking debit of EUR 4,500 to the customer account, releases the reservation, and sends a confirmation to the customer. The payment took 10 seconds from submission to confirmation, and the customer and the supplier both see the money.

The parties and the systems that each step depends on are the customer, the Bank A channel and hub, the TIPS clearing system, and Bank B. Bank A validates, screens, reserves and posts. Bank B validates, credits and reports. If any one of these four fails, the payment fails, and the failure handling is defined by the SCT Inst rulebook: a payment that is not confirmed within 10 seconds is rejected, the reservation is released, and the customer is told the payment did not go through, so the customer can retry. The pacs.002 status codes are the evidence at each step: RCVD for received, ACTC for accepted, ACCP for accepted for customer payment, ACSC for settlement completed, and ACCC for creditor account credited, and RJCT for rejected, under ISO 20022.

Failure at each second has a different cause and a different recovery. At 10:00:02, if the customer balance is insufficient, the payment is rejected immediately, no pacs.008 is sent, and the customer is told to fund the account. At 10:00:06, if TIPS cannot reserve, because Bank A has insufficient funds in its TIPS account, the payment is rejected, and treasury must fund the TIPS account. At 10:00:07, if Bank B rejects, because the creditor account is closed, Bank B sends a pacs.002 with status RJCT and reason code AC04, and Bank A releases the reservation and tells the customer. At 10:00:09, if settlement fails, the payment is not final, and the SCT Inst rulebook requires the payment to be rejected and the funds returned, not held in suspense.

The effect on the bank, the customer and operations is that speed creates a new risk: there is no time to fix an error manually. For the customer, a 10-second payment that succeeds is a better experience than a next day payment, but a 10-second payment that fails without a clear reason is a worse experience, because the customer expected instant success. For the bank, the 10-second deadline means screening, fraud checks and liquidity must all be automated and must complete in milliseconds, and any manual step will cause a timeout. A business analyst must specify the timeout, the retry rule and the customer message for every second of the timeline.

For a business analyst, product owner or subject matter expert, the test is to draw this timeline for any instant payment product and to name the message, the status, the posting and the deadline at each second. Ask what the system does at each second, what the customer sees, and what happens when the step fails. Ask how the reservation is released, how the pacs.002 is matched to the pacs.008, and how the settlement is proved in the camt.053 statement. Ask what the maximum execution time is under the scheme and the law, and how the bank proves it meets it. The SCT Inst rulebook and Regulation (EU) 2024/886 are the sources for the 10-second rule, and the ISO 20022 pacs.002 status code set is the source for the status codes, and both must be cited in the requirement.

Two mistakes are common in instant payment design. The first is to promise instant credit to the customer before settlement, which creates a credit risk if the settlement then fails, because the bank has credited a customer for money it has not received. The second is to allow a manual review inside the 10-second window, which guarantees a timeout, because a human cannot review in seconds. The correct design is to automate every check, to reserve funds before sending, to settle in central bank money through TIPS, and to reject cleanly on timeout, with the reservation released and the customer told the payment did not go through. An instant payment that is not instant is a failed payment, and the failure must be visible, not hidden in a queue.

Takeaway: an SCT Inst payment of EUR 4,500 moves from pain.001 to pacs.008 to pacs.002 with status ACCC in 10 seconds, with reservation, screening, TIPS settlement in central bank money, and a booking debit at the end. Every second has a deadline, a message, a status and a posting, and a failure at any second rejects the payment and releases the reservation. Further reading: Regulation (EU) 2024/886; European Payments Council, SCT Inst Rulebook 2025, effective 5 October 2025; ISO 20022, pacs.008 and pacs.002 message definitions. Last reviewed 7 November 2026.

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.