First phase of synchronization: determination
During this initial phase of the synchronization, the system determines which are the documentary requirements that applies at that very moment in time, with the current available data.
During this phase, no action is taken. The system just builds up the data structure with the requirements that the relevant case parties will need to satisfy. This data structured is known as the DocGroup. The main tasks executed in this part of the process are:
- Determination of applicable purposes
- Requirements sets are classified by purposes (for example, CIP, TAX, etc.). Applications can configure which purposes should be subject to synchronization depending on the stage, case types, and other.
- Determination of relevant parties
- For each of the purposes, applications can define the parties subject to documentary requirements. For example, Pega Client Lifecycle Management for Financial Services considers that all parties flagged as KYC Significant should be considered for CIP requirements.
- Determination of requirement set locators
- For each purpose and party, the system builds what is called the locator, a composite key of three values that facilitates a quick access to relevant the requirement sets.
- Preparation of context
- For each relevant requirement, the system prepares the data that will used during the assessment of the its applicability. This data set is known as Context and it is made up of all those pieces of data that drives that applicability logic. For example, in the case of Pega Client Lifecycle Management for Financial Services CIP requirements, the context contains data like the role of the customer, jurisdictions, risk information, etc. In summary, any piece of data that may be required during the assessment of the applicability rules associated to requirement sets and requirements.
- Applicability assessment
- After the relevant requirements sets are identified and retrieved, and the context is set, the system assess each individual requirement set, requirement, and determines their applicability.
Pega Client Lifecycle Management for Financial Services comes with a fully functional configuration of the module for its CIP requirements. Financial institutions, however, might want to make changes to the standard configuration or expand the use of requirements to other purposes and types of documents.
Configuring the relevant purposes
As mentioned before, the system can determine the purposes subject to synchronization (for example, CIP, Tax, and other.) based on case information. To change the default behavior modify the following rules:
| Rule name | Rule type | Usage |
|---|---|---|
| RNGDeterminePurposeByStage | Decision table | Rule that returns a CSV list of purposes based on the case stage. If it returns the string NONE, the engine will not consider any requirement set. If it returns an empty value, the system will consider all available purposes. By default, it returns CIP for the first three stages of the CLM journey (capture, enrich and due diligence) and NONE for the any other. Modify this rule add or remove stages, or add to the decision any other piece of data that might be required. |
| RNGGetSetsPurposesForSync_Ext | Data transform | If the logic to determine the purposes is too complex and cannot be implemented in a decision table, overwrite this rule. |
Configuring the relevant parties
Pega Client Lifecycle Management for Financial Services consider all the KYC Significant parties as subject to documentary requirements. To implement a different logic modify the following rules:
| Rule name | Rule type | Usage |
|---|---|---|
| RNGGetRelevantPartiesForSync | Data transform | This rule receives the purpose name as parameter and returns a list of parties. The configuration by default does not make distinction by purpose and move into the resultant list all parties in the system flagged as KYC Significant. |
Building up the requirement sets locators
In order to find the relevant requirement sets for a given purpose and party, the system uses a composite key made up of three values: purpose, locator key and locator modifier. The key generated during the synchronization is compared against the key defined in the requirement set at the time of creation.
For example, a requirement set is defined with the following values: purpose CIP, locator key Entity, and locator modifier Australia. At the time of synchronization, the system uses this information to assess this requirement set only during the evaluation of CIP requirements, when the customer is an entity and only if there are products in the Australia jurisdiction.
A given party can trigger the search of requirement sets based on multiple locators. For example, a customer with products not only in Australia but also in the US will trigger a search for requirements sets with multiple locators: purpose CIP, locator key Entity, and locator modifier Australia or US.
It can also be specified that, if no requirement set is found for the provided locators, the system searches again using this time a locator with the same purpose and locator key that the one provided and a generic modifier with value Default.
Pega Client Lifecycle Management for Financial Services set the values of the locators as follows: purpose CIP/RetailCIP, locator key Entity/Individual and locator modifier Default. If your organization has organized CIP requirements in a different way or introduce a new purpose, you will need to review modify this logic and make changes accordingly. The following rules can be used for that purpose.
| Rule name | Rule type | Usage |
|---|---|---|
| RNGGetSetsLocatorsForSync | Data transform | Entry point for the generation of locators during synchronization. If you have added a new requirement set with a new purpose, you must modify this rule so that requirement sets can be found. Follow the pattern of the base version of the rule and invoke here to your purposed-based specialized data-transforms. |
| RNGGetSetsLocatorsForSyncCIP | Data transform | Rule used to build the locators for CLM CIP requirements. If you have re-arranged the CIP requirement sets, you can modify this rule to change locators accordingly. |
Adding more information to the context
The applicability of each relevant requirement set is assessed for each relevant party. Use the Context to execute the assessment, a data set that contain all the pieces of data that somehow drives the applicability logic.
The context is used during the following three assessments. Any piece of data required by any of these assessments should be passed through the context.
- Requirement set applicability logic
- Requirement applicability logic
- Requirement scenario applicability logic
In Pega Client Lifecycle Management for Financial Services, the applicability logic of CIP requirements is mainly driven by party information. These are some of the most relevant pieces of information:
- Customer Type
- Main customer type
- Regulated organization flag
- Listed organization flag
- Existence of business address
- Existence of screening results
- PEP indicator
- Customer subtype
- Jurisdictions
If your organization requires additional information for the assessment of CIP requirements or you have created your own requirement sets under a new purpose, you will need to modify some of the following rules:
| Rule name | Rule type | Usage |
|---|---|---|
| RNGSetReqSetContextApp | Data transform | Rule used by Pega Client Lifecycle Management for Financial Services to set the context for CIP requirements. If you need to consider now additional purposes or you have changed significantly the logic for CIP, you may want to overwrite this rule. If changes are not significant, consider leaving this rule as it is and use the next extension point. |
| RNGSetReqSetContextApp_Ext | Data transform | If you need to add some additional pieces of information to the context generated out-of-the-box, implement this rule at your application. |
Passing additional parameters to applicability assessment
The assessment of applicability is implemented in the system by when rules associated to requirement set and requirements. Each of these when rules receive the context as a page-name parameter. However, they can be configured to receive additional parameters.
If you had to pass additional data to the applicability logic and passing it through the context is not a good option, consider adding a new parameter using these two rules:
| Rule name | Rule type | Usage |
|---|---|---|
RNGEvaluateSet ApplicabilityWhenParams_Ext | Data transform | Use this data-transform to pass additional parameters to the requirement set applicability when rules. |
RNGEvaluateRequirement ApplicabilityWhenParams_Ext | Data transform | Use this data-transform to pass additional parameters to the requirement applicability when rules. |
RNGEvaluateScenario ApplicabilityWhenParams | Data transform | Use this data-transform to pass additional parameters to the scenario applicability when rules in requirement. |
RNGEvaluateScenario ApplicabilityWhenParams_Ext | Data transform | Use this data-transform to pass additional parameters to the scenario applicability when rules in requirement. |
Previous topic Synchronization engine Next topic Second phase of synchronization: implementation