Using Neo4j Graph Data Science in Financial Services: From Network Analytics to ML Features

December 29, 2025
Using Neo4j Graph Data Science in Financial Services: From Network Analytics to ML Features

Using Neo4j Graph Data Science in Financial Services: From Network Analytics to ML Features

Graph Data Science (GDS) in Neo4j provides a production‑grade toolkit for analyzing connected data and turning graph structure into machine‑learning‑ready features. For financial institutions, this is particularly valuable in domains such as credit risk, fraud/AML, and customer 360, where relationships between entities often carry more signal than the entities themselves.[3][1]

This article introduces core GDS concepts and demonstrates how to apply them with concrete Cypher and Python code examples, assuming a mixed audience of finance and IT professionals.

1. What Neo4j Graph Data Science Provides

Neo4j GDS is a library that runs on top of a Neo4j database and exposes a large collection of graph algorithms, feature‑engineering primitives, and graph‑native ML pipelines. It is designed to integrate with existing analytics stacks via a Cypher API and a Python client, and can also be consumed as a managed service (Neo4j AuraDS) in the cloud.[2][1]

At a high level, GDS enables:

  • Network analysis: centrality, community detection, path analysis.
  • Graph feature engineering: converting relationships into numerical features and embeddings for ML.[1]
  • Graph ML tasks: node classification, link prediction, similarity, and recommendation.

2. Data model and GDS graph projections

Assume a typical financial graph:

  • Nodes:
    • Customer (obligor) with attributes like rating, sector, region.
    • Account with limit, utilization, product type.
    • Transaction with amount, timestamp, direction.
  • Relationships:
    • (:Customer)-[:OWNS]->(:Account)
    • (:Account)-[:HAS_TRANSACTION]->(:Transaction)
    • (:Customer)-[:RELATED_TO]->(:Customer) (related parties)
    • (:Customer)-[:SUPPLIER_OF]->(:Customer) (supply‑chain links)

GDS operates on in‑memory “projections” of the stored graph. For example, to focus on customer‑to‑customer linkages (group structures, related parties, supply chains), one might project a simplified customer graph.[1]

2.1 Creating a GDS projection (Cypher)

// Project a customer graph into GDS
CALL gds.graph.project(
  'customerGraph',
  'Customer',                      // node label
  {
    RELATED_TO: { type: 'RELATED_TO', orientation: 'UNDIRECTED' },
    SUPPLIER_OF: { type: 'SUPPLIER_OF', orientation: 'UNDIRECTED' }
  }
);

This projection is an in‑memory graph that GDS algorithms will work on, without modifying the stored data. Additional properties (e.g. exposure, sector) can be included for weighted algorithms or feature engineering.[1]

3. Centrality: identifying systemic or “hub” nodes

Centrality algorithms are often the first step to understand which actors are structurally important in a financial network. In credit and fraud contexts, this helps identify systemic obligors, influential customers, or “hub accounts” in money‑laundering schemes.[3][1]

3.1 PageRank example (Cypher)

// Run PageRank on the projected customer graph
CALL gds.pageRank.write('customerGraph', {
  maxIterations: 20,
  dampingFactor: 0.85,
  writeProperty: 'pagerank'
});

This persists a pagerank property on Customer nodes in the underlying Neo4j database. Those scores can then be used:[1]

  • Directly in dashboards (e.g. “top 100 systemic customers by network influence”).
  • As input features for downstream ML models (e.g. PD or fraud scores).

3.2 Interpreting centrality in a credit‑risk context

For a risk officer, PageRank can be interpreted as a measure of “network influence” or “systemic importance”: a customer with many connections to other important customers will receive a higher score. In a supply‑chain or interbank lending network, such nodes may require closer monitoring or tighter limits.[1]

4. Community detection: discovering clusters and rings

Community detection algorithms partition the graph into clusters of tightly connected nodes. In financial services, this is useful for:[1]

  • Detecting fraud rings and synthetic identities.
  • Identifying corporate group structures and extended related‑party networks.
  • Understanding sectoral or regional subgraphs with concentrated risk.

4.1 Louvain community detection (Cypher)

CALL gds.louvain.write('customerGraph', {
  writeProperty: 'communityId',
  maxLevels: 10
});

Each Customer node now has a communityId indicating which cluster it belongs to. Analysts can then:[1]

  • Aggregate metrics by community (e.g. total exposure, PD distribution).
  • Use communityId as a categorical feature in credit or fraud models.

Example aggregation:

MATCH (c:Customer)
WITH c.communityId AS community, count(*) AS size,
     sum(c.exposure) AS totalExposure
RETURN community, size, totalExposure
ORDER BY totalExposure DESC
LIMIT 10;

This yields the largest exposure clusters, which can highlight risk concentrations or potential fraud rings.[3][1]

5. Graph embeddings: turning structure into ML features

Graph embeddings transform the neighborhood structure of nodes into dense numeric vectors that can be consumed by downstream ML models, such as gradient‑boosted trees or neural networks. For example, in a fraud‑detection use case, embeddings capture how similar a customer’s connections and behavior are to known fraudsters.[4][5][3][1]

5.1 FastRP embedding example (Cypher)

