The Problem Space

Every episode in this series assumes one fact that's easy to state and hard to actually engineer around: SEPA Instant Credit Transfer (SCT Inst) gives a payment 10 seconds, not a business day. Before writing any code, it's worth sitting with what that single number actually forces onto an architecture — because most of the interesting decisions in this series trace back to it.

From T+1 to 10 Seconds

Classical SEPA Credit Transfer (SCT) settles on a business-day cycle: a transfer submitted this afternoon might not reach the beneficiary's account until the next business day, moving in batches through clearing windows with defined cut-off times. SCT Inst removes all of that. A payment must be initiated, validated, cleared, settled and confirmed back to the originator — with the funds actually usable by the beneficiary — in 10 seconds, at any hour, on any day of the year.

• 10 seconds, end to end — from the debtor PSP submitting the transaction to a confirmation reaching the originator, funds usable by the beneficiary immediately.
• 24/7/365, no exceptions — weekends, public holidays and 3 AM carry the same SLA as a Tuesday afternoon. There's no batch window to hide a slow nightly job in.
• Mandatory reach, not an optional feature — under the EU's Instant Payments Regulation, euro-area PSPs must be able to both send and receive SCT Inst, at the same cost as a regular SEPA transfer. It isn't a premium tier a bank can quietly decline to build.

The Actors: Who Touches the Payment, and When

An SCT Inst transaction passes through a small, fixed set of actors, and the 10-second budget is shared — unevenly — across all of them:

1. Originator — the customer initiating the transfer, via their bank's app, portal or corporate channel.
2. Debtor PSP (issuing bank) — receives the instruction, validates it, checks funds and fraud exposure, and submits it onward. This is usually where most of a bank's own engineering effort concentrates.
3. Clearing and Settlement Mechanism (CSM) — the infrastructure that actually moves money between banks: EBA Clearing's RT1 and the Eurosystem's TIPS (TARGET Instant Payment Settlement) are the two dominant ones in the euro area.
4. Creditor PSP (beneficiary bank) — receives the incoming instruction, must accept or reject it within its own slice of the budget, and credit the account.
5. Beneficiary — the recipient, who expects the money to simply be there, with no visibility into any of the above.

That chain matters because the 10-second SLA is measured end to end, not per component. If the CSM takes 2 seconds and the creditor PSP takes 3, the debtor PSP doesn't get a fresh 10-second budget — it inherits whatever is left. In practice, most banks design for a much tighter internal budget than the headline number suggests, because you don't control the other actors' latency, only your own.

What the SLA Actually Imposes, Technically

Translate the regulatory language into architecture requirements and a fairly demanding list falls out:

1. True 24/7/365 availability. No nightly batch window, no maintenance downtime a customer would ever notice. High availability stops being a nice-to-have and becomes a regulatory expectation.
2. Synchronous semantics with a hard timeout. The originator's channel is waiting on a response. Every downstream call — fraud scoring, sanctions screening, ledger debit — has to complete inside a shrinking sub-budget, or fail explicitly and fast.
3. Idempotency by default. Network retries and timeouts are a certainty at this speed, not an edge case. The same instruction can legitimately be resubmitted, and processing it twice can never mean paying out twice.
4. A positive or negative confirmation inside the window. Every transaction gets a status report back to the debtor PSP within the 10 seconds — acceptance, rejection, or a timeout that still has to resolve deterministically on both sides.
5. Exceptions handled out-of-band. Recalls, investigations and returns don't fit inside a 10-second window and were never meant to — they run as a separate, asynchronous process after the instant leg has already settled.

Why the Classical Core Banking Architecture Can't Just Absorb This

Most core banking platforms were designed around a very different assumption: transactions accumulate during the day and get reconciled in a batch run overnight. End-of-day cut-offs, nightly settlement jobs and next-morning reconciliation aren't implementation details — they're load-bearing assumptions baked into schema design, locking strategy, and even how errors get surfaced to operations teams.

Bolting a 10-second synchronous path onto that kind of system usually looks like routing SCT Inst traffic around the batch core entirely rather than through it — a purpose-built real-time path that talks to the ledger via an API instead of a nightly extract, with the batch core kept for what it's still good at: statements, regulatory reporting, and everything that genuinely can wait until tomorrow.

The mistake isn't having a batch-oriented core banking system. The mistake is trying to make it instant instead of building past it.

That's the design decision this series follows through in detail, starting with the next episode: an event-driven architecture built specifically for the instant leg, with the classical core kept in its lane. Every constraint that follows in this series — fraud detection that doesn't burn the latency budget, a database that holds up at 10x traffic, compliance that's a first-class citizen instead of an afterthought — inherits directly from the numbers laid out here.