WO2021038600A1

WO2021038600A1 - System and method for real time reconciling, auditing transactions in decentralised network with distributed ledger

Info

Publication number: WO2021038600A1
Application number: PCT/IN2020/050758
Authority: WO
Inventors: Subramanya JOIS
Original assignee: Jois Subramanya
Priority date: 2019-08-31
Filing date: 2020-08-31
Publication date: 2021-03-04

Abstract

The present invention is a protocol and platform which supports real-time reconciliation, balance confirmation and audits across multiple stakeholders and their ledgers. The platform is built on Application layer Atomic Multicast protocol, the platform ensures complete transparency and immutability of any transaction, from transaction initiator to the consumer also cutting costs. Further, the platform's Distributed Ledger offers near-Zero-latency with transaction cost while being able to support over very high throughput and scalability, thus breaking all barriers and challenges in scaling, latency and atomicity. Further, the invention can reduce and eliminate the risk of human error and fraud. The invention is an end-to-end quantum secure, thus eliminating any possibility of breaching data.

Description

1. TITLE OF THE INVENTION: SYSTEM AND METHOD FOR REAL TIME RECONCILING, AUDITING TRANSACTIONS IN DECENTRALISED NETWORK WITH DISTRIBUTED LEDGER

2. APPLICANT: a) Name: SUBRAMANYA R JOIS b) Nationality: INDIAN c) Address: 19, Singapore Gardens, Gubalala Cross, Kanakapura Road, Bangalore 560062 India

3. PREAMBLE OF THE DESCRIPTION: The following complete specification particularly describes the invention and the manner in which it is performed. FIELD OF THE INVENTION

The invention generally relates to computerized systems and methods for securing data, and more particularly, and without limitation, computerized systems and methods that generate secured decentralized ledger structures of real-time reconciliation and audit in financial transactions of a value chain and similar applications in Track-and-trace, Edge Computing and Decentralized Identity.

BACKGROUND OF THE INVENTION

In any business transaction, there are at least two parties involved. The First party is considered the sender of the transaction and the secondary party is considered the receiver. When a transaction is conducted between the two, the First party sends, say, an invoice to the second party. The First party makes an entry in his books of accounts as a “Debit” of the said amount of the invoice while the second party makes the corresponding entry as a “Credit” for the same amount. When the Second party makes a payment to the first party towards the same invoice, it is recorded as a “Debit” in the second party; ’s books of accounts while the First Party will record it a “Credit” agains the said invoice. Both the parties reconcile the the two transactions to achieve “Zero Balance” in both ledgers, which implies that both parties have reconciled their books of accounts.

Previously, in order to obtain account balances from both the ledgers in a double-entry recordkeeping (i.e., bookkeeping) system, it was necessary to manually enter accountable transactions in two or more journals, manually post the accountable transactions to corresponding accounts in the general and subsidiary ledgers of the system and sometimes post the transaction to a “Suspense Account’ as a “Holding account” till it is reconcilied, and then manually balance the accounts in the ledgers when transactions are conducted between two parties. The Same is repeated in the second party’s books of accounts to match transactions across organizations to manage payables and receivables in business.

Since the 1500s, accounting and bookkeeping have followed the practice of Double entry Bookkeeping. It implies that every entry to an account in the books of accounts of the first party requires a corresponding and opposite entry to a different account in the second party’s books of accounts. The double-entry has two equal and corresponding sides known as debit and credit. The left-hand side is debit while the right-hand side is credit. For instance, recording a sale of $100 might require two entries: a debit of $100 to an account named "Cash" in the first party’s books of accounts and a credit of $100 to an account named "Revenue." [Assets = Equities + Liabilities] in the second party’s books of accounts. The accounting equation is an error detection tool; if at any point the sum of debits for all accounts does not equal the corresponding sum of credits for all accounts, an error has occurred. However, satisfying the equation does not guarantee that there are no errors; the ledger may still "balance" even if the wrong ledger accounts have been debited or credited.

An example of double-entry bookkeeping where two companies, namely A and B, initiate a transaction. Initially, company A raises an invoice on company B. The transaction would then be registered on both the parties’ ledgers. Company A’s ledger records the amount specified in the invoice is ‘receivable from company B’ or a Debit Transaction. Company B’s ledger would indicate the invoice is to be ‘payable to company A’ or a “Credit Transaction”. Once company B makes the payment to A, the transaction details would reflect in company B’s ledger as ‘amount paid (say, by cheque) to A’ or a “Debit”. The amount will reflect in A’s ledger as ‘amount received from B’ or a “Credit”. In an example, as shown in figure 1, companies A and B represents a pair of transactions and the same reconciled. Typically, such reconciliations are carried out at the end of each working day to ensure that account books are “balanced”. This includes both legs of all transactions that are identified across all parties and reconciled, which enables them to identify outstanding receivables and payables. The situation may vary if the transactions were made over a period of time or if there were errors in the entries that prevented reconciliation or if the payment was through a third party, such as a bank. This leads to the transaction reconciliation to have a pending status or being posted to “Suspense Accounts” as it is called in Accounting practices.

The current practice involves conducting financial audits to identify pending transactions along with verifiable evidence of the transaction such as invoices, signed vouchers, receipts or bank transactions that may be used to resolve pending or erroneous transactions held in “Suspense Accounts”. The Audit exercise is time- consuming and tedious and may have human errors.

Thus, there is a need for a real-time method and system for reconciliation and audits across multiple ledgers for a transaction [sale of goods or payment by way of an invoice] to address the above mentioned limitation of the existing arts.

SUMMARY OF THE INVENTION

An aspect of the present invention is to address at least the above-mentioned problems and/or disadvantages and to provide at least the advantages described below.

The following presents a simplified summary of one or more embodiments of the present invention, in order to provide a basic understanding of such embodiments. This summary is not an extensive overview of all contemplated embodiments, and is intended to neither identify key or critical elements of all embodiments nor delineate the scope of any or all embodiments. Its sole purpose is to present some concepts of one or more embodiments of the present invention in a simplified form as a prelude to the more detailed description that is presented later.

