Regulation as a catalyst for change. What is really behind today’s regulatory pressure on banks?

What you should know:

• Regulations are no longer a test of reports; they are becoming the basis on which supervisors assess a bank’s real ability to operate under time pressure.
• The greatest source of risk is not the regulations themselves, but data and processes. System silos, manual reconciliations at the final stage of the process, and ad hoc activities are now generating the highest operational costs and supervisory risk.
• Supervisory expectations clearly indicate the direction of change in systems and data architecture. Automation, consistency, and full explainability are becoming prerequisites for a bank’s continued growth and scalability.

DORA: the end of “paper resilience”

DORA has been in force since January 2025 and introduces a new approach to assessing financial institutions. From that point on, the focus is no longer solely on having policies and documentation in place, but on whether incident management and digital resilience mechanisms actually function in practice. The regulation is applied on a continuous basis and is treated as an important element of the security of the entire financial system.

What does DORA really require from banks?

From a business perspective, DORA changes the way operational resilience is approached.

Banks must be able to:

• clearly identify critical business services,
• understand which systems, data, and suppliers support them,
• quickly assess the impact of an IT incident on customers, operational continuity, and reputation,
• provide consistent and reliable information to management and supervisors within a short timeframe.

In practice, this means moving from reactive incident response to deliberate, data-driven operational resilience management based on facts rather than fragmented inputs from multiple teams.

Where are banks weakest today?

The most common weaknesses highlighted by DORA are well known, but difficult to eliminate on a lasting basis:

• the lack of a single, consistent view of business services and their dependencies on IT,
• fragmented information on incidents, logs, and operational events,
• weak correlation between a technical incident and its actual business impact,
• limited oversight of external suppliers and their influence on business continuity.

As a result, banks often know that an incident has occurred, but are unable to quickly answer a key question: what does this mean for our customers and critical business processes?

What should be done next?

An effective response to DORA requires building a coherent operational resilience architecture, rather than deploying additional point solutions:

• Business service mapping. A clear linkage between critical business services and the systems, data, and suppliers that support them, enabling rapid impact assessment.
• Central data integration layer. Integration of data from transactional systems, ITSM tools, monitoring, security platforms, and supplier registers into a consistent information model.
• Observability and incident management. Correlating technical events with business processes, along with automated escalation and incident reporting.
• ICT third-party risk management. Assessing external suppliers based on their importance to critical services and business continuity scenarios.
• Operational resilience reporting. Consistent, automated reporting for management and supervisors, based on operational data rather than manual compilations.

BCBS 239: why data issues resurface in every supervisory review

Although BCBS 239 has formally been in force for several years, for many banks it remains an unresolved topic. Supervisors are increasingly treating it as a standing expectation related to the quality of risk data and management reporting. In practice, BCBS 239 now serves as a reference point in SREP assessments, stress tests, and inspections focused on data and models.

BCBS 239 addresses the foundations of how an organization operates: how risk data is sourced, processed, and used. Banks that limited its implementation to the reporting layer feel the consequences with every new regulation or supervisory exercise.

What does BCBS 239 really require from banks?

From a business perspective, BCBS 239 ultimately comes down to one question: can management make decisions based on reliable and consistent data?

To make this possible, a bank must be able to:

• aggregate risk data quickly, completely, and in a repeatable manner,
• apply consistent definitions and metrics across the entire organization,
• clearly explain where every key number in a report comes from,
• reproduce a historical report together with the underlying data and assumptions.

BCBS 239 shifts the focus from reporting to managing risk data as a core organizational asset.

Where do banks most often run into difficulties?

The most frequently identified issues include:

• risk data dispersed across multiple systems and silos,
• different definitions of the same concepts across risk, finance, and reporting,
• manual reconciliations and adjustments performed at the end of the process,
• limited transparency into data origin and a lack of a complete audit trail.

As a result, banks may be able to produce a report, but are unable to quickly and unequivocally defend it to management or supervisors.

What should be done next?

An effective response to BCBS 239 requires building durable foundations for risk data management, rather than adding yet another reporting layer:

• A common risk data model. Standardized definitions and structures used consistently across risk, finance, and reporting.
• A central data aggregation platform. Automated, controlled processes for sourcing and processing data from upstream systems.
• Data quality management. Validation of data consistency and completeness early in the process.
• Data lineage and audit trail. Full traceability of data from source systems through to management reports.
• Flexible management reporting. Reports that are resilient to changing regulatory requirements and evolving decision-making needs.

IFRS 9: when data, risk models, and finance have to speak with one voice

Although IFRS 9 has been in force since 2018, in practice it remains one of the most operationally demanding regulations. For banks, it is not a “completed implementation,” but an ongoing process subject to regular supervisory reviews, audits, and periodic risk model reviews. Any change in the macroeconomic environment, scenarios, or input data quickly translates into the level of provisions and the financial result.

IFRS 9 brings together areas that traditionally operated separately in banks: credit data, risk models, accounting, and management reporting. It is at this intersection that issues with data consistency and result explainability most often emerge.

What does IFRS 9 really require from banks?

From a business perspective, IFRS 9 requires banks to be able to credibly explain changes in the level of credit loss provisions.

This means the need to:

• maintain a complete and consistent history of credit data,
• apply repeatable and well-documented PD, LGD, and EAD models,
• clearly assign exposures to the appropriate classification stages,
• reconcile risk results with the general ledger and financial reports.

In practice, the key question is: why did ECL change in this period, and can we explain it in a consistent and coherent way?

Where are banks weakest today?

The most common IFRS 9-related challenges include:

• gaps or inconsistencies in historical credit data,
• manual adjustments and overrides applied at the end of the process,
• difficulties reconciling risk results with finance,
• limited explainability of changes in provisions between periods,
• a heavy reliance on the expert knowledge of a small number of individuals.

As a result, IFRS 9 becomes an area of elevated operational and audit risk, particularly during periods of economic volatility.

What should be done next?

An effective response to IFRS 9 requires putting credit data and model processes in order in a durable and scalable way:

• A central credit data repository. A consistent view of exposures, history, collateral, and credit events.
• Standardized model inputs. A single source of data for PD, LGD, EAD, and staging, used consistently across the organization.
• Model lineage and explainability. The ability to trace how changes in data, parameters, or scenarios affect the ECL result.
• Automated reconciliation with finance. Reducing manual reconciliations and adjustments at the end of the process.
• ECL change reporting. Clear analysis of the drivers of changes in provisions for management, audit, and supervisors.

SREP / ICAAP / ILAAP: a test of consistency in bank management

SREP and the ICAAP and ILAAP processes are today the primary points of interaction between banks and supervisors. This is where regulators assess capital and liquidity adequacy, as well as the maturity of risk management and the quality of decision-making. In practice, the focus is increasingly less on individual ratios and more on the consistency of the narrative, data, and scenarios presented to supervisors.

Although ICAAP and ILAAP have formally been in place for years, in many banks they remain highly manual processes, based on periodic exercises and intensive reconciliation between risk, finance, and liquidity management (treasury). As a result, any change in macroeconomic or regulatory assumptions significantly increases operational risk and extends the organization’s response time.

What do SREP / ICAAP / ILAAP really require from banks?

If reduced to a single question, it would be: can the bank consistently and credibly justify its capital and liquidity decisions?

To do so, a bank must be able to:

• use the same data across risk, finance, and planning,
• apply consistent scenarios and assumptions in stress testing,
• quickly translate changes in assumptions into capital and liquidity impacts,
• present supervisors with a clear and repeatable calculation path.

Where are banks weakest today?

The most commonly identified issues include:

• discrepancies between the data used in ICAAP, FINREP, and financial plans,
• manual construction of stress testing scenarios,
• long calculation cycles and limited ability to perform what-if analysis,
• difficulties quickly explaining differences between successive result iterations.

What should be done next?

An effective response to SREP / ICAAP / ILAAP requires structuring capital and liquidity planning processes around a common data foundation and shared scenarios:

• A common data model for risk and finance. A single data source used across ICAAP, ILAAP, stress tests, and planning.
• A central stress testing platform. Repeatable scenarios, shorter calculation times, and the ability to perform variant analysis.
• Automation of capital and liquidity calculations. Reducing manual recalculations and adjustments between iterations.
• Full calculation traceability and explainability. The ability to quickly reproduce results and explain changes between periods.
• SREP-focused management reporting. Consistent materials for management and supervisors, based on the same data and assumptions.

