EU Payment Institution License vs E-Money Institution License

Most founders approach the Payment Institution versus Electronic Money Institution decision with a rule of thumb already in hand: if the product moves money, get a PI; if it stores value, get an EMI. That shorthand has gone stale. Case law and regulatory guidance issued over the past several years have narrowed what counts as e-money issuance. The boundary the shorthand describes no longer sits where most founders think it does.

Why the PI/EMI Choice Is Harder Than the Standard Summary

The two-directive structure of EU payments law makes the choice look simpler than it is. PSD2 governs payment institutions, EMD2 governs e-money institutions, and the two statutes cover overlapping ground in ways that leave the actual boundary less tidy than the textbook summary suggests. Both licenses authorize the same list of PSD2 Annex I payment services. The PI is barred from one specific activity on that list: e-money issuance. The EMI adds exactly that one power back on top of an otherwise identical base. Treated loosely, that single difference gets rounded up into a much broader distinction than the law actually draws, and the rounding has consequences. A founder who defaults to EMI pays a higher capital requirement and waits through a longer authorization timeline for powers the business may never use. A founder who defaults to PI on the assumption that their stored-balance product is just payment processing may discover, after launch, that the product requires e-money issuance after all. Both mistakes are common, and both trace back to the same source: the "store value, get an EMI" heuristic was formed under a broader supervisory reading of what counts as e-money, a reading that EU courts and regulators have since formally narrowed.

What each license authorizes, stated precisely

A Payment Institution license authorizes the execution of payment transactions, money remittance, merchant acquiring, the issuance of payment instruments other than e-money, payment initiation services, and account information services. This is the full PSD2 Annex I list, minus one item. A PI cannot issue e-money, and it cannot hold client balances on its own books the way a bank holds deposits. Any funds passing through a PI's payment accounts have to be safeguarded, held apart from the firm's own assets, not commingled, not lent out. A PI can extend short-term credit when that credit is ancillary to executing a payment transaction, but it cannot take deposits or run a lending book funded from its balance sheet. Those require a banking license, full stop on that particular door.

An Electronic Money Institution authorizes everything a PI can do, plus the issuance and redemption of electronic money. EMD2 defines e-money precisely: electronically stored monetary value, representing a claim on the issuer, issued on receipt of funds for the purpose of making payment transactions, and accepted as a means of payment by persons other than the issuer itself. That single added power is what unlocks a specific set of products: digital wallets that hold a spendable balance, IBAN-based payment accounts where the balance itself is e-money rather than a passthrough, prepaid and debit cards funded from an e-money float, multi-currency accounts, payroll cards. E-money carries its own rule that has no PI equivalent: it must be redeemable at par value at any time the holder asks. And the same prohibition that binds a PI binds an EMI here too. An EMI cannot lend from the funds it safeguards, and it cannot pay interest out of that safeguarded pool. Both licenses, once granted by a home-state regulator, carry a passport that covers all thirty EEA states; authorization and jurisdiction are related but separate decisions.

CJEU Rulings and Regulatory Guidance on the Payment Services/E-Money Boundary

The two developments that pulled a large share of activity out of the e-money category entirely did the real intellectual work behind the current PI/EMI boundary. The effect, taken together, is that holding client balances and executing payments from them does not, on its own, make a firm an e-money issuer.

A regulatory guidance document addressed the question directly in Q&A 2022_6336, focused on the "acceptance by third parties" element built into the e-money definition. That element, the guidance holds, is not satisfied simply because a payee ends up with ordinary money in their bank account once an e-money balance gets redeemed. Acceptance requires the payee to receive e-money itself, as a distinct asset, under a direct contractual arrangement with the issuer. A payment that passes through a stored balance and lands as ordinary scriptural money at the other end is a payment service, not an act of e-money issuance, regardless of what sat in the account along the way.

Between the CJEU's reasoning and the EBA's Q&A, a substantial share of what the industry had been treating as e-money issuance under the older, more permissive reading no longer qualifies. The Bank of Lithuania has since adopted a position that captures the new logic in four words: "same function, same authorisation." If what a firm does functions as a payment service, the applicable license is a PI, whatever the balance sheet happens to look like in between.

This matters because Lithuania and a UK regulator were two of the jurisdictions that had taken the broader, earlier view of what counted as e-money, and that view pulled firms toward EMI licenses for activity that regulators would now sort differently. Wise illustrates the split concretely: its UK operations are licensed as an EMI under the FCA, while its Belgian operations are authorized as a PI under the National Bank of Belgium, two regulators looking at overlapping activity and landing on different regimes. The narrowing does not erase the EMI category. It sharpens what still belongs inside it, and that remainder is where the next section turns.

Where the EMI Remains the Only Viable Choice

None of the legal narrowing described above makes the EMI license redundant. A defined set of product features still requires one, and a founder building toward those features cannot rely on a PI to get there.

A genuine stored-value wallet, where the user holds a spendable balance that third parties accept as e-money under a direct contractual arrangement rather than a balance that simply gets redeemed into ordinary money on each transaction, needs an EMI. So does an IBAN-based account where the balance is held as e-money and the user can draw on it at will over an extended period, rather than a passthrough account tied to discrete payment instructions. Prepaid and debit card programs funded from an e-money float that the institution itself issues fall in the same category.

