Blog · AI Governance

AI Agent Types in Financial Services: A Compliance Classification Guide

AETHER Pulse·7 August 2026·16 min read

AI Agent Types in Financial Services: A Compliance Classification Guide

Hands storing tamper-evident evidence token

Every deployed system that makes decisions and can take actions without direct human intervention should be recorded as an agent in your inventory. Classify each one by business use, autonomy level, and financial impact, and you have the foundation for a defensible response to FINRA, OCC, and FRB examiners. Start by collecting four fields for every candidate system: owner/line of business, business purpose, autonomy level (advisory vs. actioning), and estimated financial blast-radius.

FINRA has explicitly classified agentic AI as a supervisory risk category and expects firms to maintain agent inventories, integrate audit trails, and demonstrate designed human oversight for material actions. That expectation is not future-state guidance; examiners are asking for it now.


Key Takeaways

A defensible AI agent inventory requires classifying every actioning system by business use, autonomy level, and financial blast-radius, then producing cryptographically signed evidence packs that examiners can verify.

PointDetails
Inventory scopeRecord every system that can take actions without per-step human approval, using the minimum metadata schema.
Triage priorityCredit-decision, AML, trading, and payment agents carry the highest exam and licensing risk; classify those first.
Blast-radius mappingAggregate daily transaction value and customer exposure by vendor and LOB to detect risk concentration clusters.
Evidence standardHMAC-SHA256 signed evidence packs stored in immutable object storage satisfy tamper-evidence requirements for examiners.
AetherpulseProvides metadata-only agent inventory, risk concentration mapping, and signed evidence packs without accessing production data.

Table of Contents

Why classifying agent types matters for US financial regulators

The supervisory rationale for classification is straightforward: regulators cannot assess what they cannot see, and neither can you. The GAO found that federal regulators are integrating AI into supervisory work and conducting AI-focused examinations, though AI outputs inform staff decisions rather than serving as sole decision sources. That distinction matters for your governance design: examiners want to see human oversight baked in, not bolted on after the fact.

Three regulatory drivers make classification non-negotiable for US firms:

  • OCC/FRB/FDIC model risk guidance: The OCC's 2026 bulletin acknowledges that generative and agentic AI are novel and evolving, and therefore outside the narrow scope of traditional model risk bulletins. Firms are expected to apply sound governance practices to fill that gap.
  • Federal Reserve inventory expectations: The Federal Reserve's model risk guidance requires a comprehensive model inventory with sufficient information to understand risks and support effective model risk management.
  • Treasury and industry adoption signals: The Treasury's AI RFI summary reports that roughly 78% of firms have implemented generative AI for at least one use case, with projected material increases in model inventories. That volume makes informal tracking untenable.

Governance goals beyond exam compliance include: risk concentration visibility across business lines, enforceable human oversight thresholds, and auditability of agent decisions at the query level. Firms that understand why regulators audit AI agents are better positioned to frame their inventory work as a risk management asset, not a compliance burden.


The eight agent types your inventory must cover

The following business-use categories represent the deployed agent types most commonly found in US regulated financial services. Each carries a distinct risk profile.

  • Trading and execution bots: Automated order routing, algorithmic execution, and market-making agents. Risk: material funds movement, market-impact exposure, potential MSB licensing triggers.
  • Credit-decision and underwriting agents: Agents that score applications, set terms, or decline credit. Risk: fair lending liability, adverse action notice obligations, high regulatory sensitivity.
  • Customer-service and chat agents: Conversational agents handling account inquiries, complaints, and disclosures. Risk: PII exposure, Consumer Financial Protection Bureau (CFPB) complaint risk, disclosure accuracy.
  • AML/monitoring and surveillance agents: Agents that flag transactions, generate SARs, or screen against sanctions lists. Risk: false-negative liability, FinCEN reporting obligations, exam scrutiny on alert logic.
  • Reconciliation and workflow automation agents: Back-office agents that match transactions, route exceptions, and trigger settlements. Risk: operational disruption, data integrity, cascading failure if misconfigured.
  • Document-processing and decisioning agents: Agents that extract, classify, and act on contract, loan, or regulatory filing content. Risk: data extraction errors, PII handling, downstream decisioning errors.
  • Payment and settlement routing agents: Agents that initiate or route fund transfers. Risk: highest licensing exposure; agents capable of moving money may trigger FinCEN/MSB or state money-transmitter registration regardless of whether they trade securities.
  • Infrastructure orchestration agents: Agents that provision resources, manage API tokens, or coordinate multi-agent pipelines. Risk: privilege escalation, scope creep, lateral movement across systems.

