Создание рабочего процесса для отчетов о подозрительной деятельности без отдельного инструмента управления кейсами (RU)

Срабатывание правила — это простая часть. То, что происходит после — оповещение, расследование, эскалация, решение о подаче Отчета о подозрительной деятельности (SAR) — это то, где на самом деле происходит большинство операций по соблюдению требований и где скрывается большая часть затрат. Типичная настройка объединяет три вещи: поставщика мониторинга, который генерирует оповещения, отдельный инструмент управления кейсами, который хранит расследование, и ручной процесс SAR, который часто заканчивается электронной таблицей и PDF-файлом. Данные повторно вводятся между системами, фрагменты аудиторского следа теряются, а аналитики проводят свой день, переключаясь между вкладками.

API мониторинга транзакций Didit поставляет весь рабочий процесс в одном продукте. Когда срабатывает правило, открывается оповещение; оповещения группируются в кейсы; назначаются аналитики; и SAR подается из той же консоли, где было создано оповещение. Нет отдельного инструмента для кейсов, который нужно лицензировать, интегрировать или согласовывать — а транзакции, которые его питают, стоят $0.02 каждая.

Это руководство описывает рабочий процесс от срабатывания правила до подачи SAR.

Основные выводы

• Оповещения открываются автоматически при срабатывании правила и проходят определенный жизненный цикл: OPEN (открыто), INVESTIGATING (расследуется), AWAITING_USER (ожидает пользователя), PENDING_SAR (ожидает SAR), SAR_FILED (SAR подан), RESOLVED (разрешено), DISMISSED (отклонено).
• Кейсы группируют связанные оповещения, имеют приоритет и степень серьезности, и отслеживают расследование через состояния OPEN (открыто), UNDER_REVIEW (на рассмотрении), AWAITING_USER (ожидает пользователя), ON_HOLD (на удержании) и RESOLVED (разрешено).
• Аналитики назначаются на оповещения и кейсы, поэтому владение и производительность измеримы.
• Подача SAR осуществляется в той же консоли, что и оповещение — без экспорта в отдельный инструмент, без повторного ввода данных.
• Путь AWAITING_USER позволяет аналитику отправить оповещение обратно пользователю для исправления вместо ручного разрешения.
• $0.02 за транзакцию, без минимальных требований. Проверка AML для помеченной стороны оплачивается отдельно по $0.20.

Что делает рабочий процесс управления кейсами

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

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

Почему это важно

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

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

Технические детали

Когда правило срабатывает на транзакции, ответ содержит статус и alert_id:

{
  "transaction_id": "txn_3c81f0",
  "status": "IN_REVIEW",
  "risk_score": 64,
  "triggered_rules": [
    { "name": "Sanctioned counterparty", "bundle": "AML/CTF", "action": "CHANGE_STATUS" }
  ],
  "alert_id": "alrt_77a920"
}

Сама транзакция создается через унифицированный API /v3/, идемпотентно по transaction_id, который вы контролируете:

curl -X POST https://verification.didit.me/v3/transactions/ \
  -H "x-api-key: $DIDIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "transaction_id": "txn_3c81f0",
    "category": "finance",
    "amount": 24000,
    "currency": "EUR",
    "currency_kind": "fiat",
    "txn_date": "2026-05-21T14:50:00Z",
    "subject": { "vendor_data": "user_6610", "role": "SENDER", "entity_type": "INDIVIDUAL" },
    "counterparty": { "role": "RECEIVER", "entity_type": "INDIVIDUAL" }
  }'

Статусы оповещений. OPEN → INVESTIGATING → (AWAITING_USER) → PENDING_SAR → SAR_FILED, или завершение на RESOLVED или DISMISSED.

Статусы кейсов. OPEN, UNDER_REVIEW, AWAITING_USER, ON_HOLD, RESOLVED.

Вебхуки. Подпишитесь на transaction.created и transaction.status.updated, чтобы ваши системы оставались синхронизированными по мере продвижения аналитика по рабочему процессу.

Цена. $0.02 за транзакцию. Проверка AML, проводимая для помеченной стороны во время расследования, оплачивается отдельно по $0.20.

