For too long, businesses in all sectors have accepted the limitations of one-size-fits-all payments; forced to accept inefficiencies, high cost and the inflexibility of off-the-shelf solutions.
The move towards open banking continues apace — the approval of PSD2 on the 8 October 2015 forces banks to open up accounts via APIs and provide access for third party developers. This will
likely become law around the start of 2018.
The will is there. A recent report from FIS indicates that 65% of banks want to create a public app store; however only 14% have currently opened up their systems with APIs. Both Visa Direct and the Mastercard Developer Zone are already opening up trusted financial rails via APIs to application developers.
Troubled by barriers to ‘open’ payments?
In practice, some of the challenges to getting to the nirvana have already been addressed. For example, integrity of financial transactions — once they hit the recognised financial rails e.g. ACH,
Visa — are reasonably assured.
Security control of application developers
Developers need the flexibility to write software whilst making sure that they absolutely cannot inject code which manipulates sensitive data — either fraudulently or by mistake. Tokenisation partly addresses this but not completely, as it expects an existing account to be present and does not support the origination of new accounts.
Approving the usage of a payments application in a particular jurisdiction is the responsibility of the bank(s) that provide the underlying financial services. Typically, this requires a manual review of the workings of the application against regulatory and risk requirements. In an open environment, the sheer volume of applications makes this manual activity infeasible.
How it works
The use cases are endless
Industrialised control will allow the number of available applications to increase dramatically as financial service provider’s trust increases. The applications are likely to be generic and whitelabelled and will be easily tailored to specific industries in specific countries. Applications that are mostly payments related can be developed, published and run standalone on the OPE.
For example, a simple payments application that supports a pooled Christmas charity donation for workers which ends up with the money on a single shared prepaid Visa card. However, it is likely that most applications will involve mash-ups where a controlling application (e.g. a retailer’s website) calls an OPE application for the payments processing.
The OPE will bring together consumers, corporates, programme managers, developers and service providers into a marketplace. Each one of these can be separate companies or potentially one company could perform two roles. For example, a bank could be both a Service Provider and a Programme Manager offering programmes using their own services.
Application developers will have access to a broad range of customers and service providers across geographic regions; and vice versa, banks will be able to provide their services through a wide range of innovative applications.