Financial transaction system with multiple validations

Abstract

The invention relates to a financial transaction system with multiple validations (100), which concerns a method for carrying out financial transactions between a sending user (110) and a receiving user (120), wherein the sending user (110) presents a tokenised QR code (50) on a mobile device such that it can be scanned using the mobile device of the receiving user (120). The receiving user (120) then indicates the transaction amount (600) to be transferred on their mobile device, and the sending user (110) subsequently confirms the amount by entering an alphanumeric code (60) in order to carry out the transaction based on a cryptographic encryption, such that the funds (800) in the sending account (111) of the sending user (110) are verified to provide an authorised transaction (900) or a rejected transaction (901). If there are sufficient funds (800), the receiving user (120) receives the transaction amount (600) in the receiving account (121).

Description

[0001] Financial Transaction System with

[0002] Multiple Validations

[0003] OBJECT AND FIELD OF THE INVENTION

[0004] The present invention relates to a method and system for securing electronic payment and collection transactions between two entities, with multiple validations. More specifically, the present invention is directed to a method and system for ensuring the integrity of electronic transactions between at least one customer, one payer, and one beneficiary or supplier by means of a tokenized QR code and an alphanumeric confirmation code.

[0005] BACKGROUND OF THE INVENTION

[0006] In many financial or consumer transactions, it is increasingly necessary to provide security and ensure that transactions are bona fide and properly authorized. There are many benefits to using third-party payment devices, such as credit cards, for transactions; however, there are many shortcomings, dangers, and additional liability exposures for the parties involved, including: a payer or financial institution (used interchangeably herein); a vendor, donor, merchant, or payee (used interchangeably herein); and a customer, purchaser, beneficiary, or buyer (used interchangeably herein).

[0007] A large number of bank card transactions are currently conducted, in which once the cardholder has provided their credit card number and expiration date to a merchant, the merchant has ample opportunity to charge any amount up to the card's credit limit, and the buyer may not discover this at all unless they closely inspect their credit card statement and notice a discrepancy. There is simply no means available for a buyer to specify an amount and lock that amount in such a way that a merchant or seller cannot alter the amount. Furthermore, anyone who obtains possession of a buyer's credit card will, for the most part, be free to use that credit card number to make fraudulent purchases.Therefore, there is a need for a method and system to secure a third-party electronic payment transaction.

[0008] In the state of the art there are some developments to carry out financial transactions with security elements, for example, document US 8,290,876 B1, called "METHOD AND SYSTEM FOR SECURING AN ELECTRONIC THIRD PARTY PAYMENT TRANSACTION" refers to a method for securing electronic payment from a third party by means of a transaction comprising: electronically maintaining a third party payment account between a paying device and a customer; programmably configuring a customer transaction device, the customer transaction device communicating with a beneficiary transaction device; the paying device delivering an electronic transaction token from the payer to the customer transaction device;the customer transaction device generates a first validation information code based on information held by the customer, including at least: the electronic transaction token and a first version of a transaction amount; and, including the first validation code in a first portion of an electronic voucher device and transmitting the transaction to the payee; a payee transaction device adding a second version of the transaction amount to a second portion of the electronic voucher system; the payee transaction device transmitting the electronic voucher information to the payer device; the payer device receiving the electronic voucher independently generating a second validation code for the customer based at least on the electronic transaction token and the second version of the transaction amount;Validation includes comparing the second validation code with the first validation code. However, this system and method does not disclose a method for financial transactions between an issuing user and a receiving user that have a QR code tokenized with the data of each user, where the receiving user has their QR code on a mobile device and said QR code is scanned by a mobile device of the issuing user so that this issuing user enters an alphanumeric code to carry out a transaction based on a cryptographic encryption, such that the user's funds are verified to validate or reject the transaction; and that in case there are sufficient funds, the transaction is made to the receiving user.

[0009] Likewise, document US20140129428A1, entitled “QR CODE-ENABLED P2P PAYMENT SYSTEMS AND METHODS” relates to systems and methods for facilitating peer-to-peer payment transactions using mobile devices. The method comprises determining a financial account for funding the payment transaction, further including receiving input from the user comprising a payment amount for the payment transaction, and generating a QR code comprising a representation of the payment amount. Furthermore, the method comprises displaying the QR code on a screen of a mobile device for scanning by a second mobile device. Apparatus and systems for implementing the method, as well as for processing the generated QR code after it is scanned by the second mobile device, are also disclosed.However, this system and method does not disclose a method for financial transactions between an issuing user and a receiving user that have a QR code tokenized with the data of each user, where the receiving user has their QR code on a mobile device and said QR code is scanned by a mobile device of the issuing user so that this issuing user enters an alphanumeric code to carry out a transaction based on a cryptographic encryption, such that the user's funds are verified to validate or reject the transaction; and that in case there are sufficient funds, the transaction is made to the receiving user.

