Across the globe, payment services are in ferment. A host of agile new entrants are challenging the banks and other providers of traditional payment services, and fighting for a slice of the eCommerce and mobile payments markets.

Below the surface turmoil the old established national payment infrastructures still underpin the vast majority of these services.  The infrastructures are increasingly creaking at the seams and make it difficult for genuinely new payment services to be introduced.

In the UK, as in several other jurisdictions, a Faster Payments System was introduced alongside the older payment systems, to enable ‘real-time’ retail payments primarily for internet banking purposes, and this has permitted the provision of some new layered services (such as PayM, which allows payers to identify payees by their mobile phone number).

However the pressure for change has not let up and in November 2016 the UK’s Payments Strategy Forum (PSF) published its strategic vision for more fundamental change. The setting up of this forum was one of the first actions of the new Payment Systems Regulator (PSR), a recent creation of the UK Treasury and operational since April 2015.

The report gives a very clear picture of the limitations and strains inherent in the current payment systems, and proposes a completely new infrastructure for retail payments as the ultimate solution.

Hannah Nixon, Managing Director of the PSR has said: “The payments industry, including the technology, infrastructure, and services offered to users, is going through the type of wholesale change that is only seen once in a generation”.

At almost the same time the Bank of England has published its consultation paper for a complete technology refresh of the UK’s Real Time Gross Settlement System (‘A new RTGS service for the United Kingdom’, September 2016). As the RTGS ultimately provides for the settlement of payments its roadmap needs to be coordinated with that of the various payments systems.

Report findings

So what is the future for UK payments? Here is an overview of the PSF report’s main findings and recommendations.

The PSR regulates eight payment systems:

• Bacs (for Direct Debits, and Direct Credits such as salaries)
• Faster Payments Scheme (provides near real-time payments e.g. for internet banking)
• CHAPS (wholesale payments and high-value retail payments)
• C&C (Cheque & other paper-based Credit instruments)
• Northern Ireland Cheque Clearing (NICC)
• LINK (servicing the network of ATMs in the UK)
• MasterCard (the Mastercard payment system)
• Visa Europe (Visa debit cards)

These payment systems have been developed individually over time with different standards over different platforms, resulting in a number of issues. The cost and complexity of interfacing with each of these systems is high, as payment service providers (PSPs) such as banks have to conform to differing standards and protocols. It is impossible for PSPs to differentiate the retail products they offer – Direct Debits are the same at every bank. However, PSPs are disadvantaged if they do not participate in every system, heightening barriers to entry into the UK payments market, and thus reducing competition. This in turn means that industry players have little incentive to innovate or improve the service to end-users. A key weakness is that the structure and amount of data that can be transferred with payments is limited, and differs from system to system.

Also, non-bank PSPs are at present unable to participate directly in several systems (including Bacs, CHAPS, C&C and FPS) because that requires a settlement account at the Bank of England, and these accounts can only be held by banks or building societies. This is an example of a constraint which arises from governance rules rather than IT systems, and is addressed by the review of RTGS noted above.

A glance at some of the PSF report’s proposed solutions may help to illuminate the kinds of functional feature that are increasingly in demand but which are not met by the present-day payments systems:

• ‘Request to Pay’ is a proposed new service that would enable governments, businesses, charities and consumers to create and send payment requests. The receiver may then choose to respond with a suitable payment.
• ‘Assurance Data’ is a bundle of features the would help payers to know that a payment will settle / has settled. This includes confirmation that the account to be debited has sufficient funds and that the payee account does indeed belong to the intended party.
• ‘Enhanced Data’ would provide additional data with the payment to allow the payee to easily identify what the payment relates to.

To fully solve the issues and deliver wholly new functions like these “the industry needs an infrastructure which is simple, secure, stable and resilient; versatile and responsive to user needs, and efficient to run and develop.”

To reach this desired end-point the strategy describes a stream of developments and remedies,  initially to enhance several of the existing systems but ultimately leading to their replacement with a New Payments Architecture (NPA).

In terms of ownership and control, the Payment System Operators (PSOs) for BACS, C&C and FPS will be consolidated into a single body, the Consolidated PSO, by the end of 2017. This body will take over responsibility for the ongoing stream of developments leading to the delivery of the NPA. (Note that the PSO may differ from the actual infrastructure provider; Bacs is operated by Bacs Payment Schemes Limited, while its technical infrastructure is currently provided by Vocalink).

