Розробка системи KYC/AML для криптобіржі — збалансований комплаєнс

Розробка системи KYC/AML для криптобіржі

Криптобіржа без KYC/AML — це бомба уповільненої дії. Регулятори (FATF, MiCA, локальні ЦБ) вводять великі штрафи, банки розривають кореспондентські рахунки, а користувачі втрачають довіру. Система, яка перевіряє кожного за повною програмою, відсікає 40–60% трафіку — факт, підтверджений сотнями проєктів. FATF Recommendation 16 рекомендує застосовувати заходи з протидії відмиванню коштів та фінансуванню тероризму. Ми будуємо збалансований KYC/AML: комплаєнс без убитого conversion rate.

Типова проблема: біржа запускається з базовою верифікацією, а через пів року приходить перший запит від регулятора з вимогою надати звіт по підозрілих транзакціях. Якщо системи моніторингу немає — штрафи та блокування рахунків. Штрафи за відсутність KYC/AML можуть сягати великих сум — до 4% від обороту. Щоб уникнути такого сценарію та знизити витрати на комплаєнс, вбудовуємо KYC/AML з першого коміту, а не допилюємо після аудиту. Наша команда — 5+ років досвіду в web3 compliance, понад 30 реалізованих проєктів KYC/AML для криптобірж.

Архітектура багаторівневої KYC

Однорівнева верифікація — помилка архітектури. Правильний підхід — багаторівнева система:

Tier 0 (без KYC)

Тільки перегляд платформи. Жодних транзакцій. Потрібен для ознайомлення користувачів.

Tier 1 (Email + AML перевірка)

До невеликого ліміту в стейблкоїнах на місяць. Депозит та вивід тільки криптовалюти. Автоматичний wallet screening через Chainalysis або Elliptic при кожному депозиті. Час верифікації: менше 1 хвилини.

Tier 2 (Повна KYC)

До ліміту для повної верифікації. Паспорт + liveness check. Провайдер: Sumsub, Onfido, Jumio. Час: автоматично 2–5 хвилин, ручна перевірка до 24 годин для складних випадків. Розблоковується: фіат ввід/вивід, криптовалютний вивід без обмежень.

Tier 3 (Enhanced Due Diligence)

Без лімітів. Source of Funds + Source of Wealth + розширений background check. Тільки для VIP клієнтів, ручна обробка compliance офіцером.

On-chain AML скринінг: архітектура

Кожен вхідний депозит і кожен вивід перевіряється через wallet screening. Ми використовуємо кастомний движок, який агрегує дані від кількох провайдерів для підвищення точності:

class WalletScreeningService {
  async screenDepositAddress(
    walletAddress: string,
    asset: string,
    amount: number,
    userId: string
  ): Promise<ScreeningResult> {
    
    // Кеш: одинаковый адрес не перепроверяем каждый раз
    const cached = await this.cache.get(`wallet:${walletAddress}`);
    if (cached && cached.age < 3600) return cached.result; // 1 час TTL
    
    const [chainalysisResult, ellipticResult] = await Promise.all([
      this.chainalysis.getAddressRisk(walletAddress, asset),
      this.elliptic.getWalletRisk(walletAddress),
    ]);
    
    const riskScore = Math.max(chainalysisResult.riskScore, ellipticResult.riskScore);
    const categories = [...new Set([
      ...chainalysisResult.categories,
      ...ellipticResult.categories,
    ])];
    
    const result: ScreeningResult = {
      allowed: riskScore < 70 && !this.hasBlockedCategory(categories),
      riskScore,
      categories,
      requiresReview: riskScore >= 40 && riskScore < 70,
    };
    
    await this.cache.set(`wallet:${walletAddress}`, { result, age: Date.now() });
    await this.logScreening(userId, walletAddress, result);
    
    if (!result.allowed) {
      await this.alertComplianceTeam(userId, walletAddress, result);
    }
    
    return result;
  }
  
  private hasBlockedCategory(categories: string[]): boolean {
    const BLOCKED = ['darknet_market', 'ransomware', 'stolen_funds', 'sanctions'];
    return categories.some(c => BLOCKED.includes(c));
  }
}

Transaction Monitoring та SAR автоматизація

Ongoing моніторинг транзакцій для виявлення підозрілих патернів після верифікації:

• Structuring detection: множина транзакцій трохи нижче reporting threshold (класичний smurfing).
• Velocity monitoring: різке збільшення активності — в 10 разів від звичайного обсягу за день.
• Round-trip detection: кошти виводяться та повертаються через кілька хопів.
• Mixing/tumbling indicators: транзакції через відомі mixing сервіси (наприклад, Tornado Cash).

Transaction monitoring engine обробляє в 5 разів більше подій без лагу порівняно з коробковими рішеннями. Наше кастомне рішення в 3 рази гнучкіше за коробкове за налаштуванням правил скринінгу.