[0010] We can also find the document US11526885B2, entitled “Systems and methods for user identification using graphic barcodes and payment card authentication read data” refers to a method for authenticating an online transaction or a login process where the method comprises: receiving image data of a visual graphic barcode from a user device, and the visual graphic barcode is configured to be displayed on an unauthenticated device to perform the online transaction; parsing the image data to obtain a transaction validation identifier; comparing the transaction validation ID with a previously stored validation ID; comparing a first set of collection data from the user device with a second set of collection data that is previously stored;and determining whether to approve or reject the online transaction based on a match between the transaction validation ID and the previously stored validation ID. However, this system and method also does not disclose a method for financial transactions between an issuing user and a receiving user that have a QR code tokenized with the data of each user, where the receiving user has their QR code on a mobile device and said QR code is scanned by a mobile device of the issuing user so that this issuing user enters an alphanumeric code to carry out a transaction based on a cryptographic encryption, such that the user's funds are verified to validate or reject the transaction; and that in case there are sufficient funds, the transaction is made to the receiving user.

[0011] Similarly, document US20140172531A1 , titled “Performing Transactions Using QR Codes,” refers to conducting transactions using a quick response (QR) code and purchasing items directly from a seller using a QR code. In one scenario, a computer system receives, from a buyer, an indication of the items to be purchased using a mobile wallet application and determines a total price for those items. The computer system then receives a tokenized QR code that includes embedded account information for the buyer. The computer system generates a second tokenized QR code that includes encrypted account information for the seller, along with encrypted account information for the buyer and the determined total price of the items to be purchased, and submits the second tokenized QR code to a transaction.This method relies on the use of two tokenized QR codes to complete the transaction, which requires two QR code readings. However, this system also does not disclose a method for financial transactions between an issuing user and a receiving user who have a tokenized QR code with each user's data. The receiving user has their QR code and displays it on a mobile device. The QR code is scanned by the issuing user's mobile device to link it to the receiving user. The issuing user then enters the amount they wish to transfer on their mobile device and then enters an alphanumeric code to complete a cryptographically encrypted transaction. The issuing user's funds are verified to validate or reject the transaction. If sufficient funds are available, the transaction is made to the receiving user.

[0012] Likewise, document WO2013054058, called “METHOD FOR CARRYING OUT AN ELECTRONIC TRANSACTION” refers to a method for carrying out an electronic transaction for a service, the method comprising the steps of: receiving, by a server from a first terminal, a request to create an electronic transaction corresponding to a requested service; saving first information about said electronic transaction on the server; sending first information about said electronic transaction from the server to the first terminal; generating, by the server, a transaction code (QR-C) comprising an identifier of said electronic transaction; sending the transaction code (QR-C) from the server to the first terminal; scanning said transaction code (QR-C) by means of a second terminal; sending second information about said electronic transaction from the server to the second terminal based on the scanned transaction code (QR-C);receive from the server a personal identification number (PIN) and validation information for the electronic transaction that are sent by the second terminal; send an electronic transaction confirmation from the server to the first terminal and to the second terminal. However, this system also does not disclose a method for financial transactions between an issuing user and a receiving user who have a QR code tokenized with the data of each user, where the receiving user has their QR code and displays it on a mobile device and said QR code is scanned by a mobile device of the issuing user to link it with the receiving user, then the issuing user indicates the amount they wish to transfer on their mobile device and subsequently enters an alphanumeric code to carry out a transaction based on a cryptographic encryption, so that the funds of the issuing user are verified to validate or reject the transaction;and if there are sufficient funds, the transaction is made to the receiving user.

[0013] Finally, we can find document WO2018229800, entitled “SYSTEM AND METHOD FOR ELECTRONIC FINANCIAL TRANSACTIONS BASED ON QR CODE” which refers to a system and method for an electronic financial transaction based on a QR code, comprising a QR code generator that generates one or more QR codes corresponding to one or more physical payment cards of a customer. The generated QR code is in encrypted format and is saved on a customer's computing device. A QR code scanner present at a merchant's location is used to scan encrypted QR codes and forward encrypted QR codes to a competent authority for validation. The merchant can specify an amount to be deducted from the physical payment card associated with the QR code. The received QR code is decrypted. The authenticity of one or more details related to the customer and the physical payment cards associated with the code is validated.Following successful validation, the requested transaction is processed using the QR code. However, this system also does not disclose a method for financial transactions between a sender and a recipient who have a QR code tokenized with each user's data. The recipient has their QR code and displays it on a mobile device. The QR code is scanned by the sender's mobile device to link it to the recipient's. The sender then enters the amount they wish to transfer on their mobile device and subsequently enters an alphanumeric code to carry out a transaction based on cryptographic encryption. The sender's funds are verified to validate or reject the transaction. If sufficient funds are available, the transaction is transferred to the recipient.

