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 articulated 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 has been 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 case is returned 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 requirement has been met. If the document is incorrect for this requirement, the verifier rejects the document and the case is returned to the collection stage. The document status is specific for the requirement that it was 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 case is returned 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 different status in any requirements using it.

Pega Client Lifecycle Management for Financial Services comes with a fully functional configuration for this component and that does not require of 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.

Configuring user roles

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 can act in more than one stage of those listed in the previous section.

The different privileges available in the requirements module are:

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 for Financial Services 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.

Skipping stages of the process

By default, the application executes the stages of the requirement case in the order provided before. However, some financial institutions may determine that some of the stages of that process may not be required to meet their business needs and they may want to skip them.

For that purpose, the following rules have been made extension points:

Configuring routing

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

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

In that model, see the following routed assignments:

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

For example, Pega Client Lifecycle Management for Financial Services 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 own 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.