Направления работ, владельцы, майлстоуны и критический путь
Почему честно говорить “16–32 недели”, а не “сделаем быстро”
Подготовка к EMI-лицензии — это не один проект “на документы”. Это комплексный проект, который включает продукт, операции, комплаенс/AML, финансы, safeguarding, ИТ-контроли, аутсорс и управление компанией.
И сроки почти всегда ломаются не на “бумажках”, а на доказательствах готовности: кто реально делает KYC, как обрабатываются алерты, как ведутся сверки, как контролируются вендоры, где логи и доступы.Поэтому нормальная подготовка к лицензированию выглядит как управляемая система: направления работ → владельцы → майлстоуны → критический путь.
Как управлять проектом, чтобы он не развалился
Один владелец проекта. Один критический путь. Одна система контроля версий. Если у вас “все помогают”, значит у вас нет владельца. У вас коллективная безответственность.
Базовые роли и владельцы
- Владелец проекта (обычно CEO/COO): сроки, приоритеты, решения, эскалации
- Владелец комплаенса/MLRO: AML/CTF, риск-модель, политика, ответы регулятору
- Владелец финансов (CFO/Head of Finance): финансовая модель, капитал, safeguarding, сверки
- Владелец продукта/ИТ (CTO/Head of Product): архитектура, ИТ-контроли, интеграции, логи/доступы
- Владелец операций (COO/Ops Lead): онбординг, support, жалобы, инциденты, runbooks
- Юридический владелец (in-house/outside counsel): governance, договоры, аутсорс, протоколы решений
Направления работ (минимальный набор)
- Периметр и продукт (что именно вы лицензируете и как это работает)
- Управление и люди (структура, роли, “fit & proper”, комитеты)
- Риски и комплаенс / AML (оценки рисков, политики, мониторинг, SAR)
- Safeguarding и финансы (схемы потоков, счета, сверки, отчётность)
- Операции (онбординг, поддержка, жалобы, возвраты/споры)
- Технологии и безопасность (доступы, логи, изменения, инциденты, устойчивость)
- Аутсорс и вендоры (реестр, due diligence, SLA, планы выхода)
- Файл заявки и управление Q&A (структура подачи, версии, ответы)
План на 16–32 недели: фазы, майлстоуны и владельцы
Фаза 1 (Недели 1–4): “Ставим рельсы”
Цель: закрепить периметр, собрать владельцев, утвердить целевую операционную модель и архитектуру.
Майлстоуны:
- M1: Зафиксирован периметр продукта (что делаем и что НЕ делаем)
Владелец: CEO/COO + Legal + Compliance - M2: Целевая операционная модель версия 1 (как работает EMI день-в-день)
Владелец: COO/Ops - M3: Архитектура и список ключевых вендоров версия 1
Владелец: CTO - M4: План проекта + критический путь + “лист доказательств”
Владелец: Владелец проекта
Ключевые артефакты:
- пользовательские сценарии (онбординг, пополнение, перевод, возврат, спор, блокировка)
- перечень необходимых политик/процедур (минимальный комплект)
- карта аутсорса: что критично и как контролируем
Фаза 2 (Недели 5–10): “Документы и операционка становятся реальными”
Цель: превратить намерения в правила и процессы, которые можно повторить и доказать.
Майлстоуны:
- M5: Пакет governance версия 1 (структура, роли, комитеты, ответственность)
Владелец: Legal + CEO - M6: Оценка рисков + риск-аппетит версия 1
Владелец: Compliance/Risk - M7: AML/CTF-фреймворк версия 1 (CDD/EDD/санкции/мониторинг/эскалации)
Владелец: MLRO - M8: Safeguarding-дизайн версия 1 (счета, сверки, отчёты)
Владелец: CFO - M9: Операционные runbooks версия 1 (жалобы, инциденты, support, KYC ops)
Владелец: Ops Owner - M10: ИТ-контроли версия 1 (доступы, логи, изменения, инциденты, BCP)
Владелец: CTO/Security
Фаза 3 (Недели 11–18): “Сборка пакета и тест доказательств”
Цель: собрать “регуляторно-читаемый” пакет и прогнать сквозные сценарии.
Майлстоуны:
- M11: Зафиксирована структура файла заявки + контроль версий
Владелец: Владелец проекта - M12: Сквозные прогоны процессов (клиент → транзакция → алерт → жалоба → инцидент)
Владелец: COO + MLRO + CTO - M13: Пакет по аутсорсу готов (реестр, due diligence, SLA, exit plans)
Владелец: Legal + CTO + Risk - M14: Финмодель + доказательства капитала/источника средств готовы
Владелец: CFO - M15: Черновик “готов к подаче” (sanity check: нет противоречий)
Владелец: Владелец проекта + Legal
Фаза 4 (Недели 19–32): “Подача и цикл вопросов-ответов”
Цель: отвечать быстро и последовательно, не ломая пакет и не создавая новые противоречия.
Майлстоуны:
- M16: Подача отправлена
Владелец: Legal / Владелец проекта - M17: Процедура Q&A (playbook) утверждена
Владелец: Владелец проекта - M18: Итерации по запросам (обновления политик/процессов/доказательств)
Владельцы: все владельцы направлений работ - M19: Операционная готовность к запуску (если требуют демонстрацию)
Владелец: COO/CTO/MLRO - M20: Финальная сверка непротиворечивости пакета
Владелец: CEO + Владелец проекта
Критический путь: что чаще всего реально тормозит подготовку
Вот список, на который CEO должен смотреть каждую неделю. Это и есть “узкие места”, а не “красивые диаграммы”.
- Периметр и ограничения: что вы делаете юридически и чего не делаете
- Governance и ключевые роли: ответственность, “fit & proper”, принятие решений
- AML как операционная система: онбординг, EDD, мониторинг, эскалации, SAR
- Safeguarding и сверки: схема счетов, периодичность, отчёты, контроль
- Аутсорс: контроль критичных вендоров, SLA, план выхода (exit plan)
- ИТ-контроли и доказательства: доступы, логи, изменения, инциденты, BCP
- Финансовая модель + доказательства капитала: непротиворечивый сторителлинг цифр
- Способность отвечать на вопросы: скорость, качество, контроль версий
Если эти пункты слабые, срок будет ближе к 32 неделям. Если сильные, можно уложиться ближе к 16–24.
Как CEO держит проект под контролем (без микроменеджмента)
Пять правил, которые реально работают:
- Еженедельный steering на 45 минут: решения, блокеры, критический путь
- Один backlog изменений (не 5 разных табличек)
- Версионность всего: документы, схемы, ответы, приложения
- Сначала доказательства, потом слова: если нет evidence, считайте что этого нет
- Stop-doing list: новые хотелки входят только если что-то выходит
Таблица: направление → владелец → ключевые deliverables
| Направление | Владелец | Минимальный набор deliverables |
| Периметр и продукт | CEO/COO + Legal | описание услуг, сценарии, ограничения/запреты |
| Governance | CEO + Legal | оргструктура, роли, комитеты, пакет “fit & proper” |
| Риски и AML/CTF | MLRO/Compliance | risk assessment, AML policy, CDD/EDD, мониторинг, SAR процесс |
| Safeguarding и финансы | CFO | safeguarding-дизайн, сверки, отчётность, финмодель |
| Операции | COO/Ops | SOP: онбординг ops, support, жалобы, инциденты, возвраты |
| ИТ и безопасность | CTO | доступы, логи, change mgmt, incident mgmt, BCP/DR |
| Аутсорс и вендоры | Legal + CTO + Risk | реестр, due diligence, SLA, exit plans, контроль |
| Файл заявки и Q&A | Владелец проекта | структура пакета, контроль версий, процедура ответов |
Вывод
16–32 недели — это не “долго”. Это нормальный срок, чтобы построить регулируемый бизнес, который умеет доказывать, что он управляемый.
Самый быстрый способ потерять время: писать документы без операционки.
Самый быстрый способ выиграть: держать критический путь и лист доказательств под еженедельным контролем.
ПОЛУЧИТЕ ČNB-READY GAP-CHECK И ЧЁТКИЙ СПИСОК ПРАВОК
ЗАПУСТИТЬ EMI PRE-CHECK
FAQ по дорожной карте подготовки к EMI-лицензии
Почему план такой длинный? Мы же стартап, хотим быстро.
Потому что подготовка к EMI-лицензии — это не “запустить приложение”, а построить управляемую операционную систему, которая умеет доказывать: кто принимает решения, как работает AML, где safeguarding, как контролируются вендоры, где логи и доступы. Быстро можно сделать только презентацию.
От чего зависит, будет это 16 недель или 32?
Почти всегда от трёх факторов:
- качество доказательств (evidence): логи, кейсы, SOP, сверки, контроль аутсорса;
- готовность команды владельцев (не “все понемногу”, а конкретные owners);
- стабильность периметра (если вы каждые 2 недели меняете продукт, срок уедет).
Что самое частое “узкое место” на критическом пути?
Топ-3 вечных тормоза:
- AML как реальный процесс, а не “политика в PDF” (EDD, алерты, эскалации, SAR);
- safeguarding + сверки (кто делает, как часто, чем подтверждает);
- outsourcing (контроль критичных вендоров, SLA, exit plan, oversight).
Сколько людей реально нужно, чтобы проект не умер?
Минимально жизнеспособно:
- владелец проекта (CEO/COO),
- MLRO/Compliance (можно внешний на старте, но с реальными полномочиями),
- Finance owner (CFO/Head of Finance),
- CTO/Tech owner,
- Ops owner.
Часть функций можно аутсорсить, но владельцев аутсорсить нельзя.
