WO2017070469A1 - Système et procédé de traitement de paiement au moyen de devises cryptographiques - Google Patents

Système et procédé de traitement de paiement au moyen de devises cryptographiques Download PDF

Info

Publication number
WO2017070469A1
WO2017070469A1 PCT/US2016/058116 US2016058116W WO2017070469A1 WO 2017070469 A1 WO2017070469 A1 WO 2017070469A1 US 2016058116 W US2016058116 W US 2016058116W WO 2017070469 A1 WO2017070469 A1 WO 2017070469A1
Authority
WO
WIPO (PCT)
Prior art keywords
currency
fiat
payee
payer
payment processor
Prior art date
Application number
PCT/US2016/058116
Other languages
English (en)
Inventor
Marwan Forzley
Aldo Mario Eduardo S. CARRASCOSO
Original Assignee
Align Commerce Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US14/919,909 external-priority patent/US20170116608A1/en
Priority claimed from US14/942,216 external-priority patent/US20170140371A1/en
Priority claimed from US15/040,498 external-priority patent/US20170228727A1/en
Application filed by Align Commerce Corporation filed Critical Align Commerce Corporation
Publication of WO2017070469A1 publication Critical patent/WO2017070469A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/12—Payment architectures specially adapted for electronic shopping systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/381—Currency conversion
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4016—Transaction verification involving fraud or risk level assessment in transaction processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/405—Establishing or using transaction specific rules
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/08—Auctions

