Category: Fraud Detection Analytics

Graph Analysis

Also known as: Graph Analytics, Network Analysis, Link Analysis

Simply put

Graph analysis is a technique that uses algorithms to automatically find and study the relationships between different entities, such as people, accounts, devices, or transactions. By modeling data as a network of connected points, it can surface hidden patterns and links that may not be visible when records are examined in isolation. In fraud and payment security work, it is often used to help investigators explore how seemingly separate entities may be connected.

Formal definition

Graph analysis is the application of data-driven techniques and algorithms to data modeled as a graph, where nodes represent entities and edges represent pairwise relationships between them, in order to discover actionable information hidden in connected data. It draws on graph theory, the mathematical study of structures used to model pairwise relations between objects, and typically employs algorithms to identify relationships, clusters, and paths across entities, often supported by visualization and exploration tooling. In fraud and risk contexts it may be applied to link entities such as accounts, cards, devices, and identifiers to help detect patterns associated with account takeover, synthetic identity, or organized fraud rings; note that its effectiveness depends on data quality, feature selection, and implementation, and like other detection controls it involves false-positive and false-negative trade-offs rather than guaranteed outcomes. This entry describes graph analysis as an analytical method and does not itself define a PCI DSS control or requirement.

Why it matters

Payment fraud is rarely committed by a single isolated actor acting in isolation. Organized fraud rings, synthetic identity schemes, and account takeover campaigns typically reuse shared elements across many apparently unrelated accounts, such as devices, email addresses, phone numbers, shipping addresses, or funding instruments. When investigators examine records one at a time, these shared connections are easy to miss. Graph analysis is intended to help surface those relationships by modeling entities as connected points, allowing analysts to see clusters and links that would otherwise remain hidden in row-by-row review.

For fraud and risk teams, this connected view can help prioritize investigation and reveal coordinated activity that individual transaction scoring may not flag. For example, several accounts that individually appear low risk may share a single device or identifier, which can suggest a common origin worth closer examination. Graph techniques may also assist in exploring patterns associated with synthetic identity fraud, where fabricated identities are built from reused or partially shared attributes.

Graph analysis is an analytical method rather than a guaranteed control, and its usefulness depends on data quality, the features selected, and how it is implemented. Like other detection approaches, it involves false-positive and false-negative trade-offs: legitimate shared infrastructure, such as households or shared networks, can produce misleading links, and sophisticated actors may deliberately avoid reusing identifiers. It should be understood as one input to investigation and risk decisioning rather than a standalone determinant of fraud.

Who it's relevant to

Fraud Analysts and Investigators

Graph analysis gives investigators a way to explore how accounts, devices, and identifiers connect, helping them uncover coordinated activity and fraud rings that isolated case review can miss. Analysts should interpret links as leads for further investigation rather than conclusions, keeping false-positive and false-negative trade-offs in mind.

Merchant Risk and Payment Processing Teams

Teams responsible for account and transaction risk can use graph techniques to identify shared attributes across accounts that may indicate synthetic identities or organized abuse. Effectiveness depends on the quality and breadth of the data available and on how the relationships are modeled.

Data Scientists and Detection Engineers

Those building detection systems apply graph algorithms and feature engineering to connected data, and are responsible for tuning models, selecting meaningful nodes and edges, and managing the balance between false positives and false negatives. This entry describes an analytical method and does not itself define a PCI DSS control or requirement.

Inside Graph Analysis

Nodes (entities)

The discrete objects modeled in a graph, such as accounts, cardholders, PANs or tokens, devices, email addresses, shipping addresses, IP addresses, and merchants. In fraud and risk analysis these represent the entities whose relationships may indicate coordinated or anomalous behavior.

Edges (relationships)

The connections between nodes, for example a device used to access multiple accounts, a shipping address shared across orders, or a payment instrument linked to several identities. Edges may carry attributes such as timestamp, frequency, or direction that inform analysis.

Link analysis

Techniques that examine how entities are connected to surface shared attributes, rings, or clusters that are not obvious when records are viewed individually. Commonly applied to detecting patterns consistent with account takeover, synthetic identity fraud, or organized card-not-present fraud.

Community and cluster detection

Methods that group densely interconnected nodes to identify potential fraud rings or collusion networks. Cluster membership is a signal for investigation rather than proof of fraud, and requires analyst review.

Feature extraction for scoring

Graph-derived attributes, such as the number of accounts sharing a device or the degree of connectivity of an entity, that can feed risk or fraud models. These features supplement, and do not replace, transaction-level and behavioral signals.

Data scope and sensitivity

The entities and attributes ingested into a graph may include cardholder data such as PAN. Where PAN is used as an identifier, it should be handled per applicable PCI DSS controls; sensitive authentication data must not be retained after authorization for this purpose. Using tokens or truncated/hashed identifiers where possible can help reduce exposure, with scope impact depending on implementation and validation.

Common questions

Answers to the questions practitioners most commonly ask about Graph Analysis.

