The Ten-Second Build: an EMI's instant-sending programme
How an EMI built 24/7 instant-sending operations, ten-second processing windows, and liquidity arrangements ahead of the April 2027 deadline.
Q1 2027
Go-live
< 10s
Processing window
340 TPS
Peak throughput
0
Regulatory incidents (90 days)
Executive summary
An electronic money institution (EMI) engaged the hub to build an instant-sending programme ahead of the 9 April 2027 SEPA Instant deadline. The programme delivered 24/7 payment operations, a ten-second processing window, and a real-time liquidity bridge. Go-live was Q1 2027, ahead of the regulatory deadline.
Client details are anonymized per the Ch. 10 labeling regime. No reasonable reader can reverse-engineer the client from the information published here.
Client context
The client is a euro-area EMI with a payment services portfolio spanning remittance, merchant acquiring, and B2B supplier payments. The EMI's existing payment infrastructure was batch-oriented: payments were queued through the business day and settled in end-of-day batches via STEP2. The EMI had no instant payment capability.
The EMI's regulatory perimeter placed it squarely in the 9 April 2027 sending obligation. Unlike banks, the EMI did not have an existing TIPS or RT1 connection. Everything had to be built from scratch.
Business challenge
The 9 April 2027 deadline requires three capabilities that the EMI did not have:
-
24/7 payment processing. SCT Inst operates 24 hours a day, 365 days a year. The EMI's operations team worked business hours, Monday to Friday. No weekend coverage. No night coverage. No holiday coverage.
-
Ten-second processing window. Each payment must be processed, fraud-screened, sanction-screened, liquidity-checked, and submitted to the clearing infrastructure within 10 seconds. The EMI's batch processing pipeline took 90 seconds per payment for fraud and sanction screening alone.
-
Real-time liquidity management. SCT Inst settles individually, not in batch. The EMI's treasury function funded the STEP2 account once per day. Real-time liquidity monitoring and top-up did not exist.
Approach
The programme ran in three parallel workstreams over 14 months:
Workstream 1: Clearing infrastructure integration
Connected the EMI to TIPS as the primary clearing infrastructure, with RT1 as backup. Built a payment router that could fail over between TIPS and RT1 without dropping in-flight payments. The router was tested with 10,000 payments in a production-equivalent environment before go-live.
Workstream 2: Processing pipeline rebuild
Replaced the batch fraud screening and sanction screening pipeline with a streaming pipeline that processes each payment in under 3 seconds. The pipeline uses a rules engine for first-pass screening and a machine learning model for second-pass review. Payments that clear both passes are submitted to the clearing infrastructure. Payments that flag for review are routed to a human analyst queue.
The human analyst queue is staffed 24/7. The EMI outsourced night and weekend coverage to a managed operations provider. The managed operations provider follows a runbook written by the hub team. The runbook covers 47 exception scenarios.
Workstream 3: Liquidity bridge
Built a real-time liquidity monitoring and top-up system. The system monitors the TIPS account balance every 5 seconds. When the balance drops below a configured threshold, the system automatically triggers a top-up from the EMI's prefunded euro account at a tier-1 bank. The top-up is executed via an API call, not a manual transfer.
The liquidity bridge was the highest-risk component. A failure in the bridge would mean the EMI could not send payments. The bridge was built with redundant bank connections: if the primary bank API is unavailable, the system falls back to a secondary bank. If both are unavailable, the system alerts the treasury team and pauses outbound payment submission.
Solution
The instant-sending build went live in Q1 2027, six weeks ahead of the April deadline. The first week of production processing showed:
| Metric | Value | Notes |
|---|---|---|
| Processing window (median) | 4.2 seconds | Well within the 10-second requirement |
| Processing window (P99) | 8.7 seconds | Within the 10-second requirement |
| Peak throughput | 340 TPS | Exceeded the 200 TPS design target |
| Fraud screening pass rate | 97.3% | 2.7% routed to human review |
| Liquidity bridge activations | 12 in week 1 | All successful, no manual intervention |
| Clearing infrastructure failover | 0 | TIPS stable throughout |
Results
- Go-live: Q1 2027, six weeks ahead of the 9 April deadline
- Processing window: median 4.2 seconds, P99 8.7 seconds
- Peak throughput: 340 transactions per second
- Zero regulatory incidents in the first 90 days
- 24/7 operations maintained through weekends and holidays with no unplanned downtime
Lessons
-
Start the clearing infrastructure integration first. It has the longest lead time. The TIPS onboarding process took 4 months, driven by the ECB's validation and testing requirements.
-
Outsource 24/7 operations if you cannot staff them. The EMI could not hire a 24/7 operations team in 14 months. Outsourcing to a managed operations provider was the pragmatic choice. The runbook is the critical deliverable, not the staffing model.
-
Build the liquidity bridge with redundancy from day one. A single bank connection is a single point of failure. The bridge must have at least two bank connections, and the failover must be automatic.
-
Test with production-equivalent volumes before go-live. The 10,000-payment test in a production-equivalent environment caught three integration defects that would have caused go-live failures. Testing with 100 payments would not have caught them.
Anonymized case study. Client permission obtained per the Ch. 10 5-step workflow. Identifying details reviewed with the client. No reasonable reader can reverse-engineer the client from the information published here. Re-verification date: August 2027.