Accordingly, in one aspect of the present invention provides a platform for reconciliation and audits across multiple ledgers for a transaction between a first party and a second party. In one embodiment, the platform has at least one first party and at least one second party, at least one neutral third-party elected by the network of nodes and at least to other follower nodes participating as witnesses to transactions. The first party and the second party sends a copy of the transaction to the neutral third party which acts as a notary to match the transaction and respond back to the first party and the second party with notarized receipts, thereby validating the transaction and ensuring its non-repudiation and immutability with a record of the notarization with notary. The entries occur in the form of a transfer between individual ledgers of the two parties which reflect in the same distributed public ledger with an encrypted copy in the notary’s ledger, thereby creating an interlocking system of enduring accounting records, and wherein the entries which are distributed and cryptographically sealed, their immutability, non-repudiation and transparency were assumed to be assured.

In another aspect of the present invention provides a real-time method for reconciliation and audits across multiple ledgers across multiple nodes for a transaction of sale of goods by way of an invoice between a first party and a second party and to third and fourth parties, further on, over a platform. The method includes election of a notary by network of nodes, recordation of entry of a sale and corresponding purchase in a ledger of books of accounts of the first party and the second party, requesting the second party and the notary to obtain public key by the first party before initiating the transaction, recordal of the invoice sent to second party along with the information on the goods sold, where the invoice is digitally signed by the first party with the public key of the second party to ensure that only second party to access the enclosed invoice with its private key, requesting the Notary to obtain the Public Key by the second party before initiating the transaction, sending a digitally signed Hash of the invoice to the notary by the first party and the second party using homomorphic encryption digitally signing the Hash with their respective Private Keys and the Notary’s Public Key, accessing the encrypted hash from both the parties with its private key and then employs homomorphic encryption to match transaction data without getting access to the transaction, posting the encrypted hash of the message out by the notary by matching the transaction data to the network for consensus to all follower nodes, where the Follower Nodes will respond back to the Notary with an acknowledgement as votes and posting the transaction trail to the ledger along with all the voters, if the votes exceed the Consensus threshold set for the term. Further, the second party may then transfer the transaction to one or more third parties, further on, down a value chain.

In yet another aspect of the present invention provides a real-time method for reconciliation and audits across multiple ledgers across multiple nodes for a payment of an invoice for transaction of sale of goods between a first party and a second party and to third and fourth parties, further on, over a platform. The method includes election of a notary by network of nodes, recordation of closure of a sale in a ledger of books of accounts of the first party and the second party, where the second party will make an entry in its books of accounts recording a credit towards the first party for the said amount of the Invoice thus reconciling the second party’s ledger, and the first party will make a corresponding entry in its ledger or books of account recording the payment receipt in its receivables as a credit from second party and thus reconciling the first party’s ledger, requesting the first party and the notary to obtain public key by the second party before initiating the transaction, recordal of the payment sent to first party along with the information with the corresponding invoice, where the invoice is digitally signed by the second party with the public key of the first party to ensure that only first party to access the enclosed payment and invoice details with its private key, requesting the Notary to obtain the Public Key by the first party before initiating the transaction, sending a digitally signed Hash of the payment and invoice to the notary by the first party and the second party using homomorphic encryption digitally signing the Hash with their respective Private Keys and the Notary’s Public Key, accessing the encrypted hash from both the parties with its private key and then employs homomorphic encryption to match transaction data without getting access to the transaction, posting the encrypted hash of the message out by the notary by matching the transaction data to the network for consensus to all follower nodes, where the follower Nodes will respond back to the Notary with an acknowledgement as votes, and posting the transaction trail to the ledger along with all the voters, if the votes exceed the consensus threshold set for the term. Further, the second party may then transfer the transaction to one or more third parties, further on, down a value chain.

Other aspects, advantages, and salient features of the invention will become apparent to those skilled in the art from the following detailed description, which, taken in conjunction with the annexed drawings, discloses exemplary embodiments of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

The above and other aspects, features, and advantages of certain exemplary embodiments of the present invention will be more apparent from the following description taken in conjunction with the accompanying drawings in which:

FIG. 1 shows a double entry bookkeeping between two parties as a prior art.

FIG. 2 shows a Triple Entry bookkeeping between two parties.

FIG. 3 shows a Triple Entry accounting between two parties using DLT according to one embodiment of the present invention. FIG. 4 shows a flow chart depicting example operations of a real-time method for reconciliation and audits across multiple ledgers for a transaction of sale of goods by way of an invoice between a first party and a second party over a platform, according to one embodiment of the present invention.

FIG. 5 shows a flow chart depicting example operations of a real-time method for reconciliation and audits across multiple ledgers for a payment of an invoice for transaction of sale of goods between a first party and a second party over a platform, according to one embodiment of the present invention.

FIG. 6 shows the flow sequence diagram according to some embodiment of the present invention.

FIG. 7 is a block diagram of a machine in the example form of a computer system within which instructions for causing the machine to perform any one or more of the operations or methodologies discussed herein may be executed.

Persons skilled in the art will appreciate that elements in the figures are illustrated for simplicity and clarity and may have not been drawn to scale. For example, the dimensions of some of the elements in the figure may be exaggerated relative to other elements to help to improve understanding of various exemplary embodiments of the present disclosure.

Throughout the drawings, it should be noted that like reference numbers are used to depict the same or similar elements, features, and structures.

DETAILED DESCRIPTION OF THE INVENTION

Embodiments of the invention will now be described more fully hereinafter with reference to the accompanying drawings, in which some, but not all, embodiments of the invention are shown. Indeed, the invention may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will satisfy applicable legal requirements. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of one or more embodiments. It may be evident; however, that such embodiment(s) may be practiced without these specific details. Like numbers refer to like elements throughout.

DEFINITIONS:

In one embodiment of the invention, the network includes all forms of networking systems and protocols including satellite systems. Internet includes but is not limited to intranets, local area networks and wide area networks. Computers include but are not limited to personal computers, stand-alone computers, tower computers, servers, desktop computers, laptop computers, notebook computers, personal digital assistants, work-stations, main frames, minicomputers, supercomputers and wearable computers. Computer can also be a special purpose computer programmed to perform algorithms. Wireless device includes but is not limited to cell phones, personal digital assistants, wireless Internet cards, wireless modems, wearable computers, IoT devices and smart cards. Databases include but are not limited to relational databases, object databases, NOSQL, Graph databases and post-relational databases. According to one embodiment of the invention, a computer and a database can be coupled together via a mobile, wireless, Bluetooth or any other protocol-based network or Ethernet connection that can be placed in a location such as but not limited to a government facility, a private company facility, a clinic, a vehicle or the like. The invention is not limited to a number of computers or wireless devices. Any number of computers or wired/wireless devices that can be connected to a network, such as a wired/wireless network or the Internet, or any other network, may be used.

