Securing the Transaction Network: The ML Model, the Agent Pass, and the Graph

1. The Bank and the Money-Flow Network

Start from the bank’s side of the counter. You operate a transactional network that clears hundreds of thousands of transfers, and you already run a machine learning model that scores every one of them. The open question is no longer whether the model can flag suspicious activity. It is what happens after an alert fires: how much of the surrounding network a reviewer can actually see, and how far the evidence behind a decision can be trusted.

New engineers tend to arrive with one straightforward rule: “Why can’t we just write an SQL query that flags transactions greater than $10,000?” Sophisticated bad actors anticipate exactly that query. Real-world money laundering rarely takes the form of a single million-dollar wire from an illicit entity into a luxury asset account. Illicit syndicates fracture capital across dozens of intermediary conduit accounts, stagger timestamps across banking holidays, and calibrate individual amounts to sit just beneath regulatory thresholds.

Tripwire is organized around that reality as a layered system, not a single oracle:

• Layer one, the model: a gradient-boosted model scores every replayed transaction, and deterministic policy routes each score to a simulated block, the review queue, or straight-through processing.
• Layer two, the agent pass: a bounded LLM agent picks up flagged reviews and reads the surrounding activity in context, instead of guessing from the aggregates the model was trained to carry.
• The graph underneath: accounts and transfers live in FalkorDB as first-class nodes, so the agent’s context is retrieved evidence rather than model memory.

This guide follows that layered path in order: what the model can and cannot do (section 2), what changes when an agent pass is added on top (section 3), and how the agent reads the transaction graph through bounded tools (section 4). The remaining sections cover the AML patterns the graph exposes, the full pipeline, the analyst workbench, and further reading.

2. Layer One: The Model That Scores the Stream

The first layer is deliberately boring technology, because it has to run across the whole stream. Tripwire pairs graph-derived features with a high-performance gradient boosting detection engine. During the model selection tournament (recorded in the Iteration 2 benchmarks), three candidate architectures were evaluated against the baseline:

The Three Deterministic Routes

Scores produced by the Champion model are mapped into three operational lanes:

One limitation of this layer is structural, not a tuning problem. Every feature the model consumes was designed in advance, and many of them are aggregates: counts, velocities, ratios, balances. That compresses a sequence of related transfers into a handful of numbers, and a pattern that only exists in the shape of the activity, such as a fan-out ring or a pass-through chain, survives only as a blur. The model can rank the stream; it cannot follow a funds path, and it cannot explain itself to a reviewer. That gap is where the second layer comes in.

3. Layer Two: The Agent Pass on Flagged Reviews

To increase security, the bank adds a second pass. Instead of asking one model to carry the whole decision, Tripwire runs an LLM agent downstream of the detector, over the transactions the model already flagged. The agent’s job is narrow and explicit: look at the alert in the context of the surrounding network, and say whether the evidence supports escalation.

The pass is opt-in per investigation. With the agent disabled, a request returns the deterministic report: fast, free, and evidence-bound. With use_llm enabled and a provider configured, the same evidence set feeds a Gemini tool-calling agent. It selects among the approved graph tools, drafts a hypothesis with a risk level and reasoning, and the draft then has to survive a deterministic verifier. The provider is allowed to fail; the review is not.

The Four Rules That Keep the Pass Bounded

What reaches the analyst is only what survived verification. A verified draft reads like a review, not a lecture: a risk level from 1 to 5, a hypothesis, supporting and counter-evidence transaction IDs, and one to six reasoning points, each tied to the evidence IDs that back it. If any cited ID, amount, currency, timestamp, or path is not in the records the tools actually returned, the draft is rejected and the deterministic report stands in its place.

4. What the Agent Reads: The Graph

The agent pass is only as good as the context it can reach, and in Tripwire that context is the money-flow graph itself. The bank’s ledger was always a sequence of transfers between accounts; the design decision is how to store it. Modeling transactions as edges between accounts (e.g., (:Account)-[:TRANSFERRED]->(:Account)) is a common pitfall. When multiple transfers occur between the same two accounts over time, edges accumulate arrays of timestamps and amounts, and multi-hop Cypher queries become slower and less precise.

