AI-Augmented Anti-Money Laundering: Graph Networks, Synthetic Identity, and Adversarial Robustness

The Problem

Rules-based AML systems operate on thresholds: transactions over $10,000 get reported, accounts with more than a fixed number of transactions in 24 hours get flagged, jurisdictions on a blocklist trigger a review queue. The result is well-documented: roughly 99% of Suspicious Activity Report (SAR) alerts generated by traditional systems are false positives. Compliance teams spend the majority of their investigative hours clearing alerts on legitimate customers — a retired teacher making a large home repair payment, a small business with a high daily cash volume — while genuinely suspicious activity moves through the gaps.

The gaps are structural. Rules-based systems evaluate transactions in isolation. Money laundering in practice is a network phenomenon. A professional laundering operation will deliberately architect around any single-transaction threshold: the structuring offence exists precisely because regulators recognised that breaking deposits into sub-reporting amounts is the simplest evasion technique. But threshold-based detection that catches structuring — looking for many sub-$10k deposits in a time window from one account — is still single-account-centric. Sophisticated layering operations work across dozens or hundreds of accounts, often across multiple institutions and jurisdictions, with funds moving through a web of shell companies before reaching their integration destination.

The three stages of money laundering each present different detection challenges. In the placement stage, illicit cash enters the financial system, typically through cash deposits, prepaid cards, or cash-intensive businesses used as fronts. Placement is the stage most amenable to existing rules-based detection — large cash deposits and structuring patterns are relatively observable. The layering stage obscures the audit trail through a series of transactions designed to separate funds from their source: wire transfers between corporate accounts, currency conversions, cross-border movements, asset purchases and re-sales. Individual transactions in a layering scheme are often unremarkable; the pattern is only visible at the network level. The integration stage reintroduces funds into the legitimate economy — real estate purchases, luxury goods, investment accounts — and by this stage the paper trail has been deliberately obscured enough that transaction-level signals are nearly undetectable.

Regulatory pressure has increased substantially. FinCEN’s 2023 AML effectiveness rule explicitly requires financial institutions to adopt risk-based, technology-assisted approaches. The Financial Action Task Force (FATF) guidance on opportunities and challenges of new technologies for AML/CFT cites graph analytics and machine learning as expected capabilities for systemically important institutions. The EU’s Sixth Anti-Money Laundering Directive (6AMLD) extends criminal liability for money laundering offences and increases the compliance burden for institutions that fail to detect patterns that machine learning methods would plausibly have caught. The regulatory direction is clear: rules-based systems alone are no longer sufficient for large institutions.

Threat Model

Structuring (Smurfing)

The canonical evasion technique. A single deposit of $90,000 would trigger a Currency Transaction Report. Breaking the same amount into nine deposits of $9,900 at different branches, ATMs, or through different accounts owned by different individuals (smurfs) avoids the per-transaction threshold. The pattern is visible across accounts and time but not within any single account. Detection requires aggregating activity across related accounts — a relationship that rules-based systems struggle to define without already knowing which accounts are related.

Shell Company Layering Networks

Funds move through a chain of corporate entities: LLC A wires to Ltd B in a low-transparency jurisdiction, which pays an invoice to Corp C, which distributes dividends to individual accounts. Each individual corporate relationship may look like a normal B2B payment. The graph structure — cycles, fan-out patterns, jurisdictional hops — is the suspicious signal. A compliance officer reviewing a single wire sees a normal intercompany transaction. A graph model trained on known laundering typologies sees a sub-network matching a layering pattern.

Synthetic Identity Fraud

Fabricated identities constructed from real data fragments — a valid SSN assigned to one person combined with a different name, date of birth, and address — are used to open accounts that feed into layering schemes. Synthetic identities are particularly dangerous because they pass individual identity verification checks: the SSN is real, the credit bureau may have limited records, the application passes basic KYC. These identities accumulate thin credit files over months before being used for fraud, a practice called “piggybacking.” The AML risk is that synthetic identities are ideal vehicles for layering: they have no suspicious transaction history, they are not personally connected to any known bad actor, and they can be abandoned without affecting a real person’s life.

