From Tables to Networks: A Deep Dive into Graph in Microsoft Fabric for Financial Services Insights

Most financial services data is already “connected.” It just isn’t modeled that way.

Fraud rings don’t show up as a single row. Money laundering doesn’t announce itself in one transaction. Counterparty exposure isn’t obvious from one booking. The meaningful signal lives in relationships: who shares an address, which accounts route funds through the same nodes, where devices and identities overlap, and how risk propagates through a network.

Graph in Microsoft Fabric is designed for exactly that: turning your OneLake data into a connected model you can explore visually, query with GQL, and enrich with built-in graph algorithms—without standing up a separate graph stack and duplicating data.

In financial services, this is the difference between “we have the data” and “we can reason over the connections.”

What we’re going to do

We’re going to make Fabric Graph feel practical—especially for regulated, high-scrutiny analytics.

You’ll walk away with:

• A clear mental model of what Graph in Microsoft Fabric is doing under the hood (and what it isn’t).
• A reference graph design for common financial services relationship problems (fraud/AML/risk).
• A hands-on guide to building a graph model in Fabric, loading it, and querying it (both visually and with GQL).
• Proven query patterns (multi-hop, star patterns, shared identifiers) plus the guardrails you need to keep results reliable and performant in today’s preview capabilities.

Along the way, we’ll keep the focus on “power with clarity”—the kind you can explain to auditors, model risk teams, and engineering leadership.

Why graphs matter in financial services (and why joins aren’t the point)

A good graph use case isn’t “I want a graph.” It’s: “I keep asking relationship questions that are awkward in tables.”

A few examples that come up constantly:

• Fraud and account takeover: “Which customers share devices, phone numbers, IPs, or beneficiary accounts?”
• AML investigations: “Show me the network around this entity, and how funds flow across 2–8 hops.”
• Counterparty and concentration risk: “What’s the connected exposure when I traverse ownership, guarantees, and shared directors?”
• Payments intelligence: “Which merchants sit at the center of high-risk clusters?”
• KYC and identity resolution: “Where do identity attributes collide across supposedly distinct customers?”

Relational databases can answer many of these—but often by building wide tables, doing repeated self-joins, or exploding intermediate result sets. Graph systems flip the work: relationships are first-class edges, so the question becomes traversal and pattern matching rather than join engineering.

This is the heart of graph analytics: you stop wrestling with the shape of the query and start asking better questions.

What Graph in Microsoft Fabric is (and what to not confuse it with)

Graph in Microsoft Fabric is a native graph database capability for analytics and modeling, currently in public preview.

A few key properties matter for how you design and operationalize it:

• It implements the labeled property graph model (nodes + edges, both with labels and properties).
• It supports GQL (Graph Query Language) aligned to the ISO standard (ISO/IEC 39075), and includes NL2GQLsupport (natural language to GQL).
• It operates directly on OneLake, positioned to reduce brittle ETL/replication patterns for graph analytics.
• It’s integrated into the Fabric experience, including Power BI integration and Fabric governance/security patterns.
• It includes built-in algorithms such as shortest path, PageRank, weakly connected components (WCC), and Louvain.

Also worth noting: industry reporting has described Fabric’s Graph feature as leveraging LinkedIn’s graph technologyand being integrated into Fabric’s Real-Time Intelligence workload, with visual exploration and natural language querying as part of the experience.

Two common confusions to avoid:

• This is not “Microsoft Graph” (the Microsoft 365 API surface).
• This is not “GraphQL” (a query language for APIs). Fabric does have GraphQL tooling, but it’s a different thing entirely than Fabric’s graph database capability.

For this post, when we say “Fabric Graph,” we mean Graph in Microsoft Fabric (preview).

The mental model: how your OneLake tables become a graph

Graph in Fabric doesn’t start with “load a graph file.” It starts with a modeling layer:

1. You select data from OneLake (typically Lakehouse-backed tables/files).
2. You map node labels to tables + key columns.
3. You map edge labels to tables + source/target key columns.
4. You Save to load/construct the graph so it’s ready for querying.

That’s a deceptively simple workflow, but it forces a useful discipline: every node type must have a stable identifier, and every relationship must be expressed as a consistent key-to-key mapping.

A practical translation looks like this:

• A customers table becomes (:Customer) nodes keyed by customer_id.
• An accounts table becomes (:Account) nodes keyed by account_id.
• A customer_accounts bridge becomes [:OWNS] edges from customer → account.
• A transactions table can become:
  • [:TRANSFERRED_TO] edges from source account → destination account (event-as-edge), or
  • (:Transaction) nodes with edges from account → transaction → account (event-as-node).