The device may be configured to either transmit (immediately or upon a timed or signaled delay at the end of specific events or time periods) or store sensed data relating to at least one message or parameter. The sensed data may be stored in an erasable memory on the device itself, the device itself may have or be in communication with a data storage device (e.g., flash drive, disk, hard drive, tape, and the like) which can then be downloaded onto a portable memory device, and can be transmitted to or carried to the computer/processor which is a core element in the operation of this system.

A communication network is configured to receive and transmit the sensed data relating to at least message, transaction or parameter either by hardwired or wireless communication with the sensor or physical receipt of a memory storage device containing the stored data. The communication network may be a wireless system directly or indirectly from the memory associated with and receiving sensed data from the device and may include a port into which permanent memory may be transmitted or a temporary memory device (e.g., flash drive) may be inserted (e.g., a USB port) to transfer from the memory device or the original sensed data source to the computer/processor.

A processor may be in communication with the communication network and configured to receive and store in memory transmitted sensed data relating to message or parameter. The data may be received and stored as raw data or raw signals and converted by software into actual values that may be displayed, printed and read by a user. Alternatively, the sensor may itself be capable of transmitting the data as readable, displayable and printable information by having a microprocessor or analog - to-digital converting component (e.g., filed programmable gated array - FPGA, or application specific integrated circuit - ASIC) in the sensor or between the sensor and the computer. The processor is configured to compare the transmitted sensed data relating to the message or parameter to a reference table stored in memory, the table indicating ranges of normal, borderline and abnormal values with respect to the transmitted sensed data. The reference tables can be standard tables available in a generically programmed computer for the system, and/or may be a reference table or tables configured for specific users or for specific category of users.

The processor may have at least one response in memory for providing at least one corrective response to at least one abnormal value of the transmitted sensed data relating to at least one parameter. The responses can include direct changes in a particular status or a message generated through a sensor or a manually entered.

The parameters that are detected by the device can be processed and/or displayed immediately to the users, or to the local computer, and alerts displayed when required The information can also be wirelessly transmitted to the user’s smart phone or computer, or the smart phone or computer of the other stake holders, for storage or analysis, or transferred from a port on the monitoring module device to a flash drive or other storage medium. In a particularly preferred embodiment of the invention, a smart phone is used as a gateway to relay data to a remote database via the mobile network, which provide real-time analytics that enable wireless communications among mobile users in an easy, secure and efficient manner. In another preferred embodiment of the invention, the device software provides the user with an easy-to-use graphical user interface on their smart phone that uses the standard navigation buttons on mobile devices. The information can also be electronically transmitted to the network in which the user is registered. NODE

A computer or computing device such as a mobile, server, wearable device, smart phones, smart watches and similar smart devices, IoT devices in use in smart city, smart home and Industry 4.0+ applications which can communicate over wired or wireless medium with other computers while having computational and storage facilities. These devices belong to a cluster of devices, also known as “Channel” and conduct their communications and transactions within the channel. A node can include a keyboard, a mouse, retinal response system, voice response system or sensor as a input or output device interface.

The compute device or node has a processor, a memory, storage device and may have a display, which can be structurally and/or functionally like the processor, the memory, the storage device and the display, respectively. Also, distributed ledger instance can be structurally and/or functionally like distributed database instance. The term “compute device” is used to generically encompass computers, processors, microprocessors, logic devices, field programmable gated arrays, application specific integrated circuits and the like. They can be on mainframe, desktop, laptop, handheld or other devices. A node is any compute device having enough functional capability to at least temporarily store and execute an accessing software so that data can be entered into the DLT system through user input controls (e.g., external sensors, IoT devices, digital camera, keyboard, touchscreen, voice entry, etc.). These may be, as further indicated herein, handheld devices (smart phones, tablet devices), tabletop devices (PC or Mac or other systems) and mainframes for central control and establishment of the internet connections. No single component need have the capability of storing all DLT data and information as it is distributed, but such a back-up node or compute device, without open access through the internet, may be used. The compute device has a processor, a memory, and a display, which can be structurally and/or functionally like the processor, the memory, the storage and the display, respectively. Also, distributed database instance can be structurally and/or functionally like distributed database instance. The compute device has a processor, a memory, and a display, which can be structurally and/or functionally like the processor, the memory, and the display, respectively. Also, distributed database instance can be structurally and/or functionally like distributed database instance.

Even though compute devices may be like each other, each compute device of the distributed database system can be different from the other compute devices. Each compute device of the distributed database system can be any one of, for example, a computing entity (e.g., a personal computing device such as a desktop computer, a laptop computer, etc.), a mobile phone, a personal digital assistant (PDA), an IoT device, a electronic sensor with a compute and so forth. For example, compute device can be a desktop computer, compute device can be a smartphone, and compute device can be a server.

A candidate node (one of numerous active nodes that is automatically acting in a communicating capacity within the network), from among the active nodes that communicates into the system and is selected upon a contemporary time-available basis to become a leader node in a channel for multiple peer-to-peer, node-to-node transaction, outputting a pulse into the network to obtain validation by a confirmation level of majority of the nodes, and being identified as the leader node for multiple peer-to-peer transaction.

BLOCKCHAIN

A blockchain, originally block chain, is a growing list of records, called blocks, which are linked using cryptography. Each block contains a cryptographic hash of the previous block, a timestamp, and transaction data (generally represented as a Merkle tree).

By design, a blockchain is resistant to modification of the data. It is "an open, distributed ledger that can record transactions between two parties efficiently and in a verifiable and permanent way”. For use as a distributed ledger, a blockchain is typically managed by a peer-to-peer network collectively adhering to a protocol for inter-node communication and validating new blocks. Once recorded, the data in any given block cannot be altered retroactively without alteration of all subsequent blocks, which requires consensus of the network majority. Although blockchain records are not unalterable, blockchains may be considered secure by design and exemplify a distributed computing system with high Byzantine fault tolerance. Decentralized consensus has therefore been claimed with a blockchain.

