Fintech Industry Adoption of Blockchain Ledgers

Blockchain is the new WEB 2.0 – a brief recommendation report on how the omnipresent technology fits into modern fintech developments.


The underlying concept of blockchain was first conceptualized in 1992 as “mathematically sound and computationally practical solution” to time stamp information (Stuart & Stornetta, 1991). It gained popularity in 2008 with the introduction of Bitcoin, swiftly followed by other crypto currencies. In this document, I am going to evaluate the benefits of blockchain based ledgers in comparison to traditional data storage methods. I will present the dangers associated with this powerful technology and provide implementation recommendation to businesses considering its adoption.

My research method describes the following:

  • Technical limitations of blockchain ledgers,
  • Differences between blockchain and cryptocurrencies,
  • Comparison of blockchain and database systems


In recent years, we have observed two emerging trends in the world of software development. The first one is a growing use of data access abstraction layers – most notably ORMs  – which shifts software design more into database agnostic territory. The second one is an increased adoption of new technologies by the finance industry, traditionally associated with more conservative approach to IT.

Combined, these two factors set a stage where blockchain based ledgers can find their way into the backbone systems of high street banks, insurance companies and investment brokers. At the same time, this appraisal from Fortune 500 companies creates a very powerful publicity. Unfortunately, this setup makes it a perfect tool for taking advantage of unsophisticated investors, who – fueled by FOMO  – would often give credence to blockchain based developments. The media hype surrounding cryptocurrencies makes it a perfect vail to cover shortcomings of otherwise unsustainable business plans.

With that said, I believe it’s a revolutionary technology, which – if implemented correctly – can deliver tremendous benefits to financial industry. It is built on principles of trust and coherency, similar to monetary systems, which makes is a perfect candidate for transactional ledgers and systems of record. It can significantly reduce the costs of verification and networking (Church, 2017).


First and foremost, blockchain will not guarantee success of a flawed design. Apart from a narrow field of ventures which actually deal with blockchain itself (exchanges, software libraries, APIs, etc.) it should not be advertised as a core feature of a proposed product. The biggest names in finance which incorporate blockchain for digital settlement purposes hardly ever mention in to their own clients.

For instance: in December 2017, there was a lot of media activity surrounding an implementation of enterprise blockchain network by American Express and Santander UK. The provider of said network, a company named Ripple, experienced a massive growth of their cryptocurrency value (XRP), even though they made it clear that this currency will not be used directly for settlements. As far as the two exchanging parties are concerned, the British website of Santander does not mention blockchain at all and searching for this phrase produces no results. Similarly, blockchain is not mentioned anywhere on AMEX homepage and its presence is limited to two articles buried in media release archives.

This example stands in a stark contrast to most ICOs , who in their marketing efforts emphasize the role of blockchain and the featurs in provides those startups with: most commonly “decentralized”, “distributed” and “transparent”. These features, despite being useful from the IT point of view, hardly ever directly present an added value to a product’s consumer. If a project does not appeal to its customer base or is an outright fraud to begin with, then the use of blockchain will not make it successful.


Another popular misconception is that projects which implement blockchain always emit and trade their own cryptocurrency. While this holds true for ICOs – which is how they raise money – it is not a requirement.

Blockchain technology provides businesses with coherent and – if the implementation is correct – transparent and distributed ledgers. Cryptocurrencies are just one of many possible use cases for these transactional logs. In fact, most if not all Fortune 500 applications are internal, where blockchain ledger is used in a closed environment as a private system of record for participating peers.

One advantage of blockchain is that it can be considered a “future-proof” technology, where a company – or a group of businesses – decides to open their settlements to third party participators. In such cases, potential investors gain access to an already established environment with full track record on file and guaranteed consistency of data.

Still, it is entirely possible for a company to implement blockchain and never involve itself in currency emissions or exchanges. This effectively reduces its exposure to any possible detrimental events associated with cryptocurrencies to almost zero. Most of the cryptocurrency frauds could be categorized into three basic types:

  • Exchange scam/hack – a balance of crypto- and/or fiat currency is removed from a blockchain exchange due to fraud or exploit.
  • Money laundering – due to open nature of most crypto currencies like Bitcoin, it is very easy to transfer value worldwide and hide its criminal nature. There are currently numerous tracking strategies attempted by various entities – from corporations like Chainalysis (contracted by Europol to combat money laundering) to educational institutions like University of Nottingham, who designed a “tainting” scheme, allowing them to follow up the coin trail within a blockchain.
  • ICO frauds – new products are introduced to the market and participation coins are offered to public for purchase. These “initial” coins are expected to gain value as the product enters its production phase. It is fairly easy to design a pseudo-product, either not developed at all or given minimal attention, and market it to not sophisticated audience as the next big revolution in its field.

In my opinion, these threats will not be gone anytime soon. Exchange attacks are of the same nature as conventional bank hacks. ICO frauds are nothing new, either, and are simply online renditions of “pump and dump” and “petty stock” scams. Money laundering cannot be fully eliminated, either.

