GRC Priorities for Banking and Financial Services in 2026

What Is Driving GRC Priorities In Banking And Financial Services In 2026

Banking and financial services institutions entered 2026 with several major regulatory regimes shifting from design to enforcement simultaneously. This convergence is unusual even by the standards of a sector accustomed to regulatory change, and it is forcing GRC, risk, and compliance leaders to rethink how their programs are structured.

A recent industry survey found that reported use of advanced AI tools in KYC and AML processes surged from 42% in 2024 to 82% in 2025, with Singaporean firms leading at 92%, followed by the US at 79% and the UK at 77%, according to Fenergo's Financial Crime Industry Trends 2025 report. This shift toward automation is happening in parallel with a wave of regulatory deadlines that are no longer theoretical. DORA enforcement is underway, Basel IV capital rules are now in force, and the EU AI Act's high-risk provisions take effect in August 2026, with direct implications for core banking AI systems.

The institutions navigating this landscape most effectively share a common trait. They are building GRC architectures that connect regulatory obligations, risk data, and control testing into a single operating model rather than maintaining separate compliance tracks for each regulation. This article examines the regulatory developments shaping 2026, the technology trends supporting them, and the practical steps banking and financial services organizations should be taking now.

DORA Enforcement Has Moved From Preparation To Supervision

DORA became fully applicable on 17 January 2025, and the regulatory conversation has shifted decisively from readiness planning to active oversight. National competent authorities across the EU are now conducting formal assessments of how financial entities have implemented the regulation's five pillars: ICT risk management, incident reporting, digital operational resilience testing, third-party risk management, and information sharing arrangements.

• ICT risk management frameworks are under direct scrutiny: Supervisors are reviewing whether boards and senior management have taken ownership of ICT risk strategy, not delegated it entirely to technology functions. Institutions are expected to demonstrate that ICT risk management is integrated into the broader enterprise risk framework rather than treated as a standalone IT concern.
• Incident reporting timelines are being tested in practice: The requirement to report major ICT-related incidents within tight regulatory windows means institutions need workflows that can classify, escalate, and report incidents without manual bottlenecks. Several supervisory updates issued through 2025 refined the technical standards for how these reports must be structured.

Legal commentators have noted that while major enforcement actions did not dominate headlines in 2025, 2026 is widely expected to mark DORA's transition into a maturity phase, with a steadier rhythm of supervisory engagement focused on operational resilience outcomes rather than only on documentation.

Basel IV's Standardized Measurement Approach Has Changed Operational Risk Capital 

The Basel IV framework, implemented in the EU from 1 January 2025 through CRR III, replaced the previous menu of operational risk approaches with a single Standardized Measurement Approach. This is one of the most consequential changes for operational risk GRC functions in over a decade, because it directly ties the quality of a bank's internal loss event data to its capital requirements.

Under the SMA, operational risk capital is calculated using a Business Indicator combined with an Internal Loss Multiplier for larger banks, meaning historical operational losses now flow directly into the capital calculation. This makes data quality, completeness, and governance around loss event databases a Pillar 1 capital issue rather than a secondary operational risk management concern. 

• Loss data governance now has capital consequences: Banks that previously treated loss event collection as a risk management exercise must now ensure that data is complete, accurately categorized, and defensible under supervisory review, because errors or omissions can directly affect capital requirements.
• The output floor changes how internal models interact with standardized approaches: The output floor began phasing in at 50% in 2025 and will rise progressively through the rest of the decade, limiting the capital benefit banks can obtain from internal ratings-based models relative to standardized approaches. This affects how risk and finance functions plan capital allocation.

EU AI Act High-Risk Provisions Bring AI Governance Into Core Banking Operations

The EU AI Act entered into force in August 2024, with obligations phasing in over several years. The provisions most relevant to banking, those governing high-risk AI systems, become fully applicable on 2 August 2026. For banks, this deadline applies directly to AI systems already running in production. Under Annex III of the Act, AI systems used to evaluate the creditworthiness of natural persons or establish credit scores are explicitly classified as high-risk, as are AI systems used in life and health insurance risk assessment and pricing. Fraud detection systems occupy a more nuanced position. Systems used specifically to detect financial fraud are generally carved out of the high-risk category, but fraud-related systems that produce automated decisions restricting access to financial services, such as automatic account blocking, may still fall within scope depending on their function.