Does graph analysis detect fraud on its own, or does it just identify relationships?

Graph analysis is a technique for modeling and examining relationships between entities such as accounts, cards, devices, IP addresses, and shipping addresses. It surfaces connection patterns and clusters that may warrant review, but it does not by itself determine that a transaction is fraudulent. Analysts and downstream scoring or rules typically interpret the relationships it reveals. On its own it is intended to help reveal linkages that flat, record-by-record analysis may miss; it is not a standalone verdict on fraud.

If two accounts are linked in a graph, does that prove collusion or fraud?

No. A link in a graph indicates a shared attribute or observed relationship, not an established intent. Shared devices, addresses, or IP ranges can arise from legitimate causes such as households, shared workplaces, mobile carrier NAT, or corporate networks. Treating linkage as proof produces false positives. Graph findings should be treated as signals for further investigation, weighted alongside other evidence, and the strength and type of each link matters more than the mere existence of a connection.

How do you decide which entities and edges to model in a fraud graph?

Modeling choices depend on the data you can reliably collect and the fraud patterns you are trying to surface. Common node types include accounts, payment instruments, devices, email addresses, phone numbers, and physical or IP addresses, with edges representing observed associations such as shared usage or transaction flow. Selection should be driven by which attributes carry signal for your fraud types, such as account takeover or synthetic identity clustering, and constrained by data quality, retention policies, and privacy obligations. Note that cardholder data and sensitive authentication data handled in these systems remain subject to applicable data protection controls; sensitive authentication data must not be retained after authorization.

How can graph analysis be integrated with existing rules and scoring models?

Graph-derived features, such as cluster size, connection density, or distance to known-bad entities, can be exposed as inputs to rules engines or machine learning scoring models rather than used in isolation. This lets network context complement transaction-level and behavioral signals. Integration typically requires deciding whether graph features are computed in near real time for authorization decisions or in batch for investigation and case management, since latency and infrastructure constraints differ substantially between those modes.

What are the main trade-offs between real-time and batch graph analysis?

Real-time graph analysis can inform decisions during authorization but is constrained by latency budgets and the cost of maintaining an up-to-date graph, which may limit query depth or the freshness of linked data. Batch analysis allows deeper traversal and larger clusters for investigation and pattern discovery but does not act within the decision window of an individual transaction. Many programs use both: lightweight graph features at decision time and richer analysis for offline investigation and model development. The appropriate balance depends on transaction volume, fraud types, and available infrastructure.

How do you manage false positives when clusters link legitimate users?

Because shared attributes can reflect legitimate behavior, tuning is needed to avoid penalizing connected but honest users. Practical measures include weighting edges by strength and reliability, distinguishing transient shared attributes from persistent ones, requiring corroborating signals before escalation, and routing ambiguous clusters to manual review rather than automated decline. Any detection threshold involves a false-positive versus false-negative trade-off, so teams should monitor review outcomes and confirmed-fraud feedback to recalibrate over time.

Common misconceptions

A connection between two entities in the graph proves they are involved in fraud.

Shared attributes such as a common device, IP, or address are signals that may warrant investigation, not proof of fraud. Legitimate reasons for shared attributes exist, for example shared households, corporate networks, or NAT. Graph findings help prioritize review and carry false-positive and false-negative trade-offs.

Graph analysis is a standalone control that prevents fraud on its own.

Graph analysis is one detection technique intended to help surface relationships and patterns. It does not replace authentication controls such as EMV chip authentication, 3-D Secure, or multi-factor authentication, nor transaction monitoring. It is intended to reduce, not eliminate, fraud, and works best as part of a layered program.

Putting cardholder data into a graph platform is outside PCI DSS scope because it is analytics rather than payment processing.

Storing or processing cardholder data such as PAN in a graph system brings that system into scope for applicable PCI DSS controls. Whether scope is reduced depends on transformations applied, such as tokenization, truncation, or hashing, and on how they are implemented and validated, not on the analytics label. Confirm requirements against the current published standard.

Best practices

Treat graph-derived connections and clusters as investigative signals that are triaged by analysts, and measure false-positive and false-negative rates rather than acting automatically on links.

Minimize sensitive data in the graph by using tokens or truncated or hashed identifiers where feasible, and never retain sensitive authentication data after authorization; document any use of PAN as an identifier.

Scope the graph platform for applicable PCI DSS controls where it stores or processes cardholder data, and validate any claimed scope reduction from tokenization, truncation, or masking against the current published standard rather than assuming.

Combine graph features with transaction-level and behavioral signals so that graph analysis supplements, rather than replaces, authentication and transaction monitoring in a layered fraud program.

Establish data quality and entity-resolution governance so that noisy or incorrect edges do not create misleading clusters, and periodically review resolution logic for over- or under-linking.

Retain audit trails and analyst review records for graph-based decisions to support investigations, dispute handling, and model governance, and revisit thresholds as fraud patterns and network rules evolve by brand and region.