NEXUS

Data Dictionary — Functional Specification

The canonical pillar data model for the NEXUS financial-crime platform. Every table anchors to one resolved party via a shared entity_key — the spine that lets sanctions, transaction monitoring, trade, ownership, intelligence, and case management be views on one truth rather than systems to reconcile. This spec is generated from data_dictionary.yaml (the governed source of truth).

29
Governed tables
9
Pillars
27
Active
2
Pending / reserved
20
FK links
entity_key
The join spine

Estate map — tables & connections

%%{init: {'theme':'dark','themeVariables':{'fontSize':'13px'}}}%%
flowchart LR
  ENT["entities
(entity_key)"]:::hub

  subgraph ACC["Accounts / Transactions"]
    A[accounts]
    T[transactions]
  end
  subgraph KYC["KYC / Reference"]
    K[kyc_profile]
    O[ownership]
    DIR[directorships]
  end
  subgraph SANC["Sanctions / Watchlists"]
    SL[sanctions_list]
    SR[screening_results]
    CR[country_risk]
    CUR[currency_risk]
    IR[industry_risk]
  end
  subgraph SHIP["Shipping / Trade"]
    V[vessels]
    VIH[vessel_identity_history]
    SE[shipping_events]
    TD[trade_documents]
    MB[market_benchmark]
    SH[shipments]
  end
  subgraph OPS["Investigation & Ops"]
    TL[task_list]
    TA[task_audit]
  end
  subgraph INT["Intel / Markets (pending)"]
    IE[intel_events]
    IRg[intel_register]
    MK[markets]
  end

  A -->|entity_key| ENT
  T -->|from/to_account| A
  T -.->|from/to_entity_key| ENT
  K -.->|entity_key| ENT
  O -->|owner/owned| ENT
  DIR -->|entity_key| ENT
  DIR -.->|person_entity_key| ENT
  V -->|owner_entity_key| ENT
  SE -->|vessel_id| V
  SE -.->|counterparty| V
  VIH -->|vessel_id| V
  SE -.->|entity_key| ENT
  TD -->|hs_code| MB
  TD -.->|entity_key| ENT
  SH -.->|entity_key| ENT
  SR -->|designation_id| SL
  SR -.->|entity_key| ENT
  TL -.->|entity_key| ENT
  TA -->|task_id| TL
  IE -.->|entity_key| ENT
  IRg -.->|entity_key| ENT
  K -. industry_code .-> IR
  K -. country .-> CR
  K -. currency .-> CUR

  classDef hub fill:#1c3a5e,stroke:#79c4ff,stroke-width:2px,color:#eaf1f9;
Solid = foreign key · dashed = entity_key anchor / reference-code link. Every operational table resolves back to entities.
The entity_key spine. `entities` is the one resolved-party table; ~13 tables carry entity_key as an anchor (transactions, kyc_profile, ownership, screening, shipping, trade, intel, tasks…). Resolution (SP1–SP3) guarantees one entity_key per real-world party across every source, so a transaction, a sanctions hit, an ownership edge and a case task about the same party all line up without reconciliation.

Reading the keys — key & relationship roles

PKPrimary key — uniquely identifies each row in its own table (one per table, e.g. designation_id, account_id).
FKForeign key — points to another table's primary key, forming the join (e.g. screening_results.designation_id → sanctions_list).
ANCHORentity_key anchor — the special FK that resolves the row back to the one canonical party in entities; the cross-pillar spine.
REFReference link — join into a governed lookup table (country, currency, industry, designation) that is periodically refreshed.

Connections reference — foreign keys, anchors & reference links

FromToOnKind
NEXUS · Data Dictionary Functional Specification · generated from data_dictionary.yaml · 2026-08-17 · 29 tables / 9 pillars