Разработка системы 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 архитектуры, потом переделывают её под давлением — это дороже, болезненнее и грозит даунтаймами. Услуги блокчейн комплаенса включают полный цикл: от 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-тикетов обеспечен.

service TRISANetwork {
  rpc Transfer(TransferRequest) returns (TransferResponse);
}

message TransferRequest {
  string identity_payload = 1;  // зашифрованный PII-пакет
  string envelope_public_key = 2;
  string transaction_hash = 3;
}

Как выбрать 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

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.

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