Drawing the Line on Payment Messages

I recently attended a meeting of the European Payments Council (EPC) Scheme Technical Forum, a group of payments professionals who carry out technical assessments of changes proposed to the SEPA schemes – SEPA CT, SCT Inst, SDD Core and SDD B2B. We were reviewing the 2018 scheme change requests. Some of the proposals under consideration related to a wider issue: to what extent should the scheme stick strictly to “payments” processes, and to what extent should it support ancillary messages that support Payment Service Provider (PSP) processes?

Account Switching

The first proposal was to introduce a mandatory message (acmt.022) to indicate that an account (or banking relationship) has been changed, and to give details of the new bank and/or account. This message would be used in response to a bank that tried to make a payment to, or to collect a direct debit from, an account that is no longer valid. Such a message is an essential part of an automated account switching scheme, such as the one operated domestically in the UK.

The Scheme Evolution and Maintenance Working Group (another body that proposes and/or evaluates scheme change requests) recommended that the proposal be rejected on the basis that the change “is not related to a specific type of EPC SEPA transaction”. That’s perfectly true; but it’s also true that a changed account is a reason for rejecting any and all types of SEPA transactions. All the SEPA schemes have reason codes to indicate that this situation has arisen, but beyond that it’s up to PSPs to figure out what to do about it. That’s operationally intensive for the PSPs, and results in a poor customer experience.

Remittance Information

A second topic that touches on the same issue is Remittance Information. There is currently limited space (140 characters) in a payment message to carry remittance information, and a proposal was carried forward to increase this space. The change applies to SEPA CT only, because SCT Inst payment messages must be kept relatively short to allow quick processing. Other instant payment schemes have got around this limitation by defining a separate remittance advice message (remt.001) that can be processed in a different timescale from the payment. But then the same argument could apply, that a remittance advice “is not related to a specific type of EPC SEPA transaction”.

If the only way to offer equivalent functionality in SCT Inst is by introducing a non-payment message, should the scheme adjust their decision criteria to allow that, or simply accept a lower level of functionality in SCT Inst?

Beyond the Boundaries

If the SEPA schemes are not extended to support these message types, what are the alternatives? Individual CSMs could define such a message and associated rules as value-added service outside the scope of the Scheme. The big drawback of this approach is that the messages and associated rules would be limited to members of that CSM, and would not work if the customer had moved to a PSP that uses a different CSM.

Request to Pay

The third topic was around the Request to Pay messages (pain.013/pain.014). As yet there is no formal proposal to introduce these into the SEPA Credit Transfer schemes, but this may be tabled in a forthcoming round of change requests, depending on the deliberations of the European Retail Payments Board (ERPB). I raised the question whether these messages also would be deemed out of scope on a similar basis to account switching.

The answer seems to be that the EPC will probably take responsibility for these messages if the ERPB asks it to do so, and the messages would get incorporated into SEPA CT and SCT Inst rulebooks (an interesting but slightly off-topic question is whether a Request to Pay that is sent via SEPA CT could be satisfied by a SCT Inst payment, or vice-versa).

Such a decision would be in line with The Clearing House in the US, and with the Hungarian Giro scheme, both of which support Request to Pay messages across their real time payment rails. The UK seems to be moving in a different direction; the current proposal for the New Payments Architecture is that Request to Pay should be implemented as an “overlay” service, implemented as a set of APIs and hence independent of the underlying payment rails. The UK reasoning is that Request to Pay services, on both the initiation (creditor) and the fulfilment (debtor) side, could be provided by non-bank entities (AISPs and PISPs), so the messaging should not flow across the payment rails, which would effectively limit participation to banks.

There is some logic in the UK’s position and there are also arguments around competition, innovation and the pace of change which I will pick up in a later piece . On the other hand, introducing a different network, a different messaging paradigm, and potentially additional organizations, adds hugely to the complexity of the end-to-end process, hence increases the probability of failures. Also, PSD2 should have taught us that expecting “market forces” to develop interoperable standards for APIs is a vain hope.

What would SWIFT do?

It’s interesting to compare the EPC Schemes with SWIFT. While both EPC and SWIFT act as Scheme bodies that set rules and standards, SWIFT also owns and operates the SWIFTNet network. In the early days, SWIFT defined a small set of payment messages, rather like the current SEPA CT Scheme. Over time it has evolved to cover a much broader range of functionality, with messages covering advice of charges, FX, collections – and indeed, Request to Pay.

SWIFT defines the mission of its Payments Market Practice Group as “achieving full straight-through processing and improved customer service around the world”. The goals of the SEPA Credit Transfer scheme are similar – the rulebook says it aims to support “best practices of straight through processing” and “the improvement of services provided to customers”. The rulebook also says the scheme forms “a common basis on which Participants are able to offer new and innovative services”.

The inclusion of the Account Switching and other non-payment message types would certainly tick the boxes of offering new, innovative improved services to customers, and improving straight-through processing by reducing manual intervention. It might even support another goal mentioned in the rulebook, to develop “a healthy and competitive market” – that was why the Account Switching service was introduced in the UK.

Drawing the boundaries

Ultimately there are no hard rules defining the boundaries of the SEPA schemes, decisions are made on a case by case basis, subject to multiple levels of scrutiny, including a public consultation phase. Personally, I would prefer to include more ancillary messages as SWIFT has done; but there are commercial, political and practical reasons why different schemes draw those boundaries in different places. I will discuss those pressures in a future piece.