Home/Research library/Compliance Slows Launches

Guide · Licensing and regulatory requirements

Payment Institution vs Electronic Money Institution

Payment Institution vs Electronic Money Institution: What’s the Difference? Choosing between a Payment Institution (PI) and an Electronic Money Institution (EMI) should come after the product has been defined, not before. The licence label does not determine what a company is all

Source-imported researchEditorial verification pending

Research draft awaiting independent review. This material was adapted from an existing research library. Provider-specific promotions have been excluded automatically; facts, regulatory requirements, and conclusions must be verified before the page is indexed publicly.

Payment Institution vs Electronic Money Institution: What’s the Difference?

Choosing between a Payment Institution (PI) and an Electronic Money Institution (EMI) should come after the product has been defined, not before.

The licence label does not determine what a company is allowed to build. The product’s actual functionality, money flow, customer relationship and regulatory role determine which permissions may be relevant.

The central distinction is usually this:

A Payment Institution provides regulated payment services. An Electronic Money Institution can issue electronic money—prepaid monetary value meeting the applicable legal definition—and can also provide payment services within the applicable regulatory framework.

That distinction is more important than whether the product happens to be described commercially as a “wallet,” “payments platform,” “balance,” or “payment account.”

For a business trying to launch quickly, this is not a semantic question. Choosing the wrong regulatory model can affect capital requirements, safeguarding architecture, product functionality, governance, contracts, customer-funds flows and the time needed to obtain regulatory approval.

This article focuses primarily on the EU/EEA and UK, as required by the Licensing and Regulatory Requirements cluster. The broader cluster also covers Payment Licensing Explained, PSP Licensing by Country, Marketplace Payment Licensing, Foreign-Exchange Licensing and related market-entry issues.

PI vs EMI: the short answer

A Payment Institution is generally a non-bank institution authorised to provide specified regulated payment services—for example executing payment transactions, acquiring card transactions or providing money-remittance services—without the PI authorisation itself giving the institution permission to issue electronic money.

An Electronic Money Institution is authorised to issue electronic money, meaning monetary value that meets a specific legal test involving electronically stored value, a claim on the issuer, issuance on receipt of funds, use for payment transactions and acceptance by someone other than the issuer. EMIs may also provide payment services under the applicable framework.

A simplified distinction is:

Question

Payment Institution

Electronic Money Institution

Provide regulated payment services?

Yes, within its permissions

Yes, within the applicable framework

Issue e-money?

Not under PI status alone

Yes

Maintain a prepaid monetary balance that legally qualifies as e-money?

Generally not as issuer

Yes

Money remittance?

Can be a PI activity

Can also be provided by an EMI where permitted

Payment acquiring?

Can be a PI activity

Can also be provided by an EMI where permitted

Wallet product?

Possibly, if no e-money is issued

Often relevant if the wallet contains e-money—but “wallet” alone proves nothing

Safeguarding?

Applies to relevant payment-service funds under applicable rules

Applies to funds received for issued e-money and, where relevant, separate payment-service funds

Regulatory category determined by product name?

The difficult question is therefore not:

“Do we want a PI licence or an EMI licence?”

It is:

“Exactly what monetary claim, account, payment service or stored-value functionality are we creating?”

What is a Payment Institution?

Under the current EU framework, PSD2 defines a payment institution as a legal person authorised to provide and execute payment services. The regulated services covered by PSD2 include activities such as operating payment accounts, executing payment transactions, issuing payment instruments, acquiring payment transactions, money remittance, payment initiation and account-information services.

In the UK, the Payment Services Regulations 2017 remain the principal regime for non-bank payment institutions. The FCA currently describes payment services as including, among other things:

services enabling cash to be placed into or withdrawn from payment accounts;

execution of transactions such as transfers, direct debits and card payments;

issuing payment instruments;

acquiring payment transactions;

money remittance;

account-information services.

An authorised PI might therefore operate a business such as:

Customer

→ payment instruction

→ PI

→ payment rails / another PSP

→ recipient.

The regulated value proposition is fundamentally moving or facilitating money through payment services, rather than issuing a new monetary value that customers subsequently hold and spend.

A payment processor is not automatically a Payment Institution

The word processor can conceal materially different activities.

Consider two companies.

Company A

It provides infrastructure that:

transmits API messages;

processes transaction data;

performs authentication or data storage;

never possesses the funds being transferred.

Depending on the facts and jurisdiction, technical-service exclusions may be relevant. UK FCA guidance, for example, recognizes an exclusion for certain technical service providers that support payment services without themselves providing the regulated payment service.

