Three-Account Segregation: How EMIs and CASPs Should Architect Operating, Safeguarding, and Reserve Accounts

Every regulator-led enforcement against an EMI, PI or CASP in the last decade traces back to the same root cause: commingling of customer funds with the firm's own working capital. One pooled account. One ledger. One reconciliation. And one Section 166 skilled person review — or its EU equivalent — to follow.

The fix is architectural, not procedural. Under EMD2 Article 7, MiCA Article 70 and PSD2 Article 10, three legally distinct pools of money must sit in three legally distinct accounts: operating, safeguarding, and reserve. Each with its own naming convention, its own reconciliation cadence, and its own audit trail.

This is the Three-Account Segregation Standard. Architect it correctly once at day one, and a decade of audits, statutory reviews and bank onboarding questionnaires become routine. Architect it badly, and every reconciliation is a small fire waiting to become a regulatory event.

A single pooled bank account is operationally tempting and legally indefensible. The operating account holds the firm's own funds — share capital, retained earnings, working capital, payroll float. The safeguarding account holds customer funds against issued e-money or payment balances. The reserve account holds asset-backing or capital-floor reserves — relevant to ART and EMT issuers and to certain CASP custody arrangements.

The three pools have different beneficial owners, different insolvency treatment, and different allowable movements. A single transfer between the wrong two pools — even reversed within minutes — is a reportable breach under most supervisory frameworks. Bank statements are evidence; ledger entries are evidence; reconciliations are evidence. Auditors do not award good intent.

For an EMI, the safeguarding obligation sits in Article 7 of EMD2¹^[1]. Funds received in exchange for e-money must be safeguarded by segregation in a credit institution, investment in secure, liquid, low-risk assets, or a comparable insurance / guarantee policy. The pool is ring-fenced from the issuer's insolvency estate.

For a payment institution, the parallel obligation lives in PSD2 Article 10². The drafting is near-identical to EMD2 Article 7: ^[2]client funds must not be commingled at any time with the funds of any natural or legal person other than the payment service users on whose behalf they are held.

For a CASP providing custody and administration of crypto-assets, the obligation lives in MiCA Article 70³. Clients' crypto-assets and funds must be ^[3]held segregated from the CASP's own holdings, recorded in a separate register, and protected from the CASP's creditors in the event of insolvency.

The UK reading is in the FCA EMI Approach Document, Chapter 12⁴, which sets the operational expectations: the safeguarding account name must be ^[4]acknowledged by the bank in writing, funds must reach the safeguarding account by the end of the business day following receipt, and reconciliations must run at least daily. These are floors, not targets.

The operating account holds the firm's own money. Payroll, rent, vendor invoices, tax, professional fees, and the working capital float used to fund FX positioning or merchant settlement timing. The pool sits inside the firm's insolvency estate and is available to its general creditors.

What goes in: merchant discount rate earned, interchange revenue, FX spreads, subscription fees, interest on bank balances credited to the firm. What does not: any unprocessed customer funds, any settlement amount owed to a payee, any e-money issued and not yet redeemed.

The single most common architectural failure is the fee sweep. Fees are charged to the customer, deducted from the safeguarding balance, and not promptly transferred to the operating account. The unaccrued fee balance sits in safeguarding without a customer attached — and that, by definition, is commingling. Fees must be transferred on the same day they are crystallised, with a journal entry referencing the customer-level ledger.

The safeguarding account is the customer-facing pool. Every euro, pound, or dollar received in exchange for e-money or against a payment service obligation lands here. The account name must contain the words "Safeguarding" or "Client Money", and the bank must have countersigned an acknowledgement letter confirming it holds no right of set-off against the firm's other balances.

The pool is ring-fenced from the firm's insolvency estate. In a wind-down, the safeguarded balance is distributed pro-rata to customers ahead of any general creditor claim. The legal certainty of that ring-fence depends entirely on the operational discipline that came before — naming, acknowledgement, daily reconciliation, no commingling. A theoretically safeguarded pool that is operationally commingled is, on insolvency, unsafeguarded.

For a CASP the safeguarding pool exists in two parallel forms: a fiat safeguarding account at a credit institution for fiat balances awaiting trade or withdrawal, and a segregated wallet structure at a qualified custodian for crypto holdings. The MiCA Article 70 segregation obligation applies to both legs.

The reserve account is the most misunderstood of the three. For most EMIs and PIs, it does not exist — there is no third pool to architect. For a stablecoin issuer issuing an asset-referenced token (ART) or e-money token (EMT) under MiCA Titles III and IV, it is the structural heart of the regime.

