Install and configure

This page provides instructions on installing and configuring the Isaac AI Agent to investigate and evaluate suspicious transaction alerts generated from surveillance monitoring systems.

Check requirements

WorkFusion offers the following options to install and run Isaac:

• On your premise
• In your cloud
• In a private cloud hosted by WorkFusion

System requirements

The server requirements for Isaac, the Transaction Monitoring Investigator, are the same as for the Work.AI platform. For details, read the Hardware and OS article.

Hardware

• RPA bots are not required unless you use the AI Agent as part of a custom solution.

• High-availability environments require PROXY.

• No AutoML Workers are used.

• Analytics is not used.

Software

• Work.AI version must be 10.2.9 or later.

Install Isaac

To install Isaac, obtain an Asset Bundle (zip archive) with the required release version from the appropriate S3 bucket. Then, upload it manually in the Control Tower interface in accordance with the guide.

Once the installation is complete, you can proceed to configure Isaac's settings.

Configure Isaac

Once Isaac's bundle is installed, you need to configure the AI Agent prior to running it for the first time. On the Digital Workers page, find the installed AI Agent and click Prepare next to it to start.

note

You can configure multiple variations, or sets of parameters, for a single AI Agent. For example, different departments can set up and manage different requirements or input methods per variation. For details, read Manage AI Agent variations.

The configuration process comprises the following steps:

1. Set the input method Isaac is to use.

2. Configure the deferral list processing settings.

3. Set up the human-in-the-loop component (optional).

4. Configure the output handling settings.

info

• When you configure an AI Agent variation for the first time, you must complete the steps one by one. Once you are in the last step, you can go back and make changes to any previous steps.
• If, for some reason, you cannot finish the configuration, click Save & continue later. This way, the entries you made are saved, and you can go back and complete the process later.
• In Work.AI versions starting from 10.2.9.2, for a variation that already has configured versions, you can import a configuration from a previous version instead of setting it from scratch. For that, click the Import version button at the bottom of the configuration screen and follow the instructions in the guide.

Input

Isaac supports two input methods:

• Through Application Programming Interface (API)

• File ingestion

API

This is the default input method. The input data is fetched automatically straight from the customer's alert system using the dedicated API.

To stream Isaac's input data through API, make sure the Enable file ingestion? option is set to No.

File ingestion

The method is mainly intended for historical data evaluation and enables ingesting input as a CSV file using the separate Transaction Monitoring File Ingestion Business Process.

Multiple files for different alert types are supported but not required unless the header information in each file varies. For example, if you have both manual tips and automatically created alerts, your options are as follows:

• Option 1: combine them manually prior to sending them to Isaac.

• Option 2: create the required mapping on the configuration screen so that the AI Agent can automatically combine them for you.

To use file ingestion as the input method for Isaac, specify the following configuration settings:

1. Set Enable file ingestion? to Yes.

   

2. In the Input sources section, specify the S3 bucket (Input file bucket) and folder (Input file location) that contain one or more input CSV files with exported alerts.

3. Map the headers in the input CSV files to the configuration fields. Each CSV file must contain a header row and subsequent rows, each representing a single alert to be reviewed:

   • Entity ID: the unique identifier of the entity associated with the alert (for example, an internal entity or customer identifier).

   • Entity name: the name or label of the entity associated with the alert.

   • Account ID: the account number or unique identifier for the alert in the source system.

   • Alert ID: the unique identifier assigned to the generated alert.

   • Alert scenario: the scenario or scheme that explains why the alert was generated (for example, structuring, high-risk jurisdiction, or smurfing).

   • Alert scope of review: the date or date range that defines the period of alert-related activity to be reviewed.

   • Alert case ID: a unique identifier of the alert case in the source or upstream system.

   • Alert review period: a specific time range during which alert activities are to be reviewed.

   • Notes (optional): descriptive information about the input source.

4. Click Save to save the created configuration. The path to the configured source appears in the Input sources list. You can change the path or header mappings by clicking Edit next to the file path.

   

   To remove an input source, click Delete next to it. To add more input sources, click Add Another and repeat steps 1 through 4.

5. In the S3 location settings for processed files section, specify the bucket (Processed file bucket) and location (Processed file location) where processed files are stored after ingestion.

Investigation

As part of the default workflow, Isaac can automatically check if new alerts are eligible to be deferred to an open investigation. The check is optional. To enable it, set Check if new alerts can be deferred to an open investigation to Yes and complete the following steps:

1. Set the S3 bucket and folder for storing the flat file (CSV) covering all open cases and make sure to upload the file to the location.

2. Map the headers from the file to the following required fields:

   • Entity ID: a unique identifier of the entity associated with the alert.

   • Deferral case ID: the identifier of the open investigation case to which eligible alerts may be deferred.

   • Deferral case scope of review (optional): when provided, it allows Isaac to better align deferral decisions with the existing investigation context.

3. Specify the deferral list file bucket (Deferral list file bucket) and location (Deferral list file location) in S3.

   

4. Set Create and email a report with potential deferrals? to Yes if you want Isaac to generate a report listing potential deferrals. In the Email address field, specify the recipient email address. To add more recipients, click Add.

   

   If the setting is enabled, the Transaction Monitoring Core Business Process generates the report and sends it to the specified email as soon as its execution reaches the corresponding step.

   Click the link to download a sample potential deferral report.

