GNN Development for Fraud Detection in Transaction Graph

GNN for fraud detection: where rules fail

A threshold rule evaluates a transaction in isolation from context: amount above limit, sharp deviation from the usual account profile, match with a list of suspicious payment details. While fraud looked like one large operation, this was enough.

When a scheme is split into dozens of small transfers between linked accounts, each transfer individually looks normal — and the rule misses the entire network.

Connections between accounts are reconstructed from indirect signals: shared device or login address, matching withdrawal details, coordinated timing of operations, chains of transfers through intermediary transit accounts.

Individually, no single signal triggers an alert, but together they form a dense area — a subgraph where the concentration of connections is noticeably higher than the background. Fraud detection here comes down to finding such areas, rather than individual rows in a log.

GNN approaches the task directly: nodes are accounts, devices, and recipients; edges are transactions with their attributes.

The model propagates the signal along edges and aggregates the node's neighborhood across several layers, so the decision relies on the structure of connections rather than on a single operation.

Formally, this is node and edge classification on a transaction graph, and it is robust to amount splitting and changing payment details.

The practical value lies in separation of roles: threshold rules remain a fast filter for obvious cases and work without delay, while the model covers what they structurally cannot see — groups of linked accounts, fan-out withdrawals, gradual "warming up" of an account before withdrawal. Below we break down how this is arranged at the level of data, labeling, and training.

What a graph model adds to transaction risk scoring

In risk scoring, a graph model relies not on an individual transaction but on its environment: who paid the recipient earlier, through which accounts the money has already passed, how quickly the amounts spread along the chain.

A scheme almost always has a repeating pattern of connections — it is not visible in a single record but manifests on a subgraph two or three steps away from it.

GNN is trained on such subgraphs and produces a score separately for a node and for an edge.

On the labeled transaction graph Elliptic, it is visible where the gain is greatest: the share of detected schemes grows among amount splitting, transit accounts, and fan-out payments — that is, where threshold rules stop working while the structure of connections remains recognizable.

False positives go down: the model looks at context, not at exceeding an amount, so bulk and payroll payments stop looking suspicious.

Reaction time is reduced to recalculating the score on the updated subgraph — the decision is made at the authorization stage, not at the end of the reporting period.

For the team, this changes not only metrics but also queue triage: for each alert, it is visible which neighbors contributed to the risk score, and priority is set by structure rather than by amount. Such a score is easier to explain both during incident review and in reporting to auditors.

GNN, rules, and classical models: comparison of approaches

On a transaction graph, the choice comes down to four schemes: rules, tabular models on aggregates, GNN, and a hybrid.

They differ not in accuracy but in applicability conditions — the volume of labeled history, requirements for scoring latency, and how much the regulator needs an explanation for each alert.

In practice, a hybrid more often wins. Structural graph metrics — node degree, number of common neighbors, chain lifetime, proximity to confirmed cases — are calculated in advance in a graph store, such as Neo4j, and enter the tabular model as ordinary features.

GNN is connected where the summary loses information: it evaluates the subgraph around an operation as a whole, rather than its aggregate.

Rules provide instant triggering and a formulation for review, the tabular model covers mass typical cases, GNN — those where the decision depends on the environment.

If the graph part errs on a rare scheme, its contribution is disabled, and scoring continues on the first two pipelines — without stopping the process.

Stages of implementing a GNN model in a fraud detection system

Implementation of a graph model is sensitive to the order of work: starting with architecture rather than labeling yields a biased sample and metrics that do not reproduce on a live stream.

Therefore, we go from data audit to handover of the pipeline, fixing a verifiable result at each stage.

1. Data audit. We check completeness of transaction fields, depth of history, share of confirmed fraud, and lag between event and label. Features known only after incident review do not enter the model.

2. Graph design. We decide what becomes a node — account, customer, device, payment detail — and which connections between them we build. We define aggregation time windows and edge features: shared devices, transfer speed, change of payment details.

3. Building the preparation pipeline. The stream rebuilds the graph at each time slice using the same logic as during training: the discrepancy between training and production samples is closed here, not during debugging.

4. Model training and validation. We split data by time, not randomly. We compare GNN with current rules on the same slices: we look at coverage at a given false positive rate and stability by week.

5. Shadow mode. The model calculates scores in parallel with the production system; decisions are not applied. It is visible how many alerts will be added to manual review and how the scores are distributed.

6. Handover to production. Monitoring of feature drift, retraining procedure, feedback from analysts, and rollback to the previous version with a single switch.

Implementation artifacts: graph schema, access policies, documentation

After handover, you should be left not with a single trained classifier but with a kit that the team uses to develop the solution without a contractor.

A graph neural network (GNN) is trained on historical connections, and without a description of the schema, it is impossible to reproduce it on new data. If an item from the list is missing, the first failure or team change turns into a long downtime.

