Skip to main content
Version: 2.3.5

Install and configure

info

You can use the documentation on version 2.3.5 for working with Tara version 2.3.6.

The guide provides instructions on installing and configuring the Tara AI Agent.

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 Platform v10.2.7 or 10.2.8 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​

  • IA Cloud Enterprise v10.2.7 or Work.AI v10.2.8
  • 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 version 2.2.6 and higher. 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 platform versionNumber of RPA BotsNumber of OCR WorkersMachine Learning worker configurationControl Tower worker configuration
2.2.63 / 6 / 20 Agents10.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 Agent 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, configure model settings:

    1. In the Trained model dropdown list, select a compatible model. Otherwise, the default (latest) one is used.

    2. In the Matching thresholds section, specify the following thresholds:

      • In the Name matching field, enter a value between 0 and 1.00. Consider names a match if they are similar to a screened entity at least to the defined extent.

      The score is closer to 0 when names are different and closer to 1.00 when names are similar. Below the threshold, names are considered different and will be a mismatch. Above the threshold, names are considered similar and will be a match.

      0.75 is the default value. Thus, if Tara predicts a name is at least a .75 likely match, it will consider the name matching or partially matching.

      note

      Increasing the threshold value might increase the automation and error rates, meaning fewer names match.

      • In the Date of birth matching field, enter a value between 0 and 9999. Consider dates of birth a match if they are within the defined number of days before or after the screened date.

      365 is the default value. Thus, if Tara identifies birth dates are within 365 days of each other, it will consider them a match. When two birth dates are more than the specified number of days apart, they are considered different and will be a mismatch.

  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 Sanction programs, select the Enable Sanction Programs checkbox to check alerts for permitted and prohibited keywords.

    1. Specify the Sanction Program name, for example, EO13662.
    2. Type in keywords into the Permitted keywords and Prohibited keywords fields. Press Enter to add a keyword.

    • If permitted keywords are found and there are no prohibited keywords, the alert is RESOLVED.

    • If prohibited keywords are found, the alert is NO_DECISION.

    1. Add ignored keywords. If you configure Ignored keywords, the "credit" prohibited keyword is permitted if it occurs in the text the same number of times as ignored keywords.

  5. In Reapplication Data > Enable DR Processing, select yes to enable the decision reapplication data flow. By default, the feature is disabled.

    Once you enable the DR flow, configure the needed settings:

    • In the Message Type drop-down list, define the message type to target for decision reapplication. The list currently has only a FUF value.

    • In the Tags to compare field, enter tag names from an alert as comma-separated values, the content of which is used to compare against historical data together with hashed hit content.

    info

    Enter at least one tag for the decision reapplication feature to work.

    • In the Search Timeframe (in days) field, specify the maximum number of days in the past to search for historical data. Older decisions will not be considered for reapplication. If the value is missing, 365 days is used as default.

    For more details on the feature, see Apply decision reapplication.

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

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

    In the Alias field, enter the same alias from the AI Agent configuration. Then, specify the token in the Value field and click Save.

Customize configuration settings​

