Bank vs EMI vs payment institution vs CASP

Credit institutions, electronic money institutions (EMIs), payment institutions (PIs) and crypto-asset service providers (CASPs) are separate regulated categories, each authorised for different activities. Around them sit agents, distributors, programme managers and technical service providers, which are not regulated in the same way. Choosing the right provider means matching your product’s activities to the permission each activity requires, then identifying the specific legal entity that holds that permission. This guide describes the categories so you can have a precise conversation with advisers and providers.

Legal and regulatory status was reviewed on 7 July 2026.

Credit institution

A credit institution — a bank — is authorised to take deposits from the public and to grant credit. Banks can also provide payment services and issue electronic money. Deposits held with a bank sit within the deposit-taking framework, which is different from the safeguarding model used by EMIs and PIs. If your product requires deposit-taking or lending on your own book, a bank is the relevant category.

EMI

An EMI is authorised to issue electronic money: value stored electronically, issued on receipt of funds and redeemable at par 2. EMIs typically also provide payment services related to that stored value. If customers need to hold and spend a balance over time, the EMI category is usually in scope. The precise boundary between EMI and PI activities is explored in EMI versus payment institution.

PI

A PI is authorised for one or more payment services — such as executing transfers, acquiring transactions, money remittance, or account-information and payment-initiation services — without issuing electronic money 1. The exact list of permitted services is fixed by the authorisation, so two PIs can have very different capabilities.

CASP

A CASP is authorised under the EU markets-in-crypto-assets framework to provide crypto-asset services, such as custody, exchange or transfer of crypto-assets 3. CASP authorisation covers crypto-asset services; it does not by itself confer permission to provide payment services or to issue electronic money. Where an activity touches both crypto-assets and payments, the interaction between frameworks must be assessed carefully — the interactive rulebook is a useful reference point 5. For authorisation scope and travel-rule obligations, see MiCA CASP authorisation and the crypto travel rule.

Account information service provider

An account information service provider (AISP) is authorised to access account data, with the user’s consent, to provide information services 1. An AISP reads data; it does not move funds. This is a narrower payment-service permission and is often combined with other services.

Payment initiation service provider

A payment initiation service provider (PISP) is authorised to initiate a payment from a user’s account held at another provider, with consent 1. A PISP triggers a transfer but does not itself hold the funds. AIS and PIS are explained further in open banking: AIS, PIS and VRP.

Agent

An agent provides payment services on behalf of an authorised firm and is registered in connection with that firm. The regulated permissions remain with the principal; the agent operates within the principal’s authorisation and oversight. Being an agent is not the same as holding your own authorisation.

Distributor

A distributor markets or distributes electronic money or a payment product on behalf of an authorised firm. As with agents, the regulated activity and responsibility remain with the licensed entity. Distribution arrangements are common in embedded models.

Programme manager

A “programme manager” is a commercial role rather than a distinct regulated category. It typically describes a company that designs and runs a card or payment programme on top of a regulated issuer’s or acquirer’s permissions. The regulated responsibility still sits with the licensed entity, so confirm which entity that is.

Technical service provider

A technical service provider supplies software, processing or infrastructure without holding payment or e-money permissions and without holding customer funds. It sits outside the regulated perimeter for those activities. This is a legitimate and common role, but it means the entity you integrate with may not be the entity that is authorised.

Regulated partner model

Many products launch by contracting with a licensed bank, EMI, PI or CASP rather than obtaining an authorisation directly. In that model the licensed entity carries regulated responsibility and you operate as an agent, distributor or programme partner. This is efficient, but obligations remain with you and must be documented — see choosing an EMI or BaaS provider and the launch a European fintech stack.

Which permissions attach to which activities

Permissions attach to activities, not to brands. The practical method is to list what your product does, then match each activity to the permission it requires. Holding spendable balances points toward electronic money; moving funds or acquiring points toward payment services; deposit-taking and lending point toward a bank; crypto-asset services point toward a CASP 1 2 3.

