Ongoing Screening of Parties
Financial institutions face significant regulatory challenges in today's complex compliance landscape. They must adhere to stringent regulations regarding Know Your Customer (KYC), anti-money laundering (AML), countering the financing of terrorism (CFT), and anti-bribery-corruption measures. These regulations require financial institutions to continuously monitor their customers for changes in risk profiles, which traditionally has been a labor-intensive and time-consuming process. Manual re-screening of customers can take days or weeks, creating operational inefficiencies and potential compliance gaps. Furthermore, the dynamic nature of risk factors means that point-in-time screening is insufficient; customers who initially passed screening may subsequently become higher risk due to changing circumstances. Financial institutions need an automated, efficient solution that provides continuous monitoring capabilities to maintain regulatory compliance while optimizing operational resources.
The Ongoing Screening (OGS) implementation provides a comprehensive solution to address afore mentioned challenges by enabling automated, continuous monitoring of customers against World Check One's extensive database of risk intelligence. This solution part of Pega Client Lifecycle Management (CLM), enables financial institutions to re-screen customers automatically at world check side at configurable intervals without manual intervention.
Enabling ongoing screening
Each eScreening Case and Adverse Media Case created in the system has a corresponding Case at the screening provider end with a unique identifier, which is stored in the CaseSystemID property. For each CaseSystemID, ongoing screening (OGS) needs to be enabled to initiate automatic re-screening at regular intervals, based on the configuration set up at service provider end.
Note: Ongoing screening status is maintained in concrete class PegaFS-Data-ExtProvider-BusService-OngoingScreening-State. At the Fulfillment Stage, an entry in this class is created for each new Party with status Pending-Enable. Two job schedulers BulkEnableOngoingScreeningForAdverseMedia and BulkEnableOngoingScreeningForeScreening are configured for adverse media and eScreening respectively to process the records with Pending-Enable status, enabling OGS for each record at the screening provider end and updating their status to Enabled upon successful completion.
To ensure that existing customers are included in the ongoing screening Process, a utility is implemented that triggers the Populate Ongoing screening state table for existing CMPs events. Check documentation for further details on Enabling ongoing screening.
Note: Once a customer is off-boarded, ongoing screening updates are no longer necessary for that customer. Similar mechanism is implemented to disable OGS for the eScreening and Adverse Media Case system IDs associated with that customer. Two job schedulers, BulkDisableOngoingScreeningForAdverseMedia and BulkDisableOngoingScreeningForeScreening, are configured for Adverse Media and eScreening respectively, to process the records with Pending-Disable status, disabling OGS for each record at the screening provider end and updating their status to Disabled upon successful completion.
Ongoing screening updates
Two job schedulers, CreateOngoingScreeningUpdateEventForAdverseMedia and CreateOngoingScreeningUpdateEventForeScreening, are configured to trigger the Get ongoing screening updates event for adverse media and eScreening respectively. These job scheduler activities first check if OGS functionality is enabled in the application for either screening or adverse media. If enabled, they trigger a new event called "Get Ongoing Screening Updates".
This event's event process manager routine populates the parameters required for Get ongoing screening updates API. Current page parameter is set to 1 for the first iteration and increments by 1 for each subsequent iteration. A date query is formed using yesterday's date and a DSS. This date query is stored in the event payload as UpdateDateQuery, in case of an exception, this value is logged to help the administrator identify where the run failed and take appropriate action. After the parameters are populated, the D_Trigger_GetOngoingScreeningUpdates Data Page is used to fetch the ongoing screening updates.
After receiving the response containing Case system IDs with updates, the system identifies the corresponding party ID for each Case system ID and trigger an Ongoing eScreening review or Ongoing adverse review event based on the provider type. Once all records in the response are processed, the system updates the event pay load with the previous current page value, mark the event for retry, and save it, enabling the EDA queue processor to pick up the event again for processing the next page of results. This process continues until the API response has no more records.
Ongoing screening review events
Two new events, Ongoing eScreening Review and Ongoing Adverse Review, have been introduced. These events are configured to use the PKYC Quick Review Bundle, which enables the process manager within the bundle to create new ongoing review cases for the relevant parties.
Check your knowledge with the following interaction:
This Topic is available in the following Modules:
If you are having problems with your training, please review the Pega Academy Support FAQs.
Want to help us improve this content?