AML/BSA and AI Agents: The Travel Rule, Transaction Monitoring, and SAR Filing

The Bank Secrecy Act has been around since 1970. FinCEN's expectations for AI-assisted transaction monitoring are not new — the 2021 guidance on AML program effectiveness explicitly called out model risk management and audit trail requirements for automated transaction monitoring systems.

If your AI agent initiates, approves, routes, or monitors financial transactions, AML/BSA requirements apply. There's no AI carve-out.

The Three AML Obligations That Directly Touch AI

Transaction Monitoring

Financial institutions must have programs to detect suspicious activity. When AI replaces or augments a human analyst in this role, two things are required:

1. The model must be validated — documented performance metrics, periodic review, change management
2. Every decision the model makes must be auditable — why was this transaction flagged? Why was this one cleared?

If your AI agent is making the call on whether a transaction gets processed or held, that decision must be explainable and auditable in a form that FinCEN examiners can review.

Currency Transaction Reports (CTRs) and Suspicious Activity Reports (SARs)

Transactions over $10,000 in cash require a CTR. Suspicious activity requires a SAR. If your AI agent processes payments, it needs to:

• Enforce the $10,000 threshold (amount cap in the manifest)
• Escalate suspicious patterns to a human for SAR determination
• Never complete a transaction that a human reviewer has flagged as suspicious without override

The SAR filing decision itself must be made by a human — it cannot be fully automated. Your AI agent should escalate to human review; the human makes the SAR determination.

The Travel Rule (31 CFR § 103.33)

For wire transfers and electronic funds transfers of $3,000 or more, the originating institution must include originator and beneficiary information throughout the transfer chain. For crypto, FinCEN's application of the Travel Rule to Virtual Asset Service Providers (VASPs) means the same obligations apply to cryptocurrency transfers.

An AI agent that initiates wire transfers or crypto transfers must enforce Travel Rule thresholds as a hard limit — not a suggestion.

What the Manifest Looks Like

{
  "policy": {
    "amount_caps": {
      "USD": 10000,
      "EUR": 9500
    },
    "counterparty_denylist": [
      "sanctioned-entity.example",
      "ofac-listed-wallet.example"
    ]
  },
  "constraints": {
    "require_human_approval": ["payment:execute", "fraud:flag"],
    "audit_retention_days": 1825
  }
}

The amount_caps field enforces the BSA reporting threshold — any transaction over $10,000 USD is denied at the gateway before it reaches the payment processor. The agent cannot exceed this limit regardless of what the upstream application requests.

counterparty_denylist enforces OFAC screening. If the destination entity appears on the denylist, the request is denied with a COUNTERPARTY_DENIED reason code — before any funds move.

require_human_approval on payment:execute means no payment goes out without a human approver. This satisfies the SAR-decision requirement: a human must be in the loop on every payment execution.

audit_retention_days: 1825 — AML record retention is 5 years from the date of the transaction.

The OFAC Problem

OFAC updates the SDN (Specially Designated Nationals) list frequently — sometimes daily. A counterparty denylist hardcoded into a manifest will drift out of date.

Two approaches:

1. Webhook-based sync: your OFAC screening service posts updates to your governance infrastructure, which updates the denylist in near-real-time
2. Pre-execution check: every payment execution triggers an OFAC screening call before the gateway approves the action — this is the more defensible approach for regulated financial institutions

UAPK's tool connector architecture supports both patterns. The OFAC screening call can be a pre-execution check wired as a required tool step before payment:execute proceeds.

Model Risk Management (SR 11-7)

The Federal Reserve's SR 11-7 guidance on model risk management applies to models used for decisions in financial services — including AI transaction monitoring models. Key requirements:

• Model validation: independent testing before deployment and periodically thereafter
• Model inventory: every model must be documented in a model inventory
• Model performance monitoring: ongoing tracking of model drift and performance degradation
• Override documentation: when humans override model outputs, those overrides must be logged

The UAPK audit log captures override events automatically. When a human approver issues an override token and the agent proceeds with an action that was initially escalated, the interaction record captures the approval event, the approver's identity, and the original decision chain. That's the override documentation SR 11-7 requires.

Penalties Are Severe

AML/BSA enforcement actions have produced some of the largest financial penalties in banking history. TD Bank's 2024 AML settlement was $3 billion. Individual compliance officers have faced personal liability.

For AI-specific violations: the 2021 FinCEN guidance explicitly states that AML program deficiencies tied to inadequate model governance are treated the same as any other program deficiency. Deploying an AI agent that processes payments without AML controls is not a technical oversight — it's a compliance violation.