New payment models in Europe

A wallet should work everywhere, process payments in seconds and feel effortless to use. Delivering on that promise requires banks, payment institutions, technology companies and merchants to work together. Whether this produces a viable service across Europe depends largely on how that cooperation is organised. Regulation shapes practical product decisions: who can provide which services, which infrastructure they can access and who bears the consequences when something goes wrong?

Consider a new wallet that lets customers pay directly from their bank accounts, both in shops and online. The provider develops the app, connects it to a payment service provider and uses external companies for identity checks, fraud detection and cloud hosting. After launching in one Member State, it plans to expand into other European markets. Later, it might add a wallet balance or stablecoin payments.

The product concept is straightforward. From a regulatory perspective, however, even a single new feature can change the provider’s role. Each new connection also creates dependencies that need to be managed in day-to-day operations.

Regulatory status depends on what you actually do

The first question is who does what within the model. Labels such as wallet, platform or technology provider are of limited help. What matters is the service a company actually provides and its relationship with users.

Payments law provides an exemption for technical services that support payment services without the technical provider ever taking possession of the funds being transferred. This is not a blanket exemption for business models that do not hold funds. Payment initiation and account information services are expressly excluded from it, as Article 3(j) of PSD2 makes clear.

For our wallet, it therefore matters whether the provider supplies a technical interface to an authorised payment service provider or itself provides a payment initiation service to the customer. Working with a bank does not remove the need to assess its own role. Depending on the setup, the provider may need its own authorisation, act as a registered agent of a payment institution or provide purely technical support. The terms used in contracts must reflect how the service actually works.

Product development should therefore begin with a clear picture of the payment process. This should show who receives the payment order, who executes it and who, if anyone, holds customer funds. Responsibility for customer identification, complaints and safeguarding customer funds must also be clear. These decisions affect authorisation requirements, costs and the time needed to enter the market.

This assessment needs to keep pace with the product. Providers that later add stored balances, new ways to pay or new customer groups should revisit their original regulatory classification.

European reach requires common rules

SEPA provides a common framework for euro credit transfers and direct debits across Europe. Wallets and merchant acceptance remain more fragmented. Being able to transfer money to an account in another Member State does not mean that a particular wallet can be used at the checkout there.

An announcement in late September 2026 illustrates the push to connect existing solutions. Bancomat, Bizum, EPI/Wero, SIBS–MB WAY and Vipps MobilePay announced the creation of a joint company, the European Network for Payments, to coordinate interoperability between their payment solutions. The planned phased rollout begins with cross-border payments between individuals, with online and in-store payments to follow. Another European initiative, the European Mobile Payment Systems Association (EMPSA), already works to make existing mobile payment systems interoperable across borders. Both initiatives reflect growing efforts to connect national payment solutions across Europe.

For a wallet provider, joining such a network can make it easier to reach customers and merchants. The participants first need to agree on clear, workable rules. When can a merchant treat a payment as confirmed? Who handles a complaint if the account is held in another country? What happens if one of the interfaces fails? Technical messaging standards answer only part of these questions.

A common rulebook must therefore also cover participation requirements, responsibilities, refund procedures and the handling of disruptions. It must allocate anti-money laundering tasks and define data protection roles. Anyone joining a network should also understand how its rules can be changed and what say they have in those decisions.

For merchants, the benefits ultimately depend on how the solution works in everyday use: integration with checkout systems, matching incoming payments to orders and processing refunds. These processes should be considered from the outset when planning a solution for use across Europe.

Instant payments change what a product can promise

Instant credit transfers provide an important basis for new account-based payment models. The Instant Payments Regulation requires euro credit transfers within its scope to be executed within ten seconds and, as a rule, around the clock. The obligations take effect in stages. The Regulation also creates the legal basis for payment and e-money institutions to access certain payment systems, subject to the relevant access requirements.

For our wallet, this creates an opportunity to give merchants certainty about receipt of payment within seconds. The product must, however, define exactly what the confirmation on screen means. A message saying that a payment order has been initiated is different from confirmation that the funds are available to the recipient. That distinction determines when the merchant can release the goods and who bears any remaining risk.

The revenue model changes too. As a rule, a payment service provider may not charge more for an instant credit transfer than for an equivalent standard credit transfer. Additional services can still have value in their own right, such as integration with merchant processes or contractual buyer protection. Providers therefore need to be clear about which service they are charging for.

A fast transfer does not automatically provide a way to reverse a payment when a purchase is disputed. Providers seeking to establish an account-based wallet for retail payments need to decide how to handle undelivered goods, returns and voluntary refunds. Customers’ statutory rights under the sales contract remain unaffected, but making those rights effective through the payment product requires dedicated procedures.

Verification of Payee reduces certain risks of misdirected payments and fraud by checking the account identifier against the recipient’s details. It does not establish whether a seller’s offer is genuine. The product should therefore avoid giving customers the impression that a successful match is a general guarantee of safety.

PSD3 and the PSR affect the entire payment process

While instant payments are already being implemented, the wider legal framework for payment services is being reworked. The third Payment Services Directive (PSD3) is intended primarily to govern the authorisation and supervision of payment institutions, including e-money services. The accompanying Payment Services Regulation (PSR) is intended to directly harmonise key rules on the provision of services and the rights and obligations of those involved.

Political agreement on the package was reached in November 2025, and the relevant European Parliament committee endorsed the agreed texts in May 2026. At the time of writing, the official legislative trackers for PSD3 and the PSR still show final adoption as pending. Providers should therefore treat the reform as a set of upcoming changes to prepare for.