CALL gds.fastRP.write('customerGraph', {
  embeddingDimension: 64,
  iterationWeights: [0.8, 1.0, 1.0, 0.8],
  writeProperty: 'embedding'
});

This call writes a 64‑dimensional embedding vector to each Customer as the embedding property. These vectors can then be exported to a data frame and merged with tabular features.[4][1]

5.2 Exporting embeddings to Python

from neo4j import GraphDatabase
import pandas as pd

uri = "bolt://localhost:7687"
driver = GraphDatabase.driver(uri, auth=("neo4j", "password"))

def fetch_embeddings(tx):
    query = """
    MATCH (c:Customer)
    RETURN c.customerId AS customer_id,
           c.embedding AS embedding,
           c.default_within_12m AS label
    """
    return list(tx.run(query))

with driver.session() as session:
    rows = session.read_transaction(fetch_embeddings)

df = pd.DataFrame([{
    "customer_id": r["customer_id"],
    "embedding": r["embedding"],
    "label": r["label"]
} for r in rows])

# Split the embedding vector into columns
emb_df = df["embedding"].apply(pd.Series)
emb_df.columns = [f"emb_{i}" for i in emb_df.columns]

features = pd.concat([df[["customer_id", "label"]], emb_df], axis=1)

This prepares a feature matrix that can be fed into any Python‑based ML library.[4]

6. Graph‑native ML pipelines: node classification and link prediction

Beyond feature engineering, GDS includes built‑in ML pipelines for node classification and link prediction tasks. These pipelines combine feature computation, train/validation splits, model training, and evaluation.[1]

6.1 Node classification pipeline (Cypher outline)

Consider a simple example where the goal is to predict whether a customer will default in the next 12 months (default_within_12m). GDS can build a node classification pipeline on top of the customer graph.[1]

// 1. Create the in‑memory graph (including features)
CALL gds.graph.project(
  'customerGraphML',
  {
    Customer: {
      properties: ['pagerank', 'degree', 'sectorCode']
    }
  },
  'RELATED_TO'
);

// 2. Create a pipeline
CALL gds.beta.pipeline.nodeClassification.create('customerDefaultPipeline');

// 3. Add feature steps (for example, degree)
CALL gds.beta.pipeline.nodeClassification.addNodeProperty(
  'customerDefaultPipeline',
  'degree',
  { nodeLabels: ['Customer'], relationshipTypes: ['RELATED_TO'] }
);

// 4. Add a model (e.g. logistic regression)
CALL gds.beta.pipeline.nodeClassification.selectFeatures(
  'customerDefaultPipeline',
  { nodeLabels: ['Customer'] }
);

// 5. Train the model
CALL gds.beta.pipeline.nodeClassification.train(
  'customerGraphML',
  {
    pipeline: 'customerDefaultPipeline',
    targetNodeLabels: ['Customer'],
    targetProperty: 'default_within_12m',
    metrics: ['AUC', 'F1']
  }
)
YIELD modelInfo, metrics;

This is a simplified outline; in a real‑world setting, the pipeline would include more features, hyperparameter tuning, and explicit train/validation configurations. The trained model can be stored in the GDS model catalog and later used for scoring new or updated data.[1]

6.2 Link prediction for suspicious relationships

Link prediction is particularly relevant for fraud/AML and related‑party detection, where the goal is to estimate whether a relationship between two customers should exist or is likely to appear.[5][3]

In GDS, link prediction features can be computed using similarity algorithms (e.g. Jaccard, Adamic‑Adar) and node embeddings; the resulting feature vectors feed a binary classifier. Official examples from Neo4j demonstrate how to use GDS link prediction to detect fraud networks in payment graphs.[5][3][1]

7. Integrating GDS with a broader financial ML stack

GDS is designed to integrate into existing data and ML platforms, whether on‑prem or on cloud providers such as AWS, Azure, and Google Cloud. A typical architecture for a financial institution looks like this:[2]

  • Neo4j core:
    • Stores the operational knowledge graph (customers, accounts, transactions, relationships).
    • Hosts GDS for graph projections, algorithm runs, and ML pipelines.
  • Analytics & ML platform:
    • Python notebooks / pipelines connect to GDS to orchestrate feature computation and model training.[1]
    • Feature store and model registry persist features and models across teams and use cases.
  • Applications:
    • Risk dashboards and fraud monitoring tools query graph‑derived metrics and scores.
    • GenAI components use graph features and ML outputs to generate explainable narratives for risk officers.

Neo4j AuraDS, the managed GDS service, provides a cloud‑native way to run these workloads without operating the graph infrastructure directly, which is attractive for teams that want to focus on analytics rather than cluster management.[2]

8. Summary: why GDS matters for finance and IT

For teams with both financial and IT expertise, Neo4j Graph Data Science offers a practical way to:

  • Understand complex exposure and transaction networks through centrality, communities, and paths.[1]
  • Turn relational and behavioral context into machine‑learning features via graph embeddings and algorithm outputs.[4][1]
  • Build graph‑native ML models, such as default prediction and fraud link prediction, and integrate them into existing ML and GenAI platforms.[5][3]

In risk, fraud, and customer analytics, the most interesting signals often live not in individual records but in how those records are connected. GDS operationalizes that insight and makes it accessible to both quantitative risk teams and engineering organizations.

Comments

Loading comments...