Survival in a time of change

Same same but different – in 2023, the abundance of challenges in payments remains equally enormous. What makes the situation even more difficult, however, is the impression that procrastination effects seem to be spreading on the bank side. Important issues are simply not being addressed. This applies both to the implementation of upcoming mandatory tasks and to the exploitation of business opportunities that arise.

The most underestimated mandatory task for 2023 is the implementation of the inconspicuous EU Directive 2020/284 "as regards introducing certain requirements for payment service providers". The directive on the prevention of fiscal fraud in cross-border e-commerce for goods and services requires payment service providers to report certain payment data. The details are quite complex: an additional, rather intricate reporting system with its own interfaces to the Federal Central Tax Office has to be set up. Data not previously available must be collected and reported: for example, the identifier of the payment recipient's location, such as the IBAN. If available, the address data and tax numbers of the payment recipient must be transmitted. The reporting obligation applies from 1 January 2024. The number of banks that have set up such projects is very limited to date. Considering that financial authorities are not exactly known for their sense of humour, this seems rather bold.

SWIFT requires structured data
Not quite as urgent, but similarly complex, is the SWIFT requirement to process only structured address data of customers in payments from November 2025. The regulation affects banks as well as end customers. It implements requirements of the leading industrialised countries to combat embargo violations, terrorist financing and money laundering. It is recommended to switch to using only the structured data as early as 2023. This will likely affect several million data records in Germany alone which are not available in this form. Banks should therefore already develop communication plans and technical implementation scenarios in the coming year – with AI support where applicable.

It is a sad but industry-accepted truth that 50 per cent of payments operating costs are for regulatory compliance and another 25 per cent for process and technical infrastructure maintenance and adaptations. It is therefore not surprising that financial institutions often lose sight of earnings potential and opportunities.

Request to Pay provides opportunities
For example, an offer that combines the still young standard Request to Pay with concrete use cases such as electronic invoices has enormous potential for banks. If banks were to offer their corporate customers the processing and handling of electronic invoices and the corresponding payment requests, they could reduce their costs – including the reconciliation of incoming payments – by around ten euros per invoice. In this context, banks could generate lucrative transaction fees, while at the same time further strengthening the business account as core of the customer relationship and, on top of that, make a significant contribution to sustainability.

The decisive success factor for corresponding services is cross-bank accessibility. It is therefore all the more gratifying that such infrastructures are already emerging in the market. It is expected that from 2026 onwards, only electronic invoices will be permitted throughout Europe anyway.

TARGET2 consolidation: "all hands on deck"
So much for the underestimated topics. Not underestimated are the preparations for the TARGET2 consolidation, which has been postponed to 20 March 2023, and the start of the SWIFT migration to the ISO 20022 format. This date should remain fixed, because another postponement of the TARGET2 consolidation would probably have the nasty consequence that TARGET2 and the SWIFT migration would diverge.

Mass payments will also be characterised by the implementation of new regulations in 2023, such as the EU regulation on the mandatory introduction of SEPA instant payments and the introduction of the latest ISO standard for all SEPA payment schemes. The latter will not only have an impact on the payment file and payments systems themselves, but will also affect peripheral systems like, for example, master data systems.

Fraud prevention for real-time credit transfers
The EU Commission's proposal for the mandatory introduction of SEPA real-time credit transfers presented at the end of October 2022 is currently the subject of in-depth discussions and lobbying. Among other things, there is intensive discussion on whether payment service providers must offer their customers a matching of account number and name. The background to the proposal is the finality of SEPA real-time credit transfers in seconds. This makes them vulnerable to fraud and is to be counteracted by the possibility of checking whether the IBAN in question really belongs to the payment recipient before the payment is sent out. Successfully combating fraud attempts is becoming a key factor in the success of instant payments.

The widespread establishment of real-time credit transfers does not only affect payment service providers who have not yet offered the instrument, but also the active players. The reason: since real-time credit transfers must not be more expensive than conventional transactions in the future, market participants expect their share of all transfers to rise from 10 to at least 30 to 40 per cent. This trend is promoted by the rising interest rate level, which rewards the holding of credit balances again. But if the number of transactions grows by at least a factor of three, all the payment service providers whose real-time infrastructure has so far been based on makeshift solutions will run into difficulties. A corresponding check is therefore urgently required.