In relation to messaging, the following table shows the range of messaging standards currently used across the various payment systems and RTGS:

• CHAPS – SWIFT MT
• Faster Payments – ISO 8583 (bespoke)
• Bacs – Standard 18
• LINK – LIS5 (bespoke)
• Visa – ISO 8583
• MasterCard – ISO 8583
• RTGS – SWIFT MT

With regards to messaging standards, the report proposes that the UK “continues adoption of the ISO 20022 messaging standard” and notes the work already being done by the FPS and Payments UK to map existing payment system message types onto ISO 20022 messages. The Bank of England also proposes to use ISO 20022 for the next generation of RTGS.

The report describes its vision for the NPA only at a high level. For example, it has not definitely chosen between a traditional centralised platform or a decentralised (distributed ledger) model. The roadmap promises a detailed design by the end of 2017.

The core of the NPA is a Simplified Payments Platform (SPP). It will have a layered architecture, with the lowest layer simply executing a simple payment from A to B in real-time. Overlay services will provide all of the more complex services required, such as the direct debit functions provided by Bacs currently. ‘Open access APIs’ allow the PSPs to communicate with the SPP services, while ‘end-user APIs’ allow PSPs to communicate with customers, or customer-facing systems. APIs also provide communication between the service layers. Messaging to and from the SPP will use ISO 20022.

Building a completely new retail payments architecture is an ambitious strategy and Andrew Hauser, executive director, banking, payments and financial resilience at the Bank of England, has sounded a note of caution: “The challenge now is to translate the high level aspirations … into something much more concrete. That means delivering a retail payments design that is technically feasible, secure, and aligned with the Bank of England’s settlement models. It also means identifying who will build, and pay for, the new system: no small challenge at a time when the industry faces many competing demands on its resources.”

All in all, it seems probable that the UK’s retail payments infrastructure will be in a state of transition for some years.

Capabilities of Transformer

Trace Financial and Transformer are world leaders when it comes to the challenges of working with diverse and complex messaging standards. Organisations such as SWIFT, Earthport, Currencies Direct, global banks and market infrastructures all rely on Transformer to address challenges such as cross-border payments, diverse ACH formats, standards interoperability (MT-MX); ISO 8583 and faster payments; evolution of ISO 20022 and canonical models.

Transformer uniquely allows analysts or developers to address all aspects including mapping, validation, enrichment, testing and maintenance without resorting to coding or scripting. In the scenarios described above the challenges largely centre around transitioning from variants of ISO 8583, SWIFT MT and other standards to ISO 20022 over a period of time and during which organisations will need to support legacy and new standards simultaneously.

Transformer offers PSPs, PSOs and infrastructure providers the tools they need to create, model and work with multiple ISO 20022 based message definitions, and to build transformations between ISO 20022 and other formats. Transformer’s libraries capture all of the details of an ISO 20022-based standard in a highly business-friendly way, including user-friendly names and full descriptions for all fields, components, and data range values, and fully supports cross-validation rules.

In a similar way Transformer’s ISO 8583 library captures every detail of each ISO 8583 variant down to a sub-field level and presents it in a way that is meaningful to the analyst.

Transformer dramatically shortens the time taken to build solutions involving complex standards. The analyst using Transformer creates solutions directly in the intuitive Design-Time GUI. There is no coding stage, even when the required data transformation is highly complex. In this way projects remain clearly articulated and easy to maintain, and removing the old-fashioned ‘spec handover’ from analyst to developer eliminates a major source of risk and delay. Testing is fully integrated at all stages.

Once configurations are complete and tested they are deployed into any runtime architecture that suits the client. A Transformer configuration can be deployed into the multitude of technical infrastructures found at a client site including java, .NET, RESTful services, etc.

Transformer is a truly strategic solution to all the challenges and delivers one best-of-breed solution for any messaging standard; for deployment in any technical infrastructure; for integration in any version control system and automated testing environment; and can be used by analysts or developers without any need to resort to coding or scripting. Transformer is an essential tool for coping with these evolving and complex demands.