A Fraud Investigation Agent

We Built Tark: A Fraud Investigation Agent on TigerGraph

For Hacker House Goa 2026, we wanted to build an agent that would answer the question:

What should happen after a suspicious transaction has been flagged?

A fraud score from a single transaction isn't all that useful to an investigator. They may want to take a closer look at the customer's transaction history, see if there are any other cards or devices associated with this customer, look at transaction bursts, small authorizations that happened beforehand and so on.

We've built Tark to do exactly that.

What is Tark?

Tark begins with a transaction and investigates the relations and activity around it with TigerGraph.

It gathers evidence from the graph and uses that evidence to update the fraud assessment of the transaction.

We didn't want to ask an LLM to decide if a transaction is fraudulent. We wanted to ground the decision in evidence, and keep track of what has been investigated.

Why TigerGraph?

Fraud rarely happens in isolation.

A transaction may look innocent on its own, but it could be part of a larger pattern.

For example, the same device could be used across multiple cards, or a card could have had a series of small transactions before a larger one.

This is where TigerGraph comes in handy, since we can use GSQL to investigate relations between these different entities.

We have queries for devices associated with transactions, activity around a particular point in time, transaction velocity and similar historical cases.

We also write completed investigations back into TigerGraph so that previous investigations can provide context for future ones.

Scope Creep Decider

One of the more interesting problems we had while building Tark was figuring out what to investigate next.

There are always several possible lines of investigation at any given time, and we didn't want to brute-force all of them.

We've built an Evidence Compass based on Expected Value of Information (EVOI).

The approach is quite simple: we estimate how much uncertainty a particular investigation could reduce, and compare it to the cost of performing that investigation.

Tark can then use this to prioritize investigations that would provide useful information and skip ones that are unlikely to affect the current assessment.

This allowed us to make the decision to investigate further based on evidence we were missing, rather than simply using all available tools.

Investigating Fraud: Keeping the Decider Honest

Evidence is stored in an Evidence Ledger and used to update the current fraud assessment using Bayesian log-odds.

The final decision then goes through a deterministic policy layer; this is important, as a high probability of fraud doesn't necessarily mean that a card should be blocked.

The final action also depends on the evidence, evidence coverage, uncertainty, policy and whether human approval is required.

The LLM is used for explanation and reporting grounded in evidence, but it cannot modify the evidence, fraud probability or policy decision.

Learning From Previous Cases

Tark can use the graph to find previous investigations that could be relevant to a current case and use those as context.

There is an important distinction to make here: while previous investigations can help us understand what might be worth looking at, we don't consider evidence from an old case as evidence for the current transaction.

The current decision has to be supported by evidence gathered from the current investigation.

The distinction became important while building the system, since we wanted historical cases to be useful without being able to subtly influence the current fraud probability.

What We Learned

The biggest lesson we've learned while building Tark is that fraud investigation is more of a process than a classification problem.

The graph allows us to find relations between different parts of a transaction that we might miss by simply looking at the transaction.

EVOI gave us a way to formalize the value of gathering more evidence rather than simply running every possible check, and making the LLM separate from the main decision loop made things much easier to reason about and debug.

With more time, we'd like to take Tark further with real-time transaction investigation, better analyst workflows and more ways of finding new patterns of fraudulent behaviour in the graph.

The main idea behind Tark, however, will remain the same:

Investigate the transaction, don't just classify it.