Skip to main content

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

First phase of synchronization: determination

Updated on February 16, 2021

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 nameRule typeUsage
RNGDeterminePurposeByStageDecision 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_ExtData transformIf 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 nameRule typeUsage
RNGGetRelevantPartiesForSyncData 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 nameRule typeUsage
RNGGetSetsLocatorsForSyncData transformEntry 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.
RNGGetSetsLocatorsForSyncCIPData transformRule 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 nameRule typeUsage
RNGSetReqSetContextAppData transformRule 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_ExtData transformIf 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 nameRule typeUsage



Data transformUse this data-transform to pass additional parameters to the requirement set applicability when rules.



Data transformUse this data-transform to pass additional parameters to the requirement applicability when rules.



Data transformUse this data-transform to pass additional parameters to the scenario applicability when rules in requirement.



Data transformUse this data-transform to pass additional parameters to the scenario applicability when rules in requirement.
Note: The preferred mechanism to pass additional data to the applicability when rules is still the context. The addition of parameters should only be considered when the data is already available in a complex data structure which mapping to the context may not be efficient.

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. is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us