After reviewing the hierarchical structure of KYC Types, it is time to start creating new KYC Types or copying existing ones for modifications. In KYC Rule Manager Studio, you can create new KYC Types by doing right-click on the nodes of the hierarchy (New > KYC Type), which will bring the default Pega screen to create new rules.
You will need to decide then the unique identifier of the rule and the ruleset and class where the KYC Type will reside. KYC Types are regular rules that follow the same principles than other rule-resolve rules. Instances of the rules in higher versions of rulesets hide instances in lower versions, instances in rulesets higher in the stack take precedence over those down below, branches take precedence over rulesets, and so on. It is important to consider all these factors when creating the rule.
After you have provided these basic parameters, the KYC Type form will be presented. The form is organized in three tabs: Type Definition, Item Definition, and History. The following two sections describe the different elements of configuration that can be set through the first two tabs. The third tab, History, is the standard one for all rules and does not have anything specific to KYC Types.
However, certain specific behaviors should be taken into consideration, especially in development environments or when deploying new types into a production environment:
- The KYC Types become available for application-wide use only after they are checked in. The run time engine does not process the KYC Types in personal rulesets.
- New KYC Types are considered for new cases only. For existing cases that already have KYC Types applied to them, new KYC types and new versions of the types are available until either the reevaluation routine runs (something that is triggered only from specific questions), or when the Surgical Policy Update detects the change in the regulatory rulesets and force the reinitialization of the case (see Surgical policy updates).
- Similarly, KYC Types that might have been discontinued or that are not applicable anymore in specific business scenarios remain in in-flight cases until the re-evaluation routine runs or the Surgical Policy Update forces the re-initialization of the case (see Surgical policy updates).