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

Abstract

A monetary transaction security and filtering device that allows the holder of a payment method to categorize monetary transactions via a multi-criteria selection process, adjustable and applicable in real time, in order to define how a monetary transaction originating from the payment method should be processed based on these criteria and actions defined by the user. Figure for the abbreviation: Fig. 1.

Description

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

[0001] The invention is a computer processing device which is integrated into the process of validating monetary transactions initiated by a holder of means of payment [figl.C] carried out by transaction processors [figl.A], allowing the specifics of a monetary transaction to be qualified, to be determined according to a series of rules with multiple criteria, and consequently, to define whether said transaction should be authorized or not.

[0002] The invention complements the validation process established by payment processors [figl.A], to provide an additional validation layer accessible to payment means holders, thus enabling personalization of how a payment means [figl.D] is usable by its holder [fig 1 .C].

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

[0004] Definition of means of payment [figl.D]: refers to a medium enabling an individual to carry out a dematerialized financial transaction with a merchant [figl.E].

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

[0006] Issuer definition [fig. B]: is an organization that, within the framework of a service contract with the cardholder [fig. C], is able to create a means of payment [fig. D], make it available to the cardholder [fig. C], and manage its relationship with the cardholder. The issuer may also, optionally, provide the cardholder with tools [fig. 2. J] that allow the cardholder to manage the account linked to the means of payment issued to them, including, for example, checking the balance, past transactions, accessing PINs, authentication methods, etc. The issuer is the custodian of all relations with the cardholder.

[0007] Definition of processor [fig. A]: is responsible for processing transactions originating from the merchant [fig. E], and on the other side, the issuer [fig. B] of the payment method. The processor allows the parties to agree on the transaction and its purpose. The The processor is a single point of entry for processing transactions originating from payment methods initiated by a cardholder. Architecture Summary

[0008] The invention is integrated into the transaction processing workflow with the payment processor via the processor API [figl.F]. Thus, the processor can submit all transactions relating to a means of payment to the invention for processing and evaluation.

[0009] The invention makes it possible to define the use which can be made of the means of payment by restricting its use and strengthening 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.

[0010] The inventive device ([Fig. 1]) as a whole consists of: a. 1 API processor [figl.F] (link between the invention and the interbank network for processing monetary transactions) connected to the payment processor. i. The processor API receives the specific elements of a transaction and returns a response on the quality of said transaction and thus indicates what follow-up the processor should give it. b. 1 API issuer [figl.I] (link between the invention and the issuer of the means of payment, or sometimes called the provider of the means of payment) connected to the issuer of the means of payment. i. The issuer AOI is supplemented by an interface [fig2.K] which will be made available to the issuer to facilitate interaction between the payment method holder and the invention, via the issuer's application tools [fig2.J], and thus translate the interactions between the holder and the issuer API. (Fig5) c. An analysis engine [FigLG] d. A categorization engine [figl.H]

[0011] The analysis engine ([Fig.3].G) interprets and isolates the constituent elements of the ongoing transaction ([Fig.3].M) transmitted by the processor ([Fig.3].A) received via the processor API of the invention ([Fig.3].F). a. The analysis engine identifies and extracts ([Fig.3].N) the characteristics of said transaction in distinct elements ([Fig.3].O) as required ([Fig.3].P) by the categorization engine so that the latter can then exploit them and proceed to categorize the submitted transaction.

[0012] The categorization engine determines the quality of the transaction based on the analysis data ([Fig. 3].0). To do this, the categorization engine checks whether the transaction falls within the scope of one of the rules applicable to the payment method. The scope is defined by: a. A rule consisting of 1 or more criteria and a comparison value (logical operator) ([Fig.4].Q3). b. The rules are ranked in order of priority ([Fig.4].Q2). c. Each rule has a predefined action which stipulates the instruction which will be given to the processor as to the continuation to be given to said transaction ([Fig.4].Ql). d. A default rule ([Fig. 5].V), configurable by the holder, applies when the transaction falls outside the scope of any 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 provide a response to the processor.

[0013] At the end of the categorization, the processor API returns to the processor the action code ([Fig.1].AA) which must be applied to the transaction, and, at the same time, the Sender API transmits to the sender the relevant information ([Fig.2].II) which enabled the invention to qualify the transaction. State of the art

[0014] To date, issuers define the conditions of use of a payment method. Cardholders may, if the issuer allows it, adjust certain parameters of these conditions of use.

