Disruptive Technology

Bitcoin and Ripple – Searching for a good problem …

/ Leigh / Leave a comment

At the risk of sounding like I have an ‘unconscious bias’ against disruptive payments tech such as Bitcoin/Blockchain/Distributed Ledger, I have to say, at this stage I don’t believe that these technologies are ready for banking prime time – yet.

So why would I even say this anyway? Why am I interested enough to even write this?

Because I believe that the blockchain and distributed ledger tech have significant and substantial promise, but I think more work needs to be done on making the underlying technology ‘industrial strength’ – especially for regulated financial services.

“Come on Leigh – go back to your 16th century double entry book ledger you old relic” – I can hear them say.  And yes, I’m a banker of nearly 30 years – but my attitude has always been ‘why not?’ as opposed to ‘why?  I’m a prolific tech early adopter and constantly thinking of ways to improve the client experience especially in corporate payments.

I’m also a little tired of the hype created by the marketing engines of certain fintech companies looking for a large reputable financial service organisation to grab the technology, run with it and blatantly disregard the impacts of the deficiencies in the ‘current’ iteration of the technology. The hype just doesn’t help. It breeds conversation such as:

CEO: “We need a distributed ledger”

CIO: “Why?” ….

CEO: “because everyone else is talking about it”

CIO: “what will we use it for?”

CEO “that’s your problem”.

I almost feel like that we are searching for the problem (in other words a “good use case”) that these solutions have been created for. It so frustrating. I mustn’t be the only one thinking this however, have a look at this tweet.

Every day I read something that indicates the ‘promise’. Maybe that’s the frustrating part. Its like the search for extra terrestrial intelligence. We know its got to be out there somewhere but we just can’t find it yet – or the challenge of exceeding the speed of light – we stand back and marvel at concepts like “warp” from Star Trek and wonder how we will ever get to travel beyond that barrier. We have a stab at what the problem is because we already know what the solution might be.

What is Bank Grade anyway?

How about this for a definition?

Bank Grade payments systems are compliant, they address real challenges, they have clear ROI, and they are scalable.

My current analysis of the ‘current’ technologies to this point shows that they fall short on some or all of the basic requirements.

I don’t intend on giving readers an understanding of what Crypto Currency, Blockchain or Distributed ledgers are. If you are here, then its assumed that you have some knowledge of it, and are at the very least interested.

Lets run the test:

Compliant?

I fear not. Transactions are anonymous for the most part (although there is of course a hash based identifier). If you can link the identifier to an owner then they aren’t anonymous anymore. But the system doesn’t know who you are and because of that they are a regulatory nightmare. With ‘unpermissioned’ blockchains (such as Bitcoin) Entry and Exit points aren’t regulated and so it is virtually impossible to complete any type of sanctions or AML type checking. Recently, for example, the Department of Financial Services in New York introduced BitLicense to try and regulate these entry and exit points. The effect of this however was that most Bitcoin exchanges left New York and set up business in a less regulated environment.

Interestingly the kerfuffle was the community wanting to preserve the ‘anonymous’ nature of the network. Sounds very bank like to me.

With Ripple – If you download the ledger you can see each and every transaction. You can see who the counterparties are, who they trust, what their credit lines are, pretty much everything. Meaning that privacy goes out the door. Do you care? Do you want everyone to see your bank balance and each transaction you’ve done? Maybe that’s not a problem for you, but banks are built on keeping your financial data private. If you know a counterparties ‘account number/hash’ then you can track everything.

Forked Ledgers also present a problem. In banking you simply can’t have two or more versions of the truth. But inside the blockchain you can …. until they resolve themselves … and when that happens you can both win and lose. Banks need one version of the truth at all times – customers expect their balance to be their balance – not a ‘version’ of their balance. A recent fork occurred in Bitcoin that wasn’t resolved for some time – if you read that article words like ‘ your bitcoins are safe if <condition> x, y z, are met’. How would you feel if your bank balance was referred to as ‘safe’ depending on certain items? Not very safe perhaps.

