One-line argument: financial crime is a network problem, the row
is the wrong unit of analysis, and we close that gap by running
Neo4j GDS as a silver-to-gold enrichment stage in front of
Databricks Genie. Framing throughout: expansion, not limitation
recovery.
The last bullet is the payload but say it carefully. "Above 90%"
is a widely-cited figure but sourcing it mid-deck slows the
story. "High double digits across published industry surveys" is
defensible without citation and still makes the point: the
baseline is broken, and it is broken because the unit of
analysis is wrong.
A ring is a shape, not a row. You cannot reach it by summing
columns or joining tables. Sets up the next slide, which names
the data structure that can represent and traverse those
connections efficiently.
The dataset contains two overlapping networks. The first is a
bipartite account-merchant graph: accounts spend at merchants.
The second is a peer-to-peer transfer network: accounts send money
directly to other accounts. Fraud rings leave footprints in both:
tight clusters of accounts trading with each other and routing
through the same merchants. The goal is not to label fraud; it is
to make the structural patterns visible so analysts can investigate.
Best proxy available without graph columns: biggest spenders,
their top merchants. Genie segments accounts into deciles by
transaction volume, counts transactions in the top decile.
Five merchants tied at 26 to 30. All look like ordinary commercial
activity. From this list there's no basis to pick one merchant
over another for investigation. The volume proxy consumed the answer.
Same question shape, different filter: community_id and
is_ring_candidate are now columns in Gold. The SQL collapses to
a single filter and count.
Two things change. MarketPlus and QuickCash were in the before
ranking at 30 and 26. From ring members alone: 111 and 104.
Half the cohort size, four times the raw count, seven times the
per-account rate. Second, CoinVault and LoanEdge never appeared
in the before ranking. The volume proxy couldn't surface them;
community membership can.
Hold on this slide until someone asks "how did you get that?"
That question is the invitation into the Architecture section.
If nobody asks, offer it.
One slide on why a graph database is the right tool to produce
those three kinds of answers. Lead with capability, not contrast.
Describe the pattern, get every instance back. The audience does
not need a SQL-vs-graph mechanics lesson; they need to know the
graph is built for the questions we just listed.
If asked in Q&A, the point comparison is: SQL needs a starting
account ID; a graph database needs only the shape.
Do not frame this as Genie having limits. The enriched-catalog
demo does not make Genie better; it gives Genie new dimensions
to operate over. Customers evaluating Genie on its merits need
to hear it is working as designed throughout.
Two questions from the base catalog, Genie answering what it's
built for. The point is not that Genie has limits; the point is
that Genie is a capable BI translator before any enrichment
happens. That establishes the floor the enriched-catalog slides
build on.
Frame the gap as a data layer problem, not a query layer
problem. The answer exists — it just has to be computed by GDS
and materialized before any query tool can reach it. This motivates
GDS as the silver-to-gold stage: the network is where those answers
live, and enrichment lands them in the catalog as ordinary columns.
The pivot slide. Traditional databases are point-lookup machines;
graph databases are pattern-matching machines. The closing bullet
is the bridge to the rest of the talk: we are not rebuilding the
analytics stack, we are landing graph intelligence in the
lakehouse as enriched Delta columns.
The pivot that ties the graph discussion back to Genie. Same Genie,
same SQL, new dimensions. The analyst works the way they always
have; the toolkit is strictly larger.
This is the slide that completes the answer to "how did you get
that?" Graph analysis produces the answers, those answers become
Delta columns, Genie queries them like any other column.
Positive-framed opening for Architecture. Lead with the unlock:
graph analysis produces three kinds of answers that don't exist
as row-level properties. Each of the three maps to a GDS algorithm
we'll see later: PageRank, Louvain, Node Similarity. Every one of
them lands as a Delta column alongside region, product, and balance.
Do not frame this as "SQL can't do X." Frame it as "graph analysis
unlocks these answers for Genie." Expansion, not limitation recovery.
Keep this slide general. The next three slides each cover one
algorithm in detail; this one sets the category and the
reproducibility property. That reproducibility matters when
scores become columns in a catalog that a non-deterministic
translator queries.
This is exactly the quantity that proxies like transfer volume
approximate badly. Ring captains route volume through structure,
so PageRank surfaces them even when their raw throughput looks
normal. 3.65× on the demo is the measured separation.
Louvain partitions by behavior, not by attributes. The 70%
purity number is honest: each ring-candidate community holds
~100 ring members and ~44 non-ring accounts absorbed by the
modularity objective. That is a Louvain tradeoff, not a GDS
failure. Worth naming directly if the audience pushes on
false positives.
Note fraud_risk_tier is a derived column, not a direct GDS
output. Worth calling out so the architecture diagram makes
sense two slides later.
The "shared neighborhood" question. Ring members visit anchor
merchants at elevated rates, which produces the Jaccard
separation. The degree cutoff is the honest caveat: accounts
that barely interact get excluded.
The pull direction matters. Neo4j does not write to Unity Catalog
directly; Databricks pulls from Neo4j via the Spark Connector in
nb04, joins with Silver tables such as accounts and account_labels,
and materializes the Gold tables. Nothing in the graph reaches
production queries except what the pipeline has already
materialized to Gold.
Two Gold tables support the Genie AFTER demo: gold_accounts holds
account metadata plus three GDS features, and
gold_account_similarity_pairs holds similarity edge pairs.
Four steps convert a network of account relationships into plain
columns that Genie queries like any other dimension. Structural
analysis runs once per pipeline cycle; every downstream consumer
reads the results as columns. The graph analysis is invisible to
the query layer.
The pipeline makes no judgment call. It surfaces shapes that
resemble rings and lets analysts do the fraud work with the
tools they already use. The "after" questions in this demo cover
merchant concentration, regional review workload, and book share
by community. That is the workflow.
Five question classes the enriched catalog opens up. Each is a
question family an analyst already knows how to ask, conditioned
on a new structural dimension. The SQL shapes are standard; what
is new is the dimension.
Pick three of these for the live portion. Composition and
cohort are the safest plays. Standard BI shapes over a new
dimension, clean bar charts, no interpretation layer. Rollup
and workload play well to ops and audit audiences. Merchant is
the "oh, this opens new investigations" moment.
Expansion, not limitation recovery. The analyst works in Genie
the same way they always have; the difference is that graph-
derived columns are now available as ordinary dimensions.
Generalize the pattern. Anywhere the answer lives in
relationships rather than individual rows, GDS-as-silver-to-gold
applies. The algorithm changes; the architecture does not.
Defensible framing for regulated environments. GDS outputs are
reproducible under a fixed projection; whatever reads the columns
adjudicates: investigator triage, supervised classifier, analyst
in Genie.
Six points. Unit of analysis, column inventory, pipeline
shape, determinism claim, what opens up, generality. The
column-inventory bullet is the sharpest: it reframes
the whole discussion around data engineering, not tool choice.
The architectural claim that answers "can we trust Genie?" You
do not need a deterministic LLM. You need a deterministic column
inventory underneath a non-deterministic translation layer.
Defensible framing for regulated environments. GDS outputs are
reproducible under a fixed projection; whatever reads the columns
adjudicates: investigator triage, supervised classifier, analyst
in Genie.
Backup anchor if Merchant Favorites doesn't land. Same shape as
the primary: the fraud-hunting question the analyst asks without
graph columns.
With no community_id available, the best proxy for "coordinated
activity" is counterparty concentration: accounts that send most
of their volume to a handful of partners. Genie writes the query
against account_links: per account, rank counterparties by volume,
keep the ones sending over half their volume to their top five.
Group by region.
Answer: 95 to 96 percent across every region. The ranking flagged
almost the entire book. No regional minority, no cohort to pull
for triage. The question consumed the answer.
is_ring_candidate is a column in Gold, so the query collapses: one
left join, average by region. No CTEs, no counterparty ranking.
The answer: four and a half to five and a half percent per region.
Roughly a tenth the size of the proxy minority. US-West highest,
APAC lowest. The structural minority the volume-proxy could not
see, because concentration does not imply coordination.
Most accounts concentrate on a handful of counterparties for
legitimate reasons: payroll, family transfers, regular suppliers.
Ring candidates are accounts that concentrate AND trade densely
with each other. Only the graph makes that distinction, and once
it's a column, Genie can triage on it like any other dimension.
This is the before answer for the merchant ring-candidate
validation pair. The question asks how spread out these high-volume
accounts are across merchants. The answer is consistent with
ordinary commercial activity: high volume, spread across many
merchants, no suspicious concentration. Without community membership
in the catalog, this is the best signal available and it's
inconclusive.
The after answer validates which of the four merchants carry actual
structural signal. The SQL joins gold_accounts and
gold_fraud_ring_communities on fraud_risk_tier and is_ring_candidate.
Two columns that don't exist in Silver.
Three merchants are noise: utilities, grocery, and retail all sit at
the ~4% book baseline. The crypto merchant is the signal: 64 of 84
customers in ring-candidate communities against a ~4% book rate — 19×
above baseline. Not a verdict, a triage priority. The before answer
could not distinguish James-Conway from the others; the after answer can.
The before answer for the account community membership validation
pair. The before question asks how spread out these high-volume
accounts are across merchants. It's the "diverse spending" reading
that was surfaced in the initial analysis. The answer is consistent
with ordinary commercial activity: high volume, spread across many
merchants, no suspicious concentration. Without community membership
in the catalog, this is the best signal available and it's
inconclusive.
The after answer closes the loop on the before interpretation.
19 of 20 top-volume accounts are low risk and cluster in two
main low-risk communities (16163 and 6049). The one high-risk
account (3404) is an isolated case in community 3040, not part
of a coordinated ring.
This is the validation result the before answer couldn't produce:
not just "these accounts visit many merchants" but "these accounts
are in known low-risk communities, and the diversity is structural,
not a cover." The enrichment confirmed the before reading rather
than overturning it, which is itself a useful demo beat. The
graph doesn't always find fraud; sometimes it confirms the analyst
was already right.