Overview

Tara is an AI Agent for Payment Sanction Screening (PSS) Alert Review who detects real-time transactions or payments to or from sanctioned individuals, entities, or jurisdictions during onboarding and throughout the customer relationship lifecycle, helping to mitigate risks to financial institutions. Screening primarily involves sanction lists published by the Office of Foreign Assets Control (OFAC) and often includes external and internal bank sanction lists.

Financial institutions (FIs) and other organizations use sanctions screening or watchlist filtering technologies, such as Fircosoft Continuity, CGI Hotscan, and NetReveal, to compare inputs, such as transactions with items on a sanction list. The output of these technologies is alerts or hits.

Tara is designed to ingest each alert generated by a financial institution's sanctions screening system and determine if it is a false positive. She is also trained to escalate potential true hits to a predefined team within the institution. Human workers manually review all flagged transactions or payments to clear false positives.

Why banks or financial institutions screen transactions

To stop illegal or questionable transactions in real time, regulators of banks and financial institutions enforce the screening of their transactions. These screenings determine risk management steps needed to protect the institutions from legal consequences, heavy financial penalties, and damage to their reputations.

Today's sanction screening process

Global banks annually process millions of payments. Rules-based and keyword lookups, such as Fuzzy, Soundex, and SEMrush, sanctions screening software, generate important alerts. It generates 5% of transactions due to alerts out of the total transactions, which is enormous. Another side of the story is that 95% of these alerts are false positives. Banks and financial institutions hire large teams to manage the manual resolution of such alerts. It costs $2-$5 to resolve each alert manually.

WorkFusion helps in the sanction screening process

WorkFusion's pre-trained Machine Learning (ML) models and intelligent bots review payment messages and alerts for several common false-positive scenarios. This reduces the four-eye investigator-checker model to a two-eye investigator-checker. Using out-of-the-box ML models, bots can serve as investigators (makers). Analysts still serve as checkers who understand and validate insights and quality.

This process reduces mundane and repetitive tasks and empowers employees to focus on high-value work.

WorkFusion's intelligent bots and ML models automate all the repetitive tasks:

• Conducting payment entity research through intelligent bots
• Validating the payment entity mapping scenario using multiple sanction lists with no human supervision needed

As these intelligent bots produce the conclusion report from multiple sources, decisions are more accessible because intelligent bots provide all the evidence on a single screen.

Benefits of Transactions Screening Intelligent Automation

Automating Transactions Screening Intelligent Automation provides the following benefits:

• Manual work is replaced with more reliable and accurate automation.
• The screening process is simplified and standardized.
• False positives are identified and excluded.
• Rationale is recorded with the audit trail.
• Easy implementation is provided for the robot-human "four-eye check" requirement.

Efficiency criteria

WorkFusion aims to achieve the following:

• Improve automation rates: up to 70% or more reduction of false positive hits.
• Provide accuracy of STP of less than 1% error rate for missing valid sanctioned entity.
• Increase volume: ~ up to 5000 alerts per hour. This is scalable.

Note that Scalability depends on hardware resources and the number of agents.

Business Process overview

A Business Process (BP) represents the core workflow and design of any automation in WorkFusion's Intelligent Automation Cloud platform. The Transaction Screening or Payment Sanctions Screening (PSS) alert review skill is managed via Control Tower.

The current PSS process flow is as follows:

The Transactions Screening skill performs the following actions:

• Acquires input records and settings.
• Navigates through all payment messages and hits.
• Filters hits according to the specified rules.
• Extracts payment messages, hit text, and hit properties.
• Passes data to the ML Engine or Cognitive Bot.
• Makes payment adjudication on the message and hit level.
• Generates output results and reports.

note

The data processing workflow in PSS does not depend on the client or the message type (SWIFT, SEPA, Fedwire, and so on).

The BP flow steps are explained as follows:

1. Read configuration reads settings from DW UI configuration and other Data Stores and propagates to output. The default configuration is saved in the configuration_payload.json file. The entry point is the DW UI configuration configuration.json form that defines all configuration fields.
2. Read data gets input data from loaded files, API calls, or the Connector. The input data is validated against the standard request object. It skips processing if a request is invalid or doesn't exist.
3. Data router controls the flow for valid and invalid requests.
4. Filter hits takes a record with request_id provided in binding from the request Data Store, converts it to a Message object, and applies hit filters according to the rules defined in the filtering_rules Data Store. These rules determine which type of a data model it will try to resolve. The bot performs data normalization and returns updated data to the message-processing Data Store.
5. Parse payment message parses the message content according to the specified content format. It does the following:
   • Searches through all message hits.
   • Matches the screened entity with the message content.
   • Composes entity fields using the type's dictionary.
   • Updates Message objects.
   • Saves them for further processing.
   • Creates a document for ML to process and saves it to the output.
6. Location verification validates the location information in screened and additional data.
7. Validation data rules checks if the request should be processed by ML.
8. Execute AutoML Model: Bridge reads a list of hits and determines false positive cases. An ML Python model accepts input (JSON) that represents a Message object and returns a response as a JSON document with the ModelDecision object.
9. Company verifier searches for screened companies in the input data to verify their information (if the Corporate Registry integration is enabled in the DW configuration). If a screened company is verified, the model decision can change to a false positive, increasing the automation rate. The bot only modifies the model result.
10. Make message decision based on ML results takes an informed adjudication decision on the message and hit levels to determine whether all hits are false positives or need to be escalated further. The bot updates the pss_request_processing Data Store with a model decision and builds responses for the Connector and API.
11. Generate report produces analytics data to display in a dashboard. The dashboard shows the automation rate and other data collected during the BP execution. HTML reports are generated, if configured. The bot sends a billing report to a specified RMQ.
12. Send REST response sends the response back to the client if the Streaming Records from External Sources option is enabled. The step can be replaced with any Connector's output step.