In retail payments, the pan-European initiative EPI – with a meanwhile limited scope of services as an account-based P2P and e-commerce procedure – faces important fundamental decisions at the turn of the year 2022/23. This concerns, for example, the questions of whether the cooperative finance group will rejoin the EPI and whether and how the initiative as a whole will move forward.

New use cases for retail payments
The key service providers in the retail payments sector will continue to work on improving their capabilities in 2023. The issuers will, for example, further develop the girocard for e-commerce. Many payment service providers are working on supporting various omnichannel concepts, not least as a result of the Corona pandemic. The focus here is not only on the now generally known use cases such as click & collect, but also on

  • The use of online payment methods at the point of sale, such as buy now, pay later,
  • The support of franchising and cooperation models, for example cross-channel and cross-company returns, and
  • The evaluation of customer behaviour across the various touchpoints.


In October 2023, the ECB's analysis phase on the digital euro will end and the Governing Council will likely decide to start the realisation phase. Since the digital euro is currently being designed as a retail euro, various banks in Europe are already working in parallel on the introduction of so-called tokenised commercial bank money in 2023.

How can the financial institutions – in view of the shortage of skilled workers as well – cope with the enormous number of tasks? It will only work if the willingness to cooperate across banks increases, standard solutions become more widespread and outsourcing is also considered. There should also be a growing willingness to renew the foundations, if necessary, instead of continuing to build on existing legacy systems while ignoring the "technical debt".

Those are a lot of projects to cover already – and we have not even talked about the impact of the coming DORA regulation, accessibility regulations and the PSD3 looming on the horizon.

Author: Hubertus von Poser, Head of Consulting Payments, PPI AG

Stablecoins blog post series – part 1: background

If you deal with the subject of cryptocurrencies, you will inevitably stumble across the topic of stablecoins, and the question of what exactly stablecoins are quickly arises. In this series of blog posts, we want to take you on a brief, condensed journey through this topic.

A stablecoin is a cryptocurrency that is stable to a certain base currency. The most common use case is in the area of crypto trading because the (cross-border) clearing between crypto exchanges can be processed faster with stablecoins than via the classic payment channels. In addition, they are becoming increasingly popular in emerging and developing countries due to their stability of value compared to local currencies.

In short, the benefits of a stablecoin can be summed up in four main points:

  • Value reference and medium of exchange for trade
  • Protection against exchange rate fluctuations
  • Generating interest income in the area of decentralised finance
  • Fast and limitless payments

Algorithmic vs. collateralised stablecoins
There are two different types of stablecoins: collateralised stablecoins and algorithmic stablecoins:

In the case of collateralised stablecoins backed by USD, the company behind the stablecoin deposits USD in a bank and issues its stablecoin. The aim is to achieve 1:1 cover. In the case of algorithmic stablecoins, only an algorithm tries to keep the exchange rate between the stablecoin and the underlying asset (e.g. USD) constant.
After the collapse of the algorithmic stablecoin "TerraUSD" in May 2022, there is only one really significant algorithmic stablecoin left: MakerDao's "DAI".

Collateralised stablecoins are usually issued by crypto exchanges. The biggest stablecoins sorted by market capitalisation are Tether, USD Coin and Binance USD. Together, they reach a total market capitalisation of around USD 130 billion (as of Nov. 2022).

Stablecoins digitally represent the value of an underlying asset on a 1:1 basis and are considered digital money. They are often covered by USD bank deposits, US government bonds or other securities. If one remembers the so-called gold standard, it is easy to recognises quite intentional parallels here.

Advantages compared to classic payments
The advantages over classic payment systems are that stablecoins are accessible to everyone worldwide and around the clock. The transaction fees are low, and cross-border payments can be made quickly and easily. A credit transfer is also possible without KYC and without the involvement of a bank. All that is needed is a smartphone with an Internet connection and a digital wallet of the currency.

As mentioned at the beginning of our article, in addition to crypto exchange traders, more and more people from emerging and developing countries have a particular interest in stablecoins.

