Cas d'usage · Conformité & LCB-FT

API de vigilance continue

Transformez l'obligation de vigilance continue de l'AMLR en tâche planifiée : revérifiez chaque client professionnel selon un cycle fondé sur le risque, surveillez les événements déclencheurs au quotidien, et re-criblez les listes de sanctions automatiquement — avec une piste d'audit à présenter à un régulateur.

Publié le 15 septembre 2026

Le problème

Les équipes conformité et LCB-FT des fintechs, prestataires de services de paiement, PSAN, prêteurs et marketplaces exécutent déjà le KYB à l'entrée en relation : résoudre l'entreprise, la cribler, décider. L'angle mort, c'est l'après. Le règlement européen AMLR (Règlement (UE) 2024/1624), applicable à partir du 10 juillet 2027, est explicite : le dossier d'un client professionnel doit rester à jour — revérifié selon un cycle fondé sur le risque, mis à jour dès qu'un événement survient. Les transpositions actuelles des directives AMLD5/6 vont déjà dans ce sens, tout comme le UK MLR 2017 pour les entités régulées au Royaume-Uni.

En pratique, la plupart des équipes traitent la revérification comme un exercice annuel sur tableur : exporter la liste, revérifier chaque entreprise à la main, espérer que rien n'a bougé entretemps. Un dirigeant démissionne ou un client entre en procédure collective huit mois après le début du cycle, et personne ne s'en aperçoit avant la revue programmée suivante — ou avant qu'un régulateur ne demande la piste d'audit, et qu'il n'y en ait pas.

Cette page décrit ce que l'obligation demande en termes généraux, pas un conseil juridique ; voir le calendrier de conformité AMLR (en anglais) pour les dates et les seuils.

Le schéma

Exécutez les mêmes contrôles qu'à l'entrée en relation, mais sur un calendrier plutôt qu'une seule fois. Quatre endpoints font le travail, plus un élément à conserver de votre côté :

