FinCrime Policy Pack Reference

The FinCrime Policy Pack is the deterministic half of the Fraud & Risk Add-on for Agentic Payments: financial-crime controls for agent-initiated transactions, authored entirely as system policies evaluated by the platform's shared policy engine. There is no new enforcement mechanism to learn; the pack rides the same engine, hierarchy, and audit surface as every other policy.

Enterprise add-on

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. It requires platform v9.18.0 or later and is currently available through the early-access program.

Inputs

Transaction-aware policies read the documented fincrime_transaction and fincrime_cohort context objects; the transaction context guide covers the schema, the per-plane carriers, and the canonical serialization the patterns bind to. Two of the pack's policies bind to the request statement instead of the context, so they protect even traffic that supplies no transaction context.

The policies

Each policy documents the public typology or guidance it was authored from, so your compliance team can trace every control to its basis.

#	Policy id	Action	Binds to	What it does	Public-source basis
1	fincrime_prohibited_geography_block	Block	context	Blocks 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	Block	context	Blocks amount >= 10000	BSA currency transaction report threshold, 31 CFR 1010.311
3	fincrime_payment_tool_authorization_gate	Block	statement	Blocks agent attempts to mutate payment routing details: beneficiary, payee, account, routing, IBAN, SWIFT	OWASP Top 10 for LLM Applications: LLM01 Prompt Injection, LLM08 Excessive Agency (confused-deputy defense)
4	fincrime_payment_execution_stepup	Step-up	statement	Escalates agent-phrased payment execution (phrasings such as initiate, execute, or send a payment, wire, or payout) for human approval	EU AI Act Article 14 human oversight; FFIEC BSA/AML Examination Manual (monitoring of payment initiation)
5	fincrime_restricted_mcc_block	Block	context	Blocks 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). A list-condition policy: edit the list to tune	Card-network public high-brand-risk MCC guidance; FinCEN MSB guidance
6	fincrime_velocity_frequency_stepup	Step-up	context (cohort)	Escalates at caller-supplied txn_frequency_1h >= 10	FFIEC BSA/AML Examination Manual: transaction velocity monitoring
7	fincrime_structuring_pattern_stepup	Step-up	context	Escalates 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	Step-up	context (cohort)	Escalates 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	Step-up	context	Escalates receivers in FATF increased-monitoring jurisdictions (the public grey list, snapshotted at pack authoring). A list-condition policy	FATF Jurisdictions under Increased Monitoring
10	fincrime_cnp_high_value_stepup	Step-up	context	Escalates card-not-present transactions at or above 5,000	Federal Reserve payments studies (elevated card-not-present fraud rates)
11	fincrime_mandatory_fields	Step-up	typed validation	Protocol integrity: a present-but-malformed fincrime context is escalated as unassessable. Implemented as typed validation in the add-on rather than a pattern row, because patterns cannot express type violations	FATF Recommendation 16-adjacent payment-message integrity principle: unassessable transaction data must not pass silently

List policies are versioned content

Policies 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 and applied by your team like any other policy change; the pack does not phone home for list updates. In particular, the increased-monitoring list in policy 9 is a snapshot: verify it against the current FATF statement before relying on it in production, and tune the list to match.

Action semantics per plane

Every pack policy is evaluated by the same shared engine on the decision API and the MCP planes today (see Current limits for the planned surfaces). What the action does follows the platform's existing per-plane contract:

• Block: hard deny on every plane the pack evaluates on. Verdict deny on the decision API, HTTP 403 on the MCP planes.
• Step-up (require_approval): verdict needs_approval plus a pending approval queue entry on the decision API. On the MCP planes a step-up match is a non-blocking, attributed match: the detection lands in the audit record's policy attribution, and the plane's human-decision surface is the session override flow rather than a queue entry.

The full per-plane outcome table, including what typed validation and risk scoring do on each surface, is in the transaction context guide.

The false-positive surface, and how to tune it

The shared engine scans the request statement and every parameter value with every enabled pattern; patterns cannot bind to one named parameter. Seeding this pack is therefore 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 fires the policy. An "amount": 15000 inside an ordinary order object hard-blocks via the amount cap; "update the bank account record for customer X" in a CRM statement hard-blocks via the tool authorization gate.
• The amount thresholds are currency-agnostic numerics. Deployments transacting in minor units or low-unit-value currencies (cents, IDR, JPY) will trip them on routine values. Tune the thresholds, or disable individual policies, before enabling the pack on such a deployment. Per-currency caps are planned.

Tuning is ordinary policy management: individual pack policies can be disabled per row, list-condition policies are tuned by editing their value lists, and the pack's thresholds and patterns should be tuned to your traffic before enforcement rollout.

Current limits

These are deliberate scoping decisions in the current release, stated so you can plan around them. All are planned work, with no dates committed here:

• Velocity and exposure step-ups evaluate 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 pattern policies express; the pack ships the corridor and card-not-present halves of that class.
• The pack's policies and the add-on's typed context validation and risk scoring evaluate on the decision API and the MCP planes today. Coverage of the Gateway Mode pre-check path and the Workflow Control Plane is planned; traffic on those paths is not governed by the add-on yet.