Company B

It contracts to provide acquiring or money-transfer services and participates in the regulated movement of customer funds.

A PI framework may become much more directly relevant.

So:

Technical involvement in payments and regulated provision of payment services are not necessarily the same thing.

The actual contractual role and funds flow matter.

What is an Electronic Money Institution?

An Electronic Money Institution is an institution authorised to issue electronic money.

That requires understanding what electronic money actually means.

Under the EU Electronic Money Directive, e-money is electronically—including magnetically—stored monetary value represented by a claim on the issuer, issued on receipt of funds for making payment transactions, and accepted by someone other than the issuer.

The UK definition follows substantially the same structure. FCA guidance currently describes e-money as monetary value that is:

stored electronically;

represented by a claim on the issuer;

issued on receipt of funds;

intended to make payment transactions;

accepted as a means of payment by persons other than the issuer;

and not otherwise excluded.

This is why e-money is usually associated with products such as:

certain prepaid cards;

certain stored-value wallets;

prepaid online accounts;

other electronic balances that customers fund in advance and can use to pay third parties.

But none of those product labels is conclusive.

The legal test controls.

What actually qualifies as electronic money?

A useful way to analyze a proposed product is to test each component of the definition.

Is there monetary value?

A database record alone is not sufficient.

There must be something that functions as monetary value rather than merely, for example:

an accounting entry;

non-monetary loyalty status;

an internal record of what the business owes;

a software counter.

Is the value represented by a claim on the issuer?

The holder needs a relevant claim against whoever issued the monetary value.

This makes contractual structure important.

Ask:

If a customer's app says “€100 balance,” who legally owes that €100-equivalent value?

Is the value stored electronically?

Modern account-based products can satisfy this condition; e-money is not limited to value literally stored on a physical card. FCA guidance explicitly notes that account-based prepaid monetary-value schemes can potentially constitute e-money.

Was it issued on receipt of funds?

Prepayment is a defining feature.

The FCA explains this as the customer paying in advance for the spending power represented by the e-money.

This distinction can separate e-money from other types of customer credit or accounting balance.

Can it be used for payment transactions?

Value merely recorded for another administrative purpose does not automatically satisfy the definition.

What can the holder actually do with it?

Is it accepted by someone other than the issuer?

This is another critical test.

A balance spendable only with the business that issued it can create a very different analysis from value usable across unrelated third-party merchants.

Specific limited-network and other exclusions can also matter, and their availability depends on the facts and jurisdiction. UK FCA guidance, for example, explains a limited-network exclusion for certain payment instruments whose use is genuinely constrained.

A “balance” is not automatically e-money

This is one of the most useful distinctions for product teams.

A system contains:

customer_balance = 100

That fact alone tells you almost nothing about its regulatory classification.

You need to know why the balance exists and what the user can do with it.

Ordinary merchant credit

Suppose an ecommerce retailer lets customers prepay an amount usable only for purchases from that same retailer.

That should not automatically be called e-money simply because the value is stored electronically. Third-party acceptance and any applicable exclusions need to be considered.

Refund balance

A merchant records £40 after a returned purchase and lets the customer apply it to a future order.

Again, the word “balance” does not determine the classification.

Questions include:

What contractual claim does the customer have?

Can the balance be redeemed?

Can it be transferred?

Can it be used with third parties?

Was monetary value being issued on receipt of funds, or is this simply the accounting treatment of a refund?

Loyalty points

A loyalty scheme may issue points because someone purchases a product.

That does not automatically make those points e-money. Among other questions, the business would need to examine whether the points represent monetary value issued on receipt of funds and whether the other elements of the e-money definition are satisfied.

Marketplace ledger

A marketplace records:

Seller A: €500 payable

That may simply be an internal record of the platform's economic liability to the seller.

A ledger balance does not become e-money merely because it is stored in a database.

But if the platform begins turning balances into reusable monetary value that holders can transfer or spend with third parties, the regulatory analysis can change materially.

The correct rule is:

Classify the rights and functionality represented by the balance—not the database field containing it.

The editorial brief specifically requires these distinctions because ordinary merchant, refund, loyalty and platform balances should not be casually equated with e-money.

PI vs EMI comparison

Current EU/EEA framework

At the time of writing, the EU's operative framework continues to include PSD2 for payment services and the Electronic Money Directive (EMD2) for e-money. The EU has agreed politically on successor PSD3 and Payment Services Regulation legislation, but the European Parliament's legislative tracker was still describing the package as “close to adoption” in its June 2026 update. The Commission also continues to list PSD2 and EMD2 as the relevant current legislation.

