MiCA licensing for a white label crypto app

The product lead and both legal teams should trace one complete transaction, including a failed order and a withdrawal. Record what the customer sees, which entity receives each instruction and which system can change its outcome. Include onboarding, quotes, acceptance, execution, settlement, wallet recovery, support and complaints.

The evidence should include screen designs, API specifications, customer terms, access permissions and event logs. Identify who can reject an order, alter a quote, choose a venue, suspend withdrawals or restore access. These records determine how the statutory service definitions apply; describing the app as a white label product does not answer those questions. (MiCA, art. 3(1)(16)–(26); ESMA Q&A 2653, answer of 14 October 2025.)

For the first release, select fungible crypto-assets already admitted to trading and exclude token issuance and financial instruments. This is a proposed product limit. Financial instruments fall outside MiCA, while the narrow custody and transfer exemption for certain exempt offers cannot be assumed for traded assets. Assess e-money-token payment functions separately before adding them. (MiCA, arts. 2(4)(a), 4(3)–(5) and 70(4).)

The CASP's compliance team should match the proposed services against its authorisation decision and official registers. Check the legal entity, restrictions and any downstream custodian. The crypto partner verification review addresses that entity-and-permission check. An Article 60 financial entity needs the relevant service entitlement and completed notification requirements; its existing financial licence is insufficient by itself. (MiCA, arts. 59–60, 75(9) and 109.)

For expansion beyond France, the CASP submits the destination countries, services and other Article 65 information to its home authority. Service may begin upon receipt of the home authority's notification that it has communicated the information onward or, at the latest, from the fifteenth calendar day after submission of all the information required by Article 65(1). Record that date separately for the launch plan. The fintech acquires no passport through this notification. (MiCA, arts. 59(7) and 65(1)–(4).)

The allocation must follow actual conduct. The parties should resolve the following functions before agreeing the commercial fee model.

• Software and order receipt. Designing screens, hosting an interface and transmitting technical data do not necessarily make the supplier a crypto-service provider. The position changes where the fintech receives a customer's buy, sell or subscription order and sends it to another provider for execution. That is the statutory reception-and-transmission service. Use an interface through which the identified CASP receives orders as provider, with the fintech confined to technical processing. A direct API connection is evidence of the arrangement, not an automatic exemption. (MiCA, art. 3(1)(23); European Commission answer to ESMA Q&A 2143.)
• Execution and pricing. Concluding purchase or sale agreements on a customer's behalf is execution. Contracting with customers against proprietary capital falls within exchange. Displaying a CASP-approved price differs from the fintech undertaking the trade as counterparty. Setting a price or spread alone does not determine classification: examine who concludes the trade and what the customer reasonably expects. ESMA also recognises that a counterparty model can involve execution and best-execution duties. Keep the CASP responsible for the applicable pricing policy, final quote and order treatment. (MiCA, arts. 3(1)(19)–(21), 77–78; ESMA Q&A 2653.)
• Custody and recovery. Safekeeping or controlling assets, or their means of access, can constitute custody. Review signing shares, administrator powers, recovery credentials and instructions to subcustodians. The absence of a complete private key at the fintech does not settle the test. Give an unlicensed technical supplier no custody role; where another entity supplies custody, verify its Article 59 status and disclose its involvement to clients. (MiCA, recital 83, arts. 3(1)(17) and 75(9).)
• Transfers. Sending crypto-assets between ledger addresses or accounts on a person's behalf is a separate service. The CASP should own the transfer instruction and authorisation process. A fintech that itself supplies transfers needs that activity assessed even if it never acts as exchange counterparty. (MiCA, arts. 3(1)(26) and 82.)
• Support and recommendations. Technical help and factual explanations differ from personalised recommendations about transactions or using crypto services. A chat agent or automated feature that recommends a transaction for a particular customer can provide advice. Restrict the fintech's support mandate and refer those recommendations to a provider authorised for advice. Personnel explaining crypto products also need the relevant knowledge and competence; purely administrative signposting has a different scope. (MiCA, arts. 3(1)(24), 68(5) and 81; ESMA Guidelines ESMA35-24871704-2922, paras. 13–28 and annex.)
• Additional features. Discretionary customer portfolios, a system matching multiple third-party trading interests and marketing tokens for an offeror require separate assessment as portfolio management, platform operation and placing. Ordinary promotion of a CASP's services is not automatically placing. Disable any added feature until its actual provider and required permission are identified. (MiCA, art. 3(1)(18), (22) and (25).)

The revenue model also needs checking. A CASP receiving and transmitting orders cannot receive benefits in return for routing those orders to a particular venue or CASP. A referral fee is not automatically prohibited, but calling a routing payment a marketing fee does not resolve Article 80(2). Document what each fee pays for and assess conflicts separately. (MiCA, arts. 72 and 80(2).)

