The KYC policies are governed by regulatory bodies and a financial institution's own internal compliance rules. The policies must comply with the latest regulatory requirements and standards. These updates to the policies usually affect the risk and documentary requirements, thus determining the course of the onboarding case. All KYC Cases in the application must comply with these latest policies.

All KYC cases are created with the latest KYC policies. If there is a change in the policies while a case is in progress, the KYC Engine ensures its compliance against the latest regulatory policies through the Surgical Policy Update (SPU) engine.

You can use the SPU engine to define a list of rulesets that contain the KYC policies and associated assets. This list of rulesets is called the regulatory stack and every KYC case refers to the regulatory stack that was active when the case was created. The SPU engine processes any additions to the rulesets as a change in policy and updates the policy on open cases with the latest version of the stack.

For example, you configure your application to have two rulesets in the regulatory stack: KYCRCEMEA and KYCRCAPAC. The first implementation of the application goes to production with the version 01-01-01 of these rulesets and the KYC cases created point to that version of the stack. If few a months later, you import a new version of the rules (for example, KYCRCEMEA 01-01-02) or you add a new ruleset to the list (KYCRCAmerica), the SPU engine detects the change and updates the policy on all the open cases.

The cases that are identified for a policy update are processed in the background, to avoid disruption to the user. If users are actively working on KYC cases while the SPU background processing is in progress, those cases are skipped. To address this scenario and ensure that all cases are completed with the latest policies, the SPU engine also includes a manual KYCPolicyUpdate update processor utility. This utility can be plugged into the KYC data collection flows to ensure that each KYC case is checked for the latest regulatory compliance before it is submitted. If required, the case is stopped for an update.

When a case needs to be updated, the SPU engine makes an internal copy of the data in the policy memory (for more details see Policy memory). After the reinitialization of the KYC Types, the SPU engine uses that data to pre-populate the answers to the questions in those types.

The regulatory stack is also used to isolate resolved cases from posterior changes in the rules. The SPU engine can pause the read-only display of the KYC types so that they can appear in the form which they were applied in the case.

• Registering rules in the regulatory stack
• Defining in-flight-cases
• Configuring custom logic for policy updates
• Configuring surgical policy update processors
• Specializing the regulatory watchdog
• Manual updates
• Preventing partial policy update during an installation or upgrade
• Important rules and references

• Pega Know Your Customer Engine