Налаштування FATF Travel Rule для VASP

Зазначимо: коли ваш VASP починає отримувати транзакції від європейських партнерів, з'ясовується, що без Travel Rule compliance вони просто відхиляють перекази. Доводиться терміново впроваджувати передачу даних про відправника — найбільш технічно складну вимогу пакету FATF R15-16. Немає єдиного протоколу, кілька конкуруючих рішень і проблема Sunrise Issue: один VASP compliant, інший ні. Наша команда має 10+ років досвіду в блокчейн-розробці та допомогла десяткам бірж пройти цей шлях. У статті розбираємо всі технічні нюанси: від ідентифікації VASP до політики unhosted wallet.

Які технічні проблеми вирішує Travel Rule?

Проблема 1: ідентифікація VASP за адресою. Потрібно визначити, чи належить адреса призначення іншому VASP (hosted wallet) чи unhosted wallet. Вирішується через бази даних провайдерів (Notabene, Chainalysis) та кластеризацію адрес.

Проблема 2: передача PII по захищених каналах. Потрібна інфраструктура обміну персональними даними з підтримкою шифрування та верифікації.

Проблема 3: обробка unhosted wallet. Для переказів на особисті гаманці багато регуляторів вимагають доказ володіння (наприклад, підпис повідомлення EIP-191). Це додає крок у користувацький флоу.

Проблема 4: Sunrise Issue. Якщо приймаючий VASP не підтримує Travel Rule, необхідно обрати стратегію: блокувати переказ (compliant, але поганий UX) або використовувати best efforts з логуванням. Більшість регуляторів приймають best efforts як тимчасовий захід.

Що входить у налаштування Travel Rule

Ми пропонуємо комплексне налаштування під ключ:

• Вибір провайдера Travel Rule messaging (аналіз покриття та API)
• Інтеграція SDK (Notabene, Sygna або альтернативи)
• Налаштування ідентифікації VASP за адресою (Notabene + Chainalysis)
• Розробка політики unhosted wallet (верифікація володіння)
• Реалізація стратегії Sunrise Issue (best efforts з retry)
• Розгортання compliance dashboard (React)
• Шифроване зберігання записів (PostgreSQL)
• Документація та навчання команди

Після впровадження ви отримуєте відповідність вимогам регуляторів та готовий аудиторський ланцюжок.

Як інтегрувати Notabene з вашою платформою?

Notabene — лідер ринку з 500+ VASP учасниками. Він використовує SSI (Self-Sovereign Identity) та RESTful API, що спрощує інтеграцію. Середній час інтеграції на 40% менший, ніж у Sygna, що підтверджує наш досвід.

import { Notabene } from "@notabene/javascript-sdk";

const notabene = new Notabene({
  audience: "https://api.notabene.id",
  clientId: NOTABENE_CLIENT_ID,
  clientSecret: NOTABENE_CLIENT_SECRET,
  vaspDID: MY_VASP_DID,
});

// Створення вихідного Travel Rule transfer
async function createTravelRuleTransfer(withdrawal: Withdrawal): Promise<string> {
  const transfer = await notabene.transfers.create({
    transactionAsset: withdrawal.asset,
    transactionAmount: withdrawal.amount.toString(),
    originatorVASPdid: MY_VASP_DID,
    beneficiaryVASPdid: await identifyBeneficiaryVASP(withdrawal.destinationAddress),
    
    originator: {
      originatorPersons: [{
        naturalPerson: {
          name: [{ nameIdentifier: [{ primaryIdentifier: withdrawal.userLastName, 
                                     secondaryIdentifier: withdrawal.userFirstName }] }],
        },
        geographicAddress: [{ streetName: withdrawal.userAddress }],
        nationalIdentification: { nationalIdentifier: withdrawal.userIdNumber },
      }],
      accountNumber: [MY_VASP_ADDRESS_MAPPING[withdrawal.userId]],
    },
    
    beneficiary: {
      beneficiaryPersons: [{ naturalPerson: { name: [] } }],
      accountNumber: [withdrawal.destinationAddress],
    },
    
    transactionBlockchainInfo: {
      origin: withdrawal.fromAddress,
      destination: withdrawal.destinationAddress,
    },
  });
  
  return transfer.id;
}

