Ви запускаєте криптобіржу на 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 | Node.js + TypeScript | 50k tx/sec |
| ML detection | Python + scikit-learn (Isolation Forest) | 10k tx/sec |
| Streaming | Apache Kafka | 100k events/sec |
| Storage | PostgreSQL + TimescaleDB | 1 TB/day |
| Alerting | Custom + PagerDuty | < 100 ms latency |
| Dashboard | React + D3.js | — |
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: порівняння
| Критерій | Rule-based | ML (Isolation Forest) |
|---|---|---|
| Виявлення відомих схем | 100% | 95% |
| Виявлення нових атак | 0% | 30% |
| False positive rate | 2% | 0.5% |
| Час інтерпретації | Миттєво | <100ms |
| Потреба в даних | Мінімальна | Вимагає історію |
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(), }); } } Процес розробки
- Аудит поточних compliance-процесів та потоків транзакцій.
- Проектування правил та ML-моделей під вашу юрисдикцію.
- Реалізація rule engine та інтеграція з blockchain (RPC, mempool).
- Тестування на історичних даних — валідація покриття не менше 90%.
- Деплой та навчання команди.
Що входить в роботу
- 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.