MICHAEL MCFALL CTO, THE ONLI CORPORATION
Aug 2nd 2018
MICHAEL MCFALL CTO, THE ONLI CORPORATION
Being able to make a coin, record it on a blockchain, and update changes to that blockchain for a fee, does not a business make. In the next few articles we will explore a few of the other factors that need to go into a technology choice.
The CTO of a financial services business is tasked by the CEO to sift through all the hype around blockchain and see if the technology can be used to offer a new product to their customer base. Technology choices have long term consequences therefore hype and “me too” atitude may be great in marketing but when you have to depend on a technology everyday, when your business depends on it, when your future depends on it, you will need to base your decisions on a little more than just headlines.
At it’s most basic level, a fin-tech business is based on transactions: transactions between partners, owners of assets and other parties peripheral to the financial transaction. How you define a transaction is therefore critical to the technology choice. There are three fundamental questions that need to be answered in order to complete a financial transaction.
How is ownership of the asset being transferred validated prior to it’s transfer?
How is the transfer of ownership recorded and accomplished in a cost efficient, reliable and verifiable manner?
How is the finalized change in ownership validated such that the compliance officer and legal counsel are provided with the required legal documentation of the transfer?
The core function of a CTO is to convert business processes into cost effective and verifiable technology processes. In our scenario, that function is around supporting the delivery of a financial products and services. Business processes are a collection of related, structured activities or tasks that when executed in a specific sequence produce a service or product for a particular customer or customers. This collection of linked and inter-dependent tasks are in fact transactions, where a transaction is an agreement, contract, exchange, understanding, or transfer of cash or property that occurs between the financial institution and their customers and/or partners resulting in a legal obligation. (http://www.businessdictionary.com/definition/transaction.html). This legal obligation must be audit-able, verifiable and legally defensible.
Core Business Processes
A financial services business is, at it’s core, a set of business processes, each of which represent a structured collection of interdependent tasks, resulting in the delivery of a product or service to a customer. Depending on the product or service being delivered, this ‘structured collection of interdependent tasks’ can happen in real-time or across a period of minutes, days or weeks. These tasks are interdependent in that if any single task fails, the entire process (or transaction) is either returned to it’s initial state, or to a previous state, whereby it can be resumed or be re-initiated from the beginning.
An example of a human real-time transaction is the withdrawal of cash from an ATM. The user inserts their card, requests a specific cash amount, and the ATM interacts with remotely connected servers over a network to debit or advance the cash to the user. In computing science, this is the simplest example of what is called a distributed transaction.
A real-estate purchase, where there are many different parties involved (lender, title company, buyer, seller, property inspector, county records, escrow company, etc.), each of which must succeed before the final exchange can be committed to the county records, is an example of a long-lived, distributed transaction.
These types of transactions are at the core of any financial services business, and are expensive to implement (people, technology, relationships, time) and represent risk in terms of legal liability for the business. These transactions, and the systems that implement them are highly regulated and audited. Since these transactions can be of high value, they also represent an exposure to fraud and theft. Since these systems are profitable to hack, they require the highest levels of security, while offering transparency for both regulators and a clear documentation trail for use in case of legal challenge.
Transaction Business Process Design
A distributed transaction can be one of two types. The first is simple transaction which is a single database transaction involving two or more network hosts: the client making the transaction request (the ATM in our example) and the database server (where the account ledger entries are recorded). There may or may not be multiple intermediate network hosts that pass the transaction request on, or record the results of the transaction for reporting and compliance purposes.
The second type of transaction is called a long-lived transaction, sometimes referred to as a ‘saga’. These long-lived transactions span multiple database transactions. A long-lived transaction can be thought of as a sequence of database transactions grouped to achieve a single atomic result. The real-estate example is such a long-lived transaction, where multiple partners enter data into their systems, and a single ‘atomic’ result, where ’atomic’ means that the transaction as a whole has been committed to the record. When the transaction is complete, it is a single, legal transfer of property, with all recordings accessible and verifiable.
An example of a long-lived transaction in the world of crypto-currencies is the exchange or transfer of bitcoins. A user logs in to a bitcoin exchange and places an order to purchase a single bitcoin ($8159 at todays price). The user provides an account from which the purchase price can be debited, either via ACH, wire transfer, direct account debit (funds on deposit at brokerage selling the bitcoin), a debit/credit card or a transfer of crypto-currency of another denomination. (6 potential different participants in this single transaction, all of which represent independent sub-transactions).
After the debit transaction (external system) has succeeded, the bitcoin purchase request is submitted to the bitcoin blockchain. This is the long-lived portion of the transaction. The transaction request goes into the transaction request queue of the nearest bitcoin network node(s), and depending on network load, may or may not be processed in the next block. Due to the design of the Bitcoin network, the transaction is not considered to be reliably committed until at least 7 cycles (each 10 minutes long) have transpired after the transaction request has been accepted. Best case, this long-lived transaction has been open and processing for at least 70 minutes.
Once the transaction is verified (using the bitcoin plain text protocol), the transaction is reported as complete, and recorded in the exchange database, allowing the user to view their transaction record. Note: this transaction record is managed and recorded using traditional technology, and is entirely independent of the transaction recorded on a blockchain network. At least 5 separate databases are involved in this transaction:
The user login and authentication system, required to verify who is requesting the Bitcoin purchase. Depending on the regulator/compliance enviroment, this authentication system may or may not be connected to the institutional KYC system.
The system reporting proof of funds used to purchase the bitcoin (often external business partner)
The system used to debit the funds used to purchase the bitcoin (again, external like ACH, wire, etc)
The Bitcoin network
Internal reporting system for recording the transaction.
If anything fails in this structured set of tasks, the system (including all sub-systems) must be returned to their original state. This is a complex transactional design problem. Implementation of such systems require experience and thorough testing and review of the underlying code. These systems are of such critical business value, that they are typically classified as trade secrets and are not put into open source repositories, due to the liability associated with their failure.
Security Token Transactions
A security token represents traditional, private security interest. Such a token can represent a share in a company, an LP interest in a fund or a trust, a member share in an LLC. Essentially, something that today exists on paper and putting an electronic wrapper around it(http://fortune.com/2018/05/18/security-token-harbor-ceo/). For the security token use case, there are additional steps:
KYC – is the user qualified to purchase the security token?
Provide proof of ownership of the actual asset.
Record the ownership change of the actual asset.
All of these tasks (a distributed transaction is defined as a collection of structured, inter-dependent tasks) are performed in the context of an existing traditional financial services processing platform. These platforms are designed and implemented to provide the critical piece of a security transaction: proof of ownership. Proof of ownership is what securities transactions are all about. These transactional systems must be able to accomplish four critical processes for each and every transaction:
Who is requesting the transaction (who is the new owner)?
Who is the current owner of the asset?
Transfer the ownership in a regulatory compliant manner.
Provide complete documentation to meet the requirements of the legal obligation represented by the transaction.
The security token use case adds additional layers to a distributed transaction, with multiple network hosts (and their potentially layered, transactional systems) participating in the long-lived transaction. All these sub-systems must be able to be returned to their original state if the transaction fails.
Ground up Implementation
If a system were to be designed from the ground up to implement long-lived, multi-node, distributed transactions using blockchains, it would have the following features:
Secure user authentication to establish ‘who’ the owner is
Secure transport layer for all system components, including client applications
Centralized Logging Service
Sub-system logging and rollback
Sub-system interfaces for recovering initial state
Integrated Customizable Reporting systems
Layered architecture, separating Marketplace (buy/offer/transfer), Exchange (order matching, transaction processing) and Treasury (integrated ownership management)
Internal Blockchain to guarantee finality of transactions
Verifiable proof of ownership system, independent of external blockchain vulnerabilities (fork, 51% attack, wallet attack)
Integrated long-lived distributed transaction manager.
Extensible, micro-services architecture for adding functionality
External API for both incoming and outgoing sub-transaction systems.
Those are the design principles used by Onli (http://onli.one), a blockchain infrastructure, built to make developing and deploying blockchain applications frictionless. Onli was designed, from the ground up, to make issuing an asset backed token painless. Security Token marketplaces and exchanges are designed to allow users to buy, sell and transfer ownership of their assets in a quick, reliable, low-cost (low friction) manner. Ease of use, and confidence in the result are paramount in the financial services arena. ONLI was designed for exactly these application.
Here are some questions every customer thinking of a purchasing a blockchain based security token should ask:
How are users identified before they can place buy/sell/transfer orders? Is it reliable? secure? hackable?
How is ownership validated and verified in the case of blockchain network failure? fork? 51% attack?
Who is liable in case of such a failure?
What regulatory systems are in place to protect the user?
How long does a transaction take?
How much does a transaction cost?
Distributed Transactions Are Hard
Long-lived distributed transactions are harder. Building a long-lived distributed transaction manager is expensive. These transaction managers are valuable and very specific to individual enterprises. Building a secure identity management and authentication system is expensive. While one can be bought off the shelf, it is expensive, and will need to be customized for financial services. Building a compliant blockchain system is going to be expensive.
The Onli Solution
The ONLIone solution can answer the CTO’s questions: Who owns the asset? How does the asset get transferred efficiently and correctly? and How can we provide the compliance and legal departments what they need?
Who owns it is answered by both the powerful and secure Onlime™ identity management system. Transfer of asset ownership is accomplished quickly and efficiently using the ONLIone suite. ONLIone comes with an integrated long-lived distributed transaction process. ONLIone developer program also insures that an in-house DevOps team can build custom micro-services to integrate compliance and reporting systems for any business process. In this way ONLIone can meet the needs of the compliance and legal departments.
ONLIone is the only blockchain based system available in the market today that meets all the requirements of financial services applications: Integrated, blockchain based user authentication and identity management, distributed ownership validation, single source liability control, custom reporting design, high-speed low-cost transaction and designed from the ground up to manage long-lived distributed transactions.