TARGET2 SEPA SWIFT payments system

SEPA Basics

An article by

Andreas Wegmann

Published on

29/12/2021

Updated on

15/11/2023

Reading time

3 min

Table of content

A modern payments system software for banks must be able to deal with many different internal and external systems. Both the regulation and the market requirements are becoming increasingly dynamic, so that flexibility is becoming more important. This article explains the most important functions and tasks for a “TARGET2 SEPA SWIFT payments system”.

SEPA TARGET2 SWIFT

TARGET2 SEPA SWIFT payments and ISO 20022

There is no doubt that ISO 20022 will be the defining technical framework for financial transactions worldwide in the future. Many systems such as SWIFT also use the previous version ISO 15022 (see also article SWIFT MT MX), so that a conversion in both directions must be possible. For the Eurosystem, the migration will take place in November 2022 (see article TARGET2 Big Bang).

ISO 20022 only provides the framework and the individual clearing systems often interpret this differently. Different format versions of ISO 20022 are also used and it is necessary to deal with different versions of the ISO standard in parallel. An example for this for the pacs.008 can be found in the entry ISO 20022 is not the same as ISO 20022.

A modern TARGET2 SEPA SWIFT payments system harmonizes all of these differences for the connected Core Banking System (CBS). All transactions are converted to the format used in the CBS.

R-transactions and “inquiries”

At first glance, a credit or debit transfer appears to be technically easy to implement. A pacs.008 only has about 20 fields and is often triggered using a pacs.008 REST API. Nevertheless, a payment system must be able to deal with around 120 fields, since the so-called “R-transactions” and “inquiries” require this. These message types are mandatory for the certification test (e.g. for TIPS see article TIPS certification tests).

A modern payment system can support the core banking system in many ways when dealing with R-transactions and, for example, automatically generate a rejection for incoming transactions with an invalid IBAN. The compensation of interest and fees is such an example as described in the article on camt.029. However, such functions have their limits where data from the core banking system is required.

Relief of technical and regulatory changes in TARGET2 SEPA SWIFT

All payment systems are subject to cyclical updates and improvements, as security and efficiency are to be increased. An example of this is the version upgrade from EBICS to EBICS 3.0 or the obligation at SWIFT to participate in SWIFT gpi. A good payments system software will keep this kind of changes away from the CBS.

Flexible routing control

Dealing with different clearing systems and communication channels requires transparent routing for payments. In the past, especially in monolithic systems, the routing has been virtually cemented. Nowadays, however, banks are faced with the challenge of having to adapt to market requirements at short notice or of cooperating with new partner companies. The IT landscape at banks is therefore becoming increasingly modular so that weak modules can be removed and new ones can be easily added. A modern payments system must be able to be integrated into such a landscape as a module and support the dynamic of change in payment transactions through flexible routing control.

By optimizing payment routes, however, costs can also be saved in conventional payment transactions and / or time can be gained in processing transactions, as described in this YouTube video: