Custom Transaction Monitoring System for AML Compliance

You launch a crypto exchange on Base or Ethereum L2. Deposits grow, but the compliance team drowns in manual checks. One missed structuring pattern—and the regulator issues a fine. Every transaction is a potential risk: without automated monitoring you miss up to 15% of suspicious operations. A transaction monitoring (TM) system analyzes each operation in real time, flagging anomalies by velocity, structuring, and other patterns. We have built dozens of such systems for exchanges and DeFi projects, guaranteeing compliance with FATF and local regulators.

What problems does transaction monitoring solve?

Transaction monitoring is not a blacklist of addresses. It is continuous analysis: velocity, structuring, round-trip transfers, geographic anomalies. Example: a client transfers $450k in 24 hours when their average daily volume is $2k—a 225x ratio. The rule-based engine immediately flags a MEDIUM alert; the ML check confirms the anomaly at 98.7%—a full freeze is triggered.

Typical patterns we handle:

• Structuring: several transactions of $9,500 over 3 days to circumvent the $10k reporting threshold.
• Velocity: 15 transactions in one hour from different IPs—sign of a bot.
• Round-trip: deposit $50k, withdraw to the same addresses minus fee after 6 hours.

How we build the monitoring system—a client case

One of our projects was an exchange on Arbitrum with 200k active users. Initially they used a third-party API for address checks—12% of suspicious transactions slipped through. We deployed a hybrid architecture:

The rule engine contains 14 deterministic rules (TM-001–TM-014). The ML module is retrained weekly on historical data. Results: zero false negatives over 8 months, detection time 86 ms.

Example Structuring Rule (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; // Find transactions just below threshold in the last 3 days 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] 

Why we use rule-based + ML

Rule-based is faster to interpret; ML catches what isn't explicitly written. In practice: rules cover 80% of known schemes, ML adds another 15%, the rest are false positives that require an operator to review. A pure rule-based system yields about 2% false positives; our hybrid gets 0.5% with the same recall.

Rule-based vs ML comparison

Alert Management and 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(), }); } } 

Development process

1. Audit current compliance processes and transaction flows.
2. Design rules and ML models for your jurisdiction.
3. Implement rule engine and integrate with blockchain (RPC, mempool).
4. Test on historical data—validate coverage of at least 90%.
5. Deploy and train the team.

What’s included

• Rule engine with 14+ preconfigured rules (structuring, velocity, round-trip, geographic).
• ML module based on Isolation Forest with weekly retraining.
• Alert Manager with automatic SAR creation.
• Dashboard for the compliance team.
• API for integration with any platform.
• Test documentation and team training.

Estimated timeline

From 2 to 3 months—from audit to production. Urgent integration with basic rules—from 3 weeks. Pinpoint your case—we’ll evaluate within 2 days.

We have developed AML systems for 5 exchanges and 12 DeFi projects. Our experience in Ethereum and Solana smart contract formal verification allows us to integrate monitoring at the chain level. Contact us to discuss your project and get a demo.

Comparison of approaches: Rule-based detects known patterns (structuring, velocity) in 100% of cases; ML finds 30% of new attacks not covered by rules. Together—95% coverage of suspicious schemes with 0.3% false positives.