All agents

Fraud Detection Agent

An always-on risk analyst that scores transactions 0–100, explains each anomaly, and recommends allow / review / block before fraud costs you.

View in marketplace Open dashboard

The Fraud Detection Agent reviews transactions and account activity, assigns each a 0–100 risk score with written reasoning, and recommends an action — allow, review, or block — against the auto-block threshold you set. It runs on demand from the dashboard or in real time via webhook, and writes an auditable risk report for every run. It recommends; whether a payment is actually blocked depends on your connected payment tooling and threshold.

What it does

Built for e-commerce, marketplaces, and fintech/payments teams, this agent acts as a consistent, tireless fraud triage layer. You feed it transaction or activity data (pasted for test runs, or sent to its webhook in production); it analyzes for anomalies — velocity patterns like rapid-fire purchases, mismatched-BIN cards, new accounts, freight-forwarder shipping addresses — and produces a risk score, reasoning, and a recommended action for each event. Its system prompt fixes its role as a fraud/risk analyst, and it is instructed to call record_output once per run with the finished risk report.

Operationally it is a short, bounded agent: it runs at most 4 turns and has access to two tools — http_request (to call a public https API or webhook, e.g. to look up an enrichment endpoint or post a verdict to your own system) and record_output (to save the deliverable). The recommendation, not enforcement, is the product: every decision is logged with reasoning so you get a clean compliance trail, and the agent surfaces a one-line summary on the dashboard feed with the full markdown report saved to the run.

How it works

Your Business
1
Ingest
Reads the transaction/activity payload — pasted into the Transactions field for a test run, or the body sent to the deployment's webhook for live events.
2
Score anomalies
As a fraud/risk analyst it evaluates velocity, BIN mismatches, account age, shipping-address risk and similar patterns, assigning each event a 0–100 risk score with written reasoning.
3
Apply threshold
Weighs each score against your Auto-block threshold (default 80) to decide between allow, review, and block.
4
Recommend action
Produces an allow / review / block recommendation per event, with the reasoning that justifies it. Enforcement depends on your connected payment tooling.
5
Record & alert
Calls record_output once to save the full risk report (markdown, stored in the R2 assets bucket) plus a one-line dashboard summary; optionally uses http_request to push the verdict to your own https endpoint/webhook.
Outcomes delivered

Setting it up — owner / admin

  1. 1
    Deploy from the marketplace
    Subscribe to the Fraud Detection Agent, then open its deployment at /dashboard/agents/[id], which exposes the agent header, a way to run it, the config panel, and execution history.
  2. 2
    Fill the config fields
    Set the two real fields: 'Transactions / activity (for test runs)' (a textarea to paste or describe sample transaction data) and 'Auto-block threshold (0-100)' (e.g. 80 — the score above which to recommend block), then save the configuration.
  3. 3
    Connect tools / sources
    The agent itself ships with only http_request and record_output. To feed live data, point your transaction source at the deployment's webhook, and use http_request to post verdicts to an alert channel or your own system over https. No OAuth is required for the core flow.
  4. 4
    Use the realtime trigger
    Triggering is realtime / event-driven: send your transaction payload to the deployment's webhook to start a run with that body as input. There is no cron schedule field for this agent (its configSchema has no schedule field) — it runs on new events or on demand.
  5. 5
    Do the first run
    Paste sample activity into the Transactions field (the built-in default example is 3 card payments of $2,400 each within 2 minutes from a new account on different BINs, shipping to a freight-forwarder address), run it, and review the execution history. Confirm the risk score, reasoning, and recommended action look right before pointing live traffic at the webhook.

Using it day to day — your team

  1. 1
    Submit activity for review
    Day to day, transactions flow to the agent via its webhook, or an analyst pastes a batch into the Transactions field and runs it from /dashboard/agents/[id].
  2. 2
    Read the risk verdict
    Each run produces a risk report — e.g. 'Risk: 88/100 (BLOCK). 3 × $2,400 in 2 min, new account, mismatched BINs, freight-forwarder address.' The one-line summary appears on the dashboard feed; the full markdown report is saved for the run.
  3. 3
    Act on the recommendation
    Use the allow / review / block recommendation to clear, queue for manual review, or stop a payment in your payment tooling. Events above your threshold are recommended for block.
  4. 4
    Audit the trail
    Every decision is logged with its reasoning and score, alongside the run's status and usage, as an auditable record for compliance and disputes.

Use cases

Real-time triage
Score incoming transactions via the webhook and flag high-risk ones for review or block before they settle.
Velocity checks
Catch rapid-fire purchase bursts and mismatched-BIN patterns — like several large card charges in minutes from a new account.
Compliance logging
Keep a reasoned, auditable record of every allow/review/block decision for disputes and audits.

What to expect

  • A 0–100 risk score with written reasoning for each event
  • An allow / review / block recommendation tied to your threshold
  • A saved markdown risk report per run, with a one-line dashboard summary
  • An auditable decision trail (score and reasoning) recorded for every run

Metrics to watch

  • Run success rate in execution history (failed vs success)
  • Block/review/allow mix relative to your threshold — drift signals you should retune it
  • False-positive rate: flagged transactions later confirmed legitimate on manual review
  • Time-to-verdict per event (the agent is capped at 4 turns)
  • Fraud loss prevented vs good transactions wrongly blocked

FAQ

Does it block transactions automatically?
No — it recommends. It scores each event and recommends allow/review/block; whether a payment is actually blocked depends on your connected payment tooling and the auto-block threshold you set.
How do I send it live transactions?
Triggering is realtime / event-driven via the deployment's webhook — the request body becomes the run's input. You can also paste data and run it on demand for ad-hoc checks.
Is every decision auditable?
Yes. Each run calls record_output once to save the full risk report (a title, a one-line dashboard summary, and the full markdown details), giving you a logged record for every run.
What does it actually have access to?
Two tools: http_request (call a public https API or webhook — it does not send any of your stored credentials, and only https URLs are allowed) and record_output (save the deliverable). Runs are bounded to 4 turns.
What threshold should I set?
The Auto-block threshold defaults to 80; events scoring above it are recommended for block. Start near 80, watch the block/review mix and false positives, and tune from there.