Table of Contents

Founders often compare BaaS and EMI as if they were two versions of the same thing. In a neobank build, they are not.

An EMI is a regulated status. In the UK, the FCA’s own overview explains that firms need FCA authorisation or registration if they want to provide payment services or issue electronic money, and the Electronic Money Regulations 2011 set the legal framework for electronic money institutions. (FCA)

BaaS, by contrast, is a delivery model. It usually means launching on top of an existing regulated institution’s connectivity and permissions, while the neobank team builds and operates the product layer above it. “BaaS” is not a separate FCA licence category. It is the commercial and technical route founders use to get to market without becoming a bank or an EMI themselves on day one. That is why the comparison becomes confusing so quickly: one term describes a regulatory footing, while the other describes a go-to-market structure.

That distinction matters because it changes the real decision. Most founders are not choosing “BaaS or EMI” in the abstract. They are choosing how much of the regulated stack to own now, how much to borrow, how quickly they need to launch, and how much operational burden they are prepared to carry in the first 12 to 24 months.


The first difference: what problem each one solves

A useful way to think about it is this.

EMI answers the question:

What regulated status do we need if we want to issue electronic money and provide certain payment services ourselves?

BaaS answers the question:

How do we launch a real neobank-style product on top of an existing regulated perimeter and existing rails?

Those are different questions, and they lead to different operating models.

If you are trying to decide how to launch a neobank, EMI is part of the answer when you are thinking about authorisation, safeguarding, reporting, and direct responsibility for regulated payment or e-money activity. The FCA’s EMI/PI application materials make that very clear. Firms applying to become EMIs need to meet authorisation conditions and provide detailed information as part of the FCA process. (FCA)

If you are trying to decide how to launch quickly without carrying the full regulatory build yourself, BaaS is usually part of the answer. In that case, the regulated institution underneath may be a bank, an EMI, or a payment institution, but your decision is still about using an existing licensed perimeter instead of building one first.


What an EMI actually gives you

In practical neobank terms, an EMI route gives you a clearer regulatory basis for certain types of stored-value and payment products.

The FCA’s overview for payment institutions and electronic money institutions is the core starting point here: EMIs sit inside the UK regime for issuing electronic money and providing certain payment services. The FCA’s Approach Document is also explicit that it is designed to explain how the FCA interprets the Payment Services Regulations and the Electronic Money Regulations in practice. (FCA)

That means an EMI route can give a founder team:

  • the ability to issue electronic money,
  • a clearer direct relationship to the FCA authorisation regime,
  • more control over how the regulated activity is structured,
  • and, over time, less dependence on a sponsor for the basic regulated status.

What it does not give you is a working neobank product by itself.

An EMI still needs:

  • customer onboarding journeys,
  • account or wallet experience,
  • transaction visibility,
  • support workflows,
  • complaints handling,
  • internal controls,
  • third-party oversight,
  • and a product layer that can survive real customer behaviour.

That is where many founders overestimate what “having an EMI” solves. It changes the regulatory footing. It does not remove the operational work of running a financial product.


The hidden cost of an EMI path

The trade-off with EMI is direct responsibility.

Under the Electronic Money Regulations, EMIs must safeguard relevant funds, and Regulation 20 specifically sets out safeguarding obligations for funds received in exchange for electronic money issued. The FCA also states that payment and e-money firms are subject to conduct-of-business rules, and that EMIs providing payment services are within PSR conduct requirements as well. (legislation.gov.uk)

That matters because direct EMI ownership brings direct obligations around:

  • safeguarding,
  • reporting,
  • notifications,
  • controls,
  • and governance.

The FCA’s reporting page for payment institutions and e-money issuers confirms that firms in these regimes must provide certain data and information regularly, and the FCA has continued to tighten expectations around safeguarding. In August 2025, the FCA published PS25/12 and related announcements confirming changes to the safeguarding regime for payments and e-money firms, with implementation from May 2026. (FCA)

So EMI can mean more control, but it also means more direct accountability earlier.


What BaaS actually gives you

A BaaS-led launch is attractive for one reason above all: it compresses the journey to market.

Instead of building the full regulated perimeter yourself, you launch on top of an existing institution’s permissions and connectivity. That makes BaaS especially useful when:

  • the niche still needs proving,
  • the team wants to validate product-market fit before carrying a full authorisation programme,
  • or the main bottleneck is product and operations, not licensing theory.

The strongest way to understand BaaS is not as “outsourced compliance.” It is as sponsor-led market entry.

That sponsor-led structure is usually what allows founders to focus their effort where it matters most in the first stage:

  • onboarding,
  • product UX,
  • admin workflows,
  • transaction states,
  • support handling,
  • and evidence trails.

This is where BaaS is often the better Day-One choice. It lets the team build a real product without having to become a bank or an EMI first.


But BaaS does not remove accountability

This is where many launch plans become unrealistic.

Using a sponsor model does not mean the founder team can ignore regulated expectations. The product still has to behave in a way the sponsor can defend. The FCA’s Approach Document is clear that payment services and e-money businesses sit inside a conduct and control framework, and the conduct requirements page makes clear that PSR conduct rules apply to payment service providers, including EMIs when they provide payment services. (FCA)

