Building a credible 3-year financial model for an EMI

3-year EMI financial model (2026): traceable assumptions from volumes to revenue, costs, own funds, liquidity and safeguarding, with stress cases, burn rate and break-even.

A “credible” EMI model is not a pretty spreadsheet. It’s a traceable story where volumes → balances → revenue → costs → capital/own funds → liquidity and safeguarding operations all reconcile, and where downside cases don’t magically disappear.

Supervisors across the EU consistently point to one core delay driver in authorisations: application quality and how quickly gaps are addressed—and the business plan/financial projections are a major part of that. Recent supervisory work at EU level continues to highlight differences in how applications are assessed, but also reinforces the same practical message: governance, financial projections, safeguarding and operational readiness are areas where weak submissions slow things down.

Czech Republic (ČNB) reality check (why this topic matters in CZ, not just “EU theory”)

In the Czech Republic, the competent authority for EMI authorisation is the Czech National Bank (Česká národní banka – ČNB). The ČNB publishes the licensing/approval framework and application forms for payment service providers and electronic money institutions under the Czech Payment System Act (Act No. 370/2017 Coll.), with detailed requirements governed by implementing decrees and annexes. Applications are submitted electronically (data box), and ČNB explicitly recommends using its forms and annex structure.

This is exactly where a “traceable model” matters: the model is not a standalone finance exercise—it is a core annex-type deliverable that must reconcile with your safeguarding concept, operating model, outsourcing, governance and risk controls.

Below is a practical build method you can reuse.

1) What your 3-year EMI model must prove

Your model should answer these questions without hand-waving:

Can you operate safely at launch and at scale? (people, controls, ICT resilience, outsourcing oversight)

Do you meet own funds at all times? (minimum capital + 2% of average outstanding e-money, plus “hybrid” add-ons where relevant)

Is liquidity realistic? (cash runway, settlement timing, refunds/chargebacks, safeguarding mechanics)

When do you break even—and under what assumptions?

How bad is the downside? (stress cases + management actions)

Czech-specific lens: ČNB expects your submission to be internally consistent across annexes and narratives. Your “financial model” should not contradict the money-flow diagram, safeguarding method, or outsourcing plan—because the licensing process is designed around a set of interlinked documents and annexes. (cnb.cz)

2) Start with a driver tree (don’t start with a P&L)

Build the model from operating drivers, then let the statements populate.

Acquisition & activity drivers

New users / month, activation rate, churn
KYC pass rate and rework rate
Active users, txns per active, avg transaction size
Product mix: wallet usage, cards penetration, FX penetration, payout penetration

Payments & balances (the EMI core)

Outstanding e-money balance (daily/average monthly)
Top-up/funding inflows, spend outflows, payout outflows
Refunds, reversals, chargebacks timing
Seasonality and concentration (top customers)

Why this matters: own funds for EMIs include minimum initial capital (€350k) and at least 2% of the average outstanding e-money. If you don’t model balances properly, your capital story is not assessable.

Czech practice note: when you present balances, tie them to your safeguarding mechanics and reconciliation cadence. ČNB’s application approach is “annex-driven”: you will be expected to show not only the numbers, but also how operations (segregation/safeguarding, reconciliations, reporting) support those numbers.

3) Revenue build: keep it “net of reality”

Wallet revenue (usually thin)

Monthly plans, account fees, premium features
Business plans (users/seats, API access, payout bundles)

Cards revenue (EU constraint)

Consumer interchange is capped (commonly referenced caps: 0.2% debit / 0.3% credit). So model:

Interchange (net to you) after scheme/processor/programme share
Subscription tiers tied to cards (often the real margin)
ATM/cash fees (if used)

FX revenue (often the margin engine)

FX markup minus liquidity costs and refund FX leakage
Separate weekday vs weekend/after-hours pricing if you use it

Payout revenue

Fee per transfer by rail (SEPA / instant / SWIFT), plus rejection/return handling charges where applicable

Credibility tip: Build revenue as net margin, not “headline fee”. If you charge 60 bps but pay 35 bps all-in, model 25 bps.

Czech/EU regulator reality: “net of reality” matters because supervisors will typically challenge optimistic take rates and ignore “gross fee marketing” if they see processor/programme-manager economics not evidenced by contracts or draft term sheets. That’s why your evidence pack (Section 9) is not optional.

4) Cost stack: model fixed vs variable correctly

Variable costs (scale with transactions/users)

Card processing/scheme fees, tokenisation, authorisation fees
Payout rail fees
KYC checks (per onboard + periodic refresh)
AML monitoring cost per active (alerts → investigations)
Fraud losses + chargeback fees + disputes ops (expected loss rate)

Semi-fixed costs (step functions)

Compliance, MLRO, risk, internal controls
Finance, safeguarding operations, reconciliations
Support (tickets scale non-linearly with cards/chargebacks)
Vendor base fees (core ledger, card processor, screening tools)

“2026 reality” cost add-on: ICT resilience