Many emerging and developing countries are struggling with high double-digit inflation rates. The own national currencies continue to lose value against the US dollar. This also affects the trust of the citizens in the respective countries. In the recent past, many of these countries experienced a so-called "bank run".
A bank run or banking storm occurs when investors want to withdraw their deposits from their banks as soon as possible. If several or all banks within a market economy are affected, this is referred to as a banking storm or banking panic.
Governments were therefore forced to close local banks. For local citizens in such a situation, stablecoins can become an attractive alternative to their domestic currency to protect themselves from financial impasses.

In various situations, stablecoins can therefore be a practical solution to problems that cannot be solved or can only be solved poorly in the FIAT system, or may even be a way out for citizens in times of economic difficulties. However, where there is light, there is also shadow. And we want to look at that with you in part 2 of our series.

Authors: Philipp Uhinck, Benjamin Schreck

Half-time whistle – the ECB's first assessment of the two-year "digital euro" analysis phase

As reported in a previous blog post, the European Central Bank (ECB) has started a two-year analysis project in October 2021 to assess how the digital euro should be designed. The outcome of this analysis phase will be a decision on whether and in what form the ECB provides the digital euro.

At the halfway point of the two-year period, an interim report was published by the ECB on 29 September 2022. This report highlights many of the questions and theses we addressed in the previous blog series on the digital euro. Thus, the ECB report takes up the progress made and addresses the basic design options for the digital euro that were recently approved by the ECB Governing Council. In this article we would like to explain what these are in a compact way:

Online and offline payment execution
Currently, the ECB is focusing on the following two transaction options:

  1. Execution of online transactions validated by an intermediary
  2. Execution of offline transactions in a peer-to-peer context that are validated directly or without an intermediary


Data protection, anonymity and credit control
In terms of consumer confidence, the ECB Governing Council describes in its report that the digital euro is expected to have similar data protection provisions as current digital payment methods. Low value payments are to receive higher data protection than payments with comparable maximum amounts. A fully anonymous payment execution without amount limits is currently not planned.
In addition, it is being considered that limits be introduced to control the credit balances. The aim is to restrict the use of the digital euro so as not to artificially create an alternative form of investment for consumers.

Important milestones in 2023

  1. In the first quarter of 2023 the European Commission will prepare a proposal for a regulation on the introduction of the digital euro.
  2. By the end of October 2023 the ECB Governing Council is to decide whether and how the development of the digital euro will continue. The following phase can extend over three subsequent years.
Source: ECB
https://www.ecb.europa.eu/paym/digital_euro/investigation/governance/shared/files/ecb.degov220929.en.pdf


Public funds as a catalyst?
Even if the half-term review still leaves much room for interpretation and design, initial tendencies are becoming clear. Similar to what is described in the report, we as PPI see that public funds in digital form can make an important contribution to the digital age. The digital euro in the current consumer context would be an important first cornerstone. We are therefore continuing to follow this topic with great enthusiasm and will continue to follow developments on the digital euro closely in the EBICS blog.
Until next time.


Author: Philipp Schröder

EBICS real-time submission or: who transfers millions of euros with PayPal?

Admittedly, what the development of FinTechs has brought to the market in recent years is smart, lean and, above all, fast. Direct feedback on mobile devices while on the move at the point of sale or on the couch while shopping online is completely normal today, and modern shoppers no longer want to do without it.

However, imagine you have to transfer large amounts of funds or you have the responsibility for other people's money in your company. What standards do you set here for the security and reliable, transparent processing of your payments? Large volumes not only concerning the amount of funds but also the technical sizes of the file processing for bulk payments require other procedures that have long been tested and established with trusted partners of the financial institutions. EBICS with batch processing of large collective files is the European banking standard on which all payment experts rely and which is being introduced step-by-step in a binding manner by more European countries. These established EBICS concepts have now been adapted for the real-time submission and instant payments enabling an innovative online processing.