AML Architecture with Graph Neural Networks

Modelling the Financial Transaction Network

The foundational representation is a heterogeneous directed graph. Nodes represent accounts, corporate entities, and individuals. Edges represent transactions — directed from sender to receiver, with edge attributes capturing amount, timestamp, currency, jurisdiction pair, and transaction type (wire, ACH, card, cash). The graph is not static: new edges are continuously added as transactions settle. Efficient AML systems maintain an incremental graph representation, typically using a graph database such as Neo4j or Amazon Neptune, updated in near-real-time from the transaction event stream.

Key design decisions at the graph construction stage affect what patterns are detectable. Including both individual accounts and corporate entities as nodes allows detection of shell company structures. Linking accounts to shared identity attributes (same phone number, same device fingerprint, overlapping address) as edges enables synthetic identity ring detection. Including non-financial relationships — shared beneficial ownership, signatories in common — gives the model additional structural signals that are invisible in transaction data alone.

GNN Architecture for AML

GraphSAGE and Graph Attention Networks (GAT) are both well-suited to AML. GraphSAGE aggregates features from sampled neighbourhoods, making it tractable for the large, sparse transaction graphs typical in financial services. GAT learns attention weights over neighbours, which provides a natural mechanism for explainability: the model learns to weight certain transaction relationships more heavily, and those weights can be surfaced to analysts.

The forward pass aggregates suspicious signals from the transaction neighbourhood of each account. An account that has no individually suspicious transactions may still receive a high risk score if its immediate neighbours have elevated risk scores and the edge attributes connecting them match layering typologies. This is the core value of GNN-based AML: risk propagates across the graph.

Feature Engineering

Node features for account nodes include:

• Account age in days at transaction time
• Rolling 7-day and 30-day transaction velocity (count and volume)
• Jurisdictional diversity index: number of distinct jurisdictions appearing in transaction counterparties over the trailing 90 days
• Round-number bias: fraction of transactions with amounts that are exact multiples of $100, $1,000, or $10,000 (a known indicator of structuring preparation)
• Incoming-to-outgoing ratio: accounts used purely as pass-throughs show a ratio near 1.0 with low net accumulation
• Average time-to-transfer: how quickly incoming funds are forwarded onward, measured in hours

Edge features for transaction edges include amount, currency, originating and receiving jurisdiction codes, and transaction type. Including the time delta since account opening is important: newly opened accounts receiving large inflows immediately are a placement signal.

Training Data and Class Imbalance

Labelled SAR cases serve as positive examples. The class imbalance is severe — confirmed money laundering cases represent a tiny fraction of all transactions — and naive training on imbalanced data produces models that default to predicting everything as legitimate. Mitigation strategies include Synthetic Minority Over-sampling Technique (SMOTE) adapted for graph data, class weights that penalise false negatives more heavily than false positives, and focal loss functions that down-weight easy negative examples. Temporal splits are mandatory for evaluation: training on past SAR cases and evaluating on future cases prevents data leakage from future-known labels into model training.

PyTorch Geometric Implementation Sketch

import torch
import torch.nn.functional as F
from torch_geometric.nn import GATConv
from torch_geometric.data import Data, DataLoader

