Install and configure

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 a private cloud hosted by WorkFusion

Hardware

note

The requirements are for the on-prem installation type.

The servers must conform to the following standards:

Server	Recommended OS	CPU (Cores)	RAM (GB)	HDD (GB)
Master	RHEL/CentOS 8.10	8	32	750
BEP Agent	RHEL/CentOS 8.10	8	32	150
Superset Analytics	RHEL/CentOS 8.5	2	4	50
MS SQL	Microsoft Windows Server 2019	4	16	500

For the architecture deployment, refer to Install AI Agents | View architecture deployment.

Software

• Work.AI v10.2.8 or 10.2.9
• 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.

Testing results on Tara v3.1.13

Configuration:

Environment topology	Tested platform version	Number of RPA Bots	Number of OCR Workers	Machine Learning (ML) Worker configuration	Control Tower Worker configuration
3 BEP Agents	10.2.9.1	5	7	1 CPU / 4 GB memory	0.4 CPU / 2 GB memory

Results:

Number of Agents	Number of alerts	Processing time
3	20,000	1 hr 1 min

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. Input
2. Model
3. Data enrichment
4. Reapplication data
5. Output

Use the Next or Back buttons to navigate between configuration screens. Click Finish to save the changes.

Input

In the Input section, specify the way to supply data to your BP.

1. Choose one of the following options:

   • WorkFusion API
   • Upload CSV file
   • Data from Connector

2. In the Maximum hits field, define the maximum number of hits per alert. Alerts exceeding this threshold will not be resolved.

   

Model

In the Model section, configure the model settings:

1. In the Decision model drop-down list, select a compatible model. If none is selected, the default (latest) one is used.

2. In the Trained NER model drop-down list, select a Named Entity Recognition (NER) model. If none is selected, the default (latest) one is used.

3. In the Custom rules file (optional) field, provide a unique name for the custom rule file located in a designated directory to prevent overwriting during updates. When configured, the file is used instead of the default rules. You can have multiple versions of the custom rule file.

   info

   The default rule file is stored in a versioned directory, such as doc-upload/payment_sanctions_screening/{$version}/rules/rules_v1.drl. Modifying the default file is not recommended.

4. In the Matching thresholds section, 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.

   Scores closer to 0 indicate less similarity, while scores closer to 1.00 indicate more similarity. Below the threshold, names are considered different, resulting in a mismatch. Above the threshold, names are considered similar and referred to as a match.

   The default value is 0.75. For example, a name with a predicted match score of 0.75 or higher is considered matching or partially matching.

   note

   Increasing the threshold value might reduce name matches, potentially increasing the automation and error rates.

5. In the Token overlap configuration drop-down list, select one of the following options:

   • None (default) does not apply specific token overlap criteria, resulting in the final name score determined by other matching methods or defaults.

   • Rare boosts the name score for rare or unique token overlaps, favoring matches where unique identifiers are critical. For example, "SBERBANK ZRT" versus "CORPORATE UNIVERSITY OF SBER BANK" results in a name match if selected.

   • Screened prioritizes matches where the screened name is contained within the watchlist entity (WLE) name. For example, "Doors LLC" versus "Wood Doors Installation Services LLC" results in a match if selected.

6. Select Use external name matching service (Babel) to enable the Babel street name matcher that overrides the default name matcher score.

   • In the Service Endpoint Link field, specify the REST endpoint for the external service.

   • In the External Name Matcher Threshold field, set a number between 0 and 1 for invoking the external service. For example, if the default matcher's score is between 0.75 and 0.95, the external service is used. Scores from the external service will override the default matcher if lower.

   warning

   Setting the external name matcher threshold to 1.0 is not recommended.

7. In the Date of birth matching field, enter a value between 0 and 9999. Dates within this range are considered matching.

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

8. In the ID matching section, select ID prefix match to match IDs with the same prefix. For example, "NL0123456789" matches "NL0123456".

