Why Choosing an EMI over BaaS Sponsorship Can Avoid Euro IBAN Account Freezes

Fintechs, payment platforms, digital asset businesses and product teams that want to embed euro IBAN accounts face an architectural choice: embrace convenient Banking-as-a-Service (BaaS) middleware or commit to direct Electronic Money Institution (EMI) integration. When payment volumes are low, this can look like a trivial decision but, as a product scales and volumes increase, it can turn into an operational nightmare.

The main issue is account freezes. These can occur if your payment rails depend on virtual pooling routed through sponsor bank infrastructure that regulators choose to sanction. In 2026, European regulators are accelerating enforcement against BaaS middleware stacks.

At the same time, direct EMI licensing through institutions that issue dedicated, named business IBANs has become more straightforward and cost-competitive. For the first time, the secure, long-term choice is also the economically rational one.

This guide evaluates the technical, regulatory and economic dimensions of this EMI vs. BaaS debate, so CTOs, Heads of Product, Chief Compliance Officers and Payment Architects can make the right choice for their businesses.

Account Freezes Occur When Virtual Sub-Ledger Routing Fails

A BaaS aggregator typically operates an omnibus account at a sponsor bank and this single bank account could hold balances for hundreds or thousands of end-user platforms.

The aggregator maintains an internal sub-ledger that maps each end-user to their share of the omnibus pool. When your user initiates a payment, the transaction moves from your platform's virtual sub-ledger to the sponsor bank's master account and on to the receiving bank's correspondent network.

Therefore, when your user's payment enters the correspondent network, the bank receiving the payment sees the sponsor bank as the payment originator, not your platform or your user. Automated Anti-Money Laundering (AML) and sanctions-screening engines examine the sender and, if the sponsor bank has been flagged for compliance issues, the entire payment gets caught. This will include your user's transaction, even if it is legitimate.

Furthermore, compliance engines are increasingly sensitive to issues caused by pooled accounts. If a single sub-ledger detail is missing from the payment message or there's a slight mismatch between the virtual account name and the beneficiary registration, these compliance engines can trigger automated holds on all transactions from that omnibus pool.

You must also consider the danger that you could be caught up in a derisking process you do not control. If a sponsor bank determines that a BaaS aggregator or the platforms it serves pose a compliance risk, it will withdraw support. Often, this involves the sponsor bank rejecting new incoming wires, then freezing existing balances and finally cutting the API connection entirely. Your platform loses access to settlement infrastructure straightaway and your users' funds are locked in the sponsor bank's account until the issue is resolved.

Regulatory Situation: BaFin, ACPR, EMD2, PSD3 and DORA

To understand why the EMI vs BaaS decision is so relevant today, it's important to look at the regulatory and safeguarding environment it exists within.

Regulatory Enforcement & Legal Safeguarding

European regulators have stepped up oversight and enforcement actions against BaaS middleware stacks.

Germany's BaFin and France's ACPR have increasingly subjected BaaS sponsor institutions to special audits, growth restrictions and compliance mandates due to systemic deficiencies in anti-money laundering (AML) controls across embedded banking infrastructure. These actions signal regulatory intolerance for BaaS arrangements where they believe customer due diligence is improperly delegated or where transaction origins are obscured.

ACPR insists that payment institutions maintain direct, verifiable knowledge of the Ultimate Beneficial Owner (UBO) and underlying transaction originators, rather than delegated knowledge through aggregators. Payment institutions cannot delegate customer due diligence (CDD) to middleware aggregators without maintaining independent oversight and direct access to end-user transaction records.

The legal mechanism protecting consumers in these de-risking scenarios is client fund safeguarding. Under PSD2 and MiCA Title III (as well as the incoming PSD3/PSR framework), EMIs must safeguard customer funds by placing them in segregated accounts with tier-1 credit institutions or holding them in secure, low-risk liquid assets. Client funds cannot be used for the EMI's operational expenses or debts. The incoming PSD3/PSR framework goes further, requiring client funds to enter a dedicated safeguarding account immediately upon receipt and expanding direct central bank safeguarding options.

While BaaS aggregators are legally bound to safeguard client funds, their pooled omnibus architecture introduces operational friction. If an aggregator or sponsor bank enters resolution, customer funds sit locked in omnibus pools, leaving end-users subject to lengthy liquidation and reconciliation delays. Direct EMI safeguarding isolates accounts at the institutional level, avoiding these sub-ledger freezes.

Additionally, Enhanced Due Diligence (EDD) triggers differently under direct vs. pooled models. A pooled sub-ledger with an ambiguous origination detail triggers an EDD hold on the entire omnibus account, freezing all sub-ledger balances. A named business IBAN triggers EDD at the individual account level, so the compliance checks are isolated and the hold affects only the specific account under investigation.

Operational Resilience & DORA Compliance

The EU Digital Operational Resilience Act (DORA, Regulation EU 2022/2554, applicable since January 2025) requires financial entities and payment institutions to evaluate and report vendor risks.

