BULGARIA Trends and Developments Contributed by: George Chisuse, Ivelin Vassilev and Stephany Valcheva, VC Law
A crypto exchange that is not ready to answer these questions in detail is not ready to file. MiCA does not licence “a crypto exchange” as a general label Many founders describe their project as a crypto exchange. That is understandable commercially, but it is not precise enough for MiCA. MiCA regulates specific crypto-asset services. A platform may need authorisation for operating a trad- ing platform, exchanging crypto-assets for funds, exchanging crypto-assets for other crypto-assets, custody and administration, transfer services, execu- tion of orders, reception and transmission of orders, placing of crypto-assets, advice or portfolio manage- ment. The FSC’s own MiCA FAQ addresses the ser- vices requiring authorisation and the different classes of authorisations, which is a useful starting point for applicants. This is where many projects make their first strategic mistake. They apply for the services they think they need today, without checking what the platform is likely to become in 12 or 18 months. For example, a business may initially want to provide crypto-to-fiat exchange only. Later, it may add client wallets, staking-related features, order routing or a marketplace where users trade with each other. Each of these features can change the regulatory analysis. If the original authorisation is too narrow, the business may later find that its licence does not support the product roadmap. The licence strategy should therefore be built around the intended operating model, not only the minimum launch version. This does not mean that every appli- cant should request the widest possible licence. An overly broad application can also create problems if the company cannot demonstrate the people, sys- tems, capital and controls needed for those services. The better approach is to map the business carefully and apply for a scope that is both commercially real- istic and operationally defensible. A useful internal exercise is to split the platform into functions. Who sets prices? Who holds client assets?
Who controls private keys? Are orders matched between clients or is the company trading as counter- party? Does the platform execute transfers for clients? Are clients given general education or personalised advice? Does the platform use third-party liquidity? Is there any fiat flow through the company? These are not technical details. They are licensing details. The programme of operations should be a real operating manual, not a narrative One of the most important documents in the applica- tion is the programme of operations or business plan. In practice, this should not be treated as a marketing description of the company. It needs to work as a regulatory map of the business. A strong programme of operations should explain the services, client journey, target markets, sup- ported assets, execution model, custody model, fiat arrangements, outsourcing, governance, staffing, risk controls, complaints process and continuity arrange- ments. It should also be consistent with every other part of the file. If the business plan says that custody is outsourced, the outsourcing register, client terms, risk policy, due diligence file and operational procedures should all tell the same story. This sounds obvious, but it is where many applications become vulnerable. The regulator reads the applica- tion as a whole. A polished business plan will not help if the AML policy assumes a different onboard- ing model, the custody policy refers to another wallet structure, the ICT policy does not mention a critical provider, and the client terms suggest services outside the requested licence scope. This is why the programme of operations should be built from the actual product architecture. Screens, user flows, order types, settlement steps and incident procedures are often more useful than abstract legal statements. The regulator needs to see how the ser- vice will function in practice. The FSC’s F&Q specifically includes questions on how the business plan is assessed, whether physi- cal presence in Bulgaria is required, what is expected from the management body, whether part of the team can be missing at application stage, and how many
144 CHAMBERS.COM
Powered by FlippingBook