9. In the Address matching section, select an option to compare addresses.

   • String Comparator (default) compares two addresses. If all tokens match, the addresses are considered a match. The method is executed first regardless of the chosen option. If two addresses are identical, there is no need to use additional services.

   • Google geocoder compares all available addresses from the screened and sanctioned data by sending them to the Google geocoder for validation. If an address exists, the geocoder returns a placeId value. If the placeId values match, the addresses are considered a match.

     

     To enable the geocoder functionality for address matching, you must select the Google Web Services option in the Data enrichment tab. In case of failure or if no result is returned from the call, String comparator is used.

   • External address matcher service is an in-house product that uses the Nominatim API to compare addresses. The service returns a structured response, for example, {"house_number_match": true,"road_match": true,"city_match": true,"state_match": false,"country_match": true,"postal_code_match": false}. If the house number, road, city, and country all match, the addresses are considered a match.

     

     The service is installed separately from Tara and must be running to accept calls.

     In the External address service endpoint field, set the service endpoint. In case of failure or if no result is returned from the call, String comparator is used.

10. In the Country from IDs section, the Extract country codes from IDs for Location Matching option is selected by default for Tara to extract country codes from known ID types. For example, in IT26S0306933090100000003191, IT is extracted for Italy. To disable the feature, deselect the option.

11. In the Blacklisted entities section, configure specific blacklisted entities for Tara to automatically escalate hits if such entities are detected. Otherwise, select No for Do you wish to provide blacklist configurations?.

    • In the Blacklisted keywords field, enter keywords that should trigger a blacklist-based search.

      • Select where to search for blacklisted entities to trigger an escalation: Tag content or Entity name.

    • In the Blacklisted countries field, the countries considered blacklisted. By default, the following countries are included in the blacklist: Iran, Cuba, Syria, North Korea, and Russia.

      • Select where to search for blacklisted country names: Tag content, Entity name, or None. Tara automatically escalates if a blacklisted country from the provided list appears in a hit.
    note

    You can manually add more blacklisted entities. Mind that the fewer entries are blacklisted, the higher the automation rate is.

Data enrichment

In Data enrichment > Address verifier, specify external data sources to retrieve additional data. Select Google Web Services and provide a valid access token:

1. In the Google Maps API Key field, enter your Google Maps API key for address verification. For more details on getting a key for a Google Cloud account, see Using the Google Maps Platform.

   

2. In the Secrets Vault Alias field, provide the alias that identifies your secure entry.

   

Reapplication data

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

When enabled, configure the following settings:

1. Add message tags.

   1. In the Message Format drop-down list, specify the message type to target for decision reapplication. Supported formats include FUF, SWIFT_MT, ISO20022(SWIFT_MX), and SWIFT_NPP.

   2. In the Tags field (optional), enter tag names from an alert as comma-separated values. The tags are compared against historical data together with hashed hit content. TYPE is recommended.

   To add additional message types, click Add another.

   If message types are added, they are used in decision reapplication. If the configuration changes, you must reload historical alerts for the changes to take effect.

2. Select the Decision Level option. Specify the level at which the decision reapplication will be applied:

   • Hit Level resolves individual hits that match historical decisions.
   • Message Level resolves the entire message if all hits match historical decisions.

3. In the Minimum event counter field, specify the minimum occurence of the same hash found in historical data. The condition must be satisfied before applying a CLDS decision.

4. In the Minimum analysts counter field, define the minimum number of analysts who made decisions on the same alert found in historical data. The condition must also be met before applying a CLDS decision.

5. In the Search timeframe (in days) field, specify the maximum number of past days to search for historical data. Older decisions will not be considered for reapplication. If the field is left blank, the default value of 365 days is applied. The field is only used during historical uploads.

6. Select Require tag content match for decision reapplication to enforce strict tag content matching for decision reapplication. Enabling this option reduces reapplication rates.

7. Select Require Message sub-type for decision reapplication to treat tag content as part of the hash for successful decision reapplication. Enabling this option also reduces reapplication rates. If the configuration changes, you must reload historical alerts for the changes to take effect.

8. Set historical decision types to be treated as resolved by an analyst. Specify decision codes from historical files to mark alerts as RESOLVE (released) during historical data uploads. If the value is modified, reload historical alerts for the changes to apply.