class AMLGraphAttentionNet(torch.nn.Module):
    def __init__(self, node_features: int, edge_features: int, hidden_dim: int = 64, heads: int = 4):
        super().__init__()
        # First GAT layer: multi-head attention over transaction neighbours
        self.conv1 = GATConv(
            in_channels=node_features,
            out_channels=hidden_dim,
            heads=heads,
            edge_dim=edge_features,
            dropout=0.3,
        )
        # Second GAT layer: reduces to single-head output for classification
        self.conv2 = GATConv(
            in_channels=hidden_dim * heads,
            out_channels=hidden_dim,
            heads=1,
            edge_dim=edge_features,
            dropout=0.3,
        )
        self.classifier = torch.nn.Linear(hidden_dim, 2)  # benign / suspicious

    def forward(self, x, edge_index, edge_attr, return_attention=False):
        # x: [num_nodes, node_features]
        # edge_index: [2, num_edges]
        # edge_attr: [num_edges, edge_features]
        x, (edge_idx_1, attn_1) = self.conv1(
            x, edge_index, edge_attr=edge_attr, return_attention_weights=True
        )
        x = F.elu(x)
        x, (edge_idx_2, attn_2) = self.conv2(
            x, edge_index, edge_attr=edge_attr, return_attention_weights=True
        )
        logits = self.classifier(x)
        if return_attention:
            return logits, attn_2  # return attention weights for explainability
        return logits


def build_transaction_graph(accounts_df, transactions_df) -> Data:
    """
    Build a PyG Data object from account and transaction dataframes.
    accounts_df: columns [account_id, age_days, tx_velocity_7d, tx_velocity_30d,
                           jurisdiction_diversity, round_number_bias, in_out_ratio,
                           avg_time_to_transfer_hrs]
    transactions_df: columns [src_account_idx, dst_account_idx, amount_usd,
                               currency_code, src_jurisdiction, dst_jurisdiction,
                               tx_type_encoded, delta_since_opening_hrs]
    """
    node_features = torch.tensor(
        accounts_df[[
            'age_days', 'tx_velocity_7d', 'tx_velocity_30d',
            'jurisdiction_diversity', 'round_number_bias',
            'in_out_ratio', 'avg_time_to_transfer_hrs'
        ]].values,
        dtype=torch.float,
    )
    edge_index = torch.tensor(
        transactions_df[['src_account_idx', 'dst_account_idx']].values.T,
        dtype=torch.long,
    )
    edge_attr = torch.tensor(
        transactions_df[[
            'amount_usd', 'currency_code', 'src_jurisdiction',
            'dst_jurisdiction', 'tx_type_encoded', 'delta_since_opening_hrs'
        ]].values,
        dtype=torch.float,
    )
    return Data(x=node_features, edge_index=edge_index, edge_attr=edge_attr)


# Training loop with class-weighted loss for imbalanced SAR data
def train_aml_model(model, loader, epochs=50, pos_weight=50.0):
    optimizer = torch.optim.Adam(model.parameters(), lr=1e-3, weight_decay=1e-4)
    # pos_weight=50 reflects ~2% base rate of positive (SAR) examples
    criterion = torch.nn.CrossEntropyLoss(
        weight=torch.tensor([1.0, pos_weight])
    )
    model.train()
    for epoch in range(epochs):
        total_loss = 0.0
        for batch in loader:
            optimizer.zero_grad()
            logits = model(batch.x, batch.edge_index, batch.edge_attr)
            loss = criterion(logits[batch.train_mask], batch.y[batch.train_mask])
            loss.backward()
            optimizer.step()
            total_loss += loss.item()
        if epoch % 10 == 0:
            print(f"Epoch {epoch}: loss={total_loss/len(loader):.4f}")

The return_attention=True path is critical for downstream explainability. The attention weights output by the second GAT layer tell you which of an account’s transaction neighbours most influenced its risk score — directly interpretable as “this account is suspicious because of its connections to these specific counterparties.”

Synthetic Identity Detection

Identity Risk Feature Vector

Synthetic identities are constructed to pass point-in-time verification checks. The detection signal lies in the inconsistencies between data fields and in the temporal relationships between identity events.

High-signal individual features:

• SSN issuance date vs. date of birth: SSNs issued after the reported date of birth (particularly for applicants claiming to be adults) indicate a synthetic or fraudulently obtained SSN.
• Credit file age relative to account opening: a thin file that appeared recently — particularly one with only a small number of accounts opened in a tight cluster — is a synthetic identity signal.
• Email and phone registration date: email addresses and phone numbers registered within days of the account application date suggest a fabricated identity.
• Device fingerprint age: browser and device fingerprint databases can reveal whether the device has appeared in prior applications under different identities.
• Address normalisation anomalies: synthetic identities often use addresses that pass postal validation but are non-residential (commercial mail-receiving agencies, parcel forwarding services).