• 1. Revue périodique déclenchée par le calendrier. Re-résoudre chaque client avec POST /companies/lookup (jusqu'à 100 éléments par appel) et comparer status, dissolution_date, address, legal_form et previous_names au dossier stocké à l'entrée en relation — annuellement pour les clients à faible risque, trimestriellement pour les clients à risque élevé.
• 2. Surveillance déclenchée par événement. POST /monitor pousse des webhooks signés HMAC-SHA256 (X-Prometiam-Signature) pour tous les pays servis sauf la France et le Chili : l'Espagne a par défaut corporate_event, status_change et sanctions_match ; l'Irlande et la Pologne (niveau société) ont par défaut status_change, dissolution et sanctions_match. Pour les clients français, il n'y a pas de webhook : une revue quotidienne via GET /company-events/search?date_from= couvre l'Espagne, la France et le Royaume-Uni, pour les dissolutions, procédures collectives, changements de dirigeants, de capital, de nom et d'adresse.
• 3. Re-criblage sanctions. GET /sanctions/changes?since= signale ce qui a été inscrit, radié ou mis à jour depuis le dernier passage ; POST /sanctions/screen re-vérifie ensuite le portefeuille dû pour ce cycle, jusqu'à 50 noms par appel.
• 4. Procédures collectives. POST /insolvency/check couvre les procédures collectives d'entreprise sur seize marchés (FR, DE, GB, AT, CH, NO, FI, US, NL, DK, HR, SE, ES, LV, EE, SG) en un seul appel groupé, jusqu'à 5 avis par élément. L'Allemagne, l'Autriche, les États-Unis et les Pays-Bas n'ont pas de registre d'entreprises derrière ces avis, c'est donc le seul signal disponible pour ces marchés. La Finlande, le Danemark, la Croatie, la Suède, l’Espagne, la Lettonie et l’Estonie disposent de fiches d'entreprise (données d'entreprise uniquement : sans dirigeants, avec des événements de changement du registre et la surveillance) et leurs avis y sont rattachés par l'identifiant d'entreprise (numéro CVR au Danemark, MBS en Croatie, organisationsnummer en Suède, NIF en Espagne, numéro d'enregistrement en Lettonie, code du registre en Estonie). La Slovaquie et les États-Unis sont aussi au niveau société uniquement (avec des événements de changement du registre et la surveillance), mais sans avis d'insolvabilité : leur faillite apparaît dans le statut de l'entreprise. La Suisse dispose elle aussi de fiches d'entreprise, et ses avis y sont rattachés par l'UID lorsque l'avis nomme l'UID du débiteur.
• 5. Piste d'audit. Stockez chaque réponse avec son match_score, le threshold utilisé, et la date de revue — le dossier qu'un régulateur demandera à voir.

# 1. Re-résoudre jusqu'à 100 clients par appel et comparer au dossier stocké
curl -X POST 'https://api.prometiam.com/functions/v1/risk-api/companies/lookup' \
  -H 'Authorization: Bearer rk_live_...' -H 'Content-Type: application/json' \
  -d '{"items":[{"country":"FR","siren":"552032534"},{"country":"ES","company_number":"A28015865"}]}'

# 2. Qu'est-ce qui a bougé sur les listes de sanctions depuis le dernier passage ?
curl 'https://api.prometiam.com/functions/v1/risk-api/sanctions/changes?since=2026-08-15' \
  -H 'Authorization: Bearer rk_live_...'

# 3. Procédures collectives sur les seize marchés couverts, même format de lot
curl -X POST 'https://api.prometiam.com/functions/v1/risk-api/insolvency/check' \
  -H 'Authorization: Bearer rk_live_...' -H 'Content-Type: application/json' \
  -d '{"items":[{"country":"FR","siren":"552032534"},{"country":"GB","name":"Example Ltd"}]}'

Deux subtilités à connaître. Les fiches françaises peuvent revenir avec status: non_diffusible lorsque l'INSEE a restreint la publication de l'identité de l'entité — à traiter comme une valeur inconnue, pas comme un changement de statut. Et GET /sanctions/changes est un signal, pas une recherche : il indique ce qui a bougé sur les listes, pas lesquels de vos clients sont concernés, donc le schéma pratique consiste à re-cribler le portefeuille dû pour ce cycle dès que le flux montre une activité. Le criblage PPE reste en bêta, limité à l'Espagne, sans parents ni proches associés, donc un résultat PPE négatif n'est pas à lui seul une conclusion FATF. Pour cribler une grande liste en un seul appel, voir le criblage par lot (en anglais).

Un exemple concret

Le job de revue : résolution par lot, comparaison, re-criblage conditionnel, vérification des procédures collectives, et journalisation de chaque résultat. Un planificateur — cron, un Cloudflare Cron Trigger, ou un worker de file d'attente — appelle review() une fois par jour avec les clients dus selon le calendrier.

import os, requests
from datetime import date

API = 'https://api.prometiam.com/functions/v1/risk-api'
HEAD = {'Authorization': f'Bearer {os.environ["PROMETIAM_API_KEY"]}'}
TRACKED = ('status', 'dissolution_date', 'address', 'legal_form', 'previous_names')
SEIZE_MARCHES = {'FR', 'DE', 'GB', 'AT', 'CH', 'NO', 'FI', 'US', 'NL', 'DK', 'HR', 'SE', 'ES', 'LV', 'EE', 'SG'}

def review(customers, last_run):
    # 1. Re-résoudre jusqu'à 100 clients à la fois ; comparer les champs suivis au dossier stocké
    for i in range(0, len(customers), 100):
        chunk = customers[i:i + 100]
        items = [{'country': c['country'], 'company_number': c['company_number']} for c in chunk]
        r = requests.post(f'{API}/companies/lookup', json={'items': items}, headers=HEAD).json()
        for stored, result in zip(chunk, r['data']):
            company = result.get('company') or {}
            changed = {f: company.get(f) for f in TRACKED if company.get(f) != stored.get(f)}
            audit(stored, 'lookup', result, changed or None)

    # 2. Ne re-cribler que si une liste de sanctions a bougé depuis le dernier passage
    changes = requests.get(f'{API}/sanctions/changes', params={'since': last_run}, headers=HEAD).json()
    if changes.get('data'):
        names = [c['legal_name'] for c in customers]
        batch = requests.post(f'{API}/sanctions/screen', headers=HEAD,
                               json={'names': names, 'threshold': 85, 'group': 'entity'}).json()
        for stored, hit in zip(customers, batch['data']):
            audit(stored, 'sanctions', hit, threshold=85)

    # 3. Procédures collectives, seize marchés uniquement
    watched = [c for c in customers if c['country'] in SEIZE_MARCHES]
    if watched:
        items = [{'country': c['country'], 'company_number': c['company_number']} for c in watched]
        r = requests.post(f'{API}/insolvency/check', json={'items': items}, headers=HEAD).json()
        for stored, result in zip(watched, r['data']):
            if result['status'] == 'found':
                audit(stored, 'insolvency', result)

def audit(customer, check, response, changed=None, threshold=None):
    # 4. Ajout uniquement : la réponse brute, le score/seuil utilisé, et la date du jour
    db.review_log.insert({'customer_id': customer['id'], 'check': check, 'response': response,
                           'match_score': response.get('best_match_score'), 'threshold': threshold,
                           'changed_fields': changed, 'reviewed_on': date.today().isoformat()})

42 lignes, imports compris. db et les lignes clients sont votre propre stockage — Prometiam n'a aucune notion de « votre portefeuille » ; il résout, crible et vérifie ce qui lui est envoyé.

Ce que renvoie l'API

Chaque contrôle renvoie un statut à traiter, plus le détail qu'une piste d'audit doit conserver :

• POST /companies/lookup — status (found / not_found / error / timeout) et, si trouvé, l'objet entreprise habituel : status, dissolution_date, address, legal_form, previous_names, et un match_score normalement nul ici puisque l'appel résout par identifiant.
• POST /sanctions/screen — status (match / clear / error / timeout) par nom, hits[], hit_count, distinct_entities, et un best_match_score — à journaliser à côté du threshold utilisé.
• POST /insolvency/check — status (found / none / error / timeout), jusqu'à 5 notices[] les plus récentes en premier, et latest_filing_date. none signifie qu'aucun avis d'entreprise n'existe sur les seize marchés couverts — pas une preuve de solvabilité.
• Webhooks POST /monitor — alert_type (corporate_event / status_change / dissolution / sanctions_match), event_date, un objet detail, et webhook_status.

www.prometiam.com/dashboard/monitoring

Adéquation tarifaire

Prenez un portefeuille de 5 000 clients. La revérification annuelle représente 5 000 éléments POST /companies/lookup par an — négligeable face à un quota mensuel. Le re-criblage trimestriel du même portefeuille représente 5 000 × 4 = 20 000 éléments POST /sanctions/screen par an, pouvant se concentrer en une pointe allant jusqu'à 5 000 sur un seul mois. Le vrai moteur, c'est la revue quotidienne déclenchée par événement : 1 500 noms espagnols, français et britanniques interrogés une fois par jour via GET /company-events/search représente environ 45 000 appels par mois, soit 90 000 crédits à 2 crédits par appel. Ajoutez une pointe de criblage de fin de trimestre par-dessus (jusqu'à 5 000 noms à 3 crédits, 15 000) et le mois le plus chargé se situe autour de 105 000 crédits — au-delà de l'offre Scale (99,99 €/mois, 50 000 crédits par mois, 300 requêtes/minute) : négociez une enveloppe Enterprise ou passez la revue sur webhooks. Le même schéma sur un portefeuille de 500 clients représente environ 9 000 crédits pour la revue plus une pointe de criblage de 1 500, soit 10 500 le mois le plus chargé : la limite de l'offre Professional (29,99 €/mois, 10 000 crédits par mois, 120 requêtes/minute), avec Scale confortablement au-dessus.

Une autre limite à anticiper : POST /monitor plafonne les abonnements actifs par offre (Gratuit 3, Starter 25, Professional 250, Scale 2 500). Un portefeuille de 5 000 clients avec tous les noms d'un pays surveillé (tous les pays servis sauf la France et le Chili) sous surveillance webhook dépasse même le plafond de l'offre Scale (99,99 €/mois) ; placez le sous-ensemble à plus haut risque sous webhook et laissez le reste à la revue quotidienne ou à un passage planifié sur GET /search.

Les limites, dites clairement

• Les avis d'insolvabilité sont uniquement d'entreprise, sur seize marchés (FR, DE, GB, AT, CH, NO, FI, US, NL, DK, HR, SE, ES, LV, EE, SG). Les procédures concursales espagnoles restent aussi consultables sur GET /search.
• La surveillance par webhook (POST /monitor) couvre tous les pays servis sauf la France et le Chili, avec un plafond d'abonnements actifs par offre. Pour les clients français, il n'existe pas de webhook : le schéma est une revue quotidienne via GET /company-events/search?country=FR&date_from=, pas une notification en temps réel.
• Le criblage de sanctions est en bêta. Le criblage PPE est en bêta, limité à l'Espagne, et ne contient ni parents ni proches associés — un résultat négatif n'est pas à lui seul une conclusion PPE FATF.
• L'Irlande est au niveau société : il n'y a pas encore de dirigeants à revérifier, donc la comparaison périodique se limite à la fiche entreprise.
• La Norvège n'a que des événements de changement du registre, depuis le 14 octobre 2026 (sans bulletin), et POST /monitor la couvre : les clients norvégiens reçoivent des webhooks (statut, dissolution, sanctions, changements du registre) ; les procédures collectives se vérifient à part.
• Rien de ceci n'est un conseil juridique. Cette page décrit ce que renvoie l'API ; la question de savoir si un programme satisfait l'AMLR, les AMLD5/6 ou le UK MLR 2017 relève de votre fonction conformité — voir le calendrier de conformité AMLR (en anglais).

Questions fréquentes

Que signifie la « vigilance continue » au sens de l'AMLR ?
Le règlement européen AMLR (Règlement (UE) 2024/1624, applicable à partir du 10 juillet 2027) traite le dossier d'un client professionnel comme quelque chose à maintenir à jour, pas comme un contrôle ponctuel à l'entrée en relation : revérifiez selon un cycle fondé sur le risque et agissez sur les événements déclencheurs, comme une dissolution ou un nouveau résultat de criblage sanctions. Ceci décrit l'obligation en termes généraux, pas un conseil juridique — voir le calendrier de conformité AMLR (en anglais).

À quelle fréquence faut-il revérifier un client professionnel ?
Une cadence courante fondée sur le risque est annuelle pour les clients à faible risque et trimestrielle pour les clients à risque élevé, en ré-exécutant les mêmes contrôles qu'à l'entrée en relation. La cadence exacte relève d'une décision de votre fonction conformité.

Le re-criblage sanctions peut-il être automatisé ?
Oui : GET /sanctions/changes?since= signale ce qui a été inscrit, radié ou mis à jour depuis le dernier passage, et POST /sanctions/screen re-vérifie jusqu'à 50 noms par appel. Le criblage de sanctions est en bêta ; le criblage PPE est en bêta, limité à l'Espagne, et ne contient ni parents ni proches associés, donc un résultat négatif n'est pas à lui seul une conclusion FATF.

La vigilance continue fonctionne-t-elle de la même façon dans tous les pays ?
Non. Les webhooks POST /monitor couvrent tous les pays servis sauf la France et le Chili. GET /company-events/search couvre l'Espagne, la France et le Royaume-Uni, plus les événements de changement du registre pour les autres pays servis (aucun avant le 14 octobre 2026 pour l’Irlande, la Pologne et la Norvège). Pour les clients français, il n'y a donc pas de webhook : le schéma est une revue quotidienne via GET /company-events/search. La Norvège n'a que des événements de changement du registre, depuis le 14 octobre 2026 (sans bulletin), et POST /monitor la couvre ; les procédures collectives se vérifient à part. L'Irlande est au niveau société, sans dirigeants à revérifier pour l'instant.

Que se passe-t-il si un lot de revue dépasse mon quota restant ?
POST /companies/lookup, POST /sanctions/screen et POST /insolvency/check comptent chaque élément comme une requête. Un lot supérieur à ce qu'il reste sur votre offre est refusé d'emblée avec un 429 (batch_exceeds_quota) et max_items_now, ce qui permet de redimensionner l'appel plutôt que de perdre des résultats partiels.

À lire aussi

• Prometiam en français — l'accueil du site en français
• Onboarding KYB — l'étape de vérification en amont que ce job revérifie
• Qu'est-ce que le BODACC ?
• API BODACC avec Node.js (en anglais)
• Ongoing Due Diligence (édition anglaise)
• Le calendrier de conformité AMLR (en anglais)
• Tarifs
• Pour les fintechs · pour les prestataires de paiement