Banks and financial institutions have been pioneers of adopting the agile operating model—moving from traditional organizations in independent units to small, cross-functional teams with end-to-end ownership of products and journeys, where handovers and dependencies are minimal and teams are united with a common purpose.
Agile operating models enable banks to capture multiple benefits, such as increased customer centricity, higher speed to market, more engaged employees, and higher productivity (Exhibit 1). Based on our research, agile institutions—those which have fully or partially adopted an agile model—are 1.5 times more likely than their competitors to overperform financially.
However, even among institutions embracing the approach, adoption has been more limited in support functions, including control functions such as risk and compliance. The customer-facing side—what is known as the first or front line—has been the first to see the urgency to adopt an agile approach, pressured by changing customer needs and expectations and a fluctuating business environment with increased competition.
A key challenge for control functions in the context of agile operating models has been the need to maintain independence. Involvement in the co-design of products and processes with the first line could therefore pose challenges for risk and compliance functions that need to be solved in the design of the agile operating model. In addition, risk and compliance functions focus on protecting the institution from risks and breaches of laws and on following rules and regulations rather than ensuring speed to market. While the emphasis stays the same, control functions are realizing that agile ways of working can support their primary purpose of keeping the bank safe from risks and ensuring regulatory compliance.
A competitive landscape, technological innovation, and a rising tide of challenges are pushing these functions to become nimbler and more responsive. This fast-changing business and external environment changes how we work and is rendering traditional organizational models less effective—and, in many ways, obsolete (Exhibit 2).
Why control functions go agile
Banks have been more amenable to adopting agile operating models for their first-line functions—those that are closest to customers. Implementing agile in risk and compliance functions, part of an organization’s second line, can bring multiple benefits to the banks:
- Products and processes developed by the first line are “compliant by design,” and risks are identified and mitigated significantly earlier through the earlier involvement of the second line in the design and development process.
- There could be faster implementation of critical regulatory changes through increased transparency on priorities and bottlenecks.
- Seamless front-to-back (across the first and second line of defense) technology can increase effectiveness and create more visibility and agility of IT—for instance, the ability to rapidly embed changing compliance and risk controls in business processes and the opportunity to automate controls.
- Increased efficiency and reduced time to market for product releases can satisfy high customer expectations and beat competition while delivering safe and regulatory-compliant products.
- There can be increased risk ownership by the front line, while control teams can have more visibility, given teams are cross-functional and agile principles promote transparency with all stakeholders.
- Attraction and retention of talent in control functions is possible through more empowering and stimulating work and a dynamic environment.
What agile models look like in control functions
Simply put, an agile operating model in risk and compliance functions has two imperatives: to support the first line’s agile organization and to enhance the ways of working in the risk and compliance functions themselves, the second line of defense (Exhibit 3).
There are a few ways to structure an agile operating model involving control functions.
To support the first line, risk and compliance officers can be embedded as permanent members of cross-cutting teams in the bank. The permanent members generally keep reporting into the second line of defense. It’s the best model to use when agile transformations are already initiated, front to back, and there is a clear benefit in enhanced collaboration with the risk and compliance functions on a permanent basis.
Another option is a flow-to-work model, where a central pool of multiskilled risk and compliance officers report into the second line and are deployed to agile teams based on needs. This is an appropriate model when the rest of the organization is agile but there is no permanent need to integrate control experts in cross-functional teams.
Under these models, standards can be further maintained in the first-line agile organization by introducing additional process changes, such as involving the second line of defense in the quarterly business review process and introducing an additional agile ceremony—a risk and compliance marketplace. That could involve representatives from risk and compliance functions meeting, for example, once per week to discuss needs and requirements and risk, compliance, and control-related topics; share best practices; and achieve a common understanding of tasks at hand for the agile team and to create transparency across the organization.
To adopt the agile operating model, the risk and compliance functions can create cross-cutting teams formed within the function. These teams own all risk and compliance-related activities of a product or a journey. The model is relevant when there is a clear business benefit in enhanced collaboration across the product life cycle within the second line of defense, which is common in the delivery organization, or “change the bank” organization (the part that is building new systems).
The other option would be an agile overlay model. In this approach, agile-inspired ways of working and tools are deployed and supported by agile coaches while the organization remains unchanged or undergoes limited change. This is a preferred model when agile ways of working bring better prioritization and sharing of best practices, but implementing the full model is not needed because handovers are limited outside of the current team.
Leaders can choose the appropriate model based on the nature of work and the level of collaboration needed. Typically, the delivery organization (change the bank) adopts the full agile operating model within the function, either across the entire organization or partially for specific products or journeys (for example, selected risk models). At the same time, the “run the bank” organization (that is, existing systems) focuses on supporting the first line’s agile organization and thus adopts a flow-to-work model or joins cross-cutting teams that form the first line of defense. However, examples of banks that have adopted the full agile operating model for the entire function (change and run) also exist.
How can control functions launch the shift to an agile model?
Agile models for risk and compliance can be adopted in three steps that focus on identification, scope, and design.
Identify the right operating model
The level of agile maturity in the wider organization and the nature of work should determine what model to use. Leaders should consider where roles connect within risk and compliance and with other business units and support functions, collaboration needs, and the level of expertise and specialization.
Determine the scope of rollout when deciding to implement the model within the second line of defense
Risk and compliance functions can tailor the scope of agile rollout based on specific needs and the function’s appetite for change. We have seen banks starting with transforming a few teams to transforming the full delivery organization and even the full organization. To start, a risk or compliance function can experiment with a few product-led agile teams and thereafter gradually roll out a full model.
Design the detailed operating model taking into consideration key guiding principles
Designing the detailed operating model includes structure, such as cross-functional product-led teams and governance or process (for example, quarterly business reviews); people and culture, for example, redesigning job structure and performance management or instilling an engineering culture; and technology, such as harmonized tooling and next-generation enabling technology.
When designing the target organizational structure, five guiding principles should be considered:
- Make it permanent. Temporary project teams are eliminated for a permanent group, or tribe, that takes ownership of a product family.
- Give ownership. Tribes are given end-to-end authority and ownership over product strategy and development.
- Make it self-sufficient. Dependency on other units or tribes is minimized or eliminated for product delivery.
- Create robust but efficient tribes. Tribe size is limited to 90 to 150 full-time employees—a level that fosters efficiency and optimal collaboration while limiting costs.
- Go big on engineering. Minimize coordination roles, or management layers, and maximize engineering talent.
The agile operating model may have started on the customer-facing side, the first line of defense, but it is gaining interest among support functions, including the second line of defense. The full potential of agile models at banks—competitive speed, nimble decision making and action taking, and better returns—cannot happen without support and control functions, including risk and compliance, working together toward an aligned vision and purpose.
We increasingly see leading banks across the globe either experimenting with agile organization by launching a few agile teams or rolling out agile at scale in risk and compliance functions. The benefits of customer-centricity, higher speed to market, more engaged employees, and higher productivity have become obvious to forward-thinking, regulated institutions.