These features feed into an identity risk score using gradient-boosted trees (XGBoost or LightGBM), which perform well on tabular identity data without requiring the graph modelling infrastructure.

Graph Analysis for Identity Rings

Individual synthetic identity detection misses coordinated rings. A fraud ring may create fifty synthetic identities, each of which passes individual risk scoring, but which share overlapping identity fragments — the same IP address during application, the same phone number used across applications in different names, the same device fingerprint, or address components that match across a cluster. Graph clustering over shared identity attributes exposes these rings. A connected component analysis over a bipartite graph (identity applications as one node set, identity attributes as the other) surfaces clusters of applications that share attributes — clusters that are far larger than would be expected by chance.

import networkx as nx
from itertools import combinations

def build_identity_graph(applications_df):
    """
    Build bipartite graph connecting applications to shared identity attributes.
    applications_df: columns [app_id, phone_hash, email_hash, device_fp, addr_hash, ip_subnet]
    Returns connected components with more than one application node.
    """
    G = nx.Graph()
    attribute_cols = ['phone_hash', 'email_hash', 'device_fp', 'addr_hash', 'ip_subnet']

    for _, row in applications_df.iterrows():
        app_node = f"app_{row['app_id']}"
        G.add_node(app_node, node_type='application')
        for col in attribute_cols:
            if row[col] is not None:
                attr_node = f"{col}_{row[col]}"
                G.add_node(attr_node, node_type='attribute')
                G.add_edge(app_node, attr_node)

    # Extract application clusters: connected components containing 2+ application nodes
    rings = []
    for component in nx.connected_components(G):
        app_nodes = [n for n in component if n.startswith('app_')]
        if len(app_nodes) >= 3:  # threshold: ring requires 3+ linked applications
            rings.append({
                'app_ids': [n.replace('app_', '') for n in app_nodes],
                'shared_attributes': [n for n in component if not n.startswith('app_')],
                'ring_size': len(app_nodes),
            })
    return sorted(rings, key=lambda r: r['ring_size'], reverse=True)

Rings of three or more applications sharing two or more identity attributes are referred directly to a fraud investigation team. The combination of ring size and the number of shared attributes drives case prioritisation.

Adversarial Robustness of AML Models

How Laundering Operations Probe Scoring Models

A financially sophisticated adversary who suspects an institution uses ML-based AML scoring will probe the model the same way a penetration tester probes a web application: systematically, with controlled variation. The technique is to execute a series of transactions that vary a single parameter — amount, timing, counterparty jurisdiction, transaction type — while monitoring for friction signals that indicate elevated risk scoring. Friction signals include: requests for source of funds documentation, delays in settlement, enhanced due diligence requests, or account holds. By mapping which parameter values correlate with friction, the adversary learns the model’s decision boundary and structures future transactions to stay outside it.

This probing is particularly effective against transparent, single-model AML systems where the same model processes all transaction types with a stable decision boundary over time. It is less effective against ensemble systems with randomised components and against systems that actively detect probing behaviour.

Graph Injection Attacks

A more sophisticated adversarial technique targets GNN-based systems specifically. A graph injection attack adds legitimate-looking nodes and edges to the transaction graph to dilute suspicious signals. The attacker creates a set of clean accounts with genuinely normal transaction histories — small purchases, salary deposits, routine utility payments — and then connects the target accounts to these clean accounts through plausible business transactions (consulting invoices, small purchases). The GNN’s neighbourhood aggregation then mixes the clean account features into the target account’s representation, reducing the propagated risk score.

Research from 2023 demonstrated that Graph Attention Networks are particularly vulnerable to this attack because the attention mechanism can be induced to up-weight clean neighbours, further suppressing the contribution of suspicious neighbours to the aggregated representation. Defences need to account for the structural possibility of legitimate-looking connections to high-risk nodes.