9. Set analyst or operator names to be excluded from continuous learning decision calculations. The specified names are excluded from the analyst count when determining whether a hit is suitable for reapplication. If the values change, you do not need to reload historical data. The setting does not affect hashes that are already enabled.

For more details on the feature, see Business Process overview | Ingest Historical Decisions for Reapplication Business Process and Apply continuous learning.

Output

In the Output section, enable generating HTML, quality control (QC), or CLDS reports after a BP run.

1. In the S3 bucket name field, specify a custom S3 bucket to securely store reports and historical data. The option also restricts access to the specified bucket.

2. To enable generating HTML reports, select Yes for Do you want to generate HTML report?.

   

   1. Do you want to generate a single page combined HTML report?. Select Yes to generate a single report file for all sanctioned hits. Otherwise, select No to generate separate files for each sanctions hit.

   For more details on how to find a generated report, see Run screening | View results.

3. To enable generating QC reports, select Yes for Do you want Quality control report to be generated?. A QC report provides a snapshot of all the data fields of messages and their corresponding hits in the CSV format. If enabled, you can run the PSS QC report BP manually or on schedule.

   

   1. Do you want to generate the report with standard columns?. Select Yes to generate a report using standard columns provided in the file in S3, for example, doc-upload/payment_sanctions_screening/reports/templates/qc_report_template.csv. For reference, see the sample template: qc_report_template.csv.

      If you select No, upload a custom qc_report_template_custom.csv file to the same S3 location as above. In the file, you can use a truncated version of the original template file, selecting the columns required for your reporting purposes.

      

   2. Choose the time range or business process execution ID for data collection. Select one of the following options:

      • Today. Collect data from 12 AM to the current time.

      • Last x days. Specify a range that includes the current date. In the Number of passed days field, enter a value between 1 and 31.

      • Last x months. Specify a range that includes the current date. In the Number of passed months field, enter a value between 1 and 12.

      • Custom. In the From and To calendar widgets, define a date range.

      • Business process execution IDs. In the UUIDs field, enter one or more BP run UUIDS to limit results to specific executions.

   3. In the Maximum file size (MB) field, set the maximum file size (up to 100 MB). If exceeded, multiple files are created.

4. To enable generating CLDS reports, select Yes for Do you want CLDS report to be generated?.

   

   1. Choose the time range or business process execution ID for data collection. Select one of the following options:

      • Today. Collect data from 12 AM to the current time.

      • Last x days. Specify a range that includes the current date. In the Number of passed days field, enter a value between 1 and 31.

      • Last x months. Specify a range that includes the current date. In the Number of passed months field, enter a value between 1 and 12.

      • Custom. In the From and To calendar widgets, define a date range.

      • Business process execution IDs. In the UUIDs field, enter one or more BP run UUIDS to limit results to specific executions.

   2. In the Maximum file size (MB) field, set the maximum file size (up to 100 MB). If exceeded, multiple files are created.

   For more details on CLDS reports, refer to Apply continuous learning | View CLDS report.

Customize configuration settings

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

Sample configuration.json

{
  "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",
    "maximumHits": 100
  },
  "model": {
    "model_id": "",
    "ner_model_id": "",
    "go_forward_on_failure": "false",
    "default_model_Id": "pss-classification-model-v4.3.4",
    "default_ner_model_Id": "named-entity-recognition-1.6.16",
    "nameMatchThreshold": 0.75,
    "dobMatchThreshold": 365,
    "matchIfRareTokenOverlap": "none",
    "idPrefixMatch": false,
    "extractCountryFromId": true
  },
  "useExternalNameMatchingServiceBabel": false,
  "configureForEachTypes": false,
  "qcReport": {
    "StandardColumns": "yes",
    "searchBy": "TODAY",
    "splitReportBy": "SIZE",
    "maxVolume": 50
  },
  "output": {
    "generate_report": false,
    "onePageReport": false
  },
  "decisionReapplication": {
    "isEnabled": false,
    "tagsToCompare": "",
    "numDaysToLookBack": "365",
    "level": "hit",
    "matchTagContent": false,
    "resolveType": "Released",
    "setupDataGrid": [
      {
        "drMessageType": "swift_mt",
        "tagsToCompare": "TYPE"
      },
      {
        "drMessageType": "fuf",
        "tagsToCompare": "TYPE"
      },
      {
        "drMessageType": "swift_mx",
        "tagsToCompare": "TYPE"
      },
      {
        "drMessageType": "swift_npp",
        "tagsToCompare": "TYPE"
      }
    ]
  },
  "container": {}
}

