All guides
MiCA / CASPCryptoEU

CASP partnership agreements for white label crypto apps

What a partnership agreement between a CASP and a white label crypto app must settle: services, decision rights, fees, records, outsourcing and exit.

Published 14 min read

A crypto as a service agreement should give the authorised provider effective control of its regulated services and give the app company enforceable commercial protections. The contract must identify the customer’s provider, allocate operational decisions, explain each payment and preserve records and continuity. It cannot confer a missing permission. MiCA provides no tied-agent route through which an unlicensed app company may provide crypto services under another company’s authorisation. (MiCA, Articles 59 and 73; Commission answer in ESMA Q&A 2143.)

An Indian software company supplies a branded app, acquisition and first-line support. An Irish crypto-asset service provider, or CASP, is intended to contract with EU customers. The proposed partnership promises licence access, an app-company veto over account restrictions, exclusive customer records and thirty days of exit assistance. It also includes a software fee and trading-revenue share.

Replace those four terms with a service allocation, bounded decision rights, purpose-specific records access and a tested exit arrangement. Assess the revenue share separately. The drafting examples below require schedules identifying the actual services, systems and responsibilities.

The white label licensing guide addresses the permission boundary. This guide concerns the agreement negotiated after selecting the operating model and prospective provider.

Identify the customer contracts and supporting schedules

The Irish CASP should contract directly with customers for each regulated service it actually provides. The Indian company’s app terms should cover its software, account access, intellectual property and support commitments. Those terms must avoid a parallel promise that the app company will execute trades, hold assets or provide another regulated service without permission. MiCA expressly requires agreements for custody and transfer services and preserves the CASP’s customer obligations through outsourcing. (MiCA, Articles 59, 73(1)(b), 75(1) and 82(1).)

Build the document stack around those relationships:

  1. CASP customer terms, service-specific agreements, fees, disclosures and necessary consents.
  2. App terms identifying the Indian company’s own service and complaint route.
  3. A business-to-business (B2B) commercial agreement covering payments, brand and software rights, changes, liability and disputes.
  4. A service and authority schedule identifying each task, decision-maker, system permission, record and escalation route.
  5. Applicable operational-outsourcing, information and communication technology (ICT), data-processing and international-transfer terms.
  6. A continuity and exit schedule connecting customer treatment with technology, records and assistance.

The B2B terms can be schedules within one agreement. Customer terms need valid acceptance by the relevant parties. State which provision controls each subject and preserve mandatory terms when documents conflict.

Before: “The CASP grants the App Company access to its MiCA licence.”

After: “The CASP provides the regulated services listed in the service schedule under its customer terms. The App Company provides the allocated software and support. Neither party receives permission through this agreement to perform an activity requiring its own authorisation.”

Support that allocation with the authorisation decision, service list, customer journey and system design. Complete partner licence checks against the exact contracting entity.

Give the CASP authority that works in production

The CASP must retain responsibility, expertise and resources to supervise outsourced functions. It needs direct access to relevant information and effective supervisory cooperation. ESMA’s authorisation briefing reinforces these control expectations. (MiCA, Articles 68 and 73; ESMA supervisory briefing, sections 4.6 and 5.)

For this arrangement, reserve customer-acceptance policy, service and asset eligibility, pricing or execution policy, lawful restrictions, compliance and regulated-service complaint outcomes to the CASP. The app company may collect documents, display approved prices and implement documented decisions. CASP-controlled automation can process routine cases; retained authority requires staff able to supervise and intervene.

Before: “No customer account may be restricted without the App Company’s approval.”

After: “The CASP may impose restrictions required by law or permitted by its lawful customer terms without prior App Company approval. It must record the basis and provide prompt information to the extent lawful. The App Company must implement valid instructions. Disputed decisions follow the agreed escalation procedure.”

Protect the app company through defined notice, escalation, correction and compensation provisions for contractual breach. A restriction power should state its permitted grounds and review process. Regulatory responsibility supplies no unlimited right to freeze customers’ assets. (MiCA, Articles 66, 73 and 75(6).)

