eScreening
Businesses must comply with laws regarding know your customer (KYC), anti-money laundering, countering the financing of terrorism, and anti-bribery-corruption. As a result, they are obliged to collect information about whom they are doing business with on an ongoing basis. Client onboarding and KYC services must be dynamic and fast in order to provide a competitive advantage. However, the main factor hindering these services is the need for client data gathering and subsequent validation on that data. This process usually takes days or weeks of diligent human work.
Client Lifecycle Management for Financial Services' eScreening functionality provides configurable integration points to synchronize with these specialized agencies. Both regulators and consumers, if integrated in real time, can solve the business problem of data integrity and eliminate large amounts of manual work.
Implementing details for eScreening
The architecture is based on the following layers.
- Integration layer, (base layer), where the technical interfacing assets and functionality reside. Technical connectors to integrate and interface with external data providers are implemented here. This layer is Pega industry and data model-agnostic, and it is intended to contain reusable assets across all Pega industry applications.
- Industry abstraction layer, (middle layer) where the actual business services are implemented as abstract, provider-agnostic components for a given Pega industry. In addition to the abstract services, some abstract data elements required to support the services are present. Those abstract elements are coupled with the Pega Foundation for Financial Services data model and features so that they can be used in applications built on top of the foundation.
- Consuming application layer, (top layer) from where the actual business applications built on top of Pega Foundation for Financial Services can consume and use the industry business services, regardless of their technical complexity or the provider in use.
All financial services applications can use the business services in a decoupled way (in relation to the actual data provider). When a provider changes, for a new location or for a new Customer implementation, the consumption of the service does not require any change. Only the two lower layers require configuration. The business side of the service is isolated from its actual implementation.
- The eScreening service in the Pega Foundation for Financial Services Industry layer can be consumed by any application built on the foundation.
- Additionally, the eScreening service can be consumed by different cases and functions within the applications like the Screening subcase or directly by the New Business or Onboarding cases, and so on.
- The eScreening service can consume different data providers by using the configurable connectors in the integration layer, or multiple sources at the same time. For example, the eScreening service can either use World-Check Connector or Equifax Connector or any other financial information data provider. It can also use all of them to merge the results and get better insights into the risk of onboarding an individual or an organization.
Integration layer
The eScreening connector is built separately, as an independent component so that it can be reused across all Pega applications.
It is built as follows:
- Dedicated classes, Int-WorldCheck and its descendants, not linked to Pega Foundation for Financial Services or any other industry data or integration classes.
- Dedicated rulesets, PegaWC and PegaWCInt have been created that can be ported as isolated components.
The in-depth details of how this layer integrates with the World-Check component can be referred to at the following link: Pega Foundation for Financial Services 8.1 Screening Using Word-Check One Guide.
This article primarily describes the Industry and Consuming application layers of the architecture.
Industry Layer
This layer contains all of the business services. It contains all of the classes specifically to the financial services industry. The data model is neither specific to the provider of the information nor to the consuming application. The eScreening service is implemented in the PegaFS-Data-ExtProvider-BusService-eScreening class and is used for individual or organization customers.
The PegaFS-Data-ExtProvider-BusService-eScreening data model is specific for the class and consists of the following properties:
- CaseSystemID: Text scalar property representing the case ID that is created in World-Check to get customer data.
- eScreeningDate: Date and time property representing when the eScreening is performed.
- NextScreeningDate: Date and time property representing when the next escreening is performed.
- ScreeningMatches: Page list property with page definition as PegaFS-Data-ExtProvider-BusService-ScreeningMatch which holds the results returned by the provider.
The rest of the properties in use by the business service belong to the inheritance tree and are also being reused by other services.
The initial triggering data page is D_Trigger_eScreening. It pages the PegaFS-Data-ExtProvider-BusService-eScreening class and calls the configured provider, for example, World-Check. This data page accepts the following parameters:
- CustomerID: represents the unique customer ID in the system. It is a mandatory parameter and the data page is cached (if caching is enabled) based on the value of this parameter.
- SourcePage: represents the reference of the page in the clipboard eventually containing the customer data copy (instance of PegaFS-Data-Party) from where the required request information for the service is going to be mapped. It is not a mandatory parameter, but if present and valid the referenced page is the source of requested data.
- Provider: represents the code for the external provider. It is used to assess which provider to use for the actual integration. It is especially relevant where there is more than one available provider to source the business service. It is a mandatory parameter and the data page is cached (if caching is enabled) based on the value of this parameter. The PegaFS.ScreeningProvider dynamic system setting is used while invoking the data page. This enables configuring the provider without having to change the underlying business service logic.
Consuming application layer
The consuming application layer contains the following stages:
- Enrich stage
- Due diligence stage
The eScreening case in the Due diligence stage is triggered when it is not created in the Enrich stage.
For Organizations, eScreening is triggered for the related parties in the Due diligence stage.
These stages are built on the following rules.
Rule name | Class type | Rule type | Ruleset | Description |
|---|---|---|---|---|
| CustomerInvestgation | A process in the Enrich stage that triggers the eScreening case by using the Create case shape in the process flow. | |||
| GetMatches | PegaFS-Work-Screening | Flow | PegaCLMFSIF | Initiating the eScreening case triggers the GetMatches process flow. This flow connects with the World-Check component to get matches. If the API returns screening matches, the flow progresses further and resolves the step, then starts the next step, Investigation. If no result is returned after invoking the API, the flow counts the number of attempts the system makes and the consecutive wait time before reattempting to find matches. In the event of a failure to connect, the Screening success decision table waits for the results and initiates the GetWCScreeningMatches data transform with the required parameters by using the pyContinueAfterWait flow action until it gets the result. If the eScreening is successful but returns no results, the user is informed. This is achieved by invoking the resolve case utility. This utility switches the flow to initiate the Synchronization stage where the details about the eScreening are persisted in the Master profile. |
| NoOfScreeningAttempts | PegaFS-Work-Screening | Property | PegaFS | The number of attempts to get matches. The wait time between attempts is controlled by the wait shape in the flow. |
| eScreeningAttemptsLimit | PegaFS | Dynamic system setting | PegaFS | Dynamic system setting to configure and extend the number of attempts to get the matches. |
| TriggerScreening | PegaFS-Work-Screening | Data transform | PegaFS | Invoking the TriggerScreening data transform in the flow adds the operator name to the World Check User API Mapping data type. This data transfom in turn calls GetWCScreeningMatches. |
| GetWCScreeningMatches | Work- | Data transform | PegaCLMFSIF | Called by the TriggerScreening data transform. Fetches and maps the results of the matches. This data is held on the pyWorkPage under pyWorkParty (customer) by using the ExternalProviderDataPage page list. For every match, a new page is created under this wrapper page list. |
| InvestigateMatches | PegaFS-Work-Screening | Flow | PegaFS | Once matches are found for the customer, the flow moves to the Investigation stage under which it invokes the InvestigateMatches process. This process waits until screening matches are resolved, and then an operator is assigned to the case for investigating the matches. Based on whether the results have a positive match or a negative match, KYC cases are triggered in the Due diligence stage. If the Match returns positive results, the relationship manager can mark the customer being onboarded as having a high risk. This leads to rigorous due diligence. If the match result is negative, then the relationship manager can proceed with a low risk customer and ask for fewer KYC details and documents. |
| UpdateMasterprofile | PegaFS-Work-Screening | Flow | PegaFS | In the Synchronization stage, the UpdateMasterprofile flow automatically syncs the given data to the master profile and autocompletes the process. |
Maintain journeys configurable timeline to trigger eScreening
While doing a Maintain journey, the eScreening is configured to trigger only if it expires during a certain timeline. This timeline is configurable in the application by using system settings.
Customers can increase or decrease the timeline based on requirements.
| Rule name | Class type | Rule type | Ruleset | Description |
|---|---|---|---|---|
| P_CustomerInvestigation_Required | PegaCLMFS-Work | When | PegaCLMFS | Initiates the CustomerInvestigation process. This when rule is extendible to add more conditional checks without changing any of the case types or processes. |
| S_CustomerInvestigation_Skip | PegaCLMFS-Work-GlobalKYC | When | PegaCLMFS | Has an embedded when condition check “HasScreeningDateExpired”, which takes in the value of DSS “Screening Validity" |
| P_CustomerInvestigation_Required | PegaCLMFS-Work | When | PegaCLMFS | Has an embedded when condition check “HasScreeningDateExpired”, which takes in the value of DSS “Screening Validity” apart from the condition if the customer is licensed to use eScreening services. |
The rules in the following table provide the conditions to trigger the case.
Rule name | Class type | Rule type | Ruleset | Description |
|---|---|---|---|---|
IsLicensedToUseEScreening | PegaFS-Work | When | PegaFS | DSS setting should be True. |
IsCustomerTypeFund | PegaFS-Work | When | PegaFS | eScreening should not trigger for Fund. |
CreateScreeningCase | PegaCLMFS-Work | When | PegaCLMFSKYCInt | API key and APIsecretkey should not be null. |
IsBusinessSegmentRetail | PegaCLMFS-Work | When | PegaCLMFS | eScreening should not trigger for Retail. |
HasValidScreeningPages | PegaFS-Work | When | PegaCLMFSIF | Evaluates internal logic. |
HasValidScreeningPages when rule needs to satisfy the rules in the following table.
Rule name | Class type | Rule type | Ruleset | Description |
|---|---|---|---|---|
HasScreeningPages | PegaFS-Work | When | PegaFS | eScreening Pages is Greater Than 0. |
HasScreeningCompleted | PegaFS-Work | When | PegaFS | CaseScreenStatus equals COMPLETED. |
HasScreeningMatches | PegaFS-Work | When | PegaFS | Screening matches should be greater than 0. |
HasScreeningDateExpired | PegaFS-Work | When | PegaFS | Next screening date is in the future. |
Previous topic Data traceability extension details Next topic Related party operationalization