Real-time SEPA transfers versus batch cores
Start with what breaks. A core that books in scheduled windows assumes it controls when a ledger entry happens. Real-time SEPA transfers remove that control, because you have to credit the payee and debit the payer continuously, at any hour, with no batch to defer the posting into. If your core takes a maintenance outage at 2am, instant SEPA payments keep arriving and someone still has to answer within nine seconds.
There is also a message that does not exist in your standard retail flow. SCT Inst requires a positive confirmation, the pacs.002 that reports back within seconds whether funds were made available or the transaction was rejected. Standard SEPA never asked your systems to produce a real-time yes or no. Now the beneficiary side must generate one, and the originator side must consume it and either finalize or restore the payer's account.
Then there are R-transactions and status enquiries. R-transactions, including recalls with camt.056, and status checks with pacs.028 have to work at 3am on a public holiday. If your operations model assumes a human reviews these during business hours, that model does not survive contact with instant SEPA payments. This section is the honest test of whether your current core can play at all.
Sub-ledger and sponsor bank models
Two patterns let you avoid ripping out the core. The first is a real-time sub-ledger that shadows the core and keeps processing alive when the core is unavailable. It runs a real-time, append-only book next to the regulated ledger and posts instant euro transactions immediately. It reconciles back to the core when the core is open. This is what lets you credit funds in real time even while the batch core sleeps.
The second is a sponsor-bank or sub-participation arrangement, where a directly connected bank provides your reachability and settlement while you plug in behind them. It is faster to compliance and lighter on capital, because you inherit their connection rather than building your own.
The trade-offs run in opposite directions:
-
A sub-ledger gives you control and speed but demands engineering effort and disciplined reconciliation, since you now run two books that must agree.
-
A sponsor bank gives you speed to market and lower build cost, but you cede control over the commercial relationship, including pricing and roadmap, and you pay for reachability you do not own.
Which one fits depends on volume and on whether instant SEPA payments are core to your product. A small institution reconciling periodically will read these trade-offs differently from a bank crediting funds in real time at scale.
Connecting to TIPS and RT1
Whatever you build behind it, the core has to reach the clearing and settlement layer. For instant SEPA payments in euro, that means TARGET Instant Payment Settlement (TIPS), the Eurosystem service that settles in central bank money 24/7/365, and EBA Clearing's RT1. This is a different world from the STEP2 and TARGET2 rails your standard SEPA traffic grew up on. TIPS runs with no maintenance windows and settles in milliseconds, and RT1 processes euro transactions in just over a second on average.
Both run on ISO 20022 messaging, so your integration speaks that language end to end, with API-based initiation into the settlement service. Reachability is not a marketing word here. A PSP is reachable in TIPS only once it is configured as a participant or reachable party with its BIC registered as an authorized account user and its account set up in the reference data. Being reachable in one clearing mechanism is not enough on its own, which is why banks join both. When J.P. Morgan became a TIPS participant in December 2021 alongside RT1, it did so to widen reach across 28 countries.
Platform selection turns on cost and timeline. Direct connection buys control and lower per-transaction cost at scale, at the price of a longer build. A gateway or aggregator gets you live faster and shifts the connectivity burden off your team. Decide this early, because it dictates how the rest of the flow is wired.
Processing inside the 10 second window
Everything now has to happen inside roughly nine to ten seconds, straight through, with a 20-second hard timeout behind it. The payment must fit inside that envelope in its entirety, or it fails. Straight-through processing is the entry ticket.
That clock creates a direct tension with fraud and sanctions logic. Any check that produces a false positive needing manual review cannot fit, because a human cannot look at a case and clear it before the timer expires. So the design has to push slow work out of the transaction path entirely and keep only deterministic, sub-second checks inside it. If a control needs a person, it belongs before or after the payment, never during.
What happens on timeout is written into the scheme, and it shapes how you build the flow. If the ten-second window cannot be met because of exceptional circumstances, the payer's PSP immediately restores the payer's account to the state it would have been in had the transaction never happened. Under the 2025 rulebook timing, the beneficiary side confirms by the seventh second. The originator receives confirmation by the ninth, and account restoration is due by the tenth if nothing comes back. Treat a timeout as funds held, not lost, and confirm status before any retry. Design for the failure path first, because at instant volumes it will fire far more often than you expect.