The right choice depends on your questions. We’ll come back to that.

Preview guardrails you need to design around

Because Graph in Fabric is in preview, you should model with its current constraints in mind:

• Supported property types exposed today include Boolean, Double, Integer, String, and Zoned DateTime.
• Variable-length (multi-hop) patterns are currently supported up to 8 hops.
• There are practical limits around query timeouts, large result sizes, and very large graph sizes (and the docs explicitly call out potential instability above certain scales).

This is not a reason to avoid the feature. It’s a reason to start with a focused graph designed for a specific class of relationship questions—and expand deliberately.

A reference graph model for fraud, AML, and customer risk

If you want one “starter” model that pays dividends quickly, build around identity, accounts, and movement of value.

Node types that tend to be high leverage

• Customer (or Party)
• Account
• Transaction (optional; depends on modeling choice)
• Merchant (for card/payments)
• Device, Phone, Email (identity signals)
• Address (normalized)
• Employer / Organization (for KYC context, when appropriate)

Relationship types that unlock investigation workflows

• (:Customer)-[:OWNS]->(:Account)
• (:Customer)-[:USES_DEVICE]->(:Device)
• (:Customer)-[:HAS_PHONE]->(:Phone)
• (:Customer)-[:LIVES_AT]->(:Address)
• (:Account)-[:TRANSFERRED_TO]->(:Account) (event-as-edge)
• (:Account)-[:PAID]->(:Merchant) (or via transaction)

The real design trick in financial services isn’t picking labels—it’s deciding what you want to be able to explain:

• If you’re building a case investigation experience, you want relationships that a human can read: Customer → Account → Account → Customer.
• If you’re building model features, you want graph structures that create stable, computable signals: community membership, centrality, number of risky neighbors, etc.

That’s where fraud detection teams usually land: one graph that supports both investigation and feature engineering, with “gold” relationship tables feeding the graph model.

How to build this in Fabric: a practical walkthrough

This section is intentionally concrete. The goal is that a reader can follow it and get to their first real query.

Step-by-step: create the Graph model and load data

Prerequisites matter more than people expect:

• Graph must be available in your region and enabled in your tenant.
• You need OneLake data to model—commonly a Lakehouse (and note the current restriction around Lakehouse schema preview).

Then, in your Fabric workspace:

1. Create a Graph model (preview) item (+ New item → Analyze and train data → Graph model).
2. In the graph model, select Get data, choose your tables from the OneLake catalog, and Load them into the modeling experience.
3. Add nodes: for each entity, pick a Label name, a Mapping table, and a Mapping column (your stable ID).
4. Add edges: select a mapping table, then choose the source node mapping column and target node mapping column that create the relationship.
5. Select Save to validate the model and load/construct the graph so it’s queryable.

A small but important operational detail: today, you generally need to reload the graph (Save) when the model or underlying data changes.

Two ways to query: visual builder or GQL code

Fabric gives you two query entry points from the graph’s home page:

• Query builder: interactive node/edge selection, filters, properties, and results.
• Code editor: write GQL directly and run it.

There’s also a Graph QuerySet concept that supports sharing query results (with role constraints described in the docs).

In practice, teams often start investigations in the query builder and then “graduate” the useful patterns into GQL for repeatable analysis.

This is where Microsoft Fabric shines: you can meet analysts where they are, while still supporting rigorous, versionable query logic.

GQL patterns that pay off in financial services

Graph Query Language in Fabric is built around a predictable structure: MATCH patterns, filter conditions (FILTER or WHERE), and RETURN projections (often with grouping/ordering).

Below are patterns I recommend because they map cleanly to fraud/AML/risk workflows.

Shared-identifier discovery (devices, phones, addresses)

This is one of the fastest “value demonstrations” you can run: show how quickly you can find customers linked by a shared identifier.

MATCH (c1:Customer)-[:USES_DEVICE]->(d:Device)<-[:USES_DEVICE]-(c2:Customer)
FILTER c1.customerId <> c2.customerId
RETURN c1.customerId AS customer1,
       c2.customerId AS customer2,
       d.deviceId     AS sharedDevice
LIMIT 100

Why it matters: this pattern is the foundation of synthetic identity detection, mule networks, and account takeover investigation. It also shows exactly why graphs are more than a novelty—because “who shares what” becomes a first-class query.

“Star” patterns for customer 360 with risk context

Fabric Graph supports composing non-linear patterns—think “radiating” edges off a central node.

