What Your CTO Should Know Before Your EMI License Application

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.

EMI License Requirements Are Fundamentally an Engineering Responsibility

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. 

What the FCA Reviews During an EMI Application

The FCA’s supporting-material checklist for authorised EMI (AEMI) applicants asks for detail on:

• Your programme of operations and business plan, including financial projections
• Measures to safeguard e-money holders’ and payment users’ funds
• Governance arrangements, internal controls, risk management procedures, and a wind-down plan
• Procedures for incident reporting, managing sensitive payment data, and business continuity
• A security policy and a security-related customer complaints policy
• Your outsourcing arrangements, if applicable

If any of this is missing, the regulator says plainly that it will reject the submission without assessing it at all.

Why Technical Architecture Shapes Your Approval Timeline

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.

The Hidden Technical Risks That Delay Applications

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 and Where Technical Readiness Starts

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.

Why Most EMI Readiness Problems Start Before Development

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.

How Early Infrastructure Decisions Shape Compliance

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.

The CTO’s Seat at the Table Before Submission

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.

What the FCA Expects From an EMI Applicant’s Technology, Security, and Operational Resilience

The FCA’s EMI license review evaluates safeguarding, ICT risk management, and operational resilience directly, in addition to capital and governance.

ICT and Security Framework Expectations

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.

Operational Resilience Requirements for UK EMI Applicants

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 Governance as a Regulatory Risk

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.

The Core Fintech Infrastructure an EMI Application Requires

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 and Ledger Separation

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.

Audit Trails, Access Control, and Monitoring

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.

Incident Response, Disaster Recovery, and Business Continuity

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.

ICT and Security Controls

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.

Why Outsourcing Structure Matters for Your EMI Application

When external engineering support is part of the stack, how you structure that relationship matters to regulators as much as whether it exists.

Regulator Expectations for External Engineering Partners

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. 

Vendor Dependency and Third-Party Risk Management

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.

How to Structure Fintech Engineering Outsourcing Correctly

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.

Common Technical Mistakes That Delay EMI Submissions

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.

How to Prepare Your Fintech Compliance Infrastructure Before You Apply

Getting your fintech compliance infrastructure genuinely ready is a cross-functional exercise.

Aligning Engineering, Compliance, and Product Teams Early

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.

Building a Regulator-Ready ICT Risk Management Framework

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.

Designing Regulated Fintech Architecture That Survives Post-License Growth

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.

A 6–9 Month Technical Roadmap Before Submission

1. Months 9–6: You map the FCA’s supporting-material checklist against your actual architecture, and design or confirm ledger segregation, KYC/AML data flows, and an ICT risk register.
2. Months 6–3: You build the audit trail and monitoring that safeguarding and incident-reporting claims depend on, formalise the outsourcing register, and align the wind-down plan with what your systems can do.
3. Months 3–0: You run operational resilience scenario tests against your impact tolerances, finalise the security policy, and review the FCA’s own guidance and video series before submitting through Connect.

Conclusion: Building the Technical Foundation Before You Apply

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.