Pro Tip: Distinguish advisory agents from actioning agents in your first pass. An agent that recommends a credit decision carries different regulatory weight than one that executes it. Payment and settlement routing agents warrant immediate legal review for licensing obligations.

Credit-decision and AML agents consistently draw the most examiner attention. Trading bots and payment routing agents carry the highest financial blast-radius. Prioritize those four categories in your initial triage.


The eight agent types your inventory must cover — overview diagram

Metadata fields every agent inventory must capture

The Federal Reserve's model risk guidance sets the baseline expectation: sufficient information to understand risks. For agentic systems, that means going beyond model name and owner. The minimum schema for each agent record includes:

FieldDescription
Unique agent IDStable identifier for cross-referencing logs and evidence
Owner / line of businessAccountable business owner and LOB
Business purposePlain-language description of what the agent does
Autonomy levelAdvisory (recommends) vs. actioning (executes)
Permitted actionsExplicit list of what the agent can initiate or modify
Data access scopeData types and systems the agent can read or write
Criticality / financial blast-radiusEstimated transaction value or customer population at risk
Vendor / hostingThird-party provider or internal deployment
Validation statusPre-deployment review outcome and date
Logs / evidence referencePointer to audit log location and retention period
Last review dateDate of most recent periodic re-evaluation

Autonomy level is not the same as model complexity. A simple rules-based bot that executes wire transfers is a high-autonomy, high-risk agent. A large language model that drafts email responses for human review is advisory. Examiners care about what the agent does, not how sophisticated its underlying model is. The AI agent discovery workflow published by Aetherpulse provides a practical template for collecting these fields at scale.


How to assess risk concentration and financial blast-radius

Risk concentration occurs when multiple high-autonomy agents share a vendor, a data source, or a business line, creating correlated failure exposure. A single vendor outage or model drift event can simultaneously impair trading execution, credit decisioning, and AML monitoring if those agents all depend on the same underlying model or API.

Approximate blast-radius for each agent using three inventory fields: daily transaction value in scope, number of customers affected by a failure, and escalation path (does a failure trigger a regulatory notification obligation?). Aggregate those figures across agents by vendor and by LOB to identify concentration clusters.

Concentration DimensionSignal to WatchMitigation
Single-vendor dependency3+ high-criticality agents on one providerContractual fallback, diversification plan
Shared data sourceMultiple agents reading the same feedRedundancy, access controls
LOB clusteringOne LOB owns most high-autonomy agentsCross-LOB governance oversight
Correlated blast-radiusAggregated daily exposure exceeds materiality thresholdSenior risk committee escalation

Agent-specific controls that go beyond standard model risk management

Traditional vendor due diligence is necessary but insufficient for agentic systems. Legal analysis identifies agentic AI risks including autonomous actions, scope creep, and reward misalignment, and recommends controls that capture chained reasoning, runtime tool calls, and action gating. Standard model risk controls do not address those dimensions.

Required agent-specific controls:

  • Action gating and transaction caps: Hard limits on transaction size, frequency, and counterparty scope enforced at the API layer, not just in policy.
  • Human-in-the-loop thresholds: Defined dollar or customer-impact thresholds above which the agent must pause and route to a human reviewer before proceeding.
  • Dynamic RBAC for agent tokens: OAuth tokens and API credentials scoped to the minimum permissions the agent requires; revocable on demand.
  • Kill switches and safe-shutdown mechanisms: Documented, tested procedures to halt an agent without data loss or cascading failures.
  • Query-level logging: Every tool call, intermediate reasoning step, and output logged with a timestamp and agent ID for unified audit trail construction.
  • Vendor contractual rights: Contractual access to logs, explainability documentation, patching timelines, and incident notification SLAs.

