The dollar never sleeps, unless it leaves the US
USD payments slow down once they cross the border
Key takeaways
Limit management is causing pain for European banks.
What’s the best way to combat it?
We’ve collected a few common approaches banks have taken, or are planning to take, when rolling out limit management for SCT Inst.
We’ve also thrown in our recommended approach, for good measure.
Here’s how Europe is building limit management architecture under SEPA Instant.
As a quick reminder, the regulation states:
So, if your client, Bob the builder, does business in multiple European countries, a change on one channel must be reflected in the others. If the limit is updated in Germany, it must be reflected in Belgium and Italy. And it must happen immediately.
We recommend establishing a centralized limit repository to make things simple. In this scenario, any updates are reflected across all payment channels immediately.
So, how are your colleagues tackling this challenge?
In this scenario, all SEPA credit transfers—instant or otherwise—share the same default limit. This keeps things simple. That said, it’s not very flexible.
And, you must give Bob the option to increase, decrease, or disable the instant transfer limit so that it differs from non-instant.
Another approach is to offer a tiered system. It could start with a Basic Tier (which has a lower daily limit for phone banking) and a rise to a Premium Tier for corporate clients (with higher or no daily limit for instant transfers).
Here, you must ensure any difference between instant and non-instant tiers still meets the Instant Payment Regulation’s (IPR’s) “no less favorable” principle. That means: you can’t charge any more for a SEPA Instant payment than a SEPA payment.
Another approach is to set dynamic limits (this one’s a win-win).
What do we mean by dynamic limits? Real-time risk scoring that adjusts or recommend limit levels to your customers based on their history and transaction patterns.
Why? Well, not everyone is going to set a limit. And you must balance your customer experience with liquidity risks.
Let’s say you start with a default. A flat cap of €150,000 for everyone – even though you know many will want a higher limit, and some will only need much lower. Are you providing the best possible experience for your customers? Are you showing them you know them?
Now, let’s say instead you dig into your data. You analyse spending patterns across your customers. You find Grete will be happier with €200,000, and George will do fine with €125,000.
In this scenario, not only are you providing a better experience, you’re in a better position to forecast your liquidity risks. That is, how much money you need in your instant payments account to cover a spike in transaction volumes.
Your customers can override your recommended limits if they want a higher or lower threshold, so long as they pass authentication.
Finally, some banks are allowing their customers to opt out or set the limit to zero if they don’t plan to use instant payments at all. This reduces fraud exposure for those who do not need real-time transfers.
(If this is the case, it could be an opportunity to educate them on the benefits of instant payments.)
So, that’s the nuts and bolts of it. How do we piece it together? What’s the best approach?
First, implement a central component (service/API) responsible for storing and enforcing the user’s limit.
Make sure that both the user interface (UI) and the payment processing layer reference the same service.
Then, make sure any limits changes are reflected in your central repository and then instantly enabled for every payment channel.
This satisfies the requirement that users must be able to lift or modify limits “any time without difficulty.”
Every payment channel (web, mobile, branch) must check the central repository before initiating a transaction to display the up-to-date limit.
This prevents confusion (i.e. where one channel displays an out-of-date limit).
When a payment is being made, the central module should check the available balance and the customer’s (or account-level) instant-payment limit.
If the transaction exceeds the limit, the request should be immediately declined. The payment cannot be processed. This is consistent with the IPR’s real-time nature.
Limit management is a core compliance and customer-experience topic.
You must offer your customers the ability to define a per-transaction or daily limit specific to instant payments
Align these limits and controls with existing non-instant SEPA practices.
And ensure robust anti-fraud protections while keeping the user experience convenient and transparent.
Because one daily or transaction-level limit must apply to all payment initiation channels, a centralized limit service is the most reliable way to comply with the IPR and avoid synchronization pitfalls. Each channel interacts with that service to:
This is an opportunity to stand out. Focus on the details. Make it a customer experience to remember.
Speak to RedCompass Labs. We’ve been helping banks, big and small, get ready for the instant payments regulation. Please feel free to reach out to discuss anything you’re unsure of in the article. Or, anything SEPA related. We are always happy to help.
Share this post
Santhosh Kumar
Senior Business Analyst, RedCompass Labs
USD payments slow down once they cross the border
The Fed is tightening payee verification, tackling fraud and gearing up for ISO 20022
Six areas to focus your efforts for a successful launch
The RPAA is live. The RTR is coming.
How can it connect the world's instant payment systems?
Payments are evolving faster than many banks can respond
Swift has provided a range of support options for contingency planning.
With the October SEPA Instant deadline fast approaching, we asked...