DISTRIBUTED LEDGER TECHNOLOGY (DLT)

A distributed ledger (also called a shared ledger or distributed ledger technology or DLT) is a consensus of replicated, shared, and synchronized digital data geographically spread across multiple sites, countries, or institutions. There is no central administrator or centralized data storage.

A peer-to-peer network is required as well as consensus algorithms to ensure replication across nodes is undertaken. One form of distributed ledger design is the blockchain system, which can be either public or private.

The distributed ledger database is spread across several nodes (devices) on a peer-to- peer network, where each transaction or database replicates and saves a copy of the ledger and updates itself independently. The primary advantage is the lack of central authority over controlling transactions and thus having a single point of control or failure. When a ledger update happens, each node constructs the new transaction, and then the nodes vote by consensus algorithm on to validate the transaction. Once a consensus has been determined, all the other nodes update themselves with the new, correct copy of the ledger. Security is accomplished through cryptographic keys and signatures and transactions are stored securely in the ledger with copies in the respective transacting nodes. The transaction details are cryptographically secured using cryptography to ensure transaction immutability.

FIG. 2 which shows a Triple Entry bookkeeping between two parties. Triple entry accounting has an enhancement over the conventional system as all the accounting entries involving outside parties that are matched and also recorded by a neutral third entry in a third ledger besides the two transacting parties. These may include purchases of inventory and supplies, sales, tax and utility payments, and other expenses. The bookkeeping entries of both parties are placed beside each other to ensure that the given transaction is congruent. In Triple Entry Accounting, a Third Ledger is introduced by a neutral third-party. The Sender and Receiver will send a copy of the transaction to the Neutral Third party which acts as a notary to match the transaction and respond back to the sender and receiver nodes with notarized receipts, thus validating the transaction and ensuring its non-repudiation and immutability with a record of the notarization with notary as well. Moreover, where Blockchain and DLTs rather than these entries occurring separately in independent sets of books, they occur in the form of a transfer between individual ledgers of the two parties that reflect in the same distributed public ledger, creating an interlocking system of enduring accounting records. Since the entries are distributed and cryptographically sealed, their immutability non-repudiation and transparency were assumed to be assured. The Triple-Entry Accounting delivers the following but not limited to Tamper-Proof Records, Permissioned Distributed Ledger, Validated Secure & Private Double-Entry, transactions. It is envisaged that audit practice firms be validators on a Triple entry accounting system used to process and record triple entry accounting records and provide trusted auditing and "Proof of Transaction." Now every transaction is effectively recorded in three places, the sender, receiver and notary. Triple entry systems while solving the matching of transaction between two parties with immutability, non-repudiation and transparency, handle one leg of a transaction, leaving transactions unreconciled. Furthermore, the traceability of a transaction or a series of transactions suffers as reconciliation is possible only in pairs in the case of value chains. Since reconciliation is typically executed only in pairs in double-entry bookkeeping practices, the tracking and reconciliation of a transaction across multiple parties remains disjointed and unresolved transactions are split, merged, reversed or returned.

FIG. 3 shows a Triple Entry accounting between two parties using DLT according to one embodiment of the present invention. The present invention of DLT protocol which adapts Triple entry accounting principles to deliver real-time reconciliation and audits across multiple ledgers while reducing the effort and cost of executing the same. Furthermore, the invention offers reconciliation not just among pairs of ledgers but also value chains that will have a combination of transactions like splitting, merging, returns and reversals of transactions. Transactions requiring splitting, merging and returns in a sequence of transactions becomes very tedious to track and trace the details and reconcile multiple hops of the transaction. Moreover, commercial transactions with incumbent transaction amounts and taxes have multiple splitting, merging and returning of goods and services. At the core of the protocol is the objective of reconciling each transaction while it is executed.

FIG. 4 shows a flow chart depicting example operations of a real-time method for reconciliation and audits across multiple ledgers for a transaction of sale of goods by way of an invoice between a first party and a second party over a platform, according to one embodiment of the present invention.

In an example embodiment, considering a scenario of a transactions between two entities A and B i.e. in the First Leg of the transaction, A sends an Invoice to B for sale of Goods. In the Second Leg of the Transaction, B sends the corresponding Payment to A for the Invoice shared in the First Leg.

At step 400, the method elects a notary by a network of nodes. The Notary is randomly elected by a network of nodes as soon as at least 5 nodes are active in a network, in under 300 milliseconds. The Newly elected Notary randomly sets the Consensus threshold percentage between 51% and 80% for the term of the said Notary. The Consensus will change randomly from Term to Term. Further, the duration of each term is random and is based on the availability of the Notary for every periodic heartbeat. Furthermore, the Notary posts a heartbeat periodically to announce its presence and get an acknowledgment back from the active nodes to confirm their presence.

At step 410, the method requests the first party has to obtain public key of the notary and second party before initiating the transaction i.e. A requests B to obtain its Public Key before initiating the transaction. Further, A requests the Notary to obtain its Public Key before initiating the transaction.

At step 420, the method records of entry of a sale and corresponding purchase in a ledger of books of accounts of the first party and the second party i.e. A wishes to sell Goods to B and record the sale in an invoice. For the same to be executed, A will make an entry in its Books of Accounts recording a Debit against B for the said amount of the Invoice. The invoiced amount will remain as Receivables in A’s Ledger of Books of Accounts from B till the Payment is recorded by A from B. Further, B will have to make a corresponding entry in its books of Account recording the Invoice and Goods as a Credit from A. The invoiced amount will remain as Payables in B’s Ledger or Books of Accounts to A till the Payment is made to A by B.

At step 430, the method requests the second party and the notary to obtain public key by the first party before initiating the transaction i.e. B requests A to obtain its Public Key before initiating the transaction. Further, B requests the Notary to obtain its Public Key before initiating the transaction.

At step 440, the method records the invoice sent to second party along with the information on the goods sold, where the invoice is digitally signed by the first party with the public key of the second party to ensure that only second party to access the enclosed invoice with its private key. i.e. A will accordingly record an invoice sent to B along with the Goods sold, digitally signed by A with the Public Key of B to ensure that only B is able to access the enclosed invoice. B will accordingly record the goods received along with the digitally signed invoice and apply its Private Key to open the Invoice and process its business. Further, B will acknowledge the digitally signed invoice with a Response Code of “1000” to A. In an example, the response code of 1000: Receiving Node acknowledges transaction to Sending Node and Leader: 1000, # (Transaction Id, Receiving Node ID, Transaction# and Received Time stamp, Term, Index).

