Client funds safeguarding for Established Operators

Established digital-asset operators already hold a licence, serve a live client base and move real money across real rails. Yet the question that surfaces most sharply at scale is not whether you can trade or custody – it is whether your client funds are held in a structure that satisfies the regulators, the banks and, increasingly, the payment-scheme rules that govern every fiat on-ramp and off-ramp you depend on. Client funds safeguarding – the legal and operational regime that segregates client money from firm money, ring-fences it against insolvency and ensures it is returned on demand – has moved from a compliance checkbox to a licence condition and a banking prerequisite across every major hub.

With regulators in the EU under MiCA (the Markets in Crypto-Assets Regulation), in Dubai under VARA (the Virtual Assets Regulatory Authority) and in Singapore under the Payment Services Act tightening their expectations on custody and safeguarding simultaneously, the gap between an operator's current structure and the required standard is often wider than internal compliance teams appreciate. This page sets out the regulated basis, the process, the cross-border interaction and the structural mistakes that cost operators their banking.

What is client funds safeguarding, and why does it matter at scale?

Client funds safeguarding is the obligation to hold client money separately from the firm's own assets, to protect it in the event of the firm's insolvency, and to maintain records that allow instant reconciliation and return. It is not a voluntary best practice. In every regulated jurisdiction – from the EU's MiCA CASP authorisation regime to the VARA activity-based licences and the MAS Payment Services Act – safeguarding is a condition of the licence itself.

At startup scale, the obligation is often met with a single pooled safeguarding account at a cooperative bank. That structure works until it does not. Growth creates two failure points. First, client money pools grow large enough to attract bank risk-appetite reviews. Second, the operator expands into new jurisdictions where the local regulator applies its own safeguarding standard – and the original structure does not travel.

In our practice, we see operators discover mid-audit that their pooled account arrangement does not satisfy the safeguarding definition the regulator applies in the new operating market. The cost is not a fine. It is the forced pause of a business line while the structure is rebuilt under regulatory scrutiny.

The cross-border dimension is acute. An operator licenced in the EU may passport its CASP authorisation across member states. But the payment accounts that hold client fiat are subject to the rules of the credit institution or EMI (electronic money institution) that provides them – rules that vary by the EMI's home jurisdiction and by the payment scheme it accesses. A safeguarding account in one member state may not satisfy a host-state regulator's expectation if the host state imposes additional local segregation requirements.

What does the regulated basis actually require?

The core requirement across leading regimes is that client funds are: (1) held in a designated account that is legally separated from firm funds; (2) not commingled with operational money; (3) reconciled daily against client liability records; and (4) immediately identifiable and returnable on the firm's insolvency.

Under MiCA, CASPs that hold client crypto-assets and funds are subject to explicit safeguarding obligations, including requirements on how client money is deposited, which institutions may hold it and how records are maintained. ESMA and the national competent authorities have signalled that they will scrutinise custody and safeguarding arrangements closely during the authorisation process and in ongoing supervision.

Under VARA in Dubai, the safeguarding expectation is embedded in the activity-specific rulebooks. Operators holding client fiat as part of an exchange or transfer/settlement activity must demonstrate that the holding arrangement is legally segregated and operationally robust before VARA grants or renews the relevant activity licence.

Under the MAS Payment Services Act in Singapore, major payment institutions – a category that applies to most digital-payment-token service providers operating at meaningful volume – must hold client funds in a trust account or as a guarantee backed by an insurance or bank guarantee. The specific mechanism and the capital that accompanies it are set by the applicable MAS notices.

The FCA in the United Kingdom applies its client-money rules from the broader financial-services regime to registered cryptoasset businesses where those businesses also hold regulated funds. The interaction between the MLR registration regime and the client-money framework is an area where operators regularly underestimate their exposure.

How do banks and EMIs assess safeguarding structures before onboarding?

Banks and EMIs do not simply check that a safeguarding account exists. They assess whether the operator's legal structure, its licence and its operational controls will survive a regulatory challenge – because their own prudential obligations depend on it.

