Introducing the EU’s Central Electronic System of Payment information (CESOP) regime – key legal considerations for client facing documentation

RegCORE Client Alert | Banking Union | Capital Markets Union

QuickTake

On 18 February 2020, the Council of the European Union (the Council) adopted a legislative package consisting of Directive 2020/284/EU[Available here.] (the CESOP Directive) and Regulation 2020/283/EU[Available here.] on measures to strengthen administrative cooperation to combat VAT fraud (collectively the CESOP regime)The legislation CESOP is composed of also includes Implementing Regulation (EU) 2022/1504 and a standard form Article 24c of Regulation (EU) 904/2010, OJ 2010, L 268/1 and Article 4 of the Implementing Regulation (EU) 2022/1504, OJ 2022, L 235/19Show Footnote setting out requirements applicable to payment service providers (PSPs) offering payment services in the EU to transmit information on cross-border payment originating from Member States and on the beneficiary (i.e. the payee) of these cross-border payments. PSPs will have to monitor and transmit information on those who receive more than 25 cross-border payments per quarter to the tax administrations of the Member States. This regime will enter into full force during January 2024.

The CESOP Directive defines cross-border payments as any payment where “the payer is located in a Member State and the payee is located in another EU/ European Economic Area (EEA)Which includes all Member States of the European Union as well as Iceland, Liechtenstein and Norway.Show Footnote Member State, in a third territory or a third country.”See Article 1 CESOP Directive inserting Article 243b(1) paragraph 2 in Chapter 4 of Title XI of Directive 2006/112/EC.Show Footnote Notably, under the CESOP regime this information is centralised in a European Database (the Central Electronic System of Payment Information (or CESOP)) where it is stored, aggregated, and cross-checked with other European databases including onward reporting to anti-fraud experts of Member States via a network called Eurofisc.

The CESOP regime aims at (i) better detection of possible e-commerce VAT fraud and (ii) improvement in the collection of tax revenues on cross-border transactions. To this end, PSPs operating in or through the EU and indeed the EEA will very soon be required to retain and report information about cross-border payments that they process. Client facing documentation of such PSPs may need to change to accommodate such collection and data processing. As a result, PSPs may need to ensure they obtain consent from payees so as to comply with the CESOP regime. How and by what means client consent is obtained may differ between legal systems of Member States. Furthermore, it may be driven by where and how a PSP required to comply with the CESOP regime interacts with a payee, pursuant to what governing law of its client facing documentation as well as whether the payee has any consumer protections at law in the jurisdiction where the payee is domiciled. All of this will determine whether a PSP can make use of “deemed consent” or must use “active consent” to be able to collect, analyse and report data on the payee as contemplated by CESOP. In short, as discussed below, while the CESOP regime may be comprehensive in introducing a pan-EU reporting framework the legal aspects of obtaining effective consent from notably retail clients that are payment services users are very much fragmented along national lines and driven by consumer protection laws and principles of contract law of individual EU Member States.

This Client Alert from PwC Legal’s EU RegCORE provides a focused overview of how CESOP aims to improve detection of VAT fraud across the EU as well as how collection, storage and aggregation of payment services data is envisaged. Given the short time frame until the CESOP regime will become applicable, it is essential for such in-scope institutions to adopt adequate solutions in order to not only meet the technical requirements required by the CESOP regime (covered here) but also how to obtain client consent and what legal considerations are relevant in client facing documentation. Our EU RegCORE team has laid out what to expect and which aspects to monitor as the move to full implementation gathers pace.

CESOP’s scope of application

Under the CESOP regime, PSPs are required to collect and report data regarding cross-border payments as from Monday 1 January 2024, with the first reporting date being Tuesday 30 April 2024. The rules on capturing relevant data are complex and typically involve the identifying and filtering of large amounts of data which needs to be recorded, analysed and reported, potentially in multiple jurisdictions to tax and then anti-fraud authorities. As such, PSPs will be confronted with material reporting obligations as well as IT functions to be able to collect and analyse all the data which needs to be reported.

As discussed in the next section below, this may mean amending existing or introducing new contractual provisions, beyond GDPR data processing language (which should not be confused as equating consent to make reports to tax and anti-fraud authorities) and other data collection language such as standalone consents for say US FATCA reporting. Such changes may conceivably affect a broad range of client facing documentation, both for PSPs that passport across the EU/EEA with an establishment (branch passporting) or without an establishment (services passporting).

