1 About Oracle Financial Services Customer Screening

Oracle Financial Services Customer Screening (OFS CS) enables organizations to effectively and efficiently screen their customers so that they can successfully meet anti-bribery, anti-corruption, export control, and other legal regulations as well as to meet anti-money laundering and counter-terrorist financing legislations. Screening customers enables organizations to keep track of and avoid the risk of being exposed to suspicious or sanctioned individuals and organizations.  

Topics:

·        Process Flow for Administrator

·        Quick Tour of Customer Screening

·        Customer Screening Workflow

Process Flow for Administrator

The system administrator can perform the required tasks and configurations in the following order. Optionally, you can also configure and execute pipelines on a new environment, and import or copy pipelines if you are moving data between environments.

The following figure illustrate process flow for Administrator

Description of the Process Flow for Administrator Workflow

Quick Tour of Customer Screening

The following table provides an overview of the tasks and the order to execute these tasks using the Customer Screening application. Click the links to read details of each task.

Table : Quick Tour of Customer Screening

Customer Screening Workflow

The following figure illustrates the Customer Screening workflow.

Description of the Customer Screening Workflow

Load Customer Data to OpenSearch

Use a predefined template to create an OS index. The template has information on the data and analyzer types used in the JSON. It also describes the fields used in the JSON. OS gives results in real-time. The matching service uses OS to generate matches.

·        To load the data and load it to OS for matching, run the CustomerFullLoad batch in the Scheduler Service. For information on how to load data from the object store to staging and from staging to the business tables if the Anti-Money Laundering (AML) application is not deployed, see Using FCCM Data Loading Service.

·        To load data for the object store to staging and staging to business tables if Anti-Money Laundering AML is not deployed, see Uploading Data Files.

·        To load Customer Delta Data and load it to OS for matching, run the CustomerDeltaLoad batch in the Scheduler Service.

Manage Pipelines

There are four ready-to-use pipelines: two pipelines are used for individual batch and real-time data and two pipelines are used for entity batch and real-time data. Within the pipelines are different matching configurations for SAN, PEP and EDD records which can be tuned depending on your risk appetite.

Matching configuration is set using the Matching Rules widget. Each widget defines a match configuration for a source (customer) and target (watch list). The source and target can be filtered. This is how we set the different matching configurations for entities and individuals. It can also be used for setting different configurations for jurisdictions and domains.

Each ruleset can contain multiple rules and the score given to an alert is the maximum of the individual rule scores. An alert is generated only if the score is above the ruleset threshold. Within a rule configuration, source and target attributes are defined along with the match type (exact match, fuzzy match, or date match)  and scoring method (Reverse Jaro Winkler, Jaro Winkler, Levenshtein). Each attribute level match has a threshold, below which the score is not considered, and a weightage. If the Must condition is set, then a match will not be created unless the score for that attribute is above the threshold.

To match the customer records with watch list data, run the IndividualScreening batch for an individual or EntityScreening batch for an entity in the Scheduler Service.

Generate Alerts or Re-alerts

After all the attribute level scores are calculated a weightage average score for the rule is calculated and check against the ruleset threshold to determine if an alert is to be created. The alert is created only if the customer data or watchlist data is new or significantly changed from the previous time it was screened. The Alert Decision widget is where attributes can be configured to determine if a change in the data or an increase in the score will create a new alert. Alerts are generated for each match that exceeds the rule threshold.

If there is a change in the record value (first name, last name, date of birth) or score, the alert is regenerated. The attributes which resulted in the re-alert is highlighted with a red box on the Event Details page for the re-alert. For more information on event details, see the Case Investigation User guide.

You can specify the attributes which generate a re-alert based on the value change or score change in the Alert Decision window. For more information on Alert Decision window, see Using Pipeline Designer guide.

Generate a Case

When one or more matches are recorded between a watch list and a customer record, a case is generated. The user can take a decision and decide if the alert is a false positive or a true match. If a new alert is generated, a new case is also generated in Enterprise Case Management (ECM).  

To generate the case in ECM, run the ScreeningToCaseMgmt batch in the Scheduler Service.

Generation of Canned Reports

Canned Reports captures the following information which will show up after the Batch execution for every run:

·         Customers in Staging table

·         Customers pushed from staging table into Customer Screening tables

·         Alerts/events generated

·         Customers with non-hits

·         Cases created

For more information on accessing the Canned Reports, see View Reports for Download.