Technology

AI Is Becoming Banking Infrastructure—But Who Is Auditing the Algorithms?

Aug 13, 2026 • 14 min read

AI is moving from analytical tool to operational layer. The challenge is no longer simply to validate a model before release, but to continuously assure systems that banks may not fully build, fully observe or fully control.

For decades, banking knew what a model audit looked like. A credit score, a market-risk model or an expected-loss engine had a defined purpose, a controlled input set, a methodology that could be documented, and outputs that could be back-tested. Independent validation could challenge the assumptions and internal audit could assess whether governance around the model was working.

Artificial intelligence is stretching that architecture. A modern AI system can combine a foundation model with proprietary data, retrieval tools, prompts, business rules, workflow software and human approvals. It may be updated by an external provider without a bank retraining anything. An agentic system can go further, choosing which tool to use, deciding what information to retrieve and initiating actions within preset permissions. The object that needs assurance is therefore no longer just the model. It is the entire decision system around it.

That turns a familiar model-risk question into a governance question: who is qualified and sufficiently independent to say that an AI-enabled banking process remains accurate, fair, secure, resilient and within risk appetite after it goes live? The answer is emerging, but it is not a single auditor or a single global standard. It is an assurance stack spanning business owners, risk and compliance, model validators, internal audit, supervisors and, in narrower circumstances, external assurance providers.

AI is no longer a collection of pilots

The scale of adoption is already large enough to make this an infrastructure question. In the Bank of England and Financial Conduct Authority's 2024 survey of UK financial services, 75% of responding firms said they were already using AI and another 10% planned to do so within three years. Foundation models accounted for 17% of reported AI use cases. More importantly for assurance, 55% of use cases involved some degree of automated decision-making, even though only 2% were described as fully autonomous.

The same survey shows why traditional oversight gets harder as adoption scales. A third of AI use cases were third-party implementations, while 46% of firms reported only a partial understanding of the AI technologies they use. The top three named providers represented 73% of reported cloud providers and 44% of reported model providers. In other words, banks are embedding AI while simultaneously increasing dependence on technology they do not fully own.

This is not only a UK concern. The Financial Stability Board's assessment of AI in finance identifies third-party concentration, cyber risk, market correlations, model risk, data quality and governance as channels through which AI could amplify vulnerabilities. Once many institutions rely on similar models, data sets or infrastructure providers, an assurance failure can become more than an idiosyncratic model error.

Model validation is necessary - but no longer sufficient

One regulatory response is to extend existing model-risk disciplines. The UK Prudential Regulation Authority's SS1/23 on model risk management, whose current version became effective on 23 April 2026, is built around model identification and classification, governance, development and use, independent validation, and model-risk mitigants. It explicitly says banks should identify and manage risks from artificial intelligence and machine learning to the extent that those technologies are used in modelling.

The United States has taken a more deliberately bounded approach. On 17 April 2026, the Federal Reserve, OCC and FDIC issued revised interagency model-risk guidance that replaced the 2011 framework and emphasised proportionality. Crucially, it says generative AI and agentic AI are outside the guidance's scope because they are novel and rapidly evolving, while traditional quantitative models and non-generative, non-agentic AI remain within scope.

That exclusion is not an argument for no controls. In a May 2026 speech, Federal Reserve Vice Chair for Supervision Michelle W. Bowman said banks are relying on existing risk-management frameworks and argued that supervisors should assess whether those tools are fit for the future rather than stretching old model guidance to cover technologies it was not designed for. The tension is useful: treating every AI feature as a classical model can produce compliance theatre, but treating generative or agentic systems as merely software can miss material decision risk.

For banks, the practical answer is to separate taxonomy from accountability. An AI system does not become low-risk because it falls outside a particular model-risk definition. If it can affect a customer decision, move money, alter a risk assessment, generate regulatory content or change a control outcome, the bank still needs evidence that the system behaves within defined limits. Model validation is one component of that evidence, not the whole of it.

Europe has created rules, not a universal external auditor

The European Union has gone furthest in creating an explicit AI legal framework, but even there the word "audit" can mislead. The AI Omnibus entered into force on 27 July 2026, extending the application date for Annex III high-risk AI requirements to 2 December 2027 and for high-risk AI embedded in regulated products to 2 August 2028. Other parts of the AI Act, including certain transparency and general-purpose AI provisions, became enforceable from 2 August 2026 under the European Commission's implementation timeline.

For banking, the classification matters. Annex III of the AI Act lists systems used to evaluate the creditworthiness of natural persons or establish a credit score as high-risk, with an exception for systems used to detect financial fraud. Yet high-risk does not automatically mean a third-party auditor signs off every system. Under Article 43's conformity-assessment rules, systems in Annex III points 2 to 8 generally follow an internal-control conformity assessment rather than a notified-body assessment.

