Skip to main content

         This documentation site is for previous versions. Visit our new documentation site for current releases.      

Configuring the Standard Filtering mechanism

Updated on June 11, 2021

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:

CategoryDecision table
Product RegulatoryProdRegulationMasterAppliesWhen

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 labelPossible valuesGlobal AML exampleLocal AML example
KYC TypeAML KYC Type NameGlobal_AML_Individual_CDDCA_AML_Individual_EDD
KYC Case Type

GKYCCase (Global cases)

LKYC (Local/Jurisdictional cases)

Customer Type*




Customer CDD Profile


Related Party Enhanced DD

Not applicableNot applicable
Enhanced Risk?true (blank value means false)Not applicabletrue
Other Condition






Not applicableNot applicable
Entity Type




Not applicableNot applicable
Jurisdiction Code



Note: Two letters ISO Country code can be replaced for any supported jurisdiction
Not applicable@evaluateWhen("IsJurisdictionCA")=true
Resulttrue or falsetruetrue

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 Upgrading from a previous version to 8.6 version

Have a question? Get answers now.

Visit the Support Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best. is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us