FinCrime Policy Pack Reference
The FinCrime Policy Pack is the policy half of the Fraud & Risk Add-on for Agentic Payments: financial-crime controls for agent-initiated transactions. It ships as a typed policy document that the v11 decision engine evaluates, on the same engine and audit surface as every other policy.
The FinCrime Policy Pack ships with the Fraud & Risk Add-on for Agentic Payments, 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 page describes platform v11.1.0. The add-on is currently available through the early-access program.
Installing the pack
A deployment installs the pack by naming it in AXONFLOW_POLICY_PACKS (AXONFLOW_POLICY_PACKS=fincrime) on the agent; the enablement page covers the setting and the reasons the agent refuses to start. The pack is never written to the legacy policy tables. It composes onto every organization's policy root, and an organization's own document does not remove it.
This is pack version 2, with eleven controls: ten deterministic controls and the advisory risk score control.
Inputs
The transaction-aware controls read the documented fincrime_transaction and fincrime_cohort context objects; the transaction context guide covers the carriers per surface and the serialization the controls match against. Two controls match the request statement instead of the context, so they protect even traffic that supplies no transaction context.
The controls
Each control documents the public typology or guidance it was authored from, so your compliance team can trace every control to its basis. A control's id is what a decision's evaluated_policies names when it applies.
| # | Control id (pack:fincrime: + …) | Outcome | Matches | What it does | Public-source basis |
|---|---|---|---|---|---|
| 1 | fincrime__prohibited__geography__block | Deny | context | Denies a transaction with either endpoint in IR, KP, CU, SY, or MM (alpha-2 or alpha-3 forms, with or without a subdivision suffix) | U.S. Treasury OFAC comprehensive sanctions programs; FATF High-Risk Jurisdictions subject to a Call for Action |
| 2 | fincrime__high__value__amount__cap | Deny | context | Denies amount >= 10000 | BSA currency transaction report threshold, 31 CFR 1010.311 |
| 3 | fincrime__payment__tool__authorization__gate | Deny | statement | Denies agent attempts to change or redirect payment routing details: beneficiary, payee, payout or bank account, routing or account number, IBAN, SWIFT | OWASP Top 10 for LLM Applications: LLM01 Prompt Injection, LLM08 Excessive Agency (confused-deputy defense) |
| 4 | fincrime__payment__execution__stepup | Hold for approval | statement | Holds agent-phrased payment execution (phrasings such as initiate, execute, or send a payment, wire, or payout) | EU AI Act Article 14 human oversight; FFIEC BSA/AML Examination Manual (monitoring of payment initiation) |
| 5 | fincrime__restricted__mcc__block | Deny | context | Denies restricted merchant category codes: 7995 (gambling), 9406 (lotteries), 4829 (money transfer), 6051 (quasi-cash), 6540 (POI funding), 5967 (direct marketing inbound teleservices), 7273 (dating services), 5993 (cigar stores), 6211 (securities brokers) | Card-network public high-brand-risk MCC guidance; FinCEN MSB guidance |
| 6 | fincrime__velocity__frequency__stepup | Hold for approval | context (cohort) | Holds at caller-supplied txn_frequency_1h >= 10 | FFIEC BSA/AML Examination Manual: transaction velocity monitoring |
| 7 | fincrime__structuring__pattern__stepup | Hold for approval | context | Holds sub-threshold transfers in the 3,000 to 9,999 band when payment_type is transfer or wire | FATF money laundering typologies: structuring below the 10,000 reporting threshold |
| 8 | fincrime__cumulative__exposure__stepup | Hold for approval | context (cohort) | Holds at txn_frequency_1h >= 20 when historical_mean_amount is supplied (aggregate-exposure proxy) | FFIEC aggregate exposure monitoring; FATF rapid-movement typologies |
| 9 | fincrime__geo__corridor__stepup | Hold for approval | context | Holds receivers in FATF increased-monitoring jurisdictions (the public grey list, snapshotted at pack authoring) | FATF Jurisdictions under Increased Monitoring |
| 10 | fincrime__cnp__high__value__stepup | Hold for approval | context | Holds card-not-present transactions at or above 5,000 | Federal Reserve payments studies (elevated card-not-present fraud rates) |
| 11 | fincrime__ml__risk__stepup | Hold for approval | risk score | Holds a transaction whose risk score is at or above 0.011591929942369461. A missing score never applies it | Advisory model score; see the scoring page for the threshold's basis and caveats |
The deny controls are typed constraints. The hold controls are mandatory requirements carrying the approval_challenge obligation, so they never deny by themselves.
v10.x had a twelfth, code-backed check, fincrime_mandatory_fields, that stepped up a malformed transaction context. It was removed with the v10 engine, and nothing replaces it in v11.1.0: see validation.
Controls 1, 5, and 9 are built from public lists that change: sanctions programs, FATF statements, and card-network category guidance all move. List updates are delivered as new pack versions; the pack does not phone home for list updates. In particular, the increased-monitoring list in control 9 is a snapshot: verify it against the current FATF statement before relying on it in production. An organization cannot edit a pack list (see below); if the snapshot no longer matches your requirements, raise it with your AxonFlow contact so it is corrected in a pack version.
Where the pack applies, and what each outcome does
The pack applies on POST /api/v1/decide and on the MCP request pass (POST /api/v1/mcp/check-input, POST /mcp/resources/query, POST /mcp/tools/execute, and the MCP server's check_policy tool). It does not apply on the Gateway Mode pre-check path, the Workflow Control Plane, or multi-agent plans.
- Deny. Verdict
denyon the decision API; HTTP403on the MCP routes. - Hold for approval. On an Enterprise deployment licensed for human approval, the call is held as a pending approval: decide answers
verdict: "needs_approval"and the MCP routes answer HTTP403, both with apending_approvalobject. A person approves or rejects it on the portal's Approvals page, and the caller retries the same call naming the approval. The full contract is in Pending approval on MCP and decide. Without the human-approval licence entitlement, a hold is refused with reasonapproval_requiredand nothing is queued.
Three limits to plan around on v11.1.0:
- Who may approve. The hold controls name an approver pool,
fincrime-approvers, but v11.1.0 does not yet enforce it: any person the approval queue admits can approve a pack hold, except the caller who raised it. - Enforcement points that cannot hold. An enforcement point whose PEP capability handshake does not advertise
approval_challengeis refused, not held, when a hold control applies. Advertise the capability to receive holds. See the scoring page for the details. - The AuthZEN evaluation route (
/access/v1/evaluation) does not hold. A hold control that applies there is refused withapproval_required.
The per-surface summary is in the transaction context guide.
The false-positive surface, and how to tune it
The controls match text: the request statement, and the transaction context serialized as JSON. On the MCP planes every parameter value is scanned, not only the fincrime objects. That makes installing the pack a deliberate fail-toward-governance choice that is right for payment-executing agents and not free for mixed-purpose deployments:
- Any statement or parameter that carries the matched shapes applies the control. An
"amount": 15000inside an ordinary order object on an MCP call is denied by the amount cap, and "update the bank account record for customer X" in a CRM statement is denied by the tool authorization gate. - The amount thresholds are currency-agnostic numerics. Deployments transacting in minor units or low-unit-value currencies (cents, IDR, JPY) trip them on routine values. The thresholds are part of the pack's matching and an organization cannot change them (see below), so send amounts in major units. Per-currency caps are planned.
Tuning a control for your organization
The v10 way of tuning, editing the pack's policy rows, is gone: the legacy policy rows are read-only in v11 (a write through the legacy policy routes answers 409 LEGACY_POLICY_WRITE_FROZEN), and the v11 pack's controls never lived there.
In v11 an organization changes a control by publishing a policy under the control's own id in its typed policy document. A policy under a pack control's id replaces the pack's copy of that control for your organization. A policy under a different id replaces nothing: it applies beside the pack's control, so it can only add a denial or a hold.
What a replacement can change differs by control:
- The risk score control compares the score against a number in the policy itself, so your copy can move the threshold up or down. This is how to set an operating point for traffic that differs from the corpus the pack's threshold was chosen on; see the scoring page.
- The ten deterministic controls each read whether the pack's own detector matched. The detector (its pattern, list, and amount) belongs to the pack, so a copy of the control cannot change what matches, only what happens when it does. List and threshold changes arrive as new pack versions.
A replacement applies only where it binds. If your copy's binds_on leaves out a scope the pack's control applies on, the pack's copy still applies on that scope.
Limits on v11.1.0
These are deliberate scoping decisions, stated so you can plan around them. All are planned work, with no dates committed here:
- The velocity and exposure controls read caller-supplied cohort aggregates; requests without cohort data do not receive them. In-platform rolling-window aggregation is planned.
- The amount cap applies to the numeric amount regardless of currency; per-currency caps are planned.
- True pairwise sender-versus-receiver comparison needs richer evaluation than text matching expresses; the pack ships the corridor and card-not-present halves of that class.
- The approver pool is named but not enforced (see above).
- The deterministic controls' patterns, lists, and amounts can be changed only by a new pack version, not per organization.
- Nothing validates the transaction context objects (see validation).