DORA applies from 17 January 2025, and by 2026 many EMIs treat DORA-style ICT risk/third-party oversight as baseline programme cost.

Czech practice note: when you budget ICT resilience, link it to your outsourcing oversight and third-party governance, because those are licensing review “hot zones” across EU authorities, and ČNB explicitly routes applicants to the broader EU guideline framework in its licensing materials.

5) Own funds & capital: make it an explicit schedule

Add a dedicated Own Funds Schedule that pulls from your balances and volumes:

Minimum initial capital: €350,000
Own funds for e-money issuance: ≥ 2% of average outstanding e-money (Directive 2009/110/EC Method D)
If you’re a “hybrid” (payment services not linked to issuance), include additional methods (A/B/C logic) and show the combined requirement (this approach is embedded in the EMD/PSD logic and widely used in supervisory practice).

What to show: monthly required own funds vs available own funds, with a management buffer (e.g., 20–30%).

Czech-specific clarity: your own-funds schedule should reconcile with the Czech submission package under the Payment System Act framework (forms + annexes). ČNB’s published process is built around structured annexes and cross-references; a capital schedule that cannot be traced to balances and services offered will raise questions.

6) Burn rate & runway: define it the way investors and supervisors do

Create a Cash Waterfall (monthly):

Ending cash = Beginning cash + net operating cashflow ± working capital timing − capex − one-off licensing costs

Track 3 burn metrics:

Gross burn (operating costs − operating revenue)
Net burn (cash outflow after revenues collected)
Runway months = cash / net burn

Also add a “minimum cash” threshold linked to operational safety (e.g., 6 months of fixed costs + expected tail losses).

Czech/EU licensing reality: regulators care less about “valuation story” and more about operational continuity—i.e., that you do not end up underfunded while still holding customer funds and running safeguarding operations.

7) Break-even: measure two ways (or you’ll fool yourself)

A) Accounting break-even (EBITDA ≥ 0)
Good for board reporting.

B) Contribution break-even (unit economics)
Break-even active users = Fixed cost / Contribution margin per active user

Where contribution margin per active user is built from:

net interchange margin + net FX margin + net payout margin + subscription fees
minus
variable processing + fraud loss + KYC/AML + variable support

This is where you see if you’re “subsidising growth”.

Practical licensing angle: contribution break-even is not just a startup KPI—used correctly, it also supports your “realistic business plan” narrative under supervisory scrutiny.

8) Stress cases supervisors actually respect (minimum set you should include)

In practice, supervisors often request a simple resilience check of the business plan using revenue shocks (e.g., −40% and −60%). The key is that the stress is not just a “top-line haircut”: it should be explainable via the core drivers (volumes, margin, mix) and lead to clear outputs on liquidity, own funds, and safeguarding operations.

Below is a minimum set of stresses that is easy to embed in the model.

Stress A — Revenue down 40% (Revenue −40%)

What changes (driver-linked):

lower transaction volumes / fewer active users (volume shock) and/or
weaker net margin (compression of FX / interchange margin, discounting) and/or
adverse product mix (less FX/cards, more low-margin flows)

What to show as outcomes:

break-even shift (both EBITDA break-even and contribution break-even)
burn rate and runway impact (cash waterfall)
impact on own funds requirement and headroom (required vs available, including a buffer)
impact on safeguarding: settlement timing, refunds, chargebacks, and reconciliation/ops workload

Management actions (must be explicit):

hiring/marketing freeze, delay non-critical launches, cut discretionary spend
reprice plans/tiers and refocus on higher-margin products
if relevant, documented shareholder support/committed funding (only if you can evidence it)

Stress B — Revenue down 60% (Revenue −60%)

This is a “severe but plausible” scenario: a check that the business does not become unsafe even under a major deviation from plan.

What changes (driver-linked):

deeper volume decline and/or stronger margin compression
higher churn / lower activation
stronger price pressure and lower take rate

What to show as outcomes:

runway in months and whether you breach the “minimum cash” safety threshold
ability to maintain own funds above the requirement on a monthly basis (including a buffer)
safeguarding robustness under worse settlement timing and refund dynamics
operational capability: whether your control environment holds (reconciliations, monitoring, reporting)

Management actions:

reduce burn to “survival mode”: rebase budget, pause non-core initiatives
reprice and introduce fair-use caps
renegotiate vendor contracts / shift costs from fixed to variable where possible

Stress C — Operational EMI stress: fraud/chargebacks spike + slower refunds/settlement

Even alongside revenue shocks, supervisors typically expect you to reflect core EMI operational risk: loss/spike scenarios and “money timing” deterioration.

What changes:

higher fraud loss rate and chargeback/dispute fees
higher disputes workload → pressure on ops/support/compliance
worse settlement timing and refund delays → cash pressure and safeguarding ops strain

What to show as outcomes:

impact on the cash waterfall and any need for additional liquidity
impact on safeguarding operations workload and reconciliation cadence/volumes
impact on own funds headroom (if average e-money balances or volumes change)