• Graph schema: node types (accounts, counterparties, devices, operations), edge types and direction, aggregation time windows, rules for connection appearance and deletion
• Feature contract: node and edge features with calculation formulas, windows, and missing value handling — a new feature can be added without rebuilding the entire schema
• Access policies: role matrix at the level of entities and features, separation of read and write, audit of access to the scoring pipeline, isolation of sensitive fields
• Model documentation: architecture, hyperparameters, checkpoint version, metrics on holdout sample, limitations card — where the model errs predictably
• Test suite: graph schema checks, regression set on historical labels, robustness check against distribution shift, comparison of metrics before rollout
• Retraining procedure: triggers (growth in share of new connections, recall degradation, feature drift), frequency, responsible persons, rollback order to previous version
• Operations manual: launch checklist, diagnostics of typical failures, procedure for connecting a new data source and updating the graph

Case study: how a graph model reduced false positives

The anti-fraud pipeline ran on threshold rules: account limits, transaction frequency, device matching. Such a set cut off the obvious but did not see a scheme of dozens of small transfers between linked accounts.

The false positive rate stayed around 68%, and the manual review queue grew faster than analysts could process it. Changing the rules required a downtime window — during that time, transactions went through without risk scoring.

What was changed

We built a transaction graph: nodes are accounts, devices, recipient payment details; edges are transfers and co-occurrences with timestamps.

The graph neural network (GNN) evaluates the environment of an operation as a whole and sees the chain, splitting, and fan, indistinguishable by individual features. Rules were left as the first filter, the neural network as the deciding voice in disputed cases.

PCI DSS requirements for data labeling were taken into account at the design stage: only anonymized features are stored in the graph.

What became

Separately, they covered schemes that the rules did not find: circular transfers within a group of accounts, splitting an amount below the threshold, fan-out payments from one device. Model updates proceed without stopping intake, and rollback to the previous version takes minutes.

What to do if the fraud detection system is already rule-based?

Rules are fixed expertise, and they cover some scenarios no worse than a model: the decision is explainable, triggers instantly, and does not require graph recalculation. There is no need to break this pipeline entirely.

The working path is to place the graph model next to the rules and gradually transfer to it those cases where the rules are no longer enough.

We start with shadow mode: the model reads the same event stream as the rules, builds a graph of connections between accounts, devices, and recipients, and assigns a risk score — but does not influence anything.

Testing on the stream over several weeks shows which schemes the rules miss: splitting amounts between linked accounts, transit chains, a spike of operations at a node with dormant connections. The output is not a report but a list of discrepancies used to tune features.

Next is a gradual transition. First, the model gets the right to raise the priority of an operation in the manual review queue, then to block only those cases where the rules are silent and the risk score is high and stable.

We increase the share of traffic in portions, and at each one we compare accuracy and false positive rate with the previous slice, not with an absolute ideal.

Rollback is built in from the very beginning: the decision branch is switched by a configuration flag, and traffic returns entirely to the rules — without rebuilding, retraining, or stopping the service.

Separately, we fix what the analyst sees: for each model alert, an explanation remains — which connections in the graph raised its suspicion.

Labeling, drift, and explainability: common technical doubts

In anti-fraud, labeling is asymmetric: confirmed cases are few, and the label arrives with a delay — the outcome of review becomes known weeks after the operation.

A graph neural network (GNN) relies both on operation features and on the node's environment, so everything comes down to labeling and how connections are replenished. Below are answers to doubts that come up before the start.

How to track model drift?

We look from two sides: on the input — new types of connections and changes in feature frequency; on the output — a drop in the share of confirmations at the top of the list. Retraining is triggered and always with rollback to previous weights.

Can the model's decision be explained?

For a node, we show which neighbors and operations raised the score: the review receives not just a score but a rationale with specific connections for manual checking. The same attribution reveals what the model gets wrong.

What about incomplete connections and implementation without downtime?

We build the graph from the available window and do not complete edges with synthetic data — the model receives features of environment sparsity.

The first iterations run in shadow mode next to the rules; we put it into production based on accumulated statistics, with thresholds and rollback.

Let's discuss the task: what data is needed for assessment

For the assessment to rely on graph structure rather than general words, a minimum of input data is needed.

Below is what is enough to describe on a call or send as an export; from this set it is already clear which metrics are achievable and where the data will constrain the solution.

• Graph schema: what acts as a node — account, card, device, counterparty — which connections between them are built and in what time window.
• Volume and stream: how many events per day, what depth of history is available, what peak spikes look like. This determines whether we train the model on the full export or on a sample.
• Confirmed cases: whether fraud labels exist, how they appear — payment return upon claim, manual review, support service request — and with what delay they become known.
• Features: what is available on nodes and connections — amounts, operation frequency, geography, connection age, device fingerprint, time between events.
• Access and environment: where the data is stored, whether training and model application can be deployed nearby, whether there is a sandbox with an anonymized sample.
• Current process: which rules operate now, what share of decisions is sent to analysts manually, and what errors are already visible at this stage.
• Constraints: requirements for verdict explainability, personal data policy, acceptable response latency for a transaction.

Once we receive this, we assemble the sample composition, check it for separability, and return with an assessment and work plan: stages, acceptance metrics, and the procedure for implementing GNN into the current review flow without stopping existing rules.