E-money Institutions vs Payment Institutions: Main Differences and FAQs

That distinction affects more than licensing paperwork. It shapes how a fintech can hold customer funds, structure wallets, launch cards, design payment flows, and scale its operating model across the EU.

For many founders, the real mistake is starting with the product label rather than the legal function. Wallet, account, or app does not determine the licence. The real question is what the institution is doing with customer funds, what services it provides, and whether it is issuing electronic money under EU rules.

At a high level, a Payment Institution provides payment services. An Electronic Money Institution can also provide payment services, but it has an additional permission: it can issue electronic money.

That is the core difference.

Under the current EU framework, payment services are governed mainly by PSD2, while electronic money is governed by the E-Money Directive. The European Commission has proposed a future PSD3 and PSR package, including a new directive covering payment services and electronic money services, but the current legal distinction between PIs and EMIs still matters in practice today. You can see the direction of travel in the Commission’s financial data access and payments package.

A PI may be the right model when a business wants to execute payments, money remittance, acquiring, or certain other payment services without issuing e-money. An EMI may be the better fit when the product involves stored value, customer balances, wallet logic, or broader payment account-style functionality built around issued electronic money.

So the right question is not which licence is better. It is which licence matches the real mechanics of the product. That is exactly why Advapay’s EMI and PI licensing services are usually part of a wider structuring discussion, not just a filing exercise.

This is where many explanations become vague, but the legal idea is fairly specific.

Under the E-Money Directive, electronic money is monetary value stored electronically, issued on receipt of funds, represented by a claim on the issuer, and accepted by parties other than the issuer.

In practical terms, that usually means a customer gives fiat funds to the institution, and the institution issues a corresponding electronic value that can be used for payments or stored in a wallet-like environment.

That is why EMI structures are often associated with e-wallets, stored balances, prepaid instruments, and app-based payment ecosystems.

Just as importantly, electronic money is not the same thing as a bank deposit, and it is not the same thing as cryptocurrency. Electronic money exists within a regulated fiat-based framework. It is redeemable and tied to a claim on the issuer. Cryptoassets follow a different legal logic and, depending on the product, may fall under different regimes entirely.

For fintechs building wallet-led products, this is where software and licence design start to overlap. The regulatory perimeter affects the product stack, which is why firms planning these models often look at both core banking software and digital core banking capabilities at the same time.

A PI can provide payment services listed under the PSD2 framework. In broad practical terms, that can include activities such as executing payment transactions, money remittance, acquiring payment transactions, issuing payment instruments, and in some cases payment initiation or account information services.

An EMI can provide payment services too, but it also has the right to issue electronic money. That extra permission is what makes the EMI structure relevant for many wallet-based or stored-value fintech models.

This is where founders often need to slow down. Two products may look similar from the user’s point of view but require different regulatory treatment underneath. A card programme, for example, does not automatically mean EMI. But if the structure involves issuing and storing e-money, the EMI perimeter becomes much more relevant.

The same is true for customer balances. A user may think they have an account, but from a licensing perspective the critical question is what that balance legally represents, how funds are safeguarded, and whether the institution is issuing e-money or only providing payment services.

Advapay’s broader guide to different types of fintech, payment, e-money, MSB and banking licences is useful here because the legal label should follow the activity, not the marketing description.

One of the clearest operational differences is initial capital.

Under the current EU framework, an EMI generally requires initial capital of EUR 350,000. This is reflected both in the E-Money Directive summary and in Advapay’s own EMI and PI licensing overview.

A PI may require less initial capital, depending on the services it provides. Under PSD2, the familiar thresholds are EUR 20,000, EUR 50,000, or EUR 125,000 depending on the payment services in scope, as summarised by EUR-Lex. Advapay also explains these thresholds in its article on the differences between small and authorised EMI and PI licences.

That does not mean PI is automatically simpler in any meaningful commercial sense. It means the licence must fit the model. Choosing a PI structure for a business that really needs EMI functionality can create problems later, including product redesign, reauthorisation work, or a future licence upgrade.

Both PIs and EMIs also face substantial ongoing obligations. The licence type changes the permitted activity, but it does not remove the need for AML and CFT controls, safeguarding of relevant customer funds, governance and internal controls, operational resilience, compliance monitoring, and regulatory reporting.

The EBA also maintains a central register framework for authorised payment and electronic money institutions in the EU and EEA. Its register of payment and electronic money institutions is a useful reminder that both categories sit inside a serious supervisory structure.

A PI is often a better fit when the business is focused on payment execution rather than stored-value issuance.

That may include remittance models, payment processing flows, merchant acquiring structures, certain infrastructure or orchestration models, or regulated payment services without a true e-money wallet layer.

An EMI is often a better fit when the product depends on issuing electronic money as part of the customer experience.

That may include e-wallets, stored-value products, prepaid balances, multi-currency customer balance environments, or app-led payment products where customer funds sit inside an issued e-money structure.

In practice, founders should avoid reducing the decision to a UI feature. A wallet in marketing language is not enough. Regulators will look at fund flows, safeguarding, redemption logic, governance, outsourcing, IT systems, and the legal character of the service.

The more ambitious the product, the more important it becomes to design the licensing route and operating model together. That is why many teams combine fintech consulting with payments and transfers infrastructure and API-ready banking integrations rather than treating them as separate workstreams.

The difference between an EMI and a PI is easy to summarise but important to get right.

An EMI can issue electronic money and provide payment services. A PI can provide payment services but cannot issue e-money. That single distinction drives a much larger set of consequences around product scope, safeguarding, capital, compliance, and long-term operating model.

For fintech founders, the smartest move is not to start with the licence label. It is to start with the real business model: how money enters the system, what the customer balance represents, what payment services are provided, and how the product is meant to scale.

That is usually where the licensing answer becomes much clearer. If you are planning an EMI or PI launch, Advapay can help with EMI and PI licensing, fintech consulting, and the core banking infrastructure needed to turn authorisation into a workable operating model.