Security does not exclude speed
The communication with your established financial institutions and the secure transfer of your payment files is now also provided with EBICS as a real-time submission. Based on the WebSocket interface introduced with the EBICS real-time specification, created payments or uploaded payment files are submitted to the bank server with the order type WIP (or corresponding BTF with EBICS 3.0). In the EBICS client the user immediately receives an active success message as a push message about the processing of the payment at the financial institution as a C5N notification. The standard protocol return messages of the financial institution's pain.002 status report are of course also provided. All this is possible if all the products involved are perfectly coordinated and integrated in the continuous process. Mobile EBICS apps for a payment release on the go also map these real-time processes. 

Secure in the fast lane
The first financial institutions are using this feature in productive operation in order to provide their customers with the quality and security they are used to with innovative speed. It may take some time before the large funds transfers are "smart" and quickly transferred from the couch to the companies' accounting departments.

But who knows what habits have crept into some home offices in the meantime. In any case, decentralised work environments have reached a new dimension. Most companies now offer the possibility to work from home, and department heads and authorised signatories also work in their home office. Releases of large payments with distributed signatures are therefore submitted from home in real time and immediately confirmed.

Furthermore, the WebSocket protocol offers the additional option of push notifications sent from the financial institution to the users of the payment application. Apart from the simple status return messages for payments, the financial institution also communicates with its customers in the form of text messages. At the user's request, the messages appear as a flyout on the GUI and are collected in a separate mailbox for reading and downloading.

APIs or not: A smart and fast processing with the usual security standards of your financial institution is no problem with EBICS either!

Author: Christian Veith


DORA – Digital Operational Resilience Act Part 2: Outlook and objectives

DORA is intended to counter the growing cyber risks. What regulations are planned? Who will be affected by the regulations?

We want to highlight this in two separate and consecutive blog posts. In the first part, we gather information on governance and organisation and look at the extensive ICT risk management requirements, ICT-related incident reporting and risks from ICT third-party providers.

In the second part, we give an outlook on upcoming developments – up to the question of how US cloud providers can be motivated to consider establishing branches in the EU. 

Part 2 

The European Parliament and the Council are expected to adopt the official text of the regulation in autumn 2022, after which it will be published in the Official Journal of the European Union. It is expected that the DORA regulation will apply throughout the EU by the end of 2024. Already at this stage, financial institutions and financial service providers should think about the implementation of an adequate ICT risk management and consider appropriate measures.

Financial companies have an intrinsic interest in protecting their digital operational resilience and improving their resilience against cyber attacks, because operational disruptions can lead to significant revenue losses and – as a result – immense reputational damage. The fact that large financial institutions and Fin- and BigTechs represent a large projection surface for hacker attacks and that the exponentially advancing digitalisation is becoming increasingly relevant reinforce the need to implement EU measures to strengthen the digital operational resilience of financial companies.

Due to the fact that financial companies are usually very strongly interconnected, even a localised cyber incident can pose enormous systemic risks for the financial sector and endanger the financial stability. The products and services provided by financial companies are often fundamental to the functioning of a society. The costs incurred by a cyber attack often mean very high costs for the society and financial companies.

On the one hand, financial companies may be deterred from reporting cyber incidents to the relevant authorities in view of reporting costs and possible reputational damage. On the other hand, cyber incident reports could generate significant external benefits in that other financial companies could identify and close security gaps. However, the proposed regulation lacks proportionality. Financial companies' ICT risk management should focus only on critical elements of the digital operational resilience. DORA, meanwhile, includes all physical components, infrastructures, premises and data centres, regardless of their operational risk. 

DORA requires financial companies to terminate contracts with critical ICT third-party providers if they violate laws, regulations, directives or contract terms, or if they are forced to do so by a financial supervisory authority.

This is likely to increase the operational risk for financial companies because it may be difficult to find suitable alternative providers on an ad hoc basis. Instead, DORA should promote a close coordination between the players concerned, articulate a catalogue of sanction levels and at least provide for transition periods. A strict contract termination mandate should be a last resort.

The restriction on concluding IT supply contracts with critical ICT third-party providers from third countries is a strong interference in the contractual freedom of European financial companies. This measure could paradoxically run counter to the strengthening of digital operational resilience, as financial companies could find themselves forced to contract providers that have a lower level of cyber maturity. This restriction has the potential to limit the selection and access to more cyber-secure and innovative ICT solutions, products and services.

