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 basic steps of the PSS BP flow are explained as follows:

1. Read settings from JSON allows reading settings from the Digital Worker configuration_payload.json file and other Data Stores and propagates to output. The step gives the entry point to the Digital Worker configuration UI via the configuration.json form.

2. Read data adds input data from loaded files, API calls, or a 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 the 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. Validation Data Rules checks if the request should be processed by ML.

7. Execute AutoML Model reads a list of hits and determines false positive cases with the explanation. An ML Python model accepts input in the form of a JSON document that represents a Message object and then returns response as a JSON document with the ModelDecision object.

8. Company verifier searches for screened companies in the input data to verify their information if the Corporate Registry integration is enabled in the Digital Worker configuration. If a screened company is verified, the model decision can change to false positive, increasing the automation rate. The bot only modifies the model result.

9. Make message decision based on model results takes an informed adjudication decision on the message and hit levels to determine whether all hits were 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.

10. Generate report produces analytics data to display in a dashboard. The dashboard then shows the automation rate and other data collected during the BP execution. HTML reports can be generated, depending on configuration settings. The bot sends a billing report to a specified RMQ.

11. Generate Rest response sends the response back to the client if the Streaming Records from External Sources option is enabled.