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 June 11, 2021

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 nameRule typeUsage
RNGDeterminePurposeByStageDecision 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_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 and KYC considers all the KYC Significant parties as subject to documentary requirements. To implement a different logic, modify the following rules.

Rule nameRule typeUsage
RNGGetRelevantPartiesForSyncData 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
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 nameRule typeUsage
RNGGetSetsLocatorsForSyncData 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.

RNGGetSetsLocatorsForSyncCIPData 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 nameRule typeUsage
RNGSetReqSetContextAppData transformPega 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_ExtData transformIf 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 nameRule typeUsage



Data transformUse the rule to pass additional parameters to the requirement set applicability when rules.



Data transformUse the rule to pass additional parameters to the requirement applicability when rules.



Data transformUse the rule to pass additional parameters to the scenario applicability when rules in requirement.



Data transformUse the rule 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 must 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