FR 3145435 A1 20240802 FR 2300934 A 20230201 Dispositif de sécurisation et de filtrage de transaction monétaires permettant au porteur d’un moyen de paiement de catégoriser les transactions monétaires via une sélection multicritère, ajustable et applicable en temps réel de transactions monétaires afin de définir de quelle façons une transaction monétaire issues du moyen de paiement doit etre traitée sur la base dédits critères et actions définis par l’utilisateur. détermination et filtrage de transactions monétaires multicritères, configurable par un porteur de moyen de paiement en temps réel. L’invention est un dispositif de traitement informatique qui s’intègre dans le processus de validation des transactions monétaires initiées par un porteur de moyen de paiement [fig1.C] réalisée par les processeurs de transactions [fig1.A], permettant de qualifier les spécificités d’une transaction monétaire, de déterminer selon une suite de règles à critère multiples, et par conséquent, de définir si ladite transaction doit etre autorisée ou non. L’invention intervient en complément du processus de validation établi par les processeurs de paiements [fig1.A], pour apporter une couche de validation supplémentaires accessible aux porteurs de moyen de paiement, permettant ainsi la personnalisation sur la façon dont un moyen de paiement [fig1.D] est utilisable par son détenteur[fig1.C]. L’invention permet à un porteur [fig1.C] du moyen de paiement [fig1.D] de pouvoir déterminer avec précision et de manière granulaire, quelle utilisation peut etre faite du dispositif de paiement qui lui a été mis à disposition par l’émetteur [fig1.B]. Définitions Définition moyen de paiement [fig1.D]: désigne un support permettant à un individu de procéder à une transaction dématérialisée financière auprès d’un marchand[fig1.E]. Définition porteur [fig1.C] : est une personne physique ou morale, qui dans le cadre d’un contrat avec l’émetteur [fig1.B], dispose d’un moyen de paiement [fig1.D] qui lui permet d’effectuer des transactions monétaires. Définition émetteur [fig1.B] : est un organisme qui dans le cadre d’un contrat de service avec le porteur [fig1.C], est en mesure de créer un moyen de paiement [fig1.D], de le mettre à disposition du porteur [fig1.C], et de gérer sa relation avec le porteur. L’émetteur pourra également en option, mettre à disposition du porteur des outils [fig2.J] qui permettent au porteur de gérer le compte lié au moyen de paiement qui lui a été remis, avec par exemple, la consultation du solde, les transactions passées, des codes secrets, des moyens d’authentification etc…). L’émetteur est le dépositaire de toutes les relations avec le porteur. Définition processeur [fig1.A]: est en charge de traiter les transactions qui sont issues du marchand [fig1.E], et de l’autre côté, l’émetteur [fig1.B] du moyen de paiement. Le processeur permet aux parties de s’accorder sur la transaction, et sa finalité. Le processeur est un point de passage unique pour le traitement des transactions issues des moyens de paiements initiés par un porteur. Résumé Architecture L’invention se greffe au processus de traitement des transactions auprès du processeur de paiement via l’API processeur [fig1.F]. Ainsi, le processeur peut soumettre toutes les transactions qui portent sur un moyen de paiement à l’invention pour traitement et évaluation. L’invention permet de définir l’utilisation qui peut en etre faite du moyen de paiement en en restreignant l’utilisation et de renforcer la sécurité du moyen de paiement et des fonds associés, ou de limiter son utilisation à des scenarios prédéfinis par le porteur du moyen de paiement. Le Dispositif inventif ( ) dans son ensemble est constitué de : 1 API processeur [fig1.F] (lien entre l’invention et le réseau interbancaire de traitement de transactions monétaires) relié au processeur de paiements. L’API processeur reçoit les éléments spécifiques d’une transaction et restitue une réponse sur la qualité de la dite transaction et indique ainsi quelle suite le processeur devra lui donner. 1 API émetteur [fig1.I] (lien entre l’invention et l’émetteur du moyen de paiement, ou parfois appelé fournisseur de moyen de paiement) relié à l’émetteur du moyen de paiement. L’AOI émetteur est complétée d’une interface [fig2.K] qui sera mise à disposition auprès de l’émetteur pour faciliter l’interaction entre le porteur du moyen de paiement et l’invention, via les outils applicatifs de l’émetteur [fig2.J] et ainsi traduire les interactions entre le porteur et l’API émetteur. (Fig5) Un moteur d’analyse [Fig1.G] Un moteur de catégorisation [fig1.H] Le moteur d’analyse ( .G) interprète et isole les éléments constitutifs de la transaction en cours ( .M) transmise par le processeur ( .A) reçue via l’API processeur de l’invention ( .F). Le moteur d’analyse identifier et extrait ( .N) les caractéristiques de ladite transaction en éléments distincts ( .O) tels qu’ils sont requis ( .P) par le moteur de catégorisation afin que ce dernier puisse ensuite les exploiter et procéder à la catégorisation de la transaction soumise. Le moteur de catégorisation détermine, sur la base des données d’analyse ( .O) la qualité de la transaction. Pour y parvenir, le moteur de catégorisation vérifie si la transaction entre dans le champ d’application de l’une des règles qui s’applique au moyen de paiement. Le champ d’application est défini par : Une règle constituée de 1 ou plusieurs critères et d’une valeur de comparaison (operateur logique) ( .Q3). Les règles sont classées par ordre de priorité ( .Q2). Chaque règle dispose d’une action prédéfinie qui stipule l’instruction qui sera donnée au processeur quant ’à la suite à donner à ladite transaction ( .Q1). Une règle par défaut ( .V), configurable par le porteur, s’applique quand la transaction n’entre dans aucun des champs d’application des règles actives. Cette règle par défaut a toujours la priorité la plus basse et intervient en dernier ressort pour assurer que l’invention soit toujours en mesure de donner une réponse au processeur. Au terme de de la catégorisation, l’API processeur renvoie au processeur le code action ( .AA) qui doit etre appliquée sur la transaction, et, dans un même temps, l’API Emetteur transmet à l’émetteur les informations pertinentes ( .I1) qui ont permis à l’invention de qualifier la transaction. Etat de l’art A ce jour, les émetteurs définissent les conditions d’utilisation d’un moyen de paiement. Les porteurs peuvent, si l’émetteur le permet, d’ajuster certains paramètres de ces conditions d’utilisation. Le moyen de paiement mis à disposition par l’émetteur comporte un certain nombre de restrictions génériques qui définit les capacités intrinsèques du moyen de paiement, qui sont des limites dures – c’est-à-dire qu’elles ne sont pas modifiables par l’utilisateur ; cet espace défini comme « critère 0 » Toute transaction qui n’est pas compris dans le champ d’application du critère 0 sera systématiquement refusée (F8.AC) par le processeur. L’invention a pour objet de fournir aux porteurs de moyen de paiement un outil avec lequel les porteurs sont en mesure de définir par eux-mêmes ( ) les conditions d’utilisation du moyen de paiement qui leur a été confié dans les limites de celles qui sont imposées par l’émetteur et/ou le réseau bancaire. Objet de l’invention L’invention porte notamment sur un système de validation de transactions monétaires dans lequel les transactions issues depuis un marchand à partir d’un moyen de paiement sont soumises à un processus de validation permettant de déterminer si la dite transaction doit être autorisée ou non, caractérisé en ce que le système comporte un dispositif d’analyse des transaction et de catégorisation temps réel basé sur des règles définies par un porteur détenteur dudit moyen de paiement ; ledit système s'intégrant en surcouche aux conditions et limitations d’utilisation d’un moyen de paiement telles que définies par l’émetteur du moyen de paiement. En outre, le système selon l’invention peut avantageusement intégrer les caractéristiques suivantes seules ou en combinaison : Ledit dispositif comporte une API émetteur permettant audit utilisateur, via une interface graphique, de suivre, définir, effacer et mettre à jour des règles de filtrage des transactions selon des critères libres de choix, ainsi que de notifier l’émetteur des actions déterminées par le moteur de catégorisation; et une API processeur d'accès à un moteur d'analyse interprétant les détails de la transaction et fournissant réponse au processeur sur la suite à donner à la transaction. ledit dispositif permet au porteur détenteur du moyen de paiement de créer des règles multicritères selon un ordre hiérarchique, et en ce que quand la transaction satisfait tous les critères définis par une règle entrant ainsi dans le champ d’application de la règle, cette règle est déclenchée et le code action est transmis au processeur et les autres règles qui suivent dans l'ordre hiérarchique sont abandonnées. la transaction est catégorisée par une règle par défaut prédéfinie par l'utilisateur détenteur du moyen de paiement en l’absence de règle applicable à ladite transaction. ledit dispositif permet au porteur détenteur du moyen de paiement de définir des règles dynamiques prenant en considération l'historique des transactions passées. ledit dispositif permet au porteur détenteur du moyen de paiement de définir des règles dynamiques prenant en considération des éléments de données en provenance de sources externes. ledit dispositif permet au porteur détenteur du moyen de paiement de définir une règle dont l’action est une requête de validation en temps réel par le porteur. ledit dispositif permet au porteur détenteur du moyen de paiement de créer un jeton de forçage à usage unique afin de stipuler au moteur de catégorisation que ce dernier devra fournir un code retour « validation forcé » pour la prochaine transaction qui sera retourné au processeur, préemptant sur les règles utilisateur et ainsi autoriser, si les fonds disponibles sont suffisants, ladite transaction. Ledit jeton est ensuite « consommé ». L’invention a pour objectif de permettre à un porteur de moyen de paiement de définir lui-même des catégories de transactions, et d’indiquer pour chacune de ces catégories, si le processeur doit ou non honorer la transaction. Le porteur aura la possibilité de définir une philosophie permissive ou restrictive, c’est-à-dire de choisir une approche : tout ce qui n’est pas explicitement autorisé est interdit, ou à l’inverse, tout ce qui n’est pas explicitement interdit, est autorisé. Grâce à l’invention, le porteur du moyen de paiement est en mesure de définir des sous-ensembles à l’ensemble défini par le critère 0, qui permet de catégoriser, par le biais de règles de filtrages des « familles » de transactions, et d’en définir les finalités respectives désirées pour chacune d’entre elles. Pour illustration : la superposition booléenne ( .AD), de 3 critères : (1 NOT (2 AND 3)) permettent de filtrer une catégorie de transactions définie par les sous ensemble S2, S3 et S5, c’est-à-dire les transactions qui satisfont le critère 1, sauf les transactions qui satisfont simultanément le critère 2 et 3. Le champ d’application étant ainsi defini, la regle y aplique ensuite une action pour déterminer comment seront traitées les transactions qui entrent dans ce champ d’application. Pour l’exemple, si l’on considère le critère 1 = transaction de plus de 20€, critère 2 = transaction en ligne et le critère 3 = transaction le week-end, la règle définie par le champ d’application donné en exemple en .AD signifierait que la règle s’appliquerait sur toutes les transactions de plus de 20€, sauf celle qui sont à la fois le week-end et en ligne. De manière plus générale, il est donné au porteur de pouvoir définir les conditions d’utilisation de son moyen de paiement selon 1 ou plusieurs critères, et d’affiner ces critères tel que jour de la semaine, heure d’utilisation, type de marchand, non du marchand, un pays en particulier, une devise, etc… et de combiner les critères choisis pour affiner les conditions d’utilisations aux besoins du porteur et s’assurer que le moyen de paiement ne puisse etre utilisé en dehors de ce qui a été prévu par les règles. ( ) Une règle par défaut est automatiquement créée afin de définir le champ d’application restant, c’est-à-dire le champ critère 0 déduit de tout les autres champ d’application défini par les règles. L’action associée a cette règle par défaut détermine la philosophie permissive ou restrictive. Les mise en œuvre possibles de l’invention incluent par exemple : De permettre aux parents qui souhaitent attribuer à leur enfant un moyen de paiement d’en limiter les capacités, De permettre aux porteurs qui souhaitent sécuriser leur moyen de paiement en en limitant les cas d’utilisation improbable et/ou potentiellement frauduleuse. De permettre des entreprises qui souhaitent mettre à disposition des moyens de paiement à leurs collaborateurs et en limiter l’utilisation à des contextes spécifiques etc… Les règles propres au moyen de paiement mis à disposition du porteur sont définies par le Porteur du moyen de paiement par le biais d’une interface proposée par l’invention ( .K) et intégrée par l’émetteur ( .J) a l’intention du porteur ( .C). Details du fonctionnement du moteur d’analyse Les données brutes sont livrées à l’API processeur ( .F) Les données brutes de la transaction telle qu’elles sont fournies par le processeur en bloc doivent etre partitionnées par le moteur d’analyse. La première étape pour l’API, est de verifier si la connexion en provenance du processeur est légitime, par le biais de clés d’authentification et de certificats d’authentification. ( .Z) Si l’authentification est satisfaisante, L’API vérifie si la transaction qui est soumise pour traitement correspond à un moyen de paiement connu et valide. Si le moyen est inconnu, ou qu’il n’y a pas l’information permettant d’identifier de manière exclusive le moyen de paiement, une réponse sera retournée auprès du processeur avec un code erreur, en précisant les raisons du rejet pour analyse ultérieure. Cette réponse ne comporte pas d’action, et le processeur devra déterminer par lui-même comment traiter la transaction en question. D’autres éléments de vérification sont traités tel que la date, l’heure et l’identifiant unique de la transaction afin de verifier que la date et l’heure de la transaction soit cohérente, (ni trop ancienne, ni dans le futur) et que la transaction n’a pas d’ores et déjà fait l’objet d’un traitement au préalable. Si toutes les vérifications ne sont pas satisfaites, le traitement est rejeté par l’invention avec un code erreur. Si la validation est satisfaite ( .Z), et que par conséquent la requête est considérée viable, un code est envoyé au processeur signalant que la requête est valide, et qu’elle va être traitée par le moteur d’analyse ( .G). L’objet du moteur d’analyse est de localiser dans les données transmises par le processeur, les critères utiles ( .P) (qui sont utilisés par le moteur de catégorisation), et d’en extraire les valeurs correspondantes ( .N). Ces valeurs serviront plus tard de base de comparaison aux valeurs cibles pour correspondant aux critères des règles du moteur de catégorisation. Par exemple, une donnée transmise par le processeur pourra prendre la forme : "transactionCurrencyIson" : "978". Elle sera isolée et le critère « Devise » sera renseigné par la valeur « US Dollar » et le critère « Devise étrangère » sera renseigné par « Vrai ». Ici, l’information fournie par le processeur donne lieu à l’extraction de 2 critères ( .O) : « nom de la devise = USD » et « devise étrangère = vrai. ». Ces critère-valeur seront ensuite exploités par le moteur de catégorisation. De cette manière, le moteur de catégorisation pourra verifier s’il existe une règle comportant un critère basé sur la devise, et si cela devait etre le cas, comparer la valeur fournie par le moteur d’analyse avec la valeur requise dans la ou les règles définies par le porteur pour déterminer si la transaction entre dans le champ d’application d’une règle ( .Q3). Une fois que les binômes critères-valeurs ont tous été extraits (ou définis comme absents), le moteur d’analyse formate les données propres à la transaction et crée une structure de données normalisée qui pourra ensuite être interprétée par le moteur de catégorisation sur la forme d’un format structuré ( .O) Details du fonctionnement du moteur de catégorisation. Le moteur de catégorisation a pour objet, de verifier s’il existe une règle définie par le porteur qui s’applique à la transaction présentée par le moteur d’analyse, et le cas échéant, de préparer la réponse qui sera transmise au processeur pour que ce dernier sache de quelle manière traiter la transaction. Le moteur de catégorisation dispose de 2 règles qui disposent de la priorité la plus haute : Règle 1 : la règle de couverture : Le moyen de paiement est-il couvert pas les fonds nécessaires. ( .T) Règle 2 : la règle d’exception : Existe-il un jeton de forçage qui permet au porteur d’autoriser la transaction sans tenir compte des règles qui suivent. ( .U) Toutes les règles définies ensuite par le porteur viennent ensuite en complément. ( .Q) La règle de couverture est une règle qui préempte toutes autre règle. Fondamentalement, cette règle permet de restreindre la capacité du moyen de paiement aux fonds disponibles pour satisfaire la transaction. La règle de d’exception s’appuie sur la fonctionnalité de jeton de forçage. Le porteur peut créer un jeton de forçage qui lui permet de préempter sur une règle qui aurait bloqué la transaction. Le jeton de forçage est à usage unique. Le jeton de forçage est systématiquement utilisé dès qu’une transaction est présentée au moteur de catégorisation . Les règles sous-jacentes sont ignorées quand un jeton est en cours d’utilisation. L’action d’un jeton de forçage est toujours une autorisation. Le jeton de forçage peut – selon le choix du porteur - avoir une date de péremption. Le de forçage peut également etre détruits directement par l’utilisateur par le biais de l’application mise à sa disposition par l’émetteur. Le moteur de catégorisation dispose d’un accès à l’ensemble des règles définies par le porteur. Une règle est constituée de : Une ou plusieurs conditions ( .Q3) déterminant le champ d’application de la règle Une Action - la réponse que le moteur devra donner au processeur si toutes les conditions ont été validées. ( .S) Un drapeau précisant si la règle est active - Valeur booléenne qui détermine si la règle est active ou non. Si la règle n’est pas active, le moteur ignorera cette règle pour passer directement à la suivante. Un identifiant unique du moyen de paiement - Il s’agit d’un champ comportant l’identifiant unique moyen de paiement pour laquelle cette règle s’applique Une priorité (afin de hiérarchiser l’ordre de passage des règles.) - Il s’agit d’une valeur numérique qui permet de classer dans quel ordre les règles vont etre traitées par le moteur ( .Q) Les règles sont accessibles au porteur en permanence et ce dernier est en mesure de les modifier quand il le souhaite, et l’application de la règle se fait en temps réel. Dès que la règle est soit créé, soit modifiée, soit détruite, l’effet est instantané sur les prochaines transactions. ( ) Le processus de catégorisation de la transaction traite les règles dans un ordre précis tel que l’utilisateur les a définis durant la phase de gestion des règles ( ) en ajustant la priorité de la règle. Dans la chaine de processing, Toutes les règles liées au moyen de paiement source de la transaction sont identifiée, classée par leur ordre de priorité, et sont traitées les unes apres les autres par le moteur de catégorisation. ( .Q) Les règles ont toutes une priorité différente afin de s’assurer qu’il ne peut y avoir d’ambiguïté sur l’ordre de passage des règles. Dès qu’une règle est appliquée, les règles suivantes sont ignorées, et l’action retenue est déterminée selon ce qui est prescris dans le champ action de la règle appliquée. ( .S/W) Les règles comportent des conditions. Ces conditions permettent de déterminer si la transaction en cours de traitement est dans le champ d’application de la règle, et donc affectée par la dite règle. Une règle peut comporter de 1 à n conditions. ( ) Une condition est constituée d’un critère, d’une valeur associée et d’un opérateur de comparaison pour déterminer si la condition est remplie. (Operateurs de type >=, , =) Les critères disponibles sur la plateforme ont vocation à évoluer afin de permettre au porteur de définir les règles qui lui conviennent selon les informations qui auront pu etre identifiée par le moteur d’analyse. Exemple : le porteur pourra par exemple choisir une liste non exhaustive de critère tels que : - Montant de la transaction - Date - Jour de la semaine - Heure de la transaction - Lieu géographique - Nom du marchand - Catégorie de Marchand (CID) - Identification du Marchand (MID) - Identification du terminal utilisé - Type de transaction (en ligne ou physique) - Description de la transaction - Autres A ces critères s’ajoutent les critères dynamiques ( ), c’est à dire des critères dont les valeurs sont calculées lors de chaque transaction. Ils sont obtenus soit Par calcul sur la base de l’historique lié au moyen de paiement ( .X) Par obtention de valeurs en provenance de sources externes ( .Y) Les critères dynamiques calculées s’obtiennent lorsqu’une règle invoque la nécessité de construire ledit critère et sa valeur afin d’etre en mesure de procéder à la comparaison. Pour y parvenir, le moteur d’analyse accède à la base de données d’historique. Par exemple, si une règle stipule que le moyen de paiement ne doit pas etre utilisé plus de 2 fois par jour, le moteur de catégorisation procède au calcul de la valeur du critère sollicité en comptant le nombre de transactions qui ont déjà été traitée dans le même jour et permet ainsi de procéder à la comparaison. Les calculs qui peuvent etre appliqués afin de construire les valeurs de référence ne sont pas limités dans leur nature, et peuvent notamment etre entre autres, des calculs de sommes, de quantité, de moyenne. Par exemple, une requête peut prendre la forme de type : On calcule la somme des « montant de transaction » de l’historique, sur une plage de temps défini dans la règle, pour une catégorie de marchand spécifique. Une fois la « somme » calculée, le moteur de catégorisation construit le critère à comparer qui portera pour l’exemple sur la somme totale des montants de transactions pour une catégorie de marchand sur un période spécifique et ainsi verifier si le montant total des transactions passées est supérieur, inférieur ou égal à la somme maximum autorisée par la règle. Les critères par obtention (ou importé) sont des critères qui dont les valeurs sont construites sur la base d’information fournie par des bases externes. C’est donné ne sont pas limités dans leur nature. Elles peuvent prendre par exemple prendre la forme d’un score de réputation d’un site marchand en ligne, ou de déterminer si le jour de la transaction est un jour férié, ou de vacances scolaires. Les critères importés sont acquis via une requête vers une api externe qui dispose des informations recherchées auprès du prestataire de données. L’ensemble des critères d’un règle détermine le champ d’application d’une règle. ( ) Les critères ne sont pas limités par leur nature ou la quantité pour définir une règle. Le champ d’application d’une règle est défini par la superposition des critères qui sont satisfaits par la transaction en cours de traitement. ( ) ( ) Les conditions sont hiérarchisées sous la forme d’une arborescence de type ET/OU combinées tel qu’illustré en exemple dans la ( .q3). Ainsi, pour que la règle soit appliquée à la transaction, il est nécessaire que la « somme booléenne » de l’arborescence soit « Vrai » jusqu’à la racine, que la règle soit active, qu’elle soit liée au moyen de paiement présenté. Des lors que la règle est appliquée, les règles qui suivent sont ignorées ( ). L’action qui sera appliquée remontée auprès du processeur sera celle qui a été renseignée dans la règle. Une règle est constituée d’une ou plusieurs actions qui permet de déterminer la suite à donner. ( .Q1) Dès lors que l’action est connue, la transaction est réputée comme étant « catégorisée » La règle par défaut ( .V) est une règle qui s’applique dès lors qu’aucune autre n’a pu etre activée. Il s’agit d’une règle qui ne dispose d’aucun critère, et qui est de fait toujours applicable. Le porteur peut déterminer que l’action de cette règle par défaut, et ne peut y ajouter de critères. L’action de la règle par défaut détermine la philosophie du moyen de paiement. Le porteur peut choisir une approche permissive, c’est-à-dire que toute transaction qui n’a été explicitement bloquée est par défaut autorisée. A l’inverse, le porteur peut décider d’une philosophie restrictive, c’est-à-dire que toute transaction qui n’a pas été explicitement autorisée sera bloquée. Le porteur procède de ce choix en choisissant l’action La règle par défaut est toujours active. La règle par défaut ne peut pas etre détruite. Les actions La réponse de l’invention prend la forme d’une action, ou plutôt d’un code action en réponse à la sollicitation du processeur via l’API processeur ( .AA). Le plus souvent, l’action consiste à autoriser ou bloquer une transaction. Il est toutefois possible pour le porteur de définir d’autres actions. L’API processeur dispose d’autre codes qui permet de signaler au processeur l’état du traitement de la transaction qui pourront servir au processeur at/ou à l’émetteur de traiter différemment les transactions Voici une série de code disponibles qui peuvent etre transmis au processeur : Codes Systèmes : Code 0x01 Success : Requête viable pour traitement Code 0x02 Error : carte inconnue (Deep TIE n’a pas trouvé de règles correspondant à cette carte) Code 0x03 Error : erreur défaut sur horodatage (une date ou heure dans le futur ou trop loin dans le passé) Code 0x04 Error : Identifiant de transaction dupliqué : Une transaction portant le même identifiant à déjà été traitée dans le passé (chaque transaction étant accompagné d’un identifiant unique, il est en principe impossible de rencontrer 2 transactions avec un numéro identique.) Code Actions : 1x01 RuleOK : Code classique pour indiquer au processeur que la transaction fait l’objet d’une règle explicite, et est autorisée pour traitement par la règle. 1x02 RuleNOK : Code classique pour indiquer au processeur que la transaction fait l’objet d’une règle explicite, et est bloquée pour traitement par la règle. 1x03 DefOK : La transaction est autorisée dû à la règle par défaut. Aucune des règles explicites ne s’appliquait à cette transaction 1x04 DefNOK : La transaction est Bloquée dû à la règle par défaut. Aucune des règles explicites ne s’appliquait à cette transaction 1x05 TokenOK : La transaction est autorisée dû à la presence d’un jeton de forçage qui a été utilisé. 1x06 FundsNOK : La transaction est refusée. Il n’y pas suffisamment de fonds disponibles pour couvrir la transaction. 1x07 BypassOK : Transaction Pseudo Refusée. Code retour habituellement principalement pour tester des règles sans pour autant affecter les transactions. Ce code spécifie qu’une règle aurait bloqué la transaction, mais qu’elle est pour le moment en mode de traçabilité. 1x08 WarnOK : Transaction autorisée avec alerte. La transaction est autorisée de manière explicite par une règle, mais qu’elle doit faire l’objet d’une notification différenciée auprès du porteur. 1x09 WarnNOK : Transaction Refusée avec alerte. La transaction est Bloquée de manière explicite par une règle, mais qu’elle doit aussi faire l’objet d’une notification différenciée auprès du porteur. Code Challenge : 2x01Challenge : Le code challenge est un code a part parce qu’il donne au porteur la possibilité de choisir au cas par cas si la transaction doit etre valable. 2x02 ChallengeOK : Le challenge est finalisé avec pour action finale l’autorisation de la transaction. 2x03 ChallengeNOK : Le challenge est finalisé avec pour action finale le blocage de la transaction. Les actions sont également transmises via l’API de l’émetteur a titre de notification pour que ce dernier puisse exploiter les informations correspondant à la transaction, et potentiellement les transmettre au porteur. Action de Règle Challenge (Fig9) Durant le traitement d’une transaction, si la transaction est une transaction par carte bancaire en ligne, celle-ci fait l’objet d’une vérification par le porteur. Cette vérification est nommée 3Dsecure par les réseaux de carte de paiement (Visa, Mastercard…) Cette authentification 3Dsecure n’a lieu que pour les opérations de paiement en Ligne (internet) et requiert que le porteur valide via sa banque la transaction. Ce procédé d’authentification 3Dsecure est indépendant des traitements effectués par l’invention. La vérification 3DSecure est transmise par le processeur. L’invention est toutefois en mesure de parquer la requête 3dSecure afin de procéder à une vérification supplémentaire qui peut ainsi prendre la forme d’une validation par un tiers qui seraient désignés comme autorité de confiance par le porteur. A titre d’exemple, si le porteur du moyen de paiement est un enfant, les tiers de confiance qui devraient valider la transaction pourraient être les parents. Cette mesure permettant de parquer la requête d’authentification de type 3Dsecure ou similaire et de solliciter un tiers est désigné comme étant le « mode challenge » par l’invention. Elle est activée par un code action spécifique ( .Q6) Lors de la création d’une règle, Le moteur de catégorisation met à disposition du porteur une la possibilité de choisir un mode challenge pour définir l’action. Cette option permet de mettre en pause le traitement de la transaction, et transmet via l’API émetteur une requête de délégation d’autorisation accompagné des éléments informatifs de la transaction. L’action challenge est accompagnée d’une action validation ou blocage par défaut en cas de non réponse du porteur. (Timeout) Dans les faits, cette action de challenge signifie que la règle ne porte pas d’action pré déterminée, et que cette dernière doit etre fournie par l’émetteur. L’émetteur peut, quand il reçoit la requête de challenge, déterminer comme il l’entend, la façon dont il va remédier à la résolution du challenge. L’émetteur peut, par exemple, solliciter le porteur via l’application web ou mobile, pour qu’il (le porteur) valide ou bloque ladite transaction qui fait l’objet d’un challenge. Dès que le Challenge a été transmis à l’émetteur, le moteur de catégorisation attend une réponse qui peut prendre 3 formes : La transaction est validée. La transaction est bloquée Timeout : L’émetteur n’a pas fourni de réponse dans une delais imparti. L’action par défaut du challenge est appliquée. (A ne pas confondre avec la règle par défaut.) Integration dans le système d’information L’invention s’intègre en 2 étapes : Une API « transaction » est mise à disposition auprès du processeur pour que ce dernier puisse soumettre la transaction et ainsi obtenir de l’invention l’instruction sur la façon dont la transaction doit etre traitée. Une API « émetteur » est mise à disposition pour que L’utilisateur, via une interface mise en place par le fournisseur du moyen de paiement, puisse définir et modifier les règles en vigueur sur son moyen de paiement. Que l’émetteur soit notifié des transactions traitées, et de créer et administrer les comptes porteurs comme par exemple traiter des opérations d’authentification « Single Sign On ». Une interface de gestion graphique mise à disposition de l’émetteur. L’émetteur pourra insérer l’interface porteur dans les applications que l’émetteur utilise pour gérer les éléments classiques de sa relation avec son client. ( .K) L’interface de gestion mise a disposition auprès de l’émetteur afin de facilité les interactions entre l’invention et le porteur est optionnelle dans le cas où l’émetteur souhaiterait développer sa propre interface qui porteuse qui saura interpréter directement les informations en provenance de ou envoyées vers l’API émetteur. Système de validation de transactions monétaires dans lequel les transactions issues depuis un marchand (fig1.E) à partir d’un moyen de paiement (Fig1.D) sont soumises à un processus de validation permettant de déterminer si la dite transaction doit être autorisée ou non, caractérisé en ce que le système comporte un dispositif d’analyse des transaction (fig1.G et fig3.N+O) et de catégorisation temps réel (fig1.H & Fig4 & Fig5) basé sur des règles définies par un porteur (fig4, fig7.AE+AF+AG) détenteur dudit moyen de paiement. Ledit système s'intégrant en surcouche aux conditions et limitations d’utilisation d’un moyen de paiement telles que définies (fig8.AC) par l’émetteur du moyen de paiement. Système suivant la revendication 1, caractérisé en ce que ledit dispositif comporte une API émetteur (fig2.I+I2) permettant audit utilisateur, via une interface graphique (fig2.K), de suivre (fig7.AH), définir (fig7.AE), effacer (fig7.AG) et mettre à jour (fig7.AF) des règles de filtrage des transactions (fig7) selon des critères libres de choix (fig 4), ainsi que de notifier l’émetteur (fig2.I+I1) des actions déterminées par le moteur de catégorisation; et une API processeur d'accès à un moteur d'analyse (fig3.F) interprétant les détails de la transaction (fig3.N) et fournissant réponse au processeur sur la suite à donner à la transaction (fig5.W). Système suivant la revendication 1 ou 2, caractérisé en ce que ledit dispositif permet au porteur détenteur du moyen de paiement de créer des règles multicritères (Fig4.Q3 / Fig7) selon un ordre hiérarchique (fig5.Q2), et en ce que quand la transaction satisfait tous les critères définis par une règle entrant ainsi dans le champ d’application de la règle (Fig4.Q3), cette règle est déclenchée et le code action (fig5.Q1 / Fig1.AA) est transmis au processeur et les autres règles qui suivent dans l'ordre hiérarchique sont abandonnées (fig5.R). Système suivant la revendication 3, caractérisé en ce que la transaction est catégorisée par une règle par défaut prédéfinie par l'utilisateur détenteur du moyen de paiement (fig5.V) en l’absence de règle applicable à ladite transaction. Système suivant l'une des revendications précédentes, caractérisé en ce que ledit dispositif permet au porteur détenteur du moyen de paiement de définir des règles dynamiques prenant en considération l'historique des transactions passées. (fig6.X) Système suivant l'une des revendications précédentes, caractérisé en ce que ledit dispositif permet au porteur détenteur du moyen de paiement de définir des règles dynamiques prenant en considération des éléments de données en provenance de sources externes. (fig6.Y) Système suivant l'une des revendications précédentes, caractérisé en ce que ledit dispositif permet au porteur détenteur du moyen de paiement de définir une règle dont l’action (fig4.Q1) est une requête de validation en temps réel par le porteur (fig9.Q6). Système suivant l'une des revendications précédentes, caractérisé en ce que ledit dispositif permet au porteur détenteur du moyen de paiement de créer un jeton de forçage à usage unique (fig5.U) qui permet d’autoriser la prochaine transaction qui sera retourné au processeur en préemptant sur les règles utilisateur et ainsi d’autoriser, si les fonds disponibles sont suffisants, ladite transaction, ledit jeton étant ensuite détruit.