A typical EMI onboarding review for an established crypto operator will examine: the operator's licence type and the safeguarding obligations that attach to it; the corporate structure (which entity is the counterparty, and is it the entity that actually holds client money?); the AML/KYC programme and the Travel Rule compliance posture; the jurisdictions in which clients are based; and whether the operator's own client-money accounts are held with a credit institution that satisfies the EMI's internal concentration rules.

In our cross-border practice, operators consistently underestimate the last point. An EMI that provides fiat rails to a crypto exchange is effectively a correspondent to that exchange's banking relationships. EMIs manage that exposure actively. An exchange whose underlying client-money accounts are held with a bank the EMI does not recognise – or in a jurisdiction the EMI's compliance team flags – will fail onboarding regardless of its licence quality.

The practical answer is a documented banking stack map: a legal memorandum that identifies every entity in the operator's structure that touches client money, the legal basis on which it holds it, the institution that provides the account, and the jurisdiction of each link in the chain. This document does not exist by default. It is built deliberately, before the onboarding conversation begins.

If your current fiat rails depend on a single EMI relationship or a single pooled account, the process above describes the standard path. Your specific facts – entity structure, user base geography, banking counterparties – change the analysis significantly. To map the licence, banking and safeguarding stack for your operation, write to OBOLUS at info@oboluslaw.com.

What are the most common structural mistakes established operators make?

A common assumption among operators reaching Series B or beyond is that a single offshore licence is sufficient to serve clients globally and that a single safeguarding account satisfies all applicable obligations. Both assumptions are wrong, and the gap between assumption and reality is where regulatory enforcement concentrates.

The first mistake is relying on a VASP registration in a jurisdiction that has not yet aligned to the FATF Recommendation 15 standard or to MiCA-equivalent safeguarding requirements. That registration may have been sufficient at the time of grant. As the regulatory environment tightens, the operator's actual client base – and the banks serving that client base – increasingly require evidence of a licence that satisfies a recognisable standard. Banks in particular have tightened their own internal policies on the quality of the licence they will accept from a crypto-operator counterparty.

The second mistake is corporate fragmentation without legal clarity. Operators that grow through acquisition or that structure for tax efficiency sometimes end up with the licensed entity, the entity that holds client money and the entity that operates the technology sitting in three different jurisdictions. Each may be legally defensible in isolation. Together, they may not satisfy any regulator's safeguarding requirement, because the obligation runs to the entity that holds the client relationship – and that entity must also be the entity with the licence and the account.

The third mistake is timing. Operators approach banking and EMI relationships after the corporate structure is finalised and the licence is in place. By that point, restructuring to satisfy an EMI's requirements is expensive and slow. The structure should be designed with banking access in mind from the outset – or, for established operators, systematically reviewed before the next capital raise or market expansion triggers a fresh round of bank onboarding.

A fourth failure mode is AML programme debt. An operator that grew quickly may have an AML/KYC programme that worked at lower volumes but has not scaled with the business. Banks and EMIs conducting due diligence at the onboarding stage will identify this. An underdeveloped transaction-monitoring programme, a thin Travel Rule compliance posture, or an incomplete sanctions-screening procedure will end an onboarding process regardless of the operator's licence.

How does cross-border operation affect the safeguarding obligation?

Cross-border operation multiplies the safeguarding obligation. It does not simply extend it. Each jurisdiction in which an operator has clients, holds fiat or accesses payment infrastructure may apply its own safeguarding standard, and those standards do not always align.

The MiCA passporting mechanism is the clearest example. A CASP authorised in one EU member state may serve clients across the EEA without a separate local licence. But the safeguarding obligation under MiCA runs across all of those client relationships. If the CASP holds client money in an account at a credit institution in its home member state, that account arrangement must satisfy not only the home state's implementation of the safeguarding obligation but also the expectations of the national competent authorities in the host states – which may differ in practice, particularly during the transition period as national implementing measures bed in.

