This Week in Fintech: You Can't Outsource Accountability

Bank of America paid more than $1.21 billion in penalties this week for AML and sanctions failures, and one finding reads like a design principle: its own monitoring missed activity that law enforcement and other banks later flagged. The same week, US regulators began asking banks whether they can control the AI agents they deploy, Amex published a framework for capturing a customer's purchase intent before an agent transacts, and a $5.2 billion RIA hired an outside firm to build AI co-workers that run inside its own systems under its staff's supervision. Infrastructure, models, and even the agents themselves can come from outside. Accountability for what they do inside the product stays with the company running it.

Treasury fines Bank of America $1.21 billion for AML and sanctions failures

The US Treasury announced enforcement actions totaling more than $1.21 billion against Bank of America for anti-money laundering and sanctions violations, the third-largest penalty in Treasury history and the largest in OCC history. FinCEN assessed a $1.2 billion penalty, which includes the OCC's $750 million civil money penalty for a deficient BSA/AML program, and OFAC settled 475 apparent sanctions violations for $11.6 million. The bank admitted it willfully failed to maintain an adequate AML program, conduct correspondent-account due diligence, and file suspicious activity reports, leaving more than $5 billion in suspicious transactions unreported on time. Regulators also found the bank relied on law enforcement inquiries and other institutions' referrals rather than its own automated controls to surface suspicious activity.

Source: U.S. Department of the Treasury

Why it matters

The finding that stands out is architectural. Regulators concluded the bank effectively outsourced a substantial part of its detection obligation, because its own transaction monitoring failed to surface what law enforcement and other banks later flagged. That is a statement about accountability rather than about vendors. A bank can run monitoring on third-party software and share signals with peers, and the obligation to detect and report still sits with the bank, so external referrals count as evidence of a gap rather than as a backstop.

The second lesson is about what regulators do with evidence of known failures. The bank had testing that showed the gaps, a 2024 cease-and-desist order, and escalations from its own compliance staff, and the penalty cites all three as aggravating factors. Documented awareness without corrective action became the core of the case, and the consent order now requires an independent review of the bank's data governance for AML, which places data quality squarely inside the enforcement perimeter.

What teams should do

This applies to banks, neobanks, BaaS providers, payment processors, and any fintech running its own transaction monitoring or relying on a partner's.

• Measure what share of your SARs originate from your own monitoring versus external referrals or law enforcement requests, since a high external share is the exact pattern regulators penalized here.
• Trace how an escalated alert moves from your monitoring system to an investigator, and fix any step where alerts accumulate without review, because unreviewed backlogs produced the late SARs in this case.
• Close findings from your own model testing on a tracked timeline, since documented awareness of a gap with no fix became an aggravating factor.
• Audit the data feeding your transaction monitoring, including customer risk profiles and third-party payment patterns, because the consent order makes AML data governance a reviewable item.
• Update customer risk profiles as behavior changes, especially heavy reliance on payments from unknown third parties, rather than treating onboarding risk as static.
• Review how your sponsor bank or BaaS provider handles detection if you depend on one, since detection you cannot inspect is still your exposure when something is missed.

US regulators ask banks whether they can control their own AI agents

Three top US regulators, including the Federal Reserve, are questioning banks about their use of advanced AI models, according to a Reuters report citing six people familiar with the matter. The inquiries, described by sources as information gathering rather than new rules, center on agentic AI in cybersecurity, whether banks deploy Chinese-developed models, and whether they can control increasingly autonomous systems. The scrutiny follows recent incidents, including a breach of Hugging Face involving AI agents developed by OpenAI and a hack on South Korean banks that reportedly used a Chinese AI agent and Anthropic's Claude Code. In Europe, the ECB has given lenders an end-October deadline for plans to counter AI-enabled cyber threats, including improved backup and recovery.

Source: Reuters

Why it matters

Regulatory attention on AI is moving from the model inventory toward the question of control: can an institution see what an autonomous agent is doing, bound what it can reach, and shut it down. The questions are exploratory for now, and sources suggest formal guidance may follow in some jurisdictions, but they show what examiners will want to see. A list of deployed models answers the old question; a demonstrated kill switch, egress limits, and action logs answer the new one.

The European thread adds a resilience requirement that US teams should read closely. Supervisors are pushing for clean, separately held copies of critical data that can restore operations if primary systems are compromised, which treats AI-enabled attacks as a recovery problem as much as a prevention one. The cost of that readiness lands on infrastructure budgets, and dependency on external AI and cloud providers becomes something examiners are likely to ask about by name.

What teams should do

This applies to banks, fintechs deploying AI agents in security or operations, and any regulated firm building on third-party foundation models. Treat these as preparation ahead of formal expectations.

• Document which actions each deployed agent can take, what systems it can reach, and who can halt it, so you can answer a regulator's control question with specifics.
• Test your ability to stop an agent mid-task and confirm the stop actually prevents further actions, since a kill switch that exists only on paper is the gap regulators are probing.
• Maintain clean, separately held backups of critical data and rehearse restoring from them, treating AI-enabled attacks as a recovery scenario.
• Inventory the provenance of every AI model in production, including the developer and jurisdiction, because regulators are asking that question directly.
• Record each agent's actions in a tamper-evident log, so an incident review can reconstruct what the agent did and why.
• Map your dependencies on external AI and cloud providers and define what happens to critical workflows if one is compromised or unavailable.