The CESOP regime’s new set of reporting rules will apply to PSPs falling within the categories as contained in points (a) to (d) of Article 1(1) of the second Payment Services Directive (PSD2) (itself under review – see standalone Client Alert from our EU RegCORE) including any person or entity benefitting from an exemption from PSD2.

The concept of payments is central to the reporting rules as it covers precisely the information which PSPs will have to keep in their records. Within CESOP, the concept of a payment is closely linked to the definition of “payment transactions” as mentioned in Article 4(5) of the PSD2 and also includes remittances. Accordingly, a payment generally corresponds to a transfer of funds from a payer (the initiator) to a payee (the beneficiary).The definitions of payer and payee are laid down in Article 243a of Directive 2006/112/EC:
•    Payer: “a natural or legal person who holds a payment account and allows a payment order from that payment account, or, where there is no payment account, a natural or legal person who gives a payment order” and;
•    Payee: “a natural or legal person who is the intended recipient of funds which have been the subject of a payment transaction”.Show Footnote

As reflected in the guidelines for the reporting of payment data from payment service providers and transmission to CESOPAvailable here.Show Footnote (the Guidelines), not all PSPs covered by PSD2 are automatically subject to reporting obligations under CESOP. It is possible, for instance, that an entity may fall under the definition of a CESOP in-scope PSP but does not actually provide any of the payment services captured by CESOP. Reporting obligations apply to payment services mentioned in points (3) to (6) of Annex I of PSD2 (Directive (EU) 2015/2366).Show Footnote

Furthermore, the lifecycle of processing payments often involves multiple actors and business models whereby the funds to-be-transferred are passed among various PSPs which can retain the funds for a certain period of time before the actual transferral to the payee occurs. This also is of relevance to payment initiators which are payment institutions for PSD 2 purposes but do not effectively provide any of the CESOP in-scope payment services.

In contrast, as suggested above, the exemption for small PSPs laid down in Article 32 PSD 2 is not extended to the CESOP reporting rules. As such, even small PSPs may be captured by reporting obligations under CESOP if all other conditions are fulfilled, such as those on in-scope payments. Moreover, Article 3(b) of PSD 2 excludes payments effected via commercial agents acting only on behalf of the payer or the payee. Hence, where a commercial agent is acting on behalf of both payer and payee, it must be registered as a PSP, as specified in Recital 11 to PSD2. It follows that commercial agents (i.e. marketplaces) which collect funds from the payer, hold them and then distribute them to the payee will have to report information on the payee under the CESOP regime. This means that small PSPs, with a turnover below EUR 3 million and, in specific cases as illustrated above, commercial agents and electronic communication networks or services, also fall within the scope of the CESOP regime, although they might qualify for less complex reporting. The Guidelines, which currently provide guidance on the legal obligations faced by PSPs may, however, be subject to changes and updates in the future depending on the evolution of the payment market and the application of the CESOP regime’s reporting obligations.

Entities in-scope of CESOP include

1.    Credit institutions
2.    E-Money Directive 2 in-scope institutions
3.    Post office giro institutions
4.    PSD2 in-scope institutions

Applicable reporting obligations Ibid.Show Footnote

1.    Credit transfers
2.    Direct debits
3.    Card payments
4.    The issuing of payment instruments and acquiring of payment transactions; and
5.    Money remittances

Triggering of the reporting obligation

To ensure compliance with the new set of rules under the CESOP regime, PSPs will have to increase their monitoring of payments to determine whether these must be reported. As detailed above, a payment will be in scope of the CESOP regime and trigger an obligation to report and collect the prescribed information where:

1.    the payment is a cross-border payment, and;

2.    the PSP providing payment services in a Member State executes at least 25 cross-border payments in that Member State per quarter to a single payee.

Whether a payment is considered as cross-border is determined in Article 243c of Directive 2006/112/EC. This determination relies on proxies in order to assign a country easily to the payer and the payee. As such, on one hand, the location of the payer shall be considered in the Member State corresponding to;

A.    the IBAN of the payer’s payment account or any other identifier which unambiguously identifies, and gives the location of, the payer; or in the absence of such identifiers; and

