The T+1 Split
One of the most common mistakes we see in early-stage payment institutions is treating safeguarding and settlement as the same thing. They are not. Mixing them up creates compliance risk and operational chaos, and are a particular focus area of the regulators – rightfully so, given that it's the customers' funds that are the subject matter.
Let's get into specifics.
Settlement timing is contractual.
It's the schedule on which there's an obligation to pay your merchants. T+1, T+3, T+7 – real time, every day, or once per month, whatever the merchant contract says. There is no regulatory obligation dictating when a settlement to a merchant must be done.
Safeguarding timing is regulatory.
Under PSD2 and its national implementations, an EMI/PI must safeguard client funds by the end of the next business day after receiving them. T+1. This is not negotiable. This is not contractual. This is law. For European EMIs/PIs the funds have to be held within Europe, in a credit institution. And if the regulated institution needs to deviate from that and would like to use a different partner, they need to inform the regulator and obtain approval. The FCA in the UK is more flexible on some of the operational specifics, but the core T+1 obligation and the requirement to hold funds in an approved credit institution remain non-negotiable.
The problems start when these two timelines get tangled.
Payment institutions can process €100 of which €2 is their processing fee. However, they don't receive from a card scheme neither €100, nor €98. They would receive a processing amount less interchange, and that interchange would depend on the many parameters of the transaction. They cannot deposit the full €100 into their safeguarding account, plan to "reconcile later," and move on, as then they are commingling the funds (client and own). Some regulators might tolerate this as a practical simplification. The FCA would not – commingling of client and own funds is a regulatory breach, full stop.
The operational implication is significant. What is needed is data, and a system – or at minimum, a process – that can split every incoming settlement from a scheme into two streams: client funds that go to the safeguarding account, and your revenue that goes to your own funds account. This split must happen within the T+1 window. Every time.
If it doesn't happen on time, that's an incident. It must be logged. Serious breaches must be reported to the regulator. And if the auditor finds a pattern of late safeguarding, there's a material compliance finding to deal with.
Rolling reserves add another layer.
Again, seemingly simple – but do we treat the rolling reserve (RR) or security deposits as client funds, and safeguard them, or not?
Under some regulators (such as the FCA in the UK), rolling reserves are not safeguarded – they must be held in a separate own-funds account, not in the safeguarding account. This creates a three-way split: client funds, earned fees, and rolling reserves. Three accounts, three reconciliation streams, one T+1 deadline.
The good news: this can be automated. A properly designed settlement engine calculates the split per transaction, routes funds to the correct accounts, and flags exceptions. The treasury function becomes a system, not a daily fire drill.
The bad news: most early-stage EMIs don't have this. They have spreadsheets, manual bank transfers, and a finance person who struggles to ensure it's done properly and timely. That works until it doesn't.
The QuietOps™ principle here is simple:
Safeguarding should be invisible. If your team is manually calculating splits and chasing bank transfers every morning, the safeguarding is loud. Design it right, automate it, make sure data is available and edge scenarios are thought of, and make it disappear into the background.
Because the moment your regulator has to ask about it, you're already late.