When Agile Meets Regulatory Compliance

Delivering regulatory projects is always a high-stakes proposition for banks. Faced with an ever more demanding compliance environment, banks today are investing extraordinary amounts of time and money in such projects. The average bank spends approximately 40% to 60% of its change budget on regulatory compliance—but squanders a significant portion of this investment on inefficiencies. As regulations continue to expand, companies need to fundamentally change their approach.

A new agile model offers banks a promising alternative approach. The perception among bank executives—and among their board members—is that using agile methods on multiyear, multimillion-dollar regulatory compliance projects is both risky and impractical. From our experience with clients, we believe this perception is false. We estimate that using the agile approach could cut banks’ IT spending by 20% to 30% and could significantly improve their ability to deliver regulatory projects on time.

An Outdated Model

Banks are naturally conservative in their approach to regulatory compliance—and with good reason. Serious failures can result in fines, regulatory constraints, legal action, and damage to a bank’s reputation. But as regulatory requirements continue to expand in scope, the traditional model of regulatory compliance is less effective and is looking increasingly outdated. For most companies, a rigid, sequential approach to software design and development is commonplace, but it leads to extraordinary waste in a large majority of regulatory projects.

Take the European Union’s Markets in Financial Instruments Directive (MiFID) 2. This directive—which aims to change how stocks, bonds, derivatives, and commodities are traded, cleared, and reported—began as an 80-page level 1 piece of legislation. The legislative process has faced numerous delays, and the level 2 requirements for MiFID2 ballooned to over 5,000 pages. The traditional approach to regulatory projects is not ideal for implementing this type of directive because its inflexible methods can result in waste. Banks get bogged down in the requirements phase, attempting to address every possible contingency, when they don’t have all the information necessary to do so effectively. As new requirements are announced, scope creep becomes impossible to avoid, and teams must go back to the drawing board to reframe the requirements—all while pushing to create interim solutions so they don’t fall too far behind on deadlines.

A New Model

The new agile model can be an extremely effective tool to help banks navigate the unexpected twists and turns that come with regulatory projects—and these large-scale IT endeavors cry out for agile:

• The projects are expensive and high risk.
• They have tight, indisputable deadlines.
• Regulatory requirements are unclear at the beginning, open to interpretation, and evolve over time.
• Each new regulation requires a novel technical solution that touches many applications, systems, and departments.
• Overdelivery is common—and costly to organizations.

But agile is not a quick fix. It introduces new ways of working that some employees may find uncomfortable at first, such as short iterations that enable teams to spot errors and react to changes quickly, collaboration in multidisciplinary teams, and full transparency and accountability. Nonetheless, these principles can be extremely effective in transforming banks’ responsiveness to regulatory changes. (For an overview of agile principles, see the sidebar.)

To use agile successfully on complex regulatory projects, organizations need to give special attention to several key aspects of the implementation. Companies that can master these best practices have an opportunity to accelerate ahead of their competitors and improve the effectiveness of their approach to regulatory compliance.

Create a core team. When planning for and implementing regulatory projects, many organizations make the mistake of creating an overly large project team. In most cases, this group includes many business and IT members who aren’t needed on a regular basis, which wastes time and diminishes the team’s focus. Instead, a small but fully dedicated core team of experts can work much more effectively, drawing on business and IT resources only when needed. With a stable, core team—led by a strong product owner—all stakeholders gain much greater transparency into the areas where the team has made progress, tasks that remain to be done, and impediments to completion.

To provide support to the core team, companies should consider establishing a separate acceleration team that focuses on resolving conflicts and addressing barriers to implementation (by ensuring that teams have the proper tools to work efficiently, for example). Particularly with large, complex regulatory projects, rapid issue resolution is essential.

