Большинство задержек по EMI возникают не из-за «медленных регуляторов». Причина почти всегда одна: заявка в поданном виде не является “assessable” — её нельзя полноценно оценить.
PSD2 прямо говорит: орган надзора сообщает решение в течение 3 месяцев с момента получения заявки — либо, если заявка неполная, в течение 3 месяцев с момента получения всей требуемой информации. То есть таймер фактически “на паузе”, пока пакет не станет полным.
Peer review EBA по PSD2-авторизациям показал, что средние end-to-end сроки сильно отличаются между странами ЕС (от нескольких месяцев до более чем года) и подчеркнул, что ключевой драйвер — качество заявки и скорость, с которой заявитель закрывает замечания/вопросы.
Ниже — самые частые причины задержек и что делать, чтобы не уходить в бесконечный rework (особенно актуально для Чехии/ČNB, но структурно верно по всему ЕС).
«Неполные» подачи (нет приложений, расплывчатые ответы, устаревшие данные)
Что происходит: регулятор просит дополнять, формальное окно оценки по сути не стартует, и вы попадаете в цикл Q&A.
Как избежать переделок:
- Сделайте единый master-индекс документов (1 таблица): требование → файл → ссылка на страницу/раздел → ответственный.
- Зафиксируйте версию подачи и проведите pre-submission аудит полноты.
- Следуйте логике EBA: информация должна быть полной, точной, актуальной и оформленной так, чтобы орган мог её оценить без догадок.
- Регуляторы говорят это и публично: оценка возможна только по полностью завершённой заявке, а срок начинает течь, когда она комплектна.
Неясный scope и «program of operations» (что именно вы делаете)
Что происходит: ваш продукт выглядит как три разных бизнеса — зависит от того, какую секцию читает ревьюер.
Типичные red flags:
- «Кошелёк» в одном месте описан как e-money, в другом — как payment account
- Не определён flow: кто держит деньги, кто что выпускает, когда происходит redemption
- Нет связки между услугами и реальными customer journeys
Как избежать переделок:
- Дайте матрицу scope & products (продукт → юридическая активность → клиенты → географии → партнёры → денежный поток).
- Добавьте end-to-end схемы (onboarding → пополнение/funding → траты/spend → возврат/redemption → жалобы/complaints).
Слабый safeguarding-пакет (№1 зона «глубокой проверки»)
Что происходит: надзор не может сделать вывод, что средства клиентов защищены операционно, а не только «на бумаге».
Частые пробелы:
- Нет логики ежедневной сверки (reconciliation) и ownership
- Неясны права доступа к safeguarding-счетам
- Нет сценария отказа (что если партнёр падает или ломается settlement)
Как избежать переделок:
- Включите safeguarding operating procedure (ежедневные шаги, доказательные outputs, обработка исключений).Рано приложите письма банка/партнёров, структуру счетов и доказательства access control.
Капитал и «source of funds» не подтверждены “чисто”
Что происходит: регулятор видит финансирование как неопределённое, условное или не совпадающее с планом.
Как избежать переделок:
- Дайте простую «историю капитала»: источник → сроки → документ-доказательство.
- Сведите прогнозы с потребностью в капитале (включая stress-сценарии) и явно опишите предпосылки.
Руководство выглядит номинально (роли названы, но системы контроля нет)
Что происходит: регулятор начинает копать «кто реально контролирует риск, compliance, аутсорсинг и инциденты» и не видит работающего механизма.
Как избежать переделок:
- Покажите governance как механику принятия решений, а не должности:
- cadence отчётности (ежемесячный risk pack, KRI, инциденты)
- workflow одобрений (новые продукты, подключение вендоров, изменения лимитов)
- план внутреннего контроля (тестирование + ответственность за remediation)
- EBA продвигает оценимую модель управления и управленческую отчётность, а не общие слова.
Fit-and-proper документы приходят поздно (или не соответствуют обязанностям)
Что происходит: файл «ждёт» назначений, распределения времени, background-доков или ясности роли.
Как избежать переделок:
- Зафиксируйте ключевых держателей функций заранее.
- Дайте карту ответственности (роль → зоны оценки → доказательства).
AML/CTF шаблонный и не привязан к продукту и каналам
Что происходит: AML подан как template, хотя модель высокорисковая (cross-border, агенты/дистрибьюторы, cash-in rails, карты, crypto exposure и т.д.).
Как избежать переделок:
- Дайте реальный business risk assessment (клиенты/гео/каналы/продукты).
- Покажите покрытие мониторинга и эскалацию (алерты → расследование → решения по SAR/STR).
- Докажите, что вы контролируете AML даже при outsourcing части процессов.
Peer review EBA также отмечает, что по ЕС остаются пробелы в governance и внутренних контролях (включая AML/CFT) — именно туда ревьюеры обычно «упираются».
Outsourcing и ICT-контроли не соответствуют ожиданиям (реальность эпохи DORA)
Что происходит: core-функции отданы на аутсорс (KYC, мониторинг, ledger, card processing, cloud), но вы не можете доказать oversight, устойчивость и планы выхода.
Почему в 2026 хуже: DORA применяется с 17 января 2025, подняв базовые ожидания по ICT-рискам, инцидентам и контролю третьих сторон.
Как избежать переделок:
- Ведите реестр критического аутсорсинга (сервисы, критичность, audit rights, субподрядчики, exit plan).
- Приложите incident playbooks и доказательства тестирования (tabletop-упражнения помогают).
Финмодель не соответствует операционной реальности
Что происходит: ревьюер видит агрессивный рост объёмов, но нет найма, нет стоимости compliance, нет резервов под fraud/chargeback, нет масштабирования vendor-расходов.
Как избежать переделок:
- Добавьте “assumptions book” и чувствительность (base/downside).
- Свяжите headcount, функции контроля и vendor-стоимость с ростом.
Медленные и хаотичные ответы на Q&A от регулятора (тихий убийца сроков)
Peer review EBA подчёркивает, что скорость и качество ответов заявителя — ключевой фактор задержек.
Как избежать переделок:
- Ведите Q&A как отдельный workstream:
- единый Q&A-трекер (вопрос → владелец → срок → файлы-доказательства → версия)
- короткие ответы + доказательные приложения (не переписывать весь файл каждый раз)
- строгий version control (что изменилось и где)
Ошибки механики подачи (datová schránka, формат пакета, «оригиналы»)
Для Чехии (ČNB): подача и последующая формальная коммуникация идут через datová schránka. Ошибки на уровне канала/формата/упаковки часто приводят к возвратам, уточнениям и дополнительным итерациям, которые незаметно съедают сроки.
Как избежать переделок:
- Проверьте процесс datová schránka до «Day 0»: доступы, полномочия отправителя, кто является уполномоченным подписантом/представителем, и как вы будете фиксировать подтверждения отправки/получения.
- Упакуйте подачу так, чтобы она была assessable:
- понятный список приложений + единый нейминг файлов + фиксированная версия (например, “Submission v1.0”).
- Упростите навигацию по доказательствам:
- один индекс (таблица) “требование → файл → раздел/страница → ответственный”.
- Закройте вопрос «оригиналов» заранее:
- если часть материалов существует только на бумаге (оригиналы/заверенные копии), подготовьте их юридически корректную электронную форму (через авторизованную конверсию/сертификацию).
- Соблюдайте техограничения:
- лимиты размеров сообщений/вложений, читаемые форматы (PDF), избегайте хаотичных сканов, используйте чёткую нумерацию и перекрёстные ссылки.
Простой “no-rework” инструментарий (что мы внедряем для быстрых пакетов)
- Document Index + Evidence Map (единый источник правды)
- Scope Matrix + Money-Flow схемы
- Safeguarding Operating Pack (ежедневные контроли + evidence outputs)
- Outsourcing & ICT Pack под ожидания DORA
- Q&A Tracker с владельцами + ссылками на доказательства (быстро, прозрачно, с чистым audit trail)
Как AMS помогает избежать доработок по EMI
Большинство задержек происходит не из-за «медленного регулятора», а потому что пакет документов не пригоден для рассмотрения при подаче.
Мы собираем пакет заявки, готовый для ЧНБ (ČNB): полный, согласованный и удобный для проверки — чтобы вы не теряли месяцы на «дополнения».
-
Gap-check: соответствие объёму EMI и ожиданиям PSD2
-
Индекс документов, структура папок и перекрёстные ссылки
-
Evidence pack по управлению, AML, safeguarding и аутсорсингу
-
QA перед подачей + «имитация вопросов регулятора»
-
Поддержка при запросах/дополнениях (чёткие ответы без противоречий)
Что вы получаете
FAQ: EMI паспортизация в Евросоюзе 2026
Почему EMI-лицензирование в ЕС часто занимает 6–12+ месяцев, даже если «законный» дедлайн короче?
На практике общий срок определяется меньше “статутным” периодом и больше тем, как быстро заявитель доводит пакет до состояния “assessable”. Если в подаче есть пробелы, противоречия или документы не складываются в целостную картину бизнеса, надзор запускает цикл уточняющих вопросов, пояснений и новых версий. Именно эта итерация добавляет месяцы. Чтобы ускорить путь к EMI-лицензии, нужно заранее собрать оценимый пакет: единый индекс документов, карту доказательств, понятные схемы потоков денег и проверяемые контрольные процедуры. Это сокращает количество Q&A-раундов и устраняет повторную сборку файла.
Как описать EMI-модель так, чтобы регулятор чётко понял, что вы делаете и под какую лицензию это подпадает?
Самая частая ошибка — описывать продукт маркетинговыми словами (“wallet”, “platform”, “payments”), не раскрывая юридическую суть каждой активности. Регулятору не нужны слоганы; ему нужна операционная ясность: какие услуги вы оказываете, когда и как выпускается e-money, кто держит деньги клиента, кто исполняет платёж и когда происходит redemption. Сильный подход — сделать “product map”: по каждой customer journey (onboarding → funding → holding → spending → refunds/redemption) показать стороны, роли, договорные связи и движение денег. Это убирает ключевой red flag — когда разные разделы заявки создают впечатление, что компания сама не уверена, EMI она, payment institution или просто тех-провайдер.
Что обычно ожидает регулятор в safeguarding-разделе, чтобы признать защиту средств “в практике”, а не только “на бумаге”?
Safeguarding не доказывается фразой «держим средства на сегрегированном счёте». Регулятор хочет операционную, evidence-based защиту: кто делает ежедневную сверку, какие отчёты формируются, что считается исключением, кто утверждает исправления и как компания действует при сбое партнёра, поломке settlement или задержке банка. Сильный safeguarding-пакет обычно включает: пошаговые ежедневные процедуры, шаблоны отчётов и evidence outputs, доказательства контроля доступов к safeguarding-счетам и реалистичные “what-if” сценарии (задержки, споры, возвраты, ошибочные проводки). Safeguarding — зона максимальной проверки и частая причина deep-dive, поэтому качество здесь напрямую влияет на сроки.
Какие AML/CTF слабости чаще всего “ломают” EMI-заявки и как доказать, что у вас не шаблонная compliance?
Частая проблема — политики выглядят формально правильно, но не связаны с тем, как бизнес реально привлекает клиентов и обрабатывает транзакции. Если модель cross-border, с агентами/дистрибьюторами, cash-in rails, картами или crypto exposure, AML/CTF должен быть адаптирован под эти риски, а не быть шаблоном. Чтобы показать зрелость, заявка должна содержать: бизнес-оценку рисков по клиентам/географиям/каналам/продуктам, логику мониторинга (какие сценарии вы ловите и почему), чёткую эскалацию (алерт → расследование → решение → SAR/STR) и то, как вы контролируете AML при аутсорсинге ключевых элементов (например, KYC). Это делает файл assessable и снижает объём вопросов от регулятора.
Как подготовиться к DORA-ожиданиям по аутсорсингу и ICT, чтобы tech/outsourcing-раздел не попал в узкое место?
С 2025 года существенно выросли базовые ожидания по ICT-рискам и контролю третьих сторон, и в 2026 это явно отражается в проверках. Большинство fintech core функций завязано на вендоров — cloud, card processing, KYC, мониторинг и ledger. Регулятору мало знать, что вы “используете провайдеров”; нужны доказательства, что вы ими управляете: критический реестр аутсорсинга, audit rights, контроль субподрядчиков, чёткие SLA/метрики и реалистичный exit plan. Сильный ICT/DORA-aligned пакет также включает incident playbooks, процедуры уведомлений и доказательства тестирования (включая tabletop-упражнения), плюс ясную внутреннюю ответственность. Это снижает риск того, что надзор поставит содержательную оценку на паузу, пока вы не докажете устойчивость и надзор.
