Решения по операциям — обзор

Задача

Решения по операциям (техническое имя — Sync Decision) — модуль, который принимает решение по операции до её исполнения. Внешняя система присылает операцию по Hypertext Transfer Protocol (HTTP) и в том же запросе получает ответ. Ответ — пропустить, отказать или отправить на ручное расследование. Источник операций — процессинг, автоматизированная банковская система или шлюз Системы быстрых платежей (СБП).

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

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

• антифрод-проверки;
• одобрение транзакций;
• контроль частоты коммуникаций;
• контроль лимитов.

Ключевые особенности

Шесть свойств модуля; подробности — в разделе «Что делает».

• Синхронный ответ — решение возвращается в том же HTTP-запросе, до исполнения операции; очередей и повторов нет.
• Правила без перезапуска — изменения событий и таблиц решений применяются без перезапуска модуля.
• Обогащение данными — к операции добавляются атрибуты клиента и агрегаты по его истории; модуль их только читает.
• Обкатка правил — новые правила проверяются на боевом потоке, не влияя на решения.
• Белые списки — срабатывание таблицы решений с признаком белого списка обнуляет итоговое решение.
• Четыре протокола — четыре адаптера, включая универсальный external; новый протокол — доработка модуля.

Что делает

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

Приём операции и ответ

Модуль принимает операцию от системы-источника и отвечает в том же запросе.

• Принимает операции по четырём протоколам: подключение новой системы-источника через external не требует правки кода. Поддержка нового протокола — доработка модуля.
  • corefinance;
  • СБП — формат Национальной системы платёжных карт (НСПК) с индикатором мошенничества;
  • banksoft;
  • external — универсальный адаптер с авторизацией по именованным API-ключам.
• Отвечает синхронно, до исполнения операции: ответ уходит в том же HTTP-запросе. Трактовку отсутствия ответа определяет вызывающая сторона.

Принятие решения

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

• Распознаёт событие: входящий запрос сопоставляется с условиями распознавания настроенных событий. Если ни одно событие не подошло, модуль отвечает «пропустить».
• Обогащает операцию данными: к полям запроса добавляются атрибуты динамического профиля — набора атрибутов клиента в быстродоступном хранилище платформы. Добавляются и агрегаты скользящих окон — сводные значения по истории клиента за заданную глубину.
• Прогоняет таблицы решений: таблица срабатывает, когда сумма весов сработавших правил строго превышает порог. Итоговое решение принимается, если сработала хотя бы одна таблица; код отказа — максимальный среди сработавших.
• Поддерживает обкатку правил: таблица-«молчун» считается и попадает в журнал, но решения не меняет — так новые правила проверяются на боевом потоке. Правило с весом 0 фиксируется как наблюдение и на порог не влияет.
• Учитывает белые списки: срабатывание таблицы решений с признаком белого списка обнуляет итоговое решение независимо от остальных таблиц.

Журнал и передача результата

Каждое решение фиксируется в аналитике и может продолжить обработку в модуле Flow.

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

Чего не делает

Ограничения перечислены от обработки запроса к данным и интерфейсу.

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

Из чего состоит

Части модуля перечислены в порядке прохождения запроса.

• Адаптеры протоколов — приём операций и ответ в формате системы-источника. Контракт HTTP-точки описан в статье API Online Engine.
• События — точки входа: как распознать операцию, какие данные подготовить и какие таблицы решений применить. Работа с ними описана в статьях Управление событиями и Настройка события.
• Скользящие окна — агрегаты по истории клиента за настроенную глубину.
• Таблицы решений — наборы правил с весами, порогом и признаками «молчун» и «белый список».
• Правила — атомарные условия; вес правила определяет его вклад в решение таблицы.
• Журнал и передача результатов — записи в аналитику и передача результата во Flow по итогам каждого решения.

Ключевые термины

Семь терминов модуля с определениями в одну строку.