First phase of synchronization: determination
During this initial phase of the synchronization, the system determines the documentary requirements that apply at that very moment in time, with the currently available data.
During the first phase, no action is taken. The system just builds up the data structure with the requirements that the relevant case parties need to satisfy. This structured data 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, and so on. Applications can configure which purposes must be subject to synchronization depending on the stage, case types, and others.
- Determination of relevant parties
- For each of the purposes, applications can define the parties subject to documentary requirements. For example, Pega Client Lifecycle Management and KYC considers that all parties flagged as KYC Significant must be considered for CIP requirements.
- Determination of requirement set locators
- For each purpose and party, the system builds the locator, a composite key of three values that facilitates quick access to relevant requirement sets.
- Preparation of context
- For each relevant requirement, the system prepares the data that is used during the assessment of its applicability. This data set is known as Context and it is made up of all the pieces of data that drive that applicability logic. For example, in the case of Pega Client Lifecycle Management and KYC CIP requirements, the context contains the following data: the role of the customer, jurisdictions, risk information, and so on. Any piece of data that may be required during the assessment of the applicability rules associated with requirement sets and requirements.
- Applicability assessment
- After the relevant requirements sets are identified and retrieved, and the Context is set, the system assesses each individual requirement set, requirement, and determines their applicability.
Pega Client Lifecycle Management and KYC 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 others) based on case information. To change the default behavior, modify the following rules.
| Rule name | Rule type | Usage |
| RNGDeterminePurposeByStage | Decision table | The rule that returns a CSV list of purposes based on the case stage If it returns the string NONE, the engine does not consider any requirement set. If it returns an empty value, the system considers all available purposes. By default, the rule returns CIP for the first three stages of the CLM journey (capture, enrich, and due diligence) and NONE value for any other. Modify the rule by adding or removing stages or add any other piece of data to the decision table 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 and KYC considers 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 | The rule receives the purpose name as a parameter and returns a list of parties. The configuration by default does not distinguish by purpose and move into the resultant list all parties in the system flagged as KYC Significant. |
Building up the requirement sets locators
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 system compares the key generated during the synchronization against the key defined in the requirement set at the creation time.
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 Australian 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 triggers 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 a locator with the same purpose and locator key that the one provided and a generic modifier with value Default.
Pega Client Lifecycle Management and KYC set the following values of the locators:
- Purpose CIP/RetailCIP
- Locator key Entity/Individual
- Locator modifier Default
| Rule name | Rule type | Usage |
| RNGGetSetsLocatorsForSync | Data transform | The entry point for the generation of locators during synchronization If you add a new requirement set with a new purpose, you must modify the rule so that requirement sets can be found. Follow the pattern of the base version of the rule and invoke here to your purpose-based specialized data transforms. |
| RNGGetSetsLocatorsForSyncCIP | Data transform | Use the rule 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 contains all the pieces of data that drive the applicability logic.
The Context is used during the following three assessments. Any of those assessments require any piece of data that must pass through the Context.
- Requirement set applicability logic
- Requirement applicability logic
- Requirement scenario applicability logic
In Pega Client Lifecycle Management and KYC, the party information drives the applicability logic of CIP requirements. See the most relevant pieces of information on the following list:
- 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 create your own requirement sets under a new purpose, you need to modify some of the following rules:
| Rule name | Rule type | Usage |
| RNGSetReqSetContextApp | Data transform | Pega Client Lifecycle Management and KYC uses the rule to set the Context for CIP requirements. If you need to consider additional purposes or change the logic significantly for CIP, overwrite this rule. If changes are not significant, consider leaving this rule and using 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 in 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, you can configure the rules 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 the rule to pass additional parameters to the requirement set applicability when rules. |
RNGEvaluateRequirement ApplicabilityWhenParams_Ext | Data transform | Use the rule to pass additional parameters to the requirement applicability when rules. |
RNGEvaluateScenario ApplicabilityWhenParams | Data transform | Use the rule to pass additional parameters to the scenario applicability when rules in requirement. |
RNGEvaluateScenario ApplicabilityWhenParams_Ext | Data transform | Use the rule to pass additional parameters to the scenario applicability when rules in requirement. |
Previous topic Synchronization engine Next topic Second phase of synchronization: implementation