CUTTER BUSINESS TECHNOLOGY JOURNAL  VOL. 31, NO. 11/12
  

Business architects attempting to modernize fintech architecture face a difficult task because the architecture constantly evolves. Modifying the architecture without halting processing is not a trivial task.

A typical fintech company today divides its IT organization into a front office, which oversees customer processing activities (e.g., customer applications, an investor site); a mid-office, which typically handles interbank transactions (e.g., SWIFT message handling, regulatory reports); and a back office, which generally manages report processing and scheduled activities like end-of-day processing. Organizations that divide their IT organization in this “three-tier” manner facilitate improving architecture changes and making technology upgrades to the IT systems with little or no failure. But achieving this type of success requires thorough solution design and architectural pattern implementation prior to attempting any change.

Blockchain as a service (BaaS) is a key architectural milestone in the blockchain platform and provides various avenues for implementing blockchain solutions across different industry solutions. Many industrial approaches to blockchain are being developed — especially in supply chain management — spanning manufacturing, retail, and financial services.

IBM, in particular, has a noteworthy solution: TradeLens, an open and neutral supply chain solution underpinned by blockchain technology. This solution, jointly supported by IBM and Maersk, is built on the IBM blockchain ecosystem powered by Hyperledger Fabric. Major shipping and logistics players across the US and Europe now use it. Similarly, Microsoft has been inventing numerous accelerated approaches using a blockchain platform. A recently launched, breakthrough approach is the company’s Azure Blockchain Workbench, an open, trusted, and global platform that helps develop solutions for global market management, customer relationship management, and supply chain management.

These two giants provide dual insights into archi­tectural solutions: both combine cross-architectural approaches using highly scalable cloud platforms for blockchain, and both concentrate on the supply chain to meet demand for these solutions. These approaches provide flexible usage in terms of quick, go-to-market solution development by simplifying development and experimentation on their prebuilt network.

This article discusses how a BaaS architecture helps the back-office service, with a focus on security aspects; how BaaS improves efficiency in cost of operations; and how BaaS, by improving security handling, differs from other popular blockchain architectures used by Hyperledger and other leading blockchain platform solutions.

Challenges in Fintech IT Services

The IT services of most banks are reinventing their solution approach to rationalize their IT architecture to address two key issues:

1. Improve efficient handling of cost of operations. The cost of operations for repeated activities and daily/routing activities accounts for a major portion of IT budgets and can consume 20%-30% of the IT budget year over year. Business architecture teams at fintech companies are engaging business consultants and functional architects to reduce the redundancy in such operations and improve system efficiency.

2. Provide higher customer satisfaction with state-of-the-art solutions for efficient fraud-detection solutions and a highly secure core banking solution (a retail banking solution, an internal IT solution, an advisory solution, etc.). With customers hav­ing access to more and more new technology and modern devices, they increasingly expect a low-cost banking experience that is both flexible and easy to use. They anticipate a quick turnaround to their requests, with intuitive banking solutions that they can use on their own or with minimal dependency on the banking support team. For example, banks need to provide a highly user-friendly interface to consumers of different ages and with varying educational/technical backgrounds. At the same time, these solutions should not compromise users’ security and privacy.

To address the challenges in the fintech industry, we need to understand the underlying problem, which has two dimensions: (1) the number of transactions being handled at one time and (2) the number of steps in the end-to-end business processing of a user operation (e.g., transferring funds, creating an account, and approving a transaction).

Blockchain as a Service

Although fintech industry solutions have experimented with blockchain to address the above challenges in efficient, highly scalable, and low-cost processing systems, there are many factors to consider in defining the standards and architecture patterns to use.

While, in general, a solution to address these challenges lies in back-office territory, with the advent of blockchain architecture and platform solutions, a decentralized architecture addresses the challenges of opera­tional overhead cost and greater customer satisfaction. Indeed, a decentralized architecture reduces operational overhead in workflow management, as with approval/rule processing mid-operation in the journey of a transaction process, as shown in Figure 1.

