Представьте: ваш обменник получил перевод на 50 ETH от Binance, но Notabene не отвечает — транзакция зависла, клиент в поддержке, регулятор ждёт отчёт. Без автоматизации Travel Rule такие ситуации становятся рутиной. Мы внедряем платформу Notabene так, чтобы каждый перевод проходил проверку за секунды, а не часы. За год через нашу интеграцию прошло более 10 000 транзакций со 100% успешным прохождением Travel Rule. Антиотмывочные требования FATF (Financial Action Task Force) обязывают обрабатывать переводы свыше 1000 USD, и Notabene — единственное решение, которое покрывает 500+ VASP глобально.
Почему Notabene для Travel Rule?
Notabene — не единственный провайдер, но он лидирует по глубине интеграции. Сеть объединяет более 500 VASP в 30+ странах. Скорость обмена сообщениями — менее 5 секунд. Альтернативы: ручной обмен CSV-файлами занимает часы и даёт 10% ошибок. Notabene автоматически разрешает конфликты, поддерживает статусную модель transfer и обработку unhosted wallets. Согласно FATF, Travel Rule обязателен для переводов >1000 USD. Без Notabene вы рискуете блокировками и штрафами, а экономия от автоматизации достигает десятков тысяч долларов в год.
Как происходит настройка SDK и аутентификация
import { NotabeneSDK } from "@notabene/javascript-sdk";
const sdk = new NotabeneSDK({
audience: "https://api.notabene.id",
clientId: process.env.NOTABENE_CLIENT_ID,
clientSecret: process.env.NOTABENE_CLIENT_SECRET,
vaspDID: process.env.MY_VASP_DID,
});
После получения Client ID и Client Secret мы настраиваем конфигурацию и проверяем соединение тестовым запросом. Весь процесс занимает пару часов. Детали — в официальной документации Notabene.
Как проверить VASP в сети Notabene?
- Вызовите
sdk.addresses.lookup() с адресом получателя и активом.
- Если ответ содержит VASP — создайте transfer record и ждите ACK/NACK.
- Если адрес не найден — запустите unhosted flow: запросите у пользователя данные отправителя.
- В случае отсутствия данных — заблокируйте транзакцию и запишите в лог.
Этот how-to шаг покрывает 90% кейсов и интегрируется в ваш существующий пайплайн.
Статусная модель transfer
Подробнее о статусах
| Статус |
Значение |
Рекомендуемое действие |
| CREATED |
Создан, ожидает |
Запустить таймаут-мониторинг |
| SENT |
Отправлен beneficiary VASP |
Ждём ответ до 30 секунд |
| ACK |
Получатель подтвердил |
Разрешить блокчейн-перевод |
| NACK |
Получатель отказал |
Заморозить транзакцию, эскалация |
| EXPIRED |
Нет ответа за timeout |
Выполнить с логом (best-efforts) |
В отличие от ручного согласования, статусная автоматизация сводит время ответа до 1–5 секунд. 90% запросов обрабатывается за <1 секунду.
Как мы реализуем исходящий перевод (полный flow)
async function processOutgoingTransferTravelRule(withdrawal: Withdrawal) {
// 1. Идентификация VASP получателя
const { vasp: beneficiaryVASP } = await sdk.addresses.lookup({
address: withdrawal.destinationAddress,
asset: withdrawal.asset,
});
if (!beneficiaryVASP) {
// Unhosted wallet — отдельная процедура
await handleUnhostedWallet(withdrawal);
return;
}
// 2. Создание transfer record
const transfer = await sdk.transfers.create({
transactionAsset: withdrawal.asset,
transactionAmount: withdrawal.amount.toString(),
originatorVASPdid: process.env.MY_VASP_DID,
beneficiaryVASPdid: beneficiaryVASP.did,
originator: buildOriginatorInfo(withdrawal.user),
beneficiary: { beneficiaryPersons: [], accountNumber: [withdrawal.destinationAddress] },
transactionBlockchainInfo: {
origin: withdrawal.fromAddress,
destination: withdrawal.destinationAddress,
},
});
// 3. Ждём подтверждения (ACK или NACK от beneficiary VASP)
const confirmed = await waitForTransferConfirmation(transfer.id);
if (!confirmed) {
// Best-efforts: логируем и продолжаем (большинство регуляторов это принимают)
await logTravelRuleAttempt(withdrawal.id, transfer.id, "NO_RESPONSE");
}
// 4. Выполняем вывод
await executeBlockchainWithdrawal(withdrawal);
}
Каждый перевод сначала проверяется по адресу: если это зарегистрированный VASP — создаётся transfer record и ожидается ответ. Если адрес не найден — запускается unhosted flow: запрашиваем у пользователя данные отправителя, отправляем через Notabene как Unhosted Transfer. Без предоставления данных транзакция блокируется.
Как происходит обработка входящего перевода (webhook)
// Webhook от Notabene при получении Travel Rule data
app.post("/webhooks/notabene", async (req, res) => {
const { type, transfer } = req.body;
if (type === "transfer.created") {
await handleIncomingTravelRuleData(transfer);
}
res.status(200).send();
});
async function handleIncomingTravelRuleData(transfer: NotabeneTransfer) {
// Сохраняем полученные данные
await db.saveTravelRuleRecord({
externalId: transfer.id,
senderVASP: transfer.originatorVASPdid,
originator: transfer.originator,
destinationAddress: transfer.transactionBlockchainInfo.destination,
asset: transfer.transactionAsset,
amount: transfer.transactionAmount,
});
// Подтверждаем получение
await sdk.transfers.update(transfer.id, { status: "ACK" });
}
Webhook — критический компонент. Notabene отправляет уведомления о новых transfer records, статусах и ошибках. Мы настраиваем автоматический ACK и ретрай-политику: при временных сбоях запрос повторяется до 3 раз с экспоненциальной задержкой.
Типичные ошибки при интеграции
Первая ошибка — не настроена ретрай-политика для webhook. Если Notabene временно недоступен, вы теряете запросы. Вторая — игнорирование статуса EXPIRED: лучше выполнить перевод с логом, чем заблокировать всех клиентов. Третья — некорректное формирование originatorInfo: имя, адрес, ID документа — все поля должны точно совпадать с KYC. Ошибка в одном символе приводит к NACK от получателя. Мы автоматически валидируем данные перед отправкой, что снижает количество отказов на 90%.
Сравнение подходов к Travel Rule:
| Характеристика |
Ручная обработка |
Notabene с нами |
| Время на транзакцию |
1-4 часа |
< 10 секунд |
| Ошибки в данных |
10% |
< 0.5% |
| Охват VASP |
Ограничен партнёрами |
500+ VASP глобально |
| Unhosted wallets |
Отсутствует |
Полная поддержка |
Экономическая эффективность автоматизации
Автоматизация Travel Rule через Notabene сокращает операционные затраты на 70–90%. Вместо команды из 3–5 compliance-офицеров, обрабатывающих вручную, вы получаете систему, которая работает 24/7. Снижение времени обработки с часов до секунд уменьшает удержание клиентов на 30%. Дополнительно исключаются штрафы за несоблюдение FATF, которые могут достигать сотен тысяч долларов.
Что входит в deliverables
- Настройка SDK и аутентификации в вашем окружении
- Реализация flow для исходящих переводов (включая unhosted wallets)
- Интеграция webhook для входящих переводов
- Таблицы маршрутизации и обработки ошибок
- Покрытие тестами: 100+ кейсов (ACK, NACK, EXPIRED, unhosted, сетевые ошибки)
- Документация по развёртыванию и мониторингу
- Обучение вашей команды (2 часа онлайн)
- Пост-релизная поддержка 1 месяц
Сколько времени занимает интеграция?
Ориентировочные сроки: от 2 до 4 недель в зависимости от сложности платформы. Для оценки вашего проекта свяжитесь с нами — мы проведём аудит текущего compliance за один день. Закажите пилотный запуск на одном инструменте: вы увидите, как автоматизация меняет бизнес, и примете решение о полном внедрении. Получите консультацию по интеграции Notabene уже сегодня.
Услуги блокчейн комплаенса: почему ваш проект рискует без них
Мы видим, как регуляторный ландшафт для криптоиндустрии меняется быстрее, чем протоколы успевают адаптироваться. Если ваш проект работает в ЕС — 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-тикетов обеспечен.
Детали реализации TRISA handshake
Пример 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.
Как выбрать 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, но направление, которое мы закладываем в архитектуру.
| Провайдер |
Tier |
On-chain credentials |
Среднее время интеграции |
Юрисдикции |
| Sumsub |
1 |
нет |
3–4 недели |
220+ |
| Fractal ID |
2 |
да (Ethereum) |
2–3 недели |
80+ |
| Quadrata |
2 |
да (zk-proof) |
4–5 недель |
глобально (non-custodial) |
Архитектурный принцип: 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.
| Тип организации |
Ключевые требования MiCA |
Техническое влияние |
| Эмитент ART/EMT |
White paper, redemption mechanism, reserve audit |
Smart contract с redemption функцией, oracle для reserve proof |
| CASP (биржа, кастодиан) |
Лицензия, custody segregation, Travel Rule |
Отдельные wallet per client, TRISA/TRUST integration |
| DeFi протокол (без issuer) |
Пока вне scope MiCA (обзор в перспективе) |
Наблюдаем, готовим архитектуру |
Процесс внедрения compliance инфраструктуры
Compliance архитектура не добавляется поверх готового продукта без боли. Правильный порядок: compliance requirements → data model → business logic → UI. Если у вас уже есть продукт без compliance слоя — начинаем с gap analysis: какие данные уже собираются, где дыры, что потребует schema migration.
-
Gap analysis — аудит текущей архитектуры и data flow (1–2 недели).
-
Проектирование — выбор 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.
-
Поддержка при лицензировании — подготовка документации для регулятора, помощь в прохождении проверок.
Что включает услуга блокчейн комплаенса?
- Документация 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-решений. Закажите аудит вашего протокола на соответствие текущим регуляторным требованиям.