Client money at your EMI has one business day

On 16 October 2026 ESMA published a new MiCA Q&A, number 2949, answered on 6 October. It settles a question many crypto-asset service providers have been quietly hoping would stay open: can client money sit at a payment institution or an e-money institution instead of a bank?

The answer is yes, briefly. A CASP may hold client funds in a payment account at a non-bank payment service provider, but only until the end of the business day after the funds arrive. By then they must be in an account at a credit institution or a central bank, opened in the CASP's own name. An account in the PSP's name, even one opened for the CASP and segregated from everything else, does not count.

That last sentence is the one that changes architectures. This note sets out what the rule is, who it reaches, where real stacks fail it, and a step-by-step way to check yours.

What Article 70 says#

Article 70 of MiCA is the safekeeping article. Paraphrased, paragraph by paragraph:

Paragraph	What it requires
70(1)	Protect clients' ownership of crypto-assets you hold, especially on insolvency, and never use them for your own account
70(2)	The same for clients' funds, other than e-money tokens, where your business model holds them
70(3)	Place those funds with a credit institution or central bank by the end of the business day after receipt, in accounts separately identifiable from your own
70(4)	Payment services linked to your crypto services must be provided by you or a third party authorised under PSD2, and clients must be told which
70(5)	Paragraphs 2 and 3 do not apply to CASPs that are themselves e-money institutions, payment institutions or credit institutions

The deadline in 70(3) has been in the text since 2023. What was unclear was whether the many CASPs that collect fiat through an EMI or a payment institution were already compliant, because the money was "safeguarded" at the PSP. Q&A 2949 says they are not, unless the funds move on in time.

What the Q&A adds#

The question was submitted on 28 August 2026. The answer makes three points:

A PSP account is a transit point, not a destination. A CASP may temporarily hold client funds in a payment account at an EMI or payment institution, whether the money comes from the client directly or from a third party on the client's behalf. It must keep meeting the 70(2) safeguarding duties while the money is there.
The clock is the next business day. No later than the end of the business day following receipt, the funds must be placed with a credit institution or central bank.
The account must be the CASP's. The receiving account must be opened and held directly in the CASP's name, or otherwise follow the applicable legal asset-segregation arrangement. An account in the non-bank PSP's name does not satisfy 70(3), even if it is designated for the CASP and segregated. ESMA's reasoning: the CASP would then hold a claim against the PSP, not an account at the bank.

Two caveats. ESMA Q&As are not binding and do not create new obligations; they tell you how supervisors will read the text. And the Q&A does not define "business day", which matters more than it sounds once weekends and national holidays enter the picture.

Who this reaches, and who it doesn't#

In scope: a CASP that is not itself an EMI, PI or bank, and that holds client fiat at any point, even for minutes. Exchanges, brokers, on-ramps and custodians with cash balances all qualify.
Out of scope by 70(5): a CASP that also holds an EMI, PI or banking licence. Its client funds fall under the other regime instead.
The gap in between: the EBA flagged on 24 September 2026, in its response to the Commission's MiCA review, that this carve-out may leave a hole. For a CASP that is also a payment institution, 70(5) switches off MiCA safekeeping, but payment-services safeguarding applies only to funds received for payment services. The EBA asked for clarity that client funds for crypto services that are not payment services do not fall outside both regimes. If you are dual-licensed, do not assume 70(5) means you are done.
No fiat at all: a crypto-only CASP that never touches client money has nothing to do here, though Article 70(1) still governs its crypto holdings.

Where real stacks fail it#

The rule is short. The way fiat actually moves through a CASP is not.

