Короткий ответ. Запуск fintech в ЕС нельзя собирать как цепочку «сначала компания, потом лицензия, потом приложение». Регуляторный периметр, продукт, движение денег, outsourcing, AML, safeguarding, IT и коммерческая модель должны проектироваться вместе. Иначе выбранная компания не подходит, интерфейс обещает запрещённый сценарий, банк не понимает потоки, а разработку приходится переделывать перед подачей.
Ниже — практическая последовательность для payment, e-money, crypto и гибридных проектов. Она не определяет конкретную лицензию без анализа фактов.
1. Начните с карты услуг и движения денег
Опишите каждое действие пользователя от регистрации до вывода средств. Кто принимает деньги? Где они хранятся? Кто исполняет перевод или обмен? Есть ли custody, conversion, issuing, acquiring, wallet, credit или только технический интерфейс? От ответа зависит, нужна ли собственная авторизация, партнёрская модель или иной маршрут.
| Модель | Ключевой вопрос | Типичная ошибка |
|---|---|---|
| Payments / e-money | Кто оказывает регулируемую платёжную услугу и хранит клиентские средства? | Называть platform fee «неплатёжной» без анализа фактического потока |
| Crypto / MiCA | Какие crypto-asset services выполняет компания? | Подаваться как broker, когда продукт также делает custody или execution |
| Embedded finance | Что делает лицензированный партнёр, а что делает платформа? | Полагаться на API-договор, который не покрывает маркетинг и UX |
| Technology provider | Остаётся ли компания вне владения средствами и принятия регулируемых решений? | Описывать себя как software provider при ином фактическом контроле |
2. Выберите регуляторный маршрут до юрисдикции
Сравнивать страны следует после определения услуг. Для проекта важны компетентный орган, ожидания к local management, команда, capital plan, сроки подготовки, доступность специалистов, язык, налоги и возможность обслуживать нужные рынки. «Самая быстрая лицензия» без подходящей операционной модели редко является самым быстрым запуском.
Для crypto-проектов переходный период MiCA завершился по всему ЕС 1 июля 2026 года. Компания, которая не имеет права работать, не должна строить план продаж на старом национальном режиме. Для payment-проектов также нужно учитывать действующие правила PSD2 и развитие PSD3/PSR, не представляя политическое соглашение как уже применяемый закон.
3. Синхронизируйте компанию, владельцев и управление
- понятная ownership structure и источник капитала;
- директора и ключевые функции с достаточным временем и опытом;
- реальное распределение решений между ЕС и другими странами;
- fit and proper пакет без противоречий в CV, проектах и долях;
- договоры между group entities, IP owner и operating company.
Регистрация shell-компании не создаёт substance. Орган оценивает, где принимаются решения и кто реально отвечает за risk, compliance, product и operations.
4. Проектируйте MVP по control map
Backlog лицензируемого продукта должен включать не только клиентские функции. Нужны onboarding, screening, transaction monitoring, case management, limits, complaints, reconciliation, access control, audit trail, incident handling и отчётность. Для каждой функции зафиксируйте: build, buy или outsource; владелец контроля; источник данных; доказательство работы.
С 17 января 2025 года DORA применяется к финансовым организациям в своём периметре. Это означает, что ICT risk, incidents, resilience testing и реестр договоров с ICT-провайдерами нельзя оставлять на период после лицензии. Cloud, KYC, core ledger и support tools должны попадать в единую vendor map.
5. Готовьте банк, safeguarding и платежных партнёров параллельно
«Лицензия сначала — банк потом» создаёт риск замкнутого круга. Партнёры хотят видеть бизнес-модель, UBO, прогнозы, geographies, AML controls, сайт, продукт и ожидаемые потоки. Регуляторный пакет, банковская заявка и описание продукта должны рассказывать одну и ту же историю.
Необходимо разделять corporate account, operational accounts, safeguarding arrangement и клиентские способы пополнения/вывода. Это разные задачи с разными критериями одобрения. CrystalCore объединяет финансовое лицензирование, бизнес-счета и платёжную инфраструктуру в одной карте зависимостей.
6. Соберите application room
- regulatory perimeter memo и service map;
- group structure, governance и responsibility matrix;
- финансовая модель с capital and liquidity assumptions;
- AML/CFT risk assessment, policies и operating procedures;
- ICT architecture, DORA map, security и business continuity;
- outsourcing register, material contracts и vendor due diligence;
- product flows, screenshots, terms, complaints и disclosures;
- banking, safeguarding и партнёрские evidence.
Документы должны описывать работающую модель, а не существовать отдельно от продукта. Если policy обещает four-eyes approval, оно должно быть видно в ролях и audit log.
7. Запускайте go-to-market без регуляторных обещаний
До получения разрешения сайт, реклама и sales scripts должны точно отражать статус. Нельзя создавать впечатление, что заявитель уже лицензирован, гарантировать дату решения или продавать услуги, на которые ещё нет права. Но можно заранее построить SEO-структуру, образовательный контент, CRM, waitlist и аналитику — с корректными формулировками.
Реалистичная последовательность проекта
| Этап | Коммерческий результат |
|---|---|
| 1. Discovery | Service map, scope, страны и критические допущения |
| 2. Architecture | Entity, governance, партнёры, product control map |
| 3. Build and evidence | MVP, policies, vendor files, financial model |
| 4. Application | Согласованный dossier и ответы на вопросы органа |
| 5. Launch | Banking, operations, compliant marketing и отчётность |
Частые вопросы
Можно ли сначала купить готовую лицензированную компанию?
Иногда это сокращает отдельные этапы, но change of control, due diligence, соответствие продукта и согласование новых владельцев остаются критичными. Покупка не отменяет проверку регулятора и партнёров.
Нужен ли полностью готовый продукт до подачи?
Зависит от режима и органа, но одной презентации обычно недостаточно. Нужны детальные flows, архитектура, controls и доказательство способности реализовать заявленную модель.
Можно ли гарантировать срок лицензии?
Нет. Срок зависит от качества пакета, команды, сложности услуг, очереди органа и количества запросов. Управлять можно readiness и скоростью ответов, но не решением органа.
Что делать первым: licence memo или разработку?
Короткий perimeter and architecture этап должен предшествовать дорогой разработке. Затем product и application workstreams идут параллельно.
Официальные источники
- ESMA: окончание переходных периодов MiCA
- ESMA: Digital Operational Resilience Act
- European Commission: payment services и статус PSD review
Проверено 10 октября 2026 года. Материал не является юридическим заключением и не гарантирует авторизацию, банковский счёт или срок решения.