A crypto-native payments company recently discovered that its banking relationship in one jurisdiction had been suspended – not because of any regulatory breach, but because its EMI onboarding documents did not demonstrate compliant client-funds safeguarding in the jurisdictions where its users sat. The fiat rails went dark. Payroll stalled. Merchant settlement halted. The business had a licence. It did not have a defensible safeguarding posture.
Client funds safeguarding from a cross-border perspective is one of the most consequential – and most frequently underestimated – obligations in digital-asset and payments law. An EMI (electronic money institution) or licensed VASP (virtual asset service provider) that collects, holds or transmits client money must ring-fence those funds against its own insolvency, maintain the segregation evidenced by auditable records, and satisfy each regulator in each jurisdiction where it operates or where its users are located. The regime applicable in the entity's home jurisdiction is the starting point. It is rarely the ending point. This page sets out the regulated basis, the common structural mistakes, and the cross-border decisions that determine whether your safeguarding posture will survive a regulatory review or a banking correspondent's due-diligence questionnaire.
What client funds safeguarding actually requires under the applicable regime
Client funds safeguarding is a ring-fencing obligation: money received from clients in the course of regulated payment or e-money activity must be isolated, at all times, from the operator's own funds and from the claims of the operator's creditors in insolvency. This principle is embedded in the payment-services and e-money frameworks of every major licensing jurisdiction – from the Payment Services Act in Singapore and the MiCA-adjacent regimes across the EU to the FSRA framework in ADGM and the VARA rulebooks in Dubai. The mechanics vary, but the structural requirement does not: client money is not corporate money.
In practice, safeguarding is achieved through one of two methods or a combination of both. The first is segregation into a designated account at a credit institution or an authorised custodian, held separately from the operator's own accounts. The second is coverage by an eligible insurance policy or guarantee. Most regulators in the licensed-payments space require the segregated-account route as the primary mechanism, with insurance as a supplementary option. The record-keeping obligations that accompany either method are substantial: operators must be able to demonstrate, at any moment and in real time, that client funds are held correctly and that reconciliations are current.
Under MiCA, for operators issuing EMTs (e-money tokens) or holding client assets in a CASP context, the own-funds and reserve requirements sit alongside the safeguarding obligation, not instead of it. ESMA and the national competent authorities have made clear that a pass-through structure that converts client fiat into tokens and holds the reserve in an unregulated wallet does not satisfy safeguarding – it compounds the risk. In our practice, we see this architectural mistake repeatedly in early-stage token projects moving from whitepaper to live product.
How does cross-border operation complicate the safeguarding obligation?
A single-jurisdiction licence rarely covers the full perimeter of a cross-border digital-asset business, and the gap between entity domicile and user geography is where most safeguarding failures occur. The entity may be authorised by the Bank of Lithuania as a CASP under the MiCA transition. Its users may be in Brazil, the Gulf and Southeast Asia. Its banking is in a third country. Each of these relationships triggers a distinct set of rules – and the sum of those rules is not automatically satisfied by compliance with any one of them.
The tension is structural. The regulator in the entity's home jurisdiction looks at how client funds are held by that entity. The regulator in the user's jurisdiction looks at whether the operator is permitted to serve its residents at all – and may impose its own safeguarding or local-account requirements as a condition of lawful operation. The correspondent bank in the middle runs a risk assessment that encompasses all of it. If any layer is missing, the correspondent's answer is typically to close the account rather than to engage in a remediation dialogue.
We regularly advise businesses that have built their licence stack around a single EU or offshore vehicle, then scaled into markets where local registration, a local account structure, or a local safeguarding ring-fence is required. The MAS Payment Services Act in Singapore, for example, draws a meaningful distinction between major payment institutions – which hold above a defined transaction or float threshold – and standard payment institutions, with different safeguarding expectations attaching to each. The SFC in Hong Kong and the VARA regime in Dubai each impose their own client-asset segregation requirements. Operating in those markets through a remote licence does not satisfy the local expectation.
For a business with users in more than two or three jurisdictions, the safeguarding question is never "what does our home regulator require" – it is "what does every regulator with a claim over our users' funds require, and how do we satisfy all of them simultaneously." That is a structural design problem, not a compliance-checklist problem.
The process above describes the standard path. Your facts – the entity type, the user geography, the banking relationships – change the analysis significantly. For a scoped assessment of your safeguarding architecture, contact OBOLUS at info@oboluslaw.com.
What are the most common structural mistakes in cross-border safeguarding?
The most persistent mistake is treating the safeguarding obligation as a banking task rather than a legal-structural one. Operators open a designated account, mark it in the chart of accounts, and consider the matter closed. They have addressed one element of the obligation. They have not addressed the legal analysis that tells them whether that account structure is the right vehicle in each jurisdiction where they operate, whether the institution holding the account satisfies the eligible-custodian test, or whether the reconciliation methodology will withstand a regulatory inspection.
A second common failure is the omnibus account problem. Many cross-border operators pool client funds from multiple jurisdictions into a single omnibus account at a single correspondent institution. This is operationally convenient. It is legally fragile. If the regulator in any operating jurisdiction requires individual client-level segregation, or requires that the holding institution be domestically authorised, the omnibus structure fails that test. Worse, it can create waterfall priority problems in an insolvency that the operator's board never anticipated.
A third failure pattern is the collapse of the distinction between the operator's own treasury – including operational reserves, token holdings and working capital – and the client float. We have seen businesses where the e-money float and the operating wallet were co-mingled in a single exchange account, with only an internal accounting entry making the separation. That entry is not safeguarding. It is a record of an intention to segregate, which is not the same thing.
The fourth mistake is EMI onboarding without a clear safeguarding narrative. EMI onboarding for a VASP requires the operator to demonstrate to the EMI – before any account is opened – that its own client-funds regime is legally coherent and operationally auditable. EMIs that onboard VASPs take on risk through the correspondent relationship. They want to see the legal opinion, the trust structure or the eligible-institution confirmation, and the reconciliation policy. Operators that arrive without these documents are declined – and the declination is rarely explained in detail, so the operator does not understand what to fix.
How does the safeguarding design change by operator profile?
The right safeguarding architecture depends on the operator's licence category, geographic footprint, and client-money volume. The following decision matrix describes three common profiles in our cross-border practice.
Profile A – EU-licensed CASP or EMI with European users and no non-EU operations. The MiCA and e-money frameworks provide a relatively coherent safeguarding regime. The obligation is to hold client funds at an authorised credit institution in a segregated account, maintain daily reconciliations, and file the required attestations with the relevant national competent authority. Passporting within the EU/EEA means the home-state authorisation covers outbound services to other member states. The principal risk is the quality of the banking relationship: not every EU credit institution will open a designated safeguarding account for a VASP, and the ones that will may impose enhanced due-diligence requirements that add weeks to the process. Timeline to compliant structure: a matter of weeks from account approval, assuming the legal documentation is ready.
Profile B – Multi-jurisdictional operator licensed in an offshore hub serving users in Asia, the Gulf and Latin America. This is the highest-complexity profile. The operator typically has a BVI or Cayman vehicle, an ADGM or VARA licence for the Gulf, MAS registration for Singapore, and user bases in markets where it has no local registration at all. Each licensed jurisdiction imposes its own safeguarding expectations. Each user-facing jurisdiction may require local registration as a precondition for serving residents. The banking requirement is typically a multi-account structure across two or three correspondents. A single safeguarding policy cannot satisfy all of these simultaneously; the operator needs a jurisdiction-by-jurisdiction matrix and a treasury architecture that can implement it. Timeline to compliant structure: variable, and dependent on banking-onboarding speed, which is the rate-limiting factor.
Profile C – Payment institution or VASP in a single emerging-market jurisdiction scaling outbound. The home-jurisdiction regime may be less prescriptive on safeguarding mechanics than MiCA or the MAS framework. The operator scales into the EU or the UK. The EU correspondent or the UK EMI now applies a MiCA-standard or FCA-standard safeguarding test to the incoming operator's structure, regardless of what the home regulator requires. The gap is often the absence of a formal trust declaration or eligible-institution confirmation. The fix is a legal restructure of the holding arrangement, not a new licence. Timeline: weeks if the analysis is done promptly; months if it requires re-papering the banking arrangements.
How does a VASP onboard with an EMI, and where does safeguarding fit?
EMI onboarding for a VASP is a compliance-to-compliance negotiation, not a standard account-opening process. The EMI's compliance function will review the VASP's licence, its AML/KYC framework, its transaction-monitoring policies, and – critically – its client-funds safeguarding architecture. The VASP that arrives with a comprehensive safeguarding policy, a legal opinion confirming its compliance with the applicable regime, and an auditable reconciliation methodology is materially more likely to be onboarded than one that cannot answer the EMI's due-diligence questionnaire in full.
The Travel Rule (the obligation to pass originator and beneficiary data with a virtual-asset transfer, derived from FATF Recommendation 15) is a separate but adjacent point. EMIs that hold fiat rails for VASPs increasingly require evidence that the VASP has a Travel Rule solution in place that covers the jurisdictions in which it operates. This is not, strictly speaking, a safeguarding requirement. But in practice it is reviewed in the same due-diligence exercise, and a missing Travel Rule policy is a ground for declination that an operator focused only on the safeguarding question may not have anticipated.
In a recent matter, a payments company sought EMI access for its stablecoin settlement operation across three European markets. The EMI's initial response was a request for documentation of the safeguarding structure in each operating jurisdiction. We prepared the jurisdiction-by-jurisdiction analysis, confirmed the eligible-institution status of the existing holding bank, and provided a trust declaration template that satisfied the EMI's standard. Onboarding completed in less than a quarter of the originally projected timeline. The safeguarding documentation was the rate-determining factor throughout.
What is the cross-border banking and fiat-rails reality for digital-asset businesses?
Fiat rails – the correspondent banking infrastructure that moves money across borders and across currencies – remain the most acute operational constraint for digital-asset businesses. The reason is not purely regulatory. It is partly structural: correspondent banks operate under their own regulator's AML and financial-crime expectations, and a VASP client that cannot demonstrate clean client-funds segregation creates a financial-crime risk that the correspondent is not compensated to manage.
The practical consequence is that VASP banking is concentrated among a relatively small number of crypto-friendly institutions and EMIs in each region. Those institutions apply consistent and demanding standards to onboarding. An operator that fails the safeguarding review at one institution will typically find that the refusal – while not formally shared between institutions – is reflected in how other institutions approach the same diligence request. The reputational contagion of a failed EMI onboarding is real and is underappreciated.
The cross-border dimension sharpens the problem. A VASP operating across the EU, the Gulf and Southeast Asia needs fiat rails in each currency area. Each rail requires an institutional relationship. Each institutional relationship requires a safeguarding narrative that is coherent in the applicable local regime. There is no shortcut that substitutes a single global correspondent for a properly constructed regional banking structure. Operators that attempt the shortcut – routing all flows through a single offshore EMI regardless of where the underlying client funds sit – run the risk of that EMI being the point of failure that takes down the entire payment stack.
We map the banking and fiat-rail architecture as part of the same engagement in which we review the safeguarding structure. The two are not separable problems. If a prior application stalled or an account was closed without a clear explanation, a second structural read can identify the specific gap and the route back to a compliant position. Write to us at info@oboluslaw.com.
Self-assessment: is your cross-border safeguarding posture defensible?
The following checklist is not a substitute for legal advice, but it surfaces the questions a regulator or a correspondent bank will ask.
- Is every designated safeguarding account held at an institution that qualifies as an eligible credit institution or eligible custodian under the regime applicable to your licence?
- Is the account legally segregated – meaning that a creditor of the operator could not attach the funds in an insolvency – and is that segregation documented in a trust declaration, escrow agreement or equivalent?
- Do daily reconciliations run between the client-money ledger and the designated account balance, and is the methodology documented in a written policy reviewed by your compliance function?
- For each jurisdiction outside your home licence where you serve clients or hold client money, have you identified whether local registration, a local holding account, or a local safeguarding structure is required?
- Does your EMI onboarding documentation include a jurisdiction-by-jurisdiction safeguarding analysis, or does it reference only the home-jurisdiction regime?
- Is the distinction between client funds and the operator's own treasury funds maintained at the account level – not only at the accounting-entry level?
- Does your safeguarding policy address the treatment of client funds in stablecoins or other digital assets, or does it cover fiat only?
A "no" or "uncertain" answer to any of these is a gap that a regulator or correspondent will identify. In our cross-border practice, the most consequential gaps are typically the second (legal segregation, not just accounting separation) and the fourth (no local-jurisdiction analysis beyond the home licence).
Related at OBOLUS
- Banking, Payments and EMI Onboarding for Digital-Asset Businesses – the full practice overview covering banking access, EMI relationships and fiat-rail structure.
- Payment Institution Licensing in Brazil – how Brazil's payment-institution regime affects cross-border safeguarding obligations for businesses serving Brazilian users.
- Governance Expectations for Boards of Licensed VASPs – the board-level accountability framework that regulators apply to safeguarding and client-asset oversight.
FAQ
Why do banks close crypto company accounts?
Banks close crypto-company accounts primarily because they cannot satisfy their own AML and financial-crime obligations in relation to the account activity. The most common specific triggers are: absence of a compliant client-funds safeguarding structure that the bank can document for its own regulator; inadequate transaction-monitoring or Travel Rule compliance; and the operator's failure to demonstrate a clear legal separation between client money and operating funds. A well-documented safeguarding posture and a comprehensive EMI onboarding package materially reduce – though do not eliminate – this risk.
How can a VASP onboard with an EMI?
A VASP seeking EMI onboarding should prepare a full compliance file before approaching the institution. That file typically includes: the VASP's licence and regulatory status in each operating jurisdiction; its AML/KYC and transaction-monitoring policies; evidence of a compliant client-funds safeguarding structure, including the designation of an eligible holding institution; a Travel Rule solution covering applicable jurisdictions; and, where required, a legal opinion confirming the regulatory basis for its cross-border operation. Operators that present this documentation proactively materially shorten the onboarding timeline and reduce the risk of unexplained declination.
What does client-money safeguarding require?
Client-money safeguarding requires, at minimum: holding client funds in a designated account legally segregated from the operator's own money; using an eligible institution as the account holder; maintaining real-time or daily reconciliation between the client-money ledger and the account balance; and documenting the arrangement in a trust declaration or equivalent instrument. Under most major regimes – including MiCA, the MAS Payment Services Act and the VARA rulebooks – these obligations apply in each jurisdiction where the operator holds client funds, not only in the home-licence jurisdiction.
About OBOLUS
OBOLUS is an independent digital-asset law boutique acting only for businesses. We advise exchanges, custodians, token issuers and payment companies on licensing across 70+ jurisdictions, on disputes and on-chain asset recovery across 25+ forums, and on the banking, safeguarding and compliance architecture that sits around them. We map the licence stack across operating, custody and payment layers before you commit – identifying the gaps that create banking risk before a correspondent finds them. Digital assets are the whole of our practice. To discuss your cross-border safeguarding posture, contact info@oboluslaw.com or reach us via t.me/oboluslaw.
By Victor Olsen, Regulatory & Compliance Analyst – specialising in cross-border regulatory architecture, EMI onboarding frameworks and client-funds compliance for digital-asset businesses.
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.