One final point – control. Who regulates this? Who do you go to when something goes wrong? Who is the ‘central body’ that arbitrates? The answer – for Bitcoin at least – is ‘no one’. Having said that, it is the computers that arbitrate – they decide who wins and loses. They do the math. So who owns ‘most’ of the computers – at the present time this is the domain of the Bitcoin Miners. Miners solve the cryptographic problems that validation of the blockchain require, and in exchange for solving the problems they get paid  – in bitcoins. Two thirds of mining capacity is owned by 6 mining pools, and the top 4 pools are based in mainland China – not owned by Government but by private individuals/corporations. In the network then, whomever owns greater than 51% of the mining resource controls the network. For everyone.

So, transactions are anonymous; they are unregulated; they are not private; they are not ‘safe’ in traditional terms; can be controlled if someone owns more than 51% of the network; and you can’t complain to anyone if the system doesn’t work or you lose your money.

If that was a catchline for your bank, would you put your money there?

Address Real Challenges?

The main challenge that the distributed ledger industry favourite Ripple state they address is being able to ‘speed up’ cross border payments. Why? From what I can gather because the transactions flowing can be agreed in real time including FX rate conversion, intra party accounting is completed by way of using the distributed ledger and each party uses the protocol to agree on these things regardless of the time of day.

But does that mean that you actually get your cash faster?

Now that depends on whether the receiving bank has a way of interacting with the ledger in order to deposit the funds into your account real time (taking into consideration the relative sanctions and anti money laundering filtering that Banks are obligated to complete on any incoming or outgoing transfers). For larger transfers, or where there is high volume the bank also has to complete other hygiene matters such as liquidity management for its own treasury function (which is both good governance and good cash management – but you probably don’t care about that). All you want is your money and this takes time.

But the Ripple system works on IOU’s. In other words, the ‘instruction to transfer’ is still separate from the ‘settlement of the transfer’. Ripple is an ‘instruction to transfer’ system. It doesn’t do settlement – because settlement actually needs the transfer of actual money between counterparties. Instead Ripple issues IOUs between counterparties and they must use those IOUs to complete settlement via the traditional SWIFT network. Ripple is NOT a replacement for banks to use SWIFT because that is the way Banks settle their own balances with each other. There is an exception here  – if Banks hold the actual ‘Ripple’ currency they can just settle in that.

Unless of course each and every Bank ditched SWIFT altogether and all around the world invested their funds into buying Ripples.

Ripple ignore these factors, or at the very least brush them to the side. The ‘last mile’ (in other words actually getting the cash into a consumers hands) is a challenge – for Ripple and also for traditional Banks. Ripple still needs the ‘Bank’ to execute the cash transfer, typically via traditional means.

The blockchain itself can also be used for other real world challenges – for example this is where the concept of ‘smart contracts’ is heard. Each clause is a programmatic instruction, and once signed the clauses can execute automatically – and the ledger can keep track of which clause was executed, when, and for what/to whom. The contract can be for trade or almost anything – it doesn’t just have to be used for Bitcoin (or parts of a coin).

But we have systems of record today that solve these problems – perhaps not as efficiently – but solve nonetheless. This area has significant promise though – I think that with the passage of time the underlying blockchain technology will get better and will be embraced by smart innovators who use the blockchain as a ‘building block’ for interesting application that we may not have even thought of today. In effect the blockchain will be wrapped in IP layers of value added functionality that solve real world problems by leveraging the basic framework of a programmatic decentralized ledger.

Clear ROI

It costs a lot of money to run the Bitcoin network. Bitcoin transaction processing consumes significant resources – a recent study concluded that the combined electricity consumption for all Miners was comparable to the entire energy consumption for the country of Ireland.

As the blockchain becomes longer the computing required increases to a point of diminishing returns thereby making it commercially uneconomical. That’s based on todays tech though – Moore’s law will influence here.

Even with more corporate application such as ripple, as previously detailed you still need the banking infrastructure to complete the last mile. So given current use cases there is a lot of change required (in risk tolerance, acceptance of non traditional records of truth, and removal of traditional reconciliation practices) in order to provide enough ROI to balance it all out. At present there are significant unquantified risks with no clear mitigation strategy or payoff. Bitcoins themselves are subject to extreme currency volatility (good if you’re a betting person), transaction fees are relatively high (average 2%) and variable depending on Spam (called dusting), and the FX conversion from BTC to fiat is relatively high when compared to retail FX margins.

That is not to say that there are no opportunities. The tech just has to mature. Or we have to revise the underlying frameworks to better provide for financial services use cases.

