Overview
Isaac, the Transaction Monitoring Investigator (TMI), automates transaction monitoring by investigating and evaluating unusual transactions identified by surveillance systems.
Current challenges in transaction monitoring
Transaction Monitoring (TM) is a critical tool for fighting global financial crime under anti-money laundering and countering the financing of terrorism (AML/CFT) programs. However, compliance is challenging due to the time, staffing, and costs required for suspicious activity monitoring.
Monthly, banks are expected to manually review millions of transaction monitoring alerts, most of which are non-suspicious.
Large volumes of data and supporting documentation accumulate in case management systems as a result of monitoring activities.
Banks need to provide integrations to enrich investigations with data from third-party sources and internal tools.
Effective transaction monitoring involves analyzing relationships between data points, detecting anomalies and unusual patterns, and comparing actual activity to expected behavior.
Teaming up with Isaac to address challenges
As an AI Agent, Isaac helps with TM alert management by using machine learning to process first-level alerts, auto-escalate those likely to require investigation, and close non-suspicious alerts.
The Transaction Monitoring Investigator addresses common Bank Secrecy Act (BSA) scenarios that generate high alert volumes, such as:
- Structuring
- Excessive fund transfers, movement of funds, and patterns of fund transfers
- Unexpected account usage or behavior
- High-risk factors
- Use of dormant accounts
To maintain transparency for examiners and auditors, each Isaac decision is supported by a human-readable justification, reporting documentation, and a confidence threshold. However, Isaac is not a transaction monitoring tool and does not generate alerts.
Isaac's capabilities
Isaac provides the following AI-based transaction monitoring capabilities:
Sampling on transactions related to alerts
Gathering KYC information on focal entities, for instance, occupation, onboarding date, risk rating, source of funds, status of a politically exposed person (PEP), and previous suspicious activity reports (SARs)
Identifying transaction counterparties and lines of business by leveraging available data and analyzing red flags, such as lack of website, shell company addresses, or high-risk geographies
Sourcing and reviewing negative news on counterparties and focal entities and conducting PEP or sanction alert reviews
Reviewing alerted and historical transactions for counterparties or focal entities to assess consistency, value, volume, expected frequency, and rapid succession payments
Summarizing, justifying, explaining, clearing or escalating decisions as appropriate
Fraud detection
Certain counterparties are not included in the investigation scope. For the detailed exclusion list, read F.A.Q | Are all counterparties included in the investigation scope?.
Business Process overview
A Business Process (BP) is the core workflow of any automation use case in the WorkFusion platform. Out of the box, Isaac comes with the following Business Processes:
Transaction Monitoring Core
The Transaction Monitoring Core Business Process is recommended for batch alert processing.
It does the following:
Retrieves input alert data from the configured source, which may be an internal monitoring system integrated via API or the output of the Transaction Monitoring File Ingestion BP.
Groups alerts by the entity ID, identifies individual entities, and attaches the relevant alert lists to each.
Sends email notifications about potential deferrals if this feature is enabled in the investigation settings.
Initiates the Transaction Monitoring Alert Investigation BP for each separate entity. For instance, if 10 entities were identified in the input data, it would call the Transaction Monitoring Alert Investigation BP 10 times.
Collects the output from the Transaction Monitoring Alert Investigation BP and updates entity details accordingly.
Generates a summary report and sends it to the configured email.
Transaction Monitoring Alert Investigation
The Transaction Monitoring Alert Investigation Business Process is recommended for alert-by-alert real-time processing.
It does the following:
Fetches alerts from the source using a dedicated API, evaluates them, and provides initial statuses and comments.
Checks the deferral list and input data against the investigation settings and, if needed, identifies alerts eligible for deferral to an open investigation.
Creates deferral requests and routes them for manual review in Workspace if the Human-in-the-loop step is enabled during configuration.
Collects the outputs from manual review (if any) and automatic evaluation results and redirects the data for further processing into one of the flows:
Applies the rule engine rules (if enabled) to standardize risk detection, accelerate alert triage, and reduce false positives.
Combines the outputs from the fraud investigation and transaction monitoring flows and returns them to the Transaction Monitoring Core BP if the latter is used.
Transaction monitoring flow
This is the default transaction data processing flow that outputs a transaction report. The flow includes a rule engine that evaluates transactions against the following filtering criteria and assigns them a status, for instance, labels them as high- or low-risk:
You can enable the rule engine per variation during Isaac's configuration on the Investigation step. If the rule engine is disabled, Isaac will not apply rules to filter transaction data.
WorkFusion provides prebuilt and no-code filtering rules out of the box. Additionally, you can customize or add more no-code rules as described in the Configure no-code Transformation step guide.
The figure below shows a no-code filtering rule that compares the country names in the transaction data against blacklisted countries and adds a REQUIRES_FURTHER_INVESTIGATION flag if a match is found. Additionally, a comment is also added to explain the flag. For more details on no-code rules, refer to Configure rules | No-code rules.
Optionally, the transaction monitoring flow can include sub-flows to enrich processed data with input from external systems (for instance, customer internal systems) or additional transaction details (for instance, details extracted from cheque images). To enable these sub-flows, follow these steps:
Build custom Business Processes to fetch the required enrichment data as described in the guide.
Integrate the BPs into the transaction monitoring flow as synchronous sub-process execution steps by specifying a Signal ID. For details, read the guide.
Enable the Run the rule engine on transactions to identify suspicious activity? option during Isaac's configuration on the Investigation step. For details, read the Install and configure guide.
The figure below shows a synchronous sub-process step that enriches the transaction monitoring flow with the details extracted from cheque images.
Fraud investigation flow
The flow is optional and initiated when the input data includes a fraudInvestigationDetails object. It produces a fraud summary report.
Similar to the transaction monitoring flow, the fraud investigation one includes a rule engine that evaluates transaction data against prebuilt and no-code filtering rules to identify a fraud (if any).
You can enable the rule engine per variation during Isaac's configuration on the Investigation step. If the rule engine is disabled, Isaac will not apply the rules to the transaction data passing through the flow.
WorkFusion provides prebuilt and no-code filtering rules out of the box. Additionally, you can customize or add more no-code rules as described in the Configure no-code Transformation step guide.
The figure below shows a no-code filtering rule that compares the transaction amount in the input data to a reference sum and adds a REQUIRES_FURTHER_INVESTIGATION flag if the amount exceeds the reference. Additionally, a comment is appended to explain the flag. For more details on no-code rules, refer to Configure rules | No-code rules.
Transaction Monitoring File Ingestion
The Transaction Monitoring File Ingestion Business Process does the following:
Updates the list of deferrals and alerts based on one or more input CSV files in the configured S3 storage. The input files comprise the data collected from surveillance monitoring systems.
Checks the processed file folder for any missing alerts.
Passes the data on to the Transaction Monitoring Core BP.