That matters because the proposed framework would integrate the prudential regulation of payment institutions and electronic-money institutions more closely. Businesses planning multi-year licensing projects should monitor the final legislation and transitional/application dates rather than designing solely around today's labels.

Under the current framework:

Issue

EMI

Core regulated function

Payment services

Issuing e-money

Can provide payment services?

Yes, within authorisation

Yes; EMD2 permits EMIs to provide payment services

Can issue e-money?

No, not merely by being a PI

Yes

Initial capital

Depends on services

Higher dedicated EMI minimum

Relevant safeguarding

Payment-service user funds within scope

Funds received for e-money plus applicable payment-service funds

Stored monetary value

Not the defining permission

Central to the EMI model

Governance / prudential supervision

Yes

Customer value redemption

Not a defining PI feature

E-money rules include issuance/redemption requirements

EMD2 expressly permits an EMI to provide payment services in addition to issuing e-money.

How capital requirements differ

Capital is one reason a business should classify the product before selecting the licensing route.

EU Payment Institutions

Under current PSD2, initial capital depends on the payment services provided:

€20,000 for an institution providing only money remittance;

€50,000 for payment initiation services;

€125,000 where the institution provides the payment services covered by points 1–5 of PSD2 Annex I.

Ongoing own-funds requirements can also apply in addition to the initial capital test.

EU Electronic Money Institutions

Current EMD2 requires an authorised EMI to have initial capital of at least €350,000.

For e-money issuance, its own-funds calculation under Method D is at least 2% of average outstanding electronic money, with additional calculations relevant where the institution provides payment services not linked to the issuance of e-money.

That does not mean:

EMI = “better PI with €350,000 capital.”

The different capital regime exists because the institution is undertaking a different regulated activity: issuing a monetary claim that can remain outstanding.

UK PI and EMI capital requirements

The UK retained separate PI and EMI regimes after leaving the EU.

For an authorised UK Payment Institution, Schedule 3 of the Payment Services Regulations 2017 currently specifies initial-capital requirements in euros:

€20,000 for money remittance;

€50,000 for payment initiation;

€125,000 for the other listed payment services covered by the relevant part of the Schedule;

no initial-capital amount in that table for an account-information-only service.

For UK authorised EMIs, current FCA reporting guidance calculates total capital against a €350,000 floor and includes a Method D own-funds requirement of 2% of average outstanding e-money, alongside requirements for unrelated payment services where applicable.

These are regulatory capital requirements, not startup-budget estimates. A licensing project also needs to fund people, controls, legal work, technology, safeguarding arrangements and regulatory operations.

Safeguarding: both models can involve customer-fund protection

A common misconception is:

“PIs move money; EMIs safeguard money.”

Both regimes can create safeguarding requirements.

The difference is which funds and activity create the obligation.

Payment Institution

Under PSD2, payment institutions providing the relevant payment services must safeguard funds received from payment-service users or another PSP for execution of payment transactions. The rules provide specified safeguarding approaches, including segregation or an insurance/guarantee method.

Electronic Money Institution

EMD2 separately requires safeguarding of funds received in exchange for issued electronic money.

If an EMI also provides unrelated payment services, those activities can create payment-service safeguarding requirements as well.

The UK safeguarding regime changed in 2026

UK readers need a particularly current view.

The FCA's Supplementary Regime for payment and e-money safeguarding came into force on 7 May 2026. Current FCA guidance says authorised PIs, authorised EMIs and applicable small EMIs must follow the relevant PSR/EMR safeguarding requirements together with the new FCA CASS and SUP provisions where applicable.

Current CASS 15 guidance also specifically recognizes that an EMI can execute payment transactions unrelated to its e-money issuance and requires the relevant funds for those transactions to be treated separately from funds connected with e-money issuance.

So even inside one regulated EMI, Finance and Compliance may need to distinguish:

e-money funds

from:

unrelated payment-service funds.

That is another reason product classification has to make its way into the ledger and safeguarding architecture.

Safeguarding is not the same as a bank deposit guarantee

E-money should not be presented to customers as though it were a bank deposit.

EMD2 expressly states that funds exchanged for e-money do not constitute deposits or other repayable funds in the same sense as bank deposits.

The FCA similarly explains that UK non-bank EMIs and authorised PIs use safeguarding arrangements and that their customer money does not receive UK Financial Services Compensation Scheme protection in the same way as eligible deposits at banks or building societies.

