Decision brief
What management should decide before integration
Name the provider
Identify the entity that contracts for and performs every regulated service, not merely the entity supplying the interface.
Test the client's role
Check whether branding, instructions, discretion, asset control or customer support moves the product company into regulated activity.
Separate adjacent services
Map custody, crypto transfers, fiat payments and technology to the correctly authorised or accountable entity.
Keep live evidence
Verify authorisation, service scope and cross-border notifications against current official records before launch and after material change.
The provider test
Start with functions, not the commercial label
Begin at the customer journey and trace each action to a legal entity. The contract is important because it tells the customer who owes the service, but the wording is not conclusive if operations tell a different story. A contract that calls one party a technology vendor will not cure a model in which that party decides whether to execute an order or controls customer keys.
The practical test has three layers. First, identify the promised service and the entity named as provider. Second, identify who performs the facts that make up that service, including customer acceptance, instruction handling, execution, transfer and custody. Third, confirm that the entity responsible for the regulated layer holds the required permission for the intended service and EU reach. Repeat the test for the product company: its own conduct may require analysis even where another entity is clearly the customer's CASP.
Model comparison
Who is the provider in four common structures?
| Model | Usual contracting and regulated provider | Product company role | What still needs review |
|---|---|---|---|
| Model Technology-only | Usual contracting and regulated provider The product company or a separate CASP contracts for the regulated service; the vendor supplies software or infrastructure. | Product company role Defines the proposition and uses the technical stack without delegating regulated decisions to the vendor. | What still needs review Whether the vendor handles instructions, controls keys, exercises discretion or otherwise performs more than a technical function. |
| Model Introducer | Usual contracting and regulated provider The CASP contracts with, accepts and serves the customer. | Product company role Markets or refers the prospective customer, then hands the regulated relationship to the CASP. | What still needs review Scripts, remuneration, data flow, order handling and post-referral conduct may show that the role exceeds introduction. |
| Model Embedded or white-label | Usual contracting and regulated provider The CASP is disclosed in the contract and performs the regulated service, even if the journey carries the product company's brand. | Product company role Owns some interface, distribution and customer-experience elements under an agreed responsibility map. | What still needs review Branding, disclosures, instruction flow, support and operational control must match the legal allocation and avoid a regulatory halo. |
| Model Direct regulated service | Usual contracting and regulated provider The product company itself contracts for and performs the service under its own applicable MiCA permission. | Product company role Operates the regulated business and remains accountable for its delivery and outsourced functions. | What still needs review A supplier or commercial partnership cannot substitute for the company's own required authorisation or notification position. |
Responsibility map
What each participant should own
| Participant | Core responsibility | Boundary to document |
|---|---|---|
| Participant Product company | Core responsibility Product design, distribution, its interface and the conduct allocated to it. | Boundary to document It should not present itself as the authorised provider unless that is legally true, and it still needs a review of its own activities. |
| Participant Selected CASP | Core responsibility The regulated services it contracts to provide, within verified authorisation scope and operating reach. | Boundary to document Customer acceptance, AML controls, instructions, custody, transfers, disclosures and complaints must be allocated expressly rather than assumed. |
| Participant Payment or banking provider | Core responsibility Any connected fiat account or payment service that requires a separately authorised provider. | Boundary to document CASP status does not by itself include every fiat, payment or banking function. |
| Participant Technology vendor | Core responsibility Infrastructure, security and service levels within the agreed technical scope. | Boundary to document Operational access and decision rights should not contradict a technology-only classification. |
| Participant SKY7 | Core responsibility Model mapping, provider selection support, onboarding preparation and integration coordination. | Boundary to document SKY7 does not provide the regulated crypto service, hold customer assets or keys, or transfer authorisation to the client. |
Outsourcing
An API changes delivery, not regulatory accountability
MiCA permits outsourcing, but the CASP remains fully responsible for its obligations under Article 73. That matters in embedded delivery because a front end, onboarding module or operational workflow may sit outside the CASP while the regulated service remains its responsibility. The arrangement needs clear access, oversight, incident, continuity, subcontracting and exit rights. CASPs are also within the DORA framework, so ICT dependencies cannot be treated as an ordinary supplier footnote.
Full CASP responsibility does not erase the product company's own exposure. Marketing must be fair, clear and not misleading, customer screens must identify the relevant provider, and the client must perform only the activities allocated to it. Responsibility can be divided operationally; the legal perimeter cannot be rewritten by a service schedule.
Step by step
How to map an embedded crypto model
-
Trace the customer journey
Map every screen, contract, data handoff, instruction, asset movement, support route and complaint path to the entity controlling it.
-
Classify the assets and services
Confirm what the product is and which activities may be crypto-asset services before assigning roles or selecting a provider.
-
Test each actor's conduct
Compare contractual labels with actual access, discretion, order handling, key control and customer-facing behaviour.
-
Verify the regulated provider
Check the live official register, exact authorised services and required cross-border notifications for the intended EU operating model.
-
Allocate control obligations
Document AML and KYT, Travel Rule data, custody, fiat payments, disclosures, recordkeeping, complaints, incidents and outsourcing oversight.
-
Align contracts and screens
Make provider identity, service scope, fees, risks, support and complaints consistent from the first product screen through the legal terms.
-
Set change control
Re-run the perimeter and evidence review when services, assets, markets, customer types, vendors or operational control materially change.
Evidence pack
What to have ready for perimeter review
-
Journey and flow maps
Customer, data, fiat and crypto-asset flows, including exception and complaint routes.
-
Contracts and disclosures
Customer terms, partner schedules, consent language, product screens and marketing claims.
-
Control matrix
System access, keys, approval rights, instruction handling, execution logic and escalation ownership.
-
Product inventory
Assets, services, customer types and intended EU reach, with classification questions flagged.
-
Compliance allocation
AML and KYT, Travel Rule, sanctions, custody, complaints, records and regulatory reporting.
-
Provider evidence
Current register entries, permission scope, notifications and due-diligence material reviewed against the proposed model.
Custody and payments
Do not collapse assets, keys and fiat into one provider
If custody is part of the product, the customer agreement should identify the authorised custody provider and reflect who controls the assets or means of access. MiCA Article 75 places specific agreement and responsibility duties on the custody provider. Delegated custody cannot simply disappear into a general technology arrangement; the downstream provider must be another CASP authorised for custody.
Fiat is a separate map. Under Article 70, connected payment services must be provided by the CASP itself where legally permitted or by an appropriately authorised payment provider. A CASP integration therefore does not automatically deliver bank accounts, payment rails or every safeguarding function. The customer journey should name each provider without implying that one permission covers the whole stack.
Classification gate
Token classification comes before provider allocation
An embedded product may involve a crypto-asset within MiCA, an asset that falls under another financial-services regime, or a mixed structure. Calling the proposition tokenisation, RWA or infrastructure does not decide the answer. Classify the asset and each service first, then test the permissions and roles. A carefully allocated CASP layer cannot solve a classification error elsewhere in the product.
01 Does a white-label CASP arrangement cover the product company?
Not automatically. The CASP's authorisation supports the regulated services that the CASP actually provides within its scope. The product company's branding, customer contact, instruction handling, discretion, asset access and support role still require a separate perimeter review.
02 Can our brand be the main interface while the CASP is the provider?
That can be a workable structure when the contracts, disclosures and operating flow clearly identify the CASP and match the real division of responsibilities. The interface should not create the impression that the product company holds an authorisation it does not hold.
03 Is an introducer always outside MiCA authorisation?
No label creates a safe harbour. A role limited in substance to marketing and referral is different from receiving instructions, arranging the regulated journey or controlling execution. Review the scripts, data handoff, remuneration and post-referral conduct.
04 Who should hold customer assets or cryptographic keys?
The custody structure should identify the authorised custody provider in the customer agreement and operating records. Control of keys, withdrawals, reconciliation and delegated custody must follow that allocation. SKY7 does not hold customer assets or keys.
05 Does CASP authorisation include fiat payment services?
Not as a blanket rule. Connected payment services need their own lawful provider and role allocation. Verify whether the CASP may provide the function itself or whether a separately authorised payment or banking provider is required.
06 What should be verified before relying on a provider?
Verify the legal entity, current official register entry, exact service permissions, relevant cross-border notifications, contract role, custody and payment model, and the match to the proposed customer journey. Provider-specific evidence belongs in live private diligence, not in a generic public claim.
Related reading
Continue the review
CASP as a Service
How SKY7 structures provider selection, evidence review, onboarding preparation and integration coordination.
VASP and CASP hub
Licensing, operating-model and transaction guidance for regulated crypto businesses.
The MiCA CASP framework
A broader guide to service classes, authorisation and operating obligations.
Acquiring an authorised CASP
When a change-of-control transaction is being considered instead of an embedded provider model.