That distinction is important. Europe is creating enforceable obligations around risk management, data governance, documentation, logging, human oversight, accuracy, robustness and cybersecurity, but much of the first-line proof still has to be generated by the provider and deployer. Regulators and market-surveillance authorities can challenge and enforce. They do not replace the institution's own assurance machinery.

The real audit target is the system, not the model

A defensible AI audit starts by tracing a decision from purpose to outcome. The central question is not simply whether a model has an acceptable accuracy score. It is whether the bank can reconstruct what information shaped a decision, which model and software version were active, what tools the system could call, what human intervention was available, and what happened when conditions moved outside expected ranges.

A defensible assurance scope

Layer	Core question	Evidence that should exist
Purpose and accountability	Is the system permitted to make or influence this decision?	Use-case inventory, risk tier, named owner, approved limits and escalation path.
Data and context	What information shaped the output?	Data lineage, retrieval sources, quality tests, privacy controls and evidence of representativeness.
Model behaviour	Does performance remain inside tolerance?	Independent validation, scenario tests, calibration, robustness, bias and error analysis.
Actions and human control	What can the system do, and where must a person intervene?	Tool permissions, transaction or action limits, approval gates, override and suspension controls.
Change and third parties	What can change without the bank rebuilding the system?	Version records, provider notices, change tests, contractual audit rights, incident and continuity arrangements.
Outcomes	What is actually happening to customers and risk in production?	Drift metrics, false positives and negatives, overrides, complaints, losses, exceptions and remediation evidence.

Source: Global Banking & Finance Review analysis of supervisory, risk-management and AI-governance frameworks cited in this article.

This system-level view changes testing. A conventional statistical model can often be challenged with a defined validation data set and stable performance metrics. A generative model may produce different wording across runs; a retrieval-augmented system may change when its knowledge base changes; an agent may follow a different sequence of tool calls depending on context. Assurance therefore has to test distributions of outcomes, boundary cases and failure modes, not merely reproduce one expected answer.

The audit trail also has to capture more than an output. For consequential use cases, banks increasingly need to retain enough evidence to reconstruct the model version, system instructions, relevant retrieved information, decision rules, tool permissions and human overrides. Without that lineage, explainability can become retrospective storytelling rather than verifiable assurance.

Cybersecurity belongs inside the same scope. Prompt injection, data leakage, insecure tool use and excessive permissions can turn a model that performs well in a laboratory into a weak control in production. The NIST Generative AI Profile provides a cross-sector framework for managing generative-AI risks across design, development, use and evaluation. It is not bank-specific regulation, but it is a useful reminder that trustworthy AI is an operational lifecycle problem, not a one-off validation event.

The third-party problem is becoming the audit problem

Vendor dependence is where the theory of independent validation meets commercial reality. The Bank of England/FCA survey found that third-party AI implementation had doubled as a share of reported use cases since 2022. It also found that firms understood externally supplied AI less completely than systems developed internally. That gap matters because a bank can be accountable for a decision without having access to a provider's training data, model weights or complete development history.

Traditional vendor-model governance still offers a starting point. The 2026 U.S. interagency guidance says sound practice for vendor models includes developing an understanding of conceptual soundness, design, development data and performance, with ongoing monitoring and outcome analysis. But frontier and generative models make full replication unrealistic in many cases. The assurance objective therefore shifts from "inspect everything" to "obtain enough independent evidence to control the risk."

That makes contract design part of auditability. Material AI procurement increasingly needs clear provisions on model and version changes, testing access, security and incident notification, data use and retention, subcontractors, logging, service continuity and exit options. Where a provider will not expose proprietary internals, banks can still require evidence about evaluations, known limitations, update processes and production incidents, and they can independently test the system at the boundary where it interacts with bank data and decisions.

The most dangerous governance assumption is that outsourcing the model outsources the risk. It does not. A bank may rent intelligence, infrastructure and data, but it still has to know what decisions the combined system is making on its behalf and whether those decisions remain within law, policy and risk appetite.

So who should audit the algorithm?

The answer is not a new "AI auditor" sitting outside the existing control framework. It is a clearer division of assurance responsibilities. The business and technology teams that deploy the system have to own pre-production testing, monitoring and evidence. Risk, compliance, operational-resilience and model-risk functions should independently challenge materiality, validation, consumer and conduct risks, data controls, security and third-party dependencies. Internal audit then has a different role: it should test whether those first and second-line controls are well designed, sufficiently independent and actually operating.

That structure is consistent with the Basel Committee's current guidance on the internal audit function in banks, which places independent, competent internal audit at the centre of sound governance and gives it a direct assurance relationship with the board. The critical word is independent. A team that designed the prompt library, approved the vendor and defined the acceptance threshold cannot be the only team that certifies those choices.

