Graph embeddings turn each account into a vector that encodes its position in the transaction network: who it pays and how its neighbors behave. For AML and fraud, that lets a model score network shapes no analyst wrote a rule for. The catch is that a raw vector explains nothing by itself, so the design problem is keeping the lift without losing the audit trail.
Most teams already build graph features by hand. Count of distinct counterparties in 30 days, fan-in and fan-out ratios, degree of a shared device, whether an account sits two hops from a known mule. These work, and you should keep them. But they only capture the patterns someone thought to enumerate. A layering scheme that routes funds through a rotating set of intermediaries, each individually unremarkable, will pass every hand-built threshold while being obvious as a structure. Representation learning is how you get at the structure without naming it in advance.
What the embedding actually learns
An embedding is a function from a node and its neighborhood to a fixed-length vector, trained so that nodes in similar positions land near each other. Two families are worth knowing.
- Shallow embeddings (node2vec and its relatives) learn one vector per node from random walks over the graph. They are cheap to train and capture community structure well, which makes them a reasonable first model. The limitation is that they are transductive: a node that was not in the training graph has no vector, so a brand-new account gets nothing until you retrain.
- Graph neural networks (a GNN such as GraphSAGE) learn a function that aggregates a node’s features and its neighbors’ features. Because they operate on features rather than identities, they generalize to nodes that did not exist at training time, which matters when the accounts you most want to score are the ones opened last week.
For a live AML setting the inductive property usually decides it. Mule networks and fraud rings churn. If your embedding cannot score a node that appeared after the last training run, you have built something that only works on history.
The training signal matters as much as the architecture. Self-supervised objectives (predict a masked edge, contrast a real neighborhood against a corrupted one) give you embeddings without needing labels, which suits the reality that confirmed money-laundering labels are sparse and lagged. Where you do have labels from filed SARs or confirmed fraud, a supervised or semi-supervised objective sharpens the space toward the risk you care about. We usually run both: a self-supervised base that captures general structure, fine-tuned on whatever confirmed cases exist.
Building the graph without leaking the future
This is where most AML graph projects quietly break, and the failure does not show up until production disappoints. The training metrics look excellent because the graph you embedded already contains the outcome you are predicting.
Point-in-time correctness on a graph is harder than on a flat feature table, because edges carry time and influence propagates. Three rules we hold to.
- Every edge has an as-of timestamp, and the graph you score at time T contains only edges observed at or before T. An account’s risky neighbor might only have become risky after your decision point. Including that edge is lookahead, and it is the single most common way graph AML models overstate their lift.
- Node features are filtered the same way. A counterparty’s total transaction volume, its SAR history, its degree, all of it must reflect what was known at T. This means the entity resolution that merges accounts into a single customer also has to be reconstructed as-of, because a merge decision made last month did not exist at the decision point you are backtesting.
- Labels come from the outcome window, features come from before it. Keep a hard wall between the period you build the graph from and the period you read the label from, with a gap that reflects real detection lag.
The practical consequence is that you cannot embed one snapshot of the current graph and backtest against history. You rebuild the graph as of each evaluation point, or you accept that your eval set is contaminated. Rebuilding is expensive, and it is the expense that separates a model that holds up in production from one that looked good in a notebook.
Keeping explainability an examiner will accept
A vector is not a reason. Under SR 11-7 your model is subject to validation, and an investigator filing a SAR needs a narrative grounded in facts. Neither is satisfied by an embedding coordinate. So the embedding drives the score, and a second layer produces the explanation.
- Score with the embedding, explain with the subgraph. When an account scores high, pull the k-hop neighborhood that most influenced the score and render it: shared counterparties, the timing of flows, the paths connecting it to prior confirmed cases. The investigator then reasons over edges they can click through rather than over a coordinate.
- Attribute the score to structure. GNN attribution methods can identify which edges and neighbor features moved the prediction. That gives you sentences like “elevated because of repeated same-day transfers to three counterparties that themselves route to a flagged account,” which is defensible in a way “distance in latent space” is not.
- Keep the embedding as a feature, not the decision. Feed the embedding score into the same model and the same alerting pipeline as your hand-built features. Now standard model documentation, feature importance, and champion-challenger testing apply. The embedding is inside a system you already know how to validate, rather than a black box bolted onto the side.
- Watch for drift on the vectors themselves. The distribution of embeddings moves as the graph evolves and as fraud adapts. Monitor it, because a shift in the embedding space is often the earliest signal that a typology has changed and your false-positive budget is about to blow.
Track the whole system against a stable eval set with point-in-time graphs, and hold the embedding score to the same false-positive budget as everything else in the alerting stack. Done this way, representation learning buys you detection of structures nobody enumerated, and the examiner still gets an alert built from edges, timestamps, and counterparties they can follow.
FAQ
Do graph embeddings replace our rules and typologies?
No. They add a learned view of network structure that hand-written rules cannot express, but the rules still run and still fire. We treat the embedding score as one more feature feeding the same alerting and case-management stack, not as a replacement for typology coverage you have to defend to an examiner.
How do you explain an alert driven by a node embedding to an investigator?
The embedding produces the score; the explanation comes from the subgraph behind it. We surface the specific paths, shared counterparties, and timing that pushed the account into a risky region of the space, so the narrative an investigator writes is grounded in edges they can click through, not in the vector itself.
Will an embedding model leak future information into training?
It will if you build the graph naively. Every edge and every node feature has to be filtered to what was knowable at the decision time you are scoring, which usually means rebuilding the graph as of each historical point rather than embedding one snapshot of today.