I wonder what would happen if every financial service organisation in the world was required to make just six little fields of data available to customers in an automated and open standard automated feed that they could use how and where they see fit. The Six Little Fields, The key day to day transactional data of all the products mentioned above and so many more, are;
- Time
- Date
- Transaction Type (Visa, ATM withdrawal, Direct Debit etc)
- Transaction Description
- Transaction Value
- Balance of the account
There are many more fields underlying this data but these are the key display fields. To allow banking to become a greater part of the web and for this data to become the basis of a thriving ecosystem we need solutions to the following three (at least) problems;
- An open standard format for transaction data
- A method of securely linking other financial institutions or 3rd party services to financial institutions so data can be transferred between them automatically
- A subscribe model for the data that allows new items to be pushed out. Similar to RSS.
I have a handful of ideas and theories on why and how to make this happen and I wanted to share my thinking in the hope that someone out there will agree and have some better ideas along with the will to try to make it happen.
Why do I believe the six little fields are so important?
I assume that most people who own financial services products, be they current accounts, credit cards, loans, savings, insurance etc. do not have them all from the same organisation. Even though I work for a bank, and I should probably whisper this, I do not have all my products with that organisation. This is of course the benefit of a free market, competition and choice, which is a fantastic thing. The big issue from my point of view is what is known in the banking industry as single customer view i.e. the ability to see your full financial picture in one nice shiny interface. This is not a new problem in the industry it is also something I have written about before, but it is one that seems far from being solved or even on any of the banks to do list.
This is one of the ideas I am burdened with and I find myself coming back to it time and again. I think what I want to see is more web thinking applied to banking. There is a lovely quote from Ben Milne of Dwolla that sums this up nicely.
“Payment networks should have a memory. You absolutely should be able to login to Visa.com and see every transaction you have ever engaged in with a Visa card. The fact that you can’t do this is ridiculous.”
I love this quote. Those with knowledge of banking will scoff and say this is ridiculous as Visa cards are issued by a multitude of organisations and the identity of the user is not tied back. Fine, but what if…
Not only should you be able to go to financial institutions you have history with but you should also be able to build your own data stores. These six little fields would be the basis of an entire ecosystem featuring so many things that the banks would never build. This tweet from Dave Birch is a great example of those sort of things but if Dave had a feed of his six little fields he could build it himself, solving his own issue, meeting his own need.
This data and mechanisms for access could be used just as much, if not more, by the banks themselves. Today most banks have struggled with building on top of or integrating with the digital banking fortresses they have built. It is why the first generation of mobile banking apps plugged into the ATM network rather than Internet Banking because the routes for data out were easier to implement.
How do you get data out of banks today?
The six little fields listed above are the ones shown in your Internet banking interfaces. Underlying those fields there will of course be extra data required such as currency, where money transferred in came from maybe even some location data of an ATM but from a customer’s point of view the six listed above are the ones they most need to see.
Today there are 3 main ways of getting data out of banks.
- Manual download of data. This seems to be the prevalent method of getting data out of the banks, certainly in the UK. Download a CSV/OFX/QIF formatted file.
- Bespoke feeds. In the US there seems to be a high number of XML feeds in existence to get data out from banks, but they are usually bespoke formats and as such need bespoke decoding. This situation has given rise to 3rd party players such as Yodlee who have put in the hard work to decode all these formats and feeds and then provide a platform to pull them all into. This is laudable but effectively places a commercial company in a very powerful position with regards to data feeds that should be free. Barclays have an automated feed available to their commercial customers in the UK to use with online accountancy service Freeagent.
- Scraping the data i.e. giving over your username and password to a 3rd party service and letting their system logon for you and pull the data. Probably against your banks T&Cs and akin to giving your postman your house keys so he can deliver a parcel. Madness. This is known as the password anti-pattern.
The above situation is so fragmented and detrimental to the development of innovative financial services and cannot continue if banking is ever going to get closer to or truly become part of the web.
1. Open Standards are required
The six little fields must be available in an open standard machine readable format, a format that every financial services organisation, and other interested consumers, could implement.
Open standards would challenge the virtual monopoly Yodlee hold and in my opinion would be better for all. Imagine if shipping containers could only fit onto one organisations fleet of ships, that is effectively the situation we are faced with today.
From an open standard point of view there is actually one in existence today. OFX, Open Financial eXchange. It is a golden oldie, first defined way back in the 90s and was primarily designed for the use of desktop money management packages such as Microsoft Money and Intuit’s Quicken. The standard seems to have gotten a bit stale, I know you should not judge a book by its cover but the OFX website is from a long gone era of web design (and they have not updated their copyright statement since 2007). I emailed the OFX group to see if they were actually still alive and it seems they are;
Yes, OFX is still very much alive. It dominates the U.S. market; over 5,000 financial institutions in the U.S. use OFX. The last specification was in 2006. There has not been a need for further revisions although there will probably be revision activity in the future as the need arises.
The problem for me with OFX is that it feels like it is trying to be all things to all men (and women). The scope of the specification covers all manner of banking functions and services, including automated delivery of data but it uses old methods and seems heavily XML based. What I believe is needed is something far simpler and based on more modern data delivery formats and protocols such as OAuth and JSON.
2. A manual download option is no good
Forcing the user to manually download their data and then upload into another system is a dark ages solution to today’s realtime always on mobile obsessed world. What I would love to see in banking is the introduction of OAuth or one of its variants. This open protocol is designed to allow the sharing of data and identity between web based services. If you have ever connected a 3rd party application to Twitter or Facebook then you have used OAuth. It solves the password anti pattern described above and also removes the need to manually download data.
This is what connected apps look like on Twitter. Imagine if there was a list of banks here instead? Why can’t I connect my data in this exact same way? If I could then Dave Birch could follow his account on Twitter with a few clicks or taps.
3. Push updates out automatically
Once the connection problem is solved then whenever a new data item i.e. transaction appears that information can be pushed out to wherever the customer has it connected. They are seeing near realtime data in the interfaces of their choosing (obviously how and when the bank posts the transaction data dictates how realtime it is, we know banks love a bit of overnight batch processing).
This source of data becomes a fantastic ingredient for building new things, these events i.e. new transactions, can then have all manner of rules applied to them. It could power IFTTT for banks. Imagine being able to set off other processes automatically as soon as key payments arrive in your account?
Conclusion
If the banking network is truly to become part of the web then the data needs to flow between them as easily and safely as possible. Today that is not really the case in most countries. The digital fortresses banks have built to keep the baddies out are now also keeping their own developers out and are hampering their efforts to build for the brave new digital world. It is in the banks interest to set this data free rather than hoard it for themselves because one day they might understand Big Data. Grasp Open Data first and learn from what people build with that data. I believe Six Little Fields can change the financial services market and how it interacts with and is perceived by the web.
This is part one of my thoughts around six little fields. In the second part I will look at the security concerns of both banks and users, how this might become a reality and whether or not the Germans have actually figured this out already. If you have any questions or comments please do leave them below or pester me on Twitter. I just want to get a conversation started around this topic really, is it a completely ridiculous idea or does it have legs?
Comments
Most standard computer formats combine date and time into one value (since time on its own is pretty useless), so that cuts your 6 fields down to 5.
You also don’t need the balance of the account with each transaction, since that is trivially calculated from a starting balance and the sum of the transaction values. So that’s only 4.
The type field might not be strictly speaking required either, seeing as the description usually contains something like ‘ATM Withdrawal Sheffield High Street/NatWest’ which can be interpreted easily enough (although distinguishing direct debits from card purchase etc in a standard way would be helpful).
The hardest bit is the authentication. But given that that you’re less likely to authorize lots and lots of apps (like on Twitter), you could probably do it with something much simpler than oAuth, which allows apps to ‘request’ access. A simpler process might be to require you to login to your online bank, create a new feed for the app you want to authorize, and then copy/paste a random password key into that app’s interface. A bit less streamlined – but far easier to implement.
I like your thinking, the fewer fields the better. On the time and date front most banks actually don’t even display the time today, so I did add it in to be a little bit provocative.
The description field varies wildly between banks as does the transaction type field. The more clearly these can be defined the better but at the moment it is far from standard. Your example string is far longer than most banks today provide.
Like your idea on the key sharing thing but I was also thinking that with OAuth being a standard (albeit a moving one) it would be good to see it being followed. For me the key thing is that you need a critical mass of banks doing this to deliver real value.
Ah yes, I forgot that banks don’t always reveal time of transaction. Maybe that’s not required.
oAuth is definitely a standard, but only within the tech startup community. Persuading banks to use this might be a initial step too far – whereas a simple key share system would let them get started much quicker. However I certainly wouldn’t complain at a full oAuth implementation. (Although the next question would be: which version of oAuth??)
I’ll let you know how I get on with the Barclays data feed set-up…
Cracking blog post Aden, when I worked at a high street bank in the 90’s, a lot of effort was put in to building single ‘Customer’ views for the branch staff. As this system ran in the branches, it meant that all data was retrieved and updated via a secure transaction gateway, with defined (horrifically complex) interfaces. There was a will and a design authority to ensure that happened in a consistent manner and it did.
I’d be very happy with
1) Automated feeds for current accounts, even in OFX, without using Yodlee or similar
2) Automated feeds for *other* products, loans, mortgages, cards, savings etc as a later thing
3) Some way of mashing up that data in to a single person view (I’ll build that in my spare time given the feeds!)
When having a ‘One’ account was a big thing, like Intelligent Finance set up, you can see that the will was there to start integrating products to provide a single balance. It is that kind of motivation which the banks require to innovate their way in to this century…
If a major UK high street bank were to switch this on, how many API calls do you reckon they’d end up receiving and how much computational power would be required to be able to handle that volume?
This question was raised at the Digital Sizzle FinTech panel a few months back. You can watch my response. 🙂
http://www.youtube.com/watch?v=y_DVY-lNaRU&feature=youtu.be&t=57m46s
PS: My point is that coming up with these ideas is really easy. Making them actually happen at the sort of scale high street banks operate at (and under the legal and compliance restrictions they face) is another thing altogether.
I appreciate your point, but the banks have had many, many years and billions of pounds of profits to ensure that they are not constrained by legacy mainframe systems. I appreciate that there is also a great deal of complexity to the various banking systems, however, an automated feed is only going to be read only, so technically you’d think that some distributed caching would help 😉
Oh Gavigan you cheery bleeder…what does Twitters API get a day? 13 Billion calls? Yes a banks APIs would need to be secure and robust but the volume would not really be a problem and it is not beyond the means of technology today. I agree though that making it actually happen is really hard. I will talk about this a bit more in part two.
Yes re: OAuth.
The transaction type is tricky. Better to have an open tags field from which standards emerge.
Also, posted transactions or pending? how do you know.