Назад

Оценка риска клиента

Перестроил калькулятор риска CRAM в RAKBANK — превратив мешанину из Excel, PDF и разрозненных систем в единую цифровую оценку, которую любой аналитик может провести и обосновать.

Каждая оценка полностью обоснована

Ведущий продуктовый дизайнер 2025 – 2026 Compliance · AML · KYC Веб · Внутренние инструменты
3 → 1 Источника объединено
0 Роли пользователей
0 Оценок полностью защищаемы

С чего всё началось

Команда комплаенса RAKBANK оценивает риск каждого клиента через инструмент под названием CRAM. Старая версия была разбросана по файлам Excel, PDF и несвязанным системам — сотрудникам приходилось искать данные и собирать оценку вручную.

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

Поэтому я взялся превратить этот разрозненный процесс в один инструмент, который выдержит любую проверку.

Что я решал

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

Почему этот клиент получил такой рейтинг?
Сможем ли мы обосновать его спустя месяцы?

Ключевые дизайн-задачи

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

«Как только аналитик видит, какие поля двигают оценку, он перестаёт оценивать клиента и начинает подгонять результат под число.»

— Риск-менеджер, RAKBANK

Для кого это

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

  • Офицеры комплаенса — основные оценщики, которые проводят оценку риска. Им нужны ясность, скорость в рамках точности и защищаемый результат.
  • Риск-менеджеры — проверяющие, которые утверждают или оспаривают оценки. Им нужна прозрачность того, как получена оценка, и полная история изменений.
  • Аудиторы — внутренние и внешние проверяющие, изучающие прошлые решения. Им нужны полные записи с отметками времени по каждому вводу и изменению.

Как я подошёл к задаче

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

Путь

  1. Интервью со стейкхолдерами

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

  2. Карта процесса и требований

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

  3. Концепт-дизайн

    Перевёл процесс в единую форму с прозрачным происхождением данных, заложенным с самого начала.

  4. Тестирование прототипа

    Итерации с офицерами комплаенса для проверки структуры формы и процесса переопределения.

  5. Поэтапный запуск

    Выкатывал поэтапно, параллельно со старым процессом — пока новый инструмент не заслужил доверие.

Где всё ломалось

Изначальный CRAM вообще не был единым инструментом — это была мешанина из таблиц, PDF-форм и разрозненных источников данных, которые сотрудники сводили вручную.

  • Данные разбросаны по нескольким несвязанным системам
  • Поля расставлены произвольно, без структурированной формы
  • Системные данные и ручной ввод смешаны вместе
  • PDF-отчёты показывали цифры, но не обоснование
  • Нет записи о причинах изменения оценки
Изначальный инструмент CRAM — мешанина из таблиц Excel, PDF-форм и разрозненных данных

Принципы, которые им руководили

Четыре принципа, выведенные из требований комплаенса и исследований, формировали каждое решение.

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

Одна форма — так, как реально работают сотрудники

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

Вердикт со всеми доказательствами

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

Сводка риска — рассчитанная оценка с диапазоном, контекстом клиента, авторством и отметкой времени

За кулисами дизайна

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

Доска дизайн-процесса — исследование с одной стороны, информационная архитектура и вайрфреймы с другой

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

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

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

Оглядываясь назад

UX в комплаенсе — это не про красоту, а про то, чтобы сделать корректность достижимой, а защищаемость автоматической.

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

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

Хотите обсудить детали?

С радостью расскажу про исследование, дизайн-решения и то, что не вошло в финал.

Связаться