Scalable

Another bummer at present. Bitcoin takes between 10-60 minutes to validate and clear a transaction. Unsuitable when compared to a real time credit card or bank account transaction.

Additionally Bitcoin only currently scales to around 7 transactions per second (by design). That’s not very good compared to what is required from global markets (tens of thousands per second or higher). You see – Size matters. Theoretically the throughput of the system could be much higher, but it requires a larger block size. Work has been done recently to increase the speed, but that requires consensus from the miners .. and they don’t agree. Taking us back to the ‘who controls the network’ issue.

I previously discussed the electricity costs.. which will suffer from the same diminishing returns matter and is ultimately dependent on how efficiently computers can solve the mathematical problems of validating the blocks.

On the ripple side, we need significantly higher participation from traditional banks and financial institutions to provide enough scale in order to start to replace traditional systems of cross border payments, but because of the challenges mentioned previously we just don’t have the scale required.

In Summary

I’m not against the technology. I think it has massive potential … with the right use cases and with solutions to the problems presented. And for those who think I’m just an old school banker that is afraid of the potential or disruptive change – think again. The discussion sort of puts you in a combative position which doesn’t feel right. I am on the same side – I want to use the technology . If I could go to my Boss and say:

“I have a solution for you. It will save in costs, it is super efficient and scalable, will speed up payments and improve customer experience, covers the bases in terms of fraud control, sanctions and AML, and help us improve revenues.”

Do you think I would? Absolutely.

I hope one day soon I can. I just cant right now. Its not bank grade – yet. Its a solution waiting for the right problem, but the solution and perhaps the underlying framework needs more work to be better suited for robust regulated financial services.

Post Publishing Note: Ripple did this past week announce “Interledger” as a possible solution for some deficiencies that I highlight above. I haven’t done a full analysis of the impacts of that innovation, but it does look like they’ve ‘wrapped’  layer of fresh IP around the underlying framework in order to make their use case stronger. Good work Ripple!

The Opportunity in Corporate Payments

/ Leigh / 1 Comment
There is currently a significant amount of focus on consumer payments which is understandable given the success of ventures such as PayPal, and the enablement of consumers to make payments easily by way of online credit card gateways and the like. Silicon Valley payments startups are trying to capture the massive volume in enabling consumers to pay easily.

Banks used to hold this domain with their customers.

The space changed between 10-15 years ago through the rise of the internet, and the slowness of many banks to respond to the needs of business who wanted to move their business online and then needed a payments gateway to facilitate the payment. Banks started to separate the ‘capture’ of the transaction to the ‘clearing’ of the transaction.

This meant that some (but not all) Banks sent their customers to newly found ‘credit card gateway’ companies whilst continuing to offer the underlying ‘merchant’ facility to the customer. This mean that the credit card transaction was ‘captured’ by the online gateway provider and ‘cleared’ by the Bank. Online gateways were agile, could develop programming interfaces (API’s) that allowed merchants to integrate their online shopping carts with the credit card system to enable payments. Banks were typically big and slow, and whilst offering a very reliable merchant service that underpinned the card transaction, they weren’t very agile at developing on-line API’s for merchants to integrate, and were less agile (or it didn’t even fit their business model) to deliver integration assistance to their customer base.

Nowadays then, if you are online merchant the typical model is to buy your card capture product from an online gateway (or even PayPal) and have that gateway integrate with their chosen Bank’s back end merchant facility.

The Bank part is a necessity (and taken for granted), the capture part is what the customer really needs. In essence, that is the product being purchased. Online gateways have been very smart, continually adapting and offering value added services (such as card reprocessing, tokenization for PCI DSS compliance), integration services, out of the box shopping card modules and the like.

What once was the domain of the Bank has now been commoditised and disaggregated from the Bank’s own offering.

As we move into corporate payments processing, it is important to examine the way that corporations ‘tender’ their banking business to the banking community. Traditionally, a corporate would issue an RFP for the provision of banking services. A shortlist would be created, various Banks would tender and more often than not a sole provider for the provision of Transaction Banking services would be selected. That provider would normally win the right to provide core banking services (such as bank accounts, liquidity (Debt), FX) and ancillary ‘value added’ services such as payments processing, merchant processing, supply chain, corporate card programs and the like.