The strongest forward-looking argument for an EMI sits here too. A firm building toward stablecoin infrastructure or tokenized money products needs the EMI, because only credit institutions and EMIs may issue electronic money tokens under MiCA, and that restriction carries forward unchanged under PSD3. A firm whose current payment volumes would support a PI on their own may still have good reason to hold an EMI if the roadmap includes embedded wallets, multi-currency IBAN infrastructure, or EMTs. The decision is whether the product surface, today or on a credible roadmap, requires the single power that only an EMI carries. That answer feeds directly into what the license actually costs to hold.

Capital and Own-Funds Requirements by License

The capital gap between the two licenses looks straightforward at first glance and gets more complicated the deeper a business plans into it. A PI's initial capital requirement ranges from a lower threshold for firms doing money remittance only, up to a higher ceiling for firms offering the full Annex I service list. An EMI's initial capital requirement is fixed: €350,000, regardless of what mix of services the firm actually offers. At the founding stage, that gap is a real planning input, not a rounding error.

It is only the first layer. EMIs carry an ongoing own-funds obligation that most founders underweight relative to the initial capital figure. Under Method D, an EMI's own funds are calculated as a percentage of its average outstanding e-money. Below a certain volume, the fixed €350,000 floor is what governs. Past that volume, the percentage-based calculation overtakes the floor, and the own-funds requirement starts scaling directly with the size of the e-money float the institution carries. A fast-growing issuer needs to model that curve against its own volume projections well before it hits the threshold, not after.

The Paysera ruling complicates the picture further. An EMI that runs payment services not linked to its e-money issuance has to apply Methods A, B, or C, the standard PI own-funds methodologies, to that portion of its business. In practice, those methods can demand more own funds than Method D would, which partially cancels out whatever apparent advantage a lower PI-style threshold might have suggested. Safeguarding sits outside all of this math in both license types: the entirety of client funds has to sit in a segregated account at a credit institution, in secure low-risk liquid assets, or under insurance cover, and none of that safeguarded money counts toward the own-funds requirement either way. Capital, in other words, is a variable a founder chooses and manages against a growth curve, not a one-time fee paid at the door.

How jurisdiction shapes the practical experience of both licenses

The choice of regulator shapes how either license actually functions in practice as much as the formal PI/EMI distinction does, so the two choices have to be made together.

Lithuania handles more PI and EMI authorizations than any other EU jurisdiction. The Bank of Lithuania accepts applications in a major international language, has no statutory residency requirement for directors though firms are expected in practice to have at least one Lithuania-resident executive director, and runs the fastest realistic licensing route in the bloc, three to six months for an EMI. Licensed PIs and EMIs both get direct access to SEPA through CENTROlink, without needing a bank intermediary to clear payments on their behalf. Revolut, Paysera, Nium, and ConnectPay are all licensed there; Payrnet was too, until its license was revoked in June 2023. Lithuania is also where the sharpest supervisory doctrine on the PI/EMI boundary has actually developed, including the ABC Projektai referral, the Paysera ruling, and the "same function, same authorisation" guidance described above. Speed of licensing there does not translate into light-touch supervision afterward. As recently as September 2026, following an inspection, the Bank of Lithuania ordered the EMI Verified Payments to restore capital adequacy by 1 October 2026, and, pending a separate decision, barred the firm from onboarding new clients, encumbering assets, or lending in the meantime. A jurisdiction that licenses quickly can still watch closely.

Other jurisdictions trade speed for other advantages. Cyprus and Malta both run authorization timelines in the six-to-nine-month range. Ireland runs longer, closer to twelve to eighteen months, a tradeoff firms sometimes accept for other reasons tied to market access or banking relationships. None of these jurisdictional differences change what a PI or an EMI is legally authorized to do. They change how long it takes to get there, how a regulator behaves once a firm is licensed, and how directly the firm can reach core payment infrastructure, all of which belong in the same decision as the license type itself.

The concrete questions that determine which license fits a given business

The PI/EMI decision comes down to a small number of yes-or-no product questions rather than a general preference for one regime over the other, and working through them in order resolves most of the ambiguity a founder is likely to face.

Will users hold a spendable balance inside the product that third parties accept as e-money under a direct contractual arrangement? If yes, the answer is EMI. If the balance is merely held in transit, with each payment initiated by a discrete instruction and redeemed into ordinary money at the other end, the ABC Projektai reasoning suggests a PI may be enough.

Will the business issue IBANs, prepaid cards, or debit cards funded from a float that it holds as the issuer? If yes, the answer is EMI: these are product surfaces that by definition require e-money issuance, not a payment service sitting next to one.

Is the business issuing, or planning to issue, electronic money tokens under MiCA? If yes, the answer is EMI, because only credit institutions and EMIs may issue EMTs, and PSD3 does not change that restriction.

Answered honestly and in sequence, these three questions do most of the work that the old shorthand tried to do in one line. A firm that answers no to all three has a strong case for a PI, at lower capital and on a faster track. A firm that answers yes to any one of them needs to plan for an EMI from the outset, including the own-funds curve and the jurisdiction that will supervise it, rather than discovering the requirement midway through a product build.