Skip to main content


         This documentation site is for previous versions. Visit our new documentation site for current releases.      
 

Flexible due diligence case orchestration

Updated on June 11, 2021

Financial institutions must understand the risk of doing business with their portfolio of clients. Internal compliance teams need to ensure that internal processes are sufficient to satisfy the scrutiny of external regulators. Failure to do so can result in regulators issuing hefty fines and strict timelines to remediate raised compliance issues. In the worst of case, this can even impact the viability of the institution.

The need to understand risk is not just during the initial onboarding but over the lifetime of the client through to offboarding. Many events such as periodic risk-based reviews, data changes, document expiry, and ownership updates result in the need for reassessment of risk.

Due diligence can vary from relatively simple to highly complex, depending on global regions, types of products offered, and market segments served. Any solution that serves these use cases must be flexible based on the level of complexity a financial institution needs to support to operate.

Due diligence can be divided into many categories and subcategories such as AML (Global/Local/Regional), Tax (FATCA/CRS), or Product Regulatory (MIFID/FINRA). A customer may be subject to one or more of these due diligence categories based on various factors such as country of residence, selected products, jurisdictions where the products are onboarded, related parties, and so on.

For example, a US-registered company, New Wave Energy, buys products in the US, France, and Australia and has John Woods as its majority shareholder, see the Due diligence categories image. During the onboarding process, the company attracts the following due diligence categories: some of them are on the company itself and some on its KYC significant related parties (in this case, the majority shareholder). Each of these categories may contain one or more questionnaires, depending on the complexity of the due diligence category and the profile of the customer.

Due diligence categories

Based on its business complexity and operational structure, a financial institution may have a single department for handling all the due diligence or different departments may be dedicated to specific categories and subcategories. Most of the time, financial institutions adopt a unique operational model for all business scenarios. However, in some situations, financial institutions may want to drive the operational model based on certain factors associated with the case. For example, they may want to involve specialized departments only for investigations on their high-risk clients, while a generic due diligence department still evaluates the low-risk clients.

The grouping and routing of due diligence work to those departments is managed in Pega Client Lifecycle Management and KYC by using due diligence cases. Each case generated by the application is routed to a specific department and contains one or multiple questionnaires covering the due diligence categories managed by that department.

Depending on the operational structure of the financial institution, the application can generate a single case with all the due diligence questionnaires or can generate of multiple cases containing the questionnaires specific to each department. For example, a financial institution may opt for managing the due diligence of the scheme shown in the diagram above through a single case routed to a department where all due diligence are conducted. On the contrary, the financial institution may opt for a distributed approach where the application generates ten cases, one per subcategory, and routes each case as appropriate to different specialized due diligence teams.

By default, Pega Client Lifecycle Management and KYC provides three main due diligence categories: Anti-Money Laundering (AML), Product Regulatory, and Tax. There are two additional categories, Credit and Legal, that are provided as placeholders that customers can extend in their implementation layer. The granularity and structure of the cases that drive the processing of each of these categories can be configured in a flexible manner based on your business needs. The configuration can be completed by performing the tasks described in the following two sections.

Have a question? Get answers now.

Visit the Support Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us