Documentary Requirements Management demonstration

The Organization LGW Finance Group is onboarding at U Plus Bank. The Capture stage is complete, and the case is now at the Enrich stage, whereby all the key data has been captured. Data in the Capture and Enrich stages helps determine the requirements that need to be satisfied for the specific journey. For instance, the Entity Type, Country of Registration, and Booking Location will trigger specific requirement sets. Additionally, related parties, more specifically the type of related parties and their KYC Significance status, also trigger requirements that are unique to them.

Available on the right-hand side of most cases, the Requirements Gadget provides users with clear information on the documentary requirements that are to be satisfied for a customer journey. The gadget indicates the number of pending requirements, broken down by customer or relevant related party. The user can see that there are 7 Total pending requirements. 4 of those are for “LGW Finance Group” and 3 for “Hector Nelson.” To see more details, expand the view for each listed party.

Upon expanding the “LGW Finance Group” and “Hector Nelson” entities, the user can see additional useful information:

1. Entity type – whether the entity is a Customer, also known as Contracting Party, or the type of Related Party such as Beneficial Owner.
2. Requirement Sets – such as: “Formation documents” and “Verification of formation or incorporation address.”
3. Requirements – each requirement set will have a set of requirements listed under it.

The user clicks on the customer’s Formation Documents requirement. This opens the case (RQ-XXX), which is at the first stage, “Document Collection.” The user can see:

1. The list of documents needed to satisfy the requirement.
2. The status of each document, for example, Pending Document.
3. The satisfaction logic for this requirement. For instance, for the formation document, they only need to provide one of the listed documents.

The user wants to satisfy the formation document Requirement by attaching the Articles of association/incorporation. They click the “Attach” link next to the stated document, opening a modal dialog with three options for attaching a document to the requirement. There is also an option to Waive the need for providing any documents. New file gives the user a chance to upload a file from their desktop. Case attachments enables the user to reuse attachments that are specific to this case (or child case). The Existing documents option uses documents that are already in the document library (either from this case or prior cases). Under New File, the user selects a file from their desktop and attaches it to the requirement case.

There are two user roles that determine the type of actions that users can perform in a requirements case. Single-user role users can only perform one action on a requirement, such as Document Collection, while multi-user roles can perform multiple actions on a case. For example, one user can collect, capture, and verify documents. For this demo, we are using a multi-user role. Thus, once we collect/attach a document, we are presented with a data capture modal that requires some pre-configured attributes, such as confirming the document is in good order. This user can also perform verification actions in the validation stage.

Because the user has already provided one document and successfully completed the first three stages of the requirements case (Document Collection, Data Capture, and Verification), the requirements case is ready for approval. For the approval stage, the user can see that the case has been assigned to the Sales Documentation Approval team. These assignments are all pre-configured in the target operating model. Upon clicking Continue, the user transitions to the Approve documents Perform Action screen. After clicking the Approve link by the provided document name, the Approve Document dialog box opens. After all the required data is provided, the user clicks Submit to approve the document. The user can now clearly see which document has been provided and approved. Additionally, the green check marks next to the satisfaction logic and requirement case label indicate that all the criteria have been met to satisfy this requirement. The user can now submit this case.

Looking at the right-hand column, the User can see that the requirement case is 100% complete. The Requirements gadget shows the Formation Document requirement as complete and the count of pending requirements reduced by 1, from 7 to 6. The user has not opened the Verification of formation or incorporation address requirement, but the status is now displayed as Verification. The system automatically recognized that the Verification of formation or incorporation address could also be satisfied using the “Articles of association/incorporation” document and reused it from the Formation documents requirement.

Clicking the Verification of formation or incorporation address requirement link leads the user to the corresponding requirement case (RQ-2017). The case is already in the Verification stage as the first two stages (Document collection and Data capture) were automatically skipped. By default, the system correctly skips the Document collection stage since the document was already attached in a separate Requirement case and is also configured to skip the Data capture stage. However, while documents are reusable across requirement cases, the system still requires manual verification and approval of the document’s usage for each requirement case.

The user must complete the rest of the pending requirement cases for both the Customer and all the related parties before the customer journey can progress beyond the due diligence stage.

Once all the requirements are satisfied, the requirements gadget will show them with a status of complete and 0 pending requirements.

This concludes the demonstration of Documentary Requirements Management.