Почему ИИ в платежах упирается в модернизацию core

Большинство банков пытаются «прикрутить» искусственный интеллект к платежам и антифроду поверх того, что уже есть: мэйнфрейм, монолитный core banking, десятки интеграций и пакетные окна. В итоге ИИ получается «умным калькулятором на коротком поводке»: данных не хватает, скорость не та, а регуляторные требования по управлению рисками и зависимостями только усиливают давление.

Реальность такая: ИИ в платёжной инфраструктуре растёт не от количества моделей, а от качества фундамента — архитектуры, данных, процессов релизов и способности системы жить в реальном времени. Я видел, как команды годами спорят про выбор фреймворка для ML, пока основная проблема лежит внизу: старый core не даёт безопасно и быстро подключать новые сценарии.

Этот материал — часть серии «Искусственный интеллект в банковской инфраструктуре и платёжных системах». Разберём, какие стратегии модернизации core и мэйнфрейма действительно работают, как сочетать их поэтапно и почему это напрямую влияет на эффективность ИИ в антифроде, мониторинге транзакций и оптимизации платёжных маршрутов.

«Ловушка банковских технологий»: почему ИИ не взлетает на легаси

Короткий ответ: легаси-системы ограничивают ИИ тремя вещами — доступом к данным, скоростью изменений и управляемостью рисков.

1) Данные есть, но «не здесь и не сейчас»

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

• закрыты в форматах и схемах, которые сложно «отдать наружу»;
• доступны только через тяжёлые интеграции или отчётные витрины;
• обновляются пакетно (batch), а не потоково.

ИИ-модель, обученная на «вчерашних» данных, в антифроде даёт предсказуемый эффект: либо растут потери, либо растёт false positive и блокируются хорошие клиенты.

2) Скорость релизов не соответствует скорости угроз

Мошеннические схемы в платежах меняются быстро. Практика 2025 года: антифрод-правила и ML-скоры должны обновляться часто, иногда ежедневно. Если core и окружающие системы требуют долгих циклов тестирования, ручных выкладок и редких «окон», ИИ становится заложником процесса.

3) Регуляторика и IT‑риски усиливают «тормоза»

Финансовый сектор живёт под постоянным контролем IT‑рисков и зависимостей от поставщиков. Чем сложнее и старше стек, тем труднее:

• доказать контролируемость изменений;
• обеспечить наблюдаемость (audit trail, трассировка);
• управлять третьими сторонами и облачными компонентами.

Вывод: модернизация core — это не ИТ‑каприз, а условие, чтобы ИИ в платежах стал управляемым, масштабируемым и проверяемым.

Три стратегии модернизации: что выбрать, чтобы открыть дорогу ИИ

Короткий ответ: не существует «единственно правильной» миграции. Почти всегда нужен микс подходов — параллельно и поэтапно.

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

1) Оптимизация «на месте»: быстрое снижение боли без больших переделов

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

Что обычно даёт эффект в платежной и core‑части:

• тонкая настройка конфигураций, оптимизация online и batch нагрузок;
• рационализация пакетных процессов (сокращение окон, перенос части задач);
• оптимизация доступа к данным (индексы, кэширование, сокращение тяжёлых запросов);
• пересмотр контрактов с вендорами и консолидация лицензий;
• частичный аутсорс конкретных компонентов;
• MFaaS (mainframe as a service) как способ получить предсказуемую модель затрат и обновлений.

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

Практический пример сценария

Банк хочет добавить ML‑скоринг на этапе авторизации платежа, но боится задержек. Оптимизация на месте позволяет:

• уменьшить время ответа core за счёт рационализации запросов;
• высвободить ресурс под вызовы скоринга;
• стабилизировать пиковые периоды (зарплатные дни, распродажи, новогодний сезон).

2) Изофункциональная модернизация: меняем технологию, не меняя продукт

Короткий ответ: это самый «прагматичный» путь: функциональность прежняя, а технологическая база становится пригодной для облака, DevSecOps и ИИ-интеграций.

Read off-loading: вынести чтение в облако

Суть: высоконагруженное чтение (например, справки, статусы, истории, часть витрин для антифрода) переносится в облачную инфраструктуру, а критические записи (write) остаются на легаси.

Что это даёт для платежей и ИИ:

• меньше нагрузка на дорогие транзакционные контуры;
• проще подключать real-time аналитические сервисы;
• удобнее развивать витрины фрод‑сигналов и профили клиентов.

Ключевой вопрос — репликация и синхронизация данных. Для антифрода задержка в секунды иногда допустима, а иногда — нет. Поэтому заранее определяют классы данных: какие должны быть строго консистентны, а какие могут быть «почти real-time».

Re-platforming (lift-and-shift): перенести как есть, но в новый runtime

Суть: запуск существующего кода в эмулированных/совместимых средах на более гибкой инфраструктуре.

Плюсы для ИИ и платежей:

• быстрое снижение стоимости вычислений и рост эластичности;
• появление современных практик DevSecOps;
• упрощение интеграций через события и API.

Риски и «грабли»:

• недооценка сложности пакетного планирования;
• необходимость параллельного прогона (parallel run) и корректного сравнения результатов;
• дисциплина наблюдаемости и управления инцидентами.

Refactoring: переписать код (например, COBOL → Java/Python)

Суть: переписывание легаси в современные языки и архитектуры.

