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 originating bank accepting the payment to the beneficiary bank confirming the funds are available. Not ten seconds per system: ten seconds for everything, including the network and the confirmation coming back.

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 that ceiling was removed as instant payments moved from an optional product to a regulated expectation across the euro area under the EU Instant Payments Regulation. Verify the current position in the live rulebook rather than from any article, including this one, because this is exactly the kind of parameter that moves.

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.

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 scheme defines an investigation and resolution mechanism, and specifying your side of it properly 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