Pro Tip: Fragmented logs are the most common exam failure mode. Require vendors to provide API call-level traces, not just summary reports. A unified trail connecting document processing, identity verification, agent decisions, and execution is what satisfies examiners.


Lifecycle governance mapped to US supervisory expectations

Examiners expect documentation at each lifecycle stage, not just at deployment. Map your governance artifacts to the following stages:

  • Pre-deployment: Risk classification against your taxonomy, impact assessment, vendor due diligence checklist, and a written approval from the model risk committee or equivalent.
  • Validation and testing: Domain knowledge checks, reward-alignment tests, and red-team results documented in a validation report. The OCC's 2026 guidance expects governance practices to address novel agent behaviors even where prior bulletins do not prescribe specific requirements.
  • Ongoing monitoring: Automated anomaly detection on agent outputs, periodic performance reviews, and escalation logs. The NIST AI Risk Management Framework functions (Govern, Map, Measure, Manage) provide a voluntary but increasingly examiner-referenced structure for organizing these artifacts.
  • Periodic re-evaluation: Annual at minimum for high-criticality agents; triggered re-evaluation after any material model update, vendor change, or incident. The GAO's review notes regulators may update guidance as risks evolve, so re-evaluation cadence should track supervisory developments.

Who owns classification and what to ask third-party providers

Classification ownership should follow a three-party RACI: the LOB owner is accountable for accurate metadata; the risk/compliance steward validates classification and controls; and central model governance maintains the master inventory and evidence repository.

For third-party and hosted agents, require written answers to the following before deployment:

  1. Can you provide API call-level audit logs, and for how long are they retained?
  2. What is your documented proof of non-retention of customer data processed by the agent?
  3. What is the complete list of permitted actions the agent can initiate on our systems?
  4. Does the agent have a tested kill switch, and what is the documented shutdown procedure?
  5. What are your SLAs for incident notification and patching?
  6. Can you provide an explainability report for agent decisions on request?

Pro Tip: Treat vendor answers as attestations, not representations. Request them in writing, store them in your evidence repository, and refresh them annually or after any material platform update.

Agents capable of moving money require an additional legal review step. Astraea Law's guidance on AI agent financial licensing identifies that payment-capable agents may trigger FinCEN registration or state money-transmitter licensing obligations independent of securities regulation.


Typical timeline and resource estimate for classification

PhaseDurationKey DeliverableResource Band
Discovery2–4 weeksCandidate agent list with owner and LOB1–2 compliance analysts + IT liaison
Classification and scoring2–6 weeksCompleted inventory with metadata fieldsRisk/compliance team + model governance
Controls remediation4–12 weeksGap closure plan and updated controlsEngineering dependency; LOB owners
Steady-state monitoringOngoingPeriodic re-evaluation reports, updated inventory0.5–1 FTE compliance + automated tooling

Enterprise programs with 50+ agents should expect the classification phase to run closer to six weeks and controls remediation to extend beyond twelve weeks where vendor renegotiation is required. The AI compliance gap assessment guide provides a stepwise prioritization approach for firms managing large inventories.


A 5-step quick-start playbook you can run this week

  1. Identify candidate systems. Pull a list of every automated system with API credentials, scheduled jobs, or LLM integrations from IT and LOB owners. Flag any system that can initiate an action without a human approving each step.
  2. Collect minimal metadata. For each candidate, record: unique ID, owner, business purpose, autonomy level, and estimated financial blast-radius. Use the schema in the classification criteria section above.
  3. Triage by autonomy and impact. Score each agent on a simple two-axis matrix: autonomy level (advisory vs. actioning) and financial blast-radius (low/medium/high). Agents in the high-autonomy, high-impact quadrant require immediate controls review.
  4. Apply controls for high-risk agents. For every agent in the top-risk tier, verify action gating, human-in-the-loop thresholds, kill switch documentation, and query-level logging are in place before the next exam cycle.
  5. Produce a signed evidence pack. Generate an inventory snapshot, attach validation reports and human review records, and apply HMAC-SHA256 signing to the package. Store with a retention policy that meets your books-and-records obligations.

