Финтех под надзором: как запускать продукты, когда регулирование становится частью архитектуры

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

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

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

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

Финтех больше не рынок, где можно сначала запуститься, а потом разобраться

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

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

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

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

Что нужно учитывать еще до проектирования продукта

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

Одна из основных зон — идентификация клиентов и противодействие легализации доходов. 115-ФЗ требует не только идентифицировать пользователей, но и контролировать операции, выявлять подозрительную активность и выстраивать соответствующие внутренние процессы.

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

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

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

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

Еще одна растущая зона риска — алгоритмы. Особенно если они используются в скоринге, antifraud-системах или влияют на доступ пользователя к финансовым услугам. Чем важнее решение, которое принимает модель, тем выше требования к возможности объяснить, почему оно было принято.

Почему compliance нельзя оставлять на конец разработки

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

Исправить несколько экранов в таком случае недостаточно.

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

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

В финтехе к технической цене ошибки добавляется юридическая.

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

Compliance-by-design: сначала ограничения, потом код

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

Это не значит, что юристы должны определять продуктовую стратегию. Речь о другом: еще во время discovery команда должна понимать, какие действия пользователя требуют идентификации, какие данные можно собирать и хранить, какие операции необходимо логировать и какие решения в будущем придется объяснять аудитору или регулятору.

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

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

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

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

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

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

Одновременно бизнес все чаще использует инфраструктуру лицензированных партнеров.

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

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

Еще один обязательный элемент — подробное логирование.

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

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

Где все еще можно двигаться быстро

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

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

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

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

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

По этой же причине меняется смысл MVP.

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

Регулирование влияет не только на разработку, но и на экономику проекта

Compliance стоит денег.

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

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

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

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

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

Иногда собственная разработка оправдана. Иногда разумнее встроиться в существующую финансовую экосистему.

Что меняется с появлением AI

Автоматизация помогает компаниям справляться с растущим объемом compliance-задач.

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

Но вместе с эффективностью AI приносит новый тип риска.

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

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

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

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

У бизнеса остается несколько вариантов выхода на рынок.

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

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

Третий — собственная лицензия и инфраструктура. Это более дорогой и долгий путь, но он дает компании больше контроля над продуктом и его экономикой.

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

Что проверить до начала разработки

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

1. Разобраться с регуляторикой

Нужно определить, какие нормы вообще относятся к продукту: 115-ФЗ, 152-ФЗ, валютное законодательство, требования Банка России и другие отраслевые документы.

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

2. Выбрать модель выхода на рынок

Не стоит автоматически считать, что всю инфраструктуру нужно создавать самостоятельно.

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

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

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

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

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

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

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

5. Спроектировать критичные зоны отдельно

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

Одновременно нужно предусмотреть логирование, аудит действий и возможность восстановить историю операций.

Если используются AI-модели, стоит заранее проверить, можно ли объяснить принимаемые ими решения.

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

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

Поэтому компании нужен постоянный процесс контроля.

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

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

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

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

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

Финтех постепенно перестает быть территорией экспериментов по принципу «запустимся сейчас, инфраструктуру достроим потом».

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

Для бизнеса это не обязательно плохая новость.

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

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

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

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