Default configuration parameters

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

The default configuration parameters are listed below.

Input parameters

• message_datastore_name contains processing data, including new and updated messages during BP execution.
• ml_thresholds_datastore_name contains the mapping of decision codes, such as definitions, confidence thresholds, and decisions.
• fuf_tag_datastore_name contains the FUF dictionary of entity attributes and their associated types.
• swift_tag_datastore_name contains the SWIFT dictionary of entity attributes and their associated types.
• iso20022_tag_datastore_name contains the ISO20022 dictionary of entity attributes and their associated types.
• maximumHits refers to the maximum number of hits per alert. Alerts exceeding this limit are auto-dispositioned as no decision.

Model parameters

• model_id is the ML model for processing input data to determine possible false positive hits. If not provided, the default_model_Id value is used.
• ner_model_id is the NER ML model for processing input data to determine possible entity types. If not provided, the default_ner_model_Id value is used.
• go_forward_on_failure is required to run AutoML Bridge.
• default_model_Id is the model version that comes with the bundle during the release.
• default_ner_model_Id is the model version that comes with the bundle during the release.
• nameMatchThreshold controls the outcome of the name matcher score and name match and mismatch decision.
• dobMatchThreshold controls the outcome of the date of birth (DOB) matcher and DOB match and mismatch decision.
• filter_datastore_name contains alert filtering rules and adjudicates only alerts that match the defined rules. If not defined, all data is processed by the model.
• useExternalNameMatchingServiceBabel enables the Babel name matcher for cross-verification of name matcher results, when set to true.
• matchIfRareTokenOverlap influences the name matcher score calculation. The default value is none. When set to true, a hit on a rare token increases the score, lowering the error and automation rates.
• idPrefixMatch influences the ID matching logic based on prefix similarity. The default value is none.
• extractCountryFromId extracts country data from IDs for location matching. The default value is true.

HTML report output parameters

• generate_report generates HTML reports stored on the MinIO server. The default value is false.
• onePageReport determines whether reports should be single-page or multi-page.

QC report parameters

• StandardColumns uses the default report template. The default value is yes. Otherwise, provide a custom file.
• searchBy specifies the search scope. The default value is TODAY.
• splitReportBy limits the report size. The maximum file size value (maxVolume) is 50 MB.

CLDS parameters

• isEnabled enables the data reapplication functionality, when set to true.
• drMessageType and tagsToCompare target specific message types and tags to be included in the CLDS processing. The supported formats are SWIFT_MT, SWIFT_MX, SWIFT_NPP, and FUF.
• numDaysToLookBack defines the range to search historical data for matching records. The default values is 365 days.
• level specifies a decision reapplication level. The default value is hit.
• matchTagContent determines if content must match between tags. The default value is false.
• resolveType sets a historical decision type that should be treated as resolved. The default value is Released.

Data Stores

All Data Stores used in the Transaction Screening processes are built during the bundle import stage. Their names cannot be changed.