Retain operational control at the CASP

The CASP can outsource operational functions subject to Article 73. The arrangement must preserve its responsibility, client relationship and authorisation conditions. It must retain enough expertise and resources to supervise the work, obtain records directly and support regulatory access. These conditions apply together. The management body should approve the responsibility schedule and allocate staff able to challenge the supplier's work. (MiCA, arts. 68 and 73(1).)

Permitted support can include collecting onboarding evidence, maintaining software and administering the CASP's complaint process. The documented mandate should identify decisions the supplier may implement, matters requiring escalation and controls it cannot change. The CASP should retain approval of customer acceptance policies, service permissions, pricing rules, withdrawal controls and complaint outcomes. This is the recommended allocation for this launch; Article 73 does not require a CASP employee to perform every clerical task personally.

The contract must define responsibilities and termination rights. The CASP also needs an outsourcing policy, contingency arrangements and an exit strategy. Test whether it can access customer records and continue or transfer its services if the fintech fails. ESMA's supervisory briefing rejects arrangements that leave the authorised business without substantive operations and control. It permits assessment of genuine third-country support; it supplies no licence-sharing exemption. (MiCA, art. 73(2)–(4); ESMA Supervisory Briefing ESMA75-453128700-1263, section 5.)

Identify the advertiser and approve each acquisition channel

The app and campaigns must identify the authorised provider of the crypto services. An unlicensed fintech must not suggest that it is itself a CASP. The CASP's marketing must be identifiable, fair, clear and not misleading. Preserve approved copy, targeting settings and referral arrangements so compliance can connect each campaign to the service actually offered. (MiCA, arts. 59(5) and 66(2).)

France adds specific controls. Targeted unsolicited contact seeking agreement to a crypto service can constitute financial canvassing, subject to statutory exclusions, including simple advertising information that contains no contractual or precontractual document. A standalone CASP cannot assume it may appoint the UK fintech company as a corporate canvasser: the corporate-mandate power is reserved to the institutions in Article L.341-3(1°). A CASP listed only under L.341-3(8°) has a different position. Route qualifying prospecting through a legally eligible actor or change the channel. (Code monétaire et financier, arts. L.341-1, L.341-2(11°), L.341-3 and L.341-4(I).)

French electronic advertising using response or contact forms to obtain agreement for crypto services has a further restriction. Its exception depends on the advertiser's own Article 59 entitlement for those services. Identify the actual advertiser and place qualifying campaigns with the authorised CASP. A fintech cannot borrow that status through branding or campaign approval. Check sponsorship separately before using it for customer acquisition. (Code de la consommation, arts. L.222-16-1 and L.222-16-2.)

Keep reverse solicitation outside the planned acquisition model

Article 61 can cover a service that an EU client requests exclusively on their own initiative, including the specifically related relationship. Solicitation by the offshore provider, a person acting for it or a relevant closely linked entity defeats that basis. A customer declaration cannot reverse the acquisition facts. Marketing the CASP's genuine authorised service is a different arrangement from directing customers to an unlicensed offshore service. (MiCA, art. 61(1).)

ESMA treats solicitation broadly, including affiliates, brand advertising and app promotions. A later marketing campaign cannot be justified merely because the original customer approach was unsolicited. New service types are restricted; ESMA confines same-type marketing to the original transaction context. An ongoing, genuinely requested relationship does not automatically lose the exception because time passes. (MiCA, art. 61(2); ESMA Guidelines ESMA35-1872330276-2030, paras. 11–28; Final Report ESMA35-1872330276-1899, section 3.4, paras. 47 and 50–51.)

The separate guide on MiCA reverse solicitation and existing EU accounts addresses continuation and migration. For this actively marketed launch, the service should begin with the authorised provider.

Match the customer promise to the regulated service

Use a direct CASP-client service agreement for the recommended model. The fintech's separate terms should describe its app services without undertaking exchange, execution or custody itself. A single acceptance flow can present both agreements if the parties and obligations remain clear. This is a recommended contracting design. MiCA expressly requires client agreements for custody and transfer services, while Article 73 preserves the CASP-client relationship when functions are outsourced. (MiCA, arts. 73(1)(b), 75(1) and 82(1).)

Identify the CASP before the customer accepts its service and at the transaction stages where provider identity matters. The custody agreement must cover the parties, service, policy, communications, security, charges and applicable law. Publish pricing and fees prominently and provide the required risk information and applicable white-paper links. Make required environmental disclosures accessible through the provider's service information. A logo in a footer cannot correct a contradictory customer promise. (MiCA, arts. 59(5), 66(2)–(5) and 75(1).)

