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 the WorkFusion platform. The Transaction Screening or Payment Sanctions Screening (PSS) alert review skill is managed via Control Tower and has several BPs for you to use.

Core Business Process

The current BP flow is as follows:

The Transactions Screening skill performs the following actions:

• Acquires input records and settings.
• Navigates through all payment messages and hits.
• Applies decision reapplication if possible (currently triggered only with the FUF content format).
• Filters hits according to the specified rules.
• Extracts payment messages, hit text, and hit properties.
• Passes data to the Named Entity Recognition Model (NER Model) for entity recognition.
• Runs through message data enrichment steps.
• Passes data to the Decision Model.
• 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 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.

   • Expected output: configuration parameters

2. Read input 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.

   • Expected input: a request JSON object or a flattened representation of it

   • Expected output: "sys_transaction_id", "processing", "ct_data_input"

   If validation fails, additional values are returned: "exception_message", "api_rest_response", "connector_response", "message_decision".

3. Continuous Learning (CLDS) (currently, for the FUF content type only) checks if a decision is made on the same payment message by an analyst and recorded. Then, using configurable rules, you can copy and reapply the decision made by the analyst and bypass the whole workflow. The processing continues at the Generate report bot step, where it is recorded, and a response is returned.

4. Data router controls the flow for valid and invalid requests.

5. BP messages filter takes a record with a 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.

   • Expected input: "sys_transaction_id", "message_datastore_name"

   • Expected output: "message_type"

6. Parse payment message parses the message content according to the specified content format. It 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, and creates a document for ML to process and saves it to the output. The supported native formats are FUF, SWIFT, ISO20022.

   • Expected input: "sys_transaction_id", "message_datastore_name", "model_params"

   • Expected output: "document", "hit_id", "message_id", "exception_message"

7. Validation data checks if the request should be processed by ML.

8. NER Model predicts all entities recognized within the message for further processing in the pipeline (Process NER Model output).

9. Location verification validates the location information in screened and additional data. For more details, refer to Install and configure | Configure date enrichment.

10. Prepare Decision Model Document passes data to the Decision Model.

11. Execute ML model 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 a Model Decision object.

    • Expected input: "document", "model_id", "go_forward_on_failure"

    • Expected output: "model_result" or "model_error"

12. Save model result collects model decision, individual factors, and data points enabling to make a proper decision.

    • Expected input: "sys_transaction_id", "message_datastore_name", "model_params", "model_result", or "model_error"

13. Make message decision based on model results and rules 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 the model decision and builds responses.

    • Expected output: "exception_message", "api_rest_response", "message_decision", "connector_response"

14. 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.

    • Expected input: "generate_report", "sys_transaction_id", "message_datastore_name"

    • Expected output: "links_to_report"

15. Generate 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.

    • Expected input: "api_rest_response"

    • Expected output: "rest_response"

Ingest Historical Decisions for Continuous Learning Business Process

The Ingest Historical Decisions For Continuous Learning BP bundled with Tara is used to reapply previous decisions. The BP loads these decisions to Data Stores and has the following steps:

1. Fetch historical decisions locates historical decisions from S3 and converts them into a CSV file appropriate for Tara to save them to the relevant Data Stores.

2. Save historical decisions batch-loads the decisions to the Data Stores using a URL to the Tara-formatted CSV file.

For more details, see Apply continuous learning.