Інтеграція 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: "uk",
        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 архітектури, потім переробляють її під тиском — це дорожче, болючіше та загрожує даунтаймами. Ми реалізували 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, але напрямок, який ми закладаємо в архітектуру.

Провайдер 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

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 Технічний вплив
Емітент 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 (огляд у перспективі) Спостерігаємо, готуємо архітектуру

Як 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-рішень. Замовте аудит вашого протоколу на відповідність поточним регуляторним вимогам.