In blockchain and cryptocurrency news, nine of the world’s biggest banks form a blockchain partnership and join forces with New York-based financial tech firm R3 to create a framework for using blockchain technology in the financial markets. The parties call out 'eliminating friction and transaction costs' as their main focus. Especially interesting for the Australian market is that CBA is in the mix. See also Global Investment Banks Back Blockchain Initiative. As an aside, it's worth unpacking where these 'transaction costs and friction' come from: mostly legacy infrastructure, servicing, and sclerotic processes. It will be fascinating to see how (or if) this initiative addresses legacy, which is where the real problems lie.
There is a lot of talk in payments, and fintech more generally, about what APIs are, and how they can help organisations expose their capabilities both to internal consumers, and externally to third parties. "Full Stack Banking: How Fintech Will Fuel API-Based Competition" talks to how unfavourable economics end up being one of the primary challenges facing partial stack fintech firms. See also Chris Dixon's views on what makes a full stack startup.
Can banks be programmable? Here's some thoughts on how APIs can help.
According to this LexisNexis 'True Cost of Fraud' study, retailers are losing 1.32% of revenue to fraud, which is up 94% from 2014, where the number was closer to 0.68%. That seems like a big increase, mostly arising in international and mobile commerce transactions.
Two billion is a very big number. Particularly when it's counting the number of lines of code in a software system. Apparently, Google has 2,000,000,000 lines of code across all of its services, which is a simply staggering number. For comparison, Windows is about 50 million lines of code, which is approximately 40 times *smaller* than the Google codebase. Given the problems that financial services organisations have with legacy systems significantly smaller than this, perhaps this is further evidence that the real problem with banking is management, and not technology.
Bain & Company have some thoughts on navigating turbulence in the payments ecosystem. The report asks the question: can payments organisations make the shift from financial utility to a technology-focussed partner. Sadly, the realisation that banking is bits is lost on a lot of old-school bankers.
Canada is the latest country to take a look at how the payments landscape is changing. The CPA is taking an holistic approach, which appears to mean that they are going to take advice from industry experts, inspect some research, and have a look at what the rest of the world is doing. Sounds eminently sensible.
Just because you have an online channel doesn't give you the right call it digital banking. Or so says Frank Schwab from FinTech Forum. The article reiterates how customer-first, straight-through processing, and agility drive towards digital banking. There's not a great deal of new stuff here, but the '8 dimension framework' is a handy way to think about the differences between 'online' and 'digital banking'.
- Data is not an asset, it's a liability
- Full stack startups
- API First with RAML - Development and Documentation of REST APIs
- Fintech Glasnost: Why U.S. Banks Are Opening Up APIs to Outsiders
The RESTful API Modelling Language (RAML) is a simple and succinct way of describing APIs. It's not the first of these to come along, but it does have a user-centric approach that makes it worth a look.
And finally, here's some notes on using rails-api to build an authenticated JSON API with Warden.