B.    the BIC or any other business ID that unambiguously identifies, and gives the location of, the payment service provider acting on behalf of the payer.

On the other hand, the location of the payee shall be considered to be in the Member State, third territory or third country corresponding to:

i.    the IBAN of the payee’s payment account or any other identifier which unambiguously identifies, and gives the location of, the payee; or in the absence of such identifiers; and

ii.    the BIC or any other business ID that unambiguously identifies and gives the location of, the payment service provider acting on behalf of the payee.

Where payees hold multiple accounts, payments should be aggregated for such payee. It is common, nowadays, that a payee offers different payment methods (i.e., direct debit or credit transfers) for the purpose of which it holds different accounts managed by different PSPs. As the person behind these accounts is a single entity, however, the payers’ PSP – possibly the same - must identify whether all the payment accounts are actually linked to a single entity. To do so, PSPs are free to use any information at their disposal, including information collected during the creation of the payment account. As a result, where the aggregation of payments exceeds the threshold number of 25, all payments irrespective of their method would have to be reported to CESOP.

In the opposite scenario where the PSP of the payee receives multiple payments to different accounts which are all owned by a single payee, it is the payee’s PSP which will have to identify whether these payments must be reported. To this end, the latter will have to use all information it has available to determine whether the accounts refer to the same payee and correspondingly aggregate all payments it completes to these accounts. The payers’ PSP will not be captured by reporting obligations under CESOP, unless it executes payments to a non-EU payment account of the same payee, in which case it will have to take these payments into consideration in order to calculate the threshold.

Because PSD2 is applicable to all EEA countries, PSPs wishing to provide their services across the EEA must obtain a license in their country of establishment and comply with the provisions of PSD2 where they intend to use this license in another country. To do so, PSPs must have passported their license by informing other countries of their intention to provide payment services within their jurisdiction – either via a branch, the use of a commercial agent, or from its country of establishment via the freedom to provide services.

The scope of CESOP therefore extends to PSPs from EEA countries which may become subject to the obligation to report and collect information on Member State-level.PSPS established in Northern Ireland must be understood as being established in a third country (and should be reported as such) for the sake of CESOP regime’s reporting obligations.Show Footnote PSPs captured by the new rules under the CESOP regime will need to report relevant information to the country in which it has its registered office or its head office, as well as to any Member State in which it has a branch or an agent.

For example, a PSP may have obtained its payment license in Spain and, by way of passporting, provides payment services also in France and Italy. To determine which data to report in the respective Member States, the PSP will look at its payment license and where its clients are located. In practice where the PSP provides payment services to a payer from Spain to a third country, it reports the payments to Spain. Alternatively, were the PSP provides payment services to a payee for payments going from Italy to France then it will report the payments to France.

Under the CESOP regime it is conceptually conceivable that EEA PSPs must report their data to (i) all EEA countries’ tax offices where they have an establishment (host country); and (ii) the country where they provide their services (home country). In total this could amount to 27+ reports. Each tax office performs certain data quality checks and forwards the data sets it has received to the central CESOP database. CESOP data is cross-checked with other databases and equally reported to anti-fraud authorities through Eurofisc.

To determine which PSP ultimately holds the reporting obligation, the location of the PSPs for both the payer and payee are decisive. Where both PSPs – of the payee and payer – are located in the EEA, the obligation to report will fall on the PSP of the payee. Where the PSP of the payee is located in a third country, said obligation falls on the PSP of the payer. The respective locations are determined by the International Bank Account Numbers (IBANs), or another identification code.The CESOP Directive does not prescribe which code should be used to this end. Where multiple codes are available, the PSP itself must choose which one best identifies the location of the respective payer or payee. In the alternative, the Business Identifier Code (BIC) of the PSP acting on behalf of the payer or payee shall apply.Show Footnote Although this may appear straightforward in theory, there are likely to be many situations, in practice, in which the identification codes do not correspond to the actual location of the payee or payer. Notwithstanding this inconsistency, the Guidelines specify that the fact that the location of the payer and payee based on their respective proxies could differ from their real location does not matter for the purpose of Article 243c.

