FinSight
FinSight is a Neo4j-powered fraud investigation agent for finding suspicious account networks in financial transaction data. It turns raw IEEE-CIS fraud records into an explorable graph so an investigator can see not only which accounts are risky, but also why they look connected.
Agent Name
FinSight
Git: https://github.com/mahanteshimath/FinSight
What It Does
FinSight helps fraud analysts investigate connected risk across accounts, devices, and merchants. It loads transaction and identity data into Neo4j Aura, then presents a live dashboard where users can:
-
inspect account, device, and merchant relationship counts;
-
filter the graph to fraud-connected activity;
-
click any node to expand its 1-hop or 2-hop neighborhood;
-
trace shared devices and merchant/product links behind suspicious accounts;
-
view fraud samples with the supporting graph context instead of a flat score;
-
switch between light and dark themes for a cleaner investigation workspace.
The goal is to make fraud investigation feel like following evidence, not scanning isolated rows.
Dataset and Why a Graph Fits
Dataset: IEEE-CIS Fraud Detection Dataset, using train_transaction.csv and train_identity.csv.
FinSight loads the first 50,000 transaction rows by default and merges transaction and identity records on TransactionID.
The graph model focuses on the entities that make fraud networks discoverable:
-
Accountnodes from card/account identifiers -
Merchantnodes from product or merchant-like transaction categories -
Devicenodes from device identity fields -
(:Account)-[:AT_MERCHANT]->(:Merchant) -
(:Account)-[:USES_DEVICE]->(:Device)
A graph fits because fraud is rarely isolated. A single account can look normal on its own, while its neighborhood reveals that it shares a device with known fraud accounts or repeatedly appears near the same merchant/product patterns. Neo4j makes those multi-hop relationships easy to ask and easy to explain:
MATCH (fraud:Account {risk_score: 1})-[:USES_DEVICE]->(d:Device)<-[:USES_DEVICE]-(neighbor:Account)
RETURN fraud.id, d.id, neighbor.id, neighbor.risk_score
That is the core idea behind FinSight: relationship structure becomes evidence.
Query history from Neo4j Aura:
Try this flow:
-
Open the deployed FinSight dashboard.
-
Go to
/graph. -
Turn on Fraud-connected only.
-
Click a risky account node.
-
Switch between 1-hop and 2-hop neighborhoods.
-
Show the shared device or merchant path that explains the suspicious connection.
Link
- Live Agent: FinSight on Vercel
Why FinSight Stands Out
The Graph Matters
FinSight does not use Neo4j as a visual spreadsheet. The relationships drive the insight. Shared devices and repeated merchant/product connections let the agent surface suspicious neighborhoods that would be hard to notice from individual transaction rows.
Built for a Real Investigator
The dashboard supports the actions an analyst would actually take: filter to risky activity, adjust graph density, expand neighborhoods, reset focus, inspect the evidence path interactively, and switch themes for comfortable analysis.
It Explains the Why
Instead of returning only "fraud" or "not fraud," FinSight shows the connected context: which account is risky, which device or merchant connects it to other activity, and how far the relationship is from the focus node.
Presentation Ready
The project includes a Neo4j Aura loader, verification script, live query evidence, dashboard demo, Next.js dashboard, and Vercel deployment.
Live Neo4j Aura Query Evidence
All summarized investigation queries were successfully executed in Neo4j Aura on the IEEE-CIS Fraud Detection graph. The query history demo above shows the live execution path, and the results below summarize what the graph revealed.
Graph Structure Confirmed Live
| Entity | Count |
|---|---|
| Account nodes | 5,446 |
| Device nodes | 590 |
| Merchant nodes | 5 |
AT_MERCHANT relationships |
7,439 |
USES_DEVICE relationships |
5,352 |
Properties: Accounts have id, risk_score, and email_domain. Devices have id and type. Merchants have id.
Query Results Summary
Query 1 - Node Counts by Label
-
Account: 5,446
-
Device: 590
-
Merchant: 5
Query 2 - Relationship Types
-
AT_MERCHANT: 7,439 -
USES_DEVICE: 5,352
Query 3 - Property Inventory
-
All 3 Account properties,
id,risk_score, andemail_domain, exist on every Account node. -
Verified in the Neo4j Aura query console.
Query 4 - Risk Score Distribution
-
Minimum risk score: 0
-
Maximum risk score: 1
-
Average risk score: ~0.0141
-
Interpretation: the graph is highly skewed toward low-risk accounts, with a small but important group flagged at maximum risk.
Query 5 - High-Risk Accounts (risk_score = 1)
-
Found high-risk accounts such as
17325(hotmail.com),1775(gmail.com),17739(anonymous.com), and7794(hotmail.com). -
Suspicious or disposable-looking email domains become more meaningful when combined with graph structure.
Query 6 - Device Sharing: Most Connected Devices
| Device | Type | Accounts Sharing It |
|---|---|---|
| Windows | desktop | 1,546 |
| iOS Device | mobile | 860 |
| MacOS | desktop | 640 |
| Trident/7.0 | desktop / IE | 505 |
| rv:11.0 | desktop | 142 |
Query 7 - Merchant Risk Exposure
| Merchant | Accounts | Avg Risk |
|---|---|---|
| W | 3,655 | 0.009 |
| H | 1,751 | 0.011 |
| R | 1,058 | 0.016 |
| S | 489 | 0.010 |
| C | 486 | 0.045 |
Merchant C has the highest average risk score among all merchants in this graph.
Query 8 - Fraud Ring Detection
Multiple high-risk accounts, including 3154, 10876, 7794, 8528, 5812, 11920, and 10493, all share Device ID 18306 (Windows, desktop). This is a classic fraud-ring pattern: many fraudulent accounts operating from the same device.
Key Insight
Device 18306 is a fraud-ring hub because it connects many accounts with risk_score = 1. Merchant C has the highest average merchant risk score at approximately 0.045. Together, these are the most actionable fraud signals found in the current graph.
Technical Quick Start
FinSight loads IEEE-CIS fraud data into Neo4j Aura and visualizes it with a Next.js dashboard.
Contributor
Mahantesh Hiremath