Paul Styles

Integration mitigation

15 Feb, 2012 09:45

In an increasingly commoditized payments world, it is no surprise that banks seek to differentiate their payments offering. Technology is usually the key enabler in creating competitive advantage, but soaring IT integration costs can all too easily derail the bank’s efforts.

Banks are being squeezed. They are caught in the vice of increasing competition, rising customer expectation and more regulation on one side; and falling prices with changing volume patterns on the other. And we can add innovation, flexibility, cost reduction and enhancing the end-user’s experience as simultaneous aims.

Unfortunately, the costs associated with IT integration make decisions on investment in new technology more difficult, as there is greater uncertainty regarding the payback period.

One answer may be to mitigate the integration issue by buying, for example, a front-end to back-office payments system, complete with fraud capability, from a single vendor : pre-integrated and with guaranteed interoperability. Time and cost saving aside, there are real benefits to be gained in terms of payments visibility and real-time information, which can form the basis of true differentiation. Add to this, easy-to-use self-service enrollment forms that provide immediate access to online services, and banks may well have a competitive, and more importantly, profitable offering for their corporate customers.

Comments

Added: 17 February, 2012 - 13:06 | Barry Kislingbury - Misys - London

Much of what you say is true, getting the integration right is a huge issue, I have two thoughts.

A complete packaged solution does remove risk and complexity. However if all components are tightly integrated you risk creating yet another silo where functions like WLC and AML are duplicated rather than using this opportunity to standardise on enterprise components. A complete package with loosely coupled components which can be replaced with enterprise alternatives would be preferable. Clients have a choice then.

This raises my next thought; you then have to integrate with these enterprise components and 3rd party systems. This has always been the problem with payment engines as they concentrate on the job of processing payments and not on the issues around ‘working with’ all the other systems a bank runs to provide a true end to end solution. This is where payment hubs came from, a solution that helps a bank integrate payments processing from the front office to the back office and out to clearing and settlement by providing tools, frameworks, and web services around a standardise payment process. This drastically reduced implementation time, complexity, risk and gets rid of bespoke interfaces and silos; it reduces those cost you suggest are stopping investment. It also provides a modern infrastructure making it easier to offer innovative new services in the front office whilst supporting changes to clearing and settlement systems (such as SEPA) without major upgrades to the core processing systems.

Hubs are therefore different from engines, but ultimately both are used to create payments solutions, the difference is in the time, approach and modern standards based tools provided to create the solution.