Functional components

The documentary requirements are applicable to each specific journey that the system determines based on the assessment of different drivers like jurisdictions, product types, customers, and related party roles or risks. The system determines which documents are required in each specific scenario and adjusts the requirements as the data changes during the journey lifecycle.

Review the functionality that is structured in the following four main functional components:

Requirements definition

The first step to use the functionality is to have the rules that drive the documentary requirements defined in the system. The process is usually performed in design time using the Requirements Portal or by developers using the Dev Studio.

Synchronization engine

This component is in charge of keeping up-to-date the documentary requirements specific to a given case. The system automatically executes it in multiple points of the application, including synchronizing with the Master Profile. Under this module, the system determines which requirements and parties should be considered and create requirement cases accordingly.

Requirements case

This case type is the vehicle for the satisfaction of a specific requirement, for example, a proof of identity. It starts with the collection of the required documents and then progresses through different data capture and verification stages until the requirement can be considered satisfied.

Supporting assets

There are few supporting essentials to facilitate the operations. That is the case, for example, of the requirements gadget embedded in the case summary screens, and that gives access to the requirement cases or the list of requirements satisfied by a given customer under the Customer 360 view.

Architecture and rulesets

CLM Requirements

The layer implements the advanced requirements functionality that CLM requires to orchestrate the satisfaction of documentary requirements. The layer is implemented on top of Pega FS Requirements as an extension of that module. Although the design of the module supports the use of the functionality by other applications. It is currently provided with CLM and can only be used within the context of that application. The rulesets that make up this layer are PegaCLMFSRNGFS (CLM specific logic) and PegaCLMFSRNGBase (application-agnostic capabilities), both referred from the PegaCLMFS application.

Pega FS Requirements

The layer implements the basic requirements functionality shipped with Pega Foundation for Financial Services. This base functionality is the one used by CLM until the introduction in 8.5 of the CLM Requirements layer and it is still in use to support in-flight cases during upgrade scenarios and CLM customers that are not ready to move into the new CLM Requirements functionality. The module is implemented in two main rulesets, PegaFSRequirements (provided with the PegaFSIF application, Pega FS specific) and PegaRequirements (provided with PegaRequirements, industry-agnostic logic).

By default, customers installing Pega Client Lifecycle Management and KYC inherit all the capabilities of these two layers by just building the applications on top of the PegaCLMFS application.

Generation 1G vs 2G

The Requirements functionality is initially developed in the early versions of Pega Client Lifecycle Management and KYC. The Pega FS Requirements provides the core of the functionality. Although the module comes with some basic functionality that covers most of the customer's immediate needs, there are some important aspects that are not considered in this version of the module. This version is the one referred above as Pega FS Requirements, and it is known as 1st Generation (1G).

In the 8.5 version, Pega Client Lifecycle Management and KYC introduced a new version of the functionality to overcome some of the most important limitations. The module is refactored to enable financial institutions to take the document management process to the next level. This new version of the module is accessed through the layer referred to above as CLM Requirements, and it is known as 2nd Generation (2G) or Requirements Next Generation (RNG).

The parallel existence of these two versions of the functionality affects customers differently depending on where they are in their journey with Pega Client Lifecycle Management and KYC.

Fresh install

Financial institutions installing Pega Client Lifecycle Management and KYC for the first time automatically adopt the latest version of the functionality (2G) without having to do any specific configuration.

Update

Financial institutions updating from the previous versions of the product must perform some manual tasks to activate the new functionality. Meanwhile, the legacy version of the application (1G) is used, before the manual tasks are completed, For more information, see "Updating from previous version to 8.5" in the chapter Updating from a previous version to 8.5.

For more information about how to move from 1G into 2G, see Updating from 1G into 2G.