Fraud & Risk Add-on for Agentic Payments
AI agents now initiate payments, payouts, and transfers. Fraud controls built on human behavioral signals, page navigation, form-fill behavior, and device fingerprints assume a human at the keyboard; when an authorized agent transacts, those layers have nothing to read. What matters instead is whether this agent, under this mandate, is allowed to move this money right now, and the earliest point those signals exist is the runtime enforcement layer.
The Fraud & Risk Add-on for Agentic Payments evaluates agent-initiated transactions inline, at the point where the agent acts: deterministic controls that block or escalate, advisory risk scoring escalated for human review, and audit evidence in the compliance exports regulated teams already use. See the product page for the commercial summary; this section is the technical documentation.
The Fraud & Risk Add-on for Agentic Payments is a separately priced add-on to AxonFlow Enterprise. It is not included in the base Enterprise license, the Evaluation tier, or the source-available Community edition. It requires platform v9.18.0 or later and is currently available through the early-access program.
Two layers, two kinds of authority
The add-on is built as two layers with deliberately different authority, because a sanctions decision is never a probability while a fraud likelihood always is:
- A deterministic policy layer runs in-process in the AxonFlow enforcement path and fails closed. It can deny outright. Its controls are prohibited-geography blocks, a high-value amount cap, payment tool authorization gates, restricted merchant-category blocks, structuring and velocity and exposure step-ups, and typed protocol-integrity validation of the transaction context. Every policy documents the public source it was authored from: FATF statements and typologies, OFAC public sanctions programs, FFIEC examination guidance, and OWASP security categories for LLM applications. The full inventory is the FinCrime Policy Pack reference.
- An advisory risk scoring layer runs as a separate service inside your deployment. Scores above the configured threshold route decision-API transactions to human review through the approval queue; on tool-call planes the score is recorded as an attributed detection. There is no path where the model alone denies or approves a transaction, and if the scoring service is unreachable or slow, the decision proceeds on deterministic controls alone with the degradation stamped on the audit record. Posture, verdict mapping, and honestly labeled model metrics are on the advisory risk scoring page.
The decision path does not depend on any LLM provider: enforcement works for traffic that never touches a model.
How a transaction reaches the controls
Callers attach two documented context objects, fincrime_transaction and fincrime_cohort, to a decision request or an MCP tool call. All fields are optional, requests without the objects get no context-derived evaluation (the pack's patterns still scan request statements, which is how payment phrasings are governed either way), and a present-but-malformed context does not pass silently: it steps up as a protocol-integrity detection on the decision API and is recorded as an attributed detection on the MCP planes. The transaction context guide is the integration reference, including the per-plane outcome semantics: pause-for-approval applies on the decision API, while on tool-call planes detections are recorded as attributed audit evidence and blocks still deny.
Evidence where your auditors already look
The add-on writes no side-channel logs. Every block, step-up, and score is a standard AxonFlow decision record with policy attribution: the policy that fired, the enforcement plane, the decision identifier, and for scored transactions a structured risk score with the threshold applied, the top contributing features, and the model version. These records appear in the audit surface read by the platform's OJK, SEBI, and EU AI Act compliance exports without extra integration; see audit logging and evidence export. The RBI export reads its own domain-specific tables and does not include these detections today.
Step-ups on the decision API create approval queue entries carrying oversight metadata, including EU AI Act Article 14 human-oversight context and AML and CFT review context, so reviewers and auditors see why a transaction was held, not just that it was.
What the add-on does not do
It does not replace your transaction monitoring, screening, or case management systems. Those keep doing their jobs. The add-on governs the layer above them: whether an AI agent is allowed to initiate a transaction at all, under what mandate, and with what human oversight. It closes the gap those systems were never built to see. The FAQ answers the questions a risk or security team should ask, including model posture and data handling.
In this section
| Page | What it answers |
|---|---|
| Transaction context guide | How do I attach transaction context to requests, and what happens per plane? |
| FinCrime Policy Pack reference | What does each deterministic policy do, and how do I tune it? |
| Advisory risk scoring | What does the scoring layer do, what does it record, and what are its honest metrics? |
| Enablement and deployment | How is the add-on enabled today, and what is planned for packaged delivery? |
| FAQ | The straight answers: model posture, data handling, what it replaces. |
