Building on a BaaS licence: what Swan, Treezor, Xpollens and Okali take on, and what stays under you

Every fintech that moves money makes one decision early: get authorised yourself, or build on somebody else's licence.

Most build on somebody else's, and for good reasons. What follows is what that arrangement takes on for you, what stays under you, and how to run the part that stays under you without it turning into a headcount problem.

Swan, Treezor, Xpollens and Okali are four French providers offering it.

Is a payment licence required to offer accounts and cards?

Your own authorisation is not out of reach. It is expensive in the three currencies a young company has least of.

Capital. An electronic money institution needs 350,000 euros of initial capital under EU law. A payment institution needs between 20,000 and 125,000 euros, depending on which services it offers.

Time. The ACPR, France's banking regulator, reviews a complete application in three months. Assembling a complete application is the longer part, and teams generally plan for closer to a year.

A permanent function. After authorisation you own the anti-money-laundering programme, transaction monitoring, safeguarding of client funds, regulatory reporting, and the technology-risk rules under DORA, the EU's operational resilience regulation. That is a team, not a project.

Against that, a provider's licence puts you in market in weeks. The calculation is easy at the start.

It changes as you grow. At enough volume the cost of your own licence starts to look small next to what you pay per transaction, and control over your own roadmap starts to matter more. Platforms do eventually make that move. For instance, Swan's 2026 shareholder letter records that Pennylane has decided to progressively internalise its banking stack, with a transition from 2028.

So the question is rarely whether to use a provider. It is which one, and what comes with it.

What responsibilities does a BaaS provider take on?

Three distinct things, worth separating because they carry different obligations.

A licence you operate under. The provider is authorised by a regulator to hold customer money and move it. You use that authorisation instead of applying for your own. In France that regulator is the ACPR, and all four are authorised by it.

Payment rails and card programmes. Accounts with real IBANs, transfers in and out, direct debits, cards. Without a provider, your engineers would integrate with each partner bank one at a time.

The compliance decision. Whether an account opens is the provider's call, and the provider answers to the regulator for it. With several of these four, the provider also does the work behind that decision.

What none of them does is collect the documents from your customer for you.

Swan, Treezor, Xpollens and Okali side by side

Two rows need to be taken together. Licence coverage and live markets answer different questions. A licence passported across the European Economic Area lets a provider operate in about 30 countries. Local IBANs, local direct debit schemes and local card programmes are separate build decisions, market by market. Ask for both coverages.

Your legal status: agent, intermediary, or distributor

You do not become a regulated institution under any of the four. You take on a defined, narrower status, and the label matters because each one carries its own registration requirements.

Agent. You act in the provider's name. The provider registers you with the regulator, and the public register shows the link. Xpollens and Okali both work this way. Okali registers its clients as payment services agents with the ACPR and sells the registration file as part of the service.

Registered intermediary. In France, Swan's partners register with Orias, the national register for finance and insurance intermediaries. In the rest of the European Economic Area they operate as commercial agents of Swan, and Swan handles that registration itself once you go live.

Distributor. Used for distributing electronic money rather than providing payment services. Narrower activity, fewer obligations. You will meet the term while comparing providers.

Confirm which one applies to you in writing, and verify it on the public register. It determines your own registration duties.

Who is responsible for KYC under a BaaS licence?

The provider holds final responsibility. Under EU law the institution holding the licence remains accountable for anti-money-laundering compliance whatever your contract says, because that is how the directives are written: PSD2 for payment services, the E-Money Directive for electronic money.

What differs is how much of the work comes back to you, and the four take visibly different positions.

Swan keeps the compliance work. Because it holds the licence, it assumes responsibility for all sensitive banking operations and does not delegate them. Its partnership documentation lists the nine operations it does delegate, and the verbs matter: consult the account, transmit information to open one, prepare a card order, prepare a transfer order. You prepare and transmit. Swan verifies, decides and executes. Swan also keeps a direct relationship with your end customer, used mainly for account holder verification and strong customer authentication, and it can audit how you behave in your own relationship with those users.

Treezor runs a shared-responsibility framework. Its user verification guide sets out three steps: you collect the declarative data and documents listed on your KYC Form, you pre-review those documents for quality, and Treezor then verifies the identity and decides whether the user is eligible. Data quality is the variable that decides how many rounds this takes.

Xpollens retains the responsibility and asks you to feed it. Its own framing is that you delegate the regulatory obligations to Xpollens, with KYC verification managed by the Xpollens team. You collect and transmit the data required to establish the customer relationship, and Xpollens keeps the regulatory and operational responsibility for the services provided. It offers third-party introduction and KYC reuse, so your customer goes through a single onboarding journey.

Okali also keeps the compliance work, with roughly half its staff in compliance and your agent registration handled as part of the service.

Read those four together and the pattern is clear. None of them asks you to make the compliance decision. All four need clean, complete input from you, and getting it clean is real work.

Where each BaaS provider operates, and which payment services it covers