At step 450, the method requests the Notary to obtain the Notary’s Public Key by the second party before initiating the transaction i.e. B will request to the Notary to obtain its Public Key before initiating the transaction. At step 460, the method sends a digitally signed encrypted transaction details of the invoice to the notary by the first party and the second party using homomorphic encryption digitally signing the encrypted transaction details with their respective Private Keys and the Notary’s Public Key. i.e. Both A and B will now send a digitally signed encrypted transaction details of the invoice to the Notary, using homomorphic encryption, digitally signing the encrypted transaction details with their respective Private Keys and the Notary’s Public Key. The Homomorphic encryption is a form of encryption allowing one to perform calculations on encrypted data without decrypting it. The result of the computation is on an encrypted form, when decrypted the output is the same as if the operations had been performed on the unencrypted data.

At step 470, the method accesses the encrypted transaction details from both the parties with its private key and then employs homomorphic encryption to match transaction data without getting access to the transaction i.e. the Notary access the encrypted transaction details from both A and B with its private key and then employs homomorphic encryption to match transaction data without getting access to the transaction.

At step 480, the method posts the encrypted hash of the message out by the notary by matching the transaction data to the network for consensus to all follower nodes, wherein the Follower Nodes will respond back to the Notary with an acknowledgement as votes i.e. Once the Transaction data is matched, the Notary the posts the encrypted hash of the message out to the network for consensus to all follower the nodes. The Follower Nodes will respond back to the Notary with an acknowledgement which will be treated as votes.

At step 490, the method posts the transaction trail to the ledger along with all the voters, if the votes exceed the Consensus threshold set for the term. i.e. once the votes exceed the Consensus threshold set for the term, the Notary will post the transaction trail to the ledger along with all the voters.

The ledger will then send out digitally signed receipts of the transaction to the two transacting nodes notarizing the transaction. I.e. the ledger will send out digitally signed receipts to A and B to notarize the transaction and provide evidence for audit.

FIG. 5 shows a flow chart depicting example operations of a real-time method for reconciliation and audits across multiple ledgers for a payment of an invoice for transaction of sale of goods between a first party and a second party over a platform, according to one embodiment of the present invention. In this operation which is a second leg of transaction i.e. Payment against invoice of first leg.

At step 500, the method elects a notary. The Notary is randomly elected by a network of nodes as soon as at least 5 nodes are active in a network in under 300 milliseconds. The Newly elected Notary randomly sets the Consensus percentage between 51 % and 80% for the term of the said Notary. The Consensus will change randomly from Term to Term. The duration of each term is random and is based on the availability of the Notary for every heartbeat. The Notary posts a heartbeat periodically to announce its presence and get an acknowledgment back from the active nodes to confirm their presence.

At step 510, the method requests the Second party has to obtain public key of the notary and first party before initiating the transaction i.e. B requests A to obtain its Public Key before initiating the transaction. Further, B requests the Notary to obtain its Public Key before initiating the transaction. At step 520, the method records the initiation of payment to the first party, thus, closure of a sale in a ledger of books of accounts of the first party and the second party, where the second party will make an entry in its books of accounts recording a debit towards the first party for the said amount of the Invoice thus reconciling the second party’s ledger, and the first party will make a corresponding entry in its ledger or books of account recording the payment receipt in its receivables as a credit from second party and thus reconciling the first party’s ledger i.e. B wishes to Pay A, towards the purchase of Goods in the First Leg of the Transaction and record the sale at its end. For the same to be executed, both A and B will have to make corresponding entries in their Books of accounts. Further, B will make an entry in its Books of Accounts recording a Debit towards A for the said amount of the Invoice and therefore resolve the Payables in B’s Ledger or Books of Accounts to “Zero-Balance”, thus reconciling B’s Ledger. Moreover, A will make a corresponding entry in its Ledger or Books of Account recording the Payment receipt in its Receivables as a Credit from B and resolve Receivables in A’s Ledger or Books of Accounts to “Zero-Balance”, thus reconciling A’s Ledger.

At step 530, the method requests the second party and the notary to obtain public key by the first party before initiating the transaction i.e. B requests A to obtain its Public Key before initiating the transaction. Further, B also requests the Notary to obtain its Public Key before initiating the transaction.

At step 540, the method records the payment sent to first party along with the information with the corresponding invoice, where the invoice is digitally signed by the second party with the public key of the first party to ensure that only first party to access the enclosed payment and invoice details with its private key. i.e. B will accordingly record a payment sent to A along with the corresponding Invoice, digitally signed by B with the Public Key of A to ensure that only A is able to access the enclosed payment and invoice details. Further, A will accordingly record the payment received along with the invoice, both digitally signed and apply its Private Key to open the payment and Invoice and process its business. Moreover, A will also acknowledge the digitally signed payment and invoice with a Response Code of “1000” to B. In an example, the response code of 1000: Receiving Node acknowledges transaction to Sending Node and Leader: 1000, # (Transaction Id, Receiving Node ID, Transaction# and Received Time stamp, Term, Index).

At step 550, the method request the first party to obtain the Public Key of the Notary before initiating the transaction i.e. A will request to the Notary to obtain its Public Key before initiating the transaction.

At step 560, the method sends a digitally signed encrypted transaction details of the payment and invoice to the notary by the first party and the second party using homomorphic encryption digitally signing the encrypted transaction details with the Notary’s Public Key. i.e. Both A and B will now send a Digitally signed encrypted transaction details of the payment and invoice to the Notary, using homomorphic encryption, digitally signing the encrypted transaction details with the Notary’s Public Key. The Homomorphic encryption is a form of encryption allowing one to perform calculations on encrypted data without decrypting it. The result of the computation is on an encrypted form, when decrypted the output is the same as if the operations had been performed on the unencrypted data.

