Community
There’s a lot of discussion surrounding the utilization of distributed ledger technology within the traditional financial services industry, and how the combination of regulation and digital identity will work to shape these systems moving forward.
Given Netki’s involvement in these discussions and projects, I wanted to share some thoughts on why I think the establishment of a unified digital identity management system and the utilization of distributed ledger technology within the regulated financial services industry presents such an exciting opportunity, and highlight the significant challenges that need to be overcome in order to move past the computer-science experiments, and into the real-world deployment of in market applications.
Banks, Distributed Ledgers, & Bitcoin
In their March, 2016 Global FinTech Report, PricewaterhouseCoopers found that while a majority of their respondents (56% of C-level FS executives in a global survey) recognize the “importance” of blockchain technology, most (57%) still say they are unlikely to respond to the trend at this time. Moreover, very few considered themselves to be “experts” on the tech, with 83% of respondents categorizing themselves as only “moderately familiar”.
“This lack of understanding may lead market participants to underestimate the potential impact of blockchain on their activities.”
Still, even in this ‘wait and see’ environment, a number of financial institutions have signed on to initiatives, such as R3CEV (over 40 banks, including Citi, Wells, Barclays, CBA, and others) and The Hyperledger Project (FIs like J.P. Morgan, BNY Mellon, and State Street), that aim to use distributed ledger technology to replace certain systems/processes, in an effort to cut costs and ‘disrupt’ themselves from within.
The general idea, as Richard Brown, R3CEV CTO puts it, “is to move from each firm having its own systems of record to having systems of record at the level of the industry”.
Unlike Bitcoin, these systems will be ‘permissioned’ such that only certain actors can secure and/or access the network.
Why financial institutions are still looking at integrating with open networks like Bitcoin
Before delving into a discussion about the challenges and potential solutions associated with providing services that utilize open blockchain-based payments networks like Bitcoin, I first want to highlight some of the reasons why the technology presents FIs with such an exciting opportunity.
While FIs have been most actively exploring the use of permissioned distributed ledger solutions to dramatically reinvent certain aspects of retail banking, it is unclear how this will impact (if at all), their ability to provide services, such as cheaper, faster payments in currently underserved markets (largely in the developing world).
It’s easy to get identity info from your own customers, and correspondent banking allows financial service providers to ‘know’ the customers of other institutions that they have a relationship with. But without the ability to easily perform proper customer due diligence on parties at the remote end of transactions (those who are either unbanked, or use an institution outside of the sending institution’s corresponding network), these kind of transfers are ultimately too risky and/or costly to present commercial banks with a viable business opportunity.
From a compliance standpoint, they still need to ‘know’ something about the recipients at the remote end of ‘high risk’ transfers, and even if certain processes can be streamlined through the use of shared, distributed ledgers, it only helps those who already have access to FIs that act as “shared ledger providers”.
This is not to say that Bitcoin can act as some sort of “silver bullet” for the establishment of formal financial services in underserved markets. Challenges surrounding scaling still need to be overcome, and top down approaches to ‘banking the unbanked with Bitcoin’ that fail to properly assess and understand the consumers and communities they are trying to reach, will likely leave Bitcoin as a solution looking for a problem.
While there are certainly challenges to overcome, we are already seeing how companies like Bitex.la in Argentina and BitPesa in Kenya have worked with, and learned from their customers/communities to provide solutions that solve real problems using Bitcoin (such as utilization of BTC as a type of intermediary currency for foreign currency exchange).
Startups like these are paving the way for the type of bottom-up approach that lends itself to this kind of innovation, and the open nature of Bitcoin allows for the type of ‘permissionless’ innovation that can yield novel approaches to long-standing challenges.
Still, there is a lot of room for a symbiotic relationship between Bitcoin and the legacy system: banking relationships remain critical for Bitcoin services that act as exchanges (BTC ←→ Fiat), and smaller Bitcoin startups based in underserved markets have a leg up in their ability to more rapidly assess customer needs and adapt new technologies to suit their needs. Strategic partnerships between the two hold the potential to create a virtuous cycle in which both FIs and Bitcoin startups/technology providers can gain access to new (lucrative) business opportunities and (HUGE) customer bases that would have previously been highly difficult, and in some cases, impossible for either of them to break into on their own.
From Max Tannahill, Business Change & Implementation Manager at ANZ:
“Integrating consumer accounts with the ability to send and receive Bitcoin would immediately deliver benefits to users they will only seek out themselves when the technology becomes more widespread.”
“Bitcoin may offer the realisation of the internet-specific method of payments envisaged in the original application protocol (the 402 code) for the World Wide Web, a need that will only increase as the world becomes increasingly connected. There is no way correspondent banking can handle this for users in a manner comparably efficient or secure.”
If the future of financial services involves a ‘platform’ model in which banks provide more “holistic solutions by tailoring their offerings to customer expectations”, we can start to see how the ability to digitally send value to anyone in the world on an open network like Bitcoin can play a role in the full realization of customer-centric banking solutions.
Why FIs Haven’t (Really) Experimented with Bitcoin (Yet)
Putting things like brand image challenges and conspiracy theories aside, what characteristics of open payments networks like Bitcoin are currently incompatible with the highly regulated financial services industry?
Licensed FIs have gained the de facto and de jure blessings of central banks, governments, and regulatory regimes to act as the effective gate-keepers for a financial system that fits in with “how government and law enforcement want money to move”. This includes strict adherence to AML/KYC regulations, which require FIs that act as ‘Money Transmitters’ to have a certain level of information about the ‘identities’ of each party to certain ‘high risk’ transactions.
Bitcoin allows users to transfer tokens of value to anyone, via their public wallet address. Transactions are confirmed by a ‘decentralized’ (in the sense that anyone who has the CPU powercan contribute) network of miners, and logged publicly (and permanently!) on the Bitcoin blockchain with the wallet address of each party to the transaction, the amount transferred, and the time it was posted.
While the use of public wallet addresses (like 1CpLXM15vjULK3ZPGUTDMUcGATGR9xGitv), which carry no identifying information about their owner, help preserve the privacy of end-users whose transactions are posted on a permanent, public ledger, the ability for an individual using a Bitcoin wallet to send funds to any wallet address (without any other identifying info pertaining to ‘who’ the recipient is), places open payments networks like Bitcoin in direct conflict with certain reporting requirements for money service businesses, as prescribed in current AML/KYC regulations.
Even if a Bitcoin wallet service KYC’s all of their own users, it is (currently) impossible for them to operate a completely open Bitcoin payment service, and be in full compliance with regulatory requirements, because the remote end of the transaction has not been identified.
From PwC Director of Blockchain & Anaytics, Ajit Tripathi:
“R3 and Bitcoin are not competitors. R3 are looking to offer alternate technical architectures for regulated financial markets whereas Bitcoin has been built for censorship resistance in an extreme environment of distrust (otherwise known as the internet).”
“That begs the question. What does REALLY make Bitcoin unsuitable for regulated financial services. Is it anonymity? Is it censorship resistance? Something else?”
“The flip question is... what's the ONE thing that underlies the foundation of modern, regulated financial services?”
“That one thing is DIGITAL IDENTITY and here's why:
Finance = Money = Distrust => It's All About The (Not Yet) Bad Guy”
This leads to an important conclusion: while Bitcoin has been built to facilitate open, peer to peer payments by keeping track of who has what through decentralized consensus, the Bitcoin blockchain alone cannot provide a record of ‘who’ that is compatible with how government and law enforcement want money to move.
Distributed Ledgers & Digital Identity
Digital Identity solutions allow FIs to ‘know’ certain things about the parties to transactions conducted online, and therefore comply with AML/KYC reporting requirements.
As Brown puts it:
“[A] key theme is that we’re thinking about identity all wrong. Most of the time we think we need to know who somebody is, what we actually need to know is something about them:
A bartender doesn’t need to know your name and your home address; they just need proof you’re over 18.
A UK doctor doesn’t need to know what town you were born in to know if you’re entitled to free healthcare.
… and so on"
In the regulated financial services industry, the particular info that FIs need to ‘know’ about their customers and the parties they transact with is dependent on, and corresponds directly with, the amount of ‘risk’ involved in the transactions initiated. This ID info must come from a ‘validated’ source, and be exchanged between parties (and their service providers) before transactions can take place.
What constitutes a valid form of digital identity that can be used to by licensed FIs for this purpose?
The key here is that we’re talking about digital identity for the purpose of complying with legal requirements.
In order to comply with California state laws, bars/restaurants can only serve alcohol to individuals that are at least 21 years old. While a bartender only needs to know that I’m 21 or older to give me a drink, she must confirm this information by checking my legal, government issued ID. I can’t, for example, present a signed note from my parents that says “Hey, I’m 21!” or show them my birthday on my Facebook profile, and expect that to constitute legitimate proof about my age.
This type of ID validation is easy in person: a bar bouncer can always use a blacklight, scanner, etc. to determine that I’m presenting a valid, government issued ID, but how can you create the equivalent to this in purely digital environments?
The short answer is that for digital identity to be legally valid, it must establish non-repudiation, ie the data that it represents about a party can be inextricably linked to a physical identity that is recognized by the applicable legal framework:
“The essence of Digital Identity is that it must provide the legal basis for asset ownership, accountability for liabilities, and dispute resolution in a civil or criminal court of law.”
Breaking this down further with another example:
As part of an FI’s e-banking platform, they need to (for compliance purposes) know the name and address of everyone that participates in transactions. How can this data be authenticated in a way that can’t be tampered with, and is inextricably linked to physical, gov issued ID credentials? We see here that while “authentication and identification are interlinked, they are not the same thing”.
This brings us to the essence of what constitutes a valid digital identity. From the UK Government Office for Science Report on Distributed Ledger technology:
“Authentication does not require that I know your identity but it does require that you provide me with a token that is inextricably linked to your identity.”
In addition to challenges surrounding the authentication of identity data for parties at the remote end of transactions, there are also serious privacy concerns surrounding how MSBs operating distributed ledger platforms can ensure that sensitive data, such as identity information, is not recorded on any type of permanent (in the case of Bitcoin - public) ledger, accessible to a group of actors with potentially competing interests.
With Bitcoin, we can imagine a system where ‘identity tokens’ are linked to users’ wallets, and transferable between parties over private, off-chain channels.
This addresses the challenges surrounding Bitcoin compatibility with regulated financial services in a couple of interesting/significant ways:
MSBs no longer need to collect all of the data pertaining to the identity of parties at the remote end of transactions; and instead, only need to confirm that such parties have an applicable validated identity token.
Example: Regs require Name, Address, and [something else] for crossborder transfers between $200-500 (US) ; A ‘level 1’ ID token validates that at least Name, Address, and [something else] have been authenticated. MSBs can allow their customers to transfer this amount to any Bitcoin wallet linked to a ‘level 1’ ID token.
Authentication of validated ID info pertaining to parties at the remote end of transactions that preserves end user privacy by keeping sensitive ID data off-chain
Again from the UK Report:
“The opportunity in the digital environment, is to use and create much more powerful and robust identity management tools that provide authentication whilst protecting privacy. One such system is public key infrastructure (PKI) relying on a cryptographic standard called X.509. Organisations using PKI can federate in order to provide, share and potentially simplify the secure delivery of services or products.”
But there are still some important questions:
Who can provide ID tokens that will meet the criteria of regulators/enforcement agencies?
What technologies can be employed to inextricably link ID tokens to a person’s legal identity, in a way that credibly establishes non-repudiation? What methodologies can be used to transmit the required regulatory user data while ensuring privacy protection?
From Brown:
“What these concepts all have in common is that they have this idea of a “certifier” – somebody or something that:”
Is trusted by the issuer
Ties something I have (my face or my blockchain address) to something I am (“over 18”, “a holder of a US bank account”, etc)
If you trust the certifier then you can trust that somebody proving ownership of the face or the address is over 18 and a holder of a US bank account, etc.”
We can gain some insight into how a digital identity provider in this context would need to operate to constitute this level of ‘trust’ from principles that govern traditional e-banking.
From the Basel Committee on Banking Supervision ‘Risk Management Principles for Electronic Banking’:
“Banking organizations have begun to employ various techniques that help establish non-repudiation and ensure confidentiality and integrity of e-banking transactions such as digital certificates using a public key infrastructure (PKI).”
“A bank may issue a digital certificate to a customer or counterparty to allow for their unique identification/authentication and reduce the risk of transaction repudiation.”
“If a bank is to rely upon a 3rd party digital certificate to establish authenticity, it should confirm that the Certificate Authority, when issuing the certificate, used the same level of authentication that the bank would have used to authenticate the person.”
Now we have a (high level) model for a digital identity system that would allow regulated financial institutions to utilize open blockchain-based networks like Bitcoin, rather than being forced to create a closed loop system in order to comply with regulatory requirements.
Trusted providers leverage established authentication standards to create legally valid, individual identity tokens
Establishment of a standardized approach for private, off-chain transfer of identity tokens between relevant parties to a transaction
Ideal approach would establish a standard protocol that allows for interoperability between a diverse set distributed ledger systems and service providers
Ability to programmatically enforce compliance with regulatory requirements
Unbundling the identification / validation process in this way allows for compliant transactions on open networks, in which users can send value to anyone (regardless of what wallet or bank they use), as long as the recipient’s Bitcoin address is linked to an applicable ID token. Moreover, by using an open, standards based approach that can adapted to any blockchain, such a system allows for interoperability between a network of ‘trusted certifiers’ (allowing for a distributed, competitive environment) and blockchain-based payment networks.
In order for something like this to be realized there will need to be a massive amount of collaboration between technology providers, auditing/consulting firms, regulators, supervisory bodies, and FIs. This will take time, but the dialogue is already in full swing, and a sound framework and significant infrastructure are already in development.
This content is provided by an external author without editing by Finextra. It expresses the views and opinions of the author.
Sonali Patil Cloud Solution Architect at TCS
20 December
Andrew Ducker Payments Consulting at Icon Solutions
19 December
Jamel Derdour CMO at Transact365 / Nucleus365
17 December
Andrii Shevchuk CTO & Co-Partner at Concryt
16 December
Welcome to Finextra. We use cookies to help us to deliver our services. You may change your preferences at our Cookie Centre.
Please read our Privacy Policy.