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 deny or hold for approval, an advisory risk score that holds 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. This section describes platform v11.1.0. The add-on 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, the FinCrime Policy Pack, runs in-process as a typed policy document the v11 decision engine evaluates. It can deny outright. Its controls are prohibited-geography blocks, a high-value amount cap, a payment tool authorization gate, restricted merchant-category blocks, and payment-execution, structuring, velocity, exposure, corridor, and card-not-present holds for approval. 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. Its score is a fact the pack's score control reads: at or above the pack's threshold, the transaction is held as a pending approval on the decision API and the MCP request pass alike. 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 the deterministic controls alone, with the reason there was no score recorded on the decision. 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, and requests without the objects get no context-derived evaluation (two of the pack's controls match request statements, which is how payment phrasings are governed either way). Nothing validates the objects on v11.1.0, so a malformed value simply may not match. The transaction context guide is the integration reference, including the per-plane outcome semantics: a deny control denies, and a hold control holds the call as a pending approval, on the decision API and on the MCP request pass.
Evidence where your auditors already look
The add-on writes no side-channel logs. Every denial and hold is a standard AxonFlow decision record with policy attribution: the controls that applied, the enforcement plane, and the decision identifier. A decision the score control reads also records policy_details.fincrime_risk_score: whether the transaction was scored and, if not, why, and for a scored transaction the score, the thresholds it was compared against, 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.
A hold creates a pending approval that a person approves or rejects on the portal's Approvals page, so reviewers and auditors see which control held a transaction, not just that it was held.
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 control do, and what can my organization change? |
| 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 on v11.1.0, and what is planned for packaged delivery? |
| FAQ | The straight answers: model posture, data handling, what it replaces. |
