AI agents now initiate payments, payouts, and transfers. Fraud controls built on human behavioral signals assume a human at the keyboard. AxonFlow 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.
The behavioral and device-signal layers of established fraud stacks read human presence: page navigation, form-fill behavior, device fingerprints. 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. The earliest point those signals exist is the runtime enforcement layer.
An agent fills no forms and moves no mouse. Behavioral fraud signals built on human interaction patterns have nothing to read when an authorized agent initiates the transaction.
Injected instructions in an invoice or vendor document can steer an authorized agent into changing a beneficiary or overpaying. The transaction looks legitimate to downstream systems because the agent really is authorized. The layer that sees the tool call is the first place it can be stopped.
Regulated teams need decision records: which control fired, on which transaction, with what outcome, and who reviewed it. Detection without retained, attributable evidence does not survive an examination.
The deterministic layer runs in-process in the AxonFlow enforcement path. A matched control denies ahead of any advisory signal, a control the engine cannot evaluate refuses the request rather than letting it pass, and a hold your enforcement point cannot carry out is refused rather than waved through. Its policies are authored from public sources, and each policy documents the public typology or guidance it is based on: FATF statements and typologies, OFAC public sanctions programs, FFIEC examination guidance, and OWASP security categories for LLM applications.
Transactions with an endpoint in a prohibited jurisdiction are blocked outright, using lists built from public OFAC comprehensive sanctions programs and FATF call-for-action statements. Transactions to jurisdictions under FATF increased monitoring, snapshotted when the pack version was authored, are escalated for review rather than passing silently. List-derived policies are versioned pack content: list updates arrive as a new pack version, not as a policy edit your team authors.
Block Step-upA hard cap on single-transaction amounts, with step-ups for high-value card-not-present transactions. Velocity, frequency, and cumulative exposure step-ups are evaluated against transaction cohort data supplied with each request, so bursts and rapid-movement behavior is escalated for review. Requests that carry no cohort data do not receive these step-ups. Nothing validates the context: a malformed value is matched as written and may simply not match the control you expect, so validate your producer against the documented field formats before rollout.
Block Step-upSub-threshold transfers in the structuring band are flagged and escalated for review, based on public FATF money laundering typologies. Staying under a reporting threshold is itself the signal.
Step-upAgent attempts to modify payment routing details, such as beneficiary, account, or routing identifiers, are blocked at the tool-call level. This is a runtime defense against prompt injection and confused-deputy attacks, mapped to the OWASP Top 10 categories for LLM applications.
BlockTransactions in restricted merchant categories are blocked using a versioned merchant-category list built from public card-network and FinCEN guidance on high-risk merchant categories. The list is pack content: a deployment installs a pack version, and your organization can replace the control under the control's own id to change what happens when the list matches, but not what it matches. List changes arrive as new pack versions.
BlockAgent-phrased payment execution requests are held for human approval before they proceed, matched on the request statement rather than the transaction context, so they are governed even on requests that carry none. The deterministic controls apply whether or not a risk score is available.
HoldThe add-on includes an ML risk scoring layer that augments the deterministic controls. It is advisory by design: the scoring service returns a number, one control in the policy pack reads it as a fact about the request, and a score at or above the threshold holds the transaction for human review. The deterministic layer keeps its authority regardless of what the model says.
The add-on writes no side-channel logs. Every block, step-up, and score lands in the same audit surface as AxonFlow's regulatory exports, with policy attribution on each record.
Detections are written as standard AxonFlow decision records: the policy that fired, the enforcement plane, the decision identifier, and for scored transactions the structured risk score. They appear in the audit surface read by the platform's OJK, SEBI, and EU AI Act compliance exports without any extra integration.
Audit Trail Evidence ExportA hold on the decision API or the MCP request routes creates a pending approval in AxonFlow's approval queue, retrievable through the platform's HITL API and decided by a person on the portal's Approvals page. The decision record names the control that held the transaction, so reviewers and auditors see why it was held, not just that it was.
HITL Pending ApprovalEach deterministic policy documents the public source it was authored from: FATF typologies and jurisdiction statements, OFAC public sanctions programs, FFIEC BSA and AML examination guidance, and OWASP LLM security categories. Your compliance team can trace every control to its basis.
ProvenanceFraud & Risk Add-on is delivered as an add-on to AxonFlow Enterprise. It enforces at the point where agents act, on direct decision requests and on agent tool calls, before a transaction reaches your payment systems.
The same enforcement point covers agent-initiated money movement across industries.
Agent-initiated disbursements and merchant payouts are screened inline. Structuring-band transfers and velocity bursts step up for review, and detections land in regulator-ready export surfaces.
Payment operations copilots are gated by tool authorization, with velocity and exposure step-ups held for a person's review, producing audit evidence your risk committee can stand behind.
Claims payout agents run under payout velocity step-ups and beneficiary-change gates. Injected instructions in claims documents that try to redirect payouts are blocked at the tool call when they touch payment routing fields.
Autonomous checkout agents operate under restricted merchant-category blocks, high-value card-not-present step-ups, and velocity step-ups, as agent-driven commerce protocols reach mainstream payment rails.
Invoice-processing agents are a target for confused-deputy attacks: instructions embedded in a vendor document steering a beneficiary change or an over-limit payment. Authorization gates and amount caps can stop what document-level scanning misses.
The questions a risk or security team should ask about any fraud product, answered plainly.
No. The model is advisory. It returns a score, and a policy decides what the score means: deterministic policies can block outright, and a score at or above the threshold holds the transaction for human review as a pending approval, on the decision API and the MCP request routes alike. The score can never deny. There is no path where the model alone denies or approves a transaction.
On accuracy: the model is trained on public datasets, there is no public labeled dataset of agent-initiated transaction fraud yet, and we have no agent-traffic training data either. We therefore publish no detection-rate or accuracy claims for agent traffic. The pack's threshold is a starting point chosen on a simulated card-transaction corpus, and its review rate will not hold on your traffic; your organization moves it by publishing a copy of the score control under its own id.
No. Your transaction monitoring, screening, and case management systems keep doing their jobs. This 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.
None through this add-on. Deterministic controls and risk scoring both run inside your deployment. There are no external data enrichment calls and no third-party data sharing. If deployed on AxonFlow's managed service, evaluation happens within your managed deployment under the platform's existing data handling terms.
It is a separately priced add-on on top of AxonFlow Enterprise. Charter partners receive early access and charter pricing. Contact us and we will walk you through it against your deployment size.
No. The AxonFlow platform is source-available under BSL 1.1, and the Community edition remains fully usable for building and testing governed agents. Fraud & Risk Add-on is a commercial add-on to AxonFlow Enterprise.
Every detection is a standard AxonFlow decision record with policy attribution, written to the same audit surface the platform's OJK, SEBI, and EU AI Act compliance exports read. Auditors see the control, the transaction, the outcome, and, where a hold was reviewed, the reviewer.
The add-on builds on AxonFlow Enterprise's enforcement, approval, and evidence machinery. Start with the platform documentation.
Fraud & Risk Add-on is a separately priced add-on to AxonFlow Enterprise. Charter partners receive early access and charter pricing, and work directly with our team on threshold calibration.
