Graph construction is the systematic transformation of raw relational data—such as transaction logs, account ownership records, and device interactions—into a structured graph representation. This process defines the nodes (entities like accounts or merchants), edges (relationships like transfers or logins), and associated attributes (features like transaction amount or timestamp) that form the input for graph neural networks.
Glossary
Graph Construction

What is Graph Construction?
Graph construction is the feature engineering process of transforming raw relational data into a structured graph format with defined nodes, edges, and attributes suitable for ingestion by graph neural networks.
The quality of graph construction directly determines downstream model performance in fraud detection. Critical design decisions include whether to build a homogeneous or heterogeneous graph, how to handle temporal dynamics through dynamic graph snapshots, and which edge weighting schemes best capture transactional significance. Poorly constructed graphs introduce structural noise that obscures the relational patterns GNNs are designed to detect.
Key Characteristics of Effective Graph Construction
The feature engineering process of transforming raw relational data into a structured graph format with defined nodes, edges, and attributes suitable for GNN ingestion.
Entity Resolution & Deduplication
The critical preprocessing step of mapping raw identifiers to canonical node entities. This involves resolving multiple representations of the same real-world actor (e.g., a user with multiple email addresses or device IDs) into a single, unique node. Without rigorous deduplication, the graph becomes sparse and fragmented, diluting the neighborhood aggregation signal. Techniques include fuzzy string matching, probabilistic record linkage, and deterministic rule-based matching on personally identifiable information (PII) hashes.
Schema Design: Heterogeneous Nodes & Edges
Defining a rich ontology of node types (e.g., AccountHolder, Merchant, Device, IP_Address) and edge types (e.g., TRANSFERS_TO, LOGS_IN_FROM, OWNS). A heterogeneous schema preserves the semantic meaning of different relationships, enabling Relational Graph Convolutional Networks (R-GCNs) to apply distinct learnable weight matrices per edge type. This prevents the model from conflating a TRANSFERS_TO relationship with a SHARES_DEVICE_WITH relationship.
Temporal Edge Weighting
Assigning time-decayed weights to edges based on transaction recency. A transaction from yesterday should exert more influence on a node's current state than one from five years ago. This is implemented by applying an exponential decay function to edge features or by creating time-weighted adjacency matrices. This technique is essential for constructing dynamic graphs where the relevance of historical behavior diminishes, preventing stale data from masking emerging fraud patterns.
Feature Engineering for Nodes & Edges
Populating nodes and edges with dense, numerical attribute vectors. Node features include account age, average transaction velocity, and risk scores. Edge features capture transaction amount, currency type, authorization response code, and time delta since the last interaction. These features serve as the initial input signals for the GNN's message-passing layers. Categorical features must be properly encoded (e.g., one-hot or learned embeddings) to avoid imposing false ordinal relationships.
Graph Sampling & Batching
The strategy for extracting manageable subgraphs from a massive, billion-edge transaction network for mini-batch training. Techniques like GraphSAINT and Cluster-GCN partition the full graph into smaller, densely connected clusters that preserve local structure. This overcomes the memory bottleneck of loading the entire adjacency matrix onto a GPU. Effective sampling ensures that each training batch is a statistically representative microcosm of the global fraud patterns.
Train/Test Split Integrity
The methodology for partitioning a graph dataset without introducing data leakage. Unlike random row-wise splitting in tabular data, graph splitting must account for message-passing dependencies. A naive split allows a test node's features to influence a training node's embedding through shared edges. The correct approach uses temporal splitting (training on past edges, testing on future edges) or inductive node splitting that masks test nodes and their incident edges entirely during training.
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.
Frequently Asked Questions
Answers to the most common technical questions about transforming raw relational data into structured graph formats optimized for graph neural network ingestion in financial fraud detection.
Graph construction is the feature engineering process of transforming raw relational data—such as transaction logs, account ownership records, device fingerprints, and IP session data—into a structured graph format with defined nodes, edges, and attributes suitable for ingestion by graph neural networks (GNNs). In financial fraud detection, this involves mapping heterogeneous entities like account holders, merchants, devices, and bank branches as nodes, while representing monetary transfers, shared credentials, and co-location events as edges. The constructed graph captures both explicit relationships (direct fund transfers) and implicit relationships (shared phone numbers or device IDs), enabling downstream models to learn structural patterns indicative of fraud rings, money laundering layering, and synthetic identity clusters. The quality of graph construction directly determines the signal available to GNN architectures, making it a critical preprocessing step that bridges raw data engineering with advanced graph learning.
Related Terms
Master the foundational data engineering concepts required to transform raw relational data into a structured graph format suitable for graph neural network ingestion.
Node Definition & Schema Design
The process of defining entity types and their feature vectors that will serve as vertices in the graph. In financial networks, nodes typically represent account holders, merchants, devices, or IP addresses. A robust schema must define the primary key for each node type and the static or dynamic attributes (e.g., account age, average transaction velocity) that form the initial feature matrix X.
Edge Engineering & Relationship Extraction
The logic for transforming raw event logs into directed or undirected connections. This involves defining edge types (e.g., TRANSFERRED_TO, LOGGED_IN_FROM) and computing edge weights based on aggregation functions:
- Monetary aggregation: Sum of transaction amounts over a time window.
- Frequency aggregation: Count of interactions between two entities.
- Temporal decay: Weighting recent interactions higher than older ones to capture concept drift.
Heterogeneous Graph Construction
Building a graph with multiple node and edge types to preserve semantic richness. Unlike homogeneous graphs, a financial heterogeneous graph distinguishes between Account and Merchant nodes, and between Transaction and Ownership edges. This requires defining a metagraph schema that specifies valid source and target node types for each relation, enabling Relational GCNs to apply distinct transformation matrices per edge type.
Temporal Graph Windowing
The strategy for partitioning a continuous stream of transactions into discrete snapshots or time-windowed subgraphs. Techniques include:
- Sliding windows: Overlapping intervals that capture smooth behavioral transitions.
- Tumbling windows: Non-overlapping fixed intervals for batch training.
- Session-based windows: Dynamic intervals based on user activity bursts. This temporal discretization is critical for feeding dynamic graphs into Temporal Graph Networks (TGNs).
Feature Engineering for Graph Attributes
The computation of node-level and edge-level features that serve as input signals for GNN layers. Node features may include degree centrality, PageRank scores, or transaction velocity. Edge features often encode transaction amount, currency type, or time elapsed since last interaction. Proper feature scaling and normalization prevent numerical instability during message passing.
Graph Sampling & Batching
Techniques for constructing mini-batches from massive transaction graphs that exceed GPU memory. Methods include neighbor sampling (GraphSAGE-style) which randomly selects a fixed number of neighbors per node, and cluster-GCN which partitions the graph into dense subgraphs. This step is essential for scaling GNN training to production-scale financial networks with billions of edges.

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