«Убедительная» модель EMI это не красивый Excel. Это проверяемая, трассируемая история, где объёмы → остатки → выручка → расходы → капитал/собственные средства → ликвидность и safeguarding-операции (защита клиентских средств) сходятся между собой, а негативные сценарии не исчезают магическим образом.
Надзорные органы по всей ЕС стабильно указывают на один ключевой фактор задержек в авторизациях: качество заявки и скорость закрытия пробелов. Бизнес-план и финансовые прогнозы составляют значительную часть этого. Последняя надзорная работа на уровне ЕС продолжает показывать различия в том, как заявки оцениваются, но одновременно усиливает одно и то же практическое сообщение: governance, финансовые прогнозы, safeguarding и операционная готовность это зоны, где слабые поданные материалы сильно замедляют процесс.
Чехия (ČNB): проверка реальностью (почему это важно именно в CZ, а не только «теория ЕС»)
В Чехии компетентным органом по авторизации EMI является Чешский национальный банк (Česká národní banka – ČNB). ČNB публикует рамки лицензирования/одобрения и формы заявок для платёжных провайдеров и институтов электронных денег в рамках чешского Закона о платёжной системе (Act No. 370/2017 Coll.), а детальные требования закреплены в подзаконных актах и приложениях. Заявки подаются электронно (datová schránka), и ČNB прямо рекомендует использовать их формы и структуру приложений.
Именно здесь критичен «трассируемый» модельный подход: модель это не отдельное финансовое упражнение. Это ключевой “annex-type” документ, который обязан сходиться с вашим safeguarding-концептом, операционной моделью, аутсорсингом, governance и контролями риска.
Ниже практический метод сборки, который можно повторять.
1) Что должна доказать ваша 3-летняя модель EMI
Модель должна отвечать на вопросы без «воды»:
- Можете ли вы безопасно работать на старте и при масштабе? (люди, контроли, ICT-устойчивость, надзор аутсорсинга)
- Выполняете ли требования по own funds постоянно? (минимальный капитал + 2% средних непогашенных e-money, плюс “hybrid” надбавки где применимо)
- Реалистична ли ликвидность? (денежный runway, сроки клиринга/settlement, возвраты/chargeback, механика safeguarding)
- Когда вы выходите в ноль и при каких допущениях?
- Насколько плох может быть downside? (стрессы + управленческие действия)
Чешский фокус: ČNB ожидает внутреннюю согласованность пакета по всем приложениям и текстовым разделам. Ваш «финансовый модель» не должен противоречить money-flow диаграмме, методу safeguarding или плану аутсорсинга, потому что лицензирование построено как набор взаимосвязанных документов и приложений. (cnb.cz)
2) Начните с дерева драйверов (не с P&L)
Собирайте модель от операционных драйверов и только потом «наполняйте» отчётность.
Драйверы привлечения и активности
- Новые пользователи/месяц, доля активации, churn
- Проходимость KYC и доля доработок (rework)
- Активные пользователи, транзакций на активного, средний чек
- Микс продукта: использование кошелька, проникновение карт, проникновение FX, проникновение payout
Платежи и остатки (ядро EMI)
- Остаток непогашенных e-money (дневной/среднемесячный)
- Inflow пополнений/фандинга, outflow трат, outflow выплат
- Тайминг возвратов, reversals, chargeback
- Сезонность и концентрация (топ-клиенты)
Почему это важно: own funds для EMI включают минимальный начальный капитал (€350k) и минимум 2% от среднего outstanding e-money. Если вы плохо моделируете остатки, вашу «капитальную» часть невозможно нормально оценить.
Практика в Чехии: показывая остатки, привяжите их к механике safeguarding и частоте/каденции сверок (reconciliations). Подход ČNB “annex-driven”: от вас ждут не только цифры, но и объяснение, как операционные процессы (segregation/safeguarding, сверки, отчётность) эти цифры обеспечивают.
3) Выручка: держите её «net of reality»
Выручка кошелька (обычно тонкая)
- Месячные планы, fees, премиум-функции
- B2B-планы (пользователи/места, API, наборы выплат)
Выручка по картам (ограничение ЕС)
Interchange для потребителей ограничен (часто приводят: 0,2% debit / 0,3% credit). Поэтому моделируйте:
- Interchange (чистый для вас) после долей scheme/processor/programme manager
- Подписочные уровни, привязанные к картам (часто реальная маржа)
- ATM/cash fees (если используете)
FX-выручка (часто главный двигатель маржи)
- FX markup минус стоимость ликвидности и FX-потери на возвратах
- Разделяйте weekday vs weekend/after-hours pricing, если это заложено
Выручка выплат (payout)
- Комиссия за перевод по rail’у (SEPA/instant/SWIFT) + сборы за обработку reject/return где применимо
Совет по достоверности: стройте выручку как чистую маржу, а не «витринную комиссию». Если вы берёте 60 bps, но платите 35 bps all-in, в модели должно быть 25 bps.
Реальность CZ/EU: надзор обычно спорит с чрезмерно оптимистичными take rate и игнорирует «маркетинговый gross fee», если экономика процессинга/programme manager не подтверждена контрактами или хотя бы черновиками term sheet. Поэтому evidence pack (раздел 9) это не опция.
4) Стек затрат: корректно разделите fixed vs variable
Переменные затраты (масштабируются с пользователями/транзакциями)
- Card processing/scheme fees, токенизация, авторизационные комиссии
- Комиссии платёжных rail’ов для выплат
- KYC-проверки (на онбординг + периодическое обновление)
- Стоимость AML-мониторинга на активного (алерты → расследования)
- Потери от фрода + комиссии chargeback + операционные расходы по спорам (expected loss rate)
Полу-фиксированные (ступенчатые)
- Compliance, MLRO, risk, внутренние контроли
- Финансы, safeguarding-операции, сверки
- Поддержка (тикеты растут нелинейно, особенно с картами/chargeback)
- Базовые vendor fees (core ledger, card processor, screening tools)
«Реальность 2026»: ICT resilience
DORA действует с 17 января 2025 года, и к 2026 многие EMI закладывают DORA-уровень ICT risk и надзор третьих сторон как базовый программный cost.
Практика в Чехии: бюджет по ICT resilience увязывайте с oversight аутсорсинга и third-party governance, потому что это “hot zones” в проверке лицензий по ЕС, и ČNB в материалах явно ведёт заявителей к широкой EU guideline базе.
5) Own funds и капитал: сделайте отдельный график/расписание
Добавьте отдельный Own Funds Schedule, который подтягивается из остатков и объёмов:
- Минимальный начальный капитал: €350,000
- Own funds для эмиссии e-money: ≥ 2% среднего outstanding e-money (Directive 2009/110/EC, Method D)
- Если вы “hybrid” (платёжные услуги не связанные с эмиссией), добавьте дополнительные методы (логика A/B/C) и покажите комбинированное требование (это встроено в логику EMD/PSD и широко применяется в надзоре)
Что показывать: ежемесячно required own funds vs available own funds + управленческий буфер (например, 20–30%).
Чешская ясность: ваш график own funds должен сходиться с чешским пакетом подачи по закону о платёжной системе (формы + приложения). Процесс ČNB строится на структурированных приложениях и перекрёстных ссылках. Расписание капитала, которое нельзя трассировать к остаткам и перечню услуг, почти гарантированно вызовет вопросы.
6) Burn rate и runway: определяйте как инвесторы и надзор
Соберите Cash Waterfall (помесячно):
Ending cash = Beginning cash + net operating cashflow ± тайминг оборотки − capex − разовые лиценз. расходы
Отслеживайте 3 метрики burn:
- Gross burn (операционные расходы − операционная выручка)
- Net burn (денежный отток после учёта собранной выручки)
- Runway (мес.) = cash / net burn
Добавьте minimum cash threshold, привязанный к операционной безопасности (например, 6 месяцев фиксированных затрат + ожидаемые tail losses).
Реальность лицензирования CZ/EU: регулятору важнее не «история оценки компании», а непрерывность и безопасность операции, то есть чтобы вы не оказались недофинансированы, продолжая держать клиентские средства и выполнять safeguarding.
7) Break-even: считайте двумя способами (иначе сами себя обманете)
A) Бухгалтерский break-even (EBITDA ≥ 0)
Подходит для отчётности совету/борду.
B) Contribution break-even (unit economics)
Break-even по активным пользователям = Fixed cost / Contribution margin на активного
Где contribution margin на активного строится из:
- net interchange margin + net FX margin + net payout margin + подписки
минус - переменный processing + потери от фрода + KYC/AML + переменная поддержка
Именно тут видно, не «субсидируете» ли вы рост.
Лицензионный угол: contribution break-even это не только стартап-метрика. При корректном применении он усиливает нарратив «реалистичного бизнес-плана» под надзорной проверкой.
8) Стрессы, которые надзор реально уважает (минимальный набор)
На практике надзор часто просит простую проверку устойчивости бизнес-плана через шок выручки (например, −40% и −60%). Ключевой момент: стресс должен быть не просто «срезали top-line», а объясняться через драйверы (объёмы, маржа, микс) и давать чёткие выходы по ликвидности, own funds и safeguarding-операциям.
Ниже минимум, который легко встроить.
Stress A: выручка −40%
Что меняется (через драйверы):
- ниже объёмы / меньше активных (volume shock) и/или
- хуже чистая маржа (компрессия FX/interchange, скидки) и/или
- неблагоприятный микс (меньше FX/карт, больше низкомаржинальных потоков)
Что показать:
- сдвиг break-even (EBITDA и contribution)
- влияние на burn rate и runway (cash waterfall)
- влияние на требование own funds и headroom (required vs available + буфер)
- влияние на safeguarding: settlement timing, refund, chargeback, нагрузка сверок/ops
Management actions (обязательно явно):
- freeze найма/маркетинга, отложить некритичные релизы, урезать discretionary spend
- перепрайсить планы/тиеры и сфокусироваться на более маржинальных продуктах
- при необходимости: подтверждённая поддержка акционера/коммит финансирования (только если есть доказательства)
Stress B: выручка −60%
«Сильно, но правдоподобно»: проверка, что бизнес не становится небезопасным даже при крупном отклонении от плана.
Что меняется:
- глубже падение объёмов и/или сильнее компрессия маржи
- выше churn / ниже activation
- сильнее ценовое давление и ниже take rate
Что показать:
- runway (мес.) и пересечение minimum cash threshold
- способность держать own funds выше требования помесячно (включая буфер)
- устойчивость safeguarding при худшем settlement timing и динамике возвратов
- операционная способность: выдерживают ли контроли (сверки, мониторинг, отчётность)
Management actions:
- снизить burn до “survival mode”: переразметить бюджет, пауза non-core
- перепрайсить и ввести fair-use caps
- пересмотреть vendor-контракты, сдвинуть затраты из fixed в variable где возможно
Stress C: операционный стресс EMI: всплеск фрода/chargeback + замедление refund/settlement
Даже с revenue shock надзор ожидает отражения core EMI риска: spike-потерь и ухудшения “money timing”.
Что меняется:
- выше fraud loss rate и комиссии по chargeback/dispute
- больше спорной нагрузки → давление на ops/support/compliance
- хуже settlement timing и задержки refund → давление на кэш и safeguarding ops
Что показать:
- влияние на cash waterfall и потребность в доп. ликвидности
- влияние на workload safeguarding и каденцию/объёмы сверок
- влияние на own funds headroom (если меняются средние остатки/объёмы)
Management actions:
- ужесточить риск-политики, снизить high-risk сегменты, step-up verification
- усилить мониторинг/контроли и SLA партнёров
- пересмотреть лимиты и правила спор/возврат
Минимальные выходы для каждого стресса (единый формат)
Для A/B/C модель должна показывать минимум:
- Runway impact: месяцев кэша под стрессом, до и после management actions
- Own funds headroom: required vs available own funds помесячно + буфер
- Safeguarding impact: эффекты settlement/refund timing, тикеты, сверки, returns/chargeback
9) «Evidence pack», который делает модель достоверной
Приложите (или будьте готовы предоставить) документы, которые превращают допущения в факты:
- Прайсинг и черновики контрактов (процессоры, programme manager, KYC/screening-вендоры)
- Headcount-план с владельцами ролей (compliance, safeguarding, ICT risk)
- Money-flow диаграммы и каденция сверок
- Политики/процессы, показывающие, что вы способны работать в регулируемом стандарте (EBA authorisation guidelines это базовая опора, на которую многие NCA ориентируются)
Чехия (ČNB): формат подачи и «annex дисциплина»
Поскольку процесс ČNB построен на формах и обязательных приложениях по чешскому праву (закон о платёжной системе + подзаконные акты), относитесь к evidence pack как к “ready-to-file” материалу, а не как к справке “на всякий случай”. В публичных guidance ČNB подчёркивает использование её форм и то, что требования сидят в рамках закона/выбл. актах; подача электронная.
Практически: привязывайте ключевые допущения к документам (draft контрактов, прайсинг, vendor предложения) и проверяйте, что выходы модели согласованы с safeguarding потоками и операционными процедурами, описанными в других частях заявки.
10) Следите за регуляторным горизонтом (не обещайте «вечную стабильность»)
ЕС предложил ревизию PSD2 (PSD3 + PSR), которая также будет покрывать сервисы электронных денег (раньше это было разделено между PSD2 и EMD2). Это может повлиять на среднесрочные допущения, особенно по надзору и гармонизации.
Мы поможем собрать финансовую модель EMI, готовую к регулятору
Если вы готовите заявку на EMI-лицензию в Чехии, AMS Europe поможет построить трассируемую 3-летнюю модель, согласованную с annex-ожиданиями ČNB и надзорной логикой ЕС: драйверы → остатки → выручка/расходы → own funds schedule → ликвидность/safeguarding механика → стресс-сценарии и management actions. Также поможем упаковать supporting evidence pack (экономика прайсинга, допущения по вендорам, headcount-план, money-flow диаграммы и каденция сверок), чтобы модель была защищаемой в Q&A с регулятором.I заявок, чтобы балансы, логика own funds, допущения по ликвидности, safeguarding операции и описания IT/аутсорсинга были согласованы. Это делает подачу защищаемой в Q&A с ČNB.
ПОЛУЧИТЕ ČNB-READY GAP-CHECK И ЧЁТКИЙ СПИСОК ПРАВОК
ЗАПУСТИТЬ EMI PRE-CHECK
FAQ
Почему ČNB чаще всего «цепляется» к финансовой модели EMI?
Самая частая причина это несогласованность пакета заявки. Финансовая модель не совпадает с money-flow диаграммой, safeguarding подходом, экономикой провайдеров (процессоры, programme manager, KYC/AML инструменты) или операционным планом. Для ČNB это выглядит как фрагментированная подача, где документы противоречат друг другу. Обычно это ведёт к доп. вопросам и задержкам. Решение: «трассируемая» модель, где ключевые числа подкреплены документами (draft контрактов, прайсинг, vendor предложения) и явно связаны с операциями и контролями.
В лицензировании EMI достаточно прогноза P&L или нужен более широкий финпакет?
Для EMI авторизации прогнозы обычно шире, чем P&L. Надзор чаще ожидает полный связанный набор расчётов: прогнозы остатков e-money, расчёты own funds, прогноз ликвидности и cash runway, плюс операционный взгляд на safeguarding (settlement timing, возвраты, споры и нагрузка на сверки). Если отправить только P&L без логики остатков и safeguarding механики, регулятору сложно оценить устойчивость и операционную безопасность.
Как обосновать выручку в EMI бизнес-плане, чтобы её не посчитали нереалистичной?
EU и чешский надзор обычно доверяет подтверждённым unit economics, а не маркетинговым «витринным комиссиям». Практика: моделируйте выручку как чистую маржу и показывайте реальный cost stack по каждому стриму (карты, FX, выплаты), по возможности подкрепляя term sheet’ами от процессоров/programme manager и vendor предложениями. Чем больше “evidence-based” экономики (контракты, прайсинг, подтверждённые fee), тем меньше риск, что прогнозы сочтут чрезмерно оптимистичными.
Какие стресс-тесты считаются приемлемыми для EMI в Европе и зачем два уровня падения выручки?
Минимальный regulator-friendly набор часто включает два уровня шока (например, −40% и −60%). Смысл не в процентах, а в демонстрации: (1) влияния на cash runway, (2) устойчивости own funds headroom, (3) стабильности safeguarding-операций (settlement timing, возвраты, chargeback, сверки). Два уровня показывают безопасность бизнеса и при «плохом годе», и при severe-but-plausible сценарии, с понятными management actions.
Сколько обычно занимает сборка финмодели EMI для чешской заявки и какие нужны входные данные?
Срок зависит от готовности ключевых входов: прайсинг/fee логика, ожидаемые объёмы и продуктовый микс, черновики соглашений с провайдерами (banking/IBAN, cards, FX liquidity, payouts, KYC/AML), базовое описание safeguarding и операций. Если это готово заранее, модель собирается быстрее и выглядит убедительнее, потому что опирается на документы, а не на «хотелки». На практике эффективнее строить модель вместе с evidence pack и логикой приложений, чтобы сократить циклы вопросов ČNB и повысить качество заявки.
