Разработка AI-системы для детекции отмывания денег

Anti-Money Laundering (AML) — антиотмывочная система, область где цена ошибки критична. Пропуск подозрительного перевода (false negative) грозит штрафами до 5% оборота по ФЗ-115. Ложная блокировка добросовестного клиента (false positive) — репутационные потери и иски. Традиционные правиловые системы детектируют только известные паттерны, генерируя до 95% ложных срабатываний. Мы разрабатываем гибридные AI-системы, которые снижают FPR на 20–40% без потери полноты обнаружения. Наш опыт — 10+ лет в финансовом ML для банков и финтехов.

В основе — комбинация детерминированных правил (для типовых сценариев) и ML-моделей (для выявления скрытых нелинейных паттернов). Ниже — архитектура, модели и этапы внедрения.

В этой статье мы разберём ключевые компоненты системы: транзакционный мониторинг, графовый анализ и интеграцию с KYC. Рассмотрим, как гибридный подход снижает нагрузку на комплаенс-отдел и соответствует требованиям FATF. Правила автоматически обрабатывают 80% операций, оставляя 20% на ML-проверку, что снижает ручной труд на 60%.

Почему ML лучше правиловых систем для AML?

Типология схем отмывания

Структурирование (Smurfing): крупная сумма разбивается на мелкие транзакции ниже порога контроля ($5.4k–7.8k. в РФ).

Layering: многоуровневые переводы через цепочку счетов и юрисдикций для сокрытия источника. Integration: отмытые средства вводятся в легальный бизнес — аффилированные услуги, недвижимость.

Red flags:

• Транзакции ровными суммами ($?.) — ниже порога, но подозрительно.
• Всплеск активности: нет операций → внезапно 50 за день.
• Географические несоответствия: клиент из Саратова, переводы в Сингапур.
• Счёт-однодневка: новый счёт, большой оборот, быстрый вывод, закрытие.

Feature Engineering

Ключ к качеству ML — признаки, отражающие поведение клиента. Мы используем два класса: Транзакционные признаки (объём, время, суммы около порогов, концентрация контрагентов):

