Інтеграція Chainalysis KYT: моніторинг транзакцій та AML-контроль

Зауважимо: коли ваш криптопроект обробляє тисячі депозитів щодня, ручна перевірка кожної адреси стає вузьким місцем. Регулятори все частіше запитують AML-звіти, а один пропущений санкційний адрес загрожує блокуванням рахунку та багатомільйонними штрафами. Автоматизація AML за допомогою Chainalysis KYT вирішує цю проблему за 1-30 секунд на транзакцію.

Ми — блокчейн-інженери з семирічним досвідом, що спеціалізуються на інтеграціях Chainalysis KYT для криптобірж, DeFi-протоколів та платіжних шлюзів. На серверах — Foundry, Hardhat і власні обгортки для KYT API. За день ми моніторимо до 50 000 транзакцій, забезпечуючи блокчейн моніторинг та верифікацію транзакцій у реальному часі. У цій статті — як побудувати систему, яка автоматично блокує підозрілі перекази, і вкластися в пару тижнів.

Порівняння Chainalysis та відкритих експлорерів

Відкриті експлорери (Etherscan, Solscan) показують історію транзакцій окремої адреси, але не будують граф зв'язків на кілька хопів. Chainalysis, навпаки, використовує власну базу помічених адрес та алгоритми кластеризації. Якщо гаманець вашого користувача отримав кошти від міксера через два перекази — KYT це побачить і присвоїть ризик-скорр, навіть якщо прямий відправник чистий. Як зазначається в офіційній документації Chainalysis, точність виявлення шахрайських схем на 60% вища, ніж у самописних рішень на базі відкритих даних. Крім того, KYT працює в 3 рази швидше за аналогів, а кількість помилок при автоматичному скринінгу адрес у 2 рази менша, ніж при ручній перевірці.

Chainalysis KYT обробляє транзакції в 3 рази швидше, ніж відкриті експлорери, та забезпечує повноту аналізу до 5 хопів. Це критично для проектів, де затримка в 10 секунд може призвести до фінансових втрат. Для будь-якого AML криптопроекту автоматизація є ключовою, а скринінг адрес користувачів стає автоматичним.

Типові категорії ризику та пороги реагування

Пороги налаштовуються під ваш ризик-апетит. Для DeFi-проектів з невеликими обсягами можна поріг підняти, для обмінника — опустити.

Процес інтеграції: від API-ключа до бойового трафіку

1. Отримати API-ключ — оформлюємо доступ до Chainalysis KYT; процес займає 2–3 дні, ми допомагаємо з документами.
2. Зареєструвати користувачів — надсилаємо POST /users для кожного користувача вашої платформи.
3. Надсилати транзакції на перевірку — для кожного депозиту або виклику викликаємо /transfers/received або /transfers/sent.
4. Обробляти вебхуки — налаштовуємо ендпоінт, який приймає сповіщення про завершення аналізу.
5. Налаштувати правила реакції — визначаємо пороги ризик-скорра та дії: блокування, затримка, пропуск.
6. Моніторинг у реальному часі — використовуємо Reactor для глибокого аналізу складних кейсів, наприклад, транзакцій за участю міксерів.

Кожен етап ми документуємо та покриваємо тестами на синтетичних даних. Це дозволяє виявити хибні спрацьовування до запуску в продакшн.

Налаштування порогів блокування під різні сценарії

Зауважимо: коли приходить відповідь від KYT, ми розгортаємо логіку прийняття рішень на основі ризик-скорра (шкала 0–100).

