---
title: "The EMI Compliance Programme Architecture: Eight Pillars Every Authorised EMI Must Operate"
slug: emi-compliance-programme-architecture
publishedAt: 2026-05-25T17:30:00Z
author: Finconduit Editorial Team
tags: EMD2, PSD2, AMLR, DORA
canonicalUrl: https://finconduit.com/resources/emi-compliance-programme-architecture
---
# The EMI Compliance Programme Architecture: Eight Pillars Every Authorised EMI Must Operate

Authorised EMIs that survive supervisory inspection run compliance as an architecture, not a department. The eight pillars, each with owner, cadence, and evidence file.

Most EMIs treat compliance as a department. A head of compliance, an MLRO, a manual, a folder of policies, and a quarterly board paper. That structure passes the day\-one authorisation review. It does not survive a supervisory inspection two years later.

Authorised EMIs that survive inspection treat compliance as an **architecture** — a set of eight load\-bearing pillars, each with a **named owner**, a **refresh cadence**, a **supervisor\-facing evidence file**, a **KRI that triggers escalation**, and a clear path to the board when the KRI breaches. A manual sits in a folder. A programme runs continuously.

This is what the architecture looks like for an **authorised EMI** under **EMD2**, **PSD2**, **AMLR**, and **DORA** — pillar by pillar, with the operating detail every CCO, MLRO, and board needs to see.

## Why a Programme Beats a Manual

A compliance manual is a static document. It tells a supervisor what you *intend* to do. A compliance programme is a live system. It tells a supervisor what you **actually did, when, on whose authority, and what evidence remains**. When a national competent authority opens an on\-site review, the manual gets a polite nod; the evidence files decide the outcome.

