---
title: "Nested EMI Structures: Why One EMI Can't Sub-License Banking Rails to Another"
slug: nested-emi-structures-banking-rails
publishedAt: 2026-08-06T10:00:00.000Z
author: Finconduit Editorial Team
tags: PSD2, EMD2, AMLR, FATF Recommendations
canonicalUrl: https://finconduit.com/resources/nested-emi-structures-banking-rails
---
# Nested EMI Structures: Why One EMI Can't Sub-License Banking Rails to Another

Why the EU's own AML architecture tolerates one EMI providing banking rails to another — but breaks down the moment that EMI re-licenses the same rails to a third.

Banking\-as\-a\-service has quietly become the default way many **EMIs** reach the market. License one EMI, plug into its rails, launch in weeks instead of years. What gets built on top of that first layer is where the structure either holds — or starts to look exactly like the highest\-risk pattern in **correspondent banking**.

The market keeps testing the same question. **EMI\-A** holds a direct licence and a direct safeguarding relationship with a **credit institution**. EMI\-A gives its banking rails to **EMI\-B** — a second, separately licensed EMI. Does the structure still hold if EMI\-B does the same thing again, onboarding **EMI\-C** onto rails neither EMI\-B nor EMI\-C ever directly controlled?

A **Lithuanian** EMI providing IBANs and payment infrastructure to a second Lithuanian EMI happens routinely — a recognised, **EBA\-tolerated** shape of banking\-as\-a\-service. The next layer, where that second EMI re\-issues the same access to a third, is where the EU's **AML architecture** stops recognising the structure at all.

## What a Nested EMI Structure Actually Is

An **electronic money institution \(EMI\)** issues e\-money and holds client funds under a **safeguarding** obligation, typically via a direct account with a **credit institution**. **Banking\-as\-a\-service \(BaaS\)** is the practice of one licensed institution making its rails — IBANs, card programmes, payment scheme access — available to a second business under its own authorisation.

A **virtual IBAN \(vIBAN\)** is an identifier that redirects payments into a single underlying **master account** held by a licensed institution, while letting each downstream party be attributed its own IBAN\-shaped reference. This is the technical layer that makes EMI\-to\-EMI rails\-sharing possible in the first place.

'**Nested**' is a term borrowed deliberately from correspondent banking, where the [**Financial Action Task Force**](https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Correspondent-banking-services.html)** \(FATF\)**¹[^1] uses it to describe a bank using its correspondent relationship to serve institutions it has no direct relationship with. Applied here: **Bank → EMI\-A → EMI\-B** is one layer of nesting. **Bank → EMI\-A → EMI\-B → EMI\-C → end client** is two.

[**EMD2**](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32009L0110) — the **Electronic Money Directive**²[^2] — legislates exactly three categories for third\-party involvement in an EMI's business: **agents**, **distributors**, and **outsourcing**. None of the three describes a second, independently licensed EMI running its own client base on rails it received from the first.

The pattern exists because it's commercially efficient, not because anyone set out to build three layers of risk. **EMI\-B** avoids the cost and timeline of its own bank relationship. **EMI\-C**, arriving later, does the same thing again — reaching for the fastest available rails rather than negotiating with a **credit institution** directly. Each individual hop looks rational. The chain as a whole does not.

## The One\-Hop Structure the EBA Already Tolerates

