Skip to main content
Version: 2.3.0

Install and configure

This page explains how to install and set up the Isaac AI Agent to review and assess transaction alerts 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.

  • AutoML Workers are not needed.

  • Analytics is not required.

Software​

  • Make sure you are using Work.AI version 10.3 or newer.

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.

After you finish installing, you can start configuring Isaac's settings.

Configure Isaac​

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

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 investigation 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 you need to pause, click Save & continue later. Your entries will be saved so that you can finish the setup when you return.
  • For a variation that already has at least one configured version, 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 guide.

Input​

Isaac supports the following input methods:

API​

This is the default input method. Isaac automatically gets input data from your alert system using its dedicated API.

To stream Isaac's input data through the API, follow the steps below:

  1. Make sure the Enable file ingestion? option is set to No.

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

  3. If needed, enable ingestion from SMB shares.

File ingestion​

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

You can use multiple files for different alert types, but this is only needed if the header information in each file is different. For example, if you have both manual tips and automatically created alerts, you have these options:

  • 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 combine them automatically.

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 file bucket field, specify the S3 bucket from where input CSV files with exported alerts are to be ingested. In the Input file location field, type in the exact folder those are to be stored.

  3. Choose an input source type:

    • S3 to set Isaac to ingest input CSV files from an S3 bucket. As the Input file bucket field appears, specify the S3 bucket in it. In the Input file location field, type in the exact folder where input CSV files with exported alerts are to be stored.

    • SMB to set Isaac to intake data from Server Message Block shares, such as Windows file shares or Linux Samba shares. Further setup includes the following steps:

      1. As the SMB Input file location field appears, specify the path to the SMB storage where the input CSV files with exported alerts are to be kept.

      2. To make sourcing from SMB possible, follow the instructions in Enable SMB ingestion section.

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

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

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

Enable SMB ingestion​

To enable data intake from Server Message Block shares, such as Windows file shares or Linux Samba shares, follow the steps below:

  1. Set Enable SMB? to Yes.

  2. In the SMB username Secret Vault alias field, choose an existing username for the Secrets Vault entry containing the credentials for the used SMB. In case there is none yet, click Create Secrets Vault entry to add one.

  3. In the SMB password Secret Vault alias field, choose an existing password for the Secrets Vault entry containing the credentials for the used SMB. In case there is none yet, click Create Secrets Vault entry to add one.

  4. Type in the SMB domain and the path to the folder where the output files are to be stored.

Investigation​

On the Investigation step, you can configure the following settings:

Deferral settings​

As part of the default workflow, Isaac can automatically check whether new alerts are eligible for deferral 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. Specify the deferral list file bucket (Deferral list file bucket) and location (Deferral list file location) in S3.

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

Alert enrichment settings​

On the Investigation step, you can configure the following settings to enrich investigation data with additional details:

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

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

    • If you use more than one option, Isaac will use the earliest date found to set the review period.

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.

Rule settings​

To configure the decision rules for Isaac, follow the steps below:

  1. 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. Isaac evaluates the transactions against configured criteria and makes decisions to label them, for instance, as high risk, low risk, or as requiring further investigation.

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

  3. In the Transformation steps of the Transaction Monitoring Alert Investigation Business Process, set up no-code rules as described in the guide.

In the Counterparties section, configure the settings as described below to customize the processing of counterparty-related data.

  • Set Enable counterparty classification? to Yes if you want Isaac to classify counterparties based on their risk assessment.

  • Set Populate all alerted counterparties? to Yes if you want Isaac to fetch data for all alerted counterparties.

  • Set Fetch counterparties based on total transactions? to Yes if you want Isaac to fetch data for all counterparties in all transactions.

  • Set the Number of counterparties to fetch field to a value from 5 (default) to 10 to define the number of counterparties Isaac should fetch from results (for further feeding to a downstream system, for instance, Adverse Media Monitoring flows).

  • Set Populate counterparties for high-risk jurisdictions? to Yes if you want Isaac to fetch data for all counterparties associated with high-risk jurisdictions.

  • Set Fetch counterparties for round-dollar transactions? to Yes if you want Isaac to fetch data for all counterparties associated with repeated transactions in exact round dollar amounts.

  • Set Fetch counterparties for each transaction type? to Yes if you want Isaac to fetch data for counterparties based on the transaction type.

  • Set Fetch counterparties for RFI and unknown transactions? to Yes if you want Isaac to fetch data for all counterparties associated with transactions marked as unknown or subject to Request for Information (RFI).

  • Set Override counterparty name from transaction description? to Yes if you want Isaac to use the counterparty names from the transaction description.

  • In the File Location for counterparty pre-screening section, specify the bucket and path to the file where you want to store the counterparty pre-screening output.

warning

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

Entity-level analysis settings​

In the Model ID field, specify the identifier for the model that Isaac will use for account-level analysis of the input data. As part of the analysis, the model will assess risks at the entity level and provide a summary status, comments, and detailed results.

Human-in-the-loop​

Human-in-the-loop is optional. It lets investigators or Quality Assurance specialists review Isaac’s output in Workspace before closing an alert or deferral request and updating downstream systems. Right now, 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, choose whether to create manual review assignments for deferrals 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.

      • Pre-assign work to users?. If set to yes, Isaac pre-assigns deferral review tasks in Workspace based on the 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 this purpose. 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 asynchronously records all transaction decisions in Data Stores. 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.

    • Storage bucket for report templates: specify a top-level S3 bucket for storing all report templates

    • 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 Excel transaction report format drop-down list, select the structure of the generated Excel transaction report:

      • The Just filters option generates an Excel report with two worksheets: one with all transactions and one with alerted transactions, including their statuses.

      • The Pivot table per tab setting 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. Choose whether you want to generate alert-, or entity-level narratives, or both.

    If you choose to generate alert-level narratives, configure the following:

    • Set Include expected/actual transactions in alert-level narrative? to Yes if you want the alert-level narratives to comprise information about total expected transactions and actual results.

    • Set Format the counterparty transactions in the Word transaction report as a table? if you want Isaac to automatically include counterparty data in the Word transaction report as a table for better readability.

  4. Set Include S3 link to the transaction list 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.

  5. Specify a value in the Maximum number of transactions before defaulting to the CSV output format field. Once the number of transaction objects in the output reaches the specified limit, Isaac will switch to preparing reports in the default CSV format.

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

    In the SMTP Secrets Vault alias drop-down list, select an existing secret entry with the 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 that will send the reports.

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

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

  7. In the Narrative grouping field, choose a transaction field for narrative grouping. Available options are as follows:

    • EntryMethod: narratives are grouped by the entry_method value (for instance, online) from Isaac's input data.

    • TransactionCodeDescription: narratives are grouped by the transactionCodeDescription value (for instance, Wire transfer) from Isaac's input data.

    • Type: narratives are grouped by the transaction_type value (for instance, external) from Isaac's input data.

Last updated on