Defensive Controls

Model opacity: The most direct defence against threshold probing is not exposing the score or any friction signal that can be precisely attributed to a score crossing a threshold. Risk-based friction — document requests, settlement delays — should be introduced with some randomisation in timing and threshold values so the adversary cannot reliably map responses to specific score bands. Never expose a numerical risk score in customer-facing communications or API responses.

Probing detection: Systematic low-value transactions across a set of accounts, varying amounts or counterparties in a structured pattern, are detectable behaviours. A monitoring layer that flags accounts executing transactions with low variance in amount and high variance in counterparty — particularly when counterparties span multiple jurisdictions — adds a second detection layer independent of the primary risk model.

Ensemble models: Maintaining multiple independent risk models — a GNN, a time-series anomaly detector, and a rules-based layer — means that probing one model’s decision boundary does not automatically allow evasion of the ensemble. Ensemble agreement (all models agree the account is low-risk) is a stronger signal than any single model’s output.

Adversarial training for graph injection: Training the GNN with synthetically generated graph injection examples hardens the model against neighbourhood dilution. During training, randomly add clean-profile neighbours to some positive (SAR) examples and verify the model maintains elevated scores for the central suspicious node despite the injected clean context.

Input perturbation robustness: Certifiable robustness techniques adapted from image classification — specifically, smoothing-based approaches that add controlled noise to input features and verify the model’s classification is stable — can establish confidence intervals on risk scores for accounts near the decision boundary.

Explainability for SAR Filing

Regulatory guidance under FinCEN and 6AMLD requires that SAR narratives contain a factual description of the suspicious activity. A black-box risk score of 0.94 is not a SAR narrative. AML systems must translate model outputs into investigator-readable explanations.

SHAP for transaction-level attribution: SHapley Additive exPlanations compute the marginal contribution of each feature to the model’s output. For a flagged account, SHAP values decompose the risk score into contributions from round-number bias, jurisdictional diversity, transaction velocity, and other features. A SAR narrative can then cite: “Account X exhibited a transaction velocity 4.2 standard deviations above peer group average, combined with 87% of outgoing transactions to jurisdictions classified as high-risk by FATF, and a round-number bias of 0.73 (peer group mean: 0.11).”

import shap
import numpy as np

def explain_account_risk(model, account_features, feature_names):
    """
    Generate SHAP-based explanation for a flagged account.
    Returns a dict of feature -> contribution for SAR narrative generation.
    """
    explainer = shap.TreeExplainer(model)  # for XGBoost/LightGBM components
    shap_values = explainer.shap_values(account_features)
    # shap_values[1] = contributions to the positive (suspicious) class
    contributions = dict(zip(feature_names, shap_values[1].flatten()))
    # Sort by absolute contribution, return top drivers
    sorted_contributions = sorted(
        contributions.items(), key=lambda x: abs(x[1]), reverse=True
    )
    return {
        'top_risk_drivers': sorted_contributions[:5],
        'base_value': explainer.expected_value[1],
        'model_output': float(np.sum(shap_values[1]) + explainer.expected_value[1]),
    }

Graph attention weights for sub-network identification: The attention weights from the GAT’s second layer identify which of the flagged account’s transaction neighbours contributed most to its risk score. Surfacing the top three to five highest-attention counterparty accounts — their account IDs, the transaction amounts, and the jurisdictions — gives investigators the starting point for a network investigation and provides concrete factual content for the SAR narrative’s description of related parties.

Feedback Loop Security

Analyst case decisions feed back into the model: confirmed SARs strengthen positive labels, cleared cases provide negative feedback. This feedback loop is essential for model improvement and for adapting to evolving laundering typologies. It is also an attack surface.

A sophisticated adversary who has an account under AML review can attempt to manipulate feedback by ensuring the investigation results in a “false positive” determination — for example, by providing convincing source-of-funds documentation for the probing transactions while keeping the genuine laundering activity off the flagged account. If this feedback reaches the training data as a clean label, future model versions may score similar patterns lower.