When the GFC hit, corporations then had to diversify their banking relationships to reduce counterparty risk. This meant that corporates had to now spread their banking services across a number of banks, each relationship meaning a new online banking site, many and varied authorisation dongles/tokens, a different bank for a different region and so on. Each bank had their own particular way of doing Host to Host services, ERP systems integration, Treasury Management, Payments processing, receivables and the like. This has created a headache for corporates wishing to be more efficient in payments and treasury operations as most banks have their ‘own’ proprietary way of achieving this processing. The industry has done its best in agreeing on new standards of processing such as ISO 20022 but not every bank has adopted these standards, and most banks don’t agree on the bilateral mechanisms residing within the standards to achieve efficiency in payments processing. In essence, each integration with a Bank is a new project.

At the same time, most Bank’s haven’t changed their delivery model of payments processing product. They still respond to tenders for Transaction Banking solutions by offering the core banking services tied in with the ancillary value added services. This then by its very nature creates a further web of a corporate having to buy its banking product from many providers to simply do business.

What if you could by your banking product from a universal/independent provider (especially in payments processing and integration) and then let that provider do all the back-end ‘stuff’ with your chosen bank in your chosen region? How would that change your perspective?

To use the previous analogy, instead of the Bank doing both the payment ‘capture’ and the payments ‘clearing’, why couldn’t another provider build a payments ‘capture’ engine and then let the chosen bank do the ‘clearing’. With the world becoming more real-time and ‘instant’ there are methods to connect to banking services now that mean that a corporate could buy their product not from a bank and instead buy it from an independent supplier that is connected to the bank for clearing.

My hypothesis then is that transaction banking payment ‘product’ (capture of the payment) will become disaggregated from traditional bank ‘clearing’ systems. Bank’s will find themselves competing with tech companies for payments processing and for other value added services that simply need a smart way to connect to the bank whilst at the same time increase efficiency and reducing complexity for the client.

This creates an opportunity for tech startups to be innovative in payments and integration processing, aggregating between banks/corporates and using best of breed agile technologies to create efficiency for corporates who just want to worry about their own business instead of worrying about the Bank processing their payments.

The opportunity in Australia alone is huge – look at the below table:

High Level Transactions Statistics (apca.com.au)

Volume Value Users
DE (Credits) 5.3m/d $24.3b 307,027
DE (Debits) 2.5m/d $19.9b 24,164
Cheque 0.7m/d $4.8b
High Value* – $96.5b
Debit Cards 312.1 m/m 18.1b/m 25.8m^
Credit Cards 164.9m/m 22.1b/m 26.5^

*These figures are values exchanged and do not include “own items”. Note also that a full picture of RTGS transactions would require HVCS transactions to be supplemented by Austraclear and RITS transactions which are not captured by APCA.

^Customer Payments Accounts cover day-to-day accounts and include: cheque, statement, savings and passbook accounts.

Banks will need to think differently about how they offer innovative product to market and the speed at which they do it. Their ability to change quickly to meet client demands will become increasingly important – especially if my hypothesis is true and they’re competing against tech companies.

Watch this space. It will be very interesting.

Same + Different = Different

/ Leigh / Leave a comment

I wrote a few weeks ago about ‘disruption‘ – insofar as the cloud impact on financial services and whether or not just having the cloud was disruptive.