The parties should record who issues trade confirmations, custody statements and fee disclosures. Customer assets must follow the custodian's segregation arrangements. Client funds received by the CASP require the applicable Article 70 safeguards; where paragraph 3 applies, funds other than e-money tokens must be placed with a credit institution or central bank by the end of the business day following receipt. Do not direct customer deposits into the fintech's operating account. The fintech's commercial remuneration should be separately identifiable. (MiCA, arts. 70 and 75(2), (5)–(7).)

Where the app adds e-money-token transfers or payment-capable custodial wallets, identify the authorised payment-service provider and its precise function. MiCA permission alone does not authorise payment services. In France, an EMT-only payment approval also does not establish permission for ordinary fiat-payment services. Enable those features only after the separate payment route is established. (MiCA, art. 70(4); EBA/Op/2025/08, paras. 17–23; ACPR, expectations for CASPs applying for payment-institution authorisation, updated 24 September 2026.)

Make support records and personal data available to the responsible provider

The support process must distinguish app defects from complaints about regulated services. Route the latter into the CASP's complaints procedure, preserve the receipt date and provide direct escalation. The procedure and template must be accessible through the app; clients cannot be compelled to use the template. Decisions are due without undue delay and ordinarily within two months, with the specific exceptional-delay procedure preserved. (MiCA, art. 71; Delegated Regulation (EU) 2025/294, arts. 1(3)–(7) and 6.)

Map data roles by purpose. The fintech may process support data on the CASP's instructions while acting as controller for its own acquisition activity. Joint determination of purposes and means requires a joint-controller assessment. Align the privacy notice, rights process and data agreement with those roles. Covered transfers to the UK can rely on the current adequacy decision; onward destinations still need checking. (GDPR, arts. 4(7)–(8), 13–14, 26, 28 and 44–46; Decision (EU) 2021/1772, as amended by Decision (EU) 2025/2574.)

For crypto transfers, the CASP needs the required originator and beneficiary information and procedures for missing data. The app must preserve those controls and records. Travel Rule data cannot be repurposed for commercial use. (Regulation (EU) 2023/1113, arts. 14–17 and 25–26.)

The ongoing app service also requires DORA assessment. The CASP must classify the function, assess the supplier and document the required service, location, security, incident, access and exit terms. Services supporting critical or important functions need additional contractual protections. That classification does not by itself make the fintech a designated critical ICT provider or require an EU subsidiary. (Regulation (EU) 2022/2554, arts. 28–31.)

Pure technical supply is the preferred starting structure. The fintech supplies the app and brand; the CASP contracts with customers and performs the regulated services. The product must make that allocation real at order receipt, execution, custody and support. This preserves the fintech's commercial role while limiting the functions that could require its own MiCA permission.

Outsourced operations can supplement that structure where the CASP can supervise defined functions. Onboarding administration and first-line support need a written mandate, access controls, trained personnel and escalation routes. If the fintech begins receiving orders as intermediary or advising clients, the parties must reassess its permission. Calling that activity outsourced support does not resolve Article 59. (MiCA, arts. 59 and 73; European Commission answer to ESMA Q&A 2143.)

Independently provided services require a different route. A fintech group retaining its own regulated EU service should establish a provider meeting MiCA's establishment, substance and permission requirements, or remove that service from the launch. An eligible financial entity can assess Article 60 within its limits. Incorporation and an application do not authorise operations. The CASP authorisation guide sets out the separate application work. (MiCA, arts. 59–60 and 62–63.)

The UK fintech must also assess its own activity. UK exchange-arranging can require FCA registration even where every customer is in the EU. Confirm the office and management connection and the actual arranging or custody functions. UK-origin promotions need their own lawful route, including the overseas-recipient exemption where its conditions are met. The expanded UK cryptoasset regime fully commences on 25 October 2027; its application process does not replace registration needed for an earlier launch. (Money Laundering Regulations 2017, regs. 8, 9(3), 9(5)(b), 14A and 56; FSMA 2000, s. 21; Financial Promotion Order 2005, art. 12; SI 2026/102, reg. 1(2)–(3).)

Before enabling customer transactions, complete the following decisions:

1. The fintech's legal lead approves its own activity assessment and removes or obtains permission for any retained regulated function.
2. The CASP's compliance lead verifies service scope, destination-country access and the applicable cross-border start date.
3. Both parties sign the customer and supplier documents, including data and ICT terms, after matching them to the implemented product.
4. The product and operations leads demonstrate order attribution, pricing control, asset flows, complaints routing and continuity access.
5. The marketing lead activates only approved channels with an identified lawful advertiser and documented country checks.

These are proposed release controls implementing the obligations above. If a control fails, postpone the affected feature or change the allocation before launch.