For product design, that affects:

customer disclosures;

treasury architecture;

safeguarding accounts;

reconciliation;

insolvency planning;

marketing language.

E-money also creates redemption obligations

In the current EU framework, EMD2 requires electronic money to be issued at par value on receipt of funds and, subject to the detailed rules, redeemable by the holder at par value.

That gives a real regulatory consequence to the decision to create e-money.

Compare:

Accounting balance

“Our system records that we owe this seller €100.”

with:

E-money balance

“We have issued €100 of regulated monetary value represented by a claim on us.”

They can look almost identical in an app.

They are not necessarily the same legal product.

Examples: which model might fit?

These examples are deliberately simplified. Actual classification depends on the full product, contracts and jurisdiction.

Example 1: Payment processor / acquirer

A company enables merchants to accept card transactions and itself provides regulated acquiring services.

Potential direction: PI.

Why?

The primary regulated activity is a payment service rather than issuance of stored monetary value.

But a company providing only technical processing without itself providing the payment service may require a different analysis.

Example 2: Remittance business

A customer gives the company €500 with an instruction to transfer it to a relative.

The company executes a remittance rather than creating a reusable stored monetary balance.

Potential direction: PI.

Money remittance is expressly a payment service under current EU and UK regimes.

Now change the product:

Customers can load €500 into an ongoing account, retain the value indefinitely within the product and use the value to pay several third-party recipients later.

The analysis begins moving toward the e-money question.

Example 3: Digital wallet storing card credentials

The app stores a customer's card credentials and uses an appropriately regulated external PSP to execute purchases.

The app itself does not issue monetary value.

Not automatically an EMI.

Calling software a “wallet” does not create e-money.

Example 4: Prepaid multipurpose wallet

The customer sends €500 to the provider.

The provider issues a €500 electronic monetary balance representing a claim against it.

The user can spend that balance with unrelated merchants.

Potential direction: EMI.

That functionality closely resembles the elements of the e-money definition.

Example 5: Marketplace seller ledger

A marketplace records that a seller has earned €500 and pays the amount through a licensed PSP at the next payout date.

Not automatically e-money.

The balance may simply record an economic liability.

Change the architecture so sellers can:

retain the balance;

transfer it to other users;

spend it with third parties;

use it as general-purpose monetary value.

The classification then deserves a new regulatory analysis.

Can an EMI provide payment services?

Yes, subject to its regulatory permissions and the applicable framework.

This is one of the most important PI-vs-EMI distinctions.

EMD2 expressly allows EU EMIs to provide payment services as well as issue e-money.

The FCA takes the same general position in the UK. Its current perimeter guidance says a UK EMI can provide payment services without obtaining a second PI authorisation under the Payment Services Regulations. The FCA also states that if a PI wants to begin issuing e-money, it should move into the EMI regulatory regime rather than simply add e-money under its PI registration.

That produces a useful rule of thumb:

Payment services only

→ examine PI model.

E-money + payment services

→ examine EMI model.

But it is still necessary to identify the actual activities and permissions.

What does this mean for accounts and wallets?

The word account is particularly dangerous in regulatory product design because several economically different products can share the same interface.

A screen saying:

Balance: £1,250

could represent:

a bank deposit;

e-money;

a payment account;

an accounting receivable;

marketplace seller earnings;

merchant store credit;

refundable customer money;

loyalty value.

You cannot classify it from the UI.

For every product balance, document:

Who owes the value?

Why was the value created?

Were funds received in exchange for it?

Can the customer redeem it?

Can it be transferred?

Can it be spent?

With whom can it be spent?

Who holds the underlying customer funds?

What happens on insolvency?

What happens when the account closes?

That analysis should happen before the product team chooses the word wallet.

PI vs EMI governance requirements

Neither authorisation should be understood as a licence fee plus a capital deposit.

A regulated payment firm needs an operating organization.

Current FCA application requirements for authorised PIs include:

robust governance;

internal controls;

risk-management procedures;

appropriate management;

a business plan;

safeguarding arrangements where applicable;

AML compliance;

security and incident processes;

business-continuity arrangements.

Current FCA requirements for authorised EMIs similarly cover governance, management competence, risk controls, safeguarding, AML and operational arrangements relevant to e-money and payment services.

That distinction matters for launch planning.

A company cannot simply write:

“Obtain EMI licence”

as one line in the final month of a product roadmap.

The licence application reflects operating infrastructure that has to be designed and evidenced.