[0014] TECHNICAL PROBLEM TO BE SOLVED

[0015] The aim is to provide a system and method for conducting financial transactions between an issuing user and a receiving user with a mobile device that has a tokenized QR code configured with each user's data, including financial and banking data, where the receiving user has their tokenized QR code and displays it on a mobile device so that said tokenized QR code is scanned by the issuing user's mobile device. The issuing user then indicates the amount they wish to transfer on their mobile device and subsequently enters an alphanumeric code to carry out a transaction based on cryptographic encryption, such that the issuing user's funds are verified to validate or reject the transaction; and if sufficient funds are available, the transaction is made to the receiving user.

[0016] This creates a method for conducting secure and rapid financial transactions with three validations: the first validation involves scanning the tokenized QR code, the second validation involves entering a previously configured alphanumeric code, and finally, a third validation involves the validation of funds.

[0017] BRIEF DESCRIPTION OF THE FIGURES

[0018] In the following detailed description, reference is made to the accompanying figures that show, by way of illustration, specific embodiments or examples; however, these drawings are not drawn to scale. Like numbers represent similar elements in all figures.

[0019] Figure 1 is a block diagram of the elements of the Financial Transaction System with Multiple Validations (100) and the communication with the database in the Cloud (40).

[0020] Figure 2 shows a block diagram of the three-validation sequence of the Multiple Validation Financial Transaction System (100).

[0021] Figure 3 is a block diagram of a Multiple Validation Financial Transaction System (100) with the process steps, according to some embodiments of the present invention.

[0022] Figure 4 shows a block diagram of the data registration process (200) and tokenization of the tokenized QR code (50) of each user.

[0023] Figure 5 shows a diagram of the login process of a registered user (210).

[0024] Figure 6 shows a block diagram with the process of the first validation (10) which involves scanning the tokenized QR code (50).

[0025] Figure 7 shows a block diagram of the second validation process (20) which comprises entering a previously configured alphanumeric code (60). Figure 8 shows a block diagram of the third validation process (30) which comprises validating the funds (800) of the issuing user (110).

[0026] Figure 9 shows a block diagram of the data processing following the three validations of the financial transaction.

[0027] Below is a list of the parts indicated in the figures:

[0028] - First validation (10)

[0029] - Second validation (20).

[0030] - Third validation (30).

[0031] - Cloud (40).

[0032] - Tokenized QR code (50).

[0033] - Alphanumeric Code (60).

[0034] - Financial Transaction System with Multiple Validations (100).

[0035] - Issuing user (110).

[0036] - Issuing account (111).

[0037] - Receiving user (120).

[0038] - Receiving account (121).

[0039] - Data logging (200).

[0040] - Personal data (201).

[0041] - User (202).

[0042] - Password (203).

[0043] - Financial data (204).

[0044] - Payment method (205).

[0045] - Registered user (210).

[0046] - PIN setting (300).

[0047] - Transaction type (400).

[0048] - QR code reading (500).

[0049] - Transaction amount (600).

[0050] - Amount confirmation (601). - PIN validation (700).

[0051] - Validated PIN (701).

[0052] - Incorrect PIN (702).

[0053] - Funds (800).

[0054] - Transaction authorized (900).

[0055] - Transaction rejected (901).

[0056] - Receipt (903).

[0057] DETAILED DESCRIPTION OF THE INVENTION

[0058] Referring in more detail to the drawings, as shown in Figure 1 through Figure 9, a Multi-Validation Financial Transaction System (100) is described. Other embodiments of the present invention entitled Multi-Validation Financial Transaction System (100) are considered within the present inventive concept, as described in the claims of this specification.

[0059] The Financial Transaction System with Multiple Validations (100) which refers to a method for carrying out secure and fast financial transactions with three validations, where the first validation (10) comprises scanning the tokenized QR code (50) with the data of the issuing bank account (111) of the issuing user (110), the second validation (20) comprises entering a previously configured alphanumeric code (60), and finally, a third validation (30) of funds (800) of the issuing account (111).

[0060] The Multiple Validation Financial Transaction System (100) refers to a method for carrying out financial transactions between an issuing user (110) and a receiving user (120) with a mobile device that has a tokenized QR code (50) with the data of each user, including financial and banking data, where the issuing user (110) shows his tokenized QR code (50) on a mobile device so that said code is scanned with the mobile device of the receiving user (120), then the receiving user (120) indicates on his mobile device the transaction amount (600) that he wants to be transferred and subsequently the issuing user (110) enters an alphanumeric code (60) to confirm the amount and carry out the transaction based on a cryptographic encryption, so that the funds (800) in the issuing account (111) of the issuing user (110) are verified to obtain an authorized transaction (900) or a rejected transaction (901);In case there are sufficient funds (800), the receiving user (120) receives the transaction amount (600) in the receiving account (121).;

