The Anatomy of a Successful EMI Authorisation: What's Actually in the File

Most founders know they need an Electronic Money Institution (EMI) licence. Very few can describe what is actually inside the file submitted to the supervisor. An EMI authorisation file is not a single document. It is a structured pack of fourteen interlocking workstreams, each with a specific reader at the National Competent Authority (NCA), each with its own quality bar, each capable of killing the application on its own.

Supervisors at the Bank of Lithuania, CSSF, MFSA, Central Bank of Ireland, BaFin, ACPR, and CySEC do not read the file end-to-end. They read it in a specific order, looking for specific failure modes. A programme of operations gets opened first. A risk register gets stress-tested second. Safeguarding architecture and the management body's fit-and-proper come third. Everything else is verification.

This article walks the anatomy. It describes the 14-document architecture in supervisor reading order, what each section must contain, which sections kill files most often, and the three rejection reasons that recur across NCAs.

An EMI authorisation is a paper decision. The supervisor never visits the office during assessment. They never observe a transaction. They form a complete view of the applicant's business model, governance, safeguarding, AML programme, and operational resilience exclusively from the contents of the file. Every gap is a question; every question is a delay; enough delays become a withdrawal.

The statutory basis is Directive 2009/110/EC (EMD2)¹, read together with PSD2 (Directive (EU) 2015/2366)², and overlaid by the EBA's binding guidelines. Each section of the file maps to a specific Article, a specific Guideline, or a specific national transposition provision. If you cannot point at the legal anchor for each section, the section is not finished.

The quality of an EMI file varies more by section than by author. A well-drafted programme of operations is wasted next to a copy-paste risk register. A pristine AML manual cannot rescue a safeguarding mandate letter that lacks ring-fencing language. Supervisors read the weakest section as the truth about the applicant, because that section reveals where management's attention does not go.

Across the EEA, the EMI authorisation file converges on fourteen mandatory documents. Local NCAs add national annexes — Lithuania asks for a separate IT integration questionnaire, Malta a fit-and-proper for shareholders above 10%, Ireland an Individual Questionnaire (IQ) per Pre-Approval Controlled Function — but the fourteen below are the shared spine.

Supervisors read them in approximately this order. The order matters: a strong Document 1 builds credibility for the rest of the file; a weak Document 1 means every later document is read with suspicion.

The programme of operations is the single most-read document in the file. It is the narrative the supervisor uses to understand who you are, what you do, who pays you, and what could go wrong. Article 5(1)(b) of EMD2 requires it. EBA guidelines on authorisation specify what it must contain.

A serious programme of operations runs 40 to 80 pages and contains five mandatory chapters:

• Business model narrative — services, target customers, geographic scope, pricing, distribution channels, and the customer's specific journey from onboarding to first transaction to dispute resolution.

• Five-year financial forecast — monthly for years 1–2, quarterly for years 3–5, with base, downside, and stressed scenarios. Volume assumptions must reconcile to capital adequacy and safeguarding projections.

• Customer-journey maps — at least three: a retail e-money holder, a corporate user, and a B2B platform partner. Each map must show every regulatory touchpoint (KYC, transaction monitoring, complaint handling, statement issuance).

• What-could-go-wrong analysis — the firm's view of its top ten failure modes, ranked by probability and impact, with the specific control that prevents each one. This chapter is what proves the management body understands its own business.

• Operational architecture — system diagram, payment-rails dependency map, third-party providers, and the firm's own staffing plan tied to volume growth.

The programme of operations must be signed personally by the proposed CEO and counter-signed by the proposed Head of Compliance / MLRO and the Chair of the Board. The signatures are not ceremonial — they bind the management body to the narrative, and supervisors will cross-examine inconsistencies during the fit-and-proper interviews.

The governance pack proves the firm has a competent, independent management body capable of running an EMI. Article 3(1) of EMD2 imports the PSD2 governance test, which the EBA further specifies in its guidelines on the suitability of the management body.

The governance pack must contain:

• Board composition — at least one independent non-executive director (two is the supervisor's preferred default for a new EMI), with declared independence criteria and time-commitment letters.

• Fit-and-proper files — for every member of the management body and every shareholder above 10%: CV with no gaps, regulatory references, criminal-record certificate (not older than three months), credit check, declaration of interests, and a written knowledge-and-experience self-assessment mapped to the EBA suitability matrix.

• Four-eyes principle evidence — at least two senior managers permanently resident in the licensing jurisdiction with full executive responsibility. This is a hard requirement; remote-CEO setups get rejected.

• RACI matrix — every regulatory obligation (safeguarding, AML, ICT, complaints, capital, reporting) mapped to a named owner, named approver, and named escalation route. Generic role labels ("Compliance") fail; specific person-by-person ownership passes.

• Committee charters — Risk, Audit, Remuneration (or a justified single committee for a smaller EMI), with quorum rules, voting thresholds, and reporting lines.

The risk register is where supervisors test whether the management body actually understands the business or has merely written a brochure. A passing risk register is quantified, not narrative.

Every material risk gets one row containing eight fields:

• Risk identifier and short description

• Inherent risk score (probability × impact, on a documented scale)

• Named control(s) — preventive and detective, each pointing to a specific policy section

• Residual risk score

• Key Risk Indicator (KRI) with measurement frequency and amber/red thresholds

• Escalation trigger — what specifically activates board notification

• Risk owner (named individual, not role)

• Review date and last-tested date

A serious EMI risk register contains 50 to 120 individual risks, grouped by category: prudential, conduct, AML/financial crime, ICT and operational, outsourcing, market, strategic, reputational. A register with twenty rows is read as a register that hasn't been built — it is read as a register that hasn't been thought through.

Article 7 of EMD2 requires that all funds received in exchange for electronic money are safeguarded. The EBA Guidelines on the criteria for the assessment of the safeguarding requirements (EBA/GL/2017/09)³ specify what supervisors expect.

The most underrated document in the entire file is the safeguarding mandate letter from the credit institution holding the safeguarded funds. It is the bank-side document, and it must satisfy three criteria:

• Same account name on both sides — the safeguarding account name in the bank's letter must match the name used in the firm's safeguarding policy, the firm's general ledger, and the reconciliation reports. Mismatches kill files.

• Ring-fencing language — explicit acknowledgement that funds in the safeguarding account are held for the benefit of e-money holders, do not form part of the EMI's estate in insolvency, and cannot be set off against any obligation the EMI owes the credit institution.

• Operational covenants — daily reporting feed, withdrawal restrictions (no payments out except to e-money holders or under court order), reconciliation cycle, and notification triggers for unusual flow patterns.

If the safeguarding bank is not yet contracted at application time, an in-principle confirmation letter (sometimes called a comfort letter) from a Tier-1 EU credit institution is acceptable, but only if it lists the three criteria above. A generic "we look forward to working with you" letter does not pass.

EMIs are obliged entities under the EU AML framework. The AML/CTF section must include a full Business-Wide Risk Assessment (BWRA), customer risk-rating methodology, sanctions screening procedures (real-time and re-screening), transaction monitoring rule set with documented thresholds, suspicious-activity reporting workflow, training plan, and the MLRO appointment.

The MLRO appointment is its own mini-file: personal CV, fit-and-proper, written job description, declared time commitment, escalation authority, and a signed acknowledgement of the personal liability the role carries. The MLRO must be resident in the licensing jurisdiction and must report directly to the board (or a board committee), not to the CEO.

With the AML Regulation (AMLR) coming into force, supervisors increasingly expect the BWRA to anticipate the AMLA single rulebook and reference the harmonised customer-due-diligence categories the EBA has been consulting on. A 2026 application that references only the 5AMLD/6AMLD body of rules without acknowledging AMLR is read as out of date.

The ICT section maps to the EBA Guidelines on ICT and security risk management (EBA/GL/2019/04)⁴, the EBA Guidelines on the security of internet payments (EBA/GL/2014/12)⁵, and — for any 2026 application — the Digital Operational Resilience Act (DORA), which applies to EMIs from January 2025.

The chapter must contain the firm's ICT risk-management framework, asset inventory, network and information-system architecture, change-management policy, vulnerability-management cycle, incident classification and reporting taxonomy, business-continuity and disaster-recovery plans, and the DORA-mandated digital operational resilience testing programme.

A common failure mode: the applicant treats ICT as a vendor question ("our cloud provider handles this") rather than as the EMI's own accountability for outcomes. Cloud providers do not bear regulatory liability for the EMI's customers. The board does.

Article 4 of EMD2 sets the initial capital floor for an EMI at EUR 350,000. Ongoing own funds must additionally satisfy Article 5: the higher of (a) the EUR 350,000 floor, (b) a percentage of outstanding e-money under Method D, and (c) the PSD2 own-funds calculation for any unbundled payment services the EMI also intends to provide.

The capital pack must contain:

• Worked own-funds calculation under each applicable method, with the chosen method justified

• Source-of-funds evidence for the paid-up capital — bank statements, share-subscription agreements, and a wealth-source narrative for shareholders above 10%

• Capital projection over five years, reconciled to the volume forecast in the programme of operations

• Capital management policy including the firm's internal own-funds buffer and the trigger at which the board must call additional capital

The EBA Guidelines on outsourcing arrangements (EBA/GL/2019/02)⁶ require every EMI to maintain a comprehensive outsourcing register. The register must list every third-party arrangement, classify each as critical or non-critical, and document the firm's due diligence, contractual safeguards, and exit plan.

Critical functions get the heaviest treatment: documented exit strategy, mapped continuity provider, data-portability tested, audit rights for the firm and the supervisor, and sub-outsourcing chain visibility. For cloud arrangements, location-of-data and concentration-risk disclosures are non-negotiable.

The remaining six sections are shorter but unforgiving:

• Section 9: Customer communications — terms of service, fee disclosures, statement templates, regulatory disclosures (including the Article 11 PSD2 information requirements applicable to the EMI's payment services).

• Section 10: Complaints procedure — internal handling within statutory deadlines (15 business days under PSD2, with the option to extend in exceptional cases), Alternative Dispute Resolution (ADR) route, and the management-information return to the board.

• Section 11: Business Continuity Plan (BCP) — scenario library, Recovery Time Objectives (RTOs), Recovery Point Objectives (RPOs), tested annually, board-approved.

• Section 12: Internal audit charter — independent function (in-house or co-sourced), three-year rolling plan, direct line to the Audit Committee.

• Section 13: Insurance — professional indemnity, cyber, and crime cover sized to the volume forecast; binder letters are acceptable at application stage.

• Section 14: References — independent regulatory references for each member of the management body from a prior regulated employer or prior NCA, plus auditor references.

The table below summarises what each section contains, its typical length, its owner inside the applicant, and the section-specific deadline pressure that drives the build sequence.

Each section has a characteristic failure mode that supervisors look for first. The table below catalogues the most common ones, drawn from public NCA feedback letters and EBA peer-review reports.

If only one chapter of the file is read carefully, it is the programme of operations. Three sub-sections decide the supervisor's opinion of the applicant.

The first is the customer journey. A passing journey describes a real customer — what they see, what they sign, what happens to their money on day one, day thirty, and day three-hundred-and-sixty-five. A failing journey describes a feature list. The test: can the supervisor close the document and re-tell the customer's first transaction step by step?

The second is the what-could-go-wrong analysis. This is the chapter most applicants skip or under-treat. The supervisor's read is binary: either the management body has imagined its top failure modes and built specific controls, or it has not. There is no middle ground.

The third is the five-year financial forecast. Supervisors stress-test the model against the EMI's safeguarding load (Article 5 calculation), own-funds requirement, staffing plan, and ICT cost base. If the volume curve produces an own-funds shortfall in year three, the file is sent back. If the staffing plan does not scale with volume, the file is sent back. The forecast must be a self-consistent model, not a spreadsheet.

Across public NCA decisions and peer-review observations, three rejection patterns recur:

1. Insufficient local substance. The applicant proposes a brass-plate setup — two non-resident directors, an outsourced compliance function, no operational headcount in the licensing jurisdiction. NCAs across the EEA have hardened on substance since 2020. An EMI must run from the licensing jurisdiction, with named individuals physically present and authorised to take decisions.

2. Safeguarding architecture that does not survive insolvency stress. The most frequent technical failure: the safeguarding bank's letter does not contain explicit ring-fencing and set-off-waiver language, or the account name on the bank side does not match the EMI's books, or the reconciliation cycle is weekly rather than daily. Article 7 EMD2 is unforgiving on this.

3. Risk register and programme of operations that do not reconcile. A volume forecast that implies a class of risk (for example, high-value corporate flows triggering enhanced due diligence at scale) without that risk appearing in the register is read as a sign that the firm has not modelled itself. Cross-document consistency is the cheapest test the supervisor runs, and the easiest one for an applicant to fail.

Across the EEA, the EMI authorisation file converges on fourteen mandatory documents: programme of operations, governance pack, risk register, safeguarding mandate letter, AML/CTF manual with MLRO appointment, ICT and operational resilience pack, capital adequacy pack, outsourcing register, customer communications, complaints procedure, business continuity plan, internal audit charter, insurance binders, and independent references. National regulators may add jurisdiction-specific annexes (Lithuania, Ireland, and Malta each have particular extras).

The EMD2 statutory clock is three months from a complete file, but the clock only starts when the supervisor declares the file complete. In practice, end-to-end timelines from kick-off to authorisation run 9 to 18 months: 3 to 6 months for pre-application drafting, 1 to 3 months of completeness review, 3 months of statutory assessment, plus question-and-answer cycles. A clean file with pre-application engagement compresses the lower end; a file submitted cold extends the upper end.

The programme of operations must be personally signed by the proposed CEO and counter-signed by the proposed MLRO and the Chair of the Board. The signatures bind these individuals to the narrative — during the fit-and-proper interviews, supervisors will ask each signatory to defend specific sections. Inconsistencies between what the document says and what the signatories say during interview are the most common reason a file pivots from "approval pending" to "withdrawn and resubmitted".

An EMI licence is granted by one home-state NCA only, and the passport regime under EMD2 extends that single licence across the EEA. So one file goes to one regulator. But the substance of the file (the fourteen sections above) is largely portable: the same programme of operations, risk register, AML manual, ICT pack, and safeguarding architecture can be adapted to any EEA NCA with marginal jurisdiction-specific edits (national language, local committee structure, national AML-specific annex). The decision is therefore not "which file?" but "which home jurisdiction?" — driven by substance, talent availability, supervisor responsiveness, and corporate-tax considerations.

“

Need the EMI file actually built and submitted? Finconduit assembles the 14-document pack and shepherds it through the supervisor's questions. Pay only on authorisation. Book a free pre-application diagnostic.

• EMI Safeguarding Architecture — the ring-fencing, account-naming, reconciliation, and bank-side mandate detail behind Section 4 of the file.

• EMI vs PSP vs VASP vs CASP Licence Comparison — how the EMI file sits next to other regulated-entity packs across the EU regime.

• Payment Institution (PI) Licence in the EU — the PSD2 sister regime that shares 90% of the file with EMD2.

• The 90-Day Pre-Application File Build for EMI/PI — the build sequence and workstream calendar that produces the fourteen documents described above.

An EMI authorisation is not a permission; it is a paper test of whether the management body has actually built a business it can run. The fourteen documents are the test paper. Each one carries a specific reader, a specific failure mode, and a specific legal anchor. The applicants who pass are not the ones with the most polished narrative — they are the ones whose programme of operations, risk register, safeguarding mandate, and capital model all describe the same firm. Cross-document consistency is the simplest, cheapest, and most decisive quality test a supervisor runs. Build the file so it survives that test, and the rest is process.

¹ Directive 2009/110/EC on the taking up, pursuit and prudential supervision of the business of electronic money institutions (EMD2) — EUR-Lex.

² Directive (EU) 2015/2366 on payment services in the internal market (PSD2) — EUR-Lex.

³ EBA Guidelines on the criteria for the assessment of the safeguarding requirements (EBA/GL/2017/09) — European Banking Authority.

⁴ EBA Guidelines on ICT and security risk management (EBA/GL/2019/04) — European Banking Authority.

⁵ EBA Guidelines on the security of internet payments (EBA/GL/2014/12) — European Banking Authority.

⁶ EBA Guidelines on outsourcing arrangements (EBA/GL/2019/02) — European Banking Authority.