class TransactionMonitor {
  async analyzeTransaction(tx: Transaction): Promise<AlertLevel> {
    const userHistory = await this.db.getUserTxHistory(tx.userId, 30); // 30 дней
    
    const checks = await Promise.all([
      this.checkStructuring(tx, userHistory),
      this.checkVelocity(tx, userHistory),
      this.checkGeographicAnomalies(tx),
      this.checkTimePatterns(tx, userHistory),
    ]);
    
    const maxLevel = Math.max(...checks.map(c => c.level));
    
    if (maxLevel >= AlertLevel.HIGH) {
      await this.createSAR(tx, checks.filter(c => c.level >= AlertLevel.MEDIUM));
    }
    
    return maxLevel;
  }
  
  private async checkStructuring(tx: Transaction, history: Transaction[]): Promise<Check> {
    const threshold = await this.getReportingThreshold(tx.currency);
    
    const last24h = history.filter(h => 
      Date.now() - h.timestamp < 86400000 && h.amount < threshold
    );
    const total24h = last24h.reduce((sum, h) => sum + h.amount, 0) + tx.amount;
    
    if (total24h >= threshold * 0.9 && last24h.length >= 3) {
      return { level: AlertLevel.HIGH, reason: 'structuring_detected' };
    }
    
    return { level: AlertLevel.NONE };
  }
}

Що входить в SAR автоматизацію?

При спрацьовуванні алертів — автоматичне формування чернетки SAR для compliance офіцера:

async function generateSARDraft(
  userId: string,
  transactions: Transaction[],
  alerts: Alert[]
): Promise<SARDocument> {
  const user = await getUserKYCData(userId);
  
  return {
    reportType: 'SUSPICIOUS_ACTIVITY',
    filingEntity: COMPANY_DETAILS,
    subject: {
      name: `${user.firstName} ${user.lastName}`,
      address: user.residenceAddress,
      dob: user.dateOfBirth,
      idNumber: user.documentNumber,
    },
    suspiciousActivity: {
      dateRange: { from: transactions[0].date, to: transactions[transactions.length - 1].date },
      totalAmount: transactions.reduce((sum, t) => sum + t.usdValue, 0),
      description: generateNarrative(alerts, transactions),
      alertTypes: alerts.map(a => a.type),
    },
    supportingTransactions: transactions.map(formatForSAR),
  };
}

Як ми будуємо збалансований KYC/AML?

Кастомне рішення на основі Sumsub та Chainalysis дає в 3 рази більше гнучкості, ніж коробкові продукти: ви самі визначаєте правила скринінгу, пороги ризику та рівні верифікації. Жодного vendor lock-in — при необхідності провайдера можна замінити без переписування архітектури.

Покроковий план впровадження

1. Аналіз вимог — визначаємо регуляторні зобов'язання (FATF, 5AMLD, локальні закони) та обираємо провайдерів.
2. Проектування архітектури — KYC state machine, AML screening pipeline, transaction monitoring engine.
3. Інтеграція KYC провайдера — Sumsub/Onfido, налаштування webhook'ів та state machine.
4. Впровадження AML скринінгу — підключення Chainalysis KYT, Elliptic, кешування результатів.
5. Розробка transaction monitoring — кастомні детектори structuring, velocity, mixing.
6. SAR модуль — автоматичне формування звітів, compliance dashboard.
7. Тестування та compliance review — перевірка на реальних кейсах, навантажувальне тестування.
8. Деплой та навчання команди — 2-денний workshop для compliance офіцерів.

Порівняння підходів: кастом vs коробка

Для бірж з обсягом понад 1000 користувачів кастомне рішення окупається за 6-12 місяців за рахунок економії на комісіях провайдера та запобіганні штрафам.

Технічний стек та терміни

Повна KYC/AML система для біржі: 3–4 місяці розробки.

В обсяг робіт входить: повна документація архітектури (UML діаграми, API специфікації), інтеграція з обраними провайдерами, кастомний transaction monitoring engine, compliance dashboard, модуль автоматичного SAR, вихідні коди, інструкції з деплою, навчання команди (2 дні воркшопу) та гарантія 6 місяців на баги.

Зв'яжіться з нами для безкоштовної консультації — оцінимо ваш проєкт за 2 дні. Замовте розробку KYC/AML системи під ключ і забезпечте відповідність регуляторним вимогам.

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

Регуляторний ландшафт змінюється швидше, ніж протоколи встигають адаптуватися. Якщо ваш проект працює в ЄС — 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, але напрямок, який ми закладаємо в архітектуру.

Архітектурний принцип: 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 змінює архітектуру 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-рішень. Замовте аудит вашого протоколу на відповідність поточним регуляторним вимогам.