Across Malta's regulated payment and virtual-asset environment, client funds safeguarding is a mandatory legal obligation – not a banking best practice. Every electronic money institution (EMI), payment institution and, increasingly, every CASP (crypto-asset service provider) authorised under the Malta Financial Services Authority (MFSA) regime must ring-fence client money from its own operating capital before accepting a single euro of customer funds. Failure to do so exposes the business to supervisory enforcement, provisional licence suspension and, in extreme cases, the permanent loss of its ability to operate in the EU. This page sets out the regulated basis, the practical steps and the cross-border interactions that matter most for inbound digital-asset businesses.
Why safeguarding is non-negotiable for Malta-regulated entities
Client funds safeguarding is, at its core, a creditor-protection rule. It ensures that if the institution fails, client money is separated from the insolvency estate and returned to clients first. Under the Malta framework, the MFSA enforces this obligation as a licence condition – meaning non-compliance is not a civil matter between the firm and its clients. It is a regulatory matter between the firm and its supervisor.
Malta sits within the EU regulatory perimeter. An EMI or payment institution authorised by the MFSA benefits from EU passporting rights, but that passport carries a corresponding obligation to meet the same safeguarding standards that apply across every other member state. For CASPs, MiCA (the EU Markets in Crypto-Assets Regulation) introduces parallel asset-protection rules for client crypto holdings that layer on top of the existing payment-sector requirements. The MFSA supervises both regimes, and the convergence of payment-law and MiCA safeguarding obligations is now the defining compliance challenge for hybrid EMI-CASP structures in Malta.
In our practice, we regularly see inbound operators underestimate this convergence. A business that already holds an EMI licence and then adds a MiCA CASP activity discovers, quickly, that the safeguarding regimes do not simply overlap – they interact, and they require separate structural decisions about how client fiat and client crypto are held, segregated and reported.
What does the MFSA regime actually require?
The MFSA's safeguarding rules for payment institutions and EMIs follow three recognised methods, each of which must be chosen and documented in the licence application. The first method requires that client funds be placed in a segregated account at an authorised credit institution – meaning a bank, not a payments intermediary. The second method requires the funds to be covered by a qualifying insurance policy or comparable guarantee from a credit institution. The third method, available in limited circumstances, allows investment in low-risk, highly liquid assets specified by the regulator.
In practice, most Malta-licensed operators use the first method. That sounds straightforward. It is not. The challenge is that finding a credit institution willing to open a segregated client-funds account for a crypto-adjacent EMI is a material operational risk. Banks in Malta and across the EU assess CASP-adjacent businesses as high-risk counterparties. Some decline outright. Others impose onerous due-diligence requirements that can delay the account opening by weeks or months.
For CASPs, MiCA introduces an additional layer. Client crypto-assets must be segregated from the CASP's own holdings at the custodial level – not merely at the accounting level. The MFSA, acting as the competent authority under MiCA for Malta-domiciled CASPs, expects to see documented custodial arrangements that address key management, access controls and the segregation audit trail before a CASP authorisation is confirmed.
Operators we advise routinely discover this requirement late in the application process. By that point, the custodial provider selection has already been made, and re-structuring the arrangement delays the licence by a material period.
To map the safeguarding structure that fits your licence profile and banking reality, contact OBOLUS at info@oboluslaw.com. The process above describes the standard path. Your facts – the entity type, the user base geography and the banking relationships you already have – change the analysis at every step.
How EMI onboarding and fiat rails interact with client-money rules
For a digital-asset business that needs fiat rails alongside its on-chain activity, the EMI structure in Malta is often the most practical EU entry point. An EMI licence (electronic money institution licence) issued by the MFSA permits the issuance of electronic money and the provision of associated payment services, with full EU passporting once the MFSA has notified the relevant host-state competent authorities.
The onboarding path for an inbound CASP seeking EMI-backed fiat rails typically runs as follows. The business first determines whether it will itself hold the EMI licence or whether it will onboard as a client to an existing licensed EMI. The latter path – sometimes called EMI onboarding – is faster but introduces a contractual dependency on the EMI's own AML/KYC policies, transaction monitoring thresholds and, critically, its own account-opening criteria for crypto-adjacent clients.
EMIs operating in Malta are themselves subject to MFSA supervision and to the FATF Travel Rule (the obligation to pass originator and beneficiary data with a virtual-asset transfer), as transposed into EU law. An inbound CASP that routes fiat settlement through a Malta-licensed EMI must therefore ensure that its own Travel Rule compliance feeds correctly into the EMI's reporting architecture. Misalignment between the CASP's transfer data and the EMI's reporting creates a joint compliance exposure.
The cross-border dimension is significant. A Malta-domiciled EMI passporting services into Germany, France or Poland will be subject to the host-state AML/CFT supervisory authority as well as to the MFSA. We have seen situations where a Malta entity's host-state notification was technically complete but its safeguarding documentation had not been updated to reflect the passported activity – a gap that led to a supervisory information request from the host competent authority within months of launch.
How does the VFA-to-MiCA transition affect safeguarding obligations?
Malta introduced its Virtual Financial Assets (VFA) framework – regulated by the MFSA – before the EU adopted MiCA. That framework required VFA service providers to appoint a VFA agent (a regulated intermediary between the provider and the MFSA) and to comply with asset-protection rules specific to the VFA regime. Those rules differed in material respects from the safeguarding obligations now imposed by MiCA.
Under the MiCA transition schedule, existing VFA licence holders are migrating to CASP authorisation under MiCA. The MFSA has indicated that transition arrangements apply for existing licence holders, but the migration is not automatic. Each entity must demonstrate that its safeguarding, governance and disclosure arrangements meet MiCA standards. For businesses that structured their custody and client-money arrangements around the VFA regime, the gap analysis is non-trivial.
The key safeguarding differences concern crypto-asset custody specifically. MiCA requires that client crypto-assets be held under a documented custody agreement with a CASP or third-party custodian that itself meets the relevant authorisation requirements. The VFA framework had no equivalent explicit custodial-authorisation requirement. Operators migrating from VFA to MiCA therefore face a structural step that goes beyond updating their compliance manual – it requires renegotiating or re-documenting the actual custody arrangement.
We advise clients at the gap-analysis stage of this migration. The practical timeline varies by the complexity of the custody structure and by how far the existing VFA documentation can be mapped to MiCA requirements, but operators who begin the gap analysis early are materially better positioned when the MFSA's transitional deadline arrives.
What banking risks do Malta crypto businesses face and how should they plan?
Account de-risking is the single largest operational risk for Malta-licensed digital-asset businesses. The risk is not hypothetical. We have seen crypto-adjacent operators lose their primary fiat account with minimal notice, leaving client funds temporarily outside any formal safeguarding arrangement while a replacement account was sought.
The structural answer is multi-banking – maintaining segregated client-money accounts at more than one institution, in more than one jurisdiction where possible, before the primary relationship fails. For a Malta-licensed EMI or CASP, the practical options extend to accounts at EU-licensed credit institutions in other member states, accounts at EMIs that themselves hold EU passports, and, for larger operators, the use of BVI or Cayman-domiciled treasury structures to hold operating capital separately from regulated client funds.
The cross-border banking strategy must, however, be structured carefully. Client funds held in a non-EU account by a Malta-licensed entity may not satisfy the MFSA's safeguarding requirements unless the account institution meets the qualifying credit-institution standard under the applicable EU rules. A business that routes client funds offshore for banking convenience risks a safeguarding breach even if the funds are, in a commercial sense, safe.
A further consideration is the interaction with Malta crypto law on capital requirements. The MFSA sets own-funds requirements by licence category. An operator that depletes its own capital in an effort to cover client liabilities because the segregated account was inaccessible – a scenario we have encountered in the context of sudden account closures – faces a simultaneous capital breach and a safeguarding breach. The two reinforce each other in the worst possible direction.
If your banking structure needs a second read before you commit, map your options with OBOLUS: message us here. If a prior application stalled or an account was closed, a structural review can surface the reason and the route forward.
Illustrative scenario: safeguarding gap discovered mid-licence transition
In a recent cross-border matter, a Malta-licensed operator was in the process of migrating from its existing VFA authorisation to a MiCA CASP structure when its primary banking partner issued a 30-day account-closure notice. The timing created a dual problem: the operator needed to document a new safeguarding account as part of its MiCA transition submission to the MFSA, but it had no confirmed replacement bank. We conducted a rapid jurisdiction-by-jurisdiction assessment of qualifying EU credit institutions and identified two institutions in separate member states willing to open segregated client-money accounts for the business within the relevant window. We then worked with the operator's internal compliance team to update the safeguarding documentation and submit the revised arrangements to the MFSA within the transition deadline. The licence migration proceeded without an enforcement gap.
Which safeguarding structure fits your operating profile?
The right safeguarding structure depends on what the business does, who its clients are and where they are located.
A payments-first operator – a business whose primary activity is fiat settlement and whose crypto exposure is incidental – will typically seek an EMI licence from the MFSA, use the segregated bank-account method for safeguarding, and structure its crypto custody as a secondary arrangement with an authorised third-party custodian. The timeline to a functioning safeguarding structure, from initial application to operational go-live, varies considerably depending on banking lead times, which are the dominant variable.
A CASP-first operator – a crypto exchange or custody provider whose fiat activity is ancillary – will typically prioritise the MiCA CASP authorisation and layer the fiat safeguarding requirement on top by onboarding to an existing Malta or EU-licensed EMI, rather than holding the EMI licence itself. This profile accepts a contractual dependency on the EMI partner but avoids the capital and governance burden of a second regulated licence.
A hybrid operator – a business offering both payment services and crypto-asset services to EU clients – faces the most complex safeguarding structure. It must maintain separate documentation trails for client fiat and client crypto, comply with both the payment-sector safeguarding rules and MiCA's custody requirements, and ensure that the two regimes' reporting obligations to the MFSA are met simultaneously. This profile almost always requires a dedicated compliance officer and documented procedures that address the boundary between the two regimes explicitly.
In each case, the cross-border dimension adds a layer of analysis. Where clients are located outside Malta or outside the EU, the applicable AML/CFT obligations of those client-facing jurisdictions interact with the MFSA's requirements, and the safeguarding documentation must reflect that interaction.
A common assumption about Malta licensing is worth addressing directly
A common assumption is that obtaining a Malta licence – whether VFA, CASP or EMI – creates a ready-made global permission to serve clients in any country. It does not. The MFSA licence regulates the Malta entity. It does not authorise that entity to provide regulated services in jurisdictions that maintain their own VASP, payment or crypto-asset licensing requirements. A Malta CASP serving clients in the United Kingdom, for example, must also consider the FCA's cryptoasset registration and financial-promotion rules. A Malta EMI passporting into a member state must notify the host competent authority before it begins operating there.
The safeguarding obligation mirrors this jurisdictional reality. A Malta-licensed entity that holds client funds for clients in multiple jurisdictions must ensure its safeguarding arrangements are documented in a way that satisfies not only the MFSA but, where host-state supervisors have a view, those supervisors as well. We map the licence stack across operating, custody and payment layers before a client commits to a structure – precisely because the local licence is the beginning of the analysis, not the end.
The payment licence question, the fiat-rails question and the crypto banking question are not three separate problems. They are one structural decision, made once, with consequences that run through every subsequent compliance and banking interaction the business has.
Related at OBOLUS
- Banking, Payments & EMI Onboarding for Digital-Asset Businesses – the full practice overview covering EMI structuring, fiat-rail strategy and account-opening across leading jurisdictions.
- Corporate Bank Account Opening in the Seychelles – a practical guide to offshore account access for digital-asset operators seeking banking diversity.
- Stablecoin Freeze Requests in Singapore – how on-chain asset recovery intersects with MAS-supervised stablecoin infrastructure.
FAQ
Why do banks close crypto company accounts?
Banks close crypto company accounts primarily because of risk-appetite policies rather than specific regulatory prohibitions. Digital-asset businesses are classified as high-risk under most EU and UK AML frameworks, which increases the bank's compliance cost and supervisory exposure. Banks apply a commercial judgment: if the cost of maintaining the relationship – in compliance resource, regulatory scrutiny and reputational risk – exceeds the revenue, the account is closed. The most effective mitigation is demonstrating, at the account-opening stage, a well-documented AML/KYC programme, a clean corporate structure and a clear business model. Reactive remediation after a closure notice is significantly less effective than proactive structuring at the outset.
How can a VASP onboard with an EMI?
A VASP seeking fiat rails through an existing licensed EMI must first pass the EMI's own client due-diligence process, which typically involves corporate documentation, AML/KYC policy review, a business-model assessment and, in many cases, a compliance questionnaire specific to virtual-asset activities. The EMI evaluates the VASP as it would any high-risk business client. Where the VASP's Travel Rule compliance and transaction-monitoring architecture align with the EMI's own regulatory obligations, the onboarding process is faster. Misalignment – for example, insufficient transaction-data fields or weak sanctions-screening – is the most common cause of EMI onboarding delays or rejections. Preparation of the compliance documentation pack before the first EMI approach is the practical starting point.
What does client-money safeguarding require?
Client-money safeguarding requires a licensed payment institution or EMI to hold client funds separately from its own operating capital at all times. The standard method is a segregated account at an authorised credit institution, held in a way that identifies the funds as client money and protects them from the firm's insolvency estate. For CASPs under MiCA, the equivalent obligation applies to client crypto-assets: they must be held under a documented custody arrangement that segregates them from the CASP's own assets at the custodial level. Documentation, regular reconciliation and reporting to the MFSA are mandatory components, not optional enhancements.
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 that sit around them. Digital assets are the whole of our practice. We map the licence stack across operating, custody and payment layers before you commit – because the local licence is the beginning of the analysis, not the end. We also work alongside forensic partners to convert on-chain evidence into court-ready disclosure applications. To discuss your situation, contact info@oboluslaw.com.
By Victor Olsen, Regulatory & Compliance Analyst – specialising in MFSA licensing, MiCA transition structuring and cross-border payment 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.