MCP for Transaction Monitoring: Real-Time Fraud Rules via AI Agents

Transaction Monitoring is a control that never sleeps. Every payment, transfer, and top-up has to be evaluated against your rules in real time, the flags have to be triaged, the genuine risks have to become cases, and some of those cases have to become a Suspicious Activity Report (SAR). It is high-volume, procedural, and evidence-driven work — the kind that an AI agent can move through quickly when it has a dependable set of tools to call. The Didit Model Context Protocol (MCP) server exposes the whole Transaction Monitoring lifecycle as tools an agent can invoke in plain language, from installing a rule bundle to closing out a remediation loop.

This post walks the full arc: connect a client, install and backtest a rule bundle, triage flagged transactions, open cases, file a SAR, and run the AWAITING_USER auto-remediation loop.

Key takeaways

• Didit's MCP server puts Transaction Monitoring — part of its 130+ tools across 11 categories — behind natural-language commands, so an agent can install rules, triage flags, and manage cases in one conversation.
• Transaction Monitoring runs a real-time rule engine with 11 seeded rule bundles across fiat and crypto, at $0.02 per transaction.
• Case management and the SAR workflow are built in, so a flagged transaction can travel from alert to filed report without leaving the platform.
• The AWAITING_USER state drives an auto-remediation loop: when a transaction needs more information from the customer, the system pauses, collects it, and resumes — and an agent can orchestrate that end to end.
• Authentication is OAuth 2.1 with Proof Key for Code Exchange (PKCE) — "Log in with Didit," no Application Programming Interface (API) key for the hosted server, scoped to your console role.
• You get 500 free checks per month, sub-2-second responses, and the MCP layer itself is free — you pay $0.02 per transaction only for what you monitor.

Why Transaction Monitoring suits an agent

Monitoring work is a sequence of well-defined decisions. Did this transaction break a rule? Is the flag a real concern or expected behavior? Does it warrant a case? Does the case warrant a SAR? Each step reads structured evidence and produces a documented outcome — the shape of task an AI agent handles reliably when the underlying platform does the detection. The agent is not inventing risk logic; it is orchestrating a real-time rule engine, reading its output, and carrying each item to its correct next state, with a human approving the consequential moves.

Didit's Transaction Monitoring module provides that engine: real-time evaluation, 11 seeded rule bundles covering common fiat and crypto typologies, velocity aggregations, case management, and a SAR workflow. Over MCP, all of it becomes callable in a sentence.

Connecting your agent to the MCP server

The server lives at https://mcp.didit.me/mcp over Streamable HTTP — hosted, or self-hosted from the open-source repository under the MIT license. Authentication is OAuth 2.1 with PKCE: a "Log in with Didit" prompt on first connect, no API key to paste for the hosted endpoint, and the agent inherits your console role through the didit:management and didit:verification scopes. It can only act where your account already can.

Add it to Claude Code in one line, then verify with /mcp:

claude mcp add --transport http didit https://mcp.didit.me/mcp

Claude Desktop, Cursor, VS Code, Windsurf, and Zed connect through a short JSON config pointing at the same URL. ChatGPT Developer Mode can attach through OpenAI's beta MCP support, which is still early, so treat it as experimental. Full setup details are in the MCP overview docs.

Installing and backtesting a rule bundle

You do not start from a blank rule set. Ask the agent to install one of the 11 seeded bundles that matches your risk profile:

"Install the high-risk-jurisdiction rule bundle for our fiat payment flows."

The agent activates the bundle through the monitoring tools and reports which rules it added. Before those rules run live, you want to know how they would have behaved on real history — a bundle that would have flagged a third of last month's legitimate volume needs tuning before it touches production. So backtest it:

"Backtest that bundle against the last 90 days of transactions and tell me how many would have been flagged and the likely false-positive rate."

The agent runs the bundle over historical data and returns the flag count, the distribution across rules, and where the noise concentrates. You iterate — tightening a velocity threshold, narrowing a jurisdiction list — until the signal-to-noise ratio is one your team can actually work.

Triaging flags and opening cases

Once the bundle is live at $0.02 per transaction, flags arrive in real time. Triage is the daily grind, and it is where an agent earns its place. Ask it to summarize the queue:

"Show me today's flagged transactions grouped by rule, and tell me which look like genuine risk versus expected customer behavior."

The agent reads each flag with its context — amount, counterparty, velocity pattern, the rule that fired — and sorts them into likely-genuine and likely-benign, explaining its reasoning for the ones that matter. For the transactions that warrant a closer look, it opens cases:

"Open a case for the three structuring-pattern flags on account 4471 and attach the triggering transactions."

Case management holds the evidence, the timeline, and the analyst notes in one place, so the record of the investigation builds itself as the agent works.

Filing a SAR

When a case crosses the threshold from suspicious to reportable, the SAR workflow takes over. The agent that investigated the case can draft the report from the evidence already attached:

"Draft a SAR for the structuring case on account 4471, summarizing the pattern, the transactions involved, and the timeline."

The agent assembles the narrative from the case record — what was observed, which transactions, over what period, why it meets the suspicious-activity bar — and presents it for review. A human always approves and files; the agent removes the blank-page problem and makes sure nothing in the case evidence is left out. Because the SAR is built from the same case the agent has been managing, the report is consistent with the underlying record rather than a separate retelling.

Running the AWAITING_USER remediation loop

Not every flag is fraud — sometimes a transaction just needs more information from the customer before it can clear. That is what the AWAITING_USER state is for. When a transaction lands there, the platform pauses it, requests the missing detail from the customer, and resumes automatically once the customer responds. An agent can drive the whole loop:

"Put the pending large-transfer flag into AWAITING_USER, request source-of-funds documentation from the customer, and resume monitoring when they reply."

The transaction sits in a controlled pending state instead of being blocked outright or waved through. When the customer supplies the documentation, the flow continues; if they do not, the item stays surfaced for review. This auto-remediation loop keeps legitimate customers moving while holding genuinely unresolved transactions, and it means your agent can resolve a large slice of flags without a human touching every one.

Start free

Transaction Monitoring over MCP means an analyst describes the control — install this bundle, backtest it, triage the queue, open a case, draft the SAR, run the remediation loop — and the agent carries each transaction to its correct next state with a human on the consequential decisions. Didit is used by 1,500+ companies, is backed by $7.5M in funding, is a Y Combinator W26 company, is profitable, and covers 220+ countries and territories. Start free: 500 checks per month at no cost, the MCP layer free, and $0.02 per transaction beyond the free tier. Read the MCP overview, browse the developer hub, or self-host the open-source server and connect your agent today.