At step 570, the method access the encrypted transaction details from both the parties and employs homomorphic encryption to match transaction data without getting access to the transaction i.e. The Notary access the encrypted transaction details from both A and B employs homomorphic encryption to match transaction data without getting access to the transaction details. At step 580, the method posts the encrypted transaction hash of the message out by the notary by matching the transaction data to the network for consensus to all follower nodes, wherein the follower Nodes will respond back to the Notary with an acknowledgement as votes i.e. once the transaction data is matched, the Notary then posts the encrypted hash of the message out to the network for consensus to all follower the nodes. Further, the follower Nodes will respond back to the Notary with an acknowledgement which will be treated as votes.

At step 590, the method posts the transaction trail to the ledger along with all the voters, if the votes exceed the consensus threshold set for the term. i.e. once the votes exceed the Consensus threshold set for the term, the Notary will post the transaction trail to the ledger along with all the voters.

The method is capable of performing a transaction i.e. a forward transaction in which the operating node sends multiple transactions as a single transaction to the next recipient, and a return transaction in which the operating node returns a received transaction to the sender of the transaction, in part or full. In the forward transaction, for example, Company A sends 100 pieces of a component to Company B, thus “sending” the components to the next stakeholder in the value chain, and in the return transaction, for example, a Company B receives 100 units of an item from a Company A and may wish to return all or some of the items while paying for the rest of items to Company A. Company B initiates the return as two different transactions, one of goods and the other as payment for accounts to be reconciled with full settlement of quantities, amount and tax. The forward or return transaction handles all tagged attributes for reconciliation along with any value addition, the attributes include quantity, rate, amount and tax applicable on all three. The method is also capable of performing a transaction which includes a split transaction in which the operating node splits a single input transaction into two or more nodes with multiple attributes, and a merge transaction in which the operating node merges multiple transactions received into a single transaction and sends it to the next recipient. In split transaction, for example, Company A receives 100 units of an item and then splits them into two batches of 50 each and sends each of the batches to two downstream buyers. The reconciliation requires Company A to receive payments from both the buyers and reconcile accounts with its bank transactions as well as buyers. In merge transaction, for example a Manufacturer receives 100 sets of five components from five different vendors to manufacture 100 units of a finished product, thus “merging” the components into one unit each and sends them to the next stakeholder in the value chain. The merge or split requires at least three pairs of ledgers to be reconciled, in addition to their respective banks and statutory filings such as GST and multiple ledgers for the goods in transit, which are to be reconciled.

Moreover, incumbent upon the transaction, reconciliation would be required on attributes like quantity, rate, amount and tax applicable on all 3. Forward and Return Transaction will handle all tagged attributes for reconciliation along with any value addition. In addition, the transaction ownership now changes to the initiator of the Forward or Return, and the receivers cannot modify the transaction until they operate upon it. The reconciliation requires the First party to receive goods and services along with related documents such as invoices, vouchers, orders from the second party. The First party may then make payments through the bank to the second party which will need to be reconciled for settlement. On the other hand, the First Party may pay, return or reverse inventories in part or in full, requiring him to reconcile inventories, corresponding payments, taxes, and other expenses with payments through the bank where reconciliation may become slightly difficult to track, especially if it’ s spread out over time. A Forward or Return will require a pair of ledgers for each party along with reconciliation by both parties with their respective banks and statutory filings such as GST. A Merge or Split requires at least three pairs of ledgers to be reconciled, in addition to their respective banks and statutory filings such as GST and multiple ledgers for the goods in transit, which are to be reconciled. With the present invention, all of the above can be achieved through API integrations with their respective sources, thereby reducing manual intervention and Operational effort and cost significantly for administration, accounting and audit.

The present invention protocol and platform supports real-time reconciliation and audits across multiple stakeholders and their ledgers. Built on Application layer Atomic Multicast protocol, the platform ensures complete transparency and immutability of any transaction, from transaction initiator to the consumer while cutting costs. The Distributed Ledger of the present invention offers near-Zero-latency with transaction cost while being able to support very high scalability and throughput, thereby breaking all barriers and challenges in scaling, latency and atomicity. Further, such a solution can reduce and eliminate the risk of human error and fraud. The invention is end-to- end quantum secure, thus eliminating any possibility of breaching data. Moreover, the present invention is can operate on the following but not limited to mobile phones running Android/iOS and desktops running Windows, Linux or macOS. In an embodiment, the invention platform uses NoSQL Graph Database which supports real time analytics and reporting. High volume transactions with multiple stakeholders for data generation and consumption in use cases such as Track-and-Trace and Reconciliation-and-Audit applications are ideal applications. The present invention platform or method or system works finest in the following but not limited to real-time track and trace, real-time reconciliation and Balance Confirmation and audit across multiple parties in a value chain requiring immutability and transparency with a high volume of transactions, and real-time balance confirmation for AP/AR. Example may be or may include but not limited to Multi-party payment processing, Multi-party supply chain solutions, Multi-party document processing, Multi-party clearing house applications, and Multi-party track and trace solutions for compliance and governance.

ADVANTAGES

Real-time reconciliation and settlement reducing over 15% of Operational Expenses across value chains._Real-time evidence-based audit reducing 8 % of Operational Expenses across value chains. The invention can reduce (or eliminate) risk of human error and fraud risk. It has high scalability and low latency. The invention is a Mining less DLT, hence low cost of energy for transaction validation and no cryptocurrency. Further, Sub-second Latency invalidation, consensus and Ledger Update after reconciliation and audit, End-to-end Post-quantum security to ensure data protection, Real-time backup of Nodal data to a cloud account, Transaction-based pricing model, ensuring high Return on Investment and low Total Cost of ownership Easy to build and maintain DApps.

EXAMPLES OF RESPONSE CODES

1000: Receiving Node acknowledges transaction to Sending Node and Leader: 1000, # (Transaction Id, Receiving Node ID, Transaction# and Received Time stamp, Term, Index)

1001: Raft Message to all Voting Nodes from Leader. Message to contain 1001, # (Message Object)

1002: Consensus reached and Ok, Leader informs all nodes in channel 1003, # (Term Id, Index),

1003: Ledger confirming update to ledger. Leader can clear and logs older than present Term and Nodes can do likewise: 1003, # (Updated Index, Term, Last Transaction Id) 1004: Clear Log up to Term -1: 1004, # (Current Term). Nodes delete all logs up to (Term ID -1)