Data Store	Description
pss_request_processing_v1	The main Data Store that stores all requests, processing updates, and decisions.
pss_payment_transfer_filtering_rules_v1	Contains filtering rules, if any. Empty by default.
pss_alerts_analytics_v1	Contains per alert analytics.
pss_messages_analytics_v1	Contains per message analytics.
pss_fuf_tags_list_v1	Contains FUF tags versus type data dictionary. Used when parsing FUF messages.
pss_iso20022_tags_list_v1	Contains ISO20022 tags versus type data dictionary. Used when parsing ISO20022 messages.
pss_swift_tags_list_v1	Contains SWIFT tags versus type data dictionary. Used when parsing SWIFT messages.
pss_de_analytics_v1	Contains analytics of data enrichment service calls for Open Corporates and Geocoder.
pss_reapplication_hashcodes_v1	Contains historical data for decision reapplication on the hit level.
pss_dr_file_analytics_data_v1	Contains analytics of loading CLDS historical data.
pss_clds_hash_analytics_v1	Contains summary information about each hit hash of historical data.
pss_request_processing_test_v20_4000 and similar test files	Contains synthetic data generated for testing.

Also, see

• View analytics Data Stores
• View CLDS Data Stores
• Input and output data | Request Data Store

Dictionaries

The pss_swift_tags_list_v1, pss_fuf_tags_list_v1, and pss_iso20022_tags_list_v1 dictionaries are used for assigning TagType and parsing tagContent. A dictionary has limited entries, so the tagType value is usually FREETEXT. You can update a dictionary and add a particular field parser if needed. Currently, treat it as a framework with limited functionality. If any tag is empty, it cannot have a hit on its value. Thus, empty tagContent is considered as invalid input.

• If the Type tag is FREETEXT, the tag content is passed to the NER model. NER marks each token with a predicted type (IND, ORG, LOC, OTHER). Then, a predicted name is calculated based on a provided hit text or sanctioned name.

• If the Type tag is NAME, the model treats the tag content as an entity name.

• If the Type tag is NAMEADDRESS of ADDRESS, the model finds an address and parses it to determine a country.

Create test dataset

To add a test dataset to your model, complete the following steps:

1. Go to AutoML > Datasets and create a test dataset. Memorize its name as you need it in further steps. For instructions, refer to the Manage datasets topic.

   

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 Testing tab, select the dataset from step 1.

   

6. Click Start to build a new model.

7. Go to AutoML > Models. The model appears in the list, and you can choose it during the AI Agent configuration.

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 described in the guide.

   

   Follow the instructions below to build a proper rule logic. See sample rules for reference.

Apply filter support tool

The filter support tool is implemented for support purposes. The primary functionality of the tool is to enable the insertion of custom rules to either include or exclude hits in a message based on the presence of keywords or text within a field in the hit:

• INCLUDE: the alert hit will be processed by Tara and might be resolved as false positive.

• EXCLUDE: the alert hit will not be processed by Tara, and the ML model decision will always be escalate or no decision for the hit.

The rules are inserted into a dedicated Data Store in Control Tower.

The rule_type column has only two values: INCLUDE or EXCLUDE.

• The first rule (shown in red) enforces the inclusion of all hits where the hit_sanctiondata_type field is INDIVIDUAL and hit_additional_data_name field is not empty. Here, NOT_EMPTY is a keyword supported by the rule logic.

• The second rule (shown in green) similarly enforces the inclusion of all hits where the sanction data type is ORGANIZATION and the hit_additional_data_name field is not empty.

• The third rule (shown in purple) is an example of an EXCLUDE rule that enforces to exclude all hits where hit_screendata_type is ORGANIZATION, and the screened data name contains the words bozo or bad. The allowed_values column supports regular expressions, allowing you to match the text in a column name (data field) to be included or excluded.

If any rule is triggered by a hit in a message, that hit is either included or excluded based on the rule type. Additionally, the exclusion rules take precedence over inclusion ones. As shown in the example above, if rule4 is triggered by a hit, it overrides rule2 and filters out the hit.

The Data Store columns are as follows:

• system_id: auto-generated.

• allowed_values: any regular expressions, text, or specific keywords (EMPTY or NOT_EMPTY).

• rule_name: the name of the rule. Rows that are part of the same rule must have the same rule name. These conditions are treated as logical AND.

• column_name: the name of the column (data field) that the rule is enforced on. The column name can be one of the columns in the input data or GLOBAL if the rule applies to all columns.

See the list of valid column names

