> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# Wallet-Screening-API auf Abruf: ohne Transaktion

> Didit prüft eine einzelne Wallet-Adresse auf AML-Risiken, ohne Transaktion. Mittelherkunft, Sanktionsbezug und Risiko-Score auf Abruf.

Sometimes you need to check a crypto wallet's AML-Risiko **bevor** eine Transaktion erfasst wird, zum Beispiel wenn ein Kunde eine Auszahlungsadresse hinzufügt oder Ihr Compliance-Team eine Adresse ad hoc prüfen möchte. Der On-Demand-Endpoint für Wallet-Screening prüft eine einzelne Adresse und liefert das vollständige Risikoergebnis zurück, ohne eine Transaktion anzulegen.

Dies ist das eigenständige Gegenstück zum [automatischen Krypto-Screening](https://docs.didit.me/de/transaction-monitoring/aml-screening.md), das bei der [Einreichung einer Transaktion](https://docs.didit.me/de/transaction-monitoring/transactions.md) läuft. Beide nutzen dieselben Blockchain-Analyseanbieter und dieselbe Ergebnisstruktur.

## Wann Sie es verwenden

| Anwendungsfall | Endpoint |
| - | - |
| Adresse vorab prüfen, ohne eine Transaktion zu erfassen | **Wallet-Screening**: `POST /v3/wallet-screening/` |
| Eine Wallet als Teil einer erfassten Ein- oder Auszahlung prüfen | [Transaktion anlegen](https://docs.didit.me/de/transaction-monitoring/transactions.md) mit `currency_kind: "crypto"` |

Wallet-Screening schreibt nichts in die Transaktionstabelle. Wenn das Screening an eine überwachte Transaktion gebunden sein soll (mit Regeln, Alerts und Webhooks), reichen Sie stattdessen eine Transaktion ein.

## Voraussetzungen

Die Transaktionsüberwachung muss für die Anwendung konfiguriert sein, entweder mit einem verwalteten Anbieter oder mit einem [vorhandenen Anbieterschlüssel](https://docs.didit.me/de/transaction-monitoring/aml-screening.md#unterstützte-anbieter). Konfigurieren Sie sie unter **Transaktionen** > **Einstellungen** > **Provider Preferences** in der [Business Console](https://business.didit.me). Ist kein Anbieter konfiguriert, antwortet der Endpoint mit `409 Conflict`.

## Anfrage

`POST https://verification.didit.me/v3/wallet-screening/`

Authentifizieren Sie sich mit dem Header `x-api-key`.

| Feld | Typ | Pflicht | Beschreibung |
| - | - | - | - |
| `wallet_address` | Zeichenkette | Ja | Die Adresse oder Netzwerkkennung, die geprüft werden soll. Muss zum gewählten Netzwerk passen, etwa `0x` + 40 Hexadezimalzeichen bei EVM-Netzwerken oder eine Lightning-Kennung, die Ihr Anbieter akzeptiert. Alias: `address`. |
| `blockchain` | Zeichenkette | Nein | Asset- bzw. Netzwerkkennung. Wenn der Wert fehlt, liest Didit das Netzwerk aus dem Adressformat: `bc1`-, `1`- und `3`-Adressen sind Bitcoin (`BTC`), `T`-Adressen sind Tron (`TRX`) und Base58-Public-Keys sind Solana (`SOL`). Eine `0x`-Adresse ist auf jedem EVM-Netzwerk gültig. Deshalb antwortet der Endpoint mit `422` und `candidate_chains`; es wird weder gescreent noch abgerechnet. Senden Sie sie erneut mit gesetztem Netzwerk. Jedes andere Format führt zu `400`. Zulässige Werte: `BTC`, `LIGHTNING`, `ETH`, `LTC`, `XRP`, `BCH`, `DOGE`, `TRX`, `SOL`, `MATIC`, `BNB`, `BASE`, `OP`, `ARB`, `AVAX`, `ADA`, `XLM`, `HBAR`, `CELO`, `MODE`, `PLUME`, `USDT`, `USDC`. Gängige Netzwerknamen werden ebenfalls akzeptiert, zum Beispiel `POLYGON` oder `POL` für `MATIC`, `BSC` für `BNB` und `TRON` für `TRX`. Alias: `currency`. |
| `direction` | Zeichenkette | Nein | `inbound`, `outbound`, `deposit` oder `withdrawal`. Optionaler Kontext für den Anbieter; für ein neutrales Screening vor einer Überweisung weglassen. Er ändert weder den zurückgegebenen `risk_score` noch `severity` noch die Aufschlüsselungen der Geldflüsse (siehe den Hinweis unter [Antwort](#antwort)). |

### Netzwerkabdeckung

Verwaltetes Screening unterstützt Base (`BASE`), Optimism (`OP`) und Arbitrum One (`ARB`), sowohl für Wallet- als auch für Transaktions-Hash-Screening.
Verbundene Anbieter können eine abweichende Abdeckung haben; ein Netzwerk muss außerdem von Ihrem gewählten Anbieter und Konto unterstützt werden.
Celo (`CELO`), Mode (`MODE`) und Plume (`PLUME`) werden über ein verbundenes TRM-Labs-Konto gescreent (Marketplace, eigener Schlüssel). Das verwaltete Screening deckt sie nicht ab und antwortet mit `400`.
Senden Sie `ETH` nicht für ein anderes EVM-Netzwerk: Dieselbe Adresse kann auf jedem Netzwerk unterschiedliche Aktivitäten und Risiken aufweisen.

Beim verwalteten Screening sind `USDT` und `USDC` veraltete Aliase für Ethereum, keine Suche über alle Netzwerke, in denen diese Token existieren.
Verwenden Sie die Netzwerkkennung (`ETH`, `TRX`, `SOL`, `MATIC`, `BNB`, `BASE`, `OP`, `ARB`, `AVAX`, `ADA`, `XLM`, `HBAR` oder mit TRM Labs `CELO`, `MODE` oder `PLUME`) für das tatsächliche Netzwerk der Wallet.
Bei Token in erfassten Transaktionen behalten Sie den Token in `transaction_details.currency` bei und geben das Netzwerk separat in `transaction_details.crypto_params.crypto_chain` an.
Siehe [Auswahl von Asset und Netzwerk](https://docs.didit.me/de/transaction-monitoring/aml-screening.md#asset--und-netzwerkauswahl).

> [!WARNING]
>
> `LIGHTNING` ist nur verfügbar, wenn für die Anwendung in der Konsole unter **Marketplace** ein verbundener Elliptic- oder Chainalysis-BYOK-Anbieter hinterlegt ist.
> Mit verwaltetem Merkle Science oder mit Crystal oder TRM Labs ist es nicht verfügbar.
> Anfragen ohne unterstützten verbundenen Anbieter führen zu `400` und werden weder gescreent noch abgerechnet.

```bash theme={null}
curl -X POST https://verification.didit.me/v3/wallet-screening/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "wallet_address": "0x94f1b9b64e2932f6a2db338f616844400cd58e8a",
    "blockchain": "ETH"
  }'
```

## Antwort

Die Antwort ist das standardisierte Screening-Ergebnis und hat dieselbe Struktur wie das `WALLET_SCREENING`-Providerergebnis, das das Transaktions-Screening zurückgibt.

| Feld | Typ | Beschreibung |
| - | - | - |
| `provider` | string | Provider, der die Adresse geprüft hat (`merklescience`, `crystal`, `chainalysis`, `elliptic`, `trmlabs`). |
| `screening_type` | string | Immer `WALLET_SCREENING`. |
| `risk_score` | integer | Normalisierter Risiko-Score von 0–100. Merkle Science bewertet eine Adresse mit `0-5`, was `0`, `15`, `35`, `55`, `75` oder `95` entspricht. |
| `severity` | string | Risikostufe, abgeleitet aus `risk_score` (siehe Hinweis unten): `UNKNOWN`, `LOW`, `MEDIUM`, `HIGH` oder `CRITICAL`. |
| `status` | string | `SCREENED`, `PENDING` oder `ERROR`. |
| `summary` | string | Lesbare Zusammenfassung. |
| `wallet_address` | string | Die geprüfte Adresse. |
| `blockchain` | string | Die geprüfte Blockchain. |
| `sanctions_hit` | boolean | `true`, wenn das geprüfte Wallet sanktioniert ist oder wenn Gelder einer seiner Gegenparteien aus sanktionierten Entitäten stammen (Exposition). Die beiden Fälle werden nicht unterschieden. |
| `pep_counterparty` | boolean \| null | Exposition gegenüber politisch exponierten Personen. `null`, wenn kein PEP-Befund vorliegt, was derzeit bei allen Ergebnissen der Fall ist, weil kein Provider einen meldet. `false` nur bei einem explizit negativen Screening-Ergebnis. `null` darf nicht als abgeschlossene PEP-Prüfung gelesen werden. |
| `dominant_risk_category` | string \| null | Am höchsten gewichtete Hochrisiko-Kategorie oder `null`. |
| `risk_factors` | array | Nach Rang sortierte Erklärung von `risk_score`, also was zu diesem Urteil geführt hat. Siehe [Risikofaktoren](#risikofaktoren). |
| `source_of_funds` | array | Herkunft der Gelder, aufgeschlüsselt nach Entität. Siehe [Aufschlüsselung der Exposition](#aufschlüsselung-der-exposition). |
| `destination_of_funds` | array | Ziel der gesendeten Gelder, aufgeschlüsselt nach Entität. Gleicher Eintragsaufbau wie `source_of_funds`. |
| `counterparty_connections` | array | Entitäten, denen der Provider die Adresse zuordnet. Siehe [Gegenparteiverbindungen](#verbindungen-zu-gegenparteien). |
| `network_nodes`, `network_edges` | array | Graph der Exposition für das Transaktions-Screening. Bei einem Wallet-Screening-Ergebnis leer. |
| `transaction_hash`, `block_timestamp`, `total_value_usd`, `fee_usd`, `transaction_flows_status`, `transaction_flows_error` | null | Felder des Transaktions-Screenings, die mit dem Ergebnisformat geteilt werden. Bei einem Wallet-Screening-Ergebnis immer `null`. |
| `sender_rows`, `receiver_rows`, `transaction_flows` | array | Felder des Transaktions-Screenings. Bei einem Wallet-Screening-Ergebnis immer leer. |
| `raw_response` | object | Die Payload des Providers. Ihre Struktur ist providerspezifisch und kann sich ohne Ankündigung ändern. Lesen Sie stattdessen die normalisierten Felder oben und parsen Sie sie nicht selbst. |
| `report_signature` | string | Undurchsichtige Signatur über dieses Ergebnis, bezogen auf Ihre Anwendung. Senden Sie die Antwort unverändert erneut, einschließlich dieses Feldes, um [die PDF-Ausgabe zu erzeugen](#pdf-bericht). |

> [!NOTE]
>
> **So wird `severity` festgelegt.** `severity` ist die Stufe des normalisierten `risk_score`: `0-9` → `UNKNOWN`, `10-39` → `LOW`, `40-69` → `MEDIUM`, `70-89` → `HIGH`, `90-100` → `CRITICAL`. `UNKNOWN` ist die niedrigste Stufe und kein eigener Zustand „keine Daten“. `risk_score: 0` (der häufige Fall einer unauffälligen Adresse) bedeutet, dass der Provider keine negative Bewertung geliefert hat, während ein Wert ungleich null im Bereich `1-9` ein echtes, aber unterhalb von `LOW` liegendes Signal ist. Lesen Sie daher den `risk_score` selbst und nicht nur die Stufe. In beiden Fällen darf `UNKNOWN` nicht als eindeutig „unauffällig“ oder bestanden dargestellt werden.
>
> **`direction` ändert das Risikomodell nicht.** Das optionale Feld `direction` wird nur als Kontext an den Provider übergeben. Es beeinflusst weder `risk_score` noch `severity` noch die zurückgegebenen Aufschlüsselungslisten: `source_of_funds` und `destination_of_funds` werden immer zurückgegeben. Das Ändern oder Weglassen von `direction` macht daher kein erneutes Screening einer bereits geprüften Adresse erforderlich.

### Risikofaktoren

`risk_factors` ist die nach Rang sortierte Antwort auf die Frage, warum die Adresse so bewertet wird. Provider bewerten eine Adresse nach ihrem eigenen Modell und liefern nur ein Urteil. Merkle Science gibt etwa eine Ganzzahl `0-5` zurück, daher können allein aus `risk_score` keine Maßnahmen abgeleitet werden. Jeder Eintrag benennt einen Treiber. Die Einträge sind zuerst nach Hochrisiko sortiert und danach nach dem Wert, der über diesen Treiber geflossen ist.

| Feld | Typ | Beschreibung |
| - | - | - |
| `source` | string | `attribution` (was der Provider über die Adresse selbst aussagt, also ihr eigenes Tag oder Cluster) oder `exposure` (wohin ihre Gelder tatsächlich geflossen sind). |
| `category` | string | Normalisierte Risikokategorie im selben Vokabular wie die Aufschlüsselung der Exposition. |
| `label` | string | Die eigene Formulierung des Providers, z. B. `Gambling / Crypto only`. Verwenden Sie dieses Label in einer Benutzeroberfläche, denn es stimmt mit dem überein, was Sie in der Konsole des Providers sehen. |
| `entity_name` | string \| null | Zugeordnete Entität, z. B. eine Glücksspielseite oder eine Börse. Die Beispiele auf dieser Seite verwenden Platzhalter wie `Example Gambling`. |
| `direction` | string | `incoming`, `outgoing`, `connected`, `attribution` (das eigene Tag der Adresse) oder `unknown`, wenn der Provider keine Richtung gemeldet hat. |
| `exposure_type` | string | `direct` (1 Hop), `indirect` (mehrere Hops), `attribution` (das eigene Tag der Adresse) oder `unknown`, wenn der Provider nicht angegeben hat, wie viele Hops die Gegenpartei entfernt ist. Behandeln Sie `unknown` als nicht klassifiziert, niemals als `direct`. |
| `amount_usd` | number \| null | USD-Wert, der diesem Treiber zugeordnet wird. |
| `percentage` | number | Anteil am **Gesamt**volumen der geprüften Adresse, beide Richtungen zusammengerechnet. Anders als `percentage` innerhalb von `source_of_funds` / `destination_of_funds`, das je Richtung normalisiert ist, sind die Werte hier über die gesamte Liste vergleichbar und summierbar. |
| `is_high_risk` | boolean | Ob die Kategorie von Didit als Hochrisiko eingestuft wird (`sanctioned`, `mixer`, `stolen_funds`, `ransomware`, `scam`, `darknet_market`, `terrorist_financing`, `child_exploitation`, `hacked_exchange`, `high_risk_exchange`, `seized_funds`). |
| `description` | string | Einzeilige Darstellung des Treibers, z. B. `9.01% indirect outgoing exposure to Gambling / Crypto only (Example Gambling)`. |

> [!NOTE]
>
> **Ein hoher Score ohne `is_high_risk`-Faktor ist ein echtes, aussagekräftiges Ergebnis.** Es bedeutet, dass der Provider die Adresse nach seinem eigenen Expositionsmodell bewertet hat, ohne einen Treffer bei Sanktionen, PEPs oder einer zugeordneten Entität zu melden. Die aufgeführten Faktoren sind die Geldflüsse hinter der Bewertung. `summary` nennt dies ausdrücklich. Behandeln Sie solche Adressen daher als „Geldflüsse prüfen“ und nicht als bestätigten Treffer. `risk_factors` ist auf die fünf stärksten Treiber begrenzt. `source_of_funds` und `destination_of_funds` enthalten dagegen immer die vollständige Aufschlüsselung.
>
> **`risk_factors` ist ein Feld auf oberster Ebene, nicht ein verschachteltes Feld.** Ergebnisse, die vor dessen Einführung erstellt wurden, enthalten den Schlüssel gar nicht. Lesen Sie ihn in diesem Fall als leere Liste, statt eine leere Erklärung anzunehmen.

### Aufschlüsselung der Exposition

Jeder Eintrag in `source_of_funds` / `destination_of_funds` beschreibt eine Entität, mit der die Adresse Geld ausgetauscht hat:

| Feld | Typ | Beschreibung |
| - | - | - |
| `category` | string | Normalisierte Risikokategorie (`exchange_licensed`, `dex`, `defi`, `mixer`, `sanctioned`, `darknet_market`, `stolen_funds`, …). |
| `entity_name` | string \| null | Zugeordnete Entität, zum Beispiel eine Börse, ein Mixer oder eine sanktionierte Gruppe. Die Beispiele auf dieser Seite verwenden Platzhalter. |
| `entity_type` | string \| null | Entitätstyp laut Anbieter (`Exchange`, `DeFi`, `Sanctions`). |
| `entity_subtype` | string \| null | Detaillierter Untertyp (`Mandatory KYC and AML`, `OFAC`). |
| `description` | string \| null | `entity_type / entity_subtype`, so wie der Anbieter die Entität bezeichnet. |
| `exposure_direction` | string | `incoming`, `outgoing` oder `connected`. |
| `exposure_type` | string | `direct` (1 Hop) oder `indirect` (mehrere Hops). |
| `is_direct` | boolean | `true`, wenn `exposure_type` den Wert `direct` hat. |
| `amount_usd` | number \| null | USD-Wert, der der Entität zugerechnet wird. |
| `percentage` | number | Anteil an der Gesamtexposition der Richtung (0–100). |
| `hops` | integer \| null | Anzahl der Hops bis zur Entität (`1` für eine direkte Gegenpartei), sofern der Anbieter sie meldet. Bei Merkle Science immer `null`, da dort nur angegeben wird, ob die Exposition direkt oder indirekt ist. Verwenden Sie stattdessen `exposure_type`. |
| `country` | string \| null | Primäres Land der Entität nach ISO 3166-1 Alpha-2. Leer oder `null`, wenn der Anbieter es nicht kennt. |
| `provider_entity_id`, `provider_entity_type_id`, `provider_entity_subtype_id` | string \| null | Die eigenen Kennungen des Anbieters für die Entität und ihren Typ. |
| `raw_amount`, `raw_currency` | number \| null, string \| null | Betrag in der eigenen Einheit des Assets, sofern der Anbieter ihn meldet. |

### Verbindungen zu Gegenparteien

`counterparty_connections` listet die Entitäten auf, denen der Anbieter die gescreente Adresse zuordnet. Bei Merkle Science stammen diese aus den eigenen Eigentümer- und Benutzer-Tags der Adresse. Dieselbe Entität kann daher zweimal erscheinen, und es werden keine Geldflüsse ausgewiesen: `received_usd`, `sent_usd`, `received_hops` und `sent_hops` sind `null`, und `percentage` ist `0.0`. Die Geldflüsse lesen Sie aus `source_of_funds` und `destination_of_funds`.

| Feld | Typ | Beschreibung |
| - | - | - |
| `entity_name` | string \| null | Zugeordnete Entität. |
| `entity_type` | string \| null | Entitätstyp laut Anbieter. |
| `entity_subtype` | string \| null | Detaillierter Untertyp. |
| `categories` | array | Normalisierte Risikokategorien der Entität. |
| `risk_level` | string | Kleingeschrieben, abhängig vom Anbieter. Bei Merkle Science ist es die eigene Risikostufe der Adresse von 0 bis 5 (`no_risk`, `low`, `medium_low`, `medium`, `high`, `critical`). Sie wird auf `high` angehoben, wenn die Kategorie der Entität ein hohes Risiko hat. Es handelt sich nicht um eine eigene Bewertung der Entität. |
| `is_direct` | boolean | Bei Merkle Science immer `true`, da die Verbindungen Zuordnungen und keine Gegenparteien sind. |
| `received_usd`, `sent_usd` | number \| null | USD, die von der Entität empfangen bzw. an sie gesendet wurden, sofern der Anbieter sie meldet. |
| `received_hops`, `sent_hops` | integer \| null | Hops zur Entität in jeder Richtung, sofern der Anbieter sie meldet. |
| `percentage` | number | Anteil an der Exposition der Adresse, sofern der Anbieter ihn meldet. Andernfalls `0.0`. |
| `country` | string \| null | Land der Entität, sofern bekannt. |
| `provider_entity_id` | string \| null | Die eigene Kennung des Anbieters für die Entität. |

> [!WARNING]
>
> Treffen Sie keine Routing-Entscheidungen auf Basis von `counterparty_connections[].risk_level` oder `counterparty_connections[].is_direct`. Bei Merkle Science wiederholt das erste die eigene Bewertung der Adresse (lesen Sie dafür `risk_score`), und das zweite ist immer `true`. Für das Ergebnis verwenden Sie `sanctions_hit`, `dominant_risk_category` und `risk_factors[].is_high_risk`. Für die Direktheit verwenden Sie `exposure_type` in `source_of_funds` / `destination_of_funds`.

### Beispiel

Eine echte Antwort für eine Adresse auf der OFAC-Sanktionsliste, geprüft mit Merkle Science. Nur `raw_response` wurde gekürzt und `report_signature` ersetzt:

```json theme={null}
{
  "provider": "merklescience",
  "screening_type": "WALLET_SCREENING",
  "risk_score": 95,
  "severity": "CRITICAL",
  "status": "SCREENED",
  "summary": "Merkle Science risk: Critical (5/5). SANCTIONS HIT. Dominant risk: sanctioned. Driven by: the address is attributed to Sanctions / OFAC (Example Sanctions)",
  "wallet_address": "0x94f1b9b64e2932f6a2db338f616844400cd58e8a",
  "transaction_hash": null,
  "blockchain": "ETH",
  "block_timestamp": null,
  "total_value_usd": null,
  "fee_usd": null,
  "sender_rows": [],
  "receiver_rows": [],
  "transaction_flows": [],
  "transaction_flows_status": null,
  "transaction_flows_error": null,
  "source_of_funds": [
    {
      "category": "sanctioned",
      "percentage": 100.0,
      "amount_usd": 9813695.0,
      "entity_name": "Example Sanctions",
      "entity_type": "Sanctions",
      "entity_subtype": "OFAC",
      "hops": null,
      "description": "Sanctions / OFAC",
      "is_direct": true,
      "exposure_direction": "incoming",
      "exposure_type": "direct",
      "provider_entity_id": "118885",
      "provider_entity_type_id": "30",
      "provider_entity_subtype_id": "125",
      "country": "",
      "raw_amount": null,
      "raw_currency": null
    }
  ],
  "destination_of_funds": [
    {
      "category": "defi",
      "percentage": 84.824453,
      "amount_usd": 7783414.38,
      "entity_name": "Example DeFi 7",
      "entity_type": "DeFi",
      "entity_subtype": "Bridges",
      "hops": null,
      "description": "DeFi / Bridges",
      "is_direct": false,
      "exposure_direction": "outgoing",
      "exposure_type": "indirect",
      "provider_entity_id": "118459",
      "provider_entity_type_id": "33",
      "provider_entity_subtype_id": "143",
      "country": "",
      "raw_amount": null,
      "raw_currency": null
    },
    {
      "category": "defi",
      "percentage": 15.175547,
      "amount_usd": 1392494.37,
      "entity_name": "Example DeFi 2",
      "entity_type": "DeFi",
      "entity_subtype": "Yield Aggregator",
      "hops": null,
      "description": "DeFi / Yield Aggregator",
      "is_direct": false,
      "exposure_direction": "outgoing",
      "exposure_type": "indirect",
      "provider_entity_id": "90192",
      "provider_entity_type_id": "33",
      "provider_entity_subtype_id": "142",
      "country": "",
      "raw_amount": null,
      "raw_currency": null
    }
  ],
  "counterparty_connections": [
    {
      "entity_name": "Example Sanctions",
      "entity_type": "Sanctions",
      "entity_subtype": "OFAC",
      "risk_level": "critical",
      "categories": [
        "sanctioned"
      ],
      "received_usd": null,
      "sent_usd": null,
      "received_hops": null,
      "sent_hops": null,
      "percentage": 0.0,
      "is_direct": true,
      "country": null,
      "provider_entity_id": null
    },
    {
      "entity_name": "Example Sanctions",
      "entity_type": "Sanctions",
      "entity_subtype": "OFAC",
      "risk_level": "critical",
      "categories": [
        "sanctioned"
      ],
      "received_usd": null,
      "sent_usd": null,
      "received_hops": null,
      "sent_hops": null,
      "percentage": 0.0,
      "is_direct": true,
      "country": null,
      "provider_entity_id": null
    }
  ],
  "network_nodes": [],
  "network_edges": [],
  "sanctions_hit": true,
  "pep_counterparty": null,
  "dominant_risk_category": "sanctioned",
  "risk_factors": [
    {
      "source": "attribution",
      "category": "sanctioned",
      "label": "Sanctions / OFAC",
      "entity_name": "Example Sanctions",
      "direction": "attribution",
      "exposure_type": "attribution",
      "amount_usd": null,
      "percentage": 0.0,
      "is_high_risk": true,
      "description": "the address is attributed to Sanctions / OFAC (Example Sanctions)"
    },
    {
      "source": "exposure",
      "category": "sanctioned",
      "label": "Sanctions / OFAC",
      "entity_name": "Example Sanctions",
      "direction": "incoming",
      "exposure_type": "direct",
      "amount_usd": 9813695.0,
      "percentage": 51.679304,
      "is_high_risk": true,
      "description": "51.6793% direct incoming exposure to Sanctions / OFAC (Example Sanctions)"
    },
    {
      "source": "exposure",
      "category": "defi",
      "label": "DeFi / Bridges",
      "entity_name": "Example DeFi 7",
      "direction": "outgoing",
      "exposure_type": "indirect",
      "amount_usd": 7783414.38,
      "percentage": 40.987766,
      "is_high_risk": false,
      "description": "40.9878% indirect outgoing exposure to DeFi / Bridges (Example DeFi 7)"
    },
    {
      "source": "exposure",
      "category": "defi",
      "label": "DeFi / Yield Aggregator",
      "entity_name": "Example DeFi 2",
      "direction": "outgoing",
      "exposure_type": "indirect",
      "amount_usd": 1392494.37,
      "percentage": 7.33293,
      "is_high_risk": false,
      "description": "7.33293% indirect outgoing exposure to DeFi / Yield Aggregator (Example DeFi 2)"
    }
  ],
  "raw_response": {
    "...": "provider-specific details"
  },
  "report_signature": "<hmac-sha256 over the result, scoped to your application>"
}
```

Die Beispiele veranschaulichen die Struktur der Antwort, sie sind kein garantiertes Ergebnis für eine reale Adresse.
Risiko-Scores und Sanktionsexposition hängen vom gewählten Netzwerk, aktuellen Erkenntnissen und der konfigurierten Risikorichtlinie ab.
Eine Börsen-Zuordnung bedeutet nicht, dass der Risiko-Score null ist: Eine Börsen-Wallet kann über ihre Geldflüsse eine Sanktionsexposition haben.
`sanctions_hit: true` kann bedeuten, dass die Wallet selbst sanktioniert ist, oder nur, dass ihre Gelder einer Sanktionsexposition ausgesetzt sind. Allein daraus folgt also nicht, dass der Inhaber der gescreenten Wallet sanktioniert ist.
Wenn dasselbe Screening für eine erfasste Transaktion läuft, können Regeln außerdem `custom_values.wallet_sanctioned` lesen, das nur dann `true` ist, wenn der Anbieter die Wallet selbst einer sanktionierten Entität zuordnet, und Regeln können außerdem `custom_values.aml_sanctions_exposure_pct` lesen.
Siehe [Screening-Felder für Regeln](https://docs.didit.me/de/transaction-monitoring/aml-screening.md#screening-felder-für-regeln).
Lesen Sie `risk_factors`, `source_of_funds` und `destination_of_funds`, um Zuordnung und Exposition zu unterscheiden.
Eine Schritt-für-Schritt-Anleitung finden Sie unter [Krypto- und Wallet-Screening](https://docs.didit.me/de/transaction-monitoring/aml-screening.md#screening-ergebnisse).

## PDF-Bericht

Um einen PDF-Bericht mit Didit-Branding zu einem Screening-Ergebnis zu erhalten, senden Sie den unveränderten Antworttext einschließlich `report_signature` erneut an `POST /v3/wallet-screening/pdf/`. Der Vorgang ist zustandslos: Es erfolgt kein Aufruf beim Anbieter, es fällt keine zusätzliche Abrechnung an, und nichts wird gespeichert. Wenn Sie vor dem erneuten Senden ein signiertes Feld ändern (`risk_score`, `severity`, `sanctions_hit`, …), schlägt die Anfrage mit `400` fehl.

```bash theme={null}
RESULT=$(curl -s -X POST https://verification.didit.me/v3/wallet-screening/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"wallet_address": "0x94f1b9b64e2932f6a2db338f616844400cd58e8a", "blockchain": "ETH"}')

curl -X POST https://verification.didit.me/v3/wallet-screening/pdf/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d "$RESULT" \
  -o wallet_screening_report.pdf
```

Das vollständige Anfrage- und Antwortschema sowie die Fehlerformate finden Sie unter [Wallet-Screening-PDF](https://docs.didit.me/de/management-api/transactions/screen-wallet-pdf.md).

## Abrechnung

Eine Nutzung der AML-Überwachung wird pro erfolgreichem Screening zum gleichen Tarif berechnet wie das transaktionsgekoppelte Krypto-Screening. Die Preise für verwaltete und verbundene API-Schlüssel finden Sie unter [Preise](https://docs.didit.me/de/transaction-monitoring/aml-screening.md#unterstützte-anbieter). Sandbox-Anwendungen werden nicht berechnet. Validierungsfehler (`400`) und Fehler wegen eines nicht konfigurierten Anbieters (`409`) werden niemals berechnet.

## Fehler

| Status | Bedeutung |
| - | - |
| `400` | Fehlerhafte Adresse, fehlendes `wallet_address` oder nicht unterstütztes `blockchain`. |
| `401` | Fehlender oder ungültiger `x-api-key`. |
| `409` | Für die Anwendung ist kein AML-Anbieter konfiguriert: Konfigurieren Sie zuerst die Transaktionsüberwachung. |
| `409` | Der Anbieter hat den von Ihnen verbundenen API-Schlüssel abgelehnt (`wallet_screening_provider_credentials_rejected`): Aktualisieren Sie den Schlüssel in der Marketplace-Verbindung oder, bei einem dort konfigurierten Schlüssel, in den Einstellungen der Transaktionsüberwachung. Ein erneuter Versuch mit demselben Schlüssel hilft nicht. |
| `409` | Der konfigurierte AML-Anbieter unterstützt das Wallet-Screening noch nicht (`wallet_screening_provider_unavailable`). |
| `422` | Eine `0x`-Adresse wurde ohne `blockchain` gesendet (`wallet_screening_chain_undetermined`). Der Antworttext enthält `candidate_chains`; senden Sie die Anfrage erneut mit einer davon. Es erfolgt kein Screening und keine Berechnung. |
| `502` | Der Anbieter konnte das Screening nicht abschließen; versuchen Sie es später erneut. |

## Nächste Schritte

> [card] [API-Referenz](https://docs.didit.me/de/management-api/transactions/screen-wallet.md)
>
> Vollständiges Anfrage- und Antwortschema für den Endpoint Screen Wallet.

> [card] [Screen Wallet PDF](https://docs.didit.me/de/management-api/transactions/screen-wallet-pdf.md)
>
> Ein Screening-Ergebnis als PDF im Didit-Design darstellen.

> [card] [Krypto- & Wallet-Screening](https://docs.didit.me/de/transaction-monitoring/aml-screening.md)
>
> Automatisches Screening bei der Transaktionserstellung und das Ergebnismodell.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.