Correspondances indirectes : le proche derrière l’alerte

Une alerte PPE peut concerner quelqu’un d’autre que votre client. Votre cliente n’a jamais exercé de fonction publique, mais son mari est ministre. Son nom figure dans le profil de celui-ci, et le screening le trouve.

L’API Smart Oversight indique désormais, dans l’alerte, à quel proche de la personne listée correspond votre client et quel est leur lien de parenté.

Qu’est-ce qu’une correspondance indirecte ?

La Recommandation 12 du GAFI étend aux membres de la famille des PPE les mesures prévues pour les PPE elles-mêmes. Comparer le nom de votre client aux seuls noms listés ne suffit donc pas. Smart Oversight le compare aussi aux proches cités dans chaque profil, qu’il s’agisse du conjoint, d’un enfant, d’un parent, d’un frère ou d’une sœur.

Quand le nom de votre client correspond à l’un de ces proches, l’alerte est levée sur la personne listée. C’est ce qu’on appelle une correspondance indirecte. L’alerte montre alors le profil de la personne listée, et l’analyste lit « John Doe, ministre des Finances » dans le dossier de Jane Doe.

Dans la réponse de l’API

Une clé d’API qui dispose du droit (scope) alerts:read lit une alerte à partir de son identifiant.

GET /v2/alerts/alr_66f1a2b3c4d5e6f708194000
Authorization: Bearer <votre clé d’API>

Pour une correspondance sur une liste de sanctions ou de PPE, l’objet match décrit la personne listée avec name, aliases, dates_of_birth, places_of_birth, nationalities et positions. S’y ajoutent occupations et description pour une PPE, sanction_programs pour une sanction. Le nouveau champ s’appelle match.indirect. L’extrait ci-dessous utilise des données fictives.

{
  "object": "alert",
  "id": "alr_66f1a2b3c4d5e6f708194000",
  "client": "cli_66f1a2b3c4d5e6f708192a3b",
  "media": "PEP_LIST",
  "targets": ["PEP"],
  "status": "OPEN",
  "resolution": "UNRESOLVED",
  "match": {
    "type": "pep_entity",
    "name": "John Doe",
    "aliases": ["Johnny Doe"],
    "dates_of_birth": [
      { "value": "1962-03-14", "precision": "day", "raw": "14/03/1962" }
    ],
    "places_of_birth": ["Springfield"],
    "nationalities": ["Freedonia"],
    "positions": ["Minister of Finance"],
    "occupations": ["Politician"],
    "description": ["Member of the national government since 2019"],
    "indirect": { "relation": "spouse", "name": "Jane Doe" }
  },
  "created_at": "2026-09-14T08:12:40.000Z",
  "resolved_at": null
}

Jane Doe est ici la conjointe de John Doe. name reprend le nom du proche tel qu’il est écrit dans le profil, et relation donne son lien avec la personne listée, parmi spouse (conjoint), child (enfant), parent et sibling (frère ou sœur).

Quand indirect vaut null, le nom de votre client correspond directement à la personne listée. Quand le champ manque, le type de correspondance n’est pas connu. C’est le cas des correspondances enregistrées avant ce changement. L’API ne fait jamais passer un cas inconnu pour une correspondance directe, et un champ absent ne doit donc pas être lu ainsi.

Le même objet match se retrouve dans GET /v2/alerts et GET /v2/clients/{ref}/alerts. Ces deux listes se filtrent par status (OPEN, DONE, VALIDATED) et par media (SANCTIONS_LIST, PEP_LIST, INTERNET_SCREENING). Le webhook envoyé quand une décision est prise sur une alerte contient lui aussi le champ.

La recherche internet fonctionne autrement. Ses correspondances n’ont pas d’objet match et renvoient l’adresse de la page dans page_url. Les correspondances indirectes ne concernent donc que les listes.

L’afficher dans votre CRM

Dans votre intégration, chaque cas reçoit son libellé.

const RELATIONS = {
  spouse: 'conjoint(e)',
  child: 'enfant',
  parent: 'parent',
  sibling: 'frère ou sœur',
};

function libelleCorrespondance(match) {
  if (!('indirect' in match)) {
    return `Correspondance possible avec ${match.name}. Type non communiqué.`;
  }
  if (match.indirect === null) {
    return `Correspondance directe avec ${match.name}.`;
  }
  const { relation, name } = match.indirect;
  return `Correspondance indirecte : ${name}, ${RELATIONS[relation]} de ${match.name}.`;
}

Placez cette ligne en haut de la fiche d’alerte, avant les fonctions de la personne listée. L’analyste lit ainsi le lien de parenté avant le profil. Si le champ est absent, affichez le profil seul et laissez l’analyste vérifier la liste source.

Enregistrer la décision

La décision repart par POST /v2/alerts/{id}/review, avec un status, une resolution et, si vous le souhaitez, un comment. Choisissez NOT_RELATED_TO_CLIENT quand le proche cité dans le profil n’est pas votre client, et TRUE_RELEVANT ou TRUE_NOT_RELEVANT quand il l’est.

Le commentaire s’ajoute à celui de l’alerte sans le remplacer. Notez-y le lien de parenté.

Passer une alerte au statut VALIDATED demande le droit alerts:validate. Une décision prise au nom d’un collaborateur ne peut être validée que si ce collaborateur est votre responsable LCB/FT (MLRO). L’article Des décisions nominatives via l’API explique comment indiquer qui a pris la décision.

La page Intégrations présente ce que couvre l’API Smart Oversight. Notre guide pour connecter votre screening KYC & LCB/FT à votre CRM montre comment réunir toutes ces fonctions dans une seule intégration.