Monday, February 01, 2016

Today's Payments Systems Market: Theory and Reality :)



A typical payments architecture, in theory at least, will comprise a central retail and/or wholesale payments engine. Usually, these will be distinct, except for relatively low-end universal banks. The different requirements – high volume, low complexity versus low volume, high complexity – has meant that the operations and systems that support them have tended to be kept separate. Nevertheless, there is a line of thought, often encapsulated within the term 'Payment Services Hub', that they could be brought together.

The retail engine will link outwards to ATMs, point of sale (POS) terminals, delivery channels (payment initiation), to internal systems (back office) and to a range of external clearing systems. The engines will handle the management of those payments, including validation and authorisation, routing, settlement, reconciliation, exceptions handling, repair, and dispute management.
That functionality might reside within the engine itself or in satellite systems, perhaps with a role as well for workflow engines and Business Process Management (BPM) offerings. There will also be account management activities, including balance management, billing, statements and reporting. Layered on top are the compliance and regulatory requirements, including antimoney
 laundering (AML) and fraud detection.

On the wholesale side, many of the requirements at the back-end are similar, albeit with different interfaces for clearing. The front-end will include links to e-banking/cash management systems and into the corporate treasury management and ERP systems. The systems will ideally need to handle bulk files, allowing customers to send a range of payments, with the system
handling the routing based on pre-defined rules.

So much for the theory. In reality, most banks' payments processing has become highly fragmented, typically along silo lines. It is not unusual for a bank to end up processing payments in 20+ areas, resulting in duplicated effort, diluted investment, inefficiency and an incomplete picture for reporting and control. The picture becomes even more complex when the bank has multiple international operations and other subsidiaries, then more complex again where there have been mergers and
acquisitions. Those pockets of payment processing might be on dedicated systems but there is also payment processing within more general applications, including the core banking systems or narrow back office applications in areas such as securities.

It is common for banks to become bogged down in the logistics of moving from this complexity to a cleaner payments architecture. The separate payment processing systems are firmly entwined, from a technical aspect with multiple interfaces but also from an organisational aspect, with strong departmental divides and fiefdoms.

This is one key reason why so many payment system projects end in complete or partial failure. It is not so much the target application as the starting point that appears to be the problem. Without strong senior management that is able to cut across departmental lines, such projects will start on the wrong footing and will struggle to recover.

However, the existing architectures are becoming ever less sustainable. There are serious risk management considerations, with an inability to see the full picture in terms of credit, market and liquidity risk. There is also operational risk with such a set-up. There is a direct cost implication because the fragmentation hinders efficient liquidity management. Similarly, it is difficult to
meet service level agreements and cut-off times. Too often there is manual processing around the systems, with particular inefficiencies where there are breaks and hand-overs of processes between departments. Understandably, the regulators take a dim view of such weaknesses and, without a complete picture, it is difficult to do fraud detection and AML (this is also often
done on a silo basis).

Another aspect of the unsustainability is technology. Many of the systems are on legacy platforms. At the time they were installed, there was probably a very good reason why they needed to run on, for instance, an IBM mainframe or a Tandem server. However, as the scalability and resilience that set those platforms apart have become standard within lower cost offerings, so there is the opportunity to significantly reduce the cost of ownership. In addition, support of those legacy platforms and legacy systems becomes ever more difficult, in part due to the dwindling resources within the bank and on the market. PL/1 programmers, for instance, do not get any younger.  

There are also competitive implications. Those banks that have a streamlined, centralised payments infrastructure that is flexible, automated and robust are pulling away from the masses who are still hampered by legacy. In today's difficult markets, where the rallying cry for some time has been 'back to basics', many banks see payments as one of their foundation stones. And today's financial sector is clearly only becoming more competitive, with payments one of the battlegrounds. It is a cliché, but
true nonetheless, that customers are becoming more demanding. We live in impatient times, where in our personal and public lives we are not used to waiting and, certainly when it comes to information, expect things to happen in real-time.

A common analogy in the payments sector is to the tracking services of the courier companies, whereby customers can see where their packages are at any point in time (online retailers provide a similar service for orders). Which banks can provide anything like this for payments at present?
Indeed, it is understandable if there is frustration. The payments space over the years seems to have been beset by too much talk by banks and too little action, arguably more so than any other area of financial services.

Meanwhile, other participants have been forging ahead. The agendas for bank-oriented payments conferences are filled with speakers who are strong on the theory but light on practical examples. Too few institutions have a good story to tell.

The heightened competition, as discussed in the previous section, is partly to do with the pace of technical change, opening up many new opportunities, particularly around micro-payments, cards, and mobile. There is a lot of innovation and there are opportunities for new entrants, with these typically in a better position to harness the new technology than the banks. Regulatory
change can also bring new competition, most clearly seen in the PSD in Europe.