The EU Commission's goals of reducing the European financial sector's dependence on US cloud providers should not turn into actionism. A more targeted measure would be to use regulatory measures to encourage these providers to establish branches in the EU so that they could be monitored more effectively by the local supervisory authorities in connection with operational risks.

In 2023 the European Banking Authority (EBA) will be responsible for the mandate to create the regulatory framework for MiCAR and DORA. In addition to its supervisory duties, the EBA is entrusted with the task of developing supervisory guidelines and procedures, as well as guidelines to ensure the exchange of information between all relevant parties. These include i.a. regulated issuers of crypto-assets, national competent authorities, the ECB and other relevant central banks. The time for this is tight, as everything has to happen before the date on which MiCAR and DORA are applied. The framework to be developed for DORA will provide a supervisory framework to ensure the monitoring and mitigation of cyber risks and ICT-related incidents. For the MiCAR regulation, on the other hand, the EBA will have to develop specific requirements for issuing crypto-assets and offering crypto-services.

Source of the figure: EU Digital Operational Resilience Act (DORA) | Compliance | Haufe


Authors:
Salar Hydary (working student, Consulting Payments)
Judith Petersen (Senior Manager, Consulting Payments)

DORA – Digital Operational Resilience Act: Part 1: Why digital operational resilience should be assessed uniformly at EU level

DORA is intended to counter the growing cyber risks. What regulations are planned? Who will be affected by the regulations?
We want to highlight this in two separate and consecutive blog posts. In the first part, we gather information on governance and organisation and look at the extensive ICT risk management requirements, ICT-related incident reporting and risks from ICT third-party providers.
In the second part, we give an outlook on upcoming developments – up to the question of how US cloud providers can be motivated to consider establishing branches in the EU.

Part 1

The European Commission, the Council of the European Union and the European Parliament reached a preliminary agreement on the Digital Operational Resilience Act (DORA) proposal on 22 May 2022. DORA thus moves to the centre stage as an integral part of the strategy to digitise the entire European financial sector. The European Commission first published the legislative proposal for DORA on 24 September 2020 as part of the digital finance package. The triumvirate of the Commission, Council and Parliament already adopted the digital finance package in September 2020 to realise the cross-border digitalisation.
The digital finance package includes the following parts:

  • Strategy for the digitalisation of the financial sector
  • Legislative proposals on crypto assets (markets in crypto-assets regulation, pilot regime for market infrastructures based on distributed ledger technology, transfer of funds regulation)
  • Legislative proposals on the operational resilience of digital systems (DORA) of the financial sector
  • Strategy for mass payments  

The European strategy for digital operational resilience was completed with the two important crypto regulations markets in crypto-assets regulation (MiCAR) and the transfer of funds regulation (ToFR). On 30 June 2022, the European Union gave the green light to the MiCAR regulation for the supervision of the crypto industry.
Already one day earlier, on 29 June 2022, the European Parliament had reached an agreement on the ToFR.
The aim of DORA is to ensure financial stability, consumer protection and market integrity on the one hand, and to effectively remove regulatory barriers in the financial sector through legal harmonisation on the other. It also creates an EU-wide, cross-sector framework to manage and mitigate the risks associated with information and communication technologies (ICT risks). The DORA regulation affects traditional financial players such as financial institutions, insurance companies and investment companies, but also FinTechs and BigTechs, crypto service providers and trading venues. Micro-enterprises that employ fewer than 10 people and whose annual turnover or annual balance sheet does not exceed EUR 2 million are excluded from the scope of application. (Art. 3 (1) No. 50 in conjunction with Article 2 (3) of the annex to the recommendation 2003/361/EC). 

Control and organisation
Financial institutions and financial service providers should have internal governance and control frameworks that ensure the effective and prudent management of all ICT risks (Art. 4 para. 1). Financial institutions and financial services providers should have a robust, comprehensive and well-documented ICT risk management framework that enables them to address ICT risks directly and effectively (Art. 5 para. 1). The governing body defines, approves and monitors the ICT risk management framework and is accountable for its implementation. To ensure a well-functioning governance, funds should be allocated for investments in ICT resources, including training on ICT risks for the employees (Art. 4 para. 2). 

