Commencer
Intégrer / SDK
Vérification des utilisateurs
Vérification d'entreprise
Surveillance des transactions
Journal des modificationsParamètres généraux
Seuils de score
Les seuils de score déterminent la manière dont le score de risque cumulé issu des règles correspondantes se traduit en statut de transaction :
Les transactions inférieures au seuil d’examen passent automatiquement à
APPROVED. Si une règle comporte une action change_status explicite, ce statut prime sur les seuils fondés sur le score : DECLINED l’emporte toujours.
Abaisser le seuil d’examen augmente le volume de transactions signalées pour examen par les analystes. Ajustez-le en fonction de la capacité de votre équipe et de votre appétence au risque.
Surveillance crypto
Activez ou désactivez le filtrage crypto automatique des transactions en cryptomonnaies. Lorsqu’il est activé, Didit filtre les adresses de portefeuille et les hachages de transaction auprès des fournisseurs d’analyse blockchain, pour toutes les transactions dontcurrency_kind: "crypto". Le filtrage par hachage de transaction exige à la fois le hachage et l’adresse de portefeuille associée.
Préférences de fournisseurs
Sélectionnez et configurez votre fournisseur d’analyse blockchain préféré :
Lorsque vous connectez votre propre clé de fournisseur, vous utilisez votre contrat existant avec ce fournisseur et payez, par filtrage, les frais d’infrastructure indiqués, par l’intermédiaire de Didit.
La surveillance du Lightning Network n’est disponible qu’avec une connexion BYOK Elliptic ou Chainalysis ajoutée via Marketplace.
Si
LIGHTNING est soumis alors qu’un autre fournisseur est actif, ou avant l’ajout de l’une des deux connexions prises en charge, la requête de filtrage renvoie 400 avec les instructions de configuration dans la Marketplace.
Workflow de remédiation
Le workflow de remédiation (remediation_workflow_id dans l’API des paramètres) est le workflow par défaut de votre application pour les actions AWAITING_USER qui ne désignent pas leur propre workflow, c’est-à-dire, en pratique, les règles de la bibliothèque intégrée (les règles personnalisées portent toujours leur propre sélection, qui prime).
Le champ accepte un identifiant de workflow (ou l’uuid d’une version spécifique) en écriture, et renvoie toujours l’identifiant stable du workflow en lecture ; les sessions sont créées avec la dernière version publiée.
Lorsqu’une telle règle fait passer une transaction à AWAITING_USER, Didit crée la session de vérification liée avec le premier workflow trouvé dans cet ordre :
- Le workflow de remédiation configuré ici.
- Le workflow Authentification biométrique de votre application, lorsque la personne concernée dispose déjà d’un visage de référence enregistré.
- Le workflow par défaut de votre application.
action_required et remediation de la transaction, ainsi que dans les deux webhooks de transaction, afin que vous puissiez rediriger l’utilisateur pour qu’il effectue la vérification requise.
Une fois que la session atteint une décision, le statut de la transaction suit automatiquement cette décision (approuvé, refusé ou en cours d’examen) et un webhook transaction.status.updated est déclenché.
Un workflow Authentification biométrique est le choix recommandé ici : l’utilisateur prouve à nouveau son identité avec un selfie pris en direct, comparé au visage enregistré lors de son onboarding initial.
Il exige que la personne dispose d’un visage de référence enregistré issu d’une vérification approuvée. Les utilisateurs qui n’en ont pas sont invités à effectuer à la place le workflow par défaut de votre application, et une note est ajoutée à la transaction pour signaler ce remplacement.
Où trouver
Rendez-vous dans Transactions > Paramètres de la Business Console pour configurer ces options. Les paramètres prennent effet immédiatement pour toutes les nouvelles transactions.Étapes suivantes
Notation des risques
Comment les seuils de score se traduisent en statuts.
Filtrage crypto
Filtrage des portefeuilles et détails des fournisseurs.
Enrichissement IP
Données IP disponibles pour les règles.