Overview

Learn how to create and manage Allow and Deny lists in RiskOS™ to apply precise or fuzzy list-based rules within your workflows.

How it works

Allow and Deny lists in RiskOS™ let you define conditions and rules that leverage values from specific lists. They can be used for positive or negative lists, custom watchlists, or other logic that requires list-based evaluations.

With RiskOS™, you can perform:

  • Exact value comparisons: Match an event value against entries in the list. Comparisons are case-insensitive and whitespace-insensitive — the system normalizes both the list entry and the incoming event value to lowercase with whitespace removed before comparing. This means "Philippines", "philippines", and "PHILIPPINES" all match the same list entry.
  • Fuzzy matching: Detect approximate matches (e.g., typos or formatting differences) using trigram-based matching.

How normalization works

When you add an entry to an allow or deny list, the system stores a normalized version alongside the original value. During evaluation, incoming event values are normalized the same way before comparison. The normalization process:

  1. Converts all characters to lowercase.
  2. Removes whitespace.

Both allow lists and deny lists use the same normalization and comparison logic.

List entryIncoming event valueNormalized list entryNormalized event valueMatch?
PhilippinesphilippinesphilippinesphilippinesYes
PhilippinesPHILIPPINESphilippinesphilippinesYes
New Yorknew yorknewyorknewyorkYes
New YorknewyorknewyorknewyorkYes
[email protected][email protected][email protected][email protected]Yes
PhilippinesPhilippinephilippinesphilippineNo
📘

Note:

Because comparisons are case-insensitive and whitespace-insensitive, you do not need to add transformation functions to normalize values before evaluating them against a list. If you have existing normalization transformations for this purpose, they are redundant and can be removed.

Fuzzy matching

Fuzzy matching uses a configurable threshold to balance strictness versus flexibility. For most use cases, we recommend starting with a threshold between 0.8–0.9. Lower thresholds may increase matches but risk false positives, while higher thresholds enforce stricter matching.

This functionality gives you the flexibility to tailor workflow logic to your specific needs.