How to choose a BaaS provider in Europe

Choosing a banking-as-a-service provider in Europe is not a software purchase. You are choosing a regulatory posture, an operational dependency, and — in most cases — the party whose licence your product actually runs on. The provider you pick determines which markets you can serve, how long your onboarding takes, what happens when a regulator asks a question, and how quickly you can change your mind later.

This guide sets out the decisions in the order they actually bind you.

Start with the licence model, not the feature list

Every European BaaS arrangement resolves to one of three shapes, and the shape is the single most consequential choice you will make.

Operating under the provider's licence. You distribute a regulated product that legally belongs to your provider — typically as their agent or distributor. This is the fastest route to market and the cheapest to start. It is also the most constrained: your provider's risk appetite becomes your product roadmap, their regulator's view of your customer base becomes your addressable market, and a change in their strategy can invalidate yours.

Your own licence, with infrastructure bought in. You hold an EMI, PI or equivalent authorisation and buy the technology — ledger, payments connectivity, card processing — from vendors. You control your product and your customer relationship. You also carry the capital requirement, the compliance function, the regulatory reporting and the hiring that comes with them. The lead time is measured in quarters, not weeks.

A hybrid. Launch under someone else's licence, apply for your own in parallel, migrate when authorised. Common and sensible — but only if the initial architecture is built to be migrated. Ask, before you sign, what a migration off this provider looks like in practice.

There is no universally correct answer. There is an answer that is correct for your volumes, your margin, your funding position and your appetite for building a compliance function. Decide this before you take a single demo, because it eliminates most of the market.

Map your markets precisely, then test them

"Europe" is not a market. Passporting means a provider authorised in one EEA state can serve others, but the practical picture is messier than the legal one: local payment schemes, local IBAN expectations, local KYC norms, local language support requirements, and local regulator attitudes to your specific use case.

Three questions separate the providers who can serve your markets from the ones who would like to:

• Which entity and which licence covers each country you named, and is it passported or locally authorised?
• Will my customers receive a local IBAN in each market, or a foreign one? IBAN discrimination is unlawful in the EEA and still routinely encountered in practice, and it will cost you conversions.
• Which local schemes are supported directly rather than through a further intermediary — and who is the intermediary?

The UK is a separate answer to all three. If you need both the UK and the EEA, you are usually buying two arrangements, whether or not the provider presents it that way.

Understand where client money actually sits

Safeguarding is the part buyers skip and auditors don't. You should be able to answer, unambiguously:

• Which regulated entity holds the funds, and under what safeguarding method?
• At which bank or banks are safeguarded funds held, and is there concentration risk in that answer?
• What happens to your customers' balances if your provider fails? What is the actual mechanism and the actual timeline?
• Is the client-money relationship with your provider, with their partner bank, or with you?

A provider who cannot explain this crisply in a first conversation is telling you something. So is one whose answer is a single unnamed partner bank.

Separate the ledger from the licence

Many BaaS propositions bundle three things that are technically separable: the licence, the ledger, and the payment connectivity. Bundling is convenient at launch and expensive at scale, because the day you want to change one of them you find you cannot change any of them.

Ask what your data would look like on exit. Can you export a full transaction and balance history in a usable format? Do you own the customer relationship and the KYC records, or do they? If you moved provider, would you be re-onboarding your entire customer base? That last question has ended more BaaS relationships than pricing ever has.

Test the integration, not the documentation

Every provider has good documentation now. Documentation quality stopped being a differentiator some years ago. What still differentiates:

• Sandbox fidelity. Does the sandbox reproduce real failure modes — rejected payments, held funds, KYC referrals — or only happy paths?
• Webhook discipline. Are events delivered at-least-once with idempotency keys and replay? Ask how they behave during an incident, not during a demo.
• Reconciliation. How do you reconcile their ledger against yours daily? If the answer involves a spreadsheet, that spreadsheet is now part of your operations forever.
• Change control. How much notice do you get for breaking changes, and what is the deprecation window?

Ask for read access to a sandbox before you sign anything. A week of a real engineer's time will tell you more than any RFP answer.

Interrogate the onboarding path — theirs and yours

Two onboarding processes matter, and buyers usually only plan for one.

Yours onto them. How long from signature to first live transaction, realistically, for a company like yours? What are the gating steps — compliance review, security assessment, scheme approval? Who is on the critical path and what has historically delayed it? Ask for the distribution, not the best case.

Your customers onto the platform. What KYC and KYB flows are available, which vendors sit behind them, what are the pass rates for your customer profile, and what happens to a referral? A provider with excellent APIs and a 60% straight-through onboarding rate for your segment is a bad provider for you.

Price the whole relationship

Per-transaction pricing is the easiest thing to compare and rarely the largest number. Build a three-year model that includes platform or minimum fees, per-account and per-card costs, FX spread, chargeback and dispute handling, interchange treatment and share, implementation and professional services, and the cost of your own team's operational load. Then re-run it at three times your projected volume and at a third of it. The provider who wins the spreadsheet at your base case often loses it badly at either edge.

Ask directly: what is your minimum commitment, what happens if I miss it, and what is the notice period to exit?

Judge the support model honestly

When something goes wrong at 09:00 on a payday, what happens? Named contact or ticket queue? What are the contractual response times for a payments incident versus a general query? Is support in your timezone and your language? Will you have a technical account manager, and is that person shared across how many clients?

Small providers give you attention and less resilience. Large providers give you process and less attention. Neither is wrong — but decide which failure mode you can live with, because you will meet it.

Ask everyone the same questions

The most common procurement mistake in this market is holding five differently-shaped conversations and then trying to compare them. Sales teams are good at steering a conversation onto their strengths. The only defence is a fixed set of questions, asked of everyone, answered in writing.

At minimum, standardise across: licence and entity structure per market, safeguarding arrangements, account and IBAN capability, payment scheme access, card capability if relevant, KYC/KYB flows and vendors, ledger and reconciliation, API and webhook behaviour, SLAs and support, data ownership and exit, pricing across your volume range, and reference customers with a comparable profile.

Then score the answers against your own must-haves and nice-to-haves, decided before you read any of them.

Where Finlane fits

This is exactly the work Finlane structures. You describe your requirements once in a guided template — or talk them through with an AI builder that asks about markets, volumes and architecture — and vetted providers in the matching category respond in a fixed shape, requirement by requirement. You stay anonymous until you accept a provider, so you are not committing to a sales relationship in order to get an answer. It is free for buyers.

If you would rather run the process yourself, the framework above is the framework, and our RFP question bank gives you the questions in a form you can paste into your own document.

Before you sign

A short list to run one last time: you know which licence model you are buying and why; you can name the entity and licence covering each market; you can explain where client money sits and what happens if the provider fails; you have tested the sandbox with a real engineer; you have a realistic onboarding timeline with named gating steps; you have modelled three years of cost at three volume levels; you know what exit looks like and who owns the customer records; and you asked every shortlisted provider the same questions.

If any of those is still fuzzy, it is not a contract question. It is a diligence question, and it is cheaper to answer now.