Oracle Financial Services Transaction Filtering is a Sanctions screening system that identifies Individuals, entities, cities, countries, goods, ports, BICs, and Stop keywords that may either be suspicious, restricted, or sanctioned with relation to a financial transaction that is processed through the Transaction Filtering application. The application enables you to integrate with any clearing or payment system, accept messages from the source system, and scans them against different watch lists maintained within the application to identify any suspicious data present within the message. The Transaction Filtering application can scan messages which are in the SWIFT, ISO20022, or Fedwire category.
Topics:
· Process Flow for Administrator
· Quick Tour of Customer Screening
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
The following table provides an overview of the tasks and the order to execute these tasks using the transaction Filtering application. Click the links to read details of each task.
Table : Quick Tour of Transaction Filtering
Order |
Tasks |
Details and Documentation |
1 |
Subscribe to the Application | Subscribe to the application. For more information on the subscription process, see Getting Started with Oracle Financial Services Crime and Compliance Management Cloud Service. |
2 |
Provision Users | Configure Security Management System (SMS) to create users, roles, and implement user authorization and authentication. For more information on provisioning users, see Setup your Cloud Account. |
3 |
Manage User Groups, Roles, and Functions | Create user groups, create roles, map users to user groups, map user groups to roles, and map roles to functions. For more information on the steps involved, see Identity Management. |
4 |
Configure Master Data | Define the master data values. For more information, see Master Data. |
5 |
Configure Transaction Filtering Administration Data | Define the TF Administration data values. For more information on message types, categories and configurations, see Transaction Filtering Administration. |
6 |
Perform Application Security Mapping | Create security attributes that allow or restrict access to users. For more information, see Oracle Financial Services Crime and Compliance Management Cloud Service Application Security. |
7 |
Manage Pipelines | · Import the ready-to-use pipelines to the Transaction Filtering application, create a copy of the imported pipelines and save it as a new pipeline. For more information, see Importing Pipelines and Copying Pipelines. · Create new pipelines and configure the same as per your requirements. To create pipelines, see Creating Pipelines. |
8 |
Create Jobs | Create jobs to define a collection of instructions for executing pipelines against threshold sets. For more information on how to create jobs, see Using Jobs. |
9 |
Map Pipeline to Jurisdiction | Map a ready-to-use pipeline or add a new pipeline and map it to one or more jurisdictions. For more information, see Map Pipeline to a Jurisdiction. |
10 |
Configure Batches | Define batches specific to Transaction Filtering in the Scheduler Service window. For more information, see Managing Batches section of Pipeline Designer and Scheduler Service. |
11 |
Onboard Prospects | TF supports both synchronous and asynchronous API. For more information on the transaction messages, see Transaction Filtering API Guide. |
12 |
Schedule and run batches | Schedule and run the TF-specific batches in the Scheduler window to load data. For more information, see Managing Batches section of Pipeline Designer and Scheduler Service. |
13 |
Screen Transactions and Watch list Records | Screen records against watch list data. For more information, see Matching Rules Widget. For editing the watchlist data, see Watchlist Management. |
14 |
Generate Case | Cases are generated based on the matching rules and associated thresholds. For information on matching rule, see Matching Guide. |
15 |
Investigate Cases | Investigate and monitor cases. For more information, see Investigating Cases. |
The following figure illustrates the TF flow diagram for Synchronous API
The following figure illustrates the TF flow diagram for Asynchronous API
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 to Identifier watchlist and load it to OS for matching, run the IdentifierWatchlistLoad batch in the Scheduler Service.
· To load the data to Country Watchlist and load it to OS for matching, run the CountryWatchlistLoadbatch in the Scheduler Service.
· To load the data to City Watchlist and load it to OS for matching, run the CityWatchlistLoadbatch in the Scheduler Service.
· To load the data to Goods Watchlist and load it to OS for matching, run the GoodsWatchlistLoad batch in the Scheduler Service.
· To load the data to Port Watchlist and load it to OS for matching, run the PortWatchlistLoad batch in the Scheduler Service.
· To load the data to Key Stop Watchlist and load it to OS for matching, run the StopKeyWordWatchlistLoad batch in the Scheduler Service.
There are two ready-to-use pipelines that are used for SWIFT And Fedwire screening and ISO20022 screening.
Matching configuration is set using the Matching Rules widget. Each widget defines a match configuration for a source (transaction) 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. A case 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 (Jaro Winkler, Levenshtein). Each attribute level match has a threshold, below which the score is not considered, and a weightage.
After all the attribute level scores are calculated a average score is calculated for the rule and checked against the ruleset threshold to determine if an alert is to be created. The alert is created only if the transaction 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.
When one or more matches are recorded between a watch list and a transaction record, a case is generated. If a new alert is generated, a new case is also generated in Enterprise Case Management (ECM).
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.