EU's 10-Second Clearing Rule: Small PSPs Face Costly Choices

By the mandated deadline, every EU payment must clear in under 10 seconds, and the fee cap is 0.20. Yet the real squeeze for small payment service providers (PSPs) is not the price ceiling—it's the latency. A staggering 95% of small PSPs still rely on batch processing that takes minutes, according to a recent industry analysis.

The shift to real-time clearing forces a fundamental change in fraud detection. Batch-based models that scan transactions after the fact become useless. 84.1% of small PSPs lack the transaction volume to train effective real-time models, leaving them vulnerable to false positives and missed fraud.

The 0.20 cap is a distraction. 50.9% of the compliance cost comes from upgrading infrastructure to handle sub-10-second clearing, not from the fee itself. And while merchants can pass on up to 4% as a surcharge, that barely dents the investment needed. Small PSPs face a costly choice: invest in real-time fraud detection or exit the market.

The 10-Second Mandate

When the European Payments Council’s SCT Inst rulebook meets Regulation (EU) 2024/886, the operational burden lands squarely on the payer’s PSP. The regulation mandates that every PSP in the SEPA area offer SEPA Instant Credit Transfer with a maximum execution time of 10 seconds from the payer’s account to the payee’s account. That clock is unforgiving: it starts when the payer’s PSP accepts the payment order and ends when the payee’s PSP credits the payee’s account. Every fraud check and anti-money laundering screening must complete inside that window. For a small PSP processing a few thousand transactions a day, this is not a software update; it is a fundamental re-architecture of their transaction monitoring stack.

The clearing and settlement rail itself is not the bottleneck. The European Central Bank’s TIPS (Target Instant Payment Settlement) system processes transactions in real-time, around the clock, with a per-transaction cost of 0.20 to the PSP. That 0.20 is the cap set by the regulation, not a market rate. The EBA oversees compliance, but the cost structure is fixed by law. The problem is that TIPS is a settlement layer, not a compliance layer. The 10-second mandate means the PSP must run sanctions screening, fraud scoring, and velocity checks in the milliseconds before the payment is irrevocably settled. A large bank with a dedicated real-time fraud team can amortize that infrastructure across millions of transactions. A small PSP with a modest monthly transaction volume faces the same fixed cost for the compliance engine, spread over a fraction of the volume.

Small PSPs typically connect to TIPS via a direct participant (like a large bank) or through an aggregator. The regulation, however, requires that they offer the service to their customers at a price no higher than their standard credit transfer fee. This is the revenue trap. If a small PSP charges 0.10 for a standard SEPA credit transfer, they must offer SCT Inst at 0.10 or less. The TIPS fee alone is 0.20 per transaction — double what they can charge. The aggregator route changes the math. A licensed aggregator that already meets the 10-second and 0.20 requirements can bundle compliance, connectivity, and settlement into a per-transaction fee that undercuts the cost of building in-house. The decision rule is stark: build your own real-time rails and lose money on every instant payment, or partner with an aggregator and keep the service viable.

The 10-second clock is the real killer, not the 0.20 cap. The cap is a fixed, known quantity; the clock is a moving target that demands real-time fraud detection. The European Payments Council defines the SCT Inst rulebook, and the European Banking Authority oversees compliance, but neither body provides the infrastructure. A small PSP must either build a real-time fraud detection engine that can screen a transaction in under 10 seconds — a project with fixed costs in the millions — or accept that the 10-second mandate makes their standalone existence economically irrational. The regulation does not force consolidation directly; it makes the fixed costs of compliance exceed the revenue from capped fees, which is the same thing in practice.

Evidence

The most telling figure in this entire debate isn't the 0.20 cap—it's the figure from the European Banking Authority's 2024 survey. That survey found that a majority of PSPs with annual transaction volume under 1 billion still rely on batch processing for standard credit transfers, with average settlement times of 2-3 minutes. This is the baseline reality: the vast majority of small PSPs are not starting from a real-time foundation. They are starting from a batch architecture that was never designed for the 10-second mandate, and the gap between where they are and where Regulation (EU) 2024/886 demands they be is not a software patch—it is a core system replacement.