Requirements for ICT risk management
The requirements listed in DORA to provide an adequate ICT risk management require specific functions. The ICT risk management framework is documented and reviewed at least annually, as well as when serious ICT-related incidents arise from digital operational resilience audits or audit procedures. The aim is to identify potential threats at an early stage, gain insights and ensure a continuous improvement of the IT risk management. (Art. 5 para. 9 DORA)
The ICT management must ensure protection and prevention against cyber attacks or minimise vulnerability to cyber incidents, and implement policies and procedures that ensure the "resilience, continuity and availability of ICT systems" and "high standards of security, confidentiality and integrity of data" (Art. 8 para. 2).
Financial institutions and financial service providers should implement an ICT strategy designed to respond promptly, effectively and appropriately to all ICT-related incidents, in particular cyber attacks, so as to minimise damage, ensure resumption of activities and restore operations as far as possible (Art. 10 para. 2). The implementation of mechanisms that both detect vulnerabilities and record all ICT-related incidents is essential.
As a market player with a strong customer focus and a reputation for integrity, financial institutions and financial service providers should have communication plans in place that "enable the responsible disclosure of ICT-related incidents or significant vulnerabilities to customers and other financial companies, as well as to the public" (DORA Art. 13 para. 1).

Reporting ICT-related incidents
DORA requires financial institutions and financial service providers to implement management procedures to monitor, identify, classify, track, log and report serious ICT-related incidents to the competent authorities (Art. 15 para. 1).
The addressees of reports of serious ICT incidents are the competent national authorities. Financial institutions and financial services providers must provide relevant details of incidents to other institutions or agencies, such as the European Supervisory Authorities (ESAs), the European Central Bank (ECB), or the central contact points designated in the directive on security of network and information systems (NIS Directive). Serious ICT-related incidents are to be reported by authorities in a centralised manner at Union level. Financial companies will be required to submit initial, interim and final reports. Should an ICT-related incident have an impact on the financial interests of service users and customers of the respective financial company, they should be informed immediately (Art. 17 para. 2).

An essential task of the ESA is to publish annually a comprehensive report in anonymous form, which provides information on the reports of competent authorities on serious ICT-related incidents. This concerns the minimum number of serious incidents, their nature, the impact on the business activities of financial companies or customers, as well as the costs (Art. 20 para. 2). In addition, the proposed regulation obliges financial institutions to ensure that contracts for the use of ICT services are terminated if ICT third-party providers violate applicable laws, regulations or contractual terms (Art. 25 para. 8). 

Check of the digital operational resilience
The ICT risk management of financial institutions and financial service providers needs to be regularly assessed for defence preparedness and detection of vulnerabilities, deficiencies or gaps and prompt implementation of corrective actions. ICT systems need to be thoroughly checked on a regular basis. Such a check must be performed at least once a year and documented accordingly. Conducting prevention, detection, response and recovery tests is essential to comprehensively address any vulnerabilities, deficiencies or gaps (Art. 21 para. 5).

The most important instruments for checking the digital operational resilience are the following (Art. 22):

  • Vulnerability assessments and checks
  • Analyses of open source software
  • Network security assessments
  • Gap analyses
  • Physical security analyses
  • Physical security checks
  • Questionnaires and scan software solutions
  • Source code checks, as far as practicable
  • Scenario-based tests
  • Compatibility tests
  • Performance tests
  • End-to-end tests
  • Threat-driven penetration tests


How demanding the resilience tests have to be depends largely on the size of the business and risk profile of each financial company.
Particularly high requirements for digital operational resilience checks apply to major institutions in the payments sector, for example large financial institutions, large payment institutions and large e-money institutions. This also applies to sub-sectors that play a central role in payments, banking, clearing and settlement. 