[0061] Figure 1 shows that the Multiple Validation Financial Transaction System (100) is made up of five essential elements: an issuing user (110) and a receiving user (120) where each user uses electronic equipment such as a telephone, electronic tablet or computer equipment to enter and use the Multiple Validation Financial Transaction System (100); a cloud server (40) which stores the data of the Multiple Validation Financial Transaction System (100); the issuing bank account (11) of the issuing user (110) from which the Transaction Amount (600) is extracted; and, the receiving account (121) of the receiving user (120) where the transaction amount (600) is deposited and transferred.

[0062] The data of the Financial Transaction System with Multiple Validations (100) that is backed up in the cloud (40) may be information related to the financial operation, such as products, services, events, auctions, promotions, discounts.

[0063] Figure 2 shows the flow and the stepped sequence of the multiple validations of the Financial Transaction System with Multiple Validations (100) where it is carried out in the following order:

[0064] - a first validation (10) comprising the receiving user (120) scanning, from his mobile device, the tokenized QR code (50) with the data of the issuing account (111) of the issuing user (110); - in case the first validation (10) has been successful, a second validation (20) is carried out comprising the receiving user (120) entering the amount of the transaction (600) and the issuing user (110) confirming the operation with a previously configured alphanumeric code (60);

[0065] - if the second validation (20) has been successful, a third validation (30) is carried out, which includes verifying the existence of sufficient funds (800) in the issuing account (111) and making the movement of funds (800) towards the receiving account (121).

[0066] Figure 3 shows the block diagram with the sequence of validation stages indicated in Figure 2, where before the first validation (10) the data registration (200) or the login to registered user (210) is carried out with a user (202) and password (203).

[0067] When the user enters the Multiple Validation Financial Transaction System (100) for the first time, the Multiple Validation Financial Transaction System (100) requests the user to configure data and register their data (200) that will be saved in the cloud server (40); when a user has already registered, the subsequent times that they enter the Multiple Validation Financial Transaction System (100) the Multiple Validation Financial Transaction System (100) requests the user for their username (202) and password (203) to validate their identity with the data saved in the cloud server (40) and give access to the Multiple Validation Financial Transaction System (100).

[0068] The registration of your data (200) to enter for the first time to the Financial Transaction System with Multiple Validations (100), may include Personal Data (201), the User (202), the Password (203), Financial Data (204) and Payment Methods (205). The personal data may include a biometric authentication process, also known as verification, which consists of a process by which the data of the characteristics of a person are compared with the biometric "template" of that person, in order to determine their similarity. The user (202) is a string of alphanumeric characters that the user indicates. The Financial Transaction System with Multiple Validations (100) is configured so that there are no duplicate users (202).

[0069] The password (203) is a string of alphanumeric characters that the user indicates at the registration stage and that can be modified later by the user.

[0070] Registered users must set an alphanumeric code (60) to complete the PIN Setup step (300). The Multi-Validation Financial Transaction System (100) is configured to require users to set PIN (300) before making financial transfers. If PIN Setup (300) is not performed, users cannot make transfers.

[0071] The Financial Data (204) comprises the bank details associated with the user's receiving account (121); the Multi-Validation Financial Transaction System (100) is configured so that the user can indicate one or more bank details of a receiving account (121); in case more than one receiving account (121) is configured, the Multi-Validation Financial Transaction System (100) is designed so that the user can establish a default receiving account (121) so that all Transaction Amounts (600) derived from transfers are deposited in said default account.

[0072] The Payment Methods (205) comprise the configuration of bank cards or funds account associated with the issuing account (111) of the user; the Financial Transaction System with Multiple Validations (100) is configured so that the user indicates at least one payment method (205) of his issuing account (111); in case more than one payment method (205) is configured, the Financial Transaction System with Multiple Validations (100) is designed so that the user can establish a payment method (121) from which the Transaction Amount (600) is extracted.

[0073] The Multi-Validation Financial Transaction System (100) presents a funds account (800) associated with each registered user (210) where the account can have different types of currencies of receiving currencies and cryptocurrencies, where the funds (800) of cryptocurrencies can be used as Transaction Amount (600) to transfer cryptocurrencies from the issuing account (111) to the receiving account (121).

[0074] Likewise, the Financial Transaction System with Multiple Validations (100) currencies can be configured so that any registered user can exchange currencies or buy cryptocurrencies with the funds (800) in his / her account.