As is more frequently the case, a scenario where say an Italian-based online PSP provides Italian IBANs to an account holder in, say, ordinarily domiciled in the Netherlands, this IBAN will not correspond to the actual place of residence of the account holder. For example, it is not unrealistic to imagine a situation in which an Italian national, living and studying in the Netherlands transfers money from its account opened with a bank in the Netherlands to its own account in Italy. This is permitted. Indeed, IBAN discrimination, while still a practical problem, is actually prohibited as a matter of EU law. However, the CESOP regime complicates this scenario as under PSD2 and CESOP accordingly, this transfer would be qualified as an in-scope cross-border payment. On the basis of the IBAN and the locations of the PSPs, this payment would also be cross-border. In the context of growing cross-border e-commerce, it remains to be seen how proportionate and adequate the current design of the CESOP regime remains.

Which information does the PSP need to report?

1.    The BIC/ID of the reporting PSP
2.    The name of the payee
3.    The VAT ID of the payee/ national tax number of the payee
4.    The IBAN of the payee
5.    The PSP BIC/ID acting on behalf of the payee
6.    The address of the payee as it appears in the records of the PSP
7.    An indication of payment refunds – yes/ no
8.    The details of any cross-border payment

a.    The date and time
b.    The amount
c.    The currency
d.    The Member State of payment origin
e.    The Member State of refund destination
f.     Location information of the payer (payment origin)
g.    The transaction ID
h.    Information verifying that the payment is initiated at the physical premises of the merchant.

This information must be recorder per calendar quarter, where applicable, and reported to the tax authorities every quarter, within one month after the last month to which the quarter relates. In addition, PSPs are expected to validate the data to-be-transmitted before submission. Whereas the tax authorities have ten days after receiving the PSP information to CESOP and must also validate the completeness of the data or elsewise reject the report. One last and third validation is conducted by CESOP upon receiving the data, where the report can be refused in whole or in part if minimum requirements are not met. In line with the General Data Protection Regulation (GDPR), the information in CESOP will be kept for a maximum of five years following the year in which it was transmitted.

The CESOP regime also provides for an exemption to report and record information for the PSP of the payer, namely where the PSP of the payee is in the EU – and, as such, it subject to individual reporting and recording obligations. Nevertheless, the PSP of the payer retains an obligation to keep account of the number of transactions in order to be able to track whether the threshold of more than 25 cross-border payments is reached, such as where there are reportable payments to that payee in as much as it uses a second PSP outside the EU which would not be captured as an CESOP in-scope entity.

It is also very much conceivable that CESOP regime under-reporting could lead to adverse regulatory and supervisory scrutiny of the PSP. Equally, incorrect or unconsented reporting by a PSP may lead to a wave of complaints to either (a) the PSP, (b) any ombudsman or (c) the regulator both in the PSP’s home Member State and/or any host Member State in which the PSP may engage with the payee.  The problem may further compound itself where industry associations may, in addition to multiple payees, make use of the EU’s collective action legislation and launch class action claims – an issue that could be exacerbated if a PSP, which has concluded (rightly or wrongly) that the PSP is in breach of the CESOP regime’s reporting trigger is not using say a retail payment account as intended and unilaterally either freezes and/or closes that account. This can lead to serious reputational risks in addition to more imminent legal and/or regulatory risks.   

Key legal considerations for (retail) client facing documentation and obtaining consent

More importantly, regardless of the technical implementation set out above, some PSPs may need to also amend existing or introduce new contractual provisions permitting them to be able to collect, analyse and, where required by CESOP, report such data on their payees. Such consent is in particular paramount where retail clients are involved. In most circumstances this may require consent from the client to such data collection, analysis and reporting being made and the type of data and reporting to tax plus anti-fraud authorities may not be covered by existing contractual provisions.

To further complicate matters, in the context of typical set-up of client facing documentation, in addition to the governing law of that documentation, various consumer protection requirements may apply and thus be available to the payee, notably if they are a retail client.  This may be further compounded when two or more jurisdictions are involved i.e., Dutch PSP provides Dutch law client facing documentation to German domiciled client.  The German domiciled client may be bound by the Dutch law contractual provisions, but these are subject to the “general good” provisions that apply when the Dutch PSP passports into Germany on a services basis. The German (retail) client would thus, in addition to being able to make regulated complaints to the Dutch ombudsman or regulator, or in the alternative making use of its right to commence a civil action in the Dutch courts for breach of contract, also doing the same in Germany i.e., to the German ombudsman, regulator or in the courts for breach of the consumer law and/or general good protections which apply very much in addition to and are not excluded by the Dutch law governed contractual documentation.

