A Finextra member 20 June, 2014, 12:46 0 likes

I agree with Mark that the perceived threat to banks by possible legislation that will give to licenced third-party providers access to bank accounts/systems for the purpose of financial product innovation, should rather be perceived as an opportunity.

But we can’t underestimate the security challenges for banks trying to do so. 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 very keen on opening up payments to app developers as well as non-technical staff without compromising security.  We’re taking two approaches as follows.

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.

Both of these approaches could hugely reduce the time and cost it takes banks to create and deploy payment products, as well as to open their systems to third-parties without compromising security.

Gerry.cavander@ixaris.com

A Finextra member 22 June, 2014, 21:42 0 likes

Mr. Hartley is absolutely spot on about the need for consumers to store "value" of many types in a safe repository and this represents an excellent opportunity for banks.  Sadly, over the last 5 years, banks , especially the mega-banks, have so severely damaged their reputation as trusted financial intermediaries, that it would be the rare consumer who would entrust this data to these casino-like organizations masquerading as government-insured financial institutions.