FR3145435A1 - determination and filtering of multi-criteria monetary transactions, configurable by a means of payment holder in real time. - Google Patents

Abstract

Device for securing and filtering monetary transactions allowing the holder of a means of payment to categorize monetary transactions via a multi-criteria selection, adjustable and applicable in real time of monetary transactions in order to define how a monetary transaction resulting from the means of payment must be processed on the basis of said criteria and actions defined by the user.

Description

determination and filtering of multi-criteria monetary transactions, configurable by a means of payment holder in real time.

The invention is a computer processing device which is integrated into the process of validating monetary transactions initiated by a means of payment holder [fig1.C] carried out by transaction processors [fig1.A], making it possible to qualify the specificities of a monetary transaction, to determine according to a series of rules with multiple criteria, and consequently, to define whether said transaction must be authorized or not.

The invention complements the validation process established by payment processors [fig1.A], to provide an additional validation layer accessible to payment method holders, thus enabling customization of the way in which a payment method [fig1.D] can be used by its holder [fig1.C].

The invention allows a holder [fig1.C] of the means of payment [fig1.D] to be able to determine precisely and in a granular manner what use can be made of the payment device made available to him by the issuer [fig1.B].

Definitions

Definition of means of payment [fig1.D]: designates a medium allowing an individual to carry out a dematerialized financial transaction with a merchant [fig1.E].

Definition of bearer [fig1.C]: is a natural or legal person, who within the framework of a contract with the issuer [fig1.B], has a means of payment [fig1.D] which allows them to carry out monetary transactions.

Definition of issuer [fig1.B]: is an organization that, within the framework of a service contract with the bearer [fig1.C], is able to create a means of payment [fig1.D], to make it available to the bearer [fig1.C], and to manage its relationship with the bearer. The issuer may also, as an option, make tools available to the bearer [fig2.J] that allow the bearer to manage the account linked to the means of payment that has been given to him, with, for example, the consultation of the balance, past transactions, secret codes, means of authentication, etc.). The issuer is the custodian of all relations with the bearer.

Processor definition [fig1.A]: is in charge of processing transactions that come from the merchant [fig1.E], and on the other side, the issuer [fig1.B] of the means of payment. The processor allows the parties to agree on the transaction, and its purpose. The processor is a single point of passage for processing transactions from means of payment initiated by a cardholder.

Abstract Architecture

The invention is grafted onto the transaction processing process with the payment processor via the processor API [fig1.F]. Thus, the processor can submit all transactions that relate to a means of payment to the invention for processing and evaluation.

The invention makes it possible to define the use that can be made of the means of payment by restricting its use and to reinforce the security of the means of payment and the associated funds, or to limit its use to scenarios predefined by the bearer of the means of payment.

1. 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.
   1. 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.
2. 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.
   1. 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)
3. Un moteur d’analyse [Fig1.G]
4. Un moteur de catégorisation [fig1.H]

The Inventive Device ( ) as a whole is made up of:

1. 1 API processor [fig1.F] (link between the invention and the interbank network for processing monetary transactions) connected to the payment processor.
   1. The processor API receives the specific elements of a transaction and returns a response on the quality of said transaction and thus indicates what action the processor should take.
2. 1 Issuer API [fig1.I] (link between the invention and the issuer of the means of payment, or sometimes called payment means provider) connected to the issuer of the means of payment.
   1. The issuer AOI is completed by an interface [fig2.K] which will be made available to the issuer to facilitate the interaction between the bearer of the means of payment and the invention, via the issuer's application tools [fig2.J] and thus translate the interactions between the bearer and the issuer API. (Fig5)
3. An analysis engine [Fig1.G]
4. A categorization engine [fig1.H]

1. 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.

The analysis engine ( .G) interprets and isolates the constituent elements of the current transaction ( .M) transmitted by the processor ( .A) received via the processor API of the invention ( .F).

1. The analysis engine identifies and extracts ( .N) the characteristics of said transaction in separate elements ( .O) as required ( .P) by the categorization engine so that the latter can then exploit them and proceed with the categorization of the submitted transaction.

1. Une règle constituée de 1 ou plusieurs critères et d’une valeur de comparaison (operateur logique) ( .Q3).
2. Les règles sont classées par ordre de priorité ( .Q2).
3. 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).
4. 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.

