KYC Quality Control
The Pega Client Lifecycle Management and Know Your Customer™ (CLM and KYC) application provides financial institutions with the ability to separate duties in the input and review of data in the context of cases.
As part of the KYC due diligence process, data entered by the analyst must be approved by a separate reviewer. This is known as the four-eyes principle.
The specific feedback to be addressed by the analyst can easily be buried in long questionnaires. With multiple iterations of feedback to sort through, even more time is wasted.
Additionally, approval or rejection may need to occur at different levels of granularity, depending on the financial institution’s policies.
What if these Quality Control challenges were solved by an application that also increased data quality and integrity with also control on data changes ?
How Pega applications help
The Quality Control feature of Pega Client Lifecycle Management and Know Your Customer distinctly highlights the KYC data that requires attention. This is key in helping the analyst and the reviewer concentrate on exactly what is needed when it is needed. The Quality Control process can be configured to be carried out at the appropriate level of granularity, from the case level down to the section or even field level.
In addition, the KYC Data Change Control (DCC) implements a proper data control mechanism to determine whether a certain response to a certain KYC item has changed since the last time it was reviewed. The DCC provides required control on data changes.
Transcript
In a real scenario, the analyst and the reviewer are roles covered by two distinct users, but for the purpose of this video, the rights have been combined into a superuser.
The Analyst is working on the onboarding of customer Fulton Furnishing Ltd. His responsibility is to enter the relevant KYC data, so he opens the Global CDD Entity questionnaire, with the QC working mode set to field level.
The new UI clearly outlines sections and fields for better recognition of where the user is in the case. The analyst answers several questions and clicks a menu that contains four actions:
- Marks a field as if this is allowed by policy in certain scenarios.
- dditional due diligence information related to the provided answer. Such information is retained in the customer KYC file and is visible in the subsequent journey.
- Internal communication related to the QC process. Remarks are not retained in the customer KYC file and are therefore only visible in the current case.
- .
Select the Applicability option to mark this field as Not applicable and enters the reason why.
Then click ,and the user interface signals to the users whether a field is marked as Not Applicable or contains additional due diligence details.
Moving ahead, the reviewer must now examine the customer KYC Data. Because of the four-eyes principle, he cannot amend any data but can approve or reject it. The data is therefore read-only.
The reviewer reviews each response, clicking or as appropriate. When clicking , the system displays a green banner.
For the high risk-businesses or industries question, the analyst has included additional details. The reviewer reads them and decides to the response. They provide a comment, and the system displays a red banner.
Note that the counter provides an updated number of mandatory fields within the section, with how many fields have been approved.
The reviewer clicks the menu, from where they can add or update remarks or review the remark's history.
Once the reviewer has reviewed and actioned all mandatory questions, the case is sent back to the analyst, who can also see the reasons why any fields were rejected in the remark's history.
This concludes the demo.
Data change control
The KYC Data Change Control (DCC) provides required control on data changes. It performs in a mechanism that constantly compare the following two different types of data.
- Current data: This is the current version of the data. The value that the KYC Type Item has at the very moment of the evaluation can change for different reasons at different points in time. It can be changed through the UI by the user, it can be changed programmatically during the propagation of data from Enrich into Due Diligence, and it can also be changed programmatically in the on-change Data Transform associated to another KYC item that changed in turn.
- Baseline data: The latest version of the KYC Item response, which is taken through review to either be approved or rejected. This value changes only at the time of explicit approval or rejection and value is used as reference in the constant comparisons that the system performs.
The DCC compares between these two types of data by implementing the following changes in the current process.
| Initialization | During the initialization of a KYC Case, the system initializes the baseline for the KYC Types in that Case. Based on the scenario and item, the baseline is initialized as empty (it is the first time the item is managed), from the Policy Profile (which contains the last value approved) or Policy Memory (recover a value of an interrupted in-flight case). |
| Initial data comparison | The system then runs the operationalization on the KYC Types and, immediately after that and if required, compares the value of all the items against the baseline that was taken initially. The result of the comparison is stored for its later use. |
| STP assessment | Then the system revisits the decision that was initially taken regarding the straight-through processing mode. If there is any change in any of the items, the system reconsiders the initial assessment and set the mode to NoSTP, and which drives the case to go through a human operator for explicit review. For that purpose, the current STP model that manages only one value needs to be modified to support the two new values: Tentative STP and Confirmed STP. |
| Data comparison after data-collection | After the KYC officer submits the KYC questionnaire for the review, the system performs an additional data comparison to detect data changes that could have been done programmatically from on-change data-transforms. |
| Approval/rejection re-baseline | When items are approved or rejected by the KYC review, the system adjusts the baseline accordingly. With KYC QC functionality active, the re-baseline happens when the reviewer clicks on approve or reject on the item or the group. When KYC QC is turned OFF, the re-baseline happens when the whole KYC questionnaire is approved or rejected. |
Conclusion
The QC feature expedite this critical process by visually highlighting the status of KYC data to users. A clear focus on exactly what needs attention facilitates more efficient collaboration between the analyst and reviewer.
Only Pega applications can provide system-enforced compliance with the four-eyes principle, combined with the flexibility of carrying out the process at differing levels of granularity.
Check your knowledge with the following interaction:
This Topic is available in the following Modules:
Want to help us improve this content?