Which licence does a business need?

A useful classification sequence is:

Step 1 — Define the product before naming the licence

Document every functionality.

Can customers:

fund an account?

hold a balance?

transfer it?

pay other users?

pay merchants?

withdraw it?

receive third-party payments?

use the service for remittances?

Step 2 — Draw the actual funds flow

For every stage identify:

Customer

→ contracting entity

→ bank / PSP / safeguarding account

→ recipient.

Ask:

Which entity receives the funds?

Which entity legally controls them?

Are funds held?

On whose behalf?

What claim does the customer receive?

The broader Licensing and Regulatory Requirements brief explicitly makes actual payment flow and participant roles central to regulatory analysis.

Step 3 — Identify the payment services

Do not just ask:

“Are we a fintech?”

Map the product to the jurisdiction's statutory list of payment services.

Step 4 — Test every stored balance against the e-money definition

For each balance ask:

monetary value?

→ stored electronically?

→ claim on issuer?

→ issued on receipt of funds?

→ used for payment transactions?

→ accepted by another person?

→ any exclusion or exemption?

If those questions point toward e-money, an EMI analysis becomes necessary.

Step 5 — Identify who actually performs the regulated activity

Perhaps the business does not need to be the regulated issuer.

A licensed partner may:

issue e-money;

hold/safeguard the relevant funds;

provide the regulated payment account;

execute regulated payments.

The product company may instead provide an application, marketplace or customer experience around that regulated infrastructure.

The contracts and operational reality must support that allocation.

Step 6 — Analyze each launch jurisdiction separately

An EU authorization does not mean:

“We now have a global EMI licence.”

The UK has its own post-Brexit regulatory framework, while countries outside Europe use different categories entirely.

Use PSP Licensing by Country and Cross-Border Payment Regulations for the country-level expansion question rather than carrying EU terminology into every market.

Why choosing the licence too early can delay launch

A common sequencing error is:

product idea

→ choose EMI

→ build product

→ hire lawyer

→ discover actual funds flow requires redesign.

The better sequence is:

product functionality

→ funds flow

→ regulatory activity map

→ licensing options

→ operating model

→ build.

Why?

Because regulatory classification affects architecture.

An EMI model may require the business to design for:

issuance and redemption;

customer-fund safeguarding;

balance reconciliation;

own-funds requirements;

governance;

risk controls;

regulatory reporting.

A PI model may require a different safeguarding population, permission set and operating architecture.

A partner model changes:

contracts;

APIs;

account ownership;

customer disclosures;

onboarding;

KYC responsibilities;

transaction routing.

Changing these after launch architecture is complete can be much slower than determining them during product design.

That is the connection to Compliance Slows Launches: the problem is often not that regulatory analysis occurred, but that it occurred after commercial and technical decisions had already made one regulatory model expensive to change. The cluster explicitly calls for businesses to treat compliance as an operating-model constraint that can affect product design and market-entry speed.

Can a company launch through a licensed partner instead?

Often, potentially—but the exact structure matters.

Direct authorisation is not the only operating model.

Option 1 — Become a directly licensed PI

Useful where the business wants direct control over regulated payment services but does not need to issue e-money.

Potential trade-offs include:

authorization time;

capital;

governance;

safeguarding;

regulatory reporting;

ongoing supervision.

Option 2 — Become a directly licensed EMI

Potentially relevant where issuing stored monetary value is genuinely central to the product.

The EMI can also support payment-service functionality under the applicable framework.

The trade-off is a broader prudential and operational burden associated with being the e-money issuer.

Option 3 — Use a licensed PI, EMI or bank

Another institution performs the regulated activity.

For example:

Customer

→ application/platform

→ licensed EMI issues the customer's monetary value

→ regulated payment infrastructure.

This can materially change the startup's own licensing analysis.

It does not mean the startup has outsourced every compliance obligation.

The company may still have responsibilities involving:

product design;

marketing;

customer support;

data protection;

fraud;

contractual commitments;

operational controls;

partner oversight;

any regulated activities it still performs itself.

Option 4 — Operate as an agent or distributor where appropriate

Some frameworks permit regulated institutions to use agents or e-money distributors subject to specific conditions.

In the UK, for example, an EMI agent can provide payment services for its principal once appropriately registered, and may distribute or redeem e-money, but the agent cannot itself issue the e-money on the EMI's behalf. The FCA separately recognizes distributors that distribute or redeem e-money without becoming its legal issuer.

These structures can support embedded-payment products, but they are regulated operating arrangements—not a label a platform can apply to itself unilaterally.