The same would also apply for a German branch of the Dutch PSP although in most instances, the branch’s client facing documentation would be governed by German law. Nevertheless, a German client could in addition to pursuing any of the actions discussed above in Germany, commence action in the Netherlands. To further compound the issue, in both scenarios above industry associations or the regulators themselves could commence action whether by collective action under EU legislation or by the regulators individually or as part of an EU-wide “common supervisory action” investigating the PSP for alleged breaches.

The same is equally true in the scenario of the Italian student discussed above moving from the Netherlands to Germany still using the Dutch PSP’s Italian IBAN numbered account (which is all perfectly legally permitted) but now ordinarily residing in Germany (which is equally legally permitted). Such a scenario opens further issues that a number of PSPs may themselves, even well prior to the go live of the CESOP regime, have inaccurate data on their clients as to where they actually reside. This is the case despite such obligation to update a PSP on current ordinary residence in a frequent manner (and at least every two years) being an EU legislative obligation that most sophisticated PSPs have also made a contractual obligation in addition to implementing this in the customer management lifecycle.

Lastly, and perhaps rather ironically, how the CESOP regime applies to virtual IBANsIn Germany for example, virtual IBANs are provided by credit institutions. They look like real IBANs although there is no individual account connected with each of them. Rather, the IBAN number serves to allocate payments, such that many virtual IBANs are usually connected to one “real IBAN”. According to BaFin, all virtual IBANs are deemed to be accounts falling within the meaning of Section 154 of the German Fiscal Code and that credit institutions are obliged to submit these to the data base pursuant to Section 24c KWG. Show Footnote is not covered in the CESOP regime’s drafting and no supervisory nor tax authority guidance has been published as of the date hereof. Virtual IBAN’s perform a number of useful means, notably in ways to mitigate if not circumvent IBAN discrimination issues, including with respect to making and receiving payments to tax authorities. As an example, German tax authorities are not capable of or otherwise have a strong preference to avoid making or taking payments from non-German IBANs. The issue exists in a number of other countries. In order to facilitate this, certain PSPs (large and small) may use virtual IBANs to allow for in-country payment services. Other instances of virtual IBANs are used by PSPs to facilitate multi-currency accounts.  Equally here, no guidance has been published.

Regardless of what IBAN is being used where and in respect of what client facing documentation in place with whom, the issue of how to obtain consent and whether as “active consent” or, where permitted by the respective and applicable laws, “deemed consent” is crucial and a paramount issue that PSPs need to get right. The use of deemed consent language in general terms and conditions (GTCs) is widespread in how it is used in contracts across EU Member States, which extends beyond GTCs used in financial services firms. The risks arising from using “deemed consent” language may well outweigh its benefits, especially when transacting with retail clients and consumers, in the context of financial – including payments – services, became evident in a landmark ruling of the German Federal Court (Bundesgerichtshof – BGH) delivered on 27 April 2021 in which it held that the use of “deemed consent” clauses are not a permitted means of amending GTCs in Germany.

What that ruling means for financial services firms as well the risks it introduces for other EU Member States are covered by PwC Legal’s EU RegCORE in a separate Client Alert, available here. This development is crucial for PSPs in that while EU financial services law and supervisory practice prescriptively stipulates conduct of business requirements applicable to retail clients across the EU, neither contract law nor consumer protection law is (at least not yet and not foreseeably anticipated of being) harmonised at the EU level. This means that besides the relevant market practices differing along national borders with respect to differing market types, PSPs will have to thoroughly assess compliance with jurisdiction-specific considerations with respect to transacting with retail clients. Following the BGH’s landmark ruling, PSPs intending to continue using “deemed consent” language in their GCTs across multiple EU Member States, it may mean that they need to perform an extensively overhaul to tailoring these GTCs and how to achieve consent to jurisdiction-specifics.

Outlook and next steps

The new CESOP regime will require PSPs to collect and report information on cross-border payment transactions and will become effective as from 1 January 2024. The new rules under this regime were introduced as part of an EU-wide overhaul of rule aiming to detect and combat VAT fraud arising from cross-border e-commerce transactions. To achieve this objective, these rules are likely to impose significant new obligations on the reporting and IT functions of PSPs.

