Build a compliance screening pipeline

A KYB onboarding check answers three questions before a counterparty is approved: who is this entity, does its name appear on a sanctions list, and is the wallet it settles from clean? This recipe builds that pipeline on Sugra Entity, which carries zero commercial upstreams - every source is a named authority: OFAC SDN, the EU consolidated list, the UN Security Council consolidated list, UK OFSI, Canada OSFI, Australia DFAT, Switzerland SECO, the World Bank listing of ineligible firms, a Wikidata-derived PEP layer and GLEIF LEI data (CC0). Every verdict is a screening signal, not a compliance determination.

What you build

Five requests form the pipeline:

Coverage check: confirm every required sanctions list is loaded and fresh before trusting any verdict.

Identity: resolve the counterparty from its LEI into a composed KYB envelope with per-field provenance.

Name screening: screen the legal name against the full sanctions corpus, read the clear / review / hit verdict and tune fuzzy-match sensitivity with threshold_review and threshold_hit.

Wallet screening: check a crypto address against sanctioned wallets before settlement.

All requests use the standard data + meta envelope described in the Quickstart. Replace YOUR_API_KEY with your key.

1. Verify screening coverage

A screening verdict is only as good as the lists behind it, so the pipeline starts with the sources manifest.

Response (truncated):

{
  "data": {
    "lists": [
      {"key": "ofac_sdn", "loaded": true, "age_hours": 1.0, "stale": false, "max_age_hours": 24},
      {"key": "eu_consolidated", "loaded": true, "age_hours": 2.66, "stale": false, "max_age_hours": 12},
      {"key": "un_sc", "loaded": true, "age_hours": 4.75, "stale": false, "max_age_hours": 72}
    ]
  }
}

Every list reports loaded, its age and the max_age_hours freshness budget it is held to. The screening endpoints are fail-closed: if the required sanctions corpus is unavailable they return 503 rather than a hollow clear, and a well-formed as_of date whose point-in-time snapshot is missing is also a 503, never a silent fallback to today's lists.

2. Resolve the counterparty by LEI

One GET composes identity, screening, ownership and adverse media from a single anchor. Here the anchor is Deutsche Bank AG's LEI.

Response (truncated):

{
  "data": {
    "entity": {
      "name": "DEUTSCHE BANK AKTIENGESELLSCHAFT",
      "country": "DE", "type": "company", "status": "ACTIVE",
      "field_provenance": {"name": "gleif", "country": "gleif", "status": "gleif", "type": "gleif"}
    },
    "screening": {"status": "review"}
  },
  "meta": {
    "screening_id": "7fbd1ad9-778e-4321-b706-226447698696",
    "disclaimer": "Screening signal, not a compliance determination. ..."
  }
}

The registry identity comes back resolved and ACTIVE, and field_provenance names the upstream (GLEIF) for every field. Store meta.screening_id with the case file - it is the stable audit identifier for this check.

3. Screen the legal name

The envelope above already embeds a screening slice; POST /api/v1/entity/screen runs the same check standalone, for names that have no LEI yet. Optional country, dob and nationality sharpen matching, and POST /api/v1/entity/screen/batch takes a list.

Response (truncated):

{
  "data": {
    "screening": {
      "status": "review",
      "matches": [
        {"list": "ofac_sdn", "restriction_type": "block", "score": 0.855,
         "matched_name": "NDA Nord-Deutsche Industrieanlagenbau GmbH", "match_type": "name_fuzzy",
         "rationale": ["composite 0.855 (shared: ['deutsche'])"], "list_published": "2026-07-17"}
      ]
    }
  },
  "meta": {"stale_screening": false, "coverage_degraded": false, "lists_missing": []}
}

The best candidate scored 0.855: above the default threshold_review (0.70) but below threshold_hit (0.90), so the verdict is review and the rationale shows why - a single shared token, "deutsche". Route review verdicts to a human, and note that meta confirms no list was missing or stale when this verdict was produced.

4. Tune match sensitivity

The defaults are deliberately conservative: one shared generic token ("Analytics", "Software", "Aktiengesellschaft") can be enough to reach review. If such candidates are drowning your review queue, raise threshold_review.

Response (truncated):

{"data": {"screening": {"status": "clear", "matches": []}}}

At the default 0.70 this same name came back review on one 0.75 candidate (shared token "analytics"); at 0.8 it is clear - no candidate reached the threshold on any loaded list. A clear is only trustworthy because the coverage guard from step 1 is fail-closed. Treat threshold changes as policy decisions and record them alongside each verdict.

5. Screen the settlement wallet

Before funds move, check the counterparty's crypto address against sanctioned wallets. This address is a documented OFAC-listed example.

Response (truncated):

{
  "data": {
    "screening": {
      "status": "hit",
      "matches": [
        {"list": "ofac_sdn", "restriction_type": "block", "matched_name": "Lazarus Group",
         "score": 1.0, "match_type": "wallet",
         "rationale": ["exact wallet match", "symbol=ETH"], "list_published": "2026-07-17"}
      ],
      "fifty_percent_rule": {"triggered": false, "ambiguous": false}
    }
  }
}

An exact wallet match scores 1.0 and returns hit with restriction_type block: stop the transaction and escalate. The fifty_percent_rule block additionally flags exposure through sanctioned ownership, not just direct listings.

Verdict semantics

Outcome	Meaning	Pipeline action
`clear`	no candidate at or above `threshold_review` on any loaded list	proceed; keep the response for the audit trail
`review`	best candidate between `threshold_review` and `threshold_hit`	human review of `matches[].rationale`
`hit`	candidate at or above `threshold_hit`, or an exact wallet or identifier match	block and escalate
HTTP `503`	required sanctions corpus unavailable, or the requested `as_of` snapshot is missing	retry later; never treat as `clear`

Going further

Sugra Entity direction - the full KYB envelope, batch screening, document-identifier checks, as_of point-in-time replays and the GLEIF corporate registry surface.

Rate limits and errors - budget per-onboarding calls against your plan's daily quota and handle 429 and 503 correctly.

Quickstart - the response envelope, authentication and rate-limit headers used throughout this recipe.

Build a compliance screening pipeline

What you build#

1. Verify screening coverage#

2. Resolve the counterparty by LEI#

3. Screen the legal name#

4. Tune match sensitivity#

5. Screen the settlement wallet#

Verdict semantics#

Going further#

What you build

1. Verify screening coverage

2. Resolve the counterparty by LEI

3. Screen the legal name

4. Tune match sensitivity

5. Screen the settlement wallet

Verdict semantics

Going further