Most fintech founders approach an EMI or PI licence application the way they'd approach any other product launch: define the requirements, build to spec, submit, done. It's a reasonable instinct, and it's the wrong one. A licence application isn't a product a regulator approves — it's a case a regulator has to be persuaded of, repeatedly, over months, often after the founder thought the case was already closed.
The applications that stall or fail rarely fail on ambition. They fail on a handful of recurring, avoidable mistakes — almost always in the same three areas: own funds, safeguarding, and governance.
Own funds: treated as a number, when it's actually a narrative
Founders tend to approach own-funds requirements as a compliance threshold to clear — calculate the minimum, hold slightly more, move on. Regulators read it differently. They want to see that the applicant understands why the requirement exists and has genuinely planned around it, not backed into a number that happens to satisfy a formula.
Common mistakes:
- Treating the regulatory minimum as the target, not the floor. A number that exactly meets the threshold, with no buffer for early-stage losses, tells a regulator the applicant hasn't modelled its own downside case.
- Projections that don't connect to the own-funds position. If the financial projections show 18 months of losses before breakeven, but the own-funds calculation only covers 6, that gap is the first thing a competent reviewer will flag — and it undermines confidence in every other number in the application.
- Static thinking about a dynamic requirement. Own funds under most frameworks scale with payment volume and business model (fixed minimum, or a percentage of relevant indicators, whichever is higher). Founders often model the day-one number and never show how it evolves as volume grows — which is exactly the scenario a regulator wants modelled.
- Underestimating what "eligible" own funds actually means. Not every form of capital qualifies. Shareholder loans, certain intercompany balances, or assets with limited liquidity often don't count the way founders assume they will, and discovering that mid-review costs real time.
What regulators actually want to see is a capital position that's been stress-tested against the business's own realistic trajectory — not the minimum the rulebook technically allows.
Safeguarding: treated as a bank account, when it's actually a system
This is where the gap between founder assumptions and regulatory expectations is widest. Founders often think of safeguarding as "open a separate account and keep customer money there." That's the mechanism, not the requirement. Regulators are looking for a control environment, not a bank statement.
Where this goes wrong most often:
- No real-time reconciliation. Safeguarded funds have to be reconciled against customer liabilities on a defined, demonstrable cadence — not checked when someone remembers to. A founder who can't produce evidence of routine, timestamped reconciliation is describing a policy, not a practice.
- Ambiguity about which funds are actually in scope. Founder gets the mechanics right for the obvious case (customer deposits) and misses edge cases — funds in transit, funds held with third-party payment partners, or funds sitting in an intermediary account during settlement. Regulators probe exactly these edges.
- Safeguarding accounts that aren't structured correctly. The account has to be legally distinguishable from the firm's own operating funds, at an institution the firm has properly documented, with acknowledgement letters in place — not just labelled "safeguarding" internally.
- No stress scenario for insolvency. The point of safeguarding is that customer funds are protected if the firm fails. Founders often can't clearly articulate how the mechanism actually functions in that scenario — which is, from the regulator's perspective, the entire point of the exercise.
Safeguarding, done properly, is an operational discipline with daily evidence behind it — not a one-time account-opening task.
Governance: treated as an org chart, when it's actually accountability
This is the area founders most consistently underestimate, largely because it's the least technical of the three and feels the most like paperwork. It isn't. Regulators are assessing whether the people in the room can actually run a regulated business, and whether the structure around them would catch a problem before it became serious.
Recurring issues:
- Governance structures that exist on paper but not in practice. A board, risk committee, and compliance function that look complete in the application but have never actually met, or exist mostly to satisfy the org chart, tend to unravel under questioning.
- Key function holders without the substance to match the title. Naming a Head of Compliance or MLRO is not the same as having someone with the experience, authority, and time allocation to genuinely perform that role. Regulators probe competence and availability, not just job titles.
- Founders holding too much unchecked authority. A structure where the founder-CEO also effectively controls risk, compliance, and finance decisions — even informally — is a governance red flag, regardless of what the org chart says.
- Policies that are templated rather than tailored. Risk, AML, and outsourcing policies copied from a generic template, without being adapted to the firm's actual business model, geography, and customer base, are usually obvious to an experienced reviewer within a few pages.
- No real evidence of independent challenge. Regulators want to see that decisions get scrutinised by someone other than the person making them — an independent non-executive, a genuinely empowered risk function, minutes that show actual debate rather than rubber-stamping.
The underlying test isn't "does this company have governance documents." It's "if something goes wrong, is there a structure in place that would catch it, escalate it, and respond — before it becomes a customer harm or a regulatory breach."
The pattern underneath all three
Own funds, safeguarding, and governance look like three separate workstreams, but the mistakes founders make in each come from the same root cause: building for the application instead of building for the business the application describes. A number that clears the threshold, an account that's technically labelled correctly, a board that exists on paper — all of these can get a submission across the line on the surface, and all of them tend to surface as real operational problems within the first year of actually operating under licence.
The founders who navigate this well tend to do one thing differently: they build the own-funds model, the safeguarding process, and the governance structure as if the licence were already granted and they had to run the business under it tomorrow — not as artefacts designed to satisfy a reviewer.
The bottom line
A licence application isn't won by answering every question the regulator asks. It's won by demonstrating, across own funds, safeguarding, and governance, that the applicant understands the risks well enough to have already built the controls a regulator would otherwise have to insist on. That distinction — between compliance built to pass review and compliance built to run a business — is what separates applications that move smoothly through the process from those that stall, get queried repeatedly, or fail outright.