Figure 1 shows how user data is autonomously handled in a decentralized fashion in a blockchain-integrated architecture to reduce cost overhead in security and risk handling using manual workflow operations. In a typical fintech organization, systemic risk cannot be predicted, but recovering from a systemic risk can be planned well in advance through a recoverable IT policy and a restructurable architecture upon which the IT systems are constructed. Developing an IT system based on BaaS attempts to build such a recoverable architecture. When the potential of blockchain architecture is explored, BaaS is an attractive design approach for fintech IT solutions that combines blockchain and a cloud-based approach (e.g., IBM FinTech portal powered by Watson) due to its ability to handle faster, more secure, and more transparent transactions with highly scalable solutions.

Since 2016, Barclays, Morgan Stanley, TP ICAP, Mitsubishi UFJ Financial Group, BNP Paribas, and myriad European fintech companies have come up with many practical business and technical trailblazing efforts, such as Digital Technology Architecture (DTA) and Digital Private Banking (DPB) solutions, involving auto recognition and self-executing smart contracts and financial settlements.

Adopting next-generation solutions in banking (see Figure 2, which depicts a typical BaaS architecture) also requires adaptive corporate governance. The model being executed must have fair fallback options and an alternate solution or path to leverage the luxury of rearchitecting and revamping the solution during a crisis situation, such as systemic risk execution, or with technical challenges, such as consumer protection or vertical scaling solutions as needed by an increasing user base.

Looking back at Figure 1, one might be interested to know how BaaS addresses security in a decentralized shared service ledger architecture where customer protection is an issue of great concern. BaaS addresses security with a multi-level, self-healing service that is much more advanced than a typical two-way handshake or multi-factor security service.

Security Considerations in BaaS

With the emergence of digital technology and the increasing availability of Internet service, peer-to-peer (P2P) transactions have risen dramatically over the past decade. On a blockchain platform, for instance, one user can transfer money to another user with Bitcoin. Blockchain is widely used today due to its user-friendly features, including transparency, immutability, and lower transaction costs.

P2P transactions happen in two ways: either through a public ledger or a permissioned ledger. As we know, validating a transaction with a permissioned ledger is a daunting task due to non-availability of proof of work and difficulty in creating a node for which the issuer or receiver requires permission from a blockchain developer.

Typically, BaaS security considerations are handled with a multi-level service (see Figure 3). Key store handling is done efficiently in different stages of public key markup, encryption service, and twofold signage and verification. Storing the public key outside the blockchain platform nodes also ensures better security. A multi-platform approach handles more than one smart contract for various stages of banking solutions.

Figure 4 shows the improved validation system and its interfaces with the rest of the elements in the system. The improved system typically gets input from the user or bank for initiating a transfer. Once the issuing entity receives the transfer signal, the system proceeds with further validation of a transfer.

The following three modules are loaded into the processor of the improved system:

1. Issuer entity. This module initiates the transfer from the source entity (e.g., bank, individual, or mercantile entity) using an online blockchain system by entering sender and receiver details along with transaction information (i.e., amount, source currency, target currency, and transaction remarks).

2. Receiver entity. This module receives the money transferred from the issuer entity at the end of the transaction once the validation is successfully completed and approved by the bank or any other approving authority during the blockchain validation process.

3. Validation system. This module consists of the following elements:

• Blockchain key generator. This element generates the header information, which is sent through a blockchain transaction and contains encrypted information about the transaction and the validation data.

• Blockchain key validator. This element takes the block node of the transaction received from the sender and uses the interpreter to obtain transaction details and validation details (e.g., address, identification remarks) based on the bank’s regulatory requirements as required by the approver.

• Blockchain key interpreter. This element converts the encrypted information received from the sender into validation remarks as required by the approver, which are used for the validation process in the validation component. The key interpreter also sends the final validation remarks to the sender after the completion of the validation.

Typical processing happens in a 10-step flow of operations as follows:

1. The user approaches the concerned bank or entity to initiate a transfer of funds from an account. The transferring entity fetches the transferee account details and customer details and initiates the transfer through the online application. After collecting the data, the issuer unit converts the collected information into a block of information in the blockchain transaction communication channel containing two compartments for customer information and transaction information.

