SEPA Instant: The Ten Second Rule and What It Breaks

The ten second limit is end to end, so every hop and every check shares one budget. Irrevocability is the deeper change: controls that used to run after settlement must now run before it or not at all. And 24/7/365 removes the batch window, which is an operating model change wearing technical clothing.

A bank builds instant payments and hits the ten second requirement comfortably in testing. Then screening takes four seconds on a name that needs review, and there is no queue to put the payment in, because a queue implies waiting and waiting is what the scheme removed.

That is the instant payments problem in one sentence. It is not throughput, and it is rarely raw latency. It is that removing time removes the place where most of banking’s controls used to live.

This continues the scheme track of The ISO 20022 Reference, after SEPA Credit Transfer.

What SCT Inst actually requires

Four properties, and each one breaks a different assumption.

Ten seconds, end to end. From the time of receipt of the payment order, which the 2025 rulebook pins to the AT-T056 timestamp with millisecond precision, to the confirmation coming back that the beneficiary has the funds. Not ten seconds per system: ten seconds for everything, including the network. The 2025 rulebook also tightened the sub-timelines inside that window to 5, 7, and 9 seconds (they were 10, 20, and 25).

24/7/365. No weekends, no bank holidays, no overnight window.

Irrevocable once credited. No unilateral unwind.

Confirmation to the originator. The originating bank learns, within the window, whether the beneficiary was credited.

The messages are the familiar ones. A pacs.008 carries the payment, a pacs.002 carries the status, and the scheme’s implementation guidelines constrain them exactly as the SCT rulebook does, on top of the same SEPA constraints: euro, IBAN, SLEV, restricted character set.

One evolution worth knowing: the scheme originally carried a per-payment amount ceiling, and the 2025 SCT Inst rulebook removed it, because the EU Instant Payments Regulation ((EU) 2024/886) leaves limits to the payer, who must be able to set their own. The Regulation also moved instant from an optional product to an obligation. Current as of October 2026: euro area banks have had to receive instant payments since 9 January 2025 and send them, at no higher price than a standard transfer, since 9 October 2025; euro area payment institutions and e-money institutions have until 9 April 2027, and PSPs in EU countries outside the euro area must receive by 9 January 2027 and send by 9 July 2027. The rulebook in effect is the 2025 SCT Inst rulebook version 1.2 (published 30 September 2026), built on the 2019 ISO 20022 message versions, and the next regular version is not expected before the end of the third quarter of 2028. Verify against the live rulebook, because these are exactly the parameters that move.

The latency budget is now a design artifact

Ten seconds end to end means each participant gets a fraction. In practice a bank’s internal budget is measured in hundreds of milliseconds, not seconds, because transmission, the clearing mechanism, and the counterparty all need their share.

That converts a non-functional requirement into a real design constraint. Write the budget down as a table and hold every component to its line:

Step	Budget
Inbound validation and format check	tens of ms
Fraud and limit checks	low hundreds of ms
Sanctions screening	low hundreds of ms
Liquidity and posting	tens of ms
Transmission and clearing	outside your control
Confirmation path	tens of ms

Then every synchronous dependency inside those steps consumes budget. A screening call that usually takes 80 milliseconds and occasionally takes 4 seconds is not a performance issue, it is a correctness issue, because the slow case produces a scheme breach.

This is where the non-functional requirements discipline stops being paperwork. “The system shall respond quickly” is useless here. “Screening returns a decision within 300 milliseconds at the 99.9th percentile, and a timeout at 300 milliseconds routes to the defined alternative path” is a specification you can test and a developer can build.

Note also that percentiles matter more than averages. At scheme volumes, the 99.9th percentile happens thousands of times a day, and every one of those is a customer.

Irrevocability is the real change

Traditional payment design assumes you can fix things afterwards. A payment settles, a control flags it later, and the money is recovered or adjusted. Whole operational functions exist on that assumption.

Instant payments remove it. Once the beneficiary is credited, the funds are theirs. Recovery means a recall request, which the beneficiary bank is not obliged to honour and which fails outright if the money has already moved on, which for a fraudulent beneficiary it certainly has.

The consequence for an analyst: every control must be re-examined for whether it runs before or after settlement. Anything that used to run after now has to run inside the window, or move to a different point in the flow, or be accepted as a residual risk with a named owner.

The controls that usually need this treatment:

• Sanctions screening.
• Fraud detection, which loses the option of holding a suspicious payment for review.
• Limit and mandate checking.
• Duplicate detection, which becomes urgent: a duplicate instant payment is irrecoverable in the same way.
• Any manual approval step, which simply cannot exist inside the window.