A point often underestimated: your operational workload grows with the number of countries and payment products you have enabled, not only with transaction volume.

The four differ widely. Swan's licence covers the European Economic Area, with local IBANs live in six markets. Treezor is authorised in 25 European countries and holds all eight payment services defined in EU payment law: deposits into an account, withdrawals, transfers, direct debits, card issuing, card acquiring, money remittance, and the two open-banking services, meaning initiating a payment for a customer and reading their account data. Xpollens operates in France under an EU-passported licence. Okali operates in France and has signalled Italy.

Let's look at an example. You launch in Spain. Your onboarding now asks for Spanish documents your team cannot read, and rejections come back citing local rules nobody on your side knows. Then you enable direct debits, and unpaid debits start arriving, each one needing a decision about when to retry and a message to the customer. Neither change moved your transaction volume much. Both added a new category of work to somebody's day.

What stays under you when the provider runs compliance

Five things, and none of them is a compliance decision.

Collecting the right documents, at the right level of detail. Each provider gives you a list. Treezor calls it your KYC Form and it varies by the services you offer, the country you operate in and the type of user.

Checking their quality before you submit. This matters more than it sounds. A blurred proof of address, one that is out of date, or simply the wrong document type will come back, and the round trip costs your customer days. Treezor names it as a step in its process: pre-review the documents before requesting the review. Somebody on your side has to actually do it.

Working the resubmission loop. A submission comes back incomplete because something is missing or of poor quality, and the case waits until your customer sends a better version. Every provider has this state. Your team owns the chasing.

Doing it again, on a schedule you do not set. Verification is not a one-time check. There are three kinds of review: onboarding, periodic, and triggered by an event. A validated user comes back round when their validation is close to expiring. This is a permanent queue, not a launch project.

Answering your own customer throughout. This part never gets delegated. The provider decides, and your customer asks you why it is taking four days.

Some duties sit only with you. At Treezor's lightest verification level, locking the user's cards is your responsibility.

Verification of Payee is the same shape. Since 9 October 2025, under the EU Instant Payments Regulation, payment service providers in the euro area check the payee's name against the IBAN before a transfer is authorised, and all four provide it. When the check returns a close match, meaning the name your customer typed is nearly but not exactly the name on the receiving account, your customer sees a warning or a blocked payment and contacts you rather than the provider.

Each provider gives you a back office for its own products. Swan provides a Partner Dashboard, a white-label banking application you can put in front of your own customers, and an open-source front end your developers can extend. Treezor provides a dashboard with separate profiles for support, compliance and admin staff, two-factor sign-in using passkeys, and single sign-on. Xpollens and Okali both provide a back office for account and payment operations. These are good tools for looking at the provider's own records. What they do not hold is your side of the case: the document your customer sent you, the thread where you asked for a better one, the result from your KYB provider, meaning the checks you run on a business customer, and the note explaining why this account matters commercially.

Five things to get right in your BaaS onboarding operations

The work above is not difficult. It goes wrong because it is spread out.

A single onboarding touches your provider, your KYB provider, your fraud tool, your support tool and your own product database. Five systems, five web applications, five permission models. Teams that run this well tend to have solved the same five things.

• One case per customer. The document, the KYB result, the support thread and the provider's status in one place, so nobody assembles a submission from four tabs.

• A quality gate before submission. Catch the blurred document on your side, where fixing it costs an hour, rather than on the provider's, where it costs your customer days.

• Explicit case states. Waiting on customer, ready to submit, under review, came back incomplete. If a case has no state, it has no owner.

• Permissions that match the job. A support agent should see a case and answer the customer. Submitting or releasing is a different job.

• A record of who sent what, and when. Your provider will eventually ask. So will your own auditor.

And one more that only shows up later: keep all of it portable. Your vendors change. You add a fraud tool, replace your KYB provider, launch a country your current provider does not cover, or outgrow the model entirely. Treezor's own ownership is in play, with Shares in exclusive negotiations to buy it from Société Générale. If your case states and your history live inside one vendor's web application, they belong to that vendor, and the next change means rebuilding how your team works rather than repointing a connection.

How other models differ: payment operations platforms and core banking

The four above let you operate under their licence. Adjacent categories place the licence and the work differently, which is worth knowing before you compare quotes.

Payment operations platforms, such as Modern Treasury, sit outside the movement of money. Their customers keep their own bank relationships and hold their own licences, which in the United States means state money transmitter licences.

Core banking platforms, such as Mambu, provide the ledger and the product engine to institutions that are already regulated. The licence and the customer relationship stay with the institution.

Each model places the licence, the rails and the responsibility differently. What none of them changes is that your team assembles a case across several systems and answers the customer at the end of it.

Running Swan, Treezor, Xpollens or Okali operations in Forest

Forest is where teams build those five processes: one case per customer, a quality gate before submission, explicit case states, permissions that match the job, and a record of who sent what.