От оповещения до поданного SAR

1. Оповещение открывается. Срабатывает правило, транзакция переходит в состояние IN_REVIEW, и открывается оповещение в состоянии OPEN с прикрепленными сработавшими правилами.
2. Аналитик принимает его. Оповещение переходит в состояние INVESTIGATING и назначается аналитику, который просматривает историю транзакций, контекст скорости и любую проверку AML.
3. Эскалация или исправление. Аналитик группирует связанные оповещения в кейс или отправляет оповещение в AWAITING_USER, чтобы клиент мог прояснить ситуацию, предоставив подтверждение средств или пройдя повторную верификацию.
4. Решение по SAR. Если деятельность требует отчетности, оповещение переходит в состояние PENDING_SAR, SAR подготавливается в той же консоли, и при подаче оповещение переходит в состояние SAR_FILED.
5. Закрытие. Оповещения, не требующие действий, разрешаются как DISMISSED (ложное срабатывание) или RESOLVED. Весь след — кто что решил, когда — остается в записи.

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

Сценарии использования

• Финтех — группировка оповещений о скорости, структурировании и санкциях по одному счету в один кейс, прежде чем принимать решение о SAR.
• Крипто — расследование оповещений, вызванных проверкой кошельков, наряду со скоростью внутри блокчейна в одном файле кейса.
• Кредитование — обработка оповещений о мошеннических схемах (мул, синтетическая личность) до документированного решения без использования второго инструмента.
• Торговые площадки — объединение оповещений о злоупотреблениях при возврате средств и чарджбэках по продавцу в кейс, затем подача или отклонение.
• iGaming — управление оповещениями об ответственной игре и AML в одном рабочем процессе, с ответственностью аналитика и аудиторским следом.

Как интегрироваться с Didit

1. Включите свои пакеты. В Бизнес-консоли включите пакеты правил, которые подходят для вашего бизнеса, чтобы оповещения открывались по соответствующим типологиям.
2. Отправляйте транзакции. POST /v3/transactions/ по мере перемещения денег, со стабильным transaction_id и vendor_data, связывающим каждую транзакцию с ее пользователем или сущностью.
3. Работайте с оповещениями в консоли. Расследуйте, назначайте аналитиков, группируйте оповещения в кейсы и подавайте SAR — все из одной и той же поверхности.
4. Синхронизируйтесь с вебхуками. Слушайте transaction.status.updated, чтобы ваши собственные системы отражали изменения состояния оповещений и кейсов.

Поскольку все это основано на унифицированном API /v3/, сессия KYB может порождать сессии KYC для своих бенефициарных владельцев, эти пользователи попадают в мониторинг транзакций, а помеченная транзакция может порождать KYC для исправления — одна платформа идентификации и борьбы с мошенничеством, от начала до конца.

Часто задаваемые вопросы

Нужен ли мне отдельный инструмент для управления кейсами?

Нет. Оповещения, кейсы, назначение аналитиков, состояния расследований и подача SAR встроены в один и тот же продукт и консоль.

Через какие состояния проходит оповещение?

OPEN, INVESTIGATING, AWAITING_USER, PENDING_SAR, SAR_FILED, RESOLVED и DISMISSED. Кейсы проходят через OPEN, UNDER_REVIEW, AWAITING_USER, ON_HOLD и RESOLVED.

Могу ли я назначать оповещения конкретным аналитикам?

Да. Оповещения и кейсы назначаются аналитикам, поэтому ответственность четкая, а производительность измерима.

Где подается SAR?

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

Сколько это стоит?

$0.02 за транзакцию, оплата за вызов без минимальных требований. Проверка AML, проводимая для помеченной стороны во время расследования, оплачивается отдельно по $0.20.

Готовы начать?

Прочитайте обзор мониторинга транзакций в документации, посмотрите, как он вписывается в остальную часть платформы на странице продукта «Мониторинг транзакций», и ознакомьтесь с прозрачными ценами за вызов на странице цен. Когда будете готовы, начните бесплатно — 500 бесплатных проверок KYC каждый месяц и мониторинг транзакций по $0.02 за вызов.