[0015] The payment method made available by the issuer includes a number of generic restrictions that define the intrinsic capabilities of the payment method, which are hard limits - that is to say, they are not modifiable by the user; this space is defined as "criterion 0"

[0016] Any transaction that is not within the scope of criterion 0 will be systematically refused (F8.AC) by the processor.

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

[0018] The invention relates in particular to a monetary transaction validation system in which transactions originating from a merchant using a means of payment are subject to a validation process to determine whether the said transaction should be authorized or not, characterized in that the system comprises a real-time transaction analysis and categorization device based on rules defined by a holder of said means of payment; said system being integrated in addition to the terms and conditions of use of a payment method as defined by the issuer of the payment method.

[0019] Furthermore, the system according to the invention may advantageously incorporate the following features alone or in combination: - Said device includes a sender 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 sender of actions determined by the categorization engine; and a processor API for access to an analysis engine interpreting the details of the transaction and providing a response to the processor on the follow-up to the transaction. - said device allows the holder of the means of payment to create multi-criteria rules in a hierarchical order, and in that when the transaction satisfies all the criteria defined by a rule thus falling within 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 payment method 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 account data elements from external sources. - said device allows the holder of the means of payment to define a rule whose action is a real-time validation request by the holder. - This device allows the holder of the payment method to create a one-time forcing token to instruct the categorization engine to provide a "forced validation" return code for the next transaction. This code will be returned to the processor, overriding user rules and thus authorizing the transaction if sufficient funds are available. The token is then "consumed".

[0020] The invention aims to enable a holder of a means of payment to define categories of transactions himself, and to indicate for each of these categories whether or not the processor should honor the transaction.

[0021] The wearer will have the option of defining a permissive or restrictive philosophy, that is, of choosing an approach: a. Anything that is not explicitly permitted is prohibited. b. or conversely, everything that is not explicitly prohibited is permitted.

[0022] Thanks to the invention, the holder of the means of payment is able to define subsets to 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 purposes desired for each of them.

[0023] For illustration: the Boolean superposition ([Fig.8].AD), of 3 criteria: (1 NOT (2 AND 3)) allows filtering 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 criteria 2 and 3. The scope being thus defined, the rule then applies an action to determine how the transactions which fall within this scope will be treated. a. For example, if we consider criterion 1 = transaction over €20, criterion 2 = online transaction and criterion 3 = weekend transaction, the rule defined by the scope given as an example in [Fig.8].AD would mean that the rule would apply to all transactions over €20, except those that are both on weekends and online. b. More generally, the cardholder is given the ability to define the conditions of use of their payment method according to one or more criteria, and to refine these criteria such as day of the week, time of use, type of merchant, merchant name, a specific country, a currency, etc., and to combine the chosen criteria to tailor the conditions of use to the cardholder's needs and ensure that the payment method cannot be used outside of what has been provided for by the rules. ([Fig.4])

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

[0025] Possible implementations of the invention include, for example: a. To allow parents who wish to allocate a means of payment to their child to limit its capabilities, b. To enable cardholders who wish to secure their means of payment by limiting the cases of unlikely and / or potentially fraudulent use. c. To allow companies that wish to provide payment methods to their employees and limit their use to specific contexts, etc...

[0026] The rules specific to the means of payment made available to the bearer are defined by the Bearer of the means of payment through an interface proposed by the invention ([Fig.7].K) and integrated by the issuer ([Fig.7].J) for the bearer's intention ([Fig.7].C). Details of how the analysis engine works

[0027] The raw data is delivered to the processor API ([Fig. 1].F)

[0028] The raw transaction data as supplied by the block processor must be partitioned by the analysis engine.

[0029] The first step for the API is to verify whether the connection from the processor is legitimate, using authentication keys and authentication certificates. ([Fig.3].Z) a. If authentication is satisfactory, the API checks if the transaction submitted for processing corresponds to a known and valid payment method. b. If the payment method is unknown, or if there is insufficient information to uniquely identify the payment method, 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 must determine how to handle the transaction independently. c. Other verification elements are processed, such as the date, time, and unique identifier of the transaction, to ensure that the date and time of the transaction are consistent (neither too old nor too far in the future) and that the transaction has not already been processed. If all the verifications are not satisfied, the process is rejected by the invention with an error code.

