Разработка AI-системы автоматизации compliance в финансах

AI compliance в финансах: где ломается автоматизация проверок

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

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

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

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

Что даёт автоматизация проверок: скорость, полнота, след

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

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

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

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

Эти эффекты стоит замерять до внедрения и после: иначе автоматизация превращается в красивый отчёт без ответа на вопрос, что изменилось в повседневной работе.

Способы развёртывания: локальный контур, облако, гибрид

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

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

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

Этапы внедрения: от аудита правил до передачи в эксплуатацию

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

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

2. Схема проверок. Реестр превращаем в схему: какие данные нужны на входе, какие проверки детерминированные, а какие требуют оценки модели, где обязателен ручной разбор. Схема задаёт порядок проверок и точки, где операция блокируется без подтверждения человеком.

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

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

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

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

Что остаётся у вас: регламенты, модели, доступы, документация

Система комплаенс-контроля передаётся не как «чёрный ящик», а как комплект артефактов, с которым ваша команда работает без нас. Правила проверок описаны декларативно и лежат в вашем репозитории, модель зафиксирована в версии, прошедшей приёмку, а каждое решение воспроизводимо по журналу.

• Регламенты контроля: какие операции проверяются, по каким признакам, что блокирует проводку, а что уходит на разбор оператору.
• Конфигурации правил: версионируемые файлы, правка которых не требует изменения кода — только ревью и откат по истории.
• Схема принятия решений: маршрут от поступления данных до вердикта, точки вмешательства человека, границы автоматики.
• Правила доступа: роли аналитика, оператора, аудитора и администратора правил; право менять правило отделено от права его утверждать.
• Журналирование: неизменяемый лог по каждому срабатыванию — входные данные, версия модели и правила, вердикт, факт вмешательства; выгрузка под аудит.
• Инструкции оператора: разбор типовых срабатываний, порядок эскалации, оформление спорного решения.
• Порядок обновления правил: согласование, проверка на исторических данных, вывод новой версии в работу, подпись ответственного.

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

Кейс: как сократили ручные проверки в кредитном подразделении

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

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

Метрики до и после

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

Что делать, если часть compliance-контроля уже автоматизирована

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

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

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

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

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

Частые технические сомнения: разбор типовых вопросов

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

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

Как вы боретесь с ложными срабатываниями и объясняете решения?

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

Что происходит при изменении требований?

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

Кто отвечает за работу системы после запуска?

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

Обсудим задачу: какие данные нужны для оценки

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

• Описание процесса: какие проверки идут сейчас, кто и на каком шаге принимает решение, где остаются ручные операции и что съедает больше всего времени.
• Источники данных: системы-источники, форматы выгрузок, периодичность обновления и примерный объём — число операций или документов за месяц.
• Обезличенная выборка: несколько сотен реальных примеров, включая редкие и пограничные случаи — на них калибруется модель и проверяется точность.
• Требования регулятора: перечень норм, формы отчётности, сроки предоставления и замечания, которые уже получали.
• Ограничения контура: где система будет работать, какие сервисы нельзя менять, требования к хранению данных и разграничению доступа.
• Критерии приёмки: допустимая доля пропусков и ложных срабатываний, кто и как проверяет ответы модели перед внедрением.
• Внешние даты: отчётные периоды или проверки, к которым решение должно быть готово, — от них зависят сроки этапов.

С этим набором мы возвращаемся с оценкой проекта, разбивкой на этапы и понятными сроками каждого. Опишите задачу — покажем, что забираем в работу первым и какие данные нужны уже на старте.