Due to the underlying nature of blockchain, where every wallet is a de facto key used to submit instructions pertaining to available coin balance, it will always be possible to transfer coins without ever removing them from the digital ecosystem. High entropy asynchronous coin mixers are also getting more advanced, making the task of following funds almost impossible.

It must be emphasized, that none of these threats are native to blockchain. It is only the act of currency trading which exposes financial industry to these risks. And with the support of industry leaders, safe transition to Blockchain for smaller businesses has never been easier (Kanal, 2017).


As a software building block, blockchain provides incredibly powerful and unique set of features, which can boost security and transparency of financial institutions.

The most basic system of record used in commerce are relational databases (a.k.a. SQL). They have been around since the 70s and are critical part of virtually any business software. Data is stored in tables resembling Excel spreadsheets which are interconnected using “foreign key” columns – simply a reference to a unique value from another table. Relational databases are vastly common in financial systems, with numerous commercial implementations (most popular ones are Oracle DB and Microsoft SQL Server), enormous customer base and constant development. However, due to their design they are not easily adaptable to distributed “cloud” systems of the 21st century. Because each table’s key must be unique and sequentially consistent, expanding the database to multiple read/write nodes (known as “master-master replication”) is not a trivial task. There have been many attempts to address this issue, but they all require additions to database engines and might call for performance and application design compromises.

Another type of data storage – very common in big data applications – are non-relational databases (a.k.a. NoSQL). They gained popularity after 2010, with the introduction of cloud hosting and distributed systems. Fundamentally, NoSQL databases are key-value document storages with no foreign keys, which makes them ideal candidates for multi-node environments. Apart from big data, they are very popular in embedded systems (like software defined networking controllers) and social networks (graph databases). Unfortunately, they are not designed to handle transactional data and cannot guarantee data consistency between consecutive records.

Blockchain is an ideal candidate for transactional data. By design, it eliminates the problems of both SQL (lack of scalability and distributed modes) and NoSQL (no data validation) databases. Contrary to databases systems, it is not possible to amend records in previous blocks without invalidating its signatures. In addition, chain branching algorithms act like a distributed network of transaction guards, making sure that only signed orders are accepted by the ledger. It has been deemed “secure and incorruptible” by numerous auditors, scientists and experts in cryptography (McDonald, 2018).


As with any other technical tool, there are certain aspects of blockchain networks which must be considered prior to implementation.

Most importantly, a business must decide between a self-hosted closed access environment and an open network of blockchain peers. While the latter option introduces additional dependency, it provides its users with transparency and security of a distributed system. The use of an open network provider does not mean that blockchain ledger will be traded on exchanges. In fact, many commercial blockchain operators enable fully private tokens or individually designated trust levels, which allow for internal settlement systems to be hosted.

Disaster recovery plans must also be considered. While anyone can download and keep a complete copy of any blockchain, business continuity also depends on software libraries, APIs and web hosted wallets. For commercial blockchains, I recommend choosing one that publishes its complete software stack as open source, which would allow a business to continue in the event of a total network collapse.

Finally, there is an aspect of transaction times (a.k.a. Average Confirmation Time), which determines how long it takes for the blockchain network to accept and verify a newly posted transaction. This parameter is usually determined by the nature of a blockchain network: mined currencies tend to have longer times because of the increasing difficulties, while commercial chains could have it reduced to almost real time. Confirmation Times turned out to be a big issue for Bitcoin, as they peaked over 10,000 minutes in January 2018, de facto paralyzing the network.

Acceptable times depend on the nature of transaction handled by blockchain: high value low intensity transfers – like property purchases, issuance of insurance policies – can take over an hour. Retail payments should be cleared in seconds. For internal settlement applications it is commonly expected that confirmations take less than 5 seconds.


The built-in features of blockchain should appeal to any financial institution concerned about the safety and consistency of its records. While it’s not a direct database replacement, it provides a natural environment for transactional data.

Openly tradeable cryptocurrencies use blockchain but are not required for internal settlement applications. Most threats associated with blockchain only apply to currency trade and not its underlying technology. It is universally agreed that revolutionary ideas usually outpace legislations, as it’s the case with blockchain (Kaushal & Tyle, 2015). This is natural and should not be considered a reason not to adopt blockchain.

I recommend blockchain implementations based on thorough due diligence of a selected provider, their software stack and track record. It should be considered a supplement to an existing IT ecosystem rather than a foundation of new commercial products.


Church, Z. (2017, 05 25). Blockchain, Explained. Retrieved from MIT Management Sloan School:
Kanal, E. (2017, 07 24). SET Insights. Retrieved from Carnegie Mellon University:
Kaushal, M., & Tyle, S. (2015, 1 13). The Blockchain: What It Is and Why It Matters. Retrieved from The Brookings Institute:
McDonald, R. (2018, 1 3). How Blockchain Could Radically Alter Global Finance. Retrieved from KelloggInsight:
Stuart, H., & Stornetta, S. W. (1991). How to Time-Stamp a Digital Document. Journal of Cryptology, 99-111.

Leave a Reply

Your email address will not be published. Required fields are marked *