A transaction graph is a directed, weighted graph where nodes represent financial entities—such as accounts, merchants, or devices—and edges represent monetary transfers between them. Edge weights typically encode transaction amounts, frequencies, or timestamps, while node attributes capture entity metadata like account age or risk scores. This structure transforms raw transaction logs into a relational topology that explicitly models the flow of funds.
Glossary
Transaction Graph

What is a Transaction Graph?
A transaction graph is a directed, weighted graph where nodes represent financial entities and edges represent monetary transfers, serving as the primary data structure for applying graph neural networks to anti-money laundering and fraud detection.
Unlike tabular data, a transaction graph preserves multi-hop relationships essential for detecting complex schemes like layering or fraud rings. Graph neural networks operate directly on this structure, learning node embeddings that encode both transactional behavior and network position. The graph serves as the canonical input for tasks including link prediction, anomaly detection, and community identification within financial ecosystems.
Key Characteristics of Transaction Graphs
Transaction graphs are not mere visualizations; they are formal mathematical objects. Their specific structural properties directly determine the performance of downstream graph neural networks and the types of fraud topologies that can be detected.
Directed and Weighted Edges
In a financial transaction graph, edges are inherently directed to represent the irreversible flow of value from a sender to a receiver. Each edge carries a weight encoding the transaction amount, and often a temporal feature like a Unix timestamp. This is critical for anti-money laundering, where the directionality of layering—splitting funds across multiple downstream accounts—is the primary signal. GNNs like Graph Attention Networks (GATs) can learn to attend asymmetrically to incoming versus outgoing payment flows, distinguishing legitimate payroll distributions from smurfing patterns.
Heterogeneous Node and Edge Typology
Realistic financial graphs are heterogeneous, containing multiple node types (e.g., AccountHolder, Merchant, Device, IP_Address) and edge types (e.g., TRANSFERS_TO, LOGS_IN_FROM, OWNS). This semantic richness allows a Relational Graph Convolutional Network (R-GCN) to apply distinct transformation matrices per relationship type. For example, a TRANSFERS_TO edge between two accounts is processed differently than a REGISTERED_WITH edge linking an account to a device fingerprint, preserving the unique semantics of each connection.
Dynamic Temporal Evolution
Unlike static social networks, transaction graphs are dynamic and continuously evolving. New nodes (accounts) and edges (transactions) arrive as a streaming time-series. A Temporal Graph Network (TGN) models this by maintaining a compressed memory state for each node that updates after every interaction. This allows the model to capture concept drift in behavior—such as a dormant account suddenly becoming a high-velocity mule—by recognizing that the timing of edges is as suspicious as their topology.
Multi-Hop Relational Context
The power of graph-based fraud detection lies in analyzing k-hop neighborhoods. A single transaction might look legitimate, but a 2-hop or 3-hop view reveals structural anomalies. For instance, a fraud ring often forms a near-clique or a dense bipartite subgraph between synthetic sellers and buyers. Message passing mechanisms in GNNs aggregate features across these hops, allowing a node to indirectly learn about the risk profile of its neighbor's neighbors, effectively detecting collusion without explicit rules.
Spectral and Spatial Feature Encoding
Transaction graphs encode information in two domains. Spatial features include local statistics like degree centrality, clustering coefficient, and PageRank, which identify hubs and isolated clusters. Spectral features, derived from the Graph Laplacian matrix, capture the global smoothness of the graph signal. Anomalies often manifest as high-frequency noise in the spectral domain. Graph Convolutional Networks (GCNs) operate on this Laplacian eigenspectrum to filter out normal, low-frequency transactional hum and amplify the high-frequency signal of fraud.
Bipartite Core Structures
Many payment networks naturally form bipartite graphs with two disjoint sets: originators (payers) and beneficiaries (payees). Fraudulent schemes like transaction laundering often create abnormally dense bipartite cores where a small set of illicit merchants is connected to a large set of synthetic payers. Algorithms like SUSPICION or custom bipartite GNNs analyze the adjacency matrix of this subgraph to detect density anomalies that would be invisible in a unimodal projection of the network.
Frequently Asked Questions
Clear, technical answers to the most common questions about the data structure powering graph-based fraud detection.
A transaction graph is a directed, weighted graph data structure where nodes represent financial entities (accounts, merchants, wallets) and edges represent monetary transfers between them. Each edge carries attributes like transaction amount, timestamp, currency, and channel. The graph works by transforming raw transaction logs into a relational topology, enabling graph neural networks to analyze multi-hop connections—for example, tracing funds from a source account through three intermediary mule accounts to a final beneficiary. Unlike tabular data, the graph explicitly encodes the structural context of each transaction, allowing models to detect anomalies based not just on individual transaction features but on the entity's role and neighborhood within the entire financial network.
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Related Terms
Explore the foundational concepts and advanced architectures that build upon the transaction graph to power graph neural network-based fraud detection.

About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us