Как запускать финтех-продукты в 2026 году: регуляторика, архитектура и compliance-by-design

Автор статьи: Иван Манжетов, менеджер портфеля финтех-продуктов в KODE

Еще несколько лет назад запуск финтех-продукта часто строился по привычной стартап-логике: проверить гипотезу, собрать MVP, показать его рынку, а уже затем подробно разбираться с лицензиями, требованиями к данным и другими ограничениями.

Сегодня такой порядок действий становится слишком рискованным.

Регуляторные требования влияют уже не только на юридическое оформление сервиса. Они определяют пользовательские сценарии, архитектуру продукта, набор интеграций, выбор партнеров, требования к инфраструктуре и даже бизнес-модель.

Если выяснить критичные ограничения непосредственно перед релизом, исправить несколько документов или экранов обычно недостаточно. Приходится менять backend, процессы идентификации, схему хранения данных, платежную логику или архитектуру целиком.

Поэтому в финтехе все важнее подход compliance-by-design: регулирование учитывают не после разработки, а во время проектирования продукта.

Финтех больше нельзя запускать по принципу «сначала продукт, потом требования»

Российский финтех заметно изменился за последние несколько лет. Если раньше рынок ассоциировался прежде всего со скоростью, быстрыми MVP и агрессивным масштабированием, то сейчас устойчивость продукта и соответствие требованиям становятся не менее важными, чем time-to-market.

Особенно заметно среда изменилась после 2020 года и затем после 2022-го. Усилились требования к финансовой инфраструктуре, работе с персональными данными, платежам, идентификации клиентов и внутренним процессам компаний.

Одну из ключевых ролей здесь играет Банк России.

Регулятор последовательно усиливает контроль за финансовыми сервисами, причем требования касаются не только банков в классическом понимании. Если компания работает с платежами, финансовыми данными, кредитными продуктами, идентификацией или другими чувствительными сценариями, требования регулятора начинают непосредственно влиять на продукт.

В основных направлениях развития финансового рынка Банк России отдельно говорит об устойчивости финансовой системы и защите интересов клиентов.

Для бизнеса из этого следует важный вывод: скорость вывода продукта на рынок больше нельзя рассматривать отдельно от регуляторных рисков.

Можно быстро разработать сервис, но если его архитектура или бизнес-процессы не соответствуют требованиям, фактического запуска не произойдет.

Есть и еще одно следствие.

Чем выше порог входа на финансовый рынок, тем сложнее небольшим компаниям самостоятельно строить всю необходимую инфраструктуру. Поэтому часть новых сервисов запускается не в качестве полностью независимых финтех-продуктов, а внутри существующих экосистем или совместно с лицензированными организациями.

Такая модель позволяет сосредоточиться на собственной продуктовой ценности, не пытаясь с нуля воспроизвести всю регулируемую инфраструктуру.

Какие регуляторные вопросы нужно разобрать до разработки

Ограничения возникают сразу в нескольких ключевых частях финтех-продукта.

Идентификация клиентов и контроль операций

Одна из самых очевидных зон — требования к идентификации пользователей и противодействию легализации доходов.

115-ФЗ предполагает не только проверку личности клиента. Компании должны контролировать операции, выявлять подозрительную активность и выстраивать соответствующие внутренние процедуры.

С продуктовой точки зрения это важно потому, что KYC и AML невозможно свести к одному дополнительному экрану.

Требования влияют сразу на несколько частей системы:

1. регистрацию пользователя;
2. клиентский путь;
3. набор собираемых данных;
4. интеграции с внешними системами;
5. хранение информации;
6. логику проверки операций;
7. обработку подозрительной активности.

Если такая логика появляется только в конце разработки, изменения могут затронуть значительную часть продукта.

Персональные данные

Вторая критичная зона — хранение и обработка пользовательских данных.

152-ФЗ устанавливает требования к работе с персональными данными, а Роскомнадзор публикует информацию о требованиях и нарушениях в этой области.

