We started this book by understanding how the banking and financial services industry operates today. We looked at blockchain technology and how it can make a difference in the financial sector. We looked at how to approach building financial applications using blockchain. We wrapped up our first chapter by taking a look at some of the popular blockchain platforms being used for financial applications. These include Ethereum, Hyperledger Fabric, and Stellar.
In Chapter 2, Building a blockchain Wallet for Fungible and Non-Fungible Assets, we worked on a blockchain wallet for holding both fungible and non-fungible tokens. This chapter looks at the concept of fungibility and how Ethereum smart contracts can be used to issue fungible and non-fungible tokens. Next, we built a wallet app that allows us to send and receive tokens. Additionally, you can approve other Ethereum accounts to mint new tokens from your address using the wallet.
The wallet is one of the most common blockchain application components. It is almost impossible to build a blockchain application without one. They serve as a tool for managing the user's private and public key pairs. Typically, they have a frontend that shows the number of tokens or assets the user is currently holding.
In Chapter 3, Designing a Payment Gateway for Online Merchants, we built a payment gateway that could be used by merchants to receive payments in ethers. To do so, we built a mock e-commerce website and a merchant Ethereum wallet for receiving payments. Customers could pay using their MetaMask Ethereum wallet or any other wallet to send a payment. The merchant's wallet was implemented using the BIP44 HD (Hierarchical Deterministic) wallet. This is a hierarchical system of deriving public-private key pairs from a single set of seed words. The BIP44 system allows us to generate a new receiving address for the merchant while receiving payments.
This ensures that the merchant's privacy on a public blockchain network is maintained. Our merchant wallet is built to track all of the receiving addresses generated by the BIP44 system for the merchant. Since Ethereum has a probabilistic consensus protocol, the merchant's wallet tracks the number of blocks added to the ledger after each transaction. After around 40 blocks, we can confirm the transaction.
This payment gateway model can be used across blockchain platforms for payments with slight modifications. For example, you could use this model for receiving payments on the bitcoin network or for ERC20 Ethereum tokens. The block confirmation feature would only be useful for blockchain platforms with probabilistic consensus protocols.
Chapter 4, Corporate Remittances and Settlement, focuses on corporate remittance. We build a permissioned Hyperledger Fabric network between the banks, Bank A and Bank B, for facilitating corporate remittances. We also set up a private IPFS network with a node for Bank A and a node for Bank B for sharing compliance documents between the banks. Lastly, we set up a bank portal where our corporate customer can log in and submit transactions and view transactions that have been submitted.
Corporate remittances are probably one of the most popular financial services offered by the banking and finance industry. They are also more susceptible to fraud compared to other financial services owing to the large ticket size of the transactions and the fact that the remitting customer is an organization instead of an individual. Hence, compliance checks and provenance for secure, efficient, faster, and fraud-resilient workflows are extremely important. This can be easily achieved using blockchain as seen in this chapter.
Chapter 5, Enabling Cross-Border Remittances with Real-Time KYC/AML Verification, uses the stellar distributed ledger platform to build a cross border remittance solution between retail customers aka individuals. The project uses the built-in Federation and Compliance modules of Stellar for exchanging KYC and AML information about the remittance participants as part of the transaction request. We set up a two-bank network with Bank A and Bank B. Each bank had its own infrastructure, including a database server, a backend server, a stellar node, and a frontend.
Customers could log in to the frontend and submit a payment request. Before submitting the request to the blockchain, the infrastructure first does a compliance handshake between Bank A and Bank B. The transaction is submitted to the blockchain only after the system gets a signoff from the remitting organization and the receiving organization.
Retail remittances have spiked in volumes significantly, especially remittances from the west to South Asian countries such as India and Bangladesh. A customer receiving payments in these countries from abroad still pays a hefty transaction processing cost for receiving money owing to a large number of intermediaries. Additionally, the payment might get delayed due to bureaucratic workflows. A cross-organization application similar to the one we described earlier will help to solve these problems and improve the customer experience
In Chapter 6, Building a Letter of Credit Workflow Module Using Smart Contracts, we looked at building automated workflows using smart contracts. Specifically, we looked at automating Letter of Credit (LC) workflows. We built an LC portal where Bank A and a buyer and seller can log in to issue, view, and settle an LC document. On the blockchain side of things, we used Ethereum smart contracts to attain our objective. We built a contract for issuing and managing new Letter of Credit contracts and we built a contract interface that would serve as a template for issuing new LCs. Users could interact with the smart contracts using the various options in the frontend.
This chapter is meant to give you a comprehensive look at the power of smart contracts, specifically Ethereum contracts. They can be leveraged to quickly and effectively build cross-department or cross-organizational workflows. This can help organizations immensely when trying to build a solution with business logic that spans across multiple organizations. Additionally, it saves costs on reconciling data across organizations.
Chapter 7, Building a Tamper-Proof Record Keeping and Document Management System, uses Hyperledger Fabric to build a tamper-proof document and file storage system. We built a React application that asks the user to choose a directory path to be secured. It then calculates and stores the hash value of each file in the directory path, the hash value of the file tree structure of the directory path, and the hash value of the last modified time of all of the files in the directory path to the blockchain. The application then periodically checks to see whether there is a mismatch in the hash values of the file tree hash and the modified time of the files in the secured directory path. A mismatch indicates that one or more files have been tampered with. Next, it compares each individual file with their corresponding hash values in the blockchain and lets the user know which files have been tampered with. It also informs the user whether any new files have been added or old files have been removed.
Banks manage huge volumes of customer documents and other confidential private files. It is imperative to have a system that will let us know in case any tampering happens so it can instantly be rectified by replacing the information from a backup. This application allows us to do so. It can be used effectively to prevent modifications by unauthorized individuals.
In Chapter 8, Building a Decentralized Trading Exchange on blockchain, we built a decentralized exchange using Ethereum smart contracts to trade gold for USD. The engine for matching trades was implemented outside of the blockchain, but the executed trades and pending trades were captured to the blockchain using a smart contract. Traders can log in to their system, point their application to the trading smart contract, and view available trades in the market. They can then submit requests to the platform to buy or sell gold.
In light of several trading exchanges defaulting globally, it probably makes sense to set up a trading exchange that is not solely under the control of a centralized authority. This is where decentralized exchanges come in. In our project, whilst the trading engine is still built and maintained by a centralized authority, the actual trade offers are submitted and recorded on the blockchain. Once offers are submitted, they cannot be modified. They can only be traded against. Hence, our order book cannot be tampered with by the exchange operator.
Users can also view matching trades and detect any cases of fraudulent transactions or offers being submitted. These features make decentralized exchanges probably one of the most important blockchain use cases. They have been explored heavily by the open source permissionless community and now the permissioned enterprise blockchain community is also showing interest.
In Chapter 9, Developing a Currency Trading Exchange for Market Making, we use the stellar platform's order book module to build a currency trading exchange. The trading exchange allows you to exchange USD, EUR, and GBP. This chapter is meant to demonstrate the stellar platform's ability to facilitate cross-asset trades. It also shows how you can very quickly build a decentralized exchange using this powerful network. Several exchanges such as StellarTerm are actually using the order book module of the public stellar network to build exchange applications.
That covers all of the projects in our book. Let's now take a look at how you can leverage and extend the knowledge you gained in this book for building applications not covered as part of this book and what other areas you probably want to look at.