How to choose an EMI or BaaS provider

Choosing an electronic money institution (EMI) or a banking-as-a-service (BaaS) provider is a decision about who carries regulated responsibility for your product, how your customers’ money is protected, and what you can realistically ship. The right answer depends on your product, your customers and the markets you operate in — not on which provider has the most polished API. This guide gives you a structured way to evaluate candidates so that legal, safeguarding, operational and commercial questions are compared on the same footing.

Legal and regulatory status was reviewed on 7 July 2026.

What EMI and BaaS mean in a provider-selection process

An EMI is an entity authorised to issue electronic money and, typically, to provide related payment services. Electronic money is monetary value stored electronically and issued on receipt of funds, redeemable at par 2. A payment institution and a bank are different regulated categories, with different permissions 1.

Banking-as-a-service is a commercial and technical model in which a regulated entity makes banking or e-money capabilities available to another company, usually through APIs. BaaS is not a licence in itself. When a vendor markets “BaaS”, you still need to identify which regulated entity stands behind each activity and what obligations remain with you.

Technology provider versus regulated service provider

The organisation that gives you an API may not be the organisation that holds the authorisation. Some providers own the regulated entity and the platform; others are technology vendors that sit in front of a separate licensed institution; and some expect you to hold, or work toward, your own authorisation. Ask directly: which regulated permissions do you rely on, which legal entity holds them, and which obligations fall to us? 3

Start with a product-and-permissions map

Before comparing vendors, write down what your product actually does: hold balances, issue accounts or IBANs, send and receive payments, issue cards, convert currency, or initiate payments from other banks. Map each activity to the permission it requires. This map is the specification you evaluate providers against, and it prevents “feature-led” selection where a demo hides a permission gap.

Identify every legal entity in the service chain

A single product may involve several legal entities: the customer-facing brand (you), the regulated EMI or bank, a processor, a card issuer, and downstream banking partners. Group branding can hide this. Insist on a written list of every entity, its role, its regulated status and its country of authorisation.

Verify permissions in official registers

Do not take a marketing page as proof of regulatory status. Confirm the entity and its permissions in the relevant official register, and check that the permissions cover the specific services and countries you need 4. A licence in one Member State does not automatically mean the provider can serve your customers everywhere you plan to operate.

Safeguarding versus deposit protection

EMIs and payment institutions must protect customer funds through safeguarding, for example by segregating them from the firm’s own money 1. Safeguarding is not a deposit-guarantee scheme and should never be described as such to customers. Understand which accounts hold safeguarded funds, at which banks, how reconciliation works and how frequently, and what happens to customer funds if the provider fails. See our dedicated guide on how safeguarding works.

Named accounts, pooled accounts and virtual IBANs

Ask whether accounts are presented in the end customer’s name, or whether funds sit in a pooled (omnibus) account with entitlements tracked in a ledger. Virtual IBANs may route to an underlying account rather than being separate bank accounts. Each model has different customer-experience, reconciliation and safeguarding implications, covered in named accounts, virtual IBANs and pooled accounts.

Domestic and cross-border payment-rail access

Match scheme and currency coverage to your roadmap. Which schemes are reachable today (for example SEPA credit transfer and instant, local rails)? Which currencies can you hold and convert? What are cut-off times and value dates? Coverage claims should be tested against your real corridors and volumes, not a country list.

Direct versus indirect scheme access

A provider may participate in a payment scheme directly, or reach it indirectly through another institution. Indirect access can add dependencies, cut-off constraints and counterparty risk. Ask how each rail is accessed and what happens if the upstream relationship changes.

Customer and sector eligibility

Confirm which customer types and sectors the provider will onboard. Some decline particular industries, jurisdictions or risk profiles. A provider that cannot serve your target customers is not a candidate, regardless of price.

Division of KYC, KYB, AML and monitoring responsibilities

Clarify who performs and who is accountable for onboarding, identity and business verification, screening and transaction monitoring. Using a provider’s tools does not transfer the regulated entity’s legal responsibility. Document the split in a responsibility matrix and align it with your compliance framework — see KYC, KYB and transaction-monitoring architecture.

API, webhooks, sandbox and operational tooling

Evaluate the developer experience honestly: API completeness, webhook reliability, sandbox fidelity, idempotency behaviour, rate limits and documentation quality. Thin documentation or a low-fidelity sandbox will cost you long after launch.

Reconciliation, statements, reports and exception handling

