Regulations do not exist in a vacuum. They impact the corporate data landscape, the processes architecture, etc. For instance, more than one regulation affects client data, the processes around trading, or the data required for financial reporting. Moreover, the implementation of financial regulations are not usually the only active change project in a financial institution. Assessing the impact of a new set of rules on the data landscape, the architecture, and the other active change processes can save time later.
As an example, if there is a project to upgrade the client relationship management support, it makes sense to check if the new regulation impacts it even if you are not going to implement it for a while. The extra work now will save time later because you will not have to ‘upgrade’ the CRM software, or even if you do, you will know what to do and when to do it. If you have any regulations due to become effective within a reasonable timeframe (let’s say six months), it pays to look for commonalities or areas impacted by both. After all, it is the same data landscape, the same architecture; they may affect the same processes. Each regulation has its own specificity, usually reports, mainly concerning trading, client relationship, financial reporting, etc. Some may require an audit trail; others may add attributes to entities in your data landscape or require new entities. In any case, they are applied to the same corporate environment. They use the same data landscape. A high-level strategic overview of their impact will simplify implementation.
Compiling a regulation is a relatively lengthy process. Regulators in major financial centers have a method to define any set of rules that involve a lot of consultations with the industry. Even though the details are not finalized, the high-level principles are enough to give you an idea of which areas will be affected. You can start a high-level impact analysis and flag any business area that might be touched by the new regulations, so any other project in any one of those areas could be reviewed to see if the forthcoming regulations might change anything included in those projects. You may not have the details, but awareness may prompt extra care in the documentation that may become useful later, or you may alert stakeholders that there will be changes in the near future. Details may not be finalized yet, but you know they will. Taking two steps back is a better use of time, and it saves on costs, gives better results, and helps you manage stakeholders’ expectations.
Looking at commonalities does not just help during the implementation stage. Data is the most valuable asset of a financial organization. Reporting uses data from the same data landscape. Taking good care of the data takes care of the most valuable asset of the organization. Different regulations may require the same information to be reported in various formats, but it is the same information, to begin with. Static data or reference data are often organized slightly differently, especially when there are two different regulatory bodies or two different teams. In Europe, MiFID and SFTR manage all the classifying codes as four alphanumeric characters; EMIR has identical codes but uses two alphanumeric characters. It is the same information. In the United States, the CFTC and the SEC have been known to give two different detailed meanings to the same concept. Processes receive data from somewhere, do something with it and send it somewhere else. As far as reporting is concerned, that somewhere else is outside the organization. As long as you know the logic required to turn the information you manage (that could be common to many regulations) and the data you report (specific to one regulation), you can have conversion tables specific to how each regulation manages the information.
It may seem like the opposite of taking two steps back, but it isn’t. Your data supports the corporate processes, and the regulator may require data in a particular format for their processing requirements. If you keep the two separate, you do not clutter your database; you just have a separate repository that you need for regulatory reporting. A repository that can be maintained in isolation from the primary corporate data management activities provided you know the logic of any correlation between the two.