FINREP / COREP: reports that expose data weaknesses

For banks, FINREP and COREP are the most “visible” points of contact with supervisors, but also the areas with the highest operational risk. Although these reports have been submitted on a regular basis for years, any change in taxonomy, interpretation, or data scope creates significant organizational strain. In practice, the challenge is not the report format itself, but the way data is prepared, which in many banks remains largely manual and reactive.

FINREP and COREP quickly expose all earlier weaknesses: inconsistent definitions, the absence of a common data model, and reliance on manual adjustments made at the end of the process. As a result, regulatory reporting is rarely perceived as a stable process and more often as a recurring exercise of “closing the topic by the deadline.”

What do FINREP / COREP really require from banks?

In simplified terms, FINREP and COREP boil down to a single requirement: the bank must deliver consistent, complete, and timely data, regardless of regulatory changes.

To achieve this, a bank must:

• apply uniform data definitions across finance, risk, and reporting,
• ensure repeatability of the reporting process,
• quickly adapt to changes in taxonomy and validations,
• reduce manual adjustments and last-minute activities.

In practice, this means moving from people- and spreadsheet-driven reporting to process- and data-driven reporting.

Where are banks weakest today?

The most common recurring issues include:

• data mappings maintained outside of production systems,
• manual pivots and adjustments at the final stage of report preparation,
• inconsistencies between FINREP, COREP, and the data used in ICAAP and IFRS 9,
• difficulties in quickly explaining adjustments raised by supervisors.

Banks often meet timeliness requirements, but at the cost of data quality, process stability, and significant strain on teams.

What should be done next?

An effective response to FINREP and COREP requires treating regulatory reporting as a repeatable process rather than a one-off obligation:

• A central regulatory reporting data model. A single, consistent source of data prepared for regulatory reporting.
• Automated taxonomy mappings. Controlled, versioned mapping rules that are resilient to regulatory changes.
• Data quality validations before reporting. Detecting errors earlier in the process, rather than after submission.
• Automated report generation. Reducing manual pivots and adjustments in the final phase of the process.
• Audit trail and report reproducibility. Full traceability from source data to the report submitted to supervisors.

IRRBB: when Excel is no longer enough

For many years, IRRBB was viewed as a relatively stable area of risk management. Changes in the interest rate environment, however, have brought interest rate risk in the banking book back under close scrutiny from supervisors and bank management. Today, the focus is no longer solely on meeting regulatory requirements, but on the real impact of interest rate decisions on financial performance and the bank’s economic value.

In practice, IRRBB very quickly reveals how well a bank understands its cash flows, customer behavior, and balance sheet structure. Where simplifications and Excel spreadsheets dominated for years, there is now a need for fast, repeatable, and defensible analyses.

What does IRRBB really require from banks?

At its core, IRRBB comes down to a single question: can the bank credibly assess the impact of interest rate changes on earnings and economic value?

To do so, a bank must be able to:

• maintain consistent cash flow schedules for assets and liabilities,
• apply documented and repeatable behavioral assumptions (for example, for deposits),
• quickly simulate different interest rate scenarios,
• present a coherent narrative across ALM, risk, and treasury.

IRRBB therefore requires a shift away from point-in-time calculations toward continuous management of interest rate risk exposure.

Where are banks weakest today?

The most commonly identified issues include:

• the absence of a single, central view of cash flows,
• scenarios calculated manually or in fragmented spreadsheets,
• inconsistent behavioral assumptions across ALM, risk, and treasury,
• long calculation times and limited ability to perform what-if analysis,
• difficulties quickly explaining changes in results between successive simulations.

Banks may be able to produce results, but are often unable to update them quickly or defend them convincingly in discussions with supervisors or management.

What should be done next?

An effective response to IRRBB requirements calls for organizing cash flow management and interest rate scenarios in a consistent and scalable way:

• A central cash flow engine. A single source of truth for asset and liability cash flows across the organization.
• Consistent behavioral assumptions. Standardized, versioned parameters used by ALM, risk, and treasury.
• Automated IRRBB scenarios. Fast, repeatable EVE and NII simulations across different interest rate variants.
• Result explainability. The ability to trace which factors drive changes in results between scenarios.
• Management and supervisory reporting. Consistent materials supporting treasury decisions and supervisory dialogue.