Tripwire enforces a fundamental architectural invariant: First-Class Transactions.

This modeling choice delivers three major operational advantages:

• Stable Transaction IDs: Every transfer possesses a permanent node ID, allowing deterministic joins between machine learning inference artifacts and graph topology.
• Bi-directional Traversal: An investigator can effortlessly trace upstream sources of funds (SENT) or downstream dispersion (RECEIVED) in a single Cypher hop.
• Zero Multi-Edge Overhead: FalkorDB stores each transaction as an independent entity in sparse matrix memory, keeping neighbor degree operations O(1).

When a reviewer or the agent asks a question, it is answered by bounded Cypher executed against FalkorDB, a high-throughput graph database engine built upon Redis that translates queries into sparse-matrix operations via GraphBLAS. The agent reaches it through the same three approved read-only tools every time:

MATCH path = (origin:Account)-[:SENT]->(tx:Transaction)-[:RECEIVED]->(destination:Account)
WHERE tx.id = $transaction_id
OPTIONAL MATCH (destination)-[:SENT]->(downstream_tx:Transaction)-[:RECEIVED]->(second_hop:Account)
WHERE downstream_tx.timestamp >= tx.timestamp 
  AND downstream_tx.timestamp <= tx.timestamp + $time_window
RETURN path, downstream_tx, second_hop LIMIT $result_limit;

In production sweeps against 998,021 transactions and 354,660 accounts, FalkorDB delivers:

• Trace Funds P95: 6.20 milliseconds
• Counterparty Inspection P95: 2.33 milliseconds
• Pass-Through Detection P95: 1.98 milliseconds

5. The AML Patterns the Graph Exposes

In the synthetic IBM AMLworld dataset, laundering syndicates repeat a small set of structural behaviors. Each is awkward to express as a predefined feature and natural to express as a traversal, which is why the second layer works on a graph in the first place:

MATCH (origin:Account {id: $source_id})-[:SENT]->(tx:Transaction)-[:RECEIVED]->(mule:Account)
WHERE tx.timestamp >= $window_start AND tx.timestamp <= $window_end
WITH origin, count(DISTINCT mule) AS fan_out_degree, collect(tx.amount) AS tranche_amounts
WHERE fan_out_degree >= 5
RETURN origin.id, fan_out_degree, tranche_amounts

Notice how each typology is characterized by a distinctive topological footprint: fan-outs create star graphs, structuring creates inbound bottlenecks, pass-throughs form linear conduit chains, and round-tripping forms directed cycles.

6. The Full Pipeline, End to End

Putting the layers in order: the replay stream feeds a point-in-time feature store, the model scores every transaction into deterministic routes, the agent pass picks up the flagged reviews, the graph supplies the evidence, and the analyst owns the conclusion.

The pipeline is engineered for sub-second analyst responsiveness. While the model scores over 76,000 transactions per second, graph evidence traversal completes in under 7ms on the demo slice, so the wait a reviewer actually notices is the agent pass, never the database.

7. The Analyst Workbench Guide

Now that you understand the underlying architecture, here is how to navigate the Tripwire workbench interface efficiently:

8. Technical Glossary & Key Terms

A searchable reference guide explaining the core vocabulary across machine learning, graph databases, and financial crime compliance:

9. Further Reading: Field Notes

The layered design in this guide is not unique to Tripwire; banks, exchanges, and payment processors are converging on the same division of labor. The closest public account is Coinbase’s three-part series on their Onramp fraud agent, which documents the build, the evaluation method, and the post-training work in unusual detail:

One scope note before you cite anything on this page: Tripwire is a synthetic IBM AMLworld workbench, not a production deployment and not a Coinbase replica. The shared lesson is about the shape of the system, a model for coverage, an agent for context, and deterministic code for authority. The benchmark numbers in this guide describe the synthetic replay only and do not establish real-world AML effectiveness.