Payments operations live and die on reconciliation. Ask how statements and reports are produced, how returns, recalls and investigations are handled, and how exceptions surface to your team. Slow or opaque reconciliation is a persistent operational tax.

Service levels, incident communication and support

Understand support hours, escalation paths, incident-communication commitments and who you can reach during a live problem. A named contact and a clear escalation route matter more than a generic uptime figure.

Pricing and minimum commitments

Compare pricing on a like-for-like basis: setup, monthly minimums, per-transaction and per-account fees, FX, and charges for returns or investigations. Minimum commitments and ramp expectations can dominate early-stage economics.

Reserve, prefunding and liquidity requirements

Ask whether the provider requires reserves, prefunding or rolling balances, and how these affect your working capital. Liquidity terms can materially change the true cost of a relationship.

Contract, suspension and termination rights

Read the suspension and termination clauses closely. Understand notice periods, the provider’s rights to suspend accounts, and your obligations on exit. These clauses determine your resilience if commercial terms or risk appetite change.

Data portability and exit planning

Negotiate exit before you launch: what data you can export, in what format, over what period, and how customer balances and mandates migrate. Providers rarely volunteer favourable exit terms after go-live.

Decision matrix

Dimension	What to confirm	Evidence to request
Regulated entity	Which legal entity is authorised for each activity	Entity name, country, register entry
Permissions	Coverage of your exact services and markets	Scope of authorisation
Eligible customers	Sectors and jurisdictions accepted	Onboarding policy
Account model	Named, pooled or virtual IBAN	Account structure diagram
Safeguarding	Where and how funds are protected	Safeguarding arrangement summary
Payment rails	Schemes, currencies, direct vs indirect	Rail and cut-off list
Compliance allocation	Who does what for KYC/KYB/AML	Responsibility matrix
Integration	API, webhooks, sandbox, idempotency	Docs and sandbox access
Reconciliation	Statements, returns, investigations	Sample reports
Support	Hours, escalation, incident comms	SLA and escalation path
Pricing	All-in fees and minimums	Full price list
Exit	Data export and migration	Exit and offboarding terms

Due-diligence checklist

• Product-and-permissions map completed and agreed internally
• Every legal entity in the chain listed with role and regulated status
• Permissions verified in the official register for each market
• Safeguarding model, banks and reconciliation cadence documented
• Account model (named / pooled / virtual IBAN) confirmed
• Payment-rail coverage tested against real corridors
• Compliance responsibility matrix signed off
• Integration validated in a realistic sandbox
• Reconciliation and exception handling reviewed with operations
• Pricing modelled at expected and stressed volumes
• Suspension, termination and exit terms reviewed by legal

Questions to ask providers

• Which regulated legal entity is authorised for each service, and in which country?
• Where can we verify those permissions in an official register?
• How exactly are client funds safeguarded, and at which banks?
• Are customer accounts named, pooled, or served by virtual IBANs?
• Which schemes and currencies are supported, and are they accessed directly or indirectly?
• Which compliance tasks are ours, and which are yours, in writing?
• What are realistic timelines for programme approval and go-live?
• What data can we export on exit, and how are balances migrated?

Common red flags

• The provider cannot name the regulated entity behind a service, or conflates the brand with the licence.
• “BaaS” is presented as if it were a licence.
• Safeguarding is described as deposit protection, or the arrangement cannot be explained clearly.
• Coverage is asserted as a country list with no detail on rails, cut-offs or eligibility.
• Compliance responsibilities are left vague or implied to transfer to the provider.
• Exit and data-portability terms are unavailable before contracting.

What this does not cover

This guide does not assess any specific provider, set prices, or determine whether a structure is compliant for your business. It complements — but does not replace — legal, regulatory and tax advice tailored to your entities, products and markets.

FAQ

Is BaaS a type of licence?

No. Banking-as-a-service is a commercial and technical model. The regulated permissions sit with a specific bank, EMI or payment institution, which you must identify.

Is an EMI the same as a bank?

No. An EMI issues electronic money and provides related payment services; a bank is a separate regulated category. Their permissions and protections differ 1.

Does safeguarding protect my customers like a bank deposit?

No. Safeguarding protects customer funds through mechanisms such as segregation, but it is not a deposit-guarantee scheme and should not be described as one to customers.

Can one authorisation cover every European market?

Not automatically. Confirm that the entity’s permissions extend to the services and countries you need, using the official register 4.

When should we discuss exit terms?

Before launch. Data portability, balance migration and offboarding are far harder to negotiate once you are live and dependent on the provider.