When Your Stablecoin Product Becomes a Payments Business

One token, two regulatory frameworks. The services you provide determine which obligations apply

What MiCA and payments law mean for your product and your budget

By Kira Maevska | 24 September 2026

If you think getting a CASP licence is the end of your stablecoin licensing journey... well, not always.

That “Send” button may come with a second regulatory bill.

For certain stablecoin services, your business needs additional payment authorisation or an appropriately licensed payment partner. That can change your launch budget, your timeline and what customers can actually do in your app.

The tricky part is that buying a stablecoin, keeping it in an account and sending it elsewhere can look like one seamless service to the customer. The rules treat those activities differently. Even “we only let customers withdraw to their own wallets” does not automatically solve the problem.

Before you pay for another licence or redesign the product, work out exactly where your business starts providing a payment service. That is what determines whether you need your own permission, a partner or a different product design.

Why payments law enters the picture

The stablecoins at the centre of this issue are electronic money tokens, or EMTs. Broadly, these are crypto-assets designed to maintain a stable value by referencing one official currency. MiCA treats them as electronic money. PSD2, the EU’s current Payment Services Directive, treats electronic money as “funds”. That is how a crypto product can also become a payments business.

The distinction matters. “Stablecoin” is a market term, and not every stablecoin is an EMT. Asset-referenced tokens have a different MiCA classification. Nor does choosing a dollar-referenced EMT remove the issue: the definition is not limited to euro tokens.

Issuing a stablecoin and offering services with someone else’s stablecoin are also different businesses. Issuing an EMT generally requires a bank or electronic money institution, subject to specific legal exemptions. If your business transfers existing EMTs for customers, a payment institution licence may be the relevant additional permission. You do not automatically need to become an EMI.

The European Banking Authority explained its approach in EBA/Op/2025/08, dated 10 June 2025, and a follow-up opinion, EBA/OP/2026/01, dated 12 February 2026. These opinions guide national regulators. They do not change the legislation, but they matter when a regulator assesses your business.

Buying holding and sending are different services

Consider three examples of what a customer might do in your app.

A customer buys EMTs directly from an exchange. The exchange sells from its own inventory and delivers what it has sold. EBA distinguishes this kind of exchange, using the company's own capital, from moving funds on a customer’s behalf. It also treats arranging crypto purchases using EMTs as outside the payment services category for these purposes.

This gives businesses room to build exchange products without assuming that every EMT purchase requires a payments licence. But you need to describe what actually happens. Selling your own assets, executing a customer’s order and moving assets the customer already owns are different activities.

Delivering what you have sold to the buyer’s own address can be part of the exchange. A transfer does not become exempt simply because it follows a trade. You need to establish whether your company is delivering its own sale or providing a transfer service for the customer. Your contracts and the way assets actually move must tell the same story.

A customer leaves EMTs in custody and later requests a withdrawal. MiCA recognises custody as a service in its own right. It can be offered independently of exchange or order execution.

But sending those EMTs back to the customer raises a separate question. The February 2026 EBA opinion specifically addresses this situation: a withdrawal to the same customer may require payment authorisation even where the custodial wallet is not a payment account.

For a founder, that makes “customers can withdraw only to their own wallets” an insufficient basis for a CASP-only model. It may narrow product functionality, but it does not automatically remove the payment service.

A customer uses a balance to pay suppliers or send EMTs to other people. EBA treats a custodial wallet that allows transfers to and from third parties as a payment account. Offering that functionality takes your product beyond buying crypto and receiving the purchased assets.

The same distinction matters within MiCA. The Commission’s answer published as ESMA Q&A 2071 states that a service meeting the definition of crypto-asset transfers requires the relevant MiCA permission even when it forms part of another crypto service.

Calling a transfer “part of the exchange” is not enough. The way the service works has to support that conclusion.

Your own licence or a payment partner

If your product includes regulated EMT payment services, you have two main routes: obtain the payment authorisation yourself or work through a payment service provider whose licence covers those services.

Your own licence can be a payment institution authorisation limited to the relevant EMT activities. It must cover the services you actually deliver. A limited licence still comes with the responsibilities of a regulated payment institution.

This should not be confused with a small payment institution registration under PSD2’s separate exemption regime. That regime does not offer the same European passport, and EBA’s CASP recommendations expressly exclude relying on Article 32 as the solution to this overlap.

