Six little fields; Why not set them free?

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.

"I want to follow my bank account on twitter, I don't care about Mrs Gaga or Snoopy Dogg - how hard can it be Barclays?"

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.

1. 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.
2. 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.
3. 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.

OAuth enabled applications screenshot

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?