Consensual interactive transactions

Abstract

A system of consenting, acknowledging, controlling, and tracking transactions introduces a digital approach to collect consent from the both the transaction maker (the payer or sender) and the transac

Description

Background / Summary 1. Field of the Invention (1) The present invention relates to collecting digital consent on Transactions from The Transaction’s Maker when making it and from The Transaction’s Beneficiary when accepting it to protect the identity holders from abuse and misuse as well as to define the liabilities and connections between all involved parties. This invention applies to any transaction that involves a Maker (or Makers) and a Beneficiary (or Beneficiaries). 2. Problem to be Solved (2) Several existing methods used to collecting consents with respect to making a transaction e.g. signature on paper and banking mobile apps have been in use. None of them, however, collect consent from The Beneficiary’s Identity Holder to confirm their relationship and acceptance with regards to The Transaction, prevent accidental transactions, and none of them protect against cyber-flag. (3) People are subject to make Accidental Transactions: The Transaction’s Maker is subject to accidentally make a transaction to an undesirable party; whereby, The Transaction’s Maker may mistype The Transaction’s Beneficiary, may mistakenly select wrong Beneficiary, an employee at The Maker’s Establishment could perform an error, or any other potential mistake. These mistakes can pose financial issues to The Transaction’s Maker as well as complications to both The Maker’s Establishment and The Beneficiary’s Establishment in order to stop or reverse The Transaction by performing a series of manual processes with long waiting time for authorization form to be filled by The Transaction’s Beneficiary and The Beneficiary’s Establishment. Besides, it can pose personal and national security issue by funding a criminal, a terrorist, or similar flagged profiles accidentally; in which, The Transaction’s Maker will end up being questioned for one of a time random mistake exhausting both The Transaction’s Maker and the relevant authorities time and efforts. According to study published in Journal of Occupational Health Psychology, a person can make up to Six (6) Errors per hour which makes up to Forty Eight (48) mistakes in a day. Therefore, Worldwide, an Eight (8) Billion People makes nearly -384 Billion Human Errors a day making the chance of having an accidental transaction in a day is highly possible. As a matter of fact, myself (the Author of The Invention) had accidentally sent nearly 20k USD to the wrong person in a single transaction whereby the process of reversing the mistake took roughly Two (2) weeks. Luckily The accidental Transaction went to a trustworthy party that accepted to reverse The Transaction otherwise I (the Author of The Invention) might needed to take a legal action which could have cost months worth of time as legal system and bodies requires time for the investigation, then the permission, then the action. (4) Officers are subject to Misuse or Abuse available Identity Documents: in the real world we live in, someone can abuse someone’s else by using their identity to make transactions with criminals, terrorists, other kind of flagged profiles, or even to just an ordinary profile. Today, just by having a copy of the victim’s passport, national ID, or other acceptable identity documents a criminal can perform transaction over the counter. For example, a criminal can bribe an employee over the counter at one of the agencies to get the employee to make a transaction using someone else’s name. In such a case, the identity holder will be questionable for something they will never know it happened while the criminal will be free, unknown, and fully anonymous. In such a case, is extremely hard (nearly impossible) to be proven to be fraudulent for many reasons most importantly the person wouldn’t have any proof of innocence. Even if the victim proven innocent, just by having the victim questionable for something they never did it makes it concerning financially. As well as it distracts the relevant authorities and waste their time, and it allows time gap for the real criminal to flee. (5) The possibility of Brand New Cyber-Attack to hurt The Beneficiary’s Profile: in this era, a person can cause a damage to someone else by paying a criminal on the dark web to get them to make a transaction to the victim’s bank account (or eWallet or any other form of financial means) in order to flag the account by the financial systems, auditors, and authorities. Receiving a transaction from a criminal, a flagged profiles, a monitored profile, or other kind of profiles with negative reputations can make The Beneficiary questionable for The Transaction they have received. According to the World Economic Forum, there are about One (1) Million cyberattacks a year that makes nearly 10 Trillion USD of damage in a year. Given such mass existing damages there could or would be some of these cases performed by sending a malicious transaction to someone via flagged account to get the victim flagged as well. (6) Involvement in Money Laundering Activities: a person or a group of people are able with existing systems and solutions to send small amount of money over the counter using stolen IDs given some help from the officer over the counter. These people can wash their money by sending a small amount of money using stolen IDs over the counter making themselves as beneficiaries and claiming these transactions as sales. This strategy will sure make the money look as a legal revenue from people with clean IDs specially that it is small amount of money so mostly it will not be flagged. Even if this gets detected, it will take months worth of time to be detected; in which, it will goes through a long investigation process which takes months. By that time, the criminal can hide or flee while ID holders will be the one facing at minimum some financial and legal inconveniences till the time they proven innocents. However as a matter of fact, claiming those small numbers as sales with from various people makes it nearly impossible for money laundering detection. (7) Chances of System Malfunction or Abuse of Transaction: recently, we have been seeing more errors than ever publicly and well known. We all have seen the entire world systems stopped due to Windows update that had a world-wide effect and we don’t know internally what happened to the systems running on windows as it is a business secrete. We don’t know if user data was effected and if there any abuse happened during those crash hours. Therefore, a bank system or any another system is subject to errors that could potentially introduce an unwanted and unrequested transaction. 3. Description of the Related Art (8) Some apps online utilizes KYC tools with its various providers that verifies the entered and uploaded identity by the end user. In which, it makes sure the end user of the edge system such as mobile app or web-app is legit and matches with the ID entered, uploaded, and verified. However, this solution is not available for transactions done over the counter operations. Additionally, there is no way in any of the current systems to use it to allow The Beneficiary to Accept or Reject a transaction. (9) There are several ways of performing 2FA (Two Factor Authentication) such as OTP, PIN, FacelD, TouchlD, Fingerprint, and more. The 2FA can only be reliable if and only if the KYC process has been completed and user is verified. This method provides a second layer of protection on a system preventing misuse online only with a critical weakness which is the solution it is not available for transactions done over the counter operations. Additionally, there is no way in any of the current systems to use it to allow The Beneficiary to Accept or Reject a transaction. (10) Proof of ID for Over The Counter Transactions with Reference Number (Optionally) Over the counter. The employee at The Maker’s Establishment checks The Maker’s Identity by asking for the relevant ID as per local requirements and the same process happens with the The Beneficiary at the The Beneficiary’s Establishment additionally The Transaction’s reference number might be required. This helps to identify the sender and the receiver in respect to the officer on the counter only whereby the officer is being trusted on the honesty and accuracy of the information. However, the officer over the counter is subject to have a conflict with The Maker and subject to abuse The Maker’s Identity. Also, the officer is could be involved with criminals to perform money laundering activities by using available identities from previous transactions in favor of benefiting from the money laundering activities. Summary of the Invention 1. General Overview (11) This Invention is about The System is called Consensual Interactive Transactions (CIT); in which, The System provides a protective layer on transactions by requiring banks, agencies, and other form of establishments to request for digital consents from The Makers on-time before processing The Transactions and to request for digital consents from The Beneficiaries on-time before crediting (or handing-over) any of The Transactions by utilizing The System through performing the following actions: • Intent to initiate a Transaction by The Maker’s Establishment. • Intent to consent to the initiated Transaction by The Maker. • Consent (utilize the intent) to the initiation by The Maker. • Confirm initiate and continue already existing processes to facilitate the transaction. • Intent to Credit / Handover The Transaction (aka Ready Intent) to The Beneficiary’s Establishment. • Consent to intent of Credit (handover) of a ready transaction by The Beneficiary. • Confirm (utilize the intent) to Credit / Handover and continue existing processes to facilitate the transaction. Notes: • The Maker has the abilities to cancel a transaction anytime before Accept, Reject, or Timeout is utilized. • The Beneficiary cannot accept a transaction without the confirmation code. • The Transaction will automatically expire after 30 days if Cancel, Accept, or Reject hasn’t been utilized. (12) The System is designed to ensure that all relevant Transactions are consented with The Respective Identity Holder to prevent anybody else from using any ID to make a transaction without a consent. Besides, it grants the power to The Maker by controlling who gets The Confirmation Code and by the ability to cancel The Transaction at anytime as long as it hasn’t been Accepted by The Beneficiary yet. Furthermore, The System defines The Beneficiary liabilities based on their actions such as Accepting or Rejecting Transactions. While the only way they can Accept The Transaction successfully is by entering The Confirmation Code that was shared to them via The Maker. The Confirmation Code play a significant role in defining the relationship between The Maker and The Beneficiary together with the OTP that confirms the true ID of each makes the relationship and accountability well defined on each party. Besides, The Confirmation Code will ensure to prevent an accidental transaction as The Beneficiary cannot accept the transaction without a valid Confirmation Code. Additionally, The System grants authorities legal grounds by defining connections and liabilities for each The Maker and The Beneficiary in case of any legal violation. The System helps Banks, Financial Institutes, agencies, and others form of establishments with piece of mind from handling cancellations and reversal requests manually. (13) This software is innovative because it defines connections and liabilities between the The Maker and The Beneficiary over a Transaction by introducing Digital Consent with the assistance of a Confirmation Code. It holds The Beneficiary liable to The Transactions they accept and protects people from having their ID abused by officers (and random people including hackers) over the counter without a valid consent which makes it a great solution to prevent impostors. It also can be used as a replacement for the excessive trust given to the officer over the counter and prevents mistakes eventually these officers are human and subject to at least mistakes (as well as violations). 2. Key Features (14) Currently there is no software or solution on earth requires The Beneficiary to provide a consent of Acceptance or Rejection a transaction before crediting (or hand-over) it into banking, cards, and similar domains. This is solved by The System by requiring The Beneficiary to consent to the transaction by Accepting it (to be credited) or rejecting it if it is unknown to them. Currently, there is no way to ensuring that The Maker over the counter is the same as The Identity Holder other than via the TRUST in the officer over the counter. This is solved by The System by requiring the establishments that uses Over the Counter Solutions to collect consent via The System before processing The Transaction. Currently there is no Straightforward way to prove The Beneficiary’s Liability over a Transaction because if they never consented to it (unless supported by other documents and evidences). This is solved by The System by requiring a Digital Consent to accepting The Transaction which will hold The Beneficiary liable for accepting transactions from flagged profiles. Currently there is no software or solution on earth protects The Beneficiary from an unwanted or an undesired incoming transactions into their bank accounts, cards, and similar domains. This is solved by The System by requiring The Beneficiary to consent to accepting The Transaction before it is credited (or handed-over). (15) The System acts as a man in the middle that only collect consents and information from The Makers and The Beneficiaries as well as handles the real status of The Transaction in accordance to the actions of The Makers and The Beneficiaries. It is the first of its kind to be able to play the Role of the Judge for The Transactions and its Disputes which eliminate risks on all parties. While, The System can never cause or pose any security issue or concern as it unable to initiate any transaction. Besides, The System cannot credit any transactions because the process has to be invoked (requested) from the providers side such as banks and other establishments. Therefore, The System can only collect consents and share it with the relevant parties such as Makers, Beneficiaries, and establishments. With these features, The System is a state of art as it protects The Makers and The Beneficiaries from any unauthorized actions regardless of its cause. The System introduces a deadlock by having every intent relying on the other and every action rely on the other making it unbreakable. 2. Advantages (16) Top Advantages to Governments and Legal Bodies • The System holds The Maker liable to what they send by collecting their consent. • The System holds The Maker liable to what they send by granting the ability to systematic cancellation. • The System holds The Maker liable to what they send by controlling and sharing the Confirmation Code. • The System holds The Beneficiary liable to what they get by collecting consent of acceptance. • The System holds The Beneficiary liable to what they get by granting the power of rejecting. • The System holds The Beneficiary liable to what they get by entering the Confirmation Code. • The System defines the relationship between The Maker and The Beneficiary via the Confirmation Code. • The System prevents people of being involved in money laundering activities. • The System protects the financial system from officers abusing their trust. (17) Top Advantages to Banks • The System saves the time and money for banks on taking cancelation forms. • The System eliminate the hectic process of cancelling a transaction. • The System cut costs for banks while performing reversals on incorrect transactions. • The System protects banks from their employees whom can breach the trust. (18) Top Advantages to Exchange and Financial Agencies • The System ensures that their officers wouldn’t be able to be involved in illegal activities. • The System supports agencies to keep customers’ identify safe from misuse. • The System saves the time and money of the agencies while performing cancellation operation manually. • The System provides liability assurance of The Beneficiary once credited (handed-over). (19) Top Advantages to Makers • The System protects The Maker’s Identity from abuse and misuse. • The System prevents putting the innocent people in questionable to Transactions they didn’t make. • The System gives the power to The Makers over their own transactions. • The System holds The Beneficiary liable in front of The Maker once The Transaction Accepted including its description. • The System helps turning The Transaction’s description from being just a statement to being an agreement via both parties consent. (20) Top Advantages to Receiver • The System protects The Beneficiary’s Identity from abuse and misuse. • The System prevents putting the innocent people in questionable to Transactions they didn’t accept. • The System helps turning The Transaction’s description from being just a statement to being an agreement via both parties consent. (21) In which, The System acts as if it was a man in the middle that just collects consents and information from multiple parties it helps to play The Judge Role in Transactions and Disputes reducing risks of fraudulent transactions and fraudulent disputes as well as protecting all parties with fair and clear process. At the same time, The System doesn’t pose any risk to any party because the initiation and readiness happens through the financial establishments. The System protects Makers and Beneficiaries from having the financial establishments acting on their behalf (maybe via errors). The System is a piece of art due to the deadlock process; whereby, each party depends on the other and each action depends on the other making it impossible to crack its features and benefits. Brief Description of the Drawings 1. Figure Descriptions •FIG. 1, On Transaction Initiate: The drawing illustrates the process of initiating a transaction; whereby, The Maker has to use The Establishment’s app (or tool) of transacting to initiate the process. In which, The Establishment has to communicate with The System to request for a consent on the initiation process. Which will results into One-Time Authorization request will be sent via any of the providers (such as SMS OTP) to the preferable method for The Maker. The System will be able to know The Maker via their Identity Document number (such as passport number or national ID number) which is included in the request from The Establishment to ensure accuracy on who is making the consent. • FIG. 2, Collect Consent to Initiate Transaction (via The System Directly): The drawing illustrates the process of collecting the consent from The Maker to approve initiating a transaction; whereby, The Maker has to enter the One-Time Authentication Code (resulted from FIG. 1) onto The System Directly to authorize the request and to allow The Establishment to continue with The Transaction. In which, The Establishment will receive a Generated Authorization Code from The System to be used to utilize the initiate intent. Once, intent has been successfully utilized, The Establishment (or entity) is allowed with consent to progress on completing The Transaction. • FIG. 3, Collect Consent to Initiate Transaction (via The Establishment): The drawing illustrates the process of collecting the consent from The Maker to approve initiating a transaction; whereby, The Maker has to enter the One-Time Authentication Code (resulted from FIG. 1) via The Establishment by giving them the One-Time Authorization to authorize the request by having The Establishment to pass the request to The System on their behalf in order to continue with The Transaction. In which, The Establishment will receive a Generated Authorization Code from The System to be used to utilize the initiate intent. Once, intent has been successfully utilized, The Establishment (or entity) is allowed with the consent to progress on completing The Transaction. This approach is useful in poor network areas and for tourists without internet plans whereby they lack access to The System. • FIG. 4, Confirm Ready Transaction for Collection (via The System Directly): The drawing illustrates the process of accepting a ready transaction; whereby, The Beneficiary has to enter the Confirmation Code (resulted from the FIG. 2 and FIG. 3) onto The System Directly to confirm the right to The Transaction and to generate a One-Time Authorization on their preferred communication method. Which will results into One-Time Authorization request will be sent via any of the providers (such as SMS OTP) to the preferable method for The Beneficiary. The System will be able to know The Beneficiary via their Identity Document number (such as passport number or national ID number) which is included in the request from The Establishment to ensure accuracy on who is making the consent. • FIG. 5, Confirm Ready Transaction for Collection (via The Establishment): The drawing illustrates the process of attempting to accept a ready transaction; whereby, The Beneficiary has to use The Establishment’s app (or tool) of transacting to confirm the right to The Transaction by sharing (or entering) the Confirmation Code (resulted from the FIG. 2 and FIG. 3) that had been gotten from The Maker. In which, The Establishment will communicate with The System to request for a consent on the crediting process to generate a One-Time Authorization on their preferred communication method. Which will results into One-Time Authorization request will be sent via any of the providers (such as SMS OTP) to the preferable method for The Beneficiary. The System will be able to know The Beneficiary via their Identity Document number (such as passport number or national ID number) which is included in the request from The Establishment to ensure accuracy on who is making the consent. • FIG. 6, Collect Consent to Accept Transaction (via The System Directly): The drawing illustrates the process of collecting the consent from The Beneficiary to credit a transaction; whereby, The Beneficiary has to enter the One-Time Authentication Code (resulted from the FIG. 4 and FIG. 5) on The System Directly to authorize the request and to allow The Establishment to continue with The Transaction. In which, The Establishment will receive a Generated Authorization Code from The System to be used to utilize the acceptance intent. Once, intent has been successfully utilized, The Establishment (or entity) is allowed with consent to progress on completing The Transaction. • FIG. 7, Collect Consent to Accept Transaction (via The Establishment): The drawing illustrates the process of collecting the consent from The Beneficiary to credit a transaction; whereby, The Beneficiary has to enter the One-Time Authentication Code (resulted from the FIG. 4 and FIG. 5) via The Establishment by giving them the One-Time Authorization to authorize the request and to allow The Establishment to pass it to The System on their behalf in order to continue with The Transaction. In which, The Establishment will receive a Generated Authorization Code from The System to be used to utilize the acceptance intent. Once, intent has been successfully utilized, The Establishment (or entity) is allowed with consent to progress on completing The Transaction. This approach is useful in poor network areas and for tourists without internet plans whereby they lack access to The System. 2. Overview of Drawings (22) The attached figures illustrates the key processes but not all of them. There are other possibilities such as cancelling intent and timeout that has not been illustrated besides many other processes that deemed secondary to these Seven 7 figures. Detailed Description of the Invention 1. Overview (23) This invention relates to a consensual interactive transactions system that has been designed to securely verify The Transaction’s Maker by collecting consent from The Respective Verified Identity Holder when making a transaction to ensure that The Transaction is initiated with consent and The Maker is the same as The Identity Holder as well as it has been designed to securely verify The Beneficiary by collecting consent from The Respective Verified Identity Holder before crediting (handing-over) a transaction to ensure that The Transaction is accepted with consent and The Beneficiary is the same as The Identity Holder. The main components include Web Admin Interface, Web Establishments Interface, Mobile User Interface, API and Database (per geo-restriction), Bridges to Providers such as SMS Provider. (24) The System requires The Maker’s Establishment to declare The Transaction’s Initiation on-time; in which, The Transaction’s Initiation cannot be completed without a valid consent by The Transaction’s Maker. Besides, The System requires The Beneficiary’s Establishment to declare The Transaction’s Readiness to be credited (or handed-over) on-time; in which, The Transaction cannot be credited (or handed-over) without a valid consent by The Transaction’s Beneficiary. (25) In which, The System requires The Transaction’s Maker to consent to initiating The Transaction (if they wish to proceed with it) by entering the OTP (or OTP alternatives) shared with The Transaction’s Maker through their preferred channel of authorization ensuring that only authorized user can consent on making The Transaction. Upon a successful initiation consent, The System will share a securely generated Confirmation Code with The Transaction’s Maker. This Confirmation Code is required to be entered by The Transaction’s Beneficiary together with the OTP (or OTP alternatives) shared with The Transaction’s Beneficiary through their preferred channel of authorization ensuring that only authorized user can consent to Accepting or Rejecting The Transaction. (26) In overall, The software consists of up to Seven (7) Actions in respect of a single Transaction; in which, up to Five (5) Actors are taking these actions as defined below: Initiate: made by The Maker’s Establishment but limited by the Consent. Consent: made by The Maker only if Initiate has been called. Ready: made by The Beneficiary’s Establishment but limited by the Accept or Reject. Cancel: made by The Maker only if Accept, Reject, and Timeout has not been called yet. Accept: made by The Beneficiary if Ready has been called but not Cancel, Reject or Timeout. Reject: made by The Beneficiary if Ready has been called but not Cancel, Accept or Timeout. Timeout: made by The System if Cancel, Accept or Reject has not been called yet. (27) Each of these Actions (excluding the Timeout) consists of Three (3) steps that are Intent, Utilize Intent, and Cancel Intent. The Three (3) steps help to insure that only One (1) Action can be performed at a time on first come first serve bases. Whereby, intent has to be utilized or cancelled in order to allow a new intent to be created. In case an intent is not been utilized or cancelled by the relevant actor within Ten (10) minutes, then the intent will be automatically cancelled by The System to allow other intents to be created. 2. Functionality: (28) Actions Order Definition and Rules as Defined in The System • An Intent is only considered to be an Intent that has been created but not utilized, cancelled, or terminated. • An Action is only considered to be an Action if it is a Utilized Intent. • There can be single Intent at a time with respect to a transaction. • An Intent can be automatically terminated if not utilized within maximum transaction’s lifespan. • Once the maximum transaction’s lifespan without successful transaction completion, then the entire process will be terminated and no more intent or actions can be made. • The first intent can only be Initiate Intent. • The second intent can only be the Consent Intent. • The Initiate Intent can be utilized after utilizing Consent Intent. • If the Initiate Intent is utilized, then the Ready Intent can be created. • If the Ready Intent is created, then the Ready Intent can be utilized. • If the Ready Intent is utilized, then the Accept or Reject Intent can be created. • If the Accept or Reject Intent is created, then the Accept or Reject Intent can be utilized. • If the Accept or Reject Intent is utilized, then the Cancel Intent cannot be created. • If the Cancel Intent is Created, then the Intents of either Ready, Accept, and Reject cannot be created. • If the Cancel Intent is Created, then the Created Intents of either Ready, Accept, and Reject will be terminated. • If the Cancellation is Utilized, then the Intents of either Ready, Accept, and Reject cannot be created. • If the Cancellation is Utilized, then the Created Intents of either Ready, Accept, and Reject will be terminated. • If the Transaction’s lifespan is over before utilizing Accept or Reject Intent, then the process will be terminated. • If process terminated, then the Intents of either Cancel, Ready, Accept, and Reject cannot be created. • If process terminated, then the Created Intents of either Cancel, Ready, Accept, and Reject will be terminated. (29) Intent Request: the purpose of the Intent request (Initiate, Consent, Cancel, Ready, Accept, Reject) is to ensure the following: • There is no 2 intents or actions is in place being processed or completed. • The requested intent is fulfills the Actions Order Definition within The System. • The requestor is entitled for the requested intent. • The System to block a timeframe to allow utilizing the intent and prevent other intents from taking place. • On success, failure, and timeout, the blocked timeframe will be released for new intents. (30) Utilization Request: the purpose of the Utilization request (Initiate, Consent, Cancel, Ready, Accept, Reject) is to ensure the following: • The intent’s blocked timeframe hasn’t been cancelled, expired or terminated. • Verify the security information required such as OTP, confirmation code, and others. 3. The System Dependancies and 3rd Party Solutions (31) The System primarily uses Twilio and SendGrid for sending OTPs and Confirmation Code over the mobile numbers as well as email addresses of The Makers and The Beneficiaries. However, this configuration can be changed or customized per establishment to ensure international compatibility and to allow other service providers to be in use per government, bank, financial institute, agency, and others form of establishments. (32) The System primarily uses KYC service providers (vary per country) to identify The Makers as well as The Beneficiaries; in which, when The Transaction is Initiated (on Initiate Intent) from any establishment The Maker will be notified and required to consent to The Transaction’s Initiation Process (if they are the one who initiated the process). While on The Transaction is Ready (on Ready Intent Utilized), The Beneficiary will be notified and required to consent to Accepting (if they are related to the transaction) or Reject it. (33) The System depends on the banks, financial institutes, agencies, and other form of establishments to declare Initiation &Readiness in real-time; while, these establishments must adhere to the instructions signals incoming from the software such as Timeout, Consent, Cancel, Accept, and Reject. 4. Conclusion: (34) The System is innovative and state of art as it introduces The Digital Consent collection on the initiation of The Transaction to be processed as well as on the readiness of The Transaction to be credited (or handed-over). It brings a protection mechanism to Identity Documents from being abused and misused. It brings confidence as it relies on consents instead of blind trust in officers. The System defines the liability and the connection between of all involved parties in a transaction through The Consent and Confirmation Code. It prevents any accidental transactions and mistakes by introducing a Confirmation Code that needs to be shared between The Makers and The Beneficiaries in order to credit (hand-over) The Transaction. The Confirmation Code doesn’t only protect The Makers but also defines The Relationship between The Makers and The Beneficiaries and show case the connections and liabilities. The System is one of the most valuable digital inventions that will protect people in this era with digital crime rates are uprising. (35) This is not an obvious solution because clearly banks, financial agencies, other establishments, and end users wants to have faster and smoother process for making transactions and benefiting from transactions rather than getting stuck at one additional step to complete the process. People usually share their QR code (account certificate and other things) of their eWallets or Accounts or other financial means fearlessly because human being haven’t yet reached to the stage whereby they are attacked by a malicious transaction quite often. With the uprising count of cyber-harassment and cyber-attacks I (the author) quite confident that one day we will hear about a criminal paid someone to make a transaction to a victim via a monitored or suspicious account. Besides, until today, there is no obvious way to verify that The Maker or The Beneficiary over the counter is the same as the identity holder making it possible to perform money laundering activities via illegal transactions by using other’s identity. I (the author) very confident that there are some criminals out there abusing other people’s identity by sending an unauthorized transactions over the counter. This abuse can be detected in future by reviewing transactions post this invention vs transactions pre this invention in terms of numbers, values, customers, and other statistics making this solution a state of art because some institutes / agencies will have a drop in transactions due to their inability to perform a transaction without the consent requirement. Furthermore, this system is a state of art because it defines each party’s liabilities via the digital consent and sequence of intents and actions. Additionally, this system is a state of art solution because it is the fastest way in today’s market to cancel a transaction (if not yet accepted or rejected); while, other existing solutions are mostly manual and slow.