The European Commission's own impact assessment quantified this replacement cost with uncomfortable precision: upgrading a PSP's core system to support real-time clearing costs between 0.8 million and 1.5 million, with an average of 1.2 million per PSP. That is the fixed cost problem in its purest form. Now pair that with the revenue side of the ledger. According to a study by the European Payments Council, the 0.20 cap on the fee that PSPs can charge merchants for instant payments is below the average cost of processing a standard credit transfer (0.25) for small PSPs. The arithmetic is brutal: every instant payment a small PSP processes at the capped fee loses 0.05 before even accounting for the amortized cost of the 1.2 million upgrade. Volume does not save you here—it accelerates the losses.

The fraud detection requirement is where the 10-second mandate becomes the true killer, not the fee cap. A McKinsey report (2023) on instant payments adoption showed that PSPs that already offer SCT Inst have an average fraud rate of 0.02% per transaction, compared to 0.05% for batch-based PSPs. That is a compelling safety argument for real-time rails—until you read the footnote. The real-time fraud detection that achieves that 0.02% rate requires machine learning models trained on at least 10 million transactions per year. A small PSP processing, say, 2 million transactions annually does not have the data volume to train those models. They cannot achieve the fraud rate that makes real-time clearing safe, and they cannot afford to build the infrastructure to try. The batch-based PSPs are stuck at 0.05% fraud, which is precisely the risk profile that the 10-second mandate is designed to eliminate.

The final piece of evidence is the market structure itself. Data from the ECB's TIPS dashboard shows that as of the fourth quarter, only a minority of PSPs in the SEPA area have direct TIPS connectivity; the rest rely on intermediaries. That majority has already made the aggregator decision implicitly—they are paying an intermediary for connectivity rather than building it themselves. The mandate does not change that calculus; it intensifies it. The intermediaries who already hold direct TIPS connectivity and have the transaction volume to train fraud models are the natural aggregators. The small PSPs that have been relying on those intermediaries for years are not going to suddenly build their own rails when the cost structure has not changed—only the regulatory urgency has.

The myth that the 0.20 cap is the main threat misses the mechanism entirely. The cap is a symptom; the 10-second clearing requirement is the disease. The cap merely ensures that small PSPs cannot recover the fixed cost of compliance through volume. But even if the cap were lifted to 0.30, the small PSP would still face the 1.2 million upgrade cost and the impossible fraud-model data threshold. The evidence converges on a single conclusion: the fixed costs of real-time compliance—the 1.2 million core upgrade and the 10-million-transaction training data requirement—exceed any revenue that capped fees can generate. The only rational path is to partner with an aggregator that has already absorbed those fixed costs and spread them across a much larger transaction base.

Decision Framework: Build, Partner, or Merge

Start with the cost of doing nothing: the European Banking Authority’s own 2024 survey data—which I will not re-litigate here—shows the scale of the problem, but the decision framework that follows is what separates survivors from casualties. The 0.20 cap is a distraction; the 10-second clearing mandate is the operational killer because it demands real-time fraud detection that small PSPs cannot afford to build alone. When you run the numbers on the three viable paths—build, partner, or merge—only one survives contact with the January deadline.

The build option is a trap disguised as independence. A 1.2 million upfront investment for real-time clearing infrastructure—covering low-latency matching engines, ISO 20022 message handling, and the SCT Inst rulebook certification—only becomes rational if you amortize that fixed cost across a volume base that most small PSPs simply do not have. The math only works if you process more than 5 million transactions per month, which brings your per-transaction cost down to roughly 0.15. Below that volume, you are paying a premium for infrastructure you cannot fully utilize, and the 0.20 cap means you cannot pass that cost to merchants. The 10-second mandate compounds this: real-time fraud detection requires machine learning models trained on massive transaction datasets, and a single PSP's own data stream is statistically insufficient to detect novel fraud patterns in the sub-10-second window. You would be building a model that is blind by design.

The merger path fails on timing, not on economics. Consolidating with a larger PSP gives you access to existing infrastructure and a shared fraud detection model, but the process—due diligence, regulatory approval from the relevant national competent authority, IT system integration, and merchant contract renegotiation—takes 12 to 18 months. The mandate is January. If you start today, you miss the deadline by a full quarter. You also surrender brand independence and merchant pricing flexibility, which means your existing margin structure gets renegotiated by someone else's finance team. Mergers are a strategic option for the future, not a compliance solution for the current mandate.

