Posted on FinExtra: https://www.finextra.com/blogposting/15448/ready-for-real-time-payments-how-about-real-time-banking 

 

As banks examine their readiness to deliver on the potential of new real-time payment schemes and meeting customer expectations for an ‘always-on’ service, it’s an ideal time to consider not only real-time payments, but also the full potential for real-time banking.

Banking and payments are intrinsically linked – all banking activity (aside from master data management and account management) falls into two main categories: financing and payments. The ability to make and receive payments is crucial across all banking functions – from trade finance to lending and foreign exchange.

In my view, banks should use the move to real-time payments to implement a single, global banking platform with a payment processor in the middle that’s capable of handling any payment type. This will enable them to put in place an infrastructure that allows them to adapt more easily to fast-changing market requirements across their global operations, while also reducing costs.

Legacy constraints bring complexity

The issue is that most banks today remain constrained by legacy technology and old-fashioned and inflexible IT packages. Most have a multitude of different payment systems, each of them handling different payment types. Just keeping these systems updated is a challenge – since banks have typically undertaken significant bespoke development. It’s not unusual to come across banks using customised IT packages that have failed to make any system upgrades for 6-8 years. The cost, complexity and risk involved in carrying this out has been prohibitive, and in some cases more expensive than implementing a new system.

Compounding the problem, many banks are now taking a short-term approach to how they implement real-time payments in an attempt to prolong the life of their existing systems. Those that are adding separate siloed systems or modules to handle schemes such as SEPA Instant Payments, alongside their existing architecture, are adding to the complexity.

Often they’re layering these satellite systems on top of an infrastructure that hasn’t been set up to handle interfaces to systems across the bank, preventing easy access to data on customers, customer accounts, available funds control, correspondent banks, bank accounts, geographical data, currency and exchange rates, embargo lists and anti-money laundering controls. Similarly, the siloed systems are unable to update account balances in real-time for relevant deposit accounts, Nostro/Vostro and general ledger accounts.

The implementation of duplicate” account management systems as a solution to handle PSD2 and Open Banking is beset with risk and a potential recipe for disaster, and is not the recommended way to go. In fact, this approach means replicating most of the functionality already contained in the bank’s legacy payment systems and creating a new set of duplicate interfaces on top of the ones it already has. While the intention is to extend the life of the bank’s legacy systems, in the process the bank is creating even greater complexity, and another maintenance headache.

With mandatory changes to SWIFT FIN messages now required as part of the upcoming SWIFT 2018 and 2019 releases, many banks have large ongoing development and implementation projects underway. Going forward, banks should be looking to vendors that can offer system upgrades as a standard part of their annual maintenance services, with no need for bespoke development.

Innovating to meet future needs

Instead the best approach to real-time payments should be to rise to the challenge and also embrace real-time banking. This means implementing a modern banking platform with a payment processor, offering rich functionality, that is flexible and adaptable, highly-parameterized, object-oriented and rules-based – which can also be used by any product solution across the bank. The banking platform should be able to easily accommodate future needs, changing regulation and specific-country requirements, such as the addition of relevant clearing systems. It should also offer a comprehensive library of ready-made global banking business objects, such as master data management, interfaces to relevant third-party systems and Open APIs.

The banking platform should be rolled out as a standard, packaged system, country by country without creating any special version of the source code. This helps to ensure that all subsequent system upgrades and SWIFT updates can be quickly and easily incorporated on a fully automated basis so that the bank never falls behind. The use of ISO 20022 standards is also a must in facilitating electronic data interchange and connectivity to existing systems within the bank, external clearing systems, SWIFT and other networks such as Ripple. Such an approach is essential in delivering increased agility.

Banks are under immense pressure to reduce costs and drive down the total cost of ownership in relation to their technology infrastructure – with goals to make cost savings of at least 50%, sometimes 80%.  Implementing a modern global banking platform is the only way to achieve this.

No-one would expect a new challenger bank today to implement multiple different payment systems to handle every different payment type. It would be madness to replicate the functionality, given 90% of the banking business objects and interfaces are common and global between the different banking applications. In a changing competitive landscape banks should take action today to address their legacy systems and to seize the opportunities associated with Open Banking, real-time payments and PSD2.