Controls for feedback loop integrity:

• Analyst feedback auditing: flag accounts where analyst “clear” decisions are followed within 30 days by new suspicious activity from the same account or from accounts with strong network connections to it.
• Minimum time horizon for negative labels: do not add “confirmed clean” labels to training data until an account has been clean for a minimum of 90 days post-investigation, reducing the window for adversarial label injection.
• Analyst anomaly detection: monitor for analysts whose clear rates significantly exceed peer averages — an indicator of either compromised accounts or social engineering of compliance staff.
• Segregation of feedback channels: feedback used for model retraining should require dual-analyst review for accounts that scored above a high-risk threshold before being cleared, preventing single-analyst decisions from poisoning training labels.

Expected Behaviour

Trade-offs

GNN computational cost vs rules-based speed: A rules-based system evaluates a transaction in microseconds. A GNN that aggregates a two-hop neighbourhood of a moderately connected account in a large financial graph may take hundreds of milliseconds per inference in a naive implementation. At high transaction volumes this is not operationally viable for real-time blocking. The standard mitigation is a two-stage architecture: rules-based and lightweight ML for real-time go/no-go decisions on individual transactions, with GNN scoring running asynchronously on the accumulated daily graph to produce daily risk score updates per account. Real-time blocking uses the asynchronous GNN score as a pre-computed feature rather than running the GNN inline.

Explainability vs model accuracy: Graph attention networks are substantially more interpretable than pure black-box deep GNNs, but they sacrifice some accuracy compared to more expressive architectures. For AML specifically, the regulatory requirement for explainable decisions makes this trade-off mandatory for institutions subject to FinCEN and 6AMLD — a highly accurate model that cannot produce a compliant SAR narrative is operationally useless regardless of its AUC on held-out SAR data.

False positive burden on compliance teams: Increasing model sensitivity to catch more genuine laundering patterns increases the false positive rate. Each false positive is an investigator-hours cost and a customer friction cost. Calibrating the model’s operating point requires explicit input from compliance leadership on the relative cost of a missed SAR versus a false positive investigation — a decision that is business and regulatory policy, not a machine learning hyperparameter.

Failure Modes

Model drift: Money laundering typologies evolve. A model trained on SAR data from 2022 to 2024 will underperform against novel typologies that emerged in 2025. Scheduled retraining on recent SAR data, combined with performance monitoring via a held-out evaluation set of labelled cases from the most recent quarter, is the minimum operational standard. Statistical drift detection on input feature distributions (population stability index per feature) provides an early warning when the incoming transaction population has shifted away from the training distribution.

Adversarial probing success: If a sophisticated operation successfully maps the model’s decision boundary through systematic probing, they may maintain sub-threshold activity for months while completing a large layering scheme. The probing detector described above is a partial mitigation, but it is not a complete defence. Periodic model refresh — changing the model architecture or training data in ways that shift the decision boundary — forces adversaries to repeat the probing process, increasing the cost and time required to map the new boundary.

Regulatory scrutiny of black-box decisions: Even with SHAP and attention weight explainability, regulators conducting a model review examination may challenge the adequacy of the model’s documentation, the representativeness of its training data, or the completeness of its coverage of FATF-identified typologies. Maintaining a model risk management framework — documentation of training data provenance, model validation results, backtesting on historical SAR cases, and a typology coverage matrix — is the operational discipline that transforms an ML AML system from a compliance liability into a defensible regulatory asset.

Feedback loop compromise: An adversary who successfully games the analyst feedback mechanism — generating confirmed “false positive” labels for genuinely suspicious activity — can degrade the model’s performance on their specific pattern over successive retraining cycles. The feedback integrity controls described above are not foolproof; an adversary with sufficient patience and access to compliance documentation could potentially design a layering scheme that consistently produces documentation adequate to achieve a “clear” determination from investigators. This threat argues for maintaining a rules-based minimum floor that cannot be learned away, and for periodic red team exercises in which internal fraud specialists attempt to generate false negative labels through the feedback mechanism.