Blog article
See all stories »

Don't worry, you don't need to develop an iPhone app

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!”

Wow!

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)

Conclusion

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.

7061

Comments: (2)

Stephen Wilson
Stephen Wilson - Lockstep Consulting - Sydney 22 November, 2010, 02:41Be the first to give this comment the thumbs up 0 likes

I hope that the security of these DIY or crowd-sourced apps are better than that of the banks' own smart phone software.  Only two weeks ago we all heard that Banks scramble to fix mobile app security flaws.  And we've already seen what was probably a test run of trojan horse banking apps on Android phones.

Is it a good idea to let anyone develop banking apps?  We don't let anyone build card terminals.  In fact we advise customers to be wary of retail equipment that looks like it's been tampered with. 

But how can anyone tell by looking at it that a smart phone app is dodgy?

Brett King
Brett King - Moven - New York 22 November, 2010, 14:24Be the first to give this comment the thumbs up 0 likes

Stephen,

The simple answer is that banks write an API layer encompassing the required security and authentication layers, and give developers a secure 'sandbox' to develop within. In this way, not only can such be done securely, but real testing of the environment can be incorporated into the development life cycle in a more constructive manner than is currently embedded in projects that are only exposed internally.

Brett King

Brett King

Brett King

CEO & Founder

Moven

Member since

14 Apr 2010

Location

New York

Blog posts

146

Comments

339

This post is from a series of posts in the group:

Innovation in Financial Services

A discussion of trends in innovation management within financial institutions, and the key processes, technology and cultural shifts driving innovation.


See all

Now hiring