The [**European Banking Authority \(EBA\)**](https://www.eba.europa.eu/sites/default/files/2024-05/612f03de-965a-4157-b638-1b4c5b081f87/EBA%20Report%20on%20virtual%20IBANs.pdf)³[^3] addressed this directly in its **May 2024 Report on Virtual IBANs \(EBA/Rep/2024/08\)**. Its entire risk framework is built around a **two\-party model**: one institution servicing the master account, and one institution issuing vIBANs to end users on top of it.

> The PSP servicing the master account is different from the PSP offering the vIBANs to the end users and: the PSP servicing the master account obtains due diligence on the end users of vIBANs; and the PSP servicing the master account and the PSP offering the vIBANs are based in the same EU Member State.

That is **Bank → EMI\-A → end client**, or **Bank → EMI\-A → EMI\-B** where EMI\-B is itself the party facing the end customer. The EBA treats it as **lower\-risk** on two conditions: due diligence on the end user flows back to the institution holding the master account, and both institutions sit in the **same EU Member State**.

[**AMLR Article 18\(2a\)**](https://eur-lex.europa.eu/eli/reg/2024/1624/oj/eng)⁴[^4] — **Regulation \(EU\) 2024/1624** — turns that tolerance into law. The institution servicing the master account must be able to obtain end\-user identification 'even where vIBANs are issued by another credit or financial institution,' within **5 working days** of requesting it. The obligation is drafted for **one intermediary** — it says 'another,' singular.


*Table: One\-hop vs. two\-hop EMI banking rails structures*

| Structure | Who faces the end client | Who owes end\-user due diligence | EBA / AMLR treatment |
| --- | --- | --- | --- |
| Bank → EMI\-A | EMI\-A | EMI\-A, direct | Standard licensed relationship |
| Bank → EMI\-A → EMI\-B | EMI\-B | EMI\-A obtains it from EMI\-B on request \(5 working days\) | Tolerated — same Member State, due diligence flows back |
| Bank → EMI\-A → EMI\-B → EMI\-C | EMI\-C | No institution in the chain is obligated to reach EMI\-C's clients | Not contemplated by AMLR Art. 18\(2a\) or the EBA's vIBAN framework |

Nothing in the **EBA's** analysis extends the same tolerance to a cross\-border version of even the one\-hop structure. Where **EMI\-A** and **EMI\-B** sit in different Member States, the report treats that as a **higher\-risk indicator**, not a neutral fact — which means a two\-hop chain, spanning at minimum two and often three national supervisors, starts from a worse position before the identification problem is even considered.

## Where the Chain Breaks — the Second Layer

Once **EMI\-B** sub\-distributes its rails to **EMI\-C**, EMI\-B has become exactly what [**AMLR Articles 36 and 37**](https://eur-lex.europa.eu/eli/reg/2024/1624/oj/eng)⁵[^5] are written to police: a respondent institution that itself provides downstream access to a further institution. Those articles require **senior management approval** before establishing a correspondent relationship, and an ongoing assessment of the respondent's own downstream relationships.

The mechanical problem is identification. **Article 18\(2a\)'s** 5\-working\-day window works when there is one intermediary between the master account and the end user. It has no built\-in mechanism for a **serial hand\-off** across three separately licensed institutions, each running its own AML programme and deciding independently what it will and won't disclose upstream.

Practically, this means **EMI\-A** — and by extension the **credit institution** underneath it — now carries a due diligence obligation toward **EMI\-C's** clients that almost no **BaaS contract** is actually built to satisfy. Most banking\-as\-a\-service agreements are drafted for a direct client relationship, not a chain of assignment three parties deep.

There's a liability dimension too. If **EMI\-C** turns out to be the weak link — thin **KYC**, a **sanctions** screening gap, a client base **EMI\-A** never assessed — the exposure doesn't stay contained at EMI\-C. **AMLR Article 36's** correspondent\-relationship logic pulls the obligation to have understood that risk back up the chain, to the institution that tolerated the second hop in the first place.

## The AML Lens — What Correspondent Banking Already Learned

This isn't a new problem, just a new industry hitting it. [**FATF**](https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Correspondent-banking-services.html)⁶[^6] describes nested correspondent banking — one bank using its correspondent relationship to serve institutions it has no direct relationship with — as **'one of the highest\-risk configurations in the global banking system.'**

US [**BSA/AML**](https://bsaaml.ffiec.gov/manual/AssessingComplianceWithBSARegulatoryRequirements/10)⁷[^7] rules independently draw the same line. A US bank must take '**reasonable steps**' to ensure a foreign respondent bank isn't using its correspondent account to serve **other foreign banks downstream** — and if it can't certify that within **30 calendar days**, the correspondent account closes. This is a US rule, not EU law, but the convergence is the point: two entirely separate legal systems independently stop at one layer of separation.

The underlying logic is visibility, not paperwork. Every hop between the licensed institution holding the underlying account and the party actually transacting removes one degree of direct knowledge — who the client is, what they do, whether their **source of funds** holds up. AML frameworks converge on **one hop** as the point past which that knowledge gap becomes structurally unmanageable, regardless of jurisdiction — which is why the same line reappears in EU vIBAN rules, EU correspondent\-relationship rules, and US correspondent banking rules without any of the three drafters having coordinated with each other.

## What It Looks Like When the Chain Breaks in Practice

**Synapse's** collapse in **April 2024** is the clearest public illustration, even though it's a US **middleware** structure rather than an EU EMI chain. Synapse connected **licensed banks** — principally [**Evolve Bank & Trust**](https://www.federalreserve.gov/supervisionreg/enforcementactions.htm)⁸[^8] — to fintech clients, functioning as the intermediary layer between a regulated balance sheet and roughly **18 million end users**.

> Fintech companies operating as middleware providers like Synapse are not directly regulated by agencies like the FDIC or the Federal Reserve... crucial aspects of Synapse's operations, such as financial record\-keeping and customer fund management, were not adequately monitored.

The result was an **$85 million shortfall** in customer funds and no single party able to produce a reliable ledger of who owned what. That failure happened at just **one layer** of intermediation. Add a second — a fully separate licensed institution with its own balance sheet, own AML programme, and own clients neither upstream party can see — and the reconciliation problem compounds rather than doubles.

## The Contractual Reality — What BaaS Agreements Actually Say

Market practice has already priced this in, even where regulation hasn't spelled it out by name. Sophisticated **banking\-as\-a\-service** providers routinely write an explicit **no\-sub\-distribution clause** into their agreements — a contractual prohibition on the client re\-selling or re\-licensing the rails onward to a further institution.

That clause exists because the provider — **EMI\-A** in this structure — understands exactly what **AMLR Articles 36–37** would ask of it if **EMI\-B** became a downstream correspondent provider itself: a due diligence obligation it has no practical way to discharge against a client base it has never seen. The private\-law backstop and the public\-law risk point in the same direction.

In practice, this surfaces during a periodic account review. EMI\-A's own bank asks a routine question about the ultimate nature of the flows moving through the **safeguarding account**, EMI\-A traces the activity back to a client base it never onboarded, and the relationship — sometimes the entire banking arrangement, not just the sub\-distributed portion — gets **re\-underwritten from scratch**. The cost of unwinding a nested structure discovered late is almost always higher than the cost of building it correctly from the start.

## Why EMD2's Third\-Party Framework Doesn't Reach This

**Agents** act on behalf of the principal EMI and are covered by its liability — but an agent is not itself a separately licensed EMI running an independent client base. **Distributors** can only distribute and redeem e\-money, notification\-only, same logic. **Outsourcing** moves an operational function to a vendor while liability stays with the licensing EMI.

None of the three describes what **EMI\-B** becomes once it onboards **EMI\-C**. Legal commentary on this gap is blunt: the directive '**does not address**' whether one licensed EMI can provide infrastructure to another separately licensed EMI, and the **EBA** directs [**competent authorities**](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32015L2366)⁹[^9] to a **case\-by\-case assessment** instead. There is no registered category to notify into — which means there is **no safe harbour**, only supervisory discretion.

'**Case\-by\-case**' is doing a lot of work in that sentence. It means there is no notification form to file, no waiting period after which silence counts as approval, and no version of this structure an **NCA** is obliged to treat consistently across firms. Two EMIs running an identical three\-layer chain in the same Member State can receive two different supervisory reads.


*Table: EMD2/PSD2 third\-party categories vs. a nested EMI structure*

| Category | What it covers | Registration | Covers EMI\-B onboarding EMI\-C? |
| --- | --- | --- | --- |
| Agent | Acts on behalf of the principal EMI; principal fully liable | Registered with NCA, public register | No — an agent is not a separately licensed institution |
| Distributor | Distributes / redeems e\-money only | Notification to NCA | No — cannot onboard independent clients |
| Outsourcing | Operational function; liability stays with the licensing EMI | Internal governance; notification for critical functions | No — outsourcing a function isn't onboarding a second institution's clients |
| Nested EMI | Second EMI independently onboards clients on borrowed rails | None — not a legislated category | This is the structure with no registered pathway |

## What Regulators Are Already Signalling

[**Bank of Lithuania**](https://www.lb.lt/en)¹⁰[^10] maintains a standing framework specifically addressing **PI and EMI** activity conducted through **third parties** — agents, distributors, outsourcing, and **white\-labelling** — and has separately written to firms about business models built around **third parties acting on an EMI's behalf, or other entities**. The precise supervisory wording continues to develop; the direction of travel does not.

[**Central Bank of Ireland's**](https://www.centralbank.ie/)¹¹[^11] January 2023 Dear CEO letter raised the same theme from the outsourcing and operational\-resilience angle, pressing firms to demonstrate genuine oversight of any arrangement where a third party stands between the licensed institution and its end client.

In the **UK**, the [**FCA's CASS 15**](https://www.fca.org.uk/)¹²[^12] safeguarding regime — fully in force from **7 May 2026** — now requires a signed **acknowledgement letter** from any third\-party institution before it can receive safeguarded funds, precisely because supervisors found firms couldn't evidence who actually controlled money sitting two or three parties downstream.

None of these signals amount to a single rule with an article number reading 'nested EMI structures are prohibited.' Taken together — a Lithuanian regulator writing directly to firms about third\-party business models, an Irish regulator pressing outsourcing oversight, a UK regulator closing the safeguarding gap a nested chain would exploit — they describe a supervisory community converging on the same conclusion from three different angles, in three different jurisdictions, without a shared rulebook forcing them to.

## What a Legitimate Multi\-Bank Architecture Looks Like Instead

The safe version of this ambition isn't a chain — it's **direct relationships**. A multi\-bank architecture built from **Tier\-1 EU clearing**, **Tier\-2 specialist**, and **Tier\-3 crypto\-aware** correspondents, each held directly and each carrying its own **due diligence** trail back to the licensed institution, achieves the same **redundancy** without a single unaccountable layer in the middle.

Where a genuine agency relationship exists, **register it as an agent** — the liability sits where the licence sits, and the **NCA** can see the whole structure. Where the downstream party is a **technology client** using the rails rather than a separately licensed institution running its own book, that's the shape **BaaS** is actually built for.

finconduit's [Multi\-Bank Architecture Designer](/tools/multi-bank-designer) scores exactly this trade\-off — redundancy against **single points of failure** — and the [Correspondent\-Banking Compatibility Checker](/tools/correspondent-banking) maps realistic acceptance bands per tier before a single RFI goes out.

Before accepting or building a second layer of rails, three questions settle most cases:

- Does the downstream party hold its own **licence**, or is it a technology client using the rails as infrastructure? Only the latter is unambiguously safe.

- Can **due diligence** on the end user reach back to the institution holding the **master account** within the **AMLR's 5\-working\-day** window — not in theory, but in the actual contract?

- Would the arrangement survive being described to the **NCA** in plain language, in a single sentence, without needing three follow\-up questions to work out who is actually liable for what?

## Frequently Asked Questions

### Can an EMI provide banking rails to another EMI?

Yes — this is a routine form of **banking\-as\-a\-service**, and the **EBA's** own **virtual IBAN** framework treats a two\-party structure as tolerable, provided due diligence on the end user flows back to the institution holding the **master account** and both parties sit in the **same EU Member State**. The problems start one layer further down.

### What is a nested EMI structure?

It's a chain where a licensed **EMI** that already receives banking rails from another institution re\-distributes those same rails to a third, separately licensed EMI, which itself onboards the end client. The term borrows directly from '**nested correspondent banking**' in AML law, where it describes exactly this pattern of layered intermediation.

### Is it illegal for an EMI to sub\-license its banking rails to a second EMI who then onboards a third EMI?

No single EU statute names the arrangement and bans it by title. But **AMLR Article 18\(2a\)'s** identification duties, **Articles 36–37's** correspondent due diligence, and **EMD2's** silence on any registered category that covers it combine to make the three\-layer structure functionally unsupportable and heavily disfavoured on supervisory review.

### How many layers of banking\-as\-a\-service sub\-distribution do regulators accept?

One, and only under conditions. The **EBA's** lower\-risk indicator requires due diligence flowing back to the master\-account institution and both parties in the same Member State. A second layer isn't addressed by the framework at all, which supervisors read as a reason for caution rather than permission.

### What's the difference between a registered EMI agent and a nested EMI arrangement?

An **agent** acts on behalf of, and is fully covered by the liability of, the principal EMI — it is registered, visible to the **NCA**, and not itself a separately licensed institution running an independent client base. A **nested EMI** is a fully separate licensed entity with its own liability, its own AML programme, and its own clients the upstream EMI has no visibility into.

### Does it matter if EMI\-A and EMI\-B are licensed in different EU Member States?

Yes. The **EBA's** lower\-risk indicator for the one\-hop structure specifically requires both institutions to sit in the **same EU Member State**. Where **EMI\-A** and **EMI\-B** are licensed by different NCAs, even a single\-hop arrangement moves into **higher\-risk territory** — and a second hop on top of that starts from an already weaker position.

> **Call to action:** Building a multi\-bank or banking\-as\-a\-service architecture and not sure which layer of the stack creates regulatory exposure? Book a free regulatory assessment — we map the structure against AMLR, EMD2, and your NCA's current supervisory posture before you build it.

## Related Guides

- [EMI vs PSP vs VASP vs CASP: Which Financial Licence Do You Need?](/resources/emi-psp-vasp-licence-comparison): clarifies the licence categories referenced throughout this piece

- [How to Get a Bank Account for a VASP or CASP \(2026\)](/resources/bank-account-vasp-casp): the direct\-relationship alternative to a nested BaaS chain

- [AML Compliance for Crypto Firms: What the 6AMLD Requires \(2026\)](/resources/aml-compliance-crypto-6amld): the due\-diligence obligations underpinning correspondent\-relationship risk

- [Banking Access for Regulated Fintechs](/services/banking): how finconduit builds direct, redundant multi\-bank architecture

The EU's supervisory appetite for nested payment structures is only tightening — **CASS 15** in the UK, **AMLR's** vIBAN identification duties, and NCA\-level guidance from **Bank of Lithuania** and **Central Bank of Ireland** are all converging on the same one\-hop line. An EMI weighing whether to build, or accept, a second layer of sub\-distribution should assume the answer is no, and design the direct multi\-bank stack it actually needs instead.

## Footnotes

[^1]: FATF, Guidance on Correspondent Banking Services, October 2016. <https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Correspondent-banking-services.html>
[^2]: Directive 2009/110/EC on the taking up, pursuit and prudential supervision of the business of electronic money institutions \(EMD2\), OJ L 267, 10.10.2009. <https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32009L0110>
[^3]: European Banking Authority, Report on Virtual IBANs, EBA/Rep/2024/08, May 2024. <https://www.eba.europa.eu/sites/default/files/2024-05/612f03de-965a-4157-b638-1b4c5b081f87/EBA%20Report%20on%20virtual%20IBANs.pdf>
[^4]: Regulation \(EU\) 2024/1624 on the prevention of the use of the financial system for the purposes of money laundering or terrorist financing \(AMLR\), Article 18\(2a\), OJ L, 19.6.2024. <https://eur-lex.europa.eu/eli/reg/2024/1624/oj/eng>
[^5]: Regulation \(EU\) 2024/1624 \(AMLR\), Articles 36–37 — general provisions and enhanced due diligence for cross\-border correspondent relationships. <https://eur-lex.europa.eu/eli/reg/2024/1624/oj/eng>
[^6]: FATF, Guidance on Correspondent Banking Services, October 2016 — nested correspondent relationships identified as a high\-risk configuration. <https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Correspondent-banking-services.html>
[^7]: FFIEC BSA/AML Examination Manual, Due Diligence Programs for Correspondent Accounts for Foreign Financial Institutions — nested correspondent account provisions. <https://bsaaml.ffiec.gov/manual/AssessingComplianceWithBSARegulatoryRequirements/10>
[^8]: Federal Reserve and Arkansas State Bank Department enforcement record concerning Evolve Bank & Trust's banking\-as\-a\-service partnerships; Synapse Financial Technologies Chapter 11 bankruptcy proceedings, 2024. <https://www.federalreserve.gov/supervisionreg/enforcementactions.htm>
[^9]: Directive \(EU\) 2015/2366 on payment services in the internal market \(PSD2\), Article 19 — use of agents, read alongside EMD2's distributor and outsourcing provisions. <https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32015L2366>
[^10]: Bank of Lithuania — regulatory guidance and supervisory correspondence on PI/EMI activity conducted via third parties, agents, distributors, outsourcing and white\-labelling. <https://www.lb.lt/en>
[^11]: Central Bank of Ireland — Dear CEO letter to payment and e\-money firms on outsourcing and operational\-resilience expectations, January 2023. <https://www.centralbank.ie/>
[^12]: FCA, CASS 15 — Safeguarding of client money and custody assets for payment and e\-money firms, in force from 7 May 2026. <https://www.fca.org.uk/>


---
Source: https://finconduit.com/resources/nested-emi-structures-banking-rails
