One solution to protecting financial data is simply to treat all data as sensitive. This would avoid the complicated work of developing and implementing complex data aggregation tools and procedures. However, this all-or-nothing approach would lead to unnecessarily
large data storage requirements, especially in large firms. If a firm has global locations in varying jurisdictions, the problem becomes even more complex. According to the Institute of International Finance, limitations in IT systems in complying with multiple
regulators can lead to inefficiencies in data aggregation which, in turn, can lead to "less sensitive data being over-protected and under-utilized because it is held in cumbersome datasets with more sensitive data."
Certain RegTech solutions can directly address this issue. By applying intelligent data extraction tools that are based on key fields, a subset of required data comprised of only required information can be created. The centralization of non-sensitive data
eliminates the need for repeated calls to back-end systems for each required regulatory end-point. Further, metadata management applications can be deployed to further analyze large volumes of data through direct calls to a single instance of the database.
If supporting multiple database systems across the enterprise, the identification of sensitive data fields will require the creation and maintenance of separate subsets. In addition, if global locations are utilizing different systems, not only will there
be a need for separate subsets but jurisdictions may require additional or different information. A common and recurring problem within the global financial industry is the different definitions and terms for central concepts between regulatory jurisdictions
and markets, making gathered data hard to aggregate and map. Until global harmonization of terms and accounting standards are agreed (if ever), the use of intelligent mapping tools to define common but disparate fields across systems will be required. Solutions
with robust rules-based business logic that can be applied to varying data models will be in high demand.
The exercise to build extracts based on sensitive data elements may be the first major task in creating a RegTech compliance roadmap. Next logical step would be to identify common field requirements across global locations and jurisdictions for compliance