Compliance API

Objects

• Rule: one version of a compliance rule: a rule type (25 types, e.g. max_issuer_pct, restricted_list, wash_sale, udf_condition), parameters, a scope (firm, groups, packages or accounts), a severity (block, warn, info) and run points (pretrade, intrade, posttrade). Versions of one rule share a lineage_id. The restatement is written by code from the definition; definition_hash fingerprints the exact version.
• Violation: a breach with an owner, a due date and a history. Override: a request to proceed past a soft warning. Package: rules plus a mandate, assigned to groups or accounts. Register: every rule with its versions, sign-offs and violations. Report: a periodic report.

Rule life cycle

draft ─(test bench, submit)→ pending_approval ─(sign-off by a person)→ active ─(new version signed)→ superseded
      ←────────(reject: sent back)────────────┘                         └─(retire, signed)→ retired

1. POST /compliance/rules drafts (or {"change_of": id} drafts a new version).
2. POST /compliance/rules/{id}/test-bench (202, a job) runs it against today's holdings and recent orders. Required.
3. POST /compliance/rules/{id}/submit.
4. A person with approve compliance rules, never the author: GET /compliance/rules/{id}/sign-off (what you sign, and a confirm_token), then POST /compliance/rules/{id}/sign-off with X-Vestoris-Confirm and a reason. Client-credentials tokens are refused (user_token_required).

Violation life cycle

open → acknowledged → resolved | waived (note required) | escalated with POST /compliance/violations/{id}/transition. Post-trade breaches resolve themselves when the holding is fixed.

Overrides

POST /orders/{id}/override with a reason; above the firm's threshold Compliance decides with POST /overrides/{id}/decision (four eyes).