Supervisors are also beginning to build their own technical capability rather than relying solely on documents supplied by firms. The BIS Innovation Hub's Project Noor, developed with the Hong Kong Monetary Authority, the UK Financial Conduct Authority and the Saudi Central Bank, is prototyping tools that help supervisors evaluate model transparency, fairness and robustness. Noor explicitly does not replace a financial institution's responsibility for explainability; it illustrates the direction of travel toward supervisors being able to challenge AI systems with independent technical tools.

External assurance can complement this stack, but it should not be confused with a universal bank-algorithm audit. Financial-statement auditors focus on financial reporting and related controls, so their work may touch models that affect valuations, provisions or reporting without covering every customer-facing or operational AI system. Likewise, ISO/IEC 42001 provides an AI management-system standard for governance and continual improvement. ISO itself describes the standard as organisation-wide management of AI risks rather than inspection of the technical details of specific applications. That makes certification useful as governance evidence, but not a substitute for use-case-specific validation and supervisory accountability.

The scarce resource is independent technical judgement

The governance chart is easier to draw than the capability model. Many banks have experienced credit modellers, cyber teams, compliance officers and internal auditors, but fewer people who can combine statistical validation with an understanding of large-language-model behaviour, software architecture, data lineage, consumer law and operational resilience. That multidisciplinary gap is where weak assurance can hide behind impressive policy documents.

Internal audit therefore needs enough technical depth to challenge, reproduce and interpret testing rather than merely confirm that testing occurred. In some institutions that will mean dedicated AI assurance specialists; in others it will mean co-sourcing specialist expertise. Either way, independence has to be protected. External specialists can support the third line, but they should not simply repackage the same vendor evidence already used by the first line.

Boards and audit committees also need a different kind of reporting. A count of AI use cases says little about risk. More useful questions are whether material systems have current independent assurance, whether unresolved findings are concentrated in customer or control-critical processes, whether vendors changed models without timely testing, whether override and complaint rates are shifting, and whether the bank can suspend an AI component without breaking a critical service.

Continuous assurance, not annual theatre

AI challenges the calendar as much as the methodology. A point-in-time audit can be obsolete after a provider update, a retrieval change, a new tool permission or a shift in customer data. High-impact systems therefore need event-driven revalidation and continuous monitoring, with defined triggers for escalation when performance, security, complaints, outcomes or model versions change materially.

But more assurance is not automatically better assurance. The Bank of England/FCA survey found that 62% of reported AI use cases were rated low materiality by the firms using them. Applying heavyweight validation to every low-risk productivity feature can slow useful innovation and encourage workarounds. The U.S. agencies' 2026 emphasis on risk-based model governance is an important counterweight: controls should be proportionate to the consequences of failure, the degree of autonomy, the sensitivity of data and the reversibility of the outcome.

The destination is therefore proportionate continuous assurance. Low-risk tools can operate within standard technology, data and access controls. Systems that influence lending, fraud actions, compliance alerts, pricing, capital, liquidity, payments or other material decisions should face stronger validation, more granular logging, tighter change governance and faster escalation. The audit architecture should become stricter as the system moves closer to money, customers and regulatory obligations.

What this means for banks, fintechs, regulators and investors

For banks, the priority is to build an inventory of AI-enabled decisions rather than merely an inventory of models. Each material decision path should link to an accountable owner, approved purpose, data sources, model and software versions, third-party dependencies, controls, validation status and production outcomes. That evidence should be designed for audit from the start, not assembled after a problem.

For fintechs and AI vendors, auditability is becoming a product attribute. Providers that can supply stable versioning, change notices, evaluation evidence, configurable logging, clear data-handling commitments and credible incident processes will be easier for regulated institutions to adopt at scale than black boxes that offer performance without assurance.

For regulators, the next challenge is comparability. If every bank measures robustness, fairness, drift and explainability differently, supervisors will struggle to compare risk across firms. Projects such as Noor point toward a future of common test methods and supervisory tooling, while the EU AI Act is creating a more formal documentation and enforcement layer. The remaining task is to align those approaches with sector-specific prudential and conduct regimes without duplicating controls.

For investors, AI governance should increasingly be read as an operational-risk signal. Institutions that cannot evidence control over model changes, third-party concentration and automated decisions may discover that the cost of AI is not a failed experiment but a compliance event, customer-remediation programme, cyber incident or service disruption. The quality of assurance can therefore matter as much as the headline level of AI adoption.

Conclusion: the audit trail is becoming financial infrastructure

Banking has spent decades building independent assurance around capital models, financial reporting, cybersecurity and operational resilience. AI does not erase those disciplines; it connects them. The most important change is that assurance has to follow the entire decision system - model, data, software, vendor, permissions, human oversight and outcomes - and it has to remain current as that system changes.

The strongest banks will not be the ones that can say they use the most AI. They will be the ones that can produce credible, independent evidence that their AI remains within defined limits in production, including when the underlying technology is supplied by someone else. As AI becomes banking infrastructure, the audit trail has to become infrastructure too.