Claims

1. Independent Claims(36) Independent Claim 1 (The Maker’s Consent on Transaction Initiation): The System to collect consent on Transactions from The Respective Identity Holder in order to process The Transaction. The Transaction Maker’s Establishment (such as bank, financial institute, transfer agency, transfer app, and any other entity that perform transactions) is required to intent to initiate a transaction in order to request for initiation’s consent collection. The Transaction’s Maker will be required to consent to The Transaction via their preferred method of One-Time Authorization (such as SMS OTP, Email Code, Hardware Token, Push Notification, and more) if and only if they acknowledge and accept The Transaction to be initiated.(37) Independent Claim 2 (The Beneficiary’s Consent on Transaction Acceptance): The System to collect consent on Transactions from The Respective Identity Holder in order to credit The Transaction. The Transaction Beneficiary’s Establishment (such as bank, financial institute, transfer agency, transfer app, and any other entity that perform transactions) is required to declare the readiness of a transaction to be credited (handed-over) in order to request for acceptance’s consent collection. The Transaction’s Beneficiary will be required to consent to The Transaction via their preferred method of One-Time Authorization (such as SMS OTP, Email Code, Hardware Token, Push Notification, and more) together with the Confirmation Code shared via The Maker if and only if they acknowledge and accept The Transaction to be credited.

