The demo went well. The agent reconciled transactions, drafted the customer reply and flagged the odd account, and the product team wanted it live next sprint. Then it went to risk and compliance, and three months later it is still there, stuck in a thread of questions nobody on the build team can answer.
So are fintech teams actually blocked from putting AI agents into production by risk and compliance review? Often, yes, but rarely because a regulation forbids agents. Most agents stall because the team cannot show what the agent is allowed to do, how its decisions can be explained, who is accountable when it is wrong, and how anyone would know. Those are answerable questions. Teams that design for them from the start get through review; teams that bolt them on after the demo usually do not.
Why review stalls: the rules were written for models, not agents
Financial risk functions are used to reviewing models. A credit scorecard takes defined inputs, produces a number, and can be back-tested. An agent is different in three ways that make reviewers nervous. It chooses its own steps. It takes actions in real systems. And the same input can produce a different output tomorrow.
The regulatory frameworks have not fully caught up, which slows things down rather than speeding them up. In April 2026 the US federal banking agencies issued revised model risk management guidance (the Federal Reserve’s SR 26-2), replacing SR 11-7 from 2011. The revised guidance states that generative AI and agentic AI models are not within its scope, describing them as novel and rapidly evolving. That does not mean agents are unregulated. It means a bank’s risk team has no dedicated playbook and must fall back on its broader risk management, third-party risk and compliance obligations. Without a template, cautious reviewers ask more questions, not fewer.
If you sell to banks rather than work in one, this lands on you. Your customer’s reviewers will expect the vendor to supply the evidence.
Where the law does bite
Most agent use cases in fintech are not directly regulated as AI. The ones that are tend to involve decisions about individual people.
- Credit decisions in the US. Regulation B requires that the reasons given for adverse action be specific and state the principal reasons. Saying the applicant failed the creditor’s internal standards or did not reach a qualifying score is explicitly not enough. An agent that influences a credit decision in a way nobody can explain creates a compliance problem regardless of how accurate it is.
- Credit scoring in the EU. The EU AI Act lists AI systems used to evaluate the creditworthiness of natural persons or establish their credit score as high-risk, with an exception for fraud detection. After the AI Omnibus amendments, which entered into force on 27 July 2026, the obligations for these stand-alone high-risk systems apply from 2 December 2027. Life and health insurance pricing and risk assessment for individuals sits on the same list.
- Operational resilience and vendors. EU financial entities have been subject to DORA since January 2025, which covers ICT third-party risk. An agent built on an external model API is an ICT third-party dependency, and reviewers will treat it that way.
Notice what is not on this list: an agent that drafts dispute responses for a human to send, reconciles ledgers, summarises KYC files for an analyst, or triages internal tickets. These still need proper controls, but they are ordinary operational risk, not a regulated automated decision.
The questions reviewers will ask, and what a good answer looks like
Every institution words them differently, but the substance repeats. Having written answers ready before the first meeting shortens review more than anything else.
| Reviewer question | Weak answer | Answer that gets approved |
|---|---|---|
| What can it do? | “It uses tools as needed.” | A list of every tool and permission, with read and write access separated |
| What can it never do? | “The prompt tells it not to.” | Hard limits enforced in code: amount caps, blocked actions, approval steps |
| Who is accountable? | “The AI team.” | A named business owner for outcomes, and a named owner for the system |
| How do you know it works? | “We tested it a lot.” | An evaluation set with pass rates, failure cases and the threshold for going live |
| Can we reconstruct a decision? | “We keep chat logs.” | Logs of inputs, retrieved data, each tool call, model version and final action |
| What happens to customer data? | “The vendor is secure.” | Data flows, retention terms, region, and whether data is used for training |
| How do we stop it? | Silence | A tested kill switch and a manual fallback process |
The second row catches more teams than any other. A prompt instruction is not a control. Reviewers know that a model can be talked out of its instructions, so anything that matters, such as a payment limit, must be enforced outside the model.
Design the agent so approval is the easy answer
Start read-only. An agent that gathers information and recommends is far easier to approve than one that acts. Take a hypothetical payments company handling chargeback disputes. Version one pulls the transaction history, merchant evidence and card network reason code, then drafts a response for an analyst. Nothing leaves the building without a person clicking send. That is a productivity tool with a human decision-maker, and review treats it that way.
Earn autonomy with evidence. After a few months of logged recommendations, you can show how often analysts accepted the draft unchanged, where they corrected it, and what those corrections had in common. That record is what justifies letting the agent act alone on the lowest-risk slice, for example disputes under a set amount with a clear reason code.
Put a human at the consequential step, not every step. Human review on everything defeats the purpose and trains reviewers to rubber-stamp. Put approval gates where a mistake costs money, affects a customer’s rights, or cannot be reversed.
Test it adversarially before review does. Prompt injection through a customer email, a document that instructs the agent to change a payee, a tool that returns malformed data. Finding these yourself, and showing the fix, builds trust quickly. We covered how in breaking your AI agent before someone else does.
Pin and record model versions. If your provider updates the model underneath you, behaviour can change. Reviewers will want to know how you detect that and re-run your evaluation set.
When “blocked” is the right answer
Some agent projects should stall. If the use case is making or materially shaping credit decisions and the team cannot produce specific, accurate reasons for each outcome, the review is doing its job. The same applies if customer data would flow to a vendor whose retention and training terms nobody has read, or if nobody in the business will own the outcomes.
A useful internal test: if the agent made its worst plausible mistake tomorrow, could you explain to a regulator, in writing, what happened and why your controls allowed it? If not, the fix is design work, not a better slide for the risk committee.
A practical path to production
- Classify the use case by consequence: internal operations, customer-facing, or decisions about individuals.
- Bring risk and compliance in at the design stage, with the questions above, not after the demo.
- Build the first version read-only, or with approval on every external action.
- Enforce limits in code, log every step, and build a kill switch.
- Create an evaluation set from real cases, including the ugly ones, and agree the go-live threshold in advance.
- Complete vendor due diligence on the model provider and any data processors.
- Go live on a narrow slice, monitor, and expand autonomy only with logged evidence.
If you are still choosing an architecture, how to build your first AI agent without it falling over covers the foundations these controls sit on.
Building agents that are designed to pass review
Most fintech agent projects that stall in compliance review need the controls built properly rather than a better argument. AB7 Solutions builds AI agents and AI workflow automation with those controls as part of the build: scoped tool permissions, approval gates, audit logging, evaluation sets and kill switches, alongside cybersecurity testing of the agent itself and human-in-the-loop review operations for the steps that should stay with people. We can also help prepare the technical documentation your risk team or your bank customer’s reviewers will ask for. We are not your legal counsel, and if a use case needs a regulatory opinion before any build, we will say so.
If your agent is sitting in review, send us the questions you were asked and we will tell you what it would take to answer them.
Email: ab@ab7solutions.com | director@ab7solutions.com
Phone: +91 9878067778 | +1 321 341 7733
Website: www.ab7solutions.com
This article is general information, not legal advice. Sources: Davis Polk on the revised interagency model risk management guidance (2026); Orrick, Agencies overhaul model risk management guidance; Regulation B, 12 CFR 1002.9; EU AI Act, Annex III; European Commission, AI Omnibus enters into force.
[…] Large firms bring breadth, governance frameworks and change management capacity, which matter for multi-country, heavily regulated programmes. Specialist firms and development partners are often faster and cheaper for defined workflows. Many organisations combine the two: a small internal AI lead sets priorities and standards, and specialist teams build. For regulated contexts, the controls reviewers expect are covered in why fintech AI agents stall in compliance review. […]