Org Intelligence Catalog

The Org Intelligence Catalog is the operational home for analyst-managed data that rules depend on: watchlists, allowlists, deny lists, lookup tables, entity state, threshold tables, sanctions references, and other reusable intelligence assets.

Use it when the value is shared across rules or analysts. If a value belongs only to one transaction, send it in the transaction payload. If many rules need the same reference data, store it as a catalog asset.

What The Catalog Adds

The catalog wraps custom tables with fraud-operations context:

  • Purpose: why the asset exists, such as sanctions screening or trusted entity handling.
  • Type: watchlist, allowlist, denylist, entity profile, threshold table, lookup table, or reference list.
  • Owner/team: who is responsible for maintenance.
  • Validation status: whether analysts consider the asset current and safe to use.
  • Schema: fields available to rules.
  • Usage: which rules reference the table or its fields.
  • Imports: import runs and row-level outcomes when tracked.

Catalog data remains organization-scoped. Catalog-managed metadata is protected from accidental edits in the normal table workflow.

Catalog Endpoints

Catalog endpoints use an authenticated organization token. They are intended for workspace and administrative workflows, not for real-time transaction submissions.

POST/v1/intelligence-catalog/{org_id}/ensure

Initialize Catalog Checks whether catalog metadata storage is ready for the organization and initializes it when needed.

GET/v1/intelligence-catalog/{org_id}/assets

List Intelligence Assets Returns the organization's catalog assets. Use when the UI needs row counts.

GET/v1/intelligence-catalog/{org_id}/assets/{table_name}/metadata

Get Asset Metadata Returns purpose, type, owner, tags, validation status, and notes for one asset.

PUT/v1/intelligence-catalog/{org_id}/assets/{table_name}/metadata

Update Asset Metadata Updates catalog metadata for one asset.

GET/v1/intelligence-catalog/{org_id}/assets/{table_name}/imports

List Asset Imports Returns import runs tracked for one asset.

POST/v1/intelligence-catalog/{org_id}/assets/{table_name}/imports

Record Asset Import Records an import run and its outcome.

Table Data

Catalog assets are backed by custom tables. Table schema and row data are managed through table endpoints:

GET/v1/tables/{org_id}

List Tables Returns custom tables for the organization.

POST/v1/tables/{org_id}

Create Table Creates a custom table with an explicit table type and schema.

GET/v1/tables/{org_id}/{table_name}/schema

Get Table Schema Returns table fields and types.

GET/v1/tables/{org_id}/{table_name}/data

Get Table Data Returns paginated table rows.

PUT/v1/tables/{org_id}/{table_name}/data

Insert Rows Adds rows to a table.

PATCH/v1/tables/{org_id}/{table_name}/data/{id}

Update Row Updates one table row.

DELETE/v1/tables/{org_id}/{table_name}

Delete Table Deletes a custom table when policy allows.

Catalog-managed metadata is protected. Manage catalog details through the catalog endpoints above, not through generic table CRUD.

---

Using Catalog Assets In Rules

Rules can reference catalog-backed tables by table and column name. This makes analyst-owned intelligence reusable without copying it into every transaction payload.

Examples:

text
sanctions.full_name contains beneficiary_name
trusted_entities.entity_id = entity_id
entity_risk_profile.risk_tier = "high"

For rule authors, the important habit is to keep references explicit. Table-qualified fields are easier to audit than ambiguous field names, and they make it clear which intelligence asset a rule depends on.

Webhook Events

Catalog and table changes can emit public webhook events:

  • table.created
  • table.deleted
  • table.rows_inserted
  • table.row_updated
  • table.row_deleted

Subscribe to these events when connected systems need to refresh cached data, sync reference data, or maintain a change-management trail.

See Webhook Events.

  1. Create or identify the table that holds the intelligence asset.
  2. Set catalog metadata: purpose, type, owner/team, and validation status.
  3. Import or edit rows.
  4. Review schema and rule usage before activating rules that depend on it.
  5. Subscribe to table webhooks if another system needs to know when the asset changes.

This gives analysts a safe, visible way to maintain shared fraud intelligence while preserving rule traceability.