Amex publishes a framework that captures purchase intent before an AI agent transacts

American Express published its Intent Intelligence framework, describing how to capture and authenticate a customer's purchase intent before an AI agent completes a transaction, then preserve that intent as a control through the transaction lifecycle. The approach differs from current implementations by making authorized intent available to the issuer earlier, before the agent executes, so the resulting purchase can be checked against what the customer approved. The framework is available through Amex's Agentic Commerce Experiences developer kit, and the company says it is seeing thousands of agentic transactions a week. Amex chairs the EMVCo agentic commerce working group and published the framework openly to encourage a common industry approach.

Source: American Express; Digital Transactions

Why it matters

The design choice is where the control point sits. Current agentic flows verify a transaction at authorization, after the agent has already acted; this framework moves the control to before execution, by capturing what the customer authorized and carrying it forward as a constraint the purchase must satisfy. Authorization shifts from confirming a payment to confirming that an agent's action matches a prior, authenticated intent.

That changes what a dispute looks like. When intent is captured and preserved up front, an issuer can compare the completed purchase against the original authorization and settle whether the agent overstepped, which gives everyone in the chain a record to resolve against. Publishing it openly and routing it through EMVCo's working group is a bid to make intent capture a common approach. EMVCo's agentic work is still in progress and the framework is a recommendation rather than a mandate, but if it takes hold, merchants and PSPs would be expected to carry an intent record whether or not they built one.

What teams should do

This applies to merchants, PSPs, issuers, wallet providers, and any product enabling purchases initiated by AI agents.

• Capture and authenticate the customer's authorized intent before an agent executes, and store it as the reference the completed transaction is checked against.
• Preserve the intent record through the full transaction lifecycle, so a dispute can be resolved by comparing the purchase to what was approved.
• Define the conditions under which an agent may act, such as spending limits, merchant scope, and timing, and enforce them at execution rather than reviewing afterward.
• Build dispute handling that distinguishes an agent exceeding its mandate from a customer changing their mind, since the two need different outcomes.
• Track emerging EMVCo guidance on agentic transactions, so your intent handling aligns with a common approach rather than a single network's spec.

Connecticut Wealth Management hires Subatomic to build an AI operating system across its stack

Connecticut Wealth Management, an independent RIA with $5.2 billion in assets, 45 advisors, and more than 1,300 client families, hired Subatomic in a five-year partnership to build an AI operating system that unifies the firm's data and deploys AI co-workers supervised by its staff. The system spans the firm's custodian, portfolio management system, CRM, planning and tax software, meeting notes, phone system, email, and documents. It runs inside CTWM's own security environment with role-based permissions, and Subatomic's Deep Lens records every action an AI co-worker takes for staff or auditors to review. The first phase is scheduled to go live before the end of 2026, with the firm aiming to hold its 35-to-1 client-to-advisor ratio while adding capacity.

Source: WealthManagement.com

Why it matters

Wealth firms are moving from buying point AI tools to commissioning an operating layer that sits across every system they run. The difference is where the AI lives: inside the firm's own infrastructure, on its own unified data, with humans supervising, rather than in a vendor-hosted tool the firm cannot inspect. The value sits in the unified data layer and the supervision model around it, since an agent that sees custodian, CRM, and planning data together can do work that stays out of reach for a single-system assistant.

The accountability piece is what makes this a template. The RIA remains the fiduciary for every action an AI co-worker takes, whoever built the system, so role-based permissions, a reviewable action log, data ownership, and what the firm keeps when a five-year contract ends become the real terms of the deal. With only 16% of wealth firms running a production AI agent, according to the WMIQ 2026 WealthStack Study, this shows what a full commitment looks like and which controls have to travel with it.

What teams should do

This applies to RIAs, wealth platforms, broker-dealers, and any firm commissioning a vendor-built AI layer across its core systems.

• Map each AI co-worker's role-based permissions to the human role it supports, so an agent never holds broader access to custodian, CRM, or planning data than its supervisor does.
• Define who reviews the agent action log, how often, and what triggers escalation, since a log nobody reads gives auditors evidence and the firm no control.
• Write data ownership, model portability, and exit terms into a multi-year AI contract up front, so the unified data layer stays yours when the partnership ends.
• Unify the data across custodian, portfolio, CRM, planning, and tax systems before scaling agents, because an agent working on partial data produces confident errors in client work.
• Measure advisor capacity and the client-to-advisor ratio before and after rollout, so the business case rests on observed throughput rather than projected hours.

Closing insight

Pick one critical control in your product, AML monitoring, fraud detection, agent authorization, or an AI co-worker's permissions, and ask who is accountable when it fails. Running it on a vendor's platform, through a partner bank, or on a system an outside firm built is normal and often the right call. This week's lesson is narrower: the rules, permissions, monitoring, and audit trail around that control have to be yours to see, test, and prove, wherever the infrastructure sits.

That is a design problem more than a build-everything problem. In our work with fintech teams at Itexus, it usually means a control layer on top of existing providers: checks integrated into the critical workflow rather than bolted on after, permissions enforced at the moment of action, and an audit trail that shows the control worked before anyone asks. If you are mapping where accountability sits across your providers and partners, we are glad to talk through the architecture.