Почему в 2025 это стало реальнее:

• генеративный ИИ помогает ускорять анализ кода, извлечение бизнес‑правил, генерацию тестов;
• «копилот»-инструменты повышают производительность разработчиков;
• автоматизированные конверторы стали заметно лучше по качеству выходного кода и сопровождению.

Но я бы занял жёсткую позицию: переписывание ради переписывания — дорого и опасно. Refactoring оправдан, когда:

• бизнес‑логика мешает запускать новые платёжные продукты;
• требуется высокая скорость изменений;
• есть план по декомиссии и архитектурная посадочная площадка.

3) Функциональная трансформация: когда нужен выход из легаси

Короткий ответ: если core не тянет стратегию (скорость вывода продуктов, комплаенс, новые каналы), придётся менять не только технологию, но и модель работы.

Собственная разработка (custom-built)

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

Где ИИ даёт максимальную отдачу:

• генерация тестов и контрактов API;
• выявление дублирующейся логики;
• ускорение разработки сервисов, которые «кормят» антифрод событиями.

Пакетное решение (vendor package)

Современные вендоры чаще предлагают компонентные (composable) возможности: не обязательно менять core целиком.

Что проверить до выбора:

• сколько версий нужно «перепрыгнуть» при апгрейде;
• насколько кастомизирована текущая инсталляция;
• есть ли зрелые API и событийная модель под платёжные сценарии.

Greenfield: новый цифровой бренд на новом стеке

Это хороший вариант, когда нужно быстро запустить продукт без «хвоста» легаси. Для ИИ в платежах greenfield часто становится полигоном:

• real-time фрод‑скоринг «по умолчанию»;
• аналитика маршрутизации платежей;
• интеллектуальная обработка спорных операций.

Side core: новый core рядом со старым

Прагматичный путь для крупных банков: новые продукты запускаются на новом core, старый обслуживает «тяжёлое наследие». Дальше — постепенная миграция.

Критические задачи:

• выделить общие функции (клиент, лимиты, справочники);
• настроить оркестрацию и «сосуществование»;
• не допустить двойных источников истины.

Core as a service

Модель взрослеет и всё чаще рассматривается не только малыми игроками. Для ИИ преимущество очевидно: быстрее интеграции и масштабирование. Минус — зрелость и контроль зависимостей нужно проверять особенно тщательно.

Интероперабельность и composable-архитектура: «клей», без которого всё развалится

Короткий ответ: чтобы ИИ работал в платежах, нужен слой, который обеспечивает сосуществование легаси и новых сервисов без хаоса.

Это и есть посадочная архитектура интероперабельности/компонуемости:

• декуплинг слоёв (каналы, платежные сервисы, core, данные);
• стандартизированные API и события;
• оркестрация сервисов (когда порядок важен) и хореография (когда важны события);
• единые абстракции для кросс‑продуктовых функций.

Для ИИ это не теория. Это практическая возможность:

• подключить антифрод как сервис к нескольким платёжным потокам;
• получать единый поток событий для обучения моделей;
• объяснять решения (traceability) и упрощать аудит.

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

Как начать: думайте широко, но стартуйте с малых ставок

Короткий ответ: начинайте с доменов, где ИИ даст измеримый эффект, а модернизация минимально рискованна.

Шаг 1. Зафиксируйте «северную звезду» вне ИТ

Не «переехать в облако», а, например:

• снизить потери от мошенничества на X% при сохранении конверсии;
• сократить время вывода платёжных изменений с месяцев до недель;
• обеспечить 24/7 без больших batch‑окон.

Шаг 2. Разложите core на домены и выберите паттерн на домен

Обычно получается микс:

• где-то оптимизация на месте;
• где-то read off-loading;
• где-то side core;
• и обязательный план декомиссии по мере миграции.

Шаг 3. Встройте ИИ-сценарии в дорожную карту, а не «после»

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

1. Real-time фрод‑скоринг на авторизации с жёсткими SLA.
2. Интеллектуальный мониторинг аномалий (drift моделей, всплески отказов, инциденты интеграций).
3. Оптимизация маршрутизации транзакций (стоимость/скорость/успешность) на основе данных.

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

Что спросит руководитель (и что отвечать)

«Можно ли внедрить ИИ в платежах без модернизации core?»

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

«Что выбрать: переписать или заменить на пакет?»

Выбирайте от стратегии. Если важна дифференциация и скорость продуктовых экспериментов — custom/side core. Если важнее стандартизация и предсказуемость — пакет. В обоих случаях интероперабельность должна быть заложена с первого дня.

«Где самый быстрый ROI?»

Часто — в связке:

• read off-loading для данных,
• улучшение релизного контура (DevSecOps),
• и запуск антифрод‑кейса, который сразу виден бизнесу.

Что делать дальше

Модернизация мэйнфрейма и core banking — это момент, когда банк решает: ИИ в платежах будет «надстройкой» или станет частью инфраструктуры, которая реально снижает риски и повышает эффективность. Я ставлю на второе, потому что мошенники и ожидания клиентов не ждут.

Если вы планируете ИИ для антифрода, мониторинга транзакций или оптимизации платёжных операций, начните с простой проверки: ваш core способен отдавать события и данные в реальном времени и принимать изменения без многомесячных циклов? Если нет — дорожная карта модернизации уже не «про потом», а про 2026.