def extract_transaction_features(transaction_history, lookback_days=90): """Признаки на основе истории транзакций клиента.""" df = transaction_history.copy() features = { # Объём транзакций 'total_amount_30d': df[df['days_ago'] <= 30]['amount'].sum(), 'transaction_count_30d': len(df[df['days_ago'] <= 30]), 'avg_transaction_amount': df['amount'].mean(), 'amount_std': df['amount'].std(), # Временные паттерны 'transactions_per_active_day': len(df) / df['date'].nunique(), 'max_transactions_single_day': df.groupby('date').size().max(), 'night_transaction_ratio': (df['hour'] < 6).mean(), 'weekend_activity_change': calculate_weekend_ratio(df), # Суммы около порогов 'near_threshold_pct': (df['amount'].between(550000, 610000)).mean(), 'round_amount_pct': (df['amount'] % 1000 == 0).mean(), # Контрагенты 'unique_counterparties': df['counterparty_id'].nunique(), 'counterparty_concentration': df.groupby('counterparty_id')['amount'].sum().max() / df['amount'].sum(), 'new_counterparty_ratio': (df['is_new_counterparty'] == True).mean(), # Географические 'foreign_transaction_ratio': (df['country'] != 'RU').mean(), 'high_risk_jurisdiction_pct': df['country'].isin(HIGH_RISK_COUNTRIES).mean() } return features def compute_network_features(account_id, transaction_graph): """Транзакции как граф: узлы = счета, рёбра = переводы.""" G = transaction_graph pagerank = nx.pagerank(G, weight='amount') betweenness = nx.betweenness_centrality(G, weight='amount') communities = nx.community.greedy_modularity_communities(G.to_undirected()) community_risk = assess_community_risk(account_id, communities, G) return { 'pagerank_score': pagerank.get(account_id, 0), 'betweenness_score': betweenness.get(account_id, 0), 'community_risk': community_risk, 'in_degree': G.in_degree(account_id), 'out_degree': G.out_degree(account_id) } 

Сетевые признаки (PageRank, betweenness, кластеризация) — помогают обнаруживать сложные layering-схемы, где счёт выступает транзитным узлом.

Модели машинного обучения

LightGBM с настройкой под AML

import lightgbm as lgb from sklearn.metrics import roc_auc_score, average_precision_score n_normal = (y_train == 0).sum() n_sar = (y_train == 1).sum() scale_pos_weight = n_normal / n_sar model = lgb.LGBMClassifier( n_estimators=500, scale_pos_weight=scale_pos_weight, learning_rate=0.05, num_leaves=31, min_child_samples=20, feature_fraction=0.8 ) # Threshold подбирается так, чтобы recall >= 0.85 from sklearn.metrics import precision_recall_curve precision, recall, thresholds = precision_recall_curve(y_val, y_scores) optimal_threshold = thresholds[np.argmax(recall >= 0.85)] 

Графовая нейронная сеть (GNN) для сетевого анализа

import torch from torch_geometric.nn import SAGEConv class AMLGraphNN(torch.nn.Module): """GNN для анализа транзакционных сетей.""" def __init__(self, node_features, edge_features, hidden_dim=64): super().__init__() self.conv1 = SAGEConv(node_features, hidden_dim) self.conv2 = SAGEConv(hidden_dim, hidden_dim) self.edge_mlp = torch.nn.Linear(edge_features, hidden_dim) self.classifier = torch.nn.Linear(hidden_dim * 2, 1) def forward(self, node_features, edge_index, edge_features): x = torch.relu(self.conv1(node_features, edge_index)) x = torch.relu(self.conv2(x, edge_index)) edge_emb = self.edge_mlp(edge_features) source_emb = x[edge_index[0]] target_emb = x[edge_index[1]] edge_repr = torch.cat([source_emb, target_emb], dim=1) return torch.sigmoid(self.classifier(edge_repr)) 

Как устроена гибридная архитектура AML?

Гибридная система объединяет правила и ML в единый пайплайн. Правила быстро отсеивают очевидные легитимные операции и сигнализируют о явных нарушениях (превышение лимитов, запрещённые юрисдикции). ML-модели анализируют признаки, которые невозможно закодировать правилами: аномальное поведение, скрытые связи, нелинейные зависимости. Результат: каждый перевод получает единый риск-скор, который учитывает и правила, и ML.

class HybridAMLSystem: def __init__(self, rule_engine, ml_model, threshold=0.5): self.rules = rule_engine self.model = ml_model self.threshold = threshold def evaluate_transaction(self, transaction, customer_history): rule_alerts = self.rules.evaluate(transaction) features = extract_transaction_features(customer_history) ml_score = self.model.predict_proba([features])[0][1] final_risk = max(rule_alerts.max_risk_score if rule_alerts else 0, ml_score) if final_risk > self.threshold: return SARCandidate( transaction=transaction, risk_score=final_risk, triggered_rules=rule_alerts, ml_explanation=shap_explain(self.model, features) ) 

Что входит в работу

• Документация: архитектурная схема, model card, руководство администратора.
• ML-пайплайн: извлечение признаков, обучение, валидация, A/B-тестирование.
• Интеграция: с KYC-системой, core banking, CRM.
• Real-time API: HTTP/gRPC эндпоинт для оценки риска каждой транзакции.
• Дашборды: мониторинг метрик, отчётность SAR, SHAP-объяснения.
• Развёртывание: в контуре заказчика (on-prem) или в облаке.
• Поддержка: 1 месяц пост-продакшн, обучение команды.

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

1. Аналитика — сбор требований, аудит текущих логов, нормативных актов (ФЗ-115, FATF).
2. Проектирование — выбор архитектуры, определение признаков, конфигурация пилота.
3. Разработка — написание кода, обучение моделей, настройка пайплайна.
4. Тестирование — кросс-валидация на исторических данных, сценарное тестирование.
5. Деплой — развёртывание, интеграция, нагрузочное тестирование.

Сроки: от 6–8 недель на базовую версию (правила + LightGBM + SAR) до 4–5 месяцев на полную (с GNN, real-time, графическим анализом).

Сравнение моделей: LightGBM vs GNN

Регуляторное соответствие

ФЗ-115 (Россия): обязательный контроль операций >$5.4k–7.8k., передача SAR в Росфинмониторинг в течение 3 рабочих дней.

FATF/EU AMLD: KYC на онбординге, continuous monitoring, усиленная проверка (EDD) для high-risk клиентов. Регуляторные требования описаны в Рекомендациях FATF.

Как мы обеспечиваем объяснимость?

Каждое подозрительное решение сопровождается SHAP-объяснением. Рассмотрим пример: перевод $8.6k–12k. из Саратова в Сингапур. SHAP-значения показывают, что foreign_transaction_ratio повысил риск на 0.34, near_threshold_pct — на 0.28, new_counterparty_ratio — на 0.21, transaction_count_30d — на 0.15, avg_transaction_amount — на 0.10. Итоговый риск 0.87 превышает порог 0.5, что генерирует SAR-отчёт.

import shap def explain_sar_decision(model, features, feature_names): """Регулятор требует обоснования каждого SAR.""" explainer = shap.TreeExplainer(model) shap_values = explainer.shap_values(features) top_factors = sorted( zip(feature_names, shap_values[0]), key=lambda x: abs(x[1]), reverse=True )[:5] explanation = "\n".join([ f"- {name}: {'повысил' if val > 0 else 'снизил'} риск на {abs(val):.2f}" for name, val in top_factors ]) return explanation 

Такой подход позволяет не только пройти аудит, но и дать операторам понятные причины блокировок.

Готовы оценить ваш проект? Закажите разработку AML-системы под ваши данные — получите консультацию по архитектуре и срокам. Свяжитесь с нами для обсуждения.