The partner route can include becoming the registered agent of a payment service provider, as EBA’s February 2026 opinion explains. The partner must actually provide or take responsibility for the payment service under the arrangement. Simply connecting its API or signing a commercial agreement does not establish that responsibility.

Before selecting a partner, establish which legal entity contracts with the customer, whose permission covers each operation and who handles payment complaints, authentication and liability. The partner may itself need a MiCA permission for its part of the service.

The commercial trade-off is control. Your own licence gives you more control over the services it covers, while bringing capital requirements and operating costs. With a partner, your pricing, available features and future changes also depend on another regulated business.

What regulators are doing in practice

Some regulators have already explained how an EMT-focused payment licence can work in practice.

France provides a concrete example. ACPR allows a reduced application file for firms that hold, or are obtaining, CASP status and commit to limiting their payment services to their EMT activities. The result is a payment institution authorisation with a restricted scope. It does not authorise payments in ordinary bank money, including through its European passport. Expanding beyond the specified EMT business requires an extension and a full application file.

ACPR also distinguishes transfers linked to a payment account from transfers without one, identifying money remittance for the latter. This is commercially significant: removing a payment account from the design does not necessarily remove the payment service.

Ireland also has an EMT-specific route through the ordinary payment institution framework. The Central Bank’s published FAQ describes a shorter application form, reuse of current CASP documentation and a condition restricting the payment permission to specified EMT activities. Subsequent expansion requires approval. It also warns that an existing payment institution partnering with a CASP will likely need approval for the change to its business model.

Austria emphasises the actual business model. FMA distinguishes bilateral exchange from client transfer services and points to the broad MiCA treatment of transfers embedded in other services. Its guidance also says that the EBA relief generally assumes the same legal entity holds both authorisations. Corporate structure therefore affects the analysis; two licences in two group companies do not necessarily produce the same outcome.

Lithuania points businesses towards a licence or a licensed provider. Its June 2025 communication also separates exchange from EMT transfers and custodial wallets with payment functions. Decide which entity will provide the payment service before committing to how the product will work.

There is a real market example in the Netherlands. DNB’s register records an EMI authorisation for zerohash europe B.V. effective from 13 May 2026. The company announced it on 18 May, alongside its existing MiCA authorisation. That demonstrates one infrastructure provider’s chosen model; it does not establish that every stablecoin business needs EMI status.

Use these examples to prepare a more precise licence application or partner brief. Your customers and the services they need should drive the business model.

What changes with a self-custody wallet

You can also build a product where customers use your software to move their own assets, while your company provides neither custody nor a transfer service on their behalf.

MiCA’s recital 83 expressly recognises providers of non-custodial wallet hardware and software as outside its scope. PSD2 also excludes qualifying technical services that support payments without the provider possessing the funds. That exclusion has limits, including for payment initiation and account information services.

A product built around genuine user control can therefore have different licensing needs. The wallet may let the user prepare, sign and submit transactions without the operator holding the assets or agreeing to execute transfers for the user.

The customer must really control the assets. Calling the wallet “non-custodial” does not make it so.

Before relying on that model, establish what happens in normal use, recovery and failure. Can your company move the assets? Does it retain a usable key or a necessary signing role? Can it change the controls that govern spending? Does the customer remain able to access and move assets if your service disappears?

These are questions for assessing the real allocation of control, not a statutory checklist. A particular recovery mechanism or multi-party computation design does not determine the answer by its name. Equally, the customer retaining some control does not automatically rule out custody by another party.

Giving users control also changes what you can promise them. If your company cannot access the assets, your ability to recover access or intervene in a transaction may be limited. Customer support and recovery promises must match what the wallet actually allows you to do.

Adding a swap button changes the analysis

You can explore connecting that wallet to swap protocols or a licensed exchange widget. The next step is to check what your company does when the customer presses “Swap”.

The wallet software and the exchange function need separate analysis. MiCA regulates activities such as receiving and transmitting orders and executing orders on behalf of clients. Those services do not all depend on taking custody.

For a widget integration, the relevant questions are practical: does the customer deal directly with the licensed exchange, or does your company accept and route the customer’s order? Who determines the service terms, executes the trade and receives the fee? Does the exchange’s permission cover the transaction and the customers being served?

