The MiCA route for banks offering crypto

A bank considering crypto tends to start with the question: do we need to become a CASP? For an existing credit institution, that is not necessarily the right first question. MiCA Article 60 provides a notification route for certain already-regulated financial entities, which for credit institutions can mean providing crypto-asset services without going through the separate CASP authorisation process that applies to new entrants under Article 59.

That does not mean the bank has no regulatory work to do, and anyone presenting Article 60 as a shortcut has not read paragraph 7. The more useful questions come after the route is identified: what does the bank intend to provide itself, what will sit with an external regulated counterparty, and what does that division mean for the notification and the operating model behind it?

Start with the regulated entity, not the brand

"Digital bank" is a commercial description, not a MiCA legal category, and Article 60 treats different regulated entities very differently.

A credit institution has the widest route, under Article 60(1). An investment firm may provide crypto-asset services under Article 60(3), but only those equivalent to the investment services and activities for which it is specifically authorised. An electronic money institution has a much narrower route under Article 60(4), covering custody and administration and transfer services, and only for the e-money tokens it issues. Other entity types named in the article, such as authorised market operators, have their own specific provisions.

Businesses branded as banks or banking apps sit under all of these structures. Some are credit institutions; many operate as EMIs or through an investment firm entity; some are agents of another regulated firm and hold no relevant authorisation of their own. So the first task is precise and slightly boring: identify the exact legal entity that would provide the service, and the authorisations it actually holds. "We are a neobank, therefore Article 60 applies" is not a sentence Legal should let pass.

What Article 60 gives a credit institution

For a credit institution, Article 60(1) is short. The institution may provide crypto-asset services if it notifies its home competent authority of the information required under Article 60(7) at least 40 working days before providing those services for the first time.

The route replaces the Article 59 authorisation process with a notification, which is a genuinely different regulatory position from a fintech applying for CASP status from scratch. It is worth being equally clear about what it is not. It is not an exemption from MiCA: the bank provides the services within MiCA's framework and its ongoing obligations. The 40 working days is an advance notification period, not an approval period, and nothing in the article describes an approval being granted at the end of it. And the route belongs to the credit institution as an entity, not to a group or a brand, which loops back to the previous section.

Notification does not mean paperwork only

Article 60(7) is where the apparent lightness of the route disappears, because the notification is a substantive description of a working crypto business.

Depending on the services intended, the package includes a programme of operations setting out the crypto-asset services to be provided and how they will be marketed; the internal control mechanisms, policies, and procedures for anti-money-laundering compliance; a risk assessment framework for money laundering and terrorist financing; a business continuity plan; technical documentation of the ICT systems and security arrangements; procedures for the segregation of clients' crypto-assets and funds; a description of the custody and administration policy where custody is intended; and a description of the execution policy where execution of orders is intended.

The competent authority then has, under Article 60(8), 20 working days from receipt to assess whether all required information has been provided. If the notification is incomplete, the authority sets a deadline for the missing information of up to 20 working days, and the notification periods are suspended until that deadline expires. Further requests for completion or clarification are at the authority's discretion. Two consequences follow. First, the entity cannot begin providing the crypto-asset services as long as the notification is incomplete; the regulation says so in terms. Second, the realistic timeline is driven by the quality of the package, not the number in the article. A bank that submits a complete notification is in a different position from one that spends months in the completeness loop, and the difference is preparation, not regulation.

So the honest framing is this: for qualifying banks, Article 60 changes the regulatory route, and the route still runs through a full description of custody arrangements, execution policy, segregation, AML controls, and ICT security. Which raises the practical question of how much of that the bank wants to operate.

Decide what the bank actually wants to operate

A credit institution could, in principle, take on the full set of crypto activities itself: receiving customer instructions, executing them in the market, maintaining venue connectivity, running crypto treasury and settlement, custodying client assets, and producing the reporting and reconciliation behind all of it. The commercial question is whether it needs to, because each function the bank operates is a function it must build, staff, and describe in the notification.