The reserve holds the asset backing for tokens in circulation — at minimum 1:1 par value, with composition rules dictated by the referenced asset and the prudential overlay. It is legally separate from both the operating and safeguarding pools and is subject to its own monthly composition disclosure and independent audit attestation. Movements between reserve and any other pool require pre-approval from the firm's risk function and, in practice, sign-off from the supervisor.

Some non-issuer CASPs also maintain a reserve pool for operational risk capital, liquidity buffers against stressed redemption scenarios, or wind-down plan reserves. These are own funds, not customer funds, but supervisors expect them held in a clearly labelled account, not commingled with general operating cash.

The composition rules for an ART or EMT reserve are tighter than most issuers initially appreciate. Reserve assets must be highly liquid, low credit risk, and capable of being liquidated against a same-day mass-redemption scenario without distressed price impact. For an EMT, the reserve sits almost entirely in cash deposits and short-dated sovereign instruments at qualifying credit institutions. For an ART referencing a basket, the reserve mirrors the basket composition with concentration limits per issuer and per asset class. Yield-chasing inside the reserve — extending duration, reaching for credit, or accepting illiquidity premium — is the most common path from a clean MiCA authorisation to a supervisory direction.

The monthly composition disclosure deserves treatment as a marketing-grade document, not a compliance afterthought. Token holders, listing venues, market makers and counterparties read it. The disclosure should state, per reporting date: the par value of tokens outstanding, the market value of reserve assets, the composition by issuer and maturity, the reserve ratio, and the name of the third party providing the attestation. Any deviation between two consecutive monthly reports needs an accompanying narrative.

Bank-side reviewers do not read your safeguarding policy. They read the account name on the mandate form. A safeguarding account titled "[Firm] — Operations 2" provides no insolvency protection no matter what your internal ledger says. The naming convention is the legal trigger.

The pattern that banks across the EEA, UK, Singapore and the UAE recognise consistently:

• Operating: "[Legal entity name] — Operating Account"

• Safeguarding: "[Legal entity name] — Safeguarding Account — Customer Funds" (or "Client Money" in the UK).

• Reserve: "[Legal entity name] — Reserve Account — [ART/EMT ticker] Asset Backing"

Every safeguarding mandate must be accompanied by a bank acknowledgement letter — a tri-party document signed by the firm and countersigned by the credit institution. The letter confirms the bank: (a) recognises the safeguarding character of the account, (b) waives any right of set-off, lien or combination of accounts, (c) will not freeze the account against any liability of the firm, and (d) will provide statements directly to the auditor on request.

Reconciliation is not a back-office task. It is the primary control that converts a paper safeguarding regime into a real one. Under FCA SYSC 19F⁵ and equivalent EEA expectations, reconciliations are run ^[5]at least once per business day, with documented investigation of every break above a defined materiality threshold.

For a high-volume CASP or EMI, daily is the floor; intra-day reconciliation — every two to four hours during trading windows — is best practice. Three reconciliations matter:

1. 1

   Internal reconciliation — customer-level sub-ledger total vs. firm-level safeguarding ledger control account.

2. 2

   External reconciliation — firm-level safeguarding ledger vs. bank statement balance for the safeguarding account.

3. 3

   Reserve reconciliation — tokens in circulation × par value vs. reserve account composition statement.

The EBA Guidelines on liquidity and operational risk management⁶ further expect firms to ^[6]stress-test the safeguarding pool against a same-day mass-redemption scenario. If the pool cannot meet a defined percentage of outstanding liabilities within a defined window, the architecture is over-leveraged and the wind-down plan is theoretical.

Three bank accounts demand three sub-ledgers inside the firm's core ledger system. Each sub-ledger has a control account in the general ledger; each control account reconciles daily to the matching bank statement. A single chart of accounts. A single source of truth.

Below the safeguarding control account, every customer has a sub-ledger of one — a personal balance that sums, across all customers, to the safeguarding control. Below the reserve control account, every token series has a sub-ledger. Below the operating control account, the standard expense and revenue accounts.

Journal entries that move money between the three pools are constrained by the ledger system itself, not just by policy:

• A hard whitelist of permitted account pairings (operating → reserve top-up, safeguarding → operating fee sweep, etc.).

• A four-eyes approval requirement on every inter-pool entry, with the second approver outside the treasury function.

• A daily exception report of every inter-pool entry sent to compliance and the MLRO.

• An immutable audit log — append-only, cryptographically chained, and accessible to the external auditor without firm-side intervention.

Firms that build the segregation in code, not in policy, pass safeguarding audits cleanly. Firms that rely on staff discipline alone do not.

A practical implementation pattern that survives both internal scrutiny and external audit: each of the three sub-ledgers lives in its own logical schema with role-based access enforced at the database layer. Treasury can post inside any one schema but cannot post across two without compliance counter-approval. The compliance officer holds the only key that authorises cross-schema journals, and every such authorisation generates a same-day report to the MLRO and a quarterly aggregate to the board risk committee.

