Feb 24, 2026

EMI Unit Economics in Czechia (2026)

Business Fintech

Wallets, Cards & Payouts Under CNB Reality

EMI unit economics in Czechia (2026): CNB-proof margins for wallets, cards and payouts, mapping revenue and costs to AML, safeguarding, reconciliations and operational controls.

EMI unit economics look “simple” until you build them for Czechia and realize the Czech National Bank (ČNB/CNB) doesn’t care about your pitch deck. CNB cares whether your model is auditable, evidenced, and operationally controllable from Day 1: onboarding controls, AML monitoring, safeguarding operations, and governance that survives questions during licensing.

In the Czech Republic, EMIs operate under Act No. 370/2017 Coll., on the Payment System, and CNB runs the licensing and supervision process. CNB also makes it clear applications must be submitted electronically (data box).

This post gives you a practical unit economics framework that fits Czech EMI constraints (no fantasy margins, no “we’ll fix compliance later”).

The core EMI unit economics equation

Model in two layers:

Contribution margin per active user (monthly)

CM/user = (Card margin + Wallet fees + Payout margin + Subscriptions) − (Processing + Fraud/chargebacks + KYC/AML + Support + Platform + Safeguarding/Ops overhead allocation)

Contribution margin per transaction (sanity checks)

CM/card txn ≈ interchange earned − scheme/processor cost − expected fraud/chargeback loss
CM/payout ≈ fee − rail fee − screening/reject handling

Why CNB-proof? Because these lines map to what you must evidence and control: transaction processing, fraud handling, AML monitoring, reconciliations, and operational governance.

Cards in the EU (and therefore Czechia): interchange is capped, so plan like an adult

Interchange caps: the EU ceiling you cannot “growth hack”

For consumer cards in the EU, interchange is capped at 0.2% (debit) and 0.3% (credit) under the Interchange Fee Regulation (IFR). Czechia applies this because it’s EU law.

Card revenue lines (realistic)

  • Interchange revenue (issuer-side):Card spend × effective interchange rate × issuer share
  • Account plans/subscriptions (often the actual profit engine): premium tiers, extra cards, SME packages
  • Replacement/express delivery fees (careful: customer trust)
  • ATM/cash fees (careful: perception + limits + chargeback noise)

Card cost lines (where margin dies)

  • Scheme + processor fees (authorisation/clearing/settlement)
  • BIN sponsor / program manager fees (if you use them)
  • Card production + shipping + replacements
  • Disputes/chargebacks operations
  • Fraud losses (CNP and first-party fraud are the classics)
  • Support load (cards generate tickets)

Key margin driver: transactions per active card + spend per active card. Low spend users are frequently loss-making unless they pay a plan fee or you price the costly operations.

Wallets: stable base, thin margin, and Czech compliance workload is not optional

Wallets look “sticky”, but CNB expects you to show a controlled environment: onboarding, monitoring, safeguarding reconciliations, complaints, and governance.

Wallet revenue lines

  • Monthly account fees (consumer/SME)
  • Tiered subscriptions (limits, features, premium support)
  • One-off fees: extra statements, confirmations, urgent documents
  • “Fair use” pricing for heavy support demand

Wallet cost lines (Czech reality)

  • KYC onboarding + periodic refresh
  • AML monitoring + sanctions screening + investigations
  • Ledger/core platform costs (often per active + per txn)
  • Reconciliations + safeguarding ops (process + people)
  • Support (access, beneficiary changes, refunds, disputes)

Important nuance: “interest on balances” is basically a trap

The Electronic Money Directive includes a prohibition of interest (or benefits) linked to how long the customer holds e-money. That means you should not build a consumer proposition that looks like “earn interest by holding e-money” as a core driver.

(Yes, structures exist at the safeguarding layer, but marketing it wrong is how you get a compliance headache you didn’t order.)

Payouts (SEPA / Instant / SWIFT): cheap rails, expensive operations

In Czechia, payouts are where “we’ll just charge €0.20” turns into “why do we have 7 people handling rejects”.

Payout revenue lines

  • Per-transfer fee (domestic vs cross-border)
  • Bundled plans (“X transfers included”)
  • Instant transfer premium (SEPA Instant)
  • Business payouts: payroll batches, vendor payments, mass payouts

Payout cost lines

  • Rail fees (SEPA vs SEPA Instant vs SWIFT)
  • Screening false positives (manual review cost)
    Returns/rejects handling (usually underestimated)
  • Investigations + proof requests (banks love paperwork, you pay salaries)

Margin drivers that matter

  • Automation rate (% straight-through processing)
  • Return/reject rate (bad IBANs, compliance blocks)
  • Average payout size (fixed vs % vs hybrid pricing)

Fees & pricing: keep conversion high without subsidising heavy users

A robust Czech EMI pricing stack:

  • Low-fee entry → monetize via subscriptions and paid “expensive” operations
  • Tiered plans → align price with cost-to-serve (support, limits, Instant rails)
  • Usage-based fees → for costly rails (Instant, SWIFT, complex corridors)
  • Business plans → priced on workload (batch payouts, users, integrations, SLA)

Rule of thumb: if you rely on interchange alone, pricing will be forced later. Usually by reality, not by strategy.

Regulatory governance as a unit economics constraint (Czechia-specific emphasis)

CNB licensing is not just “forms”. You submit electronically (data box), and your ability to answer Q&A quickly depends on whether your model is backed by evidence and clear operational ownership.

