Tag: Cyber

Do Banks Need Dedicated Graph Databases?

About This Series

Fraud is often a relationship problem. A single account can look entirely ordinary while a cluster of accounts sharing a device, an address, or a funding source looks like something else altogether. Institutions that decide to detect fraud this way eventually run into a practical question: does the relationship data need its own specialized database, or can it live inside an application?

The question is usually argued on speed; how fast the software can chase connections through the data. That turns out to be one of the less important factors. What decides it in practice is how an institution buys software, deploys it, and explains it to reviewers.

This six-part series works through that reasoning in plain language, for a banking audience rather than an engineering one.

The first video establishes the vocabulary. A graph stores information as things and the links between them (accounts, emails, phones and devices as nodes) and the connections among them as edges. Storing data that way makes questions easy that are otherwise very hard. How many accounts use this same device? Is this account connected, through one or two intermediaries, to an account already confirmed as fraudulent? Account-by-account systems cannot answer those questions, because they examine one record at a time. Investigators can, of course, find the answers manually, pivoting across the core, the card system, the digital logs and the onboarding file. The question is whether that should be a manual exercise repeated from scratch on every case.

The second video draws the distinction everything else depends on. In-application does not mean in-house. The application can be a commercial product bought from a vendor, with graph capability built in, and for most institutions it will be. The term describes only where the relationship work happens: inside the fraud application, rather than in a separate database installed beside it. So the real contrast is not homemade versus purchased. It is one component versus two, and the second component brings its own licensing, its own review, its own operational life.

The third video takes on scale. Relationship graphs at community banks and credit unions are small by computing standards, and data of that size fits comfortably in an ordinary server’s memory, where searching it beats sending a request across a network and waiting for a reply. The specialized graph databases were built for organizations operating graphs many orders of magnitude larger. That is a real problem, but not one most financial institutions have.

The fourth video makes the core case on the grounds that actually decide these purchases. One vendor to assess rather than two or three, each with its own annual reassessment. A single self-contained application rather than a database somebody has to patch, back up and put through disaster recovery testing every year. One party who can walk a model validator through the entire method end to end. And enterprise graph licensing that would sit on top of whatever the application already costs.

The fifth video examines the middle path. Embedded graph databases (libraries offering permanent storage and a question language while running inside the application) sound close to ideal for banking. The complication is stability: RedisGraph was discontinued in 2023, and Kuzu was archived in October 2025 after its team was acquired. Successors exist, but none yet has the track record an institution planning a decade out would want.

The sixth video answers the fair skeptical question. If you are not buying a graph database and not betting on a young library, where does the analysis come from? From a mature ecosystem of graph libraries; like NetworkX for Python and others in wide use for well over a decade. A graph database is essentially three things sold together: storage, a query language, and an algorithm library. An application using a library keeps the storage where it already is, replaces the query language with purpose-built screens, and gets the algorithms for the cost of a dependency. Not a lesser version of the analysis. Often literally the same algorithms.

Why a Graph-First Approach is Key to Fraud Detection Success

Most fraud detection systems (whether they’re built on rules or on modern machine-learning models) evaluate one transaction at a time. A rule checks a transaction against a threshold. A gradient boosting model checks it against a feature vector. The feature vector is richer, but it’s still a description of a single event and one account’s own recent history. Which means an organized ring can pass straight through: no individual transaction crosses a threshold, and the relationships that would give the ring away (a shared device fingerprint, two addresses that differ by a unit number, a common funding source) never enter the score at all. Those connections do eventually get found, but usually by an analyst doing manual link analysis after an alert fires, which is downstream of the decision it should have informed.

This series of whiteboard explainers makes the case for a graph-first approach to detection: treating relationships as something you maintain and score continuously, before an alert exists, rather than something someone reconstructs by hand once the money is gone. Along the way it covers why the account ID in your transaction table is already a graph edge (and the only one most institutions ever use), why your fraud labels quietly teach a model to reproduce its predecessor’s blind spots, and what actually changes when the graph comes first.

Part 1 — The Ring That Never Tripped a Rule

Eleven accounts, opened over four months, each behaving like a model customer right up until all eleven ran the same bust-out play over nine days. No alert fired. No threshold was crossed. Then an analyst lays the accounts side by side and sees it in minutes; shared device fingerprints, addresses differing by a unit number, a common funding source. The structure had been in the data for roughly ninety days. The question the series answers: why couldn’t a good model see what an analyst found in minutes?

Part 2 — You Changed the Scoring Function, Not the Unit of Analysis

Rules and supervised machine-learning share a deeper assumption than the debate between them ever surfaced: both evaluate a single row. A rule checks a transaction against a threshold; a model checks it against a feature vector. Richer, but still one event. And a ring isn’t a row anywhere in your pipeline; so no scoring function can render a verdict on it. Closes with the uncomfortable corollary: independent scoring doesn’t just miss coordination, it quietly rewards it.

Part 3 — You’ve Been Computing Graph Features for Twenty Years

group_by(account_id) finds every transaction connected through one relationship and reduces them with a fixed function. That’s a one-hop neighborhood aggregation over a single edge type; a velocity counter, in graph terms. That edge got used because it was free: a foreign key someone stored decades ago. Device, address, funding source, session; all real, all in the building, none of them pointers. So when the model needs more signal, we add time windows. One hour becomes six becomes twenty-four. Ten columns, one relationship.

Part 4 — Your Labels Come From the System You’re Replacing

Confirmed frauds. Confirmed SARs. Charge-offs coded as fraud. Every label came from a case the current stack caught. The eleven accounts, absent link analysis, get coded as credit losses; now sitting in training data as normal accounts that happened to default. The model learns to reproduce the existing perimeter with better precision. It doesn’t learn to extend it. Meanwhile fan-out from a shared SSN needs no training set to be suspicious.

Part 5 — Downstream of the Decision It Should Have Informed

The alert fires, then the analyst reconstructs the network by hand. But the alert came from the model that already missed the ring. And when the case closes, the structure evaporates; a flag, a note, nothing queryable. Next week, an adjacent account, starting from zero.

Part 6 — “We Already Do Link Analysis”

Fair objection, wrong on the mechanism. The difference isn’t speed. That analyst who decided “Apt 4B” and “#4B” were the same address performed entity resolution by eye, once, then discarded it. Same SSN means same person. Same device means connected, maybe; two people at the same branch kiosk share a fingerprint.

Part 7 — Four Operations Your Feature Vector Can’t Phrase

Degree and fan-out. Connected components, and when the island formed. Shortest path to confirmed fraud. And k-hop traversal: account seven shares a device with five, five shares a funding source with three. Two hops. No velocity counter will ever surface it.

Part 8 — What Graph-First Actually Looks Like

A resolution rule you can read. Separate views for identity and behavior. A decomposed score (identity, neighbor, transaction) that gives a validator three things to challenge. A transition matrix you can print. And when the case opens, the network is already there.