Test actual administrator rights, emergency access and override logs. First-line support must distinguish technical assistance from personalised recommendations or receiving customer orders as an intermediary. ESMA tests the operational flow and reasonable customer understanding; proprietary capital alone does not settle whether a service is exchange or execution. (MiCA, Article 3(1)(17)–(26); ESMA Q&As 2143 and 2653.)

Document the brand and acquisition permissions

Use a brand and communications schedule covering provider identification, approved claims, countries, languages, channels and screen versions. Give both parties correction rights over misuse of their names. The CASP needs authority to remove misleading regulated-service claims and communicate directly with customers when its duties require it. An unauthorised app must not present itself as a CASP. (MiCA, Articles 59(5), 66 and 73.)

Approve each target country and actual advertiser before acquisition begins. Article 65 passporting does not resolve every national marketing or consumer rule. Ireland’s Consumer Protection Code applies selected provisions to MiCA activities, with territorial and consumer-scope limits. Other targeted markets need their own checks. (Irish Consumer Protection Regulations 2025, regulations 3, 14 and 15; MiCA, Article 65.)

Price each service and identify the incentive

The payment schedule should identify the payer, recipient, service, calculation and conduct rewarded. For CASP-to-app payments:

  • A software fee should specify the supplied technology and usage measure.
  • A per-lead fee should define a qualifying introduction, consent evidence and attribution. Collecting an order or recommending a transaction changes the activity assessment.
  • A transaction-linked service fee should explain the processing performed and the volume measure.
  • A revenue share should identify the included fees or spreads, permitted deductions, refunds, reconciliation and audit rights.

MiCA Article 80(2) prohibits the relevant CASP from receiving benefits for routing client orders to a particular platform or another CASP. ESMA’s interpretation also addresses execution routing. A CASP paying for genuine software or acquisition requires a different recipient-and-activity analysis. If the app independently receives and transmits orders, its permission becomes a separate obstacle. (MiCA, Articles 59 and 80(2); ESMA Q&A 2087.)

Test whether the economics encourage excessive trading, worse customer prices, preferential routing or delayed withdrawals. Conflicts controls may require changing the arrangement; disclosure alone is insufficient. A routing reward cannot become lawful through a software-fee label. (MiCA, Articles 66 and 72; Delegated Regulation (EU) 2025/1142, Articles 4–7.)

Negotiate the commercial consequences of service restrictions, volume reductions and asset removal. Record all venue-funded benefits. The affiliated-liquidity analysis addresses the execution evidence in greater detail.

Separate customer relationships from permitted data use

The app company can protect its brand, acquisition investment, confidential pricing and lawful marketing relationship. The CASP needs continuing access to its customers and service records. Define each right by purpose, including any negotiated restriction on competing marketing.

Before: “All customers and customer records belong exclusively to the App Company.”

After: “Each party may use customer information for the purposes specified in the data schedule and supported by the required legal basis. The CASP retains direct access to records needed for its services, supervision, complaints and retention duties. Commercial restrictions preserve lawful customer communications, data-subject rights and reporting secrecy.”

Determine privacy roles separately for onboarding, support, app accounts and marketing. The Indian company may process support data on CASP instructions while controlling its own acquisition data. Jointly determined purposes require a joint-controller assessment. Use the corresponding processing, sharing or joint-controller terms. (GDPR, Articles 4(7)–(8), 5–6, 13–14, 26 and 28.)

The CASP should receive permissions and consent versions, customer instructions, positions, transactions, complaints, necessary screening outcomes and audit trails. Specify machine-readable exports, human-readable records, identifiers and timestamps. Test access during a fee dispute and supplier failure. Give the app lawful information needed for support and billing; restrict protected suspicious-report material. (MiCA, Articles 68(9) and 73; Delegated Regulation (EU) 2025/1140, Articles 2–5; Irish Criminal Justice (Money Laundering and Terrorist Financing) Act 2010, sections 49 and 55.)