The last one is worth saying plainly to stakeholders who ask for a four-eyes check on instant payments. Human approval and ten seconds are incompatible. The product either does not offer instant for those payment types, or the approval moves to a pre-authorisation of the beneficiary rather than of the payment.

Screening inside the window

The hardest constraint, and the one that decides your architecture.

The traditional model tolerates a queue because payments can wait. Under SCT Inst there is no queue, so you get three options and must choose explicitly:

1. Fully automated real-time screening. Fast matching, tuned thresholds, automatic clearing of low-score matches. Requires confidence in the tuning, because there is no human safety net inside the window.

2. Reject on non-clearance. Anything not cleared automatically in time is rejected. Safe, and it produces a customer experience question: the rejection reason cannot disclose that screening was involved, so the customer receives an unhelpful message and contacts support.

3. Do not offer instant for higher-risk flows. Route them to standard SCT where a queue exists. Often the most honest answer, and it needs a product rule rather than a technical one.

One regulatory change narrows the problem for euro area banks. Article 5d of the amended SEPA Regulation replaces in-flight screening of payer and payee against EU targeted financial sanctions with screening of your own customer base, at least once every calendar day and immediately when a new listing takes effect. That does not remove obligations under other sanctions regimes your bank applies, or fraud and AML monitoring, so the in-window decision still exists for whatever your compliance function requires per transaction. Write down which checks run where, and why.

Whichever you choose, the submission set problem from sanctions screening on ISO 20022 still applies in full. Speed does not excuse screening the wrong parties, and under time pressure the temptation to trim the submission set is real and must be resisted explicitly in the specification.

24/7/365 is an operating model change

This is the part that surprises programmes, because it is not in the message specification at all.

Removing the overnight batch window means:

• Reconciliation runs continuously, against a moving position, rather than against a frozen end-of-day state. See reconciliation design for how the matching logic changes when there is no cut.
• End-of-day processing has to coexist with live settlement.
• Liquidity management becomes continuous. Funds must be available at three in the morning on a public holiday, which means either pre-funding a buffer or automated liquidity transfers. Someone owns that buffer, and its sizing is a real analysis task.
• Maintenance and deployment have no natural window. This forces zero-downtime deployment practices, which is a significant engineering investment that often is not in the programme’s budget because nobody traced it back to the scheme requirement.
• Support coverage is genuinely round the clock, with escalation paths that work at four on a Sunday morning.

When an analyst is asked to scope instant payments, these five items belong in the impact assessment alongside the message work. They are frequently larger than the message work. It is the same blast radius analysis that ISO 20022 migrations need, applied to a different trigger.

The failure paths are the specification

The happy path is ten seconds and a confirmation. The paths that need your attention are the others.

Timeout with no response. The originating bank does not know whether the beneficiary was credited. This is the genuinely hard state, because both possible truths require different actions. The rule since the 2025 rulebook is explicit: no confirmation at ten seconds means restore the originator’s account immediately and inform them, and a positive confirmation that arrives later means telling them the payment did go through. Specifying your side of that, including the ledger entries for the late success, is the single most valuable thing in this project. Include what the customer is told while the status is unknown, which is a real question with a bad default: telling them it failed, when it may have succeeded, produces duplicate payments.

Beneficiary bank rejects inside the window. Clean, and the originator must be told promptly with a mapped reason.

Beneficiary bank unreachable. Falls back to standard SCT, or fails, depending on your product rule. Decide it rather than discovering it.

Duplicate submitted. Must be caught before settlement, because after settlement it is irrecoverable. Idempotency stops being good practice and becomes a control. Idempotency testing covers proving it.

Test conditions that follow: a payment at the ten second boundary, a screening call that times out, a confirmation lost after the beneficiary was credited, a duplicate arriving one second after the original, a payment at three in the morning on a holiday, and a beneficiary bank that is unreachable. That last set is uncomfortable to build and it is where the real defects are.

The takeaway

SCT Inst gives you ten seconds end to end, shared across every hop, which turns a latency budget into a design artifact with a line per component and percentile targets rather than averages. Irrevocability is the deeper change: any control that relied on unwinding a settled payment has to move before settlement or be consciously accepted as residual risk.

Screening is where the constraint bites hardest, and there are only three honest answers: automate it fully, reject what cannot clear in time, or do not offer instant for those flows. And 24/7/365 quietly rewrites reconciliation, liquidity, deployment, and support, which is usually more work than the messaging.

Next: Verification of Payee, the check that now runs before the payment. The full map is on The ISO 20022 Reference.

Ahmed is a Senior Technical Business Analyst with 10+ years in banking and payments. He builds practical guides and tools for analysts at The Tech BA Toolkit.

Tags: SEPA, Instant Payments, ISO 20022, Systems Analysis, Banking