The categorization engine determines, based on the analysis data ( .O) the quality of the transaction. To achieve this, the categorization engine checks whether the transaction falls within the scope of one of the rules that apply to the payment method. The scope is defined by:

1. A rule consisting of 1 or more criteria and a comparison value (logical operator) ( .Q3).
2. The rules are listed in order of priority ( .Q2).
3. Each rule has a predefined action that stipulates the instruction that will be given to the processor as to what to do next with the said transaction ( .Q1).
4. A default rule ( .V), configurable by the bearer, applies when the transaction does not fall within any of the scopes of the active rules. This default rule always has the lowest priority and intervenes as a last resort to ensure that the invention is always able to give a response to the processor.

At the end of the categorization, the processor API returns the action code ( .AA) that must be applied on the transaction, and, at the same time, the Issuer API transmits to the issuer the relevant information ( .I1) which allowed the invention to qualify the transaction.

State of the art

To date, issuers define the conditions of use of a means of payment. Holders may, if the issuer allows it, adjust certain parameters of these conditions of use.

The means of payment made available by the issuer includes a certain number of generic restrictions which define the intrinsic capacities of the means of payment, which are hard limits – that is to say they cannot be modified by the user; this space defined as “criterion 0”

Any transaction that does not fall within the scope of criterion 0 will be systematically refused (F8.AC) by the processor.

The invention aims to provide payment method holders with a tool with which the holders are able to define for themselves ( ) the conditions of use of the means of payment entrusted to them within the limits of those imposed by the issuer and/or the banking network.

Subject of the invention

The invention relates in particular to a system for validating monetary transactions in which transactions originating from a merchant using a means of payment are subject to a validation process making it possible to determine whether or not said transaction must be authorized, characterized in that the system comprises a device for analyzing transactions and for real-time categorization based on rules defined by a holder holding said means of payment; said system being integrated as an overlay with the conditions and limitations of use of a means of payment as defined by the issuer of the means of payment.

• 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é ».

Furthermore, the system according to the invention can advantageously integrate the following characteristics alone or in combination:

• Said device comprises an issuer API allowing said user, via a graphical interface, to follow, define, delete and update transaction filtering rules according to freely chosen criteria, as well as to notify the issuer of the actions determined by the categorization engine; and a processor API for accessing an analysis engine interpreting the details of the transaction and providing a response to the processor on the next steps to take with the transaction.
• said device allows the holder of the means of payment to create multi-criteria rules according to a hierarchical order, and in that when the transaction satisfies all the criteria defined by a rule thus entering the scope of the rule, this rule is triggered and the action code is transmitted to the processor and the other rules which follow in the hierarchical order are abandoned.
• the transaction is categorized by a default rule predefined by the user holding the means of payment in the absence of a rule applicable to said transaction.
• said device allows the holder of the means of payment to define dynamic rules taking into account the history of past transactions.
• said device allows the holder of the means of payment to define dynamic rules taking into consideration data elements from external sources.
• said device allows the holder of the means of payment to define a rule whose action is a validation request in real time by the holder.
• said device allows the bearer holding the means of payment to create a single-use forcing token in order to stipulate to the categorization engine that the latter must provide a “forced validation” return code for the next transaction which will be returned to the processor, preempting the user rules and thus authorizing, if the available funds are sufficient, said transaction. Said token is then “consumed”.

The invention aims to allow a means of payment holder to define transaction categories himself, and to indicate for each of these categories whether or not the processor must honor the transaction.

1. tout ce qui n’est pas explicitement autorisé est interdit,
2. ou à l’inverse, tout ce qui n’est pas explicitement interdit, est autorisé.

The wearer will have the possibility to define a permissive or restrictive philosophy, that is to say to choose an approach:

1. anything that is not explicitly permitted is prohibited,
2. or conversely, anything that is not explicitly forbidden is permitted.

Thanks to the invention, the bearer of the means of payment is able to define subsets of the set defined by criterion 0, which makes it possible to categorize, by means of filtering rules, “families” of transactions, and to define the respective desired purposes for each of them.

1. 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.
2. 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. ( )