However it seems that this word ‘disruptive’ is now everywhere. I have read no less than half a dozen articles on it this week alone. (For examples go here:

Disruptive Innovation in banking and 3 things that banks should do to protect themselves

The Disruption Machine

Australian Startups eyeing big bank insane profits

Its sort of like when you learn a new word and then you hear that word all the time. So this week I promise to not use that word any more in my Blog and instead concentrate on something that I’m very proud of – two Host to Host solutions that my team and I built at two major Australian Banks.

I learned recently that this years Peter Lee and Associates survey for Transactional Banking in Australia/New Zealand  listed those two Host to Host banking products as having the largest number of respondents/deepest penetration in this years survey. 92 Large Corporations responded to the questions about Host to Host, 55 of them (60%) reported using the products that my team designed and built. Of the 55 corporates, 29% reported an excellent experience, 66% reported an above average experience, and only 1 client reported a below average experience (‘rats’ on that point).

Why is this important?

Firstly, the Peter Lee survey is a measure used by all major banks in AU/NZ to evaluate their industry performance against each other in relation to Institutional Banking. Factors such as ‘Lead Bank’, ‘Relationship Strength’ etc. are highly sought after prizes. Peter Lee results are also used in marketing collateral and the like to prove a 3rd party view rather than just a biased view when it comes to RFP’s and the like when demonstrating one’s credentials.

Secondly, in less than 10 years, pitted against larger budgets of some international banks, large technology vendors and the like, our team has created now in 2 major banks arguably the best and most used ‘host to host’ platforms in use in Australia and New Zealand today. We did this with what I would call meagre (but not insubstantial) budgets and naturally a lot of hard work and dedication.

The teams collective innovativeness and experience has paid off twice now. At the start we backed ourselves in by taking a stand in what clients really wanted from a ‘host to host’ platform, and we never sought to just try to ‘buy’ it from a single vendor. In fact, we knew we couldn’t just ‘buy’ what we wanted – it needed to be created by using some best in class component products which were ‘wrapped’ together by a ‘custom’ layer. The first iteration started the journey, and we learned a lot. That product was even mentioned on that Bank’s annual report in 2010 (Page 29, look for ‘WIBS’).

Since that time we continued the journey building on the foundation of ideas that we had originally (again using best in class products wrapped with our custom but new and improved ‘layer’), rebuilding a new Host to Host product based on generic standards but stretching the innovation further (and of course customising to suit the target bank’s Environmental, Governance and Risk standards). At Bank #2 we repaid the original investment in just under 18 months from go live. Relatively unheard of in recent times for product/channel innovation in a big bank.

I had a mantra from day 1 at Bank #2 to drive people to do things differently. If you want the same outcomes, just use the same ingredients and the same recipe. If you want different outcomes you need to change the formula. Same + Same = Same. Same + Different = Different. The approach takes a while though. Old habits die-hard – slowly you can change things until they become the new normal. We wanted a different outcome – the formula works!

Where did the ‘magic’ come from though? Where does it sit now?

It’s in the people. Never underestimate the experience, value, drive and imagination of a tight group of people who understand deeply how to make ‘stuff’ happen – and who aren’t just technocrats – they are both Bankers and technologists.

To those who are or were part of the journey so far – thank you. So much has been done – we have proven ourselves, not once but twice now. Be proud as I am of what we as a collective have done – and look forward to the future.

Until next time,

Leigh

 

Disruptive Technology and the Cloud

/ Leigh / 1 Comment

I did a presentation recently in Sydney. It went pretty well, by that I mean I was happy with what I had to say (and so were others).

The topic was “Innovation in Payments” – nothing new in my presentation apart from some of my thoughts on the Australian New Payments Platform (NPP) and “Least Cost Routing”; but along the way I’ve been asked about my thoughts on disruptive technology.

Somewhere along the road I’ve also been involved in discussions around the cloud and its impact on disruptive technology.

Having said all of this I still think that the Gartner predictions are correct – INTEGRATION outside the corporate firewall over the next 24-48 months will be key to the success business’ will need in the future.

In Financial Services there will be for some time a desire to keep things in house. No surprise there. The increasing challenge will be how much of it stays in house and how much can be done elsewhere. What is at the root of this desire though – is it protection of customer data, or is it something else that needs to stay inside, and how much of it needs to stay inside? (By the way, lets stay right away from arguing with regulators – that’s an exercise in kicking yourself in the head; one where you end up with a blood nose and they end up getting new shoes).

Is it the cloud that is nasty? Couldn’t you just say that the cloud is just another name for a ‘hosted’ service, or a ‘managed service’ in much the same way that ‘Digital’ now used to be called ‘online’ and the before that ‘eBusiness’, or ‘e’ this or that. Is it any different? Really? For example, isn’t SWIFT a ‘cloud’ service? and if its not, why not? (or are you going to say that SWIFT is a ‘hosted/managed service’). Leave that debate for later.

For the time being though, lets just call the opportunity then the ‘cloud’. Forgetting about the security concerns (do they really exist anyway?) What will the cloud let us do tomorrow that we can’t do today. What is the advantage that cloud could provide us with?

Lets go through a few topics:

Governance – would that be any different? Maybe – you have different end points and your relationship with the infrastructure provider might be different – and that would take oversight. Data Realms/Sovereignty might be impacted, and Security of data, So I think Governance in the cloud would need to be increased, compared to managing your own infra on site. Maybe the controls are different – maybe thats an opportunity in its own right for a clever security/risk management provider.

Software SDLC – Dev methods would need to change. Software needs to recognise a different way of residing on infrastructure. Older stuff might be okay in terms of ‘living’ on named instances, but one of the benefits of a seemingly never-ending infrastructure capacity is that your software should be able to take advantage of infra when it needs to. Spinning up new web/app/database servers when software demands, and then turning off when not required is truly ‘on demand’. Software needs to know how to do this and more importantly when to do this. Developers need to be building hardware ‘cloud’ abstraction layers inside their apps, or abstraction layers for legacy software in order to do this. So the Software SDLC is impacted also. Unless you don’t care – which in that case don’t do a thing. React to failures in the traditional way and waste your money on traditional incident management. Get it right though and you could argue that you don’t need incident management because the incidents are ‘programmed’ in and are automatically dealt with.

Infrastructure Provisioning and Management – Biggest impact. Why would I want to own a server when I can ‘rent’ a virtual one, and only pay for the time its actually in use. Use of the ‘Cloud’ transfers often huge capex bills every 3/5 years to an opex outlay. That has good and bad aspects to it though. Opex hits your P&L in the year of build. Capex doesn’t. In some countries you can capex and not have the impact hit your P&L (by way of depreciation) until you commercialise – and that could be years away. On other matters, you can use automation tools to clone/copy/spin up new servers in minutes. You can use API’s from the Software SDLC to control them. You can use the same APIs to configure networks/firewalls and other security devices on the fly. You only pay for what you need. Giving Software developers access to infra for their stuff to live on in a timely manner is a HUGE precursor to agile innovations. This gets a big tick – but don’t forget the Governance impact above. How do you define “in the cloud” as an ‘as built’ infrastructure from a documentation level – especially when it can dynamically change so rapidly.

Reliability/Redundancy – Another big impact. Its a bit like ‘use the force Luke’. ‘Let go’, ‘Trust your instinct’. You have to trust that your provider has this in hand. Or build it in another cloud somewhere else. I think the cloud has untapped potential in increasing up time and reliability. Netflix used this to their advantage in the deployment of a Simian army (http://techblog.netflix.com/2011/07/netflix-simian-army.html) that randomly tests their environment for redundancy. Have a read – its a great concept – and they build failure into their daily life. Having to get up at 3am and fix servers and stuff has now gone away. Organisations that build this concept into their infrastructure management plans just ‘deal’ with incidents as they happen without having to worry about key services being down. Everyone should latch onto this initiative. Traditional DR will continue to serve a purpose but get the ‘link’ between hardware and software right in a way that uses the resources properly and your DR will turn into a 1 hour verification rather than a run book that humans can stuff up.

Security – An area with the biggest Question Marks. How can you transfer all of those security appliances and protections to the cloud in the same way as you can with physical. I need to do more research on this, and this is perhaps one area that lends itself to the most innovation from cloud/security appliance providers.

Cost– All of the above. You will increase costs in some areas, and decrease in others. But the decrease should by far out way the increase. Jump on it I say.

Now, thinking about all that, let’s answer the question I posed:

What will the cloud let us do tomorrow that we can’t do today. What is the advantage that cloud could provide us with?

In short:

  1. We can do everything we do today (or should be able to)
  2. We should be able to lower the cost of infrastructure, and transfer the context of its impact to the Balance Sheet
  3. We should be able to build in reliability and redundancy, making applications look like they can ‘self heal’ themselves if part of the infrastructure fails.
  4. There are questions about security
  5. We should be able to develop and deploy in a way that fits a modern AGILE environment
  6. We should be able to do all of this, ideally, at a lower cost.

But wait on, Im still missing something.

Didn’t I talk about the opportunity to do something disruptive?

The cloud itself won’t manufacture disruptive technology. You still need the ‘great’ ideas for that. The cloud however should provide a ‘platform’ for disruptive technology to live. A Launching pad. You still need the great software, the great products – but in the future they will ‘live’ elsewhere.

Enough for now.

Until Later

Leigh