WO2017098519A1

WO2017098519A1 - A system and method for automated financial transaction validation, processing and settlement using blockchain smart contracts

Info

Publication number: WO2017098519A1
Application number: PCT/IL2016/051321
Authority: WO
Inventors: Adi BEN-ARI; Kush PATEL
Original assignee: Tallysticks Limited
Priority date: 2015-12-08
Filing date: 2016-12-08
Publication date: 2017-06-15

Abstract

A computer implemented method for automated financial transaction processing and settlement in a network based private blockchain is herein disclosed. The method comprises steps of a. creating an instance of a smart contract associated to a first proposed financial transaction in said network based private blockchain, and a value is required for fulfillment of said first financial transaction; b. associating the first proposed transaction with a second proposed transaction; and, c. receiving a notice that the first financial transaction is.

Description

A SYSTEM AND METHOD FOR AUTOMATED FINANCIAL TRANSACTION VALIDATION, PROCESSING AND SETTLEMENT USING BLOCKCHAIN SMART CONTRACTS FIELD OF THE INVENTION

The present invention relates to a method and system for automated transaction processing using hlockchain smart contracts, and more specifically cross-organization financial transaction workflow.

BACKGROUND OF THE INVENTION

An innovation in transaction and financial technology is the automated processing and settlement of smart contract invoices on blockchain technology using existing banking mechanism which transact using fiat currencies. These smart contract invoices have been designed to transact on decentralized open source networks which may be public or private.

There is a need for a transaction settlement process that solves for providing a method of reconciliation between transaction participants without the need for a mutually trusted intermediary. Specifically, there is a need for providing an automated and instantaneous transaction settlement process that uses non-cryptographic currencies. Such transaction settlement process includes the integration of traditional banking mechanisms, which transact using fiat currencies. Companies typically use trusted intermediaries to settle transactions and subjectively record transaction information in databases, but existing practices are expensive and present a potential for inaccurate and fraudulent data representations of a company's financial interactions/workflows with transaction counterparties. Consequently, there also exists a need to create a cost-effective disintermediation solution that also captures and records transaction data in an immutable and secure manner.

BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 shows an example of the process flow using an embodiment of the invention. FIG. 2 shows an example of the process flow using an additional embodiment of the invention.

FIG. 3 shows a flowchart of an aspect of the invention of the invented method describing the role of the device of the supplier party in a transaction. FIG. 4 shows a flowchart of an aspect of the invention of the invented method describing the role of the device of the buyer party in a transaction.

FIG. 5 shows a flowchart of an aspect of the invention of the invented method describing the role of the device of the financer party in a transaction.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The following is a detailed description of the preferred embodiments. Reference is made to the accompanying drawings that form a part hereof, and in which are shown by way of illustration, specific embodiments in which the invention may be practiced. It is understood that other embodiments may be utilized and structural changes may be made without departing from the scope of the present invention. The present invention may be practiced according to the claims without some or all of these specific details. For the purpose of clarity, technical material that is known in the technical fields related to the invention has not been described in detail so that the present invention is not unnecessarily obscured.

Reference throughout this specification to "one embodiment" or "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, the appearances of the phrases "in one embodiment" or "in an embodiment" in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. Although the technology will be described in conjunction with various embodiment(s), it will be understood that they are not intended to limit the present technology to these embodiments. To the contrary, the present technology is intended to cover alternatives, modifications and equivalents which may be included within the spirit and scope of the various embodiments as defined by the appended claims.

In the following description of embodiments, numerous specific details are set forth in order to provide a thorough understanding of the present technology. However, the present technology may be practiced without these specific details. In other instances, well known methods, procedures, components, and circuits have not been described in detail so as not to unnecessarily obscure aspects of the present embodiments.

DEFINITIONS