Intraday liquidity (BCBS 248): liquidity in (almost) real time

For many years, intraday liquidity management was treated as a purely operational area, remaining in the background of traditional liquidity metrics. Today, with the growing volume of payments, pressure for immediate settlement, and increased market volatility, intraday liquidity has become a genuine management risk.

BCBS 248 standards and supervisory expectations are increasingly focused on a bank’s ability to monitor and manage cash flows in near-real time.

What does intraday liquidity really require from banks?

From a business perspective, intraday liquidity management comes down to a single question: does the bank know where its liquidity stands at any given moment during the day, and can it react before limits are breached?

To do so, a bank must be able to:

• monitor intraday cash flows with an appropriate level of time granularity,
• understand the timing and sequencing of inflows and outflows,
• identify liquidity bottlenecks in payment systems,
• make treasury decisions based on current data rather than delayed information.

Where are banks weakest today?

The most commonly identified issues include:

• a lack of data with sufficient time granularity (timestamps),
• fragmented payment information across multiple systems,
• the absence of a single, up-to-date view of liquidity usage,
• limited capabilities to forecast intraday cash flows,
• reacting to issues only after they have already materialized.

As a result, banks often know that a liquidity strain has occurred, but become aware of it too late to manage it effectively.

What should be done next?

An effective response to intraday liquidity requirements calls for treating this area as a streaming data–driven process rather than one based on static reports:

• A central intraday liquidity view. Consolidation of data from payment systems and treasury into a single operational view.
• Near-real-time data. Monitoring flows with appropriate time precision.
• Intraday alerts and limits. Early warning of potential liquidity limit breaches.
• Liquidity usage forecasting. Improved planning of treasury actions during the day.
• Management and supervisory reporting. Consistent reports demonstrating how intraday liquidity is managed.

The common denominator of today’s regulations

As is easy to observe, the regulations that currently have the strongest impact on banks share one common denominator: they no longer focus on individual reports or isolated compliance obligations, but on how a bank manages data, systems, and decisions across the entire organization.

From compliance to operational capability

There is a clear shift in supervisory expectations from the question “has the requirement been met?” to “does the bank understand its data and can it act on it?” This applies equally to operational incidents, credit risk, liquidity, capital, and regulatory reporting. Regulations are increasingly testing a bank’s ability to respond quickly and make decisions, rather than merely produce documentation.

Data as a foundation, not a byproduct

Across almost all of the regulations discussed, data emerges as the key challenge: its quality, consistency, availability, and explainability. Manual reconciliations, Excel spreadsheets, and end-of-process fixes are becoming major sources of operational risk. In response, banks are being forced to build durable data management foundations, including common data models, central integration layers, and data quality controls.

Systems as a management tool, not just a reporting layer

The role of IT systems is also changing. They are no longer passive sources of data for reports, but increasingly an active component of risk, resilience, and liquidity management. Architectures that integrate data across domains, enable correlation, and provide full explainability paths for both management and supervisors are becoming critical.

Automation and repeatability instead of ad hoc actions

A recurring theme across all regulations is pressure for repeatability and scalability. Banks can no longer respond to new regulatory requirements simply by increasing team effort. A shift toward operating models based on automation, standards, and architecture is becoming essential to reduce operational risk and fixed costs.

The role of analytics and AI: a tool, not the goal

Against this backdrop, solutions based on advanced analytics and AI are appearing more frequently. Their role, however, is not to “achieve compliance,” but to support data quality, detect anomalies, reduce manual intervention, and accelerate analysis. Effective use of new technologies still depends on a solid data and systems foundation; without it, even the best models fail to deliver lasting value.

Summary: from compliance to the ability to act

The regulatory pressure banks face today is not about individual reports or isolated requirements, but about how the organization manages data, systems, and decisions across the entire bank. DORA, BCBS 239, IFRS 9, and SREP do not mandate specific technologies; they mandate the need for a consistent and explainable operating model.

Regulation is becoming a catalyst for lasting change. Banks that build shared data foundations, automated processes, and architectures that enable rapid understanding of impact gain not only regulatory compliance, but also operational and decision-making advantage. Others will increasingly compensate for the lack of such consistency with manual effort, under growing time pressure and supervisory scrutiny.