FAQs

In practice, many organizations tune screening and monitoring differently to balance risk management with operational efficiency.

Different settings for different lists

• Sanctions (e.g., OFAC): Screening often uses looser parameters due to high regulatory scrutiny and the serious consequences of missing a true match.
• PEP and Adverse Media: Screening can use tighter parameters because these lists are larger and context-dependent. Stricter settings help manage volume and align with risk-based handling.

Different list priorities for screening vs. monitoring

• Screening: At onboarding, companies often sweep broadly across OFAC, PEP, and Adverse Media.
• Monitoring: Ongoing monitoring typically focuses on OFAC and PEP, since they update frequently and carry higher regulatory consequences.
• Adverse Media: Often rescreened periodically or targeted to high-risk segments.

👉 The goal: keep screening broad enough to avoid missing risk at entry, while keeping monitoring focused to reduce noise and alert fatigue.

• Screening: A point-in-time check (onboarding, rescreening) to block risky users before access.
• Monitoring: Ongoing checks for existing customers as lists update (new additions, updates, or removals).

Other systems expose fuzziness tolerance as a tuning parameter. RiskOS™ uses a Name Match Score that incorporates algorithms and ML techniques.

• Fuzziness is inversely proportional to the Name Match Score: higher fuzziness → lower score.
• Example thresholds: strict tolerance = only scores above 80; loose tolerance = allow scores as low as 50.

Match Type and Thresholds

• Minimum: a plausible full name (given/family or entity name).
• Additional inputs (DOB, national ID, address) reduce false positives.
• Invalid placeholders (TEST, N/A, 12345) may cause errors.
• API rejects mismatched entity types or invalid field combinations.

• Supported types: individuals, organizations, vessels, aircraft, others.
• Can be set in the dashboard or in each API request.
• If omitted → defaults to OTHER, broadening results and possibly increasing false positives.

• Surname is required for Watchlist Plus and Premier modules for individuals.
• Missing surname may cause invalid request errors.
• For organizations: use entity_name and entity_type.

OFAC administers many targeted sanctions, not only comprehensive ones.

R640 may be triggered for sectors like:

• Defense and surveillance tech
• Human rights violations in Xinjiang
• Illicit oil trade with Iran
• Individuals/entities linked to fentanyl trafficking

This means the entity is no longer active in the source list.

• The entity may have been removed or no longer meets criteria.
• Verify whether the entity exists in the list. If not, suppression is unnecessary.

👉 Best practice: check entity status before suppression.

• Common cause: a very common name producing an oversized candidate pool.
• Usually resolved by processing optimizations.
• If persistent, contact support.

Possible causes:

• Navigating to invalid page numbers
• Disabled or misconfigured roles
• UI bugs (e.g., NaN pagination)
• Case review workflow not configured

Try toggling between 1-step and 2-step workflows.

• Policy changes only apply to new evaluations created after publishing.
• Cases created before the change reflect old rules.
• Verify timestamps vs. policy change logs.

• Standard: ~50–60 core sanctions/enforcement lists (OFAC, UN, EU, UK, OIG, HIDTA).
• Plus: Adds 1,400+ global lists and 10,000+ PEP records.
• Premier: Adds 10M+ adverse media articles, 40+ extra lists, SOE data, and wider language coverage.

• Socure aggregates aliases (AKAs) via entity resolution.
• All AKAs linked to a resolved entity are surfaced, regardless of list source.
• Some compliance teams prefer per-source separation for transparency.

• Policies and tiers determine list usage.
• In dashboard, exclude regions or lists per policy.
• Use sub-accounts to separate domestic vs. international flows.

• Sandbox responses are mocked and not all lists/features are available.
• Production includes live list updates and monitoring APIs.

• Use batch jobs (CSV) to load customers for monitoring.
• Mark previously reviewed entities as accepted to suppress repeats.
• Include your reference ID and flags (acceptList, autoMonitoring).

• Sanctions: Regulators expect near-zero false negatives → use broader thresholds, tolerate more reviews.
• PEP/adverse media: Tune thresholds higher or limit monitoring to high-risk groups to reduce fatigue.