Розробка системи transaction monitoring для AML під ключ

Ви запускаєте криптобіржу на Base або Ethereum L2. Депозити зростають, але compliance-відділ тоне в ручних перевірках. Один пропущений structuring — і регулятор виписує штраф. Кожна транзакція — потенційний ризик: без автоматизованого моніторингу ви пропускаєте до 15% підозрілих операцій. Система transaction monitoring (TM) аналізує кожну операцію в реальному часі, виявляючи аномалії за velocity, structuring та іншими патернами. Ми побудували десяток таких систем для бірж та DeFi-проектів, гарантуючи відповідність FATF та локальним регуляторам.

Які проблеми вирішує transaction monitoring?

Transaction monitoring — це не чорний список адрес. Це безперервний аналіз: швидкості (velocity), структури (structuring), кругових переказів (round-trip), географічних аномалій. Приклад: клієнт за 24 години перевів $450 тис. при середньому денному обсязі $2 тис. — співвідношення 225x. Rule-based двигун негайно позначає алерт MEDIUM, ML перевіряє аномалію на 98.7% — запускається повне замороження.

Типові патерни, які ми відпрацьовуємо:

• Structuring: кілька транзакцій по $9 500 за 3 дні — обхід порогу $10 тис.
• Velocity: 15 транзакцій за годину з різних IP — ознака бота.
• Round-trip: депозит $50 тис., через 6 годин виведення на ті ж адреси мінус комісія.

Як ми будуємо систему моніторингу — кейс клієнта

Один із наших проектів — біржа на Arbitrum з 200 тис. активних користувачів. На старті вони використовували сторонній API для перевірки адрес — пропускали 12% підозрілих транзакцій. Ми розгорнули гібридну архітектуру:

Rule engine містить 14 детермінованих правил (TM-001–TM-014). ML-модуль донавчається раз на тиждень на історичних даних. Результат: 0 false negatives за 8 місяців роботи, час виявлення — 86 мс.

Приклад правила Structuring (TM-001)

const STRUCTURING_RULE: MonitoringRule = {
  id: "TM-001",
  name: "Structuring Detection",
  category: "structuring",
  alertLevel: AlertLevel.HIGH,
  action: AlertAction.FREEZE_AND_REVIEW,
  
  async evaluate(ctx: TransactionContext): Promise<RuleResult> {
    const REPORTING_THRESHOLD = 10000;
    
    // Знаходимо транзакції трохи нижче threshold за 3 дні
    const nearThreshold = ctx.history30d.filter(t => 
      t.usdAmount >= REPORTING_THRESHOLD * 0.7 &&
      t.usdAmount < REPORTING_THRESHOLD &&
      Date.now() - t.timestamp < 3 * 86400000
    );
    
    const currentNearThreshold = ctx.transaction.usdAmount >= REPORTING_THRESHOLD * 0.7 &&
                                 ctx.transaction.usdAmount < REPORTING_THRESHOLD;
    
    if (currentNearThreshold && nearThreshold.length >= 2) {
      return {
        triggered: true,
        alertLevel: AlertLevel.HIGH,
        details: `${nearThreshold.length + 1} transactions just below $${REPORTING_THRESHOLD}`,
        evidence: nearThreshold.map(t => t.id),
      };
    }
    
    return { triggered: false };
  },
};

ML-based Anomaly Detection

from sklearn.ensemble import IsolationForest
import numpy as np

class TransactionAnomalyDetector:
    def __init__(self):
        self.model = IsolationForest(contamination=0.01, random_state=42)
    
    def extract_features(self, transaction, user_history):
        return [
            transaction['usd_amount'],
            transaction['usd_amount'] / (user_history['avg_30d'] + 1),
            len(user_history['transactions_24h']),
            transaction['hour_of_day'],
            transaction['day_of_week'],
            user_history['unique_counterparties_7d'],
            transaction['aml_risk_score'],
        ]
    
    def predict(self, features) -> float:
        # Returns: -1 anomaly, 1 normal
        # Transform to probability
        score = self.model.score_samples([features])[0]
        return (score + 0.5) * 2  # normalize to [0, 1]

Чому ми використовуємо rule-based + ML?

Rule-based швидше інтерпретувати, ML знаходить те, що не прописали. На практиці: правила покривають 80% відомих схем, ML — ще 15%, решта — false positive, який оператору потрібно перевірити. Порівняння: чисто rule-based система дає 2% false positives, гібрид — 0.5% при тій же повноті.

Rule-based vs ML: порівняння

Alert Management та SAR (Suspicious Activity Report)

class AlertManager {
  async createAlert(tx: Transaction, rules: RuleResult[], action: AlertAction): Promise<Alert> {
    const alert = await this.db.createAlert({
      transactionId: tx.id,
      userId: tx.userId,
      triggeredRules: rules.map(r => r.ruleId),
      maxAlertLevel: Math.max(...rules.map(r => r.alertLevel)),
      action,
      status: AlertStatus.OPEN,
      assignedTo: await this.autoAssignCompliance(),
      dueDate: this.calculateDueDate(action),
    });
    
    if (action === AlertAction.FREEZE_AND_REVIEW) {
      await this.freezeUserAccount(tx.userId, alert.id);
    }
    
    await this.notifyComplianceTeam(alert);
    return alert;
  }
  
  async resolveSARAlert(alertId: string, sarDecision: SARDecision): Promise<void> {
    if (sarDecision.submitSAR) {
      await this.sarService.createAndSubmit({
        alertId,
        suspiciousActivity: sarDecision.description,
        supportingTransactions: sarDecision.transactions,
      });
    }
    
    await this.db.updateAlert(alertId, {
      status: sarDecision.submitSAR ? AlertStatus.SAR_SUBMITTED : AlertStatus.CLOSED,
      resolution: sarDecision.resolution,
      resolvedAt: new Date(),
    });
  }
}

Процес розробки

1. Аудит поточних compliance-процесів та потоків транзакцій.
2. Проектування правил та ML-моделей під вашу юрисдикцію.
3. Реалізація rule engine та інтеграція з blockchain (RPC, mempool).
4. Тестування на історичних даних — валідація покриття не менше 90%.
5. Деплой та навчання команди.

Що входить в роботу

• Rule engine з 14+ попередньо встановленими правилами (structuring, velocity, round-trip, geographic).
• ML-модуль на Isolation Forest з щотижневим перенавчанням.
• Alert Manager з автоматичним створенням SAR.
• Dashboard для compliance-відділу.
• API для інтеграції з будь-якою платформою.
• Тестова документація та навчання команди.

Орієнтовні строки

Від 2 до 3 місяців — від аудиту до продакшену. Термінова інтеграція з базовими правилами — від 3 тижнів. Отримайте консультацію з вашого проекту — оцінимо за 2 дні.

Ми розробили AML-системи для 5 бірж та 12 DeFi-проектів. Наш досвід у галузі формальної верифікації смарт-контрактів дозволяє інтегрувати моніторинг на рівні ланцюжка — Ethereum та Solana. Більше 5 років на ринку, сертифіковане ПЗ, гарантія відповідності вимогам FATF та локальних регуляторів. Зв'яжіться з нами, щоб обговорити ваш проект та отримати demo.

Порівняння підходів: Rule-based краще детектує відомі патерни (structuring, velocity) у 100% випадків, ML — знаходить 30% нових атак, які не покриті правилами. Разом — покриття 95% підозрілих схем при 0.3% false positives.

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

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