Applicability matrix
With this approach, the applicability of the KYC Types is configured in the applicability matrix decision table that gives a comprehensive view of all the KYC Types managed by the case or the application. Using this configuration, the engine does not need to traverse all the KYC Types in order to determine their applicability. Instead, it evaluates the central decision table and, in a single execution, determines the applicability of all the KYC Types. This approach offers significantly better performance than using standard applicability conditions.
You can add any condition that you deem appropriate to drive the applicability of the KYC Types. The decision table is run in the context of the case where the applicability process is invoked (see Configuring case processes ), and has access to all the case data, including any customer information that might be required. For example, if a certain KYC Type is only applicable for customers of type individual, a condition can be added to the table and configured to check against the property in the case that holds the customer type.
The applicability logic ensures that the KYC Types that are shown to the customer are applicable in the specific business scenario defined by the case data. However, it can also be used to drive the operational needs of the financial institution by distributing KYC Types across multiple cases that can be routed to different departments based on the nature of the data to be captured and assessed.
For example, a financial institution might be responsible for managing KYC Types for AML, Tax and Regulatory needs. All KYC Types can be presented in a single assignment to a single user, but it is likely that the organization prefers to group the KYC Types by category, and route them to different users. Each of these groups can, in turn, be further subdivided into smaller groups. For example, AML KYC Types can be divided into Global AML, US AML, UK AML, and so on.
To meet these operational needs, the system provides the ability to define locators, an abstract construct that facilitates the dynamic grouping of KYC Types without having to make significant changes to the orchestration layer. For more information, see the subchapter "Configuring locators" below.
Enabling applicability matrix
The applicability matrix is used by default in new installations. If you upgraded from version 8.5 or earlier, and you want to make use of the applicability matrix, you must enable this functionality.
Use the following Dynamic System Setting to switch the use of the matrix on and off:
| Purpose | Dynamic System Settings |
| Applicability Matrix Switch | PegaKYC - DDSmartFilter = true A value of true enables the applicability matrix, but the value of false activates the standard applicability mechanism. |
If you want to make the configuration specific to an application, instead of applying the configuration to the whole system, you can override the value of the Dynamic System Settings in the KYCSettings_DDSmartFilter data transform.
Note that this switch allows you to choose the applicability mechanism that your application will use. However, it does not automatically migrate the applicability of the KYC types from one method to another. Therefore, before you switch from one mechanism to another, you must ensure that the corresponding applicability conditions are properly configured.
Configuring the applicability matrix
The applicability matrix is implemented as a decision table that holds the applicability conditions for each of the KYC Types that must be applied to a case. The KYC engine provides a template version of the decision table (called KYCApplicabilityMatrix), and this is available under Work- Class. This template rule defines how the applicability matrix should look.
In the table, every row represents the logic that makes applicable one KYC Type. One KYC Type can have multiple rows if its applicability logic cannot be expressed in a single row. All the rows in the decision table are evaluated. If the conditions of a row are met, the associated KYC Type, which is defined in the last two columns of the table, is added to the list of applicable KYC Types of the case. At the end of the process, the list of applicable KYC Types will have as many rows in the table as were satisfied.
To define your own applicability logic, make a copy of KYCApplicabilityMatrix under your class hierarchy. You can choose to have a single copy under your main workpool if you want to have a single point of configuration. If your logic is too complex, or the number of KYC Types is too large to be maintained in a single decision table, you can specialize it by class by creating copies under the subclasses supporting the different case types.
Once you have your own copy of the applicability matrix, you can add rows to define the applicability of your KYC types. You can also add new columns for any new condition that you would like to evaluate. However, you cannot remove the last two columns of the table, which are used to add the KYC Type name and class to the list of applicable types.
Configuring locators
The application can use locators to group together related KYC Types under the same case. The locators represent the logical groups that the KYC types are grouped in. You must provide the system with two pieces of configuration information to make use of locators.
The first piece of information that you must provide is the definition of the locators that will be managed by a certain case. For example, if your application has a case type specifically created to manage AML KYC Types, you must configure that case to register the locator that will pull only the KYC Types which are related to AML.
The locators in a case are implemented using two properties: DDPurpose (which can be thought of as a group), and DDKey (which represents a subgroup). These two fields are of type page group, with the first field hosting pages of class PegaKYC-Data-TypeLocator-Purpose, and the second field hosting class PegaKYC-Data-TypeLocator-Key. The clipboard structure that supports locators is as follows:
.DDPurpose(AML)
.DDKey(US)
.DDKey(EU)
.DDKey(CA)
.DDPurpose(REG)
.DDKey(US)
.DDKey(EU)
.DDKey(CA)
.DDPurpose(TAX)
In this example, the case that is being configured manages the KYC Types created for: AML for the US, EU and CA jurisdictions, for regulatory purposes (REG) for the same jurisdictions, and for tax purposes (TAX) in all jurisdictions.
This structure must be programmatically populated on the case page by specializing the GetKYCTypeLocators data transform. You can define your own locators and logic to populate those locators, on condition that the structure matches the one shown above.
Once the case has been configured to use certain locators, you can refer to them from the applicability matrix. The KYCApplicabilityMatrix template rule includes a locator column that can be used for that purpose. For example, if you want a certain KYC Type to apply in cases configured for AML Global (DDPurpose=AML and DDKey=Global), you can add the following condition to that column: @KYCUtils .LocatorExists ("AML ","Global")
The LocatorExists utility function checks against the locators defined for the case. Both parameters (DDPurpose and DDKey ) must pass the check. The function traverses through the locator structure of the case to determine if the passed DDPurpose and DDKeyare present on the case. If the parameters are found, the engine evaluates the rest of the conditions configured in the row, and applies the KYC Type to the case if all conditions are satisfied.
The function follows an inclusive approach, where a purpose with no keys defined on the case implies that all the keys for that purpose are active. For example, in the structure defined above, the case takes all cases for TAX regardless of the jurisdiction (no keys are associated to TAX). With that configuration, the system only checks that the first parameter is passed, and the second parameter is simply ignored.
Previous topic Standard applicability conditions Next topic Upgrading standard applicability conditions from 8.5 or earlier versions