[0030] If the validation is satisfied ([Fig.3].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 ([Fig.3].G).

[0031] The purpose of the analysis engine is to locate in the data transmitted by The processor, the useful criteria ([Fig.3].P) (which are used by the categorization engine), and extract the corresponding values ​​([Fig.3].N). These values ​​will later serve as a basis for comparison with the target values ​​corresponding to the criteria of the categorization engine's rules.

[0032] For example, data transmitted by the processor may take the form: "transactionCurrencylson": "978". It will be isolated and the "Currency" criterion will be entered by the value "US Dollar" and the criterion "Foreign currency" will be entered by "True". a. Here, the information provided by the processor leads to the extraction of two criteria ([Fig. 3].O): "currency name = USD" and "foreign currency = true." These criterion values ​​will then be used by the categorization engine. In this way, the categorization engine can 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 ([Fig. 4].Q3).

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

[0034] Details of the operation of the categorization engine.

[0035] The purpose of the categorization engine is to check if 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.

[0036] The categorization engine has 2 rules which have the highest priority: a. Rule 1: The cover rule: Is the means of payment covered by the necessary funds? ([Fig. 5].T) b. Rule 2: The exception rule: Is there a forcing token that allows the holder to authorize the transaction without regard to the following rules? ([Fig.5].U) c. All the rules subsequently defined by the carrier then come into play. ([Fig.5].Q)

[0037] The coverage rule is a rule that preempts all other rules. Fundamentally, this rule restricts the capacity of the means of payment to the funds available to satisfy the transaction.

[0038] The exception rule relies on the forcing token functionality. The holder can create a forcing token that allows them to preempt a rule that would have blocked the transaction. a. The forcing token is for single use only. b. The forcing token is systematically used as soon as a transaction is presented to the categorization engine. c. The underlying rules are ignored when a token is in use. d. The action of a forcing token is always an authorization. e. The forcing token may - depending on the bearer's choice - have an expiry date. f. The forcing can also be destroyed directly by the user through the application made available to them by the issuer.

[0039] The categorization engine has access to all the rules defined by the carrier. A rule consists of: a. One or more conditions ([Fig.4].Q3) determining the scope of the rule b. An Action - the response that the engine must give to the processor if all conditions have been met. ([Fig.5].S) c. A flag indicating whether the rule is active – A boolean value that determines whether the rule is active or not. If the rule is not active, the engine will ignore it and move directly to the next one. d. A unique payment method identifier - This is a field containing the unique payment method identifier to which this rule applies e. A priority (to prioritize the order in which rules are processed) - This is a numerical value that determines the order in which the rules will be processed by the engine ([Fig.5].Q)

[0040] The rules are accessible to the holder at all times, and the holder can modify them whenever they wish; the rule is applied in real time. As soon as a rule is created, modified, or destroyed, the effect is instantaneous on subsequent transactions. ([Fig.7])

[0041] The transaction categorization process handles the rules in a precise order as defined by the user during the rule management phase ([Fig.7]) by adjusting the rule priority.

[0042] In the processing chain, all rules related to the source payment method of the transaction are identified, ranked by their priority order, and processed one after the other by the categorization engine. ([Fig.5].Q)

[0043] The rules all have a different priority in order to ensure that there can be no ambiguity about the order in which the rules are applied.

[0044] As soon as a rule is applied, subsequent rules are ignored, and the action taken is determined according to what is prescribed in the action field of the applied rule. ([Fig.5].S / W)

[0045] The rules include conditions. These conditions determine whether the transaction being processed falls within the scope of the rule, and is therefore affected by it. A rule can include from 1 to n conditions. ([Fig.4])

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

[0047] The criteria available on the platform are intended to evolve to allow the user to define the rules that suit them based on the information identified by the analysis engine. For example, the user could choose from a non-exhaustive list of criteria such as: - Transaction amount - Date - Day of the week - Time of the transaction - Geographical location - Merchant's name - Merchant Category (CID) - Merchant Identification (MID) - Identification of the terminal used - Type of transaction (online or physical) - Transaction description - Others

[0048] In addition to these criteria, there are dynamic criteria ([Fig. 6]), that is, criteria whose values ​​are calculated during each transaction. They are obtained either a. By calculation based on the history linked to the means of payment ([Fig.6].X) b. By obtaining values ​​from external sources ([Fig.6].Y)

[0049] The calculated dynamic criteria are obtained when a rule invokes the need to construct said criterion and its value in order to perform the comparison. To achieve this, the analysis engine accesses the historical database. For example, if a rule stipulates that the payment method must not be used more than twice a day, the categorization engine calculates the value of the requested criterion by counting the number of transactions that have already been processed on the same day, thus enabling the comparison. a. The calculations that can be applied to construct reference values ​​are not limited in nature, and may include, among other things, calculations of sums, quantities, and averages. b. For example, a query might take the form of: Calculate the sum of the "transaction amounts" in 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 comparison criterion which, for example, will be the total sum of transaction amounts for a merchant category over a specific period, and thus check if the total amount of past transactions is greater than, less than, or equal to the maximum sum allowed by the rule.

[0050] Criteria obtained (or imported) are criteria whose values ​​are constructed based on information provided by external databases. These criteria are not limited in nature. They can, for example, take the form of a reputation score for an online merchant site, or determine whether the day of the transaction is a public holiday or a school holiday. a. The imported criteria are acquired via a request to an external API which has the information sought from the data provider.

[0051] The set of criteria of a rule determines the scope of application of a rule. ([Fig.8])

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

[0053] The scope of a rule is defined by the overlap of the criteria which are satisfied by the transaction currently being processed. ([Fig.4]) ([Fig.8])

[0054] The conditions are hierarchically arranged in a combined AND / OR tree structure, as illustrated in the example in ([Fig.4].q3). Thus, for the rule to be applied to the transaction, it is necessary that the "Boolean sum" of the tree be "True" up to the root, that the rule be active, and that it be linked to the presented means of payment.

[0055] Once the rule is applied, subsequent rules are ignored ([Fig. 5]). The action that will be applied and reported to the processor will be the one specified in the rule.

[0056] A rule consists of one or more actions that determine the sequence to be given. ([Fig.4].Ql)

[0057] Once the action is known, the transaction is deemed to be "categorized"

[0058] The default rule ([Fig. 5].V) is a rule that applies when no other rule has been activated. It is a rule without any criteria and is therefore always applicable. The user can determine the action of this default rule and cannot add any criteria to it. a. The action of the default rule determines the philosophy of the payment method. b. The cardholder can choose a permissive approach, meaning that any transaction that has not been explicitly blocked is allowed by default. c. Conversely, the holder may decide on a restrictive philosophy, that is to say that any transaction which has not been explicitly authorized will be blocked. d. The holder makes this choice by selecting the share e. The default rule is always active. f. The default rule cannot be destroyed. The shares

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

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

[0061] The processor API has other codes that allow the processor to be informed of the status of the transaction processing, which can be used by the processor and / or the sender to process transactions differently

[0062] Here is a series of available code that can be passed to the processor: a. System Codes: i. Code 0x01 Success: Request viable for processing ii. Code 0x02 Error: Unknown card (Deep TIE did not find any rules matching this card) iii. Code 0x03 Error: error due to a timestamp fault (a date or time too far in the future or too far in the past) iv. Code 0x04 Error: Duplicate transaction ID: A transaction with the same ID has already been processed in the past (since each transaction has a unique ID, it is generally impossible to encounter two transactions with the same number). b. Code Actions: i. 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. ii. 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. iii. 1x03 DefOK: The transaction is allowed due to the default rule. None of the explicit rules applied to this transaction. iv. 1x04 DefNOK: The transaction is blocked due to the default rule. None of the explicit rules applied to this transaction. v. 1x05 TokenOK: The transaction is authorized due to the presence of a forcing token that was used. i. 1x06 FundsNOK: The transaction is declined. There are not enough funds available to cover the transaction. ii. 1x07 BypassOK: Pseudo-Declined Transaction. This return code is usually used primarily 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. iii. 1x08 WamOK: Transaction authorized with alert. The transaction is explicitly authorized by a rule, but requires separate notification to the cardholder. iv. 1x09 WamNOK: Transaction Refused with alert. The transaction is explicitly blocked by a rule, but it must also be subject to a separate notification to the cardholder. v. Code Challenge: i. 2x01 Challenge: The challenge code is a separate code because that it gives the bearer the possibility of choosing on a case-by-case basis whether the transaction should be valid. ii. 2x02 ChallengeOK: The challenge is finalized with the final action being the authorization of the transaction. iii. 2x03 ChallengeNOK: The challenge is finalized with the final action being the blocking of the transaction.

[0063] The actions are also transmitted via the issuer's API as a notification so that the latter can use the information corresponding to the transaction, and potentially transmit it to the bearer. Rule Challenge Action (Fig9)

[0064] 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 3D Secure by payment card networks (Visa, MasterCard, etc.).

[0065] This 3D Secure authentication only occurs for online (internet) payment transactions and requires the cardholder to validate the transaction through their bank. This 3D Secure authentication process is independent of the processing performed by the invention.

[0066] The 3DSecure verification is transmitted by the processor.

[0067] The invention is, however, able to park the 3dSecure request in order to proceed to an additional verification which can thus take the form of validation by a third party designated as a trusted authority by the holder. a. For example, if the holder of the means of payment is a child, the trusted third parties who should validate the transaction could be the parents.

[0068] This measure, which allows the 3D Secure or similar authentication request to be parked and a third party to be solicited, is designated as "challenge mode" by the invention. It is activated by a specific action code ([Fig.9].Q6).

[0069] When creating a rule, the categorization engine provides the holder with the option to choose a challenge mode to define the action. This option pauses the transaction processing and transmits, via the issuer API, an authorization delegation request accompanied by the transaction information.

[0070] The challenge action is accompanied by a default validation or blocking action in case of no response from the carrier. (Timeout)

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

[0072] When the issuer receives the challenge request, it may determine how it will resolve the challenge. For example, the issuer may contact the cardholder via the web or mobile application to validate or block the transaction that is the subject of the challenge.

[0073] As soon as the Challenge has been transmitted to the sender, the categorization engine awaits a response which can take 3 forms: a. The transaction is validated. b. The transaction is blocked c. Timeout: The sender did not provide a response within the allotted time. The challenge's default action is applied. (Not to be confused with the default rule.) Integration into the information system

[0074] The invention is integrated in 2 steps: a. 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. b. A "sender" API is made available so that i. The user, via an interface set up by the payment method provider, can define and modify the rules in force on their payment method. ii. That the issuer be notified of processed transactions, and to create and administer bearer accounts such as processing "Single Sign On" authentication operations.

[0075] A graphical management interface made available to the issuer. The issuer can insert the interface into the applications that the issuer uses to manage the standard elements of its relationship with its client. ([Fig.2].K)

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

Claims

Demands

1. A monetary transaction validation system, in which transactions originating from a merchant (Fig. E) from a means of payment (Fig. D) are subjected to a validation process to determine whether said transactions should be authorized or not, characterized in that the system includes a transaction analysis device (Fig. G and Fig. 3 N+O) and a real-time categorization device (Fig. H & Fig. 4 & Fig. 5) based on rules defined by a bearer (Fig. 4, Fig. 7).AE+AF+AG) holder of said means of payment, the device comprising an analysis engine and a categorization engine, the analysis engine being arranged to locate useful criteria in data of a current transaction transmitted by a processor, to extract corresponding values, and to create a normalized data structure that can be interpreted by the categorization engine, the categorization engine being arranged to check if there is a rule defined by the holder that applies to said current transaction and if so, to compare the values ​​of the criteria of the current transaction with target values ​​of the rule, so as to define an instruction that will be transmitted to the processor to process the current transaction, said system being integrated as an overlay to the conditions and limitations of use of a means of payment as defined (fig8.AC) by the issuer of the means of payment.

2. System according to claim 1, characterized in that said system comprises a sender API (fig2.I+I2) enabling 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 sender (fig2.I+Il) of the actions determined by the categorization engine; and a processor API for accessing the analysis engine (fig3.F) interpreting the details of the transaction (fig3.N) and providing a response to the processor on the follow-up to be given to the transaction (fig5.W).

3. A system according to claim 1 or 2, characterized in that said device enables the wearer holding the means to 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.Ql / Figl.AA) is transmitted to the processor and the other rules that follow in the hierarchical order are abandoned (fig5.R).

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

5. A 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 account the history of past transactions. (Fig. X)

6. A system according to any one of the preceding claims, characterized in that said device allows the holder of the means of payment to define dynamic rules taking into account data elements from external sources. (fig. Y)

7. System according to one of the preceding claims, characterized in that said device allows the holder of the means of payment to define a rule whose action (fig4.Q1) is a real-time validation request by the holder (fig9.Q6).

8. A system according to one of the preceding claims, characterized in that said device allows the holder of the means of payment to create a single-use forcing token (fig5.U) which allows the next transaction to be authorized, which will be returned to the processor by preempting the user rules and thus authorize, if the available funds are sufficient, said transaction, said token then being destroyed.

Images