Правило пишет тот, кто заметил.

В Krino правило — это дерево условий: вы выбираете поля, собираете сравнение, задаёте баллы. Без кода и без развёртывания — правила живут над данными.

Список правил: название, описание, баллы и состояние каждого правила
Движок правил · баллы и обоснование каждого правила на экране

Сценарий, версия, правило.

Три понятия, и все три в ваших руках. Сложность подстраивается под ваш бизнес, а не под продукт.

Сценарий

Привязан к одному типу события — заявке на кредит, карточному платежу, выводу средств. Он определяет, какая таблица читается и кто отвечает за исход.

Версия

Текущее состояние правил. Вы работаете над черновиком, пока рабочая версия остаётся нетронутой; публикация меняет их местами и сохраняет прежнюю в истории.

Правило

Дерево условий и баллы. Сработало — баллы добавляются; не сработало — ничего не происходит. Пороги превращают сумму в исход.

Визуальный конструктор условий с деревом условий триггера
Конструктор условий · то же дерево, которое вычисляет движок

На что может смотреть правило?

Сравнения полей

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

Правила по скорости (velocity)

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

Списки и их веса

Белые и чёрные списки, списки стран и BIN-ов и любой свой список, который вы ведёте. Добавить запись — не значит изменить правило: список живёт сам по себе.

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

Ваша собственная история решений

Все остальные условия смотрят на то, что прислал клиент. Это смотрит на то, что сделали вы: «сколько раз мы отправляли эту карту на разбор в этом месяце».

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

Вычисленные сигналы

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

Список сценариев: название, описание и действующая версия каждого
Сценарии · каждый со своим номером версии

Список знает, что в нём лежит.

Укажите, что содержит ваш список — IBAN, адрес криптокошелька, BIN карты, e-mail, телефон. С этого момента пробелы, разделители и регистр букв перестают ломать совпадения.

Пробелы, разделители, регистр

Список с записью TR33 0006 1005 1978 6457 8413 26 совпадёт с записью, в которой тот же IBAN написан без пробелов. Список с адресом Ethereum совпадёт с ним в любом регистре.

В base58 регистр — это информация

Адреса Bitcoin и TRON — то исключение, которое защищает такая конструкция: их регистр несёт смысл, поэтому он сохраняется, а не сглаживается. Два адреса, отличающиеся только регистром, — это два разных адреса, и типизированное сопоставление их не путает.

Некорректная строка не пройдёт молча

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

Иначе неверный IBAN сохранился бы молча и просто никогда бы не сработал. Для чёрного списка это худший из исходов: он выглядит заполненным.

Поле и список должны совпадать по типу

Поле, которое проверяет правило, и список, предлагаемый для проверки, сопоставляются. Полю с адресом кошелька никогда не предложат список BIN-ов карт.

Список без указанного типа сравнивает значения как есть; объявлять тип необязательно.

Список сценариев с действующей версией, состоянием черновика, последним публикатором и черновиком, публикацию которого блокируют три проблемы
Публикация сценария · действующая версия, черновик и последний публикатор

Четыре исхода на порогах, которые задаёте вы.

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

Одобрить

Проходит. Записывается, но ничьего времени не отнимает.

На разбор

Проходит, но открывается кейс — команда смотрит позже.

Задержать и разобрать

Останавливается, открывается кейс. Решает человек.

Отклонить

Отказ. Обоснование записано и готово к спору.

Проверено тремя способами до выхода в работу.

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

На выборке данных

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

На вашей собственной истории

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

Это и есть ответ на «проверьте новое правило на фроде прошлого месяца» без ожидания месяца. Ничего не записывается: ни решения, ни кейсы, ни оповещения.

Теневой прогон на живом трафике

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

Двое человек до выхода в работу

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

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

Что изменилось между двумя версиями

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

Условия правил показываются фразами, а не JSON — два блока JSON рядом дают сравнение, которое никто не читает.

Публикация — отдельный шаг

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

Ничто не выходит без проверки

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

Опубликованная версия не меняется никогда

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

Экран теста сценария с результатами правил по каждой записи
Тест сценария · строка за строкой, до любой публикации

Решение приходит вместе с обоснованием.

В ответе не только исход, но и то, как он получен. Копаться в логах не нужно.

Ответ (сокращённо)
{
  "decision": {
    "outcome": "Review",
    "score": 65,
    "scenario_name": "Card payment · high value"
  },
  "rule_executions": [
    { "rule_name": "Disposable email provider",
      "outcome": "hit", "score": 40 },
    { "rule_name": "5+ distinct cards in 24h",
      "outcome": "hit", "score": 25 },
    { "rule_name": "Sanctions list",
      "outcome": "no_hit", "score": 0 }
  ],
  "execution_time_ms": 28
}

Давайте соберём ваши правила.

Опишите проверки, которые вы сегодня делаете руками; мы настроим их в демо-контуре и покажем.