1005 - Consensus Rejected by Leader: Consensus <Threshold 1006: Digitally signed receipts to Sender and receiver

1007: Reconciliation confirmation to sender, receiver and Ledger

APPLICATION (EXAMPLE) - DECENTRALIZED IDENTITY AND VERIFIABLE CREDENTIALS

An adult individual has between 5 and 10 primary sovereign identities and numerous secondary and tertiary identities that tie back to the primary identity. The problem gets even more complex when the individual gets into professional joint ventures and personal relationships such as marriage and co-habitation with legal dependence. With the demise of an individual, a chain of records and relationships will need to be altered to represent the heir(s) and the consequent transfer of assets and liabilities. Further, in the case of change of an individual’s state adds further complexities and opaqueness to one’s records that can cause administrative issues, such as change of domicile or citizenship of an individual and his/her dependents and their respective movable and immovable assets.

At the time of birth, the local government issues a birth certificate that would be the seed document. That seed document is used to generate a national identity followed by a various other identity such as school roll number, insurance and passport. In the event of the parents of the new-born were to migrate or reside in another country, additional documentation is required to register the birth and parentage.

Examples of Primary sovereign identities are: Birth Certificate

National Identity number (Aadhaar, Social Security number, National Identity Card, etc.) Voter Id Driving License Tax Identity (PAN, IRS, etc.)

Passport

Primary identities are linked to Bio-metric identity to ensure that the identity of the individual.

Secondary Sovereign Identities:

Ownership Records and Licenses Property Weapons License

Bank and Insurance Accounts Telecom numbers Vehicle registrations Employee Id Postal Address

School and University identity

Visa and Residency in foreign countries

Transaction records linked to Sovereign Identity for recency

Tax receipts Telephone bills

Bank Statements

Tertiary Sovereign Identities:

Tertiary Sovereign Identities are identities of third-party entities linked to an individual such as

Business and Company owner ships and Bank accounts Business Tax filings Animal husbandry and Pet ownerships

Joint Identities

Joint identities are co-owned identities for a third entity, such as Marriage certificate Parents of a Minor child Partnership agreements in business Joint holdings in movable and immovable assets

Dependent Secondary identities

Sovereign identities of Dependents linked to Primary identity such as parents, spouse, children and pets Passport of dependents Visas of dependents

Dependent Tertiary Identities

Insurance and Driving licenses of dependents Vehicles owned by dependents

Whenever a Requester needs to verify a sovereign identity or a document record, the existing process requires the issuer to provide physical records, often notarized by a competent authority costing paper, time and effort. With the presently invention DID and VC platform, a requester can make an electronic request for a document directly from an issuer and receive the document after receiving the consent of the concerned user, duly signed with their respective digital signatures thus ensuring the authenticity of the document and the control on who can access the document.

The Process is as follows: Issuer signs up to the platform Node and creates a digital identity and registers its Universal Resource Name Universal Resource Identifier Document ID Cryptographic Identifier Decentralized Identifier Attachment format

A Decentralized biometric authentication system using Post Quantum cryptography authenticates and every node and transaction to secure it from any data breach. An Issuer will issue DIDs to users to their respective Digital vaults in the invention platform Nodes for the user to accept and store the data in their respective Digital V ault.

FIG. 7 is a block diagram of machine in the example form of a computer system 700 within which instructions for causing the machine to perform any one or more of the methodologies discussed herein may be executed. In alternative embodiments, the machine operates as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine may operate in the capacity of a server or a client machine in server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a mobile phone (e.g., an iPhone or a mobile phone executing an Android operating system), a web appliance, a network router, a network switch or a network bridge, or any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein. The example computer system 700 includes a processor 702 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), or both), a main memory 704, and a static memory 706, which communicate with each other via a bus 708. The computer system 700 may further include a video display unit 710 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system 700 also includes an alphanumeric input device 712 (e.g., a keyboard), a user interface (UI) navigation (or cursor control) device 714 (e.g., a mouse), a storage unit 716 (e.g., a disk drive unit), a signal generation device 718 (e.g., a speaker), and a network interface device 720.

The storage unit 716 includes a machine-readable medium 722 on which is stored one or more sets of instructions and data structures (e.g., software) 724 embodying or utilized by any one or more of the methodologies or functions described herein. The instructions 724 may also reside, completely or at least partially, within the main memory 704 or within the processor 702 during execution thereof by the computer system 700, the main memory 704 and the processor 702 also constituting machine- readable media. The instructions 724 may also reside, completely or at least partially, within the static memory 706.

While the machine-readable medium 722 is shown in an example embodiment to be a single medium, the term “machine-readable medium” may include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more instructions or data structures. The term “machine- readable medium” shall also be taken to include any tangible medium that is capable of storing, encoding or carrying instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present embodiments, or that is capable of storing, encoding, or carrying data structures utilized by or associated with such instructions. The term “machine-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories and optical and magnetic media. Specific examples of machine -readable media include non volatile memory, including by way of example semiconductor memory devices, e.g., Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and compact disc-read-only memory (CD-ROM) and digital versatile disc (or digital video disc) read-only memory (DVD-ROM) disks.

Furthermore, the machine-readable medium is non-transitory in that it does not embody a propagating signal. However, labeling the tangible machine -readable medium as “non-transitory” should not be construed to mean that the medium is incapable of movement — the medium should be considered as being transportable from one physical location to another. Additionally, since the machine-readable medium is tangible, the medium may be considered to be a machine -readable device.

The instructions 724 may further be transmitted or received over a communications network 726 using a transmission medium. The instructions 724 may be transmitted using the network interface device 720 and any one of a number of well-known transfer protocols (e.g., hypertext transfer protocol (HTTP)). Examples of communication networks include LANs, WANs, the Internet, mobile telephone networks, plain olde telephone service (POTS) networks, and wireless data networks (e.g., Wi-Fi and WiMAX networks). The term “transmission medium” shall be taken to include any intangible medium capable of storing, encoding or carrying instructions for execution by the machine, and includes digital or analog communications signals or other intangible media to facilitate communication of such software.