The term "asset" refers to any type of currency, futures contract, bond, stock, derivative, assurance/insurance contract and other financial instruments (including a business-to- business invoice and business-to-consumer bill. The term "ledger" refers to a principal book or computer file for recording transactions.

The term "blockchain" refers to a public ledger that records peer to peer digital transactions such as Bitcoin transactions.

The term "public blockchain" refers to a blockchain, in which no restrictions on reading blockchain data (which still may be encrypted) and submitting transactions for inclusion into the blockchain.

The term "private blockchain" refers to a blockchain, in which direct access to blockchain data and submitting transactions is limited to a predefined list of entities.

The term "smart contracts" refers to digital entities that define complex transaction logic and facilitate cross-organizational workflow including, but not limited to, storage of data, data access permissions, ordered workflow and computation.

The term "public key" refers to a cryptographic key used with a public key cryptographic algorithm that is uniquely associated with an entity and that may be made public. The term "private key" refers to a cryptographic key, used with a public key cryptographic algorithm that is uniquely associated with an entity and is not made public.

The term "multisignature" (multisig) refers to a digital signature scheme that allows a group of users to sign a single document. The term "fiat currency" refers to a currency which is created by "fiat" or "arbitrary" order or decree of the government. Examples of fiat currencies include, but are not limited to: the US dollar, the euro, the Great Britain pound, the Japanese Yen, etc.

The term "device", "terminal", "computer terminal", a "server", interchangeably refers to, but is not limited to hardware such as: a mobile phone, laptop, tablet, wearable computing device, cellular communicating device, PDA, communication device, personal computer, and etc.

THE INVENTION

The present invention utilizes blockchain smart contracts technology to manage cross- organization workflow in a novel way. For example, a smart contract invoice, as well as associated payments, may be tracked on a private blockchain, and those smart contracts may be automatically settled with corresponding payments. The smart contract reflects the payment required from the buyer for settlement with the seller. If the buyer wishes to defer payment, he may approve future settlement for such smart contract, as a result allowing the seller of the (approved) smart contract invoice to offer it for financing. If offered for financing, a financier may offer to purchase the smart contract invoice immediately from the seller with the understanding that the buyer may settle the smart contract with the financier instead of the seller at a later date. A reliable, immutable, shared record of transaction activity may be recorded on the distributed ledger so that an accurate view of the smart contract's transaction activity may be tracked. In such embodiment, the smart contract's transaction activity is recorded on the blockchain and distributed to all blockchain nodes. Any participant in the blockchain network may create their own instance of a smart contract invoice. Select data items in the smart contract may be encrypted and only visible to intended recipients through a read and write key permissions process. The blockchain event system is used to notify relevant parties of new blockchain transactions which may be of interest. The invention also supports a multi-sig feature on the blockchain which requires multiple signatures associated with an individual or signatures from multiple signatories within an organization in order to interact with the blockchain. Trading of financial securities such as stocks, bonds, futures, derivatives, etc. can also be transacted using the present invention.

SETTLEMENT / RECONCILIATION

The present invention represents a shared workflow for creating, selling/buying and settling a payment request using a blockchain smart contract. Each organization participating in the transaction workflow of a particular smart contract, uses its blockchain account (public/private key pair) to sign the creation, approval, sale/purchase and settlement of the smart contract, as appropriate. Sharing these signed activities on a distributed ledger enables automatic settlement of a smart contract payment request. In the case of invoices, the invoice is issued, approved, sold/bought, financed and/or eventually auto-reconciled or settled automatically, with each step recorded and shared.

TAGGING OF PAYMENT DESTINATION ACCOUNT

The present invention tags smart contract invoices with the payment receiving party's payment details. Each organization account is represented by a blockchain smart contract. Bank details are privately encrypted, and only made available at the time of payment execution to the relevant party. The solution restricts the payment destination to the one referenced in the smart contract (ie. the smart contract owner's organization account). This is enforced both at the application level as well as the smart contract level. For example, when settling a smart contract invoice, a buyer can only select the method of payment and the account from which to pay. The system will then recall the buyer's pre- stored bank details from the organization smart contract and collate that payment with the seller's bank details (from that organization's smart contract) and submit these two pieces of information, along with other pertinent payment details, to the relevant payment executing party. Depending on customer, as well as payment executing party, system design, submission of payment instructions may, alternatively, be sent via the blockchain to the relevant payment executing party. Tagging smart contracts eliminates the need for the payer to enter the receiving party's bank details, when paying an invoice. Not only does this automation make the transaction process more seamless/efficient, but it is very useful for preventing loss of revenues due to erroneous and fraudulent payment details entered by employees.

AUTOMATED CHANGE OF SMART CONTRACT PERMISSION RIGHTS

Each party involved in cross-organization workflow will be associated with a blockchain account. For example, in an invoice use case, each party— supplier, buyer, financier— has a blockchain account/key. The key is used to represent each party on the blockchain. With the present invention, the owner of the smart contract invoice is represented by a blockchain key and that key/account is indicated as a data field in the smart contract. Only the owner of the smart contract invoice can change the payment terms and only the owner of the smart contract invoice can receive payment for settlement of it. For example, the smart contract invoice is initially owned by the supplier, but later can be purchased by the financier. Payment confirmation from the financier's bank automatically triggers a permission/ownership change so that now only the financier can change the payment terms with the buyer and the buyer must provide payment confirmation to the financier to settle the smart contract invoice.

NETTED BATCH SETTLEMENT

A buyer may mark an invoice as 'Agreed' if all details are correct, 'Pay Immediately' or mark as 'Ready for Batch Payment'. Invoices can be paid either individually, or as a batch. If they are paid as a batch, the total amount outstanding between two parties based on outstanding invoices (sent/received by either party) for each currency/account pair is calculated off chain (by both parties) using on chain data, stored on chain, paid off chain, and recorded against the individual invoices on-chain. UNIVERSAL BATCH WINDOW

A batch settlement point is configured in the private blockchain network. This is a universally agreed point in time (e.g. midnight every night) when each 24 hour batch window starts/ends. A timer triggers each blockchain node to initiate a batch settlement process. At that point, all of the receivable and payable invoices that were previously marked 'Ready for Batch Payment' are retrieved from the blockchain. The invoices, already grouped by counterparties in a mapping smart contract, are totalled and netted by the application off chain (e.g. if two companies exchange invoices, and sell and buy from each other, then the total net outstanding amount is calculated). The result of the calculation is stored in a new entry in a settlement smart contract. The settlement smart contract holds the batch net settlement amount between every two counterparties, based on the off chain calculations.

BI LATERAL MACHINE-TO-MACHINE CALCULATION VALIDATION

Off-chain calculations must be validated bi-laterally. These calculations are not performed inside the smart contract, due to that fact that the data stored inside the smart contract is encrypted for privacy reasons. The blockchain therefore has no access to this data, and the smart contract can therefore not perform the batch/netting calculations on chain. The numerical data must therefore be extracted and calculation must take place off chain. Because the calculation occurs off chain, and is not visible within the blockchain, it could be open to abuse/fraud. For this reason, this invention proposes a bi-lateral machine to machine validation process, whereby:

1. The calculation is performed by one of the two parties involved in the transaction.

2. The result of the calculation is stored in the smart contract using a blockchain transaction.

3. The blockchain instance/node held by the counterparty receives notification of the calculation (in the form of a blockchain event) and automatically performs it's own calculation and verifies that the result matches the one provided by the first (this can be automated machine-to-machine validation - no manual intervention required). 4. If there is a match, then the match is recorded in the smart contract.

5. At this point, the result has been calculated separately by both parties and

matched, and can therefore be used for further activity (e.g. trigger a payment).

After bi lateral machine-to-machine calculation validation is complete:

1. A new payment for the netted outstanding amount is sent, via a blockchain smart contract, to the bank / payment gateway (using a blockchain event).

2. The bank / payment gateway retrieve the payment instruction from the blockchain smart contract, process the fiat currency payment off-chain, and update the smart contract that the payment is sent (by sending a transaction to the blockchain smart contract).

PROOF OF FIAT CURRENCY PAYMENT

Payment is made using fiat currency, and is therefore off-chain. Proof of payment, includes, but is not restricted to: proof of executing party identity, proof of payment source, payment destination and payment amount. Such information should also be provided by the payment executing party, recorded on-chain, and where possible validated on-chain by the smart contract. Two options are described in this design:

1. The Application hosted by the paying party is connected to both the blockchain network and the PSP / Bank. This Application receives the payment instruction from the blockchain smart contract, and calls the PSP / Bank via their API (real time or batch). A confirmation is provided by the PSP / Bank and persisted in the smart contract on the blockchain as a proof of payment. In order to provide a stronger proof of authenticity, the PSP / Bank API will include a response (or data items in the response) signed by the PSP / Bank, including details of the recipient bank account and payment amount, so that these can be stored in the smart contract on the blockchain and validated at a later date, either by the logic encapsulated in the smart contract or by logic implemented off-chain. It must also be possible to validate that the payment confirmation originated from the PSP / Bank and that the payment was executed as specified by the smart contract. This is achieved by storing and validating the PSP / Bank server certificate and signed response.

2. The PSP / Bank is a blockchain participant with its own account (public/private key pair) on the blockchain. In this case, proof of fiat currency payment is received from the PSP / Bank which uses its blockchain account / key. The fiat currency payment is executed by the PSP / Bank and payment confirmation is entered into the smart contract on the blockchain directly by the PSP / Bank using their blockchain account. As with any data entered into the smart contract, this proof of fiat payment is entered into the blockchain through a transaction call to the smart contract. The proof of payment stored in the smart contract by the PSP /

Bank must allow traceability to the fiat currency transaction as recorded in the PSP / Bank's own record system.

RECORDING FIAT CURRENCY PAYMENT IN TWO STAGES

Fiat current settlement is recorded in two stages. The smart contract holds the payment instructions (batch or single invoice). These are retrieved by the bank / payment provider and marked as 'Sent' in the smart contract (by sending a transaction to the blockchain). Once payment confirmation is available off-chain, the bank / payment provider updates the status to 'Paid' in the smart contract (by sending a transaction to the blockchain). For a batch payment, when the payment is 'Sent' or 'Paid', all invoices associated with that batch payment are updated.

CRYPTO-CURRENCY / TOKEN PAYMENT

The (invoice) smart contract stores the amount owed by one party to another. An alternative to settling payment using fiat currency, is to use a blockchain token (native or in a smart contract). Each party would buy are sell tokens at an exchange, and settle the obligation in the smart contract using the tokens. In this case the payment and change of ownership within the blockchain is executed and recorded in a single step. ASSET LOCKING DURING PAYMENT

When an asset (e.g. invoice) is purchased, the asset ownership field in the smart contract is locked, so that it cannot be modified, until the payment for purchase of the asset has been completed and confirmed (or cancelled) by the bank / payment processor in the smart contract.

When the off-chain payment is confirmed by the payment processor / bank in the blockchain smart contract, the asset ownership is transferred simultaneously in the smart contract within the same blockchain transaction. TWO STAGE TRANSACTIONS IN SMART CONTRACTS

Data stored inside a smart contract is not currently protected from double spend. In other words, it is theoretically possible for two nodes to submit two transactions within the same block changing the same item of data, but in a different order, leading to different results. This design overcomes this limitation by performing a change on previously committed data only (agreed through consensus), then locking the data until the next block. If another transaction in the same block attempts to change the data it will fail. The party initiating each change should therefore check that the change has been accepted by the consensus mechanism, and if not, resubmit the change as a transaction in the next block.

NON-SMART CONTRACT IMPLEMENTATION

The design could be implemented in a blockchain that does not support smart contracts. In this case, replace the term smart contract with a data entry in the ledger. Permission logic managed by the smart contract will then be enforced through encryption of the data off-chain, and change flags/tokens only visible to those parties that are permitted to make a specific change. BLOCKCHAIN IN A BOX

Installing the blockchain within large organisations, as proposed in this design, exposes an organization to a peer to peer network, which may, in theory, pose a security threat. To mitigate against this threat, one option is to host the blockchain software and database in a dedicated hardware container, where only the minimal required access points are exposed by the physical hardware solution and the on-board firmware.

FIGURES

Referring now generally to the figures and particularly to FIG.l. FIG.l shows an example of the process flow using an embodiment of the invention. The use case is related to invoice settlement and payment flow between Supplier A and Buyer B, where no Financier is involved. The following steps are performed:

1. Supplier A: Creating a Smart Contract Invoice (1.0)

1.1 Supplier A enters details of a new invoice into its ERP system.

1.2 Supplier A's ERP system notifies application A (1.2).

1.3 Application A creates a smart contract invoice on the blockchain (1.4), assigning Buyer B's account/public key as the invoice recipient.

1.4 As a result of the blockchain synchronization mechanism (1.6), the blockchain distributes the new representative smart contract (in this case, the new smart contract invoice) among all the blockchain nodes.

2. Buyer B: Paying and Reconciling a Smart Contract Invoice (1.10)

2.1 As a result of the blockchain event mechanism application B receives a smart contract event and retrieves smart contract invoice data (1.8).

2.2 Buyer B pays the invoice to Supplier A using application B. Two design options are available for payment, depending those offered by Buyer B's PSP or Bank. Either Application B sends payment instructions to Buyer's B payment gateway or bank, or Application B writes payment instructions on the blockchain for Buyer B's payment gateway or bank to collect, execute (outside of the blockchain), confirm and sign using its blockchain account. 2.3 After application B receives payment confirmation from the payment gateway or bank, it reconciles the payment against the smart contract invoice and updates Buyer B's ERP system indicating the invoice as paid (1.12).

2.4 Application B records the invoice payment confirmation details, including a certificate and signed transaction if required (proof that the payment was made by said payment facility), to the blockchain smart contract (1.14). The blockchain distributes the new transaction among all the blockchain nodes.

3. Supplier A: Receiving a Smart Contract Invoice Settlement Confirmation 3.1 As a result of the blockchain event mechanism (1.16), Supplier A's blockchain node receives the new transaction and generates an event.

3.2 Application A receives the event and updates Supplier A's ERP systems.

Referring now generally to the figures and particularly to FIG.2. FIG.2 shows an example of the process flow using an additional embodiment of the invention. The buyer wishes to defer settlement for the smart contract invoice and so the smart contract is offered for financing. The use case is related to invoice settlement, financing and payment flow between Supplier A, Buyer B and Financier C (in this embodiment, a financier (or financial entity) is involved). The following steps are performed:

1. Supplier A: Creating a Smart Contract Invoice (2.2)

1.1. Supplier A enters details of a new invoice into its ERP system.

1.2. Supplier A's ERP system notifies application A.

1.3. Application A creates a smart contract invoice on the blockchain assigning Buyer B's account/ public key as the invoice recipient. 2. Buyer B: Approving a Smart Contract Invoice

2.1 As a result of the blockchain synchronization mechanism, the blockchain distributes the new representative smart contract (in this case, the new smart contract invoice) among all the blockchain nodes. In turn, the blockchain event mechanism, application B receives smart contract event and retrieves smart contract containing the invoice and updates Buyer B's ERP system with invoice details (2.4). 2.3 Buyer B decides to defer settlement and so, approves the smart contract invoice. Buyer B's action is sent by application B as a transaction to the smart contract invoice (2.6). As a result of the blockchain synchronization mechanism, the blockchain distributes the new transaction among all the blockchain nodes. Supplier A: Offering a Smart Contract Invoice (2.8)

3.1 As a result of the blockchain event mechanism, application A receives an event from the blockchain. Company A decides to offer the smart contract for sale. Supplier A's intention is sent by application A as a transaction to the blockchain smart contract.

3.2 As a result of the blockchain synchronization mechanism, the blockchain distributes the new transaction among all the blockchain nodes. Financier C: Financing a Smart Contract Invoice (2.10)

4.1 Financiers receive notification from the blockchain that a new smart contract invoice is for sell.

4.2 Financer C makes an offer to purchase the invoice and application C enters the offer details in the user interface. Financier C's offer is sent by application C as a transaction to the blockchain. The blockchain distributes the new transaction among all the blockchain nodes. Supplier A: Selling a Smart Contract Invoice (2.12)

5.1 Supplier A's blockchain receives the transaction and generates an event. Application A receives the event and updates A's ERP with the offer.

5.2 Supplier A approves sale of the smart contract. Supplier A's decision is sent by application A as a transaction to the blockchain and the blockchain distributes the new transaction among all the blockchain nodes. Financier C: Buying a Smart Contract Invoice

6.1 Financier C's blockchain receives the transaction and generates an event. Application C receives the event from the blockchain and updates Financiers C's invoice trading platform. Financier C sends payment instructions for the invoice via the invoice trading platform (2.14).

6.2 Financer C's bank makes payment to Supplier A's bank account (2.16).

6.3 Financer C's bank sends payment confirmation to application C (2.18).

6.4. Payment confirmation details, including a certificate and signed transaction if required, as well as a change of ownership for the smart contract invoice are sent by application C as a transaction to the blockchain. The blockchain distributes the new transaction among all the blockchain nodes (2.20).

7. Buyer B: Pay Invoice

7.1 Buyer B settles the smart contract invoice with Financier C using application B (2.24)

7.2 Application B sends payment instructions, either directly or via the blockchain, to the payment gateway or bank. (2.26).

7.3 Application B receives confirmation from Buyer B's bank (2.28).

7.4 Application B matches the payment confirmation with the invoice to issue an invoice settlement confirmation. The blockchain distributes the new transaction among all other nodes. (2.30)

8. Financier C : Receive Settlement Confirmation

8.1 Financier C's blockchain receives the invoice settlement confirmation transaction and generates an event (2.30).

8.2 Application C receives an event from the blockchain and updates Financier C's invoice trading platform/user interface.

Referring now generally to the figures and particularly to FIG.3. FIG.3 is a flowchart of an aspect of the invention of the invented method describing the role of the Supplier's device for financing. In any instance where an invoice is entered into a Supplier's ERP system, the device receives a notification per step 3.2. It then creates a new instance of a smart contract invoice (3.4), indicating its ownership, and sends the transaction through the blockchain mechanism, as per step 3.6, among all the blockchain nodes and waits for the appropriate buyer feedback as per step 3.8.

If the Buyer wishes to settle the smart contract invoice, the Supplier will receive, through the blockchain mechanism, a settlement confirmation event which will also update its internal systems (3.14).

If the Buyer wishes to defer the payment, the Supplier will receive, through the blockchain mechanism, an approval of the smart contract invoice. In turn, the Supplier can create an offer to sell the smart contract (3.16) and send the transaction as per step 3.18 among all the blockchain nodes and wait for a financier offer as per step 3.20.

If the Supplier receives an offer from a Financier, the Supplier's ERP system will be updated as per step 3.22. The Supplier must then approve the sale as per step 3.24 which will send the transaction as per step 3.26 among all the blockchain nodes.

Referring now generally to the figures and particularly to FIG.4. FIG.4 is a flowchart of an aspect of the invention describing the role of the Buyer's device.

For any smart contract invoice received through the blockchain mechanism that the Buyer decides to settle immediately, he will select the account from which to settle the invoice and click PAY. The device will then route payment instructions as appropriate as per step 4.8. For any smart contract invoice received through the blockchain mechanism that the Buyer decides to defer settlement, he will issue an approval of the smart contract through the device as per step 4.10 and send the transaction as per step 4.12 among all the blockchain nodes.

For any smart contract invoice received through the blockchain mechanism that the Buyer previously deferred to settle, was subsequently financed (where the payment tag was changed to that of the Financier after payment confirmation from the Financier to the Supplier as per step 4.14) and now wishes to settle, he makes the payment to the Financer via the device as per step 4.16. After the Buyer initiates bank transfer payment to the Financier, it then waits for payment confirmation from the bank as per step 4.18. Upon receiving the confirmation, the device matches the payment confirmation to the invoice and issues an invoice settlement confirmation as per step 4.22. The device then sends the confirmation transaction as per step 4.12 among all the blockchain nodes. Referring now generally to the figures and particularly to FIG.5. FIG.5 is a flowchart of an aspect of the invention describing the role of the Financier's device

The Financier's device receives a notification from the blockchain that a new smart contract is for sale as per step 5.2. If the smart contract offer from the Supplier is of interest, the Financier makes an offer as per step 5.6 and sends the transaction as per step 5.8 among all the blockchain nodes.

When the Financier's device receives a notification from the blockchain that the sale has been agreed by the Supplier, he schedules payment for the agreed value to the Supplier's bank as per step 5.12 and waits for payment confirmation. (The device automatically knows the recipient payment instructions because all smart contract invoices are tagged.) Upon confirmation from the bank, the device transfers the ownership of the invoice to the Financier and automatically changes the (payment) tag as per step 5.14. The device simultaneously issues a purchase confirmation as per step 5.16 and sends the transaction as per step 5.18 among all the blockchain nodes.

Once the Buyer settles the smart contract, his device issues an invoice settlement confirmation (5.20) which is eventually updated in the Financier's device as per step 5.22.

The present invention uses the above processes for single smart contract sales, purchases and settlements as well as for simultaneous multi-smart contract sales, purchases and settlements. So, the Supplier, Buyer or Financier may select several smart contract invoices and, respectively, click the SELL, BUY or PAY button which will simultaneously offer, purchase and settle several smart contract invoices as per the steps outlined above.

Claims

1. A computer implemented method for automated financial transaction processing and settlement in a network based private blockchain , comprising:

a. creating an instance of a smart contract associated to a first proposed financial transaction in said network based private blockchain wherein a value is required for fulfillment of said first financial transaction [1.0] [2.2] [3.4];

b. associating said first proposed financial transaction with a second proposed financial transaction [[1.10] [2 ; and,

c. receiving a notice that said first financial transaction is fulfilled [1.16]

[2.6][3.14].

2. The method of claim 1 , wherein said value is expressed in fiat currency.

3. The method of claim 2, wherein said smart contract is associated with an invoice smart contract including payment instructions and wherein second proposed financial transaction is associated with invoice payment confirmation of said invoice smart contract. [1.0] [2.2] [3.4] [1.10] [1.16] [2.6]

4. The method of claim 2. wherein said smart contact is associated with an invoice smart contract including payment instructions and wherein second proposed financial transaction is associated with an approval and further comprising:

d. a third proposed financial transaction associated with an offer to sell ; [[2.8] [3.16] e. a fourth proposed financial transaction associated with an approval to sell

[2.10][4.10] [4.12]; and,

f. a fifth proposed financial transaction associated with an invoice reconciliation confirmation [2.30] [4.22].

5. A non-transitory computer-readable medium with instructions stored thereon, that when executed by a processor, performs the steps comprising: a. creating an instance of a smart contract associated to a first proposed financial transaction in said network based private blockchain wherein a value is required for fulfillment of said first financial transaction;

b. associating said first proposed financial transaction with a second proposed financial transaction ; and,

c. receiving a notice that said first financial transaction is fulfilled.

6. The non-transitory computer-readable medium of claim 5, wherein said value is expressed in fiat currency.

7. The non-transitory computer-readable medium of claim 6, wherein said smart contract is associated with an invoice smart contract including payment instructions and wherein second proposed financial transaction is associated with invoice payment confirmation of said invoice smart contract.

8. The non-transitory computer-readable medium of claim 6, wherein said smart contact is associated with an invoice smart contract including payment instructions and wherein second proposed financial transaction is associated with an approval and further comprising:

d. a third proposed financial transaction associated with an offer to sell ;

e. a fourth proposed financial transaction associated with an approval to sell; and, f. a fifth proposed financial transaction associated with an invoice reconciliation confirmation.

9. A computer terminal for automated financial transaction processing and settlement in a network based private blockchain , the terminal comprising:

a processing unit;

b. a communication interface communicatively coupled to the processing unit for transmitting and receiving information;

c. a local private secure cache for storing information ; and,

d. a memory communicatively coupled to the processing unit for storing instructions, wherein the processing unit is configured to:

d.1. create an instance of a smart contract associated to a first proposed financial transaction in said network based private blockchain wherein a value is required for fulfillment of said first financial transaction;

d.2. associate said first proposed financial transaction with a second proposed financial transaction ; and,

d.3. receive a notice that said first financial transaction is fulfilled.

10. The computer terminal of claim 9, wherein said value is expressed in fiat currency.

11. The computer terminal of claim 10, wherein said smart contract is associated with an invoice smart contract including payment instructions and wherein second proposed financial transaction is associated with invoice payment confirmation of said invoice smart contract.

12. The computer terminal of claim 10, wherein said smart contact is associated with an invoice smart contract including payment instructions and wherein second proposed financial transaction is associated with an approval and further comprising:

d. associate a third proposed financial transaction with an offer to sell ;

e. associate a fourth proposed financial transaction with an approval to sell; and, f. associate a fifth proposed financial transaction with an invoice reconciliation confirmation.