[0075] Figure 3 also shows the sequence of the process carried out in the Financial Transaction System with Multiple Validations (100) where the user who registers for the first time or the registered user (210) enters with his / her username (202) and password (203) to start the financial transaction through the 3 validations.In the first instance, the receiving user (120) indicates the type of transaction (400) and then reads the QR code (500) of the tokenized code (50) of the issuing user (110), thereby completing the first validation (10); then, the receiving user (120) indicates the transaction amount (600) and then the Financial Transaction System with Multiple Validations (100) performs the PIN validation (700) where the issuing user (110) enters their Alphanumeric Code (60) to confirm the amount and complete the second validation (20); Finally, the Multiple Validation Financial Transaction System (100) verifies the funds (800) of the issuing account (111) of the issuing user (110) to determine if the funds (800) have the necessary amount to send the Transaction Amount (600) to the receiving account (121) of the receiving user (120), thereby completing the third validation (30).After the third validation (30), the Financial Transaction System with Multiple Validations (100) generates a receipt (903) of the operation with the data of the financial operation that is sent to the issuing user (110) and the receiving user (120).

[0076] When the process is completed, the user can start another financial operation in the Financial Transaction System with Multiple Validations (100) by indicating again the Transaction Type (400) and following the steps described above.

[0077] Figure 4 shows a block diagram of the data registration process (200) and tokenization of the tokenized QR code (50) of each user where the Financial Transaction System with Multiple Validations (100) requests each user for their personal data (201), username (202), password (203), financial data (204) and payment methods (205), where the Financial Transaction System with Multiple Validations (100) automatically tokenizes the data into a single QR code associated with each registered user (210).

[0078] Figure 5 shows a diagram of the login process of a registered user (210) where the Financial Transaction System with Multiple Validations (100) requests the registered user (210) for his / her username (202) and password (203) to use the Financial Transaction System with Multiple Validations (100).

[0079] Figure 6 shows a block diagram with the process of the first validation (10) which involves scanning the tokenized QR code (50) that includes the choice of a Transaction Type (400) by the receiving user (120), then the issuing user (110) shows his tokenized QR code (50), then the receiving user (110) enters his account within the Financial Transaction System with Multiple Validations (100) to scan with an electronic device the tokenized QR code (50) of the issuing user (110) so that the Financial Transaction System with Multiple Validations (100) takes and links the banking data (204) of the issuing user (120) and the receiving user (110) saved in the cloud server (40).

[0080] Figure 7 shows a block diagram with the process of the second validation (20) which comprises entering a previously configured alphanumeric code (60), where the receiving user (120), from his / her same electronic device, must indicate the Transaction Amount (600) and then the issuing user (110) performs the Amount Confirmation (601); then the Financial Transaction System with Multiple Validations (100) will perform the PIN Validation (700) and will request the issuing user (110) for his / her Alphanumeric Code (60).

[0081] When the Alphanumeric Code (60) is incorrect, the Financial Transactions with Multiple Validations system (100) determines that it is an incorrect PIN (702) and will request the issuing user (110) to indicate their Alphanumeric Code (60) again; if the Alphanumeric Code (60) is correct, the Financial Transactions with Multiple Validations system (100) will determine that it is a Valid PIN (701) and will continue with the third validation (30).

[0082] The Alphanumeric Code (60) of the second validation (20) can be of 'n' digits, equally, for all registered users (210), where the security level will be higher when there are more digits.

[0083] Figure 8 shows a block diagram with the third validation process (30) that includes the validation of funds (800) of the issuing user (110); first, the Financial Transactions with Multiple Validations system (100) will send the information of the transaction amount (600) that the issuing user (110) wishes to transfer to the cloud server (40), then the Financial Transactions with Multiple Validations system (100) will verify the funds (800) of the issuing account (111), according to the configured payment method (205); If there are not enough funds (800) to carry out the operation, the Financial Transactions with Multiple Validations system (100) determines that it is a rejected Transaction (901) and will request the receiving user (120) to indicate the transaction amount again (600) and the issuing user (110) to confirm and enter their alphanumeric code (60);If there are sufficient funds (800) to carry out the operation, the Financial Transactions with Multiple Validations system (100) determines that it is an authorized Transaction (900) and will automatically send the amount indicated in the transaction amount (600) from the issuing account (111) to the receiving account (121), see also figure 1.;

[0084] Figure 9 shows a block diagram with the data processing after the three validations of the financial transaction, which includes a notification of the operation carried out, where the issuing user (110) and the receiving user (120) receive a notification with a Receipt (903) containing the detailed information of the operation. The notification can be through the same application, email, SMS message and also being registered in a transaction movement panel.

[0085] The Multiple Validation Financial Transaction system (100) can be configured so that the receipt (903) of the operation can be a note, payment receipt or invoice with the Personal Data (201), Financial Data (204) and Payment Method (205) of each user.