Management actions:

tighten risk policies, reduce high-risk segments, add step-up verification
strengthen monitoring/controls and partner SLAs
revisit limits and dispute/refund rules

Minimum outputs for each stress (consistent reporting format)

For each scenario (A/B/C), the model should show at minimum:

Runway impact — months of cash under stress, before and after management actions
Own funds headroom impact — required vs available own funds monthly, plus buffer
Safeguarding impact — settlement/refund timing effects, ticket volumes, reconciliations, returns/chargebacks

9) A simple “evidence pack” that makes your model credible

Attach (or be ready to provide) the docs that make assumptions real:

Pricing sheets and contract drafts (processors, programme manager, KYC/screening vendors)
Headcount plan with role ownership (compliance, safeguarding, ICT risk)
Money-flow diagrams and reconciliation cadence
Policies/processes that show you can operate under a regulated standard (EBA’s authorisation guidelines are the reference point many NCAs align to).

Czech Republic (ČNB) add-on: submission format and “annex discipline”

Because ČNB’s licensing process is structured around forms and mandatory annexes under Czech law (Payment System Act and implementing decrees), treat your evidence pack as “ready-to-file” material—not as optional background. ČNB’s public guidance emphasises the use of its forms, and that the relevant requirements sit within the Act/Decrees framework; applications are filed electronically.

Practically, this means: keep all key assumptions tied to documents (draft contracts, pricing sheets, vendor proposals) and ensure your model outputs are consistent with safeguarding flows and operational procedures described elsewhere in the application.

10) Watch the regulatory horizon (don’t over-promise stability)

The EU has proposed PSD2 revisions (PSD3 + PSR) that would also cover electronic money services (previously split between PSD2 and EMD2). This can affect medium-term planning assumptions, especially around supervision and harmonisation.

We can help you build a regulator-ready EMI financial model

If you are preparing an EMI licence application in the Czech Republic, AMS Europe can help you build a traceable 3-year financial model aligned with ČNB annex expectations and EU supervisory logic—covering drivers → balances → revenue/costs → own funds schedules → liquidity/safeguarding mechanics → stress cases and management actions. We also help package the supporting “evidence pack” (pricing economics, vendor assumptions, headcount plan, money-flow diagrams and reconciliation cadence) so the model is defendable in Q&A with the regulator. balances, own-funds logic, liquidity assumptions, safeguarding operations, and IT/outsourcing descriptions stay consistent—so the submission is defendable during ČNB Q&A.

GET A ČNB-READY GAP CHECK AND A CLEAR FIX LIST

START EMI PRE-CHECK

ORDER

The most common issue is lack of consistency across the application package. The financial model often does not match the money-flow diagram, the safeguarding approach, the vendor economics (processors, programme manager, KYC/AML tools), or the operational plan. For ČNB, that looks like a fragmented submission where documents contradict each other. This typically triggers follow-up questions and delays. The fix is a “traceable” model: key numbers should be supported by documents (draft contracts, pricing, vendor proposals) and clearly linked to operations and controls.

For an EMI authorisation, financial projections are usually more than a P&L. Supervisors typically expect a full set of linked schedules: e-money balance forecasts, own funds calculations, liquidity and cash runway projections, and a clear operational view of safeguarding (including settlement timing, refunds, disputes, and reconciliation workload). If you submit only a P&L without balance logic and safeguarding mechanics, it becomes difficult for the regulator to assess resilience and operational safety.

EU and Czech supervisors usually trust evidenced unit economics, not marketing-level “headline fees.” A practical approach is to model revenue as net margin and show the true cost stack behind each stream (cards, FX, payouts), supported by processor/programme-manager term sheets and vendor proposals where possible. The more “evidence-based” the economics (contracts, pricing sheets, documented fee reveals), the lower the risk that your revenue projections are viewed as overly optimistic.

A simple and regulator-friendly minimum set often includes two revenue shock levels (for example, revenue down 40% and revenue down 60%). The point is not the percentage itself, but what you demonstrate under stress: (1) cash runway impact, (2) own funds headroom resilience, and (3) whether safeguarding operations remain stable (settlement timing, refunds, chargebacks, reconciliations). Two levels help show the business remains safe under both a “bad year” scenario and a severe-but-plausible scenario, with clear management actions.

Timing depends on whether the company already has core inputs ready: pricing and fee logic, expected volumes and product mix, draft agreements with key providers (banking/IBAN, cards, FX liquidity, payouts, KYC/AML), and a baseline safeguarding and operations description. If these inputs are available early, the model can be built much faster and with stronger credibility—because it is based on documents, not assumptions. In practice, it’s most efficient to build the model together with the evidence pack and annex logic to reduce ČNB Q&A cycles and improve application quality.

Building a credible 3-year financial model for an EMI (assumptions, stress cases, burn rate, break-even)

Czech Republic (ČNB) reality check (why this topic matters in CZ, not just “EU theory”)

1) What your 3-year EMI model must prove