Skip to main content


         This documentation site is for previous versions. Visit our new documentation site for current releases.      
 

Requirements case

Updated on June 10, 2021

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.

Pega Client Lifecycle Management for Financial Services Implementation Guide Pega Client Lifecycle Management for Financial Services Implementation Guide Pega Client Lifecycle Management for Financial Services Implementation Guide Pega Client Lifecycle Management for Financial Services Implementation Guide

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.

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 act in more than one process stage.

The requirements module includes the following privileges:

PrivilegeDescription
RNGGatherInformationThis privilege gives the user the ability to perform the first step in the process, document collection.
RNGRequestWaiverThis privilege allows users to request a waiver when a document is not available.
RNGDataCollectionUsers with this privilege can perform data collection.
RNGVerificationUsers with this privilege can verify documents in the requirement.
RNGProcessWaiverThis privilege allows users to approve waiver requests that are raised for a customer.
RNGApprovalUsers with this privilege can perform the final approval at the end of the process.
RNGShowCaseAttachmentPrivilegeThis privilege drives the availability of case attachments for selection during document collection.
RNGShowExistingDocPrivilegeThis privilege drives the availability of documents in the customer library (documents previously uploaded for that customer) for selection during document collection.
RNGShowViewHistoryPrivilegeUsers with this privilege can see the full history of a document within a requirement.

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:

Role requirementsDescription
RequirementsDocumentCollector

Represents an operator that can upload documents in the initial stage of the process. Associated privileges:

RNGGatherInformation

RNGRequestWaiver

RNGShowCaseAttachmentPrivilege

RNGShowExistingDocPrivilege

RNGShowViewHistoryPrivilege

RequirementsDataCollector

Represents an operator in charge of the capture of data from the document. Associated privileges:

RNGDataCollection

RNGShowViewHistoryPrivilege

RequirementsVerifier

Represents an operator that can verify documents in a requirement. Associated privileges:

RNGVerification

RNGShowViewHistoryPrivilege

RequirementsProcessWaiver

Represents an operator that can verify and approve waiver requests. Associated privileges

RNGProcessWaiver

RNGShowViewHistoryPrivilege

RequirementsApprover

Represents an operator that can perform the final approval on the case. Associated privileges:

RNGApproval

RNGShowViewHistoryPrivilege

RequirementsMultiRole

Represents an operator that can performed the first four stages of the process. Associated privileges:

RNGGatherInformation

RNGRequestWaiver

RNGDataCollection

RNGVerification

RNGProcessWaiver

RNGShowCaseAttachmentPrivilege

RNGShowExistingDocPrivilege

RNGShowViewHistoryPrivilege

Note: The process has been configured in such a way that users with this role can performed all their work from the first stage of the process without having to move across stages. That it is to say, a user with this role can upload documents, capture data and verify their validity, all within the first stage of the process. This configuration is thought to improve significantly the processing time of requirements.

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

Access groupsDescription

CLMFSCIBSysAdmin

CLMFSRetSysAdmin

PegaRequirements:RequirementsMultiRole

PegaRequirements:RequirementsApprover

CLMFSRet_Branch_User

PegaRequirements:RequirementsDocumentCollector

CLMFSCIB_RM

PegaRequirements:RequirementsMultiRole

PegaRequirements:RequirementsApprover

CLMFSCIB_SS_Manager

CLMFSRet_SS_Manager

PegaRequirements:RequirementsApprover

CLMFSCIB_SS_User

CLMFSRet_SS_User

PegaRequirements:RequirementsMultiRole

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 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:

RuleRule typeDescription
RNGSkipApprovalStage_Ext Data transformUse the rule to skip the approval stage. Organizations can skip the stage in all circumstances or do it based on case data, the value or risk of the customer, the seniority of the verifier, and so on.
RNGSkipValidateStageData transformModify the rule to skip the verification of the documents in the requirement.
RNGSkipProcessWaiverStage_ExtData transformModify the rule to skip the process waiver stage.

Configuring routing

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:

StageWorkbasket suffix
SatisfySS_Docs
Data CollectionSS_Docs
ValidateSS_Docs
Process WaiverSS_Docs
ApprovalSS_Docs_Approve

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.

RuleRule typeDescription
RNGDeterminePartyRoutingDecision tableModify this rule to use the routing logic based on operating structure but using different prefixes for your workbaskets depending on stage or any other case variable.
RNGRouterByStageData transformModify this rule to implement your own routing logic. This logic may or may not be based on the operating structure.

Have a question? Get answers now.

Visit the Support Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us