About Enigma Screen

Background

Transaction screening solutions generate alerts identifying potential matches (hits) between entities identified within a transaction, and watchlist or sanctioned entities. Alerts with one or more hits are typically forwarded to an analyst for investigation.

False positive hits are potential matches with that, upon review, are determined to be unrelated. False positives take significant time to review, and the burden of reviewing many false positives makes it hard for analysts to thoroughly investigate hits that warrant more attention.

Enigma Screen filters out false positive hits generated by your transaction screening solution. It does this by running all hits through our match models and determining whether the listed entities match known watchlist or sanctioned entities in our databases. For each alert, Enigma Screen returns a positive/negative decision to your alert database.

Requirements specification

Enigma Screen uses decision models tuned to customer-defined performance requirements. Enigma works with you to define these requirements, but they typically include:

  • Render a decision for every alert.
  • Do not screen out any true positive hits.
  • Screen out at least x% of false positive hits.
  • Deliver a decision on each hit within x minutes.

Model development and deployment

The screening model aims to predict the “alert decision” made by an analyst during a review of alerts produced by your screener – in other words, to predict if an analyst will determine that an alert warrants investigation. All other decisions indicate that the alert does not warrant investigation and is a false positive that should be screened out:

  • At the hit level, models output a predicted probability (0-1) that the hit is either a true positive or false positive. These decimal values are thresholded based on a desired level of confidence in the answer. The level of confidence is a measure of the extent of achievable false positive reduction as compared to the risk of missing a true positive.The default confidence value optimizes for high recall of true positives.
  • At the alert level, models output a binary decision indicating if an alert can be screened out as a false positive. If all hits in a given alert are filtered out, the alert is labeled as a false positive.

Since models are a function of customer-specific requirements, as well as the transaction screener being used, model development and deployment is a multi-stage process:

  1. Enigma builds experimental models trained on historical alert data from your transaction screener. The alert data includes the decision for each hit. Enigma obtains the watchlist data associated with each hit from the screener’s output, not the watchlist provider, since the provider’s watchlist updates frequently.
  2. Enigma deploys a preliminary screening solution using the selected model, and runs it against an x-month sample.
  3. Enigma tunes the model based on your decision criteria, and tests it using x months of out-of-sample hit data.
  4. When performance consistently matches the customer-specific performance criteria, Enigma deploys the production Screen solution, along with full model documentation, for QA testing by your internal risk management team.

Performance benchmarking

Performance is measured primarily as a function of the number of false positive hits filtered out without filtering out any hits that warrant escalation.

Additional performance metrics are based upon:

  • Periodic sensitivity testing, during which Enigma Screen’s models are tested against your expected behavior dataset
  • Model speed tests to determine compliance with the performance SLAs