Set retention by category and trigger. Customer-contract records under the MiCA records regulation generally remain for five years after termination, with the specified supervisory extension. Marketing use requires its own lawful basis and channel permissions. An introduction does not give either partner perpetual marketing rights. (Delegated Regulation 2025/1140, Article 4; GDPR, Articles 5–6, 17 and 21.)

Apply outsourcing and ICT terms to the actual supply

MiCA outsourcing requirements govern outsourced operational functions. The Digital Operational Resilience Act (DORA) governs qualifying ongoing ICT supplied to the regulated financial entity. An ongoing app service supplied by the Indian company to the CASP may engage both. The CASP’s regulated crypto service needs separate classification from the technology it purchases. (MiCA, Article 73; DORA, Articles 2, 3 and 28–30; Commission answer DORA030.)

Record the ICT service, locations, subcontractors and supported function. Article 30(2) supplies baseline contractual requirements; Article 30(3) adds protections for ICT supporting critical or important functions. Agree usable audit, incident, security, recovery and exit rights. The DORA contract review covers the detailed clauses and subcontractor dependencies.

Assess custody separately. Where another provider safeguards or controls clients’ assets or access to them, Article 75(9) can require an appropriately authorised custody provider. A software-subcontractor label cannot resolve that activity. (MiCA, Articles 3(1)(17) and 75(9).)

Indian access to personal data hosted in the European Economic Area can constitute an international transfer. Choose a Chapter V mechanism fitting the entities and processing. The 2021 standard contractual clauses cover importer processing outside GDPR’s territorial scope; an importer already subject to GDPR for that processing needs a separately established transfer solution. Where those clauses apply, document the assessment of destination laws and practices and any necessary supplementary safeguards, control onward access and suspend transfers if the required protection cannot be maintained. (GDPR, Articles 3 and 44–49; Decision (EU) 2021/914, Article 1 and Annex, Clauses 8 and 14–16.)

For Indian operations, address the security requirements of the Information Technology Act and its rules on sensitive personal data or information (SPDI), and the reporting and log requirements of the Indian Computer Emergency Response Team (CERT-In). The Digital Personal Data Protection (DPDP) Act’s principal processing provisions are scheduled for 13 May 2027. Put that commencement into change control and reassess any applicable export-processing exemption against the actual purposes. (IT Act 2000, sections 43A and 70B; SPDI Rules 2011; CERT-In Directions of 28 April 2022; DPDP commencement notification.)

Allocate changes and the cost of failure

Require a change request for new features, countries, assets, pricing methods, subprocessors and access locations. Identify the evidence, approving person, customer notice or consent, implementation date and rollback. Keep affected functions disabled until permission and other prerequisites are satisfied. Critical ICT subcontracting changes require the applicable advance-information and objection process. (MiCA, Articles 59(8) and 65; Delegated Regulation (EU) 2025/532, Articles 4–6.)

Allow urgent lawful restrictions with recorded reasons and prompt permitted notice. Give the app company defined commercial choices when a change materially reduces the purchased service, including repricing or termination where agreed.

Separate customer duties, inter-party reimbursement and liability caps. Allocate investigation, recovery, customer remediation and transition costs by breach and responsibility. Preserve statutory customer rights and regulatory accountability, including attributable custody-loss liability. Where standard contractual clauses apply, the commercial cap must preserve their liability scheme, including inter-party rights. (MiCA, Articles 73 and 75(8); GDPR, Article 82; Decision 2021/914, Annex, Clauses 5 and 12.)

Check the law governing exclusions, indemnities and any claimed recovery of regulatory penalties. Select the dispute forum using the parties’ assets and enforcement routes. Agree invoicing, currency, withholding evidence and Indian export-receipt procedures for each fee. A revenue-share label cannot determine its tax treatment.

Request evidence of promised insurance, including exclusions and cancellation terms. MiCA permits qualifying own funds, insurance or a combination; it does not impose insurance on every CASP. (MiCA, Article 67.)

The incident procedure should identify each reporting actor and its trigger. CERT-In’s six-hour rule for specified incidents can require Indian reporting before the partners complete a joint investigation. Provide immediate escalation and updates supporting separate GDPR and DORA duties. (CERT-In Directions, paragraph (ii); GDPR, Article 33; DORA, Articles 19 and 30(2)(f).)

