Fraude à la souscription : décisions au même endroit

Les prêteurs paient leurs prestataires antifraude, gardent les fraudes confirmées dans un tableur et attendent l’équipe technique pour changer les règles. Decisimo réunit le tout.

Commencer gratuitement Voir le processus

La fraude à la souscription entraîne des pertes tardives

Identités volées ou inventées

Le demandeur n’est pas celui qu’il prétend être

Fraude du demandeur

Il n’a jamais eu l’intention de rembourser

Appareils ou numéros partagés

Plusieurs demandes utilisent le même identifiant

Pertes tardives

La perte se traduit par un défaut plusieurs mois plus tard

Fraudes avérées en tableur

Les règles ne peuvent pas consulter ce fichier

Panne d’un prestataire

Les demandes s’arrêtent ou passent sans contrôle

De la demande au déploiement des règles

Decisimo exécute le flux de décision. Un analyste traite les demandes à examiner et met à jour la liste des fraudes avérées.

  1. Réception de la demande

    Decisimo reçoit la demande en un seul appel.

  2. Appels simultanés aux prestataires

    Decisimo interroge en même temps les prestataires connectés.

  3. Vérification des fraudes avérées

    Decisimo vérifie chaque donnée dans la liste du prêteur.

  4. Décision selon les règles

    Decisimo renvoie « pass », « refer » ou « decline » avec un motif.

  5. Examen par un analyste

    Un analyste examine le dossier avec les éléments disponibles.

  6. Mise à jour de la liste

    Un analyste ajoute la fraude avérée, son motif et sa date d’expiration.

  7. Rejeu et version

    L’équipe fraude rejoue la modification et déploie la version.

Prestataires et règles prennent la décision ensemble

  • Sources HTTP APIPlusieurs prestataires peuvent être interrogés simultanément
  • Motifs explicitesL’équipe définit dans le portail le sens de chaque réponse
  • Appels en échecLes règles tiennent compte de l’erreur pour décider

Connecter des prestataires

L’éditeur de règles de fraude montre qu’une recherche IP sans réponse renvoie vers un analyste et que deux données correspondantes entraînent un refus, avec un motif pour chacune des décisions
Application fraud rules : « refer » si l’IP échoue, « decline » dès deux correspondances sur une fiche de fraude avérée.

Les fraudes avérées du prêteur, prises en compte à chaque décision

  • Correspondance par donnéeLa décision identifie les données qui correspondent à un dossier
  • Motif et expirationUn analyste ajoute ou retire une entrée en indiquant un motif
  • Base de données propreChaque entrée est conservée dans le Postgres du prêteur
Tableau de la liste des fraudes avérées avec cinq entrées actives, une entrée retirée, les motifs, les identifiants masqués et les dates d’expiration
La liste de démonstration masque chaque donnée, affiche cinq entrées actives et conserve une entrée retirée avec son motif.

Rejouer une règle sur l’historique avant son déploiement

  • Historique des révisionsChaque sauvegarde crée une révision, et deux révisions se comparent
  • Dates du rejeuLes décisions archivées utilisent la liste en vigueur à leur date
  • Validation de la versionUn point d’accès API peut exiger une validation avant le déploiement
Chronologie des décisions anti-fraude : appareil dv-5c02e8aa ajouté le 14 août, décision du 6 août rejouée en approve et celle du 23 août en decline
Un appareil ajouté le 14 août fait rejouer la décision du 6 août en « approve » et celle du 23 août en « decline ».

Le dossier à examiner arrive avec les éléments vus par les règles

  • File par rôleLe dossier à examiner rejoint la file d’un rôle
  • Éléments d’examenL’analyste retrouve les contrôles exécutés et leurs résultats
  • Versions et auteurLe dossier indique les éléments présentés et qui a répondu

Découvrir la gestion de dossiers

Le rôle de chacun dans l’équipe fraude, semaine après semaine

  • Modification des règlesL’équipe les modifie dans le portail, sans écrire de code
  • Enregistrement des décisionsUne table dans le Postgres du prêteur conserve chaque entrée et sortie
  • Recherches en cacheUne recherche répétée utilise le cache du prêteur, sans appeler le prestataire

Ce qui reste chez le prêteur et ses prestataires

  • Prestataires choisisLe prêteur choisit ses sources de données et les rémunère
  • Liste de fraudes propreLa liste des fraudes avérées appartient au prêteur
  • Règles du prêteurLe résultat dépend des règles de décision du prêteur

Calculer le coût du refus ou de l’examen

Questions fréquentes

Qu’est-ce que la prise de décision anti-fraude ?

La prise de décision anti-fraude combine les données d’une demande et les réponses des prestataires pour décider si elle passe, doit être examinée ou est refusée. Decisimo exécute ces règles, consulte la liste des fraudes avérées du prêteur et transmet les dossiers à examiner dans un flux de décision.

Que se passe-t-il si un prestataire anti-fraude est indisponible ?

Un appel en échec renvoie une erreur et un statut HTTP, mais le flux de décision continue. Voir la gestion des échecs

Où est stockée la liste des fraudes avérées ?

Le prêteur conserve les entrées dans son propre Postgres. L’équipe les consulte dans le portail, où chaque donnée est masquée.

Decisimo fournit-il des données de fraude ou une liste de blocage partagée ?

Decisimo ne fournit ni données de fraude ni liste de blocage partagée. Le prêteur choisit et rémunère ses prestataires et apporte sa propre liste de fraudes avérées.

Réunissez vos décisions anti-fraude au même endroit

Connectez vos prestataires et intégrez votre liste de fraudes avérées aux règles.

Commencer gratuitement