Configuring the Standard Filtering mechanism
If you want to use the Standard Filtering mechanism instead of the KYC Applicability Matrix, you can still do this. However, the Standard Filtering only supports the standard orchestration mode. The intermediate and simplified due diligence orchestration modes are unavailable. In addition, the performance benefits of the KYC Applicability Matrix do not apply.
Standard Filtering follows the same paradigm as the KYC Applicability Matrix. Applicability is defined in the decision tables, but with one major difference: the decision tables are associated with the KYC Questionnaire in the KYC Type rule form as applicability condition. As each KYC type can have a different applicability condition configured, the system must locate and execute the applicability condition each time it has to determine the applicability of a KYC Type, even if all of them refer to the same decision table. The Standard Filtering decision tables can potentially be executed as many times as there are KYC Types in the application.
Pega Client Lifecycle Management and KYC provides three decision tables that represent the three due diligence categories that the application supports. Each of these decision tables is associated with the KYC Types that fall under that category. The decision tables are described in the following table:
Category | Decision table |
AML | AMLRegulationMasterAppliesWhen |
Product Regulatory | ProdRegulationMasterAppliesWhen |
Tax | TaxRegulationMasterAppliesWhen |
Across the decision tables, the table includes one row per KYC Type, with the factors driving applicability listed as columns. The factors include customer type, customer risk, entity type, jurisdiction code, and even allowing execution of a complex when condition. The most important columns in the tables are the KYC Type name and the KYC Case type. The KYC Type name column defines the KYC Type for which the applicability condition is being evaluated. The single-row only drives the applicability for that type. The KYC Case type column defines the case type for which the applicability is being evaluated, in essence representing the subcategories.
For example, consider the two KYC Types Global_AML_Individual_CDD and CA_AML_Individual_EDD. Both the KYC Types are configured to use the AMLRegulationMasterAppliesWhen. The decision table in turn has two separate rows driving the applicability of these KYC types. The content of the decision table is described in the following table:
Property label | Possible values | Global AML example | Local AML example |
KYC Type | AML KYC Type Name | Global_AML_Individual_CDD | CA_AML_Individual_EDD |
KYC Case Type | GKYCCase (Global cases) LKYC (Local/Jurisdictional cases) | GKYCCase | LKYCCase |
Customer Type* | 0=Individual 1=Organization 2=Fund | 0 | 0 |
Customer CDD Profile | EnhancedDD Related Party Enhanced DD | Not applicable | Not applicable |
Enhanced Risk? | true (blank value means false) | Not applicable | true |
Other Condition | @evaluateWhen("IsIntermediaryFI") @evaluateWhen("IsForeignFI") @evaluateWhen("IsCorrespondentAccount") @evaluateWhen("IsUSAMLFFIApplicable") @evaluateWhen("AnyProductLifeInsurance") | Not applicable | Not applicable |
Entity Type | @evaluateWhen("GKYCFinancialEntity") @evaluateWhen("EntityIsAMutualFund") @evaluateWhen("GKYCInsuranceCompany") | Not applicable | Not applicable |
Jurisdiction Code | @evaluateWhen("EUKYCPrimaryCountry") @evaluateWhen("IsJurisdictionUS") | Not applicable | @evaluateWhen("IsJurisdictionCA")=true |
Result | true or false | true | true |
In the example above, the Global_AML_Individual_CDD questionnaire always applies to the Global KYC Case when the customer is of type individual. Similarly, the CA_AML_Individual_EDD is applicable to the Local KYC case triggered for Canada only when the booking location is Canada and EDD_Applies is true. The EDD_Applies value is driven by the AML DD Profile of the party, and when certain questions are answered with certain values, that is stating that the party is a Politically Exposed Party (PEP).
If you are using Pega Know Your Customer Regulatory Compliance in your implementation, you can change the applicability to the standard KYC Types by copying the decision tables into the implementation layer and update the conditions or columns based on specific business needs. However, if the implementation does not use Pega Know Your Customer Regulatory Compliance or demands the creation of new KYC Types then applicability needs to be driven by the creation of equivalent logic, including when rules, decision tables, decision tree, and associating them with the KYC Types.
Previous topic Configuring the Applicability Matrix mechanism Next topic Updating from a previous version to 8.7 version