Flux de travail SAR intégré : Une approche unifiée (FR)

Le déclenchement d'une règle est la partie facile. Ce qui se passe après — l'alerte, l'enquête, l'escalade, la décision de déposer une Déclaration d'Activité Suspecte (SAR) — est là où la plupart des opérations de conformité se déroulent réellement, et où la majeure partie du coût se cache. La configuration typique relie trois choses : un fournisseur de surveillance qui produit des alertes, un outil de gestion de cas séparé qui gère l'enquête, et un processus SAR manuel qui se termine souvent par une feuille de calcul et un PDF. Les données sont ressaisies entre les systèmes, la piste d'audit se fragmente, et les analystes passent leur journée à changer d'onglet.

L'API de surveillance des transactions de Didit intègre l'ensemble du flux de travail dans un seul produit. Lorsqu'une règle se déclenche, une alerte s'ouvre ; les alertes se regroupent en dossiers ; les analystes sont affectés ; et la SAR est déposée depuis la même console où l'alerte a été générée. Il n'y a pas d'outil de cas séparé à licencier, intégrer ou réconcilier — et les transactions qui l'alimentent coûtent 0,02 $ chacune.

Ce guide décrit le flux de travail, d'une règle déclenchée à une SAR déposée.

Points clés à retenir

• Les alertes s'ouvrent automatiquement lorsqu'une règle se déclenche et suivent un cycle de vie défini : OUVERT, EN_ENQUÊTE, EN_ATTENTE_UTILISATEUR, SAR_EN_ATTENTE, SAR_DÉPOSÉE, RÉSOLU, REJETÉ.
• Les dossiers regroupent les alertes connexes, portent une priorité et une gravité, et suivent une enquête à travers OUVERT, EN_EXAMEN, EN_ATTENTE_UTILISATEUR, EN_SUSPENS, et RÉSOLU.
• Les analystes sont affectés aux alertes et aux dossiers, de sorte que la propriété et la performance sont mesurables.
• Le dépôt de SAR se fait dans la même console que l'alerte — pas d'exportation vers un outil séparé, pas de données ressaisies.
• Le chemin EN_ATTENTE_UTILISATEUR permet à un analyste de renvoyer une alerte à l'utilisateur pour correction au lieu de la résoudre manuellement.
• 0,02 $ par transaction, sans minimum. Le filtrage AML sur une partie signalée est facturé séparément à 0,20 $.

Ce que fait le flux de travail de gestion de cas

La surveillance des transactions produit des signaux ; la gestion de cas les transforme en décisions défendables. Chaque alerte dans Didit porte une source — déclenchée par une règle, déclenchée par un fournisseur, ou créée par un analyste — et un statut qui reflète sa position dans l'enquête. Un analyste ouvre l'alerte, examine la transaction et les règles qui se sont déclenchées, et décide : la rejeter comme un faux positif, la résoudre, l'escalader en un dossier, la renvoyer à l'utilisateur, ou la faire progresser vers une SAR.

Les dossiers sont le conteneur pour tout ce qui est plus grand qu'une seule alerte. Plusieurs alertes sur le même utilisateur — un pic de vitesse le lundi, un signalement de contrepartie sanctionnée le mercredi — se regroupent en un seul dossier qui contient l'ensemble de l'image, avec sa propre priorité et gravité. Le dossier est ce sur quoi un enquêteur travaille, et le dossier est ce qui documente la décision de l'entreprise.

Pourquoi c'est important

Les régulateurs ne s'attendent pas seulement à ce que vous détectiez les activités suspectes — ils s'attendent à ce que vous les enquêtiez et les signaliez, et à ce que vous montriez une piste d'audit propre de la façon dont vous êtes passé de l'alerte à la décision. Une pile fragmentée vous dessert à tous les égards. La ressaisie des données entre un fournisseur de surveillance et un outil de cas introduit des erreurs. Un processus SAR sur feuille de calcul est impossible à auditer et lent à défendre. Et chaque jointure d'intégration est un endroit où une alerte peut passer inaperçue.

La fusion de la pile en un seul produit résout à la fois le problème opérationnel et réglementaire. L'alerte, l'enquête, l'analyste qui en était responsable et la SAR vivent tous dans le même enregistrement. La piste d'audit est continue car rien ne quitte le système. Et le coût évolue avec les transactions, et non avec les licences par poste pour un outil de cas que vous devez également maintenir.

Détails techniques

Lorsqu'une règle se déclenche sur une transaction, la réponse contient le statut et un alert_id :

{
  "transaction_id": "txn_3c81f0",
  "status": "IN_REVIEW",
  "risk_score": 64,
  "triggered_rules": [
    { "name": "Sanctioned counterparty", "bundle": "AML/CTF", "action": "CHANGE_STATUS" }
  ],
  "alert_id": "alrt_77a920"
}

La transaction elle-même est créée via l'API unifiée /v3/, idempotente sur un transaction_id que vous contrôlez :

curl -X POST https://verification.didit.me/v3/transactions/ \
  -H "x-api-key: $DIDIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "transaction_id": "txn_3c81f0",
    "category": "finance",
    "amount": 24000,
    "currency": "EUR",
    "currency_kind": "fiat",
    "txn_date": "2026-05-21T14:50:00Z",
    "subject": { "vendor_data": "user_6610", "role": "SENDER", "entity_type": "INDIVIDUAL" },
    "counterparty": { "role": "RECEIVER", "entity_type": "INDIVIDUAL" }
  }'