FBO and pooled accounts. A familiar setup is a "for the benefit of" account, or a pooled client-money account, that the EMI holds at its own partner bank, with virtual IBANs issued to the CASP's clients. The money is segregated, and it is at a bank. It is still in the PSP's name. That is the exact structure the Q&A rules out as the final resting place.
The sweep that nobody owns. Moving money from the PSP to the bank every business day is an operational process. If it is a person logging in to a dashboard, it fails the first time that person is ill. If it is a script, someone has to monitor it, and someone has to notice when it didn't run.
Cut-off times. Funds that arrive at 17:55 may miss the PSP's same-day payment cut-off. You need the sweep to work on the next day's first window, not on a best-effort basis.
Calendars. The PSP, the bank and the CASP may sit in different member states, with different public holidays. TARGET closing days are not the same as national holidays. Pick a calendar, write down why, and agree it with your supervisor.
Inbound from third parties. Card acquirers, open-banking initiators and other payment partners settle on their own schedules. The Q&A covers funds received from third parties on a client's behalf, so the clock arguably starts when the money reaches your PSP account, not when your ledger credits the client. Confirm that reading.
Outbound liquidity. Withdrawals often need a float at the PSP. The Q&A addresses money coming in. Keeping client money at the PSP for payouts is a separate question, and one to put to your supervisor rather than answer yourself.
Interest. Once client money sits at a bank, it may earn interest. ESMA Q&A 2486 says interest that arises from complying with 70(3) belongs to the client. That is a calculation and a payout process, not a footnote.

How to check your stack, step by step#

Work through these in order. Each step has an output you can hand to your compliance lead or your supervisor.

Step	What to do	What you end up with
1. Scope	Confirm your licences. If you are also an EMI, PI or bank, 70(5) applies, but read the EBA's gap note	A one-line scope statement, with the licence references
2. Map the money	Trace every fiat path, deposit to withdrawal, including card, SEPA, instant and partner rails	A flow diagram listing every account client money touches
3. Name test	For each account, record the legal account holder and the institution type	A table of accounts: holder, institution, PSP or bank, pass or fail
4. Fix the destination	Open accounts at a credit institution in the CASP's own name, segregated from own funds	Account agreements and bank confirmations
5. Automate the sweep	Schedule PSP-to-bank transfers inside the deadline, with cut-offs, retries and an agreed holiday calendar	A runbook and the job definition
6. Detect and escalate	Alert on any balance at the PSP older than the deadline; log it as a breach with cause and fix	Alert rules and a breach register
7. Reconcile daily	Match the client ledger against PSP and bank balances every business day; investigate any break	Signed daily reconciliation reports
8. Pass interest through	Calculate and credit interest earned on client money to clients	An interest allocation method and payout records
9. Keep the evidence	Timestamp receipt, sweep and settlement for every movement	A per-transaction audit trail you can query by date

A few notes on the harder steps.

Step 2 is where most of the work hides. Finance teams know the main operating account. They rarely have a full list of every collection account opened over the years with every rail provider. Start from the PSP contracts and bank statements, not from the architecture diagram.

Step 5 needs a defined clock. Store the time of receipt at the PSP as data, not as an inferred value from your own ledger. The deadline is calculated from it. If your PSP's API only returns a value date, ask for the booking timestamp.

Step 6 is the one supervisors will test. A sweep that works every day is not evidence. A system that would catch the day it didn't work is. Report a breach count of zero only if you can show the check that produced it.

Step 7 must reconcile at the client level. A pooled bank balance that equals total client liabilities is necessary, not sufficient. You need to show which client owns which part, on any given day, if the CASP fails.

Questions to take to your supervisor and counsel#

Some of this the text does not settle. Ask before you build around an assumption:

Which calendar defines "business day" for your setup?
Does the clock start on receipt at the PSP, or on credit to the client's account?
Can a payout float stay at the PSP, and on what terms?
If you are dual-licensed as a CASP and a PI, which regime covers funds tied to non-payment crypto services?

Write the answers down, with dates. They become part of your evidence.

The CEE angle#

The CNB said on 1 July 2026 that it had granted MiCA authorisations to 11 entities and assessed 251 applications. For the newly authorised, and for those still in the queue, the fiat side is now a supervised part of the business. If yours runs through an EMI or payment-institution partner, Q&A 2949 does not end that arrangement. It turns the PSP into the first hop and makes a bank account in your own name the second. Opening that account can take longer than building the sweep, so start there.

How we help#

This is engineering and operations work as much as compliance work, and we can take either part.

CASP Compliance Stack Audit. Fixed fee, two to four weeks. We map your fiat flows, run the account-name test, and check the sweep, reconciliation and evidence against Article 70 and Q&A 2949. You get a gap list and a build plan.
Build. Sweep automation, deadline alerting, daily client-level reconciliation and the audit trail, scoped from the audit.
Run. Monitoring and reconciliation operated as a managed service, with EU data residency, for teams that would rather not staff it.

See the readiness sprints, or write to us at info@prodevel.com.