[0086] Once the receipt is issued (903) users can perform another operation to transfer or receive funds through the Financial Transactions with Multiple Validations system (100) by returning to the step of choosing the type of transaction (400).

[0087] The Multiple Validation Financial Transaction System (100) can be configured as a virtual shopping center to enter products or services of companies to form a catalog, so that the issuing user (110) and the receiving user (120) are associated with the sale or purchase of said products or services within the catalog. The receiving user (120) can generate and configure companies within the system to register products and services to form the catalog. The tokenized QR codes (50) of the products or services can be printed on plastic cards, metal cards, coins, coupons, physical tokens, badges, brochures, printed documents, advertising and electronic media. Likewise, the tokenized QR codes (50) can be replaced with other types of tokenized printed codes, such as barcodes.

[0088] The Financial Transaction System with Multiple Validations (100) can be configured to have a smart contract generator in the First validation (10) that establishes the conditions under which the commercial exchange will be carried out and the product or service that will be delivered when making the payment. The smart contract can have the Personal Data (201) captured by each user and the data of the final Receipt (903) of the transaction. In addition, the Financial Transaction System with Multiple Validations (100) can be configured to display a preview of the contract in the first validation stage (10) and be signed by the issuing user (110) and the receiving user (120).

[0089] Likewise, the products or services of the virtual shopping center of the Financial Transactions with Multiple Validations (100) may have a tokenized QR code (50) associated with the amount of the value of the product or service, in such a way that in the first validation (10) the transaction amount (600) is automatically entered when reading the tokenized QR code (50).

[0090] The Multiple Validation Financial Transaction System (100) can be installed and configured for operation on mobile devices or computer equipment, where the issuing user (110) and the receiving user (120) can interchangeably use some of these devices to make or receive financial transactions.

Claims

CLAIMS 1. A Multiple Validation Financial Transaction System (100) comprising an issuing user (110) and a receiving user (120) where each user uses electronic equipment such as a telephone, electronic tablet or computer equipment to enter and use the Multiple Validation Financial Transaction System (100); a cloud server (40) which stores the data of the Multiple Validation Financial Transaction System (100); an issuing bank account (11) of the issuing user (110) from which a Transaction Amount (600) is extracted;and, a receiving account (121) of the receiving user (120) where the amount of the transaction (600) is deposited and transferred, where said Financial Transaction System with Multiple Validations (100) carries out secure and fast financial transactions by means of a three-validation process, characterized in that the process comprises the following stages: a first validation (10) comprising the receiving user (120) scanning, from his mobile device, the tokenized QR code (50) with the data of the issuing account (111) of the issuing user (110); a second validation (20) comprising the receiving user (120) entering the amount of the transaction (600) and the issuing user (110) confirming the operation with a previously configured alphanumeric code (60); a third validation (30) that includes verifying the existence of sufficient funds (800) in the issuing account (111) and making the movement of funds (800) towards the receiving account (121).; 2. The Financial Transaction System with Multiple Validations (100), as claimed in claim 1, characterized in that the first validation (10) comprises the following steps: the receiving user (120) enters his account within the Financial Transaction System with Multiple Validations (100) and chooses the Type of transaction (400); the issuing user (110) shows his tokenized QR code (50); the receiving user (120) scans with an electronic device the tokenized QR code (50) of the issuing user (110); the Financial Transaction System with Multiple Validations (100) obtains the banking data (204) of the issuing user (110) and of the receiving user (120) saved in the cloud server (40); 3. The Financial Transaction System with Multiple Validations (100), as claimed in claims 1 and 2, characterized in that the Type of transaction (400) can be an operation for the purchase of products, services, events, auctions, promotions, discounts.

4. The Financial Transaction System with Multiple Validations (100), as claimed in claims 1 and 2, characterized in that the Transaction Type (400) can be an event database for the acquisition of tickets or services such as transfers, lodging, meals, VIP tickets, food, drinks, food and services associated with the organization of events.

5. The Financial Transaction System with Multiple Validations (100), as claimed in claims 1 and 2, characterized in that it has an automatic payment button to obtain the transaction type data (400) automatically associated with the database of events with services and products instead of scanning the tokenized QR code (50).

6. The Financial Transaction System with Multiple Validations (100), as claimed in claims 1 and 2, characterized because the automatic payment button can be inserted by means of a programming code in an external electronic platform, where said code is generated from the Financial Transaction System with Multiple Validations (100) to make collections associated with the Personal Data (201) and banking data (204) of the issuing user (110) and the receiving user (120) saved in the cloud server (40).

7. The Financial Transaction System with Multiple Validations (100), as claimed in claims 1 and 2, characterized in that the tokenized QR code (50) of the issuing user (110) contains the personal data (201) and financial data (204) of the issuing account (111), which is automatically generated by the Financial Transaction System with Multiple Validations (100).

