Execution of ad hoc actions
In certain situations, the response to a question can trigger something more complex than just modifying the basic attributes of another questions. The system might need to perform some complex computations that could result in different kinds of actions.
Complex processing can be articulated in the system through the following configurations available for the KYC items:
- On-Change launch data transform
- Items can be configured to launch a data transform after a response to the question changes. The data transform is executed immediately after the change, and it is followed by the standard process to re-evaluate the basic attributes of the other questions within the KYC Type. This data transform is therefore an ideal place to set responses to other questions, or to set flags and other data elements that might be required later to drive the process.
- Initiate Type Re-Evaluation
- When this configuration is enabled for a given question, and there is a change in the response, the engine finds and applies to the case any additional KYC types that might become applicable because of the new response, or due to any changes triggered by the change.
- Initiate Profile Re-Evaluation
- When this configuration is enabled and there is a change in the response, the system re-evaluates the due diligence profiles associated to the KYC Type. If there is any change in the active profiles of the case, the system then reassesses once again the basic attributes of all the questions in the KYC type.
- On-Change transition data transform
- Items can be configured to launch a final data transform after all the other on-change actions have been completed. All the simple conditions and the on-change actions that are configured for the item are performed before this final data transform. The final data transform can be used to perform actions that are not required by the rest of the on-change processing, such as propagating the list of related parties from a question to the main case's data structure.
The different processes listed above are only executed by the system when the response to the associated KYC Item changes. Most of the time, that change in the response is made by the user using the standard user interface of the application. However, there are other ways in which a response to a question can be changed. The following scenarios can lead to a change in a response:
- When a user responds to a question using the user interface of the application, the system triggers the on-change actions associated to that question.
- KYC Type Initialization
- When a KYC Type is brought into a case, it can be pre-populated using responses previously stored in the Policy Profile or Policy Memory of the customer, or set through the initialization data transforms of the KYC Type. The engine registers the changes made to the responses during this initialization process, and executes the on-change actions associated to the pre-populated questions.
- On-Change imposed
- There can be situations where a response to a question results in a change in another
question. For example, a response to a question about
Country of Birthcan be used to automatically populate a question about the relevant
Country of Citizenship. These scenarios are usually implemented using the on-change launch data transform associated to the first question. However, the changes made to the second question in that data transform are not automatically identified by the engine. To trigger the on-change actions that the second question might in turn require, the change should be flagged up to the system. This can be done by invoking the RegisterPropertyForChange data transform, and passing the name of question that has been changed.
- Visibility driven
- Setting the response to a question triggers the re-evaluation of the simple conditions of all the questions within the KYC Type. This can result in some questions either gaining visibility or losing visibility. When visibility is lost from a question that was already answered, this is considered to be a change. In addition, when the question regains its visibility, the previous responses are recovered, and this event is also recorded as a change by the system. Both changes, that is, that the item has lost its visibility and that the item responses were recovered, then trigger the execution of the on-change processing logic associated to the questions.
To avoid any infinite loops resulting from a chain reaction of linking on-change actions, these actions are executed in a sequential manner, starting from the first question and ending with the last one. This means that any changes made by a question to a question above it in the KYC questionnaire is not taken into account for execution of the on-change actions. However, these changes are still taken into account for the execution of simple conditions, because simple conditions do not pose a risk of generating infinite loops.
Previous topic Re-evaluation of basic conditions Next topic Upgrading on-change actions from 8.5 or earlier versions