MATCH (c:Customer)-[:OWNS]->(a:Account),
      (c)-[:HAS_PHONE]->(p:Phone),
      (c)-[:LIVES_AT]->(addr:Address),
      (c)-[:USES_DEVICE]->(d:Device)
FILTER c.customerId = 'C12345'
RETURN c.customerId, a.accountId, p.phone, addr.addressHash, d.deviceId
LIMIT 200

Why it matters: investigators don’t want six separate queries. They want a coherent, reviewable picture.

Multi-hop traversal for “how far does this go?”

Variable-length patterns are the graph equivalent of “follow the money,” and Fabric supports bounded repeats (up to 8 hops today).

MATCH (a0:Account)-[:TRANSFERRED_TO]->{1, 4}(aN:Account)
FILTER a0.accountId = 'A0001'
RETURN a0.accountId AS startAccount, aN.accountId AS reachedAccount
LIMIT 200

A practical note from the docs: bounded variable-length patterns exist for this kind of work, and current limits cap the hop count to 8.

Avoiding noisy cycles with TRAIL

Real-world financial networks have cycles (recurring transfers, back-and-forth movement). For pattern matching, you often want to prevent reusing the same edge repeatedly. Fabric supports TRAIL to discard matches that reuse an edge.

Conceptually:

MATCH TRAIL (a:Account)-[:TRANSFERRED_TO]->(b:Account)-[:TRANSFERRED_TO]->(c:Account)
RETURN a.accountId, b.accountId, c.accountId
LIMIT 100

This matters in AML-style explorations because it reduces “loop artifacts” and keeps the narrative more intelligible.

Building ring candidates: “many-to-one-to-many” flows

A common fraud pattern is aggregation into a hub account, then redistribution (or cash-out). Graph makes “shape queries” readable.

MATCH (c1:Customer)-[:OWNS]->(a1:Account)-[:TRANSFERRED_TO]->(hub:Account)<-[:TRANSFERRED_TO]-(a2:Account)<-[:OWNS]-(c2:Customer)
FILTER c1.customerId <> c2.customerId
RETURN hub.accountId AS hubAccount,
       count(*)      AS numLinkedTransfers
ORDER BY numLinkedTransfers DESC
LIMIT 50

This query is not “the answer.” It is a candidate generator—the kind you feed into triage, scoring, or analyst review.

Where algorithms fit: turning relationships into reusable signals

Graph in Fabric isn’t just about traversals. It’s also about enrichment: adding scores or communities that can be consumed downstream in BI and AI workflows. The overview explicitly calls out built-in algorithms including shortest path, PageRank, WCC, and Louvain.

In financial services, algorithm outputs typically map to operational questions:

• PageRank / centrality-style scores: “Which accounts are structurally influential in this network?” (useful for prioritizing review queues and building model features).
• WCC (weakly connected components): “What are the disconnected islands?” (useful for segmenting networks and understanding blast radius of an alert).
• Louvain communities: “Which clusters behave like tight communities?” (useful for surfacing potential rings).

A critical preview reality: don’t treat these as magic. Treat them as features—inputs to a broader risk decisioning process, explainable and testable like any other derived signal.

Operational guardrails for regulated environments

This is the part teams often skip until it hurts. Don’t.

A few preview constraints are particularly relevant in regulated analytics environments:

• Graph models are currently limited in number per workspace, and very large graphs may be unstable beyond certain sizes.
• Graph creation/update and query execution have documented timeout behavior.
• Large responses may be truncated, and very large aggregations can be unstable.
• Data sources and type support are currently constrained (plan your schema and casting accordingly).

On the governance side, the docs highlight that Graph operates within Fabric’s security and workspace model, and access management is scoped to the hosting workspace.

My recommendation for financial services teams: start with a well-scoped graph (one product line, one region, one investigation flow), build trust, and expand with intent.

Closing: the real promise of Fabric Graph in financial services

Graph in Microsoft Fabric gives financial services teams a way to shift from “analytics over rows” to “analytics over relationships”—using a labeled property graph on OneLake, queried via standards-aligned GQL, and integrated into the same Fabric governance and capacity model you’re already using.

What makes it powerful isn’t that it’s a graph.

It’s that it brings graph thinking into the day-to-day workflows that matter: fraud operations, AML investigations, customer risk, and network-driven insights—without demanding a separate platform and separate data gravity.

If you’re exploring this space, pick one relationship question you can’t answer cleanly today, model it with a tight set of nodes and edges, and get to a first query in the Fabric code editor. That “first win” is usually all it takes for the value of connected intelligence to click.