In the financial industry, there is a constant stream of new regulations that need to be understood and implemented. The magnitude of regulatory change will depend on the scope of the regulation as well as its applicability to your organization. Some regulations are very significant and impact the whole organisation, others are less consequential and affect only a single function, process, or system. The risk of change overload is real, as at any one moment there may be multiple regulatory deadlines that must be managed in parallel.

From experience executing a number of global regulatory change projects (mostly EU), there are three areas of implementing regulatory change that pose a particular challenge:

  • ambiguity of the regulatory text,
  • inflexible time frame,
  • and engagement of resources within the organization

At first glance, these may not appear very different from other change initiatives, however, there are subtle differences because of the external compliance imperatives.

Ambiguity of regulatory text

The text of the Directive, Regulation, and the RTS (regulatory technical standard), is often not prescriptive. This means that there is considerable room for interpretation as to how it should be applied in order to comply with the regulation, depending on the business area. To add to the implementation complexity, each national regulator may have local specifications. 

The repercussions of a regulation can be much broader than the scope of the regulation itself, for instance, having to provide data for SFDR (Sustainable Finance Disclosure Regulation) reporting requires collection, validation, and storing of data. Automating the extraction of existing data and incorporating new data requirements led to a widespread revision of current models of data storage and retrieval.

Financial institutions can (and do) influence some aspects of the regulation through lobbying the regulator either individually or through industry bodies at the consultation phase and later, as the consequences of the regulation become clearer.

Inflexible timeframe

Once the date is fixed for when a regulation comes into force, there is little room for manoeuvre.  The inflexibility of the date is a constant challenge as the “time” constraint in the schedule/budget/scope project balance is fixed, and the “scope” can only be modified within limits, as it must deliver sufficient capability to ensure compliance. A consequence of this time constraint is that there will be a continual review of the scope: what must be delivered before the effective date to ensure compliance and what may be implemented in a second phase, post-regulatory date. The second phase will, for example, focus on automating and embedding the new processes and systems. This constant review of the scope leads to adjusting the plan so as to manage the compliance risk.

Although regulatory projects work to immovable deadlines, regulatory dates do sometimes get changed, for example, a number of regulatory dates were postponed during the Covid-19 pandemic in recognition of the difficulties in maintaining the business-as-usual activities. However, this is not very frequent, and formalising a revised deadline (e.g. by the EU parliament) is often a lengthy process that can take months and adds to the project uncertainty.

Engagement of resources

As regulatory change is not initiated from inside the organization but is imposed externally, there is not always a natural sponsor for the change. This can lead to too little engagement early in the project from stakeholders such as decision-makers and subject matter experts. A consequence of incomplete or late involvement can be that there are last-minute modifications to the requirement and the design.

Both identifying and ring-fencing the right resources can be conducted early in the project lifecycle as soon as the project is agreed to be necessary e.g through “regulatory watch” activities. High-level planning can determine the timing of each project phase as well as the competencies that will be required. It is not always clear who will own the new processes: the owner should be evident where an existing process must be modified, but the responsibility for new functionality may not be obvious. In addition, representatives of the teams who will run the new processes once implemented should be involved. For example, the legal team may own pre-contractual documents, but they do not own all the content of the document, so investment teams will need to be involved in ensuring that the document is coherent and meaningful for clients.

Whilst much of a regulatory change programme is a “project” like any other, it does present some unique challenges around the source of the change and the need to involve expert resources within the organization in a “change” that is not of their making. Being aware of the unique features of regulatory change helps with anticipating project needs and stakeholder involvement and hence a more effective and efficient implementation of a compliant solution.

Article by our Kathryn Duperrex, consultant at Taleo Consulting.