Option 5 — Change unnecessary product functionality

Sometimes a regulatory burden exists because the proposed product performs a function the business does not actually need.

For example, there may be no commercial requirement for the platform itself to:

maintain reusable customer monetary value;

control customer funds;

issue payment accounts;

transfer money between unrelated third parties.

Moving that activity to an appropriately licensed provider can simplify the operating model.

The objective should be genuine product simplification, not artificial contractual wording designed to disguise the activity that is actually taking place.

EU and UK rules should no longer be treated as interchangeable

Historically, the UK PI and EMI regimes were derived from the same European framework.

That does not mean businesses should assume permanent alignment.

As of August 2026:

the EU's PSD3/PSR reform is close to adoption and would reorganize aspects of payment/e-money regulation;

the UK's current framework continues to use the Payment Services Regulations 2017 and Electronic Money Regulations 2011;

the FCA introduced additional safeguarding rules effective 7 May 2026.

A business launching in both France and the UK should therefore not create one compliance workstream called:

EU/UK EMI.

It should maintain separate regulatory analyses and update them as the regimes develop.

A practical PI-or-EMI product classification map

Before approaching the licensing question, create this one-page product map:

Product question

Answer

Regulatory significance

Does the business provide a regulated payment service?

Yes / No

PI/PSP analysis

Does it receive or control payment-service funds?

Yes / No

Funds-flow/safeguarding analysis

Does it create a customer balance?

Yes / No

Investigate legal nature

Is value issued in exchange for funds?

Yes / No

E-money element

Is the value electronically stored?

Yes / No

E-money element

Does the customer have a monetary claim on issuer?

Yes / No

E-money element

Can the value make payment transactions?

Yes / No

E-money element

Can third parties accept it?

Yes / No

E-money element

Is there an applicable exclusion/exemption?

To verify

Changes perimeter analysis

Who issues the value?

Entity

Determines regulated actor

Who safeguards the underlying funds?

Entity

Operating architecture

Can the customer redeem the balance?

Terms

E-money/product analysis

Which jurisdictions are involved?

Markets

Country-by-country analysis

Could a licensed partner perform the activity?

Yes / No

Alternative launch model

Do this before comparing licence application costs.

A licence is a consequence of the product architecture.

It should not be the architecture.

Key takeaways

The difference between a Payment Institution and an Electronic Money Institution is not simply that an EMI has a larger feature set.

The important regulatory distinction is e-money issuance.

A PI can provide regulated payment services.

An EMI can issue qualifying electronic monetary value and can also provide payment services under the relevant regime.

That leads to several practical rules:

Do not call every digital balance e-money.

Do not assume every wallet requires an EMI licence.

Do not assume a payment processor is necessarily a PI.

Do not choose the licence before defining the product.

Separate actual cash control from technical payment processing.

Map who issues any stored monetary value.

Design safeguarding and reconciliation around the regulated activity.

Assess the EU/EEA and UK separately.

Consider whether a licensed partner can perform the regulated function where direct licensing does not create enough commercial value to justify the operating burden.

The launch question is therefore not simply:

PI or EMI?

It is:

What regulated financial function does our product actually perform, which entity should perform it, and which operating model lets us launch while preserving the functionality and control the business genuinely needs?

Answer that question first.

The licence choice becomes substantially clearer afterward.

This article provides general information and does not constitute legal, regulatory, financial, tax, accounting, or commercial advice. Payment and e-money classifications depend on the specific product, contractual relationships, funds flow, jurisdictions, exclusions, exemptions, and current regulatory rules. Businesses should confirm their position with qualified regulatory counsel, the relevant regulator, and appropriately licensed payment partners before launching or changing a regulated payment product.

🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂

END ARTICLE

SEO / EDITORIAL NOTES — NOT PART OF THE ARTICLE

Recommended SEO title:

Payment Institution vs Electronic Money Institution: PI vs EMI Explained

Meta title:

Payment Institution vs Electronic Money Institution | PI vs EMI

Meta description:

Compare Payment Institutions and Electronic Money Institutions, including e-money, payment services, safeguarding, capital, wallets, stored value and EU vs UK regulatory differences.

Suggested URL slug:

/licensing-regulatory-requirements/payment-institution-vs-electronic-money-institution/

Secondary targets: PI vs EMI, EMI licence, payment institution licence, electronic money institution, payment services licence

Need help narrowing down payment options?

Answer a few questions about your business and compare the capabilities that matter to you.

Explore matching options ↗