The AIFC and AFSA framework in Kazakhstan presents a different dynamic. The AIFC operates under English common-law principles, and the safeguarding concepts that AFSA applies track closely to FCA-era thinking on client money. An operator licenced in the AIFC that also holds an EU CASP authorisation must therefore satisfy two distinct legal frameworks governing the same client funds – and must document that it can do so.

In the UAE, the interaction between VARA (which covers mainland Dubai) and ADGM/FSRA (which covers the Abu Dhabi Global Market financial free zone) means that an operator with presences in both must manage safeguarding obligations under two separate regimes. DIFC-based operators face a further layer. Failing to distinguish which entity is the licence-holder and which is the account-holder in each of those contexts is a frequent source of regulatory friction.

Banking access across this geography typically requires the operator to demonstrate a coherent group-level safeguarding policy that subsumes the local requirements in each jurisdiction. Allied counsel in the relevant jurisdiction are necessary wherever local implementation diverges from the group policy.

A recent matter: safeguarding restructure ahead of a licensing expansion

In a recent engagement, a digital-asset exchange that had operated under a legacy registration for several years sought to onboard with a European EMI as part of its expansion into the EU market under MiCA. The EMI's compliance review identified that the operator's client fiat was held in a pooled operational account – not a dedicated safeguarding account – at a bank in a jurisdiction the EMI's internal policy flagged as elevated-risk. The exchange's own legal team had not identified this as a safeguarding deficiency, because the original registration had not imposed explicit account segregation requirements.

We were engaged in the later part of that year to map the full banking and safeguarding stack, identify the specific deficiencies against the MiCA CASP safeguarding standard and the EMI's own requirements, and design a restructured arrangement. That work involved coordinating with allied counsel in the EU member state where the CASP application was lodged, advising on the account migration and producing the banking-stack memorandum the EMI required. The EMI onboarding completed within the operator's target window, and the CASP authorisation process continued on schedule.

Which safeguarding structure fits which operator profile?

The right safeguarding structure is not universal. It depends on the operator's licence type, client base, fiat volume and the jurisdictions it operates in.

Profile A – EU-licenced CASP with cross-border client base. The operative regime is MiCA, with ESMA and the relevant NCA as supervisors. The required structure is a designated safeguarding account at a credit institution or an EMI that itself holds a payment institution authorisation in the EU. The account must be legally segregated, and the institution must satisfy the NCA's expectations on counterparty quality. The indicative timeline for establishing the structure, once the institution is identified, is a matter of weeks – but the institution identification and due-diligence process often takes longer than operators expect. The key risk is EMI concentration: relying on a single EMI for all client-fiat access creates a single point of failure.

Profile B – VARA-licenced exchange expanding to the EU or Singapore. The operator holds a VARA activity licence for exchange services in Dubai. Its client-fiat obligation under VARA is addressed through a UAE-based banking arrangement. As it expands, it must layer on MiCA or MAS compliance without unwinding the UAE structure. The indicative approach is a separate EU or Singapore entity holding the applicable licence, with its own safeguarding account in that jurisdiction, at an institution that satisfies the local standard. The parent entity's VARA arrangement continues. The risk is entity fragmentation: two licensed entities, two safeguarding accounts, two AML programmes – each must be internally consistent and externally defensible.

Profile C – Established operator with legacy registration, seeking EMI onboarding. This is the most common profile we see at BOFU engagement. The operator has operated under a registration that did not impose explicit safeguarding requirements. Banks and EMIs have begun imposing those requirements through their own due diligence. The path forward is a structured gap analysis, a banking-stack map and, in most cases, either an upgrade to a full CASP/VASP licence in a recognised jurisdiction or the layering of a licensed payment vehicle over the existing structure. Timelines are longer – typically several months – and the sequencing of the licence upgrade, the corporate restructuring and the banking outreach must be managed carefully to avoid a period where the operator has no viable fiat rails.

If a prior EMI application stalled or a banking account was closed, a second review of the structure usually surfaces the specific deficiency. To map the path back, contact OBOLUS at info@oboluslaw.com.

