Address Feature Taxonomy

Address features describe what was observed about an address. A feature is a fact, not a verdict: the taxonomy carries no score, risk level, list status, or action.

Every classified feature is identified by a stable canonicalKey. Keys and their hierarchy are versioned together; a screening result stamps the taxonomyVersion it was interpreted under and the mappingVersion of the vendor mapping snapshot that produced it.

Version and how to fetch

The page, the API and the download publish the same nodes for a given version.

• Taxonomy version: 2026-09-10
• Nodes: 290
• Fetch programmatically: GET /api/v2/taxonomy

Download the catalog (JSON) · Download the catalog (CSV)

Direct matches and ancestors

A mapped feature returns the key that matched directly in canonicalKey, and its ordered path in ancestorKeys. Ancestors are for navigation and grouping only: they are not additional evidence and must not be counted as extra matches.

Unclassified features may retain the provider’s original term without a canonicalKey.

Whose feature is it

Evidence stays with the role that supplied it. A counterparty's feature is never folded into the screened address's own profile.

An empty or omitted container can also mean the selected provider does not supply that field. Absence is not zero and not a clean finding.

Example

Selected fields from a recorded sandbox result: the address feature’s direct classification and its ancestor. See the API reference for the complete response fields.

{
  "self": {
    "features": [
      {
        "canonicalKey": "facts.sanctions.ofac",
        "ancestorKeys": ["facts.sanctions"]
      }
    ]
  }
}

Address screening API reference