For illustration: Boolean superposition ( .AD), of 3 criteria: (1 NOT (2 AND 3)) allow to filter a category of transactions defined by the subsets S2, S3 and S5, that is to say the transactions which satisfy criterion 1, except the transactions which simultaneously satisfy criterion 2 and 3. The scope of application being thus defined, the rule then applies an action to determine how the transactions which enter into this scope of application will be processed.

1. For example, if we consider criterion 1 = transaction of more than €20, criterion 2 = online transaction and criterion 3 = transaction on weekends, the rule defined by the scope of application given in the example in .AD would mean that the rule would apply to all transactions over €20, except those that are both weekend and online.
2. More generally, the bearer is given the ability to define the conditions of use of his means of payment according to 1 or more criteria, and to refine these criteria such as day of the week, time of use, type of merchant, name of the merchant, a particular country, a currency, etc. and to combine the chosen criteria to refine the conditions of use to the needs of the bearer and ensure that the means of payment cannot be used outside of what has been provided for by the rules. )

A default rule is automatically created to define the remaining scope, i.e. the criterion field 0 deduced from all other scopes defined by the rules. The action associated with this default rule determines the permissive or restrictive philosophy.

1. De permettre aux parents qui souhaitent attribuer à leur enfant un moyen de paiement d’en limiter les capacités,
2. De permettre aux porteurs qui souhaitent sécuriser leur moyen de paiement en en limitant les cas d’utilisation improbable et/ou potentiellement frauduleuse.
3. De permettre des entreprises qui souhaitent mettre à disposition des moyens de paiement à leurs collaborateurs et en limiter l’utilisation à des contextes spécifiques etc…

Possible implementations of the invention include, for example:

1. To allow parents who wish to assign a means of payment to their child to limit its capacities,
2. To enable cardholders who wish to secure their means of payment by limiting cases of improbable and/or potentially fraudulent use.
3. To enable companies that wish to provide means of payment to their employees and limit their use to specific contexts, etc.

The rules specific to the means of payment made available to the bearer are defined by the Bearer of the means of payment by means of an interface proposed by the invention ( .K) and integrated by the transmitter ( .J) for the bearer ( .C).

Details of how the analysis engine works

Raw data is delivered to the processor API ( .F)

The raw transaction data as provided by the bulk processor must be partitioned by the analysis engine.

1. 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.
2. 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.
3. 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.

The first step for the API is to verify if the connection coming from the processor is legitimate, through authentication keys and authentication certificates. ( .Z)

1. If authentication is successful, the API verifies whether the transaction being submitted for processing corresponds to a known and valid payment method.
2. If the means is unknown, or there is no information to uniquely identify the means of payment, a response will be returned to the processor with an error code, specifying the reasons for the rejection for further analysis. This response does not include any action, and the processor will have to determine for itself how to process the transaction in question.
3. Other verification elements are processed such as the date, time and unique identifier of the transaction in order to verify that the date and time of the transaction are consistent (neither too old nor in the future) and that the transaction has not already been processed beforehand. If all the checks are not satisfied, the processing is rejected by the invention with an error code.

If validation is satisfied ( .Z), and therefore the request is considered viable, a code is sent to the processor signaling that the request is valid, and that it will be processed by the analysis engine ( .G).

The purpose of the analysis engine is to locate in the data transmitted by the processor, the useful criteria ( .P) (which are used by the categorization engine), and extract the corresponding values ( .N). These values will later be used as a basis for comparison with the target values to match the criteria of the categorization engine rules.

1. 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).

For example, data transmitted by the processor may take the form: "transactionCurrencyIson": "978". It will be isolated and the "Currency" criterion will be filled in with the value "US Dollar" and the "Foreign Currency" criterion will be filled in with "True".

1. Here, the information provided by the processor gives rise to the extraction of 2 criteria ( .O): "currency name = USD" and "foreign currency = true." These value criteria will then be used by the categorization engine. In this way, the categorization engine will be able to check if there is a rule with a currency-based criterion, and if so, compare the value provided by the analysis engine with the value required in the rule(s) defined by the holder to determine if the transaction falls within the scope of a rule ( .Q3).

