EMI vs PI: which authorisation fits your product?

Few decisions shape a European fintech's roadmap as much as choosing between a Payment Institution (PI) and an Electronic Money Institution (EMI) authorisation — and yet many founders make the choice based on which licence "sounds more suitable" rather than a rigorous mapping of product features to regulatory permissions. Choosing incorrectly does not just create paperwork; it delays filings by months and can force a genuine architecture rework once the mismatch surfaces.

The core distinction

Payment Institutions are authorised to provide payment services — executing transfers, acquiring transactions, issuing payment instruments — without issuing electronic money balances that customers hold with the institution over time. Electronic Money Institutions can additionally issue e-money: a stored monetary value that customers hold as a balance, redeemable at any time, typically underpinning wallets and stored-value products.

This is not a subtle distinction. If your product involves a customer topping up a balance and spending it down over days or weeks, you are very likely issuing e-money and need an EMI authorisation (or an EMI partner). If your product simply initiates or acquires payments without holding customer balances, a PI authorisation is usually sufficient and considerably faster to obtain.

Three questions that resolve most ambiguity

Do customers hold a balance with you?

If funds sit in an account you control, available for the customer to spend later, that is generally e-money territory, requiring EMI status (directly or through a partner) and the associated safeguarding obligations for those balances.

Do you need safeguarding of client funds as e-money specifically?

E-money safeguarding rules differ from payment services safeguarding rules in some jurisdictions — particularly around interest treatment and the permitted safeguarding instruments. Get legal counsel to confirm which regime actually applies to your specific fund flows, rather than assuming.

Are you primarily initiating or acquiring payments?

Pure initiation or acquiring services, without any balance holding, point clearly toward PI. If you are also considering account information services, that typically sits under a related but distinct PI permission (AISP) rather than requiring EMI status at all.

Safeguarding implications in practice

Both PI and EMI regimes require safeguarding of customer funds, but the operational implications differ. E-money issuers typically need to demonstrate a continuous, reconcilable link between issued e-money balances and safeguarded funds — which circles directly back to the ledger design questions we cover elsewhere: without an immutable, typed ledger, proving that link during a regulatory review is far harder than it needs to be.

Embedding versus obtaining your own licence

Obtaining either authorisation directly is a multi-month, resource-intensive process involving detailed governance, safeguarding arrangements, outsourcing policies and capital requirements. For many product teams, embedding under a licensed partner is the faster and lower-risk path to market validation.

Pay Engineers collaborates with licence partners such as Swan, OpenPayd, Modulr and Treezor when embedding is genuinely faster than a full own-licence journey, while still designing the technical integration so that a future transition to an own licence — if volumes justify it — does not require a ground-up rebuild.

A practical decision checklist

• Map every planned product feature against "holds a balance" versus "moves money without holding it".
• Confirm safeguarding treatment with counsel for your specific jurisdiction and fund flow.
• Evaluate embedding partners on technical integration depth, not just headline commercial terms.
• Design your ledger and KYC data model to be portable across partners from day one.
• Revisit the PI-versus-EMI question whenever a new product feature is proposed, not just at launch.

Where teams get this wrong

The most common mistake is applying for a PI authorisation because it is faster, then quietly building balance-holding features into the product roadmap six months later — discovering only at a compliance review that the authorisation does not cover what has already shipped.

Your licence type should be chosen from your product roadmap, not from whichever application form looked shorter.

How this plays out across markets

The PI-versus-EMI question is not purely a European concept — most jurisdictions with modern payments regulation draw a broadly similar line between money movement and money issuance, even where the specific licence names differ. Founders building for multiple markets simultaneously should expect to repeat this analysis per jurisdiction rather than assuming a single European conclusion transfers directly elsewhere.

This is particularly relevant for platforms expanding from a single home market into adjacent ones through passporting or local licensing. A feature that was clearly PI-appropriate at home can drift toward e-money territory once local payment habits or partner integrations change how funds actually flow in a new market, so the classification exercise deserves a fresh look at each expansion, not a one-time global answer.

Key takeaways

• PI suits products that move money without holding customer balances over time.
• EMI is required (directly or via partner) when customers hold a redeemable balance with you.
• Safeguarding obligations apply under both regimes but differ in operational detail.
• Embedding under a licensed partner can validate product-market fit faster than a direct application.
• Always map licence choice to the full product roadmap, not just the feature set at launch.