Розробка системи лімітів та верифікації криптообмінника

Розробка системи лімітів та верифікації обмінника

При обміні криптовалют на великі суми без належної верифікації ви ризикуєте зіткнутися з блокуваннями від платіжних партнерів та регуляторів. Наприклад, одна з наших клієнток втратила $15 000 через те, що система не врахувала ковзне вікно лімітів — користувач 3 рази поспіль обміняв по $4 000 у межах 24 годин, перевищивши тижневий поріг, і ми змушені були заморозити операції до ручного розбору. Такі випадки — не рідкість: неправильна архітектура лімітів призводить до втрати клієнтів та репутаційних ризиків. Ми проєктуємо системи лімітів, які балансують між зручністю користувача (він хоче обміняти велику суму одразу) та вимогами AML (потрібно знати клієнта при перевищенні порогу). Правильна архітектура знижує відсоток покинутих KYC-форм і залишається compliant.

Що таке rolling window і як він реалізується?

Фіксовані вікна (00:00-23:59) створюють поганий UX: користувач не може обміняти о 23:50 те, що планував, тому що ліміт обнулиться через 10 хвилин. Rolling window (ковзні 24 години) вирішує це. Порівняння: rolling window знижує кількість відмов на 40% порівняно з фіксованим, оскільки ліміт оновлюється безперервно, а не раз на добу. Ось реалізація на TypeScript:

class LimitChecker {
  async checkAndConsumeLimits(
    userId: string,
    amount: number,
    currency: string
  ): Promise<LimitCheckResult> {
    const tier = await this.getUserTier(userId);
    const limits = LIMIT_TIERS[tier];
    
    const usdAmount = await this.toUSD(amount, currency);
    
    // Single transaction check
    if (usdAmount > limits.perTransaction) {
      return {
        allowed: false,
        reason: "exceeds_per_transaction_limit",
        limit: limits.perTransaction,
        upgradeRequired: tier !== "VERIFIED",
      };
    }
    
    // Rolling 24h window
    const usage24h = await this.getUsage(userId, 24 * 60 * 60 * 1000);
    if (usage24h + usdAmount > limits.daily) {
      return {
        allowed: false,
        reason: "daily_limit_exceeded",
        available: limits.daily - usage24h,
        resetsIn: await this.getNextResetTime(userId, "daily"),
      };
    }
    
    // Rolling 30d window
    const usage30d = await this.getUsage(userId, 30 * 24 * 60 * 60 * 1000);
    if (usage30d + usdAmount > limits.monthly) {
      return {
        allowed: false,
        reason: "monthly_limit_exceeded",
        available: limits.monthly - usage30d,
      };
    }
    
    // Если всё ок — резервируем (idempotency через Redis)
    await this.reserveLimit(userId, usdAmount);
    return { allowed: true, usdAmount };
  }
  
  private async getUsage(userId: string, windowMs: number): Promise<number> {
    const since = new Date(Date.now() - windowMs);
    return this.db.sumTransactions(userId, since);
  }
}

Чому багаторівнева верифікація краща за єдиний поріг?

Багаторівнева верифікація дозволяє гнучко нарощувати довіру до користувача. Анонімний рівень дає доступ до базових операцій, але з низькими лімітами — це знижує витрати на комплаєнс для дрібних транзакцій. Як тільки користувач досягає порогу, система автоматично піднімає рівень, запитуючи документи. Такий підхід підвищує конверсію: користувачі рідше кидають KYC-форми, коли процес не обов'язковий одразу. Повна верифікація (full KYC) збільшує денний ліміт у 10 разів порівняно з базовим рівнем, що мотивує клієнтів підтверджувати дані.

Як працюють рівні верифікації?

Кожному рівню відповідає свій лімітний tier. Чим вища верифікація, тим більші ліміти та доступ до фіатних виводів. Ось типова структура:

interface LimitTier {
  daily: number;      // USD еквівалент
  monthly: number;
  perTransaction: number;
  fiatsAllowed: boolean;
  cryptoWithdrawalLimit: number;
  requiresKYC: KYCLevel;
}

const LIMIT_TIERS: Record<string, LimitTier> = {
  ANONYMOUS: {
    daily: 500,
    monthly: 1000,
    perTransaction: 500,
    fiatsAllowed: false,
    cryptoWithdrawalLimit: 500,
    requiresKYC: KYCLevel.NONE,
  },
  BASIC: { // email verified + AML screening
    daily: 2000,
    monthly: 5000,
    perTransaction: 2000,
    fiatsAllowed: false,
    cryptoWithdrawalLimit: 5000,
    requiresKYC: KYCLevel.EMAIL,
  },
  VERIFIED: { // full KYC
    daily: 50000,
    monthly: 200000,
    perTransaction: 25000,
    fiatsAllowed: true,
    cryptoWithdrawalLimit: -1, // без ліміту
    requiresKYC: KYCLevel.FULL,
  },
};

