Most EMI delays aren’t caused by “slow regulators.” They’re caused by one thing: the application is not assessable as submitted.
PSD2 is explicit that the authority communicates its decision within 3 months of receiving an application — or, if incomplete, within 3 months of receiving all required information. In other words, the clock is effectively “paused” until the submission is complete.
EBA’s peer review on PSD2 authorisations found the average end-to-end timelines vary widely across Member States (from a few months to well over a year), and highlighted that a key driver is application quality and how quickly applicants address issues raised.
Below are the most common delay drivers, and what to do to avoid rework—especially relevant for Czechia (ČNB), but structurally true across the EU.
“Incomplete” submissions (missing attachments, vague answers, outdated info)
What happens: the regulator asks for supplements, the formal assessment window doesn’t really start, and you enter a loop of Q&A.
How to avoid rework
- Build a master document index (1 spreadsheet) listing every requirement → file name → page reference → owner.
- Freeze a “submission version” and do a pre-submission completeness audit.
- Follow the EBA authorisation guideline mindset: information should be complete, accurate, up-to-date, and presented in a way the authority can assess without guessing.
Regulators publicly say this too: they can only assess a fully completed application, and their statutory period starts once it’s complete.
Unclear scope and “program of operations” (what exactly you do)
What happens: your product looks like three different businesses depending on which section the reviewer reads.
Typical red flags
- “Wallet” described like e-money in one place, like a payment account elsewhere
- Undefined flow: who holds funds, who issues what, when redemption happens
- Missing mapping between services and real customer journeys
How to avoid rework
- Provide a scope & products matrix (product → legal activity → customers → geographies → partners → money flow).
- Add end-to-end diagrams (onboarding → funding → spend → redemption → complaints).
Weak safeguarding package (the #1 deep-dive area in reviews)
What happens: the authority can’t conclude client funds are protected operationally, not just “on paper.”
Common gaps
- No daily reconciliation logic / ownership
- Access rights to safeguarding accounts unclear
- No failure scenario (what happens if a partner fails, or settlement breaks)
How to avoid rework
- Include a safeguarding operating procedure (daily steps, evidence outputs, exception handling).
- Attach bank/partner letters, account structures, and access control evidence early.
You haven’t clearly evidenced the capital and the source of funds
What happens: the supervisor sees funding as uncertain, conditional, or inconsistent with the plan.
How to avoid rework
- Provide a simple capital story: source → timing → documentary proof.
- Reconcile forecasts to capital needs (including stressed scenarios), and make assumptions explicit.
Governance looks nominal (roles named, but no real control model)
What happens: the regulator probes “who actually controls risk, compliance, outsourcing, and incidents” and doesn’t see a working system.
How to avoid rework
- Deliver governance as decision mechanics, not job titles:
- reporting cadence (monthly risk pack, KRIs, incidents)
- approval workflow (new products, vendor onboarding, limit changes)
- internal control plan (testing + remediation ownership)
EBA guidance pushes for assessable governance and management information rather than vague descriptions.
Fit-and-proper evidence arrives late (or doesn’t match responsibilities)
What happens: the file “waits” for appointments, time allocation, background documents, or role clarity.
How to avoid rework
- Lock key function holders early.
- Provide a responsibility map (role → consideration areas → evidence).
AML/CTF is generic, not tied to your product and channels
What happens: The applicant treats AML like a template even though the business model is high-risk (cross-border flows, agents/distributors, cash-in rails, cards, crypto exposure, etc.)
How to avoid rework
- Provide a real business risk assessment (customers/geo/channels/products).
- Show transaction monitoring coverage and escalation (alerts → investigation → SAR decisions).
- Prove you can control AML if parts are outsourced.
EBA’s follow-up peer review flags remaining gaps across the EU in governance and internal controls (including AML/CFT-related areas), which is exactly where reviewers lean in.
Outsourcing and ICT controls don’t meet expectations (DORA-era reality)
What happens: You outsource core functions (KYC, monitoring, ledger, card processing, cloud), but you can’t evidence effective oversight, operational resilience, or credible exit plans.
Why it’s worse in 2026: DORA has applied since 17 January 2025, raising baseline expectations for ICT risk, incident handling, and third-party oversight.
How to avoid rework
- Maintain a critical outsourcing register (services, criticality, audit rights, subcontractors, exit plan).
- Include incident management playbooks and evidence of testing (tabletop exercises help).
Financial model doesn’t match the operating reality
What happens: the reviewer sees aggressive volume growth but no staffing, no compliance cost, no chargeback/fraud provisions, no vendor cost scaling.
How to avoid rework
- Add an “assumptions book” and show sensitivity (base/downside).
- Tie headcount, control functions, and vendor costs to growth.
Slow, messy regulator Q&A responses (the silent timeline killer)
EBA’s peer review highlights applicant responsiveness as a major factor in delays.
How to avoid rework
- Run Q&A like a workstream:
- a single Q&A tracker (question → owner → due date → evidence files → version)
- short answers + annex evidence (don’t rewrite the whole file each time)
- strict version control (what changed, where)
Submission mechanics errors (datová schránka, package format, “original” documents)
For Czechia (ČNB), you submit the application and conduct all subsequent formal communication via the datová schránka. Errors at the channel/format/packaging level often lead to returns, clarification requests, and extra iterations that silently consume the timeline.
How to avoid rework
- Before “Day 0,” validate the datová schránka workflow: confirm access, verify who can send on the applicant’s behalf, identify the duly authorized signatory/representative, and define how you will capture and store delivery and receipt confirmations.
- Package the submission so it is assessable without guesswork:
a clear annex list + a consistent file-naming convention + a fixed submission version (e.g., “Submission v1.0”). - Make evidence navigation easy:
maintain a single index (one spreadsheet) mapping “requirement → file → section/page reference → owner” so the reviewer can locate supporting evidence quickly. - Pre-empt “original document” issues:
if some materials exist only in paper form (originals / certified copies), prepare their properly valid electronic form (via appropriate authorised conversion/certification) so they don’t fail on formalities. - Respect technical constraints:
message/attachment size limits, readable formats (PDF), avoiding chaotic scans, and using clear numbering and cross-references throughout.
A simple “no-rework” toolkit (what we implement for fast files)
- Document Index + Evidence Map (single source of truth)
- Scope Matrix + Money-Flow Diagrams
- Safeguarding Operating Pack (daily controls + evidence outputs)
- Outsourcing & ICT Pack aligned with DORA expectations
- Q&A Tracker with owners + evidence links (fast turnaround, clean audit trail)
How AMS helps you avoid EMI rework
Most delays happen because the file is not assessable on submission.
We build a ČNB-ready application pack that’s complete, consistent, and easy to review — so you don’t lose months in “supplements”.
-
Gap check vs. EMI scope + PSD2 expectations
-
Document index, folder structure, and cross-references
-
Governance, AML, safeguarding, and outsourcing evidence pack
-
Pre-submission QA + “mock regulator Q&A”
-
Support during follow-ups (clean answers, no contradictions)
What you get?
FAQ: Common reasons EMI applications get delayed
Why do EMI licensing processes in the EU often take 6–12+ months, even if the “legal” deadline is shorter?
In practice, the overall timeline is driven less by the statutory review period and more by how quickly the applicant brings the file to an “assessable” state. When the submission contains gaps, inconsistencies, or documentation that cannot be stitched into a coherent picture of the business, the supervisor starts a cycle of follow-up questions, clarifications, and revised versions. That iterative back-and-forth is what adds months. To shorten the time to an EMI licence, the key is to pre-build an assessable package: a single document index, an evidence map, clear money-flow diagrams, and control procedures that can be verified. This reduces the number of Q&A rounds and avoids rebuilding the file multiple times.
How should you describe an EMI business model so the regulator clearly understands what you do and which licence it fits?
The most common mistake is describing the product in marketing terms (“wallet”, “platform”, “payments”) without explaining the legal substance of each activity. Regulators don’t need slogans; they need operational clarity: which services you provide, when and how e-money is issued, who holds customer funds, who executes the payment, and when redemption happens. A strong approach is to create a “product map”: for each customer journey (onboarding → funding → holding → spending → refunds/redemption), show the parties involved, their roles, the contractual relationships, and the movement of money. This helps eliminate a major red flag—when different sections of the application make it look like the firm itself is unsure whether it is an EMI, a payment institution, or just a technical service provider.
What does the regulator typically expect to see in safeguarding to conclude customer funds are protected in practice (not just on paper)?
Safeguarding is not proven by stating “we keep funds in a segregated account.” Regulators want operational, evidence-based protection: who performs daily reconciliation, what reports are produced, what qualifies as an exception, who approves corrections, and how the firm responds if a partner fails, settlement breaks, or a bank is delayed. A strong safeguarding package usually includes: step-by-step daily procedures, report templates and evidence outputs, access-control evidence for safeguarding accounts, and realistic “what-if” scenarios (settlement delays, disputes, refunds, mis-postings). Safeguarding is one of the highest-scrutiny areas and a frequent reason for deep dives—so getting it right often has a direct impact on EMI licence timelines.
Which AML/CTF weaknesses most often derail EMI applications, and how can you prove your compliance is not generic?
A common failure is submitting policies that look formally correct but are not connected to how the business actually acquires customers and processes transactions. If your model is cross-border, uses agents/distributors, includes cash-in rails, cards, or has crypto exposure, the AML/CTF framework must be tailored to those specific risks—not a generic template. To demonstrate maturity, the application should show: a business risk assessment by customers/geographies/channels/products, the logic of transaction monitoring (which scenarios you detect and why), a clear escalation path (alert → investigation → decision → SAR/STR), and how you control AML if key elements are outsourced (e.g., KYC providers). This makes the file assessable and reduces the volume of regulator questions.
How do you prepare for DORA-era outsourcing and ICT expectations so the tech/outsourcing section doesn’t become a licensing bottleneck for an EMI?
Since 2025, baseline expectations for ICT risk management and third-party oversight have increased materially, and in 2026 this is clearly reflected in reviews. Most fintech core functions depend on vendors—cloud, card processing, KYC, monitoring, and the ledger. Regulators don’t just want to know you “use providers”; they want evidence that you govern them: a critical outsourcing register, audit rights, subcontractor controls, clear SLAs/metrics, and a realistic exit plan. A strong ICT/DORA-aligned pack also includes incident playbooks, notification procedures, and proof of testing (including tabletop exercises), alongside clear internal accountability. This reduces the risk that the supervisor pauses substantive assessment until operational resilience and oversight are evidenced.
