Capability-Based Planning for Banks Under Regulatory Pressure
Canadian banks are managing the most concentrated regulatory investment period in recent history. OSFI's Guideline E-21 on operational resilience requires scenario testing for all critical operations by September 2027. Guideline E-23 on Model Risk Management takes effect May 2027, covering every AI and ML model in production. Open banking under the Consumer-Driven Banking Act is in active implementation with the infrastructure launching in 2026. The Basel III capital floor was paused in February 2026 to support competitiveness, but remains on the regulatory agenda. And simultaneously, every institution has an AI program with financial targets it is trying to hit.
Each of these regulatory and strategic imperatives demands investment. Each one has a plausible argument for why it should be the priority. And most banks do not have a systematic way to evaluate those arguments against each other, because the investment decisions are being made by different functions, using different frameworks, against different timelines, with different ownership over the organizational capabilities that all of these programs are, at their core, about.
Capability-based planning is the discipline that resolves this. Not by eliminating the investment pressures, but by providing a shared analytical foundation that maps regulatory requirements, strategic objectives, and technology programs to the specific organizational capabilities they affect, revealing where investment is redundant across programs, where a single capability investment satisfies multiple requirements simultaneously, and where the sequencing logic is non-negotiable because some capabilities are prerequisites for others.
Why Investment Prioritization Fails Without a Capability Lens
The standard investment prioritization process in banking produces a ranked list of projects. Each project is evaluated on its own merits: regulatory mandate or not, expected return, delivery risk, strategic alignment. The projects that score highest get funded. The ones that do not wait until the next cycle.
This process has a structural flaw for the current environment. It treats each regulatory and strategic requirement as an independent project competing for the same budget, when in reality most of them are claims on the same underlying organizational capabilities. OSFI E-21's requirement for documented critical operations and scenario testing is a claim on the operational resilience mapping capability. E-23's requirement for model documentation, validation, and monitoring is a claim on the model risk management capability. Open banking's requirement for customer data portability is a claim on the data architecture and API management capability. An AI program's requirement for reliable, well-governed training data is a claim on the data governance capability.
When these requirements are evaluated as independent projects, the bank funds a project to address E-21 resilience mapping, another to address E-23 model documentation, another to build open banking APIs, and another to improve data quality for AI. Four projects, each doing work that partially overlaps with the others, each building artifacts that are incompatible with the others because they were not designed with a shared capability foundation in mind. The duplication is expensive. The incompatibilities are more expensive still, because they surface late in delivery when integration work reveals that the four projects were each building different representations of the same underlying business reality.
Capability-based planning starts from the opposite direction. Rather than asking which projects should be funded, it asks which capabilities need to be developed or improved to satisfy the combined demands of the regulatory and strategic agenda, and then builds projects around capability investments rather than regulatory point solutions. The result is a smaller number of larger investments that each satisfy multiple requirements, with explicit traceability from each regulatory deadline to the capability it requires and from each capability improvement to the requirements it closes.
The Regulatory Capability Map for Canadian Banks in 2026-2027
Mapping the current regulatory agenda to the capabilities it requires produces a picture that is clearer than the standard regulatory project list and significantly more useful for investment sequencing.
OSFI E-21's operational resilience requirements drive capability demand in three areas. Critical operations mapping requires the bank to have a documented, current understanding of which operations are essential to delivering its services, what resources support them, and what the impact of disruption looks like. This is a business architecture capability: the methodologies and governance for maintaining an accurate, operationally relevant map of the bank's services and their dependencies. Scenario testing for critical operations requires the operational resilience testing capability: the processes, tools, and organizational structures for defining disruption scenarios, testing recovery, and documenting outcomes. Governance framework for resilience requires the operational risk governance capability: board-level ownership, management oversight structures, and reporting mechanisms for resilience performance.
OSFI E-23's model risk management requirements drive capability demand in four areas. Model inventory management requires the capability to maintain a comprehensive, current registry of all in-scope models with their ownership, purpose, status, and risk classification. Model documentation requires the technical writing and governance infrastructure to produce the documentation that E-23 specifies for each model. Model validation requires the independent review capability for assessing model performance against its intended purpose, which is an organizational design requirement as much as a technical one: the validation function must be independent of model development. Post-deployment monitoring requires the infrastructure and processes for tracking model performance, detecting drift, and triggering review or retraining when performance degrades.
Open banking's data portability requirements drive capability demand in two primary areas. API management capability covers the design, operation, governance, and version management of the APIs that expose customer data to authorized third parties under the Consumer-Driven Banking Act framework. Consent management capability covers the infrastructure for capturing, storing, enforcing, and auditing customer consent for data sharing at the granularity the legislation requires.
The AI program's requirements for reliable AI outcomes drive capability demand in data governance, data quality management, model lineage documentation, and the human oversight mechanisms that the EU AI Act and emerging Canadian regulation require for high-risk AI systems used by Canadian banks with EU market exposure.
When these requirements are laid out this way, the overlaps become visible. The model inventory management required for E-23 is the same organizational capability required for AI governance under responsible AI frameworks. The data governance capability required for E-23's training data documentation is the same capability required for open banking data quality. The operational resilience mapping required for E-21 produces the business service documentation that is also prerequisite for any meaningful AI impact assessment. These are not coincidental overlaps. They are structural, because regulatory requirements are ultimately claims on the same set of organizational capabilities that strategic programs also require.
How the BIAN Service Domain Model Anchors the Analysis
The BIAN Service Landscape is particularly useful for capability-based planning in banking because it provides a pre-built reference for the capabilities that banking organizations require across their full operating scope. Rather than building a capability map from scratch and spending months resolving definitional debates about what counts as a capability and where its boundaries lie, a bank working from BIAN can adopt the service domain vocabulary and focus the mapping work on assessing performance and strategic importance within a proven structure.
For regulatory capability mapping specifically, BIAN's service domains provide the common language that connects business architecture artifacts to the technology and operations teams responsible for implementing the capabilities. When a regulatory requirement is mapped to a BIAN service domain, the technology team that owns that domain understands immediately what is being asked, and the governance documentation produced through the analysis is expressed in vocabulary that is intelligible to regulators, vendors, and external reviewers who use the same reference model.
The practical approach for a bank building its regulatory capability map is to identify the BIAN service domains most affected by the current regulatory agenda, assess the current maturity of those domains against the performance required for compliance, and use the gap analysis as the primary input to investment prioritization. This is a more tractable scope than a comprehensive enterprise capability assessment, and it produces the specific investment case that the CFO, the Chief Risk Officer, and the board need to evaluate competing regulatory investment claims.
The Investment Sequencing Logic
Once the capability map is built and the regulatory requirements are traced to the capabilities they affect, the investment sequencing question has a cleaner answer than the standard project prioritization process can produce.
Capabilities that are required by multiple regulatory programs and that currently have significant performance gaps should be funded first, because their improvement delivers compliance value across multiple regulatory requirements simultaneously. Data governance is the clearest example in the current environment: improving the bank's data governance capability produces progress toward E-23 model documentation requirements, open banking data quality requirements, AI training data quality requirements, and the regulatory data quality requirements that OSFI has identified as a supervision priority for property and casualty insurers and is extending to banking. A single data governance investment program addresses all of these requirements, rather than four separate remediation projects each building partial data governance capability in a different organizational silo.
Capabilities that are required by one regulatory program but that are prerequisites for other strategic investments should be funded on the regulatory timeline. The model inventory management capability required for E-23 compliance is also the prerequisite for any AI CoE that aims to govern the bank's AI portfolio coherently. The bank that builds model inventory management by the E-23 deadline has also built the governance foundation for its AI program. The bank that defers it will pay twice: once when E-23 forces remediation, and again when the AI program discovers it lacks the governance infrastructure to manage a growing model portfolio.
Capabilities that are required by one regulatory program and that have no current strategic importance beyond compliance can be addressed on the minimum viable compliance timeline, without investment beyond what the regulatory requirement demands. The goal of capability-based investment planning is not to develop all capabilities to a high level of maturity. It is to develop the right capabilities to the right maturity level given the combined demands of the regulatory and strategic agenda.
The Architecture Function as Regulatory Investment Coordinator
The capability-based planning work described above cannot be done effectively by the regulatory compliance function, the technology function, or the risk function independently. It requires a coordinating function that has the organizational mandate to map across functions, the analytical capability to trace regulatory requirements to capability implications, and the credibility with senior leadership to present capability investment cases as alternatives to project investment cases.
As the business architecture for financial services post in this series describes, architecture is evolving from a technical documentation function to a strategic investment coordination function in the most mature Canadian banking institutions. The banks that have built this capability are using it to do exactly what the current regulatory environment demands: translate a complex, multi-program regulatory agenda into a coherent capability investment roadmap that eliminates duplication, surfaces dependencies, and produces a sequencing logic that holds up under scrutiny from the CFO, the Chief Risk Officer, and the board.
The banks that have not built this capability are managing their regulatory agenda the same way they always have: as a collection of independent projects, each owned by a different function, each building toward compliance on its own timeline, and each discovering late in delivery that the organizational capabilities they are building overlap with and sometimes conflict with the ones being built by the adjacent programs. The cost of that discovery, in rework, in integration complexity, and in the regulatory risk that emerges when compliance programs arrive at their deadlines with incomplete capabilities, is the cost of not having done the capability-based planning that would have made the conflicts visible before delivery began.
Talk to Us
ClarityArc's business architecture practice helps Canadian financial institutions build regulatory capability maps, trace compliance requirements to the capabilities they affect, and develop investment sequencing logic that eliminates regulatory duplication and satisfies multiple programs simultaneously. If your institution is managing a complex regulatory agenda and wants a more coherent investment prioritization approach, we are ready to help.
Get in Touch