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

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

Согласно статистике, только за первые 9 месяцев 2025 года граждане подали около 280 тысяч жалоб на финансовые услуги — максимальное значение за последние семь лет. Жалобы на банки выросли на 21%, и значительная часть касается отказов в операциях и «необъяснимых» блокировок. Это следствие не только ужесточения комплаенса, но и того, что внутри банковских систем слишком много разрозненной логики и конфликтующих правил.

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

• Для клиента это выглядит как хаос.
• Для банка — как риски, жалобы и проверки.
• Для регулятора — как отсутствие управляемости.

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

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

Отсюда — типичные сценарии:

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

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

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

Что меняет СПР или любая единая архитектура решений?

Единый центр принятия решений позволяет хранить правила, модели и параметры в одном месте, а значит — использовать их одинаково во всех каналах.
Что это даёт:

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

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

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

• в CRM — устаревший адрес;
• в KYC — другая дата обновления паспорта;
• в антифроде — неполный перечень устройств;
• в транзакционном мониторинге — часть операций отсутствует из-за задержек.

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

Отсюда и эффекты:

• приложение видит клиента как «зелёного»,
• фронт-офис — как «серого»,
• риск-модуль — как «повышенного риска».

Разные входные данные → разные ответы.

Что даёт единый контур данных?

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

Что меняется:

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

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

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

Как работает во многих компаниях сегодня:

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

По отдельности всё проходит проверку. Но никто не тестирует систему целиком — как единый контур принятия решений.
Из-за этого в продакшн попадают несовместимые изменения:

• в офисе обновили правила,
• в приложении — пороги,
• в антифроде — логику,
• а интеграционный канал остался на прошлой версии.

Каждый блок «зелёный» сам по себе, но в связке они дают разные ответы, потому что обновления выкатывались точечно, без общей регрессии.

Что меняет единый процесс тестирования в архитектуре решений?

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

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

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

Последствия для бизнеса

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

1. Клиент получает разные ответы — падает доверие
Если в приложении перевод проходит, а в офисе блокируется, или партнёрская платформа выдаёт один лимит, а мобильный банк — другой, клиент видит не "сложность архитектуры", а отсутствие порядка.
Даже разовое несоответствие воспринимается как ошибка банка — и часто заканчивается жалобой. В 2025—2026 годах такие расхождения становятся массовыми, прежде всего из-за фрагментированной логики и параллельных изменений в разных каналах.

2. Риск претензий со стороны регулятора растёт
Непоследовательные решения — это сигнал о том, что процесс принятия решений в банке неуправляем.

По 115-ФЗ, 151-ФЗ и требованиям к модели принятия решений регулятор рассматривает такие инциденты как нарушение принципов предсказуемости и обоснованности.
Один и тот же клиент не может быть «низким риском» в приложении и "высоким" — в офисе. Это сразу вызывает дополнительные запросы и проверки.

3. Увеличиваются операционные издержки

Любое расхождение — это:

• лишний звонок в call-центр,
• ручная проверка операции,
• согласование между подразделениями,
• фиксация инцидента и его разбор.

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

4. Растёт нагрузка на сотрудников первого фронта
Сотрудники офисов и поддержки вынуждены объяснять клиенту сбой, который появился не из-за их ошибки, а из-за несогласованной архитектуры.

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

5. Падает эффективность ИИ-моделей
Если модель в одном канале работает по старым параметрам, а в другом — по обновлённым, её качество прогнозов неизбежно ухудшается. В результате ухудшается PD, растёт число ложных отказов и срабатываний антифрода.

Что банкам нужно менять системно?

Когда правила, данные и модели живут в разных системах, «архитектурный выброс» становится нормой. Чтобы решения были одинаковыми во всех каналах, банкам нужен не новый модуль, а базовый порядок в архитектуре.

Ключевые элементы этого порядка:

1. Единый контур данных
Все каналы работают с одной версией клиентского профиля → исчезают расхождения и лишние срабатывания.

2. Централизованное управление правилами и моделями
Изменения в скоринге, KYC и антифроде обновляются синхронно, а не «по очереди» в разных системах.

3. Общий процесс тестирования и релизов
Все обновления проходят единый цикл проверки и выкатываются одновременно.
Банки переходят от набора отдельных моделей и модулей к нормальной управляемой архитектуре. И именно это позволяет убрать проблему, которая в 2025—2026 стала массовой: клиент получает одно и то же решение вне зависимости от того, где он его запрашивает — в приложении, офисе или у партнёра.