8. The Financial Transaction System with Multiple Validations (100), as claimed in claims 1 and 2, characterized in that the tokenized QR code (50) can be presented in a different barcode mode.

9. The Financial Transaction System with Multiple Validations (100), as claimed in claim 1, characterized in that the second validation (20) comprises the following steps: the receiving user (120) indicates the Transaction Amount (600); the Financial Transaction System with Multiple Validations (100) requests the issuing user (110) for his Alphanumeric Code (60) to carry out the Amount Confirmation (601).

10. The Financial Transaction System with Multiple Validations (100), as claimed in claims 1 and 5, characterized in that when the Alphanumeric Code (60) is incorrect, the system Financial Transactions with Multiple Validations (100) determines that it is an incorrect PIN (702) and will request the issuing user (110) to re-enter their Alphanumeric Code (60); if the Alphanumeric Code (60) is correct, the Financial Transactions with Multiple Validations system (100) will determine that it is a Valid PIN (701) and will continue with the third validation (30).

11. The Financial Transaction System with Multiple Validations (100), as claimed in claim 1, characterized in that the Alphanumeric Code (60) can be of 'n' digits, equally, for all registered users (210), where the level of security will be higher when there are more digits.

12. The Multiple Validation Financial Transaction System (100), as claimed in claim 1, characterized in that the third validation (30) comprises the following steps: verifying the funds (800) of the issuing account (111) of the issuing user (110); if there are not enough funds (800) to carry out the operation, the Multiple Validation Financial Transaction System (100) determines that it is a rejected Transaction (901) and will request the receiving user (120) to indicate the transaction amount (600) again; if there are sufficient funds (800) to carry out the operation, the Multiple Validation Financial Transaction System (100) determines that it is an authorized Transaction (900) and will send the amount indicated in the transaction amount (600) from the issuing account (110) to the receiving account (120).

13. The Financial Transaction System with Multiple Validations (100), as claimed in claim 1, characterized in that the Transaction amount (600) will be sent from the issuing account (110) to the receiving account (120) automatically or until the issuing user (110) authorizes and confirms the receipt of the products or services purchased by capturing their Alphanumeric Code (60).

14. The Financial Transaction System with Multiple Validations (100), as claimed in claim 1, characterized in that after the process of the three validations of the financial transaction, the issuing user (110) and the receiving user (120) receive a notification with a Receipt (903) that contains the detailed information of the operation, which can be a note, payment receipt or invoice with the Personal Data (201), Financial Data (204) and Payment Method (205) of each user, where the notification can be through the same application, email, SMS message and also being registered in a transaction movement panel.

15. The Financial Transaction System with Multiple Validations (100), as claimed in claim 1, characterized in that the notification can be accompanied by advertisements that have an electronic link to open the product or service shown in the advertisement.

16. The Financial Transaction System with Multiple Validations (100), as claimed in claim 1, characterized in that once the receipt (903) is issued, users can perform another operation to transfer or receive funds through the Financial Transaction System with Multiple Validations (100) by returning to the step of choosing the type of transaction (400).

17. The Financial Transaction System with Multiple Validations (100), as claimed in claim 1, characterized in that before From the first validation (10) the data registration (200) or the entry to registered users (210) is carried out with a user (202) and password (203).

18. The Financial Transaction System with Multiple Validations (100), as claimed in claims 1 and 11, characterized in that when the Financial Transaction System with Multiple Validations (100) is entered for the first time, the Financial Transaction System with Multiple Validations (100) requests the user to configure data and register their data (200) that will be protected in the cloud server (40) that may include Personal Data (201), the User (202), the Password (203), Financial Data (204) and Payment Methods (205). In case the data registration is not carried out, the Financial Transaction System with Multiple Validations (100) will delete the account in a time previously configured in the cloud.

19. The Financial Transaction System with Multiple Validations (100), as claimed in claims 1 and 11, characterized in that when a user has already registered, the Financial Transaction System with Multiple Validations (100) requests the user for his / her username (202) and password (203) to validate his / her identity with the data saved in the cloud server (40) and give access to the Financial Transaction System with Multiple Validations (100).

20. The Financial Transaction System with Multiple Validations (100), as claimed in claims 1 and 12, characterized in that the personal data may include a biometric authentication process, also known as verification, which consists of a process by which the data of the characteristics of a person are compared. person with the biometric "template" of that person, in order to determine their similarity.

21. The Financial Transaction System with Multiple Validations (100), as claimed in claims 1 and 12, characterized in that the Financial Data (204) comprises the banking data associated with the receiving account (121) of the user, where the Financial Transaction System with Multiple Validations (100) is configured so that the user indicates at least the banking data of a receiving account (121) or, indicates the financial data of the internal system or transactions of the Financial Transaction System with Multiple Validations (100);In case more than one receiving account (121) is configured, the Multiple Validation Financial Transaction System (100) is designed so that the user can establish a default receiving account (121) so that all Transaction Amounts (600) derived from transfers are deposited in said default account, likewise, users may not have a bank account registered in the system.