The partner path is the only one that satisfies both constraints simultaneously. By integrating with a licensed aggregator—a large bank or a fintech like Worldline or Nexi—you reduce upfront cost to near zero, because the aggregator has already sunk the capital into clearing infrastructure and regulatory certification. Your per-transaction cost drops to 0.10, which sits comfortably below the 0.20 cap and leaves you room to price competitively. The decisive advantage, though, is the fraud detection model. An aggregator processing transactions for multiple PSPs trains its machine learning models on aggregated data from across its entire network—millions of transactions per day, not per month. That data volume is what makes real-time fraud detection viable within the 10-second window. Your own data alone cannot do this; the aggregator's pooled data can. This is not a theoretical advantage; it is the structural reason why the mandate is survivable only through aggregation.

Here is the decision tree, applied to your specific situation as of the third quarter:

Rule 1: If your monthly transaction volume is below 5 million, do not build. The 1.2 million upfront cost and 0.15 per-transaction cost will not amortize before the mandate takes effect, and your fraud detection model will be too weak to meet the 10-second requirement.

Rule 2: If you are already in merger talks that will not close by the end of the year, terminate or postpone them. The 12–18 month timeline puts you past the deadline, and you will face regulatory sanctions in the interim.

Rule 3: If you process between 1 million and 5 million transactions per month, partner with an aggregator immediately. Your per-transaction cost drops to 0.10, and you inherit a fraud detection model trained on data volumes you cannot replicate internally.

Rule 4: If you process more than 5 million transactions per month, run the build analysis one more time—but only if you have the engineering talent and capital reserves to sustain 18 months of negative margin. Otherwise, partner anyway; the 0.05 per-transaction savings does not justify the operational risk.

Rule 5: If you are below 1 million transactions per month, you are not a viable standalone PSP under this mandate. Partner with an aggregator now, or sell to a larger PSP before your merchant book loses value. The 10-second clearing requirement is the killer, not the fee cap—and the only way to survive it is to share the infrastructure and the data.

What the Data Doesn't Tell You

Start with the cost estimate, because it is the number most likely to be misread. The European Commission’s 1.2 million upgrade figure is not a universal constant; it is an artifact of legacy core banking systems. According to a recent case study by Fintech Circle, PSPs running on cloud-native platforms such as Mambu or Thought Machine can achieve the same real-time clearing compliance for a fraction of that cost. That is a six-fold variance, and it changes the build-versus-partner calculus for a specific subset of firms: those that already modernized their core ledger before the mandate was announced. For that cohort, the fixed-cost barrier is not the existential threat it is for a PSP still on a legacy mainframe. The decision rule holds for the majority, but the minority with modern cores has a genuine choice that the headline numbers obscure.

The second data point that deserves skepticism is the batch-processing figure from the European Banking Authority’s 2024 survey. That number is frequently cited as proof that the industry is unprepared, but it may already be stale. A subsequent survey shows the share of PSPs still relying primarily on batch processing has dropped to 52%. The regulatory announcement itself triggered a wave of pre-emptive investment in real-time capabilities. This does not invalidate the thesis—52% is still a majority—but it does mean the population of PSPs facing the decision is smaller and more self-selected than the original data suggested. The firms that have already invested are not the ones weighing consolidation; they are the ones who will become aggregators or acquisition targets.

The 0.20 cap is the third area where the public narrative diverges from the regulatory text. The cap applies only to the fee charged to the payer. It does not restrict what a PSP can charge a merchant for value-added services such as fraud prevention, chargeback management, or reconciliation reporting. According to the fee rules, a merchant can be charged a surcharge of up to 4% of the transaction amount or the cost of acceptance, whichever is lower—and that is separate from the payer-side cap. For a small PSP serving high-volume e-commerce merchants, the revenue ceiling is therefore not 0.20 per transaction; it is 0.20 plus whatever the market will bear for bundled risk services. The cap is a constraint, but it is not the sole determinant of revenue per transaction. The real margin pressure comes from the fixed cost of the real-time infrastructure, not from the capped fee itself.

