Watchlist Policy Configuration

Creating watchlist policies

A policy in RiskOS™ defines the logic for when a potential watchlist hit occurs. You can configure policies 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 re-screens. It sets the criteria for when matches appear to your team for review.

Monitoring policy – Used for continuous checks after you accept a customer or entity. It sets the criteria for when the system surfaces matches 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, Socure separates policies 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 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's different.

Default policies

The default settings in Socure's Watchlist module 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, Socure provides them purely for your convenience, and you shouldn't consider them 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 so it’s clear where it applies (for example, 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, for example, “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. Socure observes statistical significance at 65, which is the recommended starting point for most customers.

Why it matters: This score reduces 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 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.

Handling a missing DOB

You can control how the DOB filter behaves when a date of birth is unavailable:

• Missing DOB on a matched entity — Enable the Include matches where match DOB is missing toggle to return matches even when the matched watchlist entity has no DOB on file. When the toggle is off, the DOB filter excludes matches that have no DOB to compare.
• Missing DOB in your input request — When your input request doesn't include a DOB, RiskOS™ returns matches by default so the DOB filter does not suppress potential hits.

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 (for example, 3+ years).
• Country filter — Limit matches to specific regions.

4.4 Adverse Media controls

• Historical range (recency window) — Limit how far back to include Adverse Media results (for example, the last 3 years).

Step 5 - Set entity types

You can specify what entity types you'd like to see in your match results to reduce false positive matches. The following entity types can be selected in your settings.

• Individual – A natural person (for example, consumer, beneficial owner, director, employee) being screened as an individual customer or party.
• Organization – A legal or juridical entity such as a company, nonprofit, financial institution, or government body being screened as a business/customer.
• Vessel – A ship or boat (for example, cargo vessel, tanker, commercial ship) being screened as the primary subject of maritime sanctions or enforcement lists.
• Aircraft – An airplane, jet, or helicopter being screened as the primary subject (common in export-control / transport-related watchlists).
• Others — Entities that are not explicitly classified as Individual, Organization, Vessel, or Aircraft in the originating source list.

When screening an entity, the system first checks if entity_type is present in your API request. If no entity_type is sent via API, the system refers to your dashboard settings.

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 you set and why
• How you adjusted them over time
• Evidence for decisions (metrics, sensitivity tests)

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

Updated 17 days ago