Configuring KYC significant flags and controlling flags in CLM

From PegaWiki
Revision as of 19:28, 7 June 2021 by BEAUM (talk | contribs) (updated application name)

(diff) ← Older revision | Approved revision (diff) | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Configuring KYC significant flags and controlling flags in CLM

Description Configuring KYC significant flags and controlling flags in CLM
Version as of 8.5
Application Pega Client Lifecycle Management for Financial Services
Capability/Industry Area Financial Services



Configuring KYC significant flags and KYC controlling flags in CLM[edit]

This document describes the default method that you need to follow in order to configure the KYC significant and controlling logic for related parties in the application.

Use case examples[edit]

Based on roles and their attributes, some related parties are marked as KYC significant. Such related parties are then considered for the due diligence processes, and the required level of due diligence is performed on them only if they have a positive eScreening match, or if they are classified as deemed controlling.

For example, a related party that has the role of Beneficial Owner of an organization should, from a regulatory standpoint, always be considered KYC significant (because a Beneficial Owner can have a controlling role in the organization). However, that Beneficial Owner will only be considered really controlling if its percentage of ownership is above a certain legal threshold (typically 25%), in which case that related party is required by law to undergo due diligence.

How to configure specific logic in your application[edit]

KYC significant status[edit]

The automated assessment for KYC significant status is performed in accordance with the PegaFS-Data-PartypartyXref. KYCSignificantDecisionLogic decision table rule, which is invoked while adding, modifying, or reviewing a related party. Based on the assessment, the bKYCSignificant property is either set to true or false.

While the preconfigured logic for assessing this flag typically covers most regular cases, there might be some situations where you wish to customize the automated assessment. To update the KYC significant logic, carry out the following steps:

  1. In Dev Studio, click Records -> Decision -> Decisions Table.
  2. Search for and select the KYCSignificantDecisionLogic decision table.
  3. Add new conditions or update existing conditions to return true based on your custom logic.
KYC Significant decision table

Deemed controlling flag[edit]

Parties are classified as deemed controlling based on the PegaFS-Data-PartypartyXref. RelevantPartyDecision decision table rule, which is invoked while adding a related party. Based on the assessment, the IsDeemedControlling property is either set to true or false. The property is persisted in the pp_IsDeemedControlling column of the fsf_partypartyxref database table during the customer data synchronization.

While the preconfigured logic for assessing this flag typically covers most regular cases, there might be some situations where the Relationship Manager needs to override the automated assessment. To set the IsDeemedControlling property to false, carry out the following steps:

  1. In Dev Studio, click Records -> Decision -> Decisions Table.
  2. Search for and select the RelevantPartyDecision decision table.
  3. Set the IsDeemedControlling property to false.
Deemed controlling decision table

Related information[edit]

In order to know more about this very topic and other related configuration please go here.