A complete application to become an Electronic Money Institution takes the FCA roughly three months to assess. An incomplete one can take twelve. Whether the application’s underlying technology does what the paperwork claims is the deciding factor.
EMI license requirements include specific obligations: safeguarding customer funds, maintaining governance arrangements, and keeping an incident response plan on file. Each of these depends on a working system behind it.
Safeguarding customer funds requires ledger logic that separates customer funds from company funds. Governance arrangements include a wind-down plan the infrastructure can execute. An incident response plan requires monitoring that can produce an audit trail.
Your compliance team writes these policies. Your engineering team builds the systems that make them work.
That’s why EMI license requirements are, in practice, as much a CTO’s problem as a legal one. And that also explains why the technical groundwork usually has to start six to nine months before submitting an application.
The stakes keep climbing as safeguarding, resilience, and outsourcing oversight have all tightened in the past two years. PSD3’s implementation will push the technical bar higher still across the UK and EU.
When people talk about EMI license requirements, they usually mean the legal ones like initial capital, fit-and-proper directors, or a safeguarding policy.
The FCA’s own guidance for EMI applicants lists what it wants alongside the legal documentation which included a programme of operations, safeguarding measures, governance arrangements including a wind-down plan, and procedures for incident reporting, managing sensitive payment data, and business continuity.
The FCA’s supporting-material checklist for authorised EMI (AEMI) applicants asks for detail on:
If any of this is missing, the regulator says plainly that it will reject the submission without assessing it at all.
Standard timescales for a new firm are three months from a complete application, twelve months for an incomplete one.
Delays trace back to disconnects between what the business plan claims and what the underlying systems can demonstrate. For example, there is a safeguarding narrative with no matching reconciliation process or an incident response procedure with no monitoring stack behind it.
Architectural risks often come to light late in the review process. For example, a ledger that mixes customer and operational funds instead of structurally separating them or sensitive payment data that hasn’t been encrypted or tokenized as required by the security policy. These only come up when a reviewr looks over the business plan and asks a technical question that the plan can’t answer.
How to get an EMI license without losing time later? It actually comes down to when the technical groundwork starts.
By the time a product is mostly built, foundational decisions are already locked in: for example, how the ledger separates customer funds from company funds.
It is far more cost-effective to incorporate those decisions during design.
How to get EMI license approval without losing quarters to review cycles: the technical conversation starts six to nine months before submission.
Decisions made early in a product’s development determine what’s possible later. If a shared ledger doesn’t separate customer funds from operational funds, it will need a rebuild before it can meet safeguarding requirements.
If a payment integration is chosen quickly, without documenting how data flows through it, it can turn into an undisclosed outsourcing relationship months down the line.
You shouldn’t add safeguarding, KYC/AML, and audit logging to the architecture at the last minute; they should be part of the design from the very beginning. That’s also where we earn our keep: we’ve built compliance-aware fintech architecture for other EMI and PI applicants, so we already know the shortcuts and dead ends.
Compliance teams write the narrative the FCA reads first. But reviewers ask technical follow-up questions. The FCA’s own applicant guidance points you toward its informational video series to help you strengthen your submission before it goes in.
Reviewers expect answers with the same confidence the business plan projects. This confidence usually comes from whoever understands the architecture, not necessarily whoever wrote the narrative.
The FCA’s EMI license review evaluates safeguarding, ICT risk management, and operational resilience directly, in addition to capital and governance.
The FCA’s supporting-material list requires a security policy, a security-related complaints policy, and evidence of the controls used to meet money laundering regulation obligations, as standard application content.
These controls follow the same ICT risk management practices used in PCI DSS, ISO 27001, and PSD2/PSD3-aligned architectures: access control, encryption standards, vulnerability management, patching cadence, and vendor risk scoring. The FCA expects each of these to be documented and demonstrably in place before submission.
Reviewers look for direct evidence, such as a penetration test report or a log of who holds admin access to the ledger. Having these ready when a reviewer asks will determine how quickly the application moves through review.
Since 2022, UK financial regulators have required in-scope firms to identify their “important business services,” set “impact tolerances” for each one. They also have to prove they can stay within those tolerances through a severe but plausible disruption: everything from a cyberattack to a third-party outage.
The three-year transition period for that framework closed at the end of March 2025. By the time you apply today, the FCA expects a working operational resilience programme.
As an EMI applicant, this means identifying which processes are critical to your business — payment processing, for example — and having a recovery plan you’ve actually tested for it.
Your engineering team keeps testing these plans on an ongoing basis, including after the application is approved and the platform is live.
Outsourcing arrangements appear explicitly on the list of application material the FCA requires. Under the FCA’s Handbook rules on outsourcing, if you hand work to a vendor, you keep full regulatory responsibility for it. Monitoring, due diligence, audit rights, and business continuity obligations don’t transfer along with the contract.
Weak outsourcing governance is one of the more common reasons a technically solid application still draws follow-up questions.
Beyond the paperwork, four pieces of fintech infrastructure determine whether your platform is ready to apply. The legal checklist doesn’t name these four items directly. Having them in place is what lets you prove the checklist items above when a reviewer asks.
Safeguarding architecture is under more regulatory pressure than almost any other part of an EMI’s technology stack. UK payment and e-money accounts grew roughly fivefold between 2017 and 2022, and firms that later failed had, on average, a 65% shortfall in the funds they owed customers.
That history is why the FCA introduced stricter safeguarding rules on 7 May 2026, requiring larger payment firms to run daily reconciliation checks, report monthly, and undergo annual audits.
A ledger you design with account and ledger separation from day one clears this bar structurally; one that commingles funds by default clears it only after a re-architecture.
Safeguarding claims and incident reports depend on the same evidence: records of who can access the ledger, and logs of what changed and who approved it. The FCA requires this audit trail. Your team also depends on it to run the business day to day.
The FCA asks you to document incident reporting procedures and business continuity arrangements as standard supporting material. Reviewers often find that these documents describe a process that doesn’t exist in the system. For example, a team writes an escalation path but never builds the monitoring that would trigger it. Or a team writes a business continuity plan that assumes a manual failover, but never tests it.
A regulated platform runs specific technical controls: access control that limits who can change ledger records, and a documented schedule for patching known vulnerabilities. The FCA checks whether these controls exist and function as intended.
PCI DSS and ISO 27001 require this same evidence.
When external engineering support is part of the stack, how you structure that relationship matters to regulators as much as whether it exists.
Because accountability for an outsourced function stays with the regulated firm, not the vendor, the FCA expects to see documented oversight: service levels you define, audit and access rights, and a named person internally who owns the relationship.
Third-party risk management covers two things: vendor quality, and how much a platform depends on any single vendor. If your core ledger and payment routing depend on one unaudited vendor, you’ve put them behind one point of failure. Reviewers respond better to platforms with documented fallback options and visibility into each dependency.
We keep architectural ownership and audit visibility in-house while extending your delivery capacity through embedded, dedicated fintech engineering teams. Our engineers work inside your sprints, codebase, and compliance reviews, producing an outsourcing arrangement that documents itself as you go.
Technical shortcomings that surface during FCA review fall into a small number of recurring patterns.
| Mistake | Why it delays approval |
|---|---|
| Building without compliance-aware architecture | Your ledger can’t structurally prove fund segregation, leaving safeguarding claims unevidenced |
| Postponing operational resilience until after launch | You haven’t mapped important business services or tested impact tolerances by submission time |
| Assuming reviewers only read the business plan | The FCA rejects incomplete supporting material without assessment, regardless of the plan’s quality |
| Leaving outsourcing arrangements undocumented | You haven’t disclosed vendors and cloud dependencies as the application requires |
| Writing a wind-down plan the systems can’t execute | The plan assumes manual processes your infrastructure has never actually run |
You can fix each of these before submission. If a reviewer flags one, resolving it takes more time and can delay the review.
Getting your fintech compliance infrastructure genuinely ready is a cross-functional exercise.
The FCA’s supporting-material checklist works best as a shared technical spec. Compliance defines the requirements. Engineering confirms what the architecture does. Product keeps both honest about what’s live versus what’s on the roadmap.
A regulator-ready ICT risk management framework connects every control to evidence a reviewer can check, such as an access log or a documented vendor assessment. If you build your framework around PCI DSS, ISO 27001, and PSD2/PSD3 SCA requirements, you get this structure automatically, because those standards already require the same kind of evidence.
If you build regulated fintech architecture only to pass the initial review, you’ll often rework it when you add a payment rail or enter a new market. Architecture you actually design for scale from the start absorbs that growth without a new compliance review each time.
The main thing that determines EMI license requirements is whether or not your systems can back up what your application says they can do.
The FCA looks at specific parts of your systems: how your ledger is structured, what your audit trail captures, how you handle incidents, and how you manage outsourcing. Each of these depends on a working system. Your compliance team writes these policies while your engineering team builds the systems that carry them out.
The review typically takes three months if you start six to nine months before you submit. It takes twelve months if you start six weeks before. A complex business with a complete application still gets the three-month timeline. What determines the timeline is whether you’ve done the preparation work in advance.
At Kindgeek, we build the ledger, audit trail, and incident response systems an EMI application needs, engineered to the FCA’s checklist. With experience working on payment platforms, neobanks, and card programs in the UK and EU, our engineers are well-versed in the architecture the FCA’s checklist expects.
We also audit existing systems against the same checklist. The audit produces a specific list of what needs to change, with enough detail for your engineering team to act on it directly.
We’ll map your existing systems against the FCA’s supporting-material checklist and tell you exactly what’s missing.
Contact usYes, you can build an EMI-ready platform with an outsourced engineering team, provided you keep a named internal owner accountable for the architecture, with real audit and access rights over what the engineering team builds. Embedding the team in your existing codebase and sprint cycle makes that oversight easier to maintain, because your internal owner sees each decision as it happens. When a reviewer asks about the architecture, that internal owner is the one who answers.
From 7 May 2026, new safeguarding rules require larger payment and e-money firms to run daily reconciliations, report monthly, and complete annual audits.
Yes, outsourcing arrangements appear explicitly in the FCA’s supporting-material list, and you keep full regulatory responsibility for any outsourced function regardless of who performs the work. Reviewers expect documented oversight, audit rights, and continuity planning around every vendor relationship.
Beyond capital and governance, the FCA’s EMI license requirements checklist calls for documented safeguarding measures, a security policy, incident reporting and business continuity procedures, and disclosure of any outsourcing arrangements. Each of these depends on a working system behind it. So, a reviewer will ask how your platform actually enforces its safeguarding measures.
The FCA’s standard timescale is three months from a complete application and twelve months for an incomplete one.
Take $49.995 as an example. This amount can be part of a discount, tax, or…
Fedwire, the US domestic wire system, settles more than $4.7 trillion in transfers a day,…
AI coding assistants speed up individual tasks. AI-native engineering changes how the entire delivery pipeline…
QA doesn't automatically scale the same way your product does. We learned this while building…
Whether the goal is a custom AI agent, a generative AI feature, or a full…
Fintechs report advanced AI adoption at 47%, compared with 30% among incumbent banks, according to…