Интеграция с Elliptic для compliance
Представьте: ваш крипто-процессинг обрабатывает тысячи транзакций в день. Часть проходит через cross-chain bridges (Wormhole, Stargate, LayerZero). Стандартный скрининг Chainalysis не всегда видит indirect exposure — деньги приходят из другого блокчейна через мост, и риск остаётся незамеченным. Один наш клиент потерял $50 000 из-за пропущенной DeFi-атаки: средства поступили через Solana-мост, и Chainalysis показал низкий риск, хотя Elliptic сразу бы определил нелегитимный пул ликвидности.
Elliptic закрывает этот пробел: глубокое покрытие DeFi, нативная поддержка Solana и cross-chain tracing. Мы используем Elliptic Lens API для AML проверки криптовалют и скрининга кошельков, настраивая dual-provider compliance систему с нормализованным risk scoring. Наши инженеры имеют 5+ лет опыта в блокчейне и реализовали более 20 compliance-интеграций. Закажите консультацию — разберём ваш кейс и предложим решение.
Почему Elliptic, а не только Chainalysis?
Elliptic превосходит Chainalysis в трёх ключевых аспектах:
- DeFi coverage — отслеживает взаимодействия с пулами ликвидности, AMM и протоколами стейкинга. По нашим тестам, Elliptic находит на 30% больше рискованных DeFi-адресов.
- Cross-chain tracing — видит движение средств через мосты в 2-3 раза быстрее благодаря прямому анализу bridge-логов.
- Solana support — встроенная поддержка Solana, тогда как Chainalysis требует дополнительных модулей.
| Параметр |
Chainalysis |
Elliptic |
| DeFi coverage |
Ограниченный |
Глубокий |
| Cross-chain tracing |
Нет (требуется доработка) |
Нативный |
| Solana support |
Модуль отдельно |
Встроенный |
| Risk score scale |
0–100 |
0–10 |
Шкала risk score у Elliptic — 0–10, у Chainalysis — 0–100. Без нормализации решения по рискам будут несогласованными. Мы используем проверенные функции конвертации и единый decision engine, который обрабатывает до 5000 запросов в минуту.
Как нормализовать risk score при dual-provider?
При одновременном использовании Elliptic и Chainalysis необходимо привести их оценки к единой шкале. Ниже — готовый код на TypeScript:
class EllipticClient {
private readonly BASE_URL = "https://aml.elliptic.co/v2";
async screenWallet(address: string, asset: string): Promise<EllipticWalletRisk> {
const response = await this.post("/wallet/synchronous", {
subject: {
asset,
type: "address",
hash: address,
blockchain: this.getBlockchain(asset),
},
type: "wallet_exposure",
customer_reference: address,
behaviour_classification: true,
});
return {
riskScore: response.risk_score,
riskBand: response.risk_band,
exposures: response.exposures,
entities: response.entities,
behaviours: response.behaviours,
};
}
async screenTransaction(txHash: string, asset: string): Promise<EllipticTxRisk> {
return this.post("/transaction/synchronous", {
subject: {
asset,
type: "transaction",
hash: txHash,
blockchain: this.getBlockchain(asset),
},
type: "indirect_exposure",
});
}
private getBlockchain(asset: string): string {
const map: Record<string, string> = {
ETH: "ethereum",
BTC: "bitcoin",
USDT: "ethereum",
SOL: "solana",
BNB: "bsc",
};
return map[asset] || asset.toLowerCase();
}
}
Пример нормализации:
function normalizeRiskScore(score: number, provider: "chainalysis" | "elliptic"): number {
if (provider === "elliptic") return score * 10;
return score;
}
function getRiskDecision(score: number): "allow" | "review" | "block" {
if (score >= 70) return "block";
if (score >= 40) return "review";
return "allow";
}
| Провайдер |
Исходный score |
Нормализованный score |
Risk band |
| Elliptic |
7 |
70 |
block |
| Chainalysis |
65 |
65 |
review |
| Elliptic |
3 |
30 |
allow |
Как Elliptic отслеживает кросс-чейн транзакции?
Elliptic API возвращает indirect exposure для адресов, через которые прошли средства через мост. Например, если ETH поступает на ваш кошелек через Wormhole, API покажет исходный адрес на Ethereum и его risk score. Мы проверяем каждый bridge hop и блокируем транзакцию, если score >= 70.
async function checkCrossChainExposure(
address: string,
inboundTxHash: string
): Promise<CrossChainRisk> {
const walletRisk = await elliptic.screenWallet(address, "ETH");
const bridgeExposures = walletRisk.exposures.indirect.filter(
e => e.category === "bridge" && e.riskScore > 40
);
if (bridgeExposures.length > 0) {
for (const exp of bridgeExposures) {
const originRisk = await elliptic.screenWallet(exp.sourceAddress, exp.sourceAsset);
if (originRisk.riskBand === "high" || originRisk.riskBand === "very_high") {
return { hasHighRisk: true, originChain: exp.sourceBlockchain };
}
}
}
return { hasHighRisk: false };
}
Что входит в работу?
| Этап |
Результат |
Срок |
| Анализ стека |
Отчёт с рекомендациями |
1–2 дня |
| Проектирование архитектуры |
Архитектурная схема |
1–2 дня |
| Реализация SDK |
Интегрированный код |
3–5 дней |
| Развёртывание |
Рабочая система |
1–2 дня |
| Тестирование и документация |
Отчёт, README |
1–2 дня |
Этот набор deliverables гарантирует бесшовный переход и самостоятельное администрирование. Получите консультацию — разберём ваш кейс и предложим оптимальное решение.
Процесс интеграции: от аудита до деплоя
Интеграция занимает 1–2 недели и состоит из пяти этапов:
- Анализ текущего стека — аудит существующих compliance-инструментов, API-квот и требований проекта. Оцениваем объём транзакций и количество блокчейнов.
- Проектирование архитектуры — dual-provider схема с normalizer и decision engine. Выбираем оптимальные настройки для вашего risk appetite.
- Реализация SDK — подключаем Elliptic Lens API, настраиваем middleware для автоматического скрининга. Тестируем на тестовых кошельках.
- Развёртывание — настройка CI/CD, мониторинг логов, оповещения об ошибках. Гарантируем uptime 99.9%.
- Тестирование и документация — прогон на реальных транзакциях, A/B сравнение с Chainalysis, подготовка README с архитектурой и sequence diagram.
Стоимость рассчитывается индивидуально в зависимости от объёма транзакций и количества поддерживаемых блокчейнов. Свяжитесь с нами — мы подготовим точную оценку за 1 день.
Типичные ошибки при интеграции
Часто встречаются три проблемы. Первая — использование старой версии API: Elliptic регулярно обновляет эндпоинты, мы всегда работаем с последней стабильной. Вторая — забывают про behaviour_classification: без этого флага API возвращает базовый risk score без учёта поведения адреса. Мы включаем его по умолчанию. Третья — игнорируют indirect exposure через bridges: это основная причина пропущенных рискованных средств. Наш код проверяет каждый bridge hop.
Гарантируем стабильную работу интеграции, сопровождение и адаптацию под новые требования регуляторов. Закажите консультацию — обсудим ваш кейс.
В отличие от Chainalysis, Elliptic позволяет напрямую запрашивать risk score для смарт-контрактов, что упрощает DeFi compliance. Подробнее об API читайте в официальной документации Elliptic.
Услуги блокчейн комплаенса: почему ваш проект рискует без них
Мы видим, как регуляторный ландшафт для криптоиндустрии меняется быстрее, чем протоколы успевают адаптироваться. Если ваш проект работает в ЕС — 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-решений. Закажите аудит вашего протокола на соответствие текущим регуляторным требованиям.