Skip to main content
Request a demo
Resources

Compliance library

How eligibility is expressed as reviewable data, why every default denies, and the questions this platform deliberately refuses to answer on your behalf.

A compliance policy as ordered rulesRules are evaluated in sequence and the first match decides. A subject matching no rule is denied, and a fact the platform does not know never satisfies a rule.Subjectan investor's facts#1Screening hit is openreject#2Country in the blocked listreject#3Professional or institutional, verifiedallowMatched no ruledenyFirst matchdecides. A laterallow cannot undoan earlier reject.Eligibility comesfrom a rule saying so.

The three defaults, and why they all deny

  1. An absent fact never satisfies a ruleNot knowing whether a verification is valid is not the same as knowing that it is, and neither is permissive. An integration that stops populating a field closes the gate rather than opening it.
  2. A policy that matches nothing deniesEligibility comes from a rule saying so, never from no rule objecting. A workspace with no published policy onboards nobody, and says exactly that.
  3. The first matching rule decidesIn sequence order. A later allow cannot undo an earlier reject, so a policy can be read top to bottom and understood.

Why the attribute vocabulary is closed

A rule engine that can read any field is one nobody can bound.

  • “What could this policy possibly depend on?” has to have a short answer — roughly 25 declared attributes, each with a type.
  • Adding an attribute is a reviewed code change, because each addition widens what a policy may discriminate on. That is a regulatory decision rather than a configuration one.
  • A condition comparing a country code to a number fails at authoring, with the path to the offending node, rather than never matching in production.
  • Nothing is ever evaluated as code, so a policy can be reviewed by reading it, diffed between versions, and replayed against a historical subject.

What we will not decide for you

No jurisdiction pack ships, deliberately

A plausible-looking built-in pack would be read as legal advice, and an unreviewed pack cannot back a published policy. Jurisdictional rules are authored by people accountable for them.

Similarly, nothing can approve a verification on its own. With no provider adapter registered, the only path to an approved verification is a named officer recording the evidence they reviewed — enforced in the schema, the service and the compliance package rather than by policy alone.

What is recorded, and for how long

  • Every decision is snapshotted with the policy version that produced it, so “why was this allowed” is answerable under the rules that governed it.
  • Personal data used for identity is encrypted at the field level; the flags rules actually need — country, classification, screening status — are kept in the clear so the engine never decrypts at scale.
  • The audit trail is hash-chained and append-only at the database, so an altered history fails rather than merely being detectable.
  • Segregation of duties is checked continuously: holding both an originating and an approving role is surfaced on the team page rather than discovered during an examination.