Requirements cases implement the process to collect and verify documents from the customers. They are created from the requirements synchronization engine when it is deemed that one requirement needs to be satisfied by a given party.

The process is divided in five main stages:

Document collection

A document collector reviews what is needed to satisfy the requirement, uploads a document, or requests a waiver, and submits the case as having all the necessary documents provided. This stage sources documents into the party document library.

Data capture

A data collector determines whether the document is in good order, captures any data that is defined as being needed, and, if correct, submits the case as having all the document data captured. If the document is not in good order, the data collector rejects the document, and the system returns the case to the document collection stage. This stage collects data that is stored in the party document library.

Verification

A document verifier determines that the document meets the requirement’s criteria and, if correct, submits that the document met the requirement. If the document is incorrect for this requirement, the verifier rejects the document, and the system returns the case to the collection stage. The document status is specific for the requirement that it is verified for, and the same document can have a different status in any requirements using it.

Waiver review

A document verifier reviews any waivers that were requested and if correct, submits the case as having the waivers verified. If the waiver is not appropriate, the document verifier rejects the waiver and the system returns the case to the document collection stage.

Approval

A document approver reviews that all documents and waivers meet the requirement’s criteria and, if correct, submits the case as being approved. If documents or waivers are rejected, and the satisfaction logic is not met, then the case is returned to the document verifier for review. The document status is specific for the requirement that it was approved for, and the same document can have a different status in any requirements using it.

Pega Client Lifecycle Management and KYC comes with a fully functional configuration for this component which does not require additional changes to work. However, financial institutions may need to modify the base behavior of the component to meet their specific business needs. The following sections describe some of the most common configurations made to this part of the functionality.

The different actions that a user can perform in the process are given by the privileges available to that user. It is important to note that a single user can perform multiple roles in the process and therefore act in more than one process stage.

The requirements module includes the following privileges:

These privileges have been grouped in the out-of-the-box using a series of roles that represents the different personas that can be involved in the process. The roles available for direct use by applications are:

Pega Client Lifecycle Management and KYC configures its access groups to use all these roles in the following manner:

If your organization needs a different configuration to meet its own operational needs, you can distribute the roles and privileges listed in this section across the access groups and roles of your organization.

By default, the application executes the stages of the requirement case in the order provided before. However, some financial institutions can determine that some of the stages of that process may not be required to meet their business needs and might want to skip them. For that purpose, the following rules are made extension points:

For that purpose, the following rules are made extension points:

The requirements functionality can be configured to route the assignments from different stages to different workbaskets.

Pega Client Lifecycle Management and KYC uses that configuration to establish a routing model based on the operational structure of the application. For more information, see Configuring operating structure).

In that model, see the following routed assignments:

As in any other routing in Pega Client Lifecycle Management and KYC, the system looks in the operating structure for a workbasket available with the same suffix as the one in the table and routes the assignments it.

For example, Pega Client Lifecycle Management and KYC provides UPlus operating structure with two workbaskets UPFS_GM_AME_US_SS_Docs and UPFS_GM_AME_US_SS_Docs_Approve, created under Global Market – America – US and serve to that jurisdiction. Equivalent workbaskets are created in many other jurisdictions and are used by the system according to the operator configuration.

Although customers are expected to use this routing model based on the operating structure, they can always opt for their logic. They can also use the out of the box, but configure it to route to different workbaskets. Look at these rules to implement the required changes.

• Requirements and document collection introduction