Crypto-native firms operating across fiat rails and on-chain wallets face an additional architectural challenge: the safeguarding pool is bi-modal — part fiat at a credit institution, part crypto at a qualified custodian. The sub-ledger must reconcile both legs into a single customer balance expressed in the customer's chosen unit of account, while the underlying reconciliations to bank and to custodian run on different cadences and against different reference data. The discipline is the same; the plumbing is more demanding.

The annual safeguarding audit is a separate engagement from the statutory financial audit, governed by a regulator-issued agreed-upon procedures framework. Auditors run five tests that recur in every safeguarding programme:

1. 1

   Sample selection — a stratified sample of business days across the period, weighted to peak volume days and month-end cutoffs.

2. 2

   Cutoff testing — confirming that customer funds received by end-of-day T+0 reached the safeguarding account by end-of-day T+1.

3. 3

   Reconciliation walkthrough — tracing a sample reconciliation from customer sub-ledger to bank statement, inclusive of investigation papers for any break.

4. 4

   Method of Receipt (MoR) walkthrough — confirming every inbound rail (SEPA, SWIFT, card acquiring, crypto on-ramp) lands in the correct destination account first time.

5. 5

   Inter-pool transfer review — sample of every transfer between operating, safeguarding and reserve, tested against the approved whitelist and four-eyes evidence.

A clean opinion requires zero MoR exceptions, zero reconciliation breaks aged past T+1, and zero unauthorised inter-pool transfers across the sample. A qualified opinion triggers a notifiable event to the supervisor — and in the UK, almost certainly a Section 166 follow-on.

Preparing for the safeguarding audit is itself a year-round programme. The annual visit becomes painful only when controls have drifted between visits. The firms with the cleanest opinions run a quarterly internal safeguarding dry-run — same sample-selection methodology, same cutoff testing, same MoR walkthrough, performed by an internal audit function with reporting lines outside treasury. By the time the external auditor arrives, exceptions have been triaged and remediated, and the engagement becomes a confirmatory exercise rather than a discovery exercise.

The supervisor's view of the safeguarding regime is shaped at least as much by self-reporting as by audit findings. Firms that disclose a small reconciliation break promptly, with a clear remediation plan and an updated control, build supervisory credit. Firms that wait for the auditor to surface the same break six months later forfeit it. The cadence of communication with the regulator should match the cadence of the reconciliation: continuous, calm, and granular.

Yes, provided each account has a distinct mandate, a distinct name, and (for safeguarding and reserve) a signed acknowledgement letter waiving any right of set-off across the three. Concentration risk is a separate consideration: holding all three pools at a single credit institution exposes the firm to single-point banking failure. Most supervisors expect the safeguarding pool to be diversified across two or more credit institutions once the balance exceeds a defined materiality threshold.

Yes. Most regulators will not grant final authorisation without sight of the safeguarding mandate, the bank acknowledgement letter, and the reconciliation playbook. In-principle approval can sometimes be issued earlier, but live processing of customer funds is gated on full authorisation, which is gated on a fully architected safeguarding regime.

The safeguarded pool sits at the credit institution, so a bank failure puts the pool into the deposit guarantee scheme like any other deposit. The protection is per-depositor — the firm is treated as the depositor, not each end-customer. Diversification across two or more credit institutions, plus a portion of the pool held in secure, liquid, low-risk assets outside any single bank, is the standard mitigation.

Fees can be charged against the customer's safeguarded balance — that is the customer's money paying a service fee. The crystallised fee then ceases to be customer money and must be swept to the operating account on the same business day. Fee revenue parked in the safeguarding pool past T+0 is commingling.

Most do. Any CASP that handles client fiat — execution venues, brokers, exchanges, OTC desks — holds client money even when crypto custody is delegated to a qualified third-party custodian. The MiCA Article 70 safeguarding obligation applies to both fiat and crypto legs of the service.

• EMI Safeguarding Architecture: the underlying control framework that the three-account standard sits on top of.

• IBAN Architecture for Crypto Exchanges: virtual IBAN versus corporate IBAN structures that feed the safeguarding pool.

• Multi-Currency Treasury Operations: how to run FX positioning across operating and safeguarding without breaching segregation.

• AML Compliance Retainer for CASPs: ongoing oversight model that includes the daily safeguarding reconciliation sign-off.

Three accounts. Three legal bases. Three cadences. Architect them on day one, encode them in the ledger system, and the next supervisory inspection becomes a paperwork exercise rather than an existential event. The firms that survive the next decade of EMI, PI and CASP enforcement will be the ones who treated segregation as infrastructure, not as a policy document filed and forgotten.