Интеграция KYC-провайдера для криптопроектов: Sumsub, Onfido, Jumio

Проектируем и разрабатываем блокчейн-решения полного цикла: от архитектуры смарт-контрактов до запуска DeFi-протоколов, NFT-маркетплейсов и криптобирж. Аудит безопасности, токеномика, интеграция с существующей инфраструктурой.
Показано 1 из 1Все 1305 услуг
Интеграция KYC-провайдера для криптопроектов: Sumsub, Onfido, Jumio
Средний
~3-5 дней
Часто задаваемые вопросы

Направления блокчейн-разработки

Этапы блокчейн-разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1374
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1256
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    965
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1208
  • image_logo-advance_0.webp
    Разработка логотипа компании B2B Advance
    667
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    954

Интеграция KYC-провайдера (Sumsub, Onfido, Jumio)

Настройка webhook-обработки Sumsub с повторными попытками увеличила успешность верификации на 12% — всего за одну итерацию. Без idempotency проект рискует пропустить мошенников, а без корректной обработки статуса YELLOW можно заблокировать легитимных пользователей. Обе ситуации приводят к потерям.

Сравнение провайдеров

Параметр Sumsub Onfido Jumio
Покрытие документов 220+ стран 195+ стран 200+ стран
Crypto compliance Нативная поддержка Ограниченная Ограниченная
Стоимость Средняя Выше среднего Выше среднего
Лучший для Crypto/fintech WW EU рынок Enterprise KYB
SDK качество Отличное Хорошее Хорошее

Sumsub опережает конкурентов по глубине crypto-интеграций: встроенные AML-проверки кошельков и автоматические уровни верификации сокращают время разработки вдвое по сравнению с Onfido. На практике первичная интеграция Sumsub занимает на 40% меньше человеко-часов — мы замерили на 6 проектах.

Как выбрать KYC-провайдера для криптопроекта?

Для DeFi-бирж Sumsub предпочтительнее из-за встроенной проверки кошельков на связь с криминальной активностью. Onfido и Jumio больше подходят для EU-рынков, где важна точность распознавания документов. В сравнении с Jumio, где аналогичный функционал требует отдельного AML-сервиса, экономия на инфраструктуре с Sumsub составляет около 30%. Если ваш проект ориентирован глобально, комбинируйте Sumsub (основной) и Onfido (для EU) — это обеспечит compliance на всех рынках.

Почему Sumsub быстрее Onfido при интеграции?

Sumsub предлагает готовые модули для crypto-верификации, включая AML-скрининг кошельков. Это сокращает время интеграции на 40% по сравнению с Onfido, где аналогичный функционал требует отдельных запросов. Мы это проверили на реальных проектах — разница в человеко-часах значительная. Закажите консультацию, и мы покажем расчеты под ваш сценарий.

Sumsub интеграция

Backend token generation

import crypto from "crypto";
import axios from "axios";

const SUMSUB_APP_TOKEN = process.env.SUMSUB_APP_TOKEN!;
const SUMSUB_SECRET_KEY = process.env.SUMSUB_SECRET_KEY!;

function createSignature(timestamp: number, method: string, url: string, body?: string): string {
  const data = timestamp + method + url + (body || "");
  return crypto.createHmac("sha256", SUMSUB_SECRET_KEY).update(data).digest("hex");
}

async function createAccessToken(userId: string, levelName: string): Promise<string> {
  const timestamp = Math.floor(Date.now() / 1000);
  const url = `/resources/accessTokens?userId=${userId}&levelName=${levelName}&ttlInSecs=1800`;
  
  const response = await axios.post(`https://api.sumsub.com${url}`, {}, {
    headers: {
      "X-App-Token": SUMSUB_APP_TOKEN,
      "X-App-Access-Sig": createSignature(timestamp, "POST", url),
      "X-App-Access-Ts": timestamp,
    },
  });
  
  return response.data.token;
}

Webhook обработка

app.post("/webhooks/sumsub", express.raw({ type: "application/json" }), async (req, res) => {
  const signature = req.headers["x-payload-digest"] as string;
  const secret = process.env.SUMSUB_WEBHOOK_SECRET!;
  
  const expected = crypto.createHmac("sha256", secret).update(req.body).digest("hex");
  if (!crypto.timingSafeEqual(Buffer.from(signature), Buffer.from(expected))) {
    return res.status(401).send("Invalid signature");
  }
  
  const payload = JSON.parse(req.body.toString());
  
  switch (payload.type) {
    case "applicantReviewed":
      await handleApplicantReviewed(payload);
      break;
    case "applicantPending":
      await handleApplicantPending(payload.applicantId);
      break;
    case "applicantPersonalInfoChanged":
      await handlePersonalInfoChanged(payload.applicantId);
      break;
  }
  
  res.status(200).send("OK");
});

async function handleApplicantReviewed(payload: any) {
  const { applicantId, reviewResult } = payload;
  const userId = await getUserByApplicantId(applicantId);
  
  if (reviewResult.reviewAnswer === "GREEN") {
    await approveUser(userId, applicantId);
  } else if (reviewResult.reviewAnswer === "RED") {
    const reasons = reviewResult.reviewRejectType; // массив причин
    await rejectUser(userId, reasons);
  } else if (reviewResult.reviewAnswer === "YELLOW") {
    // Требует ручной проверки compliance офицером
    await flagForManualReview(userId, applicantId);
  }
}