Once the criteria-value pairs have all been extracted (or defined as absent), the analysis engine formats the transaction-specific data and creates a normalized data structure that can then be interpreted by the categorization engine in the form of a structured format ( .O)

Details of how the categorization engine works.

The purpose of the categorization engine is to check whether there is a rule defined by the bearer that applies to the transaction presented by the analysis engine, and if so, to prepare the response that will be transmitted to the processor so that the latter knows how to process the transaction.

1. Règle 1 : la règle de couverture : Le moyen de paiement est-il couvert pas les fonds nécessaires. ( .T)
2. 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)
3. Toutes les règles définies ensuite par le porteur viennent ensuite en complément. ( .Q)

The categorization engine has 2 rules that have the highest priority:

1. Rule 1: The Coverage Rule: Is the payment method covered by the necessary funds? .T)
2. Rule 2: The Exception Rule: Is there a forcing token that allows the bearer to authorize the transaction without taking into account the following rules. ( .U)
3. All the rules subsequently defined by the wearer then come in addition. ( .Q)

The coverage rule is a rule that preempts all other rules. Basically, this rule allows to restrict the capacity of the means of payment to the funds available to satisfy the transaction.

1. Le jeton de forçage est à usage unique.
2. Le jeton de forçage est systématiquement utilisé dès qu’une transaction est présentée au moteur de catégorisation .
3. Les règles sous-jacentes sont ignorées quand un jeton est en cours d’utilisation.
4. L’action d’un jeton de forçage est toujours une autorisation.
5. Le jeton de forçage peut – selon le choix du porteur - avoir une date de péremption.
6. 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.

The exception rule relies on the force token functionality. The bearer can create a force token that allows them to preempt a rule that would have blocked the transaction.

1. The force token is for one-time use only.
2. The force token is systematically used as soon as a transaction is presented to the categorization engine.
3. The underlying rules are ignored when a token is in use.
4. The action of a force token is always an authorization.
5. The force token can – depending on the bearer’s choice – have an expiration date.
6. The force can also be destroyed directly by the user through the application made available to him by the transmitter.

1. Une ou plusieurs conditions ( .Q3) déterminant le champ d’application de la règle
2. Une Action - la réponse que le moteur devra donner au processeur si toutes les conditions ont été validées. ( .S)
3. 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.
4. 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
5. 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)

The categorization engine has access to all the rules defined by the wearer. A rule consists of:

1. One or more conditions ( .Q3) determining the scope of the rule
2. An Action - the response that the engine should give to the processor if all conditions have been validated. ( .S)
3. A flag indicating whether the rule is active - Boolean value that determines whether the rule is active or not. If the rule is not active, the engine will skip this rule and move directly to the next one.
4. A unique identifier of the payment method - This is a field containing the unique identifier of the payment method for which this rule applies.
5. A priority (in order to prioritize the order in which the rules are processed.) - This is a numerical value that allows you to classify the order in which the rules will be processed by the engine ( .Q)

The rules are accessible to the holder at all times and the latter is able to modify them whenever he wishes, and the application of the rule is done in real time. As soon as the rule is either created, modified or destroyed, the effect is instantaneous on the next transactions. )

The transaction categorization process processes rules in a specific order as defined by the user during the rule management phase ( ) by adjusting the rule priority.

In the processing chain, all rules related to the source payment method of the transaction are identified, classified by their order of priority, and are processed one after the other by the categorization engine. .Q)

The rules all have a different priority to ensure that there can be no ambiguity about the order in which the rules come.

As soon as a rule is applied, the following rules are ignored, and the action taken is determined according to what is prescribed in the action field of the applied rule. .S/W)

Rules have conditions. These conditions determine whether the transaction being processed is within the scope of the rule, and therefore affected by the rule. A rule can have 1 to n conditions. ( )

A condition consists of a criterion, an associated value, and a comparison operator to determine whether the condition is met. (Operators of type >=, <=, <, >, =)

The criteria available on the platform are intended to evolve in order to allow the holder to define the rules that suit him according to the information that could have been identified by the analysis engine. Example: the holder will be able to choose a non-exhaustive list of criteria such as:
- Transaction amount
- Date
- Day of the week
- Time of transaction
- Geographic location
- Merchant name
- Merchant Category (CID)
- Merchant Identification (MID)
- Identification of the terminal used
- Type of transaction (online or physical)
- Description of the transaction
- Others