Risks from ICT third-party providers
DORA places a special focus on the EU supervision of so-called ICT third-party providers and the associated ICT third-party risk. The outsourcing of digital functions plays an important role in the ICT strategy of financial companies today. This is where the ICT third-party providers come in. They offer financial companies the provision of storage space or computing power (infrastructure as a service) and the provision of software applications (platform as a service).
Outsourcing can only work if financial institutions can fully monitor and control the subcontracting processes. Financial companies that use ICT services from ICT third-party providers are responsible for ensuring that they comply with the DORA regulation (Art. 25 para. 1). However, if a financial company finds that the ICT third-party provider violates applicable laws, regulations or contractual conditions in the provision of IT services, the contract with the third-party provider must be terminated (Art. 25 para. 8). Financial companies need to put exit strategies in place to deal with failures of ICT third-party providers. The termination of the contract must not conflict with the compliance with regulatory requirements or impair the quality of the services offered (Art. 25 para. 9).
In summary, it can be stated that DORA aims to create an EU supervisory framework for "critical" ICT third parties (Art. 28 para. 1). DORA grants the financial company the right to fully monitor the services to be provided by the ICT third-party provider (Art. 27 para. 2). In doing so, the competent financial supervisory authorities may force financial companies to temporarily suspend some or all of their contracts with ICT third-party providers until the risks have been eliminated. Authorities may, if necessary, require financial companies to terminate, in whole or in part, the relevant contractual agreements concluded with critical ICT third-party providers (Art. 37 para. 3).
Before concluding a contract with an ICT third-party provider, financial institutions and financial service providers must check whether the respective IT supplier is to be classified as a critical provider or whether it covers important digital functions. Financial institutions and financial service providers should check whether their ICT third-party provider is substitutable or whether several contracts are concluded with it (Art. 25 para. 5). The assessment of these criteria is important in that financial companies are not allowed to have contractual relationships with critical ICT third-party providers that are based outside the EU and thus not established in the EU (Art. 28 para. 9).

Source of the figure: EU Digital Operational Resilience Act (DORA) | Compliance | Haufe


Authors:
Salar Hydary (working student, Consulting Payments)
Judith Petersen (Senior Manager, Consulting Payments)

SEPA 2.0 is in full swing – the migration to new format specifications is starting!

New format specifications of the German Banking Industry Committee (DK) have been in force since November 2021. The changes have not had too much impact on financial institutions and their customers so far. In November 2023, however, this will change abruptly!

The SEPA formats for credit transfers and direct debits are changing comprehensively and all payments processing service providers as well as their end customers must get ready and make preparations for those upcoming changes.
As SEPA 2.0 will de facto affect all components and all systems, dealing with the topic and all its dependencies at an early stage is of great importance for smooth processing and uninterrupted further processing of payments.

The EPC published implementation guidelines in June of this year, which, in addition to the corresponding specifications, provide further information about the anticipated changes. The use of structured address data is an essential topic of the upcoming adjustments. Whereas addresses could previously be submitted and processed unstructured by specifying the name and address, with SEPA 2.0 addresses must be specified in a structured manner. In future, there will be separate fields for the name, the street and house number, the postal code and the ISO country code. In addition to the use of structured address data, adjustments to individual fields, such as the batch booking flag, have far-reaching consequences. With the new default setting true of the batch booking flag, a batch booking will be executed in the future. Only if there is a corresponding agreement with the customer for single bookings, each transaction will be shown individually on the payer's (ordering party's) account statement if the value false is set. 

The upcoming changes will therefore not only have an impact on the payment file and payments systems themselves, but will also affect peripheral systems such as master data systems. Many banks that rely on converter solutions or older SEPA format versions now have the chance to take a holistic look at their systems and ensure smooth further processing of payments as part of a project. In this approach, it is advisable to make use of mapping tables, which make analyses, evaluations and implementation recommendations easier and more targeted. This way, separate rules and mechanisms can be established for each institution.

The TARGET2/T2S consolidation has already shown that the migration from the MT to the MX format should not be underestimated and that corresponding projects require more time than many institutions had thought. A postponement of the date by the ECB Governing Council suited many banks. However, postponement and new transition scenarios that go beyond the scenarios in the implementation guidelines should not be presumed for the migration to SEPA 2.0. Those who do not opt for an early start are accepting an enormous risk.

Author: Rebecca Stannull