• AI system inventories are the starting point for every bank: Institutions need a complete inventory of AI systems used across credit decisioning, fraud detection, AML transaction monitoring, insurance underwriting, and customer-facing automated decision-making, covering both in-house and vendor-supplied systems.
• Classification determines the compliance pathway: Once inventoried, each system must be assessed against Annex III criteria. For the financial services use cases most commonly affected, self-assessment conformity pathways are permitted, but the assessment must be fully documented and evidence-based rather than a checklist exercise.
• Human oversight must be meaningful rather than procedural: A recurring theme in regulatory guidance is the distinction between genuine human oversight and analysts who simply approve AI-generated outputs without the ability or training to challenge them. Banks need to demonstrate that staff reviewing high-risk AI decisions understand the system's logic and have real authority to override it.
• Explainability and documentation requirements extend to vendor-supplied models: Classification obligations apply regardless of whether a system was built internally or purchased from a vendor, and banks that substantially modify third-party models may be reclassified as providers, which carry heavier obligations than those of a deployer.

CSRD And ESG Disclosure Remain Active Obligations Despite Simplification Efforts

The regulatory narrative around CSRD shifted considerably through 2025 and into 2026 with the adoption of the EU's Omnibus simplification package. However, large EU banks already in scope under the original CSRD timeline continue to have active reporting obligations for FY2025 and FY2026, even as the scope of future reporting waves narrows. 

• Banks already in scope continue FY2025 and FY2026 reporting: Large EU banks that began CSRD reporting based on FY2024 data are continuing into FY2025 and FY2026 reporting cycles under existing ESRS requirements, with applicable simplification reliefs where they exist.
• Taxonomy disclosure exemptions have created comparability challenges: A temporary exemption from mandatory EU Taxonomy disclosures for banks covering FY2025 and FY2026 has led to inconsistent disclosure practices across the sector, with some institutions continuing voluntary disclosure because their reporting infrastructure was already built.
• Double materiality assessments remain a foundational requirement: Regardless of where the simplified ESRS standards ultimately land, banks in scope need to maintain robust double materiality processes that identify which sustainability matters are financially material to the institution and which represent material impacts on people and the environment.
• GRC platforms need to track a moving regulatory target: Because the scope and substantive requirements of CSRD are subject to ongoing legislative revision, GRC functions need systems that can be reconfigured as reporting standards are finalized, rather than hard-coded to a single version of ESRS.

2026 GRC Priorities: Banking Status Update

How Technology Supports Integrated GRC Programs In Banking

The regulatory convergence described above has accelerated investment in GRC technology that can operate across multiple frameworks simultaneously. Rather than building separate compliance workflows for each regulation, institutions are increasingly looking for platforms that can map a single control to multiple regulatory requirements. 

• Continuous monitoring replaces point-in-time assessments: Where compliance programs once relied on periodic manual reviews, automated control testing and real-time monitoring allow institutions to identify control failures as they occur rather than during the next scheduled audit cycle.
• Centralized data architecture reduces reconciliation burden: Bringing risk, compliance, audit, and incident data into a connected architecture reduces the time GRC teams spend reconciling figures across spreadsheets and disconnected systems, and supports the kind of risk data aggregation capabilities that regulators have long expected under frameworks like BCBS 239.
• Regulatory content libraries map obligations to controls: Platforms that maintain pre-mapped regulatory content allow institutions to see, for any given control, which regulations it satisfies. This is particularly valuable given the overlapping requirements across DORA, NIS2, Basel IV, and the EU AI Act.
• AI-assisted horizon scanning supports proactive compliance: As the volume of regulatory change accelerates, automated tracking of regulatory developments helps compliance teams identify relevant changes earlier in the process, reducing the lag between a rule change and an institution's response.

2026 GRC Technology Trends In Banking

A Common Controls Framework Is Becoming Essential For Managing Overlapping Obligations

With DORA, Basel IV, NIS2, the EU AI Act, and CSRD all imposing requirements that touch similar underlying processes, institutions managing each regulation as a separate workstream are duplicating effort across teams that are often testing the same control for different reasons.

A common controls framework addresses this by mapping individual controls to the multiple regulatory requirements they satisfy. A single control governing third-party access management, for example, may simultaneously support DORA's third-party risk pillar, relevant cybersecurity governance expectations, and elements of operational resilience reporting.

