Part I - Building a Dynamic Customer Profile using MongoDB

Welcome to our series on Building a Financial Crime Mitigation Platform using MongoDB as the unified data platform able to support the demands from modern digital financial operations. In case you missed it, be sure to check out the Series overview.

We’ll kick off our journey in the stage where every customer experience begins: Onboarding a new customer, or as it is known in the risk management world, a new “entity” (to unify the concepts of individuals and corporations). Let’s explore the steps involved in the process!

Step 1: Capturing prospective customer data

In the pursuit of converting a new prospect into a customer, financial institutions start by capturing required data: from basic (demographical) data, through legal identification and tax information, to capturing any relevant data related to the financial life of the prospective customer (credit bureau/FICO scores, assets, and potential collaterals). 

As soon as these data points are captured, you need to build a dynamic profile that will be continuously updated in an “event-driven” way. Building a dynamic profile aims to accomplish two goals: complying with Know-Your-Customer (KYC) regulations, while at the same time segmenting the customer for commercial purposes (i.e., finding the best offering).

Technically speaking, this represents a major challenge: to have a dynamic profile, we need to aggregate data coming from different sources and schemas. This is where MongoDB’s flexible data model shines.

Figure 1. From static to perpetual monitoring.

MongoDB’s data model is able to aggregate all incoming data seamlessly. It also provides data platform services natively integrated and exposed in a unified API that can be consumed by customer-facing applications, or by support and operational systems.

Figure 2. Converged data store for KYC.

Step 2: Candidate basic checks

Once prospective customer data has been captured, financial crime mitigation checks start with a deceptively simple question: who is this entity? In compliance check programs, the answer is rarely straightforward. A single real-world person or business can appear across systems with different names, addresses, identifiers, and relationships, sometimes due to benign data quality issues, sometimes as a deliberate attempt to evade detection.

Thus, a comprehensive comparison is required (beyond just text). Again, MongoDB’s capabilities shine. We can combine text and contextual (semantic) data to get better results; this is called hybrid search using the MQL $rankFusion operator.

Figure 3. Example of parallel search results showing MongoDB’s advanced search capabilities.

(Image taken from our demo prototype. Disclosure: The look and feel is from a custom UI developed for demo purposes. It is not part of MongoDB’s offering.)

The greatest benefit of using MongoDB is having all these advanced search capabilities integrated and available within the same MongoDB cluster, without the need to move the data elsewhere or having to use third-party external search engines.

Step 3: Compliance verification

After identifying similar profiles, we must now run compliance checks. The main goal is to analyze the entity’s relationships, and for this we need to scan through all potential links with existing bank’s customers and high-amount transactions. Technically speaking, we need to a network graph of all possible relationships:

Figure 4. Example of an entity’s network graph.

(Image taken from our demo prototype. Disclosure: The look and feel is from a custom UI developed for demo purposes. It is not part of MongoDB’s offering.)

Building this network graph is possible using MQL $graphLookup, an operator available through MongoDB’s aggregation pipeline. The biggest benefit of using MongoDB is that whenever you need to adjust to a higher confidence level, it can rebuild the network instantly as you adjust depth and confidence filters with no pre-computed graph tables or cache invalidation required.  

Instantaneously, you can unveil the different possible entity relationships, each with the corresponding degree of confidence.

Figure 5. Example of the relationship analysis.

(Image taken from our demo prototype. Disclosure: The look and feel is from a custom UI developed for demo purposes. It is not part of MongoDB’s offering.)

This output sets the foundation for a behavioral analysis that will converge into a single view of the customer profile.

Final Step: Building a single customer view

After gathering these data points, the final step (for now) is to aggregate them into one single view of the customer profile. Here, MongoDB’s data model brings the flexibility required to centralize all the dynamic data that will be captured not once, but in a continuous way.

Figure 6. Example of an entity stored in MongoDB’s document structure.

(Image taken from our demo prototype. Disclosure: The look and feel is from a custom UI developed for demo purposes. It is not part of MongoDB’s offering.)

MongoDB’s data model excels in a single-view model by being able to combine structured data, along with unstructured data that could potentially coexist with a vectorized representation of the profile, which will help to find similar profiles, and cluster customer profiles more effectively.

Figure 7. Example of similarity search results.

(Image taken from our demo prototype. Disclosure: The look and feel is from a custom UI developed for demo purposes. It is not part of MongoDB’s offering.)

Takeaways

Onboarding a new entity as a customer (whether individual or corporate prospect) requires a modern data platform that can capture incoming data from different sources, in different formats and schemas. 

The most critical factor for a successful anti-financial crime operation is building a dynamic customer profile. Hence, capturing and processing all possible data points is crucial. We also need to understand the entity’s potential relationships with existing customers or with known transactions. For this, MongoDB aggregation pipeline capabilities—like creating an “on-the-fly” network graph—can unveil unnoticeable behavior.

Finally, the data and analyses must converge in a single view. Here, MongoDB’s data model’s flexibility is a game-changer. It is able to store—at scale—structured and unstructured data in a single instance. It can also combine that with a vectorized representation of the profile to run similarity searches accurately. 

In the next article of this series, we will dive deeper into how AI can enhance due diligence processes as part of a comprehensive due diligence using the customer behavioral profile. Stay tuned!