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: 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. 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. 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. 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. 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. 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: 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. 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. 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. 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: 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: 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: RNGEvaluateSet ApplicabilityWhenParams_Ext RNGEvaluateRequirement ApplicabilityWhenParams_Ext RNGEvaluateScenario ApplicabilityWhenParams RNGEvaluateScenario ApplicabilityWhenParams_ExtConfiguring the relevant purposes
Rule name Rule type Usage RNGDeterminePurposeByStage Decision table 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
Rule name Rule type Usage RNGGetRelevantPartiesForSync Data transform Building up the requirement sets locators
If your organization organizes CIP requirements differently or introduces a new
purpose, you need to review this logic and make changes accordingly. To modify the
logic, use the following rules:
Rule name Rule type Usage RNGGetSetsLocatorsForSync Data transform RNGGetSetsLocatorsForSyncCIP Data transform Adding more information to the Context
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
Rule name Rule type Usage Data transform Use the rule to pass additional parameters to the requirement set
applicability when rules. Data transform Use the rule to pass additional parameters to the requirement
applicability when rules. Data transform Use the rule to pass additional parameters to the scenario
applicability when rules in requirement. 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