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.