Replace the thirty-day cut-off with an exit plan

Thirty days must be tested against the actual transition. DORA requires an adequate transition for ICT supporting critical or important functions. MiCA requires outsourcing exit arrangements and has specific wind-down duties for the services covered by Article 74. (MiCA, Articles 73–74; DORA, Articles 28(8) and 30(3)(f).)

Before: “All assistance and access end thirty days after termination.”

After: “The parties will perform the exit schedule, including continued technology, records access, licences and assistance for its agreed transition and extension periods, subject to applicable law. Regulated services remain with appropriately permitted providers. Customer transfer steps and surviving record duties must be completed.”

Specify priced resources, export formats, reconciliation and acceptance tests, transition software licences, domains and customer communications. Allocate pending orders, restricted balances and unresolved complaints. Define extensions and their charges before dependency becomes a dispute.

For a qualifying data-processing service, apply the Data Act’s switching timetable and check its specific exceptions. The standard transition is at most thirty calendar days after a notice period of no more than two months, with specified extension rights and at least thirty days for data retrieval. Where Article 29 applies, switching charges are limited to directly linked costs until they are prohibited from 12 January 2027. Article 31 exempts qualifying custom-built services from that charging rule and excludes services supplied for a limited period for non-production testing or evaluation from the switching chapter. These rules concern the data-processing service; the wider customer and asset exit requires its own plan. (Data Act, Articles 2(8), 23, 25, 29 and 31.)

If the CASP ends the partnership while retaining permission, customers may continue directly or accept a replacement provider. The replacement must accept the customers, services and assets. Obtain the contractual consent and transfer instructions required for the chosen route. For planned asset removal, set the last trading date, customer notice and a viable withdrawal or transfer route before support ends. Return custody assets consistently with Article 75; a forced conversion into another asset cannot solve an unsupported withdrawal route. (MiCA, Article 75(6); Commission answer in ESMA Q&A 2320.)

Permission loss requires a different response: stop affected unauthorised activity and implement the lawful wind-down or transfer arrangements. If the Indian supplier fails, the CASP needs tested independent records access and a usable alternative interface. Technical step-in can preserve software operations only within the stepping-in party’s lawful role. It cannot authorise the app company to take over regulated services. (MiCA, Articles 59, 64(8), 73–74; DORA, Article 28(8).)

The customer migration analysis addresses the separate acceptance and transfer mechanics.

Complete signing and activation in order

Use the following sequence as an approval record:

  1. Before signing, approve the entities, actual services, target countries, customer terms and authority schedule. Remove the licence grant and operational veto.
  2. Complete required pre-contract ICT classification, risk assessment and supplier diligence. DORA requires these before entering the relevant arrangement. (DORA, Article 28(4); Delegated Regulation (EU) 2024/1773, Articles 5–6.)
  3. Settle the fee analysis, records and data terms, liability allocation and funded exit schedule. Assign owners and evidence requirements to outstanding activation conditions. Execute the agreed version through authorised signatories with the operative schedules attached, and retain the signed documents.
  4. Before personal-data access, implement the applicable privacy and transfer safeguards. Before transactions, verify the permissions, Article 65 access and asset-specific conditions. Deploy approved terms, screens, notices and consent records.
  5. Demonstrate CASP decision authority, lawful custody and withdrawals, complaints escalation, incident reporting and independent record recovery. Test supplier failure and customer exit.
  6. Approve activation service by service. Missing permission, prohibited routing rewards, blocked regulatory records or an unworkable lawful exit require correction or redesign before the affected activity begins.

The signed agreement records the bargain. Activation requires evidence that the agreed allocation works.

Review a proposed CASP partnership

Provide the draft agreement, customer journey, service and country list, fee flows and exit dependencies. Contact Licentium to scope a review of the partnership terms and the operating decisions they must support.

Tell us what you're building
guideCryptoMiCA / CASPEU

Planning a launch somewhere new?

Prefer email? Write to hello@licentium.io. By sending, you accept our privacy policy.