The planned changes to open banking are particularly relevant. The package aims to remove barriers that prevent eligible third-party providers from accessing payment accounts and to give users more control over the data access permissions they have granted. The European Parliament highlights, among other things, prohibited barriers to access and dashboards for managing permissions. For an account-based wallet, how useful these rights are in practice depends on the quality of the interfaces and authentication processes.

There is also a stronger focus on fraud prevention and liability, including scams in which criminals impersonate a payment service provider and persuade customers to make a payment. The political agreement provides for additional prevention duties and corresponding liability rules. Whether a refund is required in a particular case will depend on whether the relevant legal conditions are met.

Providers should therefore review how a suspicious payment is handled from start to finish. Who identifies the risk? Who can intervene? What warning does the customer see, and what information will be available later to investigate a complaint? Where several partners share these tasks, their systems and contracts must work together. Updating the terms and conditions alone will not be enough.

Outsourcing requires effective oversight

It would be hard to make our wallet commercially viable if the provider had to operate every technical component itself. External specialists can speed up the launch and provide services that would be costly and time-consuming to build in-house. As tasks are shared, oversight, access to information and clear, enforceable agreements become more important.

Since 17 January 2025, DORA has provided a central framework for financial entities within its scope. The Regulation governs risks arising from information and communication technology (ICT) and extends beyond traditional outsourcing. The ongoing use of ICT services can also fall within its scope. Austria’s Financial Market Authority (FMA) explains the ICT third-party risk requirements, including registers of information, risk strategy, due diligence on providers, contractual provisions and exit strategies. Technology providers should understand these requirements too, as they feed into contracts with their regulated clients.

Contract negotiations need to reflect how important the service is to the business. More demanding requirements apply to ICT services that support critical or important functions. These include detailed service-level targets, extensive audit rights and arrangements for an orderly exit. A general promise of high availability cannot replace these provisions.

The financial entity remains responsible for meeting its regulatory obligations, as Article 28 of DORA expressly states. This is separate from its liability to customers and any right of recourse against a service provider. A customer’s claim and a claim for compensation against the technology partner are subject to different conditions, and the amounts recoverable may differ considerably.

For example, a payment service provider may have to refund a customer even though its contract with the technology provider responsible for the problem allows only limited compensation or service credits. The payment service provider may have to bear the shortfall. These situations should be considered when allocating tasks and drafting contracts.

An exit strategy needs to be just as specific. What data would a replacement provider need? In what format would it be available? How long would migration take, and who would keep the service running in the meantime? Using two providers also offers only limited backup if both rely on the same key subcontractor. Providers therefore need to understand the full service delivery chain.

Stablecoins bring payments law and MiCA together

Adding stablecoins to our wallet raises further questions about the regulatory boundaries. E-money tokens are particularly relevant to payment models. These are crypto-assets that seek to maintain a stable value by referencing a single official currency. Issuance, custody, exchange and transfer must each be assessed separately.

Authorisation under MiCA does not automatically satisfy all the requirements that payments law may impose on such a model. In its No-Action Letter on the interplay between MiCA and PSD2, the European Banking Authority (EBA) identified transfers of e-money tokens on behalf of customers, in particular, as activities that may constitute payment services. In February 2026, it provided further guidance on the supervisory treatment of the providers concerned. These statements address supervisory practice; they do not create a statutory exemption from the authorisation requirement.

For the wallet provider, the new payment option must fit into the existing allocation of roles and authorisations. Who issues the token, who carries out the transfer and who enables the merchant to receive the proceeds in a bank account? The connections between tokens, payment services and conventional accounts are central to determining which partners and authorisations are needed. The costs and risks at these points also need to be factored into the product’s commercial assessment.

The digital euro would be a different form of money: digital central bank money, whereas e-money tokens are issued by private entities. The Eurosystem addresses both developments in its payments strategy, emphasising the interaction between public infrastructure and private solutions. Any introduction of the digital euro remains subject to the necessary legislation and a subsequent decision to issue it. For product decisions today, the main question is whether the architecture can accommodate additional ways to pay without having to rebuild all customer and merchant processes.

Decisions to make before launch

For our wallet, product design and regulatory arrangements are closely connected. Seeking its own authorisation gives a provider different options and obligations from those of a purely technical provider. Joining a payment network may extend its reach while also binding it to the network’s rules. Choosing a core technology partner also determines some of its operational dependencies.

Product, legal and operations teams should make these decisions together from the outset. It helps to examine the payment process from the perspective of a customer whose payment fails or who falls victim to fraud. Can the provider establish what happened, reach the responsible party and actually process a refund where the law requires one?

Experiences like these shape trust in new payment solutions. Paying should be simple for the customer. To make that possible, the companies involved need clear agreements on what happens behind the scenes and the ability to manage those processes in practice.

About the authors

Dr Oliver Völkel, LL.M. (Columbia), is an attorney and partner at CERHA HEMPEL. He specialises in banking and capital markets law, FinTech and crypto-assets. He advises banks, financial service providers and crypto businesses, and is a legal author, editor and university lecturer.

Mag. Leyla Farahmandnia-Fluch is an attorney and Senior Associate at CERHA HEMPEL. Her previous senior legal role at a well-known payment service provider gave her practical experience with mobile payment solutions, including the regulatory and contractual aspects of international payments partnerships.

CERHA HEMPEL supports payment service providers, e-money institutions and FinTech companies from the initial product idea through authorisation to ongoing operations. We assess authorisation requirements, assist with proceedings before the Financial Market Authority and draft customer, cooperation and outsourcing agreements. We also advise on DORA, anti-money laundering and data protection, as well as liability and refund issues. A particular focus is the interaction between payment services and crypto-assets, for example when integrating stablecoins. As businesses prepare for PSD3 and the PSR, we help them identify the changes needed to their business models, contracts and internal processes and turn those findings into practical steps.