• Control rationalization reduces audit fatigue: Testing a control once and mapping the evidence to multiple regulatory requirements reduces the number of times the same control owner is asked for the same evidence by different teams.
• Shared taxonomies enable cross-framework reporting: When risk categories, control descriptions, and evidence requirements use consistent definitions across frameworks, institutions can generate regulator-specific reports from a single underlying dataset rather than maintaining parallel documentation.
• Governance ownership needs to span functions: A common controls framework only works if risk, compliance, IT security, and audit functions agree on shared definitions and ownership models, which requires governance structures that operate above individual departmental silos.

How To Build An Integrated GRC Program For 2026

Step 1: Build A Single Inventory Of Regulatory Obligations And Map Them To Controls 

Begin by consolidating the requirements of DORA, Basel IV, the EU AI Act, CSRD, and any other applicable frameworks into a single repository. For each obligation, identify the controls that already exist to satisfy it, and flag where no control currently exists. This inventory becomes the foundation for everything that follows, because it reveals where the institution is duplicating effort and where genuine gaps remain.

Step 2: Establish Data Governance Standards That Serve Risk, Capital, And Compliance Simultaneously 

Given that operational loss data now feeds directly into Basel IV capital calculations, and that DORA and the EU AI Act both depend on accurate system inventories and incident records, data governance can not be managed separately by risk, finance, and compliance teams. Establish shared data quality standards, a single authoritative source for key risk data, and clear data lineage so that the same dataset can support multiple regulatory submissions.

Step 3: Complete An AI System Inventory And Classification Exercise Ahead Of The August 2026 Deadline 

Every AI system touching credit decisions, fraud detection, AML monitoring, and customer-facing automated decisions needs to be cataloged and assessed against the EU AI Act Annex III criteria. This exercise should include vendor-supplied systems and any internally modified third-party models, since modification can change an institution's classification from deployer to provider.

Step 4: Strengthen Third-Party Risk Management To Reflect DORA's ICT Oversight Requirements 

Third-party risk programs need to extend beyond financial and operational due diligence to cover ICT concentration risk, particularly given that a defined set of critical ICT providers now sits under direct EU supervisory oversight. Institutions should map which of their critical third parties fall into this category and understand how that oversight layer interacts with their own contractual and monitoring arrangements.

Step 5: Implement Continuous Control Monitoring For The Highest-Risk Processes 

Rather than attempting to automate every control simultaneously, prioritize continuous monitoring for processes that carry the highest regulatory and financial exposure, such as ICT incident detection, operational loss event capture, and AI model performance monitoring. Continuous monitoring in these areas delivers the earliest warning of issues that could otherwise surface during a supervisory review.

Step 6: Build A Reporting Layer That Can Serve Multiple Regulators From A Single Data Model 

With API-driven regulatory reporting becoming the norm, institutions should design their reporting architecture so that prudential, operational resilience, AI governance, and sustainability reports can all be generated from a consistent underlying data model. This reduces the risk of inconsistent figures appearing in different regulatory submissions and shortens the time required to respond to new reporting templates as they are introduced.

Finding it difficult to keep pace with overlapping regulatory deadlines across risk, compliance, and audit teams? MetricStream's Connected GRC platform brings these functions onto a single platform with pre-mapped regulatory content. Explore Our Solutions

How MetricStream Can Help

MetricStream's ConnectedGRC platform is designed to help banking and financial services institutions manage the kind of overlapping regulatory requirements described throughout this article from a single, AI-first foundation. The platform's pre-mapped regulatory content libraries cover frameworks including DORA, Basel IV, NIS2, the EU AI Act, and CSRD, allowing institutions to see how a single control maps to multiple obligations rather than maintaining separate compliance tracks for each regulation.

For operational risk and resilience, MetricStream supports the kind of loss data governance, control testing, and resilience planning that Basel IV's SMA and DORA both depend on, helping institutions connect risk assessments to the loss event data that now directly affects capital calculations. For AI governance, the platform supports AI system inventories, risk classification workflows, and ongoing monitoring that align with the human oversight and documentation expectations under the EU AI Act.

Across third-party risk, IT and cyber risk, and ESG risk management, MetricStream's connected approach allows institutions to maintain a single source of truth for risk and compliance data, supporting the kind of continuous monitoring and cross-framework reporting that 2026's regulatory environment increasingly demands.

Looking for a way to bring DORA, Basel IV, AI governance, and ESG reporting onto one platform? Talk to a MetricStream expert about how Connected GRC can support your institution's 2026 priorities. Talk to an Expert