Route facts
Decision brief
Who it fits
Fintechs, payment firms, wealth platforms and corporate products evaluating an embedded, API or white-label crypto service supplied by an EU-authorised CASP.
Risk points
Stale register evidence, missing service permissions, incomplete market coverage, unclear client contracting, weak custody controls and ungoverned subcontractors can each stop a fit.
Expected outputs
A verified scope note, responsibility map, evidence-gap log, integration conditions and a reasoned proceed, remediate or reject decision for the proposed model.
Next action
Bring the customer journey, target markets, asset set, fiat flows, contracting proposal and intended provider functions before technical discovery starts.
Regulatory perimeter
A register entry is the beginning of diligence
As of July 2026, every MiCA transitional period has ended. A legacy national VASP registration or a pending application is not current CASP authority. The live ESMA register is the central public check, but a diligence file should also reconcile it with the home authority's record and provider evidence. Names, trading brands and group entities must not be treated as interchangeable.
The second check is service-by-service. Custody, exchange, execution, reception and transmission, transfer, advice and other MiCA services are distinct. The proposed product must be mapped to the exact authorised entity and service rather than to a broad claim that the group is regulated. Cross-border availability also needs evidence: home authorisation alone does not prove that every service is available in every target Member State.
Gate one
Regulatory scope checks before commercial review
| Diligence area | Evidence to reconcile | Decision question |
|---|---|---|
| Diligence area Current status | Evidence to reconcile Live ESMA register record, home-authority record and provider-supplied authorisation evidence for the same legal entity | Decision question Is the proposed regulated provider currently authorised, rather than registered under a legacy regime or still applying? |
| Diligence area Service scope | Evidence to reconcile Services reported in the public register, authorisation material and the provider's proposed product schedule | Decision question Does the entity hold every permission required by the customer journey, without relying on group-level marketing language? |
| Diligence area Cross-border availability | Evidence to reconcile Article 65 notification evidence and a current service-by-market availability matrix maintained by the provider | Decision question Can the relevant entity supply the relevant service in each target market at the point of launch? |
| Diligence area Contracting position | Evidence to reconcile Proposed customer terms, disclosures, brand presentation and role descriptions for the CASP, client, SKY7 and other providers | Decision question Will customers understand which entity provides each regulated and unregulated part of the product? |
Product fit
Scope the service before comparing features
Feature lists hide responsibility. A wallet can be custodial or non-custodial; an exchange screen can route orders or merely display prices; a fiat leg can depend on a separate bank, EMI or payment institution. Diligence should follow the customer's asset and instruction from onboarding through execution, settlement, custody, withdrawal and complaint. Every handoff needs a named legal entity, control owner and evidence source.
Tokenisation and RWA proposals need an earlier classification gate. A token that is a financial instrument or another excluded product may sit outside MiCA, so a CASP integration should not be treated as automatic authority for issuance, distribution or secondary-market activity.
Gate two
Five operating-model lenses
Custody and client assets
Identify the client custodian, wallet-control model, key-management responsibility, segregation and reconciliation process, delegated custodian and treatment of a loss or blocked withdrawal. Delegated custody is permission-dependent, not a generic vendor choice.
Execution and liquidity
Map who receives and executes orders, sets or sources prices, selects venues and counterparties, manages conflicts and handles failed or disputed execution. A liquidity relationship does not by itself prove authorised execution or customer-facing scope.
Financial-crime controls
Allocate customer risk assessment, KYC, sanctions screening, on-chain KYT, alert review, Travel Rule data, self-hosted-address controls, escalation and regulatory reporting. Tool output is evidence for a decision, not the decision owner.
Payments and settlement
Identify the bank, EMI or payment institution responsible for fiat accounts, payment execution and safeguarding where relevant. A CASP permission does not automatically add payment services, settlement accounts or card capability.
Technology and resilience
Review API authentication, access control, data flows, change management, monitoring, incident escalation, recovery, subcontractors, audit evidence and exit support. DORA responsibility remains with the regulated financial entity despite outsourcing.
Evidence request
Evidence to request before integration
-
Regulatory identity pack
Current legal-entity details, authorisation basis, live register references, authorised services and the provider's process for monitoring changes to status or scope.
-
Service and market matrix
The supported product functions, customer types, asset limits and target-market availability, tied to the entity that contracts for and supplies each service.
-
Asset and order-flow maps
Diagrams showing fiat, crypto-assets, instructions and data through onboarding, funding, execution, settlement, custody, withdrawal, reversal and exception handling.
-
Custody and counterparty evidence
Client agreement structure, wallet and key-control description, segregation and reconciliation evidence, delegated custody, execution venues and liquidity counterparties.
-
Financial-crime responsibility map
A case-level allocation for KYC, sanctions, KYT, Travel Rule, investigations, suspicious activity escalation, recordkeeping and responses to law-enforcement or regulator requests.
-
ICT and subcontractor pack
API security material, critical-function inventory, subcontractor chain, incident and continuity procedures, testing evidence, audit rights and material-change governance.
-
Complaint, wind-down and exit pack
Complaint ownership, client communications, asset return or transfer mechanics, data export format, retention responsibilities and support for an orderly provider migration.
Responsibility split
The strongest control is a reconciled responsibility map
A CASP that outsources an operational function remains responsible for its MiCA obligations. The client or brand may still own product governance, front-end disclosures, data decisions and controls arising from its own regulated status. SKY7 can analyse the model, coordinate evidence and support integration, but it does not become the custodian, execution venue, payment provider or liquidity provider through that work.
The map should therefore be built at task level rather than with broad labels such as compliance handled by partner. It should show who decides, who performs, who reviews, who reports and who communicates with the customer for every material control.
Control test
Questions that expose an incomplete responsibility split
| Control area | Question to answer | Evidence of operation |
|---|---|---|
| Control area Customer relationship | Question to answer Which legal entity is the regulated service provider, contractual counterparty and complaint recipient at each stage? | Evidence of operation Customer terms, in-product disclosures, support routing and approved marketing language that all name the same roles |
| Control area AML and sanctions | Question to answer Who sets risk appetite, approves onboarding, investigates alerts, files reports and answers authority requests? | Evidence of operation Responsibility matrix, procedures, access permissions, escalation paths, sample case records and governance minutes |
| Control area Travel Rule | Question to answer Who collects, validates, transmits, rejects and retains originator and beneficiary information, including self-hosted-address evidence? | Evidence of operation Data-flow map, technical specification, exception procedure, recordkeeping control and tested handoff between parties |
| Control area Incidents and complaints | Question to answer Who detects an event, assesses materiality, notifies affected parties, remediates the cause and closes the customer case? | Evidence of operation Severity model, notification tree, response playbook, complaint register structure and joint exercise records |
| Control area Exit and portability | Question to answer How are assets, open orders, customer records, consent evidence and compliance history returned or transferred if the relationship ends? | Evidence of operation Wind-down plan, export specification, migration runbook, retention schedule and ownership of post-termination support |
Method
A provider-neutral diligence sequence
-
Fix the customer journey
Define users, markets, assets, wallet model, order and payment flows, customer contract and brand presentation. A provider cannot be assessed against an undefined product.
-
Verify public regulatory evidence
Reconcile the live ESMA record, home-authority material, authorised services and cross-border availability before requesting sensitive technical or customer information.
-
Build the private evidence room
Request the operating, custody, financial-crime, ICT, subcontractor, incident and exit evidence relevant to the proposed functions. Keep partner identity and documents private.
-
Challenge the handoffs
Walk normal and failure scenarios through the responsibility map. Test declined onboarding, a sanctions hit, delayed execution, wallet restriction, API outage, complaint and provider exit rather than reviewing only the happy path.
-
Record conditions and monitoring
State the verified scope, unresolved gaps, required remediation, launch conditions, evidence owners and recheck triggers. The conclusion belongs to the specific model and evidence date, not to the provider in the abstract.
FAQ
Frequently asked questions
Need to test a proposed provider against your customer journey? Ask SKY7
01 Does an EU CASP authorisation cover every crypto product?
No. The authorisation records specific crypto-asset services, and cross-border provision follows a separate notification process. Payment services, token issuance, financial instruments and other regulated activities may require different permissions or providers. Match each product function to the exact entity and legal basis.
02 Can a brand operate under a provider's CASP authorisation?
There is no blanket licence-rental result. The answer depends on which entity provides the regulated service, contracts with clients, controls assets or orders, makes compliance decisions and appears in marketing. An embedded or white-label interface does not transfer authorisation to the brand.
03 Does using a third-party custodian remove the CASP's responsibility?
No. MiCA treats outsourced functions as remaining under the CASP's responsibility, and delegated custody may be entrusted only within the applicable authorised-CASP framework. Diligence must identify the client custodian, delegation chain, controls and contract rather than assuming the technology vendor carries the regulatory obligation.
04 Why is exit planning part of provider selection?
A service can become unusable through a scope change, market withdrawal, control failure, commercial termination or technical dependency. Without tested asset-return, customer communication, data-export and record-retention arrangements, the client may be locked into a provider precisely when orderly migration matters most.
Keep reading
Related reading and services
CASP-as-a-Service
The SKY7 provider-selection, onboarding preparation and integration-coordination service for EU embedded crypto models.
VASP and CASP crypto assets
The SKY7 topic hub for MiCA, custody, exchange, virtual-asset permissions and operator guidance.
The MiCA CASP framework
How authorisation, service scope, custody, conduct and outsourcing change the operating model for EU crypto providers.
Banking for crypto fintechs
The licensing, flow-of-funds, counterparty and control questions banks ask during onboarding.