2. Dependent Claims:(38) Dependent Claim 3 (Dependent on Claim 1 &Claim 2): Both Claim 1 and Claim 2 requires The Makers and The Beneficiaries to verify themselves via The System in order to be able to give and track consents on any Transaction associated with their identity. This requires each to go through a KYC process with third party verification methods together with 2FA to protect their data.(39) Dependent Claim 4 (Dependent on Claim 1 &Claim 2): Both Claim 1 and Claim 2 requires Establishments (or entities or governments) to sign up to gain an access to TheSystem with respect to their own scope of transactions. Whereby, Establishments are expected to intent to initiate and intent to ready (when applicable) in order to collect consent.(40) Dependent Claim 5 (Dependent on Claim 1 &Claim 2): Both Claim 1 and Claim 2 requires Establishments (or entities or governments) to adhere to results coming from The System with respect to their own scope of transactions such as Cancel, Reject, Timeout. Whereby, if The Transaction’s Status has been flagged as cancelled, rejected, or timeout The Establishment shall be able to reverse the process immediately."Amendments to the claims have been filed as follow."13 03 25Claims1. Independent Claims(36) Independent Claim 1 (The Maker’s Consent on Transaction Initiation): The System to collect consent on Transactions from The Respective Identity Holder in order to process The Transaction. The Transaction Maker’s Establishment (such as bank, financial institute, transfer agency, cryptocurrencies, eWallets, transfer app, and any other entity that perform transactions) is required to intent to initiate a transaction in order to request for initiation’s consent collection. The Transaction’s Maker will be required to consent to The Transaction via their preferred method of One-Time Authorization (such as SMS OTP, Email Code, Hardware Token, Push Notification, and more) if and only if they acknowledge and accept The Transaction to be initiated.(37) Independent Claim 2 (The Beneficiary’s Consent on Transaction Acceptance): The System to collect consent on Transactions from The Respective Identity Holder in order to credit The Transaction. The Transaction Beneficiary’s Establishment (such as bank, financial institute, transfer agency, cryptocurrencies, eWallets, transfer app, and any other entity that perform transactions) is required to declare the readiness of a transaction to be credited (handed-over) in order to request for acceptance’s consent collection. The Transaction’s Beneficiary will be required to consent to The Transaction via their preferred method of OneTime Authorization (such as SMS OTP, Email Code, Hardware Token, Push Notification, and more) together with the Confirmation Code shared via The Maker if and only if they acknowledge and accept The Transaction to be credited.

2. Dependent Claims:(38) Dependent Claim 3 (Dependent on Claim 1 &Claim 2): Both Claim 1 and Claim 2 requires The Makers and The Beneficiaries to verify themselves via The System in order to be able to give and track consents on any Transaction associated with their identity. This requires each to go through a KYC process with third party verification methods together with 2FA to protect their data.(39) Dependent Claim 4 (Dependent on Claim 1 &Claim 2): Both Claim 1 and Claim 2 requires Establishments (or entities or governments) to sign up to gain an access to TheSystem with respect to their own scope of transactions. Whereby, Establishments are expected to intent to initiate and intent to ready (when applicable) in order to collect consent.(40) Dependent Claim 5 (Dependent on Claim 1 &Claim 2): Both Claim 1 and Claim 2 requires Establishments (or entities or governments) to adhere to results coming from The System with respect to their own scope of transactions such as Cancel, Reject, Timeout. Whereby, if The Transaction’s Status has been flagged as cancelled, rejected, or timeout The Establishment shall be able to reverse the process immediately.13 03 25s

Images