• type
• content
• contentformat
• accountholder_name
• accountholder_type
• hit_tagcontent
• hit_tagname
• hit_tagtype
• hit_hitstartindex
• hit_hitendindex
• hit_hittext
• hit_screeneddata_type
• hit_screeneddata_name
• hit_screeneddata_dob
• hit_screeneddata_address
• hit_screeneddata_country
• hit_screeneddata_city
• hit_screeneddata_state
• hit_screeneddata_postal
• hit_screeneddata_id
• hit_additionaldata_type
• hit_additionaldata_name
• hit_additionaldata_dob
• hit_additionaldata_address
• hit_additionaldata_country
• hit_additionaldata_city
• hit_additionaldata_state
• hit_additionaldata_postal
• hit_additionaldata_id
• hit_sanctiondata_name
• hit_sanctiondata_primaryname
• hit_sanctiondata_type
• hit_sanctiondata_dob
• hit_sanctiondata_city
• hit_sanctiondata_country
• hit_sanctiondata_state
• hit_sanctiondata_sourceentryid
• hit_sanctiondata_source
• hit_sanctiondata_listtype
• hit_sanctiondata_additionalinfo
• hit_sanctiondata_alsoknownas_name
• hit_sanctiondata_alsoknownas_type
• hit_sanctiondata_address
• hit_sanctiondata_postal

• rule_type: can have two values (INCLUDE or EXCLUDE). Each rule type with the same name forms a group of rules. If rule_type has a different name, it forms a separate group of rules. Within a specific group of rules, each line is treated as logical AND. Across different groups of rules, logical OR is applied.

  When a conflict occurs between INCLUDE and EXCLUDE, EXCLUDE always takes precedence.

• custom_narrative: custom text appended to the end of the decision narrative. If a hit is filtered out by an exclusion rule, its custom narrative (if any) is added to the alert analytics as an explanation.

View sample rules

Description	rule_name	column_name	allowed_values	rule_type	Notes
Filter out individual names with the al- token in them.	rule_remove_al_token	hit_screeneddata_name	\s+al-	EXCLUDE	(PASSED) Assuming "al-" is a token by itself, "mal-nutrition" will not be tagged but "Jabbar -al lam" will.
	rule_remove_al_token	hit_screeneddata_type	INDIVIDUAL	EXCLUDE
Filter out cases where names start with the Mrs. salutation.	rule_no_salutations	hit_screeneddata_name	^Mrs	EXCLUDE	(PASSED) For example, for names beginning with Mrs.
	rule_no_salutations	hit_screeneddata_type	INDIVIDUAL	EXCLUDE
Filter out websites containing @.	rule_no_websites_with_at_symbol	hit_additionaldata_name	www.	EXCLUDE	(PASSED) Assuming that www. can be used to figure out there is a website in the name, filter out if the @ symbol is found.
	rule_no_websites_with_at_symbol	hit_additional_name	@	EXCLUDE
	rule_no_websites_with_at_symbol	hit_additionaldata_type	COMPANY	EXCLUDE
Filter out individual or company names containing "-".	rule_no_dashes_in_names	hit_screeneddata_name	"-"	EXCLUDE	(PASSED)
	rule_no_dashes_in_names	hit_screeneddata_type	COMPANY or INDIVDUAL	EXCLUDE
Escalate everything.	rule_escalate_everything_a	hit_screeneddata_name	EMPTY	INCLUDE	(PASSED)
	rule_escalate_everything_a	hit_screeneddata_name	NOT_EMPTY	INCLUDE
	another_escalate	hit_tagcontent	EMPTY	INCLUDE	(PASSED)
Filter out SS type individual.	rule_no_ss_individual	hit_additionaldata_type	INDIVIDUAL	EXCLUDE	(PASSED)
Filter out all SS data.	rule_no_ss_data	hit_additionaldata_name	EMPTY	INCLUDE	(PASSED) EMPTY and NOT_EMPTY rules work with the INCLUDE rules only.
Filter out hits containing * in the primary name field.	rule_asterisks_in_primary_name	hit_sanctiondata_primaryname	*	EXCLUDE	Hits with primary names containing * are automatically escalated or no decision. A custom narrative is appended to the decision narrative.