Banking AI governance in 2026 is a portfolio discipline tied to each use case, legal role, jurisdiction, and action. A credit-scoring model, an AML triage agent, a customer-support assistant, and an agentic payment service can share models and vendors while carrying different regulatory classifications, decision rights, and evidence needs. The common operating requirement is control across the complete lifecycle: inventory, approve, release, authorize each consequential action, monitor outcomes, investigate incidents, and retain evidence.
This guide is for Chief Risk Officers, Compliance Heads, Model Risk leaders, Internal Audit, and AI platform teams. It maps the EU AI Act, DORA, current ECB and EBA material, US model risk guidance, FCA live testing, MAS practice, and HKMA experimentation to an implementable control model. It also corrects a major 2026 change in US guidance: SR 11-7 has been superseded by SR 26-2, and the revised guidance excludes generative and agentic AI from its scope. The result is a regulation × obligation × runtime-control map that a bank can use across credit, financial crime, advisory, operations, and agentic payments. General information only; confirm institution-specific obligations with qualified legal and supervisory counsel.
Executive summary: the banking AI governance standard for 2026
The supervisory signal is clear. More than 85% of banks under European banking supervision use AI, according to a February 2026 ECB Banking Supervision speech. The ECB is widening its focus from credit scoring and fraud detection to generative AI under its 2026-28 priorities. The EBA banking and payments mapping describes the existing financial-sector framework as a strong foundation for EU AI Act implementation while identifying integration work across CRR, CRD, DORA, consumer-credit rules, and payments law.
The governance target is a controlled operating system around AI. Every use case has a business owner, legal classification, accountable risk owner, approved model and provider versions, permitted data and tools, authority limits, monitoring plan, incident path, retention rule, and evidence contract. Agentic use cases add a decision point for each proposed action because the system can select tools and change the next step while it runs.
A single enterprise framework can support many regimes when it preserves their scope. The bank maps each obligation to a control objective, implements the control once where the regimes genuinely align, and records which legal or supervisory assertion each test supports. EBA itself warns that its 2025 mapping is informational and may change with Commission guidance and harmonised standards. Treat cross-framework reuse as governed traceability, with legal conclusions kept explicit.
- Inventory the complete AI system. Record models, orchestration, agents, tools, data, vendors, downstream systems, human roles, customer effects, and jurisdictions.
- Classify from intended purpose and actual use. The same model can sit inside a high-risk credit Process, a lower-impact internal assistant, and an excluded fraud-detection use case.
- Separate lifecycle assurance from action authority. Validation establishes whether a system is fit for an approved use. Runtime controls decide whether a particular proposed action may proceed.
- Make human oversight operational. Name reviewers, define their authority, give them sufficient context and time, record their reasoned decision, and test queue capacity.
- Connect monitoring to intervention. Drift, bias, data-quality, resilience, security, and conduct signals need thresholds, owners, response clocks, rollback criteria, and evidence.
- Design third-party exits before adoption. Record dependencies, concentration, data access, model changes, incident duties, portability, fallback operation, and termination support.
The regulation × obligation × runtime-control map
This map distinguishes binding law, supervisory guidance, and industry references. “Runtime control” means a control applied to the live Process or to a proposed action. It supplements model development, validation, testing, and board governance.
| Source | Scope and status | Governance obligation | Operational control and evidence |
|---|---|---|---|
| EU AI Act | Binding EU regulation; classification and role depend on the system and facts | For covered high-risk systems: risk management, data governance, documentation, logging, human oversight, accuracy, robustness, cybersecurity, deployer monitoring, FRIA where Article 27 applies | System inventory and classification; versioned release approval; decision logs; named human authority; monitoring and incident linkage; current technical documentation |
| DORA | Binding for covered EU financial entities since 17 January 2025 | Management-body accountability; documented ICT risk framework; protection, detection, response, recovery, testing, incident reporting, and ICT third-party risk | Critical-Process mapping; provider and dependency register; failover and recovery tests; change records; incident clocks; evidence tied to the affected service |
| ECB Banking Supervision | Technology-neutral prudential supervision of banks under its remit | Coherent strategy, clear accountability, independent challenge, pre-implementation assessment, lifecycle governance, explainability, monitoring, resilience, and third-party control | Board-approved AI portfolio; second-line challenge record; intended-purpose tests; drift and outcome review; vendor concentration and exit evidence |
| EBA AI Act mapping | Informational mapping; expressly lacks the status of guidance or supervisory expectations | Integrate AI Act work with existing banking and payments law while preserving regulatory roles and supervisory cooperation | One control library with obligation-level traceability; authority map; evidence showing which test supports which regime |
| US SR 26-2 | Interagency supervisory guidance; expected to be most relevant to Fed-supervised banking organizations above $30 billion | Risk-based model governance, inventory, documentation, effective challenge, validation, monitoring, change management, and vendor-model oversight | Applies to traditional quantitative models and non-generative, non-agentic AI. Keep GenAI and agentic AI under a separately approved governance and control determination. |
| FCA existing framework and AI Live Testing | UK regulator using existing rules plus supervised testing; Live Testing is a service | Governance, risk management, monitoring, consumer and market outcomes, and evidence from real-world testing | Bounded live test; acceptance metrics; customer safeguards; live monitoring; incident and stop criteria; documented production decision |
| MAS MindForge and SAFR | MAS-industry implementation resources for AI risk management and agentic-finance safeguards | AI risk-management practices and agentic-finance safeguards | Documented governance basis; bounded authority; escalation route; action records; source-to-control traceability |
| HKMA GenA.I. Sandbox++ | Cross-sector experimentation environment announced in March 2026 | Test generative-AI use cases with relevant regulators and technical support before wider adoption | Defined experiment boundary; participating entities and owners; test evidence; issue log; risk acceptance and exit decision |
EU banking: combine AI Act classification with existing sector controls
For EU banks, the first question is the intended purpose of the AI system in its actual Process. Under Annex III point 5(b) of the EU AI Act, AI intended to evaluate the creditworthiness of natural persons or establish their credit score is listed as high-risk, subject to the Article 6 framework. Point 5(b) expressly carves out systems used to detect financial fraud. The carve-out is specific to that classification route; fraud, AML, sanctions, and payment systems remain subject to financial-sector, privacy, resilience, conduct, and security duties.
Banks can be providers, deployers, or both. A bank that develops an AI system or has one developed and puts it into service under its name may carry provider obligations. A bank using a vendor system under its authority may be a deployer. Article 25 can shift provider responsibility when a party puts its name on a high-risk system, makes a substantial modification, or changes an intended purpose so that the system becomes high-risk. Record the facts, responsible entity, contract allocation, technical changes, and approval whenever a use case changes.
The Digital Omnibus on AI, Regulation (EU) 2026/1744, moved the Annex III high-risk application date to 2 December 2027. The date creates implementation time. It also creates a fixed target for inventory, role analysis, technical documentation, logging, human oversight, accuracy and robustness evidence, deployer controls, and applicable Fundamental Rights Impact Assessments (FRIAs). The EU AI Act hub tracks the full timeline, and the worked credit-scoring FRIA shows the Article 27 assessment for a bank deployer.
EBA’s November 2025 mapping says EU banking and payments law already covers many AI Act control objectives. Its examples span governance, creditworthiness assessment, outsourcing, ICT risk, consumer protection, and payments. The EBA also identifies the need to integrate overlapping requirements and coordinate authorities. The mapping expressly says that it is informational, carries no status as guidance or supervisory expectations, and may change as Commission guidance and standards develop. A bank should retain the legal mapping version and rationale used for each release.
- Credit decisioning: classify the system, document provider and deployer roles, complete applicable FRIA work, validate model and data, define human authority, preserve logs, monitor customer outcomes, and connect complaints to remediation.
- Fraud and AML: record the classification analysis, preserve the point 5(b) fraud carve-out reasoning where relevant, apply DORA and financial-crime controls, constrain automated closure or filing authority, and retain reconstructable alert lineage.
- Customer assistants: assess Article 50 transparency, consumer-protection and privacy duties, permitted advice boundaries, hallucination and data-leak controls, handoff, monitoring, and complaints.
- Agentic payments: define the mandate, transaction and aggregate limits, recipient and rail restrictions, sanctions and fraud checks, step-level authorization, reversal handling, and human escalation.
DORA makes AI operational resilience a management-body concern
DORA has applied to covered financial entities since 17 January 2025. Article 5 assigns the management body responsibility for the ICT risk framework and requires clear roles, continuity arrangements, audit plans, and ICT knowledge. Article 6 requires a sound, comprehensive, and documented ICT risk management framework. Those duties apply when AI supports a critical or important function, depends on ICT providers, handles production data, or changes how the service detects, responds to, and recovers from disruption.
AI governance teams should connect the model and agent inventory to DORA’s ICT assets, business functions, dependencies, incidents, tests, and third-party register. A model card alone cannot show whether a credit, payments, or AML Process continues safely through a model outage, malformed output, vendor API degradation, retrieval failure, prompt injection, or tool timeout. The operating record needs service effects, fallback behavior, recovery objectives, actual test results, and the owner who accepted residual risk.
Third-party AI deserves a full dependency view. Record the model and hosting providers, subprocessors, regions, data paths, update rights, service levels, security and incident duties, audit access, portability, fallback model or manual route, and exit plan. The ECB also highlights concentration, vendor lock-in, confidentiality, security, resilience, and exit risk for generative AI. Tie contract obligations to tests and observed operations so the register remains useful during an incident.
| Control question | Minimum evidence |
|---|---|
| What service and function depend on AI? | Process map, asset and provider relationships, data flows, business owner, criticality decision |
| How does the Process fail safely? | Timeout, fallback, manual operation, capacity, recovery objective, and completed test results |
| How are changes controlled? | Approved versions, release record, validation, configuration diff, rollback criterion, rollback test |
| How are incidents detected and handled? | Signals, thresholds, event timeline, classification, notification decision, response and recovery record |
| Can the bank exit the provider? | Export and portability evidence, alternate route, data-return or deletion proof, tested transition plan |
ECB and EBA expectations: accountability, challenge, and lifecycle control
ECB Banking Supervision’s February 2026 position is technology-neutral and risk-focused. The speech identifies governance gaps around clear accountability, senior-management oversight, independent challenge, AI-specific data quality, explainability, lifecycle model governance, drift, and third-party risk. It calls for pre-implementation assessments, second-line involvement, and post-implementation monitoring. These are operational requirements: a committee name is weak evidence without an approved decision, challenge record, action owner, and verified closure.
Explainability should serve the person making or reviewing the decision. A model validator needs methods, limitations, sensitivity, and outcome analysis. A credit officer needs the factors relevant to the applicant and the authority to question the result. A customer needs an intelligible explanation and a workable route to review. Internal Audit and supervisors need a stable link from system version and data to the decision, control result, human action, and downstream effect.
The EBA mapping supports integration with existing controls. It also reinforces role and authority complexity: financial supervisors may serve as market-surveillance authorities for certain high-risk systems, while national designations and other AI systems can involve different authorities. Maintain a jurisdictional authority map and a regulatory-change owner. Each incident or material change should route through that map before notification clocks expire.
SR 11-7 AI searches now lead to SR 26-2
On 17 April 2026, the Federal Reserve, OCC, and FDIC issued SR 26-2, Revised Guidance on Model Risk Management. It supersedes and replaces SR 11-7 and SR 21-8. Any 2026 policy, vendor questionnaire, or control map that still treats SR 11-7 as current needs correction.
SR 26-2 emphasizes a risk-based approach tailored to the banking organization’s model risk profile, size, complexity, and model use. The guidance covers governance, inventory, documentation, effective challenge, validation, ongoing monitoring, change management, and vendor models. For Federal Reserve-supervised organizations, the letter says it is expected to be most relevant above $30 billion in total assets. Supervisory guidance lacks the force and effect of law, while violations of law and unsafe or unsound practices can still support supervisory action.
The scope boundary is crucial for an AI governance program. Footnote 3 excludes generative AI and agentic AI models because they are novel and rapidly evolving. The principles apply to traditional statistical and quantitative models and non-generative, non-agentic AI. The same footnote says a banking organization’s risk management and governance practices should determine suitable controls for tools, processes, and systems outside the guidance.
A bank therefore needs two linked inventories. The model inventory applies SR 26-2 to in-scope models. The broader AI-system inventory includes generative and agentic systems, their orchestration, tools, data, authority, vendors, and business consequences. The bank approves an explicit governance basis for those out-of-scope systems through operational risk, information security, third-party risk, conduct, compliance, privacy, legal, and business controls. An agent that calls a credit model can contain both layers: the quantitative credit model may be in SR 26-2 scope, while the generative or agentic orchestration is excluded and governed under the bank’s separate determination.
| System component | SR 26-2 position | Governance treatment |
|---|---|---|
| Traditional statistical credit model | Within scope when it meets the guidance definition | Inventory, documentation, effective challenge, validation, monitoring, change and vendor controls proportionate to risk |
| Non-generative, non-agentic machine-learning model | Principles apply | Risk-based model risk management, including outcome analysis and ongoing monitoring |
| Generative assistant | Explicitly excluded | Document the bank-approved governance basis, data and access constraints, testing, monitoring, human use rules, and incident path |
| Agentic payment or operations system | Explicitly excluded | Add identity, mandate, tool and data permissions, per-action decisions, human escalation, execution evidence, limits, and containment |
UK and Asia: supervised testing is becoming a governance capability
The UK FCA is applying its existing framework and building evidence through supervised testing. Its second AI Live Testing cohort, announced on 21 April 2026, includes agentic payments, AML, Know Your Customer, credit-score insights, investments, and other customer and business uses. The service focuses on risk management and live monitoring, with testing through the end of 2026 and an evaluation report planned for the first quarter of 2027.
The FCA’s July 2026 Mills Review adds a consumer lens. It describes changes to firm operations, customer journeys, competition, fraud, and cyber risk, and reports consumer interest in agentic personal-finance tools. A UK bank should translate that signal into outcome metrics, vulnerable-customer safeguards, action limits, complaint handling, fraud controls, monitoring, and a recorded decision before scaling.
In Singapore, the MAS Project MindForge Operationalisation Handbook is a MAS-industry AI risk management resource. MAS later published Safeguards for Agentic Finance at Runtime (SAFR) and a media release on the industry initiative. These sources address AI risk management and safeguards for agentic finance. This guide uses them as implementation references. Applicable law and supervisory expectations determine each institution’s obligations. The SAFR explainer, implementation guide, AML walkthrough, and EU AI Act and FINMA crosswalk present KLA’s interpretation and implementation approach.
The HKMA GenA.I. Sandbox++ announcement opened cross-sector applications through 30 June 2026 for banks and other regulated entities. The current deadline has passed; the durable lesson is the test discipline. Define the use case, participating entities, relevant regulators, data boundary, success measures, risk hypotheses, customer safeguards, technical evidence, issue handling, stop conditions, and production decision before live experimentation.
Use one operating model across the three lines
Banking AI governance becomes durable when ownership follows the system into production. The first line owns the business outcome, Process, risk acceptance, operating procedures, and control execution. The second line sets risk frameworks, challenges classification and release decisions, reviews monitoring and incidents, and tracks remediation. Internal Audit assesses design and operating effectiveness with independent evidence. Model Risk, information security, privacy, compliance, financial crime, resilience, procurement, legal, and customer-outcome teams contribute according to the use case.
Create a named AI system owner and a named Process owner. The system owner maintains inventory, intended purpose, versions, providers, data and tool boundaries, validation, and monitoring. The Process owner owns the business decision, human roles, service effects, customer handling, and fallback. A model owner alone cannot carry responsibility for an agent that calls multiple models and tools across a customer journey.
| Decision | Accountable owner | Required challenge | Evidence |
|---|---|---|---|
| Approve intended purpose and risk tier | Business and AI system owners | Compliance, Legal, Model Risk, Operational Risk | Use-case record, classification, jurisdiction and role analysis |
| Approve model and provider versions | AI system owner | Model Risk, Security, Third-Party Risk | Validation, due diligence, limitations, contract and exit evidence |
| Approve production Release | Process owner | Second line and change authority | Acceptance criteria, Simulation results, monitoring and rollback plan |
| Authorize a consequential action | Policy-defined owner or reviewer | Role and maker-checker enforcement | Policy outcome, reason, reviewer identity, rationale, timestamps |
| Accept a monitoring breach | Process and risk owners | Relevant second line | Alert, investigation, decision, remediation and retest |
| Close an incident | Incident owner | Risk, Compliance, Security, Legal as applicable | Timeline, impact, notifications, recovery, root cause and control changes |
Design controls around actions and consequences
Model tiers remain useful, yet agentic systems require an action view. The same agent can draft a customer message, retrieve internal data, change a credit limit, and initiate a payment. Each action carries a different authority, reversibility, financial materiality, customer effect, regulatory sensitivity, and novelty. Record those factors in policy and assign a closed outcome before execution.
A practical outcome vocabulary is: routine action proceeds; action proceeds with an observation; action pauses for a named human decision; action is blocked. The bank decides thresholds and reviewer authority. A previous approval grants no authority to the next step unless the mandate expressly says so. This pattern is explained in the runtime governance layer glossary and the SAFR cluster.
| Action | Default control | Escalation trigger | Evidence |
|---|---|---|---|
| Draft an internal summary | Allow within approved data boundary | Sensitive-data retrieval, unsupported claim, prohibited destination | Inputs, sources, data boundary, output, warnings |
| Recommend a credit outcome | Run approved model and policy; hold final decision where required | Policy exception, low confidence, protected-group signal, material data gap | Model and policy versions, factors, tests, reviewer record |
| Auto-close an AML alert | Permit only narrow, validated low-risk classes | Sanctions hit, high value, novel pattern, missing evidence, policy conflict | Alert facts, tools, controls, disposition, downstream state |
| File a suspicious-activity report | Human-reserved action | Every attempted agent filing | Blocked attempt or named maker-checker approvals and filing record |
| Initiate a payment | Mandate, recipient, amount, rail, velocity, fraud and sanctions checks | New beneficiary, threshold breach, anomaly, irreversible rail | Envelope, mandate, control results, decision, transaction result |
| Change production configuration | Governed Release with separation of duties | Scope expansion, new tool or data, failed validation, missing rollback | Diff, approvals, tests, rollout, monitoring and rollback status |
The minimum runtime evidence contract
An evidence contract defines what the Process must record before a consequential action can complete. It supports investigation, customer review, model monitoring, resilience, audit, and regulatory response. The record should be structured, searchable, retention-controlled, and protected against undetected alteration. The tamper-evident lineage glossary explains the integrity property, and the execution-lineage product page shows the product concept.
- Identity and ownership: AI system, agent or service identity, version, tenant or legal entity, business owner, Process owner, and acting human identity where present.
- Authority: mandate, permitted action and tools, data boundary, transaction or exposure limits, validity window, separation-of-duties requirement, and policy version.
- Proposal: action type, parameters, target, material context, input provenance, model and orchestration versions, and relevant uncertainty.
- Decision: applicable rules, machine-readable reasons, allow, warn, require_approval, or block outcome, timestamp, latency, and any failed dependency.
- Human oversight: Decision Request, reviewer role and authority, context shown, approve or decline outcome, rationale, modifications, and elapsed time.
- Execution: downstream request and response, state change, business outcome, error, reversal, rollback, and reconciliation status.
- Assurance: monitoring signals, samples, threshold breaches, complaints, incidents, investigation, remediation, retest, and closure authority.
- Integrity and retention: append-only record, verifiable export, access history, retention basis, legal hold, deletion or expiry, and independent verification result.
A 365-day implementation roadmap
Sequence the program around one complete Process, then reuse the tested control pattern. A broad inventory with no operating evidence gives leaders a weak view of residual risk. A narrow pilot with no enterprise inventory leaves unmanaged systems outside the frame. Run the inventory and the first governed Process in parallel.
| Period | Deliverables | Exit test |
|---|---|---|
| Days 0-30 | Executive mandate; owners; inventory schema; jurisdiction and role fields; risk-tier method; first Process selected; evidence contract drafted | The bank can name every component, owner, authority boundary, legal question, and consequential action in the pilot Process |
| Days 31-90 | Classification; provider and deployer analysis; model and vendor review; data and tool boundaries; policies; human roles; monitoring; fallback; Simulation | Negative tests block unauthorized actions; reviewers can decide within service levels; evidence reconstructs each run |
| Days 91-180 | Controlled production; sampling; customer and business outcomes; drift and resilience tests; incident exercise; independent evidence review | First and second lines operate controls, Internal Audit can test the record, and failures lead to bounded recovery |
| Days 181-365 | Control-library reuse; portfolio reporting; supplier concentration and exit tests; FRIA and high-risk evidence completion where applicable; audit plan | Board reporting traces portfolio risk to observed controls, outcomes, incidents, remediation, and remaining exceptions |
How KLA maps the operating model to runtime controls
KLA Control Plane provides a control and evidence layer for governed AI-agent Processes. Agent Registry records the acting system and owner. Policy Builder holds versioned rules and authority constraints. The KLA Policy Engine returns one of four decisions: allow, warn, require_approval, or block. require_approval creates a Decision Request for a named, authorized reviewer on the Decision Desk. Audit Trail and Lineage Records connect the action, policy, decision, human intervention, and execution result. Sealed Evidence Bundles support offline integrity verification.
The product mapping does not decide a bank’s legal classification, risk appetite, supervisory obligations, or final policy. The bank defines the mandate, rules, thresholds, reviewers, retention, and deployment boundary. Each use case must be connected to the governed execution path and tested in its real environment before the runtime record supports an operating-effectiveness claim.
Start with the financial-services solution, review policy-as-code, inspect the Evidence Room sample, and use Control Mapping to connect controls to framework obligations. The governing AML and payments agents guide covers the financial-crime Process in detail. For one scoped Process, book a briefing.
Primary sources and status boundaries
These primary regulator and legal sources support the legal dates, scope statements, supervisory signals, and testing programs in this guide. Re-check them for updates before a governance or legal decision.
- European Union: Regulation (EU) 2024/1689, EU AI Act; Regulation (EU) 2026/1744, Digital Omnibus on AI; Regulation (EU) 2022/2554, DORA.
- ECB Banking Supervision: Technology is neutral, governance is not: AI adoption in the banking sector, 24 February 2026; Supervisory priorities 2026-28.
- European Banking Authority: AI Act: implications for the EU banking and payments sector, 21 November 2025. The EBA states that the mapping is informational and lacks the status of guidance, supervisory expectations, legal position, or advice.
- United States: SR 26-2, Revised Guidance on Model Risk Management and its attachment, 17 April 2026.
- United Kingdom: FCA AI Live Testing second cohort, 21 April 2026; Mills Review on AI in retail financial services, 6 July 2026.
- Singapore: MAS Project MindForge and the AI Risk Management Operationalisation Handbook; Safeguards for Agentic Finance at Runtime (SAFR) and the MAS media release on SAFR. This guide cites them as MAS-industry implementation resources. Applicable law and supervisory expectations determine regulatory status and compliance obligations.
- Hong Kong: HKMA GenA.I. Sandbox++ announcement, 5 March 2026.
- Basel Committee: Digitalisation of finance, May 2024, including observed GenAI risk-management practices; ICT risk management: range of practices, 2 June 2026.
Frequently Asked Questions
What is AI governance in banking?
AI governance in banking is the system of ownership, decision rights, controls, monitoring, and evidence applied to an AI system and the banking Process around it. It covers intended purpose, models, data, tools, providers, human roles, customer and prudential effects, releases, live actions, incidents, and retirement.
Is SR 11-7 still current for bank AI model risk management?
No. On 17 April 2026, the Federal Reserve, OCC, and FDIC issued SR 26-2, which supersedes and replaces SR 11-7 and SR 21-8. Control maps and policies should cite SR 26-2 and preserve its risk-based scope.
Does SR 26-2 apply to generative AI or agentic AI?
SR 26-2 explicitly excludes generative AI and agentic AI. Its principles apply to traditional statistical and quantitative models and non-generative, non-agentic AI. The guidance says bank risk-management and governance practices should determine suitable controls for tools, processes, and systems outside its scope.
Which banking AI systems are high-risk under the EU AI Act?
Annex III point 5(b) lists AI systems intended to evaluate the creditworthiness of natural persons or establish their credit score, subject to the Article 6 framework. The point contains an express exception for systems used to detect financial fraud. Classification still depends on intended purpose, actual use, role, and the complete system facts.
How does DORA apply to AI in banks?
DORA applies through the ICT-supported financial service and its dependencies. For AI supporting critical or important functions, banks should connect the AI inventory to ICT assets, providers, incidents, resilience tests, continuity, recovery, change management, and third-party exit evidence.
What evidence should a bank retain for an AI-agent action?
Retain the acting identity and version, owner, mandate and permissions, proposed action and context, model and policy versions, rules and decision, human approval or rejection, downstream execution result, monitoring signals, incidents, remediation, retention basis, and integrity-verification result.
Is MAS SAFR a regulation?
This guide cites SAFR as a MAS-industry implementation resource on safeguards for agentic finance. Applicable law and supervisory expectations determine each institution’s obligations.
How should a bank start an AI governance program?
Establish accountable owners and one inventory schema, choose one consequential Process, classify it, define authority and evidence, implement policies and human escalation, run negative tests and Simulation, operate a controlled production pilot, and have the second line and Internal Audit test the resulting evidence.
Key Takeaways
Banking AI governance in 2026 begins with a complete inventory and ends with evidence from live operation. The bank classifies each use case, assigns legal and supervisory roles, validates models and providers, defines authority, controls each consequential action, equips humans to decide, monitors business and customer outcomes, responds to incidents, and proves the record. EU AI Act, DORA, ECB and EBA scrutiny, SR 26-2, FCA testing, MAS implementation work, and HKMA experimentation each reinforce part of that operating model. Their legal force and scope differ, so the control library must preserve the source of every assertion.
For agentic finance, add identity, explicit mandates, per-action decisions, bounded tools and data, structured escalation, and tamper-evident lineage. Use the SAFR Readiness Checklist to assess one Process, inspect the Evidence Room sample, and book a briefing when the owners and action boundary are ready.