Although an embodiment has been described with reference to specific example embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader scope of the present disclosure. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. The accompanying drawings that form a part hereof show by way of illustration, and not of limitation, specific embodiments in which the subject matter may be practiced. The embodiments illustrated are described in sufficient detail to enable those skilled in the art to practice the teachings disclosed herein. Other embodiments may be utilized and derived therefrom, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. This Detailed Description, therefore, is not to be taken in a limiting sense, and the scope of example embodiments is defined only by the appended claims, along with the full range of equivalents to which such claims are entitled.

Such embodiments of the inventive subject matter may be referred to herein, individually and/or collectively, by the term “invention” merely for convenience and without intending to voluntarily limit the scope of this application to any single invention or inventive concept if more than one is in fact disclosed. Thus, although specific embodiments have been illustrated and described herein, it should be appreciated that any arrangement calculated to achieve the same purpose may be substituted for the specific embodiments shown. This disclosure is intended to cover any and all adaptations or variations of example embodiments. Combinations of the above embodiments, and other embodiments not specifically described herein, will be apparent to those of skill in the art upon reviewing the above description.

Claims

WE CLAIM:

1. A platform for reconciliation and audits across multiple nodes with ledgers for a transaction between a first party and a second party, comprising: a first party and a second party; and at least one neutral third-party elected by the network of at least five nodes; wherein the first party and the second party sends a copy of the transaction to the neutral third party which acts as a notary to match the transaction and respond back to the first party and the second party with notarized receipts, thereby validating the transaction and ensuring its non-repudiation and immutability with a record of the notarization with notary.

2. The platform as claimed in claim 1 , wherein the entries occur in the form of a transfer between individual ledgers of the two parties which reflect in the same distributed public ledger, thereby creating an interlocking system of enduring accounting records, and wherein the entries which are distributed and cryptographically sealed, their immutability and transparency were assumed to be assured.

3. The platform as claimed in claim 1 delivers Tamper-Proof Records, Permissioned Distributed Ledger, Double-Entry + Cryptography and Validated, and Secure & Private transactions using Digital Signed Receipts.

4. The platform as claimed in claiml, wherein the accounting entries involving outside the first party and the second party that are cryptographically sealed by a third entry, wherein the transaction include purchases of inventory and supplies, sales, tax and utility payments, and other expenses, and wherein the entries of both parties are placed beside each other to ensure that the given transaction is congruent.

5. A real-time method for reconciliation and audits across multiple ledgers for a transaction of sale of goods by way of an invoice between a first party and a second party over a platform, comprising: election of a notary by network of nodes; recordation of entry of a sale or similar transaction and corresponding purchase in a ledger of books of accounts of the first party and the second party; requesting the second party and the notary to obtain public key by the first party before initiating the transaction; recordal of the invoice sent to second party along with the information on the goods sold, wherein the invoice is cryptographically signed by the first party with the public key of the second party to ensure that only second party to access the enclosed invoice with its private key; requesting the Notary to obtain the Public Key by the second party before initiating the transaction; sending a cryptogrphically signed and encrypted transaction details of the invoice to the notary by the first party and the second party using homomorphic encryption; accessing the encrypted transaction details from both the parties with its private key and then employs homomorphic encryption to match transaction data without getting access to the transaction; posting the encrypted transaction details of the message out by the notary by matching the transaction data to the network for consensus to all Follower Nodes, wherein the Follower Nodes will respond back to the Notary with an acknowledgement as votes; and posting the transaction trail to the ledger along with all the votes, if the votes exceed the Consensus threshold set for the term.

6. A real-time method for reconciliation and audits across multiple ledgers for a payment of an invoice for transaction of sale of goods between a first party and a second party over a platform, comprising: election of a notary by network of nodes; recordation of closure of a sale in a ledger of books of accounts of the first party and the second party, wherein the second party will make an entry in its books of accounts recording a debit towards the first party for the said amount of the Invoice thus reconciling the second party’s ledger, and the first party will make a corresponding entry in its ledger or books of account recording the payment receipt in its receivables as a credit from second party and thus reconciling the first party’s ledger; requesting the first party and the notary to obtain public key by the second party before initiating the transaction; recordal of the payment sent to first party along with the information with the corresponding invoice, wherein the invoice is cryptographically signed by the second party with the public key of the first party to ensure that only first party to access the enclosed payment and invoice details with its private key; requesting the Notary to obtain the Public Key by the first party before initiating the transaction; sending a cryptographically signed and encrypted Transaction details of the payment and invoice to the notary by the first party and the second party using homomorphic encryption; accessing the encrypted Transaction details from both the parties with its key pair and then employs homomorphic encryption to match transaction data without getting access to the transaction; posting the encrypted Transaction details of the message out by the notary by matching the transaction data to the network for consensus to all follower nodes, wherein the follower Nodes will respond back to the Notary with an acknowledgement as votes; and posting the transaction trail to the ledger along with all the voters, if the votes exceed the consensus threshold set for the term.

7. The method as claimed in claim 5 and 6, wherein the transaction includes a forward transaction in which the operating node sends multiple transactions as a single transaction to the next recipient, and a return transaction in which the operating node returns a received transaction to the send of the transaction, in part or full.

8. The method as claimed in claim 7, wherein the forward or return transaction handles all tagged attributes for reconciliation along with any value addition, the attributes include quantity, rate, amount and tax applicable on all three.

9. The method as claimed in claim 5 and 6, wherein the transaction include a split transaction in which the operating node splits a single input transaction into two or more nodes with multiple attributes, and a merge transaction in which the operating node merges multiple transactions received into a single transaction and sends it to the next recipient.

10. The method as claimed in claim 9, wherein the merge or split requires at least three pairs of ledgers to be reconciled, in addition to their respective banks and statutory filings such as GST and multiple ledgers for the goods in transit, which are to be reconciled.

11. The method as claimed in any of preceding claims, wherein the transaction tracking and tracing is a Bi-directionally along the entire lifecycle of a transaction from originator to final destination.

12. The method as claimed in any of preceding claims, wherein the transaction cost is minimum with fastest response time by maintaining true event time stamp on platform, log size, ledger update interval, and consensus level are configurable for each channel.

13. The method as claimed in any of preceding claims, wherein the transactions ordered by time stamp on ledger in chronological order of occurrence & replicated in same order for consensus after which the data are updated to ledger in under 2500 ms.

14. The platform and/or method as claimed in any of preceding claims is resistant to cyberattack.