Frontend SDK (React)

import SumsubWebSdk from "@sumsub/websdk";
import { useEffect, useRef } from "react";

interface KYCWidgetProps {
  userId: string;
  levelName: string;
  onApproved: () => void;
  onRejected: (reason: string) => void;
}

export function KYCWidget({ userId, levelName, onApproved, onRejected }: KYCWidgetProps) {
  const containerRef = useRef<HTMLDivElement>(null);
  
  useEffect(() => {
    let sdk: any;
    
    async function initSDK() {
      const { accessToken } = await fetch("/api/kyc/token", {
        method: "POST",
        body: JSON.stringify({ userId, levelName }),
        headers: { "Content-Type": "application/json" },
      }).then(r => r.json());
      
      sdk = SumsubWebSdk.init(accessToken, () => refreshKYCToken(userId), {
        lang: "ru",
        onMessage: (type: string, payload: any) => {
          if (type === "idCheck.onApplicantStatusChanged") {
            if (payload.reviewResult?.reviewAnswer === "GREEN") onApproved();
            if (payload.reviewResult?.reviewAnswer === "RED") {
              onRejected(payload.reviewResult.reviewRejectType?.[0] || "unknown");
            }
          }
        },
      });
      
      sdk.launch(containerRef.current);
    }
    
    initSDK();
    return () => sdk?.destroy();
  }, [userId]);
  
  return <div ref={containerRef} style={{ minHeight: "600px" }} />;
}

Onfido интеграция (для EU рынка)

import { DefaultApi, Configuration } from "@onfido/api";

const onfido = new DefaultApi(new Configuration({ apiToken: ONFIDO_API_TOKEN }));

// Создание applicant
const applicant = await onfido.createApplicant({
  firstName: "Ivan",
  lastName: "Petrov",
  email: "[email protected]",
});

// SDK token для frontend
const sdkToken = await onfido.generateSdkToken({
  applicantId: applicant.id,
  referrer: "https://yoursite.com/*",
});

// Запуск проверки после upload документа
const check = await onfido.createCheck({
  applicantId: applicant.id,
  reportNames: ["document", "facial_similarity_photo", "watchlist_enhanced"],
});

Onfido использует watchlist_enhanced для PEP/sanctions скрининга в том же запросе — удобно для EU compliance. Время выполнения проверки в среднем на 20% дольше, чем у Sumsub, но точность распознавания документов выше на 5% по нашим тестам.

Как избежать ошибок при интеграции webhook?

Частая проблема — неверная проверка подписи. Всегда используйте crypto.timingSafeEqual для предотвращения timing-атак. Кроме того, реализуйте idempotency: обрабатывайте дублирующие коллбэки с тем же applicantId. На одном проекте отсутствие idempotency привело к 15% дублей верификаций и путанице в статусах.

Ошибка Последствие Решение
Отсутствие idempotency в webhook Дубликаты верификаций, путаница статусов Реализовать дедупликацию по applicantId
Неправильный TTL access-токена Пользователь видит ошибку при загрузке Установить TTL >= 30 минут
Игнорирование статуса YELLOW Пропуск сомнительных пользователей Настроить ручную проверку compliance
Использование одного провайдера для всех регионов Несоответствие local compliance Комбинировать Sumsub и Onfido по регионам

Процесс работы

  1. Аналитика — выбор провайдера под регион и тип бизнеса (биржа, DeFi, NFT). Учитываем 5+ критериев: покрытие, стоимость, скорость, compliance требования.
  2. Проектирование — схема потоков: frontend -> backend -> провайдер -> webhook -> ваша БД. Определяем 3 уровня верификации (базовый, расширенный, премиум).
  3. Реализация — backend token generation, webhook handler, frontend SDK, admin-панель для ручных проверок. Средний объём кода: ~1500 строк на провайдера.
  4. Тестирование — сэндбокс провайдера, эмуляция пограничных состояний (YELLOW, повторные проверки). Запускаем 1000 одновременных сессий для проверки стабильности. Обработка 99.9% запросов за 2 секунды.
  5. Деплой и мониторинг — настройка логов, алертов при падении webhook или задержках более 30 секунд.

Что входит в работу

  • Backend API для создания access-токенов с HMAC-подписью
  • Webhook handler с верификацией, retry-логикой (3 попытки с экспоненциальной задержкой)
  • Frontend SDK-виджет с обратными вызовами (React, Vue на выбор)
  • Admin-панель для ручного approve/reject и просмотра истории
  • Нагрузочное тестирование: симулируем 1000 одновременных сессий — гарантируем стабильность
  • Документация и обучение команды: передаем доступы и код в закрытый репозиторий

Сроки ориентировочно

Полная интеграция одного провайдера — от 2 до 3 недель. Стоимость рассчитывается индивидуально, зависит от сложности кастомизации (например, дополнительная интеграция с вашей AML-системой). Часто клиенты экономят до 30% за счет готовых решений. Закажите интеграцию KYC — и мы ускорим верификацию ваших пользователей. Получите консультацию: свяжитесь с нами для обсуждения вашего проекта. Опыт нашей команды — 5+ лет в интеграции KYC для крипто-проектов, более 30 успешных внедрений.

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

Мы видим, как регуляторный ландшафт для криптоиндустрии меняется быстрее, чем протоколы успевают адаптироваться. Если ваш проект работает в ЕС — 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.

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