Интеграция KYT API вызывает конечную точку проверки для каждого пополнения и вывода, разбирает оценку и маршрутизирует транзакцию до движения средств. Пакетная проверка и постоянный мониторинг добавляют историю и изменение риска адресов. API должен находиться внутри потока, а не рядом: реальное время выявляет риск до расчёта, пакет и мониторинг покрывают промежутки. Руководство проходит все три режима для криптобиржи. Общий процесс см. в Phalcon Compliance. Эта страница — часть центра знаний об AML-комплаенсе.
Зачем биржам проверка реального времени на уровне API
Выбранная периодичность одновременно означает принятое окно отмывания. Недельный или дневной пакет проверяет адреса в момент выполнения, но каждое пополнение между пакетами входит беспрепятственно. В этом разрыве средства успевают поступить, переместиться и выйти в деньги. API реального времени закрывает разрыв проверкой каждого пополнения и вывода до разрешения.
Причина не только операционная. FinCEN требует от организаций денежных услуг, включая криптобиржи, программу AML (31 CFR 1022.210) и сообщения о подозрительных транзакциях (31 CFR 1022.320) вместе с руководством 2019 года (FIN-2019-G001). На практике сочетание делает необходимым постоянный мониторинг, а не задаёт фиксированный порог реального времени. Риск-ориентированный подход FATF к VASP требует того же: постоянно наблюдать транзакции вместо одной проверки при подключении. Биржа выполняет оба, сохраняя живой контроль каждого пополнения и вывода, который и даёт режим ниже. Только пакетный ритм оставляет заметный разрыв между обязанностью и работающим контролем; проверяющие считают его пробелом программы, не предпочтением внедрения.
Разработческая сторона — отдельное ограничение. Готовые сторонние инструменты не подходят сценарию биржи до доступа к внутренним системам, поэтому недооценённая задача — интеграция, не число функций. Механизм, не связанный с пополнениями, выводами и маршрутом уведомлений, не меняет возможности обнаружения, а только панель. Именно интеграция превращает способность проверки в программу.
Подготовка: пороги, маршрутизация, системный доступ
До первого вызова нужно закрепить три решения. Они определяют реальное поведение интеграции; поздняя смена требует переделки клиента API и последующего маршрута уведомлений. Они входят в AML-программу криптобиржи, охватывающую оценку рисков, проверку, разбор и записи. Здесь рассматривается слой API, не структура программы.
Первое — набор пороговых правил. API возвращает оценку, но она ничего не делает до решения биржи о действиях диапазонов. Типично три: низкий риск автоматически разрешает, средний приостанавливает для ручного разбора, высокий блокирует и создаёт уведомление. Пороги должны быть кодом, не только политикой, поскольку клиент маршрутизирует программно.
Второе — маршрутизация. При пересечении порога уведомление должно дойти до человека или очереди. Проект определяет канал: webhook в Slack или Telegram, заявку системы дел или внутреннюю очередь. Платформа поддерживает несколько каналов, включая webhook; их нужно сопоставить до запуска, не добавлять после первого пропуска.
Третье — тарифный доступ. API доступен только на Scale от $699 в месяц и Enterprise; Free, Screening Packages и Essential его не включают. Встраивающей проверку команде сначала нужен Scale. Подтверждение до интеграции предотвращает разработку под недоступный тариф. Совместная работа нескольких пользователей внутри инструмента доступна только на Enterprise. Место ограничения в общей программе крипто-AML изложено в центре знаний.
Интеграция KYT и KYA API Phalcon Compliance: три режима
API Phalcon Compliance поддерживает проверки в реальном времени, асинхронный CSV-пакет и постоянный мониторинг. Реальное время покрывает пополнения и выводы, пакет — исторические адреса и накопленные непроверенные адреса, Monitor — изменение риска ранее проверенных адресов. Биржи сочетают режимы по месту и моменту необходимости проверки.
У потоков три несводимые потребности. Живая транзакция ждёт ответа до разрешения — нужен синхронный вызов низкой задержки. Накопленные непроверенные исторические адреса проверяются массово без блокировки потока — нужна асинхронная задача. Чистый при первой проверке адрес позже может взаимодействовать с рискованным контрагентом — нужно постоянное наблюдение, не разовый вердикт.
Phalcon Compliance предоставляет три соответствующих режима: одиночный реального времени для шлюза, асинхронный CSV для накопленных непроверенных и исторических адресов, непрерывный Monitor с динамическим расписанием повторного анализа. Они разделяют одну аутентифицированную поверхность: один ключ управляет всем доступом, биржа выбирает режим на вызов вместо отдельных интеграций.
| Режим | Запуск | Задержка | Квота и частота | Сценарий |
|---|---|---|---|---|
| Одиночная проверка реального времени | Один адрес или транзакция | Уровень миллисекунд | 50 вызовов в минуту на ключ API | Живые пополнения и выводы |
| Асинхронный CSV-пакет | Загрузка CSV | Асинхронно | До 100 адресов на файл; до 400 транзакций на пакет | Проверка накопленных непроверенных и исторических адресов |
| Monitor | Непрерывно | Динамическое расписание | Не расходует Screening | Повторный анализ при изменении риска |
Последовательность одинакова: клиент аутентифицируется выданным ключом, вызывает конечную точку с адресом или идентификатором транзакции, разбирает оценку с индикаторами и количественными связями, маршрутизирует по подготовленным порогам и при пересечении отправляет уведомление через webhook или канал. API ограничен 50 вызовами в минуту на ключ, превышение даёт HTTP 429; клиент должен обрабатывать его с увеличивающейся паузой, а не немедленным повтором при ошибке.
BlockSec заявляет миллисекундную задержку одиночной проверки. Подтвердите её на собственном трафике: проектируйте переносимость задержки вместо предположения точного значения и измеряйте внутренний SLA на рабочем потоке.
Частота, квоты и тарифы: инженерные замечания
Первое ограничение — частота: 50 вызовов в минуту на ключ, далее HTTP 429. Для живых пополнений оно редко становится сдерживающим фактором, поскольку они поступают по одному, а проверка заканчивается до следующего вызова. Для массовых операций становится: синхронная проверка тысяч адресов исчерпает лимит за минуты. CSV существует для переноса нагрузки с синхронного пути: до 100 адресов на файл или 400 транзакций на пакет. Накопленные непроверенные адреса обрабатываются асинхронно без конкуренции с живым шлюзом за частоту.
Второе — квоты. Проверки расходуют баланс в порядке: обновляемая каждый цикл Subscription quota, затем Top-up Screenings, Referral Rewards и Screening Packages. Интеграции не нужно выбирать баланс. Команда-владелец бюджета должна понимать порядок: он определяет исчерпание и момент пополнения. Исключение — Monitor: динамическая повторная проверка при изменении риска не расходует Screening, поэтому постоянное включение не нагружает бюджет отдельных проверок.
Третье, неизменное ограничение — тариф. API требует Scale от $699 в месяц или Enterprise; Free, Screening Packages и Essential доступа не имеют. Дополнительно объём определяют возможности: webhook на Scale/Enterprise; пользовательский Risk Engine со Screening Packages (3 механизма), Essential (10), Scale (20), Enterprise (без ограничений); несколько пользователей — Enterprise. Ценовые детали разобраны в отдельной статье; здесь только ограничения, влияющие на план API.
Читайте документацию API Phalcon Compliance
Интеграция не завершена первым ответом с оценкой. Она завершена, когда шлюз реального времени, путь проверки накопленных непроверенных адресов и Monitor подключены к пополнениям и выводам, пороги заданы кодом, уведомления идут в реальную очередь, тариф подтверждён до первого вызова. Читайте документацию API: справочник конечных точек, контракт webhook и путь пробного доступа Scale.