Instant Payments at Scale

Euro-area PSPs crossed the two hardest SEPA Instant deadlines already, receiving by January 2025, sending and Verification of Payee by October 2025. For banks in the six non-euro EU states still ahead of the April 2027 deadline- Romania among them, that's not history, it's a runway, and the infrastructure lessons from banks that already crossed the line are worth having before the clock starts, not after. 

The 10-second window is a systems design constraint, not a target 

The regulation's headline number — funds available to the payee, or the transaction cancelled, within 10 seconds — reads like a performance goal a team optimizes toward over time. It isn't. It's a hard budget every synchronous call in the payment path has to fit inside, together, on every single transaction, with no averaging out over a slow week. A payment that clears in 10.3 seconds isn't 97% compliant. It's a failed instant payment that has to be actively cancelled, per the regulation, not just logged as slow. 

That reframes the engineering problem specifically: add up what actually happens in the path — Verification of Payee lookup, sanctions screening, fraud scoring, ledger debit and credit, confirmation back to the sending PSP — and each one is a line item against a fixed budget, not an independent SLA a team can tune in isolation. A VoP call that comfortably meets its own "under 2 seconds" target is still a problem if it's the fourth call in a chain that's already spent 7 seconds by the time it starts. 

Retries have to work backwards from everywhere else we've written about them 

We've written before about why a slow payment gateway is more dangerous than a down one, and why the right response to a flaky downstream call is a capped retry with backoff and jitter — that guidance holds for the payment gateways it was written about. It's close to the opposite of correct advice for a call inside a 10-second instant-payment budget. A retry after a timeout doesn't buy resilience here — it spends budget you don't have back, on a call that's already shown you it's slow. The correct pattern inside this specific budget is a tight, explicit timeout per call, no retry, and a fail-fast path that actively cancels the transaction the moment the budget is genuinely blown — because the regulation requires exactly that outcome anyway, and a system that hangs waiting on a retry instead of cancelling promptly is failing the same requirement more slowly and less visibly. 

 1 @CircuitBreaker(name = "vopService", fallbackMethod = "cancelInstantPayment") 
 2 @TimeLimiter(name = "vopService") // hard cap, e.g. 1500ms — no retry configured 
 3 public CompletableFuture verifyPayee(PaymentRequest request) { 
 4     return vopClient.verify(request); // one attempt, budget-bounded 
 5 } 
 6  
 7 private CompletableFuture cancelInstantPayment(PaymentRequest request, Throwable t) { 
 8     return CompletableFuture.completedFuture(VopResult.cancelled(request.getReference())); 
 9 } 

 This is the same Resilience4j toolkit used elsewhere, deliberately configured the opposite way — no retry policy at all, because the instrument that protects a slow payment gateway from a retry storm is the exact instrument that would blow an instant-payment budget here. 

Sanctions screening: the cache has to be current, not fast 

We've also written about why a stale cache is a compliance problem for a balance. Sanctions screening inverts that same lesson in a way worth naming explicitly: the risk here isn't a cache serving an old result, it's a cache serving a result against an old list. Sanctions lists update, sometimes intraday, and a nightly-refreshed batch lookup — adequate for a system with hours to reconcile — is not adequate for a check that has to run, correctly, inside a fixed few hundred milliseconds of a 10-second budget, on every single instant payment, all day and all night. The lookup itself needs to be fast (an in-memory or Redis-backed structure, not a database round-trip against a screening vendor), and separately, the data behind it needs an invalidation strategy driven by the list provider's actual update cadence, not a cron schedule chosen for convenience. Getting either half wrong — a slow lookup, or a fast lookup against a stale list — is a compliance failure with a different signature but the same regulator on the other end of it. 

The transaction-size cap is gone, and connection pools were sized for a world where it wasn't 

The regulation removed the scheme-level cap on instant payment size. Combined with the 24/7/365 availability requirement and no maintenance windows to fall back on, that's a capacity-planning problem most teams underestimate specifically because it doesn't show up in average daily volume at all — it shows up as an unpredictable burst of large-value transfers at 3 a.m. on a Saturday, exactly when a connection pool sized for typical business-hours load is thinnest. A HikariCP pool provisioned against mean concurrent demand, the way most services are reasonably sized, is the wrong sizing model for a service with no quiet maintenance window to recover in and no cap limiting how large a single instant transfer can be. Pool sizing here has to be validated against a genuinely adversarial peak scenario, not extrapolated from a normal traffic graph — and validated with the same seriousness a team would put into load-testing a payment gateway integration before launch, not assumed safe because average load looks comfortable. 

The nightly reconciliation window doesn't exist anymore 

We've written elsewhere about engineering a nightly reconciliation job to hold up at volume. Instant payments remove the premise that job depended on: there's no longer an overnight lull to run it in, because settlement happens continuously, all day, every day. Reconciliation against a real-time settlement rail has to become the incremental, continuously-running process we described as the resilient design choice in that piece — matching what changed since the last confirmed reconciliation, not the entire day's volume in one nightly pass — except now it's not an optimization for a bank that's already fast enough. It's the only design that's even structurally possible once "tonight" stops being a real window in the settlement calendar. 

What the deadline is actually testing 

None of these are exotic engineering problems individually — budgeted timeouts, current caches, honest pool sizing, continuous reconciliation are all patterns most senior backend teams already know. What the SEPA Instant deadline actually tests is whether those patterns were applied consistently across every synchronous call in a payment path that used to have hours of slack and now has ten seconds, with a regulator on the other end of every one of them. For the banks with the April 2027 deadline still ahead, that's the actual head start worth using now: not waiting to discover which call in the chain was the one that assumed it had more time than it does.