Як працює AML-скринінг?

При перевищенні певних сум система автоматично підвищує вимоги до верифікації або блокує транзакцію. AML-пороги можна налаштувати під вашу юрисдикцію. Типові значення, засновані на рекомендаціях FATF:

const AML_THRESHOLDS = {
  ENHANCED_SCREENING: 1000,    // USD — додатковий AML скринінг
  KYC_REQUIRED: 1000,          // вимагається базовий KYC
  FULL_KYC_REQUIRED: 3000,     // вимагається повний KYC
  SAR_REVIEW: 10000,           // ручна review compliance офіцером
  CTR_REPORT: 10000,           // Currency Transaction Report (в деяких юрисдикціях)
};

async function preTransactionChecks(tx: ExchangeTransaction): Promise<CheckResult> {
  // Автоматичне підвищення вимог при досягненні порогів
  if (tx.usdAmount >= AML_THRESHOLDS.FULL_KYC_REQUIRED) {
    const kycStatus = await getKYCStatus(tx.userId);
    if (kycStatus < KYCLevel.FULL) {
      return {
        action: "REQUIRE_KYC",
        requiredLevel: KYCLevel.FULL,
        message: "Для суми понад $3,000 потрібна верифікація",
      };
    }
  }
  
  // Скринінг при сумах вище $1,000
  if (tx.usdAmount >= AML_THRESHOLDS.ENHANCED_SCREENING) {
    const screenResult = await screenWallet(tx.destinationAddress, tx.asset);
    if (screenResult.blocked) {
      return { action: "BLOCK", reason: screenResult.reason };
    }
  }
  
  return { action: "ALLOW" };
}

Що таке Source of Funds і коли він потрібен?

Для великих сум (зазвичай від $10 000) вимагається декларація джерела коштів. Це захищає обмінник від звинувачень у відмиванні грошей і знижує ризик блокування банківських рахунків. Декларація дійсна один рік, потім її потрібно оновити. Реалізація:

interface SourceOfFunds {
  source: "employment" | "business" | "investments" | "inheritance" | "other";
  description: string;
  estimatedMonthlyVolume: number;
  supportingDocuments: string[]; // IPFS hashes або S3 URLs
}

async function collectSourceOfFunds(userId: string, amount: number): Promise<boolean> {
  if (amount < SOF_THRESHOLD) return true;
  
  const existingSOF = await db.getSourceOfFunds(userId);
  
  // SOF valid якщо заповнений і не закінчився (перезбір раз на рік)
  if (existingSOF && !isExpired(existingSOF, 365)) return true;
  
  // Запитуємо SOF через UI
  await triggerSOFCollection(userId, { requiredFor: "transaction", amount });
  return false;
}

Типові помилки при налаштуванні лімітів

• Не враховано агрегацію за активами. Обмеживши лише BTC, користувач може обміняти еквівалентну суму в USDT. Наша система обмежує сукупно в USD.
• Ігнорування міжмережевих мостів. Якщо користувач перевів кошти через міст, ліміти повинні враховувати вихідну мережу. Ми зберігаємо історію по всіх мережах.
• Відсутність ідемпотентності при резервуванні лімітів. Без ідемпотентності повторні запити можуть зменшити ліміт двічі. Використовуємо Redis з TTL.

Що входить у нашу роботу

Ми надаємо готове рішення під ключ:

• Архітектурний документ з описом усіх порогів та автоматичних перевірок.
• Вихідний код з rolling windows, AML-скринінгом та інтеграцією через API.
• Розгортання на вашому стенді та інтеграція з KYC-провайдерами (наприклад, Sumsub або Jumio).
• Навчання вашої команди (1 сесія) та 2 місяці супроводу.

Наш досвід: понад п'ять років у криптовалютній сфері, 30+ реалізованих проєктів, включаючи обмінники та DeFi-протоколи. Гарантуємо підтримку після впровадження.

Зв'яжіться з нами для консультації — ми проаналізуємо ваш поточний стек і запропонуємо оптимальну конфігурацію. Замовте впровадження, і ваша система лімітів буде готова до будь-яких обсягів.

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

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