Payment providers must maintain an up-to-date Register of Information detailing all third-party arrangements, including sub-outsourcing and fourth-party dependencies. Firms cannot rely solely on vendor self-assessments or questionnaires and must document pre-contract due diligence and explicit concentration risk assessments. They also need specific contract provisions covering audit rights, SLAs, data security and exit strategies if a vendor fails.

DORA also targets vendor concentration. So, if critical payment infrastructure depends on a single sponsor bank, a single BaaS aggregator and a single middleware provider, it risks multiple single points of failure that violate DORA's resilience standards. A multi-layer BaaS stack that includes your platform, an aggregator, a sponsor bank and its correspondent network introduces multiple critical dependencies where, if one fails, there is no backup.

Direct EMI integration streamlines DORA compliance by eliminating these dependencies. Your regulatory reporting and business continuity planning are simplified because you maintain a direct account at a licensed EMI with access to SEPA Instant settlement infrastructure. If a vendor fails, settlement infrastructure remains available.

Dedicated Named Business IBANs vs. Pooled vIBANs

A named business IBAN is issued directly to your end-user's legal corporate entity as a dedicated account.

When the user initiates a payment from that IBAN, the originating bank sees the business entity as the payment originator, rather than an aggregator. Correspondent banks receive clear ISO 20022 messages that identify the account holder directly in the payment fields.

A pooled virtual IBAN (vIBAN) routes to an omnibus master account where individual balances exist only on an internal sub-ledger. When a payment is sent from a pooled vIBAN, the receiving bank receives messages identifying the sponsor bank as the originating entity, not the end-user.

A regulated EMI can issue named business IBANs to hundreds of end-user entities, with each IBAN functioning as an individually segregated account. This is possible because every individual business account requires automated legal-entity verification and sanctions screening prior to activation.

The EMI registers a new IBAN in that entity's name, creates a segregated deposit account and returns the IBAN to your platform for distribution to your user. Settlement happens through direct SEPA rails, so there is no intermediate aggregator, no sponsor bank and no virtual sub-ledger lookup. Your users own their IBANs, your platform operates the provisioning layer and the EMI operates the settlement layer.

The Hidden Cost of Multi-Tier Vendor Markups

BaaS middleware incurs costs at every layer. As an example, sponsor banks can charge aggregators 10-35 basis points for direct clearing access. Then, the aggregator adds its markup, which can be 50-150 basis points on top of bank costs, plus a per-vIBAN creation fee. Finally, most BaaS stacks impose fixed FX markups of 1.5-3.0% on currency conversions. Therefore, a scaling platform that processes €2M in monthly payment volumes could pay 200-400 basis points annually before any platform margin is considered.

Direct EMI integration operates under a different cost model. Providers like Newrails charge flat maintenance fees plus per-transaction costs that decrease with volume. For the same €2M monthly volume, direct integration could be 30-50% cheaper.

Furthermore, the EMI's regulatory scope amplifies this advantage. Because a licensed EMI can passport its services across the entire EEA, your platform can serve users in multiple jurisdictions through a single EMI partnership, eliminating the need for separate regional BaaS arrangements. Multi-jurisdiction BaaS stacks may require separate contracts in each geography, multiplying vendor markups and creating regulatory fragmentation.

Direct IBAN Access to Euro Stablecoin Settlement

Web3 platforms, crypto exchanges and non-EU businesses can find it difficult to access European payment infrastructure through traditional banking channels. Banks often decline crypto-native businesses as a blanket rule and non-EU entities face additional compliance burdens. Aggregators serve these segments but can charge more because of the perceived regulatory risk they take on.

Fortunately, a direct relationship with an EMI can bypass these issues. Newrails serves crypto-native platforms and non-EU entities can obtain dedicated named business IBANs, enabling them to integrate into the same settlement infrastructure as domestic users.

With Newrails, the in-account on-chain integration enables seamless stablecoin settlement too. A user holding EUR in a named business IBAN can move it directly into EURW, Newrails' MiCA-compliant Electronic Money Token, without friction.

Evaluating Your Euro Payment Infrastructure Decision

Whether you choose an EMI or BaaS provider depends on your stage of development, your payment profile and whether you want to future-proof your product as it scales.

Early-stage startups that operate in one location with low monthly payment volumes can usually accept BaaS trade-offs. However, when you start to scale at any pace, a direct EMI integration makes sense. That's because BaaS costs quickly start to stack up and the risk of user accounts being frozen because they are pooled alongside each other becomes much more of an issue. Sponsor bank concentration creates a single point of failure, and DORA compliance becomes much harder.

The onboarding experience with a licensed EMI is generally straightforward too. Once the relationship is established, you can begin issuing named business IBANs to end-users so any pooling risk is avoided entirely.

When choosing a provider, you should aim to answer these questions:

Affirmative answers to these questions will help you avoid sponsor-bank de-risking and keep your product in the best position to scale without issues.

Frequently Asked Questions

---

You can find out more about how Newrails enables fintechs, neobanks, payment service providers, crypto exchanges, digital asset businesses and others to offer users a euro business account with named IBANs, direct SEPA access and an integrated EUR stablecoin.