Для ИТ-команды это означает, что юридический вопрос довольно быстро превращается в архитектурный.

Еще до начала разработки нужно понимать:

1. какие данные действительно необходимы продукту;
2. где они будут храниться;
3. кто получит к ним доступ;
4. каким образом будет организована защита;
5. что и в каком объеме нужно логировать;
6. можно ли восстановить историю действий с данными;
7. как будут работать интеграции с внешними системами.

Если архитектура уже построена без учета этих ограничений, переделка может оказаться значительно дороже, чем первоначальное проектирование.

Платежная инфраструктура

Отдельный блок требований связан непосредственно с платежами.

В зависимости от модели продукта компании может потребоваться собственная регулируемая инфраструктура либо партнерство с организацией, которая уже обладает необходимыми лицензиями.

Для трансграничных операций дополнительно появляются требования валютного законодательства и другие ограничения.

Поэтому вопрос «как мы принимаем и проводим платеж» нужно решать не после готового MVP, а еще на этапе выбора бизнес-модели.

Именно от него могут зависеть:

1. архитектура;
2. набор партнеров;
3. сроки запуска;
4. стоимость инфраструктуры;
5. требования к безопасности;
6. состав команды;
7. операционные процессы.

Алгоритмы и автоматические решения

Еще одна зона риска связана с применением алгоритмов.

Особенно это важно там, где модель влияет на решение, имеющее прямые последствия для клиента: например, в скоринге, antifraud или других финансовых сценариях.

Чем значимее автоматическое решение, тем важнее возможность понять, почему система его приняла.

Полностью непрозрачная модель может быть эффективной технически, но создавать сложности при внутреннем контроле, аудите или взаимодействии с регулятором.

Это необходимо учитывать еще при выборе технологии, а не только после ее внедрения.

Почему попытка «добавить compliance потом» обходится дорого

Один из наиболее рискованных сценариев запуска выглядит следующим образом.

Команда сначала проектирует продукт исключительно исходя из бизнес-логики и удобства пользователя. Собирает MVP, тестирует его, готовится к релизу. Затем юристы или специалисты по compliance начинают полноценную проверку и выясняют, что часть процессов нужно перестраивать.

Например, оказывается, что выбранная схема идентификации не подходит.

Тогда нужно менять не только форму регистрации, но и клиентский сценарий, backend, интеграции и хранение данных.

Или выясняется, что персональная информация должна обрабатываться иначе. Тогда изменения затрагивают инфраструктуру.

Или платежная схема не соответствует выбранной модели работы. Тогда под вопросом оказываются уже интеграции, договорная модель и иногда сама экономика продукта.

Причина проста: в финтехе регуляторные требования находятся внутри системы, а не вокруг нее.

В разработке давно действует общий принцип: чем позже обнаружена фундаментальная проблема, тем дороже она обходится.

Классическая модель IBM System Science Institute, которую часто приводят в отрасли, показывает, что исправление дефектов после релиза может стоить значительно дороже, чем исправление на стадии проектирования.

Для финтеха этот эффект усиливается.

Здесь ошибка может одновременно быть:

1. технической;
2. архитектурной;
3. юридической;
4. операционной;
5. репутационной.

Поэтому привычное противопоставление «скорость или compliance» не совсем верно.

Иногда попытка ускориться за счет игнорирования требований приводит к тому, что релиз в итоге происходит значительно позже из-за переделок.

Что означает compliance-by-design на практике

Compliance-by-design предполагает, что требования к продукту рассматриваются одновременно с функциональными требованиями.

Это не означает, что юристы должны руководить продуктовой разработкой или определять интерфейс приложения.

Смысл подхода в другом.

Еще на этапе discovery команда должна понимать:

1. где потребуется идентификация;
2. какие данные собираются;
3. что можно хранить;
4. каким образом будут проводиться операции;
5. какие действия необходимо логировать;
6. какие события потребуется восстанавливать при проверке;
7. какие решения алгоритмов в будущем понадобится объяснять.

В результате регулирование становится одним из входных параметров проектирования наряду с бизнес-целями, технологическими ограничениями и пользовательскими требованиями.

Меняется и состав команды на ранних этапах.

Юристы и специалисты по compliance подключаются не непосредственно перед релизом, а еще во время discovery.

При этом продуктовым менеджерам и архитекторам приходится понимать базовую отраслевую специфику, потому что регулирование непосредственно влияет на продуктовые сценарии.

Разработчикам также важно знать, почему конкретный модуль должен работать определенным образом. Иначе юридическое требование легко воспринимается как формальность, которую можно упростить ради скорости.

Банк России в своих подходах к управлению рисками также рассматривает встроенные механизмы контроля и мониторинга как часть деятельности финансовых организаций.

Для продукта это означает переход от модели «сначала разработали, потом проверили» к модели постоянного контроля.

Как регулирование влияет на архитектуру финтех-продукта

Одно из практических следствий — необходимость четче разделять компоненты по уровню риска.

Платежи, идентификация, персональные данные и другие чувствительные части системы лучше отделять от пользовательского слоя и менее критичных функций.

Это дает сразу несколько преимуществ.

Во-первых, критичные компоненты проще тестировать отдельно.

Во-вторых, изменения пользовательского интерфейса не обязательно будут затрагивать регулируемую часть системы.

В-третьих, упрощаются аудит и контроль.

В-четвертых, разные части продукта можно развивать с разной скоростью.

Такая архитектура особенно полезна для сервисов, которые планируют активно развиваться после запуска.

Не всю финансовую инфраструктуру обязательно строить самостоятельно

Еще один распространенный подход — интеграция с лицензированными партнерами.

Если основная ценность продукта находится, например, в клиентском опыте, аналитике, автоматизации или дополнительном сервисе, компании не всегда имеет смысл самостоятельно создавать всю регулируемую инфраструктуру.

Часть процессов можно передать банку или другой лицензированной организации через API.

Это позволяет быстрее выйти на рынок и сократить объем собственной инфраструктуры.

Но здесь важно не впадать в другую крайность.

Партнерство не означает, что вся ответственность автоматически исчезает. Нужно четко понимать:

1. какие функции выполняет партнер;
2. за какие процессы отвечает владелец продукта;
3. какие данные передаются между сторонами;
4. где и как они хранятся;
5. кто контролирует операции;
6. кто отвечает за инциденты.

Поэтому интеграция с лицензированным игроком снижает часть нагрузки, но сама тоже требует серьезного проектирования.

Логирование становится частью продукта

Для обычного цифрового сервиса иногда достаточно понимать, состоялась операция или нет.

Для финансового продукта этого может быть недостаточно.

При споре, внутреннем расследовании или проверке необходимо восстановить всю цепочку событий:

1. кто совершил действие;
2. когда оно произошло;
3. какие данные использовались;
4. какое решение приняла система;
5. какая операция была выполнена;
6. как изменилось состояние системы.

Поэтому подробное логирование нужно закладывать в backend и инфраструктуру изначально.

Если начать добавлять его после запуска, может оказаться, что необходимой информации просто нет или она хранится в разных системах в несопоставимом виде.

Где можно сохранять высокую скорость разработки

Усиление контроля не означает, что весь финтех теперь должен развиваться медленно. Скорее продукт необходимо разделить на зоны с разным уровнем допустимого риска. Например, пользовательский интерфейс можно тестировать и улучшать короткими итерациями.

То же касается части дополнительных функций, контентных сервисов, аналитики и нефинансовых сценариев.

В этих областях по-прежнему можно активно экспериментировать:

1. проводить A/B-тесты;
2. менять интерфейс;
3. проверять гипотезы;
4. запускать новые функции;
5. быстро анализировать пользовательскую реакцию.

