> ## 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.

# Filtrage des portefeuilles à la demande, sans transaction

> Didit filtre une adresse crypto pour le risque AML sans créer de transaction : origine des fonds, exposition aux sanctions et score de risque à la demande.

Il arrive que vous deviez vérifier le risque AML d'un portefeuille crypto **avant** qu'une transaction soit enregistrée, par exemple lorsqu'un client ajoute une adresse de retrait, ou lorsque votre équipe de conformité souhaite contrôler une adresse au cas par cas. L'endpoint de filtrage des portefeuilles à la demande analyse une seule adresse et renvoie le résultat complet de l'évaluation du risque, sans créer de transaction.

Il s'agit de l'équivalent autonome de l'[filtrage automatique des cryptomonnaies](https://docs.didit.me/fr/transaction-monitoring/aml-screening.md) effectué lors de la [soumission d'une transaction](https://docs.didit.me/fr/transaction-monitoring/transactions.md). Les deux utilisent les mêmes fournisseurs d'analyse blockchain et la même structure de résultat.

## Quand l'utiliser

| Cas d'usage | Endpoint |
| - | - |
| Pré-vérifier une adresse sans transaction à enregistrer | **Filtrage des portefeuilles** — `POST /v3/wallet-screening/` |
| Effectuer le filtrage d'un portefeuille dans le cadre d'un dépôt ou d'un retrait enregistré | [Create Transaction](https://docs.didit.me/fr/transaction-monitoring/transactions.md) avec `currency_kind: "crypto"` |

Le filtrage des portefeuilles n'écrit rien dans la table des transactions. Si vous voulez rattacher l'analyse à une transaction surveillée (avec règles, alertes et webhooks), soumettez plutôt une transaction.

## Prérequis

La surveillance des transactions doit être configurée pour l'application, avec un fournisseur géré ou une [clé de fournisseur existante](https://docs.didit.me/fr/transaction-monitoring/aml-screening.md#fournisseurs-pris-en-charge). Configurez-la dans **Transactions** > **Paramètres** > **Provider Preferences** de la [Business Console](https://business.didit.me). Si aucun fournisseur n'est configuré, l'endpoint renvoie `409 Conflict`.

## Requête

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

Authentifiez-vous avec l'en-tête `x-api-key`.

| Champ | Type | Obligatoire | Description |
| - | - | - | - |
| `wallet_address` | string | Oui | L'adresse ou l'identifiant de réseau à filtrer. Doit correspondre au réseau choisi, par exemple `0x` suivi de 40 caractères hexadécimaux pour les chaînes EVM, ou un identifiant Lightning accepté par votre fournisseur. Alias : `address`. |
| `blockchain` | string | Non | Identifiant de l'actif ou du réseau. S'il est omis, Didit déduit le réseau du format de l'adresse : les adresses `bc1`, `1` et `3` correspondent à Bitcoin (`BTC`), les adresses `T` à Tron (`TRX`) et les clés publiques base58 à Solana (`SOL`). Une adresse `0x` est valide sur tous les réseaux EVM : l'API répond donc `422` avec `candidate_chains`, rien ne fait l'objet d'un filtrage ni n'est facturé ; renvoyez-la en indiquant le réseau. Tout autre format renvoie `400`. Valeurs acceptées : `BTC`, `LIGHTNING`, `ETH`, `LTC`, `XRP`, `BCH`, `DOGE`, `TRX`, `SOL`, `MATIC`, `BNB`, `BASE`, `OP`, `ARB`, `AVAX`, `ADA`, `XLM`, `HBAR`, `CELO`, `MODE`, `PLUME`, `USDT`, `USDC`. Les noms de réseaux courants sont acceptés aussi, par exemple `POLYGON` ou `POL` pour `MATIC`, `BSC` pour `BNB` et `TRON` pour `TRX`. Alias : `currency`. |
| `direction` | string | Non | `inbound`, `outbound`, `deposit` ou `withdrawal`. Contexte facultatif pour le fournisseur ; omettez-le pour une analyse neutre avant transfert. Il ne modifie ni le `risk_score`, ni la `severity`, ni la répartition des flux de fonds (voir la note sous [Réponse](#réponse)). |

### Couverture des chaînes

Le filtrage géré prend en charge Base (`BASE`), Optimism (`OP`) et Arbitrum One (`ARB`) pour le filtrage des portefeuilles et des hachages de transaction.
La couverture des fournisseurs connectés peut varier ; une chaîne doit aussi être prise en charge par votre fournisseur et votre compte sélectionnés.
Celo (`CELO`), Mode (`MODE`) et Plume (`PLUME`) font l'objet d'un filtrage via un compte TRM Labs connecté (Marketplace, avec votre propre clé) ; l'analyse gérée ne les couvre pas et renvoie `400`.
N'envoyez pas `ETH` pour un autre réseau EVM : la même adresse peut avoir une activité et un risque différents sur chaque chaîne.

Avec l'analyse gérée, `USDT` et `USDC` sont des alias hérités pour Ethereum, et non une recherche sur tous les réseaux où ces jetons existent.
Utilisez l'identifiant de réseau (`ETH`, `TRX`, `SOL`, `MATIC`, `BNB`, `BASE`, `OP`, `ARB`, `AVAX`, `ADA`, `XLM`, `HBAR`, ou avec TRM Labs `CELO`, `MODE` ou `PLUME`) correspondant à la chaîne réelle du portefeuille.
Pour les jetons des transactions enregistrées, conservez le jeton dans `transaction_details.currency` et indiquez le réseau séparément dans `transaction_details.crypto_params.crypto_chain`.
Voir [sélection de l'actif et du réseau](https://docs.didit.me/fr/transaction-monitoring/aml-screening.md#sélection-de-l’actif-et-du-réseau).

> [!WARNING]
>
> `LIGHTNING` n'est disponible que si l'application dispose d'un fournisseur BYOK Elliptic ou Chainalysis connecté dans la **Marketplace** de la console.
> Il n'est pas disponible avec Merkle Science géré, ni avec Crystal ou TRM Labs.
> Les requêtes sans fournisseur connecté pris en charge renvoient `400` et ne sont ni analysées ni facturées.

```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"
  }'
```

## Réponse

La réponse est le résultat de filtrage standardisé. Sa structure est identique à celle du résultat du fournisseur `WALLET_SCREENING` renvoyé par le filtrage des transactions.

| Champ | Type | Description |
| - | - | - |
| `provider` | chaîne | Fournisseur ayant analysé l'adresse (`merklescience`, `crystal`, `chainalysis`, `elliptic`, `trmlabs`). |
| `screening_type` | chaîne | Toujours `WALLET_SCREENING`. |
| `risk_score` | entier | Score de risque normalisé de 0 à 100. Merkle Science attribue à une adresse une note `0-5`, qui correspond à `0`, `15`, `35`, `55`, `75` ou `95`. |
| `severity` | chaîne | Niveau de risque déduit de `risk_score` (voir la note ci-dessous) : `UNKNOWN`, `LOW`, `MEDIUM`, `HIGH` ou `CRITICAL`. |
| `status` | chaîne | `SCREENED`, `PENDING` ou `ERROR`. |
| `summary` | chaîne | Résumé lisible par un humain. |
| `wallet_address` | chaîne | L'adresse analysée. |
| `blockchain` | chaîne | La blockchain analysée. |
| `sanctions_hit` | booléen | `true` lorsque le portefeuille analysé est sous sanctions, ou lorsque les fonds d'une de ses contreparties proviennent d'entités sanctionnées (exposition). Ce champ ne distingue pas les deux cas. |
| `pep_counterparty` | booléen \| null | Exposition à une personne politiquement exposée (PEP). `null` lorsqu'aucun résultat PEP n'est disponible, ce qui est le cas de tous les résultats actuels, car aucun fournisseur n'en transmet ; `false` uniquement pour un résultat de filtrage explicitement négatif. Ne considérez pas `null` comme un contrôle PEP effectué. |
| `dominant_risk_category` | chaîne \| null | Catégorie à haut risque la plus pondérée, ou `null`. |
| `risk_factors` | tableau | Explication classée de `risk_score`, c'est-à-dire les éléments à l'origine de ce verdict. Voir [Facteurs de risque](#facteurs-de-risque). |
| `source_of_funds` | tableau | Origine des fonds reçus, par entité. Voir [Détail de l'exposition](#répartition-de-l’exposition). |
| `destination_of_funds` | tableau | Destination des fonds envoyés, par entité. Même structure d'entrée que `source_of_funds`. |
| `counterparty_connections` | tableau | Entités auxquelles le fournisseur rattache l'adresse. Voir [Connexions avec les contreparties](#connexions-de-contreparties). |
| `network_nodes`, `network_edges` | tableau | Graphe de l'exposition pour le filtrage des transactions. Vide pour un résultat de filtrage du portefeuille. |
| `transaction_hash`, `block_timestamp`, `total_value_usd`, `fee_usd`, `transaction_flows_status`, `transaction_flows_error` | null | Champs du filtrage des transactions, partagés avec la structure du résultat. Toujours `null` pour un résultat de filtrage du portefeuille. |
| `sender_rows`, `receiver_rows`, `transaction_flows` | tableau | Champs du filtrage des transactions. Toujours vides pour un résultat de filtrage du portefeuille. |
| `raw_response` | objet | Le payload propre au fournisseur. Sa structure dépend du fournisseur et peut changer sans préavis : utilisez les champs normalisés ci-dessus plutôt que de l'analyser. |
| `report_signature` | chaîne | Signature opaque de ce résultat, propre à votre application. Renvoyez la réponse sans modification, y compris ce champ, pour [générer un PDF](#rapport-pdf). |

> [!NOTE]
>
> **Comment `severity` est défini.** `severity` correspond à la tranche du `risk_score` normalisé : `0-9` → `UNKNOWN`, `10-39` → `LOW`, `40-69` → `MEDIUM`, `70-89` → `HIGH`, `90-100` → `CRITICAL`. `UNKNOWN` est la tranche la plus basse, et non un état distinct « aucune donnée ». `risk_score: 0` (le cas courant d'une adresse saine) signifie que le fournisseur n'a fourni aucune évaluation défavorable, tandis qu'une valeur non nulle dans la plage `1-9` est un signal réel mais inférieur à `LOW` : lisez donc le `risk_score` lui-même, et pas seulement la tranche. Dans tous les cas, n'affichez pas `UNKNOWN` comme un résultat « clair » ou validé.
>
> **`direction` ne modifie pas le modèle de risque.** Le champ facultatif `direction` est transmis au fournisseur uniquement à titre de contexte. Il n'affecte ni `risk_score`, ni `severity`, ni les listes de détail renvoyées : `source_of_funds` et `destination_of_funds` sont toujours renvoyées. Modifier ou omettre `direction` ne nécessite donc pas de réanalyser une adresse déjà analysée.

### Facteurs de risque

`risk_factors` est la réponse hiérarchisée à la question « pourquoi cette adresse reçoit-elle ce score ». Les fournisseurs notent une adresse selon leur propre modèle et ne renvoient qu'un verdict (Merkle Science renvoie un entier `0-5`), si bien que `risk_score` seul ne permet pas d'agir. Chaque entrée décrit un facteur, les facteurs à haut risque étant classés en premier, puis les autres selon le montant qui y a transité.

| Champ | Type | Description |
| - | - | - |
| `source` | chaîne | `attribution` (ce que le fournisseur indique que l'adresse *est* : sa propre étiquette ou son groupe) ou `exposure` (là où ses fonds ont réellement transité). |
| `category` | chaîne | Catégorie de risque normalisée, avec le même vocabulaire que le détail de l'exposition. |
| `label` | chaîne | La formulation propre au fournisseur, par exemple `Gambling / Crypto only`. Utilisez-la dans une interface : elle correspond à ce que vous verriez dans la console du fournisseur. |
| `entity_name` | chaîne \| null | Entité attribuée, par exemple un site de jeux d'argent ou une plateforme d'échange. Les exemples de cette page utilisent des noms fictifs comme `Example Gambling`. |
| `direction` | chaîne | `incoming`, `outgoing`, `connected`, `attribution` (l'étiquette propre à l'adresse) ou `unknown` lorsque le fournisseur n'a pas indiqué de direction. |
| `exposure_type` | chaîne | `direct` (1 saut), `indirect` (plusieurs sauts), `attribution` (l'étiquette propre à l'adresse) ou `unknown` lorsque le fournisseur n'a pas indiqué à combien de sauts se trouve la contrepartie. Traitez `unknown` comme non classé, jamais comme `direct`. |
| `amount_usd` | nombre \| null | Valeur en USD attribuée à ce facteur. |
| `percentage` | nombre | Part du volume **total** analysé de l'adresse, les deux sens cumulés. Contrairement à `percentage` dans `source_of_funds` et `destination_of_funds`, qui est normalisé par sens, ce champ est comparable et additionnable sur l'ensemble de la liste. |
| `is_high_risk` | booléen | Indique si la catégorie est considérée comme à haut risque par Didit (`sanctioned`, `mixer`, `stolen_funds`, `ransomware`, `scam`, `darknet_market`, `terrorist_financing`, `child_exploitation`, `hacked_exchange`, `high_risk_exchange`, `seized_funds`). |
| `description` | chaîne | Présentation sur une ligne du facteur, par exemple `9.01% indirect outgoing exposure to Gambling / Crypto only (Example Gambling)`. |

> [!NOTE]
>
> **Un score élevé sans facteur `is_high_risk` est un résultat réel et significatif.** Cela signifie que le fournisseur a noté l'adresse selon son propre modèle d'exposition, sans signaler de correspondance avec des sanctions, une PEP ou une entité attribuée. Les facteurs listés sont les flux de fonds à l'origine de la note. `summary` l'indique explicitement : traitez donc ces adresses comme « nécessitant un examen des flux », et non comme une correspondance confirmée. `risk_factors` est limité aux cinq facteurs les plus déterminants ; `source_of_funds` et `destination_of_funds` contiennent toujours le détail complet.

**`risk_factors` est un champ de premier niveau, et non imbriqué.** Les résultats filtrés avant son introduction omettent entièrement la clé : lisez-la comme une liste vide plutôt que de supposer une explication vide.

### Répartition de l'exposition

Chaque entrée de `source_of_funds` / `destination_of_funds` décrit une entité avec laquelle l'adresse a échangé des fonds :

| Champ | Type | Description |
| - | - | - |
| `category` | string | Catégorie de risque normalisée (`exchange_licensed`, `dex`, `defi`, `mixer`, `sanctioned`, `darknet_market`, `stolen_funds`, …). |
| `entity_name` | string \| null | Entité attribuée, par exemple une plateforme d'échange, un mixeur ou un groupe sous sanctions. Les exemples de cette page utilisent des valeurs fictives. |
| `entity_type` | string \| null | Type d'entité fourni par le prestataire (`Exchange`, `DeFi`, `Sanctions`). |
| `entity_subtype` | string \| null | Sous-type précis (`Mandatory KYC and AML`, `OFAC`). |
| `description` | string \| null | `entity_type / entity_subtype`, tel que le prestataire étiquette l'entité. |
| `exposure_direction` | string | `incoming`, `outgoing` ou `connected`. |
| `exposure_type` | string | `direct` (1 saut) ou `indirect` (plusieurs sauts). |
| `is_direct` | boolean | `true` lorsque `exposure_type` vaut `direct`. |
| `amount_usd` | number \| null | Valeur en USD attribuée à l'entité. |
| `percentage` | number | Part de l'exposition totale de la direction (0–100). |
| `hops` | integer \| null | Nombre de sauts jusqu'à l'entité (`1` pour une contrepartie directe), lorsque le prestataire en fournit un. Toujours `null` pour Merkle Science, qui indique seulement si l'exposition est directe ou indirecte : utilisez `exposure_type`. |
| `country` | string \| null | Pays principal de l'entité, au format ISO 3166-1 alpha-2. Vide ou `null` lorsque le prestataire ne le connaît pas. |
| `provider_entity_id`, `provider_entity_type_id`, `provider_entity_subtype_id` | string \| null | Identifiants propres au prestataire pour l'entité et son type. |
| `raw_amount`, `raw_currency` | number \| null, string \| null | Montant dans l'unité propre à l'actif, lorsque le prestataire le fournit. |

### Connexions de contreparties

`counterparty_connections` répertorie les entités auxquelles le prestataire attribue l'adresse analysée. Pour Merkle Science, ces entités proviennent des étiquettes de propriétaire et d'utilisateur de l'adresse elle-même, de sorte que la même entité peut apparaître deux fois. Elles ne contiennent aucun flux de fonds : `received_usd`, `sent_usd`, `received_hops` et `sent_hops` valent `null`, et `percentage` vaut `0.0`. Lisez les flux de fonds dans `source_of_funds` et `destination_of_funds`.

| Champ | Type | Description |
| - | - | - |
| `entity_name` | string \| null | Entité attribuée. |
| `entity_type` | string \| null | Type d'entité fourni par le prestataire. |
| `entity_subtype` | string \| null | Sous-type précis. |
| `categories` | array | Catégories de risque normalisées de l'entité. |
| `risk_level` | string | En minuscules, selon le prestataire. Pour Merkle Science, il s'agit de la note de risque de l'adresse elle-même, sur une échelle de 0 à 5 (`no_risk`, `low`, `medium_low`, `medium`, `high`, `critical`), portée à `high` lorsque la catégorie de l'entité est à haut risque. Ce n'est pas une note distincte attribuée à l'entité. |
| `is_direct` | boolean | Toujours `true` pour Merkle Science, dont les connexions sont des attributions et non des contreparties. |
| `received_usd`, `sent_usd` | number \| null | Montants en USD reçus de l'entité et envoyés à celle-ci, lorsque le prestataire les fournit. |
| `received_hops`, `sent_hops` | integer \| null | Nombre de sauts jusqu'à l'entité dans chaque sens, lorsque le prestataire les fournit. |
| `percentage` | number | Part de l'exposition de l'adresse, lorsque le prestataire la fournit ; sinon `0.0`. |
| `country` | string \| null | Pays de l'entité, lorsqu'il est connu. |
| `provider_entity_id` | string \| null | Identifiant propre au prestataire pour l'entité. |

> [!WARNING]
>
> Ne vous appuyez pas sur `counterparty_connections[].risk_level` ni sur `counterparty_connections[].is_direct` pour orienter vos décisions : pour Merkle Science, le premier reprend la note de risque propre à l'adresse (lisez `risk_score`), et le second vaut toujours `true`. Utilisez `sanctions_hit`, `dominant_risk_category` et `risk_factors[].is_high_risk` pour le verdict, et `exposure_type` dans `source_of_funds` / `destination_of_funds` pour savoir si l'exposition est directe.

### Exemple

Une réponse réelle pour une adresse figurant sur la liste de sanctions OFAC, filtrée avec Merkle Science. Seuls `raw_response` et `report_signature` ont été modifiés : le premier a été raccourci et la seconde remplacée :

```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>"
}
```

Les exemples illustrent la structure de la réponse, et non un verdict garanti pour une adresse réelle.
Les scores de risque et l'exposition aux sanctions dépendent du réseau sélectionné, des renseignements actuels et de la politique de risque configurée.
Une attribution à une plateforme d'échange n'implique pas un score de risque nul : un portefeuille d'échange peut présenter une exposition aux sanctions via ses flux de fonds.
`sanctions_hit: true` peut indiquer que le portefeuille lui-même est sous sanctions, ou seulement que ses fonds présentent une exposition aux sanctions. Cela ne signifie donc pas à lui seul que le titulaire du portefeuille analysé est sous sanctions.
Lorsque le même filtrage s'exécute sur une transaction enregistrée, les règles peuvent aussi lire `custom_values.wallet_sanctioned`, qui n'est `true` que si le prestataire attribue le portefeuille lui-même à une entité sous sanctions, ainsi que `custom_values.aml_sanctions_exposure_pct`.
Voir [Champs de filtrage pour les règles](https://docs.didit.me/fr/transaction-monitoring/aml-screening.md#champs-de-filtrage-pour-les-règles).
Lisez `risk_factors`, `source_of_funds` et `destination_of_funds` pour distinguer l'attribution de l'exposition.
Voir [Filtrage crypto et des portefeuilles](https://docs.didit.me/fr/transaction-monitoring/aml-screening.md#résultats-du-filtrage) pour un guide pas à pas.

## Rapport PDF

Pour obtenir un PDF aux couleurs de Didit d'un résultat de filtrage, renvoyez à l'identique le corps de la réponse, y compris `report_signature`, à `POST /v3/wallet-screening/pdf/`. Cette opération est sans état : aucun appel au prestataire, aucune facturation supplémentaire, et rien n'est conservé. Toute modification d'un champ signé (`risk_score`, `severity`, `sanctions_hit`, …) avant le renvoi échoue avec `400`.

```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
```

Voir [PDF du filtrage de portefeuille](https://docs.didit.me/fr/management-api/transactions/screen-wallet-pdf.md) pour le schéma complet des requêtes et des réponses, ainsi que la forme des erreurs.

## Facturation

Une utilisation de la surveillance AML est facturée par filtrage réussi, au même tarif que le filtrage crypto couplé aux transactions. Consultez [tarifs](https://docs.didit.me/fr/transaction-monitoring/aml-screening.md#fournisseurs-pris-en-charge) pour les tarifs en mode géré et avec clé connectée. Les applications sandbox ne sont pas facturées. Les erreurs de validation (`400`) et les erreurs de fournisseur non configuré (`409`) ne sont jamais facturées.

## Erreurs

| Statut | Signification |
| - | - |
| `400` | Adresse mal formée, `wallet_address` absent ou `blockchain` non pris en charge. |
| `401` | `x-api-key` absent ou invalide. |
| `409` | Aucun fournisseur AML configuré pour l'application : configurez d'abord la surveillance des transactions. |
| `409` | Le fournisseur a rejeté la clé API que vous avez connectée (`wallet_screening_provider_credentials_rejected`) : mettez à jour la clé dans la connexion Marketplace, ou dans les paramètres de surveillance des transactions pour une clé configurée à cet endroit. Réessayer avec la même clé ne sert à rien. |
| `409` | Le fournisseur AML configuré ne prend pas encore en charge le filtrage des portefeuilles (`wallet_screening_provider_unavailable`). |
| `422` | Une adresse `0x` a été envoyée sans `blockchain` (`wallet_screening_chain_undetermined`). Le corps de la réponse liste `candidate_chains` ; renvoyez la requête avec l'une d'elles. Rien n'est filtré ni facturé. |
| `502` | Le fournisseur n'a pas pu terminer le filtrage ; réessayez plus tard. |

## Étapes suivantes

> [card] [Référence de l'API](https://docs.didit.me/fr/management-api/transactions/screen-wallet.md)
>
> Schéma complet de la requête et de la réponse pour l'endpoint Screen Wallet.

> [card] [PDF Screen Wallet](https://docs.didit.me/fr/management-api/transactions/screen-wallet-pdf.md)
>
> Générez le résultat d'un filtrage sous la forme d'un PDF aux couleurs de Didit.

> [card] [Filtrage crypto et des portefeuilles](https://docs.didit.me/fr/transaction-monitoring/aml-screening.md)
>
> Filtrage automatique lors de la création d'une transaction, et modèle de résultat.


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