Rulebooks in Omnified

A rulebook is Omnified's structured, machine-evaluable representation of a regulator's AML/CFT & KYC requirements. Every threshold, list, and evidence expectation lives as data — so when counsel updates a threshold, no code change ships.

What lives in a rulebook

• Requirements — atomic obligations the regulator imposes (identify the customer, screen against sanctions, apply EDD to PEPs, etc.). Each requirement has a code, a category, and a citation.
• Applicability — which regulated entity types (bank, IBU, DPT provider, fund manager, …), customer types (individual, corporate, trust, partnership), and risk tiers (simplified, standard, enhanced) the requirement applies to.
• Machine rule — the evaluable condition. Under the hood it's a small algebra: fields_present, checks_include, payload_flag, bo_threshold, and boolean combinators (if_then, all_of, one_of).
• Evidence needed — what an auditor should expect to see when the requirement is met.
• verify_with_counsel — a flag on every seeded requirement acknowledging that the interpretation must be confirmed with qualified counsel.

Versioning

Rulebooks are versioned semantically — major.minor.patch. Publishing a new active version does not rewrite history: previously recorded validation runs keep pointing at the exact version they used, so an audit trail is always reproducible. Superseded rulebooks stay in the database and can still be read; only activerulebooks are used for new runs by default.

Every rulebook page in these docs shows a version badge and a changelog accordion — read those first when comparing an Omnified run to your own policy.

How validation works

1. A verification produces a normalised payload — jurisdiction, regulated-entity type, customer type, risk tier, channel (face-to-face / non-face-to-face), fields collected, checks performed, screening lists covered, documents collected, BO data, and policy flags.
2. The engine looks up the active rulebook for the jurisdiction and iterates every requirement.
3. Requirements that don't match the entity/customer/risk-tier tuple are marked not_applicable and dropped from the compliance surface.
4. Applicable requirements are evaluated deterministically. A pass = met. A failure = not_met with the exact missing fields, checks, or lists surfaced. A never-under-if_then that fires becomes a hard blocked.
5. The run's outcome, per-requirement findings, and payload snapshot are persisted with the rulebook version, and an entry lands in the immutable audit log.

Where to next

• Singapore (MAS) — entity matrix, requirement walkthrough, scenario library, CDD decision tree.
• GIFT City (IFSCA) — IFSC entity matrix, PMLA-aligned BO thresholds, V-CIP conditions, scenario library.
• MAS vs IFSCA — side-by-side comparison of identity rails, BO thresholds, EDD triggers, retention, and screening lists.