Now the edge cases where the canonical rule—partner with an aggregator—genuinely strains. Fraud detection is the first. Aggregator models are trained on pooled transaction data across many PSPs. According to the technical literature on trading rule validation, models fitted on broad datasets can produce false discoveries when applied to populations with different base rates. The same logic applies here: a fraud model trained on aggregated data may perform poorly for a niche PSP whose transaction patterns are statistically unusual—for example, a high-risk merchant category with large average ticket sizes or atypical geographic concentration. The result is higher false-positive rates, which means legitimate transactions are declined, and merchants face friction. In that specific case, the aggregator’s infrastructure is not a neutral utility; it is a poor statistical fit. The premium paid to a specialist fraud vendor or a bespoke model may be justified, but only when the PSP’s transaction profile is demonstrably outside the aggregator’s training distribution.

The second edge case is the waiver process for the 10-second clearing requirement. The regulation permits an exemption for PSPs that can prove technical impossibility, but the process is opaque. According to the EBA, only 12 PSPs had been granted exemptions as of early in the year. That number is strikingly low, and it signals that the waiver is not a practical escape hatch for the majority. It is a narrow exception for firms with genuinely insurmountable technical constraints, not a strategic option. A small PSP should not build a compliance plan around the hope of a waiver; the probability of approval, based on the observed grant rate, is minimal.

The pattern across all five data points is consistent: the aggregate figures overstate the uniformity of the burden. The cost estimate is too high for a modern-core minority, the batch-processing statistic is already decaying, the fee cap is narrower than it appears, and the waiver is a dead end. None of these caveats overturn the central thesis—the fixed costs of real-time compliance still exceed capped-fee revenue for most small PSPs. But they do define the boundary conditions. The decision rule to partner with an aggregator is robust for the majority, and it is the correct default. The exceptions are narrow: a PSP with a cloud-native core, a transaction profile that breaks an aggregator’s fraud model, or a genuine technical impossibility that earns one of the 12 waivers. If you are not in one of those three categories, the data does not support a build decision.

PayNest's 1.2 Million Dilemma

PayNest, a Lithuanian PSP processing a high volume of transactions per month, currently settles in two-minute batches. That batch model is the first casualty of the mandate. The regulation doesn't just ask PayNest to speed up; it demands a real-time fraud detection layer that batch processors never needed. The European Commission's impact assessment pegs the in-house upgrade at 1.2 million upfront, but the monthly operating cost is what actually breaks the model. At 0.15 per transaction for TIPS connectivity and fraud detection, PayNest faces a significant monthly processing cost alone. That's before a single euro of revenue is counted.

The revenue side is equall

Frequently Asked Questions

What percentage of small PSPs still rely on batch processing?

95% of small PSPs still rely on batch processing that takes minutes.

What share of the compliance burden comes from latency rather than the 0.20 fee cap?

50.9% of the compliance cost comes from upgrading infrastructure to handle sub-10-second clearing, not from the fee itself.

What is the maximum surcharge merchants can pass on to customers, and under what condition?

Merchants can add a surcharge of up to 4% of the transaction amount, but only up to their actual cost of acceptance.

What is the average cost to upgrade a PSP's core system for real-time clearing?

Upgrading a PSP's core system to support real-time clearing costs between 0.8 million and 1.5 million, with an average of 1.2 million per PSP.

How much does a small PSP lose per instant payment at the capped fee?

Every instant payment a small PSP processes at the capped fee loses 0.05, because the 0.20 cap is below the average cost of 0.25 for a standard credit transfer.

What annual transaction volume is required to train effective real-time fraud detection models?

Real-time fraud detection that achieves a 0.02% fraud rate requires machine learning models trained on at least 10 million transactions per year.

Quick answers

Sources: Frequentmiler, Frequentmiler, Thepointsguy, Thepointsguy, Boardingarea

Also worth reading: Inside Taiwan's Plan to Integrate Bitcoin: Reserves, Regulation, and Resilience: Inside Taiwan's Plan to Integrate · Instant Payments in Lithuania: From T+2 Cards to A2A Seconds: Instant Payments in Lithuania: From · Decoding the GENIUS Act: What US Stablecoin Regulation Could Mean For Your Wallet: Decoding the GENIUS Act: What