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.
- 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.
- 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:
|RNGGatherInformation||This privilege gives the user the ability to perform the first step in the process, document collection.|
|RNGRequestWaiver||This privilege allows users to request a waiver when a document is not available.|
|RNGDataCollection||Users with this privilege will be able to perform data collection.|
|RNGVerification||Users with this privilege will be able to verify documents in the requirement.|
|RNGProcessWaiver||This privilege allows users to approve waiver requests that could have been raised for a customer.|
|RNGApproval||Users with this privilege will be able to perform the final approval at the end of the process.|
|RNGShowCaseAttachmentPrivilege||This privilege drives the availability of case attachments for selection during document collection.|
|RNGShowExistingDocPrivilege||This privilege drives the availability of documents in the customer library (documents previously uploaded for that customer) for selection during document collection.|
|RNGShowViewHistoryPrivilege||Users with this privilege will be able to 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:
Represents an operator that can upload documents in the initial stage of the process. Associated privileges:
Represents an operator in charge of the capture of data from the document. Associated privileges:
Represents an operator that can verify documents in a requirement. Associated privileges:
Represents an operator that can verify and approve waiver requests. Associated privileges
Represents an operator that can perform the final approval on the case. Associated privileges:
Represents an operator that can performed the first four stages of the process. Associated privileges:
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:
|RNGSkipApprovalStage_Ext||Data transform||This rule can be used 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.|
|RNGSkipValidateStage||Data transform||The verification of the documents in the requirement can be skipped by modifying this rule.|
|RNGSkipProcessWaiverStage_Ext||Data transform||The process waiver stage can be skipped by modifying this rule.|
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.
|RNGDeterminePartyRouting||Decision table||Modify 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.|
|RNGRouterByStage||Data transform||Modify this rule to implement your own routing logic. This logic may or may not be based on the operating structure.|Previous topic Second phase of synchronization: implementation Next topic Document and requirements metadata