1. Par calcul sur la base de l’historique lié au moyen de paiement ( .X)
2. Par obtention de valeurs en provenance de sources externes ( .Y)

In addition to these criteria, there are dynamic criteria ( ), i.e. criteria whose values are calculated during each transaction. They are obtained either

1. By calculation based on the history linked to the means of payment ( .X)
2. By obtaining values from external sources ( .Y)

1. 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.
2. 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.

Dynamic calculated criteria are obtained when a rule invokes the need to construct said criterion and its value in order to be able to proceed with the comparison. To achieve this, the analysis engine accesses the historical database. For example, if a rule stipulates that the means of payment should not be used more than 2 times per day, the categorization engine calculates the value of the requested criterion by counting the number of transactions that have already been processed in the same day and thus allows the comparison to be made.

1. The calculations which can be applied in order to construct the reference values are not limited in their nature, and may notably be, among others, calculations of sums, quantities, averages.
2. For example, a query can take the form of type: We calculate the sum of the "transaction amounts" of the history, over a time range defined in the rule, for a specific merchant category. Once the "sum" is calculated, the categorization engine builds the criterion to compare which will for the example focus on the total sum of transaction amounts for a merchant category over a specific period and thus verify if the total amount of past transactions is greater than, less than or equal to the maximum amount authorized by the rule.

1. 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.

Obtained (or imported) criteria are criteria whose values are constructed on the basis of information provided by external databases. This is given are not limited in their nature. They can take for example the form of a reputation score of an online merchant site, or to determine if the day of the transaction is a public holiday, or a school holiday.

1. The imported criteria are acquired via a query to an external API that has the information sought from the data provider.

The set of criteria of a rule determines the scope of application of a rule. ( )

The criteria are not limited by their nature or quantity to define a rule.

The scope of a rule is defined by the overlap of criteria that are satisfied by the transaction being processed. ( ) ( )

The conditions are hierarchized in the form of a combined AND/OR type tree as illustrated in the example in the ( .q3). Thus, for the rule to be applied to the transaction, it is necessary that the "boolean sum" of the tree is "True" up to the root, that the rule is active, that it is linked to the means of payment presented.

Once the rule is applied, the following rules are ignored ( ). The action that will be applied and sent to the processor will be the one that was entered in the rule.

A rule is made up of one or more actions that determine what to do next. .Q1)

Once the action is known, the transaction is deemed to be “categorized”

1. L’action de la règle par défaut détermine la philosophie du moyen de paiement.
2. 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.
3. 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.
4. Le porteur procède de ce choix en choisissant l’action
5. La règle par défaut est toujours active.
6. La règle par défaut ne peut pas etre détruite.

The default rule ( .V) is a rule that applies when no other rule could be activated. This is a rule that has no criteria, and is therefore always applicable. The holder can determine that this rule's action is by default, and cannot add criteria to it.

1. The default rule action determines the philosophy of the payment method.
2. The holder can choose a permissive approach, meaning that any transaction that has not been explicitly blocked is allowed by default.
3. Conversely, the holder can decide on a restrictive philosophy, meaning that any transaction that has not been explicitly authorized will be blocked.
4. The bearer proceeds from this choice by choosing the action
5. The default rule is always active.
6. The default rule cannot be destroyed.

The actions

The response of the invention takes the form of an action, or rather an action code in response to the request of the processor via the processor API ( .AA).

Most often, the action consists of authorizing or blocking a transaction. However, it is possible for the bearer to define other actions.

The processor API has other codes that can signal the processor the status of the transaction processing that can be used by the processor and/or the issuer to process transactions differently.

1. Codes Systèmes :
   1. Code 0x01 Success : Requête viable pour traitement
   2. Code 0x02 Error : carte inconnue (Deep TIE n’a pas trouvé de règles correspondant à cette carte)
   3. Code 0x03 Error : erreur défaut sur horodatage (une date ou heure dans le futur ou trop loin dans le passé)
   4. 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.)
