As of May this year, only 4% of US FDIC insured institutions in the United States had any sort of mobile play, a small subset of this group had iPhone apps, and an even smaller percentage had Android apps. We already know that mobile Internet based banking
is the fastest growing interaction channel for banks today, so this level of commitment by the industry is quite concerning. So why so slow?
Why so slow?
The challenge is that iPhone came into being in 2007 and it wasn’t even on the radar of banks generally. Organizations like Bank of America (who launched their App in July 2007) were an exception. Wells Fargo, for example, was the last of the big 4 banks
in the USA, and they didn’t launch their native iPhone App until May 2009. By 2008, when many banks were considering launching an iApp, the Global Financial Crisis was upon us and budgets were being slashed, so rather than cut Bonuses, we saw bankers cut discretionary
spending in the areas of IT. Mobile was often the first to go, because the attitude was “we don’t have to worry about that yet...maybe in 10 years time”. 2009 the budget woes continued, and 2010 was about rebuilding trust so the focus was on keeping costs
low so that improvement in net earnings could be demonstrated to shareholders. Thus, we approach the start of 2011 when many banks will be thinking about mobile for the first time realistically.
This is all woefully lagging the customer behavior curve, but good to finally see the majority of banks are starting to think of ways to enable customer behavior through the mobile device and now committing to not only iPhone, but Android platforms too.
The Future Mix
By 2015 the day-to-day interactions of the average retail customer will be very different. Driven by changing customer behaviors, increasing pressure on our time, increasing customer expectations around improved interactions and journeys, etc will drive
a complete shift in channel priorities. By 2015 the #1 interacted channel (or by frequency if you prefer) will be mobile, #2 internet on the desktop and TV, #3 ATM, #4 Contact Centre, and #5 in the branch. Even #1 and #2 might tend to look a little the same;
in that, as devices like the iPad become more capable the lines between ‘mobile’ and desktop blur, so the issue of the ‘journey’ or the interaction itself becomes very critical.
It’s not just one App that we will need either. There will be a bunch of interactions we’ll be managing in this space. Increasingly those journeys will become contextually integrated and delivered via HTML 5 no longer restricted to an “App” or browser-based,
instead being based on a contextual trigger, event or service opportunity.
So obviously banks need to make a big P&L commitment to mobile as a channel and to journeys as a philosophy for serving the customer moving forward. So how is it that I advocate that you don’t need to worry about developing your App?
Lessons from VTB24 in Russia
Last week I visited with the multi-channel team at VTB24 in Russia. They are the second largest retail bank in Russia and have close to seven million customers. Given the growth in smartphone adoption and mobile usage in general in Russia, just like everywhere
else in the world, there is an obvious urgency to investing in mobile platform development. This was the challenge presented to the VTB24 team.
VTB24 was strongly committed to a mobile App for the iPhone platform, but budget constraints being what they were, they didn’t expect to be able to invest in the development of the App until 2011. Some preliminary conceptual work had already been done, but
the platform wouldn’t be mobilized till next year. They already had previously deployed WAP-based banking but this was looking tired compared with customers expectations for App-based mobile banking.
So in this environment, Daniel Gusev, who was tasked with developing the plan for development and launching the iPhone App, was very surprised to wake up one Saturday morning and find the following tweet:
“Great to see VTB24 finally has their iPhone app!” - Tweet (translated from Russian feed)
WHAT?!? This was Daniel’s immediate reaction. This can’t be right?! After all, he was the one tasked with developing the App, if someone else in VTB had been working on something, he would have known. So he logged on to the iTunes store in Russia and sure
enough, there was the App for download.
The immediate reaction was to suspect foul play. That someone had created an App to phish identity details from customers or use man-in-the-middle technology to conduct electronic theft. However, after requesting source code from Apple, VTB24 found that
the App had no suspicious content, and in fact, had adapted the iPhone APIs around WAP commands to convert the mhtml-based commands of VTB’s to a workable iApp. An elegant, and workable solution.
Daniel then tracked down the developer and had a simple question? Why on earth would you do this?
The customer answered, “Well, I wanted iPhone banking and you guys didn’t have it, so I thought I would try to see if I could build it myself. When it worked, I figured other customers might use it too!”
So VTB24 have engaged with the developer. They now have a live iPhone App that was built by a developer for a fraction of the cost, in a fraction of the time that they would have taken to develop it. Yet, it works and works well, even at some point claiming
a number 3 spot in Finance section of the Russian App Store (without any marketing support from the Bank)
There is a lesson here. Sometimes due to embedded politics and internal gaming, we want to control such ‘projects’ as the “iPhone App” internally. We might argue around compliance, risk, security, etc, but this approach shows that by thinking outside of
the box, we could actually have much quicker innovation in the customer space than we currently do.
The moment we turn the “iPhone App” into an internal project, we are essentially guaranteeing a 3-9 month turn around time to implement and launch. By engaging a developer community, we could reduce this time, cut costs, and probably end up with some really
creative solutions that we would not have thought of ourselves.
Take this on the road. Try to breakdown the barriers and IT silos in respect to production of new channel solutions. The end result may be better than anything we could do internally.