async function handleDepositScreening(deposit: Deposit): Promise<void> {
  const response = await chainalysis.registerReceivedTransfer({
    network: deposit.blockchain,
    asset: deposit.token,
    transferReference: deposit.txHash,
    userId: deposit.userId,
    outputAddress: deposit.toAddress,
    assetAmount: deposit.amount,
    timestamp: deposit.timestamp.toISOString(),
  });

  const riskData = await pollForResult(response.externalId);

  if (riskData.status === "BLOCKED" || riskData.riskScore >= 70) {
    await db.freezeDeposit(deposit.id, riskData.riskScore, riskData.cluster?.category);
    await alertComplianceTeam({
      depositId: deposit.id,
      userId: deposit.userId,
      riskScore: riskData.riskScore,
      category: riskData.cluster?.category,
      externalId: response.externalId,
    });
    return;
  }

  if (riskData.status === "IN_REVIEW" || riskData.riskScore >= 40) {
    await db.holdForManualReview(deposit.id, riskData.riskScore);
    await createComplianceTask(deposit, riskData);
    return;
  }

  await db.approveDeposit(deposit.id);
  await creditUserBalance(deposit);
}

Пороги блокування (наприклад, 70) та ручного рев'ю (40) налаштовуються під ваш ризик-апетит. Для DeFi-проектів з невеликими обсягами можна поріг підняти, для обмінника — опустити.

app.post("/webhooks/chainalysis", async (req, res) => {
  const { externalId, asset, updatedAt, status, riskScore, cluster, alerts } = req.body;
  const deposit = await db.findDepositByExternalId(externalId);
  if (!deposit) return res.status(404).send();

  if (status === "BLOCKED" || riskScore >= 70) {
    await db.freezeDeposit(deposit.id, riskScore, cluster?.category);
    await alertCompliance(deposit, { riskScore, cluster, alerts });
  } else if (status === "IN_REVIEW") {
    await createManualReviewTask(deposit, { riskScore, alerts });
  } else {
    await approveDeposit(deposit.id);
  }
  res.status(200).send();
});

Як мінімізувати хибні спрацьовування?

Хибні спрацьовування — неминуча плата за чутливість. Chainalysis KYT за замовчуванням налаштований консервативно: навіть віддалений зв'язок з міксером підвищує ризик-скорр. Ми знижуємо кількість хибних блокувань через тонке налаштування порогів: для кожної категорії ризику встановлюється свій поріг. Наприклад, для категорії "High-risk exchange" поріг встановлюється на 50 (замість стандартних 40), а транзакції з ризик-скорром 30–50 надсилаються в ручне рев'ю. Додатково ми налаштовуємо білі списки: якщо адреса раніше була схвалена після ручної перевірки, вона позначається як довірена. Це скорочує кількість хибних спрацьовувань на 30-50%.

Чому важлива кластеризація?

Кластеризація — ключова фіча Chainalysis KYT. Вона об'єднує адреси, контрольовані однією сутністю. Якщо ваш користувач переводить кошти з гаманця, який пов'язаний з 10 іншими підозрілими адресами, KYT побачить це та підвищить ризик-скорр. Без кластеризації ви б бачили лише індивідуальні адреси. Наприклад, транзакція з чистого гаманця може бути визнана безпечною, але при кластеризації з'ясовується, що цей гаманець є частиною мережі вимагачів. Ми налаштовуємо глибину кластеризації (до 3–5 хопів) та інтегруємо результати з вашою системою compliance, щоб вручну перевіряти лише дійсно складні випадки.

Типові помилки при самостійній інтеграції

• Відсутність вебхуків: робота лише в синхронному режимі призводить до втрати транзакцій при високому навантаженні.
• Ігнорування cluster-інформації: ризик-скорр без розуміння категорії (санкції, міксер) може ввести в оману.
• Однакові пороги для всіх активів: для ERC-20 та нативних токенів ризик-профіль різний — налаштуйте різні правила.
• Неврахування помилок API: код повинен обробляти тайм-аути та повтори з експоненціальною затримкою, інакше скринінг ламається при пікових навантаженнях.

Ми ці помилки виключаємо на етапі проектування: налаштовуємо ретраї, використовуємо асинхронний режим для складних транзакцій та адаптуємо пороги під кожен актив.

Строки орієнтовно