Prioritize and groom the backlog. Over the past five years, the number of new regulatory requirements has tripled globally. (See Exhibit 1.) While this number can easily reach into the hundreds per day, companies must prioritize the top 20 or 30 items in the backlog. By doing so, they can quickly build an end-to-end plan for incremental delivery. And they can easily determine which features are essential to meet the regulatory requirements. Prioritizing the backlog to eliminate nonessential items can produce substantial savings. In our work with one bank, we discovered that only 40% of the hundreds of millions of euros that project teams requested for regulatory projects were essential to compliance.

Divide requirements into clearly identifiable pieces. Teams should break down regulatory requirements into clearly defined, manageable chunks that can be delivered independently. In this way, they can continually deliver key portions of the requirements rather than attempting to deliver the entire project in one massive push. Some organizations have established a central design authority to manage the backlog of requirements by identifying new ones, breaking them down into individual items for each impacted area, and incorporating them into the backlog. This approach benefits the agile team because the design authority analyzes a regulatory requirement just once, streamlining the overall effort.

Stay in sync with the regulator. It’s a fact of life for financial institutions that regulations imposed on banks change over time. When this happens, banks are left scrambling to address unforeseen changes—under extremely tight deadlines. Knowing which requirements to implement and in what order can be difficult. For this reason, the standard sequential approach often requires substantial modifications, and absent such changes, this approach may lead teams to miss crucial deadlines. Instead, teams should strive to quickly create a minimum viable product, test it, learn what works, and iterate until it meets the requirement.

To best achieve this, the product owner must stay in regular and close contact with the regulator, not only to ensure that the team integrates regulatory changes into the project’s backlog but also to recognize when the regulator is satisfied. One European bank had great success with this approach. The bank’s agile team invited the regulator to attend major events, such as sprint reviews. By participating in these discussions, the regulator gained full visibility into how the bank was progressing and provided valuable input to the agile team. At times, when the regulator determined that the team’s results were sufficient and that further implementation would add limited value, the regulator was even willing to adjust certain requirements.

Generate trust by maximizing transparency. Because serious mistakes on regulatory projects can have ruinous consequences for individual employees, board members, and organizations as a whole, building a culture of trust and transparency is extremely important. This process starts with board members, who must understand why and how agile is used in regulatory projects and fully support the approach. It also requires trust among employees, who may be accustomed to managing a discrete portion of a project and now must work collaboratively to resolve challenges, bypass roadblocks, and take responsibility for the entire project. Finally, it requires trust across units, so teams can work collaboratively toward the same overarching goal without fear that other units will pass the buck. Teams must provide full visibility into project status, including milestones, backlog size, delivery schedule, and key obstacles. Developing a series of shared goals is also helpful, to ensure that everyone is moving in the same direction.

Would Your Regulatory Projects Benefit from Agile Methods?

Numerous conditions may suggest that a bank’s regulatory projects would benefit from agile methods:

• The regulatory requirements are not viewed as stable and will likely change over time.
• The bank has a limited track record of successfully deploying complex, cross-functional projects that touch multiple systems and platforms.
• Some key stakeholders doubt that the organization can successfully deliver projects with the current delivery model or fear that regulatory projects will have a negative impact on other important projects in the pipeline.
• Although the bank has developed an extensive and detailed list of functional and nonfunctional requirements, most are stuck in the concept development phase.
• The organization has never successfully delivered an end-to-end functional requirement related to regulatory demands.
• The underlying IT architecture is modular enough to allow for partially independent releases in certain applications.
• The organization has had at least one successful experience working with agile, and senior leaders are willing to embrace a new model.

This is not intended to serve as a checklist—but rather to present a variety of conditions where agile is ideally suited to help organizations surmount obstacles and achieve success.

Regulatory requirements inevitably evolve, and banks need the flexibility to respond effectively; otherwise, they may waste an enormous amount of resources. Organizations with a positive track record of delivering complex projects via traditional regulatory compliance methods may not need agile. But for the majority of banks that are struggling to implement regulatory projects on time and under budget, agile offers extraordinary benefits.