This can also affect how you earn money. MiCA restricts payments for routing client orders to a particular venue or provider where the operator provides reception and transmission of orders. Before building your forecasts around affiliate fees, check what service you provide and what the fee pays for. Calling it a referral fee does not settle the issue.

Using a decentralised protocol also does not automatically make the commercial interface fully decentralised. MiCA distinguishes services delivered without an intermediary from activities performed or controlled by an identifiable operator, including where part of the service uses decentralised technology.

A genuinely non-custodial wallet with a clearly defined exchange integration can be a workable model. To assess it, look at the whole service: what you control, what you agree to do for the customer and how you earn your fees.

For the community, self-custody also does not mean that every interaction will be free of identity or transfer checks. Under the EU Transfer of Funds Regulation, pure person-to-person transfers without a CASP are excluded, while transfers involving a CASP can attract information requirements even when the other address is self-hosted. For transfers above EUR 1,000, the legislation includes specific assessments of whether the relevant self-hosted address belongs to or is controlled by the CASP’s customer.

What this does to your budget

The application is only part of the cost. Your budget also needs to cover running the payment service.

That includes capital requirements, payment security and authentication, fraud reporting, complaints and liability for unauthorised transactions. EBA recommends some supervisory relief where requirements overlap or are technically difficult to apply. The payment rules still matter. “The blockchain transaction cannot be reversed” does not, by itself, settle who bears the loss.

Capital needs particular care. EBA’s baseline is cumulative MiCA and PSD2 requirements, which Ireland expressly reflects in its FAQ. France’s published treatment of its restricted EMT model discusses how the payment requirements relate to the CASP overhead-based requirement. A business should obtain a calculation for its own scope and structure before treating either “the existing capital is enough” or “the requirement simply doubles” as a budget assumption.

The upside is that the right payment permission lets you offer the transfer features your customers need. The extra revenue must support the cost and responsibility of running them. An exchange whose customers mainly want to buy and take delivery may reach a different decision from a platform built for payroll or supplier payments.

What has changed since the first EBA letter

The general EBA authorisation transition ended on 2 March 2026. The February opinion set out conditions under which regulators could let certain pending applicants continue, including restrictions on marketing and new customers for the relevant services. It did not give everyone more time. The separate maximum MiCA transition for existing providers also ended on 1 July 2026. A September 2026 launch cannot rely on those old transition headlines.

There is also a newer judicial development. In Betaal Garant Nederland, C-51/25, decided on 16 July 2026, the Court of Justice examined a construction security-deposit arrangement where banks executed the transfers. The judgment limits the credit-transfer classification in that setting and discusses the use of payment services as ancillary to another primary service.

That matters because a payment authorisation analysis must identify the actual service and the entity providing it. However, the case concerned a different business model and did not resolve every possible payment service classification. Arthur Cox highlights the unresolved money-remittance question; Linklaters explores a potentially broader reading of the judgment.

My assessment is that the decision justifies a fresh review of genuinely ancillary arrangements. It does not support treating all EMT transfers attached to custody or trading as exempt. Nor does a debate about the future PSD3 and Payment Services Regulation framework provide an operating permission today.

Before you build the next feature

Draw how the customer’s money and tokens move through your product. Show who owns or controls them and which company acts at each step. Then answer five business questions:

What is the essential customer promise? Buying crypto, retaining a balance, moving assets or paying someone else may require different capabilities.

Which actions will the company perform for the customer? Separate a sale and its delivery from later custody withdrawals and general transfers.

Who supplies the regulated service? Name the authorised entity and check its actual scope, including any restrictions.

What is the revenue model paying for? Exchange margin, software access, referrals and order routing can have different legal consequences.

What does the next product release change? Recovery, automated transfers, merchant payments or a new swap integration may change the original analysis.

Check what each new feature means for your licence, your costs and your customer promises before you commit to launching it. A “Send” button is easy to add to a product roadmap. The business behind it needs to be ready too.

About the author

Kira Maevska is a lawyer with over 15 years of professional experience. She advises crypto, Web3, fintech and technology businesses on business and token structuring, licensing, regulatory compliance, governance and fundraising. Her work focuses on translating legal requirements into practical structures that reflect a company’s products, customer base and commercial objectives.