Настройка FATF Travel Rule для VASP: Notabene и unhosted wallets

Настройка 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);
}

// Верификация владения кошельком — message подписание
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 архитектуры, потом переделывают её под давлением — это дороже, болезненнее и грозит даунтаймами. Услуги блокчейн комплаенса включают полный цикл: от gap analysis до запуска и поддержки при лицензировании. Мы реализовали 15+ проектов по AML/KYC для криптобирж и DeFi, работаем с Chainalysis, Elliptic, Sumsub, TRM Labs. Обработано более 1 млн транзакций в on-chain мониторинге — средний процент ложных срабатываний AML-скрининга держится на уровне 2.3%.

Почему 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-тикетов обеспечен.

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

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

Как выбрать 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

Markets in Crypto-Assets Regulation (EU 2023/1114) — ссылка на Wikipedia — требует от 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.

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

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

1. Gap analysis — аудит текущей архитектуры и data flow (1–2 недели).
2. Проектирование — выбор KYC-провайдера, Travel Rule протокола, AML-инструмента, модель данных.
3. Интеграция — подключение KYC API, реализация AML-скрининга в pipeline, настройка Travel Rule gateway.
4. Тестирование — end-to-end тесты, симуляция Travel Rule handshake, проверка sanctions-скрининга.
5. Деплой и мониторинг — rollout с feature flags, настройка alerting на ошибки compliance-сервисов, audit trail.
6. Поддержка при лицензировании — подготовка документации для регулятора, помощь в прохождении проверок.

Что включает услуга блокчейн комплаенса?

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

Ориентиры по срокам

• 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-решений. Закажите аудит вашего протокола на соответствие текущим регуляторным требованиям.