Creating Watchlist policies

A policy in RiskOS™ defines the logic for when a potential watchlist hit is returned. Policies can be configured separately for screening and monitoring, and each category (Sanctions, Enforcement, PEP, Adverse Media) can have one or more active screening policies and one or more active monitoring policies per environment.

Screening policy – Used for point-in-time checks such as onboarding or periodic rescreens. It sets the criteria for when matches are surfaced to your team for review.

Monitoring policy – Used for continuous checks after a customer or entity has been accepted. It sets the criteria for when matches are surfaced to your team for review.

📘
Note:
Policy changes apply to all future evaluations. They won’t retroactively change existing cases.

Matching policies to your risk tolerance

Socure allows you to configure policies as granularly as needed to match your risk tolerance and operational bandwidth.

By default, policies are separated into screening and monitoring. You can further segment policies by watchlist type, or even by specific list or source:

For example:

If you have a more conservative approach to Sanctions screening, you might create a dedicated policy for Sanctions. In that policy, you could set a lower Name Match or Entity Correlation Score threshold so you are alerted to more potential matches.
If you have a more moderate approach to PEP and adverse media screening, you might set a higher threshold for Name Match or Entity Correlation Score so that your team is only alerted for higher-risk cases.

You will repeat the configuration process twice—once for screening and once for monitoring. You can duplicate a screening policy to create a monitoring policy and adjust only what is different.

Default policies

The default settings in Socure's Watchlist module are carefully calibrated to balance screening accuracy with operational efficiency. They integrate industry best practices and feedback from our global customer base:

Precision: Ensures the system accurately identifies relevant entities while minimizing false positives. This reduces the number of irrelevant matches flagged.
Recall: Focuses on capturing as many relevant matches as possible, even if it means flagging additional items for review. This helps ensure potentially important entities are not overlooked.

These default settings provide a configuration that reflects industry standards, supporting effective and efficient watchlist monitoring. However, they are provided purely for your convenience and should not be considered legal advice. Always confirm configurations with your compliance team.

Step 1 - Create a new policy

Go to Product Settings → Global Watchlist in RiskOS™.
Choose the environment (Sandbox for testing, Production for live traffic).
Click Edit to open the configuration panel.
Under Search Policies, click Add Policy.
Name the policy clearly so it’s obvious where it applies (e.g., Sanctions_Onboarding or PEP_Monitoring).

Step 2 - Select watchlists and sources

Segment policies by selecting different watchlists or types. For example, you might create one policy with a lower Name and Entity Match Score threshold for Sanctions regimes, and another with a higher threshold for PEP or Adverse Media.

Step 3 - Set score threshold settings

Threshold settings control how RiskOS™ decides if two records (your customer’s details and a list entry) are “close enough” to be considered a match. These use two machine learning model scores: the Name Match Score and the Entity Correlation Score.

3.1 Name Match Score

Names are rarely consistent. Different alphabets, nicknames, initials, and typos can all cause variation. Socure uses a Name Match Score to quantify how likely it is that the input name matches a watchlist entity. Scores range from 0–100, where:

90–100: Extremely strong match
75–90: Strong match with minor spelling or formatting differences
50–75: Moderate match with noticeable differences
30–50: Weak match with significant discrepancies
1–30: Very weak match with numerous differences

The score is calculated using:

Exact matching
Fuzzy matching (spelling or formatting differences)
Phonetic matching (how names sound)
Rule-based matching (explicit criteria, e.g., “names match and DOB within range”)
Machine learning–based matching (LSTM models across languages and scripts)

Default Name Match Score threshold: 70 — based on the optimal average starting point for most customers.

Why it matters: A single score expresses how confident the system is that two names refer to the same person or entity. Too low a threshold creates false positives, while too high a threshold risks false negatives—especially critical for PEPs and Sanctions.

3.2 Entity Correlation Score

The Entity Correlation Score (0–100) indicates how likely it is that your customer and the list entity are the same person or business. It factors in multiple identifiers such as name, DOB, and country.

Start open: Set to ≥0 during initial testing to capture all matches.
After calibration: Raise thresholds (typically 60–70+) to reduce noise.

Default Entity Correlation Score threshold: 0. Statistical significance is observed at 65, which we recommend as a starting point for most customers.

Why it matters: This score has been shown to reduce false positives by up to 78%, making it a powerful tuning tool.

Step 4 - Set false positive reduction filters

You can configure Watchlist to reduce false positives using:

DOB match criteria
Suppress PEPs without live URLs
Inactive PEP filter
PEP country filter
Adverse Media date filter

4.1 All / Any condition

Choose whether:

ALL conditions must be met to trigger an alert, or
ANY single condition being met can trigger an alert

4.2 Date of Birth (DOB) matching

DOB matching helps distinguish between individuals with the same name. RiskOS™ supports Exact, ±1 year, and 2-digit transposition options.

Default DOB match setting: Exact YYYY.

See the table of tolerance options for details.

4.3 PEP policy controls

Suppress PEPs without URLs — Hide records without supporting source URLs.
Exclude inactive PEPs — Filter out PEPs inactive beyond a threshold (e.g., 3+ years).
Country filter — Limit matches to specific regions.

4.4 Adverse Media controls

Historical range (recency window) — Limit how far back Adverse Media results are included (e.g., last 3 years).

Step 5 - Set entity types

Specify what kind of subject you’re screening — individual, organization, vessel, aircraft, etc. Entity type can be set in RiskOS™ settings or in each Evaluation API request.

Providing entity type improves accuracy and reduces false positives.

Guidance on setting and maintaining Watchlist policies

📘
Note:
This information is for general guidance only and is not legal advice. Always consult your compliance team and review internal policies before making changes.

1. Regulatory requirements and list types

Sanctions: Zero false negatives expected. Thresholds should be broad.
PEPs: Risk-based approach. Balance sensitivity and volume.
Adverse Media: Focus on reputational risk. Use higher thresholds to reduce noise.
Custom lists: Tune thresholds based on business needs.

2. Business context and use case

Screening (onboarding): Broader thresholds to avoid misses.
Monitoring (ongoing): Tighter thresholds to reduce noise.
Geography matters — enable or disable lists by region.

3. Data quality

Names only: Use lower thresholds, fuzzier settings.
Names + identifiers: Use higher thresholds and exact matches.

4. List size and alert volume

Large lists (Adverse Media): Require stricter thresholds.
Small, high-risk lists (Sanctions): Lower thresholds are acceptable.

5. Operational workload

Balance thresholds to avoid analyst fatigue or missed matches. Track:

True positive rate
False positive rate
Handling time
Analyst workload

6. Auditability

Document:

Which policies are set and why
How they were adjusted over time
Evidence for decisions (metrics, sensitivity tests)

📘
Takeaway:
Policies are not “set and forget.” Tune them based on regulation, business context, data quality, list size, and workload. Always document your changes.