Consequences of the FASTER Directive: GDPR and the hidden data governance challenge

The EU’s FASTER Directive is intended to modernise withholding tax relief by moving from document-based processes towards structured digital reporting. While much of the discussion has focused on operational efficiency, one important question has received far less attention: what happens to all of the personal data moving through the payment chain?

FASTER introduces two reporting models: direct reporting and indirect reporting. These fundamentally change how Certified Financial Intermediaries (CFIs) exchange information. Those changes bring GDPR considerations that extend well beyond traditional tax reporting.

Figure 1. FASTER Reporting modalities.

How FASTER changes the reporting model

In the direct reporting modality, each CFI in the payment chain reports its own registered owners to the Source Member State Competent Authority (SMSCA). If the CFI is also acting on behalf of an N-CFI, it will report those registered owners too. 

In the indirect reporting modality, each CFI reports its registered owners to the CFI immediately above it in the payment chain. Again, if any CFIs are acting on behalf of NCFIs, the CFI concerned will report its own registered owners as well as the registered owners of the N-CFI. This cycle repeats up the payment chain to the topmost level withholding agent or designated CFI who reports the entire payment chain to the SMSCA. 

FASTER does not describe every operational detail about how tax relief is granted. To that extent FASTER is a reporting framework that is based on the presumption of a common interest in robust and comprehensive relief at source and quick refund systems. The practical implementation of those “robust” and “comprehensive” relief mechanisms can still vary by Source Member State (SMS). However, the indirect reporting mode will still have all CFIs transferring data up the chain of payment with only the withholding agent or other designated reporting CFI reporting that data to the Source Member State Competent Authority (SMSCA), usually the tax administration. The direct reporting mode, on the other hand, will see each CFI reporting its own direct registered owners to the SMSCA. So, the indirect mode will effectively give the SMSCA the entire payment chain from the report of the withholding agent. The direct reporting mode will allow the SMSCA to reconstruct the payment chain from multiple reports, but with more work involved. In both cases, relief may be granted to clients of non-CFIs (N-CFI) provided there is a legal agreement in place in which the N-CFI has given permission to a CFI (and the CFI has accepted the responsibility) to undertake reporting on the N-CFI’s behalf.  

Why indirect reporting raises new GDPR questions

The same problem occurs in both modalities but is more pronounced and complex in the indirect model, that of data protection. Let’s look at this from the bottom of the payment chain upwards with a FASTER lens. I may be a local CFI or an N-CFI obtaining tax relief benefits for my clients. In the direct reporting model, I only have to worry about getting the data to the SMSCA and they will likely provide a secure portal for that purpose in much the same way that this happens in FATCA and CRS today. However, in the indirect mode, I will have to provide all the reporting data to the CFI above me in the payment chain. They in turn will aggregate my data with data received from their other CFI and N-CFI relationships and pass that up the chain, the amount of such data increasing the further up the chain we go. 

Who is responsible for personal data?

The data concerned is personal data, name, address, TIN etc. For individuals it will clearly fall into the classification of personally identifiable information (PII) which is covered by another EU regulation: GDPR. So, the questions that arise for CFIs at the bottom of the payment chain are: 

1. Who is receiving my clients’ personal data? Surely, I will have to know who each party is in the chain, which I may not currently know. 
2. What are they doing with it? I will be a controller for my own clients’ personal data when I collect and use it for FASTER relief and reporting purposes. If they receive, validate, store, aggregate or forward the data for their own FASTER, custody or withholding-tax obligations, they are more likely to be independent controllers, or in some cases joint controllers, rather than processors. In the indirect FASTER model, a CFI that receives data from multiple downstream parties, validates and aggregates it, and then passes it to the next CFI or withholding tax agent is itself carrying out controller processing and needs its own GDPR lawful basis, transparency controls, minimisation controls, accuracy controls, retention controls, security controls and accountability controls. 
3. How is my client’s personal data being protected by each recipient? 
4. How will it be processed or manipulated? 
5. How long will it be stored and by whom? 
6. What if some of the data is wrong?  

Cross-border data transfers add another layer of complexity

