Skip to main content
Version: 2.2.3

Install and configure

The guide provides instructions on installing and configuring the Tara AI Digital Worker (AI DW).

Check requirements​

WorkFusion uses the following options to install and run Tara for Transaction Screening:

  • On your premise
  • In your Cloud
  • In the private Cloud that WorkFusion hosts

Hardware​

note

The requirements are for the on-prem installation type.

The servers must conform to the Enterprise Edition v10.2.6 or 10.2.7 standards. The specifications below allow the system to handle up to 3000 requests or messages per hour for PSS version 2.1+. It also allows scaling additional BEP servers horizontally to handle additional loads.

ServerRecommended OSCPU (Cores)RAM (GB)HDD (GB)
ApplicationRHEL 8.5832750
BEP AgentRHEL 8.5832150
AnalyticsMicrosoft Windows Server 2019416150
MS SQLMicrosoft Windows Server 2019416500

Software​

  • Intelligent Automation Cloud Enterprise version 10.2.6+
  • ODF 2
  • Python 3

Performance​

note

The performance metrics are for the on-prem installation type.

The PSS skill leverages BEP servers that can be horizontally scaled for higher volumes.

Below is a sample of the volumes that can be expected when using the provided version and configuration. The system shows stable performance and resource consumption during the whole test, without unexpected spikes and errors, or any critical errors and warnings in logs.

Configuration:

Skill versionEnvironment topologyTested IA Cloud versionNumber of RPA BotsNumber of OCR WorkersMachine Learning worker configurationControl Tower worker configuration
2.2.33 / 6 / 20 Agents10.2.6, 10.2.7571 CPU / 8 GB memory0.4 CPU / 2 GB memory

Results:

Number of AgentsNumber of Payment alertsDurationNumber of PSS WorkersHits/hour
320,0001 hr 51 min636,000
620,0001 hr 5 min1274,000
2020,00026 min40230,000
20 (3 BP x 20,000 alerts)60,00051 min40353,000

Here, one payment alert = five hits.

Install​

See the Install AI Agents guide.

Configure​

You can configure or update the AI DW configuration in one of the following ways:

  • Go to the Digital Workers tab, select your Business Model, click the Actions menu, and select Settings.

  • Go to the Digital Workers tab and click your Business Model. On the Business Processes tab, click the Actions menu and select Settings.

Configure the following settings:

  1. In Input, select the way to supply data to a BP. Choose one of the following options:

  2. In Model, select a compatible model from the list. Otherwise, the default (latest) one is used.

  3. In Data enrichment, specify the sources to get data from:

    1. In the Corporate registry field, select a corporate registry provider to get additional entity information. For more details, refer to the Integrate external services section.

    2. In the Address verifier field, select a service to check screened addresses.

      • In the Google Maps API Key field, specify your Google Maps API key. Address Validator uses it to access the Google Maps service for address verification. For more details on getting a key for a Google Cloud account, see Using the Google Maps Platform.

      • In the Secrets Vault Alias field, enter the alias that distinguishes your secure entry.

  4. In Output, select Yes to generate an HTML report of BP results after a BP run. For more details on how to find a generated report, see Run screening | View results.

  5. Click Finish.

Integrate external services​

To configure integration with an external service for retrieving additional data and improving model decisions, provide a valid access token. Perform the following steps:

  1. In the AI DW configuration menu, go to the Data Enrichment tab and select OpenCorporates.

  2. In the Credentials location field, specify the Secrets Vault location of the credentials for the provider's license.

  3. Enter an alias for the token. There are two options to do it:

    • Enter the alias in the Provider's security token field.

    • Go to System Settings > Secrets Vault and click Add.

    Enter the same alias from the AI DW configuration, specify the token in the Value field, and click Save.

Customize configuration settings​

During the AI DW configuration phase, a BP starts with reading settings from the configuration.json file that contains all parameters required to load data and control a data flow.

A sample configuration.json file
{
  "provider": {
    "name": "open_corporates",
    "credentials_alias": "opencorporates_api_token",
    "trigger_codes": "5"
  },
  "input": {
    "source": "file",
    "message_datastore_name": "pss_request_processing_v1",
    "ml_thresholds_datastore_name": "pss_payment_transfer_thresholds_v1",
    "filter_datastore_name": "pss_payment_transfer_filtering_rules_v1",
    "message_batch_size": "500",
    "message_poll_interval_mills": "60000"
  },
  "model": {
    "model_id": "",
    "go_forward_on_failure": "false",
    "default_model_Id": "pss-classification-model-v2.2.3.0"
  },
  "output": {
    "generate_report": false
  },
  "submit": false
}

You can customize the following parameters:

  • message_datastore_name: name of the Data Store that contains processing data. New messages come to this Data Store. Data gets updated during the BP execution.
  • ml_thresholds_datastore_name: name of the Data Store that contains the mapping of decision codes: definition, confidence threshold, decision.
  • dictionary_datastore_name: name of the Data Store that contains a dictionary of entity attributes and their types in relation to the message type.
  • model_id: name of the ML model used to process input data to determine possible False Positive hits.
  • go_forward_on_failure: variable required to run ML Bridge.
  • message_batch_size: number of messages to process at once.
  • message_poll_interval_millls: message monitoring poll interval in milliseconds. If negative, polling stops when reading all messages.
  • filter_datastore_name: Data Store that contains alerts filtering rules; adjudicate only alerts that match the defined rules. If not defined, all data goes through the model.
  • open_corporates_trigger_codes: for the Company entity type, you can call Open Corporates to find information about it. Makes a call if a model returns specific decision codes. If not defined, no calls to Open Corporates are made. May contain comma-separated values where each value is a decision code returned by the model.
  • provider_name: corporate registry provider for the company validation.
  • provider_credentials_alias: alias registered in Secrets Vault.
  • provider_credentials_value: (optional) access token used if there is none in Secrets Vault.