Совсем другая ситуация с платежами, KYC, персональными данными и критичной финансовой логикой. Здесь изменения должны проходить более строгую проверку и тестирование. Получается своеобразная модель двух скоростей.
Одна часть продукта развивается быстро и итеративно, другая — более консервативно. Такой подход позволяет одновременно сохранять скорость и контролировать риски.

MVP в финтехе тоже нужно понимать иначе

Изменение требований влияет и на само представление о минимально жизнеспособном продукте.

MVP в финтехе не может означать «пока сделаем безопасность попроще» или «регуляторику добавим во второй версии». Минимальным может быть набор функций.

Можно:

1. сократить количество пользовательских сценариев;
2. оставить только ключевую функцию;
3. отказаться от дополнительных возможностей;
4. сделать более простой интерфейс;
5. временно не запускать вторичные сервисы.

Но базовая финансовая логика должна работать корректно с первой версии. То же относится к защите данных, идентификации и другим обязательным процессам.

Поэтому хороший финтех-MVP — не продукт с упрощенной надежностью, а продукт с минимальным набором функций и полноценной критичной частью.

Почему compliance нужно считать в экономике продукта

Регулирование влияет не только на архитектуру и сроки разработки, но и на unit-экономику и общую стоимость проекта.

Есть прямые расходы:

1. лицензирование;
2. инфраструктура;
3. информационная безопасность;
4. юридическое сопровождение;
5. аудит;
6. compliance-команда.

Но есть и менее очевидные.

Например:

1. дополнительные согласования;
2. увеличение сроков разработки;
3. более сложное тестирование;
4. требования к документации;
5. постоянный мониторинг изменений;
6. стоимость обновлений критичных компонентов.

По материалам Ассоциации ФинТех, соответствие требованиям регулятора становится заметной частью нагрузки на участников финансового рынка.

Для крупной организации эти расходы могут распределяться на миллионы клиентов и большое количество продуктов.

Для небольшого бизнеса тот же объем обязательных затрат может заметно изменить экономику проекта.

Поэтому еще до начала разработки полезно задать несколько вопросов.

Насколько оправдано самостоятельно создавать всю финансовую инфраструктуру?

Какой объем операций необходим, чтобы окупить постоянные расходы?

Что можно взять у внешнего партнера?

Какие процессы обязательно должны оставаться внутри?

Иногда собственная разработка действительно дает стратегическое преимущество.

Но иногда именно попытка построить все самостоятельно делает проект экономически невыгодным.

AI помогает автоматизировать compliance, но создает новые риски

По мере роста количества операций ручной контроль становится все менее масштабируемым.

Поэтому автоматизация уже активно применяется в процессах:

1. мониторинга транзакций;
2. выявления подозрительных операций;
3. KYC;
4. antifraud;
5. анализа поведения клиентов.

AI позволяет обрабатывать больше данных и быстрее находить аномалии.

Но вместе с этим возникает новый вопрос: насколько компания понимает решения собственной модели?

Если алгоритм просто ранжирует контент, требования к объяснимости могут быть одними.

Если алгоритм влияет на доступ клиента к финансовой услуге, последствия уже гораздо серьезнее.

В материалах Банка России о применении искусственного интеллекта в финансовой сфере отдельно рассматриваются вопросы прозрачности, управляемости и доверия к таким системам.

Для бизнеса это создает дополнительный критерий выбора технологии.

Важно не только то, насколько точно работает модель, но и:

1. можно ли контролировать ее решения;
2. можно ли объяснить результат;
3. можно ли провести аудит;
4. существуют ли механизмы ручного контроля;
5. можно ли изменить или остановить работу модели.

Иными словами, эффективность алгоритма становится только одним из параметров.

Какие модели запуска остаются у бизнеса

В текущих условиях можно выделить три базовых сценария выхода на рынок.