In view of the relatively short time period before the CESOP regime comes into full effect, and as different EU Member States impose different penalties for incorrect or late reporting, PSPs should swiftly consider how best to ensure that compliance with reporting obligations and related rules can be upheld going forward as this regime becomes applicable.

Some of this may include beyond the following imminent steps for PSPs (to the extent not already underway) beyond “just” the tax reporting specific priorities, in:

1.    Performing a legal and regulatory impact assessment: determining the level of impact as segmented by Member States, entities and types plus client categorisation, combination of multiple accounts (across product types) to create a “single customer view”, availability of human and technology resources, operational impact and impact on overall governance, business operating model as well as three lines of defence risk model;

2.    Working backwards from 1 January 2024 on technology and implementation plan to ensure it meets financial services regulatory and supervisory expectations: to build a detailed implementation roadmap (including forward planning changes to legal and other client facing documentation (including consents) reflecting the jurisdiction-specific aspects as applicable to the operational footprint of the PSP as well as the affected client geography and tasking a comprehensive project management team to ensure smooth delivery across multiple workstreams and competing stakeholder, regulatory as well as client facing demands and pressures on timelines;

3.    Updating governance frameworks across all business-as-usual workstreams plus mapping of critical path dependencies in stress scenarios: by integrating CESOP across the PSPs existing systems, policies, procedures and controls as well as reporting to executive and control functions within the PSP as well as to multiple tax authorities and assigning appropriate process owners;

4.    Communicating with clients beyond just contracts and other client facing documentation: in a timely, fair clear and not misleading manner as to changes, their rights and obligations access to help pages and helplines and how and when eligible complaints may be raised to whom and where; and

5.    Training and communicating the above both through a bottom up and top-down approach: to ensure all stakeholders are aware to the sensitivities that may arise in collecting, analysing and ultimately reporting client data to a whole range of authorities in a new manner. This may include training client facing service centres but all other relevant functions that have relevant client-facing touchpoints throughout the customer journey and product lifecycle.

In summary, PSPs should assess what changes CESOP compliance, while great on paper but difficult in practice, need to be included overall but equally, in the shorter term in their respective client facing documentation. Moreover, PSPs need to consider what consents need to be obtained from whom and how and by when. All of this is paramount so as to ensure such PSPs can aim to meet the CESOP’s aims in a timely and appropriate manner that equally does not lead to undue risk for the PSP and no detriment the payees.

While the above may assume that (retail) clients of PSPs read contractual terms and other client facing documentation with the same level of understanding and attention to detail that the PSP let alone the relevant regulatory policymakers and supervisory authorities would like, underestimating the importance of clearly obtained and traceable consent from clients carries a clear risk for any PSP.

Ultimately whether CESOP will have the positive impact intended or instead be a barrier to cross-border payment flows and thus commerce or push other forms of payment instruments remains to be seen.

About us

PwC Legal is assisting a number of financial services firms and market participants in forward planning for changes stemming from relevant related developments. We have assembled a multi-disciplinary and multijurisdictional team of sector experts to support clients navigate challenges and seize opportunities as well as to proactively engage with their market stakeholders and regulators.  

Moreover, we have developed a number of RegTech and SupTech tools for supervised firms, including PwC Legal’s Rule Scanner tool, backed by a trusted set of managed solutions from PwC Legal Business Solutions, allowing for horizon scanning and risk mapping of all legislative and regulatory developments as well as sanctions and fines from more than 750 legislative and regulatory policymakers and other industry voices in over 170 jurisdictions impacting financial services firms and their business.  

Moreover, in leveraging our Rule Scanner technology, we offer a further solution for clients to digitise financial services firms’ relevant internal policies and procedures, create a comprehensive documentation inventory with an established documentation hierarchy and embedded glossary that has version control over a defined backward plus forward looking timeline to be able to ensure changes in one policy are carried through over to other policy and procedure documents, critical path dependencies are mapped and legislative and regulatory developments are flagged where these may require actions to be taken in such policies and procedures.   

If you would like to discuss any of the developments mentioned above, or how they may affect your business more generally, please contact any of our key contacts or PwC Legal’s RegCORE Team via de_regcore@pwc.com or our website.