Forest connects to your provider as a datasource and reads the records your team works on every day: accounts, payments, transactions, mandates, cards, returns, and the history behind each one. It reads your KYB provider, your support tool and your own database the same way. So the five systems become one case on one screen, with the document your customer sent sitting next to the status your provider returned.

Your developers write each operation your team needs once, as a Forest action, and your team runs it from the record. Ask the customer for a better document, and the case holds that state until it arrives. Submit for review, and the provider's response lands back on the same case.

Our engineers build the first workspace alongside your team, on top of the provider you already use.

Letting AI agents and automations work under the same permissions

Forest publishes your operations as an MCP server, the standard interface AI tools use to reach an external system. An AI agent connects with a scoped role and can read and act only inside that scope, exactly like a person on your team. Calls run inside your environment, under your permissions, on your audit trail.

The role belongs to the job rather than to a person, so the same setup covers unattended work. An automation checks whether a submitted document was legible and re-requests it if not. A specialised fintech AI agent assembles a submission from four systems and stops at the approval step, where a human takes over.

This matters most when your data sits across several vendors. An AI agent working your cases needs the same permissions your team has, and needs to leave the same evidence, whichever vendor's data it touches.

What to ask a BaaS provider before you sign

1. Which licence will I operate under, and in what capacity? Agent, intermediary and distributor carry different registration duties. Confirm it in writing and check the public register.

2. Who decides on KYC, and what do you need from me? Swan publishes what it delegates and Treezor documents its process. Ask everyone for the equivalent, in writing.

3. What happens when a submission is rejected, and how often will you re-review a customer? This is where your real workload lives. Ask for the rejection reasons, the resubmission process, and the periodic review cycle, not just the field list.

4. Which countries does your licence cover, and which markets are actually live for me? Those are different answers. Ask what adding one involves on my side.

5. If I change provider in two years, what do I rebuild? Ask for your team's tooling to be included in the answer.

Common questions about building on a BaaS licence

Is the BaaS provider regulated, or am I?

The provider is. It holds the licence and answers to the regulator. You take on a narrower status, usually agent or registered intermediary, which carries its own registration but does not make you a regulated institution.

If the provider runs KYC, what does my team still do?

You collect the documents and declarative data from your customer, check their quality before submitting, handle the resubmissions when something comes back, and answer your customer while the case is open. The provider makes the decision; you produce the input.

Who is accountable if a customer turns out to be fraudulent?

The institution holding the licence is accountable to the regulator, whatever your contract says. How commercial liability and losses are shared between you and the provider is a contractual matter, so ask to see that clause before you sign rather than after an incident.

What is Verification of Payee, and whose obligation is it?

It is a check of the payee's name against the IBAN before a credit transfer is authorised, mandatory for payment service providers in the euro area since 9 October 2025 under the EU Instant Payments Regulation. The obligation sits with the provider. When a check returns a close match, your customer contacts you about it rather than the provider.

Can I work with more than one BaaS provider?

Yes, and platforms do it to cover markets or payment methods a single provider does not reach. It doubles the operational surface: two sets of document requirements, two review processes, two sets of case states. Worth doing deliberately rather than by accident.

How hard is it to change BaaS provider?

The technical integration is the smaller half. The harder part is everything your team built around the old provider: the document requests, the case states, the approval steps and the history. If those live inside the provider's own web application, they do not come with you.

Get Forest running on your embedded banking operations

Building on someone else's licence is the right call for most fintechs, and stays right for a long time. Swan, Treezor, Xpollens and Okali each take on the hard part, and several take on the compliance function too.

What stays under you is an operation, and it does not sit inside any one supplier. It spans your provider, your KYB provider, your fraud tool, your support tool and your own database. No vendor owns that shape, which is why it needs a layer of its own, on your side of the line. That is what Forest is, and it comes in four parts.

Connected data. Forest connects to your provider, your KYB provider, your support tool and your own database as datasources, and reads them live. Nothing is copied into a new system, and one customer becomes one case.

Actions. Your developers write each operation your team needs once. Request a document, submit for review, retry a debit, release a payment. Your team runs them from the record, without a ticket to engineering.

Workflows. The paths that repeat get built once and then run: a rejected document triggers a fresh request, a periodic review opens a case before the deadline, an escalation stops and waits for a human.

Governance. Record-level permissions so a support agent can see a case without releasing a payment. Four-eyes approval on the actions that warrant it. A full audit trail of who did what, when, and with what inputs, exportable the day your provider or your auditor asks. The same rules apply to your team and to any AI agent you connect.

All of it runs on your own infrastructure, reading through your credentials, so your customer data stays in your systems. And none of it is tied to the provider underneath, so changing provider means pointing a datasource somewhere new rather than rebuilding how your team works.

If your team is collecting documents, chasing rejections and answering customers across a provider dashboard and a spreadsheet, book a demo and we will map your provider's flows to a Forest workspace with one of our engineers.

Forest is the operational layer for regulated fintechs. Connect your core banking, payment and compliance providers as datasources, build the actions and workflows your team runs every day, and keep permissions and a full audit trail on every call. Runs on your own infrastructure.