KYT API реального времени для проверки до транзакции

KYT API реального времени отвечает на один вопрос в единственный момент, когда ответ ещё способен изменить исход: до разрешения транзакции. Ончейн-переводы необратимы, поэтому после отправки пополнения или вывода в сеть остаются лишь расследование и отчётность. Проверка до транзакции переносит решение раньше — в окно, когда высокорискового контрагента ещё можно заблокировать или приостановить. Руководство остаётся в этом окне: его значение, требования к задержке, возврат решения API, блокировка/приостановка/разрешение, выбор между реальным временем, пакетом и мониторингом и контрольный список интеграции. Все возможности KYT представлены в Phalcon Compliance. Эта страница — часть центра знаний о KYT.

Почему важна проверка до транзакции

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

Мониторинг после транзакции не заменяет проверку до неё. Риск-ориентированный подход FATF к VASP обязывает постоянно мониторить транзакции с учётом риска, а не ограничиваться единственной проверкой при подключении. FinCEN аналогично формулирует обязанности постоянного AML-мониторинга в правиле о программе AML для организаций денежных услуг (31 CFR 1022.210) для криптобирж и других организаций денежных услуг США. Ни одна рамка не задаёт жёсткого числа задержки, но обе ожидают, что контроль реально применяется к регулируемой им транзакции. Программа, выявляющая риск лишь после движения средств, имеет пробел, который проверяющие считают слабостью программы, а не предпочтением внедрения.

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

Насколько быстро должен возвращаться запрос проверки

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

Идеальная цель ниже. Ответ самого API менее чем за 100 миллисекунд оставляет время остальным частям шлюза. Сетевой обмен, внутренняя маршрутизация, журналирование и пороговое решение расходуют бюджет сверх самого вызова. Если API один занимает 300 миллисекунд, остальному стеку ничего не остаётся. Задержка — не функция в спецификации. Она определяет, работает ли контроль в потоке транзакции или пытается её догнать.

BlockSec заявляет задержку на уровне миллисекунд для API проверки в реальном времени. Считайте её целью для подтверждения на рабочем трафике до построения внутреннего SLA. Шлюз, ожидающий 50 миллисекунд, но фактически получающий 400, начнёт деградировать до первого уведомления. Он должен измерять реальное время и корректно снижать функциональность при превышении.

Как работает KYT API проверки в реальном времени

KYT API находится в пути принятия решения по транзакции, а не рядом с ним. Четыре шага потока должны уложиться в бюджет задержки. Клиент аутентифицируется и передаёт адрес или идентификатор транзакции. API сопоставляет адрес с данными о рисках и возвращает оценку с доказательствами. Шлюз клиента преобразует оценку в решение — блокировать, приостановить или разрешить — с помощью программно заданных порогов, затем разрешает или перехватывает транзакцию. Вызов синхронный и для одного адреса, поскольку решение должно прийти до разрешения транзакции.

Phalcon Compliance предоставляет API именно в такой форме. Доступом управляет один ключ API. Вызов возвращает оценку риска, лежащие за ней показатели связей и определившие её индикаторы. Данные построены на более чем 600 миллионах размеченных адресов и более чем 17 категориях индикаторов риска, охватывающих поведение, связи с известными незаконными сервисами и риск контрагентов. По оценке шлюз маршрутизирует операцию. Индикаторы и показатели связей читает аналитик при приостановке для разбора; они делают решение пригодным для аудита, а не непрозрачным.

Использование API определяют два ограничения. Во-первых, доступ открыт на Scale от $699 в месяц и Enterprise. Free, Screening Packages и Essential предназначены для проверок через интерфейс платформы, а не встраивания в транзакционный шлюз. Команда, создающая предварительную проверку, должна перейти на Scale или Enterprise до написания первого вызова. Во-вторых, задержка — ответ на уровне миллисекунд — определяет, может ли API обслуживать предварительный шлюз или должен остаться мониторингом после транзакции. Подтверждение реального времени под собственной нагрузкой — часть запуска, а не формальность после него.

Блокировать, приостановить или разрешить: решайте до движения средств

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

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

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

Реальное время, пакетная проверка и Monitor: когда что применять

Проверка до транзакции — не единственный режим; путаница между режимами — распространённый сбой. KYT API работает в трёх режимах, каждый со своим вопросом. Одиночная проверка реального времени отвечает: «Безопасно ли разрешить эту транзакцию сейчас?» Пакетная проверка: «Каков профиль риска накопленных непроверенных адресов?» Monitor: «Изменился ли риск уже проверенного адреса с последнего просмотра?» Режимы не сводятся к одному; неправильный либо расходует квоту, либо пропускает риск.

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

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

Контрольный список интеграции предварительной проверки

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

1. Подтвердите тариф API. Доступ к API реального времени требует Scale от $699 в месяц или Enterprise. Подтвердите до написания первого вызова.

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

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

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

5. Сохраняйте доказательства с каждым решением. Оценка, пороговый диапазон, индикаторы риска и показатели связей должны храниться с записью транзакции. Решение должно воспроизводиться спустя месяцы.

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

7. Обрабатывайте лимиты запросов. API проверки ограничивает частоту на ключ; сверх лимита возвращает HTTP 429. Клиент должен выдерживать увеличивающуюся паузу, а не повторять запрос немедленно при ошибке.

8. Включите Monitor для изменения риска. Предварительная проверка выявляет риск на шлюзе. Monitor — риск, возникший позже. Он не расходует квоту Screening, поэтому может оставаться включённым без нагрузки на бюджет реального времени.

Шлюз, прошедший этот список, принимает предварительное решение внутри транзакционного пути: пороги срабатывают, уведомления доходят до человека, доказательства сохраняются, а путь деградации обеспечивает безопасное поведение при сбое. Именно это означает предварительная проверка в реальном времени на практике. Читайте документацию KYT API Phalcon Compliance: справочник конечных точек, вход через Scale и полную схему индикаторов риска.