Why group branding is not a substitute for identifying the contracting legal entity

A single brand can sit above several legal entities in different countries with different permissions. The entity you contract with, and the entity that is authorised for each activity, are what matter — not the group name on the website. Insist on a written list of every entity in the chain, its role, its regulated status and its country of authorisation. This prevents a demo or brand from masking a permission gap.

Decision table by use case

Use case	Typical activity	Category most often involved
Hold and spend a stored balance	Issuing electronic money	EMI (or bank)
Execute transfers or acquire card payments	Payment service	PI or EMI
Read account data with consent	Account information service	AISP
Initiate a payment from another account	Payment initiation service	PISP
Take deposits and lend	Deposit-taking, credit	Bank
Custody or exchange crypto-assets	Crypto-asset service	CASP
Supply software only, no funds held	Technical service	Technical service provider

This is orientation only; confirm the specific entity’s permissions before relying on them.

Regulatory-register verification checklist

• Every legal entity in the chain listed with its role and country
• The authorised entity confirmed in the relevant official register
• The specific permissions checked against your exact activities
• Crypto-asset services and payment services verified separately where both apply
• Passporting or cross-border coverage confirmed for each market
• Agent, distributor or programme roles distinguished from the principal’s authorisation
• Technical service providers identified as outside the regulated perimeter

Current PSD2/EMD2 framework

As of 7 July 2026, PSD2 is part of the operative EU payment-services framework and EMD2 is part of the operative EU electronic-money framework 1 2. Payment-service and electronic-money permissions are defined and verified under these instruments today.

Forthcoming PSD3/PSR status

A political agreement on PSD3 and the Payment Services Regulation (PSR) was reached in November 2025, and technical and institutional work continued into 2026. As of the European Commission’s 19 May 2026 status update, the texts were not yet formally adopted; final adoption and publication were expected in Q4 2026, with most PSR provisions expected to apply 21 months after entry into force 4. PSD3 and PSR are forthcoming and must not be described as current law.

Questions to ask providers

• Which legal entity contracts with us, and which entity is authorised for each activity?
• Which regulated category applies — bank, EMI, PI or CASP — for each service?
• Where can we verify these permissions in an official register?
• If crypto-asset services are involved, is there separate payment-services authorisation where needed?
• Are we operating as an agent, distributor or programme partner, and what does that make us responsible for?
• Which components are supplied by a technical service provider outside the regulated perimeter?

Common red flags

• The provider cannot name the specific authorised entity behind a service.
• Group branding is used as if it proved a particular entity’s permissions.
• A CASP authorisation is presented as if it also granted payment-services permissions 3.
• Agent or distributor status is described as equivalent to holding an authorisation.
• PSD3 or PSR is described as if it were already applicable law 4.
• Permissions are asserted for markets without confirming passporting or local coverage.

What this does not cover

This guide explains the categories and how permissions attach to activities; it does not classify your product, confirm which entity you need, or state that any arrangement is compliant. It is general information, not legal, regulatory or tax advice, and it does not rank or endorse any provider.

FAQ

Is an EMI a bank?

No. A bank takes deposits and lends; an EMI issues electronic money and typically provides related payment services. They are separate regulated categories with different funds-protection models 2.

Does a CASP authorisation let a firm provide payment services?

Not automatically. A CASP is authorised for crypto-asset services under the markets-in-crypto-assets framework; payment services and electronic-money issuance require their own permissions 3.

What is the difference between an agent and a licensed firm?

An agent provides payment services on behalf of an authorised principal and operates within the principal’s authorisation. It does not hold its own payment-services authorisation 1.

How do I know which category my product needs?

List what your product does and match each activity to the permission it requires, then confirm the entity’s permissions in an official register and with advisers. This guide does not classify your product for you.

Are PSD3 and the PSR in force?

Not as of 7 July 2026. They were agreed in principle in November 2025 but not yet formally adopted as of 19 May 2026, with adoption expected in Q4 2026 and most PSR provisions expected to apply 21 months after entry into force 4.