Are you ready for the banking app store?

Are you ready for the banking app store?

Within the next two years, 25% of the top 50 global banks will have launched a banking app store to improve app discovery, user experience and collaboration, says Gartner.

The explosive growth of apps is causing significant challenges for the banking industry, says the analyst house, as the visibility of customer banking apps in public stores decreases as more third party applications come online. Moreover, the more apps a bank deploys, the more challenging it becomes for users to discover the right app for them.

"Left unaddressed, these two challenges and others could really have a negative impact on banking revenues and customer experience," says Kristen Moyer, research vice president at Gartner. "Banks can use banking app stores to improve app discovery but only if the added cost and complexity are warranted."

The issue is most pressing for banks that offer an application programming interface. Public Web APIs deployed to third-party developers, customers, partners, employees and others serve as a multiplier to the number of apps deployed by the bank itself.

Banking app stores that either provide immediate downloads onsite or link to public stores like iTunes will often be most appropriate for banks with an API platform or those that have deployed 15 to 20 or more apps, says Moyer.

Banks with fewer apps may not need to devote resource to a purpose-built app store, but should still consider re-engineering their websites to make it easier for customers to find apps and provide feedback.

"This will be most effective when the total number of apps is less than 10 to 20," says Moyer. "For each app, provide complete descriptions and screen shots, and allow social commentary. Each app could then be linked to the associated public app store."

As more banks deploy app stores, it will put competitive pressure on those that do not, she believes, advising all banks to evaluate the need for a bank-specific app store in the 2014-to-2015 time frame.

Comments: (4)

A Finextra member
A Finextra member 05 June, 2014, 22:19Be the first to give this comment the thumbs up 0 likes

This surely be a welcome development.  I see app centers even within processing enterprises (acquiring) and the feedback, the heightened level of engagement with customers (merchants) is extremely positive.  


A Finextra member
A Finextra member 06 June, 2014, 09:03Be the first to give this comment the thumbs up 0 likes

This is a good read from Kristen but i think rather than the big piece of this being app stores is the need for them and the change from proposing multi faceated mobile banking experiences to one where small neat interchangable micro apps require it that all work together in the broader ecosystem.

A Finextra member
A Finextra member 06 June, 2014, 12:28Be the first to give this comment the thumbs up 0 likes

Kristen writes a good article here with the right approach and suggestions. All too easy for bank own apps to 'get lost' in the store search list, especially when 3rd party apps may share similar app titles or use the same iconography/imagery.

A Finextra member
A Finextra member 07 June, 2014, 08:25Be the first to give this comment the thumbs up 0 likes

Interesting and timely concept presented by Gartner, but it does raise questions about how banks are creating the apps and the kind of apps being created.

Apple’s iconic app store is populated by apps from developers with at best a tenuous relationship with Apple while only a few banks have enabled external developers to create apps for their app store.  The few that have – such as Credit Agricole with its CAStore – seem to offer only access to sanitized data to developers.  Offering transactional capabilities, such as sending a payment, or accessing a bank account balance, raises all sorts of issues about ensuring security.  While banks can of course carefully review developer code to weed out malicious code, this is hardly a scalable activity and clearly not a core competence for banks.  At present therefore, banks that launch app stores either have to write lots of apps themselves or else risk disappointing customers with apps that are interesting but not very useful.

At Ixaris, we’re obsessed with opening up payments to app developers without compromising security.  We’re taking two approaches, both of which we will be showing at PayExpo in London next week.

The first one is a simple app building tool that enables non-technical staff to configure various transactional capabilities (such as issuing prepaid cards, methods for funding them, etc.) through a guided configuration that at the end results in a payment application. A default user interface is created that can then be customized using style sheets, etc. Initially we expect this will be used by the bank’s own staff. But eventually we hope it will be their customers.

The second – which complements and extends the app builder concept - is Payments Mark-up Language (PayML). PayML extends HTML5 with a set of tags that enables developers to write sophisticated multi-device apps using their usual web dev tools.  The PayML tags enable them to create placeholders in their apps for payment sensitive data such as “the user’s bank account balance” or “data field for the user to enter their credit card number”.  Such HTML apps can then be submitted to the bank, scrubbed automatically to remove potentially harmful code and then run in the bank’s secure environment to provide the app functionality.  When a user subscribing to the app is logged in to the bank’s secure environment, the tags can be resolved to the user’s actual bank account balance, or to the secure entry of credit card details.  Since the developer has no access to the bank’s secure environment, and cannot pass actual code into it, there is no way that secure information can leak out to unauthorized parties while the app is running.

Life will, of course, get more interesting should the banks be required to open up their systems, and perhaps that’s when PayML or something like it will become essential.