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.

Money laundering rings, mule networks, and coordinated schemes deliberately split activity across accounts to evade per-account detection. The pattern is network-level; no GROUP BY recovers it. This sets up the anchor reveal on the next slide.

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.

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 on the Sample GDS Algorithms slide: 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.

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. 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.

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.

Three points aligned to the three-part structure: the anchor, the architecture, the payoff. Close on expansion framing.

Use this slide if the audience wants to see Genie on the raw catalog first. It establishes that Genie is a capable BI translator before any enrichment happens.

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 is sharper than the primary anchor because it uses the top 20 accounts rather than the top decile, which makes the result more striking: across 20 of the highest-volume accounts, no two accounts visit more than one shared merchant. 243 distinct merchants, maximum co-visit count of 2. The volume proxy produces a flat, dispersed list that looks like ordinary diverse spending.

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.