A crypto firm can submit its MiCA application, answer the first round of questions and still have no clear idea whether it will get a licence.
The file may be complete. The lawyers may be satisfied with it. What remains unsettled is often more basic: the authority has not yet been convinced that the business described on paper can be run, controlled and supervised in practice.
That gap explains why applications slow down. It also explains why some never reach a formal refusal. The firm changes its plans, withdraws, or runs out of time while trying to fix problems that looked smaller when the file was submitted.
MiCA provides for both an initial completeness check and a substantive assessment. An authority usually sets a deadline for missing information and it may decline to review an application that remains incomplete. Once the file is complete, it can still ask further questions before deciding whether to grant or refuse authorisation. Passing the first check is not a prediction of the final result.
The questions tend to gather around a few difficult parts of the business: the services being offered, the people making decisions, the group behind the applicant and the systems protecting customers. There is no single “usual mistake.” More often, one of those areas leads the supervisor into another.
The application meets the business
An applicant typically arrives with a programme of operations and a list of MiCA services it wants permission to provide. The authority then has to work out whether that list describes what customers actually experience.
Take an exchange function. A customer sees a price, clicks to trade and receives crypto-assets. Behind that short journey, the firm may be acting as the customer’s counterparty, passing an order to another venue or operating the venue itself. The differences affect which services it needs authorised and how it manages conflicts of interest.
The same difficulty can appear in a group with several entities. One company contracts with the customer, another operates the platform and a third performs part of the transaction. The regulator needs to know where responsibility begins and ends. A group-wide description of “our platform” will not answer that.
This is an early point at which an application can stall. Clarifying the service may change more than one page of the file. It can affect customer terms, disclosures, the risk assessment, staffing and the financial plan. A firm that applied for a broad set of services may decide to narrow its request rather than defend an operating model it has not fully built.
ESMA explicitly identifies firms seeking a high number of crypto-asset services as candidates for elevated scrutiny. Combining services can create risks that a simpler operation does not face, particularly where the firm performs different roles in the same transaction.
There is also a temptation to apply for services the company expects to offer later. That can seem efficient: obtain a broad licence now and avoid another regulatory process when the product expands. The difficulty is that the authority assesses the applicant in front of it. Plans for a future desk, future staff or an unfinished system may not establish that the firm can provide the service safely at the point of authorisation.
Complete does not mean ready
MiCA’s completeness stage checks whether the required information has been submitted. It is not a judgment that every arrangement in the file works. That comes later.
The distinction sounds procedural until an applicant receives a follow-up question it cannot answer without changing the business.
Imagine a firm whose AML policy says alerts will be reviewed by its compliance team. During assessment, the authority asks about the team’s workload. There is one person in the role, and the growth forecast assumes a steep increase in customers. The answer may require another hire, a different monitoring process and a revised budget.
None of that means the original file was missing its AML policy. The policy was there. The difficulty lies in whether the firm can carry it out.
The same pattern appears in financial forecasts. A business plan may fund product development and customer acquisition generously while assuming that risk, compliance and support costs will remain almost flat. ESMA tells supervisors to examine realistic three-year projections, including what would happen if revenue fell well below expectations.
A downside scenario is useful precisely because it can force a choice. If income disappoints, does the firm still have enough people to monitor transactions and safeguard customers? If not, the proposed business may need more capital, a narrower launch or both.
This is where applicants can underestimate the cost of changing course. Adding two people to compliance does not only alter the staffing chart. It changes the budget, the reporting lines and possibly the timetable for launch. Replacing a provider may mean retesting systems and rewriting contracts. The file can be revised, but it takes time to make the new version describe a business that is actually ready.
Why clarification requests multiply
A request from a supervisor may look narrow when it first arrives. Often it is not.
Ask how a firm reviews suspicious transactions and the answer may lead to its monitoring provider. Ask about that provider and the discussion moves to data access, service failures and who can change the system’s settings. From there it reaches the board: what information does management receive, and what has it done with it?
The questions are connected because the operation is connected. An alert is not handled solely by the AML policy. It depends on software, staff, escalation rights and management oversight.
Applicants sometimes respond by supplying a revised document for each question. That may satisfy a discrete request while leaving contradictions elsewhere in the file. The outsourcing schedule names one provider; the technical description names another. The forecast assumes a new compliance hire next year, while the AML procedure assigns that person work from the first day of operation.
At that stage, the useful response is not necessarily another lengthy explanation. It may be a decision about the business itself: postpone a service, make the hire earlier, or change who controls a critical process. The paperwork should follow that decision, not stand in for it.
Who runs the EU firm?
For groups entering Europe, the local applicant may be only one part of a much larger operation. That is not inherently a problem. It does, however, make the location of decision-making important.
ESMA asks supervisors to look beyond a registered office and identify whether the EU entity can make decisions on its EU business. It expects sufficient personnel in the authorising country and wants authorities to be satisfied that effective management does not sit elsewhere.
In practice, that can become an uncomfortable discussion. Local managers may attend the meetings, yet need approval from a non-EU parent before changing a product or suspending a service. A supervisor may ask them to explain a technology incident and discover that only another group company has access to the relevant system. The EU entity then has to show how it can discharge responsibilities it cannot directly control.
Outsourcing sharpens the issue. A firm is allowed to use external providers, including companies in its own group. It still needs the knowledge and authority to oversee their work. ESMA says arrangements should not strip the CASP down to a “letter-box entity”; where outsourcing prevents effective supervision, its guidance says the application should be rejected.
This is not an argument against outsourcing. It is a reason to examine the arrangement before submission. A signed contract is little comfort if the applicant cannot obtain information promptly, respond to an outage or challenge the provider responsible for a critical service.
The hardest cases may involve providers the company has relied on for years. Replacing a vendor that runs the platform is very different from changing an adviser. Even if the applicant accepts a supervisor’s concern, it may not be able to remedy it quickly enough to keep the application moving.
People, history and judgment
A licence application also asks the authority to place confidence in the people behind the firm.
A strong product founder may be surrounded by managers whose regulated-finance experience is limited. That can be addressed by building a suitable team. It cannot be addressed simply by giving people impressive titles in an organisation chart. ESMA’s guidance calls for supervisors to consider the knowledge and suitability of management, as well as whether compliance has the capacity and independence to do its work.e
Past problems receive attention too. ESMA says a firm’s supervisory history, including that of group companies, shareholders and key people, can justify closer scrutiny. Earlier violations do not necessarily disqualify a manager; the authority should examine the circumstances and what the person learned.
Binance’s Greek MiCA bid offers a public glimpse of that pressure, though not a definitive account of a rejected application. In June 2026, Reuters reported that the exchange was expected to lose its Greek licence bid. Binance said it believed the application met the requirements and that it had received no formal indication otherwise. The company subsequently withdrew the application and said it would seek another route into Europe. 1090
According to Reuters’ sources, officials had concerns about Binance’s earlier financial-crime penalties, international structure and senior management. Binance pointed to its investment in compliance. Greece did not publish a final refusal explaining its assessment, so those reported concerns should not be recast as formal findings against the application. 1092
The broader point is that a regulator will not assess a new policy without regard to the firm proposing it. If a company has had serious compliance problems, it should expect close examination of the changes made since then—and of the people now responsible for keeping those changes in place.
There is room for a candid account of an earlier failure. A company can describe the incident, identify the control that failed and show how it tested the replacement. That is more useful to an assessor than a long statement about commitment to compliance. The first gives the supervisor something to examine; the second asks to be taken on trust.
When the technology matters
Crypto licensing is not only a review of directors and policy manuals. The authority also needs to understand the systems through which customers use the service.
A custody arrangement, for instance, cannot be assessed without knowing who controls access to assets and what happens when a provider fails. A monitoring system needs more than a description of its software: alerts must reach people who can investigate and act. An incident plan should survive contact with the technology on which the business depends.
The importance of that work became clearer in a case where a licence was granted, not refused. In a 2025 peer review of Malta’s authorisation of an unnamed CASP, ESMA said several material issues were unresolved at the time of approval. Its reviewers found insufficient evidence that aspects of the firm’s growth plans, conflicts of interest, governance, ICT infrastructure, custody arrangements and certain AML risks had been adequately assessed.
The finding was directed at the authorisation process; it was not a finding that the applicant had been rejected. It shows why supervisors may be reluctant to leave significant questions for after approval. ESMA’s reviewers argued that key deficiencies should have been remedied before the licence became effective. Malta’s regulator accepted the review’s findings while pointing to its expertise and supervisory work.
For an applicant, the practical consequence is clear enough. A request for a demonstration of a system or an explanation of a provider’s role should not be treated as a minor documentary follow-up. It may be the point at which the authority decides whether a material risk has been settled.
There is an important difference between saying that an incident procedure exists and showing how it would work. The supervisor may want to know who notices an outage, how quickly the firm learns which customers were affected and whether staff can still access the information needed to protect their assets. Those answers depend on the design of the system and the agreements around it, not the quality of a policy summary.
How a bid ends
There are several ways for an application to stop, and calling all of them “rejections” obscures what happened.
A file may remain incomplete after the applicant has been given time to supply missing information; MiCA permits the authority to refuse to review it. A complete application may proceed through assessment and end in a formal refusal. Or the company may withdraw before that decision—perhaps because it needs to rebuild part of the business, or because the changes required no longer make commercial sense.
These outcomes say different things. An incomplete file has not necessarily had its business model assessed. A withdrawal may reflect a decision by the firm rather than a final judgment by the supervisor. A formal refusal, by contrast, follows an assessment that ends without authorisation.
That distinction is especially important when discussing named companies. Without a public decision, outsiders may know that a bid ended and still know very little about the authority’s exact reasoning. Binance is an example: the withdrawal is public, and concerns were reported, but no detailed Greek refusal was published. 1092
Applicants can also be caught between the assessment timetable and the end of a transitional period. ESMA told unauthorised CASPs facing the 2026 deadline to prepare an orderly wind-down, stop taking on new EU clients and explain to existing clients what would happen to their services and assets. A pending application did not remove that practical problem.
For an operating firm, the deadline changes the stakes of every unresolved question. Hiring a director or changing a provider might be possible with another six months. With only weeks remaining, the same task may force a decision about customer onboarding, service restrictions or withdrawal.
Before the file goes in
The best preparation is a review that treats the application as an account of the business today, rather than a description of what it hopes to become.
Follow one customer from registration through a transaction and, if relevant, a withdrawal or complaint. Identify the legal entity, staff member, system and provider involved at each stage. Then introduce a problem: a monitoring alert, a failed transfer or an unavailable vendor. See who has the information and authority to deal with it.
The exercise may reveal a missing contract, an unrealistic workload or a decision that is still made outside the EU applicant. Those findings can be inconvenient. They are easier to address before submission than during an assessment in which every change has consequences for other parts of the file.
Finally, put the staffing plan beside the financial forecast. A business that can afford its controls only if growth follows the most optimistic projection has built little room for delay. A narrower service offering, a larger funding buffer or a later launch may make for a less exciting plan. It may also make for a more credible application.
MiCA applications stall at the point where a supervisor needs evidence and the firm has only an intention. Sometimes the evidence can be supplied. Sometimes the business has to change first. The firms most likely to avoid a long, uncertain process are the ones that discover that difference before the regulator does.
Sources:
- Regulation (EU) 2023/1114 on Markets in Crypto-Assets (MiCA)
- ESMA, Supervisory Briefing: Authorisation of CASPs under MiCA
- ESMA, Fast-track peer review on a CASP authorisation and supervision in Malta
- ESMA, Public Statement on the End of the MiCA Transitional Period
