The second phase of the synchronization engine takes care of the creation and withdrawal of requirement cases as per the documentary requirements determined during the previous phase.

In this phase, the system iterates through all the requirement sets and requirements that are deemed applicable before and creates or reuses cases for them. In addition, the system withdraws all those cases that, according to the results of the previous phase, are not required anymore. The second phase executes the following tasks:

Case initialization

In the situations where the synchronization engine determines that a new case is required, the system creates the new instance and initializes it with all the data required for its later processing.

Case reopening/reuse

If the system determines that the requirement is already managed in the current customer journey and, therefore, there is a case for it in the system, it process to reuse the requirement (if it is in flight) or reopen it (if it is already resolved).

Case withdrawal

After the system ensures that all applicable requirements have their corresponding case, it withdraws all those cases that were created in previous runs of the synchronization engine and whose requirements are not applicable anymore.

Requirements reuse

If a given requirement is processed before for the same party and within the same Context in a previous customer journey, it can be reused.

Documents reuse

As part of the case initialization, the system checks if the targeted party already has some of the documents requested in the requirement. If any match is found, it is automatically attached to the case and the case made progress to the next applicable stage.

There are few extension points provided in this part of the process for financial institutions to change the default behavior of the engine.

During the initialization of requirement cases, the synchronization engine transfers all the requirement relevant information, along with party data, routing information, and so on.

Additional information can be passed by extending the following rule:

You can reuse requirements completed in previous customer journeys for the same party and under the same context (the same contracting party).

To enable or disable this functionality based on the case data or the journey type, use following when rule:

If the functionality is enabled, the system will search in the requirements metadata table for any completed requirement created in the past that meets the following criteria:

Same party

The requirement is for the same party.

Same context

The main journey is for the same contracting party.

Same requirement

The same name as per requirement definition.

Same scenario

The requirement is resolved with the same scenario that is currently active.

No changes in the requirement

The requirement definition is the same since its use.

To implement the last of the checks, to determine whether the requirement definition is changed since the requirement is resolved, the system uses the Satisfaction Logic Indicator. This indicator is a string that is set at the time of the resolution of the requirement and which is later used during the requirement use logic.

By default, the system sets the last update time of the requirement definition (pxUpdateDateTime) as the Satisfaction Logic Indicator. So any update in the definition of the requirement prevents the reuse of previous instances of requirements of that type.

While the conservative approach works well for many financial institutions, you might want to make changes and create a more sophisticated logic to generate the string. For example, generate a hash from the satisfaction logic and its associated documents to give more flexibility to the reuse process and therefore reduce the operational load of the teams.

To implement your the Satisfaction Logic Indicator, use the following rule:

At the time of the assessment, the system also considers if any one of the previously provided documents to satisfy the requirement is expired or stale. If that is the case, the requirement cannot be reused. To change this behavior, extend the following rule:

When you created the requirement case, the system checks if the customer has already provided documents requested by the requirement in the past. The system automatically attaches all those documents that could previously exist and, depending on the status of the document and the satisfaction logic, make the case progress to the appropriate stage.

For example, if a requirement expects either a passport or a driver license from a given party, and that party already provided the passport in a previous journey, the system can automatically attach the document and try to make the case progress. To satisfy the requirement that only one document is required, the case leaves the initial stage of Satisfy and goes into the next Data capture stage. If the passport went already through the Data capture stage in the past, the system determines that the second stage is not required and makes the case progress to the third one, the Verification stage.

However, if the logic of the requirement is different and requires both documents, passport and driver license, the system can attach the document automatically but is not able to make it go beyond the first Satisfy stage, where the case waits for a second document to be uploaded.

To change some of the behavior of this functionality, use the following rules:

Pega Client Lifecycle Management and KYC executes the requirements synchronization engine in most of the synchronizations with the Master Profile.

To change the behavior of the functionality and restrict its execution to only certain stages or steps in the process, use the following rules:

• Synchronization engine