2. Code Actions :
   1. 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.
   2. 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.
   3. 1x03 DefOK : La transaction est autorisée dû à la règle par défaut. Aucune des règles explicites ne s’appliquait à cette transaction
   4. 1x04 DefNOK : La transaction est Bloquée dû à la règle par défaut. Aucune des règles explicites ne s’appliquait à cette transaction
   5. 1x05 TokenOK : La transaction est autorisée dû à la presence d’un jeton de forçage qui a été utilisé.

1. 1x06 FundsNOK : La transaction est refusée. Il n’y pas suffisamment de fonds disponibles pour couvrir la transaction.
2. 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é.
3. 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.
4. 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.
5. Code Challenge :
   1. 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.
   2. 2x02 ChallengeOK : Le challenge est finalisé avec pour action finale l’autorisation de la transaction.
   3. 2x03 ChallengeNOK : Le challenge est finalisé avec pour action finale le blocage de la transaction.

Here is a series of available codes that can be passed to the processor:

1. System Codes:
   1. Code 0x01 Success: Request viable for processing
   2. Code 0x02 Error: Unknown card (Deep TIE did not find any rules matching this card)
   3. Code 0x03 Error: faulty timestamp error (a date or time in the future or too far in the past)
   4. Code 0x04 Error: Duplicate transaction identifier: A transaction with the same identifier has already been processed in the past (each transaction being accompanied by a unique identifier, it is in principle impossible to encounter 2 transactions with an identical number.)
2. Action Code:
   1. 1x01 RuleOK: Classic code to indicate to the processor that the transaction is subject to an explicit rule, and is authorized for processing by the rule.
   2. 1x02 RuleNOK: Classic code to indicate to the processor that the transaction is subject to an explicit rule, and is blocked for processing by the rule.
   3. 1x03 DefOK: The transaction is allowed due to the default rule. None of the explicit rules applied to this transaction.
   4. 1x04 DefNOK: Transaction is Blocked due to default rule. None of the explicit rules applied to this transaction
   5. 1x05 TokenOK: The transaction is authorized due to the presence of a force token that was used.

1. 1x06 FundsNOK: The transaction is declined. There are not enough funds available to cover the transaction.
2. 1x07 BypassOK: Pseudo Transaction Refused. Return code usually mainly to test rules without affecting transactions. This code specifies that a rule would have blocked the transaction, but that it is currently in traceability mode.
3. 1x08 WarnOK: Transaction authorized with alert. The transaction is explicitly authorized by a rule, but it must be the subject of a differentiated notification to the bearer.
4. 1x09 WarnNOK: Transaction Refused with alert. The transaction is explicitly blocked by a rule, but it must also be the subject of a differentiated notification to the holder.
5. Code Challenge:
   1. 2x01Challenge: The challenge code is a separate code because it gives the bearer the possibility to choose on a case-by-case basis whether the transaction should be valid.
   2. 2x02 ChallengeOK: The challenge is finalized with the final action being authorization of the transaction.
   3. 2x03 ChallengeNOK: The challenge is finalized with the final action being blocking the transaction.

The shares are also transmitted via the issuer's API as a notification so that the latter can exploit the information corresponding to the transaction, and potentially transmit it to the bearer.

Challenge Rule Action (Fig9)

During the processing of a transaction, if the transaction is an online bank card transaction, it is subject to verification by the cardholder. This verification is called 3Dsecure by the payment card networks (Visa, Mastercard, etc.)

This 3Dsecure authentication only takes place for online payment transactions (internet) and requires that the bearer validates the transaction via his bank. This 3Dsecure authentication process is independent of the processing carried out by the invention.

3DSecure verification is passed through the processor.

1. 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.

The invention is however able to park the 3dSecure request in order to carry out an additional verification which can thus take the form of a validation by a third party who would be designated as a trusted authority by the bearer.

1. For example, if the bearer of the means of payment is a child, the trusted third parties who should validate the transaction could be the parents.

This measure for parking the 3Dsecure or similar authentication request and requesting a third party is designated as the "challenge mode" by the invention. It is activated by a specific action code ( .Q6)

When creating a rule, the categorization engine provides the holder with the possibility of choosing a challenge mode to define the action. This option allows to pause the processing of the transaction, and transmits via the issuer API an authorization delegation request accompanied by the informative elements of the transaction.

The challenge action is accompanied by a validation or blocking action by default in the event of no response from the bearer. (Timeout)