Also, CNB explicitly lists the regulatory landscape for payments, including Act No. 370/2017 Coll. and directly applicable EU regulations such as DORA (Regulation (EU) 2022/2554), which pushes ICT governance expectations into “baseline hygiene”.

Translate that into modelling:

  • more controls + more oversight = real Opex
  • vendor sprawl = fixed cost + more failure modes
  • poor automation = exploding headcount per volume

Quick illustrative example (monthly, simplified, no fantasies)

Assume:

  • 10,000 active users
  • €700 card spend/user/month → €7.0m total spend
  • EU interchange caps apply
  • 20% users on a €6 premium plan
  • payouts: 1.2 per user/month, net margin €0.25 per payout (after rail fees + handling), illustrative

Revenue (illustrative):

  • Interchange: modest because capped
  • Subscriptions: 2,000 × €6 = €12,000
  • Payout margin: 10,000 × 1.2 × €0.25 = €3,000

Then reality hits: processing, scheme fees, KYC/AML, disputes, fraud, support, platform, safeguarding ops.

Takeaway: in Czechia (and the EU), a viable EMI unit economics model is usually built on pricing discipline + automation + controlled operations, not on interchange dreams.

The modelling template (what CNB-friendly spreadsheets include)

Inputs

  • Active users, activation rate, churn
  • Card spend/user, tx count/user, debit/credit mix
  • Subscription attach rate + ARPU by tier
  • Payout count/user, rail mix, return rate
  • KYC cost per onboard, AML cost per active, tickets/user
  • Scheme/processing cost per card txn, dispute rate, fraud rate
  • Safeguarding + reconciliation workload (people-hours per 1k tx)

Outputs

  • CM/user, CM/txn by product line
  • CAC payback (months) and LTV
  • Sensitivity: spend, plan attach rate, fraud rate, return rate, automation rate

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

 

START EMI PRE-CHECK

ORDER

FAQ:

Can an EMI in Czechia rely on interchange as the main revenue line?

Not realistically. In the EU (including Czechia), consumer card interchange is capped (0.2% debit / 0.3% credit), so interchange alone rarely covers the full cost stack: processing + scheme fees + disputes + fraud + support + compliance. Treat interchange as a supporting line, not your core margin. Your sustainable margin usually comes from subscriptions, business plans, and pricing of costly operations (instant rails, investigations, heavy support).

What does the CNB actually expect to see behind “unit economics” in an EMI application?

CNB won’t call it “unit economics”, but they will effectively test the same thing: whether your pricing and cost assumptions are evidenced and your operating model is controllable. That usually means:

  • clear fee schedule and pricing logic (including edge cases like rejects/returns),
  • realistic vendor cost inputs (ledger, KYC, screening, processor, card program),
  • staffing model linked to volumes (alerts, disputes, support tickets),
  • safeguarding and reconciliation workload mapped to processes and owners,
  • governance and outsourcing oversight that works in practice.

 

Is “free account + free transfers” a problem for a Czech EMI model?

It’s not illegal, it’s just usually economically fake unless you’re subsidising with something else (and you’ve modelled that subsidy honestly). “Free” usually shifts costs into:

  • manual review (AML, sanctions, investigations),
  • returns/reject handling,
  • support tickets,
  • vendor per-txn fees.

CNB’s concern is simple: if your model bleeds at scale, you will cut corners later, and supervisors hate surprises.

How should we price payouts (SEPA vs SEPA Instant) without killing conversion?

Use a tiered structure that matches cost-to-serve:

  • include a reasonable number of standard SEPA transfers in bundles,
  • charge a clear premium for SEPA Instant,
  • add “fair use” protections for heavy users (or move them to business plans),

keep rejects/returns handling priced or at least limited, because it eats staff time fast.
Also model return rates. People love typing bad IBANs. It’s a hobby.

What cost bucket is most underestimated by first-time Czech EMI founders?

Operations tied to compliance and exceptions:

  • false positives from screening,
  • investigations and proof requests,
  • dispute/chargeback ops,
  • manual reviews for edge cases,

safeguarding and reconciliation workload.
Founders model the “happy path” and then act shocked when reality shows up.

Does Czech law allow an EMI to pay interest on customer balances?

As a rule, e-money regulations prohibit paying interest (or benefits) linked to how long e-money is held. Even where structures exist at the safeguarding layer, you generally should not build your consumer value proposition on “earn interest by holding e-money” without very careful legal structuring and wording. If it looks like a deposit product in marketing, it will be treated like a deposit product in scrutiny.

What is the fastest way to improve margins without raising prices?

Reduce exception handling and manual work:

  • increase straight-through processing,
  • improve onboarding data quality,
  • reduce return rate (beneficiary validation, IBAN checks),
  • tighten fraud prevention early (before chargebacks scale),
  • consolidate vendors (less “vendor sprawl”, fewer fixed costs and incidents).

In 2026, “margin improvement” is mostly “less chaos per transaction”.

How do we present unit economics in a way that survives CNB Q&A?

Show it in a structure CNB can interrogate:

  • per-user margin (monthly) + per-transaction margin (by product line),
  • clear assumptions table (inputs) + evidence (contracts, quotes, benchmarks),
  • sensitivity cases (fraud up, returns up, slower growth, higher staffing),
  • mapping from volumes → alerts/disputes/tickets → headcount → Opex,

reconciliation/safeguarding workflow and ownership.
CNB doesn’t need your hype. They need your model to be auditable and internally consistent.