Как бороться с архитектурным выбросом: когда ИИ в разных каналах даёт разные ответы
В 2025—2026 годах банки столкнулись с неприятной закономерностью: клиент задаёт один и тот же запрос, а система отвечает по-разному. В мобильном приложении — одобрение, в офисе — отказ, у партнёра по API — ещё одна версия решения. Формально всё работает: скоринг считается, антифрод срабатывает, профили подтягиваются. Но на практике возникает «архитектурный выброс» — ситуация, когда логика в разных каналах расходится настолько, что предсказать итоговое решение невозможно.
URL скопирован в буфер обмена!
Согласно статистике, только за первые 9 месяцев 2025 года граждане подали около 280 тысяч жалоб на финансовые услуги — максимальное значение за последние семь лет. Жалобы на банки выросли на 21%, и значительная часть касается отказов в операциях и «необъяснимых» блокировок. Это следствие не только ужесточения комплаенса, но и того, что внутри банковских систем слишком много разрозненной логики и конфликтующих правил.
Причина в том, что цифровая инфраструктура финансовых организаций развивалась фрагментарно: ИИ-модули внедряли точечно, скоринговые модели обновляли по отдельности, антифрод строили параллельно с KYC. В итоге каждая система формирует своё «представление» о клиенте — и это представление меняется в зависимости от канала.
Причина в том, что цифровая инфраструктура финансовых организаций развивалась фрагментарно: ИИ-модули внедряли точечно, скоринговые модели обновляли по отдельности, антифрод строили параллельно с KYC. В итоге каждая система формирует своё «представление» о клиенте — и это представление меняется в зависимости от канала.
- Для клиента это выглядит как хаос.
- Для банка — как риски, жалобы и проверки.
- Для регулятора — как отсутствие управляемости.
1
Причина 1. Разные правила в разных системах
Архитектурный выброс почти всегда начинается там, где логика разнесена по разным продуктам и командам. Скоринг живёт в одном модуле, антифрод — в другом, правила KYC — в третьем, а транзакционный мониторинг использует собственный набор параметров. Формально всё работает корректно, но вместе они образуют хаотичный набор правил, которые не знают друг о друге.
Отсюда — типичные сценарии:
Для банка — как репутационный риск: такие случаи легко попадают в жалобы и проверки.
Проблема не в конкретной ошибке, а в самой механике: когда правила разнесены «по коробочкам», они неизбежно расходятся.
Что меняет СПР или любая единая архитектура решений?
Единый центр принятия решений позволяет хранить правила, модели и параметры в одном месте, а значит — использовать их одинаково во всех каналах.
Что это даёт:
Отсюда — типичные сценарии:
- мобильное приложение использует старую версию скоринга, потому что обновление еще не дошло до фронта;
- офисный сотрудник запускает проверку по правилам, которые были переписаны месяц назад, но система их не подтянула;
- партнёр по API получает решение на основании иной логики, потому что подключён к отдельному контуру.
Для банка — как репутационный риск: такие случаи легко попадают в жалобы и проверки.
Проблема не в конкретной ошибке, а в самой механике: когда правила разнесены «по коробочкам», они неизбежно расходятся.
Что меняет СПР или любая единая архитектура решений?
Единый центр принятия решений позволяет хранить правила, модели и параметры в одном месте, а значит — использовать их одинаково во всех каналах.
Что это даёт:
- одна логика для приложения, офиса, API и внутренних процессов — клиент получает одинаковый ответ независимо от точки входа;
- изменения вносятся один раз, без ручной синхронизации между командами;
- исчезают расхождения между версиями правил, которые часто становятся причиной ошибочных отказов;
- регуляторный комплаенс становится контролируемым, потому что каждая проверка проходит через единый контур.
2
Причина 2. Несогласованные данные
Даже при едином наборе правил решения будут расходиться, если системы опираются на разные данные. Это одна из главных причин архитектурного выброса — и самая незаметная в ежедневной работе.
Внутри банка данные о клиенте редко хранятся в одном месте. Приложение подтягивает информацию из фронтовой базы, отдел рисков — из хранилища, транзакционный мониторинг — из собственной витрины, а антифрод ориентируется на события, которые обновляются с задержкой. В результате один и тот же клиент имеет несколько версий профиля:
Отсюда и эффекты:
Что даёт единый контур данных?
Когда банк выстраивает общий слой данных - не формально, а в реальной операционке - архитектурный выброс снижается в разы.
Что меняется:
Внутри банка данные о клиенте редко хранятся в одном месте. Приложение подтягивает информацию из фронтовой базы, отдел рисков — из хранилища, транзакционный мониторинг — из собственной витрины, а антифрод ориентируется на события, которые обновляются с задержкой. В результате один и тот же клиент имеет несколько версий профиля:
- в CRM — устаревший адрес;
- в KYC — другая дата обновления паспорта;
- в антифроде — неполный перечень устройств;
- в транзакционном мониторинге — часть операций отсутствует из-за задержек.
Отсюда и эффекты:
- приложение видит клиента как «зелёного»,
- фронт-офис — как «серого»,
- риск-модуль — как «повышенного риска».
Что даёт единый контур данных?
Когда банк выстраивает общий слой данных - не формально, а в реальной операционке - архитектурный выброс снижается в разы.
Что меняется:
- у всех каналов появляется одна версия профиля клиента;
- данные обновляются синхронно, а не с разницей в часы или дни;
- системы больше не принимают решение «в слепую», потому что видят одинаковую картину;
- исчезают противоречия, которые раньше приводили к отказам и жалобам.
3
Причина 3. Нет единого процесса тестирования и релизов
Даже если правила и модели написаны корректно, архитектурный выброс всё равно появляется там, где отсутствует централизованный процесс тестирования. Это незаметная, но критическая причина расхождений между каналами.
Как работает во многих компаниях сегодня:
Из-за этого в продакшн попадают несовместимые изменения:
Что меняет единый процесс тестирования в архитектуре решений?
Когда компания выстраивает общий контур релизов, исчезает сама возможность случайных расхождений:
Как работает во многих компаниях сегодня:
- каждое подразделение тестирует только свой участок логики;
- мобильное приложение проверяет пользовательский сценарий,
- антифрод — свои триггеры,
- риски — модель,
- транзакционный мониторинг — операции,
- API-партнёры — только свой канал.
Из-за этого в продакшн попадают несовместимые изменения:
- в офисе обновили правила,
- в приложении — пороги,
- в антифроде — логику,
- а интеграционный канал остался на прошлой версии.
Что меняет единый процесс тестирования в архитектуре решений?
Когда компания выстраивает общий контур релизов, исчезает сама возможность случайных расхождений:
- все изменения проходят через единый стенд, а не отдельные тестовые среды;
- правила, пороги и модели тестируются в наборе типовых клиентских сценариев, а не точечно;
- каналы приводятся к одной версии логики, прежде чем обновление уходит в продакшн;
- возврат на предыдущую версию возможен за минуты, а не недели.
Последствия для бизнеса
Архитектурный выброс — это не техническая мелочь, а управленческий риск, который напрямую влияет на клиента, на регуляторные проверки и на издержки компании.
1. Клиент получает разные ответы — падает доверие
Если в приложении перевод проходит, а в офисе блокируется, или партнёрская платформа выдаёт один лимит, а мобильный банк — другой, клиент видит не "сложность архитектуры", а отсутствие порядка.
Даже разовое несоответствие воспринимается как ошибка банка — и часто заканчивается жалобой. В 2025—2026 годах такие расхождения становятся массовыми, прежде всего из-за фрагментированной логики и параллельных изменений в разных каналах.
2. Риск претензий со стороны регулятора растёт
Непоследовательные решения — это сигнал о том, что процесс принятия решений в банке неуправляем.
По 115-ФЗ, 151-ФЗ и требованиям к модели принятия решений регулятор рассматривает такие инциденты как нарушение принципов предсказуемости и обоснованности.
Один и тот же клиент не может быть «низким риском» в приложении и "высоким" — в офисе. Это сразу вызывает дополнительные запросы и проверки.
3. Увеличиваются операционные издержки
Любое расхождение — это:
4. Растёт нагрузка на сотрудников первого фронта
Сотрудники офисов и поддержки вынуждены объяснять клиенту сбой, который появился не из-за их ошибки, а из-за несогласованной архитектуры.
Это создаёт эмоциональное напряжение, снижает качество обслуживания и забирает время, которое могло быть направлено на продажи или консультации.
5. Падает эффективность ИИ-моделей
Если модель в одном канале работает по старым параметрам, а в другом — по обновлённым, её качество прогнозов неизбежно ухудшается. В результате ухудшается PD, растёт число ложных отказов и срабатываний антифрода.
1. Клиент получает разные ответы — падает доверие
Если в приложении перевод проходит, а в офисе блокируется, или партнёрская платформа выдаёт один лимит, а мобильный банк — другой, клиент видит не "сложность архитектуры", а отсутствие порядка.
Даже разовое несоответствие воспринимается как ошибка банка — и часто заканчивается жалобой. В 2025—2026 годах такие расхождения становятся массовыми, прежде всего из-за фрагментированной логики и параллельных изменений в разных каналах.
2. Риск претензий со стороны регулятора растёт
Непоследовательные решения — это сигнал о том, что процесс принятия решений в банке неуправляем.
По 115-ФЗ, 151-ФЗ и требованиям к модели принятия решений регулятор рассматривает такие инциденты как нарушение принципов предсказуемости и обоснованности.
Один и тот же клиент не может быть «низким риском» в приложении и "высоким" — в офисе. Это сразу вызывает дополнительные запросы и проверки.
3. Увеличиваются операционные издержки
Любое расхождение — это:
- лишний звонок в call-центр,
- ручная проверка операции,
- согласование между подразделениями,
- фиксация инцидента и его разбор.
4. Растёт нагрузка на сотрудников первого фронта
Сотрудники офисов и поддержки вынуждены объяснять клиенту сбой, который появился не из-за их ошибки, а из-за несогласованной архитектуры.
Это создаёт эмоциональное напряжение, снижает качество обслуживания и забирает время, которое могло быть направлено на продажи или консультации.
5. Падает эффективность ИИ-моделей
Если модель в одном канале работает по старым параметрам, а в другом — по обновлённым, её качество прогнозов неизбежно ухудшается. В результате ухудшается PD, растёт число ложных отказов и срабатываний антифрода.
Что банкам нужно менять системно?
Когда правила, данные и модели живут в разных системах, «архитектурный выброс» становится нормой. Чтобы решения были одинаковыми во всех каналах, банкам нужен не новый модуль, а базовый порядок в архитектуре.
Ключевые элементы этого порядка:
1. Единый контур данных
Все каналы работают с одной версией клиентского профиля → исчезают расхождения и лишние срабатывания.
2. Централизованное управление правилами и моделями
Изменения в скоринге, KYC и антифроде обновляются синхронно, а не «по очереди» в разных системах.
3. Общий процесс тестирования и релизов
Все обновления проходят единый цикл проверки и выкатываются одновременно.
Банки переходят от набора отдельных моделей и модулей к нормальной управляемой архитектуре. И именно это позволяет убрать проблему, которая в 2025—2026 стала массовой: клиент получает одно и то же решение вне зависимости от того, где он его запрашивает — в приложении, офисе или у партнёра.
Ключевые элементы этого порядка:
1. Единый контур данных
Все каналы работают с одной версией клиентского профиля → исчезают расхождения и лишние срабатывания.
2. Централизованное управление правилами и моделями
Изменения в скоринге, KYC и антифроде обновляются синхронно, а не «по очереди» в разных системах.
3. Общий процесс тестирования и релизов
Все обновления проходят единый цикл проверки и выкатываются одновременно.
Банки переходят от набора отдельных моделей и модулей к нормальной управляемой архитектуре. И именно это позволяет убрать проблему, которая в 2025—2026 стала массовой: клиент получает одно и то же решение вне зависимости от того, где он его запрашивает — в приложении, офисе или у партнёра.
Посмотрите наши решения в деле
Нажимая кнопку «Записаться на встречу», вы даёте согласие на обработку ваших персональных данных
Разберем ваш проект, подготовим индивидуальное решение
Рассчитаем стоимость внедрения для вашего бизнеса
Подберем продукт под ваши бизнес-потребности
Читайте еще