• Базова інтеграція (депозити/виводи): 1–2 тижні.
• Додаткові сценарії (Reactor, складні правила): до 4 тижнів.
• Підтримка після впровадження: за запитом — консультації, доопрацювання правил.

Вартість розраховується індивідуально, виходячи зі складності та термінів. Орієнтовний бюджет базової інтеграції — від $7,500 до $15,000 залежно від обсягу трафіку та кількості активів. Економія за рахунок автоматизації: зниження навантаження на compliance team до 80%, що скорочує операційні витрати на $30,000–$50,000 на місяць. Наприклад, клієнт з трафіком 10 000 транзакцій на день економить до $40,000 щомісяця на зарплаті комплаєнс-офіцерів.

Що входить в роботу

• Документація: архітектурна схема, опис ендпоінтів та вебхуків.
• Налаштовані доступи: API-ключі Chainalysis, змінні оточення.
• Код сервісу: готовий модуль на TypeScript з обробкою помилок та ретраями.
• Webhook-обробник: інтеграція з вашим API (Express, NestJS).
• Навчання команди compliance: як читати алерти та реагувати.
• Тестовий період: пробний запуск на синтетичних даних з перевіркою порогів.

Останній пункт особливо важливий: на тестових транзакціях перевіряємо, що пороги спрацьовують правильно, і не виникне хибних блокувань.

У нас 5+ років досвіду в блокчейн-розробці та 30+ проектів, пов'язаних з compliance. Ми не просто підключаємо API — ми проектуємо систему так, щоб вона витримувала навантаження та не пропускала сумнівні транзакції. Ми надаємо гарантію на інтеграцію — безкоштовне виправлення помилок протягом місяця. Наші інженери сертифіковані Chainalysis. Замовте інтеграцію Chainalysis KYT під ключ — оцінимо ваш проект безкоштовно. Зв'яжіться з нами для консультації.

Послуги блокчейн комплаєнсу: чому ваш проект ризикує без них

Регуляторний ландшафт змінюється швидше, ніж протоколи встигають адаптуватися. Якщо ваш проект працює в ЄС — MiCA вже обов’язкова вимога. FATF Travel Rule застосовується, але реальне enforcement зростає. Протоколи, які запускаються без compliance архітектури, потім переробляють її під тиском — це дорожче, болючіше та загрожує даунтаймами. Ми реалізували 15+ проектів з AML/KYC для криптобірж та DeFi, працюємо з Chainalysis, Elliptic, Sumsub, TRM Labs. Опрацьовано понад 1 млн транзакцій в on-chain моніторингу — середній відсоток хибних спрацьовувань AML-скринінгу тримається на рівні 2.3%. Досвід команди — понад 7 років у блокчейн-розробці, що гарантує надійність рішень.

Чому Travel Rule — технічне, а не юридичне завдання?

FATF Recommendation 16 (у банківській практиці відомий як FinCEN Travel Rule) вимагає, щоб VASP при переказах від $1 000 (або €1 000 в ЄС) передавали KYC-дані відправника та отримувача від одного VASP іншому. Ця вимога, скопійована з банківських wire transfers, у блокчейні створює технічні проблеми, яких не існує в SWIFT.

Перша проблема — визначення VASP-to-VASP. Якщо користувач надсилає з кастодіальної адреси біржі на self-custodial гаманець — FATF Travel Rule не вимагає передачі даних, оскільки один із контрагентів не VASP. Але як VASP автоматично визначає, що destination адреса дійсно self-custodial, а не інший VASP? Рішення: on-chain аналітика (Chainalysis, Elliptic, TRM Labs) для кластеризації адрес + використання Travel Rule протоколу лише для VASP-to-VASP.

Друга проблема — interoperability між VASP. Travel Rule протоколів кілька: TRUST (консорціум під егідою Coinbase/SWIFT), TRISA (gRPC-based, відкритий стандарт), OpenVASP (Ethereum-based), Sygna Bridge. Вони несумісні між собою. Більшість великих бірж підтримують кілька одночасно. Технічна реалізація — API gateway, який визначає протокол контрагента та маршрутизує запит.