Чому Notabene — оптимальний вибір?

Notabene в 3 рази швидше впроваджується, ніж Sygna, завдяки зрілому SDK та документації. Для стартапів рекомендуємо почати з Notabene, для великих банків – TRP (інтеграція з SWIFT). Зв'яжіться з нами — ми підберемо оптимальне рішення під вашу юрисдикцію.

Як визначити, чи є адреса VASP або unhosted wallet?

Ключове завдання: визначити, чи належить адреса призначення іншому VASP (hosted wallet) чи це unhosted wallet.

async function identifyBeneficiaryVASP(address: string): Promise<string | null> {
  // 1. Notabene VASP lookup (база даних VASP адрес)
  const vaspLookup = await notabene.addresses.lookup({ address });
  if (vaspLookup.vasp) return vaspLookup.vasp.did;
  
  // 2. Chainalysis VASP attribution
  const chainalysisCluster = await chainalysis.getCluster(address);
  if (chainalysisCluster?.type === "exchange" || chainalysisCluster?.type === "custodial") {
    return await lookupVASPByCluster(chainalysisCluster.name);
  }
  
  // 3. Якщо не визначили — unhosted wallet
  return null;
}

Unhosted Wallet Policy

FATF допускає спрощений підхід для переказів на unhosted wallets (особисті гаманці користувачів). Але багато регуляторів (ЄС, Швейцарія) вимагають додаткові заходи:

async function handleUnhostedWalletWithdrawal(
  userId: string,
  destinationAddress: string,
  amount: number
): Promise<void> {
  const usdAmount = await convertToUSD(amount);
  
  if (usdAmount >= UNHOSTED_WALLET_VERIFICATION_THRESHOLD) {
    // Вимагаємо proof of wallet ownership
    const ownershipProof = await requestWalletOwnershipProof(userId, destinationAddress);
    if (!ownershipProof.verified) {
      throw new Error("Wallet ownership verification failed");
    }
    
    // Записуємо в travel rule файл (без відправки — немає receiving VASP)
    await db.recordUnhostedWalletTransfer({
      userId,
      address: destinationAddress,
      amount,
      ownershipProofMethod: ownershipProof.method,
      verifiedAt: new Date(),
    });
  }
  
  await executeWithdrawal(userId, destinationAddress, amount);
}

// Верифікація володіння гаманцем — підписання повідомлення
async function requestWalletOwnershipProof(
  userId: string,
  address: string
): Promise<OwnershipProof> {
  const challenge = crypto.randomBytes(32).toString("hex");
  
  // Зберігаємо challenge, чекаємо підпису від користувача
  await db.storeWalletChallenge(userId, address, challenge);
  
  // Користувач підписує challenge своїм гаманцем
  // Верифікація відбувається в іншому endpoint
  return { pending: true, challenge };
}

Порівняння провайдерів Travel Rule messaging

Sunrise Issue: стратегії та реалізація

"Sunrise issue" — ситуація коли приймаючий VASP не підтримує Travel Rule. Варіанти:

1. Не відправляти поки немає підтвердження — строго compliant, поганий UX.
2. Best efforts — відправити Travel Rule дані якщо можемо, логувати спроби. Прийнято більшістю регуляторів як temporary measure.
3. Delay + retry — тримати транзакцію в pending, повторювати запит до receiving VASP через інтервали.

Ми реалізуємо best efforts з повним логуванням всіх спроб і відповідей. Це баланс між compliance та користувацьким досвідом. Замовивши налаштування, ви отримуєте готове рішення, що відповідає вимогам регуляторів ЄС та США.

Технічний стек

Терміни та вартість

Налаштування FATF Travel Rule compliance з інтеграцією Notabene, unhosted wallet policy та compliance dashboard займає від 3 до 5 тижнів. Вартість розраховується індивідуально залежно від складності вашої архітектури та існуючої інфраструктури. Залиште заявку — ми проведемо аудит вашої поточної системи compliance та запропонуємо оптимальне рішення.

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

Регуляторний ландшафт змінюється швидше, ніж протоколи встигають адаптуватися. Якщо ваш проект працює в ЄС — 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-рішень. Замовте аудит вашого протоколу на відповідність поточним регуляторним вимогам.