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.
Passing additional information to requirement cases
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:
The rule receives the requirement definition and the new requirement case, and it is executed in the context of the customer journey case.
Modify this rule to pass additional information to the newly created requirement case.
Configuring requirement reuse
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:
Use the rule to let the engine know whether to reuse requirements or not. The engine receives the requirement as an input, and it must return a boolean output parameter. If the parameter goes out with true, the functionality is enabled. Otherwise, the functionality is disabled.
Use this rule to implement logic that may depend on the journey type or the type of requirement.
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:
The rule receives the requirement that is considered as input and generates an output parameter with the Satisfaction Logic Indicator.
Modify this rule to implement a more complex logic that can maximize the benefits of the requirements reuse functionality.
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:
The rule returns the false value by default, so the requirement with a past valid end date cannot be reused.
Modify the rule to return the true value if the system must ignore the expiry or stale or both dates of the documents within the requirement.
Configuring document reuse
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:
The rule determines whether the system must reuse or not the expired or stale documents. By default, the rule returns the false value, so the system does not consider expired documents.
Change this rule to return true if you want to enable the reuse of expired or stale documents.
When the system is configured to consider only documents that are expired, the rule uses the current execution date as the date to compare against the expiration or stale date of the document.
Modify the rule if you want the system to ignore documents sometime before the actual expiration or stale, or both dates (for example, three or six months later).
Use the rule to avoid the reuse of documents of a certain type. By default, document reuse is active for all document types.
Modify the rule to control which document types must be considered for document reuse.
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:
The rule acts as a general switch for synchronization. The rule can be turned on and off based on certain conditions. By default, it is always turn on.
Modify the rule if you want to disable the synchronization from your application without modifying all the invocation points or doing it selectively under certain circumstances. The decision should be based on case data.
Map value that determines whether the requirements synchronization needs to be run during the Master Profile synchronization based on the type of case where it is executed.
Modify this rule to enable or disable the requirements synchronization engine based on case type.
The rule gives some control to processes that want to skip or include the synchronization based on certain conditions. The calling process can set the bTriggerRequirements property that the rule checks to skip or not the synchronization.
Use the bTriggerRequirements property to enable or disable the synchronization from specific processes.