Вариант 1. Работать через лицензированного партнера

Компания отвечает за собственный продукт, пользовательский опыт и бизнес-логику, а часть регулируемой инфраструктуры предоставляет банк или другая организация.

Плюсы такого подхода:

1. ниже порог входа;
2. меньше собственной инфраструктуры;
3. быстрее запуск;
4. часть регулируемых процессов уже существует у партнера.

Минус — зависимость от внешнего игрока и его технологий, условий и процессов.

Кроме того, компании все равно необходимо четко разделять зоны ответственности.

Вариант 2. Создать сервис вокруг финансовой инфраструктуры

Не каждый финтех-продукт обязан самостоятельно проводить платежи.

Продуктовая ценность может находиться в:

1. аналитике;
2. автоматизации;
3. управлении финансами;
4. клиентском интерфейсе;
5. дополнительных сервисах;
6. инструментах для бизнеса.

В таком случае компания может сознательно не заходить в наиболее регулируемые части цепочки.

Это снижает нагрузку и позволяет быстрее проверять бизнес-гипотезу.

Вариант 3. Строить собственную регулируемую инфраструктуру

Самый сложный вариант — самостоятельно получить необходимые разрешения и создать собственную инфраструктуру. Это требует больше времени и инвестиций, но дает максимальный контроль. Такой путь оправдан, если именно финансовая инфраструктура является ядром бизнес-модели и компания рассчитывает работать с ней на большом масштабе. Часто используется гибридная схема. Часть компонентов остается собственной, а часть закрывается с помощью партнеров.

Чек-лист перед началом разработки финтех-продукта

Чтобы не обнаруживать критичные ограничения после готового MVP, стоит пройти несколько этапов еще до старта основной разработки.

1. Провести регуляторную оценку

Нужно определить, какие требования затрагивают конкретный продукт.

В зависимости от модели это могут быть:

1. 115-ФЗ;
2. 152-ФЗ;
3. требования Банка России;
4. валютное законодательство;
5. требования к платежным операциям;
6. дополнительные отраслевые нормы.

Отдельно стоит выделить самые рискованные пользовательские сценарии.

Обычно это:

1. идентификация;
2. платежи;
3. хранение персональных данных;
4. скоринг;
5. автоматические решения;
6. трансграничные операции.

Результатом этого этапа должна быть не просто юридическая справка, а список конкретных ограничений для продукта.

2. Определить модель выхода на рынок

Далее нужно решить, какой объем инфраструктуры компания готова строить самостоятельно.

Полезно сравнить несколько сценариев:

1. собственная инфраструктура;
2. партнерство с лицензированной организацией;
3. запуск без наиболее регулируемых финансовых функций;
4. гибридная модель.

Сравнивать стоит не только стоимость первоначального запуска, но и дальнейшее развитие.

3. Подключить юристов и compliance к discovery

Если специалисты по регулированию впервые видят продукт непосредственно перед релизом, команда уже лишается большей части пространства для маневра. На discovery решения еще относительно дешевы.

Можно изменить:

1. пользовательский сценарий;
2. архитектуру;
3. интеграции;
4. набор данных;
5. бизнес-модель.

После нескольких месяцев разработки те же изменения стоят значительно дороже. Поэтому юридическая и продуктовая работа должны идти параллельно.

4. Посчитать полную стоимость соответствия требованиям

Бюджет продукта должен учитывать не только стоимость дизайна и разработки.

Нужно добавить:

1. лицензирование;
2. инфраструктуру;
3. безопасность;
4. аудит;
5. юридическую поддержку;
6. эксплуатацию;
7. мониторинг;
8. обновление документации;
9. изменение критичных модулей.

Только после этого можно корректно сравнивать собственную разработку с партнерской моделью.

5. Разделить архитектуру по зонам риска

Компоненты, связанные с платежами, данными и идентификацией, желательно отделить от частей продукта, которые планируется активно менять.

