Komission FASTER xsd malli

The Nordic finance sector in Denmark, Finland and Sweden would like to thank you for the opportunity to comment on the FASTER xsd.

To start, we wish to respectfully highlight that the two-week consultation period allocated for the proposal regarding the reporting model is insufficient. The draft currently under consultation would have required a time‑consuming review also by IT specialists (e.g. to create and test various customer scenarios). Unfortunately, our members did not have sufficient time for this within the consultation period.

An excessively short consultation period is the reason why we have not been able to form a common position in all areas together with all our members (DK, FI, SE).

We would kindly request that, in future, the Commission allows an extended period for consultation by circulating draft proposals in a manner that affords stakeholders adequate time to thoroughly review the materials, prepare comprehensive comments or statements, and undertake the necessary internal assessments.

Comments on reporting format

A standard format across all member states will be crucial for efficient implementation and well-functioning flow.

The industry would have broadly preferred the use of the ISO standard in FASTER reporting. While ISO 20022 will not be used for reporting to tax authorities, intermediaries may still use ISO 20022 messages for exchanges along the chain (e.g., indirect reporting scenarios). Therefore, we understand that the SMPG will work on an ISO 20022 business justification for intermediary-to-intermediary messaging to support FASTER reporting.

It is important that the maintenance of the XSD format happens in a way which allows industries to further align the changes with the ISO20022 format used between intermediaries.

A determining factor will be what information the data fields contain – this requires additional information to assess.

Definitions

It is key to the FASTER reporting that each term is precisely defined and preferably aligned with international market standards. Allowed variations must be clarified, for instance with respect to optional information (e.g. names, which may be written differently with respect to omissions, abbreviations etc.). Definitions and guidelines should take the operational burden of the requirements into consideration. 

Comments to open points from the Commission
(point only mentioned where we have comments)

1. Way data must be reported

We understand that the Commission is cooperating with SOFT-DEV to clarify the way reporting must be provided. We would like to repeat the following comments:

• The more harmonized the reporting approach the more efficient and viable the solution.
• A centralized (EU Portal based) upload of the XSD files to the authorities, would be preferrable, to reduce complexity and support efficiency of the upload process.

2. CFI identification

It is suggested to introduce a unique CFI identification number, and we fully support this suggestion:

• Such number will unambiguously identify an intermediary as a CFI.
• It allows for flexibility within an organisation, where other identifying numbers (LEI for instance) may otherwise cover more CFIs.
• If, as suggested, the number is in the CFI registry, then it allows for effective controls in the CFI-network, ensuring that non-CFIs are not erroneously treated as CFIs.
• We suggest that a CFI get the unique ID immediately by registration in the EU Portal.

3. Non-CFIs – Elements cardinality

• A CFI can only be made responsible for identifying own direct customers, including any non-CFI and only by the information available in the CFI’s records.
• If a non-CFI is part of the reporting network it must be the CFI having the non-CFI as a direct customer, which shares the relevant information on the non-CFI either directly with the authorities or indirectly via an upstream CFI.
• If certain information is required for a non-CFI, it is suggested to prepare a non-CFI certificate (compare to W-8IMY under the US QI regime).
• Even if certain information is required, there may be situations where such information cannot be secured, if the non-CFI is recalcitrant, and this will create a gap in the reporting information for which no CFI can be made accountable. 
  The consequence of such gap may be the loss of relief opportunities for the non-CFI’s customers and/or blacklisting of the non-CFI.
• It should never reflect negative on a CFI if a non-CFI in the custody chain does not want to cooperate on share information.

4. Official address

• To support efficiency of the CFI-framework and likewise the communication from authorities to CFIs, we further suggest including a specific FASTER Point of Contact (PoC) in the reporting information/CFI registrations.

5. Standard xs: Date type

We agree that the date type should be without references to time zone and simplified to “yyyy-mm-dd” only.

• The dates defining the payment and relief rights should be determined by the source country – BUT –
• A harmonisation and clear EU definition of the payment and entitlement defining dates and criteria would be highly beneficial (AGM date, ex date, record date, pay date).
• References to certain hours on the day, for instance on AGM date, will not work.

6. Additional data fields in XSD (and data requirements in general)
Overall we prefer as harmonised a reporting as possible, and no redundancy of information.

• As previously mentioned, we suggest adding FASTER PoC information for CFIs.
• We suggest making a special reporting format for non-CFI scenarios, which
  • Clearly distinguishes non-CFI scenarios from CFI scenarios
  • Allows for both disclosure and non-disclosure of non-CFI underlying customers, dependent on whether another CFI takes responsibility for disclosure of the non-CFI customers.
• We suggest making a special recipient category for tax transparent entities, including joint accounts, to reflect that the registered owner is clearly not considered the (only) BO.
   a) As the registered owner is not the BO, any claim for tax benefits must be raised for the underlying investors
  b) The reporting hence requires two levels, as both the registered owner and the BO(s) must be presented
• A harmonisation and a clear definition of the BO-term, together with a clarification of the operative interpretation, are essential to effectiveness.
• We suggest making a special reporting category for financial arrangements, which require additional attention and possibly more information than standard scenarios.
• A harmonisation and a clear definition of the financial arrangements, together with a clarification of the operative interpretation, are essential to effectiveness. 
• If a security-position is defined by Issuer-CSD (instead of CSD) and ISIN, why is “Issuer” and “Security Type” required? The more information, which is not key to identification, the more burdensome the reporting process becomes (control and reconciliation work increase).
• The use of securities “settled” and “pending settlement” should be clearly defined. (like point of time).

In addition to the above comments on the open points, we would like to point out that requiring the issuer’s official address causes difficulties as it is always a challenge to have this type of information in different registers.  We would hope that this requirement will be removed.

Future changes to the xsd model

It is important to ensure a transparent and structured future change model for the XSD, which allows CFIs’ influence on changes. It is also important that any changes are published well in advance, allowing the industry sufficient time for updates or modifications. Furthermore, it is crucial that these changes take effect simultaneously in every Member State.

With regard to the entry into force of the changes, it is important that they always take effect at a specific point in time. The beginning of the year (1 January) would be such a logical point, but this may represent a conflict with the ISO20022 reporting, which is always updated at certain points in time other than the beginning of the calendar year.  We suggest initiating a dialog with the SMPG to choose the right solution.

Optional data required by Member States

Initially it must be highlighted that a requirement for optional data should be considered carefully by the member states. Such requirement will reduce harmonisation and increase the complexity and the operational burden of the CFIs.

If the opportunity to add data is applied, it is important for custodians to know what optional data any Member State requires in the reporting.  This should be easily available in one place (preferably in the EU-portal) and we hope that the Commission will pay attention to this.

Further it is important that any changes that individual Member States may make, for example regarding optional data requirements, should be communicated to custodians well in advance and preferably implemented at specific times (such as 1 January).

For more information, please contact:

Fredrik Bonthron, Chief Economist, Swedish Securities Markets Association, fredrik@svpm.se  
Lene Schønebeck, Tax Director, Finance Denmark, LSC@fida.dk
Marja Blomqvist, Head of Tax Regulation, Finance Finland, marja.blomqvist@financefinland.fi 
Katrin Fahlgren, Senior Legal Advisor, Finance Sweden, katrin.fahlgren@financesweden.se