2. The collected information is encrypted and stored in the header of the node for the first block of the transaction.

3. The transaction information is used as is throughout the blockchain communication until it reaches the receiver bank. Customer information is changed during every block transfer in the channel, depending on the requirements of the receiving bank. For example, some banks may not be interested in customer address or customer contact number during the transfer, whereas some banks prefer them as mandatory input for the transfer.

4. Each block ID is unique to the group issuer/sender, and hence duplicate transactions for the same user (issuer/sender) are invalidated during block creation as it is duplicated with another transaction having the same ID.

5. The receiver bank decides where a new node is created and chained, as part of a smart rule, to the received node to create a connection between nodes in the blockchain communication. This chain of nodes grows until a validator bank receives the information and the validation process is initiated. To preserve data security throughout the entire transaction, the blockchain consortium that defines the underlying platform (e.g., IBM Hyperledger, Microsoft Workbench) prefers a standard security mechanism of encrypting the data and transfer throughout the nodes in the channel.

6. A single lenient structure of nodes (i.e., each node containing a transactional piece of information) is created in the blockchain transmission by com­bining a group of nodes created throughout the transaction in a clustered node of transactions (each node is like a branch in a tree with a root node at the beginning of the transaction having customer information). When the sender bank initiates a transaction, a transaction block is created containing customer and transaction information, along with a unique generated identifier in the block’s header. This header is taken through all the blocks when the header information is created in the blockchain, as per blockchain transmission protocol. When the next block is created, the header is copied to the new block, and the customer information is transmitted as per validation rules. This process of transmitting the block ID and header is done for each block created throughout the entire transmission until the final block is created at the receiver block or when the validator accepts the block for validation to complete the transaction.

7. A convenient clustered data store mechanism is introduced to enable an efficient validation mechanism and improvise the validation process for any type of blockchain transaction. This chain of nodes is formed as a clustered node (tree structure), and the details that have passed into different nodes in the transaction are stored in this tree structure and are stored as part of the node during the creation of the block that contains customer information and are transferred to the validation component. The validation node is linked (link validation process) to the approval process that the receiver bank uses to approve/reject the transaction by checking the clustered information received in the node. The clustered information can be enriched with all the blocks of the communication (that have a header with customer information) in the transaction chain as well. Once the validation is complete, this information is finally stored in the ledger transaction of the receiver bank.

8. In the transaction processing bank, the validation component receives the block to be validated and delinks the required customer data information from the node. A cluster of information is prepared for the approver to validate and the transaction proceeds. This information is decrypted and sent to the approver through a non-volatile memory transfer and will not persist until the validation process is complete so that the transaction is handled only in the respective banks of the sender and receiver.

9. Once the validation process is complete, the information on approval status is attached to the final block of the transaction and sent to the receiver bank. The receiver bank obtains the receiver account information from its (receiver bank) database, and the transaction is realized/credited to the receiver account as instructed by the sender during the initiation of the transaction (with respect to the receiver currency type and mode of receipt — cash, credit note, etc.).

10. In the validation step, a clustered node of customer/account/currency information, as required by the approver, is prepared. A subsequent step uses this node to transmit to the approver for further processing. Based on the outcome of the validation, the remaining step of realization of payment or rejection of the transaction is carried out; this is the post-validation outcome in a regular blockchain hierarchy process. This validation step works in a premised, ledger-based, blockchain transaction as the boundary of information required for clustered block preparation, having mandatory information from the customer, account, and currency blocks.

Conclusion

The primary goal of BaaS architecture is better trans­action management — with a higher processing rate due to anonymous transmission and multi-node approval in a typical multi-contract platform using a blockchain solution. This goal is efficiently achieved in the validation module explained above, as the validation is self-controlled by the node where customer information is available, instead of backtracking the entire chain communication to obtain the customer details.

A customized validation rule can be added in the validation module to enforce country-based regulatory rules for better transaction management and prevention of fraudulent transactions. The result is higher transaction security, with the customer block being encrypted and transferred in each block until the transaction is validated and completed at the receiver bank.

Blockchain helps to create a smart, efficient solution design for a fintech’s back office by addressing key issues like security and risk management.