Financial Crimes Compliance - Data Strategy

Read the first article in this series here.

The Case for an Actionable Data Catalog

In our previous discussions, we explored the difficulties that large financial services organizations encounter in evolving their financial crimes compliance functions from reactive to proactive. We also examined various process and organizational changes that could facilitate this shift. In this article, we will delve into the most significant hurdle these global financial institutions face on their path to proactive financial crimes compliance, an actionable Data Catalog, as the foundation for the financial crimes compliance data strategy.

According to Gartner, a Data Strategy is described as "a highly dynamic process employed to support the acquisition, organization, analysis, and delivery of data in support of business objectives."

In the realm of Financial Crimes Compliance, the business objective is to ensure that all regulatory mandates are adhered to promptly, ensuring no monitorable transactions are missed. If banks can proactively comply with these regulations—preferably before any fines are imposed—it is significantly better for both their bottom line and reputational integrity.

This objective can only be met if the data is accurate, complete, consistent, timely, and unique. These standards pose a challenge for any single complex operational or warehouse system, and even more so for a global enterprise. While it's a formidable challenge, like many substantial issues, the solution often lies in taking incremental steps. Starting with small, manageable actions and building upon them is a prudent approach.

This is why I recommend beginning with a Data Catalog. Knowing what data you possess and how the data is tied to your business processes is a crucial first step towards proactive compliance.

Many organizations have indeed attempted to create data catalogs, but these typically fall into one of two categories: "Business Process Model" catalogs or "Physical Data Store" catalogs. Each type, by itself, has the inherent gap of data lineage between business processes and associated data entities, rendering them “reactive”. By the time these catalogs are constructed, they often become outdated due to changes in either the business process models or the operational applications.

In the case of Business Process Model catalogs, I've observed business processes being decomposed into three or four levels of hierarchy, where the most granular layer is defined as a "data entity." However, this is still a synthetic construct and not a physical data entity. This approach aims to align data with specific business processes, but it can become disconnected from the actual data storage and handling practices as processes evolve.

On the other hand, Physical Data Store catalogs often involve pulling metadata from physical databases into a centralized data store to build a data catalog. However, the data entities in these catalogs are frequently isolated from the business processes they support and are segmented by system boundaries, which limits their usefulness in understanding the broader data landscape.

Let’s consider a business process catalog for Anti-Money Laundering (AML).

Similarly, let’s also examine a physical data catalog that corresponds to Anti-Money Laundering.

The first catalog stops at level-3 of the business process model, which is a simpler and much higher construct not connected to the physical catalog. The second catalog, while documenting very relevant information for data used in Anti-Money Laundering, doesn’t connect to any business process. To address this limitation, many organizations tie a level-3 business process directly to an IT system. This creates awareness of which IT systems are related to, say, Detection, but doesn’t provide any actionable intelligence.

One way to make a catalog proactive and actionable is to extend the business process model to a level where processes can be directly connected to data attributes in the physical catalog. At that point, both catalogs can merge together as one unit, enabling a seamless connection between data and processes. This integration can drive financial crimes compliance changes from data-to-processes or process-to-data, making the catalog a powerful tool for proactive compliance.

Let’s see how we can connect the two where any changes to processes or data can trigger an action.

In the diagram above, we have expanded the business process model to a level (level-5 in this example) where the processes become granular enough to be associated with physical data elements in the data catalog. Please note, this is a high-level representation of the data model only; the arrows show the relationships between business processes and one or more data entities. The actual data attributes under these entities will only come from physical implementation.

At this point, we can begin to merge the two catalogs as one. Here is an outline of how we go about it.

To connect the two catalogs—business process models and physical data stores—where any changes to processes or data can trigger an action, we can follow these steps:

1.     Identify Key Business Processes: Break down business processes into detailed, granular levels that can be mapped to specific data attributes. For example, in AML, processes like "Transaction Monitoring" or "Customer Due Diligence" need to be decomposed into actionable steps.

2.     Map Data Attributes to Processes: Link each granular business process to corresponding data attributes in the physical data store. This involves creating a detailed mapping of data attributes (e.g., customer ID, transaction amount) to specific process steps.

3.     Establish Data Lineage: Ensure clear data lineage that traces the flow of data from its origin (source systems) through various transformations to its final use in business processes. This helps in understanding how data attributes influence business processes and vice versa.

 4.     Integrate Catalogs: Merge the business process model catalog and the physical data store catalog into a unified system. This unified catalog should allow for bi-directional navigation—from processes to data and from data to processes.

 5.     Implement Automation for Change Management:

o   Change Detection: Implement mechanisms to detect changes in data attributes or business processes. This could involve monitoring tools or automated scripts that flag changes in real-time.

o   Trigger Actions: Define rules for actions to be triggered by changes. For example, if a new data attribute is added or an existing one is modified, update the corresponding business process. Conversely, if a business process is altered, ensure that the relevant data attributes are adjusted or reviewed.

6.     Use Technology Tools: Utilize technology platforms that support integrated data management and business process management. Tools like metadata management systems, process mining tools, and data lineage solutions can help in maintaining and updating the integrated catalog.

7.     Continuous Improvement: Regularly review and update the unified catalog to ensure it remains current with organizational changes. Engage stakeholders from both the business and technology sides to ensure alignment and address any gaps.

8.     Governance Framework: Establish a governance framework that oversees the catalog's maintenance, ensuring data quality, consistency, and compliance. This framework should include policies, procedures, and roles responsible for managing the integrated catalog.

Look forward to feedback and comments as I prepare for the next article in the series. Happy reading!