An AI Agent for Regulatory Reporting After SR 26-2: Who Owns the Evidence?

Key takeaways

• SR 26-2 (April 17, 2026) supersedes SR 11-7 and places generative and agentic AI outside its scope. An AI agent for regulatory reporting is therefore governed by whatever the bank designs for it.
• Three questions decide whether that design holds up: what evidence the agent touched, which policy allowed each step, and who approved the report.
• The agent prepares. It pulls extracts, reconciles, flags breaks and drafts notes. A named preparer reviews and a named approver owns the submission. The human still decides.
• Measure your own baseline first. Any time saved is illustrative until you have measured it on your own reports.

Regulatory reporting is one of the first places banking teams think about agents, and for understandable reasons. The work is repetitive, it pulls from many systems, and the deadlines do not move. Much of the effort goes into assembly: finding the right extract, reconciling it to the general ledger, chasing the owner of a break, and writing the note that explains a variance.

That is also why it needs care. The output goes to a regulator, someone signs it, and examiners can ask how a number was produced. If an agent did part of the work, the bank has to be able to show what the agent did.

What SR 26-2 changed, and what it left open

On April 17, 2026, the Federal Reserve, OCC and FDIC issued revised model risk management guidance through SR 26-2. It supersedes SR 11-7. The guidance text distinguishes traditional statistical and quantitative models, including non-generative and non-agentic AI, from generative and agentic AI, and Footnote 3 places the latter outside its scope. Banks are pointed to their own risk management and governance practices for those tools.

That is a scope decision, not an exemption. Vice Chair for Supervision Bowman said in remarks published on May 1, 2026 that other risk management and governance practices are expected to support the adoption of generative and agentic AI. For a reporting agent, the practical meaning is simple: no outside framework will tell you what its record must contain. Your bank decides, and your bank defends the decision. We cover the scope question in more depth on our SR 26-2 banking AI governance page.

A reporting workflow can also contain both kinds of component. A conventional model that produces an input, such as a reserve estimate, may sit inside SR 26-2. The agent that assembles the schedule around it does not. Each needs its own assessment, and finishing one does not complete the other.

Where an agent fits in the reporting workflow

Break a typical report cycle into steps and the split between preparation and decision is usually clear.

Steps an agent can prepare:

• Pull the defined extracts from source systems for the reporting date.
• Reconcile totals to the general ledger and to the prior period, and list every break above the threshold your procedure sets.
• Match each break to a likely owner and draft the request for an explanation.
• Assemble the evidence pack: extracts, reconciliations, explanations received, and open items.
• Draft variance notes from the explanations, marked as drafts.

Steps that stay with people:

• Deciding whether a break is resolved or needs an adjustment.
• Approving any manual adjustment.
• Reviewing the final figures and notes.
• Signing the attestation and submitting the report.

In this design, submission is not an action the agent has. It can prepare the package, but it cannot send it. That boundary is easier to defend when it is enforced by what the agent is permitted to do rather than by an instruction asking it not to.

The three questions your record must answer

When an examiner, an auditor or your own second line asks about an agent-assisted report, the questions tend to reduce to three.

1. What evidence did the agent touch?

List every source the agent read, with the time it read it. For reporting, timing matters: a figure restated after the cut-off should not silently change what the agent used. The record should show the extract, the version and the retrieval time, plus every tool call the agent made to get there. If the agent asked for data it was not allowed to read, the refusal belongs in the record too.

2. Which policy allowed each step?

Two things were live when the agent ran: the bank’s reporting procedure and the agent’s own instructions. Both have versions. When a procedure changes between quarters and the agent’s output shifts, the version history is how you explain the difference. The same applies to the agent’s permissions: which systems it could reach, which models it could call, and which actions needed a person.

3. Who approved the report?

This is the part that cannot be delegated. The record needs the named preparer who reviewed the package, the named approver who signed, the time of each decision, and the reason for any override of something the agent flagged. If a reviewer accepted a break the agent raised, the reason is part of the evidence.

For a fuller checklist of what to keep, see our post on what to retain when an AI agent supports a decision. For the broader concept, start with what is agentic AI governance.

How this maps to controls you can actually run

Writing down the three questions is the easy part. Making the answers exist every time is the harder part. These are the controls that do the work, described in terms of what the Moring platform provides.

Approve before build. The reporting use case is registered with its data class and the models it needs, then passes four gates in order, each with its own owner: commercial, security, technical and tiering. A rejection at any gate rejects the use case. Restricted data is only allowed at the top tier.

Certify before production. The agent’s manifest maps its prompts, models, tools and skills at one commit. A person decides each certification gate, and nothing deploys until an approver signs off. The deploy step produces a certificate naming exactly what would go to production, and only named production approvers can promote it. Nobody approves their own deploy.

Limit what it can reach at run time. The agent’s key reaches only the models it was granted. Tool access goes through a gateway with per-server guardrails, including human approval steps. An action like “submit” is simply not granted.

Keep the record. Every model call is recorded with user, team, model, tokens, cost, latency and guardrail verdict. Every run, finding, certificate and stop is kept per agent.

Stop it if needed. If the agent misbehaves during a reporting cycle, stopping it blocks its key, so the gateway refuses every call. Who stopped it, when and why is on record, and only the production approver or a super admin can resume it.

None of this replaces your reporting controls. It gives the reporting controls a record they can rely on for the steps the agent performed.

An illustrative cycle

Here is how one quarter might look. This is illustrative, not a measured result.

1. On the business day after cut-off, the agent pulls the defined extracts and reconciles them to the ledger. It finds a set of breaks above threshold.
2. It drafts an explanation request for each break and routes it to the owner your procedure names.
3. As explanations come in, it attaches them to the evidence pack and drafts variance notes.
4. The preparer reviews the pack. They accept most explanations, reject one, and book an adjustment through the normal approval path.
5. The approver reviews the final schedule, reads the notes, and signs. The submission goes out through your existing channel, by a person.

Afterwards, anyone with access can see which extracts were used, which procedure version applied, which breaks were raised, and who decided each one.

What not to promise

Some claims sound good and will not survive review.

• “SR 26-2 compliant agent.” The guidance places agentic AI outside its scope. The claim hides the very distinction your reviewers need to see.
• “The agent files the report.” It should not, and in this design it cannot.
• Time or cost savings before you measure. Until you have a baseline and a measured cycle, any number is a projection. Label it that way.

Where to start

Choose one report, or one schedule within a report, where the reconciliation work is heavy and the owners are clear. Write down the current steps and who owns each. Measure your own baseline: hours to assemble, the number of late breaks, and the rework after review. Then decide which steps the agent may prepare and which stay with people, and design the record before the agent runs.

The goal is not to remove people from regulatory reporting. It is to give the people who sign the report a complete, checkable package, and a record that shows they made the call.

Frequently asked questions

Sources

About the author

Arya SharanProduct Marketing & GTM, Moring AIChennai

Owns product marketing and go-to-market at Moring AI across positioning, demand and enablement. Works with regulated buyers on how governed AI agents are scoped, evaluated and bought. Writes about the operating questions that decide whether an agent reaches production.

LinkedIn profile →