Tracing Fraud Rings with a Graph: What I Learned Building with FalkorDB

Aadvik Krishna — Sat, 17 Oct 2026 19:25:00 +0000

Banks flag suspicious transactions all day. The hard part isn't the flag—it's seeing what's behind it.

Fraud rings can hide in relationships: accounts that share a device, logins from the same IP address, and money that loops between accounts. This is a graph problem, so for Graph Hacks, I built Fraud Ring Investigator, a project that investigates flagged transactions using FalkorDB and explains the evidence behind its findings.

How it works

The graph contains people, accounts, devices, IP addresses, merchants, and money transfers. The project uses synthetic data with three planted fraud rings among legitimate accounts.

For each flagged transaction, the investigation:

Finds accounts linked through shared devices and IP addresses.
Groups connected accounts using weakly connected components.
Ranks potentially important hub accounts.
Traces money paths as evidence.
Looks for circular transfer patterns.
Freezes accounts and creates a compliance case in the graph.

The report includes graph paths and the Cypher queries behind its claims, helping an analyst inspect how the investigation reached its conclusions.

What I learned

1. The relationships you choose matter

My initial approach to weakly connected components included money transfers. That connected separate rings through ordinary accounts. Restricting the analysis to device and IP relationships helped separate the planted rings in my dataset.

2. PageRank doesn't tell the whole story

PageRank can help identify important accounts, but it doesn't capture every kind of activity. An account sending money to multiple other accounts may be important even if PageRank alone doesn't rank it highly. Combining it with transfer degree helped address this in my project.

3. Database details matter

While building the project, I encountered FalkorDB query constraints and duplicate graph nodes. I adjusted the shortest-path queries to fit the engine's requirements and used MERGE to avoid creating duplicate device and IP nodes. This reinforced the importance of testing queries against the actual database.

4. A graph can store investigation outcomes

The project doesn't just query relationships. It also writes investigation outcomes back into the graph: freezing an account and creating a Case node linked to affected accounts. This keeps the investigation evidence and recorded actions connected.

Limitations and next steps

The current project uses a small synthetic dataset and a fixed investigation pipeline. It is a prototype, not a production fraud-detection system. A possible next step is to let an LLM choose which graph investigation tool to call based on the evidence found at each stage.

You can explore the source code here:

Fraud Ring Investigator on GitHub

Building this project taught me that graph databases are useful not just for storing connected data, but also for investigating relationships and producing evidence that people can inspect.

Building an Incident Triage Agent with Full Observability in SigNoz

Aadvik Krishna — Fri, 24 Jul 2026 01:00:59 +0000

The problem: AI agents are black boxes

AI agents chain LLM calls and tool calls together to make decisions. But
when something goes wrong — a slow response, an unexpected answer, a
runaway cost — you're stuck guessing. You can't debug what you can't see.

For the "Agents of SigNoz" hackathon, I wanted to build something that
addresses this directly: an AI agent whose entire decision-making process
is fully observable, end to end.

What I built

An Incident Triage Agent — a small AI agent that simulates what an
on-call engineer's assistant might do during a production incident:

Plans an investigation approach (LLM call)
Searches logs for relevant errors (tool call)
Checks a runbook for the matching incident type (tool call)
Scores severity based on what it found (tool call)
Summarizes a recommended action for the engineer (LLM call)

Every one of these five steps is wrapped in its own OpenTelemetry span, so
a single incident investigation shows up in SigNoz as one connected trace
with all five child spans nested underneath it.

Tech stack

Python for the agent logic
Google Gemini API (gemini-3.5-flash) for the two LLM calls
OpenTelemetry SDK, exporting spans via OTLP/gRPC
SigNoz, self-hosted locally via the new Foundry installer

How I used SigNoz

Traces

Each span carries custom attributes beyond the defaults — token counts,
latency in seconds, an estimated cost, the severity level the agent
assigned, and even a simple heuristic flag for potential hallucination
(whether the final summary references something that was never in the
logs or runbook). Opening a trace in SigNoz's flame graph view immediately
shows where the time went — in my case, the two LLM calls consistently
took 10-15 seconds each, while all three tool calls combined took under a
second. That's not obvious from reading code; it's obvious from a trace.

Dashboards

I built two dashboards directly from trace data using SigNoz's query
builder:

Latency by Step — average duration grouped by span name, showing exactly which part of the agent's pipeline is the bottleneck
Severity Distribution — count of incidents grouped by the severity the agent assigned, useful for spotting patterns across many runs

Alerts

I set up a threshold alert on the planning LLM call: if agent.llm.plan
takes longer than 15 seconds on average, it fires. This is the kind of
thing you'd actually want in production — a way to know your agent is
degrading before someone notices the user-facing symptom.

What I learned

The most interesting finding, honestly, wasn't about SigNoz — it was
about my own agent. Once I could see the trace breakdown, it became
obvious that essentially all the latency in this pipeline comes from the
two LLM calls, not the tool calls. That's an unglamorous but important
insight: if I wanted to optimize this agent, the tool calls are not
where I'd spend my time.

That's the whole pitch for agent observability — it turns "the agent
felt slow" into "the agent's planning step specifically took 12 seconds,
here's the trace, here's the token count, here's the cost." You can't
have that conversation without instrumentation.

Try it yourself

Full code, setup instructions, and the Foundry deployment config are on
GitHub: github.com/aadvik93/incident-triage-agent

Built for the Agents of SigNoz
hackathon, Track 01: AI & Agent Observability.

DEV Community: Aadvik Krishna

Tracing Fraud Rings with a Graph: What I Learned Building with FalkorDB

How it works

What I learned

1. The relationships you choose matter

2. PageRank doesn't tell the whole story

3. Database details matter

4. A graph can store investigation outcomes

Limitations and next steps

Building an Incident Triage Agent with Full Observability in SigNoz

The problem: AI agents are black boxes

What I built

Tech stack

How I used SigNoz

Traces

Dashboards

Alerts

What I learned

Try it yourself