MFSA Malta License: where the application breaks during review
An application for an MFSA Malta license breaks not on the form but on the mismatch between the business model and the regulatory class.
A company describes exchange and custody services but requests a license under a narrow class — the regulator compares the declared operations with the actual asset flow and sees a discrepancy.
The regulator’s requirements for an application test not declarations but how operations are executed.
The second break point is the source of client funds and the origin of capital: the wording “funds come from clients” does not pass; you need an ownership tree down to ultimate beneficial owners, verified sources, and segregation of client funds from the company’s capital. A weak disclosed source of funds is the most common reason for license refusal.
The third area is transaction traceability and separation of functions within the team.
You need end-to-end accounting from asset receipt to withdrawal, regular reconciliation of wallets with internal ledgers, a separate person responsible for the compliance function and a separate one for anti-money laundering.
When trading, custody, and control are handled by one person, the regulator reads this as a lack of independent control.
We build compliance for a crypto company under Maltese jurisdiction from the business model: first we fix the regulatory class and the list of operations, then build policies, accounting, and role allocation for them. We work out how to close this before submitting the application.
What regulated status in Malta provides: timelines and risks
Regulated status in Malta is not a one-off document but a regime of ongoing reporting: while the license is active, every new service and change in ownership structure must go through approval.
That is why the package is assembled backwards — first the actual operations are described, and only then are the documents prepared.
Review timelines and repeat regulator requests
Most of the time is consumed not by the regulator but by the request-response cycle. One round of clarifications adds several weeks to the application review period, and with a poorly described operating model there can be three or four rounds.
We prepare answers in advance to the typical MFSA questions: how revenue is generated, who the ultimate owners are, and how client identification and client fund custody are structured.
The class of refusals that is closed before submission
- Discrepancy between declared activity and actual operations in the system.
- Gaps in substantiating the source of funds for owners and clients.
- Lack of monitoring of suspicious transactions and retention of their history.
Any such gap means either the application is returned for revision or, worse, there is a risk of operations being suspended after the license is issued.
The burden on the team during review falls on lawyers, engineers, and financial control simultaneously — we close it with regulations and a responsibility matrix before launch, not during the approval process.
Ways to obtain and maintain regulated status
The choice of path is not about the speed of submission but about which regime will withstand subsequent review. The regulator looks at actual responsibility for operations, not the form of the application.
| Option | When it fits | Limitations |
|---|---|---|
| Own license | There is a staff of key positions; processes are built before submission | Long review; key roles must be within the jurisdiction; reporting and audit regardless of turnover |
| VFA agent | Market entry is needed now, with the control function outsourced | Responsibility for the agent remains with you; decisions are coordinated; changing the agent rebuilds processes |
| Purchase of a licensed company | There are resources for legal due diligence and integration | Inherited obligations of previous owners; divergence of processes from those declared removes status |
| Phased entry | Demand needs to be tested with a narrow set of operations | The initial regime limits acceptance of third-party funds and work with some instruments |
Limitations of each option
The agency model is cheaper at the start, but control is split: a disputed case goes through coordination, and incident response time increases. Buying a company shortens the path to the first operation but transfers the seller’s decision history to you.
What the regulator checks first
The presence of a management structure, not a paper one: who is responsible for compliance, how client asset accounting is structured, how suspicious transactions are recorded and investigated.
Separately — resilience: verified capital, segregated fund custody, and a recovery plan after failure.
Stages of work: from model audit to handover of regulations
The work proceeds sequentially: each stage relies on the artifacts of the previous one. The regulator returns a dossier assembled without a model audit — therefore the order of steps is fixed, not chosen for convenience.
- Business model audit. We analyze where value comes from, who holds client funds, and which operations pass through your infrastructure. The output is a flow map and a conclusion about which status brings you under regulation.
- License class and list of services. We match the model to the regulator’s requirements and fix which operations you are entitled to provide and which must be moved outside the perimeter or delegated to a partner.
- Dossier preparation. Business description, ownership structure, origin of funds, information about management and key employees, questionnaires, and supporting documents.
- Design of control processes. Procedures for client checks, transaction monitoring, investigation of suspicious activity, segregated custody of client funds, and handling conflicts of interest.
- Technical implementation. Transaction accounting and reporting extracts, roles and access rights, action logging, regular asset reconciliation — so that control does not rely on manual reminders.
- Handover of regulations. We train the team, hand over the package of procedures and templates, and stay in touch until the regulator’s decision and the first reviews.
Who participates on the client side
The product owner confirms that the described model matches the actual one. The technical lead is responsible for implementing controls in the system, and the business line manager is responsible for timelines and communication. We take on the wording and correspondence with MFSA.
How long each stage takes
The model audit takes from a few days to a couple of weeks. The dossier and process design take up most of the timeline: it depends on the number of services and the ownership structure.
We implement controls in parallel with approval, and we give exact boundaries after the audit — not before.
What remains with you after compliance implementation
Compliance is not a folder with a final report but a set of working documents that the team acts on every day. Below is what exactly remains in your hands after implementation.
Policies and regulations
- anti-money laundering policy aligned with the requirements of the Maltese regulator, with a description of its scope;
- client check procedures: risk levels, list of requested data, procedure for handling discrepancies;
- transaction monitoring regulations: trigger thresholds, escalation rules, response times to an alert;
- rules for processing and storing personal data with role-based access differentiation.
Flow charts and responsibility matrix
- fund flow charts from incoming payment to withdrawal: control points and the person responsible at each stage;
- responsibility matrix: for each procedure, it is clear who approves, who executes, and who signs the reporting;
- logs and reporting: templates for transaction logs, review registers, and periodic reports to the regulator with completed examples;
- compliance documentation map: full list, update deadlines, and owner of each document.
The set remains with you and works without our involvement: a new employee is onboarded into the procedures according to the document, not a retelling. A response to a regulator’s request is assembled from ready logs, not reconstructed from correspondence.
Case study: from regulator refusal to working status
Three refusals in a row is a typical entry point for projects where tokenomics and corporate structure were designed separately from the regulator’s requirements.
They came to us after the third return of the dossier, when timelines agreed with investors had already slipped: the regulator saw a gap between the declared rights of token holders and the actual scheme for obtaining them.
This is a licensing case where the cost of an error is not individual comments but the entire product launch.
What it was before
The application was assembled in fragments: the ownership structure was split across two jurisdictions, none of the directors was a resident, and the internal anti-money laundering rules existed as a template document without any link to real operations.
Suspicious transaction monitoring had no responsible person, and reporting diverged from what was declared in the dossier. The result was 38 comments in three letters, and not a single submission reached an interview with management.
What changed after
Holder rights were separated by class: income distribution and voting were described in separate documents, disclosure on major holders and their sources of funds was added.
The dossier was reassembled in full — from the ownership scheme to client identification procedures; a compliance officer and a resident director were appointed, and regular internal audit of operations was introduced.
After resubmission, the share of comments closed in the first round rose from zero to around 90%, and the review itself took half the time of the shortest rejected application.
The status is confirmed in the public MFSA register: the entry is open for verification by counterparties and banks.
What to do if the business already operates in another jurisdiction
The question is not where to obtain a license but what to do with the already operating perimeter: client contracts, accounts, reporting to the current regulator, and transaction history.
An MFSA license does not transfer this history by itself — it must be repackaged for the new supervision.
The choice comes down to three schemes: change of jurisdiction, a dual structure, and recognition of status in the EU through passporting of an existing authorization. The scheme is selected based on the function map, not the speed of document submission.
| Option | When it fits | Limitations |
|---|---|---|
| Transfer of structure | One operational center; ready to change regulator | Consent of the current regulator, re-registration of contracts and payments, re-audit |
| Dual structure: holding and Maltese company | Existing authorizations and client flows need to be preserved | Separation of functions, transfer pricing justification, dual reporting |
| Recognition of status in the EU: passporting | There is already a license in an EEA country, and the product matches | Works only within the directive and does not cover new types of activity |
The key is the separation of functions between companies.
Fund acceptance, custody, trading operations, marketing, and IT are assigned to a specific legal entity with its own staff and powers: the regulator checks that the Maltese company conducts activity rather than resells access to the license.
The order of work: audit of the current perimeter, function and flow map, choice of scheme, coordination with the current regulator, transfer, and repeat compliance audit.
Separately, we design a rollback — if the transfer is not approved on time, the operating perimeter remains in service.
Common technical doubts before submitting an application
Doubts before submitting an application to MFSA are almost always technical rather than legal: how presence on the island is proved, who is responsible for reporting, and what may be done before status is assigned. Below are five questions that most often come up during dossier preparation, with short answers.
Is a real office needed, and is a local director mandatory?
Formally, an address and presence in the jurisdiction are required, not a “mailbox”. Review practice includes a lease agreement, workspaces, and a local resident director with real powers and signature authority.
A scheme with a nominee director without access to operations and bank accounts falls apart during review.
What are the requirements for management and key employees?
A dossier is collected for each person: confirmation of qualifications and experience, criminal record certificates, disclosure of shares, affiliated companies, and conflicts of interest.
The regulator assesses business reputation and the ability to manage this specific class of activity, so experience in an adjacent field must be described substantively.
How does the reporting review work?
The composition of regular reporting, the audit procedure, and data storage are approved. The key is consistency: figures in the report are reconciled with transaction history, operation logs, and internal regulations. A divergence between the declared model and actual records is the most common cause of questions.
What can be done before obtaining status?
Preparatory work — yes: development, infrastructure, regulations, hiring. Attracting clients and conducting operations in the regulated line of business — no.
The launch plan is built so that technical readiness occurs before status, but public activity is switched on only after it.
Are systems and access separation reviewed?
Yes. They look at key storage, action logging, employee roles and rights, and recovery after failure.
If access is granted to everyone and there are no immutable logs, this is closed before submission — reworking the infrastructure after comments takes longer than designing it for the requirements from the start.
Let's discuss the structure and application submission plan
For the discussion of an MFSA license in Malta to be substantive rather than a general overview, drafts and factual inputs are enough for the first conversation — perfect documents are not required at this stage.
We will analyze the business model, determine the applicable registration class, and come back with a timeline estimate and an application submission plan where each stage is tied to a responsible person and a result.
What is worth preparing for the conversation:
- Product description: what exactly the platform does — exchange, custody, token issuance, capital raising. Both the license class and the scope of the regulator’s requirements depend on this.
- Ownership structure: where the current legal entity is registered, who the owners and directors are, whether a Maltese company and a holding company above it are planned, and whether there are affiliated structures in other jurisdictions.
- Management details for business reputation checks: experience in the financial sector, participation in other companies, supporting documents for key individuals.
- Movement of client funds: where assets are stored, how company and client funds are separated, who is responsible for private keys, and how cold storage is organized.
- Current internal control and KYC procedures: even draft policies, the transaction monitoring procedure, and who is appointed as responsible for compliance.
- Calendar milestones: desired launch date and steps already taken — negotiations with a Maltese representative, code audit, applications in other countries.
Based on this list of inputs, we will build a realistic schedule: package preparation, interaction with the regulator, responses to its requests, and technical refinement of the platform to meet the requirements.
Describe the task — we will come back with a stage-by-stage timeline estimate and an application submission plan.