How SR 26-2, FinCEN's CDD Rule, GLBA, and third-party risk rules apply to AI employees doing KYC, sanctions screening, and chargebacks at US banks.
A bank evaluating an AI employee for KYC, sanctions screening, or chargeback handling is not asking a product question. It is asking a supervisory one: what happens the first time an examiner asks who approved this decision, and how do you show your work. That question separates AI employees that can run inside a regulated bank from the ones that can only run in a demo.
Banking is where Zamp's compliance-grade architecture was forced into existence, not the only place it runs. Why Zamp isn't just a finance AI company covers how the same audit-trail-first design now runs regulated work in life sciences, and front-office deployments like institutional client onboarding, alongside the back-office banking use cases below.
This guide covers the US rules that actually govern AI employees in banking and financial services: the federal banking agencies' 2026 overhaul of model risk management guidance, the Bank Secrecy Act and FinCEN's Customer Due Diligence Rule, the Gramm-Leach-Bliley Act's data safeguards, third-party risk management expectations, and how sanctions screening, trade finance, and chargeback decisioning fit into all of it. It also covers what to check for when a vendor's AI employee is going to sit inside your bank's regulated processes.
Most companies adopting AI worry about accuracy and cost. Banks worry about those too, but they also answer to examiners who can require a bank to unwind a program, file a corrective action plan, or hold more capital against a process they consider poorly controlled. A chargeback decision, a sanctions match disposition, or a customer risk rating is not just an operational output. It is evidence in an exam file, and it stays evidence for as long as regulators can ask about it.
That changes what good AI means in a bank. A model that is 95% accurate but cannot explain the other 5% is a liability, not a win, because the bank still has to answer for every one of those cases individually if a regulator asks. The requirement is not just performance. It is explainability, a record of who approved what and when, and a designated human who owns the outcome. A vendor pitching raw accuracy numbers without addressing any of that is pitching the wrong bank.
For fifteen years, model risk in US banking meant one document: the 2011 Supervisory Guidance on Model Risk Management issued by the Federal Reserve and the OCC, known industry-wide as SR 11-7, which the FDIC adopted in 2017. It set the rules for how banks validate, monitor, and govern models used in business decisions, and examiners have graded banks against it ever since.
That changed on April 17, 2026. The three federal banking agencies replaced SR 11-7 with new interagency guidance: Federal Reserve SR 26-2, OCC Bulletin 2026-13, and FDIC FIL-15-2026. The new guidance keeps the core disciplines banks already know: independent validation, ongoing monitoring, outcomes analysis, governance, and effective challenge. What changed is the boundary around what counts as a model and how much effort each one deserves. The guidance is risk-based and is expected to matter most for banking organizations with more than $30 billion in assets, though smaller banks with significant or complex model use can still fall inside it.
The detail that matters most for an AI employee doing KYC or sanctions work is this: SR 26-2 explicitly excludes generative AI and agentic AI from its formal scope. The agencies describe both as novel and rapidly evolving, and they direct banks to apply broader risk-management and governance practices to tools outside the guidance. A future interagency request for information on banks' use of AI, including generative and agentic AI, has been announced, which signals more specific expectations are coming.
That exclusion is not the same as an exemption. An agentic system that chains several steps together, where one agent's output becomes the next agent's input, carries a real risk of compounding errors that a single-step model never had. Examiners are watching that risk closely even without a formal rule requiring them to. In practice, a bank deploying an AI employee for a regulated process sits in an in-between zone right now: not yet bound by SR 26-2's formal validation requirements, but still expected to show the governance discipline the guidance was written to enforce. The safer assumption is that formal coverage is a matter of when, not if, and building the audit trail now costs far less than retrofitting one after the rule lands.
This is where deployment architecture becomes a compliance decision, not just a technical one. An AI employee built around an Agent Operating Procedure, a documented set of tolerances, approval thresholds, and escalation rules that a compliance officer can read and adjust directly, gives a bank something concrete to hand an examiner today, ahead of any formal requirement to do so. A black-box agent whose logic lives only inside a prompt has nothing to show once the RFI turns into a rule, and by then the gap is expensive to close.
The Bank Secrecy Act and FinCEN's Customer Due Diligence Rule do not care whether a human or an AI agent performs the work. A bank still has to verify customer identity, identify beneficial owners of legal-entity customers, understand the nature of the customer relationship, and monitor for suspicious activity closely enough to file a Suspicious Activity Report when the facts call for it. None of those obligations shift to a vendor because the vendor's software did the underlying work.
What automation changes is throughput and consistency, not the underlying legal duty. An AI employee handling onboarding can pull identity documents, cross-reference beneficial ownership structures, and flag inconsistencies faster than a manual analyst working through a queue. It can also apply the same risk-rating logic to every applicant instead of the variance that creeps in when different analysts interpret the same policy differently on a busy Friday. See our KYC automation guide for how that onboarding workflow runs end to end.
The part banks tend to get wrong is treating the AI's output as the final answer instead of as a recommendation with evidence attached. A defensible setup keeps a named compliance officer as the approver of record for anything above a low-risk threshold, with the AI employee assembling the file rather than closing the case. That distinction, recommend versus decide, is often what separates a program an examiner accepts from one they flag.
Sanctions screening against OFAC lists and transaction monitoring for suspicious patterns sit at the highest-consequence end of bank compliance work, because a missed true positive can mean a bank processed a payment for a sanctioned party. An AI employee working this queue has to do two things at once: reduce the false-positive rate that buries analysts in irrelevant alerts, and never quietly suppress a genuine hit to hit that goal.
The design pattern that works is the same one as KYC: the agent triages, scores, and assembles evidence, but escalation to a human reviewer happens automatically once confidence drops below a set threshold, and every disposition, cleared or escalated, gets logged with the reasoning behind it. That log is what turns a sanctions program from a black box into something a bank can defend during an exam. Our guide to AI agents in financial crime investigations goes deeper into how that evidence-gathering works case by case.
The Gramm-Leach-Bliley Act requires financial institutions to protect customer information. For banks, that requirement is implemented through the federal banking agencies' Interagency Guidelines Establishing Information Security Standards, which call for a written information security program and oversight of service providers with access to customer information. The FTC's Safeguards Rule covers nonbank financial institutions such as many fintech lenders. Either way, the obligation extends to any vendor or system that touches the data, AI included. An AI employee that reads account records, transaction history, or identity documents is processing exactly the data GLBA is written to protect.
Separately, the agencies' June 2023 Interagency Guidance on Third-Party Relationships: Risk Management applies to an AI vendor the same way it applies to a core banking processor: planning, due diligence before onboarding, contract terms that preserve audit and termination rights, ongoing monitoring, and an exit plan. Using a third party does not transfer the bank's compliance responsibility. An AI vendor that cannot answer basic third-party risk questions, where data lives, who can access it, what happens on termination, is going to stall in procurement regardless of how good the model is.
For a bank vetting an AI vendor, both of these rules turn into the same practical question: where does the model run, where is the data stored, and who else can see it. That is why deployment model matters as much as accuracy. An AI employee that can run on-prem, as multi-tenant SaaS, or fully inside the bank's own cloud under the bank's own security controls gives a compliance team options for answering GLBA and third-party risk questions that a single fixed deployment cannot.
Chargeback and dispute handling looks like an operational workflow, but for consumer accounts it runs on federal timelines. Regulation E (12 CFR 1005.11) generally gives a bank 10 business days to investigate an electronic fund transfer error, or up to 45 days if it provisionally credits the account, with 90-day windows for certain cases. Regulation Z (12 CFR 1026.13) requires a credit card issuer to acknowledge a billing-error notice within 30 days and resolve it within two complete billing cycles, never more than 90 days. Card network rules sit on top of both. Missing a deadline or mishandling documentation is not just a lost dispute. It can be a compliance finding, and the CFPB examines for it.
An AI employee working chargebacks has to hit the same procedural requirements a human analyst does: gather the transaction evidence, apply the right dispute reason code, meet the response window, and produce a record showing why a case was resolved the way it was. See our chargeback automation guide for the mechanics of that evidence assembly and representment process.
Trade finance operations, letter-of-credit review, document checking against UCP 600 standards, sanctions screening on counterparties and vessels, run on a different rhythm than KYC or chargebacks, but they carry the same governance requirements. A discrepancy in a bill of lading or a screening miss on a shipping counterparty has the same regulatory weight as a missed sanctions hit anywhere else in the bank. An AI employee handling trade document review needs the same audit trail and human escalation path as one handling onboarding, even though the documents look completely different.
The rules above apply to every regulated job. The jobs themselves vary. Beyond KYC, sanctions, chargebacks, and trade finance, these are the areas where a job-scoped AI employee tends to earn its place, each with a decision line that stays with an authorized person.
An investigation AI employee can gather transaction, account, device, counterparty, customer, and prior-case context; test approved typologies; build a timeline; identify missing evidence; draft a supported recommendation; and preserve citations for review.
The procedure should state who may disposition an alert, block activity, restrict an account, contact a customer, file a report, or make another consequential decision.
An AI employee can inspect payment messages and case data, trace a transaction across approved systems, identify missing or conflicting details, prepare repair instructions, coordinate information requests, update allowed fields, and verify the final status.
Release, return, recall, beneficiary change, sanctions disposition, and other high-impact actions should sit behind the institution's authority and dual-control model.
The role can compare bank, ledger, processor, settlement, custody, and subledger records; investigate timing and reference differences; gather evidence; propose treatment; post allowed adjustments; and verify that balances and downstream systems agree. See the automated reconciliation guide.
The role can collect application and covenant evidence, validate completeness, compare values across documents and systems, prepare exception summaries, monitor conditions, and route the case. Credit policy decisions, overrides, pricing, adverse action, and customer commitments should remain within explicit authorized workflows.
AI employees can support accounts payable, receivable, treasury, close, reconciliation, substantiation, and reporting evidence inside a bank or fintech, including recurring accounting-ops work such as reviewing operating-expense postings against policy and preparing OpEx reclassification entries for accountant review. The finance AI employee guide explains that operating model.
A control AI employee can select evidence, test defined attributes, identify missing support, prepare exceptions, trace remediation, and maintain a review package. It should not silently rewrite the control, population, sample logic, or exception criteria.
An examiner will look past the use case to the controls around it. The ones that matter for an AI employee map closely to what banks already apply to people and systems:
The safest first use case is not necessarily the smallest. It is the job with a named owner, stable policy, a clear system of record, a verifiable final state, reversible or reviewable actions, and a measurable baseline. Avoid any process whose policy is still unsettled or whose systems and access can't be provided.
Then prove it the way an examiner would test it, not the way a demo shows it:
Once the owning team trusts the evidence and the record, let that team pull the AI employee into adjacent jobs. Expansion driven by the people who live with the outcome holds up better under review than expansion driven by a rollout schedule.
Most vendor demos look similar. The differences that matter to an examiner show up when you ask about governance, not features. A short list worth working through before signing anything:
This is the model Zamp builds to. Every AI employee runs against an Agent Operating Procedure that a process owner controls directly, carries a full decision audit trail on every action, and deploys on-prem, multi-tenant, or inside your own cloud depending on what your compliance function requires. Reviewed corrections feed back into the procedure, and across a bank's AI employees that accumulated operating knowledge becomes what Zamp calls the institution's Company Brain, which a new role in an adjacent job can draw on instead of starting from a blank prompt. Before moving from proof to production, work through the AI employee security and governance checklist, and see how finance teams run AI employees and the automated reconciliation guide for adjacent back-office jobs.
The rules covered here govern how AI employees handle regulated financial decisions specifically. If your bank is also using AI in hiring or other HR decisions, a separate set of US employment law requirements applies, state hiring-disclosure laws and federal anti-discrimination rules chief among them. Our guide to AI employee laws across the US covers that ground.