5. Configure the following additional investigation settings:

   

   • Set Retrieve transactions from external sources? to Yes to enrich Isaac's input data with alert-specific transaction details from external systems (for instance, internal transactional systems).

   • Set Enrich alerts with additional transaction details? to Yes to fetch and attach additional transaction details for use in subsequent investigations related to a specific case. For instance, these could be details extracted from cheque images or Automated Clearing House (ACH) data.

   • Set Run the rule engine on transactions to identify suspicious activity? to Yes to run pre-built and no-code rules on the transactions retrieved for each alert, evaluate transactions against configured criteria, and make decisions, for instance, labeling them as high risk, low risk, or as requiring further investigation.

     • In Enabled Pre-built Rules, select the pre-built code rules you want to apply. For more information, see Configure rules | Pre-built rules.

     

     • In the Transformation steps of the Transaction Monitoring Alert Investigation Business Process, set up no-code rules according to the instructions in the guide.

   • In the Scope of review strategy field, select one or more options to define how Isaac determines the review period for a given alert in a fraud investigation. The available options are as follows:

     • Use scope of review from alert details. Isaac identifies the earliest fraud-related date from the alert details (the alertDetailsList object in the input data) and uses it as the start date of the review period.

     • Extract all alerted transaction dates. Isaac identifies the earliest fraud-related date from the alerted transaction details (the alertedTransactions object in the input data) and uses it as the start date of the review period.

     • Extract all case note dates. Isaac identifies the earliest fraud-related date from the case notes (the caseNotes object in the input data) and uses it as the start date of the review period.

     When a combination of the options is used, Isaac uses the earliest extracted date to define the scope of review.

note

Depending on your Isaac implementation, you might need to set up custom Business Processes to retrieve data from external sources or to enrich alerts with additional transaction details. These Business Processes must then be integrated into the Transaction Monitoring Alert Investigation Business Process. For details, read Overview | Transaction Monitoring Alert Investigation.

Human-in-the-loop

Human-in-the-loop is an optional step that enables investigators or Quality Assurance specialists to review Isaac's output in Workspace before an alert or deferral request is closed and downstream systems are updated. Currently, only deferral-related human-in-the-loop tasks are supported.

To configure the human-in-the-loop settings, do as follows:

1. Set Automatically route users to the next task in the queue? to Yes to route users in Workspace to the next available task that is not actively being processed, regardless of assignment ownership.

   

2. In the Deferral task settings section, enable or disable the creation of deferral manual review assignments in Workspace:

   • Choose Enable in all cases if you want Isaac to create assignments for reviewing deferral requests in Workspace. When the option is enabled, you can configure the following deferral review settings:

     • Restrict access to specific user groups?. If set to Yes, specify the field name in the deferral file containing the name of the user group that you want to access the deferral task in Workspace. In case you specified no group, the assignment is visible to all users in Workspace.

     • Do you want to pre-assign work to users?. If set to yes, Isaac pre-assigns deferral review tasks in Workspace based on assignee information provided in the deferral input file.

       • Username: the name of the field in the deferral input file that contains the Workspace username of the user to whom the deferral review task is assigned.

       • Assignee email address: the name of the field in the deferral input file that contains the email address of the user to whom the deferral review task is assigned.

       • Email the assignee when the deferral task is ready for review? Select Yes to send an email notification to the assigned user or No to decline the action.

       • Notify additional users? The setting is available only if you set Email assigned user when deferral task is ready for review? to Yes. Select Yes to notify additional users and specify one or more email addresses for the purposes. Select No to decline the action.

     • Deferral due date: the number of business days for the assignment to be completed in Workspace.

   • Choose Disable in all cases if you do not want Isaac to create assignments for manual review of deferrals in Workspace.

Output

As part of the default workflow, Isaac records all transaction decisions to Data Stores asynchronously. If required, you can configure Isaac to generate the following report types:

• Transaction report

• Fraud summary report

• Final alert summary report

To enable emailing of the final summary report, follow the steps below:

1. Set Email a summary of all alerts after each batch completes? to Yes and specify the email address that should receive the summary and fraud summary reports.

   

   To send the same report to multiple recipients, click the Add button and enter an additional email address.

2. Set the file buckets and output templates for the fraud summary and transaction reports as needed.

   

   • Fraud report template bucket: automatically populated; specifies the storage location for fraud report templates.

   • Fraud report output template: optional; specifies the template used to generate the fraud summary report. Leave empty if no template is required.

   • Excel transaction report template bucket: automatically populated; specifies the storage location for Excel transaction report templates.

   • Excel transaction report output template: optional; specifies the template used to generate the Excel transaction report. Leave empty if no template is required.

   • In the Document Format drop-down list, select the structure of the generated Excel transaction report:

     • JustFilters generates an Excel report with two worksheets: one with all transactions and one with alerted transactions including their statuses.

     • PivotTablePerTab generates an Excel report based on your custom template with pivot tables defined by you.

   • Word transaction report template bucket: automatically populated; specifies the storage location for Word transaction report templates.

   • Word transaction report output template: optional; specifies the template used to generate the Word transaction report. Leave empty if no template is required.

3. Set Include transactions in JSON output? to Yes to include transaction-level data in the JSON output. Use the option with caution as enabling it can significantly increase the size of the output payload.

4. In the Email settings section, configure the SMTP connection details.

   • In the SMTP Secrets Vault alias drop-down list, select an existing secret entry that contains credentials for the service email account.

   To create a new secret entry, click Create Secrets Vault entry, specify the alias, key, and value, and then click Save.

   • In the SMTP host field, specify the SMTP server hostname.

   • In the SMTP port field, specify the port used by the SMTP server.

   • In the Sender email address field, enter the email address used to send the reports.

   • In the Reply-to email address field, specify the email address that recipients can use for replies.

   • Set Enable authorization? to Yes to enable SMTP authentication and TLS encryption for secure data transfer.