Sample inventory row:

Agent IDOwnerPurposeAutonomyBlast-RadiusVendorValidation StatusLast Review
AGT-1Retail Banking / J. SmithAutomated credit pre-screeningActioningHighInternalValidated 20252026

How to make agent evidence audit-ready with tamper-evident provenance

Examiners expect a minimum evidence set: an inventory snapshot, query-level audit logs, validation reports, human review records, and vendor attestations. Fragmented or mutable logs fail that standard. The AI regulatory disclosure obligations guide covers the books-and-records implications in detail.

The tamper-evidence method that meets exam needs uses metadata-only ingest (no customer data enters the governance layer) combined with HMAC-SHA256 signing of evidence packs at the point of generation. The cryptographic spec is straightforward: the evidence pack contents are serialized, a shared secret key is applied using HMAC-SHA256, and the resulting digest is stored alongside the pack. Any subsequent modification to the pack produces a different digest, making tampering detectable without requiring a blockchain or external notary.

Evidence ComponentFormatRetention Guidance
Inventory snapshotSigned JSON or CSV with digestMinimum 3 years; align with books-and-records rules
Query-level audit logsTimestamped log files, agent ID taggedMinimum 3 years; vendor logs contractually secured
Validation reportsPDF or structured document, signedLife of agent plus 3 years
Human review recordsTimestamped approval logsMinimum 3 years
Vendor attestationsWritten responses, datedAnnual refresh; stored in evidence repository

Aetherpulse's evidence methodology describes how HMAC-SHA256 signed evidence packs are generated from metadata-only ingest, producing provenance-tracked outputs without touching production data.

Pro Tip: Store evidence packs in an immutable object store (AWS S3 Object Lock or equivalent) with versioning enabled. The combination of cryptographic signing and immutable storage gives examiners two independent tamper-detection mechanisms.


The classification work that actually reduces exam friction

Most compliance teams approach agent classification as a documentation exercise. That framing underestimates its operational value. A well-maintained inventory with accurate autonomy levels and blast-radius estimates is the fastest path to answering an examiner's first question: "Show me every system that can take a material action without human approval." Firms that cannot answer that question in the first day of an examination spend the rest of it on the back foot.

The controls checklist and vendor question framework in this guide are not theoretical. They reflect the specific artifacts examiners are requesting in AI-focused examinations, as documented by the GAO and in FINRA's 2026 supervisory classification. Calibrate governance intensity to agent criticality: a chatbot that drafts responses for human review does not require the same controls burden as an execution agent routing wire transfers. Misallocating governance effort to low-risk agents while leaving high-autonomy agents under-documented is the failure mode that produces material exam findings.


Aetherpulse gives you the inventory, evidence, and risk maps examiners expect

Producing a defensible agent inventory with tamper-evident evidence packs is the core challenge this article describes. Aetherpulse addresses it directly: the platform connects via OAuth metadata only, touching no customer data, and builds an agent inventory and identity graph from what it finds. Risk concentration mapping, including financial blast-radius exposure across agents and business lines, is surfaced automatically. Every evidence pack is cryptographically signed using HMAC-SHA256, giving examiners two independent tamper-detection mechanisms without requiring access to production systems.

Aetherpulse

That maps precisely to the taxonomy and evidence structure described here: business-use classification, autonomy scoring, blast-radius aggregation, and signed evidence packs on demand. For compliance teams facing an exam cycle or a first-pass inventory project, Aetherpulse removes the engineering dependency that typically delays classification work by weeks. Review the evidence infrastructure and pricing or explore the full platform at Aetherpulse to see how it fits your program.


Sources

Recommended

Working on Article 26 readiness, deployer-side governance evidence, or AI agent risk at a regulated firm? We'd value 15 minutes of your perspective.

Start a conversation