Launching an e-wallet company in the European Union involves much more than building an application where users can see a balance and make payments. Behind the interface there needs to be a regulated entity, a ledger capable of accurately recording customer funds and transactions, and financial infrastructure that connects the wallet to banks, payment schemes and other providers.
For most founders, these requirements can be grouped into three areas: regulatory authorisation or registration, core banking software, and payment infrastructure.
The three should be planned together. A decision made during licensing can determine how customer funds must be held, which functionality the software needs to support and what type of banking partners the company will require.
1. Choose the right payment or e-money regulatory status
The first question is what the wallet will actually allow customers to do.
Will users simply initiate payments, or will they be able to keep money in the wallet? Will the company provide payment accounts? Will customers receive and send transfers? Will the wallet support cards, currency exchange or other financial services?
This distinction matters because a Payment Institution and an Electronic Money Institution do not perform exactly the same regulatory function.
Under the current EU framework, there are four broad routes that founders commonly encounter.
Authorised Payment Institution
An Authorised Payment Institution, often referred to as a PI, is designed for companies providing regulated payment services.
Depending on its authorisation, a PI can support activities such as executing payment transactions, money remittance, acquiring or other payment services covered by the applicable framework.
A PI can hold payment accounts where these are used for payment transactions, but funds received for providing payment services do not automatically become electronic money.
This distinction is important for e-wallet founders. If the proposed product is primarily about executing payments rather than issuing stored monetary value, a PI structure may be sufficient.
For authorised PIs, PSD2 currently provides different minimum initial capital requirements depending on the payment services being offered, ranging from €20,000 to €125,000. These are initial thresholds rather than a complete picture of regulatory capital: ongoing own-funds requirements and national implementation must also be considered.
Small or Registered Payment Institution
EU legislation also allows Member States to provide an exemption from the full PI authorisation regime for smaller payment businesses.
These businesses are often described in practice as Small Payment Institutions, Registered Payment Institutions or exempted payment institutions, although terminology varies between jurisdictions.
Under PSD2, the Member State can set a transaction-volume threshold for this regime, but it cannot exceed an average of €3 million in payment transactions per month over the relevant period.
The main advantage is a lighter regulatory route for a business operating at a smaller scale. The trade-off is that it is generally a domestic solution rather than a route for building a payment business across the entire EU.
For a founder planning to test a product in one country, this can sometimes be relevant. For a company intending to expand quickly across several EU markets, full authorisation may be more appropriate.
Authorised Electronic Money Institution
For many full e-wallet models, an Authorised Electronic Money Institution, or EMI, is particularly relevant.
Where the business itself issues that electronic value, the regulatory analysis moves beyond simply executing payment transactions.
A company holding E-money Institution license can issue electronic money and can also provide payment services within the scope of its authorisation.
Under the existing E-Money Directive, the minimum initial capital for an authorised EMI is €350,000.
The regulatory application normally goes much further than demonstrating that the company has the required capital. Regulators will typically examine governance, shareholders and management, AML controls, safeguarding arrangements, risk management, outsourcing, IT systems, security, financial forecasts and how the entire operating model works.
For an e-wallet intended to hold customer balances and operate across multiple European markets, this is often the regulatory model that deserves the closest examination.
Small or Registered Electronic Money Institution
A fourth possibility is an exempted or small Electronic Money Institution.
EU rules allow Member States to introduce a waiver from parts of the full EMI authorisation framework for smaller e-money businesses. Under the current E-Money Directive, the relevant ceiling cannot exceed €5 million in average outstanding electronic money, although Member States can impose a lower limit.
Again, this is not the same as operating without regulation.
The entity remains registered and subject to applicable requirements, including relevant AML obligations. The major limitation is geographic: the EU framework does not give institutions operating under this waiver the same cross-border rights available to fully authorised institutions.
The exact availability, terminology and conditions of these small or registered regimes differ between EU countries. A founder should therefore choose the jurisdiction only after establishing which regulatory model fits the intended product and expansion strategy.
The EU payments framework is also undergoing reform through PSD3 and the proposed Payment Services Regulation. Political agreement has already been reached, but the new framework has not yet fully replaced the existing PSD2 and E-Money Directive regime. Companies preparing an application should therefore verify the rules and transition arrangements applicable at the time they apply.
2. Build the wallet on the right core banking software
Obtaining regulatory approval does not create the actual wallet.
The company needs a technology layer capable of managing customers, accounts, balances and transactions. For many e-wallet businesses, this role is performed by core banking software.
The core system effectively becomes the operational engine behind the customer-facing application.
It may maintain individual customer ledgers, record debits and credits, calculate fees, support multiple currencies, process internal transfers and provide operations and compliance teams with a real-time view of what is happening inside the platform.
The system may also need to integrate KYC and KYB providers, transaction monitoring, sanctions screening, accounting systems, card processors, banks and payment providers.
APIs are therefore one of the most important factors when selecting a platform.
Scalability also matters. A wallet initially supporting EUR transfers may later add GBP, PLN or USD, cards, business accounts or additional payment providers. Replacing the core platform after the business has already accumulated thousands of customers can be significantly more complicated than designing for these integrations from the beginning.
The objective should not be to select the platform with the longest list of features. It should be to select software that matches the regulatory, financial and operational architecture of the particular wallet.
3. Connect the wallet to real payment infrastructure
A licence and core banking platform still do not give an e-wallet access to the financial system.
The final layer is the network of external partners that allows customers to actually deposit, transfer, exchange and spend money – connect to payment rails.
An e-wallet targeting European customers may require access to SEPA payments and potentially SEPA Instant. It may need banking partners to provide operational or safeguarding accounts and additional providers for international transfers.
If customers are given individual account details or IBANs, an appropriate banking or payments partner may need to provide that infrastructure.
A multi-currency wallet may require an FX and liquidity provider. A product offering debit cards will need card issuing and processing infrastructure, potentially together with a card scheme relationship through the relevant programme structure.
The company may also need KYC/KYB, AML and sanctions-screening providers, fraud monitoring tools and other specialist services.
The result is rarely a single integration.
A typical e-wallet can involve several providers working behind one customer experience. A user may fund the wallet through one partner, hold funds through another institution, exchange currency through an FX provider and send the resulting payment through a separate payment rail.
That creates an important operational requirement: the company needs to understand not only whether each provider works individually, but how they work together.
Settlement times, transaction limits, supported countries, rejected-payment handling, safeguarding arrangements, reconciliation files, API availability and compliance restrictions all affect the final product.
This is why payment infrastructure should be discussed with potential partners while the licence application and technology architecture are still being developed, rather than after both are complete.
See also: How Mobile-First Indexing is Reshaping Dental Website Performance
Building an e-wallet means connecting three systems
An e-wallet may look simple to the customer. Behind it sits a much more complex structure.
The regulatory status determines what the company is permitted to do. Core banking software records and controls what happens inside the wallet. Banking and payment infrastructure connects that wallet to the external financial system.
For founders, the practical sequence is therefore:
regulation → core banking software → payment infrastructure.
In reality, however, these three workstreams need to develop in parallel.
A change in the planned payment services can alter the licence requirements. A banking partner can require changes to onboarding or transaction monitoring. A new payment rail can require additional functionality in the core system.
Planning these dependencies from the beginning makes it much easier to move from an e-wallet concept to a product that can actually process real customer transactions.