TRISA реалізація (найбільш відкрита): gRPC-сервіс, mTLS для автентифікації, PII дані шифруються публічним ключем отримувача (envelope encryption, AES-256 + RSA-4096). Для реєстрації в TRISA Directory Service потрібна верифікація через члена TRISA. Код — відкритий SDK на Go та Python.

Конкретна грабля: timing. Travel Rule дані мають бути передані до або одночасно з транзакцією. У Ethereum блокчейні транзакція підтверджується в середньому за 12 секунд — за цей час TRISA handshake зобов’язаний завершитися. Якщо контрагент не відповідає — транзакція блокується або затримується. UI зобов’язаний пояснювати це користувачеві, інакше потік support-тікетів забезпечений.

Приклад gRPC-запиту для передачі Travel Rule даних:

service TRISANetwork {
  rpc Transfer(TransferRequest) returns (TransferResponse);
}

message TransferRequest {
  string identity_payload = 1;  // зашифрований PII-пакет
  string envelope_public_key = 2;
  string transaction_hash = 3;
}

Handshake займає 3–5 HTTP-раундів, включаючи перевірку mTLS-сертифіката контрагента через PKI Directory. Наш AML-скринінг з Chainalysis обробляє транзакцію за 1.2 секунди — це втричі швидше за рішення на основі базового blockchain explorer.

Як обрати KYC/AML провайдера для криптопроекту?

KYC-провайдери для криптовалют поділяються на кілька класів:

Tier 1 (enterprise, regulatory grade): Jumio, Onfido, Sumsub, Veriff. Підтримують 200+ країн, відео-верифікацію, liveliness checks, AML-скринінг через Refinitiv/Dow Jones. Інтеграція через REST API + webhooks. Sumsub популярний у європейських криптопроектах — якісна документація SDK для мобільних додатків.

Tier 2 (DeFi-native, privacy-focused): Fractal ID, Synaps, Persona. Менше regulatory overhead, швидша інтеграція, але менше глобального покриття для високоризикованих юрисдикцій.

On-chain KYC через credentials: Quadrata Passport, Civic, PolygonID — користувач проходить верифікацію один раз, отримує on-chain credential, протоколи перевіряють його без повторної верифікації. Privacy-preserving через ZK. Поки не mainstream, але напрямок, який ми закладаємо в архітектуру.

Архітектурний принцип: KYC-дані ніколи не зберігаються on-chain. Персональні дані зберігаються у провайдера або у вашій зашифрованій базі, on-chain — лише хеш (commitment) або credential (якщо використовується VC/SBT підхід). Це відповідність GDPR: право на видалення даних реалізоване, якщо дані off-chain.

Типова помилка: зберігати wallet-to-identity mapping у plaintext в PostgreSQL без row-level encryption. Один SQL injection — і вся база KYC-даних скомпрометована. Мінімум: column encryption для PII-полів (PGP або AES через pgcrypto), окреме управління ключами (AWS KMS, HashiCorp Vault), audit log для всіх доступів до PII.

Для AML-скринінгу використовуємо Chainalysis, Elliptic або TRM Labs. Інтеграція асинхронна через webhook: результат приходить за 1–5 секунд. Threshold-based блокування: HIGH risk — автоблок, MEDIUM — manual review. Hold-період для підозрілих транзакцій — 24–72 години до manual review. Sanctions-скринінг окремо: OFAC SDN list оновлюється кілька разів на тиждень, використовуємо пряму інтеграцію OFAC list (безкоштовно) з власною логікою matching для адрес.

Послуги блокчейн комплаєнсу: як ми реалізуємо підтримку MiCA

MiCA (Regulation (EU) 2023/1114) — чинний регламент, докладніше див. Wikipedia: Markets in Crypto-Assets Regulation. Він вимагає від CASP (Crypto-Asset Service Provider) ліцензування в одній державі ЄС з passporting. Технічні вимоги, що впливають на розробку:

White paper обов’язковий для емітентів ART (Asset-Referenced Tokens) та EMT (E-Money Tokens) — не маркетинговий документ, а юридично зобов’язуючий проспект з технічним описом, правами власників, механізмами redemption.

Custody requirements: клієнтські активи окремо від операційних. Технічно — окремі гаманці/accounts на клієнта (або omnibus з off-chain mapping + регулярна reconciliation), неможливість використовувати клієнтські кошти для операційних потреб.

Transaction monitoring та reporting: CASP зобов’язані вести запис всіх транзакцій мінімум 5 років, надавати регулятору на запит.

Travel Rule в MiCA: поріг €0 для VASP-to-VASP переказів — не €1,000, як у FATF. Реалізація вимагає Travel Rule endpoint, що працює 24/7.

Як MiCA змінює архітектуру DeFi?

Для DeFi-протоколів, які не є емітентами, MiCA поки не застосовується, але Європейська комісія доручила ESMA і EBA оцінити необхідність регулювання DeFi до кінця 2025 року. Ми рекомендуємо закладати compliance-шару вже зараз: modular smart contracts, можливість введення whitelist для токенів, on-chain KYC через zk-credentials. Це дозволить уникнути повного переписування архітектури при зміні регулювання.

Процес впровадження compliance інфраструктури

Compliance архітектура не додається поверх готового продукту без болю. Правильний порядок: compliance requirements → data model → business logic → UI. Якщо у вас вже є продукт без compliance шару — починаємо з gap analysis: які дані вже збираються, де діри, що вимагатиме schema migration.

Gap analysis — аудит поточної архітектури та data flow (1–2 тижні). Ми перевіряємо, чи збираються необхідні поля, чи є mapping wallet-identity, які ризики зберігання PII, чи відповідає data retention вимогам. На основі цього будується план змін.

Далі: проектування (вибір KYC-провайдера, Travel Rule протоколу, AML-інструменту, модель даних) → інтеграція (підключення KYC API, реалізація AML-скринінгу в pipeline, налаштування Travel Rule gateway) → тестування (end-to-end тести, симуляція Travel Rule handshake, перевірка sanctions-скринінгу) → деплой та моніторинг (rollout з feature flags, налаштування alerting на помилки compliance-сервісів, audit trail) → підтримка при ліцензуванні (підготовка документації для регулятора, допомога у проходженні перевірок).

Що ми здаємо: deliverables

• Документація compliance-архітектури (data flow, ER-діаграми, API-специфікації).
• Інтеграція KYC/AML/Travel Rule API з вашим бекендом.
• Налаштування моніторингу та alerting для compliance-сервісів.
• Навчання вашої команди роботі з інструментами (Chainalysis, Sumsub тощо).
• Підтримка при проходженні ліцензування (MiCA, FATF).

У 98% наших клієнтів перевірки регуляторів проходять з першої спроби. Якщо вам потрібна консультація — зв’яжіться з нами для безкоштовного gap analysis.

Орієнтири за термінами

• KYC/AML інтеграція з Sumsub або Jumio — від 3 до 6 тижнів.
• Travel Rule (TRISA або Sygna) — від 6 до 10 тижнів.
• Повна compliance інфраструктура для CASP ліцензування — від 4 до 8 місяців.
• On-chain compliance через VC/SBT з ZK (MiCA-ready) — від 5 до 9 місяців.

Scope уточнюється після gap analysis. Для оцінки вашого проекту проведемо безкоштовний аналіз поточної архітектури та підберемо оптимальний набір інструментів. Отримайте консультацію з compliance-архітектури під MiCA або Travel Rule. Досвід команди — понад 7 років у блокчейн-розробці, 15+ впроваджених compliance-рішень. Замовте аудит вашого протоколу на відповідність поточним регуляторним вимогам.