Skip to Content
DataMatching on PEPs and Sanctions

PEP and Sanctions Screening in Strise (v.3)

This article outlines how Strise performs screening for PEP (Politically Exposed Person) and Sanctions. The article also highlights how the screening can be modified through settings, how and when alerts are sent and key improvements implemented in v.3 — done in Q4 2025.


1. How Screening Works

Both processes for screening PEPs and Sanctions follow a similar flow:

  1. Preprocessing: This involves cleaning data by removing accents, titles, company legal form abbreviations, etc.
  2. Search: A name search is conducted against PEP and Sanction lists to find relevant hits.
  3. Filtering: Results are filtered based on user settings, such as PEP/RCA status expiry, similarity thresholds, and excluded sources.
  4. Scoring: A weighted arithmetic mean is calculated based on a set of configurable fields and the hits are marked as suggested false or suggested true.
  5. User Verification: Users can verify the results from the step above.

1.1 Preprocessing

This step normalises the name and aliases, ensuring that minor variations in spelling, accents, or special characters do not prevent us from identifying a potential match against the screening lists.

WhatApplies toExample inputExample output
Accents from characters are removedBothAdelaideAdelaide
Dash-separated parts are split into distinct termsBothJohn-DoeJohn Doe
Other non-alphanumeric characters are removed and joined into a single termBothJohn.DoeJohnDoe
Titles are removedPeopleMr. John DoeJohn Doe
Legal forms are removedCompaniesStrise ASStrise

The normalized names and aliases from the preprocessing step serve as a comprehensive search query. The PEP and Sanction lists searched against can be configured from settings.

A name is considered a match only if it satisfies both of the following conditions:

  1. Per-Term Match: Each individual word in the name must pass a specific similarity test.
  2. Overall Match: The name as a whole must meet a minimum similarity threshold.

The Per-Term Matching Rule

  • The 75% Rule: A term must have at least a 75% similarity to its corresponding term. We calculate this using Damerau-Levenshtein distance . This can be simplified as: “For every 4 characters in a term, 1 edit is permitted.”
  • Short Term Exception: For very short terms (2 or 3 characters), we allow 1 edit, even if this is below the 75% threshold.

Examples:

Name 1Name 2MatchComment
Jonas Anders JohanssonJonas Andreas JohanssonNoTotal similarity is 92% but per-term: 100%, 67%, 100%
Maria Amparo Moraleda MartinezCarain Amparo Moraleda MartinezNoTotal similarity 90% but per-term: 40%, 100%, 100%, 100%
Tomas AlvarezThomas AlvarezYesTotal similarity is 92% and per-term: 83%, 100%
Ava PrescottAna PrescottYesTotal similarity is 91% and per-term: 67%, 100%. Short term exception applies.

The Overall Match Rule

Handling Missing Names (Subset Logic)

  • The Rule: A match is permitted if one name is a complete subset of the other. For example, A C can match A B C (where B is a missing middle name). The order of the words is irrelevant.
  • The Restriction: The algorithm does not allow matches where terms are simply different. A B C will not match A B D.

Examples:

Name 1Name 2Match
Kim JohansenKim Andre JohansenYes
Andre JohansenKim Andre JohansenYes
James Edward WilliamWilliam JamesYes
James LewisJames William Edward LewisYes
Hans Bertil LansHans Bertil SahlinNo

The Overall Similarity Score

After aligning the names, we calculate a final similarity score for the entire set of matched terms. The combined set of matched terms must have an overall similarity equal to or greater than the specified similarity score set by the user.

1.3 Filtering

Results from the search are filtered out based on the defined settings. The available filtering options are:

  • The overall similarity score of the name
  • The retention duration of a PEP (how long the status is valid after a role has ended)

1.4 Scoring

Once a potential hit passes our initial name-matching filters, we calculate a final match score using a weighted arithmetic mean, expressed as a percentage from 0% to 100%.

Key aspects of the scoring:

  • Each weight is configurable in settings.
  • A component is ignored if the data point is missing from the Strise entity or the PEP or Sanction source.
  • A match on SSN from the Strise entity with the entity from the source will always override the match percentage to 100%.

See the documentation for more details:

1.5 User Verification

The user can verify each result as true or false. It will always be possible to see information about the changes, e.g. what user verified the hit, what status, at what time, etc. This log can also be downloaded as a .csv-file.

2. Settings

For both PEP and Sanction settings, it’s possible to affect the Search, Filtering and Scoring steps:

  • Search: Select which PEP and Sanction lists are screened against.
  • Filtering:
    • Minimum fuzzy name match — controls how similar a name must be to be flagged.
    • PEP/RCA retention period — how long a person remains a PEP after their role has ended.
  • Scoring:
    • Data field weighting — determines the relative importance of each data field.
    • Suggested true match — the threshold used to determine if a score is classified as suggested true or false.

3. Alerts

Alerts are sent when the following conditions are met:

  • The underlying data of the PEP or Sanction data is updated
  • The scoring has classified the hit as suggested true

Alerts are not sent in the following cases:

  • The status of a PEP or Sanction is verified, both through the app and API.
  • The data of the entity in Strise changes.

Other relevant points:

  • Alerts will be sent for previously verified hits, regardless if they are confirmed true or false, as long as they meet the above conditions.

4. Improvements done in this version

October-November 2025:

  • A previous hard limit on search results has been removed. These caps were set at 10 for PEP and 250 for Sanctions.
  • The new subset logic handles cases where any number of terms are missing from either name, and discards names that have completely different terms.
  • The “Per-Term Matching Rule” has been added as support for the new subset matching logic.

5. FAQ

Where do RCA family relations come from?

RCA (Relative or Close Associate) relations come directly from the PEP/RCA lists provided by our data providers (Trapets and Dow Jones). Strise does not independently determine or infer family relations.

How an incorrect entity match can occur

If a Strise entity matches a name on the list but lacks a date of birth for disambiguation, the match may link to the wrong person. The relation data from the source is correct; the issue is in entity resolution when birth dates are missing.

Summary

If you see an unexpected RCA relation, the relation type is sourced from the data provider and is likely accurate for the person on the list — but the Strise entity it has been matched to may not be the correct individual.

Do you have any other questions around this topic? Contact us at support@strise.ai.

Last updated on