Mashups are beginning to excite the banking world because of their potential to give customers more control over customer data – to be able to query it, manipulate it, enhance it and even combine it with other data sources or online services.

Mashups mean different things to different people. Essentially, mashups are flexible combinations of data, visuals and software, creating new tools and services for customers to use when dealing with banks. 

Dion Hinchcliffe, business strategist and enterprise architect at Hinchcliffe & Company, has posted a succinct explanation of the different mashup categories. He explains how mashups can range from solutions that enable customers to combine different data sources in their browser – as in Yahoo! Pipes – to recombinant software on an enterprise server.

There have been some 'proof of concepts' built (including one by Misys) showing how giving total ownership of financial data back to the retail or corporate customer could work in a mashup editor.  However, this functionality goes well beyond the capabilities of today's online banking or personal financial management sites and some banks might not have the appetite for giving customers this kind of access to their data.  Moreover, no advanced and widely accepted use case enabling customer customisation of their online banking experience has yet emerged. 

But pushing the boundaries of what today's web technology is capable of and looking at what's missing is an interesting thought experiment.

Four hurdles for banking mashups

If banks provide access to all customer data in a feed as usable and flexible as an RSS feed, perhaps with additional mashup tools, four hurdles would first need to be negotiated:

1. Security – Some useful mashup services could require banks releasing customer data to third-party service providers.  Both banks and their customers need to be confident that the data remains secure.
2. Standards – would all financial institutions have to provide data in a common format for customer mashups to be feasible? Could ISO20022, FPML or XBRL be extended to incorporate this requirement?
3. Metadata – what kind of useful metadata should and could be tagged to financial data in a standard way? What metadata could a bank provide to both corporate or personal customers?
4. Feedback – what could a bank learn from how its customers use and enrich the data it provides them? What feedback mechanisms could be built to benefit the bank's understanding of its customer?

So what is happening today? 

More realistically, you can expect more live deployments of mashups within banks' firewalls over the coming years. Server-side software and data mashups are probably the most common scenarios in the banking sector, for the rapid creation of prototypes, enterprise tools and applications – particularly in the areas of business intelligence and risk management. 

Developments such as the launch of the Open Mashup Alliance (OMA) www.openmashup.org in September last year, and the development of the Enterprise Mashup Markup Language (EMML), will help drive forward standardisation in this area.  It was interesting to note Bank of America's reason for being the founding enterprise member of the alliance. 

Some of the thinking about what bank data sources can be usefully combined and compared is already finding its way into new data-based bank offerings. 

A good example is Australia's ANZ launching an online tool which lets registered small business customers view comparative Point of Sale benchmarking data for similar firms in their local area. 

I expect that we'll see a lot more of this kind of thing, both from banks and also the independent account aggregation / PFM services. This can only be a good thing for customers.