During the AI Agent 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
{
  "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",
    "fuf_tag_datastore_name": "pss_fuf_tags_list_v1",
    "swift_tag_datastore_name": "pss_swift_tags_list_v1",
    "iso20022_tag_datastore_name": "pss_iso20022_tags_list_v1"
  },
  "model": {
    "model_id": "",
    "go_forward_on_failure": "false",
    "default_model_Id": "pss-classification-model-v3.2.8",
    "nameMatchThreshold": 0.75,
    "dobMatchThreshold": 365
  },
  "provider": {
    "name": ""
  },
  "output": {
    "generate_report": false
  },
  "sanctionPrograms":{
    "enableSanctionPrograms":true
  },
  "container":{
    "sanction_programs":[
      {
        "sanctionPrograms":{
          "sanctionName":"EO13662",
          "permittedKeywords":"margincall,fxdeal,fxtrade,forex,currency trade,margin call,margn call,margin call intraday,activity fx,fx activity,fx deal,fx trade,forex deal,interest rate swap,forex trade,interest rate derivative,otc derivative,foreign exchange,exchange deal,collateral management,management fx,fx margin,coll mgmt,forex netted,collateral mgmt,pmnt under,forex precious metal trade,forex precious metal,no debt or equity,n o debt or equity,no  debt or equity,does not relate to any debt or equity,credit derivative,credit derivatives,credit default swap",
          "prohibitedKeywords":"debt,equity,credit,loan,acceptance,stock,isin,sedol,qusip,buy,trade,trade finance,credit extension,letter of credit,discount note,commercial paper,fixed income,share issuance,depositary receipts,bill of lading",
          "ignoredKeywords":"credit suisse,credit agricole,credit andorra,credit bank,credit europe bank,credit dnepr,credit libanais,credit lyonnais,credit moscow bank,credit mutuel,credit standard bank,credit ural,credit uruguay,credit du maroc,home credit,credit populaire d'algerie,bank bfg credit,bank devon credit,banque internationale du cameroun pour l'epargne et le credit,banque malienne de credit et de depots,banque nationale de credit,banque de credit de bujumbura,credit immobilier et hotelier,credit industriel et commercial,dexia credit local de france,mutuelles congolaises d'epargne et de credit,national credit & commerce bank,national credit bank,nepal credit and commerce bank,renaissance credit,southern credit banking corporation,thai credit retail bank,vancouver city savings credit union"
        }
      }
    ]
  }
}

You can customize some settings, some are hidden from the user interface and cannot be changed.

The default configuration parameters are as follows:

  • 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.
  • fuf_tag_datastore_name: name of the Data Store that contains the FUF dictionary of entity attributes and their types associated with a message type.
  • swift_tag_datastore_name: name of the Data Store that contains the SWIFT dictionary of entity attributes and their types associated with a message type.
  • iso20022_tag_datastore_name: name of the Data Store that contains the ISO20022 dictionary of entity attributes and their types associated with a message type.
  • model_id: name of the ML model used to process input data to determine possible False Positive hits. If not provided, the default_model_Id value is used.
  • default_model_Id: model version that comes with the bundle during the release.
  • go_forward_on_failure: variable required to run AutoML Bridge.
  • nameMatchThreshold: threshold that controls the outcome of the name matcher score and name match and mismatch decision.
  • dobMatchThreshold: threshold that controls the outcome of the date of birth (DOB) matcher and DOB match and mismatch decision.
  • filter_datastore_name: Data Store that contains alert filtering rules and adjudicates only alerts that match the defined rules. If not defined, all data goes through the model.
  • generate_report: option that generates HTML reports and stores them on the MinIO server.
  • enableSanctionPrograms: option that enables the usage of sanction programs; turned on by default with one prebuilt program.

The Data Stores used in the Transaction Screening processes are as follows:

Data StoreDescription
pss_request_processing_v1Stores all requests, processing updates, and decisions.
pss_payment_transfer_filtering_rules_v1Contains filtering rules, if any. Empty by default.
pss_alerts_analytics_v1Contains per alert analytics.
pss_messages_analytics_v1Contains per message analytics.
pss_fuf_tags_list_v1Contains FUF tags versus type data dictionary. Used when parsing FUF messages.
pss_iso20022_tags_list_v1Contains ISO20022 tags versus type data dictionary. Used when parsing ISO20022 messages.
pss_swift_tags_list_v1Contains SWIFT tags versus type data dictionary. Used when parsing SWIFT messages.
pss_opencorporates_search_result_v1Contains results from calling the Open Corporates service.
pss_de_analytics_v1Contains analytics of data enrichment service calls for Open Corporates and Geocoder.
pss_dr_file_analytics_data_v1Contains statistics of Decision Reapplication historical data upload.
pss_request_processing_test_4000 (and similar test Data Stores)Contains synthetic data generated for testing.

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

    The default settings are as follows:

    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

    A selected type corresponds to the entity on the screened side. This type can come as an input; otherwise, it is predicted by the NER model. If no screened type is available, a sanctioned type is used.

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

Message type (msgtype)Attribute name (attrname)Entity name (entityname)Type (type)Description (description)
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