System response times for KYC Type and Item selection are improved by loading KYC Type and Item data on node-level data pages and using them only when they are required. The data stored on the node level data pages includes attribute conditions such as applies when and read-only, sequence numbers, and initializer data transform rule references.

• KYC Type attributes that include the KYC type identifiers and the applicability conditions are loaded and stored on the D_Types data page. This data page is an index of all the types available to the application and their main applicability conditions.
• The actual content of each of the types – all KYC items, conditions, triggers and data transforms, and so on – is stored under the D_TypeObject data page. The system maintains one instance of this data page per KYC Type in the system.

This configuration leads to an improvement in the KYC Engine performance because no data has to be fetched from the database when creating cases and applying KYC Types.

In order keep these node-level data pages up to date after changes in the KYC Types and to minimize performance impact on users, the system uses two different resources.

The first one is a declare-trigger that cleans the node level data pages and forces them to reload as soon as there is a change in an existing type or when a new type is created. It is important to note that this trigger is only used if the operator making the changes has KYC in the stack. For example, the import of rules using a generic administrator without KYC will not trigger the reload of the data pages.

In addition to the trigger, the system also periodically refreshes the data pages. Every day, the data pages become stale and need to be reloaded. Without any special configuration, the data pages are reloaded the next time that they are invoked, usually during a user session. To avoid the impact on the first user of the day, the application has an agent that can be configured to run at night to reload the data pages.

In addition to the trigger, the system also includes a watchdog under the new KYC Watchdog infrastructure. The new watchdog monitors the KYC rule type table and flushes the data pages if any new rule was added or modified.

The Pega Know Your Customer for Financial Services Engine's watchdog infrastructure simplifies the implementation of the all jobs that must be executed on regular intervals.

The watch dog is driven by the KYCWatchDog job scheduler. This job is executed periodically based on the configuration of the scheduler (by default, every 5 minutes). In each execution, it iterates through the different watchdog classes registered in the system and execute them.

The KYC Watchdog implementation contains the following classes:

• PegaKYC-Data-WatchDog: container class of all watchdog related rules.
• PegaKYC-Data-WatchDog-Logic: class that implements the actual logic of the watchdogs.
• PegaKYC-Data-WatchDog-Log: concrete class used to log the execution of the watchdogs.

To add a new watchdog, users must copy the KYCWatchDog job scheduler to their implementation and update it to have an access group that best represents the application in the implementation layer. You may require one copy of the job scheduler per application, if there is more than one application in the implementation that needs an application specific-watchdog.

Once the job scheduler is copied and updated, users must create a sub-class of PegaKYC-Data-WatchDog-Logic (for example PegaKYC-Data-WatchDog-Logic-Types) and create an activity with the name PerformWatchTask under it. This activity must contain the logic that is intended to be executed by the watchdog.

Without any additional configuration, the system executes the logic that is defined under each of the logic classes in the PerformWatchTask activity.

For a more advanced configuration where the watchdog must keep a track of the last execution of the task and drive the next execution based on it, use the PegaKYC-Data-WatchDog-Log log class. The logic to read or write these instances should be included in the PerformWatchTask activity and should consider the following fields for the class:

Last Run

Last execution time stamp of the watchdog

Watchdog Name

A standard short name for the watchdog. For example, KYCTypes

Watch Class Name

The class that was used for implementation of the watch dog. For example, PegaKYC-Data-WatchDog-Logic-Types

A user can use this data in the next run of the PerformWatchTask activity, by accessing the D_WatchDogLog data page.

The application includes a watchdog to detect changes in KYC Types and reload node level data pages accordingly. The watchdog uses the last execution time stamp of the watchdog to determine if there are any new KYC types that were added to or updated in the system since the last run of the watchdog. The watchdog flushes the D_Types and D_TypeObject data pages if there are any new types added or updated in the system.

Since the D_Types data page uses rule resolution, it is incredibly complex and time consuming for the watchdog to determine whether the application was impacted by the change. The watchdog flushes all node-level data pages and relies on the system to load each of the types on the data pages when the first user accesses them. Therefore, every day and every time a KYC type is added or updated in the system, the first user of each of the KYC types may experience a slight delay while applying the KYC types to the case.

• Pega Know Your Customer Engine