We must also consider that some CFIs may be established in third countries e.g., the USA. Many FASTER indirect-reporting flows will thus be cross-border in the GDPR sense as opposed to the FASTER sense. Intra-EEA flows are cross-border but not Chapter V restricted transfers. EU/EEA-UK flows are currently adequacy-based. Transfers to non-adequate jurisdictions or to global vendors (on behalf of CFIs) outside the EEA/UK adequacy perimeter will require a specific transfer mechanism, and onward-transfer controls will need to be built into the CFI-to-CFI and vendor contracts. 

Figure 2. US CFI reporting in an indirect reporting jurisdiction via an EU CFI.

While it’s unlikely, where personal data is transferred from the EEA to a US CFI or vendor, that transfer will be a Chapter V GDPR transfer. This could, theoretically, be an EU CFI with a US CFI above them in the payment chain. The personal data may be covered by the EU-US Data Privacy Framework where the US CFI recipient is actively certified and the transfer falls within the scope of that certification. If the Data Privacy Framework is not available, for example because the recipient is not certified or is not eligible to certify, the transfer will need another recognised mechanism, such as Standard Contractual Clauses (SCC), Binding Corporate Rules (BCR) or another Article 46 safeguard. In each case, the CFI will also need to address onward transfers, data minimisation, security, retention and accountability. 

The more likely scenario in this example, would simply be a US citizen seeking tax relief on investments in the EU and presuming that the SMSCA has approved the use of paper Form 6166 as an adequate alternative to an eTRC. Such a US person’s personal information will not usually be protected at the US CFI level by GDPR. It will instead be protected principally by US financial privacy and safeguarding regimes, such as the Gramm-Leach Bliley Act (GLBA), Regulation P, Regulation S-P, applicable cybersecurity rules and state breach-notification laws, depending on the regulatory status of the US CFI. Those rules are likely to require privacy notices, controls over disclosure and redisclosure, administrative, technical and physical safeguards, incident-response procedures and oversight of service providers.   

In a FASTER indirect-reporting chain, those statutory protections would probably be supplemented by CFI-to-CFI contractual terms (and CFI to vendor terms) restricting use of the data to FASTER relief, withholding-tax administration and regulatory reporting, requiring secure transmission, limiting onward transfers, imposing retention and deletion rules, and allocating responsibility for breach notification, data quality and unauthorised reuse. Once the data is received by an EU CFI or SMSCA, the processing will be governed by GDPR, even though the data subject is a US person. 

Figure 3. US CFI with EU CFI and US & EU registered owners in indirect reporting.

Data subject rights under FASTER

Of course, in any of these cases, the rights of the data subject are central. So, it’s to be expected that, at implementation there will be those who test the system by submitting a data subject access request. Such a request could give the CFI at the bottom of the payment chain a real headache. For example, a typical data subject access request could include a request for: 

1. All personal data processed for FASTER 
2. Information about who the data was disclosed to (disclose the chain of payment) 
3. Request for the legal basis and role for the disclosure and 
4. Information about the transfer mechanism especially if it relates to any cross-border transfer involving a non-EU or EEA State 

In FASTER, some of these rights may be difficult to exercise fully because the processing may be based on legal obligation, tax administration, anti-abuse or statutory reporting requirements. That means the data subject may have a strong right to know, access, correct, restrict and challenge, but a weaker right to require deletion or prevent reporting where the controller is legally required to process the data. GDPR also allows Union or Member State law to restrict certain data subject rights where necessary and proportionate to protect important public interests, including taxation matters. 

So, in addition to the practical impact of FASTER reporting on personal information, it’s also possible that CFIs will need to construct policies and procedures to respond to data subject enquiries under GDPR. 

FASTER is also a data governance project

FASTER has the potential to improve withholding tax relief across Europe, but it also creates a fundamentally different data-sharing environment. Particularly in the indirect reporting model, personal data may pass through multiple independent controllers before reaching the Source Member State Competent Authority.

That means FASTER should not simply be viewed as another tax reporting obligation. It is also a major data governance challenge requiring CFIs to think carefully about lawful processing, transparency, cross-border transfers, data subject rights and operational controls under GDPR.

This is the first in our three-part series exploring the unintended consequences of the FASTER Directive. Next we will explore how the Digital Operational Resilience Act (DORA) and FASTER interact.