Remember XORO? Let’s bring XORO back to life.
After a lot of international shows, he decides to celebrate his daughter’s birthday in two days with a grand celebration. He plans to hire an events management company, ROX, to design the celebration. To kick it off, he needs to deposit a large amount of money.
Being in the United States, XORO goes onto the bank website and tries to initiate a wire transfer. ROX has an account in London. Severe panic arises when the transfer delays longer than the intended time due to an intermediary being involved. XORO worries about the money, time, and the happiness of his daughter.
Further, the bank advises him to visit the branch and submit a letter to confirm the large transaction for security purposes. All of this is entirely controlled and regulated by the bank. After all the formalities, the very money that XORO wanted to transfer gets hugely delayed because of the bank’s control over his money.
To add to his grief, XORO was charged a minimum balance penalty, which he was truly unaware of. The bank had decided to increase the minimum amount that his account must hold and dispatched a letter to his house in London, which went unattended. The whole situation was a bitter experience for XORO, a penalty against his own money for the sake of the safety that the bank provided.
Have you ever felt the pain that XORO experienced here? The frustration of bank transfers, deposits, and so forth?
Imagine how it would have been decades ago. Today, we have blockchains rewiring the concept of money, transactions, security, and consensus.
Better access to his own money, digitally residing in his wallet on his node or machine
Faster transfer to the other user, with no other intermediary control
Secure end-to-end encryption of the transaction
Immutability and no room for human/manual error in intermediate operations
Awareness of the pre-defined rules and consensus of transfer, made clearer to him on the ledger
Stake in voting on the agreement to add a rule or remove a rule on the ledger
Now, this does not mean that blockchains make banks obsolete. It purely makes the operations of financial institutions better, with an infrastructure upgrade for all stakeholders. It further decentralizes the processes and operations among all stakeholders.
The History of International Transactions
Evolution of transaction networks
In the early 1830s, telegraphy developed into a network of point-to-point transmissions of signals, which were represented initially by various visual codes, dashes, and dots, which further evolved into alphanumeric messages. The development of telegraphy picked up speed due to the accelerated developments of the electric battery and the wonders of electrical engineering performed by Ohm, Faraday, and Ampere.
From there, with the demands of connectivity increasing in the 1930s, the frequencies of signals were varied using voice multiplexing with asynchronous requests. Thus, the Telex networks were developed. In simple words, it was an exchange network of teleprinters. These networks were a start to financial transactions’ occurring across countries. The switching networks took several days to transfer, depending on network connectivity. With further growing demands and the need for secure, speedy systems, the Society for Worldwide Interbank Financial Telecommunication, abbreviated as SWIFT, came into picture around the 1970s. This was the same time at which ARPANET was developed, which went on to be the basis of our current-day internet .
Just as electrical improvements occurred, telegraphy evolved. With increased numbers of communication systems, TELEX improved. Just as ARPANET was at its inception, SWIFT evolved. Now that every user has a machine that has an IP address and computational power, having connectivity exist just between financial institutions is not enough anymore. End users seek complete connectivity with their assets and operations, thereby making blockchains a natural choice of operation as they connect peer to peer.
The internet and digital banking services still make one’s finances a virtual black box for the end user, as digital banking services are centralized and governed by their own private regulations. The methods of encryption and storage are not known to the end user in private centralized platforms. With the concept of a blockchain, transparency and security are brought to the end user. As explained in this book and this chapter in particular, from the end consumer to the core developer, blockchains envision making people aware of the encryption options for their digital assets and what happens to them during a transaction, offering complete transparency. At the same time, blockchains provide a control and right to privacy with their infrastructure.
Decoding Process Designs for Financial Instititutes
As blockchains are still evolving, several packages, versions, and existing chains are subject to change. However, the design flow of decentralized networks using the concept of blockchains will lay the foundation for a decentralized economy. The way to operate may still change. For example, Bitcoin & Ethereum Blockchains have been highly recognized for its decentralized network & the cryptocurrencies that are transacted across the platform. However, they may get replaced with newer versions, or new Blockchain Frameworks for specific sectors. This does not change the decentralized format which remains core to the concept of Blockchains.
Given the way Uber, AirBnb, and Amazon have taken over our travel, stay, and retail, blockchains in the financial domain will revolutionize the way money is generated, stored, transferred, and hedged.
Details of SWIFT architecture
Details of SWIFT messaging architecture
The SWIFT network allows end users to initiate the transfer request through the bank’s platform. The bank is connected to the SWIFT network. The messages are verified based on the parameter check of the SWIFT network. Once verified by this centralized architecture, it triggers the intended receipent’s bank, which may or may not be a part of the SWIFT network. If it is a part of the network, the message is transferred, thereby reflecting the transaction of money
In a blockchain, the decentralized ledger performs similar operations; however, the difference is that the end users—both the recipient and the initiator—are independent nodes that trigger the transaction without any centralized intermediary in between.
Hyperledger is an umbrella project of open source blockchains and related tools, started in December 2015 by the Linux Foundation, and has received contributions from IBM, Intel and SAP Ariba, to support the collaborative development of blockchain-based distributed ledgers.
In simpler words, Hyperledger enables a Blockchain Framework to set up decentralised systems in platform agnostic ways.
Let’s view this in action over Hyperledger. To set up Hyperledger for the first time, we’ll create a development environment and establish the chain on a single instance (single virtual machine). Further, we can scale it to production environments for multi-node instances (multiple devices, VMs, etc.).
CA nodes: The nodes running the certificate authority (CA) that issues certificates across the elements of the network. These certificate services extend to users or other components of the blockchain for operations such as the addition of users or invoking transactions and TLS-secured connections between users and other components of the blockchain. The CA nodes have to initialize first, before the peer nodes, so as to set up the security, access control, and rights. These nodes extend an identity to the network. Through the certificate authority, while onboarding a user node, the enroll ID, name, type of identity, affiliation, and maximum enrollments allowed are defined. Similarly, these nodes provide other services for transactions and operations.
Orderer nodes: These nodes run the messaging system across the chain. Consider it the work manager that distributes messages in a consistent framework. Based on the defined operations, these nodes help in propagating messages as broadcasts or singular transactions. They validate the transaction and ensure on-chain credibility as a group of nodes. Hyperledger has two modes of ordering—SOLO (development purpose) and Kafka (production environments to scale).
Peer nodes: Every node (end device, VM, smartphone, laptop) in the blockchain can be termed as a peer node. These nodes are users that transact, maintain the last state, or copy and append to the shared ledger. They contribute to making the blockchain immutable, as every peer must get updated for any change to be registered on the blockchain when used as a shared public ledger. Some peers may be observers, validators, or initiators of transactions.
CouchDB nodes: Nodes that have the CouchDB database that stores the state and provides querying mechanisms for the chaincode data and operations.
Correlate or contrast these components against a centralized web platform that has elements of DNS hosting, TLS security via SSL, queuing, front-end server, back-end server, and database. These elements communicate with each other to render a website.
A distributed system. Source: https://github.com/caleteeter/azure-docs/blob/caleteeter-hlfupdates/articles/blockchain-workbench/hyperledger-fabric-single-member-blockchain.md. Used under CC-BY 4.0 License
Let’s start with the Hyperledger Composer.
Hyperledger Composer
Now that we know the key stakeholders of the blockchain network, let’s see the execution in action via the Hyperledger Composer Playground. Here, we’ll use the example of trade finance.
Bill of lading, letter of credits, and bank guarantees
Connecting all stakeholders
Fraud-pattern detections
Validation of true capacity
Unbiased credit ratings
Draw out real-life supply chains that affect your daily life and could be improved.
Consider a use case where we have an intended trade between importer and exporter. The requirement for a letter of credit comes from the interbank lack of transparency, which causes authorities to rely on LOCs signed by the advisory banks.
For this, we built SmartPlug, a data translational tool that converts trade documents into smart contracts to onboard traders for fair trade. Let’s see how the current-day letter of credit is tangibly executed on a digital platform that runs on consensus.
- 1.
Click on Download Business Network 1.
- 2.Download the .bna file, which contains the following elements:
Lib – It contains the business logic for the blockchain.
Models – It stores information about participants and assets for the blockchain.
package.json – It stores dependencies with the various packages.
Permissions.acl – It stores user access control.
README.md – It stores information related to the platform.
Lib: sample.js
Sample File showcasing business logic
Models: sample.cto
.
Package.json
.
permissions.acl
.
README.md
.
Running the Example
- 1.Go to the Exporter tab of the SmartPlug demo (Figure 4-10) and upload.
Figure 4-10Interface to upload data blocks in usable forms
- 2.
The interface will do some validation. Then click Submit.
- 3.You’ll see a success screen (Figure 4-11). Click “Let’s Blockchain!”
Figure 4-11Hyperledger’s console that inputs the data from the portal to the decentralized platform
- 4.
Click the Import/Replace button and upload the .bna file.
- 5.You’ll see Figure 4-12. Click Deploy.
Figure 4-12Imports BNA on console
- 6.Click on the Test tab (Figure 4-13).
Figure 4-13Can set test variables for each variable
- 7.Click on Submit Transaction (you’ll see Figure 4-14).
Figure 4-14Transaction methods defined in the code can be selected and executed on the Hyperledger Composer Playground
- 8.Create a transaction for SetupDemo (you’ll see the results in Figure 4-15).
Figure 4-15Transaction registry
- 9.Check for the participants (exporter, importer, shipper), as shown in Figure 4-16.
Figure 4-16Ledger data for exporter
- 10.Check for the contract (Figure 4-17).
Figure 4-17Contract detail conditions from the code
- 11.Check for the shipment (Figure 4-18).
Figure 4-18Shipment data on ledger
- 12.Check for the transactions (Figure 4-19).
Figure 4-19Ledger for transaction records
- 13.Create a shipment transaction for the shipment ID (Figure 4-20).
Figure 4-20Invoking creation of shipment
- 14.Upload the shipper receipt (Figure 4-21).
Figure 4-21Shipper’s upload validates that the shipment is in transition with him
- 15.The platform validates all of the receipts and translations. If there is fraud in the receipt it will give an error before submitting (Figure 4-22).
Figure 4-22If details mismatch, validation fails and avoids fraudulent data
- 16.After submitting the proper document (Figure 4-23), it will proceed.
Figure 4-23Successful validation upon uploading correct documents
- 17.Create a transaction for shipment transit (Figure 4-24).
Figure 4-24Validates with the shipment ID and the Orderer node (here, it’s the shipment company)
- 18.Check for the exporter and importer balances on the ledger (Figure 4-25).
Figure 4-25Update of values in exporter’s wallet and records
- 19.The importer can then accept the shipment (Figure 4-26).
Figure 4-26Platform where importer accepts shipment by uploading receipt
- 20.Check for exporter account balance (Figure 4-27).
Figure 4-27Equivalent update of values in exporter’s records based on the contract details defined in the code
- 21.Check for the importer account balance (Figure 4-28).
Figure 4-28Importer’s account balance amount is reduced, and payment is made as per contract
Now that we have experienced the journey of the Hyperledger Composer Playground, let’s build one for other fintech use cases. Build the use case for peer-to-peer micro-financing and -lending options.