Why We Built Agent-Native Fraud Detection

Picture this: a payment comes in at 2:47 AM — $3,200 from a new device in Jakarta, flagged by three rules. An AI agent picks it up in under a second. It calls evaluate_risk and gets back a score of 78 with a SHAP breakdown showing the device fingerprint and velocity pattern drove the decision. The agent cross-references the customer's last five transactions, determines this is a known travel pattern, calls submit_outcome to record the payment as legitimate, and closes the alert. No human woke up. No false positive sat in a queue until morning.

That workflow is what becomes possible when a fraud engine speaks the same protocol as AI agents. We built a native Model Context Protocol (MCP) server into our Fraud Decision Engine — and in this post, we will explain why, what it exposes, and what it means for fraud operations teams.

What Is MCP, and Why Should Banking Teams Care?

Model Context Protocol is an open standard under the Linux Foundation that defines how AI models connect to external tools. Think of it as a universal adapter: instead of building custom integrations for every AI platform, you build one MCP server and every compatible agent — Claude, GPT, Gemini, open-source models, your own internal agents — can use your tools natively.

For banking teams, three things matter:

• No vendor lock-in. Your fraud engine becomes consumable by any AI agent. Switch models, swap orchestration layers, run multiple agents in parallel — the engine does not care.
• Structured tool semantics. Each tool has a defined schema — typed inputs, typed outputs, explicit error states. An agent calling evaluate_risk knows exactly what parameters it needs and what shape the response will take.
• Built-in discovery. An MCP-aware agent can ask the server "what tools do you have?" and get back a machine-readable catalogue. New tools become available to agents automatically — no integration code, no SDK updates.

If you read our earlier post on whether your fraud engine is agent-ready, MCP is the concrete protocol that turns those principles into a shipping integration.

Four Tools, One Server

Our MCP server exposes four tools. Each maps to a core fraud operations workflow.

evaluate_risk

Submit a transaction and get back a risk score with a full SHAP-based explanation — which features contributed, by how much, and in which direction. Agents do not just get a number; they get the reasoning. This is what makes autonomous triage possible.

submit_outcome

Report whether a payment succeeded or failed. This closes the feedback loop that makes the engine smarter over time. When an agent observes a result — approved and settled, declined by the issuer, charged back — it feeds that outcome back into the system. The engine uses these signals to refine scoring models and adjust rule thresholds.

submit_fraud_label

Label an event as fraudulent or legitimate, with multi-source tracking that records who applied the label — human analyst, AI agent, or chargeback processor. The engine tracks provenance of every label, which matters for ML training data quality and regulatory audit trails.

check_health

Verify that the engine is up and responding. Simple, but essential for autonomous workflows. Health checks let agents implement graceful degradation — fall back to a queue, alert a human, or retry with backoff — instead of failing silently.

Transports and Security

We ship two transports: stdio for development (local process, zero network config, fast iteration) and HTTP for production (network service behind your load balancers, scaling independently of the agent layer). The same tool definitions work identically in both environments.

Security uses JWT + HMAC. JWT handles identity — the agent presents a signed token with its permissions and scope. HMAC handles integrity — every request body is signed and verified before processing. For on-premise deployments, which is how most Southeast Asian banks prefer to run fraud infrastructure, both the agent and the MCP server sit inside the bank's network perimeter. JWT and HMAC provide defence in depth even when the network is trusted.

The Vision: Autonomous Fraud Investigation

Today's fraud teams operate linearly: engine scores, analyst reviews, analyst decides, analyst labels, ML team retrains. Every step involves a human, and every handoff introduces latency — hours to days between alert and label.

With an agent-native engine, the workflow becomes a loop:

1. Agent calls evaluate_risk and reads the SHAP explanation.
2. Agent cross-references customer history, velocity patterns, and known fraud typologies.
3. For clear cases, the agent calls submit_fraud_label and closes the alert.
4. For edge cases, the agent escalates with a structured summary of what it found and why it could not decide.
5. The human resolves the edge case. The label flows back into the engine immediately.

The result: humans focus on the 15-20% of cases that genuinely require judgement. The other 80% are handled at machine speed with full audit trails. Labels flow in real time, not weekly batch jobs. Scoring models improve continuously, not quarterly.

Why Native MCP, Not a Wrapper

We could have wrapped a REST API with an MCP adapter. We chose to build MCP as a first-class integration point in the engine itself. The difference: no translation layer adding latency or losing type fidelity, tool schemas generated from the same code that implements the tools, and no adapter to fall out of sync when the API evolves.

We believe our Fraud Decision Engine is among the first fraud engines with native MCP support. The protocol is still early — adopted rapidly, but not yet ubiquitous in financial services. Banks that adopt agent-native fraud infrastructure now are positioning themselves ahead of the curve, not chasing it.

Run-True Decision's Fraud Decision Engine ships with a native MCP server — 4 tools, JWT+HMAC auth, stdio and HTTP transports. Talk to us about agent-native fraud infrastructure.