The Electronic Money Directive \(**EMD2**, [Directive 2009/110/EC](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32009L0110)¹[^1]\) sets the licence perimeter and the safeguarding regime. The Payment Services Directive \(**PSD2**, [Directive \(EU\) 2015/2366](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32015L2366)²[^2]\) layers on conduct, complaints, and incident reporting. The [Anti\-Money Laundering Regulation](https://eur-lex.europa.eu/eli/reg/2024/1624/oj)³[^3] \(**AMLR**\) imposes the financial\-crime architecture. **DORA** \([Regulation \(EU\) 2022/2554](https://eur-lex.europa.eu/eli/reg/2022/2554/oj)⁴[^4]\) imposes ICT resilience. Four regulatory pillars, eight operating pillars.

The mental shift is small but decisive. Stop asking *"do we have a policy?"* Start asking **"who owns the policy, when does it refresh, and where is the evidence?"** If you cannot answer all three questions in under sixty seconds, that pillar is unowned.

## The Eight Pillars — Overview

The Eight\-Pillar EMI Compliance Programme covers every line that an authorised EMI must defend in supervisory dialogue. The pillars are not a checklist. They are a **continuously operated system** with named accountability at each pillar.

1. **Governance** — board composition, fit\-and\-proper, RACI, four\-eyes evidence.

1. **AML/CFT** — manual, MLRO function, customer risk assessment, SAR pipeline.

1. **Sanctions** — screening rules, list refresh, hit\-disposition log, OFAC/EU/UN coverage.

1. **Safeguarding** — mandate letter, reconciliation cadence, exception log, banking\-partner refresh.

1. **ICT / DORA** — ICT risk register, third\-party register, incident classification.

1. **Outsourcing** — critical functions, exit plans, annual review.

1. **Complaints** — intake, decisioning timelines under PSD2 Art. 101, escalation to NCA.

1. **Reporting** — regulatory returns, internal MI, board\-level dashboard.

> **Tip:** If any pillar cannot answer 'who owns this, when does it refresh, and where is the evidence' in under sixty seconds, treat it as unowned and rebuild it before the next inspection cycle.

## Pillar 1: Governance

Governance is the architecture's load\-bearing wall. Every other pillar inherits its escalation path from here. The **board composition** must satisfy [EBA Guidelines on internal governance \(EBA/GL/2021/05\)](https://www.eba.europa.eu/regulation-and-policy/internal-governance)⁵[^5] — independence, collective suitability, succession planning.

**Fit\-and\-proper refresh** runs **annually** for every key function holder — board, CEO, CFO, MLRO, CCO, Head of Risk, Head of Safeguarding. The evidence file holds the signed declaration, the criminal\-record extract, the credit\-history confirmation, and the regulatory\-history attestation. **Missing one declaration costs the entire pillar at inspection**.

The **RACI matrix** — Responsible, Accountable, Consulted, Informed — must cover every regulated process. **Four\-eyes evidence** lives in the workflow tool, not in a screenshot folder. If the second pair of eyes is the same person clicking a different button, that is not four\-eyes. **KRI**: percentage of regulated processes with documented RACI; target **100%**. Escalation trigger: any single unowned process surfaced in monthly governance review.

## Pillar 2: AML/CFT

The **AML/CFT manual** is owned by the **MLRO** and refreshes **at least annually** or on any material change in customer base, geography, product mix, or regulation. Under **AMLR**, the manual must reflect a documented **business\-wide risk assessment** that the board has signed.

The **MLRO function** must operate with sufficient seniority, independence, and resourcing — a named primary, a named deputy, no reporting line through commercial. The annual **MLRO report** is a board\-level deliverable, not a memo. It reports SAR volumes, alert backlogs, training completion, EDD case load, and known programme gaps.

The **customer risk assessment** runs at onboarding and refreshes on a risk\-tiered cadence: **annually for high\-risk**, every **two years for medium**, every **three to five years for low**, plus event\-driven triggers. The **SAR pipeline** must show alert generation, triage, escalation, MLRO disposition, and submission timestamps. KRI: alert backlog older than thirty days; target **zero**.

## Pillar 3: Sanctions

Sanctions is the pillar with the lowest tolerance and the highest fine exposure. Inspectors test it first because errors are binary. The **screening rules** must cover **customer onboarding, ongoing daily rescreening, payment\-level screening**, and **counterparty screening** for outbound and inbound transactions.

**List refresh cadence** is **daily** — full stop. Coverage must include the **EU consolidated sanctions list**, **UK OFSI consolidated list**, **OFAC SDN and sectoral lists**, **UN Security Council sanctions**, and any other lists relevant to the customer base. The vendor SLA must explicitly cover refresh frequency.

The **hit\-disposition log** is the evidence file inspectors open first. Every alert must show: trigger source, screening engine, match score, disposition reason, disposition author, second\-line review, and timestamp. KRI: hit\-disposition median time; target **under 24 hours**. Escalation trigger: any true\-positive hit, automatic same\-day notification to the board and the relevant **NCA**.

## Pillar 4: Safeguarding

Safeguarding is the pillar that distinguishes an **EMI** from any other regulated entity. Under **EMD2** Article 7, client funds must be segregated from the EMI's own funds and either held in safeguarding accounts with credit institutions, invested in secure low\-risk assets, or covered by an authorised insurance policy or comparable guarantee.

The **mandate letter** with each safeguarding partner must explicitly acknowledge the safeguarding nature of the account, the EMI's role as account holder for the benefit of customers, and the prohibition on set\-off. A generic operating\-account agreement is not a mandate letter. **Inspectors ask for the letter by name**.

**Reconciliation cadence** is **daily** for the safeguarded balance versus the customer liability ledger. The **exception log** records every break, age, root cause, remediation, and sign\-off. **Banking\-partner refresh** — full re\-due diligence of each safeguarding institution — runs **at least annually**. KRI: aged reconciliation breaks over forty\-eight hours; target **zero**. Escalation trigger: any break that survives one full reconciliation cycle.

> **Warning:** Safeguarding failures sit at the top of every NCA enforcement list because they cause direct customer harm. Treat aged reconciliation breaks as a board\-level incident, not a back\-office cleanup.

## Pillar 5: ICT / DORA

**DORA** applied from **17 January 2025** and reframes ICT from a control objective into a board\-level resilience programme. The **ICT risk register** must cover every information asset, threat scenario, control, residual risk, and treatment owner.

The **third\-party ICT register** — a standalone DORA deliverable — captures every ICT service provider, criticality tier, function supported, data category, location, sub\-outsourcing chain, exit plan reference, and contract anchor. Inspectors will sample\-test the register against the contracts in minutes. **Incomplete registers are the most common DORA finding**.

The **incident\-classification log** applies the DORA classification criteria — clients affected, geographical spread, data losses, reputational impact, duration, economic impact, criticality of services. A **major ICT\-related incident** triggers a same\-day initial notification, an intermediate report within seventy\-two hours, and a final report within one month. KRI: % of incidents classified within four hours; target **100%**.

## Pillar 6: Outsourcing

Outsourcing is governed by the [EBA Guidelines on outsourcing arrangements \(EBA/GL/2019/02\)](https://www.eba.europa.eu/regulation-and-policy/internal-governance/guidelines-on-outsourcing-arrangements)⁶[^6] and overlaps with DORA's third\-party ICT regime. The first task is identifying **critical or important functions** — these carry tighter contract, due diligence, audit\-rights, and exit\-planning requirements.

Every critical or important arrangement needs a **documented exit plan** — not a paragraph stating that one exists, but an operational plan with timelines, alternative providers, data\-migration steps, and tested fallback positions. **"We would re\-tender" is not an exit plan**.

The **annual outsourcing review** tests provider performance, SLA adherence, financial soundness, sub\-outsourcing changes, regulatory\-perimeter shifts, and the continued ability to exit. KRI: % of critical providers with current annual review on file; target **100%**. Escalation trigger: any critical provider operating without a current exit plan walks straight to the board.

## Pillar 7: Complaints

Complaints sit inside **PSD2** Article 101, which sets a **fifteen\-business\-day decisioning window** — extendable, in exceptional circumstances, to **thirty\-five business days** with a justified interim response. Both deadlines are tested on inspection by tracing a sample of cases from intake to closure.

The **intake channel** must be accessible — at minimum a published email address, an in\-app channel, and a postal route. Each complaint is logged, categorised by root cause, assigned an owner, decisioned, and reported. **Root\-cause taxonomy** matters more than volume — recurring causes feed back into product and operations.

Escalation to the **NCA** follows the periodic complaints\-data return, plus immediate notification on any complaint with systemic, conduct, or safeguarding implications. KRI: % of complaints closed within fifteen business days; target **above 95%**. KRI: % of root causes recurring quarter\-on\-quarter; target **declining trend**.

## Pillar 8: Reporting

Reporting is the visible face of every other pillar. Three layers operate in parallel: **regulatory returns** \(NCA\-defined templates, periodicities, and data schemas\), **internal MI** \(monthly compliance pack\), and a **board\-level dashboard** \(one page, eight pillars, eight KRIs, RAG status, trend arrow\).

Regulatory returns include **own\-funds and capital adequacy returns**, **safeguarding returns**, **payments\-volume returns**, **fraud returns**, **DORA major\-incident reports**, and the periodic **complaints data return**. Each return is owned by a named function and produced on a documented timeline.

The **board\-level dashboard** is the single artefact that proves the architecture exists. If a board cannot, in any given meeting, see all eight pillar KRIs with trend arrows on one page, the programme is not yet operating as an architecture. KRI: % of regulatory returns filed on time and accepted first\-pass; target **100%**.

## The Eight Pillars at a Glance


*Table: The eight pillars of an authorised EMI compliance programme — owner, refresh cadence, evidence file, KRI, and primary regulator reference.*

| Pillar | Owner | Refresh | Evidence File | Primary Reference |
| --- | --- | --- | --- | --- |
| Governance | Board / CEO | Annual \+ on change | Board minutes, RACI, F&P file | EBA/GL/2021/05 |
| AML/CFT | MLRO | Annual \+ event\-driven | BWRA, manual, SAR log | AMLR 2024/1624 |
| Sanctions | Head of Financial Crime | Daily \(lists\) | Hit\-disposition log, list\-version log | EU/UK/OFAC/UN regimes |
| Safeguarding | Head of Safeguarding | Daily \(recon\), annual \(DD\) | Mandate letters, recon reports, exception log | EMD2 Art. 7 |
| ICT / DORA | CISO / CIO | Annual \+ on change | ICT risk register, 3rd\-party register, incident log | DORA 2022/2554 |
| Outsourcing | CCO / COO | Annual | Outsourcing register, exit plans | EBA/GL/2019/02 |
| Complaints | Head of Customer Operations | Continuous | Complaints register, decisioning log | PSD2 Art. 101 |
| Reporting | CFO / CCO | Per return periodicity | Returns archive, MI pack, board dashboard | EMD2 \+ PSD2 \+ NCA rules |

## Quarterly Cadence Map

Each pillar should produce a defined output every ninety days. A **quarterly cadence map** turns the architecture into an operating rhythm — and gives the board a predictable, comparable artefact pack.


*Table: Quarterly cadence map — the deliverable each pillar produces every 90 days.*

| Pillar | Q1 | Q2 | Q3 | Q4 |
| --- | --- | --- | --- | --- |
| Governance | Annual board effectiveness | F&P refresh sweep | RACI refresh | Annual self\-assessment |
| AML/CFT | BWRA refresh | Manual review | Training cycle | Annual MLRO report |
| Sanctions | Vendor SLA review | Rules calibration | Annual screening tuning test | Coverage review |
| Safeguarding | Bank DD refresh | Recon controls review | Mandate\-letter audit | Annual safeguarding attestation |
| ICT / DORA | ICT risk\-register refresh | TLPT / scenario test | Third\-party register audit | Annual ICT strategy review |
| Outsourcing | Critical\-provider review | Exit\-plan walkthrough | Sub\-outsourcing audit | Annual register refresh |
| Complaints | Root\-cause analysis | Decisioning SLA audit | Regulator return | Annual trend report |
| Reporting | Returns calendar refresh | Dashboard review | MI pack refresh | Annual reporting attestation |

## The Three Most Inspected Pillars \(and Why\)

Across EEA NCA enforcement actions, three pillars dominate findings: **Safeguarding**, **AML/CFT**, and **ICT**. Each fails for a different reason and each demands a different defence posture.

**Safeguarding** fails because reconciliation breaks age, mandate letters are missing, or the customer\-liability ledger drifts from the safeguarded balance. Customer harm is direct and visible — and so is the fine.

**AML/CFT** fails because alert backlogs grow, customer\-risk reviews lapse, and SARs are filed late or not at all. Under **AMLR** and the new **AMLA** supervisory regime, the standard rises and the scope of direct supervision widens for higher\-risk firms.

**ICT** fails because the **third\-party register** is incomplete, the incident\-classification log lacks rigour, or exit plans are theoretical. **DORA** raised the bar substantially — what counted as adequate in 2024 is materially below the line in 2026.

## Frequently Asked Questions

### What does an EMI compliance programme actually contain?

An **EMI compliance programme** contains eight pillars: **Governance, AML/CFT, Sanctions, Safeguarding, ICT/DORA, Outsourcing, Complaints, and Reporting**. Each pillar has a named owner, a refresh cadence, a supervisor\-facing evidence file, a KRI that triggers escalation, and a defined path to the board. The combined artefact pack — manuals, registers, logs, dashboards — is what an NCA inspection actually tests.

### How often must an EMI refresh its compliance manual?

At minimum **annually**, plus on any material change in business model, product, geography, customer base, or regulation. Under **AMLR** and **DORA**, the cadence is tighter for the financial\-crime manual and the ICT risk register. Treat the annual refresh as a minimum floor, not a ceiling — event\-driven refreshes are what differentiate a programme from a manual.

### Who has to sign off on the EMI's risk register?

The **board** signs the **business\-wide risk assessment** under AMLR, the **ICT risk register** under DORA, and the **enterprise risk register** under the EBA internal\-governance guidelines. Operational ownership sits with the MLRO, CISO, and Head of Risk respectively, but the accountability for accuracy and completeness lives at board level.

### What's the difference between an EMI compliance programme and a CASP one?

The eight\-pillar architecture is broadly the same, but the underlying obligations differ. An **EMI** sits under **EMD2 \+ PSD2** with safeguarding as the defining pillar. A **CASP** sits under **MiCA** with client\-asset segregation, market\-abuse, and white\-paper obligations on top. Both inherit AMLR and DORA. The architecture is portable; the regulatory references and capital rules are not.

> **Call to action:** Want the architecture installed in your EMI? Finconduit builds and runs the eight\-pillar programme for authorised and pre\-authorisation EMIs. Free first diagnostic — no committee required.

## Related Guides

- [EMI Safeguarding Architecture](/resources/emi-safeguarding-architecture) — how the safeguarding pillar is built, run, and inspected.

- [AML Compliance Retainer for CASPs](/resources/aml-compliance-retainer-casp) — what an outsourced AML/CFT function actually delivers.

- [AMLR Readiness Programme: 12\-Month Roadmap](/resources/amlr-readiness-12-month-roadmap) — sequencing the AML/CFT pillar through to the 2027 application date.

- [DORA Implementation Playbook](/resources/dora-implementation-playbook-casps) — building out the ICT pillar to inspection\-ready depth.

The reason this architecture matters is not theoretical. Supervisory inspections — both routine and *thematic* — increasingly test the operating reality of compliance, not the existence of a manual. An inspector who arrives with a sampling plan does not want to read the AML policy; they want to pull twenty customer files at random and trace each from onboarding through ongoing monitoring to closure. They do not want the safeguarding policy; they want the **daily reconciliation** for the last ninety days with every break narrated. They do not want the ICT chapter; they want the **third\-party register** and three randomly selected contracts to compare. Architecture beats manual because architecture is the only structure that produces those artefacts on demand.

The boards that operate this well have three habits in common. First, every pillar has a single **named owner** — not a department, not a committee, a person whose performance review references the pillar. Second, every pillar publishes one **forward\-looking KRI** rather than a backwards\-looking volume metric — for safeguarding, ageing reconciliation breaks; for AML, alert backlog; for sanctions, hit\-disposition median time. Third, the board reviews the eight\-pillar dashboard **every meeting** without exception — so the architecture is the agenda, not a slide pack circulated afterwards.

There is a fourth habit that distinguishes the firms running an architecture from the firms running a manual: they treat **evidence** as a first\-class product. Every pillar designs its workflow so that evidence is produced as a natural by\-product of doing the work — not retrofitted afterwards. If the safeguarding reconciliation requires a sign\-off click in a workflow tool, the evidence is automatic. If it requires writing a memo at quarter\-end, the evidence is unreliable. Architectures that depend on people remembering to document do not survive a two\-day supervisory site visit.

The cost of installing the architecture is meaningful but finite. For a mid\-sized authorised **EMI** the first\-year build typically runs across the compliance, risk, ICT, and operations functions, with the heaviest lift in the **third\-party register** and the **business\-wide risk assessment**. The cost of *not* installing it is open\-ended — supervisory variation orders, a **section 166\-equivalent skilled\-person review**, restitution costs, a public censure, and in the worst cases a **variation of permission** or licence revocation. Boards that have priced the downside do not under\-invest in the architecture.

A manual tells a supervisor what an EMI intends. A **programme** tells a supervisor what an EMI actually does, every day, on whose authority, and with what evidence remaining. The eight pillars are not a maturity model to grow into — they are the minimum operating standard for any authorised EMI in 2026. The firms that survive the next inspection cycle are the ones already running the architecture, not the ones still writing about it.

- [The Orderly Wind\-Down Plan for CASPs and EMIs](/resources/casp-emi-wind-down-plan) — the wind\-down plan that supervisors expect a compliant EMI programme to maintain from authorisation.

## Footnotes

[^1]: Directive 2009/110/EC of the European Parliament and of the Council 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%3A32009L0110>
[^2]: Directive \(EU\) 2015/2366 of the European Parliament and of the Council on payment services in the internal market \(PSD2\), OJ L 337, 23.12.2015. <https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32015L2366>
[^3]: Regulation \(EU\) 2024/1624 of the European Parliament and of the Council on the prevention of the use of the financial system for the purposes of money laundering or terrorist financing \(AMLR\), OJ L, 19.6.2024. <https://eur-lex.europa.eu/eli/reg/2024/1624/oj>
[^4]: Regulation \(EU\) 2022/2554 of the European Parliament and of the Council on digital operational resilience for the financial sector \(DORA\), OJ L 333, 27.12.2022. <https://eur-lex.europa.eu/eli/reg/2022/2554/oj>
[^5]: EBA Guidelines on internal governance under Directive 2013/36/EU \(EBA/GL/2021/05\), European Banking Authority, July 2021. <https://www.eba.europa.eu/regulation-and-policy/internal-governance>
[^6]: EBA Guidelines on outsourcing arrangements \(EBA/GL/2019/02\), European Banking Authority, February 2019. <https://www.eba.europa.eu/regulation-and-policy/internal-governance/guidelines-on-outsourcing-arrangements>


---
Source: https://finconduit.com/resources/emi-compliance-programme-architecture