Еще несколько лет назад финтех часто воспринимали как отдельную категорию: банковские приложения, переводы, онлайн-эквайринг, кошельки, карты. Для большинства компаний это выглядело как вспомогательная функция. Есть сайт, есть товар, есть клиент, значит нужно просто подключить оплату и не трогать лишнее.
Сейчас такой подход уже плохо работает. Деньги проходят через продукт почти на каждом этапе: регистрация клиента, оплата заказа, возврат, начисление бонусов, выплата партнеру, проверка риска, отчетность, поддержка. Даже если компания не считает себя финтехом, внутри нее все равно появляется финансовая логика. Чем больше операций, тем заметнее становится разница между «у нас есть оплата» и «у нас нормально устроены платежи».
Это особенно видно в рознице, маркетплейсах, сервисах по подписке, логистике, B2B-платформах и продуктах для малого бизнеса. Клиент ожидает, что платеж пройдет быстро, статус будет понятным, возврат не превратится в переписку с поддержкой, а способ оплаты можно будет выбрать без лишних действий. Для бизнеса это уже вопрос не удобства, а операционной устойчивости.
Почему обычного подключения оплаты уже мало
Подключить платежную форму сравнительно просто. Сложность начинается дальше. Что происходит после оплаты? Как заказ связывается с платежом? Где виден статус возврата? Что делать, если операция зависла? Как поддержка понимает, что именно произошло? Как бухгалтерия собирает данные? Как система отличает обычную активность клиента от подозрительной?
Если эти вопросы решаются вручную, продукт быстро начинает тормозить. На небольшом объеме это еще можно не замечать. Один сотрудник проверит спорный платеж, другой выгрузит отчет, третий напишет клиенту. Но при росте заказов ручная схема превращается в источник ошибок. Появляются задержки, повторные обращения в поддержку, путаница в статусах, расхождения в отчетах и лишняя нагрузка на команду.
Представим маркетплейс. Покупатель оплачивает заказ, площадка удерживает комиссию, продавец получает выплату, часть суммы может быть возвращена, а где-то еще нужно учесть бонусы, промокод или оплату частями. Это уже не одна транзакция, а цепочка связанных действий. Если платежная часть не встроена в платформу, команда будет постоянно «склеивать» данные между личным кабинетом, банком, CRM, бухгалтерией и службой поддержки.
Поэтому современная финтех-инфраструктура начинается не с красивой кнопки «Оплатить». Она начинается с понимания того, как деньги движутся внутри продукта и какие события должны происходить автоматически.
Что изменилось на российском рынке платежей
Российский рынок уже довольно далеко ушел от модели, где карта была единственным понятным цифровым способом оплаты. По данным Банка России, по итогам 2025 года доля безналичных платежей в розничном обороте составила 88%. На 1 января 2026 года в национальную платежную систему входили 31 платежная система и 353 оператора по переводу денежных средств.
Продолжает расти и внутренняя платежная инфраструктура. На 1 января 2026 года было выпущено 476,5 млн карт «Мир». К 1 мая 2026 года через Систему быстрых платежей прошло 49,1 млрд операций на сумму 259,7 трлн рублей.
Для пользователя все это выглядит просто: перевод по номеру телефона, QR-код, оплата через приложение, мгновенное уведомление. Для бизнеса за этой простотой стоит другое требование. Платежный путь должен быть быстрым, понятным и устойчивым. Если клиент не понимает, прошла ли оплата, где его возврат или почему операция не завершилась, он воспринимает это как проблему продукта, а не как техническую особенность банка или провайдера.
Отсюда появляется новая задача: платежная архитектура должна быть гибкой. Компании нужно быть готовой подключать новые способы оплаты, менять провайдеров, добавлять сценарии возвратов, учитывать комиссии, поддерживать разные роли пользователей и при этом не ломать основной продукт.
Цифровой рубль и универсальный платежный код: зачем думать об этом заранее
Цифровой рубль пока не стал массовым платежным инструментом для бизнеса, но его уже нельзя воспринимать как далекую экспериментальную тему. Банк России связывает его внедрение с поэтапным подключением банков и торговых компаний. Для крупных участников рынка требования начнут действовать раньше, для остальных переход будет растянут во времени.
Это не значит, что бизнесу нужно срочно перестраивать все платежи. Но уже сейчас стоит проверить, насколько текущая система вообще готова к появлению новых типов операций. Вопрос не только в том, появится ли новый способ оплаты в интерфейсе. Вопрос в учете, сверке, возвратах, правах доступа, отчетности и поддержке.
Похожая история с универсальным платежным кодом. Его смысл в том, чтобы упростить оплату без карт и дать пользователю доступ к разным вариантам платежа через единую точку входа. Для продавца или цифровой платформы это звучит удобно, но технически требует нормальной платежной архитектуры. Если каждый новый способ оплаты добавляется через отдельную «заплатку», со временем продукт становится тяжелым в поддержке.
Гибкость здесь важнее количества функций. Хорошая система должна позволять добавлять новые платежные сценарии без полной переделки оформления заказа, личного кабинета и отчетности.
Антифрод стал частью пользовательского опыта
Чем быстрее проходят платежи, тем меньше времени остается на ручную проверку. Поэтому защита от мошенничества больше не может быть отдельным процессом, который живет где-то после операции. Она должна работать в момент действия пользователя.
С 1 января 2026 года Банк России расширил список признаков мошеннических переводов с 6 до 12. Банки должны проверять операции клиентов по этим признакам и предотвращать подозрительные переводы. Для финтех-продуктов это важный сигнал: рынок движется к более раннему выявлению риска.
На практике это касается не только банков. Маркетплейс сталкивается с подозрительными возвратами и попытками обхода правил. Сервис доставки видит нестандартные выплаты. Кошелек или платежное приложение должно отслеживать новые устройства, необычные суммы, резкую смену поведения, частые переводы и странные цепочки операций.
Хороший антифрод не должен мешать нормальному клиенту. Если система слишком жесткая, она будет блокировать обычные действия и портить конверсию. Если слишком мягкая, бизнес получит убытки и репутационные риски. Поэтому антифрод все чаще проектируют как часть продуктовой логики: он учитывает контекст операции, историю пользователя, устройство, сумму, скорость действий и тип сценария.
Где искусственный интеллект действительно полезен
ИИ в финтехе звучит модно, но сам по себе он ничего не исправляет. Он полезен там, где есть много данных, повторяющиеся решения и понятные правила проверки результата.
Например, система может анализировать платежное поведение и замечать отклонения раньше человека. Она может помогать службе поддержки быстрее находить причину спорной операции. Может ускорять обработку документов, предварительно оценивать риск клиента, подсвечивать странные действия в личном кабинете или помогать финансовой команде находить ошибки в данных.
Но есть важное условие: данные должны быть нормальными. Если статусы платежей хранятся в разных местах, возвраты описаны вручную, события не связаны между собой, а история действий неполная, ИИ будет работать с шумом. В лучшем случае он даст мало пользы. В худшем начнет создавать уверенные, но неверные выводы.
Поэтому внедрение ИИ в финтехе начинается не с модели, а с архитектуры данных. Нужно понимать, какие события собираются, как они связаны, кто имеет к ним доступ, где хранится история изменений и как команда проверяет результат автоматического решения.
Блокчейн: не универсальный ответ, а инструмент для конкретных случаев
Блокчейн часто пытаются применить там, где достаточно обычной базы данных. Если процесс полностью контролирует одна компания, участники доверяют одному оператору, а запись не нужно независимо проверять нескольким сторонам, классическая архитектура обычно проще, дешевле и быстрее.
Но есть сценарии, где блокчейн действительно дает смысл. Например, когда несколько участников должны видеть одну и ту же историю операций, а изменение записи задним числом недопустимо. Это может быть токенизация активов, расчеты между участниками цепочки поставок, смарт-контракты, подтверждение прав, прозрачные выплаты или цифровые кошельки.
Главный вопрос здесь простой: какую измеримую проблему решает блокчейн? Если он снижает споры, ускоряет расчеты, повышает прозрачность или автоматизирует условия сделки, его стоит рассматривать. Если задача сводится к обычному хранению данных, лишняя сложность только увеличит стоимость разработки и поддержки.
Что нужно продумать до запуска финтех-продукта
Финтех-продукт сложно «дособрать» после запуска, если базовая логика была спроектирована неправильно. Особенно это касается проверки клиентов, контроля операций, отчетности, журналов действий, ролей пользователей, хранения данных и безопасности.
На старте такие вещи часто кажутся второстепенными. Команда хочет быстрее выпустить интерфейс, показать личный кабинет, подключить оплату, открыть доступ первым пользователям. Это понятно, но именно здесь чаще всего появляется технический долг. Потом выясняется, что возвраты трудно связать с заказами, поддержка не видит историю действий, отчеты собираются вручную, роли доступа слишком широкие, а проверка клиентов мешает уже работающему сценарию.
Правильнее начинать с карты финансовых процессов. Нужно описать, как проходит оплата, кто участвует в операции, какие статусы возможны, где может возникнуть ошибка, как обрабатывается возврат, какие данные нужны поддержке, какие действия должны попадать в журнал, какие проверки выполняются до завершения операции.
Такой подход выглядит менее эффектно, чем быстрый дизайн интерфейса, зато он экономит много времени на этапе роста. Когда финансовая логика понятна заранее, продукт проще масштабировать, подключать новых провайдеров, добавлять способы оплаты, менять тарифы, выходить на новые рынки и проходить проверки.
Финтех перестал быть отдельной функцией бизнеса
Финтех уже нельзя рассматривать как отдельный модуль, который живет рядом с продуктом. Для многих компаний он становится частью операционной системы бизнеса. Через него проходят деньги, данные, клиентские действия, риски, отчеты и новые источники дохода.
Для розничной торговли это скорость оплаты и понятные возвраты. Для маркетплейса это управление расчетами между покупателями, продавцами и платформой. Для малого бизнеса это автоматизация счетов, платежей и отчетности без большой финансовой команды. Для банков и финансовых компаний это конкурентоспособность, безопасность и готовность к новым требованиям. Для логистики и B2B-сектора это прозрачные расчеты, меньше ручных согласований и меньше ошибок в документах.
В конечном счете финтех важен не потому, что это технологический тренд. Он важен потому, что деньги внутри цифрового продукта должны двигаться предсказуемо. Клиент должен понимать, что происходит с его платежом. Команда должна видеть, где возникла ошибка. Бизнес должен контролировать комиссии, возвраты, риски и отчетность.
Компании, которые заранее выстраивают такую архитектуру, получают не просто набор платежных функций. Они получают больше контроля над продуктом и меньше хаоса в ежедневных операциях. На рынке, где клиент привык к быстрым и понятным цифровым сервисам, это уже становится нормальным требованием.