Definitions

  • the present invention is related to the field of payment processing and currency exchange using cryptocurrencies.
  • Currencies may be transferred from a payer to a payee for various reasons.
  • a buyer may purchase goods or services from a merchant in person, via telephone or through an Internet web site.
  • a merchant or business may be paying a supplier, employees, sales people, consultants, or others. They may also be issuing refunds or rebates to customers or suppliers, or making payments as part of an affiliate program with another business or individual. Businesses may be paying salaries to employees or consultants on a reoccurring or one-time basis. There are a number of other situations where an individual will be simply transferring currencies to an associate or family member in another country. Payments may be small or large and completion of the payment may be required quickly or to be completed at a specific time, for example, at the end of the business day in a particular time zone. Payments may be made in the same or different currencies.
  • Currencies may be the fiat-currency of a country such as a US dollar, Euro, or Yen or may be a crypto-currency, of which bitcoin is one example. While fiat-currencies are usually exchanged at a bank or currency exchange using well established rules, crypto-currencies transactions are based on a blockchain, a digital ledger used to record transactions, and are exchanged through crypto-exchanges.
  • currency can be used generally to refer to both a fiat-currency and a crypto-currency.
  • the term exchange can be used generally to refer to both a bank or currency exchange for fiat-currencies, and to refer to a crypto-exchange that utilizes a blockchain or similar technology to record exchanges. Exchange rates apply to conversions between two fiat-currencies, two crypto-currencies, or between a fiat-currency and a crypto-currency.
  • the process can be described as a "rail."
  • the rail can be visualized as the path the transaction takes from sender to receiver.
  • a sender may deposit an amount of their local fiat-currency into their local bank account and initiate a transfer to a receiver in another country.
  • the deposited fiat-currency may be exchanged at the bank into an intermediate currency and then transferred to the receiver.
  • the route the transfer takes from bank to first exchange to second exchange is the rail that was utilized for the transaction.
  • a payment transaction can use multiple rails to transfer an amount of currency from the sender to the receiver.
  • Crypto-currencies have been developed that can be used to provide payment for goods and service and be used by both payers and payees and be used for both domestic and international transfers, payments and exchanges.
  • Crypto-currencies are a medium of exchange designed around securely exchanging information and value.
  • a crypto-currency can be centralized or decentralized.
  • Crypto-currencies may take the form of digital data but may also may be physically represented by cards or printed paper.
  • Public-private key pairs are used to ensure the security of crypto-currencies. Public and private key pairs together, separately and individually are used to sign transactions, crypto currencies or other related ecommerce transactions in order to unlock value or show ownership of a particular crypto currency, transaction or combination thereof.
  • Keys may be simple or complex and the more complex the key and its associated management and application, the more secure the use of crypto-currencies. Addresses are used to refer to public keys, which must be combined with their private keys to access the crypto-currency. To access a crypto currency transaction containing a specific amount of crypto currency a single or combination of public-private key pairs is required.
  • Crypto-currency wallets are associated with addresses that act as a locator to the wallet to allow depositing and withdrawing from the wallet. Private keys are used to access the wallet addresses.
  • Private keys are used to sign a multi-signature address which then cause the payment to be released to the receiver or sent back to the sender.
  • multi-signature addressed are merely proxies to existing payment types such as cards, bank accounts, wallets, gift cards or other forms of payments.
  • Crypto-currencies have the characteristics of being stateless, with transactions done on the Internet and with exchanges located in many countries of the world. Due to their locations and various factors in their home countries such as government regulations, as well as competition between exchanges, each offers different services and charge different rates for those services which may be taken advantage of by new technology. Furthermore, since they are accessed over the Internet, a larger number of crypto-currency exchanges can now be used for as currency exchange rails.
  • a payment processor is a company that provides financial services that included the transfer of different currencies or same currencies from a sender to a receiver.
  • the payment processor must charge fees to remain profitable while still offering competitive rates. Due to the use of multiple rails, the task for a payment processor of choosing a rail for a currency transaction is no longer a simple task and requires new methods in order to do it in a timely and effective manner.
  • Some entities such as companies employing many independent contractors must pay their employees a relatively small amount monthly.
  • the employer often is assessed a per transaction fee for each payment and each independent contractor must often also pay a transaction fee to receive a payment. If the fee is based on the transaction rather than the amount transferred and the amount is small, the fees can amount to a significant portion of the total payment.
  • An extreme case is organizations who deal in micropayments that may be less than $1, $5, or $20 depending on the case. Even very small transaction fees may exceed the amount of the payment, making these types of business models unfeasible.
  • the time to make a payment can vary from being almost instantaneous to days, to months for some types of international transfers. Reporting and confirmation of payments can also be an issue with neither the payer nor the payee completely sure who sent a payment, what fees and exchange rates were charges, and if it was actually received. Should a payment be delayed or the received amount not match the expected amount, it can be difficult and time-consuming working with the banks and payment processors to determine what has happened.
  • Digital or crypto-currencies have been developed that can be used to provide payment for goods and service and be used by both payers and payees and be used for both domestic and international transfers. Crypto-currencies are a medium of exchange designed around securely exchanging information and value. A crypto-currency can be either centralized or decentralized. Crypto-currencies often require a digital wallet or exchange in order to make or receive payments, and exchanging fiat-currencies with crypto-currencies can be quite difficult.
  • a payment processor receives currency information and identification information.
  • the currency information comprising a payer fiat-currency and a payee fiat-currency, and identification information comprising information verifying the identify of a payer and a payee.
  • the payment processor utilizes the currency information and the identification information to determine a transaction restriction level.
  • the payment processor verifies that the identification information meets a threshold for the transaction restriction level.
  • the payment processor receives payment in the payer fiat-currency and initiates a transaction to convert the payer fiat-currency amount into a crypto-currency amount.
  • the payment processor converts the crypto-currency amount into the payee fiat-currency and initiates a transfer of the payee fiat-currency amount to the payee.
  • the payment processor determines criteria to be used to select the crypto-currency and selects the crypto-currency.
  • a payment processor receives currency information and identification information.
  • the currency information comprises a payer fiat- currency and a payee fiat-currency.
  • the identification information comprises information verifying the identify of a payer and a payee.
  • the payment processor utilizes the currency information and the identification information to determine a transaction restriction level. The payment processor verifies that the identification information does not meet a threshold for the transaction restriction level and augments the identification information to meet the threshold for the transaction restriction level.
  • the payment processor receives payment in the payer fiat-currency and initiates a transaction to convert the payer fiat-currency amount into a crypto-currency amount.
  • the payment processor converts the crypto-currency amount into the payee fiat-currency and initiates a transfer of the payee fiat-currency amount to the payee.
  • the payment processor may augment the identification information by verifying the identity of the payer or payee with a portion of information provided by the payer and a portion of information provided by the payee.
  • a further embodiment of the invention a payment processor receives currency information and identification information.
  • the currency information comprises a payer fiat- currency and a payee fiat-currency.
  • the identification information comprising information comprising a payer trusted level and a payee trusted level.
  • the payment processor utilizes the currency information and the identification information to determine a transaction restriction level.
  • the payment processor verifies that the payer trusted level and the payee trusted level meet a threshold for the transaction restriction level.
  • the payment processor receives payment in the payer fiat-currency and initiates a transaction to convert the payer fiat-currency amount into a crypto-currency amount.
  • the payment processor converts the crypto-currency amount into the payee fiat-currency and initiates a transfer of the payee fiat- currency amount to the payee.
  • a payment processor receives a first fiat-currency amount and information comprising a payee deposit destination.
  • the payment processor receives a first plurality of criteria and evaluates a first plurality of exchanges against the first plurality of criteria to select a first transaction exchange from the first plurality of exchanges to initiate a first conversion between a first fiat-currency amount and a cryptocurrency amount.
  • the payment processor receives a second plurality of criteria and evaluates a second plurality of exchanges against the second plurality of criteria.
  • the payment processor selects a second transaction exchange from the second plurality of exchanges to perform a second conversion between the crypto-currency amount and a second fiat-currency amount.
  • the payment processor initiates a transfer of said second fiat-currency amount to the payee deposit destination.
  • a payment processor receives a first fiat- currency amount and information comprising a payee deposit destination.
  • the payment processor receives a first plurality of criteria and assigns a least a first weighting to at least one of the first plurality of criteria and uses the first weighting to produce a first weighted criteria.
  • the payment processor evaluates a first plurality of exchanges against at least one of the first plurality of criteria and the first weighted criteria, and selects a first transaction exchange from the first plurality of exchanges to initiate a first conversion between a first fiat-currency amount and a crypto-currency amount.
  • the payment processor receives a second plurality of criteria, assigns at least a second weighting to at least one of the second plurality of criteria and uses the second weighting to produce a second weighted criteria.
  • the payment processor evaluates a second plurality of exchanges against at least one of the second plurality of criteria and the second weighted criteria, and selects a second transaction exchange from the second plurality of exchanges to initiate a second conversion between the crypto-currency amount and a second fiat- currency amount.
  • the payment processor initiates a transfer of the second fiat-currency amount to the payee deposit destination.
  • a process for generating a multi- signature address comprises defining an address associated with said multi-signature address and generating a plurality of keys and associating them with the address.
  • one or more rules is defined that when triggered enable each of their corresponding plurality of keys to be signed.
  • Each of the one or more rules is a logical combination of one or more conditions, where each condition has one or more attributes that when true allow each of the conditions to be true.
  • the number of keys that must be signed in order to unlock the address is also defined.
  • One or more exit rules may be defined associated with each address where if not all of the plurality of keys have been signed before the exit rule is triggered then all of the plurality of keys are reset to an unsigned state cancelling the transaction.
  • a multi- signature address is received and a plurality of keys is determined from the address.
  • the number of the plurality of keys that must be signed in order to unlock said address is also determined.
  • At least one rule associated with at least two of the plurality of keys is determined.
  • One of said at least two of the plurality of keys is signed after waiting until the at least one condition occurs.
  • At least one condition having one or more attributes that when true allow said at least one condition to be true.
  • the address is unlocked when the required number of the plurality of keys are signed.
  • a multi-signature address has an address associated with it and a plurality of keys are associated with the address.
  • For each of the plurality of keys there are one or more rules that when triggered enable each of their corresponding plurality of keys to be signed.
  • Each of the one or more rules is a logical combination of one or more conditions and each of the one or more conditions have one or more attributes that when true allow each of said conditions to be true.
  • One or more exit rules may be associated with the address wherein if not all of the plurality of keys have been signed before the exit rule is triggered then all of the plurality of keys are reset to an unsigned state.
  • Yet another embodiment of the invention involves a method for implementing a policy for financial transactions involving a merchant, a consumer, and a payment processor.
  • a plurality of multi-signature addresses are defined and addresses associated with each of said plurality of multi-signature addresses are defined.
  • a plurality of keys are associated with each of said address.
  • one or more rules are defined that when triggered enable each of the corresponding plurality of keys to be signed.
  • Thed one or more rules are a logical combination of one or more conditions, where the one or more conditions each have one or more attributes that when true allow each of the conditions to be true.
  • the financial transactions may utilize crypto-currencies.
  • the number of keys that must be signed to unlock the addresses, the rules, the conditions, and the attributes may be defined by the consumer, the merchant, or the payment processor.
  • Payment processing policies for implementing using multi-signature addresses includes defining an address associated with the multi-signature addresses and generating a plurality of keys and associating them with each of the addresses. For each of the plurality of keys one or more rules is defined that when triggered enable each of their corresponding plurality of keys to be signed. Each rule is a logical combination of one or more conditions and each of the one or more conditions has one or more attributes that when true allow each of the conditions to be true. A number of keys must be signed in order to unlock each address.
  • One or more exit rules may be defined associated with each address where if not all of the plurality of keys have been signed before the exit rule is triggered then all of the plurality of keys are reset to an unsigned state cancelling the transaction.
  • FIG. 1 shows an overview of a financial transaction using an embodiment of the invention.
  • FIG. 2 shows an overview of a payer or payee being verified by the system
  • FIG. 3 shows an overview of an embodiment of a level 1 verification.
  • FIG. 4 shows an overview of an embodiment of a level 2 verification.
  • FIG. 5 shows an overview of an embodiment of a level 3 verification.
  • FIG. 6 shows a detailed embodiment of paying an invoice and sending an invoice.
  • FIG. 7 shows an overview of a transaction being made where exchanges are chosen using criteria.
  • FIG. 8 shows an overview of a transaction being made where exchanges are chosen using criteria and where payments may be made in the presence of reserves.
  • FIG. 9 shows an overview of choosing the best rail to make a conversion and transfer.
  • FIG. 10 illustrates the process of converting different amounts of currency in different countries.
  • FIG. 11 illustrated the network used to initiated and make a fiat-currency transfer using a crypto-currency rail.
  • FIG. 12 shows the hierarchy of policies, multi-signature addresses, keys, rules, conditions, and attributes.
  • FIG. 13 shows examples of rules, conditions, and attributes
  • Embodiments of the invention relate to trusted currency transactions involving two parties who are customers of a payment processor.
  • at least one party will be a business.
  • the other party may be a business or an individual.
  • One party of the transaction is the payer, who is making a payment.
  • the other party is the payee, who is receiving a payment.
  • Transactions require both a payer and a payee.
  • Transactions using embodiments of this invention may be initiated by either the payer or the payee.
  • the payer may receive a request for payment and then respond by paying the specified amount or the payer can initiate a transaction to send or pay money to a payee.
  • the payee may receive money from a payer or may initiate a transaction to request or demand payment from the payee.
  • the payer 100 may a shopper paying a merchant or a business paying a supplier. Often the payee 101 will be a supplier receiving a payment, an employee, or a consultant.
  • a shopper may initiate a transaction by indicating a desire to purchase a good through a variety of means such as a website, over the telephone, or through an e-mail or traditional, hard copy mail.
  • a payer 100 such as an employer may initiate a single or multiple payments on a one-time or reoccurring basis in order to pay the salary of an employee or contractor. Payments to suppliers may also be on a one-time or reoccurring basis.
  • a payee 101 such as a company selling goods may initiate an invoice transaction to demand payment for goods sold and delivered to the payer which may be an individual, another company, or another organization.
  • the payment processor 102 acts as a coordinator for the transaction.
  • the payment processor 102 is an entity, likely a company or organization, that is providing a service for facilitating the financial transaction between the payer 100 and payee 101.
  • the payment processor 102 may be independent of the payer and payee, providing the service through a website, telephone, or in person.
  • the payment processor 102 may also be the same entity as the payer 100 or payee 101, facilitating the financial transaction as well as sending or receiving currencies.
  • the payer and payee register with the payment processor to participate in financial transactions.
  • the payment processor 102 coordinates with crypto-currency exchanges 103 to convert between fiat-currencies and crypto-currencies 107, and between different crypto-currencies.
  • Banking institutions 104 may be used to accept payments from a payer in a fiat-currency of their choice 106 and to remit payments to a payee in the fiat-currency of their choice 108.
  • the transaction may not involve any good or service but may be a financial transfer to send funds from a payer 100 to a payee 101.
  • the payer and payee may be in the same or different countries.
  • the payer and the payee may use the same or different fiat-currencies, or may use one of a variety of crypto-currencies 107.
  • transactions conducted using embodiments of the invention may involve the identities of one or both parties verified in compliance with Anti-Money Laundering (AML) policies and Know-Your-Customer (KYC) requirements or similar requirements in the jurisdiction of the payer or the payee or both jurisdictions. Transactions may also be compliant with similar international regulations.
  • the payment processor classifies payees and payers as new, or naked customers 201, unprofiled customers 202, transacting customers 203, or authenticated members 204.
  • a naked customer 201 is a payee or payer that has registered with the payment processor to make or receive a payment.
  • the naked customers 201 have supplied only minimal, unverified information to identify themselves such as an e-mail address, name, telephone number, or other information or combination of information to allow the payment processor to contact them.
  • the registration will be done on the payment processor's website involving a user name and password for authentication, though this could also be done via e-mail, telephone or other means. It may also be done on a third party website that the payment processor has access to, such as a bank, financial institution, credit card company, or the payee's or payer's website.
  • the payment processor may provide APIs (application program interface) to enable these third parties to securely interface with the payment processor.
  • the process of registering as a naked customer 201 creates an account with the payment processor changing their classification to being an unprofiled customer 202.
  • An unprofiled customer 202 is then prompted to enter additional identification, business, and banking information to enable the payment processor and banking institutions to access their financial accounts to withdraw or deposit money.
  • This information may include their country of residence, bank account and routing information, crypto-currency wallet address, credit or debit card information, email address, home or business address, telephone number and other information as required to make a financial transaction.
  • the customer becomes a transacting customer 203 and may send or receive fiat-currency or crypto-currency transactions. Since the identity of the transacting customer 203 has not yet been verified, there may be limitations on the transaction they are permitted to do.
  • a transacting customer 203 may be limited to transactions below $2,000 for each transaction and no more than $10,000 within a month.
  • the payment processor will be required to verify the identity of the payer or payee. For some transactions, especially for large amounts of money, both may have to be verified. Verification can be done in different levels depending on the amount of money involved or other criteria as set out in the regulations. For small amounts it may be sufficient to do a level 1 301 verification that verifies data such as the location of the IP address, address of the business, location of the phone number, business industry databases, OF AC (Office of Foreign Assets Control), and similar checks.
  • level 2 401 verification can be done. This may include review of government issued photo ID, proof of address, articles of incorporation, a review of SEC filings for public companies, and similar documents required for regulatory compliance.
  • a level 3 501 verification may be required, for example greater than $10,000, credit references, bank statements, and even onsite visits by the payment processor or their agents may be required. The transfer of larger amounts or other special circumstances may be required even more stringent checks.
  • Authenticated members are payers 100 or payees 101 who have been verified for transactions up to a specified amount or for transactions that meet certain criteria that could include source and destination country, and number of payees and other criteria. Future transactions involving authenticated members may be streamlined in that they can be initiated and completed without additional verification. This simplifies repeat and reoccurring payments between parties. It also simplifies transactions between authenticated members 204 that have not previously transacted. For example, if payer A has transacted with payee B, then A and B are both authenticated members. If payer C has transacted with payee D, then C and D are both authenticated members.
  • payer A wants to transfer money to payee D or payer C wants to transfer money to payee B, it can be done without account verification since all four parties are authenticated members. However, if any of the parties are only verified at level 1 and then want to make a larger, level 2 transaction, they may have to submit further information to be verified to the required level to complete the transaction.
  • FIG. 3 shows details of an example of level 1 verification 301 according to one embodiment of the invention.
  • the level 1 verification starts with verification of the data input by an applicant (payer or payee) 302.
  • the data can be verified through a variety of means including a Geo (IP) location, address verification, phone number verification, OF AC (Office of Foreign Assets Control) check, and a check of business or industry directories.
  • Geo (IP) location is where the geographic location of an IP is queried from a public database.
  • the results of the check may raise flags 303 caused by results that meet predefined or dynamic criteria or exceed predefined or dynamic thresholds. Flags may also be raised when data is not available. If flags are raised, then a manual review 304 is required.
  • a check will be done to determine if the applicant has been banded from the service previously 311. If so, then the application will be declined 312 and the applicant rejected. If the applicant has not previously been banned, then the application will be escalated to compliance for a manual check 310. Should the use of funds be valid 313 then a check is made to verify if the transfer is a non-business-to-business use such as sending funds to the applicant themselves, to family, or to another individual 314. If this is the case a test will be done to verify is the applicant is a real customer 317. If not, the applicant will be declined 318. If so a gratuity test will be performed 316.
  • the value of the transaction will be evaluated against a threshold 320, for example $2,500.
  • a threshold 320 for example $2,500.
  • the exact limit may be chosen for business reasons by the payment processor or to ensure compliance with relevant government AML, KYC, and other regulations. If the transaction amount is less than the limit, then level 1 verification is completed 319. If the amount exceeds the threshold 320, then level 2 verification is required.
  • FIG. 4 shows details of an example of level 2 verification 401 according to one embodiment of the invention.
  • the applicant (payer or payee) is required to upload or provide more identification 402 such as government photo ID, proof of address, a list of beneficial owners of the company, articles of incorporation, or other similar identification.
  • the payment processor may also request additional information 403 as required.
  • a check of the beneficial owners 407 will be done and the information will be verified for completeness 406. If complete and the applicant is a public company 405 then a search will be done for the directors of the company and the data recorded by the payment processor 404.
  • the ID and the address will be verified 408 and if the verification of ID and the supplied address fails then the application will be escalated to compliance 409.
  • level 1 verification 320 for example, $100,000 410, as required for business reasons by the payment processor or to ensure compliance with relevant government AML, KYC, and other regulations, the transaction will be escalated to level 3 verification 413. If the transaction amount is greater than a lesser amount, such as $10,000 411, then level 2 verification is complete 414, otherwise more verification of applicant documents may be required.
  • FIG. 5 shows details of an example of level 3 verification 501 according to one embodiment of the invention.
  • the applicant payer or payee
  • the payer initiates the transaction by accessing the payment processor as a naked customer and registering.
  • the payer uses a computer or mobile device to access the website of the payment processor. This can be done by entering a URL in a web browser window, by clicking on a link in an e-mail, or by a variety of other well-known means.
  • the payer is prompted to create an account by entering a minimal amount of information that allows the payment processor to contact them. This could include a name, e-mail address, telephone number, and a password.
  • the payer then becomes an unprofiled customer.
  • the payment processor will than send a confirmation e-mail to the e-mail address entered by the payer prompting them to enter further information about themselves and their company.
  • the payer logs into the payment processor website and is presented with choices including to make a payment. This can be in response to an invoice being received or be unilaterally sending a payment to a payee.
  • the payer must then provide additional information concerning themselves or the business in order to verify their identify for regulatory compliance.
  • This information may include the name of business, the address of their place of business as well as banking information such as the bank name, routing number, and account number from which payment will be received. It may also include a crypto currency wallet address, credit or debit card information, or other information to allow money to be transferred from the payer to the payment processor. This information may be verified to comply with regulations based on the amount of money to be transferred, the country of origin or destination, the frequency or number of transactions, or other parameters. At this point the payer is considered to be a transacting customer and can proceed with the payment.
  • the payer must also enter information regarding the payee.
  • the information required may be similar or the same as for the payer.
  • the payer can input a minimal, but incomplete amount of information, complete information to verify the payee's identity, or any amount of information in between.
  • Minimal information would be the minimum information required by the payment processor to be able to contact the payee to receive further information.
  • Complete information is the information required to identify the payee and their business and comply will relevant government AML, KYC, and any other relevant regulations. Any information not provided by the payer will be provided by the payee afterwards and will be verified by the payment processor.
  • the payer having provided partial or complete payee information, will then provide the amount to be paid, and whether they will pay in crypto-currency or fiat-currency.
  • the amount to be paid in fiat-currency will often be the fiat-currency where the payer resides but may be another common fiat-currency such as US dollars or Euros.
  • Various options can also be made when making a payment that can be specified through a user interface at the payment processor's website. While individuals will likely only make a single payment at a time, business have more complex needs which could include paying multiple payees as part of the same transaction, making reoccurring payment such as salaries, electronic interfaces to accounting and financial software, and extensive reporting for internal or to fulfill government regulations regarding financial reporting and money laundering. For very small transactions such as micropayments where the fees are considered by the payer or payee to be significant, the payer, payee, or payment processor may choose to aggregate transactions before initiating the transfer at a later time. The payer may choose to not initiate transfers until the amount to be transferred exceed an amount or other criteria.
  • the payment processor may provide information on fees, time required to make the transaction, information tied to Service Level Agreements (SLAs) or any other information before the payer commits to the transaction.
  • SLAs Service Level Agreements
  • the payment processor will than use the payment information provided by the payer to transfer the required funds from the payer's bank or other payment source as indicated by the payer. This can be done in a variety of ways as known in the art including Automated Clearing House (ACH) transfers, electronic transfer, credit card payments, debit transfers, or drawing from an exiting payer account with the payment processor. If the payer is providing funds in a crypto-currency the payer will provide information to allow the payment processor to receive the funds which may include digital wallet addresses.
  • the payment processor has the option of initiating the transfer immediately or may delay the payment until they have received the funds from the payer.
  • the payment processor may initiate the transactions immediately or may also delay payment until certain criteria have been met such as receiving payment from the payer, making payment on a specified date, when the total amount to be transferred exceeds a certain amount, or any other criteria set by the payer or the payment processor.
  • the payment processor will then select a crypto-currency or several crypto-currencies for the transaction.
  • Crypto-currencies There are a variety of crypto-currencies and this variety is expected to grow over time. Depending on parameters of the transaction one crypto-currency may provide an advantage over others such as lower fees, increased security, faster transfer, extensive reporting, government approval, or others. Payers or payees may also insist on the use of a single or multiple approved crypto- currencies. Parameters are numerous but could include the location of the payer and payee, type of transfer, amount to be transferred and others.
  • the payment processor may choose a default crypto-currency or use these parameters to choose one. They may also select multiple crypto-currencies and present these choices to the payer and allow them to make the choice. Once a crypto-currency is chosen it will have associated protocols that govern the transfer, which may include information required, minimum and maximum amounts, and others.
  • the payment processor will select an exchange or multiple exchanges to convert the fiat-currency supplied by the payee to an equivalent amount of crypto-currency minus any fees that apply.
  • the exchange may be a digital or cryptocurrency exchange, a private transaction, dark pool, or offline exchange.
  • the exchange may report an exchange rate and any fees to be charged to the payment processor who may relay this information to the payer for approval or for informational purposes.
  • the payment processor may use the exchange rate spread between buying and selling to receive a fee for the transaction.
  • the payer may also supply a range of acceptable fees, a minimum amount of crypto-currency to be received by the payee after fees are paid, or other criteria and the payment processor may proceed without approval if the criteria are met.
  • the fiat-currency is successfully converted to crypto-currency by the exchange, which may be verified by a number of means including checking for errors, verifying success on the crypto-currency block chain, receiving an explicit indication of success from the exchange, or other means.
  • the crypto-currency amount is now converted by an exchange to an equivalent amount of the fiat-currency specified by or for the payee.
  • this conversion from crypto-currency to payee fiat- currency may have its own set of criteria.
  • some exchanges may provide an advantage such as lower fees, increased security, faster transfer, extensive reporting, government approval, or others.
  • Payers or payees may also insist on the use of a single or multiple approved crypto-currencies. Parameters are numerous but could include the location of the payer and payee, type of transfer, amount to be transferred and others. A default exchange may be used or an exchange may be chosen based on these criteria.
  • both the payer and the payee must be authorized members that have provided the required information and had the information verified by the payment processor.
  • a payee who in not an authorized member will receive an e-mail or similar communication such as SMS, from the payer either directly or through the payment processor.
  • the payee will be prompted to log into the payment processor's web site to supply additional information that hasn't been provided by the payer. This can include information regarding the business, the banking information of the payee, in fact, similar information required to identify the payee, compliant with government AML, KYC or other relevant national or international regulations.
  • the information will be verified by the payment processor as in the case of the payer.
  • the payee may also provide additional parameters such as the fiat-currency or crypto- currency of choice.
  • the payee may specify a minimum amount of payment to receive in order to aggregate payments to lessen the impact of any fees charged by the payment processor or their local bank.
  • the amount of information that must be provided and the verification required depends on the level of verification required which is dictated by government or international regulations or the business relationship between the payer and payee. For very small transactions, verification may not be required.
  • the payment processor will initiate the conversion from crypto- currency to the payee's fiat-currency and may receive the fiat-currency and use the payee's banking or deposit information to pay the crypto-currency to the payee. Alternatively, the payment processor may initiate the transfer of the payee fiat-currency directly to the payee from the exchange or through a third party using information identifying the payee.
  • the payment processor may then report information to the payer and payee including confirmation of the transfer completing successfully, exchange rates, fees, previously completed transfers, future scheduled transfers, taxes due, and other relevant information. Reporting may also be made to government bodies as required.
  • Transactions may be initiated by either the payer or the payee.
  • the payee may register and issue an invoice or a demand for a payment. If the payer is not an authenticated member the payee will input a minimum amount of information for the payment processor to contact the payer, complete information regarding the payer, or incomplete information regarding the payer. The payer will receive an e-mail or similar communication such as SMS, from the payee either directly or through the payment processor. The payer will be prompted to log into the payment processor's web site to supply additional information that hasn't been provided by the payer. This can include information regarding the business, the banking information of the payer, information required to identify the payer, compliant with government AML, KYC or other relevant national or international regulations.
  • FIG. 6 shows details of an example of a system used to make a transaction made using a first embodiment of the invention.
  • a transaction between a verified payer and a payee that has not previously used the payment processor starts when a payer wishes to pay a payee for a good or a service with the payer paying in a national, or fiat-currency of their choice and the payee receiving payment in a fiat-currency of their choice.
  • the payer may be a shopper paying a merchant or a business that is paying a supplier, an employee, or a consultant.
  • the payer and payee may be in the same or different countries.
  • the transaction may not involve any good or service but may be a financial transfer to send funds from a payer to a payee.
  • a payer or sender who has previously been verified and has conducted at least one transaction before starts the process by indicating through a user interface to pay an invoice 601.
  • the invoice contains at least partial identification information for the payer and the payee and may include banking information to where the payment should be made.
  • the process for a payee, or receiver is different for a new receiver 602 or an existing receiver 607 that has been verified.
  • the payer initiates the paying of an invoice and indicates a payee or receiver of the funds. Typically, the payer will not know if the receiver is a new or existing client of the payment processor. If the receiver or payee 602 is new, then the payer is prompted to enter banking information 603 to the system to enable payment.
  • the payer is then presented with a payment summary page 604 to enable them to verify the invoice payment details.
  • the payer will then be informed that since the payee is new 606 that the transaction must wait until the payee or receiver is registered and verified.
  • the payment processor will also be authorized to debit the payer's account as soon as the receiver registers and is verified 605.
  • the receiver is an existing client 607 of the payment processor but has not been verified for the size or other characteristic of the transaction 611
  • the payer will still be presented with a payment summary page 612 but will then be informed that the receiver must be verified 650 and that the payment processor is authorized to debit the payer's account as soon as the receiver registers and is verified 613.
  • the status of the transaction is changed to "sent pay" 614.
  • An email is sent to the receiver prompting them to complete their profile 615, to be registered and verified, in order to receive their payment.
  • An email is also sent to the sender informing them that the payment processor is awaiting payee confirmation and that the payment will be processed 616.
  • the payee or receiver After receiving the email notification, the payee or receiver will log into the payment processor's website and be presented with a user interface 618 that allows them to confirm the information for their account and to claim the invoice amount 617.
  • a final check of the transaction will be made to determine if the payer and payee are verified against the threshold for the transaction parameters. If the threshold is exceeded 620 then an additional popup window 620 will be presented to allow input of further information. If the threshold is not exceeded 619 the payee is then presented with a success/confirmation page 622.
  • the payee is an existing receiver and has been fully verified 609 then the payer is presented with a payment confirmation page 610. Another popup window confirming the decision and prompting for any additionally required bank details 626 is displayed. Once this happens or the success/confirmation page 622 is displayed then the status of the transaction is changed to "pull authorization" 624 and a confirmation email is sent to the sender 623 indicating that the payee will soon receive the funds, and to the receiver 625 informing them to expect to receive funds shortly.
  • An an example of a payee sending an invoice 630 is similar in that the process differs for the case of an existing, new sender or payer 631, or an existing sender, or payer 632.
  • the payee is presented with a user interface containing an invoice detail page from 633 that allows them to enter invoice data including the identity of the payer and banking information for both the payee or the payer.
  • An invoice summary form 634 is then displayed to allow the sender or payee to review and confirm the information.
  • the invoice is then sent 636 and any status updates to the payee 635 is also sent.
  • a check is made as to whether a transaction threshold for is not exceeded 638 or is exceeded 637 and if the threshold is exceeded an additional form is displayed 639 to enable the upload and verification of additional documentation.
  • An email is then sent to the payee 640 to prompt them to pay the invoice.
  • the payee who created the invoice is also sent an email 641 as a receipt for the transaction.
  • the payer may login to their existing account 643, or register for a regular or guest account 642. They are then presented with an interface to preview the invoice 644 and may then process and pay it 645. The status then changes to "push authorization" and the funds are transferred from the payer to the payee 649.
  • a configurable software module referred to as an "exchange router" uses criteria to select a rail, including currency exchanges, to be used in a currency conversion transaction where funds are transferred from a sender to a receiver.
  • the exchange router also administers how an exchange is going to be used on a crypto-network when the transaction is processed.
  • the module gathers dynamically changing cost and criteria input in real time from a variety of exchanges in order to choose an optimal rail for the transaction.
  • the exchange router is configurable through inputs that provide the criteria to evaluate exchanges. The input may be provided by one or more of the sender, receiver, payment processor, businesses, governments, banks, consumers, or any other organization.
  • criteria There may be a single input criteria or several where the criteria will vary depending on the needs of the parties involved in the financial transaction.
  • a variety of criteria may be used but common ones include the bid and ask price of the currency as is commonly used today.
  • Other criteria may include the maximum number of transactions in during a day, month, or other time period, minimum or maximum currency amount per transaction or during a time period. Criteria may be to use only fiat-currencies, crypto-currencies, or it may be allowable to use a combination of the two. Criteria may be selected and grouped to provide the basis of service level agreements (SLAs) between the sender or receiver and the payment processor.
  • SLAs service level agreements
  • Other possible criteria may be the fees charged, cost per transaction, monthly fees, or other costs involved in the transaction. Additional criteria of interest may be related to payment types supported for payments in and out. Criteria related to exchange size and reliability may also be used, for example, size of the company that owns the exchange, amount of currency converted, number of conversions, and exchange uptime.
  • an example of a crypto-currency financial transaction is the transfer of funds from a payer 701 in one country to a payee 713 in the same or another country using crypto-currency as a transport mechanism.
  • a payer in a first country initiates a transfer using their home country fiat-currency 702 and specifying the payee's deposit destination information 703 such as a bank account and routing information.
  • the payment processor will then convert the fiat-currency amount to an equivalent crypto-currency amount 707.
  • the crypto-currency will be transferred to the payee's country using crypto-currency infrastructure as a transport mechanism.
  • the crypto-currency is converted to a second fiat-currency 709, that is payee's home country fiat-currency, and paid to the payee.
  • These steps are typically performed in the order above but could be done in any order given the level of trust and arrangements between the parties involved.
  • In the above transaction there are two exchanges performed; from a first fiat-currency to crypto-currency and from the crypto-currency to a second fiat- currency. Both of these conversions may utilize the exchange server of this embodiment with the same or different criteria defined.
  • the criteria could be defined by either the sender or the receiver of the transfer, the company providing the transfer infrastructure, government regulations or other entities. Criteria may be combined and may be decided at the time of transfer or in advance.
  • the transaction uses a rail that uses two exchanges; a first exchange to convert the payee fiat-currency to crypto-currency and a second exchange to convert the crypto-currency to an equivalent amount of the payee's fiat-currency.
  • Each exchange has a weighting in the exchange router where the weighting gives it a relative priority compared to other exchanges. This is defined as the exchange weighting.
  • the router determines the exchange to use based on the weighting allocated for the exchange.
  • This crypto-currency financial transaction illustrates the transfer of funds from a payer 801 in one country to a payee 813 in the same or another country using crypto-currency as a transport mechanism where the presence of sufficient reserve funds allows for a payment to a payee to be made before other currency exchanges have completed or been confirmed.
  • a payer in a first country initiates a transfer using their home country fiat-currency 803 and specifying the payee's deposit destination information 803 such as a bank account and routing information.
  • the payment processor determines one or more exchanges to use for the fiat-currency to crypto-currency 806, crypto-currency to fiat-currency 808, and any crypto-currency to crypto-conversions required using criteria as defined.
  • the criteria 805 could be defined by either the sender or the receiver of the transfer, the company providing the transfer infrastructure, government regulations or other entities. Criteria may be combined and may be decided at the time of transfer or in advance.
  • the criteria may change as well, the will then convert the fiat-currency amount to an equivalent crypto-currency amount.
  • the conversions form a chain and in this embodiment the presence of a reserve fund in the correct currency at any part of the chain allows for that transfer to be made before currency is received from the previous link in the chain.
  • a payee may receive their payment 809 in their local fiat-currency 811 should the local crypto-currency to fiat-currency exchange hold a reserve in the local currency and make the payout before receiving crypto-currency received from the payee's initiated transaction.
  • steps in the processes described herein may be performed in any order given reserve levels, contractual agreements, or other arrangements as agreed to by one of more of the parties involved.
  • FIG. 9 illustrates an embodiment of the invention as implemented on computer hardware by a payment processor to choose a rail for financial transaction.
  • a transaction can be initiated by either a payer (sender) or a payee (receiver).
  • a payer may have received an invoice to pay, may be required to make a payment in advance of a shipment, or may simply want to transfer funds to another party.
  • a payee may want to initiate a transaction to request funds as in sending an invoice to another party.
  • Both the sender and the receiver are registered with the payment processor or will be registered as part of the process and this will include information required to comply with KYC (know your customer) and AML (anti-money laundering) requirements as required by governments or by the sender or the receiver.
  • KYC requirements may also be required by an exchange or a third party who may be guaranteeing the transaction or acting as an escrow agent.
  • the payment processor starts to collect key parameters of the transaction. This can be looking at the source 902 and the destination 903.
  • the payment processor reads in a first set of criteria that are relevant for transfers originating from the United States. These criteria may vary depending on the originating country and may vary depending on the information provided by the sender.
  • the payment processor will also look at the destination of the transfer 903 and this will dictate a second set of criteria that is added to the first set. In the example given the destination may be Mexico or China. Assuming that China 904 does not permit crypto-currency transfers then a traditional wire transfer will be used to pay out the transfer to the receiver.
  • the receiving currency will be examined 905 and this lead to a third set of criteria being added.
  • the payment is made from the United States to Mexico in US dollars then crypto-currencies may not be used and a wire transfer is chosen 906.
  • the payee receives funds in peso there exist rails that utilize both traditional wire transfer exchanges and crypto-currency exchanges and the payment processor.
  • the calculation of the cost 908 of the rails is non-trivial and is performed by the payment processor.
  • the calculation of the cost 908 of the available rails starts with the use of computer implemented API (application programming interfaces) to automatically query the banks and exchanges that make up the possible rails for the transfer. Each exchange and bank will return different data in different formats and this must be normalized by the payment processor in order to compare them. The costs will then be evaluated against the criteria.
  • a variety of criteria may be used but common ones include the bid and ask price of the currency as is commonly used today.
  • Other criteria may include the maximum number of transactions in during a day, month, or other time period, minimum or maximum currency amount per transaction or during a time period. Criteria may include the amount of time required to complete a transaction. Further criteria may include the amount, detail, and accuracy of the reporting provided by the rail.
  • Criteria may be to use only fiat- currencies, crypto-currencies, or it may be allowable to use a combination of the two. Criteria may be selected and grouped to provide the basis of service level agreements (SLAs) between the sender or receiver and the payment processor. This may be combined with reporting in order to determine if the SLA conditions have been fulfilled. Due to the stateless nature of crypto-currency exchanges there may also be criteria based on the fiat- currencies supported by the exchange as well as their liquidity for chosen fiat-currencies. The country where the exchange is located or registered in, what laws they operate under and what national or international regulations they abide by may also be of interest. Other possible criteria may be the fees charged, cost per transaction, monthly fees, or other costs involved in the transaction. Additional criteria of interest may be related to payment types supported for payments in and out. Criteria related to exchange size and reliability may also be used, for example, size of the company that owns the exchange, amount of currency converted, number of conversions, and exchange uptime.
  • SLAs service level agreements
  • the querying of the banks and exchanges must be done in a timely manner as close to the time of the payment processor evaluating rails to ensure that highly volatile data is as up to date as possible.
  • the payment processor may maintain a table of costs that include when they were last updated and an indication of their volatility. Highly volatile costs may have to be updated frequently while low volatility costs may be updated infrequently.
  • each source and destination in this illustrative example the United States 1002, Kenya 1005, Mexico 1003, and Italy 1004 has a number of rails that can be used to transfer funds from and to them.
  • Rails may be bidirectional or unidirectional. Unidirectional transfers are where currencies may be transferred in or out using a particular exchange but not both. A country such as the United States will have a large number of available rails 1007 while a smaller country such as Kenya may have only one 1006.
  • Rails may incorporate a single or multiple exchanges and may be able to convert all or only some fiat-currencies and crypto-currencies.
  • FIG. 11 shows a geographical view of an embodiment of the invention.
  • the sender is located in the US 1101 and may initiate or respond to transactions using a personal computer, mobile device, telephone or other means of communication.
  • the interface using a personal computer or mobile device may be a customized web page or a local application that allows the use to register, authenticate with the payment processor, provide identification for themselves and the receiver, and to communicate with the payment processor to verify their identity in link with KYC criteria.
  • the user interface also allows them to specify general criteria to be used with all of their transactions as well as specific criteria. Specific criteria may apply to sending payments, receiving payments, to certain receivers or groups of receivers. Specific criteria may apply to receivers in certain countries, or that use certain currencies, including crypto-currencies. For example; criteria may apply to receivers in Mexico that want to receive payment in bitcoin and are in the telecommunications industry. Other criteria may apply to receivers in Germany who want to receive payment in Euro and have overdue payments due to the sender.
  • the sender 1101 interfaces to the payment processor 1102 who may be located in the same country as the sender or the receiver, or somewhere where neither is located. If the sender is sending in fiat-currency they will typically interface with one of the local banks 1104, or another local bank 1105. If they are sending funds in a crypto-currency they may use one located in their home country 1106, or one in the receiver's country 1109, or one located elsewhere 1107 or 1108. Similar to the sender, the receiver 1103 may initiate or respond to transactions using a personal computer, mobile device, telephone or other means of communication.
  • the interface using a personal computer or mobile device may be a customized web page or a local application that allows the use to register, authenticate with the payment processor, provide identification for themselves and the receiver, and to communicate with the payment processor to verify their identity in link with KYC criteria.
  • the user interface also allows them to specify general criteria to be used with all of their transactions as well as specific criteria.
  • the receiver 1103 may receive payout in the fiat-currency of their choice using a local bank 1111 from among a choice of local banks 1110. They may receive payment in a crypto- currency through a crypto-exchange that is local 1109, in the sender's country 1106, or located elsewhere 1107, 1108.
  • the payment processor will evaluate the transaction data and its associated criteria as well as criteria supplied by the sender and the receiver.
  • the payment processor will determine the optimal rail for the transaction given the criteria.
  • the payment processor may also determine redundant or back-up rails that could also be used to complete the transaction. These redundant rails may have the same cost, or the same overall cost but may have higher scores or lower costs in different criteria from the primary rail.
  • the payment processor may have criteria to decide when to use a redundant rail or may give the choice to the sender or the receiver.
  • FIG. 12 illustrates how security policies 1201 can be implemented using a third embodiment of the invention.
  • Multi-signature addresses 1202 provide security for access to crypto-currencies for secure storage or transactions.
  • a multi-signature address is an address that is associated with more than one public-private key pair 1203.
  • One of the simplest form of multi-signature address 1202 is an m-of-n address and is defined by the variables m and n, where n is the total number of public-private keys associated with generating a multi- signature address 1202 and m is the number of private keys that must be signed in order to unlock the address associated with the crypto-currency.
  • n is 2. It can be seen that m is less than or equal to n.
  • a multi-signature transaction is one that sends and receives funds from a multi-signature address.
  • Using an m-of-n multi-signature address 1202 allows the n keys to be kept in multiple location, on multiple computer systems, with multiple computer operating systems even in non-digital and offline locations such as in paper or in paper wallets.
  • the key can be managed and administered using separate applications as well. Since m of the total keys must be compromised in order to unlock the value assigned to a transaction unlocking the multi- signature address becomes more difficult than the case of a single signature which has only a single key.
  • M-of-n multi-signature addresses 1202 also provide redundancy. For example, with a 2-of-3 address, the crypto-currency owner can still unlock the value if they forget any single key provided they have at least 2 of the 3. Multi -signature addresses 1202 may also be shared among multiple people where a majority vote or a defined number of votes are required to unlock and use the funds. Another embodiment of multi-signature addresses involves a party such as a payment processor setting up, tearing down, configuring, and processing multi- signature addresses and transactions involving multi-signature addresses.
  • Each key 1203 may be labeled and named by the payment processor or user for reference.
  • Each key 1203 is also programmed or configured by linking it to a script, software, or configuration 1206.
  • Each script defines a number of conditions 1208, attributes 1209, and rules 1207.
  • the script or the software 1206 can be resident on a payer's computer, server, digital storage, cloud locations or mobile device.
  • the script 1206 could also be resident on servers, or computers or mobile devices operated by the payment processor or another third party.
  • the script 1206 includes one or more rules 1207 that must trigger to enable a key 1203 to be signed.
  • Each rule 1207 defines a Boolean combination of conditions 1208 that must occur for the rule 1207 to be triggered. For example, given four conditions 1208 labeled A, B. C. and D, one rule 1207 may be triggered if conditions 1208 A. B. and D occur, whether C occurs or not. Another example would be to trigger the rule 1207 if B and C occurred but not D. A further example would be to trigger a rule 1207 if any 3 of conditions A, B, C, or D occur.
  • conditions 1208 are comprised of one or more attributes 1209 such as if the price of bitcoins is greater than $500. the price of inventory is less than $200, a seller is located in a specific location such as San Francisco, or the age of a buyer over 18 years of age. or any number of other attributes 1209 agreed upon by the payment processor, the merchant, the consumer, the payer, the payee, or other involved parties.
  • attributes 1209 such as if the price of bitcoins is greater than $500. the price of inventory is less than $200, a seller is located in a specific location such as San Francisco, or the age of a buyer over 18 years of age. or any number of other attributes 1209 agreed upon by the payment processor, the merchant, the consumer, the payer, the payee, or other involved parties.
  • rules 1207, conditions 1208, and attributes 1209 other combinations and combinations can be defined depending on the level of complexity desired and the level of security required.
  • a "safety key" 1205 may also be defined which would allow for the unlocking of an escrow or a disputed
  • the payment processor can setup an "exit key" 1204; a time based rules or any other type of rules to exit or cancel a multi-signature transaction and return the funds to their owner or another action.
  • the attributes 1209, conditions 1208 and rules 1207 for the exit rule 1204 may be setup in situations where the triggering of the events that are designed to activate the keys have not occurred and where a time limit has expired.
  • An example is that if the multi-signature address 1202 is configured where the private key 1203 is activated if the price of the good goes down by 5% for a period no more than 24 hours, then at the expiry of the time period, the transaction expires and the funds are returned to their owner.
  • the exit rule 1204 conditions could be time based, event based, payer based, payee based, or enforced by the payment processor based on its policies or requests by banks, government agencies or any other entity that has the ability to force the address to expire.
  • attributes 1209 include but are not limited to:
  • Time field Key is activated after midnight.
  • the key is activated only if the payer is in California.
  • the key is activated based on the identity of the payer on a national or state driver's license.
  • Price of a good or service The key is activated if the price of the good is over specified amount or the price of this service declines to below a specified price.
  • the key is activated if the price of a crypto-currency is over a specified amount or the price of a fiat-currency is over a specified amount.
  • the key is activated if the payer is in the customer database.
  • the key can be activated if the weather in New York is above 50 degrees Fahrenheit or if the result of the presidential election were in favor of candidate A.
  • scripts 1206 can be used for multiple aspects of a multi-signature key system including but not limited to the following.
  • Routing to Mobile devices o Routing to Local machine storage, including hard disks and solid-state drives o Routing to Web browser storage
  • o Script that allows for automated remote signing. For example, through email or through a dashboard application,
  • Keys may be generated by any number of electronic devices including servers, computer, tablets, cell phones. Keys may be supplied or partially supplied by the user, the payment processor, or by a financial institution such as a bank or currency exchange. The keys may be stored on a user's own device and may be stored in a database. When stored in a database, an application can be authorized to access the key from the database. Keys may be split and stored in a number of locations, for example partially on a user's device, with a payment processor, or with a financial institution such as a bank or currency exchange.
  • a multi-signature address 1202 can also function as a unique identifier that abstracts traditional payment types including: wallets, cash, cards, bank, prepaid cards, gift cards, voucher cards, voucher pins, or any other form of eMoney.
  • the multi-signature address becomes the trigger for the payment action. For example, once conditions are met, credit cards are charged, funds pushed or pulled from bank accounts, funds released from escrow, cash exchanged or moved into electronic wallets, gift cards exchanged for inventory, vouchers applied and executed.
  • the same logic and actions that apply to crypto-currency are applicable for traditional payments and the address acts as a proxy, or a representation of the action required from traditional payments.
  • a set of rules 1207 on a network can define the behavior of payments inside the network. Therefore, it is feasible to setup operating policies 1201 on the network comprising of a set of rules 1207 and conditions 1208 administered on a set of multi-signature addresses 1202 thereby determining and influencing the behavior of transactions; what gets accepted and what gets declined.
  • E-Commerce and financial service providers can incorporate multi-signature keys for conducting currency exchanges within or between countries, to purchase items, issue invoices, to pay employees and a variety of other uses.
  • Currency exchanges can be from a national or fiat currency to a crypto-currency such as Bitcoin or the reverse, from a crypto- currency to a fiat currency.
  • the transfer of currencies can be between the same currency or between different currencies.
  • Service providers may integrate multi-signature technology into a web-based user interface using APIs (application programming interfaces).
  • a payment processor is a company or organization that provides the software and infrastructure to do currency exchanges using multi-signature keys.
  • a plugin can be created by the payment processor to allow people to collect payments through their website in different crypto and fiat currencies.
  • the plugin provided by the payment processor provides a payment gateway that may be branded by either the service provider or the payment processor.
  • a user must enter identification and bank account information after which the payment proceeds in a similar way to paying online using a credit card or PayPal.
  • the Payment processor is responsible for checking and verifying the user's identity including name, address and any other required information required to verify their identity.
  • the service provider (merchant or financial institution) is not required to assume the risk of a fraudulent transaction. This is assumed by the payment processor.
  • the plugin uses a software module called a "risk engine" that will confirm the user data and combine it with attributes of the transaction to evaluate the risk of the transaction to determine the complexity of the multi signature key to be used.
  • Transaction attributes can include the identity and payment history of the payer and payee, the source and destination country of the transaction, the fiat or crypto currencies involved and their amount, the risk tolerance of merchants, financial institutions, currency exchanges, and governments involves, and a variety of other factors.
  • the risk engine allows the user to enter the required information to evaluate the transaction and if it determines that it is a high-risk transaction may stop the transaction, and require additional information or require manual intervention.
  • the payment processor will evaluate the multi signature key and sign them, thereby assuming the risk for the transaction.
  • the merchant, financial exchange, currency exchange, or other involved party may configure the level of risk they are willing to accept using a software module referred to as the "business configuration engine”. This can be used to specify the parameters of the multi signature key such as the number of keys, number of rules, scripts, conditions, and attributes.
  • Advanced currency exchange features may be implemented by the plugin such as creating queues for each source and destination currency exchange and only triggering the actual conversion when a predefined exchange rate is met.
  • This can be implemented using multi-signature keys by defining an additional key where the rule includes a condition where the attribute is the desired exchange rate. Note that if the condition is never met some conversions may take a long time or may never trigger. In this case an exit key containing a rule with a condition using an attribute of the pendency of the transaction can be used to automatically cancel the transaction or notify the payee or payer.
  • the payment processor has its own risk engine to determine the parameter of the multi signature key and therefore may assume the risk of the transaction.
  • the evaluation by the risk engine and the responsibility may be bourn by third party insurance companies.
  • companies, merchants, financial institutions, insurance companies and other parties may utilize multi signature keys to implement a manual authorization system for high risk or high value transactions. This can be done by defining a manual key in each multi signature address that must be entered by an individual in the organization to approve the transaction.
  • the manual key may involve entering data through a user interface device such as a keyboard, a scanned signature, biometric information such as a finger print or iris scan, or inserting a specially prepared USB key, SD card, NFC device or similar non-volatile memory device.
  • the finance manager may be able to approve most transactions immediately but transactions over a specified amount are queued until the CEO or CFO inserts a USB key into a computer or terminal or accesses the payment processor's website using a specific laptop, computer, or mobile computing device.
  • the private manual key stored on a USB key or electronic device does not have to be the actual key but may be a hash of the key.
  • a similar setup may be used by police to release confiscated funds, a parent to approve purchases made by their children over a predefined amount, or customs officials when currency limits are exceeded.
  • larger organizations there may be a large number of private USB sticks containing private manual keys to approve large transactions. These may be distributed to the officers of the company and large transactions may be signed and approved by using a subset of the distributed keys.
  • a bank may have a special authorization key with 3 USB sticks required from a total of 10 officers of the bank to approve the transaction.
  • Any algorithm, software, or method disclosed herein can be embodied in software stored on a non-transitory tangible medium such as, for example, a flash memory, a CD-ROM, a floppy disk, a hard drive, a digital versatile disk (DVD), or other memory devices, but persons of ordinary skill in the art will readily appreciate that the entire algorithm and/or parts thereof could alternatively be executed by a device other than a controller and/or embodied in firmware or dedicated hardware in a well-known manner (e.g., it may be implemented by an application specific integrated circuit (ASIC), a programmable logic device (PLD), a field programmable logic device (FPLD), discrete logic, etc.).
  • ASIC application specific integrated circuit
  • PLD programmable logic device
  • FPLD field programmable logic device
  • machine-readable instructions represented in any flowchart depicted herein can be implemented manually as opposed to automatically by a controller, processor, or similar computing device or machine.
  • specific algorithms are described with reference to flowcharts depicted herein, persons of ordinary skill in the art will readily appreciate that many other methods of implementing the example machine readable instructions may alternatively be used. For example, the order of execution of the blocks may be changed, and/or some of the blocks described may be changed, eliminated, or combined.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Finance (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Computer Security & Cryptography (AREA)
  • Marketing (AREA)
  • Technology Law (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Un processeur de paiement reçoit des informations sur des devises ainsi que des informations d'identification. Les informations sur les devises comprennent la devise fiduciaire d'un payeur et la devise fiduciaire d'un bénéficiaire, et les informations d'identification comprennent des informations permettant de vérifier l'identité d'un payeur et d'un bénéficiaire. Le processeur de paiement utilise les informations sur les devises et les informations d'identification pour déterminer un niveau de restriction de transaction et vérifie que les informations d'identification sont conformes au seuil pour le niveau de restriction de transaction. Le processeur de paiement reçoit un paiement dans la devise fiduciaire du payeur et déclenche une transaction pour convertir le montant dans la devise fiduciaire du payeur en montant dans la devise cryptographique. Le processeur de paiement convertit le montant dans la devise cryptographique en montant dans la devise fiduciaire du bénéficiaire. Le processeur de paiement déclenche un transfert du montant dans la devise fiduciaire du bénéficiaire vers le bénéficiaire.
PCT/US2016/058116 2015-10-22 2016-10-21 Système et procédé de traitement de paiement au moyen de devises cryptographiques WO2017070469A1 (fr)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US14/919,909 2015-10-22
US14/919,909 US20170116608A1 (en) 2015-10-22 2015-10-22 System and method for payment processing using crypto currencies
US14/942,216 2015-11-16
US14/942,216 US20170140371A1 (en) 2015-11-16 2015-11-16 Multiple payment rail gateway and router
US15/040,498 2016-02-10
US15/040,498 US20170228727A1 (en) 2016-02-10 2016-02-10 Conditional payment processing using multi-signature addresses

Publications (1)

Publication Number Publication Date
WO2017070469A1 true WO2017070469A1 (fr) 2017-04-27

Family

ID=58558257

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2016/058116 WO2017070469A1 (fr) 2015-10-22 2016-10-21 Système et procédé de traitement de paiement au moyen de devises cryptographiques

Country Status (1)

Country Link
WO (1) WO2017070469A1 (fr)

Cited By (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018204822A1 (fr) * 2017-05-04 2018-11-08 Monticello Enterprises LLC Permettre des paiements de cryptomonnaie par l'intermédiaire d'une interface de programmation d'application de navigateur
CN108805712A (zh) * 2018-05-29 2018-11-13 阿里巴巴集团控股有限公司 资产转移的回退处理方法及装置、电子设备
CN108876607A (zh) * 2018-05-29 2018-11-23 阿里巴巴集团控股有限公司 资产转移方法及装置、电子设备
US20190026705A1 (en) * 2017-07-18 2019-01-24 Ki Ho Lee Payment system using cryptocurrency exchanges
CN109687970A (zh) * 2018-12-07 2019-04-26 南京理工大学 一种移动区块链全节点及其实现方法
WO2019084571A1 (fr) * 2017-10-23 2019-05-02 Spangenberg Erich Lawson Système de paiement d'ico, de financement participatif et de prévente utilisant une monnaie alternative
WO2019094828A1 (fr) * 2017-11-09 2019-05-16 Indeco Union Génération de crypto-actifs numériques
WO2019222432A1 (fr) * 2018-05-16 2019-11-21 Rare Bits, Inc. Utilisation d'une devise classique pour l'achat, la vente et/ou la négociation en temps réel de marchandises à base de chaîne de blocs
WO2019246567A1 (fr) * 2018-06-21 2019-12-26 9Th Gear Technologies, Inc. Procédé, appareil et système orientés chaîne de blocs permettant d'accélérer un traitement de transaction
WO2020010383A1 (fr) * 2018-07-13 2020-01-16 Elbaite Holdings Pty Limited Procédé permettant de faciliter des transactions entre des utilisateurs
WO2020028513A1 (fr) * 2018-07-31 2020-02-06 Morgan Stanley Services Group Inc. Réseau de nœuds de calcul et procédé d'exploitation des nœuds de calcul pour effectuer un transfert d'argent entre comptes bancaires en temps réel
EP3608858A1 (fr) * 2018-08-10 2020-02-12 Vasile Cosmin Tuturas Haiduc Procédé de transfert d'argent réversible décentralisé
US10789598B2 (en) 2018-05-29 2020-09-29 Alibaba Group Holding Limited Blockchain transaction reconciliation method and apparatus, and electronic device
CN112819630A (zh) * 2021-02-08 2021-05-18 天地融科技股份有限公司 一种定向数字货币签发方法及装置
US20210224795A1 (en) * 2018-06-29 2021-07-22 Swycl Inc. Escrow non-face-to-face cryptocurrency transaction device and method using phone number
WO2021225898A1 (fr) * 2020-05-06 2021-11-11 Flexa Network Inc. Système de paiement en cryptomonnaie
WO2022046123A1 (fr) * 2020-08-31 2022-03-03 Steamchain Corp. Système et procédé de conversion de monnaie commandés par l'utilisateur
US11328303B2 (en) 2018-05-29 2022-05-10 Advanced New Technologies Co., Ltd. Asset transfer method and apparatus, and electronic device
EP3850498A4 (fr) * 2018-09-17 2022-06-01 Blockrules Ltd Système d'authentification de transactions et procédés apparentés
US20220237598A1 (en) * 2021-01-22 2022-07-28 Bakkt Marketplace, LLC Efficient, accurate, and secure digital asset conversions for real-time funding of merchant transactions
EP3903274A4 (fr) * 2018-12-27 2022-08-24 Multichain Ventures, Inc. Système et procédé pour établir une transaction de paiement à l'aide de multiples monnaies électroniques
US11880826B2 (en) 2020-12-16 2024-01-23 Bakkt Marketplace, LLC Efficient, accurate, and secure processing of digital asset conversion to fiat currency
US11961136B2 (en) 2020-12-16 2024-04-16 Bakkt Marketplace, LLC Efficient, accurate, and secure transfers of internally-custodied digital assets

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080091619A1 (en) * 2006-10-11 2008-04-17 Visa International Service Association Method and system for processing micropayment transactions
US20130097056A1 (en) * 2011-10-13 2013-04-18 Xerox Corporation Methods and systems for recommending services based on an electronic social media trust model
US20150178693A1 (en) * 2013-12-20 2015-06-25 Eric A. Solis Financial services ecosystem
US20150262139A1 (en) * 2014-03-17 2015-09-17 Coinbase, Inc. Bitcoin exchange

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080091619A1 (en) * 2006-10-11 2008-04-17 Visa International Service Association Method and system for processing micropayment transactions
US20130097056A1 (en) * 2011-10-13 2013-04-18 Xerox Corporation Methods and systems for recommending services based on an electronic social media trust model
US20150178693A1 (en) * 2013-12-20 2015-06-25 Eric A. Solis Financial services ecosystem
US20150262139A1 (en) * 2014-03-17 2015-09-17 Coinbase, Inc. Bitcoin exchange

Cited By (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018204822A1 (fr) * 2017-05-04 2018-11-08 Monticello Enterprises LLC Permettre des paiements de cryptomonnaie par l'intermédiaire d'une interface de programmation d'application de navigateur
US20190026705A1 (en) * 2017-07-18 2019-01-24 Ki Ho Lee Payment system using cryptocurrency exchanges
WO2019084571A1 (fr) * 2017-10-23 2019-05-02 Spangenberg Erich Lawson Système de paiement d'ico, de financement participatif et de prévente utilisant une monnaie alternative
WO2019094828A1 (fr) * 2017-11-09 2019-05-16 Indeco Union Génération de crypto-actifs numériques
WO2019222432A1 (fr) * 2018-05-16 2019-11-21 Rare Bits, Inc. Utilisation d'une devise classique pour l'achat, la vente et/ou la négociation en temps réel de marchandises à base de chaîne de blocs
CN108876607B (zh) * 2018-05-29 2021-03-23 创新先进技术有限公司 资产转移方法及装置、电子设备
US11216820B2 (en) 2018-05-29 2022-01-04 Advanced New Technologies Co., Ltd. Asset transfer reversal method and apparatus, and electronic device
CN108876607A (zh) * 2018-05-29 2018-11-23 阿里巴巴集团控股有限公司 资产转移方法及装置、电子设备
US11449873B2 (en) 2018-05-29 2022-09-20 Advanced New Technologies Co., Ltd. Blockchain transaction reconciliation method and apparatus, and electronic device
TWI699725B (zh) * 2018-05-29 2020-07-21 香港商阿里巴巴集團服務有限公司 資產轉移方法及裝置、電子設備
US10789598B2 (en) 2018-05-29 2020-09-29 Alibaba Group Holding Limited Blockchain transaction reconciliation method and apparatus, and electronic device
CN108805712A (zh) * 2018-05-29 2018-11-13 阿里巴巴集团控股有限公司 资产转移的回退处理方法及装置、电子设备
US11328303B2 (en) 2018-05-29 2022-05-10 Advanced New Technologies Co., Ltd. Asset transfer method and apparatus, and electronic device
WO2019246567A1 (fr) * 2018-06-21 2019-12-26 9Th Gear Technologies, Inc. Procédé, appareil et système orientés chaîne de blocs permettant d'accélérer un traitement de transaction
US20210224795A1 (en) * 2018-06-29 2021-07-22 Swycl Inc. Escrow non-face-to-face cryptocurrency transaction device and method using phone number
WO2020010383A1 (fr) * 2018-07-13 2020-01-16 Elbaite Holdings Pty Limited Procédé permettant de faciliter des transactions entre des utilisateurs
WO2020028513A1 (fr) * 2018-07-31 2020-02-06 Morgan Stanley Services Group Inc. Réseau de nœuds de calcul et procédé d'exploitation des nœuds de calcul pour effectuer un transfert d'argent entre comptes bancaires en temps réel
US11037113B2 (en) 2018-07-31 2021-06-15 Morgan Stanley Services Group Inc. Network of computing nodes and a method of operating the computing nodes to effectuate real-time bank account-to-bank account money transfer
EP3608858A1 (fr) * 2018-08-10 2020-02-12 Vasile Cosmin Tuturas Haiduc Procédé de transfert d'argent réversible décentralisé
EP3850498A4 (fr) * 2018-09-17 2022-06-01 Blockrules Ltd Système d'authentification de transactions et procédés apparentés
CN109687970B (zh) * 2018-12-07 2022-02-01 南京理工大学 一种移动区块链全节点及其实现方法
CN109687970A (zh) * 2018-12-07 2019-04-26 南京理工大学 一种移动区块链全节点及其实现方法
EP3903274A4 (fr) * 2018-12-27 2022-08-24 Multichain Ventures, Inc. Système et procédé pour établir une transaction de paiement à l'aide de multiples monnaies électroniques
WO2021225898A1 (fr) * 2020-05-06 2021-11-11 Flexa Network Inc. Système de paiement en cryptomonnaie
WO2022046123A1 (fr) * 2020-08-31 2022-03-03 Steamchain Corp. Système et procédé de conversion de monnaie commandés par l'utilisateur
US11880826B2 (en) 2020-12-16 2024-01-23 Bakkt Marketplace, LLC Efficient, accurate, and secure processing of digital asset conversion to fiat currency
US11961136B2 (en) 2020-12-16 2024-04-16 Bakkt Marketplace, LLC Efficient, accurate, and secure transfers of internally-custodied digital assets
US20220237598A1 (en) * 2021-01-22 2022-07-28 Bakkt Marketplace, LLC Efficient, accurate, and secure digital asset conversions for real-time funding of merchant transactions
CN112819630A (zh) * 2021-02-08 2021-05-18 天地融科技股份有限公司 一种定向数字货币签发方法及装置

Similar Documents

Publication Publication Date Title
WO2017070469A1 (fr) Système et procédé de traitement de paiement au moyen de devises cryptographiques
US11321682B2 (en) System and method for transferring funds
US11810087B1 (en) System and method for transferring funds
RU2644514C2 (ru) Способы и системы для проверки транзакций перевода электронных денежных средств
JP5118959B2 (ja) オンライン認証方法及びシステム
US20190318353A1 (en) Real time data processing platform for resources on delivery interactions
US7925586B2 (en) Method and system for multi-currency escrow service for web-based transactions
US8630951B2 (en) Systems and methods for electronically circulating a currency
US20100191622A1 (en) Distributed Transaction layer
US20170116608A1 (en) System and method for payment processing using crypto currencies
KR20240008378A (ko) 디지털 화폐를 사용하는 거래를 용이하게 하기 위한 시스템 및 방법
JP2007536619A5 (fr)
US20170228727A1 (en) Conditional payment processing using multi-signature addresses
US20210090166A1 (en) System and Method for Acquiring a Cryptocurrency in Exchange for Completing a Financial Transaction of Another
US20140365247A1 (en) Method, apparatus, and computer program product for obtaining coverage request authorizations
US10970688B2 (en) System and method for transferring funds
JP5592428B2 (ja) ネットワークで金融取引を行うためのシステム及び方法
WO2023201360A2 (fr) Procédé, contrôleur et support lisible par ordinateur permettant le remplacement d'une structure de données de transfert à répétition annulée sur un réseau de transfert distribué
US10140658B1 (en) Commodity backed virtual currency method and system for network transactions
US11507931B1 (en) Payout payment platform
US20220391864A1 (en) Blockchain Lien System for Digital Financial Transactions
KR20060108269A (ko) 안전한 전자상거래 중개 시스템 및 전자상거래 중개 방법
JP2024501883A (ja) デジタル通貨を使用して取引を円滑にするためのシステムおよび方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16858292

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16858292

Country of ref document: EP

Kind code of ref document: A1