In practice, a BaaS-led product still needs:

  • clear transaction-state handling,
  • supportable failures,
  • evidence for customer outcomes,
  • complaint workflows,
  • internal permissions,
  • monitoring and escalation,
  • and enough operational maturity to pass partner due diligence.

That is why BaaS is not a shortcut around operational reality. It is a shortcut around building the regulated perimeter yourself before you know the product will win.


The comparison founders usually need

In real neobank builds, the choice is often closer to this:

BaaS-led sponsor route

Best when speed matters, the niche still needs validating, and the product layer is the main thing that must be built well now.

EMI-led route

More attractive when e-money issuance is core to the proposition, long-term regulatory control matters more, and the company can absorb heavier safeguarding and reporting obligations earlier.

Own bank route later

Relevant for a much smaller number of companies, usually when scale, capital, governance, and long-term economics justify deposit-taking and full bank authorisation. The Bank of England’s New Bank Start-up Unit materials show how different this path is in practice: becoming a bank means going through a dedicated PRA/FCA authorisation process built for deposit-taking institutions. (Bank of England)

That is why “BaaS vs EMI” is often really a question about timing and ownership, not only about regulation.


Where founders get the comparison wrong

There are three mistakes that appear again and again.

1) Treating EMI as a complete alternative to BaaS

It is easy to talk about EMI as if it replaces the whole BaaS model. In reality, many EMI-led launches still use multiple external providers for rails, cards, KYC, fraud, messaging, and product infrastructure. So moving toward EMI does not eliminate partnership complexity. It changes where the legal and operational accountability sits.

2) Treating BaaS as only infrastructure

Founders sometimes talk about BaaS as if it is only APIs and rails. In practice, BaaS is also about how a launch is structured commercially and operationally. The question is not only “can the provider move money?” It is also “can our product operate safely and clearly on top of that provider?”

3) Ignoring the product layer

This is the biggest one.

Whether the foundation is sponsor-led or EMI-led, the product still needs:

  • onboarding logic,
  • permissions and approvals,
  • admin tooling,
  • support case handling,
  • complaint visibility,
  • and clear event trails.

That is why the hardest part of a neobank launch is often not “BaaS vs EMI.” It is whether the product layer above either option is mature enough to survive real users.


The product layer is where the launch succeeds or fails

This is the part founders consistently underestimate.

The visible front-end is not enough. A launch-ready product also needs:

  • coherent transaction lifecycle behaviour,
  • internal visibility for support and operations,
  • role-based access and change logging,
  • complaint handling,
  • and enough evidence to answer partner scrutiny.

That requirement exists in both paths.

If you launch through BaaS, the sponsor still wants to see a product it can stand behind.

If you launch through your own EMI, the FCA still expects you to operate inside the conduct, safeguarding, and reporting regime that comes with that status. (FCA)

This is why the strongest founder question is not:

“Do we want BaaS or EMI?”

It is:

“Which regulated route gets us live fastest without creating operational weakness that will slow us down later?”

A practical founder framework

If speed-to-market is the main pressure, and the team still needs to validate the niche, a BaaS-led model is usually stronger.

If the product economics, compliance readiness, and governance maturity already justify more direct ownership of the regulated e-money layer, EMI becomes more attractive.

If the long-term ambition is to become a bank, that is usually a later-stage decision once scale, margins, and organisational maturity support it.

A simple way to test the decision is to ask:

  • Do we need regulatory control now, or do we mainly need launch speed?
  • Is our real bottleneck licensing, or product execution?
  • Can we support safeguarding and reporting discipline directly?
  • Are we prepared for the governance burden that comes with own authorisation?
  • Would sponsor dependence be a strategic risk now, or later?

These questions tend to produce a clearer answer than debating the labels themselves.


Where Finamp fits

Finamp fits the part of the problem founders most often under-resource: the product layer above the regulated structure.

For teams taking a sponsor-led route, Finamp supports a faster path to launch by providing a maintained product layer with:

  • operationally clear transaction behaviour,
  • supportable workflows,
  • evidence-friendly structure,
  • admin visibility,
  • and enough modularity to evolve the partner stack later.

That means the decision does not have to be “move fast with BaaS” versus “be serious with EMI.” A BaaS-led route can still be operationally mature if the product layer is built properly.

And if the company later moves toward deeper ownership of the regulated stack, the product foundation is already in place.

Book a Call


The real conclusion

The cleanest way to say it is this:

EMI is a regulatory status. BaaS is a delivery model. The two can overlap in a real neobank stack, but they are not direct equivalents. (FCA)

For most neobank founders, the stronger Day-One path is usually:

  • use BaaS to get inside a live regulated perimeter quickly,
  • understand when an EMI route becomes strategically valuable,
  • and invest early in the product and operational layer that both paths still require.

That is the difference that matters in practice. Not which acronym sounds stronger, but which route helps you launch a real product without building the wrong burden too early.