Self-assessment: is your safeguarding structure sufficient?

The following questions are a starting point for an internal review. They are not a substitute for legal analysis, but they identify the areas where established operators most frequently carry unrecognised exposure.

Is the entity that holds client fiat the same entity that holds the relevant licence? If not, is there a documented legal basis for the arrangement that satisfies both the licensing regulator and the institution providing the account?

Is the client-money account designated as a safeguarding or trust account in the account agreement with the bank or EMI? A general operating account with a credit balance is not a safeguarding account, regardless of how it is labelled internally.

Does the institution holding the account satisfy the regulator's counterparty quality requirements? Under MiCA, for example, the institution must meet a defined standard. Under VARA, the VARA rulebook specifies the type of institution that may hold client money.

Is the reconciliation process documented and running daily? Regulators expect to see operational evidence of reconciliation, not just a policy. AML programme completeness: does the transaction-monitoring programme scale to current volume, and is the Travel Rule implemented across all applicable transfers?

Has the structure been reviewed since the last licence upgrade, corporate restructuring or banking relationship change? Each of those events can create a new gap between the existing arrangement and the current obligation.

Related at OBOLUS

Related at OBOLUS

• Banking, Payments and EMI Onboarding – the full service overview for digital-asset businesses seeking fiat rails and payment access
• EMI Onboarding for VASPs in Georgia – jurisdiction-specific guidance on accessing EMI relationships through the Georgian market
• Digital-Asset Licensing in Germany: BaFin – what businesses need to know about the BaFin regime and its interaction with MiCA

FAQ

Why do banks close crypto company accounts?

Banks close crypto company accounts when their internal risk assessment concludes that the operator's AML programme, licence quality or corporate structure does not meet the bank's own compliance obligations. Common triggers include an unrecognised or low-standard licence, an inadequate Travel Rule posture, client geography that the bank flags as elevated-risk, or a safeguarding structure that the bank cannot verify as legally segregated. The decision is usually a risk-appetite call, not a legal prohibition – which means a better-documented structure at a more appropriate institution can resolve it.

How can a VASP onboard with an EMI?

An EMI will onboard a VASP (virtual asset service provider) when it can satisfy its own compliance obligations with respect to that counterparty. That requires the VASP to present a recognised licence, a complete AML/KYC programme including Travel Rule compliance, a clearly documented corporate structure identifying which entity holds client money and on what legal basis, and a client base that the EMI's risk policies can accommodate. Preparation – including a banking-stack memorandum and a gap analysis against the EMI's known requirements – materially improves the onboarding success rate.

What does client-money safeguarding require?

At its core, client-money safeguarding requires that client funds are held separately from the firm's own money, in a designated account at a qualifying institution, reconciled daily against client liability records and protected from the firm's creditors in insolvency. The specific requirements – which institution may hold the account, what designation the account must carry, what records must be maintained – vary by jurisdiction and by licence type. Under MiCA, VARA and the MAS Payment Services Act, safeguarding is a condition of the licence, not a voluntary arrangement, and regulators verify compliance actively.

About OBOLUS

OBOLUS is an independent digital-asset law boutique acting only for businesses. We advise exchanges, custodians, token issuers and funds on licensing across 70+ jurisdictions, on disputes and on-chain asset recovery across 25+ forums, and on the tax, banking and compliance structures that sit around them. Digital assets are the entirety of our practice. We map the licence, banking and safeguarding stack across operating, custody and payment layers before operators commit – because the cost of a structural deficiency surfaces at the worst possible moment. To discuss your situation, contact info@oboluslaw.com or message us at t.me/oboluslaw.

By Victor Olsen, Regulatory & Compliance Analyst – specialising in licence structuring, safeguarding frameworks and cross-border regulatory analysis for established digital-asset operators.

This publication is general information about the law and does not constitute legal advice. It is not a substitute for advice tailored to your circumstances. OBOLUS accepts no liability for action taken or not taken on the basis of this material. For advice on your situation, contact info@oboluslaw.com.