Securing payment service provider (PSP) and acquiring arrangements in Malta is one of the most operationally critical steps a crypto business can take in the EU. Malta sits inside the MiCA (Markets in Crypto-Assets Regulation) perimeter, supervised by the MFSA (Malta Financial Services Authority), and its payment sector operates under the EU's Payment Services Directive regime as transposed into Maltese law. For a digital-asset business, the question is not simply whether a PSP will onboard you – it is whether your licence stack, your AML posture and your corporate structure meet the thresholds that Maltese and EU payment institutions require before they open fiat rails. This page maps the legal requirements, the process, and the cross-border angles that determine whether an agreement is reachable.
Operating without the right licence or without the structural hygiene that PSPs demand risks enforcement action, frozen payment rails and loss of banking at the worst possible moment. In our practice, that moment is almost always when transaction volumes peak.
What is the regulated basis for PSP activity in Malta?
A business that processes payments or settles acquiring transactions in or through Malta must either hold its own payment institution authorisation from the MFSA or operate as an agent or distributor of a licensed payment institution. The MFSA supervises payment services under the Payment Services Act as transposed from the EU Payment Services Directive framework. The MFSA also supervises virtual financial assets under Malta's prior VFA (Virtual Financial Assets) framework, which is now transitioning to the MiCA CASP (Crypto-Asset Service Provider) authorisation regime. These two regulatory tracks – payment services and virtual asset services – intersect directly when a crypto business needs to accept or settle fiat.
The practical effect: a crypto exchange or custodian that wants to onboard a Maltese PSP or acquirer must demonstrate compliance across both tracks. Payment institutions assess not just your business model but the licence you hold for your crypto activity, your AML programme, your beneficial ownership structure and the jurisdictions your users touch.
Malta's passporting rules matter here. A payment institution authorised in Malta can passport its services across the EU and EEA under the Payment Services Directive regime. Similarly, once a crypto operator holds a MiCA CASP authorisation in Malta, it can passport that authorisation across all EU member states. This creates a strategic rationale for Malta as a hub – but only for businesses that can sustain the MFSA's compliance expectations on both sides.
Which crypto businesses need a PSP or acquiring agreement in Malta?
Any digital-asset business that collects fiat from clients, settles trading profits in fiat, pays out redemptions or runs a card-to-crypto onramp needs a functioning PSP relationship. The need arises across at least four operator profiles.
A crypto exchange accepting card payments or bank transfers from EU retail users needs an acquiring agreement or a payment processing arrangement. Without one, fiat onboarding stalls. A custodian that holds client funds pending deployment needs a safeguarding account at a regulated institution – in Malta, this maps to the client-money rules enforced by the MFSA and the applicable EU payment regulation. A token issuer running a token sale or ongoing redemption cycle needs payment rails that can handle both inbound subscription proceeds and outbound redemptions in euro or other major currencies. A fund or lending protocol with fiat settlement legs needs an institutional PSP relationship that can withstand the fund's own AML and KYC audit trail.
In each case, the PSP or acquirer will conduct its own due diligence on the applicant. That due diligence mirrors – and in some respects exceeds – the MFSA's own licensing review.
If your business touches EU users and you have not yet mapped the licence, safeguarding and AML layers your PSP will audit, the gap between your current structure and what is required is likely larger than you expect. To get a scoped assessment of your position, contact OBOLUS at info@oboluslaw.com.
The process above describes the standard path. Your facts – the entity, the user base, the banking – change the analysis. Map your options.
How does a crypto business approach the PSP onboarding process in Malta?
PSP onboarding for a crypto business in Malta follows a structured sequence that begins well before the formal application to a payment institution. The first step is structural readiness: a Maltese or EU-authorised entity, a board-approved AML/CFT policy, a beneficial ownership chain that resolves to identified individuals, and a business model narrative that the PSP's compliance function can approve.
The second step is regulatory status. A Maltese PSP will require confirmation of the applicant's virtual asset licence or CASP authorisation status. During the MiCA transition period, businesses operating under the prior VFA framework in Malta are assessed against the MiCA transition schedule. New entrants seeking a CASP authorisation from the MFSA must factor the authorisation timeline into their PSP onboarding plan – a PSP will not open rails to a business whose regulatory status is pending without explicit comfort on the expected outcome.
The third step is the AML package. Malta's AML regime applies the FATF Recommendations, including Recommendation 15 on virtual assets and the Travel Rule (the obligation to pass originator and beneficiary data with a transfer above the applicable threshold). A crypto business seeking PSP onboarding must demonstrate Travel Rule compliance, a functioning transaction monitoring system and a record of suspicious transaction reporting to the FIAU (Financial Intelligence Analysis Unit), Malta's financial intelligence unit.
The fourth step is the commercial negotiation of the acquiring or processing agreement itself. The agreement will contain representations about the merchant's regulatory status, ongoing compliance obligations, audit rights for the PSP, transaction volume limits and dispute resolution mechanics. Legal review of these terms is not optional – the representations and ongoing obligations in a standard acquiring agreement can create material liability if the business's status changes post-signing.
What does the cross-border reality mean for Malta-based digital-asset businesses?
Malta is a small jurisdiction with an EU passport. The cross-border reality for a digital-asset business is that its users, its banking, its liquidity providers and its tax position will almost certainly span multiple jurisdictions simultaneously. The legal analysis cannot stop at the Maltese border.
Consider a crypto exchange incorporated in Malta, holding a CASP authorisation from the MFSA, serving users in Germany, France and the Netherlands. Under MiCA passporting, the exchange can serve those EU users from its Maltese base. But the PSP relationship may be with a Lithuanian or Irish payment institution that has its own supervisory relationship with its home NCA. The acquiring bank may be headquartered in Luxembourg. The stablecoin settlement leg may involve a Circle USDC reserve held in the United States. Each of these touchpoints has its own regulatory logic.
In our practice, we regularly advise businesses that have secured a Maltese VFA registration or CASP authorisation but have not mapped the consequential obligations their PSP agreement will impose on them in practice. The most common gap is the Travel Rule: the Maltese entity is compliant with the MFSA's Travel Rule expectations, but the PSP's own threshold for Travel Rule compliance data is set to a different standard, and the two systems do not reconcile cleanly.
Tax interaction is the second cross-border angle. A Maltese holding or operating company may attract a favourable corporate tax rate on trading profits, but the VAT treatment of payment processing fees, the withholding tax applicable to cross-border payments and the transfer pricing rules that apply when the Maltese entity transacts with group companies in other jurisdictions all require separate analysis. Malta has a developed tax treaty network and specific guidance on the VAT treatment of financial services – but applying that guidance to a crypto payment flow requires mapping the transaction structure before, not after, the PSP agreement is signed.
How do MFSA supervision and MiCA interact with PSP eligibility?
The MFSA's role as both the payment institution supervisor and the crypto-asset supervisor in Malta creates a dual-track compliance environment that PSPs actively monitor. A business that is out of good standing with the MFSA on its CASP authorisation – whether because of a pending AML finding, a condition attached to the licence or a lapsed registration – will find that its PSP relationships come under immediate pressure.
MiCA introduced a harmonised whitepaper obligation for most crypto-asset classes and a set of ongoing governance, capital and complaint-handling requirements for CASPs. For a Malta-based business, these obligations are enforced by the MFSA as the home NCA. PSPs conducting their own due diligence will look for evidence of whitepaper compliance where required, board-level accountability for the AML function and evidence that the business's capital position meets the applicable MiCA own-funds requirement.
The transition from Malta's prior VFA framework to MiCA is material. Businesses that were registered as VFA service providers under the VFA Act are required to seek CASP authorisation under MiCA within the transition window. A business that has not initiated that transition, or that is uncertain whether its prior registration covers the activities it is actually conducting, faces a material gap that a PSP due diligence process will surface.
We have seen businesses discover during PSP onboarding that their VFA registration covered a narrower set of activities than their actual business model. Rectifying that gap – whether by amending the authorisation scope or by restructuring the activity model – requires MFSA engagement and takes time. Starting PSP onboarding without resolving that gap means the process will stall.
A practical illustration
In a recent engagement, a crypto lending business incorporated in Malta sought to onboard a European payment institution as its primary fiat settlement partner. The business held a VFA service provider registration but had not yet applied for CASP authorisation under MiCA. The PSP's compliance team flagged the transition gap during preliminary due diligence. We were instructed to prepare a regulatory gap analysis, draft the MFSA transition notification and produce a remediation roadmap. We also reviewed the draft acquiring agreement and identified three representations the business could not make in good standing at that moment – including a representation about the completeness of its Travel Rule compliance programme. The agreement was restructured with a conditions-precedent mechanic tied to CASP authorisation milestones. The PSP relationship proceeded on a phased basis rather than collapsing.
What are the most common mistakes crypto businesses make in Malta PSP onboarding?
The four most common mistakes we see are structural, not operational. They can each be fixed – but earlier is significantly cheaper.
The first is treating PSP onboarding as a commercial process rather than a regulatory one. A PSP in Malta is a regulated institution. Its onboarding of a crypto client is itself a regulated activity under its own AML obligations. The due diligence it conducts on a crypto applicant is thorough and adversarial in the sense that a single gap – in the AML programme, in the licence status, in the beneficial ownership chain – will trigger a hold or a rejection. Approaching the process with a commercial mindset rather than a compliance mindset produces avoidable delays.
The second mistake is assuming that a single offshore licence is sufficient to satisfy a Maltese PSP. It is not. A PSP operating in Malta under the EU Payment Services Directive regime cannot take on a client whose only licensing basis is an offshore registration in a jurisdiction the FATF or the EU has flagged as high-risk or non-cooperative. The licence stack must be coherent with the jurisdictions where the business actually operates and where its users are located.
The third mistake is underinvesting in the Travel Rule infrastructure before approaching a PSP. Most Maltese payment institutions have their own Travel Rule obligations. They will not create a compliance risk for themselves by onboarding a crypto business that cannot demonstrate a functioning Travel Rule programme. The programme must exist and be documented before the PSP conversation begins.
The fourth is signing an acquiring agreement without legal review of the ongoing compliance representations and the event-of-default provisions. A PSP agreement that allows the PSP to suspend settlement upon any regulatory investigation – even one that is resolved without finding – creates an existential operational risk if it is not negotiated down to a more defined trigger.
If a prior PSP application stalled or an account was closed, a structural review can identify the reason and the route back. Write to OBOLUS at info@oboluslaw.com or message us at t.me/oboluslaw.
If a prior application stalled or an account was closed, a second read can surface the structural reason and the route back. Map your options.
Which operator profile should pursue which approach?
Not every crypto business will follow the same path to PSP onboarding in Malta. The right approach depends on the operator's existing regulatory status, its user base and its transaction volume.
A business that is already authorised under MiCA as a CASP in Malta and has a documented Travel Rule programme and a completed AML audit is the strongest candidate for direct PSP onboarding. The timeline from a complete application to a functioning PSP relationship is a matter of weeks in this profile, assuming the business model is straightforward and the acquiring volumes are within standard thresholds.
A business in the VFA-to-CASP transition window that has initiated its MFSA authorisation application but has not yet received it should approach PSP onboarding in parallel with the authorisation process, structuring the PSP agreement with conditions precedent tied to authorisation milestones. This profile adds complexity but does not foreclose the path.
A business that has no Maltese licence and is considering Malta as its EU hub should map the CASP authorisation process as the first step, with PSP onboarding planned for the period immediately following authorisation. Attempting PSP onboarding before initiating the authorisation process wastes both time and relationship capital with the PSP.
A business that operates in multiple EU jurisdictions and is considering Malta specifically for its PSP relationship – without intending to hold its primary CASP authorisation there – needs specific advice on whether the entity structure and activity model supports that approach under MiCA's passporting rules and the PSP's own onboarding policy.
What does client-money safeguarding require for PSP eligibility?
Client-money safeguarding is a distinct and non-negotiable condition for PSP eligibility in Malta. Under the EU payment regulation framework as transposed and supervised by the MFSA, payment institutions and their clients must maintain safeguarding arrangements that protect client funds from insolvency risk. For a crypto business, this means that fiat funds received from clients – pending conversion, settlement or withdrawal – must be held in a segregated account at a credit institution or invested in liquid low-risk assets, and must not be commingled with the business's own operating funds.
A PSP will require evidence of compliant safeguarding arrangements before opening settlement rails. For a crypto business, this often requires opening a segregated safeguarding account at a separate Maltese or EU-regulated bank – which itself requires the same structural readiness the PSP demands. The two processes run in parallel and must be coordinated.
In our practice, we regularly advise businesses that have underestimated the safeguarding requirement. The typical failure mode is a business that holds client fiat in its own operating account, describes this as "segregated" in its policies, and then discovers during PSP due diligence that the arrangement does not meet the legal standard. Rectifying this after the fact – when a PSP relationship has already been offered conditionally – is possible, but it compresses timelines and increases execution risk.
Related at OBOLUS
- Banking, Payments and EMI Onboarding for Digital-Asset Businesses – how we map the full fiat-rail stack for crypto operators across jurisdictions
- PSP and Acquiring Agreement in Australia under AUSTRAC – the equivalent analysis for the Australian regulatory environment
- AML Audit Defence for Digital-Asset Firms – legal counsel when a regulator or PSP challenges your AML programme
FAQ
Why do banks close crypto company accounts?
Banks close crypto company accounts primarily because of AML risk appetite, not legal prohibition. A crypto business that cannot demonstrate a documented Travel Rule programme, a clear beneficial ownership structure and a credible transaction monitoring system presents a compliance burden the bank has not underwritten. Regulatory pressure on banks to manage their exposure to high-risk sectors means that any gap in the crypto client's compliance posture typically triggers account closure rather than a remediation conversation. Structural readiness before approach is the only reliable mitigation.
How can a VASP onboard with an EMI?
A VASP (virtual asset service provider) seeking to onboard with an EMI (electronic money institution) must present a complete compliance package: a current licence or authorisation in a recognised jurisdiction, a board-approved AML/CFT policy, Travel Rule compliance documentation, a beneficial ownership disclosure and a business model narrative the EMI's compliance team can approve. The EMI will conduct its own risk assessment. In our practice, the process moves fastest when the VASP has anticipated the EMI's due diligence checklist and resolved each item before the formal application is submitted.
What does client-money safeguarding require?
Client-money safeguarding under EU payment regulation requires that fiat funds received from clients be held in a dedicated segregated account at a regulated credit institution, separate from the business's own operating funds and protected from the firm's insolvency. The safeguarding account must be clearly designated and the safeguarding arrangements must be documented in the business's operational procedures. A PSP or EMI will require evidence of compliant safeguarding before opening settlement rails. Non-compliant arrangements – including nominally "segregated" accounts that do not meet the legal standard – are a common ground for PSP rejection.
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. We map the licence stack across operating, custody and payment layers before you commit – so the PSP conversation begins from a position of structural strength, not remediation. We advise crypto exchanges, custodians, token issuers and funds across more than seventy licensing jurisdictions. Digital assets are the whole of our practice. To discuss your situation, contact info@oboluslaw.com.
Ready to map your PSP and acquiring structure in Malta? To pressure-test your structure before you commit, message us via t.me/oboluslaw or write to info@oboluslaw.com. Map your options.
By Victor Olsen, Regulatory & Compliance Analyst – specialising in MFSA and MiCA compliance requirements for digital-asset businesses seeking EU payment and acquiring arrangements.
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.