מערכת ניטור עסקאות מותאמת אישית לציות ל-AML

אתם משיקים בורסת קריפטו על Base או Ethereum L2. הפיקדונות גדלים, אבל צוות הציות טובע בבדיקות ידניות. דפוס מבנה אחד שהוחמצ—והרגולטור מטיל קנס. כל עסקה היא סיכון פוטנציאלי: ללא ניטור אוטומטי אתם מפספסים עד 15% מהפעולות החשודות. מערכת ניטור עסקאות (TM) מנתחת כל פעולה בזמן אמת, ומסמנת חריגות לפי מהירות, מבנה ודפוסים אחרים. בנינו עשרות מערכות כאלה עבור בורסות ופרויקטי DeFi, תוך הבטחת ציות ל-FATF ולרגולטורים מקומיים.

אילו בעיות פותר ניטור עסקאות?

ניטור עסקאות אינו רשימה שחורה של כתובות. זהו ניתוח רציף: מהירות, מבנה, העברות מעגליות, חריגות גיאוגרפיות. דוגמה: לקוח מעביר 450 אלף דולר ב-24 שעות כאשר הנפח היומי הממוצע שלו הוא 2 אלף דולר—יחס של פי 225. מנוע הכללים מסמן מיד התראה ברמת MEDIUM; בדיקת ה-ML מאשרת את החריגה ב-98.7%—מופעל חיסום מלא.

דפוסים אופייניים שאנו מטפלים בהם:

• מבנה (Structuring): מספר עסקאות של 9,500 דולר במשך 3 ימים כדי לעקוף את סף הדיווח של 10,000 דולר.
• מהירות (Velocity): 15 עסקאות בשעה אחת מכתובות IP שונות—סימן לבוט.
• העברה מעגלית (Round-trip): הפקדת 50 אלף דולר, משיכה לאותן כתובות בניכוי עמלה לאחר 6 שעות.

כיצד אנו בונים את מערכת הניטור—מקרה לקוח

אחד הפרויקטים שלנו היה בורסה על Arbitrum עם 200 אלף משתמשים פעילים. בתחילה הם השתמשו ב-API של צד שלישי לבדיקות כתובות—12% מהעסקאות החשודות חמקו. פרסנו ארכיטקטורה היברידית:

מנוע הכללים מכיל 14 כללים דטרמיניסטיים (TM-001–TM-014). מודול ה-ML מאומן מחדש מדי שבוע על נתונים היסטוריים. תוצאות: אפס תוצאות שליליות שגויות במשך 8 חודשים, זמן זיהוי של 86 אלפיות שנייה.

דוגמה לכלל מבנה (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

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]

למה אנו משתמשים בכללים + ML

כללים קל יותר לפרשנות; ML תופס מה שלא כתוב במפורש. בפועל: כללים מכסים 80% מהתכניות הידועות, ML מוסיף עוד 15%, והשאר הם תוצאות חיוביות שגויות הדורשות בדיקה של מפעיל. מערכת מבוססת כללים בלבד מייצרת כ-2% תוצאות חיוביות שגויות; המערכת ההיברידית שלנו מגיעה ל-0.5% עם אותו רמת רגישות.

השוואה בין כללים ל-ML

ניהול התראות ו-SAR (דוח פעילות חשודה)

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. ביקורת על תהליכי הציות הנוכחיים וזרימות העסקאות.
2. עיצוב כללים ומודלי ML עבור תחום השיפוט שלכם.
3. יישום מנוע הכללים ואינטגרציה עם הבלוקצ'יין (RPC, mempool).
4. בדיקה על נתונים היסטוריים—אימות כיסוי של לפחות 90%.
5. פריסה והכשרת הצוות.

מה כלול

• מנוע כללים עם 14+ כללים מוגדרים מראש (מבנה, מהירות, העברה מעגלית, גיאוגרפיה).
• מודול ML מבוסס Isolation Forest עם אימון שבועי מחדש.
• מנהל התראות עם יצירה אוטומטית של SAR.
• לוח מחוונים לצוות הציות.
• API לאינטגרציה עם כל פלטפורמה.
• תיעוד בדיקות והכשרת צוות.

לוח זמנים משוער

מ-2 עד 3 חודשים—מביקורת ועד ייצור. אינטגרציה דחופה עם כללים בסיסיים—מ-3 שבועות. ציינו את המקרה שלכם—נעריך תוך יומיים.

פיתחנו מערכות AML עבור 5 בורסות ו-12 פרויקטי DeFi. הניסיון שלנו בEthereum וSolana באימות פורמלי של חוזים חכמים מאפשר לנו לשלב ניטור ברמת השרשרת. צרו קשר כדי לדון בפרויקט שלכם ולקבל הדגמה.

השוואת גישות: כללים מזהים דפוסים ידועים (מבנה, מהירות) ב-100% מהמקרים; ML מוצא 30% מההתקפות החדשות שאינן מכוסות על ידי הכללים. יחד—כיסוי של 95% מהתכניות החשודות עם 0.3% תוצאות חיוביות שגויות.