22. The Financial Transaction System with Multiple Validations (100), as claimed in claims 1 and 12, characterized in that the payment methods (205) comprise the configuration of bank cards or funds account associated with the issuing account (111) of the user, where the Financial Transaction System with Multiple Validations (100) is configured so that the user indicates at least one payment method (205) of his issuing account (111); in case more than one payment method (205) is configured, the Financial Transaction System with Multiple Validations (100) is designed so that the user can establish a payment method (121) default and is selected to perform the transaction from which the Transaction Amount (600) is extracted.

23. The Multiple Validation Financial Transaction System (100), as claimed in claim 1, characterized in that the funds (800) associated with each registered user (210) can be of different types of currencies, coins, bonds, deeds, any value transaction, accounts associated with institutions for the deposit of securities and cryptocurrencies, where the cryptocurrency funds (800) can be used as Transaction Amount (600) to transfer cryptocurrencies from the issuing account (111) to the receiving account (121).

24. The Financial Transaction System with Multiple Validations (100), as claimed in claim 1, characterized in that the Financial Transaction System with Multiple Validations (100) can be configured so that any registered user can exchange currencies and also buy and pay with cryptocurrencies with the funds (800) in his / her account.

25. The Financial Transaction System with Multiple Validations (100), as claimed in claim 1, characterized in that registered users must establish an alphanumeric code (60) to perform the PIN Configuration step (300), where the Financial Transaction System with Multiple Validations (100) is configured so that users perform the PIN configuration (300) before making financial transfers.

26. The Financial Transaction System with Multiple Validations (100), as claimed in claim 1, characterized in that said Financial Transaction System with Multiple Validations (100) can be configured as a virtual shopping center, point of sale type terminal, digital exchange house, event system, restaurant or e-commerce to enter products or services of companies to form a catalog, so that the issuing user (110) and the receiving user (120) associate the financial transaction with the sale or purchase of said products or services within the catalog; likewise, the receiving user (120) can generate and configure companies within the system to register products and services to form the catalog which can be used as 27. The Financial Transaction System with Multiple Validations (100), as claimed in claim 1, characterized in that said Financial Transaction System with Multiple Validations (100) can be configured to have a generator of smart contracts in the First validation (10) that establish the conditions in which the commercial exchange will be carried out and the product or service that will be delivered when making the payment, where the smart contract can have the Personal Data (201) captured by each user and the data of the final Receipt (903) of the transaction.

28. The Financial Transaction System with Multiple Validations (100), as claimed in claims 1 and 21, characterized in that, in addition, said Financial Transaction System with Multiple Validations (100) can be configured so that a preview of the smart contract is shown in the stage of the first validation (10) and is signed by the issuing user (110) and the receiving user (120).

29. The Financial Transaction System with Multiple Validations (100), as claimed in claims 1 and 20, characterized in that the products or services of the virtual shopping center of the System of Financial Transactions with Multiple Validations (100) can have a tokenized QR code (50) associated with the amount of the value of the product or service, such that in the first validation (10) the transaction amount (600) is automatically entered when reading the tokenized QR code (50), where said QR code is automatically generated by the Financial Transaction System with Multiple Validations (100) for each product, service or user.

30. The Financial Transaction System with Multiple Validations (100), as claimed in claims 1 and 20, characterized in that the tokenization of the tokenized QR code (50) is carried out in a private blockchain of the Financial Transaction System with Multiple Validations (100), by means of an encrypted code applied to all information sent and received within the system.

31. The Financial Transaction System with Multiple Validations (100), as claimed in claims 1 and 20, characterized in that said Financial Transaction System with Multiple Validations (100) can be installed and configured for operation on mobile devices or computer equipment, where the issuing user (110) and the receiving user (120) can interchangeably use some of these equipment to carry out or receive financial transactions.

32. The Financial Transaction System with Multiple Validations (100), as claimed in claims 1 and 20, characterized in that the tokenized QR codes (50) of the products or services can be printed on plastic cards, metal cards, coins, coupons, physical tokens, badges, brochures, printed documents, advertising and electronic media.

33. The Financial Transaction System with Multiple Validations (100), as claimed in claims 1-26, characterized in that the tokenized QR codes (50) can be replaced by another type of tokenized printed codes, such as barcodes.

34. The Financial Transaction System with Multiple Validations (100), as claimed in claims 1-26, characterized in that the messages or notices derived from the use of the account of any of the registered or unregistered users may be accompanied by one or more advertisements that have an electronic link to open the product or service shown in the advertisement.

Images