The alternative division keeps the customer side with the bank and places the market side with a regulated counterparty. The bank owns the proposition, the pricing, and the customer relationship; the counterparty provides market access, execution, and custody behind it. The distinction from white-label matters: in this structure the counterparty is not a consumer brand and does not provide the bank's customer-facing product. The customer stays with the bank, and the counterparty sits behind it for the market activities. Aplo's bank proposition is built this way. The economics of that division, and of the alternatives, are a subject in their own right; the point here is regulatory and operational, which is that the division changes what the bank's notification and operating model must cover in depth.

A narrower service perimeter can reduce what the bank has to build

The division of functions also matters for institutions that do not qualify for Article 60(1) at all.

Where the entity is not a credit institution, the appropriate route depends on its existing authorisations, its legal form, and the exact crypto-asset services it intends to provide, and the Article 60 routes for investment firms and EMIs are narrower in specific ways described above. In an outsourced execution model, the institution's own regulated scope can sometimes be narrower than the full service set its customers experience, because the external CASP performs the execution and market-facing services. One form this takes is the institution providing custody plus reception and transmission of orders while the external CASP carries execution, where that division fits the institution's licence position.

The qualifier is doing real work in that sentence. Whether a narrower perimeter is available, and what it must contain, is a case-by-case assessment for the institution's Legal and Compliance teams against its actual permissions and its actual product. No provider can answer it generically, and a provider that claims to should be read with suspicion.

Outsourcing execution does not outsource governance

Whichever structure is chosen, using an external CASP does not transfer the bank's responsibilities to it.

The bank still owns its regulatory perimeter and the obligations inside it. It still designs the client proposition and its pricing, communicates with its customers, and answers for what they are told. It still performs counterparty due diligence on the CASP, oversees the outsourced relationship on an ongoing basis, and runs the internal controls and governance around a new asset class, including how the integration between its systems and the counterparty's is monitored day to day. None of that can be delegated, and no CASP's authorisation covers the bank's own obligations.

What outsourcing changes is narrower and still valuable: which market functions the bank has to operate itself, and therefore how much exchange-grade infrastructure sits inside the bank's own walls and its notification.

What to look for in the CASP on the other side

Once the market side is placed with a counterparty, the diligence on that counterparty becomes part of the bank's own file. The questions worth asking in writing:

Is the exact legal entity authorised, and for which crypto-asset services? Brands are not authorised; entities are, and the services covered by an authorisation are listed on the registers. Does the provider act as agent or principal, which shapes both the economics and the conflicts around every order? How are client assets safeguarded, in what segregation structure, and how is it reconciled? What execution evidence comes back: venue-level fills, benchmark comparisons, and fees stated separately from the market price? How does the integration reach the bank's systems for orders, custody, settlement, and reporting? And how does the relationship work across the jurisdictions the bank operates in, where passporting matters? There is a broader treatment of choosing a crypto provider under MiCA now that the transitional period has ended, and of what institutions should expect from a crypto prime broker beyond bare market access.

The registers are where that diligence should end up regardless of the provider, since entities and services are verifiable there and brands are not. Aplo SAS, for its part, holds MiCA CASP authorisation supervised by the AMF in France, with passporting requested, not yet granted, across seven further EU markets.

Article 60 should shape architecture early

The pattern that goes wrong is sequencing. Product decides the proposition, Engineering scopes the build, and the regulatory route is asked to accommodate decisions already made, at which point it turns out the chosen structure puts execution inside an entity that cannot notify for it.

The workable sequence runs the other way. Identify the regulated legal entity and what it holds. Define the customer proposition. Map the crypto-asset services that proposition actually requires, in MiCA's terms rather than product language. Decide which of those services the bank wants to perform and which will sit with an external CASP. Confirm the Article 60 position, or the alternative route, for that exact division. Then build the operating model and the notification package around the structure, rather than retrofitting the structure to the build.

Run in that order, the notification stops being a compliance formality bolted onto a finished product and becomes what it is in the regulation: a description of an operating model the bank has already designed deliberately.

Mapping a bank crypto proposition under MiCA? Aplo can talk your Product, Legal, and Compliance teams through how its market access, execution, and custody model sits alongside the institution's existing permissions.