In fact, this challenge action means that the rule does not carry a predetermined action, and that the latter must be provided by the issuer.

The issuer may, when it receives the challenge request, determine as it sees fit, how it will remedy the resolution of the challenge. The issuer may, for example, request the bearer via the web or mobile application, so that he (the bearer) validates or blocks said transaction which is the subject of a challenge.

1. La transaction est validée.
2. La transaction est bloquée
3. 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.)

Once the Challenge has been transmitted to the transmitter, the categorization engine waits for a response which can take 3 forms:

1. The transaction is validated.
2. The transaction is blocked
3. Timeout: The issuer did not provide a response within a specified timeout period. The challenge's default action is applied. (Not to be confused with the default rule.)

Integration into the information system

1. 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.
2. Une API « émetteur » est mise à disposition pour que
   1. 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.
   2. 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 ».

The invention is integrated into 2 stages:

1. A “transaction” API is made available to the processor so that the latter can submit the transaction and thus obtain from the invention the instruction on how the transaction should be processed.
2. A “transmitter” API is made available so that
   1. The user, via an interface set up by the payment method provider, can define and modify the rules in force on their payment method.
   2. That the issuer is notified of the transactions processed, and to create and administer the bearer accounts such as processing “Single Sign On” authentication operations.

A graphical management interface made available to the issuer. The issuer will be able to insert the bearer interface into the applications that the issuer uses to manage the classic elements of its relationship with its customer. ( .K)

The management interface made available to the issuer in order to facilitate interactions between the invention and the bearer is optional in the event that the issuer wishes to develop its own bearer interface which will be able to directly interpret the information coming from or sent to the issuer API.

Claims (8)

Monetary transaction validation system in which transactions originating from a merchant (fig1.E) from a means of payment (Fig1.D) are subject to a validation process to determine whether said transaction should be authorized or not, characterized in that the system includes a transaction analysis device (fig1.G and fig3.N+O) and real-time categorization (fig1.H & Fig4 & Fig5) based on rules defined by a bearer (fig4, fig7.AE+AF+AG) holding said means of payment. Said system is integrated as an overlay with the conditions and limitations of use of a means of payment as defined (fig8.AC) by the issuer of the means of payment. System according to claim 1, characterized in that said device comprises an issuer API (fig2.I+I2) allowing said user, via a graphical interface (fig2.K), to follow (fig7.AH), define (fig7.AE), delete (fig7.AG) and update (fig7.AF) transaction filtering rules (fig7) according to freely chosen criteria (fig 4), as well as to notify the issuer (fig2.I+I1) of the actions determined by the categorization engine; and a processor API for accessing an analysis engine (fig3.F) interpreting the details of the transaction (fig3.N) and providing a response to the processor on the next step in the transaction (fig5.W). System according to claim 1 or 2, characterized in that said device allows the bearer holding the means of payment to create multi-criteria rules (Fig4.Q3 / Fig7) according to a hierarchical order (fig5.Q2), and in that when the transaction satisfies all the criteria defined by a rule thus entering the scope of the rule (Fig4.Q3), this rule is triggered and the action code (fig5.Q1 / Fig1.AA) is transmitted to the processor and the other rules which follow in the hierarchical order are abandoned (fig5.R). System according to claim 3, characterized in that the transaction is categorized by a default rule predefined by the user holding the means of payment (fig5.V) in the absence of a rule applicable to said transaction. System according to one of the preceding claims, characterized in that said device allows the holder of the means of payment to define dynamic rules taking into consideration the history of past transactions. (fig6.X) System according to one of the preceding claims, characterized in that said device allows the bearer holding the means of payment to define dynamic rules taking into consideration data elements coming from external sources. (fig6.Y) System according to one of the preceding claims, characterized in that said device allows the holder holding the means of payment to define a rule whose action (fig4.Q1) is a request for validation in real time by the holder (fig9.Q6). System according to one of the preceding claims, characterized in that said device allows the bearer holding the means of payment to create a single-use forcing token (fig. 5.U) which allows the next transaction to be authorized which will be returned to the processor by preempting the user rules and thus authorizing, if the available funds are sufficient, said transaction, said token then being destroyed.