Customize models​

You can customize decision rules, influence ML model outcomes, and thus configure your own rules for specific needs. After completion, a new model appears in the list, and you can choose it during the AI DW configuration.

To update the decision rules, do the following:

  1. Go to AutoML > Datasets and create a test dataset. Memorize its name, as you need it in further steps. See the sample dataset with one record. For more details, refer to the Manage datasets section.

  2. Go to AutoML > Models and find your model in the list.

  3. Click the model's Actions menu and select Copy to modify.

  4. On the Modify window > Prototype > Model ID, specify a new name of the model variant and click Next to continue. Mind that the name must start with pss-classification-model.

  5. On the Modify window > Testing, select the dataset from step 1 and click Next to continue.

  6. On the Modify window > Post-processing, click Next to continue. Tara does not have any post-processors, so skip this step.

  7. On the Modify window > Rules, set up the model's custom rules.

    On the Resolve rules tab, configure the rules that define the factors contributing to a false positive (or RESOLVE) decision. Specify the type in the drop-down menu and select the applicable rule next to it. Each row represents one rule.

    If any rule is valid, a hit is resolved. For example, you resolve a hit if Name mismatch, Type mismatch, or a combination of Date of birth mismatch and Location mismatch are found in the list of reasons. Mind that Date of birth mismatch or Location mismatch alone is insufficient for a resolution. Also, each rule has an associated type, which is All types by default. You can fine-tune the rules to only impact certain hit types. Supported hit types are:

    • Individual
    • Organization
    • Location
    • Vessel
    • Aircraft

  8. Click Start to build a new model that contains a new decision matrix. When the operation finishes, your new model with the selected name appears in the list of models.

  9. Go to AutoML > Models and select your new model from the list.

How decision matrix works
  • A hit is resolved when any of the conditions apply:
    • Each row creates a resolve condition.
    • Each condition contains one or more deciding factors.
    • When conditions have all factors, that maximizes the automation rate.
  • A hit is escalated when any of the conditions apply:
    • Each row creates an escalating condition.
    • Each condition contains one or more deciding factors.
    • When conditions have all factors, that minimizes mistakes.
See an example request
{
  "id": "1",
  "type": "PAYMENT_TRANSFER",
  "hits": [
    {
      "id": "1",
      "tagContent": "Payment to John Doe for service",
      "tagType": "FREETEXT",
      "screenedData": {
        "name": "John Doe",
        "type": INDIVIDUAL,
        "country": "USA"
        "dob":"1978"
      },
      "additionalData": {},
      "sanctionData": {
        "name": "John Doe",
        "primaryName": "John Henry Doe",
        "type": "INDIVIDUAL",
        "dob": "1956",
        "country": "USA",
        "sourceEntryId": "1",
        "source": "OFAC",
        "listType": "WORLD_COMPLIANCE",
        "alsoKnownAs": [
          {
            "name": "John Doe",
            "type": "NOT_AVAILABLE"
          }
        ]
      }
    }
  ]
}
See model examples

  • Model 1 (default settings)

    Expected decision: NO_DECISION

    There is Date of birth mismatch, and you can resolve only if Date of birth mismatch + Location mismatch. Date of birth mismatch on the same row means AND Location mismatch.

  • Model 2

    Expected decision: RESOLVE

    Date of birth mismatch is a stand-alone reason for a hit dismissal.

Add message type​

info

The procedure works only for messages received in the Fircosoft FUF or SWIFT RAW formats.

To add a message type for processing, do as follows:

  1. In the data-model-api sources, go to the MessageType.java file and define a new type. Release any changes to the data model API with the updated version. Use the updated version in the project as a dependency. The existing message types are as follows:

    public enum MessageType {
    GDS,
    ACH,
    SWF,
    FED_WIRE,
    PAYMENT_TRANSFER,
    }

  2. In the dictionary, add details of the entities that belong to the new message type, for example, sanctions-bcb/wfs-data/datastore/pss_fuf_tags_list.csv. This file defines the entity type for the entity attribute and maps message types to the entity attributes. If the entity type cannot be found, it becomes freetext.

See sample dictionary entries below.

msgtypeattrnameentitynametypedescription
GDSColf_CunryCollectFromCountryCollect from Country Name
GDSColf_NameCollectFromNameCollect from Name
SWFSWF_4_30Requested Execution DateDatedate
ACHIAT-ODFINOriginatingCompanyORIGINATING DFI NAME

If you add new attribute types to the type dictionary column, update the AttributeType.java file to match values of new attribute types. The existing attribute types are as follows:

public enum AttributeType {
    NAME,
    NAMEADDRESS,
    ADDRESS,
    CITY,
    STATE,
    ZIP,
    POSTALCODE,
    COMPANY,
    COUNTRY,
    COUNTRYCODE,
    CITYCODE,
    NUMBER,
    AMOUNT,
    ID,
    DATE,
    VESSEL,
    FREETEXT
}

Update filtering rules​

To adjudicate a specific subset of the data, create a filtering Data Store and set the rules. If a record complies with any defined rules, it is processed by the model.

Mind that:

  • Filtering rules apply on the hit level.
  • Each row must contain at least one condition.
  • If a rule has many conditions, add more rows with the same rule name.
  • Allowed values have comma-separated values of the field name. The field can also contain predefined values such as EMPTY and NOT_EMPTY.

To work with filtering rules, do as follows:

  1. Go to Advanced > Data Stores and select the pss_payment_transfer_filtering_rules_v1 Data Store.

  2. Add, modify, or delete the rules as if you work with rows and columns of any other Data Stores.

Last updated on