Statuts d'alerte. OUVERT → EN_ENQUÊTE → (EN_ATTENTE_UTILISATEUR) → SAR_EN_ATTENTE → SAR_DÉPOSÉE, ou se termine par RÉSOLU ou REJETÉ.

Statuts de dossier. OUVERT, EN_EXAMEN, EN_ATTENTE_UTILISATEUR, EN_SUSPENS, RÉSOLU.

Webhooks. Abonnez-vous à transaction.created et transaction.status.updated afin que vos systèmes restent synchronisés lorsqu'un analyste fait progresser une alerte dans le flux de travail.

Prix. 0,02 $ par transaction. Le filtrage AML effectué sur une partie signalée pendant une enquête est facturé séparément à 0,20 $.

De l'alerte à la SAR déposée

1. L'alerte s'ouvre. Une règle se déclenche, la transaction passe à IN_REVIEW, et une alerte s'ouvre en état OUVERT avec les règles déclenchées attachées.
2. L'analyste la prend en charge. L'alerte passe à EN_ENQUÊTE et est assignée à un analyste, qui examine l'historique des transactions, le contexte de vitesse et tout filtrage AML.
3. Escalader ou corriger. L'analyste regroupe les alertes connexes dans un dossier, ou pousse l'alerte à EN_ATTENTE_UTILISATEUR afin que le client puisse la clarifier avec une preuve de fonds ou une nouvelle vérification.
4. Décider d'une SAR. Si l'activité justifie un rapport, l'alerte passe à SAR_EN_ATTENTE, la SAR est préparée dans la même console, et lors du dépôt, l'alerte passe à SAR_DÉPOSÉE.
5. Clôturer. Les alertes qui ne justifient pas d'action sont résolues comme REJETÉ (faux positif) ou RÉSOLU. L'intégralité de la piste — qui a décidé quoi, quand — reste enregistrée.

Parce que les alertes peuvent passer à EN_ATTENTE_UTILISATEUR, l'enquête et la boucle d'autorégulation partagent la même interface : un analyste peut renvoyer une alerte limite à l'utilisateur plutôt que d'y consacrer du temps, et l'alerte reprend automatiquement une fois que l'utilisateur répond.

Cas d'utilisation

• Fintech — regrouper les alertes de vitesse, de structuration et de sanctions sur un seul compte dans un seul dossier avant de décider d'une SAR.
• Crypto — enquêter sur les alertes déclenchées par l'exposition au filtrage de portefeuille ainsi que sur la vitesse on-chain dans le même dossier.
• Prêt — traiter les alertes de fraude (mule, identité synthétique) jusqu'à une décision documentée sans un deuxième outil.
• Marketplaces — consolider les alertes d'abus de remboursement et de rétrofacturation sur un vendeur dans un dossier, puis déposer ou rejeter.
• iGaming — gérer les alertes de jeu responsable et AML dans un seul flux de travail, avec la propriété de l'analyste et une piste d'audit.

Comment intégrer Didit

1. Activez vos bundles. Dans la console d'entreprise, activez les bundles de règles qui conviennent à votre entreprise afin que les alertes s'ouvrent en fonction des typologies appropriées.
2. Envoyez les transactions. POST /v3/transactions/ au fur et à mesure que l'argent circule, avec un transaction_id stable et des vendor_data reliant chacun à son utilisateur ou entité.
3. Traitez les alertes dans la Console. Enquêter, assigner des analystes, regrouper les alertes en dossiers et déposer des SAR — tout depuis la même interface.
4. Synchronisez avec les webhooks. Écoutez transaction.status.updated afin que vos propres systèmes reflètent les changements d'état des alertes et des dossiers.

Parce que tout est sur l'API unifiée /v3/, une session KYB peut générer les sessions KYC pour ses UBO, ces utilisateurs passent à la surveillance des transactions, et une transaction signalée peut générer un KYC de correction — une plateforme d'identité et de fraude, de bout en bout.

Questions fréquemment posées

Ai-je besoin d'un outil de gestion de cas séparé ?

Non. Les alertes, les dossiers, l'affectation des analystes, les états d'enquête et le dépôt des SAR sont intégrés au même produit et à la même console.

Quels sont les états par lesquels passe une alerte ?

OUVERT, EN_ENQUÊTE, EN_ATTENTE_UTILISATEUR, SAR_EN_ATTENTE, SAR_DÉPOSÉE, RÉSOLU et REJETÉ. Les dossiers passent par OUVERT, EN_EXAMEN, EN_ATTENTE_UTILISATEUR, EN_SUSPENS et RÉSOLU.

Puis-je attribuer des alertes à des analystes spécifiques ?

Oui. Les alertes et les dossiers sont attribués aux analystes, de sorte que la propriété est claire et la performance mesurable.

Où la SAR est-elle déposée ?

Dans la même console où l'alerte a été générée. Il n'y a pas d'exportation vers un outil séparé ni de données ressaisies, ce qui assure la continuité de la piste d'audit.

Quel est le coût ?

0,02 $ par transaction, facturé par appel sans minimum. Le filtrage AML effectué sur une partie signalée pendant une enquête est facturé séparément à 0,20 $.

Prêt à commencer ?

Lisez l'aperçu de la surveillance des transactions dans la documentation, découvrez comment cela s'intègre au reste de la plateforme sur la page produit de la surveillance des transactions, et vérifiez les prix transparents par appel sur la page de tarification. Lorsque vous êtes prêt, commencez gratuitement — 500 vérifications KYC gratuites chaque mois, et la surveillance des transactions à 0,02 $ par appel.