Это позволит:

1. тестировать их отдельно;
2. применять разные процессы релиза;
3. уменьшить количество зависимостей;
4. упростить аудит;
5. быстрее развивать пользовательскую часть.

Если продукт использует AI, дополнительно стоит определить требования к контролируемости и объяснимости модели.

Что делать после релиза

Даже хорошо спроектированный compliance-процесс нельзя настроить один раз и больше к нему не возвращаться. Законодательство меняется. Меняется сам продукт. Появляются новые партнеры, API, функции и способы обработки данных. Поэтому после запуска нужен регулярный процесс контроля.

Отдельно тестировать критичные части продукта

Платежи, KYC и другие чувствительные модули требуют более строгого контроля, чем обычные продуктовые функции. У них может быть свой цикл тестирования и выпуска изменений.

Автоматизировать повторяющиеся compliance-процессы

Там, где это возможно, имеет смысл автоматизировать:

1. проверки;
2. мониторинг операций;
3. подготовку отчетности;
4. уведомления;
5. анализ подозрительной активности.

Но автоматизация не должна превращать процесс в неконтролируемый черный ящик.

Регулярно пересматривать внешние интеграции

Если критичная функция передана партнеру, компания должна понимать, как изменения у этого партнера влияют на ее собственный продукт. API, правила обработки данных и зона ответственности могут со временем меняться.

Следить за требованиями регуляторов

Compliance — не только задача перед запуском.

Нужно регулярно отслеживать:

1. новые требования;
2. рекомендации Банка России;
3. изменения законодательства;
4. практику Роскомнадзора;
5. новые требования к отдельным технологиям.

При существенных изменениях необходимо повторно оценивать архитектуру и процессы.

Проводить внутренние проверки

Полезно периодически смотреть на собственный продукт так, будто его проверяет внешний аудитор.

Можно ли восстановить историю операции?

Понятно ли, кто получил доступ к данным?

Есть ли ответственные за критичные процессы?

Актуальна ли документация?

Можно ли объяснить автоматическое решение?

Такая проверка позволяет находить проблемы до того, как они превращаются в инциденты.

Подготовить сценарий на случай нарушения

Еще до возникновения проблемы должно быть понятно:

1. кто фиксирует инцидент;
2. кому он эскалируется;
3. кто принимает решение;
4. кто взаимодействует с регулятором;
5. какие данные необходимо сохранить;
6. какие системы нужно проверить;
7. какие действия предпринимаются дальше.

Такой план можно периодически проверять на симуляциях.

Например, смоделировать запрос регулятора или внутреннее расследование и посмотреть, насколько быстро команда сможет собрать необходимую информацию.

Что все это меняет для бизнеса

Финтех становится все менее подходящим рынком для стратегии «сначала быстро запустимся, потом достроим фундамент». Требования к надежности, данным, платежам и контролю слишком глубоко встроены в продукт. Поэтому цена неправильного решения на старте растет. Но усиление регулирования не обязательно нужно воспринимать исключительно как барьер. Оно заставляет компании раньше отвечать на вопросы, которые все равно пришлось бы решать при масштабировании.

Где проходит граница ответственности?

Кто контролирует операции?

Как защищаются данные?

Как продукт будет проходить аудит?

Какие решения можно объяснить?

Насколько архитектура выдержит рост бизнеса?

Если компания отвечает на эти вопросы до разработки, результатом становится не только более безопасная система. Такой продукт проще масштабировать, интегрировать с партнерами, поддерживать и развивать. Compliance постепенно превращается из последней проверки перед релизом в один из элементов продуктового проектирования. И в 2026 году преимущество получает не обязательно команда, которая быстрее остальных собрала первую версию. Гораздо важнее то, сможет ли эта версия выйти на рынок, пройти необходимые проверки и развиваться дальше без необходимости через год переписывать фундамент продукта.