Проектирование ради уверенности

01 · Что такое платформа CLM?

Не столько инструмент продуктивности, сколько система контроля

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

CLM работает не в одиночку. Она забирает данные клиента из Finacle, основной системы учёта банка, и проводит свои процессы проверки через IBPS, процессный движок банка. CLM это слой поверх обоих: единственное место, где комплаенс-решения принимаются, отслеживаются и защищаются.

Системы никогда не создавались для взаимодействия друг с другом

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

Инсайт, изменивший направление

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

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

Решение 01

Кто решает, как распределяется работа?

Варианты, которые мы рассматривали:

• Автоназначение. Система распределяет нагрузку алгоритмически.
• Самостоятельный выбор. Аналитики сами берут дела из очереди.
• Под контролем тимлида. Руководители распределяют работу инструментами массового назначения.

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

Решение 02

Сколько обоснований стоит требовать от сотрудников?

Варианты, которые мы рассматривали:

• Тихое логирование. Каждое действие записывается автоматически, без участия пользователя.
• Полное обоснование. Каждое действие требует письменной причины перед продолжением.
• Структурированные комментарии. Обоснование требуется только при смене маршрута, изменении риска и срабатывании последствий.

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

Роль 01 · Аналитик

Открыть очередь, обработать дело, оставить запись

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

Роль 02 · Тимлид

Увидеть бэклог до того, как он станет нарушением

Тимлиды открывают дашборд, видят нагрузку и бэклог команды, массово назначают нераспределённые дела и следят за тем, кто перегружается, прежде чем это превратится в нарушение SLA.