When we look at a typical change program, we wouldn’t think twice about deploying an IT Architect to manage the IT Architecture or a Business Architect to manage the Business Architecture so when a change program involves complex regulations, why don’t we deploy a Regulatory Architect to manage the Regulatory Architecture?

Regulatory change programs are unique to themselves and bring with them a different set of ‘pains’ that require different solutions to solve.

So what are some of the current ‘pains’ in the market?

• “We are struggling with implementation. There are mountains of high-end analysis of the regulations but how do you convert regulations into requirements and a set of deliverables that can be implemented?”

Action: Regulations have changed – gone are the days of Basel 1. The legislative process is multi-dimensional. Legislation evolves in real-time and is dynamic, meaning that a regulatory change program cannot be managed in the same way that a static IT upgrade or software installation project can be managed. The Regulatory Architect uses structured methodologies for ‘mapping’ the relevant pieces of regulation onto the correct work streams.

• “We are drowning in paper. Everyone, across the organisation and at all levels, has the same set of 500 pages of regulations.”

Action: There is no need for this – the Regulatory Architect centralises this operation, deploying intelligent, structured ‘knowledge management’ around the legislative process. This provides the client with a simplified strategy that avoids the typical problems associated with information overload, duplication of the discovery process, incorrect interpretation and so on.

• “Our project isn’t flexible enough. It runs the risk of derailing.”

Action: A regulatory project is de facto a mixed methodology project. It has aspects of waterfall as well as aspects of agile, as the goal posts move around. The Regulatory Architect enables the project to ‘square this circle’.

• “We can’t keep on top of the continuous releases and updates and how it impacts work streams.”

Action: Regulatory releases and updates are pivot points at which projects may need to change direction. The Regulatory Architect deploys a top-down strategy that manages this process.

These pains are typical across any regulatory change project, where the daunting breadth and complexity of global financial regulations is leaving the traditional compliance function drowning under its own weight.

Regulatory Architecture aims to solve these pains, as a function of its ability to “take the compliance function to the coal face”.

In my next blog here, I want to look at the role of the Regulatory Architect and how the Regulatory Architect actually goes about solving these pains.