01

CRS February Newsletter

The road continues Introduction

The Common Reporting Standard (“CRS”) regime has come into effect in over 100 participating jurisdictions. Similar to FATCA, the CRS regime differs among the implementing jurisdictions, and changes with constant developments. As part of Deloitte’s efforts to provide transparency with respect to this evolving landscape, a summary of key jurisdictional updates on CRS signatories, regulations, guidance, and other related news is distributed via our monthly CRS Newsletter.

OECD updates

The OECD published updated CRS FAQs. Q22 was revised under Sections II-VII to include that the effective implementation of the CRS pursuant to Section IX requires that jurisdictions take effective measures to ensure the reporting of financial accounts until a valid self-certification has been obtained. Q9 was added under Section VIII (A) to clarify that for purposes of the gross income tests to be applied in the context of the definitions of Investment Entity and Custodial Institution all remuneration for the relevant activities of an Entity is to be taken into account, independent of whether that remuneration is paid directly to the Entity to which the test is applied or to another entity. In addition, Q9 was added under Section VIII(D) to clarify that for the purposes of conducting due diligence procedures with respect to Preexisting Entity Account Holders, specific indicia listed in this FAQ and other relevant considerations should be considered to determine the Reportable Jurisdiction. Lastly, Q2 was added under Section VIII(E) to clarify that when determining whether income is passive it is necessary to consider the nature of the income that the insurance business receives (February 22, 2019). Country updates

Aruba

Aruba’s Tax Department published an updated version of its AEOI Technical Guidance Notes (v2.2) providing technical clarifications on Undocumented Accounts, Controlling Persons, ResCountryCode, and AcctHolderType (February 19, 2019).

In addition, Aruba’s Tax Department sent a communication to the registered reporting financial institutions (RFIs) with information on applicable CRS reporting deadlines (February 25, 2019).

Aruba AEOI guidance (v2.2).pdf

Aruba - Communication.pdf

Global Financial Services Industry

02

Belize

Belize’s Income Tax Department issued an AEOI Notice reminding RFIs of the AEOI local registration requirement. This notice reminds reporting financial institutions (RFIs) that have reporting obligations to notify the Belize competent authority of that fact. This obligation is fulfilled by the RFI’s enrollment on the Belize’s AEOI Portal (February 11, 2019).

British Virgin Islands

British Virgin Islands’ International Tax Authority released an updated version of its CRS Guidance Notes (February 19, 2019).

China

China’s State Administration of Taxation released a Notice with respect to the availability of the AEOI portal. The portal is now open for CRS registration, submission of Nil reports, and testing purposes. The portal will be ready for data upload in late April (February 25, 2019).

Curacao

Curacao’s Ministry of Finance released an updated version of its CRS Reportable jurisdictions list for 2019, and updated its reporting manuals, schemas and calendar of activities for 2019 (February 15, 2019).

Curacao - CRS Reportable Jurisdictio

Cyprus

Cyprus’s Ministry of Finance published an updated CRS Participating jurisdiction list (February 25, 2019).

Czech Republic

Czech Republic’s Ministry of Finance published an AEOI Decree on excluded accounts under local law for CRS purposes. The new decree will come into force on April 1, 2019 (February 14, 2019).

Czech Republic - AEOI Decree.pdf

France

The French Tax Authority released an updated version of its CRS Technical Guidance Notes (v1.8). This version includes a summary of the applicable 2019 deadlines, and the publication of an updated version of the CRS Reportable Jurisdiction list for TY2018 (February 14, 2019).

CRS technical guidance v1.8- Feb 20

Germany

The Federal Tax Office of Germany released a CRS Infobrief (02/2019) providing guidance on correcting CRS data after a submission has taken place (February 4, 2019).

03

In addition, the Federal Tax Office of Germany released a CRS Infobrief (03/2019), announcing that a provisional reportable jurisdiction list for 2019 has been published on the tax authority’s website. The finalized list is expected to be announced by the end of June 2019 (February 20, 2019).

Guernsey

Guernsey’s Revenue Service published Bulletin 2019/1, which provides advance notification to reporting financial institutions that formal Notices will be issued shortly to all RFIs by the Director via the IGOR messaging facility requiring FIs to submit corrections for FATCA/CRS data where record level errors have been identified by the IRS or the CRS Reportable Jurisdictions after data transmission (February 21, 2019).

Hong Kong

Hong Kong’s Inland Revenue Department released a new version of their Encryption Tool for AEOI purposes, and an Application Form for obtaining an e-Cert (Organizational) for AEOI Functions. The authorized person(s), appointed to register an AEOI Account for the FI, must use an e-Cert (Organizational) with AEOI Functions for authentication purposes to be able to open an AEOI Account and access the AEOI Portal (February 28, 2019).

India

India’s Income Tax Department (ITD) released updated versions of its report generation and validation utility User Guides for Form 61 (v3.2), Form 61B (v.3.2) and Form 61A (v.5.2) (February 7, 2019). The ITD also issued updated versions of its Reporting Portal FAQs (v4.3) with the inclusion of FAQs related to the Address Update pop-up providing guidance on how to properly input the RFI’s address on the Reporting Portal (February 11, 2019). In addition, the ITD released an updated (1) XML FAQs (v1.0); (2) Quick Reference Guide (v1.0); and (3) Reporting Portal User Guide (v3.2) adding instructions for downloading XML statements and FAQs in the Annex (February 20, 2019).

Lastly, the ITD issued an updated version of its report generation and validation utility tool for Form 61B (v.2.4). The EmSigner tool (v.1.0) is also available for download (February 21, 2019).

Indonesia

Indonesia’s Tax Authority (Directorate) released an updated XSD file along with examples of XML filing elements for submitting financial information, and a template that FIs can use to file financial information and its submission for the purposes of implementing the provisions of the tax legislation. In addition, the Directorate published Instructions for submitting the XML files (February 28, 2019).

Isle of Man

The Income Tax Division of Isle of Man published a CRS industry advisory notice. The Notice includes (1) the Reportable Jurisdictions list for 2018 (Appendix I); (2) a Provisional list of Reportable Jurisdictions for 2019 (Appendix II); and (3) an updated CRS Participating Jurisdictions list for 2018 (Appendix III) (February 4, 2019). Israel

The Israel’s Tax Authority published a list of Participating Jurisdictions, and two lists of Reportable Jurisdictions, one with regards to TY17 reporting, and another one with regards to TY18 reporting. The document includes a clarification indicating that the CRS reporting deadline is June 23, 2019 for TY 2017, and September 8, 2019 for TY 2018 (February 6, 2019). In addition, the Israel Parliament has approved the final form of its CRS Regulations (February 12, 2019).

04

Italy

The Italian Revenue Agency (Ministry of Economy and Finance) released an official gazette amending Annex B of the Ministerial Decree of December 28, 2015. Specific amendments to the Decree include the addition of participating jurisdictions (Annex D) with respect to Automatic Exchange of Information (AEOI), the inclusion of a list of Italian Financial Institutions not required to submit information with respect to AEOI, and a list of accounts to be treated as excluded accounts (February 6, 2019).

Italy - Official Gazette.pdf

Mauritania

Mauritania joined the Multilateral Convention on Mutual Administrative Assistance in Tax Matters, becoming the 127th signatory to join the list of participating jurisdictions (February 12, 2019).

New Zealand

New Zealand’s Parliament amended its Tax Administration Regulations 2019 to include the CRS Reportable Jurisdiction list for 2019. Thirty additional jurisdictions have been added to the reportable jurisdictions list for reporting periods beginning on or after April 1, 2018. This amended version will come into force 28 days after the date of its notification in the Gazette (February 28, 2019).

Portugal

The Government of Portugal released Decree Law 17/2019 amending its AEOI legislation (February 14, 2019).

Russia

Russia’s Federal Tax Service (FTS) published an update with respect to CRS reporting informing FIs on the type of report they should submit to the FTS along with guidance on how to amend previously sent reports (February 3, 2019).

Lastly, the FTS published a reminder for FIs with respect to AEOI reporting. Starting March 25, 2019, an updated version of the software “Taxpayer LE” will be available, which will allow RFIs to generate a report on foreign customers using the new format of version 5.02. Note that the previous version (format version 5.01) applied until March 1, 2019 (February 28, 2019).

Singapore

The Inland Revenue Authority of Singapore (IRAS) released an updated list of CRS Participating Jurisdictions and CRS Reportable Jurisdictions with respect to TY 2018. The updated list of participating jurisdictions will go into effect on March 1, 2019 (February 28, 2019).

Spain

The Tax Agency of Spain published an updated version of CRS FAQs, which incorporates the OECD’s FAQs on RBI/CBI schemes (February 7, 2019).

Sweden

The Swedish Tax Agency published an updated version of its CRS Technical Guidance Notes (v3) (February 1, 2019).

CRS technical guidance- Feb 2019.p

Additionally, the Swedish Tax Agency released a FATCA/CRS Newsletter (February 8, 2019).

05

Switzerland

Switzerland’s Federal Council (AFC) announced that the consultation on the revision of the Swiss AEOI Laws (Federal Act and Ordinance) is currently open. Comments can be submitted to the AFC until June 12, 2019 (February 27, 2019).

South Africa

South Africa’s Government published its 2019 Budget Review, which includes a proposal to locally implement the OECD’s model mandatory disclosure rules in order to identify and counter offshore structures and arrangements designed in an attempt to circumvent financial account reporting under the OECD’s CRS (February 25, 2019).

Taiwan

Taiwan’s Ministry of Finance published a reminder for Financial Institutions to comply with the Taiwanese CRS regulations starting 2019 and established a CRS website as a reference to RFIs (February 11, 2019).

Lastly, the Ministry of Finance published updated CRS FAQs (February 22, 2019).

Uruguay

Uruguay’s General Tax Directorate (DGI) published an update with regards to the availability of the testing environment for submitting CRS reports. In order to be able to operate in the testing environment and submit reports by April 1, RFIs must be registered in the Registry for the Automatic Exchange of Financial Information (February 5, 2019).

The DGI also announced the release of a new public key for the production environment with respect to AEOI reporting. The new certificate took effect in the system on February 19, 2019 (February 14, 2019).

Vanuatu

Vanuatu’s Ministry of Finance and Economic Management (MFEM) published an AEOI Notice advising all FIs with reportable accounts to notify the Vanuatu Competent Authority of their reporting obligation under AEOI Regulations Order No. 76 of 2017 and the International Tax Cooperation Act No. 7 of 2016 (February 7, 2019).

In addition, Vanuatu’s Department of Finance and Treasury published (1) an XML Schema User Manual (v2.1); (2) a Multi Data Exchange Solution (MDES) User Guide providing further guidance on registration and reporting via the MDES Portal; and (3) a 2019 AEOI Timeline (January 31, 2019).

For more information please click here or contact:

Denise Hintzke Managing Director, Global FATCA/CRS Tax Leader Deloitte Tax LLP +1 212 436 4792

Anne Mericle Senior Manager, Global Information Reporting PMO Deloitte Tax LLP +1 212 436 3908

Susan Schultz Managing Director, FATCA Global Delivery Center (GDC) Operations Leader Deloitte Tax LLP +1 612 397 4604

Susan Segar Managing Director, Global Information Reporting Deloitte Tax LLP +1 703 885 6328

Americas Phillip Brunson Partner, Global Leader – Information Reporting Deloitte Tax LLP +1 212 618 4041

Steve Chapman Partner, Global Information Reporting Deloitte Tax LLP +1 212 436 2339

David Charlton Principal, Global Information Reporting Deloitte Tax LLP +1 617 437 2118

James Dockeray FATCA Leader Deloitte Caribbean and Bermuda Deloitte Ltd. +1 441 299 1399

Patty Florness Partner, Global Information Reporting Deloitte Tax LLP +1 212 436 7413

Andrea Garcia Castelao Principal, Global Information Reporting-CRS Deloitte Tax LLP +1 212 436 3785

Peter Larsen Managing Director, Global Information Reporting Deloitte Tax LLP +1 415 783 4575

Anthony Martirano Managing Director, Global Information Reporting Deloitte Tax LLP +1 973 602 6986

Richard Marcovitz FATCA/CRS Leader Deloitte Canada Deloitte LLP +1 416 775 4760

Robert Schlock Managing Director, Global Information Reporting Deloitte Tax LLP +1 212 436 3541

Michael Shepard Principal Deloitte Transactions and Business Analytics LLP +1 215 299 5260

Kristen Starling Managing Director, Global Information Reporting Deloitte Tax LLP +1 212 436 4281

Sagun Vijayananda Partner, Global Information Reporting Deloitte Tax LLP +1 212 436 7329

Asia-Pacific Troy Andrews FATCA/CRS Partner Deloitte New Zealand Deloitte +64 93030729

Alison Noble FATCA/CRS Leader Deloitte Australia Deloitte Services Pty Ltd +61 3 9671 6716

Tom Toryanik FATCA/CRS Leader Deloitte Singapore Deloitte & Touche LLP +65 6530 8024

Michael Velten FATCA/CRS Leader, Asia-Pacific Deloitte Singapore Deloitte & Touche LLP +65 6531 5039

Europe, Middle East & Africa Brandi Caruso Tax Transparency Leader Deloitte Switzerland Deloitte AG +41 58 279 6397

Eric Centi FATCA/CRS Tax Partner Deloitte Luxembourg Deloitte Tax & Consulting +352 45145 2162

Karim Ousta FATCA Tax Leader, Middle East Deloitte United Arab Emirates Deloitte LLP +971 4 5064700

Owen Gibbs UK FATCA/CRS/DAC Director Deloitte United Kingdom Deloitte LLP +44 20 7007 4819

Alex Law FATCA Leader, Middle East Deloitte United Arab Emirates Deloitte LLP +971 4 506 4700

Jason McGarvey UK FATCA/CRS/DAC Director Deloitte, United Kingdom Deloitte LLP +44 20 7303 0412

Chris Tragheim EMEA Operational Tax Leader Deloitte United Kingdom Deloitte LLP + 44 20 7303 2848

Markus Weber Financial Services Industry Tax Leader Deloitte Switzerland Deloitte AG +41 58 279 7527

This alert contains general information only and Deloitte is not, by means of this alert, rendering accounting, business, financial, investment, legal, tax, or other professional advice or services. This alert is not a substitute for such professional advice or services, nor should it be used as a basis for any decision or action that may affect your business. Before making any decision or taking any action that may affect your business, you should consult a qualified professional advisor. Deloitte shall not be responsible for any loss sustained by any person who relies on this alert.

About Deloitte Deloitte refers to one or more of Deloitte Touche Tohmatsu Limited, a UK private company limited by guarantee (“DTTL”), its network of member firms, and their related entities. DTTL and each of its member firms are legally separate and independent entities. DTTL (also referred to as “Deloitte Global”) does not provide services to clients. In the United States, Deloitte refers to one or more of the US member firms of DTTL, their related entities that operate using the “Deloitte” name in the United States and their respective affiliates. Certain services may not be available to attest clients under the rules and regulations of public accounting. Please see www.deloitte.com/about to learn more about our global network of member firms. Copyright © 2019 Deloitte Development LLC. All rights reserved.

REVENUS 2018

TRANSFERT D’INFORMATIONS EN APPLICATION DES DISPOSITIFS

CRS – DAC 2PAR PROCÉDÉ INFORMATIQUE

CAHIER DES CHARGES

Historique des révisions

Version Date Auteur Description

1.0 01/12/2016 DGFiP bureau GF-1A (enliaison avec les bureaux SI-1C, Cap Numérique bureau particulier et mobilité, CF3, E2)

Cahier des charges pour la collecte des informations auprès des institutions financières en vue de leur transfert en application des dispositifs CRS-DAC 2 par procédé informatique

1.1 8/02/2017 Descriptif du compte-rendu de 2ème niveau (5.1.2.5)Mise à jour de la liste des États et territoires donnant lieu à transmission d'informations (6.1)Code ISO particuliers (6.1)Précisions sur les contrôles de second niveau (5.3.2.1)

1.2 25/04/2017 Structure détaillée du message CRS_OECD (3.2)Précisions sur les déclarations rectificatives

1.3 21/07/2017 Ajout des références des commentaires administratifs (1.4)Précisions sur le niveau d'exigence des données (3.1.5)Ajout de liens vers les sites d'informations sur l'algorithme et le format du NIF/TIN des pays de l'UE etOCDE (3.2.7 et 4.2)Ajout d'exemples de fichiers (6.2)

1.4 11/08/2017 Précision sur l'utilisation des codes OECD pour les balises DocTypeIndic (4.3.2)Correction d'erreurs sur le code OECD du DocTypeIndic dans les exemples de fichiers n°3 (6.2.3) et n°4 (6.2.4)

1.5 22/12/2017 Précisions sur l’utilisation des codes OECD pour les balises DocTypeIndic (4.3.2)Correction d’erreurs de l’exemple 3 (6.2.3)Délai de correction suite au rejet du fichier par une juridiction partenaire et modification du compte rendu de troisième niveau (5.3.3)Ajout des codes ISO des juridictions partenaires (6.1)Taille maximale de 32 000 enregistrements par fichier (3.1.2)

1.6 05/01/2018 Mise à jour de la liste provisoire des États partenaires donnant lieu à échange d’informations (6.1)

1.7 14/06/2018 Mise à jour de la liste provisoire des États partenaires donnant lieu à échange d’informations (6.1)Balise <ResCountryCode> bloc ReportingFI (3.2.4)

1.8 01/02/2019 Correction de l’exemple 4 (6.2.4)-Calendrier de campagne (56)Précisions sur le contrôle 16 (5.3.2.1)

2

Mise à jour de la liste des Etats donnant lieu à transmission d’informations (6.1)

Note : les modifications relatives au nouveau guide d''utilisateur CRS - DAC V1.7 sont indiquées avec un tramage jaune.

3

PRÉCISION

Les déclarants trouveront au BOI-INT-AEA- 20 l'ensemble des définitions et précisions doctrinales nécessairesau bon remplissage des déclarations CRS-DAC2. Sont notamment précisés sur ce document les élémentssuivants :

• le champ des institutions financières déclarantes et non déclarantes ;• le champ des comptes à déclarer ;• les obligations de diligence à la charge des institutions financières ;• Les modalités déclaratives.

4

SOMMAIRE

1 INTRODUCTION......................................................................................................................................6

1.1 Objectif du document.......................................................................................................................6

1.2 Structure du document....................................................................................................................6

1.3 Documents techniques de référence..............................................................................................7

1.4 Documentation juridiquement applicable......................................................................................7

1.5 Terminologie, abréviations et acronymes......................................................................................8

2 PRÉSENTATION GÉNÉRALE DE L'ACCORD CRS / DAC 2.................................................................9

3 PRÉSENTATION PHYSIQUE DES INFORMATIONS.............................................................................10

3.1 Caractéristiques des messages XML.............................................................................................10

3.1.1 Schémas applicables.................................................................................................................10

3.1.2 Le message et les blocs de données CRS...............................................................................10

3.1.3 Le message et les informations techniques d'identification..................................................11

3.1.4 Multiplicité..................................................................................................................................11

3.1.5 Niveau d'exigence des données...............................................................................................12

3.2 Structure détaillée du message CRS_OECD..................................................................................12

3.2.1 CRS_OECD.................................................................................................................................13

3.2.2 CRS_OECD / MessageSpec.......................................................................................................13

3.2.3 CRS_OECD / CrsBody...............................................................................................................15

3.2.4 CRS_OECD / CrsBody / ReportingFI........................................................................................16

3.2.5 CRS_OECD / CrsBody / ReportingGroup / AccountReport....................................................17

3.2.6 Bloc générique ftc:DocSpec_Type...........................................................................................21

3.2.7 Bloc générique crs:Individual...................................................................................................23

3.2.8 Bloc générique cfc:Address_Type...........................................................................................27

3.2.9 Bloc générique sfa:OrganisationParty_Type...........................................................................30

3.3 Exemple de messages XML.............................................................................................................30

4 NOTICES EXPLICATIVES.......................................................................................................................31

4.1 RG1 Règles de gestion de la norme CRS.......................................................................................31

4.2 RG2 Règles de gestion spécifiques à la collecte...........................................................................31

4.3 RG3 Déclaration rectificative...........................................................................................................35

4.3.1 Cadre général.............................................................................................................................35

4.3.2 Tableau : alimentation des balises DocTypeIndic pour les fichiers correctifs.....................37

4.3.3 Précisions...................................................................................................................................38

4.4 RG4 Déclarations ne comportant aucun compte à déclarer.........................................................39

5 VOLET TECHNIQUE...............................................................................................................................40

5.1 Envoi des fichiers.............................................................................................................................40

5.1.1 Description des fonctionnalités................................................................................................40

5.1.2 Modalité d’utilisation du service...............................................................................................40

5.2 Caractéristiques des fichiers..........................................................................................................48

5.2.1 Conventions de nommage du fichier XML...............................................................................48

5.2.2 Format du fichier........................................................................................................................48

5.2.3 Compression..............................................................................................................................48

5.2.4 Taille maximum du fichier.........................................................................................................48

5.2.5 Encodage du fichier XML..........................................................................................................48

5

5.2.6 Structure du fichier XML............................................................................................................48

5.2.7 Structure du fichier XML............................................................................................................48

5.2.8 Éléments non autorisés dans le fichier XML...........................................................................49

5.3 Contrôles.......................................................................................................................................... 49

5.3.1 Contrôles de premier niveau.....................................................................................................50

5.3.2 Contrôles de second niveau (enregistrement par enregistrement).......................................52

5.3.3 Demandes de correction suite à un retour des États et territoires donnant lieu à transmissiond'informations.....................................................................................................................................55

5.4 Fichiers d'essai................................................................................................................................55

5.5 Assistance........................................................................................................................................ 56

6 ANNEXES................................................................................................................................................ 57

6.1 Liste des États et territoires donnant lieu à transmission d’informations..................................57

6.2 Codes ISO particuliers.....................................................................................................................58

6.3 Exemples de fichiers XML...............................................................................................................59

6.3.1 Exemple 1 : fichier contenant une déclaration initiale de deux comptes (OECD1)...............59

6.3.2 Exemple 2 : fichier contenant une déclaration complémentaire de compte (OECD0)..........63

6.3.3 Exemple 3 : fichier contenant des corrections de données sur un compte précédemment dé-claré (OECD2)......................................................................................................................................66

6.3.4 Exemple 4 : fichier contenant des annulations de données sur un compte précédemment dé-claré (OECD3)......................................................................................................................................69

6.3.5 Exemple 5 : Cas particulier - Fichier contenant la modification des coordonnées d'une institu-tion financière.....................................................................................................................................72

6.3.6 Exemple 6 : Cas particulier - Fichier contenant la déclaration d'une entité non financière (ENF)passive multi-résidente dont le contrôle est détenu par plusieurs personnes..............................74

6

1 INTRODUCTION

1.1 Objectif du document

Ce document décrit la procédure de collecte et de déclaration à l'administration fiscale des informationsrelatives aux personnes et aux entités résidentes d’États ou de territoires donnant lieu à transmissiond'informations. Les institutions financières doivent communiquer chaque année ces informations àl'administration fiscale dans le cadre de l’accord multilatéral entre autorités compétentes concernant l'échangeautomatique de renseignements sur les comptes financiers (MCAA) signé par la France le 29 octobre 2014, etde la d irective 2014/107 du 9 décembre 2014 modifiant la directive 2011/16/UE en ce qui concerne l'échangeautomatique et obligatoire d'informations dans le domaine fiscal. Ce dispositif s'applique également auxaccords signés par l'Union européenne avec la Principauté du Liechtenstein et la République de Saint-Marin.

Ces accords et la directive prévoient que les administrations fiscales des États et territoires signataires recevrontdes institutions financières un ensemble d’informations sur les comptes financiers (intérêts, dividendes, autresrevenus et produits de cession provenant d'actifs financiers détenus sur des comptes conservateurs, solde etnuméro de compte, valeur de rachat, etc.) des personnes physiques ou des entités afin de les transmettreautomatiquement aux autorités de leur État ou territoire de résidence.

Le dépôt par les institutions financières du fichier concernant ces informations devra s'inscrire dans lecalendrier de la campagne de déclaration à l'administration fiscale et selon des modalités détaillées au chapitre 5du présent cahier des charges. La date limite de remise des fichiers CRS/ DAC 2 est fixée par décret1 au31 juillet de l'année qui suit celle au titre de laquelle les revenus ont été perçus et/ou les soldes arrêtés.

Ce transfert a été autorisé par la Commission Nationale de l'Informatique et des Libertés (CNIL) le 05 juillet2017.

1.2 Structure du document

Chapitre 1 Introduction : Introduit le sujet et la structure de ce document ;Chapitre 2 Présentation générale : Présente l'économie générale du dispositif ;Chapitre 3 Présentation physique des informations : Présente la structure des données collectées ;Chapitre 4 Notices explicatives : Présente les règles de gestion applicables aux données ;Chapitre 5 Volet technique : Présente les éléments techniques de la collecte des fichiers ;Chapitre 6 Annexes.

1Voir l'article 54 du décret n° 2016-1683 du 5 décembre 2016 fixant les règles et procédures concernant l’échange automatique de ren-seignements relatifs aux comptes financiers, dites « norme commune de déclaration ».

7

1.3 Documents techniques de référence

N° Titre Référence Version Date

1 Cahier des charges de collecte auprès des institutions financières

Cahier Des Charges CRS XML

V1.8 01/02/2019

2 (OCDE 2017) Norme d'échange automatique de renseignements relatifs aux comptes financiers en matière fiscale, Seconde édition

http://www.oecd.org/fr/ctp/norme-d-echange-automatique-de-renseignements-relatifs-aux-comptes-financiers-en-matiere-fiscale-2016-9789264268050-fr.htm

27/03/2017

3 Schéma CRS XMLSchéma ISOCRSTYPESchéma OECDTYPESchéma CommonTypeFatcaCrs

http://www.oecd.org/tax/automatic-exchange/common-reporting-standard/schema-and-user-guide/CRS-schema-v1.0.zip

V1 13/05/201410/12/201311/12/201316/01/2014

1.4 Documentation juridiquement applicable

N° Titre Référence Version Date de signature

Date d'entrée envigueur

4 Accord multilatéral signé par la France

29/10/2014 XX/XX/XXXX

5 Directive 2014/107/UE 09/12/2014 XX/XX/XXXX

6 CNIL 05/07/20172 05/07/2017

7 Code général des impôts, CGI. - art. 1649 AC

01/01/2016

8 Décret n° 2016-1683 du 5 décembre 2016

08/12/2016

9 Arrêté du 9 décembre 2016 (publié au J.O. du 23 décembre 2016 ) précisant le décret n° 2016-1683 du 5 décembre 2016

23/12/2016

10 Commentaires administratifs BOI-INT-AEA-20

20170614 14/06/2017

2Date de signature par Madame la Présidente de la CNIL du récépissé de déclaration concernant la modification du traitement EAIpour les nouveaux transferts de données, notamment dans le cadre de la norme CRS, autorisant le traitement de données à caractèrepersonnel. Cf. également l'arrêté du 25 juillet 2017 modifiant l'arrêté du 5 octobre 2015 portant création par la direction générale desfinances publiques d'un traitement automatisé d'échange automatique des informations dénommé « EAI », publié au Journal officieldu 3 août 2017.

8

1.5 Terminologie, abréviations et acronymes

AbréviationsAcronymes Signification

AAC Accord entre autorités compétentes

AD Accusé de dépôt

AMF Autorité des marchés financiers

CNIL Commission Nationale de l'Informatique et des Libertés

CRA Compte rendu d'anomalie

DGFiP Direction Générale des Finances Publiques

ENF Entité non financière

GIIN Numéro d'enregistrement auprès de l'IRS (Global Intermediary Identification Number)

IF Institution Financière

IF déclarante L'IF qui déclare ses données CRS

IF remettante L'IF qui envoie la déclaration CRS

LEI Legal Entity Identifier

NCD Norme commune de déclaration (ou CRS : Common reporting standard)

NIF Numéro d'Identification Fiscale (ou TIN : Tax identification Number)

OCDE Organisation de Coopération et de Développement Économiques

RG Règle de Gestion

UE Union européenne

XML Extensible Mark-up Language

XSD XML Schema Definition

9

2 PRÉSENTATION GÉNÉRALE DE L'ACCORD CRS / DAC 2

À la suite de l’adoption le 18 mars 2010 de la législation américaine Foreign Account Tax Compliant Act (diteFATCA) (BOI-INT-AEA-10), les ministres des finances du G20 ont mandaté l’OCDE lors du sommet deMexico en novembre 2012 afin d’élaborer sur cette base une norme mondiale en matière de transparencefiscale.

Inspirée du dispositif mis en œuvre dans le cadre de FATCA, la nouvelle norme mondiale relative à l'échangeautomatique de renseignements relatifs aux comptes financiers a été adoptée par l'OCDE le 15 juillet 2014.Endossée par les chefs d’État et de gouvernement du G20 les 15 et 16 novembre 2014 à Brisbane, elle secompose d’un modèle d’accord, de procédures de diligence à la charge des institutions financières (« la normecommune de déclaration »), de commentaires et d’un schéma informatique.

La loi n°2015-1778 du 28 décembre 2015 a autorisé l'approbation de l'accord multilatéral entre autoritéscompétentes concernant l’échange automatique de renseignements relatifs aux comptes financiers (MCAA)signé par la France le 29 octobre 2014. Cet accord multilatéral fixe un cadre pour l'échange automatiqued'informations entre les États parties conformément à la norme mondiale.

En parallèle, au niveau européen, la directive 2014/107/UE du Conseil du 9 décembre 2014 a modifié ladirective 2011/16/UE pour prévoir l'échange automatique et obligatoire d'informations dans le domaine fiscal.Elle requiert des États membres qu'ils s'échangent des renseignements et qu'ils transposent la norme communede déclaration. Au nom de l'Union européenne, la Commission a également signé des accords d'échangeautomatique de renseignements avec des États tiers (Andorre, Liechtenstein, Monaco, Saint-Marin, Suisse)3.

Ces textes décrivent les informations qui doivent être obtenues et échangées par les États et territoires souhaitants'échanger des renseignements ainsi que le calendrier et les modalités pratiques.

3Pour les déclarations à déposer en 2017 et portant sur les informations relatives à l'année 2016, seuls deux accords seront entrés en vi-gueur. Il s'agit des accords conclus entre la France et le Liechtenstein, et l'accord conclu entre la France et Saint-Marin.

10

3 PRÉSENTATION PHYSIQUE DES INFORMATIONS

Pour la bonne compréhension des éléments techniques du présent cahier des charges (chapitres 3 et 5), il est nécessaire que le lecteur ait une bonne connaissance des langages XML et XML Schéma (XSD).

3.1 Caractéristiques des messages XML

Le présent cahier des charges est compatible avec le document « Norme d’échange automatique derenseignement relatifs aux comptes financiers en matière fiscale » publié sous la responsabilité du Secrétairegénéral de l’OCDE :

OCDE (2017), Norme d’échange automatique de renseignement relatifs aux comptes financiers en matièrefiscale, Seconde édition, Éditions OCDE.http://www.oecd.org/fr/ctp/norme-d-echange-automatique-de-renseignements-relatifs-aux-comptes-financiers-en-matiere-fiscale-2016-9789264268050-fr.htm

Ce volet décrit la manière de répondre aux exigences du cahier des charges CRS XML afin de produire unfichier XML conforme au « Guide de l’utilisateur de la norme commune de déclaration » version 1.0 détaillé enannexe 3 du document « Norme d’échange automatique de renseignement relatifs aux comptes financiers enmatière fiscale » et conforme aux règles de gestion et contrôles spécifiques à la collecte CRS DGFiP.

3.1.1 Schémas applicables

Les schémas de la norme « CRS XML Schema » sont disponibles à l'adresse suivante :http://www.oecd.org/tax/automatic-exchange/common-reporting-standard/schema-and-user-guide/CRS-schema-v1.0.zip

La DGFiP utilisera un schéma XSD plus restrictif que la norme CRS implémentant notamment des contrôlesspécifiques pour la collecte et selon le contexte test ou dépôt réel (cf. § 5.2.7.2). Pour autant, les institutionsfinancières doivent systématiquement se référencer à la norme CRS pour le remplissage de leurs déclarations.La DGFiP apporte dans ce cahier des charges les seules précisions complémentaires à la norme.

Les déclarations CRS devront donc impérativement être en conformité avec les schémas rappelés ci-dessus et les contrôles et règles de gestion spécifiques à cette collecte décrits infra.

3.1.2 Le message et les blocs de données CRS

Au niveau le plus haut, la déclaration CRS comporte un bloc nommé CRS_OECD, encore appelé messageCRS_OECD.

Le message CRS_OECD est composé d'un bloc MessageSpec et d'un ou plusieurs blocs CrsBody. Le blocMessageSpec caractérise le message CRS_OECD tandis que le bloc CrsBody identifie l'IF déclarante et lesdonnées déclarées par celle-ci.

Un bloc CRS comporte un bloc ReportingFI et un ou plusieurs blocs ReportingGroup.

11

Un bloc ReportingGroup comporte au moins un bloc AccountReport, sauf dans le cas d'une déclarationcorrigeant ou supprimant uniquement un ReportingFI. Dans ce cas, le bloc AccountReport n'est alors pasobligatoire.

Les informations du message CRS_OECD permettront de constituer un fichier XML dont les caractéristiquestechniques sont abordées dans le chapitre 5 VOLET TECHNIQUE.

La structure du message CRS_OECD offre plusieurs possibilités de déclaration:• Un message CRS_OECD peut regrouper les données CRS de une ou plusieurs IF (IF déclarantes) alors que

la remise du message CRS_OECD est effectuée par une seule IF (IF remettante)• Un message CRS_OECD peut contenir les données CRS d'une seule IF (IF déclarante) qui remet son

message CRS_OECD (IF remettante). Dans ce cas, l'IF remettante est identique à l'IF déclarante,

Une attention particulière est appelée sur la taille maximale du message qui ne peut excéder 32 000 enregistrements(account reports).

3.1.3 Le message et les informations techniques d'identification

Le message CRS_OECD comporte des informations techniques qui visent à identifier, de manière unique etnon ambiguë, les blocs du message CRS_OECD.

Ces informations techniques sont obligatoires.

Elles se trouvent dans :• le bloc MessageSpec (de niveau message)• le bloc générique DocSpec (de niveau bloc d'information).

Les blocs qui peuvent être corrigés (Correctable) comportent le bloc générique DocSpec.

Détails des éléments techniques d'identification :

• MessageSpec• MessageRefId• CorrMessageRefId (non utilisé en collecte CRS, la présence de cette balise entraînera un rejet 1er

niveau)

• DocSpec• DocRefId• CorrMessageRefId (non utilisé en collecte CRS)• CorrDocRefId

Les déclarations CRS / DAC2 devront donc impérativement être en conformité avec les schémas rappelés ci-dessus.

3.1.4 MultiplicitéPour chaque balise XML est précisée la multiplicité de l'information, selon la liste suivante :

12

Multi Commentaire

[0..1] 0 ou 1 information

[0..n] 0 à n information(s)

[1..1] 1 et une seule information

[1..n] 1 à n information(s)

3.1.5 Niveau d'exigence des donnéesPour chaque élément ou attribut de données XML est indiqué le caractère obligatoire, facultatif, ou non requis.Le niveau d'exigence des données de la déclaration CRS / DAC2 est caractérisé comme suit :

Exigence Code utilisé Commentaire

Validation V Obligatoire et contrôlé par les schémas XSD

(Facultatif) Obligatoire

(F) Oblig. Optionnel au regard du schéma XSD, mais si l'information est disponible, elle doit être fournie, conformément à la NCD

Facultatif F Élément facultatif pouvant présenter un choix entre deux types dont un seul doit être utilisé (par exemple, choix entre AddressFix et AddressFreee)

Ne pas renseigner N Élément non obligatoire, ni pour la validation dans le schéma, ni pour la NCD

3.2 Structure détaillée du message CRS_OECD

La structure à respecter pour la collecte est détaillée dans le guide de l'utilisateur de la norme CRS (disponible en anglais ou en français). Elle est détaillée dans les tableaux suivants.

13

3.2.1 CRS_OECD

N°zone

Or Niveau Objet <balise XML> Multi Taille Type Exigence Commentaire

CRS_OECD <crs:CRS_OECD> [1..1] V Élément racine

CRS_OECD version= [0..1] Max 10 char

String V Doit contenir la valeur de la version du schéma NCD qui a étéutilisé pour créer le rapport.Seule valeur possible : 1.0

1 > MessageSpec <crs:MessageSpec> [1..1] crs:MessageSpec_Type V

2 > CrsBody <crs:CrsBody> [1..n] crs:Crs_Type V

3.2.2 CRS_OECD / MessageSpec (crs:MessageSpec_Type)

N°zone Or Niveau Objet <balise XML> Multi Taille Type Exigence Commentaire

1 MessageSpec <crs:MessageSpec> [1..1] crs:MessageSpec_Type V Constitue l'en-tête du message. Il caractérise le message. Ellespécifie la date de la création du message, l’année civile àlaquelle la déclaration se rapporte, et la nature de la déclaration(initiale, corrective, etc.).

1.1 > SendingCompanyIN <crs:SendingCompanyIN>

[0..1] Max 200 char

xsd:string F Numéro d'identifiant de la compagnie remettante (SIRET, SIREN,LEI, AMF ou GIIN) utilisé pour le dépôt. Recommandé mais nonobligatoire

1.2 > TransmittingCountry

<crs:TransmittingCountry>

[1..1] 2 digits iso:CountryCode_Type V Seule valeur possible = FR

1.3 > ReceivingCountry <crs:ReceivingCountry>

[1..1] 2 digits iso:CountryCode_Type V Seule valeur possible = FR

1.4 > MessageType <crs:MessageType> [1..1] crs:MessageType_EnumType

V Seule valeur possible = CRS

1.5 > Warning <crs:Warning> [0..1] free textMax 4000 char

xsd:string N NE PAS UTILISER

1.6 > Contact <crs:Contact> [0..1] free textMax 200 caract

xsd:stringN

NE PAS UTILISER

14

N°zone Or Niveau Objet <balise XML> Multi Taille Type Exigence Commentaire

1.7 > MessageRefID <crs:MessageRefId> [1..1] free textMax 200 char

xsd:string V Concaténation des éléments suivants, séparés par un « _ » :- IF- Millésime (année fiscale)- Numéro de déclarant de l'IF- Numéro unique par fichier déposéExemple : IF_2016_12345678912345_XXXXXX

Dans le cadre de la collecte, cet élément fait l'objet d'un contrôlede validation CV02 (cf. §5.3.1.3) et du contrôle de second niveaun°1 (cf. §5.3.2.1).

1.8 > MessageTypeIndic <crs:MessageTypeIndic>

[1..1] crs:MessageType_EnumType

F Seules valeurs possibles :• CRS701 : le message contient des renseignements

nouveaux• CRS702 : le message contient des corrections à des

renseignements nouveaux

La présence de la valeur CRS703 sera un motif de rejet.

Dans le cadre de la collecte, cet élément fait l'objet d'unerestriction par rapport à la norme CRS et d'un contrôle devalidation CV02 (cf. §5.3.1.3).

1.9 > CorrMessageRefID <crs:CorrMessageRefId>

[0..n] free textMax 200 char

xsd:string N NE PAS UTILISERL'utilisation de cet élément est interdite dans l'élémentMessageSpec (contrôle CV02 pris en compte dans le cadre de lacollecte cf. §5.3.1.3).

1.10 > ReportingPeriod <crs:ReportingPeriod>

[1..1] xsd:date V Cette donnée identifie l’année civile à laquelle se rapporte lemessage en utilisant le format AAAA-MM-JJ. Par exemple, sil’information déclarée concerne les comptes ou les paiementsrelatifs à l’année civile 2016, le champ doit se lire, “2016-12-31”8 chiffres (et 2 traits d’union)

1.11 > Timestamp <crs:Timestamp> [1..1] xsd:dateTime V Cette donnée identifie la date et heure de création du fichierLe format à utiliser est le suivant : AAAA-MM-JJ’T’hh:mm:ss. Lesfractions de seconde ne sont pas mentionnées.Exemple : 2017-06-15T09:45:30

15

3.2.3 CRS_OECD / CrsBody (crs:Body_Type)Ce tableau énumère la séquence des blocs d'information possibles. Chaque bloc est détaillé dans les tableaux suivants .

N°zone Or Niveau Objet <balise XML> Multi Taille Type Exigence Commentaire

2 CrsBody <crs:CrsBody> [1..n] crs:CrsBody_Type V

2.1 > ReportingFI <crs:ReportingFI> [1..1] crs:CorrectableReportOrganisation_Type

V Identifie l'institution financière qui tient le compte financier déclaréou qui effectue le paiement déclaré.cf. BLOC GENERIQUE OrganisationParty_Type

2.2 > ReportingGroup <crs:ReportingGroup> [1..n] V Cet élément de données contient des détails spécifiquesconcernant la déclaration NCD envoyée par l’IF déclarante

2.3 >> Sponsor <crs:Sponsor> [0..1] crs:CorrectableReportOrganisation_Type

N NE PAS UTILISERLorsqu’une institution financière utilise un tiers pour soumettre desinformations en son nom dans la norme NCD, cet élément n’estpas utilisé mais ses informations de contact peuvent être fourniesdans l’élément « Contact ».

2.4 >> Intermediary <crs:Intermediary> [0..1] crs:CorrectableReportOrganisation_Type

N NE PAS UTILISER

2.6 OR} >> AccountReport <crs:AccountReport> [0..n] crs:CorrectableAccountReport_Type

(F)oblig.

AccountReport est un élément obligatoire dans la NCD

2.7 OR} >> PoolReport <crs:PoolReport> [0..n] ftc:CorrectablePoolReport_Type

N NE PAS UTILISER

16

3.2.4 CRS_OECD / CrsBody / ReportingFI (crs:CorrectableReportOrganisation_Type)

N°zone Or Niveau Objet <balise XML> Multi Taille Type Exigence Commentaire

2.1 ReportingFI <crs:ReportingFI> [1..1] crs:CorrectableOrganisationParty_Type

V Identifie l’Institution financière qui tient le Compte financierdéclaré ou qui effectue le paiement déclaré.cf. BLOC GENERIQUE OrganisationParty_Type

2.1.1 > ResCountryCode <crs:ResCountryCode> [0..2] 2 digit iso:CountryCode_Type (F)oblig.

Cet élément de données donne le code pays du pays derésidence fiscale de l’organisation déclarante ou devant fairel’objet d’une déclaration.

Valeurs possibles :• FR : France• BL : Saint-Barthélemy

Cet élément fait l'objet du contrôle de second niveau n°21 (cf.§5.3.2.1). Il est nécessaire d’alimenter cette balise des codes FRou BL,sous peine de rejet du fichier.

2.1.2 > IN <crs:IN> [0..n] Min 1 charMax 200 char

crs:OrganisationIN_Type

(F)oblig.

renseigner l'IN si cette information est disponibleReportingFI : INType=SIRET/SIREN/LEI/AMF/GIIN

Dans le cadre de la collecte, cet élément fait l'objet d'une restriction par rapport à la norme CRS et d'un contrôle de validation CV02 (cf. §5.3.2.1).

2.1.2 > IN issuedBy [0..1] 2-digit iso:CountryCode_Type F Code du pays émetteur du numéro d'identificationL'attribut « issuedBy » de l'élément « IN » est obligatoire dès lorsque ce dernier est présent.

La liste des valeurs possibles est donnée par le schémaISOCRSTYPE visé dans le §1.3 Documents technique deréférence.

Dans le cadre de la collecte, cet élément fait l'objet d'un contrôlede validation CV02 (cf. §5.3.1.3).

2.1.3 > Name <crs:Name> [1..n] Max 200 char

cfc:NameOrganisation_Type

V Raison sociale de l’Entité déclarante

2.1.3 > Name NameType [0..1] stf:OECDNameType_EnumType

F Le type de nom doit correspondre à une valeur autorisée.

La valorisation par OECD201 n'est pas autorisée.

2.1.4 > Address <crs:Address> [1..n] cfc:Address_Type V cf. BLOC GENERIQUE Adresse_Type

2.1.5 > DocSpec <crs:DocSpec> [1..1] stf:DocSpec_Type V cf. BLOC GENERIQUE DocSpec_Type

17

3.2.5 CRS_OECD / CrsBody / ReportingGroup / AccountReport (crs:CorrectableAccountReport_Type)

N° zone Or Niveau Objet <balise XML> Multi Taille Type Exigence Commentaire

2.6 AccountReport <crs:AccountReport> [0..n] crs:CorrectableAccountReport_Type

(F)oblig.

Le bloc est obligatoire sauf s'il s'agit d'une correction de l'élémentReportingFI. En cas de correction de ReportingFI, seule la baliseReportingGroup est obligatoire. Voir exemple 2 de l'annexe §6.3.

Cet élément fait l'objet du contrôle de second niveau n°10 (cf.§5.3.2.1).

2.6.1 > DocSpec <crs:DocSpec> [1..1] stf:DocSpec_Type V Identifie l’élément spécifique du message NCD transmis. Ilpermet d’identifier les éléments nécessitant une correction

cf. BLOC GENERIQUE DocSpec_Type

2.6.2 > AccountNumber <crs:AccountNumber> [1..1] crs:FIAccountNumber_Type

V Le numéro de compte peut être :- le numéro de compte d’un Compte conservateur ou d’unCompte de dépôt ;- le code (ISIN ou autre) d’une obligation ou d’un titre departicipation (s’il n’est pas détenu dans un Compteconservateur) ;- le code d’identification d’un Contrat d’assurance avec valeur derachat ou d’un Contrat de rente.Si exceptionnellement, il n’y a pas de système de numérotation des comptes, utiliser la mention NANUM (en anglais « no account number ») qui signale l’absence de numéro, car il s’agit d’un élément Validation.

Dans le cadre de la collecte, cet élément fait l'objet des contrôlesde second niveau n°2 et 3 (cf. §5.3.2.1).

2.6.2 > AccountNumber AcctNumberType [0..1] cfc:AcctNumberType_EnumType

F Précision sur le type de numéro de compte ou de contrat. Valeurspossibles :

• OECD601 = IBAN L'account number associé à cetélément fait l'objet du contrôle de second niveau n°2(cf. §5.3.2.1)

• OECD602 = OBAN• OECD603 = ISIN L'account number associé à cet

élément fait l'objet du contrôle de second niveau n°3(cf. §5.3.2.1)

• OECD604 = OSIN• OECD605 = Autre

2.6.2 > UndocumentedAccount

UndocumentedAccount [0..1] xsd:boolean (F)oblig.

2.6.2 > ClosedAccount ClosedAccount [0..1] xsd:boolean (F)oblig.

Cet attribut doit être utilisé dans les déclarations NCD pourindiquer qu’il s’agit d’un compte cloturé.

2.6.2 > DormantAccount DormantAccount [0..1] xsd:boolean F Cet attribut peut être utilisé dans les déclarations NCD pourindiquer qu’il s’agit d’un compte dormant.

18

N° zone Or Niveau Objet <balise XML> Multi Taille Type Exigence Commentaire

2.6.3 > AccountHolder <crs:AccountHolder> [1..1] crs:AccountHolder_Type

V Pour la NCD, cet élément de données peut identifier une EntitéTitulaire de compte qui est :• Une ENF passive contrôlée par une ou plusieurs Personne(s) devant faire l’objet d’une déclaration.• Une Personne devant faire l’objet d’une déclaration NCD.

2.6.3.1 {OR >> Individual <crs:Individual> [1..1] crs:PersonParty_Type V cf. BLOC GENERIQUE PersonParty_Type

2.6.3.2 OR} >> Organisation <crs:Organisation> [1..1] crs:OrganisationParty_Type

V cf. BLOC GENERIQUE OrganisationParty_Type

2.6.3.3 OR} >> AcctHolderType <crs:AcctHolderType> [1..1] crs:CrsAcctHolderType_EnumType

V Renseigner ce champ uniquement si le Compte financier faisantl’objet de la déclaration est détenu par une Entité ou si lepaiement faisant l’objet de la déclaration a été effectué au profitd’une Entité décrite ci-dessus. Valeurs possibles :

• CRS101 = Entité non financière passive pour laquelle une ou plusieurs Personne(s) devant faire l’objet d’une déclaration est ou sont des Personne(s) détenant le contrôle.

• CRS102 = Personne devant faire l’objet d’une déclaration dans la NCD

• CRS103 = Entité non financière passive sans controlling person à déclarer

2.6.4 > ControllingPerson

<crs:SubstantialOwner>

[0..n] crs:ControllingPerson_Type

(F)oblig.

Cet élément fait l'objet des contrôles de second niveau n°6 et 7(cf. §5.3.2.1).

2.6.4.1 >> Individual <crs:Individual> [1..1] crs:PersonParty_Type V Définit une Personne détenant le contrôle avec ses nom,adresse, pays de résidence

19

N° zone Or Niveau Objet <balise XML> Multi Taille Type Exigence Commentaire

2.6.4.2 >> CtrlgPersonType <crs:CtrlgPersonType>

[1..n] crsCrsCtrlgPersonType_EnumType

(F)oblig.

Valeurs possibles :

• CRS801 = CP de la personne morale – propriété• CRS802 = CP de la personne morale – autres moyens• CRS803 = CP de la personne morale – dirigeant• CRS804 = CP de la structure juridique – trust –

constituant• CRS805 = CP de la structure juridique – trust –

fiduciaire• CRS806 = CP de la structure juridique – trust –

protecteur• CRS807 = CP de la structure juridique – trust –

bénéficiaire• CRS808 = CP de la structure juridique – trust – autre

CRS809 = CP de la structure juridique – autre – constituant-équivalent

• CRS810 = CP de la structure juridique – autre – fiduciaire-équivalent

• CRS811 = CP de la structure juridique – autre – protecteur-équivalent

• CRS812 = CP de la structure juridique – autre – bénéficiaire-équivalent

• CRS813 = CP de la structure juridique – autre – autre-équivalent

2.6.5 > AccountBalance <crs:AccountBalance> [1..1] cfc:MonAmnt_Type V Communiquer le solde ou la valeur du Compte financier faisantl’objet de la déclaration. Sa valeur doit être supérieure ou égale àzéro (montants négatifs interdits), Cas particulier : lorsque le compte a été clôturé (cf. attribut« closedAccount » de l'AccountNumber), le solde doit être égal àzéro.

Cet élément fait l'objet des contrôles de second niveau n°4 et 5(cf. §5.3.2.1).

2.6.5 > AccountBalance currCode [1..1] 3 digits iso:currCode_Type V DeviseLa liste des valeurs possibles est donnée par le schémaISOCRSTYPE visé dans le §1.3 Documents techniques deréférence.

2.6.6 > Payment <crs:Payment> [0..n] crs:Payment_Type F Communiquer des renseignements sur le paiement effectué auprofit du Compte financier faisant l’objet de la déclaration pendantla période considérée.Les renseignements sur le paiement sont répétables, dans le casoù il y a plus d’un type de paiement à déclarer.

2.6.6.1 >> Type <crs:Type> [1..1] crs:CrsPaymentType_EnumType

V Choisir le code correct pour identifier le type de paiement. La listedes types de paiements spécifiques est :

• CRS501 = Dividendes• CRS502 = Intérêt• CRS503 = Produits Brut/Rachats• CRS504 = Autres revenus

20

N° zone Or Niveau Objet <balise XML> Multi Taille Type Exigence Commentaire

2.6.6.2 >> PaymentAmnt <crs:PaymentAmnt> [1..1] cfc:MonAmnt_Type V Le montant des paiements doit être saisi dans la monnaie enquestion jusqu’à la deuxième décimale. Par exemple mille euross’écrivent 1000.00.

2.6.6.2 >> PaymentAmnt currCode [1..1] 3 digits iso:currCode_Type V DeviseLa liste des valeurs possibles est donnée par le schémaISOCRSTYPE visé dans le §1.3 Documents techniques deréférence.

21

3.2.6 Bloc générique ftc:DocSpec_Type

N° zone Or Niveau Objet <balise XML> Multi Taille Type Exigence Commentaire

3 DocSpec <crs:DocSpec> [1..1] stf:DocSpec_Type V DocSpec identifie l’enregistrement spécifique au sein du messageNCD transmis. Il permet de signaler les enregistrements quinécessitent une correction.

3.1 > DocTypeIndic <stf:DocTypeIndic> [1..1] stf:OECDDocTypeIndic_EnumType

V Cet élément précise le type de données qui sont envoyées. Lesoptions possibles sont les suivantes :

• OECD0 = Resend Data (Renvoi de données) cette valeur particulière fait l'objet du contrôle de second niveau n°16 (cf. §5.3.2.1)

• OECD1 = New Data (Nouvelles données)• OECD2 = Corrected Data (Données corrigées)• OECD3 = Deletion of Data (Suppression de données)• OECD10 = Resend Test Data (Renvoi données de

test )• OECD11 = New Test Data (Nouvelles données de test)• OECD12 = Corrected Test Data (Données de test

corrigées)• OECD13 = Deletion of Test Data (Suppression des

données de test)

À contrario, une déclaration ne pourra pas comporter deDocTypeIndic avec des valeurs différentes.

Les codes OECD0 à 3 sont prévus uniquement pour lesdéclarations de production et ne doivent pas être utilisés pour lestests.

Les codes OECD10 à 13 sont prévus uniquement pour les testset ne doivent pas être utilisés pour les déclarations de production.

Dans le cadre de la collecte, cet élément fait l'objet d'une restriction par rapport à la norme CRS et d'un contrôle de validation CV02 (cf. §5.3.1.3).

3.2 > DocRefId <stf:DocRefId> [1..1] Min 1 charMax 200 char

xsd:string V Un identifiant unique pour ce document (c’est-à-dire unenregistrement et tous les éléments de données qui font partie desa descendance). Une correction (ou une suppression) doit avoirun nouveau DocRefID unique, pour servir de référence par lasuite.

Pour un ReportingFI, par exemple, concaténation des élémentssuivants, séparéspar un « _ » :- IF- Millésime (année fiscale)

22

N° zone Or Niveau Objet <balise XML> Multi Taille Type Exigence Commentaire

- Numéro de déclarant de l'IF- Numéro unique par identifiant IFEx : IF_2016_01234567890123456789_v001

Pour un AccountReport, par exemple, concaténation des éléments suivants,séparés par un « _ » :- IF- Millésime (année fiscale)- Numéro de déclarant de l'IF- Numéro unique pour une année et un identifiant IFEx : IF_2016_01234567890123456789_0000006531

Dans le cadre de la collecte, cet élément fait l'objet d'une restriction par rapport à la norme CRS visée par le contrôle de validation CV02 (cf. §5.3.1.3) et fait l'objet du contrôle de second niveau n°11 (cf. §5.3.2.1).

3.3 > CorrMessageRefId <stf:CorrMessageRefId>

[0..1] Min 1 charMax 200 char

xsd:string N NE PAS UTILISERLa présence de cet élément dans l'élément DocSpec constitue unmotif de rejet (cf. §5.3.1.3).

3.4 > CorrDocRefId <stf:CorrDocRefId> [0..1] Min 21 charMax 200 char

xsd:string F Le type CorrDocRefID permet de référencer le DocRefID del’élément à corriger ou à supprimer. Il doit toujours renvoyer à ladernière référence expédiée de cet Account-report (DocRefID).Ainsi, une série de corrections ou de modifications peut être traitée, puisque chaque correction remplace complètement la version antérieure, sous réserve des précisions apportées au §4.3(cf. page 35).

Dans le cadre de la collecte, cet élément fait l'objet d'une restriction par rapport à la norme CRS et d'un contrôle de validation CV02 (cf. §5.3.1.3). et fait l'objet des contrôles de second niveau n°12 à 15 et n° 18 (cf. §5.3.2.1).

23

3.2.7 Bloc générique crs:Individual

N° zone Or Niveau Objet <balise XML> Multi Taille Type Exigence Commentaire

4 Individual crs:PersonParty_Type BLOC GENERIQUE PersonParty_Type

Ces données sont à compléter des éléments relatifs auxpersonnes physiques :

• titulaire du compte ;

• ou personne détenant le contrôle d'une entité nonfinancière passive titulaire du compte.

4.1 > ResCountryCode <crs:ResCountryCode> [0..n] 2-digit iso:CountryCode_Type V Le ou les code(s) du ou des pays de résidence fiscale de lapersonne physique.

Ce(s) code(s) doi(ven)t doit uniquement se rapporter un ouplusieurs des États et territoires donnant lieu à transmissiond'information (cf. annexe §6.1 avec), la particularité suivante :Le champ doit être initié par défaut à « FR » pour les comptes non documentés (cf : définition de la norme CRS pour les comptes non documentés).

Dans le guide de l'OCDE :[Pour les déclarations nationales, si la personne physique est certifiée comme résidente fiscale ou traitée comme tel dans plus d’une juridiction, cet élément peut être répété et les données doivent être envoyées à l’autorité fiscale. Il serait aussi recommandable de rendre obligatoire l’utilisation du code du payspour les comptes non documentés, qui ne feront pas l’objet d’échange entre Autorités compétentes]

La liste des valeurs possibles est donnée par le schémaISOCRSTYPE visé dans le §1.3 Documents techniques deréférence.

Cet élément fait l'objet du contrôle de second niveau n°8 (cf.§5.3.2.1).

24

N° zone Or Niveau Objet <balise XML> Multi Taille Type Exigence Commentaire

4.2 > TIN <crs:TIN> [0..n] Min 1 charMax 200 char

cfc:TIN_Type (F)oblig.

Cet élément de données correspond au Numéro d’identificationfiscale (NIF) utilisé par l’administration fiscale réceptrice pouridentifier le Titulaire du compte. Renseigner le TIN fourni par le titulaire du compte s'il existe.L'algorithme et le format du TIN, s'ils sont connus, seront pris encompte par la DGFIP pour vérifier son exactitude dans le cadred’un contrôle non bloquant. Dans le cadre de la collecte, cetélément fait l'objet d'une restriction par rapport à la norme CRS.Des informations sur l'algorithme et le format du TIN des pays del'UE et OCDE sont disponibles sur les sites suivants :

• https://ec.europa.eu/taxation_customs/tin/

• http://www.oecd.org/tax/automatic-exchange/crs-implementation-and-assistance/tax-identification-numbers/

Dans le cadre de la collecte, cet élément fait l'objet d'une restriction par rapport à la norme CRS et d'un contrôle de validation CV02 (cf. §5.3.1.3). Il fait également l'objet du contrôle non bloquant de second niveau n°19 (cf. §5.3.2.1).

4.2 > TIN issuedBy [0..1] 2-digit iso:CountryCode_Type (F)oblig.

Code du pays émetteur du TIN. Obligatoire si le TIN estrenseigné.À défaut d'information sur le pays d'émission du TIN, le pays signalé en tant que ResCountryCode doit être renseigné dans cette balise.

Dans le cadre de la collecte, cet élément fait l'objet d'une restriction par rapport à la norme CRS (cf. §5.3.1.3) et d'un contrôle de validation CV02 (cf. §5.3.1.3). Il fait également l'objet d'un contrôle de second niveau (cf. §5.3.2.1).

4.3 > Name <crs:Name> [1..n] Max 200 char

crs:NamePerson_Type V

25

N° zone Or Niveau Objet <balise XML> Multi Taille Type Exigence Commentaire

4.3 > NamePerson_type nameType [0..1] stf:OECDNameType_EnumType

F Il est possible dans la NCD qu’une personne physique ou une Entité ait plusieurs noms. Un qualificatif indique le type de nom dont il s’agit, par exemple un surnom (« nick »), un nom commercial (« dba ») un nom plus court pour désigner l’Entité ou un nom utilisé publiquement à la place de la raison sociale, etc.Les valeurs possibles sont les suivantes :

• OECD201 = NE PAS UTILISER• OECD202 = indiv• OECD203 = alias• OECD204 = nick (nickname)• OECD205 = aka (also known as)• OECD206 = dba (doing business as)• OECD207 = legal• OECD208 = atbirth

Dans le cadre de la collecte, cet élément fait l'objet d'une restriction par rapport à la norme CRS et d'un contrôle de validation CV02 (cf. §5.3.1.3).

4.3.1 >> PrecedingTitle <crs:PrecedingTitle> [0..1] Max 200 char

xsd:string F

4.3.2 >> Title <crs:Title> [0..n] Max 200 char

xsd:string F

4.3.3 >> FirstName <crs:FirstName> [1..1] Max 200 char

xsd:string V Prénom

4.3.3 >> FirstName xnlNameType [0..1] Max 200 char

xsd:string F

4.3.4 >> MiddleName <crs:MiddleName> [0..n] Max 200 char

xsd:string F

4.3.4 >> MiddleName xnlNameType [0..1] Max 200 char

xsd:string F

4.3.5 >> NamePrefix <crs:NamePrefix> [0..1] Max 200 char

xsd:string F

4.3.5 >> NamePrefix xnlNameType [0..1] Max 200 char

xsd:string F

4.3.6 >> LastName xnlNameType [0..1] Max 200 char

xsd:string V Nom de famille

4.3.7 >> GenerationIdentifier

<crs:GenerationIdentifier>

[0..n] Max 200 char

xsd:string F

4.3.8 >> Suffix <crs:Suffix> [0..n] Max 200 char

xsd:string F

4.3.9 >> GeneralSuffix <crs:GeneralSuffix> [0..1] Max 200 char

xsd:string F

26

N° zone Or Niveau Objet <balise XML> Multi Taille Type Exigence Commentaire

4.4 > Address <crs:Address> [1..n] cfc:Address_Type V cf. BLOC GENERIQUE Address_Type

4.5 > Nationality <crs:Nationality> [0..n] iso:CountryCode_Type F Nationalité.

La liste des valeurs possibles est donnée par le schémaISOCRSTYPE visé dans le §1.3 Documents techniques deréférence.

4.6 > BirthInfo <crs:BirthInfo> [0..1] Contient la date de naissance du titulaire du compte.

4.6.1 >> BirthDate <crs:BirthDate> [0..1] xsd:date (F)oblig.

Le format de cette donnée est AAAA-MM-JJ.

Cet élément fait l'objet du contrôle de second niveau n°9 (cf.§5.3.2.1).

4.6.2 >> City <crs:City> [0..1] Max 200 char

xsd:string F

4.6.3 >> CitySubentity <crs:CitySubentity> [0..1] Max 200 char

xsd:string F

4.6.4 >> CountryInfo <crs:CountryInfo> [0..1] Max 200 char

F

4.6.4.1 {OR >>> CountryCode <crs:CountryCode> [1..1] 2-digit iso:CountryCode_Type F La liste des valeurs possibles est donnée par le schémaISOCRSTYPE visé dans le §1.3 Documents techniques deréférence.

4.6.4.2 OR} >>> FormerCountryName

<crs:FormerCountryName>

[1..1] Max 200 char

xsd:string F

27

3.2.8 Bloc générique cfc:Address_Type

N° zone Or Niveau Objet <balise XML> Multi Taille Type Exigence Commentaire

5 Address_Type BLOC GENERIQUE Address_Type

Deux types d'adresse dans le schéma :• adresse structurée (AddressFix)• adresse libre (AddressFree)

L'adresse au format structuré doit être utilisée sauf si l'institutionfinancière déclarante ne peut renseigner les différentes parties del'adresse dans les zones correspondantes.

Adresse du dernier domicile connu de la personne titulaire ducompte. Si cette adresse n'est pas disponible, l'IF devra déclarerl'adresse postale utilisée pour contacter le titulaire du compte.

5 Address_Type legalAddressType [0..1] stf:OECDLegalAddressType_EnumType

F Cet élément de données est un attribut de l’adresse. Il indique lestatut légal de l’adresse (résidentielle ou professionnelle, résidentielle, professionnelle, siège, non précisé). Les valeurs possibles sont les suivantes :

• OECD301 = residential or business• OECD302 = residential• OECD303 = business• OECD304 = registered office• OECD305 = unspecified

5.1 > CountryCode <cfc:CountryCode> [1..1] 2-digits iso:CountryCode_Type V Code de pays associé à l'adresse du titulaire du compte.Particularité : Le champ doit être initié par défaut à « FR » pourles comptes non documentés dans le guide de l'OCDE :[Pour les comptes non documentés, le code national du pays peutêtre utilisé puisque aucune adresse n’est disponible. Comme le champ adresse nécessite un autre élément pour être validé, la mention « Undocumented » peut être utilisée en lieu et place d’une adresse.]

La liste des valeurs possibles est donnée par le schémaISOCRSTYPE visé dans le §1.3 Documents techniques deréférence.

28

N° zone Or Niveau Objet <balise XML> Multi Taille Type Exigence Commentaire

5.2 {OR > AddressFree <cfc:AddressFree> [1..1] Mex 4000 char

xsd:string F Saisie d'informations d'adresse en texte libre : toutes lescoordonnées disponibles seront présentées comme une chaîned'octets (blanc ou "/" (barre oblique) ou le retour à la ligne utilisépour délimiter les parties de l'adresse).

Cette option (AdressFree) ne doit être utilisée que si les donnéesne peuvent être présentées dans le format AddressFix.

Attention à la particularité suivante : Renseigner à« Undocumented » pour les comptes non documentés.

Si l'adresse au format structuré est utilisée, il est possible de saisirl'adresse de la rue complète du titulaire du compte dans l'élémentAddressFree plutôt que d'utiliser les éléments fixes associés.Dans ce cas, la ville, la sous-entité, et le code postal doivent êtreremplis dans les éléments appropriés de l'adresse structurée.

Dans le cadre de la collecte, cet élément fait l'objet d'une restriction par rapport à la norme CRS et d'un contrôle de validation CV02 (cf. §5.3.1.3).

5.3 OR} > AddressFix <cfc:AddressFix> [1..1] cfc:AddressFix_Type F Dans le cadre de la collecte, cet élément fait l'objet d'une restriction par rapport à la norme CRS et d'un contrôle de validation CV02 sur la valeur <City> (cf. §5.3.1.3).

5.3.1 >> Street <cfc:Street> [0..1] Max 200 char

xsd:string F rue

5.3.2 >> BuildingIdentifier

<cfc:BuildingIdentifier>

[0..1] Max 200 char

xsd:string F Numéro de rue (à défaut bâtiment)

5.3.3 >> SuiteIdentifier <cfc:SuiteIdentifier>

[0..1] Max 200 char

xsd:string F Complément d'adresseExemple : n° d'appartement, résidence, etc.

5.3.4 >> FloorIdentifier <cfc:FloorIdentifier>

[0..1] Max 200 char

xsd:string F N° d'étage

5.3.5 >> DistrictName <cfc:DistrictName> [0..1] Max 200 char

xsd:string F Département

5.3.6 >> POB <cfc:POB> [0..1] Max 200 char

xsd:string F Boîte postale

5.3.7 >> PostCode <cfc:PostCode> [0..1] Max 200 char

xsd:string F Code postal. L'élément doit toujours être précisé s’il existe

5.3.8 >> City <cfc:City> [1..1] Max 200 char

xsd:string V Commune

Dans le cadre de la collecte, cet élément fait l'objet d'une restriction par rapport à la norme CRS et d'un contrôle de validation CV02 (cf. §5.3.1.3).

5.3.9 >> CountrySubentity <cfc:CountrySubentity>

[0..1] Max 200 char

xsd:string F Région ou État fédéré

29

N° zone Or Niveau Objet <balise XML> Multi Taille Type Exigence Commentaire

5.3 OR} > AddressFree <cfc:AddressFree> [0..1] Max 4000 char

xsd:string F

30

3.2.9 Bloc générique sfa:OrganisationParty_TypeN° zone Or Niveau Objet <balise XML> Multi Taille Type Exigence Commentaire

6 crs:OrganisationParty_Type

crs:OrganisationParty_Type

Ces données sont à compléter des éléments relatifs aux entités (IF déclarante, mandataire ou titulaire du compte).

6.1 > ResCountryCode <crs:ResCountryCode> [0..n] 2 digit iso:CountryCode_Type (F)oblig.

Cette donnée décrit le code du pays de résidence fiscale de l'entité déclarante ou de l'entité titulaire du compte faisant l'objet de la déclaration. (selon les champs concernés).

La liste des valeurs possibles est donnée par le schéma ISOFATCATYPE visé dans le §1.3 Documents techniques de référence.

Cet élément fait l'objet des contrôles de second niveau n°8 et 20(cf. §5.3.2.1).

6.2 > IN <crs:IN> [0..n] Min 1 charMax 200 char

crs:OrganisationIN_Type

(F)oblig.

Numéro d'identification.

Dans la NCD cela peut être le GIIN ou un NIF, le numérod’immatriculation de la société, le numéro d’identification mondiald’entités (EIN) ou un autre numéro d’identification similaire.

6.2 > IN issuedBy [0..1] 2-digit iso:CountryCode_Type F Code du pays émetteur du numéro d'identification.

La liste des valeurs possibles est donnée par le schéma ISOCRSTYPE visé dans le §1.3 Documents techniques de référence.

6.2 > IN INType [0..1] Max 200 char

xsd:string F

6.3 > Name <crs:Name> [1..n] Max 200 char

cfc:NameOrganisation_Type

V Dans le cadre de la collecte, cet élément fait l'objet d'une restriction par rapport à la norme CRS et d'un contrôle de validation CV02 (cf. §5.3.1.3).

6.3 > Name nameType [0..1] stf:OECDNameType_EnumType

F Dans le cadre de la collecte, cet élément fait l'objet d'une restriction par rapport à la norme CRS (cf. §5.3.1.3).

6.4 > crs:Address <crs:Address> [1..n] cfc:Address_Type V cf. BLOC GENERIQUE Address_Type

3.3 Exemple de messages XML

Deux exemples de fichiers XML sont fournis en annexe §6.2.

31

4 NOTICES EXPLICATIVES

4.1 RG1 Règles de gestion de la norme CRS

Les règles de gestion, hors spécificités de la collecte, sont décrites dans le guide utilisateur de la norme CRS.

4.2 RG2 Règles de gestion spécifiques à la collecte

Rappel des principes retenus pour la collecte :- une entité déclarante doit déposer une déclaration globale, en un ou plusieurs fichiers ;- une IF remettante peut déclarer pour plusieurs IF déclarantes ;- un fichier recense pour chaque entité déclarante un ou plusieurs comptes ;- un même fichier peut rassembler des déclarations de comptes / contrats de résidents de pays différents ;- Il est possible de déclarer les différents comptes / contrats d’un même titulaire dans plusieurs fichiers.

Il conviendra d'appliquer une vigilance particulière s'agissant des détenteurs de comptes « multi-résident ».Dans ce cas, le compte devra être déclaré dans un seul et même fichier (pas de ventilation par pays) et donc apparaître sous un seul et unique DocRefId. Cette occurrence devra néanmoins mentionner l'ensemble des États et territoires de résidence fiscale d'États et de territoires donnant lieu à transmission d’informations du « multi-résident », et l'ensemble des TIN correspondants.

Pour chaque compte :- Les informations concernant le bénéficiaire seront renseignées avec sa ou ses résidences fiscales

Rappel : les règles suivantes ne sont que des précisions complémentaires vis-à-vis de la norme CRS

En-tête du message (MessageSpec) :

Elément / Attribut Règle de valorisation

SendingCompanyIN(Annexe 3. I)*

Numéro d'identifiant de la compagnie remettante (SIRET, SIREN, LEI, AMF ou GIIN) utilisé pour le dépôt – recommandé mais pas obligatoire

TransmittingCountry(Annexe 3. I)*

Initialiser toujours à "FR"

ReceivingCountry(Annexe 3. I)*

Initialiser toujours à "FR"

Warning(Annexe 3. I)*

Ne pas utiliser

Contact(Annexe 3. I)*

Ne pas utiliser

MessageRefID(Annexe 3. I)*

Concaténation des éléments suivants, séparés par un « _ » :- IF- Millésime (année fiscale)- Numéro de déclarant de l'IF- Numéro unique par fichier déposéExemple : IF_2016_12345678912345_XXXXXXDans le cadre de la collecte, cet élément fait l'objet d'une restriction par rapport à la norme CRS (cf. §5.3.1.3)

* référence aux annexes du guide utilisateur Norme d’échange automatique de renseignement relatifs aux comptes financiers en matière fiscale, Seconde édition, Éditions OCDE.

32

En-tête du message (MessageSpec) - Suite :

Élément / Attribut Règle de valorisation

MessageTypeIndic(Annexe 3. I)*

Les valeurs possibles sont CRS701 (le message contient des renseignements nouveaux) et CRS 702 (le message contient des corrections à des renseignements envoyés antérieurement).Dans le cadre de la collecte, cet élément fait l'objet d'une restriction par rapport à la norme CRS (cf. §5.3.1.3)

CorrMessageRefID(Annexe 3. I)*

L'utilisation de cet élément est interdite dans l'élément MessageSpec (contrôle pris en compte dans le cadre de la collecte cf. §5.3.1.3)

Timestamp(Annexe 3. I)*

Date et heure auxquelles le message a été généré

* référence aux annexes du guide utilisateurNorme d’échange automatique de renseignement relatifs aux comptes financiers en matière fiscale, Seconde édition, Éditions OCDE.

Corps du message (CrsBody) :

Élément / Attribut Règle de valorisation

"ResCountryCode" des éléments de type "OrganisationParty_Type" (Annexe 3. IIa)*

Conforme au guide et à l'annexe §6.2.Précision : cette balise doit nécessairement être valorisée, sauf en cas de AcctHolderType = CRS101Cette balise doit être valorisée par le ResCountryCode de l'entité, quelle que soit la localisation, et ne doit en aucun cas être automatiquement valorisée par FR ou tout autre code ISO. Un code pays qui serait non partenaire peut être utilisé lorsque le code pays de la Controlling Person fait partie de la liste des pays partenaires et que AcctHolderType = CRS 101

"ResCountryCode" des éléments de type "PersonParty_Type" (Annexe 3. IIa)*

Conforme au guide et à l'annexe §6.1 avec la particularité suivante :Le champ doit être initié par défaut à "FR" pour les comptes non documentés (cf :définition de la norme CRS pour les comptes non documentés)

Dans le guide de l'OCDE :[Pour les déclarations nationales, si la personne physique est certifiée comme résidente fiscale ou traitée comme tel dans plus d’une juridiction, cet élément peut être répété et les données doivent être envoyées à l’autorité fiscale. Il seraitaussi recommandable de rendre obligatoire l’utilisation du code du pays pour lescomptes non documentés, qui ne feront pas l’objet d’échange entre Autorités compétentes]

"CountryCode" des élements de type "Address_Type"(Annexe 3. IId)*

Conforme au guide et à l'annexe §6.1 avec la particularité suivante :Le champ doit être initié par défaut à « FR » pour les comptes non documentés

Dans le guide de l'OCDE :[Pour les comptes non documentés, le code national du pays peut être utilisé puisque aucune adresse n’est disponible. Comme le champ adresse nécessite un autre élément pour être validé, la mention « Undocumented » peut être utiliséeen lieu et place d’une adresse.]

* référence aux annexes du guide utilisateur Norme d’échange automatique de renseignement relatifs aux comptes financiers en matière fiscale, Seconde édition, Éditions OCDE.

33

Corps du message (CrsBody) - Suite :

Élément / Attribut Règle de valorisation

"AdressFree" des élements de type "Address_Type"(Annexe 3. IId)*

Attention à la particularité suivante :Renseigner à « Undocumented » pour les comptes non documentés

Dans le cadre de la collecte, cet élément fait l'objet d'une restriction par rapport à la norme CRS (cf. §5.3.1.3)

Pour s'assurer de la rédaction correcte des adresses, il est possible de se référer ausite internet de l'Union postale universelle (UPU), et plus particulièrement à la rubrique activité, système d'adressage dans les pays membresEn français : (http://www.upu.int/fr/activities/addressing/postal-addressing-systems-in-member-countries.html)En anglais : (http://www.upu.int/en/activities/addressing/postal-addressing-systems-in-member-countries.html).

"AddressFix.City" des élements de type "Address_Type"(Annexe 3. IId)*

Dans le cadre de la collecte, cet élément fait l'objet d'une restriction par rapport à la norme CRS (cf. §5.3.1.3)

Pour s'assurer de la rédaction correcte des adresses, il est possible de se référer ausite internet de l'Union postale universelle (UPU), et plus particulièrement à la rubrique activité, système d'adressage dans les pays membres.En français : (http://www.upu.int/fr/activities/addressing/postal-addressing-systems-in-member-countries.html)En anglais : (http://www.upu.int/en/activities/addressing/postal-addressing-systems-in-member-countries.html).

"IN" avec attributs "issuedBy" et "INType" des élements de type "OrganisationParty_Type" ("ReportingFI"ou "AccountHolder.Organisation")(Annexe 3. IIIb.)*

Obligatoire (facultatif) : renseigner l'IN si cette information est disponibleReportingFI :INType=SIRET/SIREN/LEI/AMF/GIINissuedBy=FR/US/...

Dans le cadre de la collecte, cet élément fait l'objet d'une restriction par rapport à la norme CRS (cf. §5.3.1.3)

AccountReport (Annexe 3. IVc)*

Le bloc est obligatoire sauf s'il s'agit d'une correction de l'élément ReportingFI.En cas de correction de ReportingFI, seule la balise ReportingGroup est obligatoire. Voir exemple 2 de l'annexe §Erreur : source de la référence non trouvée.

DocTypeIndic(Annexe 3. recommandations techniques. 3.)*

OECD0 = Renvoi de donnée (utilisé uniquement pour les blocs d'information (records) <Reporting FI>)OECD1 = Donnée nouvelleOECD2 = Donnée corrigéeOECD3 = Donnée effacéeDans le cadre de la collecte, une règle de contrôle est mise en place (cf. §5.3.1.3)

* référence aux annexes du guide utilisateur Norme d’échange automatique de renseignement relatifs aux comptes financiers en matière fiscale, Seconde édition, Éditions OCDE.

34

Corps du message (CrsBody) - Suite :

Élément / Attribut Règle de valorisation

DocRefID(Annexe 3. recommandations techniques. 4.)*

Pour un ReportingFI, par exemple, concaténation des éléments suivants, séparés par un « _ » :

- IF- Millésime (année fiscale)- Numéro de déclarant de l'IF- Numéro unique par identifiant IFEx : IF_2016_01234567890123456789_v001

Pour un AccountReport, par exemple, concaténation des éléments suivants, séparés par un « _ » :

- IF- Millésime (année fiscale)- Numéro de déclarant de l'IF- Numéro unique pour une année et un identifiant IFEx : IF_2016_01234567890123456789_0000006531

Dans le cadre de la collecte, cet élément fait l'objet d'une restriction par rapport à la norme CRS (cf. §5.3.1.3)

CorrDocRefID(Annexe 3. recommandations techniques. 4.)*

Référence de l'enregistrement précédemment envoyé.Dans le cadre de la collecte, cet élément fait l'objet d'une restriction par rapport à la norme CRS (cf. §5.3.1.3)

CorrMessageRefId(Recommandations techniques §4, p273)*

L'utilisation de cet élément est interdite dans l'élément DocSpec (contrôle pris en compte dans le cadre de la collecte cf. §5.3.1.3).

TIN(Annexe3. IIb)*

Obligatoire (facultatif)Renseigner le TIN fourni par le titulaire du compte s'il existe. L'algorithme et le format du TIN, s'ils sont connus, seront pris en compte par la DGFIP pour vérifier son exactitude dans le cadre d’un contrôle non bloquant. Dans le cadre de la collecte, cet élément fait l'objet d'une restriction par rapport à la norme CRS (cf. §5.3.1.3)Des informations sur l'algorithme et le format du TIN des pays de l'UE et OCDE sont disponibles sur les sites suivants : - https://ec.europa.eu/taxation_customs/tin/- http://www.oecd.org/tax/automatic-exchange/crs-implementation-and-assistance/tax-identification-numbers/

Attribut « issuedBy » de l'élément « TIN »(Annexe3. IIb)*

Obligatoire si le TIN est renseigné. À défaut d'information sur le pays d'émission du TIN, le pays signalé en tant que resCountryCode doit être renseigné dans cette balise.Dans le cadre de la collecte, cet élément fait l'objet d'une restriction par rapport à la norme CRS (cf. §5.3.1.3)

* référence aux annexes du guide utilisateur Norme d’échange automatique de renseignement relatifs aux comptes financiers en matière fiscale, Seconde édition, Éditions OCDE.

35

Corps du message (CrsBody) - Suite :

Élément / Attribut Règle de valorisation

Type de nom (attribut nameType des éléments « NameOrganisation_Type » et « NamePerson_Type »)(Annexe 3.IIc)*

Dans le cadre de la collecte, cet élément fait l'objet d'une restriction par rapport à la norme CRS (cf. §5.3.1.3)

« LastName » des éléments« NamePerson_Type »(Annexe 3.IIc)*

Dans le cadre de la collecte, cet élément fait l'objet d'une restriction par rapport à la norme CRS (cf. §5.3.1.3)

« Name » des éléments « OrganisationParty_Type »(Annexe 3.IIIc)*

Dans le cadre de la collecte, cet élément fait l'objet d'une restriction par rapport à la norme CRS (cf. §5.3.1.3)

* référence aux annexes du guide utilisateur Norme d’échange automatique de renseignement relatifs aux comptes financiers en matière fiscale, Seconde édition, Éditions OCDE.

4.3 RG3 Déclaration rectificative

4.3.1 Cadre général

Un fichier modificatif peut être envoyé :• suite à une correction spontanée du fichier initial• pour corriger des enregistrements rejetés du fichier initial A

Un message correctif a la même structure qu'un message initial.

D'une manière générale, la correction doit se rapporter au dernier enregistrement valide de la chaîne corrective,sauf s'il n'y en a pas. Dans ce cas, la correction se rapporte à l'enregistrement initial.

En collecte, l'élément MessageTypeIndic est ignoré (pas de distinction message initial ou correctif).

On utilise les valeurs suivantes de DocTypIndic pour les éléments AccountReport et Reporting FI :OECD0 = Renvoi de donnée (utilisé uniquement pour les blocs d'information <Reporting FI>)OECD1 = Donnée nouvelleOECD2 = Donnée corrigéeOECD3 = Donnée effacée

Pour les tests :OECD10 = Renvoi de donnée de test (utilisé uniquement pour les blocs d'information <Reporting FI>)OECD11 = Donnée nouvelle de testOECD12 = Donnée corrigée de testOECD13 = Donnée effacée de test

Pour chaque élément « ReportingFI » et « AccountReport » :

36

- Le DocRefID doit être unique dans l'espace et le temps- En cas de correction ou effacement, la balise CorrDocRefID doit référencer le DocRefID valide précé-demment envoyé qui doit être corrigé ou annulé.- Une correction suite à une correction est possible (dans un fichier suivant). Le correctif doit toujours renvoyer à la dernière référence expédiée de cet Account-report et/ou reportingFI (DocRefID). Ainsi, une série de correc-tions ou de modifications peut être traitée, puisque chaque correction remplace complètement la version anté-rieure. Pour le cas d'un ReportingFI ou d'un AccountReport rejeté, on se référera au paragraphe Précisions ci-après (cf. 4.3.3).- Une réutilisation d'un DocRefID suite à un effacement n'est pas possible.

Les consignes d'alimentation des balises DocTypeIndic et les modalités de reprise des DocRefID sont précisées dans le tableau figurant en page suivante (cf. 4.3.2).

Ordre de dépôt des fichiers :Il est conseillé d'attendre le compte-rendu de validation du 1er fichier avant de déposer un fichier correctif (dé-lai maximum de 72h pour obtenir un compte-rendu de validation).

Annulation de fichier :Il n'existe pas de possibilité d'annuler un fichier complet par la procédure de renseignement du « MessageSpec.-CorrMessageRefID ». Une corrective qui annule chacune des données sera renvoyée.

37

4.3.2 Tableau : alimentation des balises DocTypeIndic pour les fichiers correctifs

38

Description Ex CDC MessageSpecCrsBody

ReportingFi AccountReport

DocRefId CorrDocRefId DocRefId CorrDocRefId

Déclaration initiale n°1 CRS701 OECD1 DocRefId unique à servir OECD1 à servir

N°2 CRS701 OECD0 OECD1 à servir

CRS701 OECD1 OECD1 à servir

CRS701 OECD2 OECD1

CRS701 OECD0 OECD2

Correction et annulation du bloc AccountReport précedem m ent acceptés

n °3 CRS 702 OECD0 OECD2

n °4 CRS702 OECD0 OECD3

CRS702 OECD2 OECD2

CRS702 OECD3 OECD3

Exemple de correction du seul bloc ReportingFi précédemment accepté

n°5 CRS702 OECD2 Bloc AccountReport non présent

MessageTypeIndic

Message refID

DocTypIndic

Balises du bloc ReportingFi

DocTypIndic

Balises du bloc AccountReport

Message refID unique

DocRefId unique

Déclaration complémentaire à une déclaration acceptée ( comptes ou bénéficiaire omis)

Message refID unique

reconduire le DocRefId du précédent ReportingFi

Reconduire les balises du précédent ReportingFi

DocRefId unique

Correction en cas de rejet d'un fichier : statut EAI : échange rejeté

rejet au niveau fichier  : aucune information n'est enregistrée. Envoi d'un nouveau f ichier initial corrigé des erreurs ayant provoqué le rejet

Message refID unique (celui du

fichier rejeté est réutilisable)

DocRefId unique (celui du fichier

rejeté est réutilisable)

Reconduire les balises du précédent ReportingFi

qu'elles soient corrigées ou reconduites à

l'identique

DocRefId unique (celui

du f ichier rejeté est

réutilisable)

Correction en cas d'enregistrements rejetés. Statut EAI : enregistrements rejetés

erreur sur le ReportingFI toute la déclaration ( ReportingFI+ AccountReport) doit être renvoyée

Message refID unique

nouvel DocRefId unique

DocRefId que l'on souhaite corrigé

Reconduire les balises du précédent ReportingFi

qu'elles soient corrigées ou reconduites à

l'identique

DocRefId unique (celui

du f ichier rejeté est

réutilisable)

Reconduire toutes les balises du précédent

AccountReport

Erreur sur les AccountReport : les enregistrements rejetés doivent être renvoyés ( sauf exception)

Message refID unique

reconduire le DocRefId du précédent ReportingFi

Reconduire les balises du précédent ReportingFi

nouvel DocRefId

unique

DocRefId que l'on souhaite

corrigé

Reconduire les balises du précédent AccountReport

qu'elles soient corrigées ou reconduites à l'identique

Correction d'une valeur du bloc AccountReportSans modif ication du bloc ReportingFi

Message refID unique

reconduire le DocRefId du précédent ReportingFi

Reconduire les balises du précédent ReportingFi

nouvel DocRefId

unique

DocRefId que l'on souhaite

corrigé

Reconduire les balises du précédent AccountReport

qu'elles soient corrigées ou reconduites à l'identique

Annulation du bloc AccountReportSans modif ication du bloc ReportingFi

Message refID unique

reconduire le DocRefId du précédent ReportingFi

Reconduire les balises du précédent ReportingFi

nouvel DocRefId

unique

DocRefId que l'on souhaite

annulé

Reconduire toutes les balises du précédent

AccountReport

Correction d'une valeur du bloc AccountReportAvec correction du bloc ReportingFi

Message refID unique

nouvel DocRefId unique

DocRefId que l'on souhaite corrigé

Reconduire les balises du précédent ReportingFi

qu'elles soient corrigées ou reconduites à

l'identique

nouvel DocRefId

unique

DocRefId que l'on souhaite

corrigé

Reconduire les balises du précédent AccountReport

qu'elles soient corrigées ou reconduites à l'identique

Annulation du bloc AccountReport Avec annulation du bloc ReportingFi

Message refID unique

nouvel DocRefId unique

DocRefId que l'on souhaite annulé

Reconduire les balises du précédent ReportingFi

nouvel DocRefId

unique

DocRefId que l'on souhaite

annulé

Reconduire les balises du précédent AccountReport

Correction d'une valeur du seul bloc ReportingFi(Sans modif ication du bloc AccountReport)

Message refID unique

nouvel DocRefId unique

DocRefId que l'on souhaite corrigé

Reconduire les balises du précédent ReportingFi

qu'elles soient corrigées ou reconduites à

l'identique

(1) Hypothèse retenue : le fichier précédent contient un bloc ReportingFi et un bloc AccountReport qui n'ont pas été rejetés (Cf paragraphe 4.3.2 Précisions).

4.3.3 Précisions

Il existe des règles spécifiques selon le type de rejet des données. En particulier, le renvoi d'un correctif n'est pas toujours requis.Suivant le type d'erreurs à corriger / modifier, et comme détaillé ci-dessous, ces modifications devront fairel'objet, quel que soit le nombre d'enregistrements impliqués :- d'un dépôt d'un nouveau fichier initial : cas A- ou d'une modification d'un fichier initial par un fichier correctif : cas B1, B2, B3- ou d'une modification d'un fichier correctif par un fichier correctif : cas C

A) Dépôt d'un nouveau fichier initial :

Le fichier A initial est rejeté au niveau fichier.

Dans ce cas, le dépôt d'un correctif n'est pas possible. L'envoi par l'IF d'un nouveau fichier initial (corrigé deserreurs ayant provoqué le rejet du fichier) est requis pour pouvoir valablement déposer les données del'enregistrement

B) Modification d'un fichier initial par un fichier correctif :

B1: Le fichier A initial est accepté au niveau fichier.

Dans ce cas, le dépôt d'un correctif est requis pour modifier des données d'un enregistrement quel que soit lecontrôle de niveau métier.

B2: Le fichier B (1er correctif) est rejeté au niveau fichier.

39

B3: Le fichier B (1er correctif) est accepté au niveau fichier mais il contient un enregistrement rejeté.

C) Modification d'un fichier correctif par un fichier correctif

Le fichier B (1er correctif) est accepté au niveau fichier. Une Le fichier B (1er correctif) est accepté au niveaufichier. Une correction doit être apportée sur un enregistrement valide du fichier B.

4.4 RG4 Déclarations ne comportant aucun compte à déclarer

L'obligation déclarative, conformément à l'accord multilatéral du 29 octobre 2014, s'applique à toutes les IFentrant dans le champ d'application de l'accord CRS.

La DGFiP préconise de signaler une absence totale de compte à déclarer (cf. §5.1.2.4 Déclaration d'un étatnéant) sur le portail Tiers Déclarants. Dans ces conditions, la déclaration d'état néant concerne tous les États outerritoires donnant lieu à transmission d'informations pour l'IF déclarante indiquée par la saisie de son numéroSIRET, LEI ou AMF.

40

5 VOLET TECHNIQUE

5.1 Envoi des fichiers

Pour faciliter la transmission des fichiers de la collecte CRS XML, l’Administration fiscale propose un service en ligne spécialisé Tiers déclarants (TELE-TD) qui permettra d’effectuer par Internet, de manière sécurisée, simple et gratuite, la déclaration des informations visées par le présent cahier des charges. Aucun autre mode detransmission n'est autorisé.Les fichiers transférés feront l'objet de 2 contrôles distincts et dé-corrélés dans le temps :

• les contrôles de « premier niveau »• les contrôles de « second niveau »

Ces contrôles sont décrits au §5.1.2.5

Télé-TD ne restituera que le contrôle de premier niveau.

5.1.1 Description des fonctionnalités

Le service spécialisé TELE-TD permet :• une authentification par une procédure Identifiant/Mot de passe ;• la saisie d'informations précisant le dépôt ;• la sélection et l'envoi, via une liaison sécurisée Internet, du fichier correspondant à la déclaration CRS ;• la remise immédiate, en fin de procédure de téléchargement :

• d'un accusé de dépôt (AD) avec la référence DGFiP du fichier déposé ;• d'un compte rendu d'anomalies (CRA) en cas d'anomalie(s) détectée(s).

Les contrôles sont décrits au §5.3.1 Contrôles de premier niveau et §5.3.2 Contrôle de second niveau.

5.1.2 Modalité d’utilisation du service

L'accès à TELE-TD s'effectue depuis l'espace Tiers déclarants sur le site www.impots.gouv.fr :• lien PARTENAIRES > Tiers déclarants• lien Accès à la transmission par l’internet des fichiers TD/Bilatéral (EDI)

5.1.2.1 Authentification par Identifiant/Mot de passe

Une procédure d’attribution d'un identifiant Télé-TD est disponible à partir de la page de connexion en cliquantsur le lien « Obtenir mes identifiants ».

Les éléments d'identification lors de la saisie seront :• Raison sociale• Un des numéros d'identification de l'IF suivants : numéro SIRET, GIIN, LEI ou d'agrément AMF• Nom du correspondant• Numéro de téléphone• Adresse courriel pour réception des identifiants• Code de Sécurité (captcha)

Les numéros SIRET feront l'objet d'un contrôle par l'algorithme de LUHNLes numéros GIIN, LEI ou d'agrément AMF feront l'objet d'un contrôle formel (contrôle de vraisemblance).Le GIIN est un identifiant sur 19 caractères de format : XXXXXX.XXXXX.XX.XXX

41

Le LEI est un identifiant sur 20 caractères alphanumériques.Le numéro d'agrément AMF est généralement un identifiant comportant 11 caractères au plus.

5.1.2.2 Saisie des informations précisant le dépôt

Un écran de saisie d'informations, correspondant à un bordereau d'envoi (BE), sera proposé. Sur cet écran lesdonnées suivantes seront demandées :

• un bloc « DESIGNATION DE L'ORGANISME EMETTEUR » pour les coordonnées de l'IFremettante ;

• un bloc « CORRESPONDANT RESPONSABLE » pour les coordonnées du contact• un bloc « CARACTERISTIQUES DE L'ENVOI »

L'adresse courriel communiquée doit être pérenne. En effet, elle sera notamment utilisée pour l'envoi del'accusé de dépôt ou du compte rendu d'anomalie de premier niveau, l'envoi du compte rendu des contrôles desecond niveau ou toute demande d'information complémentaire ultérieure. Il est donc fortement recommandéd'utiliser une adresse courriel fonctionnelle d'un service et non l'adresse d'une personne physique en particulier.

5.1.2.3 Envoi du fichier

La procédure permet de sélectionner, sur le poste de l'utilisateur du service, le fichier à télécharger, une fois leBE correctement saisi.

5.1.2.4 Déclaration d'un état néant

Conformément à la RG4, une IF peut signaler à la DGFiP qu'elle n'a aucune information à transmettre au titredu présent cahier des charges.

En pratique, le bloc « CARACTERISTIQUES DE L'ENVOI » permet de sélectionner une option de dépôt d'unétat néant qui fera l'objet d'une demande de confirmation. Suite à cette confirmation, aucun téléchargement defichier ne sera proposé.

Remarque importante : Dans ce cas particulier, le numéro d'identification du remettant saisi dans le BE(§5.1.2.2 Saisie des informations précisant le dépôt) devra être identique au numéro d'identification de l'IFsouhaitant déclarer une absence de compte à déclarer. Ce dialogue devra être répété dans son intégralité pourchaque IF dans cette situation.

5.1.2.5 Contrôle du dépôt

Cas d'un état néant (aucun fichier déposé)

Aucun contrôle n'étant réalisé, un accusé de dépôt sera affiché. Il attestera de la prise en compte de l'état néantet communiquera des informations d'horodatage et de référence fournies par la DGFiP. L'utilisateur aura lapossibilité de l'imprimer (possibilité de sauvegarde au format PDF).

Cas d'un fichier déposé

Comme indiqué au §5.3 Contrôles, le fichier fera l'objet de 2 étapes de contrôles. Les contrôles visés au §5.3.1Contrôles de premier niveau et §5.3.2 Contrôle de second niveau seront donc mis en œuvre.

42

En l'absence d'anomalie de premier niveau, un accusé de dépôt sera affiché. Il attestera de la bonne réception etde la validité du dépôt et communiquera des informations d'horodatage, la référence DGFiP. L'utilisateur aurala possibilité de l'imprimer (possibilité de sauvegarde au format PDF).

En cas d'anomalie de premier niveau, le dépôt sera rejeté en intégralité et le CRA affiché avec des informationsd'horodatage, la référence DGFiP et des éléments d'information précisant la cause du rejet.

Il sera précisé sur le CRA la version du schéma de collecte DGFiP utilisée pour les contrôles, soit la version 1.0pour ce cahier des charges.

Une fois le dépôt validé, il fera l'objet de contrôles supplémentaires, dits de second niveau (Voir §5.3.2Contrôle de second niveau), suite auxquels un compte-rendu d'anomalie ou un compte-rendu de validation,sera communiqué par mail dans les 72H.

43

Exemple d'accusé de dépôt pour un état néant

Exemple d'accusé de dépôt pour un fichier déposé 1 (1er niveau) : le fichier est bien reçu par l'administration etva subir des contrôles de 2nd niveau. Un compte rendu sera transmis par courriel (à l'adresse saisie dans lebordereau) dans les 72 heures, pour confirmer ou non la validité du fichier.

44

Exemple de CRA (1 er niveau)

• Dans cet exemple, le fichier téléchargé ne respectait pas le schéma XSD (erreur sur le« MessageTypeindic »).

Descriptif du compte-rendu de 2ème niveau

Le schéma XML sera identique à celui disponible sur le site de l'OCDE à date du 7/02/2017 (v1.0) et disponiblesur le site impot.gouv.fr, concernant les notifications d'État à État (http://www.oecd.org/tax/exchange-of-tax-information/common-reporting-standard-status-message-xml-schema-user-guide-for-tax-administrations.htm).

Les règles de nommage des 3 fichiers présents dans le mail CRM de 2eme niveau sont :

• chaîne « CRS-DAC2_Contrôles2nd niveauCR »• valeur de resultatValidation (valide ou rejete)• horodatage = plus ancien evenement.date_evenement tel que evenement.type_evenement='CHKDON'>

(Le time stamp correspond à yyyy-mm-dd hh:mm:ss :ms concaténé)• extension : « .xml »

Le nom est identique pour le fichier PDF et CSV sauf pour l’extension. Exemple : CRS-DAC2_Controles2nd_niveauCR_Echange_valide_0604201710424442.xml (avec également CRS-DAC2_Controles2nd_niveauSynthèse_Echange_valide_0604201710424442.pdf et CRS-DAC2_Controles2nd_niveauCR_Echange_valide_0604201710424442.csv).

45

Exemple de compte rendu 2ème niveau (provisoire)

<?xml version="1.0" encoding="UTF-8"?><csm:CRSStatusMessage_OECD xmlns:csm="urn:oecd:ties:csm:v1" xmlns:iso="urn:oecd:ties:isocsmtypes:v1" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <csm:MessageSpec> <csm:TransmittingCountry>FR</csm:TransmittingCountry> <csm:ReceivingCountry>FR</csm:ReceivingCountry> <csm:MessageType>CRSMessageStatus</csm:MessageType> <csm:MessageRefId>FR_2016_DGFIP_000000045</csm:MessageRefId> <csm:Timestamp>2017-02-02T15:24:28</csm:Timestamp> </csm:MessageSpec> <csm:CrsStatusMessage> <csm:OriginalMessage> <csm:OriginalMessageRefID>IF_2016_FR_ZA_2016_CO_0003_2.48.01</csm:OriginalMessageRefID> </csm:OriginalMessage> <csm:ValidationErrors> <csm:RecordError> <csm:Code>12</csm:Code> <csm:Details Language="FR">CorrDocRefID ne correspond à aucun enregistrement connu.</csm:Details> <csm:DocRefIDInError>IF_2016_RFI_CO0060__2.48.01-0001</csm:DocRefIDInError> <csm:FieldsInError> <csm:FieldPath>CorrDocRefId</csm:FieldPath> </csm:FieldsInError> </csm:RecordError> <csm:RecordError> <csm:Code>12</csm:Code> <csm:Details Language="FR">CorrDocRefID ne correspond à aucun enregistrement connu.</csm:Details> <csm:DocRefIDInError>IF_2016_AR_CO0120_2.48.01-0002</csm:DocRefIDInError> <csm:FieldsInError> <csm:FieldPath>CorrDocRefId</csm:FieldPath> </csm:FieldsInError> </csm:RecordError> <csm:RecordError> <csm:Code>12</csm:Code> <csm:Details Language="FR">CorrDocRefID ne correspond à aucun enregistrement connu.</csm:Details> <csm:DocRefIDInError>IF_2016_AR_CO0120_2.48.01-0002</csm:DocRefIDInError> <csm:FieldsInError> <csm:FieldPath>CorrDocRefId</csm:FieldPath> </csm:FieldsInError> </csm:RecordError> <csm:RecordError> <csm:Code>12</csm:Code> <csm:Details Language="FR">CorrDocRefID ne correspond à aucun enregistrement connu.</csm:Details> <csm:DocRefIDInError>IF_2016_AR_CO0120_2.48.01-147-0004</csm:DocRefIDInError> <csm:FieldsInError> <csm:FieldPath>CorrDocRefId</csm:FieldPath> </csm:FieldsInError> </csm:RecordError> <csm:RecordError>

46

<csm:Code>12</csm:Code> <csm:Details Language="FR">CorrDocRefID ne correspond à aucun enregistrement connu.</csm:Details> <csm:DocRefIDInError>IF_2016_AR_CO0120_2.48.01-147-0004</csm:DocRefIDInError> <csm:FieldsInError> <csm:FieldPath>CorrDocRefId</csm:FieldPath> </csm:FieldsInError> </csm:RecordError> <csm:RecordError> <csm:Code>12</csm:Code> <csm:Details Language="FR">CorrDocRefID ne correspond à aucun enregistrement connu.</csm:Details> <csm:DocRefIDInError>IF_2016_AR_CO0120_2.48.01-2-0003</csm:DocRefIDInError> <csm:FieldsInError> <csm:FieldPath>CorrDocRefId</csm:FieldPath> </csm:FieldsInError> </csm:RecordError> <csm:RecordError> <csm:Code>12</csm:Code> <csm:Details Language="FR">CorrDocRefID ne correspond à aucun enregistrement connu.</csm:Details> <csm:DocRefIDInError>IF_2016_AR_CO0120_2.48.01-2-0003</csm:DocRefIDInError> <csm:FieldsInError> <csm:FieldPath>CorrDocRefId</csm:FieldPath> </csm:FieldsInError> </csm:RecordError> <csm:RecordError> <csm:Code>12</csm:Code> <csm:Details Language="FR">CorrDocRefID ne correspond à aucun enregistrement connu.</csm:Details> <csm:DocRefIDInError>IF_2016_RFI_CO0060__2.48.01-0005</csm:DocRefIDInError> <csm:FieldsInError> <csm:FieldPath>CorrDocRefId</csm:FieldPath> </csm:FieldsInError> </csm:RecordError> <csm:RecordError> <csm:Code>12</csm:Code> <csm:Details Language="FR">CorrDocRefID ne correspond à aucun enregistrement connu.</csm:Details> <csm:DocRefIDInError>IF_2016_AR_CO0120_2.48.01-0007</csm:DocRefIDInError> <csm:FieldsInError> <csm:FieldPath>CorrDocRefId</csm:FieldPath> </csm:FieldsInError> </csm:RecordError> <csm:RecordError> <csm:Code>12</csm:Code> <csm:Details Language="FR">CorrDocRefID ne correspond à aucun enregistrement connu.</csm:Details> <csm:DocRefIDInError>IF_2016_AR_CO0120_2.48.01-0007</csm:DocRefIDInError> <csm:FieldsInError> <csm:FieldPath>CorrDocRefId</csm:FieldPath> </csm:FieldsInError> </csm:RecordError> <csm:RecordError>

47

<csm:Code>12</csm:Code> <csm:Details Language="FR">CorrDocRefID ne correspond à aucun enregistrement connu.</csm:Details> <csm:DocRefIDInError>IF_2016_AR_CO0120_2.48.01-0006</csm:DocRefIDInError> <csm:FieldsInError> <csm:FieldPath>CorrDocRefId</csm:FieldPath> </csm:FieldsInError> </csm:RecordError> <csm:RecordError> <csm:Code>12</csm:Code> <csm:Details Language="FR">CorrDocRefID ne correspond à aucun enregistrement connu.</csm:Details> <csm:DocRefIDInError>IF_2016_AR_CO0120_2.48.01-0006</csm:DocRefIDInError> <csm:FieldsInError> <csm:FieldPath>CorrDocRefId</csm:FieldPath> </csm:FieldsInError> </csm:RecordError> </csm:ValidationErrors> <csm:ValidationResult> <csm:Status>Accepted</csm:Status> <csm:ValidatedBy>1.0</csm:ValidatedBy> </csm:ValidationResult> </csm:CrsStatusMessage></csm:CRSStatusMessage_OECD>

Description des balises :<csm:MessageSpec><TransmittingCountry> = FR<ReceivingCountry> = FR<csm:MessageType>CRSMessageStatus</csm:MessageType><MessageRefID> = Concaténation des éléments suivants, séparés par un « _ » :- "FR"- millésime (année fiscale à laquelle se rapporte le fichier transmis par l'institution financière)- DGFiP- Numéro séquentiel unique sur 9 caractères numériques

body<OriginalMessage><OriginalMessageRefID> = MessageRefId du fichier

<ValidationErrors><FileError><Code> = en cas d'échec d'un contrôle de 2nd niveau, le code erreur est valorisé danscette balise (il s'agit ici de contrôle entraînant le rejet du fichier. Cf Cahier des charges de collecte)<ValidationErrors><FileError><Details> = cette balise est valorisée par la description du contrôle en échec (Cf Cahierdes charges de collecte)

<ValidationErrors><RecordError><Code> = en cas d'échec d'un contrôle de 2nd niveau, le code erreur est valorisédans cette balise (Cf Cahier des charges de collecte)<ValidationErrors><RecordError><Details> = cette balise est valorisée par la description du contrôle en échec (CfCahier des charges de collecte)avec comme attribut le language= FR <ValidationErrors><RecordError><DocRefIDInError> = DocRefID de collecte en erreur (répétable)

<ValidationErrors><RecordError><FieldsInError> = balise en erreur (répétable)

<ValidationResult> = Rejected (si erreur contrôle entraînant le rejet du fichier) ou Accepted si aucune erreur ou si un ouplusieurs enregistrement(s) en erreur contrôle de niveau enregistrement. <ValidatedBy> = 1.0

48

5.2 Caractéristiques des fichiers

5.2.1 Conventions de nommage du fichier XMLLes caractères accentués, caractères spéciaux (\, /, *, ?, « , <, >, |, œ, €, ', @, etc.) ou caractères de contrôle ne sont pas autorisés dans les noms de fichier à déposer.Hormis ces contraintes, aucun nommage n’est imposé.

5.2.2 Format du fichierLe fichier doit être de type texte respectant la syntaxe XML (cf. §5.2.5 Encodage du fichier XML), non crypténi protégé par mot de passe. Il est fortement recommandé de suffixer le fichier, avant compression, avec l'extension « .xml ».

Tout autre type de fichier n'est pas autorisé et sera rejeté, en particulier les fichiers aux formats PDF, XLS, XLSX, ODS, DOC, DOCX, ODT, MP3, etc. (cf. §5.3 Contrôles).

5.2.3 CompressionLe fichier peut être compressé au format GZIP. Le choix de l'outil de compression est libre dès lors qu'il reste conforme à l'implémentation standard zlib v1.2.3 ou supérieure (cf. http://zlib.net/).

5.2.4 Taille maximum du fichierLa taille du fichier ne pourra pas excéder 100 méga-octets avant compression. La taille maximale du message ne peut excéder 32 000 enregistrements (account reports).

5.2.5 Encodage du fichier XMLLe fichier sera encodé en UTF-8 sans BOM (Byte-Order Mark).

5.2.6 Structure du fichier XMLLa structure du fichier XML doit être conforme aux recommandations XML et XML Schemas 1.0 du World Wide Web Consortium (W3C).

5.2.7 Structure du fichier XML

5.2.7.1 Prologue du fichier XML

Le prologue devra comporter obligatoirement et seulement la déclaration XML comprenant les attributs 'version' et 'encoding'. La première ligne du fichier sera, par exemple :

<?xml version="1.0" encoding="UTF-8"?>

La présence de l'attribut définissant l'encodage est indispensable. En son absence, le fichier sera rejeté lors du dépôt. Il en sera de même en cas d'encodage non UTF-8 (cf. §5.3.1.1 Contrôles de niveau Fichier, contrôle CF15).

Les instructions de traitement et les déclarations de type de document (DTD) sont interdites. Par contre, le fichier ne sera pas rejeté si des commentaires sont présents dans le prologue.

5.2.7.2 Arbre des éléments

49

Celui-ci sera conforme aux schémas XML que l'on peut obtenir à l'URL https://www.impots.gouv.fr/portail/files/media/1_metier/3_partenaire/tiers_declarants/cdc_td_bilateral/schema_collecte_crs_2017_dgfip.zip

Sous réserve de la technologie utilisée, un schéma xml peut à la fois être employé pour : • l'élaboration du code permettant de générer un fichier xml ;

• la validation d'un fichier xml.

Dès lors, l'archive A-schéma_collecte_CRS_2017_DGFiP.zip comporte le schéma permettant de générer un fi-chier de collecte et de le contrôler indifféremment qu'il soit un dépôt de test ou un dépôt réel.

La DGFIP attire l'attention des institutions financières sur le fait que les fichiers test ne seront pas acceptés en environnement de production (rejet de 1er niveau). Réciproquement, les fichiers de production ne seront pas acceptés en environnement de test.

5.2.8 Éléments non autorisés dans le fichier XML

5.2.8.1 Caractères non autorisés

L'utilisation des caractères apostrophe ('), double tiret (--) et dièse (#) est interdite :- le caractère apostrophe (') doit être remplacé par la notation &apos;- il n'existe actuellement aucune chaîne de caractères de substitution pour le double tiret (--) et le dièse (#)

Les caractères esperluette (&) et inférieur (<) de la syntaxe XML sont interdits comme valeur d’élément ou d'attribut et les substitutions suivantes doivent être appliquées :- le caractère esperluette (&) doit être remplacé par la notation &amp;- le caractère inférieur (<) doit être remplacé par la notation &lt;

Il est recommandé de suivre les bonnes pratiques du W3C XML Schema dans les valeurs d’élément ou d'attribut et d'appliquer les substitutions suivantes :- le caractère supérieur (>) peut être remplacé par la notation &gt;- le caractère guillemet droit (") peut être remplacé par la notation &quot;

5.2.8.2 Autres éléments non autorisés

Les fichiers XML ne doivent par ailleurs comporter aucun des éléments suivants :- liens hypertextes ;- composants JavaScript ;- fichiers exécutables ;- fichiers d'archives compressés.

5.3 Contrôles

Les contrôles sont réalisés en trois phases :

1. Les contrôles dits de premier niveau fourniront une validation synchrone à l'utilisateur pour les règles portant sur la nature du fichier et sa validation au regard d'un schéma xml.

2. Les contrôles dits de second niveau fourniront un compte-rendu portant sur les règles métiers de collecteinstaurées par la DGFiP.

50

3. Les contrôles dits de troisième niveau sont des contrôles opérés par l'État destinataire des déclarations. Ils génèrent un compte rendu à destination de la DGFiP qui aura la charge de son exploitation. Ainsi, untroisième type de compte-rendu d'anomalies peut être transmis ultérieurement à l'utilisateur.Précision : il n'y a pas d'accusé de dépôt pour cette troisième phase.

5.3.1 Contrôles de premier niveau

Les contrôles sont réalisés successivement en trois étapes dans l'ordre :

• Exploitabilité du fichier : les contrôles dits « Fichier » sont identifiés par CFnn (nn = numéro)• Vérification que le fichier xml est bien formé : contrôles dits « Validation » CV01• Vérification que le fichier xml est valide au regard du schéma de collecte DGFiP : contrôles dits

« Validation » CV02

L'échec d'un contrôle à une quelconque des trois étapes provoque le rejet du fichier dans sa totalité. Uncompte-rendu d'anomalie précise les causes du rejet (jusqu'à 100 anomalies). L'utilisateur du service est invité àproposer un nouveau fichier après correction des causes signalées.

Lorsqu'un fichier est rejeté en premier niveau (que ce soit CF, CV01 ou CV02), il n'y a pas de transmission à laseconde étape de validation et il n'y aura donc pas d'intégration dans le système informatique de la DGFiP.Donc en cas de rejet fichier, les DocRefID ne sont pas stockés par la DGFiP, ils sont réutilisables.

5.3.1.1 Contrôles Fichier

Les contrôles suivants permettent de vérifier l'exploitabilité pour les étapes suivantes du fichier déposé.

Numéro Contrôle Libellé d’anomalie

CF01Erreur bloquante fichier inexploitable« Fichier illisible »

CF11Erreur bloquante« Fichier vide »

CF12Erreur bloquante le fichier reçu n'est pas un fichier texte« Fichier binaire (fichier texte attendu) »

CF13Erreur bloquante sur le fichier compressé« Fichier GZIP non conforme »

CF14Erreur bloquante sur la taille du fichier« La taille du fichier est supérieure à la limite autorisée »

CF15Erreur bloquante sur le fichier XML« Déclaration XML absente ou erronée du fichier »

5.3.1.2 Contrôles de niveau validation CV01

Ils permettent de vérifier la conformité du fichier par rapport aux recommandations XML du W3C4.

5.3.1.3 Contrôles de niveau validation CV02

Ils permettent de valider la structure du fichier XML au regard du présent cahier des charges (validation XSD).

4Extensible Markup Language (XML) 1.0 (Fifth Edition) : https://www.w3.org/TR/2008/REC-xml-20081126/

51

Selon le contexte (période de test, dépôt en réel), l'ensemble de schémas est différent.

Chaque ensemble de fichiers XSD constitue le schéma de collecte DGFiP. Le schéma de collecte est issu du schéma CRS v1.0 dont la description est dans le document de la norme CRS référencé [2] et disponible sur internet (cf.§3.1 et §3.1.1). Les règles sont identiques à celles décrites dans la norme CRS à l'exception de celles portant sur les éléments suivants :

Élément Règle

MessageRefId(I. Message Header p.252)

La valeur de l'élément est composée de quatre parties séparées par un tiret bas '_'La première partie est la chaîne fixe composée de deux caractères 'IF'.La seconde partie est une chaîne de quatre caractères représentant un nombre entier de 2010 à 2099.Les troisième et quatrième parties sont libres. Toutefois la troisième partie ne devra pas comporter le caractère de séparation '_' au risque de voir celle-ci tronquée.La valeur de l'élément ne devra pas dépasser 200 caractères.

CorrMessageRefId(I. Message Header p.253)

La présence de cet élément dans l'élément MessageSpec et DocSpec constitue un motif de rejet.

Type de nom (attribut nameType)(§IIc – NamePerson_Typep.256)

Le type de nom doit correspondre à une valeur autorisée. La valorisation par OECD201 n'est pas autorisée.

MessageTypeIndic(I. Message Header p.253)

Les seules valeurs autorisées sont 'CRS701' et 'CRS702'. La présence de la valeur 'CRS703' sera un motif de rejet.

TIN(§IIb. TIN_Type p.255)

L'élément TIN n'est pas obligatoire, mais s'il est présent sa valeur doit contenir au moins un caractère différent de l'espace '&#20;' et de la tabulation '\t' et ne doit pascontenir de saut de ligne '\n' ni de retour chariot '\r'.

Attribut « issuedBy » de l'élément « TIN »(§IIb. TIN_Type p.255)

L'attribut « issuedBy » de l'élément « TIN » est obligatoire dès lors que ce dernier est présent.À défaut d'information sur le pays d'émission du TIN, le pays signalé en tant que resCountryCode doit être renseigné dans cette balise.

IN(§IIIb. Entity IN p.261)

L'élément IN n'est pas obligatoire, mais s'il est présent sa valeur doit contenir au moins un caractère différent de l'espace '&#20;' et de la tabulation '\t' et ne doit pascontenir de saut de ligne '\n' ni de retour chariot '\r'.

« Name » des éléments « OrganisationParty_Type »(§IIIc – OrganisationParty_Type p.262)

La valeur doit contenir au moins un caractère différent de l'espace '&#20;' et de la tabulation '\t' et ne doit pas contenir de saut de ligne '\n' ni de retour chariot '\r'.

« LastName » des éléments « NamePerson_Type »(§IIc – NamePerson_Typep.257)

La valeur doit contenir au moins un caractère différent de l'espace '&#20;' et de la tabulation '\t' et ne doit pas contenir de saut de ligne '\n' ni de retour chariot '\r'.

"AddressFix.City" des élements de type "Address_Type"(§IId – Address_Type p.259)

Si « AddressFix » est sélectionné, la valeur du champ « City » doit contenir au moins un caractère différent de l'espace '&#20;' et de la tabulation '\t' et ne doit pascontenir de saut de ligne '\n' ni de retour chariot '\r'.

52

Élément Règle

"AddressFree" des élements de type "Address_Type"(§IId – Address_Type p.258)

Si « AddressFree » est sélectionné, la valeur doit contenir au moins un caractère différent de l'espace '&#20;' et de la tabulation '\t' et ne doit pas contenir de saut deligne '\n' ni de retour chariot '\r'.

Le séparateur utilisé pour délimiter les différents éléments peut être un espace ou une barre oblique ('/') mais en aucun cas un retour chariot.

DocTypeIndic(Recommandations techniques §3, p.272)

En période de tests et sur la plate-forme dédiée, les seules valeurs autorisées sont 'OECD10', 'OECD11', 'OECD12', et 'OECD13'.Pour un dépôt en réel sur la plate-forme de production, les seules valeurs autorisées sont 'OECD0', 'OECD1', 'OECD2', et 'OECD3'.

DocRefId(Recommandations techniques §4, p.273)

La valeur de l'élément est composée de 1 à 200 caractères appartenant aux seules listes suivantes :- les chiffres de 0 à 9- les lettres minuscules de a à z et les lettres majuscules de A à Z- les caractères '+' (signe plus), ',' (virgule), '-' (trait d'union), '.' (point), ' :' (deux points), '=' (égal), '_' (tiret bas).

Précision : les autres caractères tel que l'espace '&#x20;' ou autres marques sont interdites et constitueront un motif de rejet.

CorrDocRefId(Recommandations techniques §4, p.273)

Idem que l'élément DocRefId ci-dessus.

Les contrôles de niveau « Validation » sont réalisés grâce à des analyseurs (parseurs) XML et XSD schémas.

5.3.2 Contrôles de second niveau (enregistrement par enregistrement)

À ce niveau, le rejet peut s'opérer à plusieurs niveaux :- au niveau du message (cf Code erreur 1) ;- au niveau du ReportingFI ;- au niveau de l'enregistrement Account Report.

Le stockage de toutes les références DocRefID est opéré dès lors que le message n'est pas rejeté, afin d'assurer un chaînage avec les éventuels prochains dépôts ; Si un enregistrement est rejeté, il doit être corrigé par un CorrDocRefID, puisque le DocRefID a été stocké et a un statut qu'il convient de corriger. Dans le cas où un ReportingFI a été rejeté, les DocRefID des AccountReport ne sont pas réutilisables.

Suite aux contrôles de 2nd niveau, un compte-rendu exhaustif sera transmis par mail à l'adresse enregistrée dansun délai de 72H après le dépôt du fichier par une IF et sa validation en 1er niveau. En cas de non-réception de compte-rendu, il sera possible de l'obtenir en contactant l'assistance EAI.

53

5.3.2.1 Liste de contrôles

Codeerreur

Contrôle Description du contrôle Conséquence

1MessageRefID déjà utilisé

La référence du MessageRefID a déjà été utilisée pour un précédent message déjà reçu.

Rejet du message (rejet « file »)

2Numéro du compte IBAN

Le numéro de compte « AccountNumber » ne respectepas la structure IBAN alors que le type de compte « AcctNumberType » est OECD601.

Rejet de l'enregistrement « Account report » associé

3Numéro de compte ISIN

Le numéro de compte « AccountNumber » ne respectepas la structure ISIN alors que le type de compte « AcctNumberType » est OECD603.

Rejet de l'enregistrement « AccountReport » associé

4Solde du compte négatif

Le solde du compte « AccountBalance » est inférieur àzéro. Le solde doit être supérieur ou égal à zéro.

Rejet de l'enregistrement « AccountReport » associé

5Solde du compte clos

Le solde du compte « AccountBalance » doit être égal à zéro lorsque le compte a été cloturé (attribut « ClosedAccount » de « AccountNumber »).

Rejet de l'enregistrement « AccountReport » associé

6Le titulaire du compte ne doit pas être renseigné

Ne pas utiliser la balise « ControllingPerson » quand le titulaire du compte est une entité « Organisation» et que le type de titulaire « AcctHolderType » est CRS102 (Personne devant faire l’objet d’une déclaration) ou CRS 103 (Entité non financière passive qui est une Personne devant faire l’objet d’unedéclaration).

Rejet de l'enregistrement « AccountReport » associé

7Le titulaire du compte doit être renseigné

La balise « ControllingPerson » doit être renseignée quand le titulaire du compte est une entité « Organisation» et que le type de titulaire « AcctHolderType » est CRS101 (Entité non financière passive pour laquelle une ou plusieurs Personne(s) devant faire l’objet d’une déclaration est ou sont Personne(s) détenant le contrôle).

Rejet de l'enregistrement « AccountReport » associé

8Pays ou territoiresde résidence

Au moins un des États ou territoires de résidence du titulaire d'un compte ou de la personne physique qui contrôle le titulaire de compte, doit faire parti de la liste des États ou territoires donnant lieu à transmission d'informations.

Rejet de l'enregistrement « AccountReport » associé

9 Date de naissanceLa date de naissance n'est pas conforme. La date doit être après 1900 et avant l'année en cours.

Rejet de l'enregistrement « AccountReport » associé

10Déclaration de compte

Une déclaration de compte « AccountReport » doit être renseignée (sauf en cas de correction de l'élément « ReportingFI »).

Rejet de l'enregistrement « Reporting FI »

11DocRefID déjà utilisé

La référence d'enregistrement « DocRefID » est déjà utilisée par un autre enregistrement.

Rejet de l'enregistrement « ReportingFI » et/ou des enregistrements « AccountReport » associés*

12CorrDocRefId inconnu

CorrDocRefID ne correspond à aucun enregistrement <DocRefId> connu.

Rejet de l'enregistrement « ReportingFI » et/ou des enregistrements « AccountReport » associés*

13 CorrDocRefId n'est plus valide

CorrDocRefID fait référence à un enregistrement qui n'est plus valide.

Rejet de l'enregistrement « ReportingFI » et/ou des enregistrements « AccountReport » associés*

54

* Rejet de l'enregistrement « ReportingFI » et de tous les enregistrements « AccountReport » associés si la référence rejetée concerne la « ReportingFI ».Rejet de l'enregistrement « AccountReport » si la référence rejetée concerne le seul « AccountReport ».

Codeerreur

Contrôle Description du contrôle Conséquence

14CorrDocRefId pour un nouvel enregistrement

Il ne faut pas spécifier de CorrDocRefID pour un nouvel enregistrement (DocTypeIndic1).

Rejet de l'enregistrement « ReportingFI » et/ou des enregistrements « AccountReport » associés*

15CorrDocRefId absent

La référence CorrDocRefID est absente pour un DocTypeIndic 2 ou 3.

Rejet de l'enregistrement « ReportingFI » et/ou des enregistrements « AccountReport » associés*

16 Option de renvoiL'option de renvoi « Resend » (« Resend Data » et « Resend Test Data ») ne peut être utilisée que pour unélément « ReportingFI » déjà reçu.

Rejet de l'enregistrement « ReportingFI » et/ou des enregistrements « AccountReport » associés*

17Suppression du ReportingFI

L'IF déclarante « ReportingFI » peut être supprimée si toutes les déclarations de comptes liées sont individuellement supprimées.

rejet de l'enregistrement « ReportingFI »

18CorrDocRefId deux fois dans le même message

La même référence « CorrDocRefID » ne peut pas êtrecorrigée ou effacée deux fois dans le même message. Par défaut, seule la 1ère référence sera acceptée.

Rejet du « ReportingFI » et/ou des enregistrements « AccountReport » associés*

19Algorithme, structure, format du TIN

L'algorithme, la structure et/ou le format du TIN sont invalides.

Pas de rejet - non bloquant

20Pays de compte non documenté

Le code du pays de résidence « ResCountryCode » doit être FR pour un compte non documenté.

Rejet de l'« AccountReport »

21ResCountryCode du ReportingFI

Le ResCountryCode du ReportingFI doit correspondreà « FR » ou « BL ».

Rejet du « ReportingFI » et des enregistrements « AccountReport » associés

* Rejet de l'enregistrement « ReportingFI » et de tous les enregistrements « AccountReport » associés si la référence rejetée concernela « ReportingFI ».Rejet de l'enregistrement « AccountReport » si la référence rejetée concerne le seul « AccountReport ».

5.3.2.2 Format du compte-rendu de validation de second niveau

Pour chaque fichier déposé ayant passé avec succès les contrôles de premier niveau, un compte-rendu de 2ndniveau sera généré à l'issue des contrôles de second niveau. Ce compte-rendu contient la référence au fichierdéposé (MessageRefID) et donne le statut d'acceptation du fichier (cf : annexe 1) :

- soit le fichier est accepté sans aucune erreur ;- soit le fichier est accepté avec des réserves non bloquantes (liste exhaustive des enregistrements en erreurs) ;- soit le fichier est accepté avec des réserves bloquantes (liste exhaustive des enregistrements en erreurs) ;- soit le fichier est rejeté (rejet du message).

Le schéma XML utilisé répond au besoin de détail et d'exhaustivité en présentant pour chaque erreur au moins :- la référence de l'enregistrement concerné (ReportingFI ou AccountReport) ;- le code de l'erreur ;- les balises XML concernées.

55

Ce schéma est utilisé pour les retours suite à un dépôt.

Le fichier est transmis par courriel à l'adresse renseignée lors du dépôt dans Télé-TD. Si le compte-rendu desecond niveau dépasse une certaine taille, l'archive sera découpée et envoyée en plusieurs mails numérotés.

En plus de ce fichier XML, un tableau de synthèse qui présentera le nombre d'erreurs par motif sera inclus dans le courriel.

5.3.3 Demandes de correction suite à un retour des États et territoires donnant lieu à transmission d'informations

Les éventuelles demandes de corrections suite à un retour des juridictions partenaires après transmission desdonnées déposées par les institutions financières, seront transmises par courriel à l'adresse renseignée lors dudépôt dans Télé-TD. Les institutions financières ont un délai de 60 jours pour déposer un fichier correctif.

Calendrier

Les jalons de la campagne de collecte des déclarations sont les suivants :

• 02/05/2019 : Ouverture du service en ligne spécialisé Tiers déclarants (TELE-TD) pour prise en chargede la collecte CRS.

• 31/07/2019 : Date limite de dépôt des déclarations CRS valides au sens des schémas XSD applicables(cf. §1.3 Documents techniques de référence).

• Au-delà de la date limite de dépôt, les déclarations CRS seront considérées comme hors délai. La collecte CRS/DAC 2 clôturera au 31 juillet 2019. Le portail télé-TD rouvrira le 1er octobre 2019. Lesdéclarations correctives, et/ou initiales hors délais, seront prises en compte par la DGFiP et transmisesaux juridictions partenaires (s'agissant des enregistrements valides) à partir de cette date.

• 30/09/2019 : Date limite d'envoi aux juridictions partenaires de l'ensemble des déclarations CRS.

5.4 Fichiers d'essai

À partir du 02 mai 2018, le service en ligne Tiers déclarants (TELE-TD) sera mis à la disposition des IF pourleur permettre de tester le dépôt de(s) déclaration(s) (dates d'ouverture et de fermeture de cette période de testseront confirmées ultérieurement).

Afin d’éviter tout risque de traitement inapproprié, les déclarations CRS déposées durant la période de testdevront impérativement être de type OECD10, OECD11, OECD12, OECD13. Les déposants devrontimpérativement veiller à ne pas déposer de fichiers d'essai sur le portail TELE-TD après la date declôture de la période de test indiquée ci-dessus.

Les fichiers d'essai déposés pendant la période de test ne valent pas dépôt réel.

Les dépôts sur ce portail de test sont purgés tous les quinze jours.

Des données réelles, notamment concernant le TIN, peuvent être utilisées sur la plate-forme de tests.Cependant, la DGFiP rappelle qu'il est indispensable de prévoir des clauses de confidentialité dans l'usage deces données, notamment avec des prestataires externes.

56

5.5 Assistance

Lors du processus de dépôt d'une déclaration CRS sur le service en ligne TELE-TD, l'émetteur du fichier estinvité à désigner le correspondant qui sera pris en compte par l'administration fiscale pour assurer le suivi desquestions relatives à l'exploitation du fichier.

Il est donc important de renseigner précisément les rubriques « CORRESPONDANT RESPONSABLE » qui désignera l'interlocuteur privilégié du service d'assistance pour ce dépôt.

Les déclarants confrontés à des problèmes spécifiques ont la possibilité de contacter l’assistance directe de l’établissement de services informatiques (ESI) de NEVERS. Ses coordonnées sont les suivantes :

DIRECTION GÉNÉRALE DES FINANCES PUBLIQUESÉTABLISSEMENT DE SERVICES INFORMATIQUES

BP 70958007 NEVERS CEDEX

téléphone :

57

0 810 003 739 0,06 € / min

6 ANNEXES

6.1 Liste provisoire des États et territoires donnant lieu à transmission d’in-formations au titre de l’année 2018

Afrique du Sud ZA Guernesey GG Pays-Bas NL

Allemagne DE Hongrie HU Pologne PL

Andorre AD Hong-Kong HK Portugal PT

Arabie Saoudite SA Îles Bonaire, Saba et Saint-Eustache

BQ République Tchèque CZ

Argentine AR Île de Man IM Roumanie RO

Australie AU Îles Féroé FO Royaume-Uni GB

Autriche AT Inde IN Saint-Marin SM

Azerbaïdjan AZ Indonésie ID Seychelles SC

Barbade BB Irlande IE Singapour SG

Belgique BE Islande IS Slovaquie SK

Brésil BR Israël IL Slovénie SI

Bulgarie BG Italie IT Suède SE

Canada CA Japon JP Suisse CH

Chili CL Jersey JE Uruguay UY

Chine CN Lettonie LV

Chypre CY Liechtenstein LI

Colombie CO Lituanie LT

Corée du Sud KR Luxembourg LU

Croatie HR Malaisie MY

Danemark DK Malte MT

Espagne ES Maurice MU

Estonie EE Mexique MX

Fédération de Russie

RU Monaco MC

Finlande FI Norvège NO

Gibraltar GI Nouvelle-Zélande NZ

Grèce GR Pakistan PK

Groenland GL Panama PA

58

Codes ISO particuliers

Conformément aux exigences de l'Union européenne, les ResCountryCode doivent obligatoirement être conformes au tableau suivant :

1 2 3 4 5 6 8

Dispositif

DAC 2Dispositif

CRS

ResCountryCodedu ReportingFI

(corps du message)

ResCountryCode ouCountryCode dans le

ReportingGroup(corps du message)

Date del'échange

FR

Guadeloupe OUI OUI FR / 2017

Guyane OUI OUI FR / 2017

Martinique OUI OUI FR / 2017

Réunion OUI OUI FR / 2017

Mayotte OUI OUI FR / 2017

Saint-Martin OUI NON FR / 2017

Saint-Barthélemy

OUI NON BL / 2017

NL

Bonaire NON OUI / BQ 2017

Saint Eustache NON OUI / BQ 2017

Saba NON OUI / BQ 2017

Aruba NON OUI / AW --

Curacao NON OUI / CW 2018

Saint-Marteen NON OUI / SX --

ES Îles Canaries OUI OUI / ES 2017

UK Gibraltar OUI OUI / GI 2017

PT Les Açores OUI OUI / PT 2017

Madère OUI OUI / PT 2017

FI Åland OUI OUI / FI 2017

* Ces codes ISO doivent faire l'objet d'une confirmation par l'Union européenne.

59

6.2 Exemples de fichiers XML

Ces exemples de fichiers XML sont fournis à titre indicatif et ne sont pas représentatifs de cas d'utilisation réels. Ils sont valides d'un point de vue schéma, ce qui ne signifie pas qu'ils sont valides vis-à-vis des contrôles de 2nd niveau.

6.2.1 Exemple 1 : fichier contenant une déclaration initiale de deux comptes (OECD1).

Cet exemple présente le cas de la déclaration initiale par la banque Zed de deux comptes détenus par des personnes physiques multi-résidentes.

La déclaration est de type OECD1.

Données de la déclaration initiale :IF DECLARANTE

Nom Banque Zed

Adresse 14 rue des Dahlias – 75000 PARIS

SIRET 12345678912345

CLIENT PERSONNE PHYSIQUE À DÉCLARER (1)

Nom LOPEZ

Prénom Juan

Adresse 1 (Espagne - ES) Avenida de San Luis, 12-13 – 28033 MADRID

Adresse 2 (Mexique - MX) Urion 30 – Col. Tlatilco – 02860 MEXICO

Adresse 3 (Belgique - BE) 163 avenue de Philippeville – 6001 MARCINELLE

Numéro de compte FR3812345987650257181259066

TIN (ES) 01234567-X

TIN (MX) 548987213Z

Solde de compte au 31/12/2016 2000000€

CLIENT PERSONNE PHYSIQUE À DÉCLARER (2)

Nom SANCHEZ

Prénom Pedro

Adresse 1 (Espagne - ES) 17 calle Los Acebos – 33008 OVIEDO

Numéro de compte FR3001001252321478126350420

TIN (ES) 00000051T

TIN (BE) Inconnu

Solde de compte au 31/12/2016 700000

60

<?xml version="1.0" encoding="UTF-8"?><crs:CRS_OECD xmlns:stf="urn:oecd:ties:stf:v4" xmlns:crs="urn:oecd:ties:crs:v1"xmlns:cfc="urn:oecd:ties:commontypesfatcacrs:v1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="urn:oecd:ties:crs:v1 CrsXML_v1.0_DGFiP.xsd" version="1.0">

<crs:MessageSpec><crs:SendingCompanyIN>12345678912345</crs:SendingCompanyIN><crs:TransmittingCountry>FR</crs:TransmittingCountry><crs:ReceivingCountry>FR</crs:ReceivingCountry><crs:MessageType>CRS</crs:MessageType><crs:MessageRefId>IF_2016_12345678912345_M199099887254</crs:MessageRefId><crs:MessageTypeIndic>CRS701</crs:MessageTypeIndic><crs:ReportingPeriod>2016-12-31</crs:ReportingPeriod><crs:Timestamp>2017-03-22T22:38:00</crs:Timestamp>

</crs:MessageSpec><crs:CrsBody>

<crs:ReportingFI><crs:ResCountryCode>FR</crs:ResCountryCode>

<crs:IN INType="TIN" issuedBy="FR">12345678912345</crs:IN><crs:Name>Banque Zed</crs:Name><crs:Address>

<cfc:CountryCode>FR</cfc:CountryCode><cfc:AddressFree>14 rue des dahlias/75000/PARIS</cfc:AddressFree>

</crs:Address><crs:DocSpec>

<stf:DocTypeIndic>OECD1</stf:DocTypeIndic><stf:DocRefId>IF_2016_12345678912345_IF256872058</stf:DocRefId>

</crs:DocSpec></crs:ReportingFI><crs:ReportingGroup>

<crs:AccountReport><crs:DocSpec>

<stf:DocTypeIndic>OECD1</stf:DocTypeIndic><stf:DocRefId>IF_2016_12345678912345_AR256872627</stf:DocRefId>

</crs:DocSpec><crs:AccountNumber AcctNumberType="OECD601">FR3812345987650257181259066</crs:AccountNumber><crs:AccountHolder>

<crs:Individual><crs:ResCountryCode>BE</crs:ResCountryCode><crs:ResCountryCode>ES</crs:ResCountryCode><crs:ResCountryCode>MX</crs:ResCountryCode><crs:TIN issuedBy="ES">01234567-X</crs:TIN><crs:TIN issuedBy="MX">548987213Z</crs:TIN><crs:Name>

<crs:FirstName>Juan</crs:FirstName>

61

<crs:LastName>Lopez</crs:LastName></crs:Name><crs:Address>

<cfc:CountryCode>ES</cfc:CountryCode><cfc:AddressFree>Avenida de San Luis, 12-13/28033 MADRID</cfc:AddressFree>

</crs:Address><crs:Address>

<cfc:CountryCode>MX</cfc:CountryCode><cfc:AddressFree>Urión 30/Col. Tlatilco/02860 MEXICO, D.F./MEXICO</cfc:AddressFree>

</crs:Address><crs:Address legalAddressType="OECD303">

<cfc:CountryCode>BE</cfc:CountryCode><cfc:AddressFix>

<cfc:Street>Avenue de Philippeville</cfc:Street><cfc:BuildingIdentifier>163</cfc:BuildingIdentifier><cfc:PostCode>6001</cfc:PostCode><cfc:City>Marcinelle</cfc:City>

</cfc:AddressFix></crs:Address><crs:BirthInfo>

<crs:BirthDate>1970-02-15</crs:BirthDate><crs:City>Valencia</crs:City>

</crs:BirthInfo></crs:Individual>

</crs:AccountHolder><crs:AccountBalance currCode="EUR">2000000.00</crs:AccountBalance><crs:Payment>

<crs:Type>CRS502</crs:Type><crs:PaymentAmnt currCode="EUR">100000.00</crs:PaymentAmnt>

</crs:Payment></crs:AccountReport><crs:AccountReport>

<crs:DocSpec><stf:DocTypeIndic>OECD1</stf:DocTypeIndic><stf:DocRefId>IF_2016_12345678912345_AR25687872895</stf:DocRefId>

</crs:DocSpec><crs:AccountNumber AcctNumberType="OECD601">FR3001001252321478126350420</crs:AccountNumber><crs:AccountHolder>

<crs:Individual><crs:ResCountryCode>ES</crs:ResCountryCode><crs:ResCountryCode>BE</crs:ResCountryCode><crs:TIN issuedBy="ES">00000051T</crs:TIN>

62

<crs:Name><crs:FirstName>Pedro</crs:FirstName><crs:LastName>Sanchez</crs:LastName>

</crs:Name><crs:Address>

<cfc:CountryCode>ES</cfc:CountryCode><cfc:AddressFree>17 Calle Los Acebos 33008 Oviedo</cfc:AddressFree>

</crs:Address><crs:BirthInfo>

<crs:BirthDate>1965-03-21</crs:BirthDate><crs:City>Oviedo</crs:City>

</crs:BirthInfo></crs:Individual>

</crs:AccountHolder><crs:AccountBalance currCode="EUR">700000.00</crs:AccountBalance>

</crs:AccountReport></crs:ReportingGroup>

</crs:CrsBody></crs:CRS_OECD>

63

6.2.2 Exemple 2 : fichier contenant une déclaration complémentaire de compte (OECD0)

Cet exemple présente le cas de la déclaration complémentaire par la banque Zed d'un compte détenu par une personne physique multi-résidente omise sur la déclaration initiale.

La déclaration est de type OECD0 pour la ReportingFI.

Données de la déclaration complémentaire :IF DECLARANTE

Nom Banque Zed

Adresse 14 rue des Dahlias – 75000 PARIS

SIRET 12345678912345

CLIENT PERSONNE PHYSIQUE À DÉCLARER

Nom SVENSSON

Prénom Jan-Erik

Adresse 1 (Suède – SE)<AddressFree>

18-20 Hamngatan – 111 77 STOCKHOLM

Adresse 2 (Estonie – EE)<AddressFree>

20 Toom Kuninga – 15185 TALLINN

Adresse 3 (Norvège – NO)<AddressFix>

25 B Karl Johansgate – 0025 OSLO

Numéro de compte FR2717788589002247251897012

TIN (SE) 870314-2391

TIN (EE) 47302200234

TIN (NO) Inconnu

Solde de compte au 31/12/2016 1255897 €

Paiement de dividendes en 2016 255 €

Paiement d'intérêts en 2016 3287 €

64

<?xml version="1.0" encoding="UTF-8"?><crs:CRS_OECD xmlns:stf="urn:oecd:ties:stf:v4" xmlns:crs="urn:oecd:ties:crs:v1"xmlns:cfc="urn:oecd:ties:commontypesfatcacrs:v1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="urn:oecd:ties:crs:v1 CrsXML_v1.0_DGFiP.xsd" version="1.0">

<crs:MessageSpec><crs:SendingCompanyIN>12345678912345</crs:SendingCompanyIN><crs:TransmittingCountry>FR</crs:TransmittingCountry><crs:ReceivingCountry>FR</crs:ReceivingCountry><crs:MessageType>CRS</crs:MessageType><crs:MessageRefId>IF_2016_12345678912345_M1999874486344681014</crs:MessageRefId><crs:MessageTypeIndic>CRS701</crs:MessageTypeIndic><crs:ReportingPeriod>2016-12-31</crs:ReportingPeriod><crs:Timestamp>2017-03-12T15:02:21</crs:Timestamp>

</crs:MessageSpec><crs:CrsBody>

<crs:ReportingFI><crs:ResCountryCode>FR</crs:ResCountryCode><crs:IN INType="TIN" issuedBy="FR">12345678912345</crs:IN><crs:Name>Banque Zed</crs:Name><crs:Address>

<cfc:CountryCode>FR</cfc:CountryCode><cfc:AddressFree>14 rue des dahlias/75000/PARIS</cfc:AddressFree>

</crs:Address><crs:DocSpec>

<stf:DocTypeIndic>OECD0</stf:DocTypeIndic><stf:DocRefId>IF_2016_12345678912345_IF256872058</stf:DocRefId>

</crs:DocSpec></crs:ReportingFI><crs:ReportingGroup>

<crs:AccountReport><crs:DocSpec>

<stf:DocTypeIndic>OECD1</stf:DocTypeIndic><stf:DocRefId>IF_2016_12345678912345_AR897897402587</stf:DocRefId>

</crs:DocSpec><crs:AccountNumber AcctNumberType="OECD601">FR2717788589002247251897012</crs:AccountNumber><crs:AccountHolder>

<crs:Individual><crs:ResCountryCode>SE</crs:ResCountryCode><crs:ResCountryCode>EE</crs:ResCountryCode><crs:ResCountryCode>NO</crs:ResCountryCode><crs:TIN issuedBy="SE">870314-2391</crs:TIN><crs:TIN issuedBy="EE">47302200234</crs:TIN><crs:Name>

<crs:FirstName>Jan-Erik</crs:FirstName>

65

<crs:LastName>Svensson</crs:LastName></crs:Name><crs:Address>

<cfc:CountryCode>SE</cfc:CountryCode><cfc:AddressFree>18-20 Hamngatan / Stockholm 111 77</cfc:AddressFree>

</crs:Address><crs:Address>

<cfc:CountryCode>EE</cfc:CountryCode><cfc:AddressFree>20 Toom Kuninga/15185 TALLINN</cfc:AddressFree>

</crs:Address><crs:Address>

<cfc:CountryCode>NO</cfc:CountryCode><cfc:AddressFix>

<cfc:Street>Karl Johansgate</cfc:Street><cfc:BuildingIdentifier>25 B</cfc:BuildingIdentifier><cfc:PostCode>0025</cfc:PostCode><cfc:City>OSLO</cfc:City>

</cfc:AddressFix></crs:Address><crs:BirthInfo>

<crs:BirthDate>1963-08-29</crs:BirthDate><crs:City>Paris</crs:City>

</crs:BirthInfo></crs:Individual>

</crs:AccountHolder><crs:AccountBalance currCode="EUR">1255897.00</crs:AccountBalance><crs:Payment>

<crs:Type>CRS501</crs:Type><crs:PaymentAmnt currCode="EUR">255.00</crs:PaymentAmnt>

</crs:Payment><crs:Payment>

<crs:Type>CRS502</crs:Type><crs:PaymentAmnt currCode="EUR">3287.00</crs:PaymentAmnt>

</crs:Payment></crs:AccountReport>

</crs:ReportingGroup></crs:CrsBody>

</crs:CRS_OECD>

66

6.2.3 Exemple 3 : fichier contenant des corrections de données sur un compte précédemment déclaré (OECD2).

Cet exemple présente le cas de la correction par la banque Zed d'un compte détenu par une personne physique multi-résidente précédemment déclarée (compte unique de l'exemple 2) et comportant plusieurs erreurs :- l'adresse 2 en Estonie est annulée et remplacée par une adresse au Luxembourg ;- le TIN estonien est annulé et remplacé par un TIN luxembourgeois ;- le solde de compte au 31/12/2016 est porté de 1255897 € à 2558954 € ;- le montant des dividendes payés en 2016 est porté de 255 € à 2255 €.

La déclaration est de type OECD2 pour l'Account Report modifié (cf. tableau au 4.3.2).

Données de la déclaration rectificative (données corrigées en rouge)IF DECLARANTE

Nom Banque Zed

Adresse 14 rue des Dahlias – 75000 PARIS

SIRET 12345678912345

CLIENT PERSONNE PHYSIQUE À DÉCLARER

Nom SVENSSON

Prénom Jan-Erik

Adresse 1 (Suède – SE)<AddressFree>

18-20 Hamngatan – 111 77 STOCKHOLM

Adresse 2 (Luxembourg – LU)<AddressFree>

47 rue du Mont Saint Luc – 4002 ESCH-SUR-ALZETTE

Adresse 3 (Norvège – NO)<AddressFix>

25 B Karl Johansgate – 0025 OSLO

Numéro de compte FR2717788589002247251897012

TIN (SE 870314-2391

TIN (LU) 1020304050607

TIN (NO) Inconnu

Solde de compte au 31/12/2016 2558954 €

Paiement de dividendes en 2016 2255 €

Paiement d'intérêts en 2016 3287 €

67

<?xml version="1.0" encoding="UTF-8"?><crs:CRS_OECD xmlns:stf="urn:oecd:ties:stf:v4" xmlns:crs="urn:oecd:ties:crs:v1"xmlns:cfc="urn:oecd:ties:commontypesfatcacrs:v1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="urn:oecd:ties:crs:v1 CrsXML_v1.0_DGFiP.xsd" version="1.0">

<crs:MessageSpec><crs:TransmittingCountry>FR</crs:TransmittingCountry><crs:ReceivingCountry>FR</crs:ReceivingCountry><crs:MessageType>CRS</crs:MessageType><crs:MessageRefId>IF_2016_12345678912345_M87592729</crs:MessageRefId><crs:MessageTypeIndic>CRS702</crs:MessageTypeIndic><crs:ReportingPeriod>2016-12-31</crs:ReportingPeriod><crs:Timestamp>2017-04-10T11:30:47</crs:Timestamp>

</crs:MessageSpec><crs:CrsBody>

<crs:ReportingFI><crs:ResCountryCode>FR</crs:ResCountryCode><crs:IN INType="TIN" issuedBy="FR">12345678912345</crs:IN><crs:Name>Banque Zed</crs:Name><crs:Address>

<cfc:CountryCode>FR</cfc:CountryCode><cfc:AddressFree>14 rue des dahlias/75000/PARIS</cfc:AddressFree>

</crs:Address><crs:DocSpec>

<stf:DocTypeIndic>OECD0</stf:DocTypeIndic><stf:DocRefId>IF_2016_12345678912345_IF29902311</stf:DocRefId><stf:CorrDocRefId> IF_2016_12345678912345_IF256872058</stf:CorrDocRefId>

</crs:DocSpec></crs:ReportingFI><crs:ReportingGroup>

<crs:AccountReport><crs:DocSpec>

<stf:DocTypeIndic>OECD2</stf:DocTypeIndic><stf:DocRefId>IF_2016_12345678912345_AR27890032 </stf:DocRefId><stf:CorrDocRefId>IF_2016_12345678912345_AR897897402587</stf:CorrDocRefId>

</crs:DocSpec><crs:AccountNumber AcctNumberType="OECD601">FR2717788589002247251897012</crs:AccountNumber><crs:AccountHolder>

<crs:Individual><crs:ResCountryCode>SE</crs:ResCountryCode><crs:ResCountryCode>LU</crs:ResCountryCode><crs:ResCountryCode>NO</crs:ResCountryCode><crs:TIN issuedBy="SE">870314-2391</crs:TIN><crs:TIN issuedBy="LU">1020304050607</crs:TIN><crs:Name>

68

<crs:FirstName>Jan-Erik</crs:FirstName><crs:LastName>Svensson</crs:LastName>

</crs:Name><crs:Address>

<cfc:CountryCode>SE</cfc:CountryCode><cfc:AddressFree>18-20 Hamngatan / Stockholm 111 77</cfc:AddressFree>

</crs:Address><crs:Address>

<cfc:CountryCode>LU</cfc:CountryCode><cfc:AddressFree>47 rue du Mont Saint Luc/4002 ESCH-SUR-ALZETTE</cfc:AddressFree>

</crs:Address><crs:Address>

<cfc:CountryCode>NO</cfc:CountryCode><cfc:AddressFix>

<cfc:Street>Karl Johansgate</cfc:Street><cfc:BuildingIdentifier>25 B</cfc:BuildingIdentifier><cfc:PostCode>0025</cfc:PostCode><cfc:City>OSLO</cfc:City>

</cfc:AddressFix></crs:Address><crs:BirthInfo>

<crs:BirthDate>1963-08-29</crs:BirthDate><crs:City>Paris</crs:City>

</crs:BirthInfo></crs:Individual>

</crs:AccountHolder><crs:AccountBalance currCode="EUR">2558954.00</crs:AccountBalance><crs:Payment>

<crs:Type>CRS501</crs:Type><crs:PaymentAmnt currCode="EUR">2255.00</crs:PaymentAmnt>

</crs:Payment><crs:Payment>

<crs:Type>CRS502</crs:Type><crs:PaymentAmnt currCode="EUR">3287.00</crs:PaymentAmnt>

</crs:Payment></crs:AccountReport>

</crs:ReportingGroup></crs:CrsBody>

</crs:CRS_OECD>

69

6.2.4 Exemple 4 : fichier contenant des annulations de données sur un compte précédemment déclaré (OECD3).

Cet exemple présente le cas de la suppression par la banque Zed d'un compte détenu par une personne déclarée à tort (compte 1 de l'exemple 1). Les données correspondantes sont supprimées.

La déclaration est de type OECD3 pour l'Account Report annulé (cf. tableau au 4.3.2).

Données annulées :IF DECLARANTE

Nom Banque Zed

Adresse 14 rue des Dahlias – 75000 PARIS

SIRET 12345678912345

CLIENT PERSONNE PHYSIQUE À ANNULER (1)

Nom LOPEZ

Prénom Juan

Adresse 1 (Espagne - ES) Avenida de San Luis, 12-13 – 28033 MADRID

Adresse 2 (Mexique - MX) Urion 30 – Col. Tlatilco – 02860 MEXICO

Adresse 3 (Belgique - BE) 163 avenue de Philippeville – 6001 MARCINELLE

Numéro de compte FR3812345987650257181259066

TIN (ES) 01234567-X

TIN (MX) 548987213Z

Solde de compte au 31/12/2016 2000000€

70

<?xml version="1.0" encoding="UTF-8"?><crs:CRS_OECD xmlns:stf="urn:oecd:ties:stf:v4" xmlns:crs="urn:oecd:ties:crs:v1"xmlns:cfc="urn:oecd:ties:commontypesfatcacrs:v1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="urn:oecd:ties:crs:v1 CrsXML_v1.0_DGFiP.xsd" version="1.0">

<crs:MessageSpec><crs:TransmittingCountry>FR</crs:TransmittingCountry><crs:ReceivingCountry>FR</crs:ReceivingCountry><crs:MessageType>CRS</crs:MessageType><crs:MessageRefId>IF_2016_12345678912345_M87592729</crs:MessageRefId><crs:MessageTypeIndic>CRS702</crs:MessageTypeIndic><crs:ReportingPeriod>2016-12-31</crs:ReportingPeriod><crs:Timestamp>2017-04-10T11:30:47</crs:Timestamp>

</crs:MessageSpec><crs:CrsBody>

<crs:ReportingFI><crs:ResCountryCode>FR</crs:ResCountryCode><crs:IN INType="TIN" issuedBy="FR">12345678912345</crs:IN><crs:Name>Banque Zed</crs:Name><crs:Address>

<cfc:CountryCode>FR</cfc:CountryCode><cfc:AddressFree>14 rue des dahlias/75000/PARIS</cfc:AddressFree>

</crs:Address><crs:DocSpec>

<stf:DocTypeIndic>OECD0</stf:DocTypeIndic><stf:DocRefId>IF_2016_12345678912345_IF256872058</stf:DocRefId>

</crs:DocSpec></crs:ReportingFI><crs:ReportingGroup>

<crs:AccountReport><crs:DocSpec>

<stf:DocTypeIndic>OECD3</stf:DocTypeIndic><stf:DocRefId>IF_2016_12345678912345_AR25858763</stf:DocRefId><stf:CorrDocRefId>IF_2016_12345678912345_AR256872627 </stf:CorrDocRefId>

</crs:DocSpec><crs:AccountNumber AcctNumberType="OECD601">FR3812345987650257181259066</crs:AccountNumber><crs:AccountHolder>

<crs:Individual><crs:ResCountryCode>BE</crs:ResCountryCode><crs:ResCountryCode>ES</crs:ResCountryCode><crs:ResCountryCode>MX</crs:ResCountryCode><crs:TIN issuedBy="ES">01234567-X</crs:TIN><crs:TIN issuedBy="MX">548987213Z</crs:TIN><crs:Name>

<crs:FirstName>Juan</crs:FirstName>

71

<crs:LastName>Lopez</crs:LastName></crs:Name><crs:Address>

<cfc:CountryCode>ES</cfc:CountryCode><cfc:AddressFree>Avenida de San Luis, 12-13/28033 MADRID</cfc:AddressFree>

</crs:Address><crs:Address>

<cfc:CountryCode>MX</cfc:CountryCode><cfc:AddressFree>Urión 30/Col. Tlatilco/02860 MEXICO, D.F./MEXICO</cfc:AddressFree>

</crs:Address><crs:Address legalAddressType="OECD303">

<cfc:CountryCode>BE</cfc:CountryCode><cfc:AddressFix>

<cfc:Street>Avenue de Philippeville</cfc:Street><cfc:BuildingIdentifier>163</cfc:BuildingIdentifier><cfc:PostCode>6001</cfc:PostCode><cfc:City>Marcinelle</cfc:City>

</cfc:AddressFix></crs:Address><crs:BirthInfo>

<crs:BirthDate>1970-02-15</crs:BirthDate><crs:City>Valencia</crs:City>

</crs:BirthInfo></crs:Individual>

</crs:AccountHolder><crs:AccountBalance currCode="EUR">2000000.00</crs:AccountBalance><crs:Payment>

<crs:Type>CRS502</crs:Type><crs:PaymentAmnt currCode="EUR">100000.00</crs:PaymentAmnt>

</crs:Payment></crs:AccountReport>

</crs:ReportingGroup></crs:CrsBody>

</crs:CRS_OECD>

72

6.2.5 Exemple 5 : Cas particulier - Fichier contenant la modification des coordonnées d'une institution financière.

Cet exemple présente le cas de la modification d'une partie de l'adresse de la Banque Zed.

La déclaration est de type OECD2 pour la Reporting FI modifiée (cf. tableau au 4.3.2).

Les comptes précédemment déclarés n'étant pas modifiés, le bloc d'informations <ReportingGroup> est repris àblanc.

Données de la déclaration rectificative (données corrigées en rouge) :IF DECLARANTE

Nom Banque Zed

Adresse 14 rue des Marguerites – 75000 PARIS

SIRET 12345678912345

73

<?xml version="1.0" encoding="UTF-8"?><crs:CRS_OECD xmlns:stf="urn:oecd:ties:stf:v4" xmlns:crs="urn:oecd:ties:crs:v1"xmlns:cfc="urn:oecd:ties:commontypesfatcacrs:v1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="urn:oecd:ties:crs:v1 CrsXML_v1.0_DGFiP.xsd" version="1.0">

<crs:MessageSpec><crs:TransmittingCountry>FR</crs:TransmittingCountry><crs:ReceivingCountry>FR</crs:ReceivingCountry><crs:MessageType>CRS</crs:MessageType><crs:MessageRefId>IF_2016_12345678912345_M29902311</crs:MessageRefId><crs:MessageTypeIndic>CRS702</crs:MessageTypeIndic><crs:ReportingPeriod>2016-12-31</crs:ReportingPeriod><crs:Timestamp>2017-04-10T11:30:47</crs:Timestamp>

</crs:MessageSpec><crs:CrsBody>

<crs:ReportingFI><crs:ResCountryCode>FR</crs:ResCountryCode><crs:IN INType="TIN" issuedBy="FR">12345678912345</crs:IN><crs:Name>Banque Zed</crs:Name><crs:Address>

<cfc:CountryCode>FR</cfc:CountryCode><cfc:AddressFree>14 rue des Marguerites/75000/PARIS</cfc:AddressFree>

</crs:Address><crs:DocSpec>

<stf:DocTypeIndic>OECD2</stf:DocTypeIndic><stf:DocRefId>IF_2016_12345678912345_IF8752498742584</stf:DocRefId><stf:CorrDocRefId>IF_2016_12345678912345_IF19902311</stf:CorrDocRefId>

</crs:DocSpec></crs:ReportingFI><crs:ReportingGroup> </crs:ReportingGroup>

</crs:CrsBody></crs:CRS_OECD>

74

6.2.6 Exemple 6 : Cas particulier - Fichier contenant la déclaration d'une entité non financière (ENF) passive multi-résidente dont le contrôle est détenu par plusieurs personnes.

Cet exemple présente le cas de la déclaration par la compagnie Assurances Mondass d'un compte détenu par une ENF passive multi-résidente (Belgique et Norvège), dont le contrôle est détenu par trois personnes physiques distinctes (une personne d'Espagne et deux personnes de Norvège). Dans ce cas, la règle prévoit de déclarer trois AccountReport distincts (cf : Norme d’échange automatique de renseignement relatifs aux comptes financiers en matière fiscale, Seconde édition, p.267)

• Account Report 1 : ENF passive multi-résidente de type CRS101 (ResCountryCode Belgique et Norvège) et une ControlingPerson résidente fiscale d'Espagne.

• Account Report 2 : ENF passive multi-résident de type CRS101 (ResCountryCode Belgique et Norvège) et deux ControlingPerson résidentes de Norvège.

• Account Report 3 : ENF passive multi-résidente de type CRS103 (ResCountryCode Belgique et Norvège). La norme préconise en présence d'un AccountReport de type CRS101 avec une ControllingPerson ayant le même ResCountryCode que l'ENF passive (Norvège) d'émettre également un AccountReport de type CRS103 avec la seule ENF passive.

Cette déclaration est de type OECD1.

Données de la déclaration initiales :IF DECLARANTE

Nom Assurances Mondass

Adresse Rue du Parc – 00000 MOULINSART

SIRET 12345678912345

ENF PASSIVE DÉTENTRICE DU COMPTE

Nom World Invest

Adresse 1 (Belgique - BE) Rue Joseph II, 44 – 1000 BRUXELLES

Adresse 2 (Norvège - NO) Bassengbakken 4 – 7042 TRONDHEIM

Numéro de compte FR8843212788282073752228713

TIN (BE) Néant

TIN (NO) Néant

Solde de compte au 31/12/2016 2000000 €

Paiement d'intérêts en 2016 3287 €

PERSONNE DÉTENANT LE CONTROLE (1)

Nom LOPEZ

Prénom Juan

Adresse (Espagne – ES) Avenida de San Luis, 12-13 – 28033 MADRID

TIN (ES) 01234567-X

PERSONNE DÉTENANT LE CONTROLE (2)

Nom SVENSSON

Prénom Jan-Erik

Adresse (Norvège – NO) Karl Johansgate 25 B - 0025 OSLO

TIN (NO) 15027085142

75

PERSONNE DÉTENANT LE CONTROLE (3)

Nom HELGENSEN

Prénom Erna

Adresse 1 (Suède – NO) Holtegaten 29 - 0355 OSLO

TIN (NO) 14036305289

76

<?xml version="1.0" encoding="UTF-8"?><crs:CRS_OECD xmlns:stf="urn:oecd:ties:stf:v4" xmlns:crs="urn:oecd:ties:crs:v1"xmlns:cfc="urn:oecd:ties:commontypesfatcacrs:v1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="urn:oecd:ties:crs:v1 CrsXML_v1.0_DGFiP.xsd" version="1.0">

<crs:MessageSpec><crs:SendingCompanyIN>12345678912345</crs:SendingCompanyIN><crs:TransmittingCountry>FR</crs:TransmittingCountry><crs:ReceivingCountry>FR</crs:ReceivingCountry><crs:MessageType>CRS</crs:MessageType><crs:MessageRefId>IF_2016_12345678912345_ERJFOIE872554615641LQLJEL</crs:MessageRefId><crs:MessageTypeIndic>CRS701</crs:MessageTypeIndic><crs:ReportingPeriod>2016-12-31</crs:ReportingPeriod><crs:Timestamp>2017-05-19T10:00:52</crs:Timestamp>

</crs:MessageSpec><crs:CrsBody>

<crs:ReportingFI><crs:ResCountryCode>FR</crs:ResCountryCode><crs:IN INType="TIN" issuedBy="FR">12345678912345</crs:IN><crs:Name>Assurances Mondass</crs:Name><crs:Address>

<cfc:CountryCode>FR</cfc:CountryCode><cfc:AddressFree>Rue du Parc/00000 MOULINSART</cfc:AddressFree>

</crs:Address><crs:DocSpec>

<stf:DocTypeIndic>OECD1</stf:DocTypeIndic><stf:DocRefId>IF_2016_12345678912345_IF199087454687</stf:DocRefId>

</crs:DocSpec></crs:ReportingFI><crs:ReportingGroup>

<crs:AccountReport><crs:DocSpec>

<stf:DocTypeIndic>OECD1</stf:DocTypeIndic><stf:DocRefId>IF_2016_12345678912345_AR19908751324</stf:DocRefId>

</crs:DocSpec><crs:AccountNumber AcctNumberType="OECD601">FR8843212788282073752228713</crs:AccountNumber><crs:AccountHolder>

<crs:Organisation><crs:ResCountryCode>BE</crs:ResCountryCode><crs:ResCountryCode>NO</crs:ResCountryCode><crs:Name>World Invest</crs:Name><crs:Address>

<cfc:CountryCode>BE</cfc:CountryCode><cfc:AddressFree>Rue Joseph II 44/1000 BRUXELLES</cfc:AddressFree>

</crs:Address>

77

<crs:Address><cfc:CountryCode>NO</cfc:CountryCode><cfc:AddressFree>Bassengbakken 4/7042 TRONDHEIM</cfc:AddressFree>

</crs:Address></crs:Organisation><crs:AcctHolderType>CRS101</crs:AcctHolderType>

</crs:AccountHolder><crs:ControllingPerson>

<crs:Individual><crs:ResCountryCode>ES</crs:ResCountryCode><crs:TIN issuedBy="ES">01234567-X</crs:TIN><crs:Name>

<crs:FirstName>Juan</crs:FirstName><crs:LastName>Lopez</crs:LastName>

</crs:Name><crs:Address>

<cfc:CountryCode>ES</cfc:CountryCode><cfc:AddressFree>Avenida de San Luis, 12-13/28033 MADRID</cfc:AddressFree>

</crs:Address><crs:BirthInfo>

<crs:BirthDate>1970-02-15</crs:BirthDate><crs:City>Valencia</crs:City>

</crs:BirthInfo></crs:Individual><crs:CtrlgPersonType>CRS801</crs:CtrlgPersonType>

</crs:ControllingPerson><crs:AccountBalance currCode="EUR">2000000.00</crs:AccountBalance><crs:Payment>

<crs:Type>CRS502</crs:Type><crs:PaymentAmnt currCode="EUR">100000.00</crs:PaymentAmnt>

</crs:Payment></crs:AccountReport><crs:AccountReport>

<crs:DocSpec><stf:DocTypeIndic>OECD1</stf:DocTypeIndic><stf:DocRefId>IF_2016_12345678912345_AR199070459483514</stf:DocRefId>

</crs:DocSpec><crs:AccountNumber AcctNumberType="OECD601">FR8843212788282073752228713</crs:AccountNumber><crs:AccountHolder>

<crs:Organisation><crs:ResCountryCode>BE</crs:ResCountryCode><crs:ResCountryCode>NO</crs:ResCountryCode>

78

<crs:Name>World Invest</crs:Name><crs:Address>

<cfc:CountryCode>BE</cfc:CountryCode><cfc:AddressFree>Rue Joseph II 44/1000 BRUXELLES</cfc:AddressFree>

</crs:Address><crs:Address>

<cfc:CountryCode>NO</cfc:CountryCode><cfc:AddressFree>Bassengbakken 4/7042 TRONDHEIM</cfc:AddressFree>

</crs:Address></crs:Organisation><crs:AcctHolderType>CRS103</crs:AcctHolderType>

</crs:AccountHolder><crs:AccountBalance currCode="EUR">2000000.00</crs:AccountBalance><crs:Payment>

<crs:Type>CRS502</crs:Type><crs:PaymentAmnt currCode="EUR">100000.00</crs:PaymentAmnt>

</crs:Payment></crs:AccountReport><crs:AccountReport>

<crs:DocSpec><stf:DocTypeIndic>OECD1</stf:DocTypeIndic><stf:DocRefId>IF_2016_12345678912345_AR1990FKJ54545</stf:DocRefId>

</crs:DocSpec><crs:AccountNumber AcctNumberType="OECD601">FR8843212788282073752228713</crs:AccountNumber><crs:AccountHolder>

<crs:Organisation><crs:ResCountryCode>BE</crs:ResCountryCode><crs:ResCountryCode>NO</crs:ResCountryCode><crs:Name>World Invest</crs:Name><crs:Address>

<cfc:CountryCode>BE</cfc:CountryCode><cfc:AddressFree>Rue Joseph II 44/1000 BRUXELLES</cfc:AddressFree>

</crs:Address><crs:Address>

<cfc:CountryCode>NO</cfc:CountryCode><cfc:AddressFree>Bassengbakken 4/7042 TRONDHEIM</cfc:AddressFree>

</crs:Address></crs:Organisation><crs:AcctHolderType>CRS101</crs:AcctHolderType>

</crs:AccountHolder><crs:ControllingPerson>

<crs:Individual>

79

<crs:ResCountryCode>NO</crs:ResCountryCode><crs:TIN issuedBy="NO">15027085142</crs:TIN><crs:Name>

<crs:FirstName>Jan-Erik</crs:FirstName><crs:LastName>SVENSSON</crs:LastName>

</crs:Name><crs:Address>

<cfc:CountryCode>NO</cfc:CountryCode><cfc:AddressFree>Karl Johansgate 25 B/0025 OSLO</cfc:AddressFree>

</crs:Address><crs:BirthInfo>

<crs:BirthDate>1970-02-15</crs:BirthDate><crs:City>OSLO</crs:City>

</crs:BirthInfo></crs:Individual><crs:CtrlgPersonType>CRS801</crs:CtrlgPersonType>

</crs:ControllingPerson><crs:ControllingPerson>

<crs:Individual><crs:ResCountryCode>NO</crs:ResCountryCode><crs:TIN issuedBy="NO">14036305289</crs:TIN><crs:Name>

<crs:FirstName>Erna</crs:FirstName><crs:LastName>HELGESEN</crs:LastName>

</crs:Name><crs:Address>

<cfc:CountryCode>NO</cfc:CountryCode><cfc:AddressFree>Holtegaten 29/0355 OSLO</cfc:AddressFree>

</crs:Address><crs:BirthInfo>

<crs:BirthDate>1963-03-14</crs:BirthDate><crs:City>Bergen</crs:City>

</crs:BirthInfo></crs:Individual><crs:CtrlgPersonType>CRS801</crs:CtrlgPersonType>

</crs:ControllingPerson><crs:AccountBalance currCode="EUR">2000000.00</crs:AccountBalance><crs:Payment>

<crs:Type>CRS502</crs:Type><crs:PaymentAmnt currCode="EUR">100000.00</crs:PaymentAmnt>

</crs:Payment></crs:AccountReport>

80

</crs:ReportingGroup></crs:CrsBody>

</crs:CRS_OECD>

FIN DU DOCUMENT

81

____________________________________________________________ Systém ASPI - stav k 14.2.2019 do částky 16/2019 Sb. a 4/2019 Sb.m.s. 26/2019 Sb. - o stanovení vyňatých účtů pro účely automatické výměny informací s j iným státem - poslední stav textu

26/2019 Sb.

VYHLÁŠKA

ze dne 29. ledna 2019

o stanov ení v yňatých účtů pro účely automatické v ýměny informací s j iným státem v rámci mezinárodní spolupráce při správ ě daní

Ministerstvo financí stanoví podle § 13d odst. 6 zákona č. 164/2013 Sb., o mezinárodní spolupráci při správě daní a o

změně dalších souvisejících zákonů, ve znění zákona č. 105/2016 Sb. a zákona č. 92/2017 Sb.:

§ 1

Předmět úprav y Tato vyhláška zapracovává příslušný předpis Evropské unie

1) a stanoví pro účely automatické výměny informací s

jiným státem vyňaté účty, u nichž je nízké riziko, že jejich prostřednictvím bude ohroženo správné zjištění a stanovení daně

nebo zabezpečení její úhrady.

§ 2

Vyňaté účty Vyňatým účtem je penzijní připojištění se státním příspěvkem účastníka podle zákona upravujícího penzijní připojištění se státním příspěvkem, jestliže celková výše jeho příspěvků za kalendářní rok nepřesáhne částku odpovídající 50

000 USD.

§ 3

Zrušov ací ustanovení Vyhláška č. 108/2016 Sb., o stanovení vyňatých účtů pro účely automatické výměny informací s jiným státem v rámci mezinárodní spolupráce při správě daní, se zrušuje.

§ 4

Účinnost

Tato vyhláška nabývá účinnosti dnem 1. dubna 2019.

Ministryně financí:

JUDr. Schillerov á, Ph.D., v. r. ____________________

1) Směrnice Rady 2014/107/EU ze dne 9. prosince 2014, kterou se mění směrnice 2011/16/EU, pokud jde o pov innou automatickou v ýměnu inf ormací v oblasti daní.

— 20 —

GAZZETTA UFFICIALE DELLA REPUBBLICA ITALIANA Serie generale - n. 316-2-2019

Art. 6.

Gli oneri per interessi, relativi all’anno finanziario 2019, faranno carico al capitolo 2216 (unità di voto par-lamentare 21.1) dello stato di previsione della spesa del Ministero dell’economia e delle finanze, per l’anno stes-so, ed a quelli corrispondenti, per gli anni successivi.

L’onere per il rimborso del capitale relativo all’anno finanziario 2025 farà carico al capitolo che verrà iscrit-to nello stato dì previsione della spesa del Ministero dell’economia e delle finanze per l’anno stesso, corri-spondente al capitolo 9537 (unità di voto parlamentare 21.2) dello stato di previsione per l’anno in corso.

L’ammontare della provvigione di collocamento, pre-vista dall’art. 2 del presente decreto, sarà scritturato dalle sezioni di Tesoreria fra i «pagamenti da regolare» e farà carico al capitolo 2247 (unità di voto parlamentare 21.1; codice gestionale 109) dello stato di previsione della spe-sa del Ministero dell’economia e delle finanze per l’anno finanziario 2019.

Il presente decreto sarà pubblicato nella Gazzetta Uffi-ciale della Repubblica italiana.

Roma, 29 gennaio 2019

p. Il direttore generale del Tesoro: IACOVONI

19A00765

DECRETO 29 gennaio 2019 .

Modifica degli allegati B e D al decreto 28 dicembre 2015, in materia di scambio automatico obbligatorio di informa-zioni nel settore fiscale.

IL DIRETTORE GENERALEDELLE FINANZE

E

IL DIRETTOREDELL’AGENZIA DELLE ENTRATE

Vista la legge 18 giugno 2015, n. 95, contenente di-sposizioni concernenti gli adempimenti delle istituzioni finanziarie italiane ai fini dell’attuazione dello scambio automatico di informazioni derivanti dall’Accordo tra il Governo della Repubblica italiana e il Governo degli Sta-ti Uniti d’America fatto a Roma il 10 gennaio 2014 e da accordi tra l’Italia e altri Stati esteri;

Visto il decreto del Ministro dell’economia e delle fi-nanze 28 dicembre 2015, pubblicato nella Gazzetta Uffi-ciale della Repubblica italiana 31 dicembre 2015, n. 303, recante l’attuazione della legge 18 giugno 2015, n. 95 e della direttiva 2014/107/UE del Consiglio, del 9 dicem-bre 2014, recante modifica della direttiva 2011/16/UE per quanto riguarda lo scambio automatico obbligatorio di informazioni nel settore fiscale;

Visto, in particolare, l’art. 4, comma 2, del predetto de-creto 28 dicembre 2015, che prevede che gli allegati al medesimo decreto possono essere modificati con provve-dimento del direttore generale delle finanze e del direttore dell’Agenzia delle entrate;

Vista la Convenzione OCSE – Consiglio d’Europa, recante la Convenzione multilaterale sulla reciproca as-sistenza amministrativa in materia fiscale, firmata a Stra-sburgo il 25 gennaio 1988, come modificata dal Protocol-lo del 27 maggio 2010;

Vista la legge 10 febbraio 2005, n. 19, recante l’ade-sione della Repubblica italiana alla Convenzione concer-nente la reciproca assistenza amministrativa in materia fiscale tra gli Stati membri del Consiglio d’Europa ed i Paesi membri dell’Organizzazione per la cooperazione e lo sviluppo economico – OCSE, con Allegati, fatta a Stra-sburgo il 25 gennaio 1988, e sua esecuzione;

Vista la legge 27 ottobre 2011, n. 193, recante la ra-tifica e l’esecuzione del Protocollo emendativo della Convenzione del 1988 tra gli Stati membri del Consiglio d’Europa ed i Paesi membri dell’Organizzazione per la cooperazione e lo sviluppo economico – OCSE, sulla re-ciproca assistenza amministrativa in materia fiscale, fatto a Parigi il 27 maggio 2010;

Visto l’Accordo multilaterale tra i Paesi membri dell’Organizzazione per la cooperazione e lo sviluppo economico in materia di scambio automatico di infor-mazioni su conti finanziari, per l’implementazione del nuovo standard unico globale per lo scambio automatico di informazioni ( Common reporting standard ), firmato a Berlino il 29 ottobre 2014, e successive sottoscrizioni;

Visto il decreto legislativo 30 luglio 1999, n. 300, re-cante la riforma dell’organizzazione del Governo, a nor-ma dell’art. 11 della legge 15 marzo 1997, n. 59, e succes-sive modificazioni;

Visto il decreto legislativo 3 luglio 2003, n. 173, concer-nente la riorganizzazione del Ministero dell’economia e delle finanze e delle agenzie fiscali, a norma dell’art. 1 del-la legge 6 luglio 2002, n. 137, e successive modificazioni;

Visto il decreto del Presidente del Consiglio dei mini-stri 27 febbraio 2013, n. 67, recante il regolamento di or-ganizzazione del Ministero dell’economia e delle finanze, a norma degli articoli 2, comma 10 -ter , e 23 -quinquies , del decreto-legge 6 luglio 2012, n. 95, convertito, con modificazioni, dalla legge 7 agosto 2012, n. 135, e suc-cessive modificazioni;

Visto il decreto del Ministro dell’economia e delle fi-nanze 17 luglio 2014, recante individuazione e attribu-zioni degli uffici di livello dirigenziale non generale dei Dipartimenti del Ministero dell’economia e delle finanze, in attuazione dell’art. 1, comma 2, del citato decreto del Presidente del Consiglio dei ministri n. 67 del 2013, e successive modificazioni;

— 21 —

GAZZETTA UFFICIALE DELLA REPUBBLICA ITALIANA Serie generale - n. 316-2-2019

Visto lo Statuto dell’Agenzia delle entrate, approvato con delibera del Comitato drettivo n. 6 del 13 dicembre 2000, pubblicato nella Gazzetta Ufficiale della Repubblica italiana 20 febbraio 2001, n. 42, e successive modificazioni;

Visto il Regolamento di amministrazione dell’Agenzia delle entrate, approvato con delibera del Comitato dretti-vo n. 4 del 30 novembre 2000, pubblicato nella Gazzet-ta Ufficiale della Repubblica italiana 13 febbraio 2001, n. 36, e successive modificazioni;

Visto il decreto del Ministro delle finanze 28 dicembre 2000, pubblicato nella Gazzetta Ufficiale della Repubblica italiana 12 febbraio 2001, n. 9, concernente disposizioni re-canti le modalità di avvio delle Agenzie fiscali e l’istituzio-ne del ruolo speciale provvisorio del personale dell’Ammi-nistrazione finanziaria, emanato a norma degli articoli 73 e 74 del decreto legislativo 30 luglio 1999, n. 300;

Decretano:

Art. 1.

Modifica dell’Allegato B

1. A decorrere dal 1° aprile 2019 le forme di previdenza complementare aperte, limitatamente alle adesioni indivi-duali, sono istituzioni finanziarie tenute alla comunicazio-ne e i piani pensionistici individuali sono conti oggetto di comunicazione. Di conseguenza, al decreto del Ministro dell’economia e delle finanze 28 dicembre 2015, l’Allegato B, recante l’elenco delle entità da trattare come istituzio-ni finanziarie non tenute alla comunicazione e dei conti da trattare come conti esclusi, è modificato nel modo seguente:

a) il punto 1 è sostituito dal seguente: «1. Elenco delle istituzioni finanziarie italiane non tenute alla comunicazione:

Cassa Depositi e Prestiti S.p.a.;

Enti di previdenza e sicurezza sociale privatizzati dal decreto legislativo 30 giugno 1994, n. 509, o istituiti ai sensi del decreto legislativo 10 febbraio 1996, n. 103 (Casse previdenziali);

Forme pensionistiche complementari istituite ai sensi del decreto legislativo 5 dicembre 2005, n. 252, ad esclusione dei fondi pensione aperti limitatamente alle adesioni individuali.»;

b) il punto 2 è sostituito dal seguente: «2. Elenco dei conti esclusi:

polizze collettive TFR a beneficio dei dipendenti calcolate su salari o stipendi e assoggettate a tassazione e contribuzione previdenziale.».

2. I piani pensionistici individuali in essere alla data del 31 marzo 2019 si considerano conti preesistenti e le procedure di adeguata verifica dei medesimi piani devono concludersi:

a) entro il 31 dicembre 2019, per i conti di importo rilevante;

b) entro il 31 dicembre 2020, per i conti di importo non rilevante.

Art. 2.

Modifica dell’Allegato D

1. Al decreto del Ministro dell’economia e delle finan-ze 28 dicembre 2015, l’Allegato D, recante l’elenco delle giurisdizioni partecipanti, è sostituito dal seguente:

N. Giurisdizioni

1 ALBANIA

2 ANDORRA

3 ANGUILLA

4 ANTIGUA E BARBUDA

5 ARABIA SAUDITA

6 ARGENTINA

7 ARUBA

8 AUSTRALIA

9 AUSTRIA

10 AZERBAIJAN

11 BARBADOS

12 BAHAMAS

13 BAHRAIN

14 BELGIO

15 BELIZE

16 BERMUDA

17 BONAIRE

18 BRASILE

19 BULGARIA

20 CANADA

21 CILE

22 CIPRO

23 COLOMBIA

24 COREA

25 COSTA RICA

26 CROAZIA

27 CURAÇAO

28 DANIMARCA

29 EMIRATI ARABI UNITI

30 ESTONIA

31 FEDERAZIONE RUSSA

32 FINLANDIA*

33 FRANCIA**

34 GERMANIA

35 GHANA

36 GIAPPONE

37 GIBILTERRA

— 22 —

GAZZETTA UFFICIALE DELLA REPUBBLICA ITALIANA Serie generale - n. 316-2-2019

38 GRECIA

39 GRENADA

40 GROENLANDIA

41 GUERNSEY

42 HONG KONG

43 INDIA

44 INDONESIA

45 IRLANDA

46 ISLANDA

47 ISOLA DI MAN

48 ISOLE CAYMAN

49 ISOLE COOK

50 ISOLE FAROE

51 ISOLE MARSHALL

52 ISOLE TURKS E CAICOS

53 ISOLE VERGINI BRITANNICHE

54 ISRAELE

55 JERSEY

56 KUWAIT

57 LETTONIA

58 LIBANO

59 LIECHTENSTEIN

60 LITUANIA

61 LUSSEMBURGO

62 MACAO

63 MALESIA

64 MALTA

65 MAURITIUS

66 MESSICO

67 MONACO

68 MONSERRAT

69 NAURU

70 NIGERIA

71 NIUE

72 NORVEGIA

73 NUOVA ZELANDA

74 PAESI BASSI

75 PAKISTAN

76 PANAMA

77 POLONIA

78 PORTOGALLO***

79 QATAR

80 REGNO UNITO

81 REPUBBLICA CECA

82 REPUBBLICA POPOLARE CINESE

83 REPUBBLICA SLOVACCA

84 ROMANIA

85 SABA

86 SAINT KITTS E NEVIS

87 SAINT LUCIA

88 SAINT VINCENT E GRENADINES

89 SAMOA

90 SAN MARINO

91 SEYCHELLES

92 SINGAPORE

93 SINT EUSTATIUS

94 SINT MAARTEN

95 SLOVENIA

96 SPAGNA****

97 SUDAFRICA

98 SVEZIA

99 SVIZZERA

100 TURCHIA

101 UNGHERIA

102 URUGUAY

103 VANUATU

* Include: Isole Åland.

** Include: Guadalupa, Guyana francese, Martinica, Riunione, Saint Martin e Mayotte, Saint Barthélemy.

*** Include: Azzorre e Madera.

**** Include: Isole Canarie.

Il presente provvedimento sarà pubblicato nella Gaz-zetta Ufficiale della Repubblica italiana.

Roma, 29 gennaio 2019

Il direttore generaledelle finanze LAPECORELLA

Il direttoredell’Agenzia delle entrate

MAGGIORE

19A00774

From: Stefan Plat <splat@impuesto.aw> On Behalf Of Automatische Gegevensuitwisseling

Subject: CRS planning Belastingjaar 2018

Geachte relatie,

Via deze e-mail ontvangt u, vanuit DIMP, de planning van het Common Reporting Standard (CRS) voor het Belastingjaar 2018.

Zoals uit onderstaande planning kan worden afgeleid, dient de Financiële Instelling (FI) uiterlijk voor dinsdag 30 april 2019 17:00 uur de leveringen aan DIMP te hebben voldaan.Het gehele proces van eventuele correctieleveringen dient te zijn afgerond voor maandag 30 september 2019 17:00 uur.

Datum Planning

Vanaf maandag 18 maart 2019 FI’s kunnen hun account en EOI-relatie aanmaken/actualiseren.

Maandag 1 april 2019 – vrijdag 12april 2019

Testperiode voor FI’s om door middel van een testbericht met testdatavoor het nieuwe belastingjaar te controleren, of eigen berichten of invoer,de validatie van het XLM-bericht en de controle bij ontvangst doorstaan.

Vanaf maandag 15 april 2019 08:00uur

CRS ‘goes live’; MDES wordt vrijgegeven voor het leveren van XML-files ofhet handmatig invoeren (let op na deze datum kunnen FI’s niet meer zelf relaties aanmaken).

Dinsdag 30 april 2019 17:00 uur Deadline voor het inwinnen van leveringen door DIMP m.a.w. indien eenFI, na deze datum en tijdstip alsnog gegevens levert aan DIMP, is de FInon-compliant (MDES blijft open na sluitingsdatum).

Vrijdag 28 juni 2019 DIMP verstuurt de leveringen aan MCAA-landen.

Maandag 1 juli 2019 – maandag 30september 2019 17:00 uur

FI’s ontvangen notificaties met betrekking tot eventuele fouten in deleveringen en dienen correcties terug te zenden naar DIMP.

Mocht u vragen hebben naar aanleiding van bovenstaande, dan kunt u altijd een e-mail sturennaar agu@impuesto.aw.Hopende u hiermee voldoende te hebben geïnformeerd.

Met vriendelijke groet,

Automatische Gegevensuitwisseling

Camacuri 2Oranjestad, Aruba

Tel: (+297) 522-7423Fax: (+297) 522-7429Website: www.impuesto.aw

Departamento di Impuesto hanteert gebruikersvoorwaarden voor het gebruik van e-mail. U vindt deze opwww.impuesto.aw.

,

Handleiding Automatic

Exchange of Information

CRS - Common Reporting

Standard

Met ingang van 1 januari 2019 wordt voor

de levering voor alle belastingjaren het

actuele XML-berichtschema FATCA CRS

versie 2.2 gebruikt

Versie 2.1

aruba

C

R

S

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 2

1. INLEIDING ..................................................................................................................................................... 4

1.1 GEGEVENSLEVERINGEN ........................................................................................................................................ 4

1.2. HANDLEIDING EN XML BERICHTSCHEMA ................................................................................................................ 6

2. FISCAAL-JURIDISCH ....................................................................................................................................... 7

2.1 WETGEVING ...................................................................................................................................................... 7

2.2. VERDRAG ......................................................................................................................................................... 7

4. DUE DILIGENCE PROCEDURES BIJ FINANCIËLE INSTELLINGEN EN JAARLIJKS LEVEREN VAN GEGEVENS ......... 8

4.1. JURISDICTION OF RESIDENCE T.B.V. CRS-LEVERINGEN AAN MCAA-LANDEN .................................................................. 8

4.3. JAARLIJKS TE LEVEREN FINANCIËLE GEGEVENS .......................................................................................................... 8

4.4. TYPE ACCOUNTHOLDERS ..................................................................................................................................... 8

5. LEVEREN EN VERSTREKKEN (GECORRIGEERDE) GEGEVENS + VERWERKEN NOTIFICATIES ............................ 9

5.1. PROCES VAN LEVEREN EN VERSTREKKEN + NOTIFICATIES VERWERKEN EN CORRIGEREN ..................................................... 9

5.2. LOGISTIEK EN MDES ALS ONDERSTEUNING VOOR FINANCIËLE INSTELLINGEN EN DIMP ................................................. 12

5.3. MDES OPENGESTELD VOOR HET TESTEN VAN HET LEVEREN VAN GEGEVENS ................................................................ 12

5.4. IDENTIFICATIE VAN BERICHTEN EN DELEN ERVAN – VERWIJZING BIJ CORRECTIE NAAR ORIGINEEL ....................................... 12

6. BERICHTOPBOUW VOOR INTERNATIONALE GEGEVENSLEVERING CRS ....................................................... 15

BEPAALDE GEGEVENSGROEPEN ALLEEN VOOR FATCA EN ANDERE ALLEEN VOOR CRS .......................................................... 15

6.1. BERICHTSOORT EN VERSIE GEGEVENSLEVERING ...................................................................................................... 17

6.2. MESSAGEHEADER (LOGISTIEKE GEGEVENS VAN HET BERICHT) ................................................................................... 18

6.3. MESSAGEBODY ............................................................................................................................................... 21

7. NOTIFICATIES OP GEGEVENSNIVEAU ONTVANGEN VAN MCAA-LANDEN ................................................... 63

BIJLAGE 1: BEGRIPPEN EN DEFINITIES............................................................................................................. 64

BIJLAGE 2: MOGELIJKE TEKENS IN XSD:STRING ELEMENTEN = UTF-8 EXCLUSIEF ACHT TEKENS ..................... 66

BIJLAGE 3: FATCA CRS XML BERICHTSCHEMA VERSIE 2.0 ............................................................................... 67

BIJLAGE 4: FOUTMELDINGEN (NOTIFICATIES) OP GEGEVENSNIVEAU VANUIT MCAA-LANDEN ....................... 68

BIJLAGE 5: CONTROLES EN FOUTMELDINGEN GEGEVENSLEVERING AAN DIMP .............................................. 70

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 3

Versiebeheer

versie Datum Wijzigingen

2.0 definitief

01-01-2018 1e definitieve versie van de “handleiding internationale gegevenslevering FATCA CRS”. Deze handleiding is vanaf 1-1-2018 van kracht voor de CRS-leveringen voor belastingjaar 2017 en volgende belastingjaren met bijbehorend FATCA CRS XML-berichtschema versie 2.0.

2.1 27-02-2018 Interne aantekeningen DIMP

2.2 22-01-2019 In de inleiding van 6.3.2.3.2 AccountReport - Accountholder is aangegeven hoe te handelen bij een Undocumented Account bij adresgegevens voor Accountholder individual en Accountholder organisation (is ook bij de velden AddressType, CountryCode en AddressFree in de toelichting opgenomen).

Controle 65 stelt zeker dat een FI voor een Accountholder Organisation van het soort “Passive Non-Financial Entity with one or more controlling persons that is a Reportable Person” (i.e. CRS101 in AcctHolderTypeCRS)” verplicht is om Controlling Persons mee te leveren.

Controle 66 beperkt zich tot Accountholders individuals geeft aan dat een ResCountryCode van een ControllingPerson altijd een van de ResCountryCodes bij de Accountholder Individual zelf moet zijn. Er is een nieuwe controle 122 toegevoegd waarin voor Accountholder organisation met AcctHolderTypeCRS = CRS101 is aangegeven dat een ResCountryCode van een ControllingPerson de landcode van een MCAA-land moet zijn waarmee CRS-gegevens worden uitgewisseld en dat het niet ‘US’ mag zijn.

Bij AcctHolderTypeCRS in paragraaf 6.3.2.3.2.2 is toegevoegd dat in geval van code CRS101 het verplicht is om Controlling Person(s) mee te leveren voor deze Accountholder Organisation. Ook is opgenomen dat ControllingPerson(s) leveren bij AcctHolderTypeCRS = CRS102 of CRS103 niet is toegestaan.

Vanwege wijzigingen in de wijze van corrigeren en aanvulllen (zie paragraaf 5.4) zijn de controle 12 en 13 verwijderd, zijn de controle 108 en controle 110 aangepast en is controle 121 toegevoegd. Controle 70 is komen te vervallen omdat controle 95, 96, 112, 113, 119 en 120 de controle beter en compleet uitvoeren.

In de inleiding van paragraaf 6.3.2.3.4 is tekst toegevoegd met uitleg over gebruik van ResCountryCodes bij ControllingPersons. Eenzelfde uitleg is ook toegevoegd in de tabel in die paragraaf met uitleg over de te leveren ResCountryCode(s).

In bijlage 4 is bij 800746 en 800747 Controlling Person Type vervangen door Controlling Person. Controles 106 en 107 in bijlage 5 zijn overeenkomstig gewijzigd.

Voor leeglevering is controle 122 toegevoegd om zeker te zijn dat geen AccountReport(s) worden geleverd.

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 4

1. Inleiding

Internationale gegevenslevering door financiële instellingen

Deze handleiding is bestemd voor financiële instellingen die gegevens leveren aan het Departamento di

Impesto Aruba (hierna DIMP genoemd) in het kader van internationale gegevensuitwisseling CRS.

Het bijbehorende XML-schema is al voorbereid op een levering voor Fatca en CRS. Echter, Aruba heeft geen

overeenkomst gesloten met de Internal Revenue Service en daarom moeten financiële Instellingen in Aruba

direct informatie verstrekken aan de Verenigde Staten. De handleiding en XML-schema worden daarom alleen

gebruikt voor leveringen in het kader van CRS.

De gegevenslevering betreft:

Financiële gegevens in het kader van de Multilateral Competent Authority Agreement on Automatic

Exchange of Financial Account Infomation (MCAA), de Common Reporting Standard (CRS) op basis van

jurisdiction of residence in MCAA-landen

De handleiding (versie 2.0) is bestemd voor levering voor belastingjaar 2017 en volgende belastingjaren.

Onderstaande gegevens moeten door financiële Instellingen worden geleverd aan DIMP?

• naam

• adres

• geboortedatum en –plaats

• fiscaal woonland of vestigingsland

• het fiscale identificatienummer

Daarnaast geeft de financiële instelling onder meer de volgende financiële gegevens door:

• het rekeningnummer of polisnummer (bij verzekeringen)

• het saldo of de waarde van de rekening

• de rente- en dividendinkomsten

• de waarden van kapitaal- en lijfrenteverzekeringen

• de opbrengsten van verkoop van financiële producten zoals effecten

Per account worden financiële gegevens éénmaal geleverd en bij AccountHolder moet worden aangegeven

voor welke landen de financiële gegevens bestemd zijn. Dat gebeurt bij AccountHolder via het gegeven

ResCountryCode, dat 1 of meer keer voorkomt, en eveneens bij AccountHolder via de combinatie TIN en

TIN@IssuedBy.

Financiële Instellingen (FI) leveren gegevens aan DIMP en geven bij accountholders via ResCountryCode aan

voor welk(e) land(en) de gegevens bestemd zijn. DIMP verstrekt gegevens over personen met een MCAA-land

als jurisdiction of residence aan het betreffende MCAAland voor de CRS https://www.oecd.org/ctp/exchange-

of-tax-information/MCAA-Signatories.pdf.

Multi Data Exchange solution (MDES) van DIMP ondersteunt de internationale gegevensuitwisseling voor CRS.

Financiële Instellingen en DIMP zijn gebruikers van MDES.

1.1 Gegevensleveringen

Ondersteuning bij Internationale Gegevensuitwisseling voor FI’s en Sponsoren in Aruba

Op de DIMP website http://www.impuesto.aw/Admin/CommonReportingStandard/tabid/914/Default.aspx is informatie te vinden voor FI’s en Sponsoren die gegevens t.b.v. de FATCA en de CRS dienen te leveren aan de Dimp.

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 5

Gegevensleveringen door vestigingen van FI’s in een ander land

Gegevenslevering in het kader van FATCA CRS door vestigingen van financiële instellingen in andere landen gebeurt conform het proces en afspraken van het land waar de vestiging is gehuisvest. Leveringen van gegevens t.b.v. MCAA-landen starten als het land van vestiging start met uitwisseling en ontvangst in het kader van de CRS; voor Aruba is dat belastingjaar 2017. FATCA/CRS-afspraken voor levering van gegevens In het kader van CRS moeten de afgesproken financiële gegevens vanuit de jurisdictie (in dit geval Aruba) geleverd worden. Daarom levert een financiële instelling voor zijn in Aruba gevestigde ReportingFI’s gegevens aan DIMP. DIMP selecteert en verstrekt de gegevens aan MCAA-landen.

Figuur 1 laat zien hoe CRS verwacht dat financiële instellingen met vestigingen in verschillende landen aan een MCAA-land gegevens verstrekken.

Entity A levert aan DIMP voor zichzelf en voor Branch A1 maar niet voor Branch A2, Branch B1 levert zelfstandig aan DIMP, Branch A2 levert zelfstandig vanuit het land van vestiging, in dit geval niet Aruba, Entity B levert in haar vestigingsland voor zichzelf en voor Branch B2 en niet voor Branch B1. Branch A2 moet uit haar vestigingsland leveren voor CRS. Branch B1, een in Aruba gevestigde buitenlandse vestiging van Entity B, levert de gegevens zelf aan DIMP. Het moederbedrijf Entity B levert vanuit een ander land voor zichzelf en Branch B2.

Figuur 1: voor welke ReportingFI’s moet in Aruba worden geleverd t.b.v. verstrekking aan MCAA-landen

Registratie in de Portal MDES

Voor de gegevenslevering gebruikt DIMP het webportal portal MDESDIMP. Om CRS gegevens te leveren aan DIMP melden Financiële Instellingen zich aan als gebruiker van MDES. Let op: de FI is zelf verantwoordelijk voor het beheer en onderhoud van de registratiegegevens en dient zelf te zorgen voor een back-up van de login gegevens. Indien de FI niet meer over de login gegevens van de gebruiker beschikt, dient contact te worden opgenomen met DIMP om de gebruiker te laten verwijderen en een nieuwe gebruiker aan te maken.

Entity A

Branch A1 Branch A2

Entity B

Branch B1 Branch B2

participating

Jurisdiction A

1

2

1

Entity A + Branch A1

en Branch B1 zijn

ReportingFI’s in Jurisdiction A

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 6

De Financiële Instelling meldt zich via MDES aan. Een nieuw gebruikersaccount aanvragen doet u als volgt: 1. Kies voor de taak 'Account aanvragen' op de homepagina; 2. Voer de gevraagde gegevens in, upload de juiste documenten (pdf, doc, docx, png, jpg, jpeg, bmp;

maximaal 10MB per bestand); 3. Kies voor 'Afronden'; 4. U ontvangt een e-mail bericht om uw aanvraag te bevestigen; 5. Klik op de link in de e-mail waarmee het activeringsscherm geopend wordt; 6. Controleer uw gegevens; 7. Kies voor 'Afronden'. In het geval de aanvraag wordt afgewezen ontvangt u in een e-mail de instructies van DIMP.

Gegevens Indienen (via XML-berichten) – zie gebruikershandleiding MDES

Nadat uw bestand is gecontroleerd (XSD-controles en controles bij ontvangst in de MDES uit bijlage 5) en

is ingelezen, dan moet de betreffende levering bij DIMP worden ingediend. Dit doet u door:

kies het betreffende dossier in het FATCA/CRS overzicht in de Uploads tab om deze te openen en daarna

de taak “Indienen” te kiezen

en het indienen te bevestigen.

Na het afronden van deze taak hebt u uw levering bij DIMP ingediend en ontvangt u hiervan per e‐mail een bevestiging. Handmatige invoer in portal MDES (om gegevens in te dienen)

Naast het XML-bericht (t.b.v. bulk) kent de MDES ook de mogelijkheid voor handmatig scherminvoer.

DIMP verzamelt de gegevens en verstrekt de CRS-gegevens aan de MCAA-landen. De ResCountryCode bij

accountholder is bepalend voor de selectie t.b.v. verstrekking aan MCAA-landen. In de verstrekking aan de

landen is bij een Accountholder alleen de ResCountryCode van het betreffende land opgenomen.

NB. Als een ReportingFI geen enkele accountholder met een jurisdiction of residence heeft in een of meer MCAA-landen

moet door de FI een GEEN-levering voor dat belastingjaar worden ingediend.

Notificaties vanuit MCAA-landen

Als DIMP de gegevens heeft verstrekt aan MCAA-landen, dan kunnen vanuit deze landen notificaties op gegevensniveau terugkomen (zie bijlage 4). Deze worden in MDES beschikbaar gesteld en kunnen aanleiding zijn voor een correctie levering door de financiële instelling.

Due Diligence procedure bij financiële instellingen

Om te bepalen waarover gerapporteerd moet worden is het noodzakelijk dat Financiële Instellingen volgens de due diligence procedures bepalen of over een account gerapporteerd (reportable accounts) moet worden. Voor de CRS moet bepaald worden in welk(e) land(en) een accountholder zijn jurisdiction of residence heeft (zie ook hoofdstuk 4 van de handleiding).

1.2. Handleiding en XML berichtschema

Handleiding en XML berichtschema zijn:

Handleiding Internationale Gegevensuitwisseling CRS versie 2.2 en

XML berichtschema FATCA CRS versie 2.1. De handleiding dient door financiële instellingen gehanteerd te worden voor gegevensleveringen of –invoer voor belastingjaar 2018 DIMP voor CRS-gegevens.

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 7

2. Fiscaal-Juridisch

2.1 Wetgeving

De Landsverordening en verdragen voor internationale gegevensuitwisseling zijn te vinden op de website van

de Departamento di Impuesto. Op grond van de Landsverordening Internationale Bijstandsverlening bij de

heffing van Belastingen (LIBB) moeten de Financiële Instellingen (administratieplichtigen) op eigen initiatief de

aangewezen gegevens voor de aangewezen personen aan DIMP leveren. De LIBB is in werking getreden op 22

december 2017.

2.2. Verdrag

CRS

Voor de wederzijdse uitwisseling van gegevens met betrekking tot de CRS heeft de Minister van Financiën op

29 oktober 2014 de Multilateral Competent Authority Agreement on Automatic Exchange of Financial Account

Infomation (MCAA) ondertekend. Voor definties en te leveren gegevens wordt verwezen naar:

http://www.oecd.org/tax/automatic-exchange/international-framework-for-the-crs/multilateral-competent-

authority-agreement.pdf. In de MCAA staat beschreven welke gegevens voor een accountholder met

jurisdiction of residence in een MCAA-land moet worden geleverd. In de paragrafen 6.3.2.3.5 (accountbalance)

en 6.3.2.3.6 (payments) is dat ook aangegeven.

De Minister van Financiën heeft in afstemming met de OECD besloten om de internationale

gegevensuitwisseling in het kader van de CRS in te laten gaan vanaf belastingjaar 2017.

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 8

4. Due Diligence procedures bij financiële instellingen en jaarlijks leveren van gegevens

Van Financiële instellingen wordt verwacht dat zij uit hun administratie voor alle personen met een

jurisdiction(s) of residence in (een) MCAA-land(en), gegevens over accounts van die personen (accountholder

individual en accountholder organisation) leveren aan DIMP. DIMP zorgt vervolgens voor de verstrekking van

gegevens van personen met een jurisdiction of residence in een MCAA-land aan betreffend MCAA-land (CRS).

4.1. Jurisdiction of residence t.b.v. CRS-leveringen aan MCAA-landen

In deel II van http://www.oecd.org/tax/automatic-exchange/common-reporting-standard/common-reporting-

standard-and-related-commentaries/ staat in onderdeel A beschreven voor welke accountholders in het kader

van de CRS moet worden geleverd. Jurisdiction of residence van een accountholder is daarbij bepalend. Een

accountholder kan meerdere jurisdiction(s) of residence hebben. Daar staat ook welke gegevens voor die

accountholders geleverd moeten. Vereisten voor vastleggen van jurisdiction of residence - de due diligence

procedures – staan in deel II onderdeel B.

4.3. Jaarlijks te leveren financiële gegevens

Financiële instellingen in Aruba zullen, voor CRS-leveringen, zeker gesteld moeten hebben dat ieder jaar de

vereiste selectie van de gegevens geleverd kan worden. Om de financiële gegevens te kunnen leveren zullen de

Financiële Instellingen elk kalenderjaar gegevens op jaarbasis èn gegevens per peildatum laatste dag van het

kalenderjaar vastgelegd moeten hebben of afgeleid kunnen worden uit de vastlegging. De te leveren CRS-

gegevens staan in section 1 en 2 van de MCAA.

NB: financiële instellingen leveren per account en bij accountholder is via ResCountryCode aangegeven voor welke MCAA-

landen de accountgegevens bestemd zijn.

4.4. Type accountholders

CRS onderkent andere type accountholders in geval van een organisation als accountholder (zie paragraaf

6.3.2.3.2.2):

als voor accountholder organisation geldt dat een of meer MCAA-landen zijn/haar jurisdiction of residence

is, dan moet CRS-type accountholder worden geleverd.

Is een accountholder organisation een US-person en heeft hij een jurisdiction of residence in een MCAA-

land, dan moet het FATCA-type accountholder niet worden geleverd maar het CRS-type accountholder wel

worden geleverd.

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 9

5. Leveren en verstrekken (gecorrigeerde) gegevens + Verwerken notificaties

Dit hoofdstuk beschrijft het proces voor leveren van financiële gegevens door financiële instellingen (FI’s) en

het verstrekken door DIMP aan de MCAA-landen (CRS) op basis van de leveringen van FI’s voor ReportingFI’s.

5.1. Proces van leveren en verstrekken + notificaties verwerken en corrigeren

Voor gegevenslevering door FI’s over 2018 wordt gebruik gemaakt van het FATCA CRS XML-berichtschema

versie 2.1, een gecombineerde XML-bericht om via één bericht financiële gegevens te leveren aan DIMP. MDES

zorgt er vervolgens voor dat uit het gecombineerde bericht gegevens geselecteerd worden om te verstrekken

aan MCAA-landen.

Berichten kennen XSD-controles en bij ontvangst voert de MDES een aantal controles uit (zie bijlage 5). Als de

gegevens handmatig in de MDES worden ingevoerd dan worden overeenkomstige controles uitgevoerd.

Figuur 2 Leveren door FI’s – Verstrekken aan MCAA-landen - Notificaties en Correcties

Leveren van gegevens door Financiële Instellingen aan DIMP Financiële instellingen leveren voor gegevens over accounts en bij accountholder geven zij via ResCountryCode aan voor welke landen de gegevens bestemd zijn. Vanaf belastingjaar 2017 wordt geleverd voor accountholders met een jurisdiction of residence in een MCAA-land (CRS). Volledigheid is gewaarborgd door de afspraak dat financiële instellingen ook voor Reporting FI’s zonder data een bericht sturen naar DIMP. Dat bericht heeft in de MessageHeader een MessageTypeIndic = CRS703 en heeft in de ReportingGroup een NilReport. Verstrekken van gegevens door DIMP aan MCAA-landen DIMP verzamelt alle gegevens van alle financiële instellingen en checkt of zij van alle Reporting FI’s weet welke gegevens doorgeleverd moeten worden c.q. dat een Reporting FI geen gegevens behoeft te leveren. Daarna verstrekt DIMP gegevens. Gegegevens worden verstrekt over personen met het betreffende MCAA-land als jurisdictie of residence

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 10

(alleen ResCountryCode=’MCAA-land’ en TIN met TIN@IssuedBy=’MCAA-land’ wordt verstrekt). Als één ReportingFI gegevens aan een MCAA-land verstrekt, dan ontvangt dat betreffende MCAA-land leegleveringen de ReportingFI’s die geen gegevens verstrekken aan dat MCAA-land. Verwerken Notificaties van MCAA-landen door DIMP en FI’s Als gegevens niet correct zijn, sturen MCAA-landen een notificatie naar DIMP. Notificaties op berichtniveau handelt DIMP zelf af. MDES sorteert notificaties naar Reporting FI op gegevensniveau en verstuurt een attenderings e-mail naar de FI , die de gegevens namens de Reporting FI leverde aan DIMP. In MDES zijn de notificaties op gegevensniveau voor de betreffende FI beschikbaar voor inzage. In bijlage 4 is een overzicht met foutcodes (notificaties) opgenomen. NB: Notificaties kunnen jaren na dato binnenkomen en hebben dan betrekking op oude jaren. Financiële instelling en DIMP (d.m.v. MDES) moeten in staat zijn om voor die oude jaren de notificatie te verwerken en moeten in staat zijn, als dat nodig is, om een correctiebericht voor dat oude jaar te leveren en te verstrekken aan MCAA-landen.

Leveren van correcties door FI’s aan DIMP Als bij beoordeling van de notificaties blijkt, dat correcties moeten worden geleverd, dan levert de financiële instelling een correctielevering met de juiste gegevens en verwijzingen naar het oorspronkelijke bericht (CorMessageRefId) en - voor het deel van het bericht dat gewijzigd is - een verwijzing naar het deel in het oorspronkelijke bericht dat gewijzigd is (CorrDocRefId). Verstrekken van correcties door DIMP MCAA-landen Vervolgens verzamelt DIMP alle correcties en verstrekt de correcties aan de MCAA-landen. Hierbij hanteert

DIMP het principe van geen correctie op correctie in één bericht.

In tabel 1 is de planning van gegevensuitwisseling opgenomen. Elk jaar vindt over het voorgaande belastingjaar

internationale gegevensuitwisseling plaats in het 1e halfjaar. Het moment van leveren van gegevens door

financiële instellingen aan DIMP vindt in principe plaats voor 30 april. Het verstrekken van de gegevens door

DIMP MCAA-landen moet afgerond zijn binnen 9 maanden na afloop van het kalenderjaar.

Processtappen/activiteiten voor uitwisseling gegevens door wanneer

Publiceren van de handleiding Financiële Instellingen en de gebruikershandleiding MDES op de

website

DIMP Week 5

De financiële instellingen worden geïnformeerd over de openstelling van de MDES voor het

testen van gegevensleveringen

DIMP Week 5

Indien nodig en naar gelang behoefte van FI’s het organiseren van een informatiebijeenkomst

FI’s en (kleine)Trust maatschappijen om FI’s bij te praten over wijzigingen.

DIMP week 11

Testperiode voor financiële instellingen om door middel van testbericht met testdata voor het

nieuwe belastingjaar te controlen of eigen berichten of invoer de validatie van het XLM-bericht

en de controle bij ontvangst doorstaan

FI vanaf week 13

Vastleggen in MDES dat een FI geen accountholders heeft die een MCAA-land als jurisdiction of

residence heeft

FI week 15

Vrijgeven MDES voor LEVEREN van gegevens Week 16

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 11

Leveren gegevens door financiële instellingen + verstrekken door DIMP aan MCAA-landen

Inwinnen van leveringen van FI’s en controle op XML berichtschema + alerts en notificaties in de

vorm van foutmeldingen over de leveringen aan de FI’s beschikbaar stellen

DIMP week 18

deadline

30 april

Kennis nemen van alerts en notificaties en beoordelen + zo nodig een correctielevering doen FI week 16-18

Controleren op en rappelleren over volledigheid van levering door alle FI’s (gegevens zijn

geleverd of er is een ‘leeg levering’ voor FI)

DIMP week 19

Als onvolledigheid is geconstateerd, dan zullen desbetreffende FI’s en DIMP de stappen voor

opnieuw leveren en ontvangen doorlopen.

FI’s + DIMP Week 20

Selecteren, verzamelen financiële gegevens per MCAA-land en verstrekken aan MCAA-landen DIMP week 26

deadline 30 juni

Inwinnen gegevens, beoordelen en alerts en notificaties terug zenden aan DIMP MCAA-

landen

week 26-39

Ontvangen en verwerken van alerts en notificaties van MCAA-landen:

- Notificaties op berichtniveau handelt DIMP zelf af

- Notificaties op gegevensniveau voor REPORTING FI’s stelt DIMP beschikbaar aan de FI die de Reporting FI-gegevens leverde

DIMP week 26-39

Verwerken notificaties op gegevensgroep niveau FFI’s en leveren van correcties aan DIMP FI/sponsor

(+Reporting

FI)

week 35-39

Inwinnen van correctieleveringen van FI’s en controleren op XML-bericht-schema + alerts en

notificaties in de vorm van foutmeldingen over correctieleveringen aan FI’s en beschikbaar

stellen

DIMP Week 35-39

Verwerken notificaties op gegevensgroep niveau Reporting FI’s en leveren van correcties aan

DIMP

FI/Sponsor

(+Reporting

FI)

week 35-39

Inwinnen van 2e correctieleveringen van FI’s (compleet en correct) DIMP week 35-39

Controleren op en rappelleren over volledigheid van correctielevering door alle FI’s voor alle

Reporting FI’s (op te vatten als opvolging van notificaties)

DIMP week 35-39

Als onvolledigheid is geconstateerd, dan zullen betreffende FI’s en DIMP de stappen voor

opnieuw leveren en ontvangen doorlopen.

FI’s/sponsor

+ DIMP

week 35-39

Selecteren en verzamelen van gecorrigeerde gegevens per MCAA-land en verstrekken aan

MCAA-landen

DIMP week 35-39

Vaststellen dat verwerking van selecteren en verzamelen correcties goed is verlopen.

Datapreparatie uitvoeren en verstrekken van de financiële gegevens aan elk MCAA-land

DIMP week 35-39

deadline

30 september

tabel 1: planning international gegevensuitwisseling t.b.v. CRS

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 12

5.2. Logistiek en MDES als ondersteuning voor financiële instellingen en DIMP

MDES ondersteunt het:

leveren via FATCA CRS XML berichten c.q. handmatig invoeren in MDES van afgesproken financiële gegevens door financiële instellingen aan DIMP;

verstrekken door DIMP van door FI geleverde financiële gegevens aan MCAA-landen;

verwerken van notificatie over verstrekte gegevens van MCAA-landen aan DIMP en het attenderen en beschikbaar stellen van notificaties aan FI’s;

ontvangen van afgesproken financiële gegevens vanuit MCAA-landen over accountholders met Aruba als jurisdiction of residence t.b.v. de heffing en toezicht door DIMP;

geven van notificaties aan MCAA-landen door DIMP.

5.2.2. Financiële instellingen leveren gegevens aan DIMP via MDES

De financiële instelling kan in MDES gegevenslevering(en) aanbieden en later eventuele correcties daarop aanbieden. In de schermvoering bij het aanbieden vindt bevestiging van het aanbieden als zodanig plaats. Als de gegevens zijn beoordeeld, ontvangt de financiële instelling een e-mail (alert) dat het verwerkingsrapport beschikbaar is gesteld op MDES. In het verwerkingsverslag is weergegeven dat de gegevenslevering voldeed aan het FATCA CRS XML berichtschema versie 2.1.

5.2.3. Financiële instellingen ontvangen notificaties van DIMP via MDES

De MCAA-landen sturen e-mails (alerts) terug om de ontvangst en de verwerking te bevestigen. Als er notificaties (fouten in de levering) binnen komen bij DIMP dan stelt de MDES de notificaties op gegevensniveau beschikbaar voor elke financiële instelling die gegevens met fouten leverde. Via een e-mail (alert) worden financiële instellingen erop geattendeerd dat er notificaties klaar staan in MDES.

5.3. MDES opengesteld voor het testen van het leveren van gegevens

MDES voorziet jaarlijks in een testservice voor financiële instellingen om de levering van financiële gegevens te kunnen testen tegen het XML berichtschema en tegen de controles bij ontvangst in de MDES. In de periode van 1 januari tot het moment van openstelling is de MDES niet beschikbaar voor gebruik. In de periode openstelling tot vrijgave MDES is:

het testen van berichten mogelijk voor ALLE belastingjaren (met in DocRef alleen DocIndicType = OECD11, OECD12 of OECD13); de FI geeft aan dat het gaat om testgegevens!

geen levering van productiegegevens mogelijk voor ALLE belastingjaren (berichten met een of meer DocRef met DocIndicType = OECD1, OECD2 of OECD3 worden afgekeurd)

In de periode na vrijgave en tot aan het dichtzetten op 1-1 van het volgende kalenderjaar, is:

levering van productiegegevens mogelijk voor ALLE belastingjaren (alleen berichten met DocRef met DocIndicType = OECD1, OECD2 of OECD3 worden goedgekeurd)

geen levering van testgegevens mogelijk voor ALLE belastingjaren (berichten met een of meer DocRef met DocIndicType = OECD11, OECD12 of OECD13 worden afgekeurd)

Voor de werkwijze van de testservice wordt verwezen naar de gebruikershandleiding MDES op de website Dimp.

5.4. Identificatie van berichten en delen ervan – verwijzing bij correctie naar origineel

Het FATCA CRS XML-bericht kent in de Messageheader elementen om het bericht als zodanig te identificeren maar ook verwijzigingen naar het bericht dat gecorrigeerd wordt (correcties kunnen andere gegevens zijn maar ook een leeglevering in plaats van levering van gegevens):

MessageRefId is de identificatie van het bericht zelf,

CorrMessageRefId verwijst naar het MessageRefId bericht, waarvan gegevens gecorrigeerd, verwijderd of gewijzigd worden.

Verder heeft het FATCA CRS XML-bericht voor verschillende onderdelen van het bericht eenzelfde mechanisme van identificatie. Dat gaat via de gegevensgroep DocSpec. In DocSpec zijn de volgende elementen aanwezig:

DocRefId als identificatie van de gegevensgroep binnen het bericht zelf

CorrDocRefId als verwijzing naar de identificatie van de overeenkomstige gegevensgroep, die gecorrigeerd of gewijzigd wordt.

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 13

In het FATCA CRS XML bericht kunnen de gegevensgroepen ReportingFI en AccountReport met het DocSpec-mechanisme afzonderlijk worden gecorrigeerd of verwijderd. Als (een) element(en) in een gegevensgroep gecorrigeerd worden, dan wordt de complete gegevensgroep in het correctiebericht opgenomen. Dus het mechanisme van vervanging van de gegevensgroep als geheel wordt gehanteerd.

Berichten van financiële instellingen aan DIMP, waarmee gegevens worden geleverd Voor deze berichten geven financiële instelling unieke identificaties aan het bericht (MessageRefId en dus ook CorrMessageRefId) en aan gegevensgroepen in het bericht (DocRefID en dus ook CorrDocRefId). De (Corr)MessageRefId en de (Corr)DocRefId in deze berichten moeten beginnen met de 2 letterige landcode volgens ISO 3166-1 gevolgd door het belastingjaar (JJJJ) waarvoor de gegevens in het bericht gelden. Voor belastingjaar 2017 de eerste zes karakters van zowel (Corr)MessageRefId als (Corr)DocRefId gelijk aan ‘AW AW2017’gevolgd door de persoons persoons-nummer van de leverende financiële instelling. Deze berichten worden aan DIMP geleverd door een financiële instelling (persoonsnummer in element SendingCompanyIN in de Messageheader van het bericht) en bevatten alle financiële gegevens voor de ReportingFI, die tot die financiële instelling behoren. Op berichtniveau kent het FATCA CRS XML berichtschema een soortaanduiding MessageTypeIndic, waarmee wordt aangegeven of het betreffende bericht alleen nieuwe gegevens bevat (CRS701) of alleen gecorrigeerde, verwijderde of gewijzigde gegevens bevat (CRS702) of ReportingFI’s bevat waarvoor geen leveringen worden gedaan (CRS703), de zogenaamde leeg-levering. In uitzonderlijke gevallen kan een volledig bericht verwijderd worden. Dit wordt alleen gebruikt als er een grote fout is opgetreden voorafgaand of tijdens de levering c.q. verstrekking van het bericht (een damage bijvoorbeeld). In dat geval wordt een bericht gestuurd met als CorrMessageRefId de identificatie van het te verwijderen bericht en is MessageTypeIndic ==CRS702 (beide in de Messageheader). In alle DocSpec gegevensgroepen is DocTypeIndic = OECD3 (of OECD13 in geval van een testlevering). Het correctiebericht waarmee een voorgaand bericht wordt verwijderd, wordt altijd gevolgd door een nieuw bericht met MessageTypeIndic = CRS701 en in alle DocSpec gegevensgroepen DocTypeIndic = OECD1 (of OECD11 in geval van een verwijderde testlevering). Deze mogelijkheid moet met uiterste terughoudendheid worden gebruikt. En als ze gebruikt wordt dan is uiterste zorgvuldigheid vereist en is het niet anders mogelijk dan ALLE berichten (correctieberichten en initiële bericht) te verwijderen om vervolgens met een bericht met nieuwe gegevens ‘opnieuw’ te beginnen. Voorbeelden van correctie gegevens AccountReport Twee voorbeelden (niet tijdens test) van correctie van gegevensgroepen zijn:

Correctie van Payment Amount (Payment Amount behoort tot de gegevensgroep AccountReport). De gehele gegevensgroep AccountReport met daarbinnen AccountNumber, AccountHolder, SubstantialOwner, ControllingPerson, AccountBalance, Payment (gewijzigd) en AdditionalData, wordt volledig gevuld opgenomen in het correctiebericht. Payment Amount bevat de gecorrigeerde waarde. DocTypeIndic in DocSpec van AccountReport = OECD2.

Correctie van meerdere gegevens, bijvoorbeeld Naam en Adres van AccountHolder en Payment Amount (AccountHolder en Payment Amount behoren beide tot de gegevensgroep AccountReport). De gehele gegevensgroep AccountReport met daarbinnen Accountnumber, AccountHolder (gewijzigd), SubstantialOwner, ControllingPerson, AccountBalance, Payment (gewijzigd) en AdditionalData, wordt volledig gevuld opgenomen in het correctiebericht. Naam en Adres bij AccountHolder en Payment Amount bevatten de gecorrigeerde gegevens. DocTypeIndic in DocSpec van AccountReport = OECD2.

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 14

Correctie AccountReport in combinatie met NilReport Verder is er nog correctie van levering van gegevens naar een ‘leeg levering’ voor de betreffende ReportingFI

en omgekeerd correctie van een ‘leeg levering’ voor een ReportingFI naar een levering van gegevens voor de

betreffende ReportingFI:

1. Van geleverde gegevens naar ‘leeg levering’ voor een ReportingFI Stel er zijn gegevens geleverd voor een ReportingFI in bericht met MessageRefId = AW persoonsAW2017PersoonsnrAbcd met MessageTypeIndic = CRS701 (nieuwe gegevens) en met in de body gegevens van de ReportingFI en AccountReports in de ReportingGroup.

Bij nader inzien blijkt dat deze ReportingFI geen accountholders met een MCAA-land als jurisdiction of residence heeft. Dit kan gecorrigeerd worden door een correctiebericht te sturen met CorrMessageRefId = AW2017 persoonsnrAbcd en bijv. MessageRefId = AW2017 persoonsnrAbce en MessageTypeIndic = CRS703 (leeg levering) en dan in de body de ReportingFI en in de ReportingGroup een NiLReport (zie inleiding hoofdstuk 6).

2. Van een ‘leeg levering’ voor een ReportingFI naar levering van gegevens voor de betreffende ReportingFI Voorbeeld: Voor een ReportingFI is aangegeven dat er geen accountholders zijn met een MCAA-land als jurisdiction of residence, waarvoor gegevens geleverd moeten worden. Dit is gedaan met een bericht met MessageRefId = AW2017 persoonsnrAbcf met MessageTypeIndic = CRS703 (leeg levering) en met in de body gegevens van de ReportingFI en een ReportingGroup met een NilReport. Bij nader inzien blijkt dat voor deze ReportingFI wel gegevens moeten worden geleverd. Dit kan gecorrigeerd worden door een correctiebericht te sturen met CorrMessageRefId = AW2017 persoonsnrAbcf en bijv. MessageRefId = AW2017 persoonsnrAbcg en MessageTypeIndic = CRS702 en dan in de body gegevens van de ReportingFI en in de ReportingGroup de AccountReports met gegevens die geleverd moeten worden. DocTypeIndic in alle voorkomende DocSpec in ReportingGroup van de betreffende ReportingFI = OECD1.

Correctie gegevens ReportFI

Als ReportingFI gegevens gecorrigeerd moeten worden, dan dient dat te gebeuren met een correctiebericht

bestaande uit de gecorrigeerde ReportingFI en de bijbehorende (ongewijzigde) ReportingGroup met een

NilReport ingeval van leeglevering en één of meer AccountReports ingeval van geleverde gegevens.

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 15

6. Berichtopbouw voor internationale gegevenslevering CRS

Financiële instellingen leveren volgens het FATCA CRS XML berichtschema versie 2.1 berichten met één levering van gegevens over accountholders, die DIMP verstrekt aan MCAA-landen (CRS) en al voorbereid is op verstrekking aan de IRS (FATCA). De structuur van het FATCA CRS XML berichtschema is gevisualiseerd in figuur 3a en 3b. De figuren laten zien welke delen van het bericht (voorzien van driehoeken) gecorrigeerd of verwijderd kunnen worden. De sterren geven aan dat in de MessageHeader wordt aangegeven welk type levering het is: levering van nieuwe gegevens, een leeglevering (geen gegevens) of een correctielevering. Het FATCA CRS XML berichtschema bestaat uit de volgende onderdelen:

Berichtsoort + Versie (één per bericht)

Messageheader (één per bericht) met de logistieke gegevens van het bericht,

MessageBody van het bericht (één of meerdere) met daarin de gegevensgroepen:

o ReportingFI (één per body),

o ReportingGroup (één per MessageBody) met daarin de gegevensgroepen:

Sponsor (optioneel (0,1) en alleen bestemd voor FATCA-levering)

OF één NilReport in de ReportingGroup:

NilReport

OF een of meer AccountReports in de ReportingGroup:

AccountReport(s) met daarin:

- Accountnumber (één in een AccountReport)

- Accountholder (één in een AccountReport); Accountholder heeft 1 of meer ResCountryCode(s)

met net zoveel combinaties TIN en TIN@IssuedBy (voor elk land, waaraan gegevens verstrekt

moeten worden, een ResCountryCode en een combi TIN en TIN@IssuedBy)

- Substantial Owner (geen of meer in een AccountReport; alleen bestemd voor FATCA-levering)

- Controlling Person (geen of meer in een AccountReport; alleen bestemd voor CRS-levering)

- AccountBalance (één in een AccountReport)

- Payment (geen of meerdere in een AccountReport)

- AdditionalData

Bij Accountholders is een veld aanwezig om aan te geven dat de betreffende Accountholder recalcitrant is.

MDES zal op basis van die indicatie zorgdragen voor rapportage aan de IRS over dergelijke accountholders.

Bepaalde gegevensgroepen alleen voor FATCA en andere alleen voor CRS

In de leveringen worden bepaalde gegevensgroepen alleen voor FATCA onderkend en andere gegevensgroepen

alleen voor CRS. In figuur 3a in hoofdstuk 6 wordt dit schematisch weergegeven. Om gegevens te kunnen

leveren in deze specifieke groepen zullen financiéle instellingen de betreffende gegevens in de administratie

moeten hebben vastgelegd. Het betreft:

Alleen voor FATCA

in ReportingFI

o FilerCategory

in de body van het bericht in ReportingGroup:

o Sponsor (inclusief FilerCategory)

en binnen AccountReport

o Substantial Owner

o AdditionalData

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 16

Figuur 3a; visualisatie van de structuur van het FATCA CRS XML berichtschema versie 2.0

Figuur 3b toont wat enkelvoudig (1), optioneel (0,1) en vaker voor kan komen in het bericht (1..N).

Figuur 3b: cardinaliteiten binnen het FATCA CRS XML berichtschema versie 2.0

Messageheader met o.a MessageTypeIndic MessageRefID en CorrMessageRefID

MessageBody

Reporting FI DocRefID en CorrDocRefID

Versie

ReportingGroup

Sponsor

Accountreport

Legenda

alleen FACTAalleen CRS

MessageRefIDCorrMesageRefID

DocSpec met:DocRefID + CorrDocRefID

AccountNumber

AccountHolder

Individual

Organisation

AccountBalance

Substantial Owner

Payment

Controlling Person

NilReport

AdditionalData

OF

Versie + MessageHeader

Body

Body

Body

ReportingFI

ReportingGroup

Sponsor

AccountReport

AccountReport

AccountReport

1

0,1

1

AccountReport:

- AccountNumber (1)- Accountholder (1)- SubstantialOwner (0..N)- Controlling Person (0..N)- Accountbalance (1)- Payment (0..N)

FATCA

CRS

of Individual of OrganisationResCountryCode (1..N)

NilReport 1

1

OF

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 17

NB.

Omdat het CRS XML berichtschema, dat OECD hanteert voor gegevensuitwisseling tussen MCAA-landen, per MessageBody

naast één ReportingFI ook één ReportingGroup vereist1, is ervoor gekozen om voor gegevenslevering aan DIMP uit te gaan

van de meest beperkte berichtstructuur en dus per MessageBody steeds één ReportingFI en ook één ReportingGroup.

NB.

In één bericht kunnen meerdere MessageBody’s voorkomen. Als er sprake is van ‘leeg levering’ dan zijn messagebody’s

gevuld met ReportingFI en ReportingGroup met daarin NilReport (MessageTypeIndic in MessageHeader = CRS703).

Financiële instellingen in Aruba ( persoonsPersoonsnummer van financiële instelling in SendingCompanyIN in de Messageheader) leveren gegevens over personen die een ‘jurisdiction of residence’ hebben in MCAA-landen. Internationale gegevenslevering gaat uit van initiële levering en leveringen met intrekking

2 van (delen van)

gegevenslevering of correctie van (delen van) gegevenslevering, waarbij de gegevenslevering (op bericht niveau) worden aangeduid met MessageRefId en CorrMessageRefId en binnen het bericht worden de gecorrigeerde, verwijderde of gewijzigde delen van het bericht aangeduid met DocRefId en CorrDocRefId. Correctie of verwijdering is mogelijk voor de volgende delen van het bericht:

NilReport in gebruik voor FATCA en CRS (1..1)

AccountReport in gebruik voor FATCA en CRS (1..N) Leveringen met FATCA CRS XML berichtschema versie 2.1 (een GEGEVENS-levering of een LEEG-levering) Volgens het FATCA CRS XML berichtschema versie 2.1 bestaat ReportingGroup uit of een NilReport of een AccountReport(s). Een van de twee is verplicht. In de MessageHeader geeft de indicator MessageTypeIndic aan of het bericht nieuwe gegevens bevat (CRS701) of correcties bevat (CRS702) of leegleveringen bevat (CRS703). Dit betekent voor de leveringen:

voor leveringen met ReportingFI’s waarvoor een LEEG-levering gedaan wordt, geldt: o in de MessageHeader heeft MessageTypeIndic de waarde CRS703, o ReportingGroup bevat een NilReport

voor leveringen met ReportingFI’s waarvoor een GEGEVENS-levering gedaan wordt, geldt: o in de MessageHeader heeft MessageTypeIndic waarde CRS701 (nieuw) of waarde CRS702 (correctie), o ReportingGroup bevat één of meer AccountReport(s)

6.1. Berichtsoort en versie gegevenslevering

Het bericht start met een vast element, dat aangeeft om welk berichtsoort het gaat. Verder bevat het een

versie-aanduiding van het FATCA CRS XML berichtschema dat de financiële instelling heeft gebruikt om het

bericht te vervaardigen. DIMP hanteert één FATCA CRS XML-berichtschema voor alle belastingjaren tot dan

toe. Als het FATCA XML schema (IRS) of het CRS XML schema (OECD) wijzigt dan beziet DIMP of de wijziging

aanleiding is voor een nieuwe versie van het FATCA CRS XML berichtschema voor de financiële instellingen in

Aruba.

1 Het FATCA XML-berichtschema, dat de IRS hanteert voor gegevensuitwissleingen met een Competent Authority in andere

landen, staat per ReportingFI meerdere ReportingGroups toe. 2 Verwijdering.

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 18

Gegevensnaam FATCA_CRS

Xpath (XML) FATCA_CRS

Omschrijving Vaste tekst om soort gegevenslevering aan te duiden

Condities Verplicht

Toelichting Standaard tekst is ‘FATCA_CRS’ voor gegevensleveringen in het kader van CRS.

Kardinaliteit 1..1

Formaat xsd:string

Domein Validatie op ‘FATCA_CRS’

gegevensnaam Version

Xpath (XML) FATCA_CRS@Version

Omschrijving Versie van het FATCA CRS XML berichtschema

Condities Verplicht

Toelichting De versie van het XML schema is met ingang van 1-1-2018 voor alle belastingjaren gelijk aan de actuele versie van het FATCA CRS XML berichtschema: versie 2.1. Als een financiële instelling volgens een verkeerde versie levert, dan krijgt de financiële instelling een notificatie om opnieuw te leveren maar dan volgens geldende XML berichtschema.

Kardinaliteit 1..1

Formaat xsd:string

Domein versienummer in het bericht met gelijk zijn aan het geldende versienummer

6.2. Messageheader (logistieke gegevens van het bericht)

De Messageheader bestaat uit een aantal logistieke gegevens en unieke identificatie gegevens.

gegevensnaam MessageHeader – SendingCompanyIN

Xpath (XML) FATCA_CRS/MessageHeader/SendingCompanyIN

Omschrijving persoonsnummer van de leverende financiële instelling het nummer die bij aanmelding in de MDES is ontvangen

Condities Verplicht

Toelichting Voor de gegevenslevering FATCA-CRS levert een financiële instelling voor zichzelf. MCAA-landen voor de CRS – vanaf belastingjaar 2017

Kardinaliteit 1..1

Formaat xsd:stringMax200

Domein Validatie op bestaande persoonsnummer

gegevensnaam MessageHeader – TransmittingCountry

Xpath (XML) FATCA_CRS/MessageHeader/TransmittingCountry

Omschrijving Landcode van Aruba ( AW) conform ISO standaard voor Country-Code-Type

Condities Gevuld met ‘ AW’ en is verplicht

Toelichting Gegevens zijn afkomstig van een financiële instelling gevestigd in Aruba

Kardinaliteit 1..1

Formaat xsd:string (2 posities)

Domein Validatie op aanwezigheid van ‘ AW’

gegevensnaam MessageHeader – ReceivingCountry

Xpath (XML) FATCA_CRS/MessageHeader/ReceivingCountry

Omschrijving Landcode van Aruba ( AW) conform ISO standaard voor Country-Code-Type

Condities Gevuld met ‘ AW’ en is verplicht

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 19

Toelichting Financiële instelling levert aan DIMP en dus Aruba.

Kardinaliteit 1..1

Formaat xsd:string (2 posities)

Domein Validatie op aanwezigheid van ‘ AW’

gegevensnaam MessageHeader – MessageType

Xpath (XML) FATCA_CRS/MessageHeader/MessageType

Omschrijving Bevat vaste tekst ‘FATCA-CRS’

Condities Gevuld met ‘FATCA-CRS’ en is verplicht

Toelichting Vaste tekst

Kardinaliteit 1..1

Formaat xsd:string (vaste waarde ‘FATCA-CRS’)

Domein Validatie op aanwezigheid van ‘FATCA-CRS’

gegevensnaam MessageHeader – Warning

Xpath (XML) FATCA_CRS/MessageHeader/Warning

Omschrijving Waarschuwing betreffende de inhoud van de gegevenslevering

Condities Optioneel

Toelichting Kan bijv. worden gebruikt om aan te geven dat voor deze gegevenslevering als geheel de ReportingPeriod niet 12 maanden maar slechts 10 maanden is.

Kardinaliteit 0..1

Formaat xsd:stringMax4000

Domein Maximaal 4000 karakters lang

gegevensnaam MessageHeader – Contact

Xpath (XML) FATCA_CRS/MessageHeader/Contact

Omschrijving Contactgegevens voor de gegevenslevering

Condities Optioneel

Toelichting Kan door de leverende financiële instelling worden gebruikt om bij DIMP te laten vastleggen wat de contactgegevens zijn voor de betreffende gegevenslevering als geheel. Dit gegeven wordt niet doorgestuurd naar MCAA-landen

Kardinaliteit 0..1

Formaat xsd:stringMax200

Domein Maximaal 200 karakters lang

gegevensnaam MessageHeader – MessageRefId

Xpath (XML) FATCA_CRS/MessageHeader/MessageRefId

Omschrijving Unieke identificatie van het bericht

Condities Verplicht

Toelichting Het unieke MessageRefId wordt gecreëerd door de leverende financiële instelling. Een voorbeeld kan zijn AW2017( persoons-nummer)123456789.

Kardinaliteit 1..1

Formaat xsd:string

Domein De eerste zes karakters moeten gelijk zijn aan ‘ AW’ gevolgd door het belastingjaar (JJJJ) waarvoor de gegevens in het bericht gelden. Voor belastingjaar 2017 is het dus ‘ AW2017’. Vervolgens dient de persoons-nummer van de leverende financiële instelling opgenomen te zijn gevolgd door de identificatie van het bericht als zodanig.. Mag geen spaties bevatten en mag niet meer dan 200 karakters groot zijn

gegevensnaam MessageHeader – MessageTypeIndic

Xpath (XML) FATCA_CRS/MessageHeader/MessageTypeIndic

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 20

Omschrijving Geeft aan welk type gegevenslevering het bericht als geheel is:

voor GEGEVENS-levering (CRS701)

voor correctie van een eerdere levering (CRS702)

voor LEEG-levering (CRS703).

Condities Verplicht

Toelichting Een verplicht element, waarmee meteen ook de volledigheid van levering door de financiële instelling kan worden bewaakt. Mogelijke waarden zijn:

CRS701 bericht bevat nieuwe data of aanvullingen op eerdere leveringen

CRS702 bericht bevat alleen correcties van eerder gestuurde informatie

CRS703 bericht bevat reporting FI’s zonder data met ReportingGroup/NilReport

Berichten met MessageTypeIndic = CRS701 mogen in alle DocSpecs in het bericht alleen OECD1 (productie-gegevens) of OECD11 (testgegevens) als DocTypeIndic voorkomen. De DocSpecs van ReportingFI bevat OECD0 of OECD10 testgegevens) als DocTypeIndic, als het ‘recent date’ van de ReportingFI betreft om nieuwe AccountReports te leveren. Berichten met MessageTypeIndic = CRS702 mogen in alle DocSpecs in het bericht bij leveringen met productie-gegevens alleen OECD2 of OECD3 of bij leveringen van testgegevens alleen OECD12 of OECD13 als DocTypeIndic voorkomen. De DocSpecs van ReportingFI bevat OECD0 of OECD10 testgegevens) als DocTypeIndic, als het ‘recent date’ van de ReportingFI betreft om AccountReports te verwijderen of te corrigeren. Berichten met MessageTypeIndic = CRS703 zijn bedoeld voor initiёle LEEG-levering en bevatten daarom in de DocSpec van het NilReport en in de eventuele DocSpec van de Sponsor alleen OECD1 of bij leveringen van testgegevens alleen OECD11 als DocTypeIndic

De typering geldt voor het gehele bericht (hetgeen meteen betekent dat voor verschillende Reporting FI in het bericht of alleen nieuwe data of alleen gecorrigeerde data of alleen ‘leeg leveringen’ kunnen worden geleverd):

ingeval van nieuwe gegevens, aanvullingen of correcties is ReportingGroup gevuld met een of meer AccountReports en indien van toepassing een Sponsor

ingeval van leeglevering is ReportingGroup gevuld met een NilReport en indien van toepassing een Sponsor

Voor uitleg over het gebruik DocTypeIndic in DocSpecs van ReportingFi, Sponsor, NilReport en AccountReport i.c.m. MessageTypeIndic wordt verwezen naar paragraaf 5.4.

Kardinaliteit 1..1

Formaat xsd:string (met een waardebereik zoals aangegeven bij Domein)

Domein De waarden zijn: CRS701, CRS702, CRS703.

gegevensnaam MessageHeader – CorrMessageRefId

Xpath (XML) FATCA_CRS/MessageHeader/CorrMessageRefId

Omschrijving Unieke identificatie van het bericht, dat wordt ingetrokken of gecorrigeerd c.q. waarvan delen worden ingetrokken of gecorrigeerd.

Condities Verplicht in geval van MessageIndicType = CRS702 en optioneel als MessageIndicType = CRS703 en niet toegestaan als MessageIndicType = CRS701

Toelichting Unieke ID is (eerder) uitgegeven door de leverende financiële instelling

Kardinaliteit 0..1

Formaat xsd:string

Domein De eerste zes karakters moeten gelijk zijn aan ‘ AW’ gevolgd door het belastingjaar (JJJJ) waarvoor de gegevens in het bericht gelden. Voor belastingjaar 2017 is het dus ‘ AW2017’. Vervolgens dient het persoonsnummer van de leverende financiële instelling opgenomen te zijn gevolgd door de identificatie van het bericht als zodanig. Mag geen spaties bevatten en mag niet meer dan 200 karakters groot zijn

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 21

gegevensnaam MessageHeader – ReportingPeriod

Xpath (XML) FATCA_CRS/MessageHeader/ReportingPeriod

Omschrijving Aanduiding van de periode waarover gerapporteerd wordt

Condities Verplicht

Toelichting Een jaar wordt weergegeven door de einddatum. Voor belastingjaar 2017 is ReportingPeriod gelijk aan 2017-12-31.

Kardinaliteit 1..1

Formaat JJJJ-MM-DD

Domein n.v.t.

gegevensnaam MessageHeader – TimeStamp

Xpath (XML) FATCA_CRS/MessageHeader/Timestamp

Omschrijving Tijdstip waarop het bericht door de leverende financiële instelling verzonden is naar DIMP.

Condities Verplicht

Toelichting Op 14 maart 2018 om 9.45 uur en 30 seconden verstuurd wordt weergegeven door: 2018-03-14T09:45:30

Kardinaliteit 1..1

Formaat JJJJ-MM-DD’T’hh:mm:ss

Domein n.v.t.

6.3. MessageBody

Een bericht bevat één of meer MessageBody’s. Een MessageBody bestaat uit één combinatie van Reporting FI

en Reporting Group. Als een financiële instelling rapporteert voor meer dan één ReportingFI, dan zal het

bericht meer dan één MessageBody moeten bevatten. Voor elke ReportingFI een eigen MessageBody.

Een ReportingGroup bestaat uit:

Ggegevens levering (nieuw of correctie):

AccountReport komt 1 of meer keer voor (ingeval van nieuwe gegevens of correcties)

of leeglevering:

NilReport komt 1 keer voor (ingeval van leeglevering)

NB

Iingeval van ‘geen levering’ voor een of meer ReportingFI’s wordt de MessageBody geleverd met een gevulde ReportingFI en

met een ReportingGroup gevuld met een NilReport. In de MessageHeader staat dan in MessageTypeIndic de code CRS703

(zie inleiding hoofdstuk 6).

6.3.1. ReportingFI

Dit deel van het bericht is nieuw, gecorrigeerd of verwijderd en kent daarom een DocSpec deel op ReportingFI-

niveau om het deel uniek te identificeren en desgewenst terug te verwijzen naar de te corrigeren ReportingFI

uit een eerder bericht. Bij correctie wordt de gehele ReportingFI opnieuw aangeleverd, ook de gegevens die

niet gewijzigd zijn.

6.3.1.1. ReportingFI – de gegevens

Een ReportingFI is de eenheid waarover wordt gerapporteerd. Voor de CRS is ReportingFI een rapporterende

eenheid en is het aan de financiële instelling of zij een onderverdeling naar ReportingFI’s maakt of ineens levert

waarbij de financiële instelling zelf de ReportingFI is. Een ReportingFI bestaat als gegevensgroep uit:

ResCountryCode

TIN (identification Number) bestaande uit:

o de identificatie als zodanig,

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 22

o IssuedBy

Naam of namen van de ReportingFI (minstens één naam is verplicht en meerdere namen is mogelijk)

bestaande uit:

o de naam als zodanig

o een typeaanduiding van die naam

Adres(sen) van de ReportingFI (minstens één en meerdere zijn mogelijk) bestaande uit:

o de landcode

o een typeaanduiding van het adres

o het adres als zodanig

in een fixed formaat (optioneel aangevuld met AddressFree voor aanvulling) met als attributen:

straat

gebouw identificatie

suite identificatie

floor identificatie

district naam

postbus

postcode

stad

landsonderdeel

of free format (AddressFree)

het adres als xsd:string

gegevensnaam MessageBody - ReportingFI – ResCountryCode

Xpath (XML) FATCA_CRS/MessageBody/ReportingFI/ResCountryCode

Omschrijving De landcode van de ‘tax residence’ van de ReportingFI.

Condities Verplicht gevuld met ‘ AW’

Toelichting Conform FATCA CRS afspraken wordt voor ReportingFI’s gerapporteerd vanuit de tax residence van de betreffende ReportingFI. Om die reden is ResCountryCode altijd gelijk aan ‘ AW’. Is het een ander land dan dient die ReportingFI vanuit dat andere land te rapporteren (zie “FATCA/CRS-afspraken voor levering van gegevens” in paragraaf 1.1)

Kardinaliteit 1..1

Formaat xsd:string (2 posities)

Domein Vaste waarde is ‘ AW’

gegevensnaam MessageBody - ReportingFI – TIN

Xpath (XML) FATCA_CRS/ MessageBody/ReportingFI/TIN

Omschrijving Identificatie van de ReportingFI (via TIN@Issued_By is aangegeven voor welk land)

Condities Verplicht:

voor een FFI als ReportingFI is de TIN gelijk aan de GIIN ontvangen van de IRS (de ReportingFI heeft US-persons als accountholder, waarover gerapporteerd wordt)

voor overige ReportingFI is de TIN gelijk aan het persoons nummer van de financiële instelling

Toelichting Dit element is het identificatienummer (TIN), zoals gebruikt door de zendende en/of ontvangende ‘tax administration’:

voor CRS bepaalt de zendende ‘tax administration’ het identificatienummer: persoonsnummer van de financiële instelling in Aruba.

Kardinaliteit 1..1 (volgens het FATCA CRS XML schema 0..N, maar de verbandscontrole eist 1..1)

Formaat xsd:stringMax200

Domein Moet voldoen aan het formaat van de TIN in het land in IssuedBy en mag niet langer dan

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 23

200 karakters zijn.

gegevensnaam MessageBody - ReportingFI – TIN – IssuedBy

Xpath (XML) FATCA_CRS/ MessageBody/ReportingFI/TIN@IssuedBy

Omschrijving beschrijving van de ‘jurisdiction’ die de TIN heeft uitgegeven

Condities Verplicht als TIN is gevuld

Toelichting Het is de landcode van het land waar de TIN is uitgegeven.

.

voor ReportingFI’s, is TIN@IssuedBy gelijk aan ‘ AW’ (het persoons-nummer werd uitgegeven door DIMP)

Kardinaliteit 1..1 (verplicht als TIN gevuld is; anders niet aanwezig)

Formaat xsd:string (2 posities)

Domein Landcode moet voldoen aan ISO-3166-1

In FATCA CRS XML-berichtschema versie 2.0 is TIN-attribuut “INType” bij OrganisationParty_Type niet

opgenomen. In het CRS berichtschema komt INType als optioneel attribuut van IN voor.

Voor een ReportingFI is één naam verplicht en zijn meerdere namen mogelijk.

De elementen hierna vormen de naam van een ReportingFI.

gegevensnaam MessageBody - ReportingFI - Name

Xpath (XML) FATCA_CRS/ MessageBody/ReportingFI/Name/Name

Omschrijving De juridische naam van de ReportingFI

Condities Verplicht

Toelichting Geen

Kardinaliteit 1..N

Formaat xsd:stringMax200

Domein Maximaal 200 karakters

gegevensnaam MessageBody - ReportingFI – Name - NameType

Xpath (XML) FATCA_CRS/ MessageBody/ReportingFI/Name@NameType

Omschrijving Typering van de naam van de ReportingFI (niet gebruikt in het FATCA-CRS bericht)

Condities Verplicht

Toelichting Element wordt gebruikt voor CRS en vanaf belastingjaar 2016 ook door FATCA. OECD201 is gereserveerd voor SMFAliasOrOther en wordt niet gebruikt. De volgende naam types worden onderkend:

OECD202 = individual

OECD203 = alias

OECD204 = nick (nickname)

OECD205 = AKA (also known as)

OECD206 = DBA (doing business as)

OECD207 = legal

OECD208 = at birth

Kardinaliteit 1..1

Formaat xsd:string (met een waardebereik zoals aangegeven bij Domein)

Domein Waarden zijn: OECD202, OECD203, OECD204, OECD205, OECD206, OECD207, OECD208

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 24

De elementen hierna vormen het adres van de ReportingFI, dat op twee manieren kan worden geleverd (voor

CRS moet AddressFix gebruikt worden en kan uitgeweken worden naar AddressFree als niet de verschillende

elementen uit AddressFix voor de ReportingFI kunnen worden geleverd).

Minimaal één adres moet geleverd worden en meerdere adressen zijn mogelijk. Een adres wordt geleverd:

als AddressFix (het adres wordt dan weergegeven in een aantal elementen) met optioneel gebruik van

AddressFree voor aanvulling op de AddressFix elementen

als AddressFree (vrije tekst in één element)

In beide gevallen moet het adres voorzien zijn van landcode (CountryCode) en adrestype (AddressType).

gegevensnaam MessageBody - ReportingFI – Address – AddressType

Xpath (XML) FATCA_CRS/ MessageBody/ReportingFI/Address@AddressType

Omschrijving Dit element geeft aan welk soort adres het adres van de ReportingFI is

Condities Optioneel

Toelichting Er wordt een aantal adressoorten onderkend, te weten:

OECD301 = residential or business

OECD302 = residential

OECD303 = business

OECD304 = registered office

OECD305 = unspecified

Kardinaliteit 0..1

Formaat xsd:string (een van de waarden uit Domein)

Domein De waarden zijn: OECD301, OECD302, OECD303, OECD304, OECD305.

gegevensnaam MessageBody - ReportingFI – Address – CountryCode

Xpath (XML) FATCA_CRS/ MessageBody/ReportingFI/Address/CountryCode

Omschrijving De landcode van het land waar de ReportingFI is gevestigd

Condities Verplicht

Toelichting Dit is voor FATCA-CRS berichten, voor ReportingFI’s in Aruba altijd ‘ AW’ Het gaat immers om ReportingFI’s die gevestigd zijn in Aruba.

Kardinaliteit 1..1

Formaat xsd;string (altijd gevuld met ‘ AW’)

Domein Vaste waarde is ‘ AW’

Elementen uit AddressFix zijn Street, BuildingIdentifier, SuiteIdentifier, FloorIdentifier, DistrictName, POB,

PostCode, City en CountrySubentity optioneel met AddressFree voor aanvullende informatie. CRS geeft de

voorkeur aan adressen in de vorm van een AddressFix weergave. Alleen als het niet anders kan, dan is een

adres in AddressFree weergave toegestaan.

gegevensnaam MessageBody - ReportingFI – Address - AddressFix – Street

Xpath (XML) FATCA_CRS/ MessageBody/ReportingFI/Address/AddressFix/Street

Omschrijving Straatnaam van het adres van de ReportingFI

Condities Optioneel

Toelichting Geen

Kardinaliteit 0..1

Formaat xsd:stringMax200

Domein Maximaal 200 karakters

gegevensnaam MessageBody - ReportingFI – Address - AdressFix – BuildingIdentifier

Xpath (XML) FATCA_CRS/ MessageBody/ReportingFI/Address/AddressFix/BuildingIdentifier

Omschrijving Gebouw identificatie, indien van toepassing in het adres van de ReportingFI

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 25

Condities Optioneel

Toelichting Geen

Kardinaliteit 0..1

Formaat xsd:stringMax200

Domein Maximaal 200 karakters

gegevensnaam MessageBody - ReportingFI – Address - AddressFIx – SuiteIdentifier

Xpath (XML) FATCA_CRS/ MessageBody/ReportingFI/Address/AddressFix/SuiteIdentifier

Omschrijving Suite identificatie, indien van toepassing in het adres van de ReportingFI

Condities Optioneel

Toelichting Geen

Kardinaliteit 0..1

Formaat xsd:stringMax200

Domein Maximaal 200 karakters

gegevensnaam MessageBody - ReportingFI – Address - AddressFix – FloorIdentifier

Xpath (XML) FATCA_CRS/ MessageBody/ReportingFI/Address/AddressFix/FloorIdentifier

Omschrijving Etage identificatie, indien van toepassing in het adres van de ReportingFI

Condities Optioneel

Toelichting Geen

Kardinaliteit 0..1

Formaat xsd:stringMax200

Domein Maximaal 200 karakters

gegevensnaam MessageBody - ReportingFI – Address - AddressFix – Districtname

Xpath (XML) FATCA_CRS/ MessageBody/ReportingFI/Address/AddressFix/DistrictName

Omschrijving Naam van het district, indien van toepassing in het adres van de ReportingFI

Condities Optioneel

Toelichting Geen

Kardinaliteit 0..1

Formaat xsd:stringMax200

Domein Maximaal 200 karakters

gegevensnaam MessageBody - ReportingFI – Address - AddressFix – POB

Xpath (XML) FATCA_CRS/ MessageBody/ReportingFI/Address/AddressFix/POB

Omschrijving Postbus nummer, indien van toepassing in het adres van de ReportingFI

Condities Optioneel

Toelichting Geen

Kardinaliteit 0..1

Formaat xsd:stringMax200

Domein Maximaal 200 karakters

gegevensnaam MessageBody - ReportingFI – Address - AddressFix – PostCode

Xpath (XML) FATCA_CRS/ MessageBody/ReportingFI/Address/AddressFix/PostCode

Omschrijving Postcode, indien van toepassing in het adres van de ReportingFI

Condities Optioneel

Toelichting In Aruba wordt geen gebruik gemaakt van postcodes. Dit element zal dus blanco zijn.

Kardinaliteit 0..1 (in Aruba wordt geen gebruik gemaakt van postcodes)

Formaat xsd:string (leeg)

Domein Maximaal 200 karakters

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 26

gegevensnaam MessageBody - ReportingFI – Address - AddressFix – City

Xpath (XML) FATCA_CRS/ MessageBody/ReportingFI/Address/AddressFix/City

Omschrijving Plaatsnaam in het adres van de ReportingFI

Condities Verplicht

Toelichting De plaatsnaam is verplicht en wordt gebruikt voor validatie

Kardinaliteit 1..1

Formaat xsd:stringMax200

Domein Maximaal 200 karakters

gegevensnaam MessageBody - ReportingFI – Address - AddressFix – CountrySubentity

Xpath (XML) FATCA_CRS/ MessageBody/ReportingFI/Address/AddressFix/CountrySubentity

Omschrijving Landsonderdeel, indien van toepassing in het adres van de ReportingFI

Condities Optioneel

Toelichting Geen

Kardinaliteit 0..1

Formaat xsd:stringMax200

Domein Maximaal 200 karakters

AddressFree bestaat uit één element (xsd:string). CRS geeft de voorkeur aan adressen in de vorm van een

AddressFix weergave. Alleen als het niet anders kan, dan is een adres in AddressFree weergave toegestaan.

gegevensnaam MessageBody - ReportingFI – Address – AddressFree

Xpath (XML) FATCA_CRS/ MessageBody/ReportingFI/Address/AddressFree

Omschrijving Vrije tekst omschrijving van het adres.

Condities Optioneel

Toelichting Alleen te gebruiken als elementen uit AddressFix niet geleverd kunnen worden voor het adres van de ReportingFI (CRS gaat uit van adressen in AddressFix weergave).

Of optioneel te gebruiken als aanvulling op de gegevens in het AddressFix formaat. AddressFree mag maximaal 4000 karakters lang zijn.

Kardinaliteit 0..1

Formaat xsd:stringMax4000

Domein Maximaal 4000 karakters

6.3.1.2. ReportingFI –DocSpec

DocSpec bevat de unieke identificatie voor de gegevensgroep ReportingFI en bevat, in geval van levering van

correcties in de gegevensgroep ReportingFI, een verwijzing naar de unieke identificatie van de levering van

ReportingFI gegevens die door middel van de gegevens in dit bericht gecorrigeerd worden (opnieuw geleverd).

DocSpec bestaat uit: DocTypeIndic, DocRefId en bij een correctie ook CorrDocRefId.

gegevensnaam MessageBody - ReportingFI – DocSpec - DocTypeIndic

Xpath (XML) FATCA_CRS/ MessageBody/ReportingFI/DocSpec/DocTypeIndic

Omschrijving Typering van de ReportingFI gegevens (nieuw, correctie, verwijdering)

Condities Verplicht

Toelichting Er wordt een aantal DocTypeIndic waarden onderkend, te weten:

OECD1 = nieuwe gegevens (new data)

OECD2 = gecorrigeerde gegevens (corrected data)

OECD3 = verwijderde gegevens (deleted data) En tijdens het testen van gegevenslevering:

OECD11 = nieuwe testgegevens (new data)

OECD12 = gecorrigeerde testgegevens (corrected testdata)

OECD13 = verwijderde testgegevens (deleted testdata)

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 27

Voorafgaand aan de vrijgave van de MDES voor een bepaald belastingjaar zijn alleen de DocTypeIndic codes OECD11, OECD12 en OECD13 toegestaan (dit zijn testleveringen). Vanaf het moment van vrijgave van de MDES voor een bepaald belastingjaar zijn alleen de DocTypeIndic codes OECD1, OECD2 en OECD3 toegestaan (dit zijn productieleveringen). NB Een FATCA-CRS bericht met voor een ReportingFI een DocSpec met DocTypeIndic = OECD3 wordt altijd gevolgd door een FATCA-CRS bericht met voor dezelfde ReportingFI een DocSpec met DocTypeIndic = OECD1 (bij testen is het OECD13 gevolgd door OECD11).

Kardinaliteit 1..1

Formaat xsd:string (een van de waarden uit Domein)

Domein De waarden zijn: OECD1, OECD2, OECD3, OECD11, OECD12, OECD13

gegevensnaam MessageBody - ReportingFI – DocSpec - DocRefId

Xpath (XML) FATCA_CRS/ MessageBody/ReportingFI/DocSpec/DocRefId

Omschrijving Unieke aanduiding van de gegevensgroep ReportingFI in het FATCA-CRS bericht.

Condities Verplicht

Toelichting Het bericht bestaat uit onderdelen (gegevensgroep). Als een onderdeel corrigeerbaar is, dan heeft het een DocRefId. De leverende financiële instelling creëert het DocRefId.

Kardinaliteit 1..1

Formaat xsd:stringMax200

Domein De eerste zes karakters moeten gelijk zijn aan ‘ AW’ gevolgd door het belastingjaar (JJJJ) waarvoor de gegevens in het bericht gelden. Voor belastingjaar 2017 is het dus ‘ AW2017’. Vervolgens dient het persoonsnummer van de leverende financiële instelling opgenomen te zijn gevolgd door de identificatie van het bericht als zodanig. . Mag geen spaties bevatten en mag niet meer dan 200 karakters groot zijn

gegevensnaam MessageBody - ReportingFI – DocSpec - CorrDocRefId

Xpath (XML) FATCA_CRS/ MessageBody/ReportingFI/DocSpec/CorrDocRefId

Omschrijving Als er sprake is van correctie, verwijdering of wijziging van ReportingFI gegevens uit een eerder bericht, dan verwijst CorrDocRefId naar de DocRefId van de gegevensgroep ReportingFI, waarop de correctie of verwijdering betrekking heeft.

Condities Verplicht in geval van correctie of verwijdering

Toelichting CorrDocRefId is een DocRefId die eerder door de leverende financiële instelling werd gecreëerd

Kardinaliteit 0..1 (verplicht in geval van correctie of verwijdering)

Formaat xsd:stringMax200

Domein De eerste zes karakters moeten gelijk zijn aan ‘ AW’ gevolgd door het belastingjaar (JJJJ) waarvoor de gegevens in het bericht gelden. Voor belastingjaar 2017 is het dus ‘ AW2017’. Vervolgens dient de persoonsnummer van de leverende financiële instelling opgenomen te zijn gevolgd door de identificatie van het bericht als zodanig.. Mag geen spaties bevatten en mag niet meer dan 200 karakters groot zijn

6.3.2. ReportingGroup

ReportingGroup bestaat uit gegevensgroepen Sponsor, NilReport en AccountReport. Sponsor is alleen van

belang voor FATCA en is optioneel.

Een FATCA CRS bericht bevat één of meerdere MessageBody’s. In MessageBody komt altijd één ReportingFI en

één ReportingGroup voor. ReportingGroup bestaat uit of een NilReport of AccountReports (een of meer).

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 28

6.3.2.1. Sponsor

Sponsor is alleen van belang voor FATCA-leveringen aan de IRS en daarom niet verder gespecificeerd.

6.3.2.2. NilReport

Doordat het een leeglevering voor een ReportingFI betreft komt binnen één ReportingGroup NilReport één

keer voor en zijn er geen AccountReports aanwezig in de ReportingGroup. Betreft het een levering van

gegevens (nieuw of correctie), dan bevat ReportingGroup één of meer AccountReport(s) en komt NilReport

niet voor in de ReportingGroup.

NilReport bestaat uit een DocSpec gedeelte en het veld NoAccountToReport, dat als enige waarde ‘yes’ kent.

Een NilReport is nieuw met bijbehorende DocSpec met DocSpecTypeIndic=OECD1 of kan worden verwijderd

met bijbehorende DocSpec met DocSpecTypeIndic=OECD3.

Correctie van een NilReport komt niet voor als gevolg van de inhoud van het NilReport (alleen het veld

NoAccountToReport). Hoe van NilReport naar levering van gegevens en omgekeerd gegaan kan worden voor

een ReportingFI is beschreven in paragraaf 5.4 - ‘Correctie AccountReport in combinatie met NilReport’.

6.3.2.2.1. NilReport – DocSpec

DocSpec bevat de unieke identificatie voor de gegevensgroep NilReport binnen ReportingGroup en bevat, in

geval van een correctie waarbij voor de ReportingFI het NilReport wordt verwijderd, een verwijzing naar de

unieke identificatie van de levering van NilReport-gegevens die verwiijderd moet worden. DocSpec bestaat uit:

DocTypeIndic, DocRefId en bij een correctie t.b.v. verwijdering van een NilReport ook CorrDocRefId.

gegevensnaam MessageBody - ReportingGroup – NilReport – DocSpec - DocTypeIndic

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/NilReport/DocSpec/DocTypeIndic

Omschrijving Typering van de NilReport gegevens (nieuw of verwijderd)

Condities Verplicht

Toelichting Er wordt een aantal DocTypeIndic waarden onderkend, te weten:

OECD1 = nieuwe gegevens (new data)

OECD2 = gecorrigeerde gegevens (corrected data) – n.v.t. voor NilReport

OECD3 = verwijderde gegevens (deleted data) En tijdens het testen van gegevenslevering:

OECD11 = nieuwe testgegevens (new data)

OECD12 = gecorrigeerde testgegevens (corrected testdata) – n.v.t. voor NilReport

OECD13 = verwijderde testgegevens (deleted testdata) Voorafgaand aan de vrijgave van de MDES voor een bepaald belastingjaar zijn alleen de DocTypeIndic codes OECD11, OECD12 en OECD13 toegestaan (dit zijn testleveringen). Vanaf het moment van vrijgave van de MDES voor een bepaald belastingjaar zijn alleen deDocTypeIndic codes OECD1, OECD2 en OECD3 toegestaan (dit zijn productieleveringen).

Kardinaliteit 1..1

Formaat xsd:string (een van de waarden uit Domein)

Domein De waarden zijn: OECD1, OECD3, OECD11, OECD13

gegevensnaam MessageBody - ReportingGroup – NilReport – DocSpec - DocRefId

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/NilReport/DocSpec/DocRefId

Omschrijving Unieke aanduiding van de gegevensgroep NilReport in het FATCA-CRS bericht.

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 29

Condities Verplicht

Toelichting Het bericht bestaat uit onderdelen (gegevensgroep). Als een onderdeel corrigeerbaar is, dan heeft het een DocRefId. De leverende financiële instelling creëert het DocRefId.

Kardinaliteit 1..1

Formaat xsd:stringMax200

Domein Eerste zes karakters moeten gelijk zijn aan ‘ AW’ gevolgd door het belastingjaar (JJJJ) waarvoor gegevens in het bericht gelden. Voor belastingjaar 2017 is het dus ‘ AW2017’. Vervolgens dient de persoonsnummer van de leverende financiële instelling opgenomen te zijn gevolgd door de identificatie van het bericht als zodanig. Mag geen spaties bevatten en mag niet meer dan 200 karakters groot zijn

gegevensnaam MessageBody - ReportingGroup – NilReport – DocSpec - CorrDocRefId

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/NilReport/DocSpec/CorrDocRefId

Omschrijving Als er sprake is van verwijdering van NilReport gegevens uit een eerder bericht, dan verwijst CorrDocRefId naar de DocRefId van de gegevensgroep NilReport binnen het bericht, waarop de verwijdering betrekking heeft.

Condities Verplicht als er sprake is van verwijdering

Toelichting CorrDocRefId is een DocRefId die eerder door de leverende financiële instelling werd gecreëerd

Kardinaliteit 0..1 (verplicht in geval van verwijdering)

Formaat xsd:stringMax200

Domein Eerste zes karakters moeten gelijk zijn aan ‘ AW’ gevolgd door het belastingjaar (JJJJ) waarvoor gegevens in het bericht gelden. Voor belastingjaar 2017 is het dus ‘ AW2017’. Vervolgens dient de persoons-nummer van de leverende financiële instelling opgenomen te zijn gevolgd door de identificatie van het bericht als zodanig. Mag geen spaties bevatten en mag niet meer dan 200 karakters groot zijn

6.3.2.2.2. NilReport – gegevens

NilReport kent één gegeven, te weten NoAccountToReport, dat verplicht is als NilReport is opgenomen in de

ReportingGroup. De waarde van NoAccountToReport is altijd ‘yes’.

gegevensnaam MessageBody - ReportingGroup – NilReport – NoAccountToReport

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/NilReport/NoAccountToReport

Omschrijving Met ‘yes’ wordt aangegeven dat de ReportingFI geen enkel account kent, waarover gerapporteerd moet worden (leeglevering voor een ReportingFI).

Condities Verplicht als NilReport aanwezig is

Toelichting geen

Kardinaliteit 1..1

Formaat xsd:string (vaste waarde)

Domein Altijd waarde ‘yes’ als NilReport wordt geleverd

6.3.2.3. AccountReport

Binnen één ReportingGroup kan AccountReport een of meer keer voorkomen. Voor AccountReport als

onderdeel van een ReportingGroup is nieuw, gecorrigeerd en ingetrokken mogelijk en kent daarom een

DocSpec deel op AccountReport-niveau om het deel uniek te identificeren en desgewenst terug te verwijzen

naar het de te corrigeren AccountReport uit een eerder bericht. Bij correctie wordt AccountReport in z’n

geheel opnieuw aangeleverd, ook de gegevens die niet veranderd zijn. Bij verwijdering volstaat de DocSpec om

te verwijderen en volgt een levering van AccountReport gegevens van het DocTypeIndic=OECD1 (in geval van

reële gegevens) of OECD11 (in geval van testgegevens).

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 30

Vanaf belastingjaar 2017 dienen een of meer AccountReports te worden geleverd als er accountholder(s) zijn

die een MCAA-land als jurisdiction of residence hebben (ongeacht de hoogte van de accountbalance; ook als

deze accountholder tegelijk een US-person is).

Is een AccountReport geleverd, dan verstrekt de DIMP aan een MCAA-land het AccountReport met

accountbalance en payments aan het betreffende MCAA-land ongeachte de hoogte van de accountbalance.

Binnen AccountReport worden de volgende gegevensgroepen onderkend:

AccountNumber

AccountHolder (individual of organisation)

SubstantialOwner (alleen in gebruik voor FATCA)

ControllingPerson (alleen in gebruik voor CRS)

AccountBalance

Payment

Additional Data3

Een AccountReport start met een DocSpec gegevensgroep.

Voor een “en/of account” moet voor elke accountholder apart een AccountReport worden geleverd. Binnen

een AccountReport komen AccountNumber, AccountHolder (of Individual of Organisation) en AccountBalance

verplicht één keer voor. Payment komt niet, één of meerdere keren voor.

ControllingPerson (CRS en dus in geval van AccountHolders die een of meer MCAA-landen als Jurisdiction of

Residence heeft) komen niet of één of meerdere keren voor.

6.3.2.2.0. AccountReport – DocSpec

DocSpec bevat de unieke identificatie voor de gegevensgroep AccountReport binnen ReportingGroup en bevat,

in geval van levering van correcties in gegevensgroep AccountReport, een verwijzing naar de unieke

identificatie van de levering van AccountReport-gegevens die door middel van de gegevens in dit bericht

gecorrigeerd worden (opnieuw geleverd). DocSpec bestaat uit: DocTypeIndic, DocRefId en bij een correctie

ook CorrDocRefId.

gegevensnaam MessageBody - ReportingGroup – AccountReport – DocSpec - DocTypeIndic

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/DocSpec/DocTypeIndic

Omschrijving Typering van de AccountReport gegevens (new, corrected, deleted, amended)

Condities Verplicht

Toelichting Er wordt een aantal DocTypeIndic waarden onderkend, te weten:

OECD1 = nieuwe gegevens (new data)

OECD2 = gecorrigeerde gegevens (corrected data)

OECD3 = verwijderde gegevens (deleted data) En tijdens het testen van gegevenslevering:

OECD11 = nieuwe testgegevens (new testdata)

OECD12 = gecorrigeerde testgegevens (corrected testdata)

OECD13 = verwijderde testgegevens (deleted testdata) Voorafgaand aan de vrijgave van de MDES voor een bepaald belastingjaar zijn alleen de

3 vanwege introductie van FATCA XML-berichtschema versie 2.0 door de IRS voor FACTA-gegevensuitwisseling voor

belastingjaar 2016 en latere belastingjaren

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 31

DocTypeIndic codes OECD11, OECD12 en OECD13 toegestaan (dit zijn testleveringen). Vanaf het moment van vrijgave van de MDES voor een bepaald belastingjaar zijn alleen de DocTypeIndic codes OECD1, OECD2 en OECD3 toegestaan (dit zijn productieleveringen). NB Een FATCA-CRS bericht met voor een AccountReport een DocSpec met DocTypeIndic = OECD3 wordt altijd gevolgd door een FATCA-CRS bericht met voor dezelfde AccountReport een DocSpec met DocTypeIndic = OECD1 (bij testen is het OECD13 gevolgd door OECD11).

Kardinaliteit 1..1

Formaat xsd:string (een van de waarden uit Domein)

Domein De waarden zijn: OECD1, OECD2, OECD3, OECD11, OECD12, OECD13

gegevensnaam MessageBody - ReportingGroup – AccountReport – DocSpec - DocRefId

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/DocSpec/DocRefId

Omschrijving Unieke aanduiding van de gegevensgroep AccountReport in het FATCA-CRS bericht.

Condities Verplicht

Toelichting Het bericht bestaat uit onderdelen (gegevensgroep). Als een onderdeel corrigeerbaar is, dan heeft het een DocRefId. De leverende financiële instelling creëert het DocRefId.

Kardinaliteit 1..1

Formaat xsd:string

Domein Eerste zes karakters moeten gelijk zijn aan ‘ AW’ gevolgd door het belastingjaar (JJJJ) waarvoor gegevens in het bericht gelden. Voor belastingjaar 2017 is het dus ‘ AW2017’. Vervolgens dient de persoons-nummer van de leverende financiële instelling opgenomen te zijn gevolgd door de identificatie van het bericht als zodanig. Mag geen spaties bevatten en mag niet meer dan 200 karakters groot zijn

gegevensnaam MessageBody - ReportingGroup – AccountReport – DocSpec - CorrDocRefId

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/DocSpec/CorrDocRefId

Omschrijving Als er sprake is van correctie of verwijdering van AccountReport gegevens uit een eerder bericht, dan verwijst CorrDocRefId naar de DocRefId van de gegevensgroep AccountReport binnen het bericht, waarop de correctie of verwijdering betrekking heeft.

Condities Verplicht als er sprake is van correctie of verwijdering

Toelichting CorrDocRefId is een DocRefId die eerder door de leverende financiële instelling werd gecreëerd

Kardinaliteit 0..1 (verplicht in geval van correctie of verwijdering)

Formaat xsd:string

Domein Eerste zes karakters moeten gelijk zijn aan ‘ AW’ gevolgd door het belastingjaar (JJJJ) waarvoor gegevens in het bericht gelden. Voor belastingjaar 2017 is het dus ‘ AW2017’. Vervolgens dient de persoons-nummer van de leverende financiële instelling opgenomen te zijn gevolgd door de identificatie van het bericht als zodanig. Mag geen spaties bevatten en mag niet meer dan 200 karakters groot zijn

6.3.2.3.1. AccountReport – AccountNumber

gegevensnaam MessageBody - ReportingGroup – AccountReport – AccountNumber

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountNumber

Omschrijving Accountnumber of andere unieke identificatie, die de financiële instelling gebruikt om het account te identificeren. Als daarvan geen sprake is, vul dan ‘NANUM’ in om aan te geven dat er geen account identificatie bestaat binnen de financiële instelling.

Condities Verplicht

Toelichting Als AccountNumber@AccountNumberType = OECD601, dan moet de structuur van het

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 32

AccountNumber voldoen aan de structuur voor een IBAN-nummer, die maximaal 34 posities lang is en varieert per land maar voldoet altijd aan: - landcode volgens ISO 3166-1 alpha-2 - twee cijfers als controle getal - een rekeningidentificatie bestaande uit maximaal 30 cijfers en letters Als AccountNumber@AccountNumberType = OECD603, dan moet de structuur van het AccountNumber voldoen aan de structuur voor een ISIN-nummer, die twaalf posities lang is en voldoet aan:: - landcode volgens ISO 3166-1 alpha-2 - negen cijfers als identificatie van account - een cijfer als controlegetal Voor de overige AccountNumberTypes worden geen controles uitgevoerd.

Kardinaliteit 1..1

Formaat xsd:string

Domein Het daadwerkelijke accountnumber of als er geen accountnumber is ‘NANUM’.

gegevensnaam MessageBody - ReportingGroup – AccountReport – AccountNumber – AccountNumberType

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountNumber@AccountNumberType

Omschrijving Type accountnumber met als mogelijke waarden:

OECD601 = IBAN (International Bank Account Number met standaard structuur)

OECD602 = OBAN (Other Bank Account Number)

OECD603 = ISIN (International Securities Information Number; standaard structuur)

OECD604 = OSIN (Other Securities Information Number)

OECD605 = Other (elk ander type accountnummer of verzekeringscontract)

Condities Optioneel

Toelichting Als IBAN of ISIN aanwezig zijn, dan dient dit type accountnumber geleverd te worden.

Kardinaliteit 0..1

Formaat xsd:string (een van de waarden uit Domein)

Domein Waarde bereik is: OECD601, OECD602, OECD603, OECD604, OECD605

gegevensnaam MessageBody - ReportingGroup – AccountReport – AccountNumber – UndocumentedAccount

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountNumber@UndocumentedAccount

Omschrijving Element om aan te geven dat een account niet is gedocumenteerd.

Condities (optioneel) verplicht

Toelichting Dit element is alleen bestemd voor lokaal gebruik (en wordt als zodanig niet gebruikt in het berichtenverkeer tussen financiële instelling in Aruba en DIMP)

Kardinaliteit 0 (niet in gebruik voor Aruba)

Formaat xsd:boolean

Domein ‘true’ en ‘false’.

gegevensnaam MessageBody - ReportingGroup – AccountReport – AccountNumber - ClosedAccount

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountNumber@ClosedAccount

Omschrijving Dit element geeft aan dat het Account gedurende de ReportingPeriod beëindigd is.

Condities (optioneel) verplicht

Toelichting Element wordt alleen gebruikt om aan te geven dat een account beëindigd is. In geval het account nog doorloopt voorbij de ReportingPeriod, dan wordt ClosedAccount niet geleverd.

Kardinaliteit 0..1 (alleen te leveren met ‘true’, i.c. als account is beëindigd in de ReportingPeriod)

Formaat xsd:boolean

Domein Alleen ‘true’ (beëindigd account) wordt gebruikt. Er wordt geen gebruik gemaakt van ‘false’ (niet beëindigd account); element wordt dan niet geleverd.

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 33

NB

In het FATCA XML berichtschema versie 2.0 is AccountClosed een aparte veld tussen Accountnumber en AccountHolder. De

verstrekfunctie van de MDES plaatst de waarde uit AccountNumber@ClosedAccount in het FATCA CRS XML berichtschema

versie 2.0 in het aparte veld AccountClosed in het FATCA XML berichtschema versie 2.0. Het CRS XML berichtschema v1.0

komt qua structuur overeen met FATCA CRS XML bericht v2.0 (en bevat dus AccountNumber@ClosedAccount).

gegevensnaam MessageBody - ReportingGroup – AccountReport – AccountNumber - DormantAccount

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountNumber@DormantAccount

Omschrijving Dit element geeft aan dat een Account gedurende de gehele ReportingPeriod slapende is.

Condities Optioneel

Toelichting Element wordt alleen gebruikt om aan te geven dat een account slapende is.

Kardinaliteit 0..1 (alleen te leveren met ‘true’, i.c. als het account slapende is)

Formaat xsd:boolean

Domein Alleen ‘true’ (slapend account) wordt gebruikt. Er wordt geen gebruik gemaakt van ‘false’ (niet slapend account); element wordt dan niet geleverd.

6.3.2.3.2. AccountReport - AccountHolder

Als de AccountHolder een natuurlijk persoon is, dan wordt de gegevensgroep Individual gevuld geleverd.

Als de AccountHolder geen natuurlijk persoon is, dan wordt de gegevensgroep Organisation gevuld geleverd.

Eén van de twee gegevensgroepen is gevuld.

Verder wordt bij Accountholder Organisation type AccountHolder alleen voor CRS geleverd.

Is er sprake van een ‘UndocumentedAccount’ (zie paragraaf 6.3.2.3.1), dan wordt bij Adresgegevens geleverd:

- CountryCode = CW (‘domestic’ land)

- als verder niets van het adres bekend is, wordt AddressFree geleverd met ‘undocumented’ als tekst.

Dit geldt zowel voor Accountholder Individual als voor Accountholder Organisation.

6.3.2.3.2.1. AccountHolder - Individual

Als een AccountHolder een natuurlijk persoon is, dan wordt gegevensgroep Individual geleverd, bestaande uit:

ResCountryCode(s)

Recalcitrant (true/falce) alleen van belang voor de FATCA; wordt niet geleverd aan MCAA-landen

TIN (Tax Identification Number) binnen elke ResCountryCode, bestaande uit:

o de identificatie als zodanig,

o IssuedBy

Naam of namen van de AccountHolder, een natuurlijk persoon (minstens één naam is verplicht en

meerdere namen is mogelijk) bestaande uit:

o een typeaanduiding van die naam

o Voorafgaande Titel

o Titel

o Voornaam

o Tussenvoegsel

o Voorvoegsel

o Achternaam

o Generatie identificatie

o Achtervoegsel

o Algemeen Achtervoegsel

Adres(sen) van de AccountHolder, een natuurlijk persoon (minimaal één adres en meerdere zijn mogelijk),

bestaande uit:

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 34

o de landcode

o een typeaanduiding van het adres

o het adres als zodanig

in een fixed formaat (optioneel aangevuld met AddressFree voor aanvulling) met als attributen:

straat

gebouw identificatie

suite identificatie

floor identificatie

district naam

postbus

postcode

stad

landsonderdeel

of free format (AddressFree)

het adres als xsd:string

Nationaliteit (wordt geen gebruik van gemaakt)

Geboorte gegevens van de AccountHolder (natuurlijk persoon), bestaande uit:

o Geboortedatum

o Geboorteplaats

o Stadsdeel geboorteplaats

o Geboorteland informatie (een van de twee):

Geboorteland (code) in geval huidige jurisdiction het geboorteland is

Geboorteland (naam) in geval huidige jurisdiction niet het geboorteland is

Kardinaliteit is weergegeven voor de situatie, dat de AccountHolder een natuurlijk persoon is.

gegevensnaam MessageBody - ReportingGroup – AccountReport - AccountHolder - Individual - ResCountryCode

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Individual/ResCountryCode

Omschrijving De landcode van de ‘tax residence’ van de AccountHolder (een natuurlijk persoon).

Condities Het element ResCountryCode wordt bij AccountHolder/Individual zo vaak herhaald als dat er sprake is van Jurisdiction(s) of Residence .

Toelichting Via ResCountryCode wordt aangegeven voor welke landen dit Account van belang is. Er wordt voor elk MCAA-land dat een Jurisdiction of Residence voor de accountholder is (CRS) een element ResCountryCode opgenomen:

als de jurisdiction of residence van de accountholder bijvoorbeeld Italië is, dan is er een element ResCountryCode gevuld met ‘IT’

Kardinaliteit 1..N (altijd één element gevuld geleverd)

Formaat xsd:string (2 posities)

Domein Landcode moet voldoen aan ISO-3166-1

gegevensnaam MessageBody - ReportingGroup – AccountReport – AccountHolder – Individual – Recalcitrant

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Individual/Recalcitrant

Omschrijving Element om aan te geven dat een accountholder individual recalcitrant is. Dit element is altijd aanwezig:

ingeval van een recalcitrante accountholder individual is de waarde ‘true’.

is dat niet het geval, dan is de waarde ‘false’.

Condities Verplicht

Toelichting Geen

Kardinaliteit 1..1

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 35

Formaat xsd:boolean

Domein ‘true’ (als de accountholder individual recalcitrant is) ‘false’ (als de accountholder organisation niet recalcitrant is)

De elementen hierna vormen het Tax Identification Number (TIN) van de AccountHolder (natuurlijk persoon).

gegevensnaam MessageBody - ReportingGroup – AccountReport - AccountHolder - Individual – TIN

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Individual/TIN

Omschrijving TIN (Tax Identification Number) van de AccountHolder Individual in het land waarvoor de gegevens bestemd zijn (een MCAA-land). Voor elke ResCountryCode een TIN als die bekend is. Als voor een MCAA-land de TIN niet beschikbaar is in de administratie van de financiële instelling dan hoeft het element (en TIN@IssuedBy) niet geleverd te worden. Wel zal bij verstrekking aan het MCAA-land een notificatie terugkomen dat de TIN verplicht is. Als de TIN absoluut niet bekend is, dan is vullen met ‘000000000’ (negen nullen) het beste alternatief.

Condities (Optioneel) Verplicht

Toelichting Voor CRS is dit de TIN in de betreffende Jurisdiction of Residence (meer dan één is mogelijk) De elementen TIN en TIN@IssuedBy horen bij elkaar (en zijn optioneel). Als TIN wordt geleverd dan is TIN@IssuedBy verplicht :

in geval van jurisdiction of residence voor CRS is Italië moeten de elementen “de TIN in Italië” en met ‘IT’ gevuld worden.

Bij meerdere jurisdictions of residence in het kader van CRS moet voor elke jurisdiction of residence een element worden ingevuld. TIN@IssuedBy moet een van de landcodes bij ResCountryCode van de AccountHolder Individual zijn. Voor een account dat al bestond voordat het een reportable account werd, zijn TIN’s niet verplicht als deze niet noodzakelijk is onder de lokale wetgeving. Van een financiële instelling verwacht zich redelijkerwijs in tespannen om de TIN in het tweede kalenderjaar volgend op het eerste jaar waarin het account reportable is, wel te leveren voor bestaande accounts.

Kardinaliteit 0..N

Formaat xsd:stringMax200 (en de TIN moet voldoen aan het formaat dat in het IssuedBy land geldt)

Domein Maximaal 200 karakters

gegevensnaam MessageBody - ReportingGroup – AccountReport - AccountHolder – Individual - TIN – IssuedBy

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Individual/TIN@IssuedBy

Omschrijving beschrijving van de ‘jurisdiction’ die de TIN heeft uitgegeven

Condities Verplicht als TIN geleverd wordt

Toelichting Het land waarin de TIN geldt

Kardinaliteit 1..1

Formaat xsd:string (2 posities)

Domein Landcode moet voldoen aan ISO-3166-1 En moet een van de ResCountryCodes bij deze AccountHolder zijn.

Voor een AccountHolder Individual is één naam (met attributen) verplicht en zijn meerdere namen (met

attributen) mogelijk. De elementen hierna vormen de naam van de AccountHolder (een natuurlijk persoon).

gegevensnaam MessageBody - ReportingGroup - AccountReport - AccountHolder - Individual – Name - NameType

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Individual/Name@NameType

Omschrijving Type naam met als mogelijke waarden:

OECD202 = indiv

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 36

OECD203 = alias

OECD204 = nick

OECD205 = aka (also known as)

OECD206 = dba (does business as)

OECD207 = legal

OECD208 = naam bij geboorte

Condities Optioneel

Toelichting Element wordt gebruikt voor CRS en wordt niet gebruikt voor FATCA. OECD201 (gereserveerd voor SMFAliasOrOther) wordt niet gebruikt.

Kardinaliteit 0..1

Formaat xsd:string (met een waarde uit waarde bereik in domein)

Domein Waarde bereik is: OECD202, OECD203, OECD204, OECD205, OECD206, OECD207, OECD208

gegevensnaam MessageBody - ReportingGroup - AccountReport - AccountHolder - Individual – Name – PreceedingTitle

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Individual/Name/PreceedingTitle

Omschrijving Aanhef

Condities Optioneel

Toelichting Bijvoorbeeld ‘His Excellency’

Kardinaliteit 0..1

Formaat xsd:stringMax200

Domein Maximaal 200 karakters

gegevensnaam MessageBody - ReportingGroup - AccountReport - AccountHolder - Individual – Name - Title

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Individual/Name/Title

Omschrijving Titel

Condities Optioneel

Toelichting Bijvoorbeeld ‘Dr.’, maar ook ‘mevrouw’, ‘de heer’

Kardinaliteit 0..N

Formaat xsd:stringMax200

Domein Maximaal 200 karakters

gegevensnaam MessageBody - ReportingGroup - AccountReport - AccountHolder - Individual – Name - FirstName

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Individual/Name/FirstName

Omschrijving Voornaam

Condities Verplicht voor CRS en vanaf belastingjaar 2016 ook verplicht voor FATCA. Als Accountholder Individual geen voornaam heeft, dan moet ‘NFN’ worden ingevuld als voornaam.

Toelichting Geen

Kardinaliteit 1..1

Formaat xsd:stringMax200

Domein Maximaal 200 karakters

gegevensnaam MessageBody - ReportingGroup - AccountReport - AccountHolder - Individual – Name – FirstName - xnlNameType

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Individual/Name /FirstName@xnlNameType

Omschrijving xnlNameType bij FirstName geeft aan welk type naam de FirstName is. Voorbeelden zijn:

given name

forename

Christian name

father’s name

etc. In sommige landen kan de FirstName een familienaam of een achternaam zijn.

Condities Optioneel

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 37

Toelichting geen

Kardinaliteit 0..1

Formaat xsd:string

Domein zie omschrijving

gegevensnaam MessageBody - ReportingGroup - AccountReport - AccountHolder - Individual – Name – MiddleName

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Individual/Name/MiddleName

Omschrijving Middelste naam

Condities Optioneel

Toelichting Is voor vele nationaliteiten een belangrijk onderdeel van de naam

Kardinaliteit 0..N

Formaat xsd:stringMax200

Domein Maximaal 200 karakters

gegevensnaam MessageBody - ReportingGroup - AccountReport - AccountHolder - Individual – Name – MiddleName – xnlNameType

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Individual/Name /MiddleName@xnlNameType

Omschrijving xnlNameType bij MiddleName geeft aan welk type naam de MiddleName is. Voorbeelden zijn:

first name

middle name

maiden name

father’s name

given name

etc.

Condities Optioneel

Toelichting geen

Kardinaliteit 0..1

Formaat xsd:string

Domein zie omschrijving

gegevensnaam MessageBody - ReportingGroup - AccountReport - AccountHolder - Individual – Name – NamePrefix

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Individual/Name/NamePrefix

Omschrijving Naamvoorvoegsel

Condities Optioneel

Toelichting Voorbeelden zijn ‘van de’ of ‘von’

Kardinaliteit 0..1

Formaat xsd:stringMax200

Domein Maximaal 200 karakters

gegevensnaam MessageBody - ReportingGroup - AccountReport - AccountHolder - Individual – Name – NamePrefix – xnlNameType

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Individual/Name /NamePrefix@xnlNameType

Omschrijving xnlNameType bij NamePrefix geeft aan welk type naam de NamePrefix is. Voorbeelden zijn:

de

van

van de

von

etc.

Condities Optioneel

Toelichting geen

Kardinaliteit 0..1

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 38

Formaat xsd:string

Domein zie omschrijving

gegevensnaam MessageBody - ReportingGroup - AccountReport - AccountHolder - Individual – Name - LastName

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Individual/Name/LastName

Omschrijving Achternaam

Condities Verplicht

Toelichting Voor een AccountHolder (natuurlijk persoon) is de achternaam een verplicht te leveren element.

Kardinaliteit 1..1

Formaat xsd:stringMax200

Domein Maximaal 200 karakters

gegevensnaam MessageBody - ReportingGroup - AccountReport - AccountHolder - Individual – Name – LastName - xnlNameType

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Individual/Name /LastName@xnlNameType

Omschrijving xnlNameType bij LastName geeft aan welk type naam de LastName is. Voorbeelden zijn:

father’s name

family name

achternaam

mother’s name

etc. In sommige landen kan de LastName een ‘given name’ of een ‘firstname’ zijn.

Condities Optioneel

Toelichting geen

Kardinaliteit 0..1

Formaat xsd:string

Domein zie omschrijving

gegevensnaam MessageBody - ReportingGroup - AccountReport - AccountHolder - Individual – Name –GenerationIdentifier

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Individual/Name/GenerationIdentifier

Omschrijving Generatie aanduiding

Condities Optioneel

Toelichting Bijvoorbeeld ‘III’ of ‘Third’

Kardinaliteit 0..N

Formaat xsd:stringMax200

Domein Maximaal 200 karakters

gegevensnaam MessageBody - ReportingGroup - AccountReport - AccountHolder - Individual – Name – Suffix

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Individual/Name/Suffix

Omschrijving Naamachtervoegsel

Condities Optioneel

Toelichting Voorbeeld is ‘PhD’

Kardinaliteit 0..N

Formaat xsd:stringMax200

Domein Maximaal 200 karakters

gegevensnaam MessageBody - ReportingGroup - AccountReport - AccountHolder - Individual – Name – GeneralSuffix

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Individual/Name/GeneralSuffix

Omschrijving Algemeen achtervoegsel

Condities Optioneel

Toelichting Bijvoorbeeld ‘retired’

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 39

Kardinaliteit 0..1

Formaat xsd:stringMax200

Domein Maximaal 200 karakters

Minimaal één adres moet geleverd worden en meerdere adressen zijn mogelijk. Een adres wordt geleverd:

als AddressFix (het adres wordt dan weergegeven in een aantal elementen) met optioneel gebruik van

AddressFree voor aanvulling op de AddressFix elementen

als AddressFree (vrije tekst in één element)

In beide gevallen moet het adres voorzien zijn van landcode (CountryCode) en adrestype (AddressType).

gegevensnaam MessageBody - ReportingGroup – AccountReport - AccountHolder - Individual - Address – AddressType

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Individual/Address@AddressType

Omschrijving Dit element geeft aan welk soort adres het AccountHolder adres is (natuurlijk persoon)

Condities Optioneel

Toelichting Er wordt een aantal adressoorten onderkend, te weten:

OECD301 = residential or business

OECD302 = residential

OECD303 = business

OECD304 = registered office

OECD305 = unspecified Als er sprake is van een ‘UndocumentedAccount’, lever dan OECD305.

Kardinaliteit 0..1

Formaat xsd:string (een van de waarden uit Domein)

Domein De waarden zijn: OECD301, OECD302, OECD303, OECD304, OECD305.

gegevensnaam MessageBody - ReportingGroup – AccountReport - AccountHolder - Individual - Address –CountryCode

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Individual/Address/CountryCode

Omschrijving De landcode van het land waar de AccountHolder (natuurlijk persoon) is gevestigd. Voor wat te leveren bij een ‘undocumented account’ zie inleiding paragraaf 6.3.2.3.2.

Condities Verplicht (controle op voorkomen in de ISO-3166-1 standard)

Toelichting Geen

Kardinaliteit 1..1

Formaat xsd;string (2 posities) en dient te voldoen aan de ISO-3166-1 standard

Domein Waarden volgens de ISO-3166-1 standard

Elementen uit AddressFix zijn Street, BuidingIdentifier, SuiteIdentifier, FloorIdentifier, DistrictName, POB,

PostCode, City en CountrySubentity optioneel met AddressFree voor aanvullende informatie. CRS geeft de

voorkeur aan adressen in de vorm van een AddressFix weergave. Alleen als het niet anders kan, dan is een

adres in AddressFree weergave toegestaan.

gegevensnaam MessageBody - ReportingGroup – AccountReport - AccountHolder - Individual - Address – AddressFix – Street

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Individual/Address/AddressFix/Street

Omschrijving Straatnaam van het AccountHolder adres (natuurlijk persoon)

Condities Optioneel

Toelichting Geen

Kardinaliteit 0..1

Formaat xsd:stringMax200

Domein Maximaal 200 karakters

gegevensnaam MessageBody-ReportingGroup–AccountReport - AccountHolder-Individual–Address –AddressFix–BuildingIdentifier

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Individual/Address /AddressFix/BuildingIdentifier

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 40

Omschrijving Gebouw identificatie, indien van toepassing in het AccountHolder adres (natuurlijk persoon)

Condities Optioneel

Toelichting Geen

Kardinaliteit 0..1

Formaat xsd:stringMax200

Domein Maximaal 200 karakters

gegevensnaam MessageBody-ReportingGroup–AccountReport-AccountHolder - Individual – Address – AddressFix – SuiteIdentifier

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Individual/Address /AddressFix/SuiteIdentifier

Omschrijving Suite identificatie, indien van toepassing in het AccountHolder adres (een natuurlijk persoon)

Condities Optioneel

Toelichting Geen

Kardinaliteit 0..1

Formaat xsd:stringMax200

Domein Maximaal 200 karakters

gegevensnaam MessageBody-ReportingGroup-AccountReport - AccountHolder - Individual – Address – AddressFix – FloorIdentifier

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Individual/Address /AddressFix/FloorIdentifier

Omschrijving Etage identificatie, indien van toepassing in het AccountHolder adres (natuurlijk persoon)

Condities Optioneel

Toelichting Geen

Kardinaliteit 0..1

Formaat xsd:stringMax200

Domein Maximaal 200 karakters

gegevensnaam MessageBody-ReportingGroup-AccountReport- AccountHolder - Individual – Address – AddressFix – Districtname

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Individual/Address /AddressFix/DistrictName

Omschrijving Naam van het district, indien van toepassing in het AccountHolder adres (natuurlijk persoon)

Condities Optioneel

Toelichting Geen

Kardinaliteit 0..1

Formaat xsd:stringMax200

Domein Maximaal 200 karakters

gegevensnaam MessageBody - ReportingGroup - AccountReport - AccountHolder - Individual – Address – AddressFix – POB

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Individual/Address/ AddressFix/POB

Omschrijving Postbus nummer, indien van toepassing in het AccountHolder adres (natuurlijk persoon)

Condities Optioneel

Toelichting Geen

Kardinaliteit 0..1

Formaat xsd:stringMax200

Domein Maximaal 200 karakters

gegevensnaam MessageBody - ReportingGroup - AccountReport - AccountHolder - Individual – Address – AddressFix – PostCode

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Individual/Address/

AddressFix/PostCode

Omschrijving Postcode, indien van toepassing in het AccountHolder adres (natuurlijk persoon)

Condities Optioneel

Toelichting In Aruba wordt geen gebruik gemaakt van postcodes.

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 41

Als het vestigingsland Aruba is, dan zal PostCode blanco zijn.

Kardinaliteit 0..1

Formaat xsd:stringMax200

Domein Maximaal 200 karakters

gegevensnaam MessageBody - ReportingGroup – AccountReport - AccountHolder - Individual – Address – AddressFix – City

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Individual/Address/ AddressFix/City

Omschrijving Plaatsnaam in het AccountHolder adres (natuurlijk persoon)

Condities Verplicht

Toelichting De plaatsnaam is verplicht en wordt gebruikt voor validatie

Kardinaliteit 1..1

Formaat xsd:stringMax200

Domein Maximaal 200 karakters

gegevensnaam MessageBody-ReportingGroup-AccountReport-AccountHolder-Individual–Address – AddressFix – CountrySubentity

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Individual/Address /AddressFix/CountrySubentity

Omschrijving Landsonderdeel, indien van toepassing in het AccountHolder adres (natuurlijk persoon)

Condities Optioneel

Toelichting Geen

Kardinaliteit 0..1

Formaat xsd:stringMax200

Domein Maximaal 200 karakters

AddressFree bestaat uit één element (xsd:string).

gegevensnaam MessageBody - ReportingGroup – AccountReport - AccountHolder - Individual - Address – AddressFree

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Individual/Address /AddressFree

Omschrijving Vrije tekst omschrijving van het adres.

Condities Optioneel

Toelichting Alleen te gebruiken als de elementen uit AddressFix niet geleverd kunnen worden voor het AccountHolder adres (natuurlijk persoon).

Of optioneel te gebruiken als aanvulling op de gegevens in het AddressFix formaat. AddressFree mag maximaal 4000 karakters lang zijn. Voor wat te leveren bij een ‘undocumented account’ zie inleiding paragraaf 6.3.2.3.2.

Kardinaliteit 0..1

Formaat xsd:stringMax4000

Domein Maximaal 4000 karakters

Het element hierna betreft nationaliteit van de AccountHolder (een natuurlijk persoon). Dit element wordt

noch voor FATCA noch voor CRS benut en wordt dus niet worden gevraagd om te leveren.

gegevensnaam MessageBody - ReportingGroup - AccountReport - AccountHolder - Individual – Nationality

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Individual/Nationality

Omschrijving Nationaliteit van de AccountHolder (natuurlijk persoon) – niet te gebruiken (zie toelichting)

Condities Optioneel (niet leveren)

Toelichting In "Standard for Automatic Exchange of Financial Accunt Information in Tax Matters" van de OECD (pagina 241) staat 'This data element is not required voor CRS and should not be completed'. FATCA gebruikt dit gegeven op dezelfde manier. Reden waarom in de Handleiding is opgenomen dat het gegeven niet geleverd dient te worden.

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 42

Kardinaliteit 0..0 (niet te gebruiken)

Formaat xsd:string

Domein n.v.t.

De elementen hierna vormen de geboorte gegevens van de AccountHolder (een natuurlijk persoon).

FATCA maakt alleen gebruik van geboortedatum.

gegevensnaam MessageBody - ReportingGroup - AccountReport - AccountHolder - Individual – BirthInfo – BirthDate

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Individual/BirthInfo/BirthDate

Omschrijving Geboortedatum van AccountHolder (natuurlijk persoon)

Condities (optioneel) verplicht

Toelichting Geboortedatum mag leeg gelaten worden als het een reeds bestaand account is en de financiële instelling niet in staat is de geboortedatum te achterhalen.

Kardinaliteit 0..1

Formaat YYYY-MM-DD

Domein Een datum in het verleden

gegevensnaam MessageBody - ReportingGroup - AccountReport - AccountHolder - Individual – BirthInfo – City

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Individual/BirthInfo/City

Omschrijving Geboorteplaats van AccountHolder (natuurlijk persoon)

Condities Optioneel (en niet in gebruik voor FATCA)

Toelichting Geboorteplaats mag leeg gelaten worden.

Kardinaliteit 0..1

Formaat xsd:stringMax200

Domein Maximaal 200 karakters

Een van de twee onderstaande elementen wordt gevuld geleverd als geboorteplaats of geboorteplaats en

stadsdeel gevuld zijn. Het kan zijn:

huidige jurisdiction (landcode volgens ISO-3166-1 standaard in BirthInfo/CountryInfo/CountryCode) of

een vroegere jurisdiction (naam van het land in BirthInfo/CountryInfo/FormerCountryName).

Gegevensnaam MessageBody - ReportingGroup - AccountReport - AccountHolder - Individual – BirthInfo – CountryInfo – CountryCode

Xpath (XML) FATCA_CRS/MessageBody//ReportingGroup/AccountReport/AccountHolder/Individual/BirthInfo /CountryInfo/CountryCode

Omschrijving Geboorteland van AccountHolder (natuurlijk persoon)

Condities Optioneel (en niet in gebruik voor FATCA)

Toelichting Landcode van geboorteland is gevuld als Geboorteplaats (al dan niet met Stadsdeel) is ingevuld en de huidige jurisdiction het geboorteland is.

Kardinaliteit 0..1

Formaat xsd:string (2 posities)

Domein Landcode volgens ISO-3166-1 formaat

Gegevensnaam MessageBody - ReportingGroup - AccountReport - AccountHolder - Individual – BirthInfo – CountryInfo – FormerCountryName

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Individual/BirthInfo /CountryInfo/FormerCountryName

Omschrijving Geboorteland van de AccountHolder (natuurlijk persoon)

Condities Optioneel (en niet in gebruik voor FATCA)

Toelichting Naam van het geboorteland is gevuld als Geboorteplaats (al dan niet met Stadsdeel) is ingevuld en de huidige jurisdiction niet het geboorteland is.

Kardinaliteit 0..1

Formaat xsd:stringMax200

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 43

Domein Maximaal 200 karakters

6.3.2.3.2.2. AccountHolder - Organisation

Als een AccountHolder een niet natuurlijk persoon is, dan wordt de gegevensgroep Organisation geleverd,

bestaande uit:

ResCountryCode(s)

Recalcitrant (true/falce) alleen van belang voor de FATCA; wordt niet geleverd aan MCAA-landen

TIN (identification Number) binnen elke ResCountryCode, bestaande uit:

o de identificatie als zodanig,

o IssuedBy

Naam of namen van de niet natuurlijke persoon als AccountHolder (minimaal één naam is verplicht en

meerdere namen is mogelijk), bestaande uit:

o de naam als zodanig

o een typeaanduiding van die naam

Adres(sen) van de niet natuurlijke persoon als AccountHolder (minimaal één adres en meerdere zijn

mogelijk), bestaande uit:

o de landcode

o een typeaanduiding van het adres

o het adres als zodanig

in een fixed formaat (optioneel aangevuld met AddressFree voor aanvulling) met als attributen:

straat

gebouw identificatie

suite identificatie

floor identificatie

district naam

postbus

postcode

stad

landsonderdeel

of free format (AddressFree)

het adres als xsd:stringMax4000

en ook:

AcctHolderTypeFATCA (als bij ResCountryCode ‘US’ voorkomt)

AcctHolderTypeCRS (als bij ResCountryCode een of meer MCAA-landen als jurisdictions of residence staan

Kardinaliteit is weergegeven voor de situatie, dat de AccountHolder een niet natuurlijk persoon is.

Gegevensnaam MessageBody - ReportingGroup – AccountReport - AccountHolder - Organisation – ResCountryCode

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Organisation/ResCountryCode

Omschrijving De landcode van de ‘tax residence’ van de AccountHolder (niet natuurlijk persoon).

Condities Het element ResCountryCode wordt bij AccountHolder/Organisation zo vaak herhaald als dat er sprake is van Jurisdiction(s) of Residence .

Toelichting Via ResCountryCode wordt aangegeven voor welke landen dit Account van belang is. Er wordt voor elk MCAA-land dat een jurisdiction of residence voor de accountholder is (CRS) een element ResCountryCode opgenomen:

als de jurisdiction of residence van de accountholder Italië is, dan is er een element ResCountryCode gevuld met ‘IT’

Kardinaliteit 1..N (altijd één element gevuld geleverd)

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 44

Formaat xsd:string (2 posities)

Domein Landcode moet voldoen aan ISO-3166-1

gegevensnaam MessageBody - ReportingGroup – AccountReport – AccountHolder – Organisation – Recalcitrant

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Organisation/Recalcitrant

Omschrijving Element om aan te geven dat een accountholder organisation recalcitrant is. Dit element is altijd aanwezig:

ingeval van een recalcitrante accountholder individual is de waarde ‘true’.

Is dat niet het geval, dan is de waarde ‘false’

Condities Verplicht

Toelichting Geen

Kardinaliteit 1..1

Formaat xsd:boolean

Domein ‘true’ (als de accountholder organisation recalcitrant is) ‘false’ (als de accountholder organisation niet recalcitrant is)

De elementen hierna vormen het Identification Number (IN) van de AccountHolder (niet natuurlijk persoon).

Gegevensnaam MessageBody - ReportingGroup – AccountReport - AccountHolder - Organisation – TIN

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Organisation/TIN

Omschrijving TIN (Tax Identification Number) van de AccountHolder organisation in het land waarvoor de gegevens bestemd zijn (een MCAA-land). Voor elke ResCountryCode een TIN. Als voor een MCAA-land de TIN niet beschikbaar is in de administratie van de financiële instelling, dan mag TIN (en TIN@IssuedBy) niet geleverd worden. Wel zal bij verstrekking aan het MCAA-land een notificatie terugkomen dat de TIN verplicht is. Als de TIN absoluut niet bekend is, dan is vullen met ‘000000000’ (negen nullen) het beste alternatief.

Condities (Optioneel) Verplicht

Toelichting Voor CRS is het de TIN in de betreffende Jurisdiction of Residence (meer dan één is mogelijk). Het betreft een TIN van een niet natuurlijk persoon. De elementen TIN en TIN@IssuedBy horen bij elkaar (en zijn optioneel). Als TIN wordt geleverd dan is TIN@IssuedBy verplicht :

in geval van jurisdiction of residence voor CRS is Italië moeten de elementen met de TIN in Italië en met ‘IT’ gevuld worden.

Bij meerdere jurisdictions of residence in het kader van CRS moet voor elke jurisdiction of residence een element worden ingevuld. TIN@IssuedBy moet een van de landcodes bij ResCountryCode van de AccountHolder Organisation zijn. Voor een account dat al bestond voordat het een reportable account werd, zijn TIN’s niet verplicht als deze niet noodzakelijk is onder de lokale wetgeving. Van een financiële instelling wordt verwacht zich redelijkerwijs in te spannen om de TIN in het tweede kalenderjaar volgend op het eerste jaar waarin het account reportable is, de TIN wel te leveren voor bestaande accounts.

Kardinaliteit 0..N

Formaat xsd:stringMax200

Domein Maximal 200 karakters

Gegevensnaam MessageBody - ReportingGroup – AccountReport - AccountHolder - Organisation - TIN – IssuedBy

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 45

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Organisation /TIN@IssuedBy

Omschrijving beschrijving van de ‘jurisdiction’ die de TIN heeft uitgegeven

Condities Verplicht als TIN geleverd wordt

Toelichting Het land waarin de TIN geldt

Kardinaliteit 1..1

Formaat xsd:string (2 posities)

Domein Landcode moet voldoen aan ISO-3166-1 En moet een van de ResCountryCodes bij deze AccountHolder zijn.

In het XML berichtschema FATCA CRS is vooralsnog het TIN-attribuut INType bij OrganisationParty_Type niet

opgenomen. In het CRS berichtschema komt INType als optioneel attribuut van IN voor.

Voor een AccountHolder Organisation is één naam verplicht en zijn meerdere namen mogelijk. De elementen

hierna vormen de naam van een AccountHolder Organisation (niet natuurlijk persoon).

Gegevensnaam MessageBody - ReportingGroup - AccountReport - AccountHolder - Organisation - Name

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Organisation/Name

Omschrijving De wettelijke naam van de AccountHolder (een niet natuurlijk persoon)

Condities Verplicht

Toelichting Geen

Kardinaliteit 1..N

Formaat xsd:stringMax200

Domein Maximal 200 karakters

Gegevensnaam MessageBody - ReportingGroup – AccountReport - AccountHolder - Organisation - NameType

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Organisation/Name@NameType

Omschrijving Typering van de naam van de AccountHolder (niet gebruikt in het FATCA-CRS bericht)

Condities Optioneel

Toelichting Element wordt alleen gebruikt voor CRS. OECD201 (gereserveerd voor SMFAliasOrOther) wordt niet gebruikt.

Kardinaliteit 0..0 (niet gebruikt)

Formaat xsd:string (met een waarde uit waarde bereik in domein)

Domein Waardebereik is: OECD202, OECD203, OECD204, OECD205, OECD206, OECD207, OECD208

De elementen hierna vormen het adres van de AccountHolder (niet natuurlijk persoon), dat op twee manieren

kan worden geleverd:

als AddressFix (het adres wordt dan weergegeven in een aantal elementen) met optioneel gebruik van

AddressFree voor aanvulling op de AddressFix elementen

als AddressFree (vrije tekst in één element)

In beide gevallen wordt het adres voorzien van landcode (CountryCode) en een adrestype (AddressType).

Gegevensnaam MessageBody-ReportingGroup–AccountReport-AccountHolder-Organisation - Address – AddressType

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Organisation /Address@AddressType

Omschrijving Dit element geeft aan welk soort adres het AccountHolder adres is (niet natuurlijk persoon)

Condities Optioneel

Toelichting Er wordt een aantal adressoorten onderkend, te weten:

OECD301 = residential or business

OECD302 = residential

OECD303 = business

OECD304 = registered office

OECD305 = unspecified

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 46

Als er sprake is van een ‘UndocumentedAccount’, lever dan OECD305.

Kardinaliteit 0..1

Formaat xsd:string (een van de waarden uit Domein)

Domein De waarden zijn: OECD301, OECD302, OECD303, OECD304, OECD305.

Gegevensnaam MessageBody-ReportingGroup–AccountReport-AccountHolder-Organisation - Address – CountryCode

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Organisation/Address /CountryCode

Omschrijving De landcode van het land waar de AccountHolder (niet natuurlijk persoon) is gevestigd. Voor wat te leveren bij een ‘undocumented account’ zie inleiding paragraaf 6.3.2.3.2.

Condities Verplicht (controle op voorkomen in de ISO-3166-1 standard)

Toelichting Geen

Kardinaliteit 1..1

Formaat xsd;string (2 posities) en voldoet aan ISO-3166-1 standard

Domein Waarden volgens de ISO-3166-1 standard

Elementen uit AddressFix zijn Street, BuidingIdentifier, SuiteIdentifier, FloorIdentifier, DistrictName, POB,

PostCode, City en CountrySubentity optioneel met AddressFree voor aanvullende informatie. CRS geeft de

voorkeur aan adressen in de vorm van een AddressFix weergave. Alleen als het niet anders kan, dan is een

adres in AddressFree weergave toegestaan.

gegevensnaam MessageBody-ReportingGroup–AccountReport-AccountHolder-Organisation-Address–AddressFix–Street

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Organisation/Address /AddressFix/Street

Omschrijving Straatnaam van het AccountHolder adres (niet natuurlijk persoon)

Condities Optioneel

Toelichting Geen

Kardinaliteit 0..1

Formaat xsd:stringMax200

Domein Maximal 200 karakters

gegevensnaam MessageBody - ReportingGroup – AccountReport - AccountHolder - Organisation – Address – AddressFix – BuildingIdentifier

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Organisation/Address /AddressFix/BuildingIdentifier

Omschrijving Gebouw identificatie, indien van toepassing in het adres van de AccountHolder Organisation

Condities Optioneel

Toelichting Geen

Kardinaliteit 0..1

Formaat xsd:stringMax200

Domein Maximal 200 karakters

gegevensnaam MessageBody - ReportingGroup – AccountReport - AccountHolder - Organisation – Address – AddressFix – SuiteIdentifier

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Organisation/Address /AddressFix/SuiteIdentifier

Omschrijving Suite identificatie, indien van toepassing in het AccountHolder adres (een niet natuurlijk persoon)

Condities Optioneel

Toelichting Geen

Kardinaliteit 0..1

Formaat xsd:stringMax200

Domein Maximal 200 karakters

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 47

gegevensnaam MessageBody - ReportingGroup - AccountReport - AccountHolder - Organisation – Address – AddressFix – FloorIdentifier

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Organisation/Address /AddressFix/FloorIdentifier

Omschrijving Etage identificatie, indien van toepassing in het AccountHolder adres (niet natuurlijk persoon)

Condities Optioneel

Toelichting Geen

Kardinaliteit 0..1

Formaat xsd:stringMax200

Domein Maximal 200 karakters

gegevensnaam MessageBody - ReportingGroup - AccountReport - AccountHolder - Organisation – Address – AddressFix – Districtname

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Organisation/Address /AddressFix/DistrictName

Omschrijving Naam van het district, indien van toepassing in het AccountHolder adres (niet natuurlijk persoon)

Condities Optioneel

Toelichting Geen

Kardinaliteit 0..1

Formaat xsd:stringMax200

Domein Maximal 200 karakters

gegevensnaam MessageBody - ReportingGroup - AccountReport - AccountHolder - Organisation – Address – AddressFix – POB

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Organisation/Address/ AddressFix/POB

Omschrijving Postbus nummer, indien van toepassing in het AccountHolder adres (niet natuurlijk persoon)

Condities Optioneel

Toelichting Geen

Kardinaliteit 0..1

Formaat xsd:stringMax200

Domein Maximal 200 karakters

gegevensnaam MessageBody - ReportingGroup - AccountReport - AccountHolder - Organisation – Address – AddressFix – PostCode

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Organisation/Address/ AddressFix/PostCode

Omschrijving Postcode, indien van toepassing in het AccountHolder adres (niet natuurlijk persoon)

Condities Optioneel

Toelichting In Aruba wordt geen gebruik gemaakt van postcodes. Als het vestigingsland Aruba is, dan zal PostCode blanco zijn.

Kardinaliteit 0..1

Formaat xsd:stringMax200

Domein Maximal 200 karakters

gegevensnaam MessageBody - ReportingGroup – AccountReport - AccountHolder - Organisation – Address – AddressFix – City

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Organisation/Address/ AddressFix/City

Omschrijving Plaatsnaam in het AccountHolder adres (niet natuurlijk persoon)

Condities Verplicht

Toelichting De plaatsnaam is verplicht en wordt gebruikt voor validatie

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 48

Kardinaliteit 1..1

Formaat xsd:stringMax200

Domein Maximal 200 karakters

gegevensnaam MessageBody - ReportingGroup - AccountReport - AccountHolder - Organisation – Address – AddressFix – CountrySubentity

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Organisation/Address/ AddressFix/CountrySubentity

Omschrijving Landsonderdeel, indien van toepassing in het AccountHolder adres (niet natuurlijk persoon)

Condities Optioneel

Toelichting Geen

Kardinaliteit 0..1

Formaat xsd:stringMax200

Domein Maximal 200 karakters

AddressFree bestaat uit één element (xsd:string).

gegevensnaam MessageBody - ReportingGroup – AccountReport - AccountHolder - Organisation - Address – AddressFree

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Organisation/Address /AddressFree

Omschrijving Vrije tekst omschrijving van het adres.

Condities Optioneel

Toelichting Alleen te gebruiken als de elementen uit AddressFix niet geleverd kunnen worden voor het AccountHolder adres (niet natuurlijk persoon).

Of optioneel te gebruiken als aanvulling op de gegevens in het AddressFix formaat. AddressFree mag maximaal 4000 karakters lang zijn. Voor wat te leveren bij een ‘undocumented account’ zie inleiding paragraaf 6.3.2.3.2.

Kardinaliteit 0..1

Formaat xsd:stringMax4000

Domein Maximal 4000 karakters

Voor FATCA en voor CRS worden andere types AccountHolder onderscheiden.Dit is reden geweest om in het

FATCA-CRS bericht twee elementen op te nemen voor AcctHolderType, te weten AcctHolderTypeFATCA en

AcctHolderTypeCRS.

Afhankelijk van de ResCountryCodes bij AccountHolder/Organisation wordt een van de twee of beide of geen

aangeleverd vanuit de financiële instellingen. Het CRS-type als de accountholder (ook) een ander land als

jurisdiction of residence heeft (element is nodig voor CRS-levering).

Gegevensnaam MessageBody-ReportingGroup – AccountReport – AccountHolder – Organisation -AcctHolderTypeCRS

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Organisation /AcctHolderTypeCRS

Omschrijving type AccountHolder ten behoeve van CRS-leveringen. Mogelijke waarden zijn:

CRS101 = Passive Non-Financial Entity with one or more controlling persons that is a Reportable Person

CRS102 = CRS Reportable Person

CRS103 = Passive Non-Financial Entity that is a CRS Reportable Person Als bij AcctHolderTypeCRS als code CRS101 (Passive Non-Financial Entity with one or more controlling persons that is a Reportable Person), dan is de FI of Sponsor verplicht om Controlling Person(s) te leveren voor deze Accountholder Organisation. Het AccountReport wordt in dat geval verstrekt aan MCAA-land(en) van de ControllingPerson(s).

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 49

Als bij AcctHolderTypeCRS als code CRS102 (CRS reportable Person) ofCRS103 (Passive Non-Financial Entity that is a CRS Reportable Person), dan moet de FI of Sponsor geen Controlling Person(s) leveren voor deze Accountholder Organisation.

Condities (optioneel) verplicht

Toelichting Vanaf belastingjaar 2017 moet AcctHolderTypeCRS gevuld zijn als de AccountHolder (een) ander(e) land(en) als jurisdiction of residence heeft.

Kardinaliteit 0..1

Formaat xsd:string (een van de waarden uit Domein)

Domein Waarde bereik is: CRS101, CRS102, CRS103.

6.3.2.3.3. AccountReport – SubstantialOwner (alleen bestemd voor FATCA)

Voor FATCA is het verplicht om bij bepaalde AcctHolderTypeFATCA aan te geven wie SubstantialOwner(s) zijn.

SubstantialOwners zijn niet van toepassing voor leveringen in het kader van de CRS.

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 50

6.3.2.3.4. AccountReport – ControllingPerson

Controlling Person(s) is (zijn) verplicht als AcctHolderTypeCRS in AccountReport gelijk is aan CRS101; de

Accountholder Organisation is een Passive NFE4. Zijn er meerdere ControllingPersons dan moeten alle

ControllingPersons gemeld worden.

ControllingPerson(s) is (zijn) op te vatten als de natuurlijke persoon (personen), die de controle over een

entiteit uitoefent (uitoefenen). In het geval van een Trust, kan dit de oprichter, de trustee, de beschermer, de

begunstigde of groep van begunstigden en andere natuurlijke personen zijn, die feitelijke de volledige controle

uitoefenen over de Trust voor een Passive NFE. In het geval van een andere wettelijke regeling dan een Trust,

kan dit een persoon of personen zijn in een vergelijkbare of soortgelijke positie(s).

Als de ControllingPerson geen ingezetene is van het land van vestiging van de Entiteit, dan moet toch de

informatie over de rekening worden verstrekt.

ControllingPerson(s) mogen bij een Accountholder Organisation met AcctHolderTypeCRS = CRS102 (CRS

Reportable Person) en CRS103 (Passive NFE that is a CRS Reportable Person) niet worden geleverd.

De ResCountryCode(s) van ControllingPersons moeten overeenkomen met de ResCountryCode van de

Accountholder individual c.q. Accountholder Organisation. De enige uitzondering daarop is Accountholder

Organisation met AcctHolderTypeCRS als code CRS101 (Passive Non-Financial Entity with one or more

controlling persons that is a Reportable Person). Voor deze Accountholders mag de ResCountryCode van de

ControllingPerson een andere zijn dan de ResCountryCode(s) van de Accountholder, als het maar een van de

MCAA-landen is waarmee Curaçao CRS-gegevens uitwisselt en mag om die reden geen US-person zijn.

Voor elke ControllingPerson worden de volgende gegevens geleverd:

ResCountryCode(s)

TIN (Tax Identification Number) binnen elke ResCountryCode, bestaande uit:

o de identificatie als zodanig,

o IssuedBy

Naam of namen van de ControllingPerson (minimaal één naam is verplicht en meerdere namen zijn

mogelijk), bestaande uit:

o een typeaanduiding van die naam

o Voorafgaande Titel

o Titel

o Voornaam

o Tussenvoegsel

o Voorvoegsel

o Achternaam

o Generatie identificatie

o Achtervoegsel

o Algemeen Achtervoegsel

Adres(sen) van de ControllingPerson (minimaal één adres en meerdere zijn mogelijk), bestaande uit:

o de landcode

o een typeaanduiding van het adres

o het adres als zodanig

4 Passive NFE = Passive Non-Financial Entity

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 51

in een fixed formaat (optioneel aangevuld met AddressFree voor aanvulling) met als attributen:

straat

gebouw identificatie

suite identificatie

floor identificatie

district naam

postbus

postcode

stad

landsonderdeel

of free format (AddressFree)

het adres als xsd:string

Nationaliteit (wordt geen gebruik van gemaakt)

Geboorte gegevens van de ControllingPerson, bestaande uit:

o Geboortedatum

o Geboorteplaats

o Stadsdeel geboorteplaatsy

o Geboorteland informatie

o Geboorteland (code) in geval huidige jurisdiction het geboorteland is

o Geboorteland (naam) in geval huidige jurisdiction niet het geboorteland is

gegevensnaam MessageBody - ReportingGroup – AccountReport - ControllingPerson - Individual – ResCountryCode

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/ControllingPerson/Individual /ResCountryCode

Omschrijving De landcode(s) van de jurisdiction of residence van de ControllingPerson (een natuurlijk persoon).

Condities In geval van een Passive NFE is er sprake van een of meerdere Controlling Persons. Voor elke jurisdiction of residence worden de account gegevens van de Passive NFE geleverd met de alle Controlling Persons met diezelfde jurisdiction of residence.

Toelichting Per jurisdiction of residence van een of meer Controlling Persons wordt een AccountReport geleverd met accountgegevens van de Passive NFE en andere gerelateerde gegevens. Dit is alleen van toepassing voor CRS-leveringen. Een Controlling Person kan meer dan één jurisdiction of residence hebben.

Kardinaliteit 1..N (altijd één element gevuld geleverd)

Formaat xsd:string (2 posities)

Domein Landcode moet voldoen aan ISO-3166-1 (uitgezonderd ‘US’)

Elementen hierna vormen het Tax Identification Number (TIN) van de ControllingPerson (natuurlijk persoon).

gegevensnaam MessageBody - ReportingGroup – AccountReport - ControllingPerson - Individual – TIN

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/ControllingPerson/Individual/TIN

Omschrijving Het Tax Identificatie Nummer, zoals dat in de Jurisdisctie of Residence van de ControllingPerson (een natuurlijk persoon) aan hem/haar is verstrekt. Voor elke ResCountryCode een TIN voorzover bekend in de administratie van de financiële instelling. Controlling person wordt gebruikt in geval van levering van CRS-gegevens.

Condities Optioneel Verplicht (verplicht, indien aanwezig in administratie van de financiële instelling)

Toelichting Geen

Kardinaliteit 0..N (indien aanwezig in de administratie van de financiële instelling)

Formaat xsd:stringMax200 (formaat van TIN in MCAA-landen is beduidend korter dan 200 karakters)

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 52

Domein Maximaal 200 karakters

gegevensnaam MessageBody - ReportingGroup – AccountReport - ControllingPerson - Individual - TIN – IssuedBy

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/ControllingPerson/Individual /TIN@IssuedBy

Omschrijving beschrijving van de ‘jurisdiction’ die de TIN heeft uitgegeven

Condities Verplicht als de TIN er is)

Toelichting Geen

Kardinaliteit 1..1 (verplicht als TIN geleverd wordt; wordt de TIN niet geleverd dan ook geen TIN@IssuedBy

Formaat xsd:string (2 posities)

Domein Landcode moet voldoen aan ISO-3166-1

Voor een ControllingPerson is één naam (met attributen) verplicht en zijn meerdere namen (met attributen)

mogelijk. De elementen hierna vormen de naam van de ControllingPerson (een natuurlijk persoon).

gegevensnaam MessageBody - ReportingGroup - AccountReport - ControllingPerson - Individual – Name – NameType

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/ControllingPerson/Individual/ Name@NameType

Omschrijving Type naam met als mogelijke waarden:

OECD202 = indiv

OECD203 = alias

OECD204 = nick

OECD205 = aka (also known as)

OECD206 = dba (does business as)

OECD207 = legal

OECD208 = naam bij geboorte

Condities Optioneel

Toelichting Element wordt gebruikt voor CRS en wordt niet gebruikt voor FATCA. Controlling Person is een CRS-gegevensgroep. OECD201 (gereserveerd voor SMFAliasOrOther) wordt niet gebruikt.

Kardinaliteit 0..1

Formaat xsd:string

Domein Waarde bereik is: OECD202, OECD203, OECD204, OECD205, OECD206, OECD207, OECD208

gegevensnaam MessageBody-ReportingGroup-AccountReport-ControllingPerson-Individual – Name – PreceedingTitle

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/ControllingPerson/Individual /Name/PreceedingTitle

Omschrijving Aanhef

Condities Optioneel

Toelichting Bijvoorbeeld ‘His Excellency’

Kardinaliteit 0..1

Formaat xsd:stringMax200

Domein Maximaal 200 karakters

gegevensnaam MessageBody - ReportingGroup - AccountReport - ControllingPerson - Individual – Name - Title

Xpath (XML) FATCA_CRS/ReportingGroup/AccountReport/ControllingPerson/Individual/Name/Title

Omschrijving Titel

Condities Optioneel

Toelichting Bijvoorbeeld ‘Dr.’, maar ook ‘mevrouw’, ‘de heer’

Kardinaliteit 0..N

Formaat xsd:stringMax200

Domein Maximaal 200 karakters

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 53

gegevensnaam MessageBody - ReportingGroup - AccountReport - ControllingPerson - Individual – Name – FirstName

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/ControllingPerson/Individual /Name/FirstName

Omschrijving Voornaam

Condities Firstname is verplicht voor Controlling Person. Als de ControllingPerson geen voornaam heeft, dan moet ‘NFN’ als voornaam worden geleverd.

Toelichting Geen

Kardinaliteit 1..1

Formaat xsd:stringMax200

Domein Maximaal 200 karakters

gegevensnaam MessageBody - ReportingGroup - AccountReport – ControllingPerson - Individual – Name – FirstName – xnlNameType

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/ControllingPerson/Individual/Name /FirstName@xnlNameType

Omschrijving xnlNameType bij FirstName geeft aan welk type naam de FirstName is. Voorbeelden zijn:

given name

forename

Christian name

father’s name

etc. In sommige landen kan de FirstName een familienaam of een achternaam zijn.

Condities Optioneel

Toelichting geen

Kardinaliteit 0..1

Formaat xsd:string

Domein zie omschrijving

gegevensnaam MessageBody-ReportingGroup - AccountReport - ControllingPerson - Individual – Name – MiddleName

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/ControllingPerson/Individual /Name/MiddleName

Omschrijving Middelste naam

Condities Optioneel

Toelichting Is voor vele nationaliteiten een belangrijk onderdeel van de naam

Kardinaliteit 0..N

Formaat xsd:stringMax200

Domein Maximaal 200 karakters

gegevensnaam MessageBody - ReportingGroup - AccountReport - ControllingPerson - Individual – Name – MiddleName – xnlNameType

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/ControllingPerson/Individual/Name /MiddleName@xnlNameType

Omschrijving xnlNameType bij MiddleName geeft aan welk type naam de MiddleName is. Voorbeelden zijn:

first name

middle name

maiden name

father’s name

given name

etc.

Condities Optioneel

Toelichting geen

Kardinaliteit 0..1

Formaat xsd:string

Domein zie omschrijving

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 54

gegevensnaam MessageBody - ReportingGroup - AccountReport - ControllingPerson - Individual – Name – NamePrefix

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/ControllingPerson/Individual /Name/NamePrefix

Omschrijving Naamvoorvoegsel

Condities Optioneel

Toelichting Voorbeelden zijn ‘van de’ of ‘von’

Kardinaliteit 0..1

Formaat xsd:stringMax200

Domein Maximaal 200 karakters

gegevensnaam MessageBody - ReportingGroup - AccountReport - ControllingPerson - Individual – Name – NamePrefix – xnlNameType

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/ControllingPerson/Individual/Name /NamePrefix@xnlNameType

Omschrijving xnlNameType bij NamePrefix geeft aan welk type naam de NamePrefix is. Voorbeelden zijn:

de

van

van de

von

etc.

Condities Optioneel

Toelichting geen

Kardinaliteit 0..1

Formaat xsd:string

Domein zie omschrijving

gegevensnaam MessageBody - ReportingGroup - AccountReport - ControllingPerson - Individual – Name – LastName

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/ControllingPerson/Individual /Name/LastName

Omschrijving Achternaam

Condities Verplicht

Toelichting Voor een ControllingPerson (natuurlijk persoon) is de achternaam een verplicht te leveren element.

Kardinaliteit 1..1

Formaat xsd:stringMax200

Domein Maximaal 200 karakters

gegevensnaam MessageBody - ReportingGroup - AccountReport - ControllingPerson - Individual – Name – LastName - xnlNameType

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/ControllingPerson/Individual/Name /LastName@xnlNameType

Omschrijving xnlNameType bij LastName geeft aan welk type naam de LastName is. Voorbeelden zijn:

father’s name

family name

achternaam

mother’s name

etc. In sommige landen kan de LastName een ‘given name’ of een ‘firstname’ zijn.

Condities Optioneel

Toelichting geen

Kardinaliteit 0..1

Formaat xsd:string

Domein zie omschrijving

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 55

gegevensnaam MessageBody - ReportingGroup - AccountReport - ControllingPerson - Individual – Name - GenerationIdentifier

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/ControllingPerson/Individual /Name/GenerationIdentifier

Omschrijving Generatie aanduiding

Condities Optioneel

Toelichting Bijvoorbeeld ‘III’ of ‘Third’

Kardinaliteit 0..N

Formaat xsd:stringMax200

Domein Maximaal 200 karakters

gegevensnaam MessageBody - ReportingGroup - AccountReport - ControllingPerson - Individual – Name - Suffix

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/ControllingPerson/Individual/Name/Suffix

Omschrijving Naamachtervoegsel

Condities Optioneel

Toelichting Voorbeeld is ‘PhD’

Kardinaliteit 0..N

Formaat xsd:stringMax200

Domein Maximaal 200 karakters

gegevensnaam MessageBody-ReportingGroup-AccountReport - ControllingPerson - Individual – Name – GeneralSuffix

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/ControllingPerson/Individual /Name/GeneralSuffix

Omschrijving Algemeen achtervoegsel

Condities Optioneel

Toelichting Bijvoorbeeld ‘retired’

Kardinaliteit 0..1

Formaat xsd:stringMax200

Domein Maximaal 200 karakters

Minimaal één adres moet geleverd worden en meerdere adressen zijn mogelijk. Een adres wordt geleverd:

als AddressFix (het adres wordt dan weergegeven in een aantal elementen) met optioneel gebruik van

AddressFree voor aanvulling op de AddressFix elementen

als AddressFree (vrije tekst in één element)

In beide gevallen moet het adres voorzien zijn van landcode (CountryCode) en adrestype (AddressType).

gegevensnaam MessageBody-ReportingGroup–AccountReport-ControllingPerson - Individual - Address – AddressType

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/ControllingPerson/Individual /Address@AddressType

Omschrijving Dit element geeft aan welk soort adres het ControllingPerson adres is (natuurlijk persoon)

Condities Optioneel

Toelichting Er wordt een aantal adressoorten onderkend, te weten:

OECD301 = residential or business

OECD302 = residential

OECD303 = business

OECD304 = registered office

OECD305 = unspecified

Kardinaliteit 0..1

Formaat xsd:string (een van de waarden uit Domein)

Domein De waarden zijn: OECD301, OECD302, OECD303, OECD304, OECD305.

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 56

gegevensnaam MessageBody-ReportingGroup–AccountReport-ControllingPerson - Individual - Address – CountryCode

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/ControllingPerson/Individual /Address/CountryCode

Omschrijving De landcode van het land waar de ControllingPerson (natuurlijk persoon) is gevestigd

Condities Verplicht (controle op voorkomen in de ISO-3166-1 standaard)

Toelichting Geen

Kardinaliteit 1..1

Formaat xsd;string (2 posities) en voldoet aan de ISO-3166-1 standard

Domein Waarden volgens de ISO-3166-1 standard

Elementen uit AddressFix zijn Street, BuidingIdentifier, SuiteIdentifier, FloorIdentifier, DistrictName, POB,

PostCode, City en CountrySubentity optioneel met AddressFree voor aanvullende informatie. CRS geeft de

voorkeur aan adressen in de vorm van een AddressFix weergave. Alleen als het niet anders kan, dan is een

adres in AddressFree weergave toegestaan.

gegevensnaam MessageBody - ReportingGroup – AccountReport - ControllingPerson - Individual - Address – AddressFix – Street

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/ControllingPerson/Individual /Address/ AddressFix/Street

Omschrijving Straatnaam van het ControllingPerson adres (natuurlijk persoon)

Condities Optioneel

Toelichting Geen

Kardinaliteit 0..1

Formaat xsd:stringMax200

Domein Maximaal 200 karakters

gegevensnaam MessageBody - ReportingGroup – AccountReport - ControllingPerson - Individual – Address – AddressFix – BuildingIdentifier

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/ControllingPerson/Individual/Address /AddressFix/BuildingIdentifier

Omschrijving Gebouw identificatie, indien van toepassing in het ControllingPerson adres (natuurlijk persoon)

Condities Optioneel

Toelichting Geen

Kardinaliteit 0..1

Formaat xsd:stringMax200

Domein Maximaal 200 karakters

gegevensnaam MessageBody - ReportingGroup – AccountReport - ControllingPerson - Individual – Address – AddressFix – SuiteIdentifier

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/ControllingPerson/Individual/Address /AddressFix/SuiteIdentifier

Omschrijving Suite identificatie, indien van toepassing in het ControllingPerson adres (een natuurlijk persoon)

Condities Optioneel

Toelichting Geen

Kardinaliteit 0..1

Formaat xsd:stringMax200

Domein Maximaal 200 karakters

gegevensnaam MessageBody - ReportingGroup - AccountReport - ControllingPerson - Individual – Address – AddressFix – FloorIdentifier

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/ControllingPerson/Individual/Address/ AddressFix/FloorIdentifier

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 57

Omschrijving Etage identificatie, indien van toepassing in het ControllingPerson adres (natuurlijk persoon)

Condities Optioneel

Toelichting Geen

Kardinaliteit 0..1

Formaat xsd:stringMax200

Domein Maximaal 200 karakters

gegevensnaam MessageBody - ReportingGroup - AccountReport - ControllingPerson - Individual – Address – AddressFix – Districtname

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/ControllingPerson/Individual/Address/ AddressFix/DistrictName

Omschrijving Naam van het district, indien van toepassing in ControllingPerson adres (natuurlijk persoon)

Condities Optioneel

Toelichting Geen

Kardinaliteit 0..1

Formaat xsd:stringMax200

Domein Maximaal 200 karakters

gegevensnaam MessageBody - ReportingGroup - AccountReport - ControllingPerson - Individual – Address – AddressFix – POB

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/ControllingPerson/Individual/Address/ AddressFix/POB

Omschrijving Postbus nummer, indien van toepassing in het ControllingPerson adres (natuurlijk persoon)

Condities Optioneel

Toelichting Geen

Kardinaliteit 0..1

Formaat xsd:stringMax200

Domein Maximaal 200 karakters

gegevensnaam MessageBody - ReportingGroup - AccountReport - ControllingPerson - Individual – Address –

AddressFix – PostCode

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/ControllingPerson/Individual/Address/ AddressFix/PostCode

Omschrijving Postcode, indien van toepassing in het ControllingPerson adres (natuurlijk persoon)

Condities Optioneel

Toelichting In Aruba wordt geen gebruik gemaakt van postcodes. Als het vestigingsland Aruba is, dan zal PostCode blanco zijn.

Kardinaliteit 0..1

Formaat xsd:stringMax200

Domein Maximaal 200 karakters

gegevensnaam MessageBody-ReportingGroup–AccountReport-ControllingPerson-Individual–Address–AddressFix–City

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/ControllingPerson/Individual/Address/ AddressFix/City

Omschrijving Plaatsnaam in het ControllingPerson adres (natuurlijk persoon)

Condities Verplicht

Toelichting De plaatsnaam is verplicht en wordt gebruikt voor validatie

Kardinaliteit 1..1

Formaat xsd:stringMax200

Domein Maximaal 200 karakters

gegevensnaam MessageBody - ReportingGroup - AccountReport - ControllingPerson - Individual – Address – AddressFix - CountrySubentity

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/ControllingPerson/Individual/Address

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 58

/AddressFix/CountrySubentity

Omschrijving Landsonderdeel, indien van toepassing in het ControllingPerson adres (natuurlijk persoon)

Condities Optioneel

Toelichting Geen

Kardinaliteit 0..1

Formaat xsd:stringMax200

Domein Maximaal 200 karakters

AddressFree bestaat uit één element (xsd:string).

gegevensnaam MessageBody - ReportingGroup – AccountReport - ControllingPerson - Individual – Address – AddressFree

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/ControllingPerson/Individual/Address /AddressFree

Omschrijving Vrije tekst omschrijving van het adres.

Condities Optioneel

Toelichting Alleen te gebruiken als de elementen uit AddressFix niet geleverd kunnen worden voor het ControllingPerson adres (natuurlijk persoon).

Of optioneel te gebruiken als aanvulling op de gegevens in het AddressFix formaat. AddressFree mag maximaal 4000 karakters lang zijn.

Kardinaliteit 0..1

Formaat xsd:stringMax4000

Domein Maximaal 4000 karakters

Het element hierna betreft nationaliteit van de ControllingPerson (een natuurlijk persoon). Dit element wordt

noch voor FATCA noch voor CRS benut en zal als zodanig dus niet worden gevraagd om te leveren.

geevensnaam MessageBody- ReportingGroup - AccountReport - ControllingPerson - Individual – Nationality

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/ControllingPerson/Individual/Nationality

Omschrijving Nationaliteit van de ControllingPerson (natuurlijk persoon) – niet te gebruiken (zie toelichting)

Condities Optioneel (niet leveren)

Toelichting In "Standard for Automatic Exchange of Financial Accunt Information in Tax Matters" van de OECD (pagina 241) staat 'This data element is not required voor CRS and should not be completed'. FATCA gebruikt dit gegeven op dezelfde manier. Reden waarom in de Handleiding is opgenomen dat het gegeven niet geleverd dient te worden.

Kardinaliteit 0..0 (niet te gebruiken)

Formaat xsd:string

Domein n.v.t.

De elementen hierna vormen de geboorte gegevens van de Controlling Person (een natuurlijk persoon).

gegevensnaam MessageBody - ReportingGroup - AccountReport - AccountHolder - Individual – BirthInfo – BirthDate

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Individual /BirthInfo/BirthDate

Omschrijving Geboortedatum van AccountHolder (natuurlijk persoon)

Condities (optioneel) verplicht

Toelichting Geboortedatum mag leeg gelaten worden als het een reeds bestaand account is en de financiële instelling niet in staat is de geboortedatum te achterhalen.

Kardinaliteit 0..1

Formaat YYYY-MM-DD

Domein Een datum in het verleden

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 59

gegevensnaam MessageBody - ReportingGroup - AccountReport - AccountHolder - Individual – BirthInfo – City

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountHolder/Individual /BirthInfo/City

Omschrijving Geboorteplaats van AccountHolder (natuurlijk persoon)

Condities Optioneel (en niet in gebruik voor FATCA)

Toelichting Geboorteplaats mag leeg gelaten worden.

Kardinaliteit 0..1

Formaat xsd:stringMax200

Domein Maximaal 200 karakters

Een van de twee onderstaande elementen wordt gevuld geleverd als geboorteplaats of geboorteplaats en

stadsdeel gevuld zijn. Het kan zijn:

huidige jurisdiction (landcode volgens ISO-3166-1 standaard in BirthInfo/CountryInfo/CountryCode) of

een vroegere jurisdiction (naam van het land in BirthInfo/CountryInfo/FormerCountryName).

gegevensnaam MessageBody - ReportingGroup - AccountReport - ControllingPerson - Individual – BirthInfo – CountryInfo – CountryCode

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/ControllingPerson/Individual/BirthInfo /CountryInfo/CountryCode

Omschrijving Geboorteland van ControllingPerson (natuurlijk persoon)

Condities Optioneel (en niet in gebruik voor FATCA)

Toelichting Landcode van geboorteland is gevuld als Geboorteplaats (al dan niet met Stadsdeel) is ingevuld en de huidige jurisdiction het geboorteland is.

Kardinaliteit 0..1

Formaat xsd:string (2 posities)

Domein Landcode volgens ISO-3166-1 formaat

gegevensnaam MessageBody - ReportingGroup - AccountReport - ControllingPerson - Individual – BirthInfo – CountryInfo – FormerCountryName

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/ControllingPerson/Individual/BirthInfo /CountryInfo/FormerCountryName

Omschrijving Geboorteland van ControllingPerson (natuurlijk persoon)

Condities Optioneel (en niet in gebruik voor FATCA)

Toelichting Naam van het geboorteland is gevuld als Geboorteplaats (al dan niet met Stadsdeel) is ingevuld en de huidige jurisdiction niet het geboorteland is.

Kardinaliteit 0..1

Formaat xsd:stringMax200

Domein Maximaal 200 karakters

Het volgende element geeft het type ControllingPerson weer.

gegevensnaam MessageBody - ReportingGroup – AccountReport - ControllingPerson - CtrlgPersonType

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/ControllingPerson/CtrlgPersonType

Omschrijving Dit element geeft aan welk type ControllingPerson het is

Condities (optioneel) verplicht

Toelichting Er wordt een aantal typen controlling person onderkend, te weten:

CRS801 = Controlling person of legal person - ownership

CRS802 = Controlling person of legal person – other means

CRS803 = Controlling person of legal person – senior managing official

CRS804 = Controlling person of legal arrangement - trust - settlor

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 60

CRS805 = Controlling person of legal arrangement - trust – trustee

CRS806 = Controlling person of legal arrangement - trust – protector

CRS807 = Controlling person of legal arrangement - trust - beneficiary

CRS808 = Controlling person of legal arrangement - trust – other

CRS809 = Controlling person of legal arrangement - other – settlor-equivalent

CRS810 = Controlling person of legal arrangement - other – trustee-equivalent

CRS811 = Controlling person of legal arrangement - other – protector-equivalent

CRS812 = Controlling person of legal arrangement - other – beneficiary-equivalent

CRS813 = Controlling person of legal arrangement - other – other-equivalent

Kardinaliteit 0..1 (als er sprake is van een controlling person, dan is dit element verplicht)

Formaat xsd:string (een van de waarden uit Domein)

Domein De waarden zijn: CRS801, CRS802, CRS803, CRS804, CRS805, CRS806, CRS807, CRS808, CRS809, CRS810, CRS811, CRS812, CRS813.

6.3.2.3.5. AccountReport - AccountBalance

Saldo per 31-12 van het jaar waarover gerapporteerd wordt.

gegevensnaam MessageBody - ReportingGroup - AccountReport – AccountBalance

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountBalance

Omschrijving Saldo of waarde per einddatum van de ReportingPeriod (veelal 31-12)

Condities Verplicht (validatie)

Toelichting Definitie van AccountBalance is afhankelijk van het soort account:

voor depository en custodial accounts: saldo of waarde per 31-12.

voor cash value en annuity contracts: cash value insurance of het annuity contract per 31-12.

voor debt of equity accounts: waarde van debt of equity interest, die de accountholder heeft in de financiële instelling

Als het account gedurende de ReportingPeriod is beëindigd, lever dan het saldo zoals dat net voor beëindiging van het account gold. De beëindiging van het Account wordt bij AccountNumber@ClosedAccount aangegeven. MDES zorgt voor correcte verstrekking aan MCAA-landen:

als een Account gedurende het jaar is beëindigd: o dan verstrekt DIMP aan de IRS de Accountbalance en de Payments als Accountbalance > $

50.000. Daarnaast wordt AccountClosed = ‘true’ verstrekt. o dan verstrekt DIMP aan MCAA-landen Accountbalance = 0 en de Payments en daarnaast

AccountNumber@ClosedAccount = ‘true’

als er per 31-12 sprake is van een Accountbalance: o dan verstrekt DIMP aan de IRS Accountbalance en de payments geleverd als de

Accountbalance > $ 50.000. Is dat niet het geval, dan wordt niets geleverd. dan verstrekt DIMP aan MCAA-landen Accountbalance en payments, ongeacht de hoogte van de Accountbalance.

Kardinaliteit 1..1

Formaat Numeriek met 2 decimalen (cfc:MonAmnt_Type). Formaat is ..999.99 (een punt als scheidingsteken) Maximale waarde niet groter dan 1 met 16 nullen voor de punt (scheidingsteken voor decimalen).

Domein n.v.t.

gegevensnaam MessageBody - ReportingGroup - AccountReport - AccountBalance – AccountBalance - CurrCode

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AccountBalance/AccountBalance@CurrCode

Omschrijving Valuta code

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 61

Condities Verplicht

Toelichting Geen

Kardinaliteit 1..1

Formaat Xsd:string (3 posities conform ISO-4217 Alpha 3)

Domein Waarde bereik: alle valuta codes uit ISO-4217 Alpha 3

6.3.2.3.6. AccountReport - Payment

Opbrengsten in het jaar waarover gerapporteerd wordt.

In het kader van de CRS moeten vanaf belastingjaar 2017 voor accountholders met jurisdiction of residence in

een MCAA-land opbrengsten dividend, interest, verkoop en aflossing (CRS501 t/m CRS504 als PaymentType)

Payment kan 0..N maal voorkomen. Als Payment voorkomt, dan moet geleverd worden:

PaymentType,

PaymentAmnt,

PaymentAmnt@CurrCode.

gegevensnaam MessageBody - ReportingGroup - AccountReport - Payment - PaymentType

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/Payment/PaymentType

Omschrijving PaymentType waarden zijn dan als volgt:

CRS501 = Dividends

CRS502 = Interest

CRS503 = Bruto opbrengst en Aflossing

CRS504 = Anders (bijv. inkomen gegenereerd vanwege aanhouden van aandelen in account)

Condities Verplicht voor elk geleverd Payment

Toelichting Voor leveringen voor accountholders met een jurisdiction of residence in een MCAA-land geldt: belastingjaar 2017 en volgende belastingjaren: alle PaymentTypes (CRS501 t/m CRS504)

Kardinaliteit 1..1 (verplicht voor elk Payment; payment kan 0..N voorkomen)

Formaat xsd:string

Domein Waarde bereik: CRS501, CRS502, CRS503, CRS504

gegevensnaam MessageBody - ReportingGroup - AccountReport - Payment - PaymentAmnt

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/Payment/PaymentAmnt

Omschrijving Opbrengt in de ReportingPeriod voor het Account

Condities Verplicht voor elk geleverde Payment

Toelichting Opbrengst (Payment) is afhankelijk van het soort account:

Voor depository accounts: geagregeerde gross amount of interest betaald of gecrediteerd op het account gedurende de ReportingPeriod.

Voor custodial accounts: o geagregeerde gross amount van dividends betaald of gecrediteerd op het account

gedurende de ReportingPeriod. o geagreerde gross amount van interest betaald of gecrediteerd op het account gedurende

de ReportingPeriod. o geagregeerde gross proceeds uit verkoop of aflossing van een eigendom betaald of

gecrediteerd op het account gedurende de ReportingPeriod met betrekking tot dat deel waarvoor ReportingFI optreedt als custodian, broker, nominee of anderszins als een agent.

o geagregeerde gross amount van alle overige inkomsten betaald of gecrediteerd op het account gedurende de ReportingPeriod.

Voor debt of equity accounts: geagregeerde gross amount van betalingen of crediteringen op het account gedurende de ReportingPeriod.

Voor cash value insurance en annuity contract accounts: geagregeerde gross amount van betalingen of crediteringen inclusief aflossing op het account gedurende de ReportingPeriod.

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 62

In PaymentType toelichting staat beschreven welke Payments voor de verschillende belastingjaren (na)geleverd moeten worden.

Kardinaliteit 1..1 (verplicht voor elk payment; payment kan 0..N voorkomen)

Formaat Numeriek met 2 decimalen (cfc:MonAmnt_Type). Formaat is ..999.99 (een punt als scheidingsteken) Maximale waarde niet groter dan 1 met 16 nullen voor de punt (scheidingsteken voor decimalen).

Domein n.v.t.

gegevensnaam MessageBody - ReportingGroup - AccountReport - Payment – PaymentAmnt - CurrCode

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/Payment/PaymentAmnt@CurrCode

Omschrijving Valuta code

Condities Verplicht voor elk geleverd Payment

Toelichting Als er een payment amount is, dan is CurrCode verplicht (voor elke payment account een CurrCode)

Kardinaliteit 1..1 (verplicht voor elk payment; payment kan 0..N voorkomen)

Formaat Xsd:string (3 posities conform ISO-4217 Alpha 3)

Domein Waarde bereik: alle valuta codes uit ISO-4217 Alpha 3

6.3.2.3.7. Additional Data

Additional Data is nieuw in het FATCA CRS XML berichtschema versie 2.0 en is opgenomen omdat het FATCA

XML berichtschema versie 2.0 deze nieuwe gegevensgroep bevat.

Additional Data is aanvullende informatie binnen een AccountReport en is optioneel. Additional Data bestaat

uit een aantal Additional Item (maximaal 100 Additional Items). Een Additional Item bestaat uit:

ItemName en

ItemContent.

gegevensnaam MessageBody - ReportingGroup - AccountReport – Additional Data – AdditionalItem - ItemName

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AdditionalData/AdditionalItem/ItemName

Omschrijving De naam van het Additional Item

Condities Verplicht als gekozen is voor een Additional Item als onderdeel van Additional Data (max. 100 additional items)

Toelichting Geen

Kardinaliteit 1..1 (als gekozen is voor een Additional Item als onderdeel van Additional Data)

Formaat Xsd:stringMax200

Domein Maximaal 200 karakters

gegevensnaam MessageBody - ReportingGroup - AccountReport – Additional Data – AdditionalItem - ItemContent

Xpath (XML) FATCA_CRS/MessageBody/ReportingGroup/AccountReport/AdditionalData/AdditionalItem/ItemContent

Omschrijving De inhoud van het Additional Item

Condities Verplicht als gekozen is voor een Additional Item als onderdeel van Additional Data (max. 100 additional items)

Toelichting Geen

Kardinaliteit 1..1 (als gekozen is voor een Additional Item als onderdeel van Additional Data)

Formaat Xsd:stringMax4000

Domein Maximaal 4000 karakters

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 63

7. Notificaties op gegevensniveau ontvangen van MCAA-landen

MCAA-landen sturen notificaties aan DIMP over verstrekte gegevens. Deze notificaties zijn er op berichtniveau en op gegevensniveau. Notificaties op berichtniveau worden door DIMP afgehandeld. Notificaties op gegevensniveau worden door de MDES verzameld en beschikbaar gesteld aan de financiële instellingen, die de gegevens met fouten hebben geleverd. Notificaties op gegevensniveau worden in twee stappen verwerkt:

1. Notificaties MCAA-landen aan DIMP:

Notificaties op gegevensniveau van MCAA-landen worden door DIMP vastgelegd in MDES en beschikbaar

gesteld (zie 2) aan de financiële instellingen, die gegevens geleverd hebben.

2. Beschikbaar stellen van notificaties door DIMP aan financiële instellingen:

Financiële instellingen, die met fouten geleverd hebben, ontvangen een attendering e-mail en kunnen in

MDES de notificaties per gegevens per ReportingFI raadplegen.

FATCA en CRS onderkennen deels dezelfde en deels andere notificaties . In bijlage 4 is een geïntegreerd

overzicht van CRS notificaties opgenomen. Leverende FI’s ontvangen notificaties op gegevensniveau zoals die

vanuit MCAA-landen door DIMP worden ontvangen.

Voor de FATCA notificaties wordt verwezen naar : ‘International Compliance Management Model (ICMM)

Notification User Guide’, publicatie 5189 – -5-2017 (https://www.irs.gov/pub/irs-pdf/p5189.pdf) en

‘International Compliance Management Model (ICMM) Notification XML Schema User Guide’,(publicatie 5216

– 3-2017 (https://www.irs.gov/pub/irs-pdf/p5216.pdf).

Voor de CRS notificaties wordt verwezen naar http://www.oecd.org/tax/exchange-of-tax-

information/common-reporting-standard-status-message-xml-schema-user-guide-for-tax-administrations.htm

Als er notificaties zijn dan ontvangt de betreffende FI een (alert) email dat de inhoud van de notificaties op

gegevensniveau in de MDES ter inzage beschikbaar is.

Alleen tussen landen onderling is sprake van XML notificatieberichten.

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 64

Bijlage 1: begrippen en definities

AEOI staat voor Automatic Exchange of Information. Vragen met betrekking tot de

gegevensuitwisseling kunnen gesteld worden via agu@impuesto.aw

Alert is een e-mail bericht, dat wordt verstuurd door de ontvanger van gegevens aan degene die gegevens

verstrekte c.q. leverde. Het attendeert erop dat de gegevens in goede staat zijn ontvangen en of er notificaties

zijn ten aanzien van het bericht zelf en/of de inhoud van gegevensgroepen in het bericht.

CRS is de afkorting voor Common Reporting Standard.

CTS is de afkorting voor Common data Transmission System. Het netwerk dat beschikbaar wordt

gesteld voor de gegevensuitwisseling met MCAA-landen.

Datapreparatie is het versleutelen en comprimeren van gegevens tot een bericht, dat kan worden verstrekt

aan een MCAA-land.

FATCA is de afkorting voor Foreign Account Tax Compliance Act.

FFI in het kader van dit document is een (onderdeel van een) financiële instelling, die als ‘foreign financial

institution’ bij de IRS geregistreerd staat en is gevestigd in Aruba. In de gegevensuitwisseling is een FFI een

ReportingFI.

FI is een financiële instelling in Aruba.

Gegevenslevering door financiële instellingen en aan DIMP is een levering van

afgesproken financiële gegevens voor een belastingjaar voor accountholders, die een of meer MCAA-land(en)

als jurisdiction of residence heeft. Van accountholders kunnen gegevens naar meerdere landen moeten (op te

nemen in ResCountryCode bij Accountholder). Een gegevenslevering door de financiële instelling is een XML-

bericht met een FATCA CRS XML-berichtschema versie 2.0 of handmatige invoer van gegevens om uit te

wisselen. Een gegevenslevering bevat één of meer MessageBody’s met steeds een combi van ReportingFI en

ReportingGroup.

Gegevensverstrekking door DIMP aan MCAA-landen is een verstrekking van afgesproken

financiële gegevens voor een belastingjaar voor een selectie van accountholders. Vanaf belastingjaar 2017 is

het ook verstrekkingen aan MCAA-landen voor accountholders met jurisdiction of residence in dat MCAA-land.

Een gegevensverstrekking door DIMP aan een land is een XML-bericht met een voor het betreffende land

geldende XML berichtschema:

CRS XML berichtschema versie 2.1 voor MCAA-landen

Een gegevensverstrekking bevat één of meer MessageBody’s met steeds een combi van ReportingFI en

ReportingGroup. In de ReportingGroup is of een NilReport of zijn een of meer AccountReport aanwezig.

DIMP is de verkorte schrijfwijze voor de Departamento di Impuesto .

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 65

Landsverordening Internationale Bijstandsverlening bij de heffing van Belastingen (LIBB) is

een wet die eind december 2017 van kracht is en de juridische basis voor internationale gegevensuitwisseling

FATCA CRS.

MCAA is een Multilateral Competent Authority Agreement on Automatic Exchange of

Financial Account Information. Op 29 oktober 2014 in Berlijn hebben 48 landen een MCAA ondertekend

om vanaf belastingjaar 2016 onderling CRS-gegevens te gaan uitwisselen. Aruba heeft de MCAA ondertekend

om voor het eerst over belastingjaar 2017 gegevens in het kader van de CRS te gaan uitwisselen.

MCAA-land is een land waarmee Aruba onderling CRS-gegevens uitwisselt. Een land is een MCAA-land als het

land de MCAA heeft ondertekend.

Notificaties voor CRS gegevensuitwisseling (vanaf belastingjaar 2017) bevatten foutmeldingen

(notificaties) over gegevensverstrekkingen op twee niveaus:

- notificaties op berichtniveau vanuit MCAA-landen, worden afgehandeld door DIMP - notificaties op gegevensniveau MCAA-landen, die door DIMP beschikbaar worden gesteld aan de

financiële instellingen, die gegevens met fouten hebben geleverd. Financiële instellingen ontvangen een attendering e-mail als zij gegevens met fouten hebben geleverd en kunnen in MDES de notificaties (van alle landen) per gegevens per ReportingFI raadplegen.

OECD is de afkorting voor Organisation for Economic Co-operation and Development.

MDES is de afkorting van de web portal Multi Data Exchange Solution, die financiële instellingen

en DIMP ondersteunt bij de uitvoering van de internationale gegevensuitwisseling in het kader van CRS.

ReportingFI is binnen een bericht de organisatie c.q. organisatieonderdeel waarvoor financiële gegevens

worden geleverd c.q. verstrekt . De geleverde c.q. versterkte gegevens zijn opgenomen in bijbehorende

ReportingGroup binnen de MessageBody.

De MessageBody kan vaker voorkomen in één bericht en bestaat uit een combinatie van één ReportingFI en

één ReportingGroup met of een NilReport of een of meer AccountReports.

UTF-8 encoding standard is een verzameling tekens die in xsd:string elementen van gegevensleveringen

mogen voorkomen. Uit deze verzameling van tekens mogen acht tekens of combinaties niet gebruikt worden.

Het betreft in Engelse termen:

apostrophe (‘),

ampersand (&),

ampersand hash (&#),

double dash (—),

greater than (>),

less than (<),

slash asterisk (/*),

quotation mark (“).

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 66

Bijlage 2: Mogelijke tekens in xsd:string elementen = UTF-8 exclusief acht tekens

FATCA XML documents should conform to recommended XML schema best practices. Certain characters are prohibited and if included will cause the file to reject the transmission and generate an error notification. Non-Optional Entity Reference If an XML document contains one of these characters in the XML text content, the data packet will be rejected and an error notification (XML not well-formed) will be generated. These characters are not allowed by XML syntax rules and must be replaced with the following predefined entity references. To prevent error notifications, please ensure your XML documents do not include any of these characters.

Character Description Entity Reference

& Ampersand &amp;

< Less Than &lt;

Optional Entity Reference If an XML document contains one of these characters in the XML text content, it is not restricted and will not cause an error notification. The characters should be replaced by the following predefined entity references to conform to XML schema best practices.

Character Description Entity Reference

> Greater Than &gt;

' Apostrophe &apos;

" Quotation Mark &quot;

SQL Injection Validation If an XML document contains one of these combinations of characters in the XML text content, the data packet will be rejected and a failed threat detection (error) notification will be generated. These combinations of characters are not allowed.To prevent error notifications, do not include any of these combinations of characters.

Character Description Entity Reference

- - Double Dash N/A

/* Slash Asterisk N/A

&# Ampersand Hash N/A

Page Last Reviewed or Updated: 10-Aug-2015

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 67

Bijlage 3: FATCA CRS XML berichtschema versie 2.0

Het XML-berichtschema FATCA CRS versie 2.1 als zodanig en visualisaties ervan en een voorbeeld van een XML-bericht, dat voldoet aan het XML-berichtschema FATCA CRS, zijn als separate bijlage aan de Handleiding Internationale Gegevensuitwisseling FATCA CRS toegevoegd.

De separate bijlage met het XML-berichtschema FATCA CRS bestaat uit:

het XML berichtschema FATCA CRS versie 2.1

FatcaCrs_v2.1.xsd

Het maakt gebruik van types, die specifiek voor dat XML-berichtschema gedefinieerd:

FatcaCrsTypes_v2.1.xsd

En het maakt gebruik van de volgende extern gedefinieerde XML-schema’s:

stffatcatypes_v2.1.xsd

isofatcatypes_v1.1.xsd

oecdtypes_v4.2.xsd

schematisch totaaloverzicht XML-berichtschema FATCA CRS

totaaloverzicht v2.0.png

Legenda bij Totaaloverzicht XML-berichtschema FATCA CRS.docx

een voorbeeld van een bericht volgens het XML-berichtschema FATCA CRS ziet er als volgt uit: de inhoud van de gegevens is automatisch gegenereerd en kan niet realistisch zijn; het gaat om het XML berichtschema FATCA CRS

Voorbeeld v2.0.xml

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 68

Bijlage 4: foutmeldingen (notificaties) op gegevensniveau vanuit MCAA-landen

notificatie code omschrijving

800701 AccountNumber moet aanwezig zijn. AIs er geen AccountNumber is, dan dient "NANUM' geleverd te worden.

800702 Als AccountNumberType = OECD601 (IBAN account), dan moet AccountNumber voldoen aan het IBAN formaat, dat maximaal 34 posities lang is

en varieert per land maar voldoet altijd aan:

- landcode volgens ISO 3166-1 alpha-2

- twee cijfers als controle getal

- een rekeningidentificatie bestaande uit maximaal 30 cijfers en letters

800703 Als AccountNumberType = OECD603 (ISIN account), dan moet AccountNumber voldoen aan het ISIN formaat (12 posities):

- landcode volgens ISO 3166-1 alpha-2

- negen cijfers als identificatie van het account

- een cijfer als controlegetal

800704 Account Balance niet ≥ 0.00 (PFGU zorgt voor de juiste verstrekking naar USA en MCAA-landen)

800705 ResCountryCode voor ReportingFI is verplicht en moet overeen komen met de Sending Country Code

800706 Naam is niet geleverd voor ReportingFI

800707 Naam is niet geleverd voor Accountholder of Recipient

800708 NameType mag niet OECD201 zijn (dit geldt voor ReportingFI, Sponsor, Accountholder Individual, Accountholder Organisation, SubstantialOwner

Individual, SubstantialOwner Organisation en Controlling Person)

800709 FirstName bij AccountHolder Individual is verplicht (als Accountholder Individual geen voornaam heeft, dan 'NFN' invullen)

800710 AccountHolder Individual LastName is niet geleverd

800711 FirstName bij SubstantialOwner Individual is verplicht (als SubstantialOwner Individual geen voornaam heeft dan 'NFN' invullen)

800712 Naam is niet geleverd voor SubstantialOwner Individual

800713 Naam is niet geleverd voor SubstantialOwner Organisation

800714 FirstName bij Controlling Person is verplicht (als Controlling Person geen voornaam heeft dan 'NFN' invullen)

800715 Controlling Person LastName is niet geleverd

800716 City of Town is niet geleverd voor ReportingFI

800717 City of Town is niet geleverd voor AccountHolder of Recipient

800718 City of Town is niet geleverd voor Asset owner

800719 Als bij het adres voor een AccountHolder Organisation is gekozen voor AddressFix, dan moet City gevuld zijn

800720 City of Town is niet geleverd voor Sponsor of SubstantialOwner Organisation

800721 City of Town is niet geleverd voor Controlling Person

800722 Als bij adres ReportingFI is gekozen voor AddressFree, dan moet AddressFree daad- werkelijk gevuld zijn

800723 Als bij het adres voor een AccountHolder Individual is gekozen voor AddressFree, dan moet AddressFree daadwerkelijk gevuld zijn

800724 Als bij adres AccountHolder Organisation is gekozen voor AddressFree, moet AddressFree daadwerkelijk gevuld zijn

800725 Als bij adres SubstantialOwner Individual is gekozen voor AddressFree, moet AddressFree daadwerkelijk gevuld zijn

800726 Als bij adres SubstantialOwner Organisation is gekozen voor AddressFree, moet AddressFree daadwerkelijk gevuld zijn

800727 Als bij een adres voor een Controlling Person is gekozen voor AddressFree, dan moet AddressFree daadwerkelijk gevuld zijn

800728 geboortedatum mag niet voor 1900 vallen en niet het huidige jaar zijn

800729 Geboortedatum is niet geleverd voor Accountholder Individual

800730 Geboortedatum is niet geleverd voor SubstantialOwner Individual

800731 Geboortedatum is niet valide voor Accountholder Individual (blijkt uit persoonsregistratie USA of MCAA-land)

800732 Geboortedatum is niet valide voor SubstantialOwner Individual (blijkt uit persoonsregistratie USA)

800733 GIIN komt niet overeen met registratie bij de IRS (geldt bij ReportingFI ingeval van een FFI en bij Sponsor)

800734 GIIN formaat is niet valide voor een Sponsor (SP moet voorkomen in GIIN)

800735 GIIN van de ReportingFI (als zijnde een FFI) is niet geleverd

800736 GIIN voor Sponsor komt niet voor in de IRS-registratie

800737 Naam/geboortedatum match klopt niet voor Accountholder Indivivdual (blijkt uit de persoonsregistratie USA of MCAA-land)

800738 TIN ReportingFI is niet geleverd

800739 TIN Accountholder Individual of TIN Accountholder organisation is niet geleverd

800740 TIN Accountholder Individual of TIN Accountholder organisation is niet valide

- voor US-persons moet het TIN-formaat voldoen aan 999999999 of 99-9999999 of 999-99-9999

- voor MCAA-landen is nog geen controle op formaat opgenomen in de PFGU

800741 TIN Substantial Owner niet valide (voor US-persons is TIN-formaat gelijk aan 999999999 of 99-9999999 of 999-99-9999)

800742 Voor Controlling Person is de TIN (voorzien van TIN@IssuedBy) niet geleverd

Notificaties voor ReportingGroups

- 800701 tot en met 800747 voor 1e levering van gegevens voor een ReportingGroup (levering van nieuwe gegevens)

- overeenkomstige serie 800901 tot en met 800947 voor 2e en volgende levering van gegevens voor een ReportingGroup (correctieleveringen)

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 69

800743niet in gebruik

TIN structuur is niet valide (CRS voorziet deze controle in de toekomst voor TIN's van diverse MCAA-landen)

800744 niet in gebruik

TIN is niet valide tegen het TIN-algoritme (CRS voorziet deze notificatie in de toekomst voor TIN's van diverse MCAA-landen)

800745 niet in gebruik

TIN heeft geen valide semantiek (CRS voorziet deze notificatie in de toekomst voor TIN's van diverse MCAA-landen)

800746 ControllingPersonType niet leveren bij Accountholder Organisation met AccountHolderTypeCRS = CRS102 of CRS103

800747 ControllingPersonType is verplicht, ingeval van Accountholder Organisation met AccountHolderTypeCRS = CRS101

801300 Fout in NilReport

801400 Dubbel NilReport in één bericht

801500 Fout in NilReport correctie

801600 NilReport correctie zonder goede match met origineel

801700 Verwijderd NilReport zonder match met origineel

99999niet in gebruik

custom error (ontvangen bericht bevat een fout waarvoor geen specifieke error code bestaat; in details is de fout beschreven)

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 70

Bijlage 5: Controles en foutmeldingen gegevenslevering aan DIMP

validatie

nr

Validatie omschrijving Element Tekst van de foutmelding

(Nederlands)

X1 FATCA CRS XML-schema XSD - Vanuit XSD

A1 Jurisdictions of Residence komen in de

MDES voor als landen waarmee gegevens

worden uitgewisseld voor een bepaald

belastingjaar

- Dit land is voor dit belastingjaar niet

bekend als land voor de internationale

gegevens uitwisseling.

A2 Alle ReportingFI's zijn als EOI-relaties van de

leverende instelling (SendingCompanyIN)

geregistreerd

ReportingFI - TIN De ReportingFI(s) met de TIN(s) (TINs

gescheiden met komma's) zijn niet als

gerelateerde instellingen van de leverende

instelling geregistreerd.

A3 Controle dat waarborgt dat er geen

dubbele/dezelfde GIIN’s van ReportingFI’s in

1 levering voorkomen

- Dit bestand bevat meerdere reports van

een zelfde ReportingFI. Elke ReportingFI

mag maar één keer in de levering

voorkomen.

1 Validatie versienummervanaf 1-1-2018

hanteert DIMP één FATCA CRS XML-schema

voor:

levering over belastingjaar 2017 (met

gegevens bestemd voor CRS)

Version Versie in het ge-uploade bestand komt niet

overeen met de geldende versie van het

FATCA CRS XML bericht

3 Validatie op bestaande persoonsnummer MessageHeader -

SendingCompanyIN

SendingCompanyIN bevat geen bestaand

persoonsnummer.

4 Komt overeen met het persoonsnummer

waarvoor de gebruiker geautoriseerd is om

gegevens te leveren

MessageHeader -

SendingCompanyIN

U bent niet bevoegd om gegevens te

verstrekken namens de instelling genoemd

in SendingCompanyIN.

5 Validatie op aanwezigheid van ‘ AW’ MessageHeader -

TransmittingCountry

Transmitting country moet ' AW' zijn

6 Validatie op aanwezigheid van ‘ AW’ MessageHeader -

ReceivingCountry

Receiving country moet ' AW' zijn

7 MessageRefId is een verplicht veld MessageHeader -

MessageRefId

MessageRefID is verplicht en moet

beginnen met ' AW' gevolgd door het

belastingjaar en het persoonsnummer van

de leverende FI of - in geval van een

Sponsor als leverende FI - het nummer dat

de Sponsor bij aanmelding in MDES heeft

gekregen.

8 De eerste zes karakters moeten gelijk zijn

aan ‘ AW’ gevolgd door het belastingjaar

(JJJJ) waarvoor de gegevens in het bericht

gelden. Voor belastingjaar 2017 is het dus ‘

AW2017’. Vervolgens dient de

persoonsnummer van de financiële

instelling opgenomen te zijn gevolgd door

de identificatie van het bericht als zodanig.

MessageHeader -

MessageRefId

MessageRefID moet beginnen met ' AW'

gevolgd door het belastingjaar en het

persoonsnummer van de leverende FI .

9 Mag geen spaties bevatten MessageHeader -

MessageRefId

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 71

10 Is nog niet gebruikt in een bestand dat al

geüpload is, tenzij dit bestand ingetrokken

of afgekeurd is.

MessageHeader -

MessageRefId

Het MessageRefId <MessageRefId> is al

gebruikt in een eerdere upload. Indien de

opbouw correct is, dient u een (ander)

volgnummer te gebruiken.

11 Verplicht in geval van MessageTypeIndic =

CRS702.

MessageHeader -

CorrMessageRefId

CorrMessageRefID is verplicht voor een

correctiebericht (code CRS702)

12 Verplicht in geval van MessageTypeIndic =

CRS703 indien het bestand ReportingFI's

bevat waarvoor al gegevens zijn ingediend

in het betreffende belastingjaar

MessageHeader -

CorrMessageRefId

CorrMessageRefID is verplicht voor een

leeg levering (code CRS703) als deze

ReportingFIs bevat waarvoor al gegevens

zijn ingediend

13 ReportingFI, account report noch evt.

sponsor onderdelen van een reporting FI die

in een CRS703 bericht met een

CorrMessageRefId voorkomen mogen niet

gecorrigeerd zijn met een (of meerdere)

CRS702 berichten.

ReportingFI – TIN Gegevens voor ReportingFI (TIN, Name)

zijn eerder gecorrigeerd en kan niet meer

middels CRS703 berichten verwijderd

worden. U dient de verwijdering met

CRS702 bericht(en) te doen.

14 De eerste zes karakters moeten gelijk zijn

aan ‘ AW’ gevolgd door het belastingjaar

(JJJJ) waarvoor de gegevens in het bericht

gelden. Voor belastingjaar 2014 is het dus ‘

AW2017’. Vervolgens dient de persoons-

code van de financiële instelling opgenomen

te zijn gevolgd door de identificatie van het

bericht als zodanig.

MessageHeader -

CorrMessageRefId

CorrMessageRefID moet beginnen met '

AW' gevolgd door het belastingjaar en het

persoonsnummer van de leverende FI.

15 CorrMessageRefId bevat de MessageRefId

van een niet eerder geüpload, niet

afgekeurd of ingetrokken, bestand

MessageHeader -

CorrMessageRefId

Er is geen eerder bericht met het

MessageRefID vermeld in

CorrMessageRefID

16 Mag geen spaties bevatten MessageHeader -

CorrMessageRefId

17 Elementen mogen geen verboden

combinaties bevatten (zie bijlage 2)

Het zijn --, /* en &#.

Alle text- en attribute-

elementen

Tekst-elementen in het gehele bestand

mogen geen van de volgende combinaties

bevatten: --, /* en &#.

19 In de MessageBody van een FATCA CRS

bericht komt altijd één ReportingFI en één

ReportingGroup voor.

- voor leeglevering bevat ReportingGroup

één NilReport en evt. Sponsor gegevens

- voor levering van gegevens bevat

ReportingGroep één of meer

Accountreports

MessageBody Ieder MessageBody moet exact één

ReportingFI en één ReportingGroup

bevatten.

De ReportingGroup moet of een NilReport

of één of meer AccountReports bevatten.

22 Verplicht gevuld met ‘ AW’ ReportingFI –

ResCountryCode

ResCountryCode van ReportingFI moet '

AW' zijn.

23 Voor ReportingFI en SubstantialOwner

Individual, SubstantialOwner Organisation

en ControllingPerson is de TIN verplicht

TIN TIN is verplicht voor ReportingFI,

SubstantialOwner Individual en

SubstantialOwner Organisation.

24 TIN IssuedBy verplicht indien TIN ingevuld is TIN - IssuedBy U dient aan te geven door wie de

betreffende TIN uitgegeven is

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 72

26 Naam van de ReportingFI is verplicht ReportingFI - Name Naam van ReportingFI moeten worden

ingevuld.

27 Verplicht gevuld met ‘ AW’ ReportingFI – Address –

CountryCode

Country code in het adres van ReportingFI

moet ingevuld worden met ' AW'.

28 Verplicht indien AddressFix aanwezig Address - AddressFix – City AddressFix – City is verplicht en dient

opgegeven te worden indien AddressFix

gebruikt wordt.

29 DocRefId is verplicht DocRefId DocRefId dient bij alle elementen

opgegeven te worden.

30 De eerste zes karakters moeten gelijk zijn

aan ‘ AW’ gevolgd door het belastingjaar

(JJJJ) waarvoor de gegevens in het bericht

gelden. Voor belastingjaar 2017 is het dus ‘

AW2017’. Vervolgens dient de

persoonsnummer van de financiële

instelling opgenomen te zijn gevolgd door

de identificatie van het bericht als zodanig.

DocRefId Het DocRefID van (ReportingFI /

AccountRapport / PoolRapport /

Intermediair / Sponsor) moet beginnen

met ' AW', gevolgd door het belastingjaar

en het persoons-nummer.

Vanaf belastingjaar 2015:

Het DocRefID van (ReportingFI /

AccountRapport / Sponsor) moet beginnen

met ' AW', gevolgd door het belastingjaar

en het persoons-nummer.

31 Is nog niet gebruikt op een andere plek in dit bestand of in een bestand dat al ge-upload is,

tenzij dit bestand ingetrokken of afgekeurd

is.

Uitzondering hierop vormt de DocRefId voor een ReportingFI, als er sprake is van resent data (DocTypeIndic = OECD0 of OECD10 voor die ReportingFI).

DocRefId Het DocRefID is meer dan eens in dit

bestand gebruikt of is al eerder gebruikt.

DocRefID moet uniek zijn.

33 De eerste zes karakters moeten gelijk zijn

aan ‘ AW’ gevolgd door het belastingjaar

(JJJJ) waarvoor de gegevens in het bericht

gelden. Voor belastingjaar 2017 is het dus ‘

AW20177’. Vervolgens dient de persoons-

code van de financiële instelling opgenomen

te zijn gevolgd door de identificatie van het

bericht als zodanig.

CorrDocRefId DocRefID van ReportingFI, AccountRapport

en Sponsor moet beginnen met ' AW',

gevolgd door het belastingjaar en het

persoonsnummer.

34 In CorrDocRefId is de DocRefId van een

gegevensgroep uit het te corrigeren bestand

opgenomen (d.w.z. het bestand met de

MessageRefId waarnaar in

CorrMessageRefId in de MessageHeader

van het correctiebericht wordt gerefereerd).

Validatie controleert of de DocRefId in het

te corrigeren bestand wel voorkomt

CorrDocRefId Het CorrDocRefID bestaat niet in het

bestand dat u aan het corrigeren bent.

35 Bij het herzien van een levering dient het

CorrectionRefId van het nieuwe bestand

gelijk te zijn aan de MessageRefId van het

oorspronkelijke bestand

CorrMessageRefId Het CorrMessageRefID is niet hetzelfde als

het MessageRefID van de oorspronkelijke

case.

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 73

36 De gegevensgroep die de DocRefId heeft die

in CorrDocRefId genoemd wordt, is van

hetzelfde type als deze gegevensgroep

(d.w.z. bijvoorbeeld zijn allebei ReportingFI

of allebei Sponsor).

CorrDocRefId CorrDocRefID is een ongeldige referentie.

Ccorrigerende element is een ReportingFI,

AccountRapport ), maar het originele

element is een ReportingFI,

AccountRapport .

37 Mag geen spaties bevatten CorrDocRefId CorrDocRefId dient bij alle elementen

opgegeven te worden.

38 Verplicht gevuld met een ISO-3166-1

landencode indien Sponsor gebruikt wordt.

Sponsor - ResCountryCode ResCountryCode van Sponsor moet een

ISO-3166-1 landencode zijn.

40 Validatie op Sponsor's TIN en

SendingCompanyIn

Sponsor – TIN in combinatie

met

Messageheader -

SendingCompanyIN

TIN van Sponsor moet gelijk zijn aan de

GIIN die de Sponsor heeft ontvangen van

de IRS

41 SendingCompanyIn is verplicht en is gelijk

aan persoons nummer van MDES gebruiker

(voor een leverende FI) of gelijk aan

nummer dat de Sponsor bij aanmelding in

MDES heeft ontvangen (voor een Sponsor)

MessageHeader -

SendingCompanyIN

Het nummer in SendingCompanyIN en het

GINN nummer in Sponsor - TIN behoren

niet toe aan een Sponsor

45 AccountNumber is verplicht (als het

nummer er niet is, dan moet NANUM

worden ingevuld)

AccountNumber Conform handleiding dient de echte

account number of (in voorgeschreven

gevallen) NANUM opgegeven te worden.

48 ResCountryCode is verplicht indien

Accountholder Individual aanwezig

AccountHolder - Individual -

ResCountryCode

ResCountryCode is verplicht indien

Individual aanwezig.

49 Firstname is verplicht indien Accountholder

Individual aanwezig

AccountHolder - Individual -

Name – Firstname

Firstname is verplicht indien Individual

aanwezig.

50 Lastname is verplicht indien Accountholder

Individual aanwezig

AccountHolder - Individual -

Name – Lastname

Lastname is verplicht indien Individual

aanwezig.

55 Verplicht gevuld met een ISO-3166-1

landencode indien Accountholder Individual

gebruikt wordt.

AccountHolder - Individual -

Address – CountryCode

Country code van AccountHolder owners

adres moet een ISO-3166-1 landencode

zijn.

59 AcctHolderTypeFATCA moet gevuld zijn als

AccountHolder Organisation een US-person

is. Is de AccountHolder Organisation geen

US-person, dan wordt dit element niet

geleverd.

AccountHolder –

Organisation -

AcctHolderTypeFATCA

AcctHolderTypeFATCA moet gevuld zijn als

de AccountHolder een US-person en een

organisatie is. Is de AccountHolder geen

US-person, dan mag dit element niet

voorkomen.

60 Vanaf belastingjaar 2017 moet

AcctHolderTypeCRS gevuld zijn als de

AccountHolder een organisatie is, en (een)

ander(e) land(en) dan US als jurisdiction of

residence heeft.

AccountHolder –

Organisation -

AcctHolderTypeCRS

AccountHolder – AcctHolderTypeCRS

Vanaf belastingjaar 2017 moet

AcctHolderTypeCRS gevuld zijn als de

AccountHolder (een) ander(e) land(en) als

jurisdiction of residence heeft.

61 SubstantialOwner(s) moeten worden

geleverd t.b.v. de FATCA-levering, als er

sprake is van:- specified US owner(s) of- een

‘documented FI’ of- substantial US owner(s)

of controlling US-person(s) van een passive

NFFE.SubstantialOwners zijn verplicht als

AcctHolderTypeFATCA in AccountReport =

FATCA101 of FATCA102.Geen levering van

deze gegevensgroep in geval van een

AccountReport -

SubstantialOwner

SubstantialOwners zijn verplicht als

AcctHolderTypeFATCA in AccountReport =

FATCA101 of FATCA102. Geen levering van

deze gegevensgroep in geval van een

‘nonparticipating FFI of een ‘specified US

person’

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 74

‘nonparticipating FFI of een ‘specified US

person’

62 SubstantialOwners zijn niet van toepassing

voor leveringen in het kader van de CRS

AccountReport -

SubstantialOwner

SubstantialOwner is niet toegestaan in een

AccountReport als de AccountHolder geen

US-person is

63 ResCountryCode voor SubstantialOwner

Individual moet gevuld zijn met ‘US’

SubstantialOwner -

Individual - ResCountryCode

ResCountryCode SubstantialOwner

Individual moet ‘US’ zijn.

64 Verplicht gevuld met een ISO-3166-1

landencode indien Individual gebruikt

wordt.

SubstantialOwner -

Individual - Address –

CountryCode

Country code van Substantial Owner adres

moet een ISO-3166-1 landencode zijn.

65 Controlling Persons zijn verplicht als

AcctHolderTypeCRS in AccountReport gelijk

is aan CRS101

AccountReport -

ControllingPerson

Controlling Persons zijn verplicht als

AcctHolderTypeCRS in AccountReport =

CRS101.

66 Voor Accountholders individual mogen

ControllingPersons alleen ResCountryCodes

hebben die ook bij de Accountholder zelf

voorkomen.

AccountReport –

ControllingPerson

bij Accountholder Individual

ResCountryCode van ControllingPerson

mag alleen landen bevatten die ook in de

ResCountryCode van AccountHolder

individual voorkomen.

67 Verplicht gevuld met een ISO-3166-1

landencode indien Individual gebruikt

wordt.

ControllingPerson -

Individual - Address –

CountryCode

Country code van ControllingPerson adres

moet een ISO-3166-1 landencode zijn.

70 Er mogen in een nieuw levering type CRS701

geen andere OECD types dan OECD1

gebruikt worden.

MessageHeader -

MessageTypeIndic

Een bestand met

MessageTypeIndic=CRS701 mag alleen

nieuwe gegevens bevatten

71 De keuze "Type levering" moet overeen

komen met MessageTypeIndic in het ge-

uploade bestand

MessageHeader -

MessageTypeIndic

MessageTypeIndic is anders dan door u

opgegeven

72 Het gekozen jaar moet overeen komen met

de reporting period zoals in het ge-uploade

bestand opgegeven.

MessageHeader -

ReportingPeriod

De reporting period in het bestand is

anders dan de door u opgegeven reporting

period

74 Correcties op elementen dienen altijd te

gebeuren op het laatst gecorrigeerde

element in een bepaalde reeks correcties.

CorrDocRefId Een correctie op een bepaald element mag

alleen uitgevoerd worden op het laatst

gecorrigeerde element

76 TIN moet voor elke ResCountryCode bij

Accountholder Organisation worden

geleverd (ontbreekt de TIN voor een

bepaalde ResCountryCode dan geen TIN (en

bijbehorende TIN@IssuedBy leveren)

AccountHolder -

Organisation - TIN

AccountHolder - Organisation - TIN is een

verplicht veld en dient opgegeven te

worden.

77 Verplicht als TIN geleverd wordt AccountHolder -

Organisation - TIN –

IssuedBy

AccountHolder - Organisation - TIN –

IssuedBy is een verplicht veld en dient

opgegeven te worden.

78 Naam van Accountholder Organisation is

verplicht

Accountholder-Organisation-

Name

Accountholder-Organisation-Name is een

verplicht veld en dient opgegeven te

worden.

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 75

79 Als AddressFix is gekozen, dan is AddressFix-

City verplicht

Accountholder-Organisation-

AddressFix-City

Accountholder-Organisation-AddressFix-

City is een verplicht veld en dient

opgegeven te worden, als is gekozen voor

AddressFix om het adres te leveren.

80 De Countrycode voor een Accountholder

Organisation is verplicht

Accountholder-Organisation-

CountryCode

Accountholder-Organisation-Country Code

is een verplicht veld en dient opgegeven te

worden.

81 Voor SubstantialOwner Organisation moet

ResCountryCode gevuld zijn met ‘US’

SubtantialOwner-

Organisation-

ResCountryCode

De ResCountryCode van een Substantial

Owner Organisation moet ‘US’ zijn.

82 Lastname van SubstantialOwner-Individual

is verplicht

SubstantialOwner-

Individual-Lastname

SubstantialOwner-Lastname is een

verplicht veld en dient opgegeven te

worden.

83 Firstname van SubstantialOwner-Individual

is verplicht (als firstname niet bekend is dan

dient ‘NFN’ te worden geleverd)

SubstantialOwner-

Individual-Firstname

SubstantialOwner-Firstname is een

verplicht veld en dient opgegeven te

worden (ingeval er geen Firstname bekend

is, dan dient ‘NFN’ te worden geleverd.

84 Als AddressFix is gekozen, dan is AddressFix-

City verplicht

SubstantialOwner-Individual

- AddressFix-City

SubstantialOwner-Individual-AddressFix-

City is een verplicht veld en dient

opgegeven te worden.

85 Firstname van ControllingPerson-Individual

is verplicht (als firstname niet bekend is dan

dienst ‘NFN’ te worden geleverd)

ControllingPerson-Individual-

Firstname

ControllingPerson-Individual-Firstname is

een verplicht veld en dient opgegeven te

worden (ingeval er geen Firstname bekend

is, dan dient ‘NFN’ te worden geleverd..

86 Lastname van ControllingPerson-Individual

is verplicht

ControllingPerson-Individual-

Lastname

ControllingPerson-Individual-Lastname is

een verplicht veld en dient opgegeven te

worden.

87 Als AddressFix is gekozen, dan is AddressFix-

City verplicht

ControllingPerson-

AddressFix-City

ControllingPerson-AddressFix-City is een

verplicht veld en dient opgegeven te

worden, als is gekozen voor AddressFix om

het adres te leveren.

88 PaymentType is verplicht als Payments

worden geleverd

AccountReport-Payment-

PaymentType

Als Payments geleverd worden, dan moet

ook het PaymentType worden geleverd.

89 ResCountryCode is bij Controlling Person

verplicht

ControllingPerson -

ResCountryCode

90 Naam van de Sponsor is verplicht Sponsor - Name Sponsor-Name is een verplicht veld en

dient opgegeven te worden.

93 Voor de ReportingFI(s) in de levering is voor

het belastingjaar geen Afmelding van de

levering ("GEEN-levering") geregistreerd.

ReportingFI De ReportingFI (TIN) is afgemeld voor het

leveren over (Belastingjaar). Indien u toch

gegevens hebt om te leveren over deze

instelling, dient u de afmelding eerst in te

trekken

94 Als de account holder alleen US-person (dus

niet ook een MCAA-land als jurisdiction of

residence heeft), dan dient de account

balance > USD 50.000 te zijn. Dit wordt

alleen gecontroleerd, indien accountbalance

in USD wordt gerapporteerd

AccountBalance Alleen Accounts met een accountbalance

> USD 50.000 dienen gerapporteerd te

worden, als de account holder alleen US-

person is.

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 76

95 Er mag alleen gebruik worden gemaakt van productie DocTypeIndic's (OECD1, OECD2, OECD3) wanneer het systeem voor het betreffende jaar vrijgegeven is voor leveren (NTP error indien fout)

Alle DocRef - DocTypeIndic Testgegevens (DocTypeIndic = OECD11,

OECD12, OECD13) in een productielevering

zijn niet toegestaan

96 Er mag alleen gebruik worden gemaakt van test DocTypeIndic's (OECD11,OECD12, OECD13) als het systeem is opengesteld voor beheer van relaties FI’s en FFI’s en voor testen van de XML-berichten voor levering en nog niet is vrijgegeven voor levering van productie gegevens (NPT error indien fout)

Alle DocRef - DocTypeIndic Produictiegegevens (DocTypeIndic =

OECD1, OECD2, OECD3) in een testlevering

zijn niet toegestaan

97 Voor Sponsor is FilerCategory verplicht

(FATCA607, FATCA608 of FATCA609).

Sponsor - FilerCategory Als Sponsor geleverd wordt, dan is

FilerCategory verplicht. Mogelijke waarden

zijn FATCA607, FATCA608 en FATCA609.

98 Toegestane waarden voor FilerCategory

voor ReportingFI zijn conform IGA Model 1:

FATCA601, FATCA602, FATCA603 en

FATCA605, FATCA606 en FATCA610

ReportingFI - FilerCategory Wanneer ReportingFI-FilerCategory geleverd wordt, mogen alleen de waardes FATCA601, FATCA602, FATCA603, FATCA605, FATCA606 en FATCA610 gebruikt worden.

99 Voor ReportingFI’s die door een Sponsor

worden geleverd moet de FilerCategory bij

Sponsor gevuld zijn en mag bij ReportingFI

de FilerCategory niet worden geleverd

Combinatie van

FilerCategory bij Sponsor en

FilerCategory bij ReportingFI

Als gegevens voor een FFI worden geleverd door een Sponsor, dan mag FilerCategory bij ReportingFI niet worden geleverd.

100 Als AccountNumber@AcountNumberType =

OECD601 (rekeningnummer is een IBAN-

nummer), dan moet AccountNumber

voldoen aan het IBAN-formaat.

AccountNumber

als AccountNumberType =

OECD601.

Als AccountNumber@AccountNumberType = OECD601, dan moet de structuur van het AccountNumber voldoen aan de structuur voor een IBAN-nummer. Dit nummer mag maximaal 34 posities lang zijn en varieert per land, maar moet voldoen aan: (landcode volgens ISO 3166-1 alpha-2, twee cijfers als controle getal, een rekeningidentificatie bestaande uit maximaal 30 cijfers en letters)

101 Als AccountNumber@AcountNumberType =

OECD603 (rekeningnummer is een ISIN-

nummer), dan moet AccountNumber

voldoen aan het ISIN-formaat.

AccountNumber

als AccountNumberType =

OECD603.

Als AccountNumber@AccountNumberType = OECD603, dan moet de structuur van het AccountNumber voldoen aan de structuur voor een ISIN-nummer, die twaalf posities lang is en voldoet aan:: - landcode volgens ISO 3166-1 alpha-2 - negen cijfers als identificatie van account - een cijfer als controlegetal

102 Accountbalance < 0 AccountBalance De geleverde AccountBalance moet groter

of gelijk aan 0 zijn.

103 Als AddressFix is gekozen, dan is AddressFix-

City verplicht

SubstantialOwner-

Organisation - AddressFix-

City

SubstantialOwner-Organisation-

AddressFix-City is een verplicht veld en

dient opgegeven te worden.

104 Als bij een Address is gekozen voor

AddressFree, dan moet het daadwerkelijk

gevuld zijn (dit geldt voor ReportingFI,

Sponsor, Accountholder Individual,

Accountholder Organisation,

SubstantialOwner Individual,

SubstantialOwner Organisation en

ControllingPerson Individual)

Als AddressFree het enige

Adres veld is, dan moet het

gevuld zijn.

Als AddressFree wordt gebuikt om het

adress weer te geven, dan moet het

daadwerkelijk voorzien zijn van tekst.

105 Voor Accountholder Individual,

Accountholder Organisation en

SubstantialOwner Individual en

SubstantialOwner Organisation moet de TIN

ingeval van TIN@IssuedBy = ‘US’ voldoen

aan het TIN-formaat van de USA.

TIN bij Accountholder

Individual, Accountholder

Organisation,

SubstantialOwner Individual

en SubstantialOwner

Organisation

Formaat van TIN ingeval TIN@IssuedBy =

‘US’ moet gelijk zijn aan 999999999

of 99-9999999 of 999-99-9999.

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 77

106 ControllingPersonType moet niet gevuld zijn

als AcctholderTypeCRS voor Accountholder

Organisation gelijk is aan CRS102 of CRS103

ControllingPersonType Als AcctholderTypeCRS = CRS102 of CRS103

voor een Accountholder Organisation, dan

moet ControllingPersonType niet worden

geleverd.

107 ControllingPersonType is verplicht als

AcctholderTypeCRS = CRS101 voor

Accountholder Organisation.

ControllingPersonType Als AcctholderTypeCRS = CRS101 voor een

Accountholder Organisation, dan is

ControllingPersonType verplicht..

108 In DocRef van ReportingFI, Sponsor,

NilReport en AccountReport mag

CorrDocRefId niet voorkomen als

MessageTypeIndic = CRS701.

MessageTypeIndic in

combinatie met aanwezig-

heid van CorrDocRefId in

DocRef’s

Als er een levering van nieuwe data wordt gedaan, dan mag in de DocSpec het veld CorrDocRefId niet voorkomen.

109 In DocRef van ReportingFI, Sponsor,

NilReport en AccountReport moet

CorrDocRefId voorkomen als

MessageTypeIndic = CRS702.

Voor DocSpec van ReportingFI met Doc-

TupeIndic = OECD0 of OECD10 (testgege-

vens) mag CorrDocRefId niet gevuld zijn,

omdat het ‘resent data’ betreft.

MessageTypeIndic in

combinatie met aanwezig-

heid van CorrDocRefId in

DocRef’s

Als er een correctielevering van data wordt gedaan, dan moet in de DocSpec het veld CorrDocRefId geleverd worden.

110 Als MessageTypeIndic = CRS701, dan mog in

de Messageheader CorrMessageRefId niet

worden geleverd

MessageTypeIndic in

combinatie met aanwezig-

heid van CorrMessageRefId

Als er een levering van nieuwe data wordt

gedaan, dan mag CorrMessageRefId in de

MessageHeader niet voorkomen.

111 Als m.b.v. een correctielevering ReportingFI

wordt verwijderd (DocTypeIndic = OECD3 (of

OECD13 voor testlevering) in de DocRef van

de ReportingFI, dan moet een

ReportingGroup geleverd worden om het

eerder geleverde NilReport c.q. eerder

geleverde AccountReports, al dan niet

voorzien van Sponsor gegevens ook

verwijderd worden (op te nemen in de

correctielevering met DocTypeIIndic =

OECD3 c.q. OECD13).

Als DocTypeIndic = OECD3 of

OECD13 voor ReportingFI,

dan moet ReportingGroup

worden geleverd met daarin

een NilReport of een of meer

AccountReports met

DocTypeIndic = OECD3 c.q.

OECD13 of AccountReports

met dat DocTypeIndic en als

van toepassing Sponsor met

hetzelfde DocTypeIndic.

Verwijderen van een ReportingFI kan

alleen dan, als ook de ReportingGroup

wordt verwijderd.

112 Als MessageTypeIndic = CRS701, dan

moeten alle DocTypeIndic in DocRef gelijk

zijn aan OECD1 of OECD11.

MessageTypeIndic in

combinatie met alle

DocTypeIndic in DocRef

Voor nieuw levering moet DocTypeIndic

gelijk zijn aan OECD1 (productie) c.q.

OECD11 (test)

113 Als MessageTypeIndic = CRS702, dan

moeten alle DocTypeIndic in DocRef gelijk

zijn aan OECD2 of OECD3 c.q OECD12 of

OECD13.

MessageTypeIndic in

combinatie met alle

DocTypeIndic in DocRef

Voor correctielevering moet DocTypeIndic

gelijk zijn aan OECD2 of OECD3 (productie)

c.q. OECD12 of OECD13 (test)

114 Als MessageTypeIndic = CRS701, dan mag

de ReportingGroup geen NilReport bevatten

(NilReports moeten worden geleverd in een

bericht met MessageTypeIndic = CRS703).

MessageTypeIndic in

combinatie met aanwezig

zijn van een NilReport in

ReportingGroup

In een levering van nieuwe data mag in de

ReportingGroup geen NilReport

voorkomen.

115 TIN moet voor elke ResCountryCode bij een

Accountholder Individual worden geleverd

(ontbreekt de TIN voor een bepaalde

ResCountryCode, dan geen TIN en

bijbehorende TIN@IssuedBy leveren)

AccountHolder –

Individual - TIN

AccountHolder - Individual - TIN is een

verplicht veld en dient opgegeven te

worden.

116 Voor belastingjaar 2014 mogen conform de

IGA geen Payments worden geleverd

ReportingPeriod=2014-12-31

en Payments

Conform de IGA mogen voor belastingjaar

2014 geen Payments worden geleverd

117 Voor belastingjaar 2015 mogen conform de

IGA alleen Payments van PaymentType

CRS501 en CRS502 worden geleverd

ReportingPeriod=2015-12-31

en PaymentType

Conform de IGA mogen voor belastingjaar

2015 als Payments alleen opbrengsten

dividend en interest worden geleverd

118 FilerCategory moet bij ReportingFI gelijk zijn

aan FATCA606, als in een accountholder

organisation de AcctHolderTypeFATCA gelijk

is aan FATCA105

ReportingFI – FilerCategory

i.c.m. Accountholder

Organisation

AcctHolderTypeFATCA

Als bij Accountholder organisation

AcctHolderTypeFATCA gelijk is aan

FATCA105, dan moet FilerCategory bij

ReportingFI gelijk zijn aan FATCA606.

119 De waarden OECD0 en OECD10 mogen niet

worden gebruikt in de DocSpec van Sponsor,

DocSpec – DocTypeIndic

Herzenden gegevens is niet toegestaan

voor Sponsor,NilReport en AccountReport

Handleiding internationale gegevenslevering FATCA CRS

versie 2.2 pagina 78

NilReport en AccountReport

Voor Sponsor, NilReport en

AccountReport

(OECD0 of OECD10 als DocTypeIndic is

niet toegestaan)

120 De waarden OECD2 en OECD12 mogen niet

worden gebruikt in DocSpec van NilReport

DocSpec – DocTypeIndic

voor NilReport

Voor NilReport is correctie niet van

toepassing (OECD2 of OECD12 als

DocTypeIndic is niet toegestaan)

121 Als er sprake is van Resent Data voor een

ReportingFI (DocTypeIndic = OECD0 of

OECD10), dan moet het DocRefId identiek

zijn aan het DocRefId van deze Reporting FI

in het bericht dat gecorrigeerd of aangevuld

wordt.

DocSpec – DocTypeIndic en

DocSpec – DocRefId

Voor ReportingFI

Als er sprake is van Resent Data voor een

ReportingFI (OECD0 of OECD10) dan moet

het DocRefId van de ReportingFI identiek

zijn aan het DocRefId van deze

ReportingFI in het bericht dat

gecorrigeerd of aangevuld wordt.

122 Voor Accountholder organisation met

AcctHolderTypeCRS = CRS101 mag de

ControllingPerson een ResCountryCode

hebben die afwijkt van (alle) ResCountry-

Codes van de Accountholder organisation,

maar moet wel een van de MCAA landen

zijn waarmee CRS-gegevens worden

uitgewisseld en mag niet ‘US’ zijn.

AccountReport

ControllingPersons

Bij Accountholder

organization met Acct-

HolderTypeCRS = CRS101

ResCountryCode(s) van de Controlling

Person(s) moet een van de MCAA-landen

zijn waarmee CRS-gegevens worden

uitgewisseld en mag niet ‘US’ zijn.

123 In een leeglevering ( MessageTypeIndic =

CRS703) mogen in ReportingGroup geen

AccountReport(s) voorkomen.

MessageTypeIndic in

combinatie met aanwezig

zijn van AccountReport(s) in

ReportingGroup

In een leeglevering mogen in de

ReportingGroup geen AccountReport(s)

voorkomen.

SKV260-CRS Utgåva 3 (utkast 1, februari 2019) 1

SKV260-CRS Utgåva 3 (utkast 1, februari 2019) 2

Inledning ................................................................................................. 3

Inlämning av CRS-kontrolluppgifter ........................................................ 4

Hur du läser den tekniska beskrivningen ................................................ 5

Common Reporting Standard User Guide, Second Edition .................... 6

CRS XML och Skatteverket ...................................................................... 6

Uppgifter som ska lämnas i rapporten (XML-filen) ................................ 8

1 MessageSpec ........................................................................... 8

2 ReportingFI .......................................................................... 10

2.1 ResCountryCode ................................................................... 10

2.2 IN .......................................................................................... 10

2.3 Name .................................................................................... 11

2.4 Address ................................................................................. 11

2.5 DocSpec ................................................................................ 11

3 ReportingGroup .................................................................... 13

3.1 Sponsor ................................................................................. 13

3.2 Intermediary ......................................................................... 13

3.3 AccountReport ...................................................................... 13

3.4 PoolReport ............................................................................ 15

3.5 AccountHolder ..................................................................... 15

3.6 AcctHolderType ................................................................... 20

3.7 ControllingPerson ................................................................. 20

4 XML-filen för CRS-kontrolluppgifter ................................... 24

4.1 E-tjänsten ”Test av filer – CRS och FATCA samt CbCR” .. 25

5 Inlämningssätt ...................................................................... 26

5.1 E-tjänsten ”Lämna filer – CRS och FATCA samt CbCR” ... 26

5.2 E-transport ............................................................................ 28

5.3 Teknisk support .................................................................... 28

6 Länkar till CRS-sidor ............................................................ 29

7 Verksamhetskontroller CRS ................................................. 29

SKV260-CRS Utgåva 3 (utkast 1, februari 2019) 3

Inledning Denna tekniska beskrivning vänder sig till finansiella institut som ska lämna in rapporter med CRS-kontrolluppgifter till Skatteverket. Här beskrivs hur en XML-fil för CRS-kontrolluppgifter ska utformas samt hur den ska lämnas in till Skatteverket.

Denna utgåva av teknisk beskrivning gäller för redovisning av CRS-kontrolluppgifter som lämnas in under 2019 och avser inkomståret (kalenderåret) 2018.

Observera att detta är ett utkast av utgåva 3, av den tekniska beskrivningen för CRS-kontrolluppgifter. Större och väsentliga förändringar i innehåll och redovisningar jämfört med föregående utgåva är följande:

Förändrade och nya verksamhetskontroller i e-tjänsterna o Se avsnitt 7

Förtydligad information om odokumenterat konto o Se avsnitt 3.3.2 och 3.5.2

Landskoden AX får inte användas för att ange hemvist o Se avsnitt 3.5.2, 3.5.9 och 3.7.1

Förtydliganden om vilken information som ska lämnas för enheter samt när det finns personer med bestämmande inflytande (ControllingPerson)

o Se avsnitt 3.6, 3.7 och 3.7.7

Dessa och andra mindre förändringar mot tidigare utgåva är markerat med grått nedan. Observera att e-tjänsten för inlämning på Skatteverkets webbplats i dagsläget inte är fullt anpassad till inkomståret 2018.

Ny version av e-tjänsten kommer i början av april 2019 och Skatteverket rekommenderar därför att inlämning av CRS-rapporter avseende inkomståret 2018 sker tidigast i april 2019.

Om ni som finansiellt institut har frågor om denna tekniska beskrivning eller andra frågor om CRS kan ni kontakta Skatteverket via finansiella.konton@skatteverket.se.

De finansiella institut som ska skicka in, rätta eller komplettera CRS-kontrolluppgifter avseende inkomstår 2016 eller 2017 ska kontakta Skatteverket via e-post finansiella.konton@skatteverket.se innan uppgifterna skickas in. Vid sådan rapportering ska senaste utgåvan av teknisk beskrivning och User Guide (Second edition) tillämpas.

Skatteverket skickar löpande ut information om nyheter avseende CRS och FATCA i ett nyhetsbrev via e-post. Om du vill få detta nyhetsbrev så kan du kontakta Skatteverket via e-post finansiella.konton@skatteverket.se så läggs du till på vår sändlista.

Information om hur du lämnar FATCA-kontrolluppgifter finns i SKV260-FATCA. Se www.skatteverket.se/fatca.

CRS – vad är det? Arbete inom OECD och EU har resulterat i att ett stort antal länder utbyter upplysningar om finansiella konton. CRS – Common Reporting Standard - är OECD:s standard för att underlätta ett automatiskt informationsutbyte av upplysningar om finansiella konton mellan olika länder. EU:s regelverk för informationsutbyte om finansiella konton mellan medlems-staterna heter DAC 2 (Directive on Administrative Cooperation). Regelverken liknar varandra

SKV260-CRS Utgåva 3 (utkast 1, februari 2019) 4

och är införda gemensamt i svensk lagstiftning. I den här tekniska beskrivningen används fortsättningsvis bara ”CRS”, även om båda regelverken omfattas.

CRS innebär att svenska rapporteringsskyldiga finansiella institut ska

anmäla till Skatteverket att de är rapporteringsskyldiga,

granska och identifiera rapporteringspliktiga konton och

lämna kontrolluppgifter till Skatteverket om rapporteringspliktiga, samt odokumenterade, finansiella konton.

Detta gäller för finansiella konton som innehas av privatpersoner och företag (enheter) som har skatterättslig hemvist i något annat land än Sverige och USA. Kontrolluppgifter ska lämnas oavsett hemvistland och oavsett om Sverige har ett informationsutbytesavtal med landet ifråga. Skatteverket skickar sedan uppgifterna vidare till respektive land som deltar i informations-utbytet om finansiella konton.

Bestämmelser om CRS-kontrolluppgifter finns i Skatteförfarandelagen (2011:1244) och Skatteförfarandeförordningen (2011:1261), förkortade till SFL resp. SFF nedan.

En kort information om CRS hittar du på Skatteverkets webbplats, www.skatteverket.se/crs. Där finns även information om hur du anmäler dig som rapporteringsskyldigt finansiellt institut till Skatteverket samt blankett för anmälan. Mer utförlig information om CRS finns i Skatteverkets Rättslig vägledning.

Inlämning av CRS-kontrolluppgifter Kontrolluppgifter om rapporteringspliktiga konton, så kallade CRS-kontrolluppgifter, avseende inkomstår 2018 ska vara Skatteverket tillhanda senast den 15 maj 2019.

Inlämningen av CRS-kontrolluppgifter till Skatteverket ska göras i XML-filer som baseras på det XML-schema som publicerats av OECD (Standard for Automatic Exchange of Financial Account Information in Tax Matters, CRS XML Schema v. 1.0). Schemat, som är det av Skatteverket fastställda formuläret för rapportering av CRS-kontrolluppgifter, finns att tillgå på Skatteverkets och OECD:s webbplatser, www.skatteverket.se/crs och www.oecd.org/tax/automatic-exchange/common-reporting-standard/.

Använd Skatteverkts e-tjänst, Lämna filer – CRS och FATCA samt CbCR, för inlämning av CRS-kontrolluppgifter. Mer information om hur CRS-kontrolluppgifter ska lämnas till Skatteverket finns i avsnitt 5. På Skatteverkets webbplats finns ett antal publicerade exempelfiler (XML-filer). Dessa exempelfiler uppfyller de formella och tekniska krav som ställs för rapportering av CRS-kontrolluppgifter till Skatteverket. Du hittar exempelfilerna på www.skatteverket.se/crs.

På Skatteverkets webbplats finns även en e-tjänst, Test av filer – CRS och FATCA samt CbCR, där det är möjligt att testa XML-filer med CRS-kontrolluppgifter och se att de uppfyller Skatteverkets tekniska grundkrav. Läs mer om e-tjänsten för test i avsnitt 4.1.

Observera att det XML-format som beskrivs i Teknisk beskrivning – för elektronisk redovisning av kontrolluppgifter (SKV260), inte kan användas för att lämna in CRS-kontrolluppgifter. Det är inte heller möjligt att lämna in CRS-kontrolluppgifter via samma inlämningsvägar som vanliga kontrolluppgifter.

SKV260-CRS Utgåva 3 (utkast 1, februari 2019) 5

Nollrapportering

I vissa länder finns det krav på att ett rapporteringsskyldigt finansiellt institut, som inte har några uppgifter om rapporteringspliktiga konton, ska lämna en uppgift om att det inte finns något att rapportera, så kallad nollrapportering. Något sådant krav på rapportering finns inte i svensk lagstiftning och någon nollrapportering ska därför inte göras till Skatteverket. Observera att rapporteringsskyldiga finansiella institut ska göra en anmälan till Skatteverket att de är ett rapporteringsskyldigt finansiellt institut och att det ska göras även om det inte finns några uppgifter att rapportera. Mer information om anmälan finns på www.skatteverket.se/crs under rubriken Anmälan.

Om det blir fel

Om fel upptäcks i de filer med CRS-kontrolluppgifter som lämnats till Skatteverket är det möjligt att göra rättelser eller kompletteringar. Kontakta alltid Skatteverket via e-post (finansiella.konton@skatteverket.se) innan ni lämnar in era rättelser eller kompletteringar.

Inlämnade rapporter med CRS-kontrolluppgifter avseende inkomstår 2018 kan fram till och med 30 augusti 20191 enkelt rättas genom att en helt ny rapport lämnas in. Kontrolluppgifter kan då läggas till, tas bort eller justeras i den nya rapporten. I dessa rapporter ska DocTypeIndic anges som OECD1. Observera att samma MessageRefId som användes vid den ursprungliga rapporteringen måste användas vid dessa rättelser. När samma MessageRefId används på den nya rapporten så ersätts tidigare rapporter med CRS-kontrolluppgifter i sin helhet av den senast inlämnade rapporten.

Om ytterligare uppgifter ska läggas till tidigare rapportering kan antingen en helt ny rapport innehållande samtliga uppgifter (dvs. tidigare inlämnade och nytillkomna) och med samma MessageRefId lämnas in eller så lämnas ytterligare en rapport med annat MessageRefId och enbart innehållande de nya uppgifterna.

Rättelser efter informationsutbyte

Efter att Skatteverket har skickat rapporterna med CRS-kontrolluppgifter till respektive mottagarland, dvs. efter den ordinarie rapporteringen, så ska de förfaranden för rättelser som beskrivs på sidorna 252 - 271 i CRS User Guide (Version 2.0) användas. Kontakta alltid Skatteverket via e-post (finansiella.konton@skatteverket.se) innan ni lämnar in era rättelser.

Hur du läser den tekniska beskrivningen I denna tekniska beskrivning finns information om hur de XML-filer som ska användas vid inlämningen av CRS-kontrolluppgifter till Skatteverket ska utformas samt hur de kan lämnas in till Skatteverket. Information om det XML-schema som ska användas, CRS XML Schema v. 1.0, finns i första hand i Common Reporting Standard User Guide, Version 2.0. Mer information finns i nästa avsnitt. Rubrikerna i denna tekniska beskrivning är på engelska och motsvarar de olika delarna, eller elementen, i XML-schemat som ska fyllas i, alternativt inte fyllas i.

Anpassningar och förtydliganden av hur XML-filen ska fyllas i utifrån det svenska regelverket finns beskrivet i avsnitt 1-4. Det ska ses som en hjälp och ett komplement till CRS User Guide.

1 Observera att sista dag att lämna CRS-kontrolluppgifter är 15 maj året efter inkomståret.

SKV260-CRS Utgåva 3 (utkast 1, februari 2019) 6

Common Reporting Standard User Guide, Version 2.0 Common Reporting Standard User Guide (nedan kallad User Guide eller CRS User Guide) är en del i OECD:s Standard for Automatic Exchange of Financial Account Information in Tax Matters (Second Edition) och den finns i Annex 3. Under 2017 publicerades en andra utgåva av Standard for Automatic Exchange of Financial Account Information in Tax Matters. Det är enbart den sista delen av CRS User Guide som utökats och den innehåller numera ytterligare information om hantering av korrigeringar av CRS-rapporteringar och fler korrigerings-exempel. Övriga delar av OECD:s Standard for Automatic Exchange of Financial Account Information in Tax Matters är oförändrade i förhållande till första utgåvan utfärdad 2014.

CRS User Guide är uppdelad i sex avsnitt samt två bilagor (Appendix A och B). Utöver det inledande avsnittet Introduction och How the CRS User Guide links to the CRS Schema, finns de fyra avsnitten

Message Header

PersonParty_Type

OrganisationParty_Type

CRS Body.

I de olika avsnitten finns utförlig information om specifika dataelement och ibland attribut som beskriver dataelementet. För varje dataelement och dess attribut anges om elementet måste ingå i filen (mandatory eller validation), är valfri (optional), eller inte används (null). Följande termer används genomgående:

Validation (validering) – Uppgiften krävs för schemavalidering och måste inkluderas.

Mandatory (obligatorisk) – Uppgiften krävs inte för schemavalidering, men krävs för rapportering av CRS-kontrolluppgifter.

Optional (frivillig) – Uppgiften krävs inte för rapportering av CRS-kontrolluppgifter, men ska lämnas om den finns tillgänglig.

Optional (non CRS) – Uppgiften krävs inte för rapportering av CRS-kontroll-uppgifter och kan utelämnas.

Common Reporting Standard User Guide, version 2.0, finns att tillgå på Skatteverkets och OECD:s CRS-webbplatser, www.skatteverket.se/crs och www.oecd.org/tax/automatic-exchange/common-reporting-standard/.

Förutom de kontroller som beskrivs i User Guide (och finns i schemat) har Skatteverket valt att lägga till ytterligare kontroller, t.ex. att vissa element ska anges på ett bestämt sätt, se avsnitt 7 för beskrivning av de s.k. verksamhetskontrollerna.

CRS XML och Skatteverket Vid framtagandet av XML-filer för inlämning av CRS-kontrolluppgifter ska det XML-schema som publicerats av OECD (CRS XML Schema v. 1.0) användas. Schemat, som är det av Skatteverket fastställda formuläret för rapportering av CRS-kontrolluppgifter, finns att tillgå på Skatteverkets och OECD:s webbplatser, www.skatteverket.se/crs och www.oecd.org/tax/automatic-exchange/common-reporting-standard/.

SKV260-CRS Utgåva 3 (utkast 1, februari 2019) 7

Schemat CRS XML v. 1.0

Information om CRS XML Schema v. 1.0 finns i första hand i CRS User Guide. I de två bilagorna (Appendix A och B) till User Guide finns bilder som grafiskt visar struktur m.m. för CRS XML Schema v. 1.0.

Informationen i avsnitten 1-4 i denna tekniska beskrivning ska ses som ett komplement till och förtydligande av den information som finns i User Guiden. Schemat CRS XML Schema v 1.0 har företräde framför någon information som presenteras i denna tekniska beskrivning eller CRS User Guide.

Principer för XML-filer för CRS

Alla XML-filer ska överensstämma med rekommenderad praxis. Vissa specialtecken och mönster är förbjudna och om detta ingår i filen kommer den inte vara möjlig att lämna in. För att XML-filen ska vara korrekt ska den inledas med en XML-header, <?xml version="1.0" encoding="UTF-8"?>. XML-filen får inte innehålla stora mängder blanktecken.

Den teckenuppsättning som ska användas är UTF-8. Specialtecknen ska konverteras till det format som visas i nedanstående tabell.

Tecken XML-format Anmärkning

& &amp; Obligatorisk konvertering

< &lt; Obligatorisk konvertering

’ &apos; Obligatorisk konvertering

” &quot; Obligatorisk konvertering

> &gt; Konverteringen är inte obligatorisk, men motsvarar god praxis

-- Saknas Får inte användas

# Saknas Får inte användas

/* Saknas Kombinationen får inte användas

&# Saknas Kombinationen får inte användas

Filer får inte innehålla tecknet  = Byte Order Mark (BOM) eller taggen !DOCTYPE. Det latinska alfabetet (se t.ex. ISO 8859-1) ska användas vilket innebär att t.ex. å, ä och ö är tillämpliga. Landskoder ska anges med två tecken och följa ISO 3166-1 Alpha 2. Valutakoder ska anges med tre tecken och följa ISO 4217 Alpha 3. Tillåtna landskoder och valutakoder framgår av CRS XML Schema v. 1.0.

Avsnitt och delar i CRS XML

CRS XML Schema v. 1.0 är uppdelat i ett antal avsnitt och delar. I avsnitt 1-3 i denna tekniska beskrivning finns information om vad som ska fyllas i under respektive avsnitt och del. I en bilaga (appendix A) till User Guide finns ett antal schemabilder som visar olika avsnitt och delar i schemat.

Bilden nedan visar de väsentliga avsnitten och delarna i CRS XML. Dessa är MessageSpec och CrsBody samt ReportingFI och ReportingGroup (som är en undernivå till CrsBody).

SKV260-CRS Utgåva 3 (utkast 1, februari 2019) 8

När uppgifter fyllts i under de olika avsnitten sammanställs de till en XML-fil, en rapport. Med rapport menas nedan den XML-fil som sammanställts och ska lämnas till Skatteverket, se avsnitt 4.

Observera att vid rapporteringen till Skatteverket får det bara finnas en (1) CrsBody per XML-fil.

Uppgifter som ska lämnas i rapporten (XML-filen)

1 MessageSpec Avsnittet Rapportspecifikation (MessageSpec) är uppdelat i elva delar; SendingCompanyIN, TransmittingCountry, ReceivingCountry, MessageType, Warning, Contact, MessageRefId, MessageTypeIndic, CorrMessageRefId, ReportingPeriod och Timestamp (se bild på sidan 274, Appendix A i User Guide).

Avsnittet MessageSpec ska finnas med vid rapporteringen till Skatteverket, men det kommer inte att vidarebefordras till mottagande land.

1.1 SendingCompanyIN Här anges det svenska organisationsnumret för det rapporteringsskyldiga finansiella institutet (SendingCompanyIN) som lämnar in rapporten.

Denna uppgift är frivillig enligt schemat, men obligatorisk vid rapportering till Skatteverket.

Ett svenskt organisationsnummer ska inledas med sekelsiffra följt av organisations-numret som anges utan bindestreck. För svenska enheter ska sekelsiffran vara 16.

o Exempel: 165029000030

Observera att det svenska organisationsnummer som anges här normalt ska vara samma som det som redovisas under ReportingFI/IN. Se avsnitt 2.2.

1.2 TransmittingCountry Rapporterande land (TransmittingCountry) avser det land där rapporten lämnas in och även det land som rapporteringen skickas ifrån.

Här anges alltid SE (Sverige).

SKV260-CRS Utgåva 3 (utkast 1, februari 2019) 9

1.3 ReceivingCountry Mottagande land (ReceivingCountry) avser det land som ska ta emot de kontrolluppgifter om rapporteringspliktiga konton som finns i rapporten.

Här anges alltid SE (Sverige).

1.4 MessageType Här ska det fyllas i vilken typ av uppgifter (MessageType) som lämnas i rapporten.

Här anges alltid CRS.

1.5 Warning Tillägg (Warning) kan användas för att skriva in extra information om rapportens innehåll, men ska inte användas vid rapporteringen till Skatteverket.

Uppgiften ska inte fyllas i.

1.6 Contact Kontaktuppgifter (Contact) avser uppgifter om det företag som lämnar in rapporten. Vid rapporteringen till Skatteverket ska uppgifterna för företaget eller den som har lämnat uppgiften fyllas i här.

Denna uppgift är frivillig enligt schemat, men obligatorisk vid rapportering till Skatteverket.

Här anges

o Företagets namn samt namn, telefonnummer och e-postadress för en kontaktperson.

o Exempel: Stora Banken AB, Lasse Larsson, 0812345678, lars.larsson@storabanken.se

1.7 MessageRefId Här ska ett unikt identifieringsnummer (MessageRefId) fyllas i. MessageRefId ska användas som referens vid korrigeringar till Skatteverket efter ordinarie rapportering.

Identifieringsnumret bestäms av uppgiftslämnaren, men det måste följa nedanstående struktur. Ett korrekt MessageRefId

ska inledas med IN (Identification Number) för det rapporteringsskyldiga finansiella institut (ReportingFI) som rapporten avser.

o D.v.s. samma organisationsnummer (IN), inklusive sekelsiffra, som finns i avsnittet ReportingFI/IN.

IN ska följas av punkt (.) och det år som uppgifterna avser (t.ex. 2018).

o Det ska vara samma år som finns i avsnittet MessageSpec/ReportingPeriod.

Årtal följs av punkt (.) och minst tre (3) och max 182 unika alfanumeriska tecken. Med alfanumeriska tecken avses 0-9, a-z och A-Z.

Exempel: 165678901234.2018.54321

Maximalt antal tillåtna tecken är 200.

1.8 MessageTypeIndic Här är det möjligt att ange vilken typ av rapportering det är fråga om.

SKV260-CRS Utgåva 3 (utkast 1, februari 2019) 10

Uppgiften ska inte fyllas i.

1.9 CorrMessageRefId Identifieringsnummer för rättade uppgifter (CorrMessageRefId) ska inte fyllas i vid den ordinarie rapporteringen.

Uppgiften fylls endast i vid rättelser efter informationsutbyte

o Kontakta alltid Skatteverket innan ni lämnar in rättelser. Se avsnittet ”Om det blir fel” på sidan 4.

1.10 ReportingPeriod Det inkomstår (kalenderår) som rapporten avser (ReportingPeriod). Året ska anges i formatet ÅÅÅÅ-MM-DD. Året ska alltid följas av månad 12 och dag 31.

För de rapporter som ska lämnas in avseende 2018 ska 2018-12-31 anges.

1.11 Timestamp Tidsstämpel (Timestamp) som visar när rapporten sammanställdes. Uppgiften avser datum och klockslag.

Här anges det när rapporten sammanställdes. Använd formatet ÅÅÅÅ-MM-DD’T’tt:mm:ss.

o Exempel: 2019-04-25T08:45:30

Observera att om flera rapporter lämnas in, t.ex. vid rättelse eller komplettering, bör tidsstämpelen vara senare än den tidigare rapporten och visa när rapporten sammanställdes.

2 ReportingFI I avsnittet rapporteringsskyldigt finansiellt institut (ReportingFI) lämnas uppgifter om det finansiella institut som är uppgiftslämnare för rapporteringspliktiga konton. ReportingFI är uppdelad i fem delar (element); ResCountryCode, IN, Name, Address och DocSpec.

Uppgifterna som anges under avsnittet ReportingFI ska avse samma rapporteringsskyldiga finansiella institut som angetts under MessageSpec/SendingCompanyIN.

2.1 ResCountryCode Landskod för hemvist (ResCountryCode) avser vilket land som det finansiella institutet har sin hemvist i.

Uppgiften ska inte fyllas i.

Om uppgiften ändå fylls i ska SE anges

2.2 IN Här anges det svenska organisationsnumret (IN) för det finansiella institutet som rapporten avser.

Ett svenskt organisationsnummer ska inledas med sekelsiffra följt av organisations-numret, som anges utan bindestreck. För svenska enheter ska sekelsiffran vara 16.

o Exempel: 165029000030

SKV260-CRS Utgåva 3 (utkast 1, februari 2019) 11

o Det är samma organisationsnummer, inklusive sekelsiffra, som finns i avsnittet MessageSpec/SendingCompanyIN som ska anges.

Attributet INType ska inte användas i detta avsnitt.

Om attributet IssuedBy används, ska SE anges.

2.3 Name Här ska det finansiella institutets namn (Name) anges.

Här anges det registrerade namnet.

o Attributet nameType ska inte anges.

2.4 Address Adress (Address) avser det finansiella institutets adress. Uppgift ska lämnas om landskod (CountryCode) för det finansiella institutets adress samt fullständig adress. Det finns två alternativ för att ange adress, AddressFree eller AddressFix. I första hand ska AddressFix användas. Se avsnitt IId på sidan 239 i User Guide.

I CountryCode anges SE för en svensk adress.

I AddressFix eller AddressFree ska fullständig adress anges.

I AddresFix ska alltid City anges.

Om AddressFree används rekommenderas att uppgifterna lämnas i ordningen gata, delstat, postnummer och postort. Uppgifterna kan lämpligen åtskiljas av blanksteg eller slashtecken (/), t.ex.

o Byvägen1/11111/Storstad.

2.5 DocSpec DocSpec är uppdelad i fyra delar (element); DocTypeIndic, DocRefId, CorrMessageRefId och CorrDocRefId. Dessa fyra delar visar status för de uppgifter som anges i detta avsnitt samt identifieringsnummer för uppgifterna. Följande uppgifter lämnas under respektive del:

2.5.1 DocTypeIndic

Typ av information (DocTypeIndic) avser status för uppgiften. Den kan vara ny (New), rättad (Corrected) eller borttag (Deletion) av data. Bara en typ av information (DocTypeIndic) kan anges i respektive rapport. Det går alltså inte att ange OECD1 och OECD2 i samma rapport.

Här anges OECD1 (New Data).

o OECD2 (Corrected) eller OECD3 (Deletion) ska användas vid t.ex. rättelser eller borttag efter informationsutbyte, dvs. de används inte vid den ordinarie rapporteringen.

o OECD11 - OECD13 avser testuppgifter och ska inte användas.

OECD0 (Resent Data) ska endast användas vid rättelser efter informationsutbyte och det kan bara anges under ReportingFI.

o Kontakta alltid Skatteverket innan ni lämnar in rättelser. Se avsnittet ”Om det blir fel” på sidan 4.

SKV260-CRS Utgåva 3 (utkast 1, februari 2019) 12

2.5.2 DocRefId

Här ska ett identifieringsnummer för avsnittet (DocRefId) fyllas i. DocRefId ska användas som referens vid korrigeringar till Skatteverket efter ordinarie rapportering. Det kan även användas vid kontakt mellan uppgiftslämnare och Skatteverket, t.ex. vid frågor om innehållet.

Identifieringsnumret bestäms av uppgiftslämnaren, men ska vara unikt för uppgiftslämnaren över all tid och måste bestå av följande tre delar; IN, år och minst tre tecken.

DocRefId (identifieringsnumret) ska inledas med IN (Identification Number) för det rapporteringsskyldiga finansiella institut (ReportingFI) som rapporten avser. Det är samma organisationsnummer, inklusive sekelsiffra, som finns i avsnittet ReportingFI/IN, som ska användas.

IN ska följas av punkt (.) och det år som uppgifterna avser (t.ex. 2018).

o Det ska vara samma år som finns i avsnittet MessageSpec/ReportingPeriod.

Årtalet följs av punkt och minst tre (3) och max 172 unika alfanumeriska tecken. Med alfanumeriska tecken avses 0-9, a-z och A-Z.

Maximalt antal tillåtna tecken är 200.

Exempel: 165678901234.2018.54ac32fde1dfeyh33535

2.5.3 CorrMessageRefId Identifieringsnummer för rättade uppgifter (CorrMessageRefId) ska inte användas vid CRS-rapporteringen.

Uppgiften ska inte fyllas i

2.5.4 CorrDocRefId

Identifieringsnummer för rättade uppgifter (CorrDocRefId) ska inte fyllas i vid den ordinarie rapporteringen.

Uppgiften fylls endast i vid rättelser efter informationsutbyte

o Kontakta alltid Skatteverket innan ni lämnar in rättelser. Se avsnittet ”Om det blir fel” på sidan 4.

SKV260-CRS Utgåva 3 (utkast 1, februari 2019) 13

3 ReportingGroup Rapporteringspliktiga uppgifter (ReportingGroup) är uppdelad i fyra delar. Dessa är Sponsor, Intermediary, AccountReport och PoolReport (se bild här nedan). Uppgifterna rapporteras beroende på av vem och av vilken anledning uppgifterna lämnas.

Observera att det bara får finnas en ReportingGroup under en CrsBody.

3.1 Sponsor Avsnittet uppdragstagande enhet (Sponsor) kan inte användas vid CRS-rapportering (non-CRS).

3.2 Intermediary Avsnittet förmedlare (Intermediary) kan inte användas vid CRS-rapporteringen (non-CRS).

3.3 AccountReport Här ska det rapporteringsskyldiga finansiella institutet lämna uppgifter om varje rapporterings-pliktigt konto. En AccountReport är uppdelad i sex delar; DocSpec, AccountNumber, AccountHolder, ControllingPerson, AccountBalance och Payment (se bild på sidan 278 i User Guide, Appendix A).

Observera att minst en AccountReport måste finnas i varje rapport (CRS XML-fil).

3.3.1 DocSpec

Se information i avsnitt 2.5.

3.3.2 AccountNumber

Uppgift om kontots identifikationsnummer (AccountNumber) lämnas här. Om det inte finns något vanligt kontonummer, ska det nummer som det finansiella institutet använder för att identifiera kontohavarens tillgångar användas.

Här anges kontonumret för det rapporteringspliktiga kontot. Ytterligare uppgifter om kontonumret samt status för kontot lämnas i attributen AccountNumberType, UndocumentedAccount, ClosedAccount och DormantAccount.

Typ av kontonummer (AcctNumberType)

o Behöver inte anges, men om det anges ska OECD601 till OECD605 användas.

SKV260-CRS Utgåva 3 (utkast 1, februari 2019) 14

o Om OECD601 (IBAN) eller OECD603 (ISIN) anges ska kontonumret (AccountNumber) fyllas i enligt branschstandard för IBAN respektive ISIN.

o Se även sidan 246 i User Guide.

Odokumenterat konto (UndocumentedAccount)

o Om kontot är odokumenterat ska true anges med gemener.

o Uppgift om att kontot är odokumenterat ska endast anges för konton där kontohavaren är en fysisk person (Individual)

o Se även information om odokumenterat konto i avsnitt 3.5.2 ResCountryCode

Avslutat konto (ClosedAccount)

o Om kontot är avslutat ska true anges med gemener.

Observera att om true anges så ska AccountBalance alltid anges till 0.00.

Vilande konto (DormantAccount),

o Uppgiften ska inte fyllas i.

o Observera att vilande konton inte är finansiella konton och därför inte ska

rapporteras.

3.3.3 AccountHolder

Uppgift om kontohavare (AccountHolder) lämnas här. Avsnittet är uppdelat i flera delar.

Se avsnitt 3.5 nedan.

3.3.4 ControllingPerson

Uppgift om person som har ett bestämmande inflytande (ControllingPerson) lämnas här i vissa fall. Avsnittet är uppdelat i flera delar.

Se avsnitt 3.7 nedan.

3.3.5 AccountBalance Uppgift om kontots saldo (AccountBalance) ska lämnas här. Uppgiften som ska lämnas avser kontots saldo eller värde, vid utgången av året. Här lämnas även uppgift om saldo för de konton som har avslutats under året. Här lämnas följande uppgifter:

Saldo eller värde ska anges i svenska kronor.

o Om kontot är i annan valuta ska omräkning ske till svenska kronor.

o Anges med två decimaler som avskiljs med . (punkt).

o Saldo eller värde anges så här,

100000.00

Om värdet är 0 (noll) eller negativt, anges 0.00 som värde.

I attributet currCode (valutakod) ska alltid SEK anges.

Observera att för de konton som har avslutats under året, så ska alltid 0.00 anges som värde.

o Se även avsnitt 3.3.2 och Avslutat konto (ClosedAccount)

SKV260-CRS Utgåva 3 (utkast 1, februari 2019) 15

3.3.6 Payment Uppgift om ersättningar (Payment) ska lämnas här. Dessa ersättningar kan vara ränta,

utdelning, annan inkomst samt försäljning och inlösen av tillgångar som förvaras på det

rapporteringspliktiga kontot. I avsnittet ska det utöver ersättningar (PaymentAmnt) lämnas

uppgift om typ av ersättning (Type).

Följande uppgifter är möjliga att ange i elementet Type.

CRS501 = Utdelning

CRS502 = Ränta

CRS503 = Försäljning eller inlösen

CRS504 = Annan inkomst

I elementet PaymentAmnt ska ersättningar anges.

Ersättningar ska anges som bruttobelopp i svenska kronor.

o Om kontot är i annan valuta ska omräkning ske till svenska kronor.

Ersättningar anges med två decimaler som avskiljs med . (punkt). Exempel:

o Ettusen kronor i utdelning anges som 1000.00

o Ett mer ojämnt belopp, t.ex. 1 234 kronor och 56 öre, anges som 1234.56

Om ersättningarna (Payment) är negativa, anges 0.00 som värde.

I attributet currCode (valutakod) ska alltid SEK anges.

Om ersättningar (Payment) saknas bör elementet över huvud taget inte tas med i

rapporteringen.

3.4 PoolReport Gemensam rapportering (PoolReport) används inte vid CRS-rapportering (non-CRS).

3.5 AccountHolder I avsnittet Kontohavare (AccountHolder) lämnas uppgifter om den som är kontohavare för ett finansiellt konto. Uppgift lämnas antingen om fysisk person (Individual) eller om enhet (Organisation). Se bild på sidan 280-281 i User Guide.

3.5.1 Individual

I den här delen lämnas uppgift om kontohavare som är fysiska personer (Individual) och den är uppdelad i sex delar: ResCountryCode, TIN, Name, Address, Nationality och BirthInfo. Uppgifterna ska fyllas i om en fysisk person är kontohavare för ett rapporteringspliktigt finansiellt konto.

3.5.2 ResCountryCode

Landskod för hemvist (ResCountryCode) avser vilket land som kontohavaren för det rapporteringspliktiga kontot har, eller kan antas ha, sin hemvist i. Om kontohavaren har, eller kan antas ha, hemvist i flera stater ska landskoden för samtliga stater rapporteras.

Uppgiften ska alltid anges och vara en landskod, t.ex. DK.

Vid flera hemvist anges varje landskod i separata rader/fält.

SKV260-CRS Utgåva 3 (utkast 1, februari 2019) 16

På OECD:s webbplats finns en portal om automatiskt informationsutbyte. Under CRS Implementation and Assistance går det bl.a. att hitta uppgifter om hur andra länders regler för skattehemvist är uppbyggda.

Observera att finansiella konton är rapporteringspliktiga om de innehas av personer med hemvist i något annat land än Sverige eller USA. Konton med kontohavare som enbart har hemvist i SE eller US är normalt inte rapporteringspliktiga konton.

Odokumenterade konton

Om ett konto är ett så kallat odokumenterat konto, så ska SE anges som landskod för hemvist. Observera att uppgift om att kontot är odokumenterat anges vid AccountNumber (se avsnitt 3.3.2 ovan).

Åland

Åland har en egen landskod (AX) i ISO 3166-1 och denna används normalt endast som ett prefix i postadresser för Åland. Kontohavare som bor på Åland har normalt hemvist i Finland (FI) och vid lämnande av CRS-kontrolluppgifter ska landskoden FI användas för att ange landskod för hemvist (ResCountryCode).

Landskoden AX ska inte användas för att ange hemvist.

3.5.3 TIN Uppgift om skatteregistreringsnummer (Taxpayer Identification Number = TIN) för kontohavaren ska alltid anges om sådant finns.

Här anges kontohavarens TIN

o På OECD:s webbplats finns en portal om automatiskt informationsutbyte. Under CRS Implementation and Assistance går det bl.a. att hitta uppgifter om hur andra länders skatteregistreringsummer (TIN) är uppbyggda.

o De TIN som redovisas här bör följa den uppbyggnad av TIN som finns redovisad för respektive land på OECD:s webbplats

Uppgift om landskod för TIN ska anges i attributet IssuedBy.

o För t.ex. ett finskt TIN ska FI anges.

Om uppgift om flera TIN finns för den fysiska personen ska uppgift lämnas om samtliga TIN, d.v.s. för respektive land. Dessa uppgifter lämnas då i separata rader/fält.

Om den fysiska personen har ett svenskt personnummer eller samordningsnummer, ska detta alltid anges.

o Ett svenskt personnummer ska inledas med sekelsiffra följt av person- eller samordningsnummer. Sekelsiffra är 19 eller 20, t.ex. 197304237055 (totalt 12 tecken). Bindestreck eller plustecken ska inte användas.

o För ett svenskt personnummer ska SE anges i attributet IssuedBy.

Om skatteregistreringsnummer saknas ska elementet TIN utelämnas.

Om elementet TIN finns, måste minst en (1) siffra anges i elementet.

Du kan läsa mer om TIN på Skatteverkets eller OECD:s webbplats.

3.5.4 Name

Uppgift om namn (Name) på den fysiska personen ska fyllas i här. Uppgift ska lämnas om för- och efternamn. Flera av fälten (NamePerson_Type, PrecedingTitle, Title, MiddleName,

SKV260-CRS Utgåva 3 (utkast 1, februari 2019) 17

NamePrefix, GenerationIdentifier, Suffix och GeneralSuffix) är sådana som inte ska användas vid den svenska CRS-rapporteringen. Attributet nameType ska inte användas.

Här anges kontohavarens fullständiga namn (samtliga för- och efternamn).

I elementet FirstName anges kontohavarens förnamn.

o Uppgiften ska alltid anges (obligatorisk).

o Om uppgiften inte finns kan NFN (No First Name) anges.

I elementet LastName anges kontohavarens efternamn.

o Uppgiften ska alltid anges (obligatorisk).

o Om för- och efternamn inte går att särskilja, anges både för- och efternamn här samt NFN i elementet FirstName.

Respektive element måste innehåll minst ett tecken som inte är blanktecken.

3.5.5 Address

Uppgift om den fysiska personens adress (Address) ska fyllas i här. Uppgift ska lämnas om landskod (CountryCode) för den fysiska personens adress samt personens fullständiga adress. Det finns två alternativ för att ange adress (Address_Type): AddressFix eller AddressFree. I första hand ska AddressFix användas. Se avsnitt IId i User Guide.

Här anges landskod (CountryCode) för den stat som adressen hör hemma i.

o För utländsk adress anges det landets landskod, t.ex. FI för en adress i Finland eller NO för en adress i Norge.

o Vid svensk adress anges SE.

I AddressFix eller AddressFree anges kontohavarens fullständiga adress.

När AddresFix används ska elementen anges i den ordning som framgår av schemat.

o Elementet City är obligatoriskt när AddressFix används.

Elementet måste innehålla minst ett tecken som inte är blanktecken.

Om AddressFree används rekommenderas att uppgifterna lämnas i ordningen gata, delstat, postnummer och postort. Uppgifterna kan lämpligen åtskiljas av blanksteg eller slashtecken (/), t.ex.

o Byvägen1/11111/Storstad.

o Elementet måste innehålla minst ett tecken som inte är blanktecken.

o Observera att landskoden (CountryCode) ska motsvara den stat som den angivna adressen finns i även när AddressFree används.

T.ex. ska inte landskoden SE anges för en finsk adress.

Attributet legalAdressType ska inte användas vid den svenska rapporteringen.

3.5.6 Nationality

Uppgift om medborgarskap (Nationality) ska inte lämnas.

Uppgiften ska inte användas vid CRS-rapportering (non-CRS).

3.5.7 BirthInfo

Uppgift om födelsedatum och födelseort (BirthInfo) lämnas här.

SKV260-CRS Utgåva 3 (utkast 1, februari 2019) 18

Här ska kontohavarens födelsedatum (BirthDate) anges.

o Observera att uppgift om födelsedatum alltid ska anges. Tidigare gällde att uppgifter om födelsedatum skulle anges om TIN (skatteregistreringsnummer) saknades.

Födelsedatum anges i formatet ÅÅÅÅ-MM-DD,

o Exempel 1975-01-21.

o Födelsedatum tidigare än 1900-01-01 kan inte anges.

o 1900-01-01 kan anges som födelsedatum för kontohavaren i de fall födelse-datum är 1899-12-31 eller tidigare samt om uppgift om födelsedatum är okänt.

Här anges födelseort (City) och land (CountryInfo) om uppgiften finns i uppgiftslämnarens elektroniskt sökbara databaser.

o I City anges födelseort i klartext.

o I CountryInfo anges CountryCode (landskod) eller FormerCountryName (landsnamn i klartext, t.ex. Jugoslavien).

CitySubentity ska inte fyllas i.

Observera att födelsedatum ska anges även om svenskt person- eller samordningsnummer lämnats under TIN.

3.5.8 Organisation I den här delen lämnas uppgift om enheter (Organisation) och den är uppdelad i fyra delar: ResCountryCode, IN, Name och Address. Uppgifterna ska fyllas i om en enhet är kontohavare för ett rapporteringspliktigt finansiellt konto.

Observera att det även måste fyllas i uppgifter om vilken typ av kontohavare (AcctHolderType) som enheten är, se avsnitt 3.6.

3.5.9 ResCountryCode

Landskod för hemvist (ResCountryCode) avser vilket land som kontohavaren för det rapporteringspliktiga kontot har sin hemvist i. Om enheten har flera hemviststater ska landskoden för samtliga stater rapporteras.

Uppgiften ska alltid anges och vara en landskod, t.ex. DK.

Vid flera landskoder anges varje landskod i separata rader/fält.

Om man inte känner till enhetens hemviststat kan SE anges.

På OECD:s webbplats finns en portal om automatiskt informationsutbyte. Under CRS Implementation and Assistance går det bl.a. att hitta uppgifter om hur andra länders regler för skattehemvist är uppbyggda.

Åland

Åland har en egen landskod (AX) i ISO 3166-1 och denna används normalt endast som ett prefix i postadresser för Åland. En enhet (Organisation) som finns på Åland har normalt hemvist i Finland (FI) och vid lämnande av CRS-kontrolluppgifter ska landskoden FI användas för att ange landskod för hemvist (ResCountryCode).

Landskoden AX ska inte användas för att ange hemvist.

SKV260-CRS Utgåva 3 (utkast 1, februari 2019) 19

3.5.10 IN

Uppgift om skatteregisteringsnummer (Identification Number = IN) för kontohavaren (enheten) ska alltid anges om sådant finns.

Här anges kontohavarens skatteregistreringsnummer (IN)

o På OECD:s webbplats finns en portal om automatiskt informationsutbyte. Under CRS Implementation and Assistance går det bl.a. att hitta uppgifter om hur andra länders skatteregistreringsummer (IN) är uppbyggda.

o De skatteregistreringsnummer (IN) som redovisas här bör följa den uppbyggnad av skatteregistreringsnummer som finns redovisad för respektive land på OECD:s webbplats

o I attributet IssuedBy ska landskod för det aktuella skatteregistreringsnumret anges. För t.ex. ett finskt TIN ska FI anges.

Finns uppgift om flera IN för enheten ska uppgift lämnas om samtliga IN, d.v.s. för respektive land. Dessa uppgifter lämnas då i separata rader/fält.

Om enheten har ett svenskt organisationsnummer ska detta alltid anges.

o Ett svenskt organisationsnummer ska inledas med sekelsiffra följt av organisationsnumret. För svenska enheter ska sekelsiffran vara 16, t.ex. 165029000030. Bindestreck ska inte användas.

o I attributet IssuedBy ska SE anges som landskod för svenska organisationsnummer.

Om skatteregistreringsnummer saknas ska elementet IN utelämnas.

Om elementet IN finns måste minst en (1) siffra anges i elementet.

Om attributet INType används, ska det vara TIN, US GIIN, EIN eller LEI.

3.5.11 Name

Uppgift om namn (Name) på enheten ska fyllas i här. Uppgift ska lämnas om det registrerade namnet.

Här anges kontohavarens registrerade namn.

o Attributet nameType ska inte användas.

3.5.12 Address

Uppgift om enhetens (kontohavarens) adress (Address) ska fyllas i här. Uppgift ska lämnas om landskod (CountryCode) för enhetens adress samt fullständig adress. Det finns två alternativ för att ange adress (Address_Type): AddressFix eller AddressFree. I första hand ska AddressFix användas. Se avsnitt IId i User Guide.

Här anges landskod (CountryCode) för den stat som adressen hör hemma i.

o Vid utländsk adress anges det landets landskod, t.ex. FI för Finland.

o Vid svensk adress anges SE.

I AddressFix eller AddressFree anges kontohavarens fullständiga adress.

När AddresFix används ska elementen anges i den ordning som framgår av schemat.

o Elementet City är obligatoriskt när AddressFix används.

SKV260-CRS Utgåva 3 (utkast 1, februari 2019) 20

Elementet måste innehålla minst ett tecken som inte är blanktecken.

Om AddressFree används rekommenderas att uppgifterna lämnas i ordningen gata, delstat, postnummer och postort. Uppgifterna kan lämpligen åtskiljas av blanksteg eller slashtecken (/), t.ex.

o Byvägen1/11111/Storstad.

o Elementet måste innehålla minst ett tecken som inte är blanktecken.

o Observera att landskoden (CountryCode) ska motsvara den stat som den angivna adressen finns i även när AddressFree används.

T.ex. ska inte landskoden SE anges för en finsk adress.

Attributet legalAdressType ska inte användas vid den svenska rapporteringen.

3.6 AcctHolderType I detta avsnitt ska uppgifter lämnas om vilken typ av kontohavare (AcctHolderType) som en

enhet (Organisation) är. Elementet AcctHolderType är obligatoriskt när en enhet

(Organisation) är kontohavare. Följande uppgifter är möjliga att fylla i:

CRS101 = Passive Non-Financial Entity with – one or more controlling person that is

a Reportable Person.

o CRS101 ska anges för en enhet som är en passiv icke-finansiell enhet och där

en eller flera fysiska personer har bestämmande inflytande och är

rapporteringspliktiga.

När CRS101 anges ska uppgift även lämnas under ControllingPerson.

Se avsnitt 3.7.

CRS102 = CRS Reportable Person.

o CRS102 ska anges för enhet med hemvist i annat land.

CRS103 = Passive Non-Financial Entity that is a CRS Reportable Person.

o CRS103 ska anges för enhet med hemvist i annat land, som är en passiv icke-

finansiell enhet, utan personer med bestämmande inflytande.

Observera att när CRS102 eller CRS103 anges ska inte uppgift lämnas under ControllingPerson.

3.7 ControllingPerson Om kontohavaren är en sådan enhet (CRS101) där en eller flera fysiska personer har ett bestämmande inflytande och är rapporteringspliktiga (ControllingPerson) ska uppgifter lämnas om dessa personer. ControllingPerson är uppdelad i sex delar; ResCountryCode, TIN, Name, Address, Nationality och BirthInfo.

Om CRS102 eller CRS103 angetts under AcctHolderType ska inte uppgift lämnas om fysiska personer som har ett bestämmande inflytande (ControllingPerson).

SKV260-CRS Utgåva 3 (utkast 1, februari 2019) 21

3.7.1 ResCountryCode

Landskod för hemvist (ResCountryCode) avser vilket land som en fysisk person med bestämmande inflytande (ControllingPerson) har sin hemvist i. Om personen har flera hemviststater ska landskoden för samtliga stater rapporteras.

Uppgiften ska alltid anges och vara en landskod, t.ex. DK.

Vid flera landskoder anges varje landskod i separata rader/fält.

På OECD:s webbplats finns en portal om automatiskt informationsutbyte. Under CRS Implementation and Assistance går det bl.a. att hitta uppgifter om hur andra länders regler för skattehemvist är uppbyggda.

Observera att en fysisk person med bestämmande inflytande (ControllingPerson) är rapporteringspliktig om personen har hemvist i något annat land än Sverige eller USA. En fysisk person med bestämmande inflytande som enbart har hemvist i SE eller US är normalt inte rapporteringspliktig.

Åland

Åland har en egen landskod (AX) i ISO 3166-1 och denna används normalt endast som ett prefix i postadresser för Åland. En fysisk person med bestämmande inflytande (Controlling Person) som bor på Åland har normalt hemvist i Finland (FI) och vid lämnande av CRS-kontrolluppgifter ska landskoden FI användas för att ange landskod för hemvist (ResCountryCode).

Landskoden AX ska inte användas för att ange hemvist.

3.7.2 TIN Uppgift om skatteregistreringsnummer (Taxpayer Identification Number = TIN) ska alltid anges om sådant finns.

Här anges TIN för fysisk person med bestämmande inflytande (ControllingPerson)

o På OECD:s webbplats finns en portal om automatiskt informationsutbyte. Under CRS Implementation and Assistance går det bl.a. att hitta uppgifter om hur andra länders skatteregistreringsummer (TIN) är uppbyggda.

o De TIN som redovisas här bör följa den uppbyggnad av TIN som finns redovisad för respektive land på OECD:s webbplats

Uppgift om landskod för TIN ska anges i attributet IssuedBy.

o För t.ex. ett finskt TIN ska FI anges.

Om uppgift om flera TIN finns för den fysiska personen med bestämmande inflytande ska uppgift lämnas om samtliga TIN, d.v.s. för respektive land. Dessa uppgifter lämnas då i separata rader/fält.

Om den fysiska personen med bestämmande inflytande har ett svenskt personnummer, eller samordningsnummer, ska detta alltid anges.

o Ett svenskt personnummer ska inledas med sekelsiffra följt av och person- eller samordningsnummer. Sekelsiffra är 19 eller 20, t.ex. 197304237055 (totalt 12 tecken). Bindestreck eller plustecken ska inte användas.

o För ett svenskt personnummer ska SE anges i attributet IssuedBy.

Om skatteregistreringsnummer saknas ska elementet TIN utelämnas.

SKV260-CRS Utgåva 3 (utkast 1, februari 2019) 22

Om elementet TIN finns måste minst en (1) siffra anges i elementet.

Du kan läsa mer om TIN på Skatteverkets eller OECD:s webbplats.

3.7.3 Name

Uppgift om namn (Name) på den fysiska personen med bestämmande inflytande (Controlling Person) ska fyllas i här. Uppgift ska lämnas om för- och efternamn. Flera av fälten (NamePerson_Type, PrecedingTitle, Title, MiddleName, NamePrefix, GenerationIdentifier, Suffix och GeneralSuffix) är sådana som inte ska användas vid den svenska CRS-rapporteringen. Attributet nameType ska inte användas.

Här anges fullständigt namn (samtliga för- och efternamn) för den fysiska personen med bestämmande inflytande (ControllingPerson).

I elementet FirstName anges förnamn.

o Uppgiften ska alltid anges (obligatorisk).

o Om uppgiften inte finns kan NFN (No First Name) anges.

I elementet LastName anges efternamn.

o Uppgiften ska alltid anges (obligatorisk).

o Om för- och efternamn inte går att särskilja, anges både för- och efternamn här samt NFN i elementet FirstName.

Respektive element måste innehåll minst ett tecken som inte är blanktecken.

3.7.4 Address

Uppgift om adress (Address) för den fysiska personen med bestämmande inflytande (ControllingPerson) ska fyllas i här. Uppgift ska lämnas om landskod (CountryCode) för den fysiska personens adress samt fullständig adress. Det finns två alternativ för att ange adress (Address_Type): AddressFix eller AddressFree. I första hand ska AddressFix användas. Se avsnitt IId i User Guide.

Här anges landskod (CountryCode) för den stat som adressen hör hemma i.

o Vid utländsk adress anges det landets landskod, t.ex. FI för en adress i Finland.

o Vid svensk adress anges SE.

I AddressFix eller AddressFree anges den fysiska personens fullständiga adress.

När AddresFix används ska elementen anges i den ordning som framgår av schemat.

o Elementet City är obligatoriskt när AddressFix används.

Elementet måste innehålla minst ett tecken som inte är blanktecken.

Om AddressFree används rekommenderas att uppgifterna lämnas i ordningen gata, delstat, postnummer och postort. Uppgifterna kan lämpligen åtskiljas av blanksteg eller slashtecken (/), t.ex.

o Byvägen1/11111/Storstad.

o Elementet måste innehålla minst ett tecken som inte är blanktecken.

o Observera att landskoden (CountryCode) ska motsvara den stat som den angivna adressen finns i även när AddressFree används.

T.ex. ska inte landskoden SE anges för en finsk adress.

SKV260-CRS Utgåva 3 (utkast 1, februari 2019) 23

Attributet legalAdressType ska inte användas vid den svenska rapporteringen.

3.7.5 Nationality

Uppgift om medborgarskap (Nationality) ska inte lämnas.

Uppgiften ska inte användas vid CRS-rapportering (non-CRS).

3.7.6 BirthInfo

Uppgift om födelsedatum och födelseort (BirthInfo) lämnas här.

Här ska födelsedatum (BirthDate) för den fysiska personen med bestämmande inflytande (ControllingPerson) anges.

o Observera att uppgift om födelsdatum alltid ska anges. Tidigare gällde att uppgifter om födelsedatum skulle anges om TIN (skatteregistreringsnummer) saknades.

Födelsedatum anges i formatet ÅÅÅÅ-MM-DD.

o Exempel 1975-01-21.

o Födelsedatum tidigare än 1900-01-01 kan inte anges.

o 1900-01-01 kan anges som födelsedatum för den fysiska personen med bestämmande inflytande i de fall födelsedatum är 1899-12-31 eller tidigare saknas samt om uppgift om födelsedatum är okänt.

Här anges födelseort (City) och land (CountryInfo) om uppgiften finns i uppgiftslämnarens elektroniskt sökbara databaser.

o I City anges födelseort i klartext.

o I CountryInfo anges CountryCode (landskod) eller FormerCountryName (landsnamn i klartext, t.ex. Jugoslavien).

CitySubentity ska inte fyllas i.

Observera att födelsedatum ska anges även om ett svenskt person- eller samordningsnummer lämnats under TIN.

3.7.7 CtrlgPersonType Här lämnas uppgifter om hur en fysisk person (som har ett bestämmande inflytande och är rapporteringspliktig) utövar det bestämmande inflytandet över kontohavaren. I CtrlgPersonType kan CRS801 till CRS813 anges.

Om enheten är en juridisk person kan en av följande koder anges för att beskriva hur den fysiska personen utövar bestämmande inflytande

o CRS801= ownership (ägande) o CRS802= other means (annat sätt) o CRS803= senior managing official (anställning eller annat uppdrag)

Om enheten är en juridisk konstruktion som är en trust ska en av följande koder anges för att beskriva hur den fysiska personen utövar bestämmande inflytande

o CRS804= settlor (stiftare) o CRS805= trustee (förvaltare) o CRS806= protector (beskyddare) o CRS807= beneficiary (förmånstagare) o CRS808= other (annat sätt)

SKV260-CRS Utgåva 3 (utkast 1, februari 2019) 24

Om enheten är en annan juridisk konstruktion kan en av följande koder anges för att beskriva hur den fysiska personen utövar bestämmande inflytande

o CRS809= settlor-equivalent (motsvarande stiftare) o CRS810= trustee-equivalent (motsvarande förvaltare) o CRS811= protector-equivalent (motsvarande beskyddare) o CRS812= beneficiary-equivalent (motsvarande förmånstagare) o CRS813= other-equivalent (annat motsvarande sätt)

Observera att

det enligt de nuvarande svenska bestämmelserna om kontrolluppgifter enbart finns en skyldighet att lämna uppgift till Skatteverket om hur en fysisk person utövar bestämmande inflytande när en trust är kontohavare.

bestämmelserna om kontrolluppgifter fr.o.m. inkomståret 2019, dvs. för kontroll-uppgifter som lämnas in 2020 eller senare, har utökats och att uppgifter då även ska lämnas om hur en fysisk person utövar bestämmande inflytande när en juridisk person eller annan juridisk konstruktion är kontohavare.

4 XML-filen för CRS-kontrolluppgifter CRS-kontrolluppgifter ska lämnas in till Skatteverket i en XML-fil, en rapport med kontrolluppgifter. Filen ska vara korrekt ifylld och validerad mot schema CRS XML v. 1.0. Schemat finns att tillgå på www.skatteverket.se/crs och OECD:s webbplats http://www.oecd.org/tax/automatic-exchange/common-reporting-standard/.

I en rapport (XML-fil) med CRS-kontrolluppgifter får det bara finnas uppgifter från en uppgiftslämnare (ReportingFI), d.v.s. en rapport per ReportingFI. För att XML-filen ska vara korrekt ska den alltid inledas med en XML-header, <?xml version="1.0" encoding="UTF-8"?>.

Filnamnet ska inledas med CRS_ och innehålla uppgift om inkomstår samt företagets namn. Filtypen ska vara .xml.

Exempel: CRS_2018_Storabanken.xml.

På Skatteverkets webbplats finns e-tjänst, Test av filer – CRS och FATCA samt CbCR, där XML-filernas kvalitet kan kontrolleras (validering). Läs mer om testtjänsten nedan i avsnitt 4.1.

Varje finansiellt institut som ska lämna CRS-kontrolluppgifter bör innan XML-filen skapas och lämnas in till Skatteverket gå igenom denna tekniska beskrivning och stora delar av CRS User Guide.

Om XML-filen godkänns i Skatteverkets e-tjänster, så innebär det att innehållet uppfyller nästan samtliga de krav på innehållet som beskrivs i denna tekniska beskrivning. Läs mer om verksamhetskontrollerna i e-tjänsterna i avsnitt 7. Viktiga punkter att kontrollera hur de är ifyllda om filen inte godkänns är:

o Att rätt info finns i MessageSpec

Se avsnitt 1 o Att rätt IN använts under ReportingFI

Se avsnitt 2.2 o Att DocRefId är unikt, har rätt format och inleds med IN.

Se avsnitt 2.5

SKV260-CRS Utgåva 3 (utkast 1, februari 2019) 25

o Att landskoder anges med stora bokstäver, t.ex. DE. o Att belopp anges med två (2) decimaler, t.ex. 100.00 med . (punkt) som skiljetecken

4.1 E-tjänsten ”Test av filer – CRS och FATCA samt CbCR” Skatteverket har en e-tjänst där det är möjligt att testa XML-filer med CRS-kontrolluppgifter och se att de uppfyller Skatteverkets grundkrav. Dels testas att filen innehåller suffix ”.xml”, att filen är av XML-format samt att den validerar mot XML-schemat. Förutom schemavalidering finns ytterligare ett antal verksamhetskontroller. Exempel på dessa är

Organisationsnummer ska anges med 12 siffror och inledas med 16, t.ex. 165029000030.

DocRefId är unikt inom hela filen.

Det ska finnas minst en (1) AccountReport i filen.

Maxstorlek för testfiler är 10 MB. Ingen inloggning behövs vid användning av e-tjänsten ”Test av filer – CRS och FATCA samt CbCR”. På sidan www.skatteverket.se/crs finns en länk till e-tjänsten.

E-tjänsten ”Test av filer – CRS och FATCA samt CbCR” är i dagsläget i princip fullt ut anpassad till CRS-rapporteringen för inkomståret 2018.

Observera att vissa förändringar kan komma i den nya versionen av e-tjänsten i början av april 2019.

SKV260-CRS Utgåva 3 (utkast 1, februari 2019) 26

5 Inlämningssätt

5.1 E-tjänsten ”Lämna filer – CRS och FATCA samt CbCR” Rapporter (XML-filer) med CRS-kontrolluppgifter lämnas i första hand in via e-tjänsten ”Lämna filer - CRS och FATCA samt CbCR”, och du hittar den enklast via en länk på www.skatteverket.se/crs.

Observera att e-tjänsten för inlämning av CRS-rapporter på Skatteverkets webbplats i dagsläget inte är fullt ut anpassad till inkomståret 2018.

Ny version av e-tjänsten kommer i början av april 2019 och Skatteverket rekommenderar därför att inlämning av CRS-rapporter avseende inkomståret 2018 sker tidigast i april 2019.

Innan du kan använda e-tjänsten behöver du logga in. Det gör du t.ex. med ett mobilt BankID, en e-legitimation som finns på fil i din dator eller på ett kort. Information om e-legitimation finns bl.a. på Skatteverkets webbplats - se här. När du loggat in till e-tjänsten kommer du till denna sida.

SKV260-CRS Utgåva 3 (utkast 1, februari 2019) 27

Klicka på knappen ”Välj fil” och leta fram den XML-fil med CRS-kontrolluppgifter som du ska lämna in till Skatteverket. Du behöver också välja vilken typ av fil du ska lämna. Här ska du välja CRS XML-schema v. 1.0. Klicka därefter på knappen ”Nästa”.

I nästa steg kontrolleras XML-filens innehåll och om allt är korrekt visas följande sida;

Kontrollera att uppgifterna är riktiga och sätt en bock i rutan vid ”Jag har granskat…” innan du klickar på knappen ”Skicka in”.

När du har skickat in XML-filen får du en kvittens som du kan spara på din dator. Samtliga kvittenser för de XML-filer du lämnat in med din e-legitimation hittar du via menyvalet ”Kvittenser”.

Om den XML-fil som du laddat upp innehåller ett eller flera fel får du information om dessa fel i en teknisk felrapport som du kan skriva ut eller spara ned på din dator. Bilden nedan visar exempel på hur en felrapport kan se ut.

SKV260-CRS Utgåva 3 (utkast 1, februari 2019) 28

Stora filer

E-tjänsten ”Lämna filer - CRS och FATCA samt CbCR” kan inte hantera filer som är ca 40 MB eller större. I dessa fall kan rapporteringen istället delas upp på flera XML-filer. Om rapporteringen delas upp i två eller flera filer så måste dessa filer ha egna unika MessageRefId.

5.2 E-transport Rapporter med CRS-kontrolluppgifter kan även lämnas in via e-transport. E-transport kräver att ni har avtal med Skatteverket samt ett certifikat. Det går att lämna filer maskinellt eller manuellt. För att få behörighet att lämna in CRS-kontrolluppgifter via e-transport ska du kontakta Skatteverket via e-post till finansiella.konton@skatteverket.se. Du kan läsa mer om e-transport och certifikat på Skatteverkets webbplats www.skatteverket.se/e-transport.

5.3 Teknisk support Vid tekniska frågor eller problem angående e-tjänsterna ”Test av filer – CRS och FATCA samt CbCR” eller ”Lämna filer – CRS och FATCA samt CbCR” samt e-transport vänligen kontakta Skatteupplysningen på telefonnummer 0771-567 567. Det är även möjligt att kontakta Skatteverket via e-post till finansiella.konton@skatteverket.se.

SKV260-CRS Utgåva 3 (utkast 1, februari 2019) 29

6 Länkar till CRS-sidor

6.1 Skatteverkets CRS-information Skatteverkets information om CRS finns här www.skatteverket.se/crs.

6.2 OECD:s webbplats om CRS OECD:s samlade information om CRS finns att tillgå här http://www.oecd.org/tax/automatic-exchange/common-reporting-standard/.

7 Verksamhetskontroller CRS När rapporterna med CRS-kontrolluppgifter lämnas in till Skatteverket görs ett antal kontroller (s.k. verksamhetskontroller) i e-tjänsten. När rapporterna med CRS-kontrolluppgifter finns hos Skatteverket görs ytterligare ett antal verksamhetskontroller.

De verksamhetskontroller som är ändrade eller nya är markerade med grått. Tecken som är förbjudna eller där det är obligatorisk konvertering ingår i Skatteverkets verksamhetskontroller. Det innebär att filen inte går att skicka in om den innehåller något av de tecken som räknas upp i tabellen på sidan 6 eller i tabellen nedan.

Kontroll Schema Path Felmeddelande Avsnittet Intermediary ska ej rapporteras CrsBody/ReportingGroup/Intermediary Element is not allowed (C1) Avsnittet PoolReport ska ej rapporteras CrsBody/ReportingGroup/PoolReport Element is not allowed (C2)

Organisationsnummer ska anges med 12 siffror och inledas med 16.

MessageSpec/SendingCompanyIN IN (organisationsnummer) not valid. Must be 12 consecutive digits and start with 16. (C3)

Kontroll mot generell komponent för verifiering av organisationsnummer

MessageSpec/SendingCompanyIN IN (organisationsnummer) not valid (C4)

Kontaktuppgifter måste anges MessageSpec/Contact Contact not populated (C5)

Om elementet finns ska det börja medvärdet som finns i ReportingFI/IN (position 1-12) Position 13 ska vara punkt (.) Position 14-17 ska vara år från ReportingPeriod Position 18 ska vara punkt (.) Position 19-200 ska bestå av minst tre alfanumeriska tecken

MessageSpec/MessageRefID CrsBody/ReportingFI/DocSpec/DocRefId CrsBody/ReportingGroup/AccountReport/DocSpec/DocRefId

Format Not Valid (C6)

År i ReportingPeriod (pos 1-4) ska vara mellan 2016 och kalenderår -1

MessageSpec/ReportingPeriod Year not valid (C7)

IN ska anges med 12 siffror och vara ett formellt korrekt organisationsnummer (se även C3+C4)

CrsBody/ReportingFI/IN Felaktigt IN (organisations-nummer). Numret ska anges med 12 siffror, inledas med sekelsiffran 16 och vara formellt korrekt. (C8)

Attributet issuedBy ska vara SE eller ej angivet

CrsBody/ReportingFI/IN[@issuedBy]

Attributet issuedBy ska vara SE eller ej angivet (C9)

Kontroll att DocRefId är unikt inom hela filen

CrsBody/ReportingFI/DocSpec/DocRefId CrsBody/ReportingGroup/AccountReport/DocSpec/DocRefId

The DocRefId is not unique (C10)

SKV260-CRS Utgåva 3 (utkast 1, februari 2019) 30

Det ska finnas minst en AccountReport om det är en initial fil eller Resend på ReportingFI (DocTypeIndic=OECD1 eller OECD0 på ReportingFI)

CrsBody/ReportingGroup/ AccountReport

Must be provided (C14)

Om AccountHolder är en Organisation och AccountHolderType=CRS101 måste ControllingPerson finnas

CrsBody/ReportingGroup/AccountReport/ControllingPerson

Om AccountHolder är en Organisation och Account HolderType=CRS101 måste ControllingPerson finnas (C27)

Avsnittet Sponsor ska ej rapporteras CrsBody/ReportingGroup/Sponsor/ Element is not allowed (C30)

Belopp ska anges med 2 decimaler CrsBody/ReportingGroup/AccountReport/AccountBalance CrsBody/ReportingGroup/AccountReport/Payment/PaymentAmnt

Belopp ska anges med två decimaler(C31)

Elementet IN är obligatoriskt CrsBody/ReportingFI/IN IN (organisationsnummer) är obligatoriskt (C32)

Det ska bara finnas ett avsnitt CrsBody

CrsBody

Only one CrsBody is allowed (C34)

Kontroll att XML-filen inte innehåller följande tecken eller teckenkombinationer: &# # (Hash) -- (Double Dash) /* (snedstreck asterisk)

Prohibited character(C42)

Kontroll att XML-filen inte innehåller följande tecken eller teckenkombinationer (FI ska ha konverterat dem enligt nedan): & konverteras till: (&amp;) < konverteras till: (&lt;) ’ konverteras till: (&apos; ) " konverteras till : (&quot;)

Konvertering krävs av följande tecken: & konverteras till: (&amp;) < konverteras till: (&lt;) ’ konverteras till: (&apos;) " konverteras till: (&quot;) (C43)

Timestamp ska anges i formatet ÅÅÅÅ-MM-DD[T]tt:mm:ss T.ex. 2019-04-15T14:37:40

MessageSpec/Timestamp Timestamp ska anges i formatet ÅÅÅÅ-MM-DD[T]tt:mm:ss T ex 2019-04-15T14:37:40 (C57)

Om AccountHolder är en Organisation och AccountHolderType=CRS102 eller CRS103 får ControllingPerson inte finnas

CrsBody/ReportingGroup/AccountReport/ControllingPerson

Om AccountHolder är en Organisation och AccountHolderType = CRS102 eller CRS103 får ControllingPerson inte finnas (C62)

Om Accountholder är en Individual får det inte finnas ControllingPerson

CrsBody/ReportingGroup/AccountReport/ControllingPerson

Om Accountholder är en Individual får det inte finnas ControllingPerson (C63)

ResCountryCode är obligatoriskt om CrsBody/ReportingGroup/AccountReport/AccountHolder/Organisation finns

CrsBody/ReportingGroup/AccountReport/AccountHolder/Organisation/ResCountryCode

ResCountryCode ska anges om AccountHolder är en Organisation (C65)

Kontroll att taggen !DOCTYPE inte finns i XML-filen

Taggen !DOCTYPE får inte finnas i XML-filen (C66)

Nyhetsbrev 1(4)

Datum

2018-02-08

Finansiella kontrolluppgifter

Postadress: 171 94 SOLNA Telefon: 0771-567 567

Mejl via "Kontakta oss" på www.skatteverket.se

Februari månads nyhetsbrev!

Här kommer ett extra nyhetsbrev. I det finner du åter informationen om Lex Asea-värden. Ett bolag har tillkommit varför delar av informationen sänds ”i repris”. Dessa uppgifter ligger sist i brevet.

E-tjänsterna för kontrolluppgifter

E-tjänsterna för att testa och lämna in CRS- och FATCA-kontrolluppgifter är i dagsläget i princip fullt ut anpassade till rapporteringen för inkomstår 2018, men Skatteverket rekommenderar att ni avvaktar med att lämna in kontrolluppgifter till början av april 2019.

Tekniska beskrivningar

Nya utgåvor (utkast) av tekniska beskrivningar för CRS- och FATCA-kontrolluppgifter har nu publicerats på vår webbplats, se www.skatteverket.se/crs och www.skatteverket.se/fatca.

Samma XML-scheman och e-tjänst ska användas för rapportering. Inga större förändringar, men vi vill uppmärksamma följande förändringar;

CRS-kontrolluppgifter

Förtydligad information om odokumenterat konto

Landskoden AX (Åland) får inte användas för att ange hemvist

Förtydliganden om vilken information som ska lämnas för enheter samt när det finns personer med bestämmande inflytande (ControllingPerson)

FATCA-kontrolluppgifter

Förtydligad information om FilerCategory och AccountClosed o Dessa två uppgifter är obligatoriska vid rapportering till IRS och uppgifterna

bör därför lämnas till Skatteverket.

Förändringar i redovisning av TIN när ett korrekt amerikanskt skatteregistreringsnummer (US TIN) saknas för kontohavaren.

o AAAAAAAAA (nio A i versaler) ska anges som TIN o 000000000 (nio nollor) ska inte anges som TIN (det har varit möjligt tidigare

år) Synpunkter på och frågor om utkasten skickas till finansiella.konton@skatteverket.se

Slutlig version av de tekniska beskrivningarna publiceras under mars 2019.

Hälsningar

Monica Hellén

Finansiella

Nyhetsbrev 2(4)

Datum

2018-02-08

Finansiella kontrolluppgifter

Värden på utdelade aktier vid lex Asea utdelningar under 2018 när kontrolluppgifter ska lämnas med anledning av FATCA-avtalet samt CRS och DAC 2

Absolicon Solar Collector AB:s utdelning år 2018 av aktier i dotterbolaget Industrial Solar Holding Europe AB

Värdet på utdelningen bör uppgå till 18 kronor för varje innehavd aktie i Absolicon Solar Collector AB när kontrolluppgift ska lämnas med anledning av FATCA-avtalet samt CRS och DAC 2.

För en aktie i Absolicon Solar Collector AB erhölls två aktier i Industrial Solar Holding Europe AB.

Aktierna i det utdelade dotterbolaget Industrial Solar Holding Europe AB är inte noterade varför värdet på utdelningen bör beräknas utifrån värdenedgången av aktierna i Absolicon Solar Collector AB.

Värdenedgången beräknas med ledning av Skatteverkets meddelande SKV M 2018:21. Av meddelandet framgår att värdet på en aktie i Absolicon Solar Collector AB innan utdelningen var 168 kronor. Värdet efter utdelningen var 150 kronor varför värdenedgången på aktien i Absolicon Solar Collector AB uppgick till 18 kronor. Värdet av två utdelade aktier i Industrial Solar Holding Europe AB uppgår då till 18 kronor.

Atlas Copco AB:s utdelning år 2018 av aktier i dotterbolaget Epiroc AB

Värdet på utdelningen bör uppgå till 87,20 kronor för varje innehavd A-aktie i Atlas Copco AB när kontrolluppgift ska lämnas med anledning av FATCA-avtalet samt CRS och DAC 2.

Värdet på utdelningen bör uppgå till 81,12 kronor för varje innehavd B-aktie i Atlas Copco AB när kontrolluppgift ska lämnas med anledning av FATCA-avtalet samt CRS och DAC 2.

För en A-aktie i Atlas Copco AB erhölls en A-aktie i Epiroc AB och för en B-aktie i Atlas Copco AB erhölls en B-aktie i Epiroc AB.

Aktierna i det utdelade dotterbolaget Epiroc AB var marknadsnoterade när utdelningen kunde disponeras. Värdet för lägsta betalkurs för en A-aktie i Epiroc uppgick denna dag till 87,20 kronor. Värdet för lägsta betalkurs för en B-aktie i Epiroc uppgick till 81,12 kronor.

Finansiella

Nyhetsbrev 3(4)

Datum

2018-02-08

Finansiella kontrolluppgifter

Autoliv, Inc.:s utdelning år 2018 av aktier eller depåbevis i Veoneer, Inc.

Värdet på utdelningen bör uppgå till 357 kronor för varje innehavd aktie/depåbevis i Autoliv, Inc. när kontrolluppgift ska lämnas med anledning av FATCA-avtalet samt CRS och DAC 2.

För en aktie/depåbevis i Autoliv, Inc. erhölls en aktie/depåbevis i Veoneer, Inc.

Aktierna/depåbevisen i det utdelade dotterbolaget Veoneer, Inc. var marknadsnoterade när utdelningen kunde disponeras. Värdet för lägsta betalkurs för en aktie/depåbevis i Veoneer, Inc. uppgick denna dag till 357 kronor.

BrainCool AB:s utdelning år 2018 av aktier i dotterbolaget PolarCool AB

Värdet på utdelningen bör uppgå till 0,03 kronor för varje innehavd aktie i BrainCool AB när kontrolluppgift ska lämnas med anledning av FATCA-avtalet samt CRS och DAC 2.

För en aktie i BrainCool AB erhölls en aktie i PolarCool AB.

Aktierna i det utdelade dotterbolaget PolarCool AB noterades först efter tre månader efter utdelningen varför värdet på utdelningen bör beräknas utifrån värdenedgången av aktierna i BrainCool AB.

Värdenedgången beräknas med ledning av Skatteverkets meddelande SKV M 2019:7. Av meddelandet framgår att värdet på en aktie i BrainCool AB innan utdelningen var 6,45 kronor. Värdet efter utdelningen var 6,42 kronor varför värdenedgången på aktien i BrainCool AB uppgick till 0,03 kronor.

Hemfosa fastigheter AB:s utdelning år 2018 av aktier i dotterbolaget Nyfosa AB

Värdet på utdelningen bör uppgå till 41,16 kronor för varje innehavd stamaktie i Hemfosa fastigheter AB när kontrolluppgift ska lämnas med anledning av FATCA-avtalet samt CRS och DAC 2.

För en stamaktie i Hemfosa fastigheter AB erhölls en aktie i Nyfosa AB.

Aktierna i det utdelade dotterbolaget Nyfosa AB var marknadsnoterade när utdelningen kunde disponeras. Värdet för lägsta betalkurs uppgick denna dag till 41,16 kronor.

Finansiella

Nyhetsbrev 4(4)

Datum

2018-02-08

Finansiella kontrolluppgifter

HomeMaid AB:s utdelning år 2018 av aktier i Veteranpoolen AB.

Värdet på utdelningen bör uppgå till 12 kronor för varje innehavd aktie i HomeMaid AB när kontrolluppgift ska lämnas med anledning av FATCA-avtalet samt CRS och DAC 2.

För en A-aktie i HomeMaid erhölls en A-aktie i Veteranpoolen AB och för en B-aktie i HomeMaid AB erhölls en B-aktie i Veteranpoolen AB. Enbart B-aktier i Veteranpoolen AB är noterade varför värdet på utdelad A-aktie i Veteranpoolen AB bör motsvara värdet på utdelad B-aktie.

B-aktierna i det utdelade dotterbolaget Veteranpoolen AB noterades den 30 januari 2018. Medianvärdet av de fem första handelsdagarnas lägsta betalkurser uppgick till 12 kronor.

Ifox Investment AB:s utdelning år 2018 av aktier i dotterbolaget Nickel Mountain Resources AB

Värdet på utdelningen bör uppgå till 0,44 kronor för varje innehavd aktie i Ifox Investment AB när kontrolluppgift ska lämnas med anledning av FATCA-avtalet samt CRS och DAC 2.

För en aktie i Ifox Investment AB erhölls två aktier i Nickel Mountain Resources AB.

Aktierna i det utdelade dotterbolaget Nickel Mountain Resources AB var marknadsnoterade när utdelningen kunde disponeras. Värdet för lägsta betalkurs uppgick denna dag till 0,22 kronor varför värdet av två erhållna aktier i Nickel Mountain Resources AB uppgick till 0,44 kronor.

Curaçao Status:

Legal basis: See definition of the term “Reportable Jurisdiction” in Art. 2a(8) of the Landsbesluit, Houdende Algemene Maatregelen, van de 27ste juni 2017 tot wijziging van het Landsbesluit internationale

bijstandsverlening bij de heffing van belastingen.

Jurisdiction Committed Data collection as of Reporting by

Deadline to amend the lists: N/A N/A

Argentina 2017 01-07-2017 31-03-2018

Australia 2018 01-07-2017 31-03-2018

Austria 2018 01-07-2017 31-03-2018

Azerbaijan 2018 01-07-2017 31-03-2018

Belgium 2017 01-07-2017 31-03-2018

Brazil 2018 01-07-2017 31-03-2018

Bulgaria 2017 01-07-2017 31-03-2018

Canada 2018 01-07-2017 31-03-2018

Chile 2018 01-07-2017 31-03-2018

China (People's Republic of) 2018 01-07-2017 31-03-2018

Colombia 2017 01-07-2017 31-03-2018

Curaçao Status:

Legal basis: See definition of the term “Reportable Jurisdiction” in Art. 2a(8) of the Landsbesluit, Houdende Algemene Maatregelen, van de 27ste juni 2017 tot wijziging van het Landsbesluit internationale

bijstandsverlening bij de heffing van belastingen.

Jurisdiction Committed Data collection as of Reporting by

Croatia 2017 01-07-2017 31-03-2018

Czech Republic 2017 01-07-2017 31-03-2018

Denmark 2017 01-07-2017 31-03-2018

Estonia 2017 01-07-2017 31-03-2018

Faroe Islands 2017 01-07-2017 31-03-2018

Finland 2017 01-07-2017 31-03-2018

France 2017 01-07-2017 31-03-2018

Germany 2017 01-07-2017 31-03-2018

Gibraltar 2017 01-07-2017 31-03-2018

Greece 2017 01-07-2017 31-03-2018

Greenland 2018 01-07-2017 31-03-2018

Guernsey 2017 01-07-2017 31-03-2018

Hungary 2017 01-07-2017 31-03-2018

Iceland 2017 01-07-2017 31-03-2018

India 2017 01-07-2017 31-03-2018

Indonesia 2018 01-07-2017 31-03-2018

Ireland 2017 01-07-2017 31-03-2018

Isle of Man 2017 01-07-2017 31-03-2018

Italy 2017 01-07-2017 31-03-2018

Japan 2018 01-07-2017 31-03-2018

Jersey 2017 01-07-2017 31-03-2018

Korea 2017 01-07-2017 31-03-2018

Latvia 2017 01-07-2017 31-03-2018

Curaçao Status:

Legal basis: See definition of the term “Reportable Jurisdiction” in Art. 2a(8) of the Landsbesluit, Houdende Algemene Maatregelen, van de 27ste juni 2017 tot wijziging van het Landsbesluit internationale

bijstandsverlening bij de heffing van belastingen.

Jurisdiction Committed Data collection as of Reporting by

Lithuania 2017 01-07-2017 31-03-2018

Luxembourg 2017 01-07-2017 31-03-2018

Malaysia 2018 01-07-2017 31-03-2018

Malta 2017 01-07-2017 31-03-2018

Mauritius 2018 01-07-2017 31-03-2018

Mexico 2017 01-07-2017 31-03-2018

Netherlands 2017 01-07-2017 31-03-2018

New Zealand 2018 01-07-2017 31-03-2018

Norway 2017 01-07-2017 31-03-2018

Pakistan 2018 01-07-2017 31-03-2018

Poland 2017 01-07-2017 31-03-2018

Portugal 2017 01-07-2017 31-03-2018

San Marino 2017 01-07-2017 31-03-2018

Saudi Arabia 2018 01-07-2017 31-03-2018

Seychelles 2017 01-07-2017 31-03-2018

Singapore 2018 01-07-2017 31-03-2018

Slovak Republic 2017 01-07-2017 31-03-2018

Slovenia 2017 01-07-2017 31-03-2018

South Africa 2017 01-07-2017 31-03-2018

Curaçao Status:

Jurisdiction Committed Data collection as of Reporting by

Spain 2017 01-07-2017 31-03-2018

Sweden 2017 01-07-2017 31-03-2018

United Kingdom 2017 01-07-2017 31-03-2018

Uruguay 2018 01-07-2017 31-03-2018

Non-residents from all other jurisdictions 01-07-2017 31-03-2018

I

「金融機構執行共同申報及盡職審查作業辦法」

疑義解答(Q&A)

目錄

壹、總則 ................................................ 1

一、 什麼是 CRS？ ................................................ 1

二、 我國實施 CRS 的目的？ ........................................ 1

三、 我國執行 CRS 之法律依據、相關規定及施行日期？ ................ 2

四、 我國將與哪些國家或地區進行稅務用途金融帳戶資訊自動交換？ .... 2

四之一、帳戶持有人如經申報金融機構辨識具 1 個以上應申報國居住者身分，

其持有之金融帳戶資訊應如何申報及交換？(107年 8月 7日增訂) .. 3

五、 稅捐稽徵機關可否直接將所交換資訊用於課稅用途？ .............. 3

六、 與應申報國進行金融帳戶資訊交換，如何確保資訊保密？ .......... 3

七、 金融機構之總機構及分支機構均位於我國境內，由誰進行盡職審查及申

報？ ...................................................... 3

八、 國營金融機構是否應辦理盡職審查及申報？ ...................... 3

九、 本辦法第 3 條得免辦理盡職審查及申報之國際組織為何？ .......... 4

貳、名詞定義 ............................................ 4

十、 本辦法所稱實體是否包含財團法人、社團法人或非法人團體(第 4條)？

...................................................... 4

十一、本辦法第 4 條第 3 項「控制」規定，所稱「持有一實體之表決權及價

值超過百分之五十」，「價值」應如何判斷？ .................... 4

十二、投資公司是否屬申報金融機構？............................... 4

十三、證券投資信託事業或證券投資信託基金是否為申報金融機構？相關之

盡職審查及申報規定為何？ .................................... 4

十四、與全權委託投資相關之盡職審查及申報規定為何？............... 5

十五、與我國特定金錢信託相關之盡職審查及申報規定為何？........... 7

十五之一、第三方支付服務業、電子支付機構及電子票證發行機構是否構成

第 6條存款機構？(107年 8月 7日增訂) ........................ 8

十六、金融機構擔任全球保管機構之次保管機構，應否辦理盡職審查及申

報？.. ...................................................... 8

十七、金融機構擔任合格境外機構投資人之保管機構，應否辦理盡職審查及

申報？ ...................................................... 9

十八、金融機構擔任投資型保險投資資產之保管機構，應否辦理盡職審查及

申報？ ...................................................... 9

II

十九、可能符合投資實體要件之實體為何(第 8條)？................... 9

二十、信託如何認定是否屬金融機構？............................... 9

二十一、投資實體收入比例如何計算(第 8條)？...................... 10

二十二、發行保單之保險公司及其控股公司，何者屬申報金融機構(第 9 條)？

..................................................... 10

二十三、黃金存摺是否屬金融資產(第 10條)？....................... 10

二十四、擔保帳戶是否屬保管帳戶範疇(第 18條)？................... 10

二十五、產物保險契約應否申報？.................................. 11

二十六、儲蓄型保險契約應否申報？................................ 11

二十七、我國既有帳戶與新帳戶之劃分時點與其他國家是否一致？是否合宜

(第 22條)？ ................................................ 11

二十八、既有客戶於 108 年 1 月 1 日後開立之帳戶屬新帳戶或既有帳戶

(第 22 條)？(107年 11月 26日修訂) ......................... 11

二十九、本辦法第 23條第 3款第 2目所稱任何人是否包含要保人本人？. 12

三十、本辦法第 23 條第 7款第 1目及第 2目所稱聯繫之意涵為何？..... 12

三十一、人壽保險身故保險金是否為被排除帳戶之遺產帳戶(第 23 條第 4 款)？

..................................................... 13

三十二、如客戶信用卡溢繳款超過 5 萬美元，為符合本辦法第 14 條免申報信

用卡發卡機構要件規定，該機構於 60 日內應退回客戶溢繳款超過 5 萬

美元部分或全數退回？ ....................................... 13

三十三、被排除帳戶有關退休金或養老金帳戶享有租稅優惠之規定有何限制

(第 23條第 1款)？ .......................................... 13

三十四、金融機構應注意規避適用本辦法之情形有哪些？.............. 13

三十五、國際金融業務分行(OBU)帳戶、國際保險業務分公司(OIU) 保單、國

際證券業務分公司(OSU)帳戶是否須申報？ ...................... 14

三十六、如何查詢應申報國居住者認定原則？........................ 14

三十七、如何認定經認可證券市場？經常性交易(第 25條)？........... 14

三十八、積極非金融機構實體收入比例如何計算(第 28條)？........... 14

三十九、集團因正常避險需要與非關係實體從事避險交易，是否符合積極非

金融機構實體要件規定(第 28條第 1項第 7款)？ ................ 16

四十、公益信託及財團法人是否屬積極非金融機構實體(第 28 條第 1 項第 8

款)？ ..................................................... 16

四十一、有權使用保險契約現金價值或變更受益人之人係指何人(第 29 條第 2

項)？ ..................................................... 16

四十二、應申報國稅籍編號之編碼資訊如何查詢？.................... 16

四十三、我國居住者之稅籍編號為何？.............................. 17

四十四、申報金融機構進行居住地址審查是否應取得本辦法規定之全部證明

文據(第 36 條)？ ............................................ 17

III

叁、盡職審查 ........................................... 17

四十五、申報金融機構審查既有帳戶之高資產帳戶，輔以新帳戶盡職審查程

序，如已依該程序取得自我證明文件，是否仍須依高資產帳戶盡職審查

程序相關規定辦理？申報金融機構無既有帳戶持有人之稅籍編號或出生

日期資訊，應如何辦理申報(第 33 條、第 38 條及第 50 條第 2 項第 1

款)？ ..................................................... 17

四十五之一、金融機構如規劃於 109 年 12 月 31 日前以高資產帳戶審查程序

完成較低資產帳戶盡職審查，則較低資產帳戶於其後任一曆年度之末日

成為高資產帳戶，可否免再依高資產帳戶標準執行審查？(107 年 11 月

26日增訂) ................................................ 18

四十六、申報金融機構於計算非以美元計價之帳戶門檻數額時，應採用之換

算匯率為何？何謂主要往來指定銀行(第 34 條第 2 項)？(107 年 8 月 7

日修訂) ................................................... 18

四十七、依法不得銷售與應申報國居住者之具現金價值保險契約或年金保險

契約，「依法」所指為何(第 35條)？ .......................... 19

四十八、金控集團之銀行、保險公司或同一金融機構得否沿用同一客戶提供

之自我證明文件？(107年 11月 26日修訂) ..................... 19

四十九、何謂經理客戶關係之人(第 38條)？......................... 20

五十、對於客戶不提供身分證明文件者，金融機構應如何辦理？........ 20

五十一、自我證明文件之使用效期？................................ 20

五十二、金融機構得否自訂自我證明文件版本？...................... 20

五十二之一、自 108 年 1 月 1 日起，是否全部新開立之外國帳戶均應取得及

留存帳戶持有人之自我證明文件？(107年 11月 26日增訂) ....... 21

五十三、取得自我證明文件之時限為何？............................ 21

五十四、取得自我證明文件之形式及方式為何？...................... 22

五十五、何謂自我證明文件或證明文據不正確或不合理(第 47條)？..... 22

五十六、申報金融機構得否合併計算客戶於該機構及其關係實體所有金融帳

戶之總餘額或價值？ ......................................... 22

肆、申報 ............................................... 23

五十七、金融帳戶餘額或價值如為負數，應如何申報(第 50條第 1 項)？. 23

五十八、如何認定帳戶終止(第 50條第 1項)？....................... 23

五十九、終止帳戶應如何申報(第 50條第 1項)？..................... 23

五十九之一、申報金融機構於 108 年 12 月 31 日前完成部分較低資產帳戶審

查，是否應於次年 6 月申報該帳戶相關資訊？(107 年 11 月 26 日增訂)

..................................................... 23

IV

六十、第 50 條第 1 項第 7 款所稱申報金融機構為義務人或債務人支付或計入

帳戶持有人之金額包括哪些？ ................................. 23

六十一、何謂合理致力(第 50條第 2項第 1款)？..................... 24

六十二、申報資訊如為不同幣別時，應如何申報(第 50條第 1項)？..... 24

六十三、代金融機構進行盡職審查及申報作業之服務提供者是否有資格或條

件限制？是否應簽立契約(第 52條)？ .......................... 24

六十四、 金融機構授權他人代為收取相關文件，不論係以書面或電子形式，

是否亦適用本辦法規定(第 52條)？ ............................ 24

1

「金融機構執行共同申報及盡職審查作業辦法」

疑義解答(Q&A)

壹、總則

一、 什麼是 CRS？

答：

(一)為有效防杜納稅義務人利用金融資訊保密特性將所得或財

產隱匿於外國金融機構規避稅負，經濟合作暨發展組織

(OECD)界定國際新資訊透明標準為「稅務用途資訊(含金融

帳戶資訊)自動交換」，參考美國「外國帳戶稅收遵從法

(FATCA)」，於 103 年發布「共同申報及盡職審查準則

(Common Standard on Reporting and Due Diligence for

Financial Account Information)」(下稱 CRS)，作為各

國執行金融帳戶資訊交換及國際間同儕檢視之標準。

(二)CRS 運作模式為申報金融機構依國內 CRS 法令，對其管理

之金融帳戶進行盡職審查，於審查後向稅捐稽徵機關申報

應申報國居住者之相關金融帳戶資訊，再由租稅協定主管

機關依據多邊公約、雙邊租稅協定或稅務資訊交換協定

(TIEA)，每年定期將該等帳戶資訊自動交換予締約他方主

管機關。國際間已有 100多個國家或地區承諾實施 CRS。

二、 我國實施 CRS的目的？

答：

(一)OECD 及歐盟等國際組織以一國是否採行國際新標準建置自

動資訊交換機制，判斷其資訊透明程度，定期公布不合作

租稅管轄區名單。對資訊不透明租稅管轄區，國際間常見

採取防禦性手段，包括對這些轄區居住者取得所得適用較

高扣繳率、要求負擔較重之課稅文據義務與舉證責任、對

於自這些轄區取得投資之收益否准適用參與免稅及逕予認

定為受控外國公司等租稅措施。

(二)我國屬海島型經濟，積極推動國際貿易及跨境投資，為營

造優良投資環境，善盡國際義務，避免列入不合作名單，

2

遭國際制裁影響國家形象及經貿投資，因應資訊透明國際

趨勢，落實 CRS 制度，確保臺商海外投資競爭力，吸引海

外資金投資，提升我國整體經濟發展。

三、 我國執行 CRS之法律依據、相關規定及施行日期？

答：為完備按國際新資訊透明標準互惠進行稅務用途資訊(含金

融帳戶資訊)交換法律依據，106 年 6 月 14 日增訂公布稅捐

稽徵法第 5 條之 1、第 46 條之 1，為利後續 CRS 實務執行，

財政部依據稅捐稽徵法第 5 條之 1 第 6 項授權規定訂定金融

機構執行共同申報及盡職審查作業辦法(下稱本辦法)，自發

布日 106年 11月 16日施行。

四、 我國將與哪些國家或地區進行稅務用途金融帳戶資訊自動交

換？

答：

(一)現階段將以雙邊租稅協定或 TIEA 為基礎，與協定夥伴國推

動簽署主管機關協定(CAA)，進行稅務用途金融帳戶資訊自

動交換。財政部將適時發布應申報國名單，以利金融機構

遵循。

(二)本辦法對於金融機構盡職審查程序採廣泛範圍法，金融機

構應蒐集帳戶持有人(或具控制權之人)稅務居住者身分之

特定資訊。倘該等帳戶持有人(或具控制權之人)經辨識為

中國大陸、香港及澳門居住者，由於與中國大陸、香港及

澳門商訂稅務用途資訊交換非屬稅捐稽徵法第 5 條之 1 授

權範圍，不適用本辦法相關申報規定；又倘該等帳戶持有

人(或具控制權之人)經辨識為美國居住者，係依 105 年 12

月 22 日簽署「駐美國台北經濟文化代表處與美國在台協會

合作促進外國帳戶稅收遵從法執行協定」(IGA)之執行，亦

不適用本辦法相關申報規定。

3

四之一、帳戶持有人如經申報金融機構辨識具 1 個以上應申報國

居住者身分，其持有之金融帳戶資訊應如何申報及交換？

(107年 8月 7日增訂)

答：申報金融機構應向稅捐稽徵機關申報帳戶持有人所有具居住

者身分之應申報國及其稅籍編號，由稅捐稽徵機關將前述帳

戶持有人之金融帳戶資訊自動交換與各該應申報國主管機關。

五、 稅捐稽徵機關可否直接將所交換資訊用於課稅用途？

答：締約他方主管機關依雙邊租稅協定或 TIEA，定期提供我方主

管機關之稅務用途金融帳戶資訊，係供評估逃漏稅風險，進

行選案查核，相關核課仍須經稅捐稽徵機關查核相關事證，

方能確認是否涉及逃漏稅情事，尚不至將所交換資訊直接用

於課稅用途。依法誠實申報納稅義務人毋須擔憂前述資訊增

加租稅負擔。

六、 與應申報國進行金融帳戶資訊交換，如何確保資訊保密？

答：按 CRS 運作模式，締約國(地區)雙方得以多邊公約、雙邊租

稅協定或 TIEA 為國際法律基礎，雙方簽訂 CAA 規範應申報

帳戶、應申報資訊之時限及方式等，將金融帳戶資訊自動交

換與他方締約國(地區)主管機關。上述多邊公約、雙邊租稅

協定、TIEA 或 CAA 均訂有保密及資料保護措施，締約雙方對

自他方締約國(地區)取得之稅務用途資訊，負有保密義務。

七、 金融機構之總機構及分支機構均位於我國境內，由誰進行盡

職審查及申報？

答：金融帳戶應由管理該帳戶之金融機構總機構或分支機構進行

盡職審查；金融機構總機構在我國境內者，應由其總機構彙

總申報其於我國境內分支機構所有應申報帳戶資訊，亦得依

第 52 條規定授權他人代為完成其盡職審查及申報義務，但

相關審查及申報責任仍歸屬該申報金融機構。

八、 國營金融機構是否應辦理盡職審查及申報？

答：國營金融機構倘資本為我國政府完全持有，屬本辦法所定政

府實體，惟其從事存款機構、保管機構或特定保險公司商業

4

金融活動所衍生相關義務之給付款，依本辦法第 3 條第 1 款

但書規定，不適用免辦理盡職審查及申報之規定，其如有管

理金融帳戶，包括存款帳戶、保管帳戶、於特定投資實體持

有之權益或債權、具現金價值保險契約及具現金價值年金保

險契約，仍應辦理盡職審查及申報。

九、 本辦法第 3條得免辦理盡職審查及申報之國際組織為何？

答：參考 OECD CRS 第八節 B(3)及 IGA 附錄 2，指國際組織或其

完全持有之機關或機構，符合「主要由政府組成」、「與我

國訂有生效之總部協議或類似協議」及「收入未歸屬於私人

利益」規定之政府間組織(含超國家組織)」。

貳、名詞定義

十、 本辦法所稱實體是否包含財團法人、社團法人或非法人團體

(第 4條)？

答：第 4 條所稱實體，係指自然人以外之人或法律安排，如公司

(營利性社團法人)、基金會(公益性財團法人)、信託、合夥

等。

十一、 本辦法第 4 條第 3 項「控制」規定，所稱「持有一實體之表

決權及價值超過百分之五十」，「價值」應如何判斷？

答：該實體如為公司，依公司股份或資本額；如為合夥，依出資

額或資產清償債務後之賸餘財產；如為信託，為受益人持有

權益之公平市價。

十二、 投資公司是否屬申報金融機構？

答：我國境內之投資公司主要業務如係為客戶或代客戶從事第 8

條第 1 款所列任一目具約束力之投資活動或操作，歸屬於該

等活動或操作之收入合計數達該款所定門檻，且非屬第 3 條

所定免辦理盡職審查及申報者，即屬申報金融機構。

十三、 證券投資信託事業或證券投資信託基金是否為申報金融機構？

相關之盡職審查及申報規定為何？

答：

(一)證券投資信託事業：

5

我國證券投資信託事業為客戶或代客戶從事具約束力之相

關投資活動或操作之最近 3 個會計年度收入合計數達第 8

條第 1 款所定門檻，即屬第 8 條所稱投資實體，為第 5 條

所稱申報金融機構。但其業務如僅為客戶或代客戶從事投

資等目的，就以客戶名義存放於其他金融機構(如保管機構)

之金融資產管理投資組合(如全權委託)，符合第 16 條第 1

款但書規定，非屬其管理之金融帳戶，免辦理盡職審查，

如該事業無應申報帳戶，於依第 51 條規定申報時，應予註

明。

(二) 證券投資信託基金：

1.我國證券投資信託基金由第 6條、第 7條、第 8 條第 1款

及第 9 條所定之存款機構、保管機構、投資實體及特定保

險公司管理，最近 3 個會計年度歸屬於金融資產之投資、

再投資或交易之收入合計數達第 8條第 2款所定門檻，即

屬第 8 條第 2款所稱投資實體，為第 5條所稱申報金融機

構，該基金管理之金融帳戶即客戶於該基金持有之權益，

應依第三章盡職審查程序辨識帳戶持有人之居住者身分，

如帳戶持有人為消極非金融機構實體，應再辨識對該實體

具控制權之人之居住者身分，審查有無應申報帳戶，依第

四章規定申報。

2.我國證券投資信託基金之基金保管機構，如符合第 6 條存

款機構或第 7 條保管機構要件，即為申報金融機構，應依

第三章盡職審查程序辨識證券投資信託基金專戶是否為應

申報帳戶，如該專戶持有人依第 25 條第 2 項規定非屬應

申報國居住者(如證券投資信託基金亦為申報金融機構)，

該帳戶非應申報帳戶，如該保管機構無應申報帳戶，該機

構依第 51條規定申報時，應予註明。

十四、 與全權委託投資相關之盡職審查及申報規定為何？

答：

(一)客戶委任交付委託投資資產者

6

1.證券投資信託事業、證券投資顧問事業或經主管機關核准

經(兼)營全權委託投資業務之信託業、保險業、證券經紀

商、期貨經紀商、期貨經理事業及期貨信託事業等，最近

3 個會計年度歸屬於為客戶或代客戶從事具約束力之投資

活動或操作之收入合計數達第 8條第 1款所定門檻，即屬

投資實體，為申報金融機構。全權委託業務屬為客戶或代

客戶從事投資，就以客戶名義存放於保管機構之金融資產

管理投資組合，因非屬前述事業管理之金融帳戶，免辦理

盡職審查，如該事業無應申報帳戶，於依第 51 條規定申

報時，應予註明。

2.委託人將委託投資資產委任全權委託保管機構保管，該保

管機構符合第 6條存款機構或第 7條保管機構要件，即為

申報金融機構，應依第三章盡職審查程序辨識帳戶持有人

之居住者身分，如帳戶持有人為消極非金融機構實體，應

再辨識對該實體具控制權之人之居住者身分，審查有無應

申報帳戶，依第四章規定申報。

(二)客戶信託移轉委託投資資產者

1.證券投資信託事業、證券投資顧問事業或經主管機關核准

經(兼)營全權委託投資業務者，最近 3 個會計年度歸屬於

為客戶或代客戶從事具約束力之投資活動或操作之收入合

計數達第 8條第 1款所定門檻，即屬投資實體，為申報金

融機構。全權委託業務屬為客戶或代客戶從事投資，就以

客戶名義存放於保管機構之金融資產管理投資組合，因非

屬前述事業管理之金融帳戶，免辦理盡職審查，如該事業

無應申報帳戶，於依第 51條規定申報時，應予註明。

2.委託人將委託投資資產信託移轉全權委託保管機構，由證

券投資信託事業、證券投資顧問事業或經主管機關核准經

(兼)營全權委託投資業務者管理，為客戶從事投資決策及

執行投資或交易，該信託最近 3 個會計年度歸屬於金融資

產之投資、再投資或交易之收入合計數達第 8條第 2款所

定門檻，該信託即屬投資實體，為申報金融機構，應依第

7

三章盡職審查程序辨識帳戶持有人之居住者身分，如帳戶

持有人為消極非金融機構實體，應再辨識對該實體具控制

權之人之居住者身分，審查有無應申報帳戶，依第四章規

定申報。但如受託人(全權委託保管機構)已依相關規定就

全權委託投資信託之帳戶持有人為盡職審查及申報該信託

下所有應申報帳戶資訊，該信託免再辦理盡職審查及申報。

3.全權委託保管機構如符合第 6 條存款機構或第 7 條保管機

構等金融機構要件為申報金融機構，應依第三章盡職審查

程序辨識全權委託信託財產專戶是否為應申報帳戶，如該

專戶持有人依第 25條第 2 項規定非屬應申報國居住者(如

該專戶持有人為金融機構)，該帳戶非應申報帳戶，免辦

理盡職審查，如該機構無應申報帳戶，於依第 51 條規定

申報時，應予註明。

十五、 與我國特定金錢信託相關之盡職審查及申報規定為何？

答：我國特定金錢信託以金錢交付予受託金融機構，由該機構依

投資人決定之投資標的、金額及時點進行投資，應先就實際

經營方式判斷是否符合第 8 條投資實體要件，致構成金融機

構。惟受託金融機構如未具投資決策權，該特定金錢信託未

符合投資實體由受託金融機構「管理」要件，非屬金融機構，

應由管理該特定金錢信託相關金融帳戶之金融機構(例如：

保管機構)，依第三章盡職審查程序辨識該帳戶持有人之居

住者身分，如帳戶持有人為消極非金融機構實體，應再辨識

對該實體具控制權之人之居住者身分，審查有無應申報帳戶，

依第四章規定申報。

投資人 受託金融機構 金融市場

保管機構

金錢交付

指示投資

受託投資

款項交付

投資

交割及保管

8

十五之一、第三方支付服務業、電子支付機構及電子票證發行機構

是否構成第 6條存款機構？(107年 8月 7日增訂)

答：依現行第三方支付服務業、電子支付機構及電子票證發行機

構定義及運作方式，未有其他收受存款行為，有別於以銀行

業或類似行業之通常營業方式收受存款，非屬第 6 條所定存

款機構。

(一)第三方支付服務業定義為從事配合金融機構及履約相關條

件，並與銀行合作，取得信用卡特約商店資格，提供電子

商務(含行動商務)買賣雙方支付擔保中介機制之行業，依

「消費者保護法」及「第三方支付服務定型化契約應記載

及不得記載事項」僅代理收付交易款項。

(二)電子支付機構定義為經營代理收付實質交易款項、收受儲

值款項(指接受使用者將款項預先存放於電子支付帳戶，以

供與電子支付機構以外之其他使用者進行資金使用移轉之

業務)及電子支付帳戶間款項移轉業務之公司。電子支付機

構收受每一使用者之儲值金額不得超過等值新臺幣 5 萬元。

(三)電子票證發行機構定義為經營發行用於支付特約機構提供

之商品、服務對價及政府部門各種款項等之電子票證及簽

訂特約機構之機構。電子票證之儲存金額不得超過新臺幣

1萬元。

十六、 金融機構擔任全球保管機構之次保管機構，應否辦理盡職審

查及申報？

答：金融機構擔任全球保管機構之次保管機構，如係為全球保管

機構於次保管機構所在國交易之證券提供保管服務，應依第

三章盡職審查程序辨識其管理之相關金融帳戶持有人之居住

者身分，如帳戶持有人為消極非金融機構實體，應再辨識對

該實體具控制權之人之居住者身分，審查有無應申報帳戶，

依第四章規定申報。

9

十七、 金融機構擔任合格境外機構投資人之保管機構，應否辦理盡

職審查及申報？

答：金融機構擔任合格境外機構投資人之保管機構，應依第三章

盡職審查程序辨識其管理之相關金融帳戶持有人之居住者身

分，如帳戶持有人為消極非金融機構實體，應再辨識對該實

體具控制權之人之居住者身分，審查有無應申報帳戶，依第

四章規定申報。

十八、 金融機構擔任投資型保險投資資產之保管機構，應否辦理盡

職審查及申報？

答：金融機構擔任投資型保險投資資產之保管機構，應依第三章

盡職審查程序辨識其管理之相關金融帳戶持有人之居住者身

分，如帳戶持有人為消極非金融機構實體，應再辨識對該實

體具控制權之人之居住者身分，如該帳戶持有人依第 25 條

第 2 項規定非屬應申報國居住者(如該帳戶持有人為金融機

構)，該帳戶非應申報帳戶，免辦理盡職審查，如該機構無

應申報帳戶，於依第 51條規定申報時，應予註明。

十九、 可能符合投資實體要件之實體為何(第 8條)？

答：如實體為集合投資工具、共同基金、指數股票型基金、私募

基金、避險基金、創投基金、融資收購基金或金融資產之投

資、再投資或交易基於投資策略成立之類似投資工具，通常

得視該實體為投資實體，惟仍應按具體事實認定。

二十、 信託如何認定是否屬金融機構？

答：信託如由具資產決策權之其他金融機構管理，最近 3 個會計

年度歸屬於金融資產之投資、再投資或交易之收入合計數達

第 8 條第 2 款所定門檻，且非屬第 3 條所定免辦理盡職審查

及申報者，即屬投資實體，為金融機構；反之，則屬非金融

機構實體。

10

二十一、 投資實體收入比例如何計算(第 8條)？

答：舉例說明，A 公司主要業務係從事證券投資信託基金之管理

運用、接受客戶全權委託投資及代理境外基金銷售，其最近

3個會計年度之收入明細如下：

收入類別 105年度 106年度 107年度

管理費收入 800,000元 900,000元 1,000,000元

銷售手續費收入 8,000元 9,000元 10,000元

其他營業收入 1,000元 2,000元 3,000元

合 計 809,000元 911,000元 1,013,000元

A 公司主要業務符合第 8 條所定為客戶或代客戶從事具約束

力之相關投資活動或操作，且最近 3 個會計年度歸屬該等活

動或操作之收入合計數，即管理費收入達收入總額 50%，A

公司認屬投資實體。

二十二、 發行保單之保險公司及其控股公司，何者屬申報金融機構

(第 9條)？

答：保險公司及其控股公司如發行具現金價值保險契約或年金保

險契約，或對前述保險契約承擔給付義務者，屬第 9 條特定

保險公司範疇，為申報金融機構。多數保險公司之控股公司

對於前述保險契約未承擔給付義務，非屬特定保險公司，即

非申報金融機構。

二十三、 黃金存摺是否屬金融資產(第 10條)？

答：本辦法所稱金融資產係指金融機構透過帳戶管理之資產。黃

金為實體商品，非屬第 10 條之金融資產；黃金存摺係金融

機構提供客戶以存摺方式登載其與客戶間黃金買賣及保管業

務，符合金融資產要件。

二十四、 擔保帳戶是否屬保管帳戶範疇(第 18條)？

答：擔保帳戶係為他人利益持有之帳戶或依約負有返還現金或資

產予他人義務者。交易一方向交易他方收取保證金或擔保品

(如有價證券)，且依約負有返還義務，相關擔保帳戶可能屬

第 18 條保管帳戶範疇，須依雙方契約約定及個案事實認定。

11

倘擔保品所有權可於契約期間移轉，形同擔保品持有人擁有

該擔保品完整所有權及受益所有權，非屬為他人利益持有金

融資產之帳戶，即非本辦法所稱保管帳戶。

二十五、 產物保險契約應否申報？

答：產物保險契約如未具現金價值，非屬第 16 條金融帳戶範疇，

申報金融機構免就該帳戶進行盡職審查及申報。

二十六、 儲蓄型保險契約應否申報？

答：實務所稱儲蓄型保險契約，泛指生存給付成分較高之人壽保

險，此類保險商品於契約約定期限屆滿後通常會提供保戶生

存保險金，且要保人提前解約可拿回部分已繳保險費，符合

具現金價值保險契約要件，屬金融帳戶，申報金融機構應依

第三章盡職審查程序辨識該契約之帳戶持有人之居住者身分，

如帳戶持有人為消極非金融機構實體，應再辨識對該實體具

控制權之人之居住者身分，審查有無應申報帳戶，依第四章

規定申報。

二十七、 我國既有帳戶與新帳戶之劃分時點與其他國家是否一致？

是否合宜(第 22條)？

答：既有帳戶及新帳戶之劃分時點係由實施 CRS 之國家或地區自

行擇定。考量各界反映實務執行資訊系統建置及人員訓練等

所需時程至少 1 年，且我國甫規劃建立 CRS 制度，爰將既有

帳戶及新帳戶劃分時點定為本辦法發布日之次一曆年度末日

(107 年 12 月 31 日)，以利金融機構有充裕時間完備實務作

業及資訊系統建置。

二十八、 既有客戶於 108 年 1 月 1 日後開立之帳戶屬新帳戶或

既有帳戶(第 22 條)？(107年 11月 26日修訂)

答：

(一)依第 22 條第 2 項規定，申報金融機構於 108 年 1 月 1

日後開立及管理由個人或實體持有之金融帳戶為新個人帳

戶或新實體帳戶。次依財政部 107 年 10 月 31 日台財際字

第 10700642570 號令規定，申報金融機構既有客戶於 108

12

年 1 月 1 日後在該機構開立帳戶，如同時符合下列規定，

該帳戶屬既有帳戶；反之，則屬新帳戶：

1.帳戶持有人於相同申報金融機構或其在我國境內屬申報金

融機構之關係實體，持有於 107年 12月 31日前開立之既

有帳戶(以下同)。

2.申報金融機構及其在我國境內屬申報金融機構之關係實體，

於執行盡職審查特別規定及計算帳戶餘額或價值時，將既

有帳戶及由該既有帳戶持有人持有之新帳戶，視為單一帳

戶。

3.申報金融機構開立及管理由既有帳戶持有人持有之新帳戶

執行防制洗錢及認識客戶程序時，得依其就該既有帳戶已

執行之前述程序結果認定。

4.申報金融機構開立及管理由既有帳戶持有人持有之新帳戶

在帳戶開立時，依本辦法以外之其他規定，毋須新增或補

充客戶資訊。

(二)申報金融機構自 108 年 1 月 1 日起執行盡職審查，得將前

述特定帳戶持有人開立之新帳戶歸類為既有帳戶，依既有

帳戶盡職審查程序辦理，或自行選擇依第 33 條第 1 項規定

輔以新帳戶盡職審查程序，保有執行彈性。

二十九、 本辦法第 23 條第 3 款第 2 目所稱任何人是否包含要保人

本人？

答：第 23 條第 3 款第 2 目所稱「除終止契約外，任何人不得透

過提領、質借或其他方式取得現金價值」，其中任何人包含

要保人本人。

三十、 本辦法第 23 條第 7 款第 1 目及第 2 目所稱聯繫之意涵為何？

答：第 23 條第 7 款一定金額以下且久未往來之帳戶規定，其中

「聯繫」一詞包含帳戶持有人以任何形式及方式就相關帳戶

與申報金融機構接洽，例如：帳戶持有人就帳戶餘額電詢

(如電話、傳真、電子郵件)申報金融機構，即屬聯繫行為。

13

三十一、 人壽保險身故保險金是否為被排除帳戶之遺產帳戶(第 23

條第 4款)？

答：依我國保險法第 112 條規定，保險金額約定於被保險人死亡

時給付於其所指定之受益人者，其金額不得作為被保險人之

遺產；同法第 113 條規定，死亡保險契約未指定受益人者，

其保險金額作為被保險人之遺產。人壽保險身故保險金是否

符合第 23 條第 4 款規定為被排除帳戶，須依保險契約約定

及個案事實認定。

三十二、 如客戶信用卡溢繳款超過 5 萬美元，為符合本辦法第 14

條免申報信用卡發卡機構要件規定，該機構於 60 日內應

退回客戶溢繳款超過 5萬美元部分或全數退回？ 答：依第 14 條規定，金融機構應訂定並執行避免客戶溢繳款超

過 5 萬美元之相關退款政策及程序，客戶溢繳款超過 5 萬美

元時應退還全部或部分，應按各該金融機構於前揭退款政策

所定方式退還，且執行退款程序後亦符合客戶溢繳款不超過

5萬美元規定。

三十三、 被排除帳戶有關退休金或養老金帳戶享有租稅優惠之規定

有何限制(第 23條第 1款)？ 答：退休金或養老金帳戶享有之租稅優惠以我國之租稅優惠為限，

如提撥至退休金或養老金帳戶金額，可自帳戶持有人之收入

總額扣除或不計入該總額、適用較低稅率、該等帳戶投資收

益遞延課稅或適用較低稅率等。

三十四、 金融機構應注意規避適用本辦法之情形有哪些？ 答：金融機構應注意個人或實體可能於每年年底將其他應申報帳

戶餘額暫時存放於免申報信用卡發卡機構，規避帳戶資訊申

報。CRS 反規避規定係視各國(地區)因應規避及執行 CRS 之

做法而定。考量各界認為第 23 條第 6款「客戶溢繳款超過 5

萬美元時於 60 日內完成退款」之排除規定可能導致客戶藉

由溢繳款規避高資產帳戶餘額之歸戶，爰於該款規定，金融

機構應以實質經濟事實關係依第 34 條第 2 項規定計算客戶

14

溢繳款。財政部將視金融機構執行情形，評估增列反規避規

定。

三十五、 國際金融業務分行(OBU)帳戶、國際保險業務分公司(OIU)

保單、國際證券業務分公司(OSU)帳戶是否須申報？

答：OBU 帳戶、OIU 保單或 OSU 帳戶如屬第 16 條規定之金融帳戶，

申報金融機構應盡職審查該等帳戶是否由外國居住者持有或

控制，經辨識該帳戶持有人或具控制權之人為居住者之國家

(地區)為我國租稅協定夥伴國並經財政部公告為應申報國，

該等帳戶即為應申報帳戶。

三十六、 如何查詢應申報國居住者認定原則？

答：經濟合作暨發展組織(OECD)網站發布多數承諾按 CRS 執行金

融帳戶資訊自動交換國家(地區)之稅務居住者身分認定要件

並持續更新，可自 OECD 網站 http://www.oecd.org 查詢(點

選 Topics/ Tax/ Exchange of information/ Automatic

exchange of information portal/ CRS Implementation

and Assistance/ tax residency rules)。

三十七、 如何認定經認可證券市場？經常性交易(第 25條)？

答：

(一)經認可證券市場，指經政府機關正式認可及監督之市場，

且該市場年度股票交易價值具相當規模；如該市場於前三

曆年度每年度股票交易價值均達 10 億美元，即屬具相當規

模市場。

(二)經常性交易，指股票於經認可證券市場持續進行交易且交

易量具相當規模；如該類別股票於前一曆年度 60 個營業日

以上於經認可證券市場進行交易，且於該曆年度於該市場

交易之該類別股票總數，占該類別股票平均已發行股數

10%以上者。

三十八、 積極非金融機構實體收入比例如何計算(第 28條)？

答：舉例說明如下：

15

(一)A 公司主要業務係從事製造、加工與銷售，非本辦法所稱

金融機構。其前一會計年度之收入明細如下：

收入類別 106年度

營業收入 1,000,000元

股利收入 90,000元

利息收入 5,000元

租金收入 100,000元

權利金收入 50,000元

外幣已實現兌換利益 25,000元

合計 1,270,000元

A 公司前一會計年度之股利、利息、租金、權利金及貨幣

匯兌增益收入等非積極營業活動產生收入之合計數

270,000 元未達收入總額 1,270,000 元之 50﹪，且該期間

內持有用於取得前揭非積極營業活動收入之資產，未達其

資產總額 50﹪，符合第 28 條第 1 項第 1 款要件， A 公司

屬積極非金融機構實體。

(二)B 公司主要業務係從事仲介服務，非本辦法所稱金融機構。

其前一會計年度之收入明細如下：

收入類別 106年度

佣金收入 500,000元

利息收入 200,000元

股利收入 400,000元

合計 1,100,000元

B 公司前一會計年度之利息及股利收入等非積極營業活動

產生收入之合計數 600,000 元，達收入總額 1,100,000 元

之 50﹪，未符合第 28條第 1項規定，B公司非屬該款所定

積極非金融機構實體。

16

三十九、 集團因正常避險需要與非關係實體從事避險交易，是否符

合積極非金融機構實體要件規定(第 28 條第 1 項第 7 款)？

答：第 28 條第 1 項第 7 款規定積極非金融機構實體情形，係指

主要活動為與其主要從事金融機構以外業務之關係實體或為

該關係實體從事融資或避險交易，且未對非關係實體提供融

資或避險服務者。集團因正常避險需要與非關係實體從事避

險交易者，未符合該款積極非金融機構實體要件規定。

四十、 公益信託及財團法人是否屬積極非金融機構實體(第 28 條第

1項第 8款)？

答：公益信託及財團法人如非屬本辦法所稱申報金融機構，其符

合第 28 條第 1 項第 8 款各目規定，即屬該款規範之積極非

金融機構實體。

四十一、 有權使用保險契約現金價值或變更受益人之人係指何人

(第 29條第 2項)？

答：第 21 條所稱現金價值，指要保人解除或終止契約時有權收

取之金額或得以契約借款之金額，兩者從高認定。依我國保

險法規定，保險契約解除或終止，除特定情事，要保人有權

收取保險人已收受之保險費、解約金或保單價值準備金；又

要保人得以保險契約為質向保險人借款，並有權變更受益人，

爰本辦法所稱有權使用現金價值或變更受益人之人於我國保

險實務通常指保險契約之要保人。

四十二、 應申報國稅籍編號之編碼資訊如何查詢？

答：OECD 網站發布多數承諾按 CRS 執行金融帳戶資訊自動交換

國家(地區)之稅籍編號(TIN)資訊並持續更新，可自 OECD 網

站 http://www.oecd.org 查詢(點選 Topics/ Tax/ Exchange

of information/ Automatic exchange of information

portal/ CRS Implementation and Assistance/ Tax

identification numbers (TINs))。

17

四十三、 我國居住者之稅籍編號為何？

答：我國稅務居住者識別碼編配原則分為個人及非個人(含法人、

機關、團體、機構或其他實體)：

(一)個人：

1.具身分證字號者為身分證字號(10 碼，由內政部戶政司編

配)。

2.具統一證號者為統一證號(10 碼，由內政部移民署編配)。

3.個人無身分證字號或統一證號者，以現行稅籍編號(大陸

地區人民為 9+西元出生年後 2 碼及出生月日 4 碼；其餘

情形為西元出生年月日 8碼+英文姓名前 2字母 2碼)方式

編配。

(二)非個人為統一編號(8 碼，由公司、商業登記主管機關或稅

籍登記所轄稅捐稽徵機關編配)。

四十四、 申報金融機構進行居住地址審查是否應取得本辦法規定之

全部證明文據(第 36條)？

答：第 32 條各款所列文件均屬證明文據，申報金融機構進行居

住地址審查僅須取得符合該條規定之任一證明文據，如政府

機關核發之居住者證明或載有個人姓名且作為辨識身分使用

之有效身分證明等。

叁、盡職審查

四十五、 申報金融機構審查既有帳戶之高資產帳戶，輔以新帳戶盡

職審查程序，如已依該程序取得自我證明文件，是否仍須

依高資產帳戶盡職審查程序相關規定辦理？申報金融機構

無既有帳戶持有人之稅籍編號或出生日期資訊，應如何辦

理申報(第 33條、第 38條及第 50條第 2項第 1款)？

答：

(一)申報金融機構審查既有帳戶之高資產帳戶，如已依新個人

帳戶審查程序取得自我證明文件，毋須再依本辦法所定高

資產帳戶盡職審查程序審查，惟如該申報金融機構由經理

18

客戶關係之人可得知自我證明文件不正確或不合理，應另

取得有效自我證明文件。

(二)申報金融機構如無既有帳戶持有人之稅籍編號或出生日期

資訊，且依我國法律無須蒐集該等資訊者，申報時即無須

申報稅籍編號或出生日期資訊，惟應依第 50 條第 2 項第 1

款規定，於確認該帳戶屬應申報帳戶次二曆年度之末日前，

合理致力取得該帳戶持有人之稅籍編號及出生日期資訊。

四十五之一、金融機構如規劃於 109 年 12 月 31 日前以高資產帳戶

審查程序完成較低資產帳戶盡職審查，則較低資產帳

戶於其後任一曆年度之末日成為高資產帳戶，可否免

再依高資產帳戶標準執行審查？(107 年 11 月 26 日增

訂)

答：第 33 條第 1 項後段規定，申報金融機構得依高資產帳戶盡

職審查程序審查較低資產帳戶。金融機構如規劃於 109 年 12

月 31 日前以高資產帳戶審查程序完成較低資產帳戶盡職審

查，則較低資產帳戶於其後任一曆年度之末日成為高資產帳

戶，得免再依高資產帳戶標準執行審查。惟後續申報金融機

構應依第 38 條規定執行相關程序，確保經理客戶關係之人

辨識帳戶狀態變動。

四十六、 申報金融機構於計算非以美元計價之帳戶門檻數額時，應

採用之換算匯率為何？何謂主要往來指定銀行(第 34 條第

2項)？(107年 8月 7日修訂)

答：第 34 條第 2 項規定，申報金融機構應採用「主要往來指定

銀行」牌告外匯收盤匯率換算；所稱「主要往來指定銀行」，

指申報金融機構主要往來之中央銀行指定辦理外匯業務銀行。

上述規定係參考「票券金融公司辦理外幣債券經紀自營及投

資管理辦法」第 8 條第 3 項訂定，按其實務作法，申報金融

機構得自行選擇經中央銀行許可辦理外匯業務銀行之匯率換

算。

19

四十七、 依法不得銷售與應申報國居住者之具現金價值保險契約或

年金保險契約，「依法」所指為何(第 35條)？

答：第 35 條所稱依法不得銷售具現金價值保險契約或年金保險

契約與應申報國居住者，係指申報金融機構為居住者之國家

(地區)法令禁止銷售該等契約與另一國家(地區)居住者，或

應申報國(地區)法令禁止申報金融機構銷售該等契約與該應

申報國(地區)居住者。

四十八、 金控集團之銀行、保險公司或同一金融機構得否沿用同一

客戶提供之自我證明文件？(107年 11月 26日修訂)

答：

(一)申報金融機構於新帳戶開立時，應依本辦法規定取得自我

證明文件，其目的係為辨識開戶時，帳戶持有人之居住者

身分；嗣後如有帳戶狀態變動失其正確性及合理性等情形，

應依規定另取得有效自我證明文件。依此，申報金融機構

執行盡職審查程序，擬將客戶於其或同一金控集團之其他

子公司開立之帳戶及其他帳戶視為單一帳戶，審查自我證

明文件或證明文據之正確性或合理性，於符合個人資料保

護相關規定下，得沿用客戶提供之自我證明文件。惟提醒

申報金融機構對每一帳戶均負有盡職審查義務，應確保已

依本辦法規定辨識每一帳戶持有人之居住者身分，如申報

金融機構可得知自我證明文件不正確或不合理，應另取得

有效自我證明文件。

(二)舉例說明，如客戶 108 年 1 月 1 日於銀行開立存款帳戶，

另於 108 年 2 月 1 日於該銀行開立保管帳戶，經審查客戶

前開立存款帳戶提供之自我證明文件無不正確或不合理情

形，於符合個人資料保護相關規定下，得採用該前次提供

之自我證明文件辨識其居住者身分，惟如與該銀行就前述

保管帳戶取得之其他資訊不符，銀行應另取得有效自我證

明文件並對前述存款帳戶重為盡職審查。

20

四十九、 何謂經理客戶關係之人(第 38條)？

答：由申報金融機構指派之人，持續對帳戶持有人提供有關銀行

業務、投資、信託及遺產規劃等諮詢，並建議、轉介或安排

提供金融商品、服務或其他內部或外部協助，以滿足客戶需

求，不以申報金融機構設有該職位為限。

五十、 對於客戶不提供身分證明文件者，金融機構應如何辦理？

答：

(一)新帳戶部分，金融機構防制洗錢辦法規定，客戶開立新帳

戶應配合提供審核客戶身分措施相關文件，如客戶拒絕提

供審核客戶身分措施相關文件，金融機構應予以婉拒建立

業務關係或交易。

(二)既有帳戶部分，金融機構就保存之證明文據或電子紀錄，

或依法律規定或為管理客戶關係目的保存之資訊，審查帳

戶持有人居住之國家(地區)，自我證明文件或證明文據係

作為佐證金融機構審查結果與事實不符之文據；金融機構

如未能就其保存之紀錄或資訊查得帳戶持有人為居住者之

國家(地區)，且無法取得自我證明文件及證明文據，應申

報該帳戶為無資訊帳戶。

五十一、 自我證明文件之使用效期？

答：自我證明文件原則持續有效。但帳戶持有人狀態變動，申報

金融機構明知或可得而知原自我證明文件不正確或不合理時，

不得採用。

五十二、 金融機構得否自訂自我證明文件版本？

答：

(一)金融機構得自訂自我證明文件版本，其應填報資訊內容實

質意涵須與財政部發布範本一致。

(二)財政部發布之自我證明表範本，可至該部網站下載(點選服

務園地/國際財政服務資訊/稅務用途資訊交換(含金融帳戶

資訊)/稅務用途金融帳戶資訊自動交換/書表格式)。

21

五十二之一、自 108 年 1 月 1 日起，是否全部新開立之外國帳戶均

應取得及留存帳戶持有人之自我證明文件？(107 年

11月 26日增訂)

答：

(一)依據本辦法規定，金融機構應盡職審查其管理之所有外國

帳戶，辨識應申報帳戶後，定期向稅捐稽徵機關申報相關

帳戶資訊。以新帳戶之開立為例，金融機構受理開戶作業

時，應先區分本國帳戶(僅具本國居住者身分者持有之帳戶)

及外國帳戶，本國帳戶部分，嗣後如狀態變動而具外國居

住者身分，金融機構應依法辦理盡職審查及申報；外國帳

戶部分，自 108 年 1 月 1 日起開立之新帳戶，除符合特定

條件之新帳戶另有規定外(詳第二十八題)，依法應取得及

留存帳戶持有人之自我證明文件。

(二)為協助金融機構提升盡職審查之正確性及有效性，以利金

融機構向稅捐稽徵機關申報帳戶資訊，財政部發布自我證

明文件範本，範本內容係參考 OECD 相關文件所擬，與國際

實務作法一致，涵蓋帳戶持有人與具控制權人稅務居住者

身分辨識、實體類型、稅籍編號、聲明及簽署等資訊，供

金融機構參考運用。

(三)實務上，金融機構依其業務屬性，規劃盡職審查及申報之

內部控制程序。有關判斷本國帳戶與外國帳戶之作業程序，

金融機構或以開戶人出具自我證明文件認定；或於開戶文

件結合自我證明文件內容供開戶人填寫；或以開戶文件輔

以具法律效力之承諾聲明及必要之證明文據認定；或有其

他可善盡盡職審查及申報義務之方式。

(四)金融機構經取得與帳戶相關之其他資訊，可得知帳戶持有

人具外國居住者身分，應另取得有效自我證明文件並對相

關帳戶重為盡職審查。

五十三、 取得自我證明文件之時限為何？

答：申報金融機構應於新帳戶開立時，即時取得有效之自我證明

文件，俾完成盡職審查及申報義務。惟少數申報金融機構因

22

營業部門獨特性，未能於帳戶開立當日取得有效之自我證明

文件，申報金融機構應儘快於 90 日內取得及審查；另鑑於

取得新帳戶持有人自我證明文件對確保 CRS 有效實施至關重

要，申報金融機構應具強力措施確保取得。

五十四、 取得自我證明文件之形式及方式為何？

答：

(一)自我證明文件得以任何形式及方式提供，該文件須包含所

有必要資訊且由金融機構客戶簽名或確認(如提供該文件者

確認其同意文件所載內容)。如金融機構以非書面方式蒐集

自我證明文件必要資訊，取得方式應與開戶程序一致，並

保存相關紀錄。

(二)自我證明文件如以電子形式提供，須確保電子系統接收之

資訊與使用者傳送之資訊相同，且紀錄使用者傳輸、更新

或修正自我證明文件所有情形，並確保系統使用者與提供

自我證明文件者為該文件所載之人，且要求提供該文件時，

能夠提供影本資料。

五十五、 何謂自我證明文件或證明文據不正確或不合理(第 47 條)？

答：申報金融機構就所知之相關事實、自我證明文件所載聲明或

其他文據、相關經理客戶關係之人知悉，足以對帳戶持有人

聲明提出質疑，屬第 47 條所稱申報金融機構明知或可得而

知自我證明文件或證明文據不正確或不合理之情形。申報金

融機構留存帳戶之資訊，如與帳戶持有人聲明之身分不一致，

亦屬之。

五十六、 申報金融機構得否合併計算客戶於該機構及其關係實體所

有金融帳戶之總餘額或價值？

答：於符合個人資料保護相關規定下，申報金融機構電腦系統得

具連結客戶帳戶資訊之識別碼及加總餘額或價值功能；倘申

報金融機構電腦系統具前揭功能，依本辦法第 49 條第 1 項，

應合併計算客戶於該機構及其關係實體持有金融帳戶之總餘

額或價值。

23

肆、申報

五十七、 金融帳戶餘額或價值如為負數，應如何申報(第 50 條第 1

項)？

答：金融帳戶餘額或價值如為負數，申報金融機構應將該帳戶之

餘額或價值申報為零。

五十八、 如何認定帳戶終止(第 50條第 1項)？

答：依適用之我國法令規定認定帳戶是否終止；如我國法令未有

相關規範，依申報金融機構帳戶管理之一般作業程序認定帳

戶是否終止。

五十九、 終止帳戶應如何申報(第 50條第 1項)？

答：申報金融機構應申報該帳戶已終止及餘額或價值為零，並就

該帳戶類型依第 50 條第 1 項第 5 款至第 7 款規定申報相關

資訊。

五十九之一、申報金融機構於 108 年 12 月 31 日前完成部分較低資

產帳戶審查，是否應於次年 6 月申報該帳戶相關資訊？

(107年 11月 26日增訂)

答：依第 51 條規定，申報金融機構應於每年 6 月 1 日至 6 月 30

日向稅捐稽徵機關申報上一曆年度應申報帳戶資訊。又第 39

條及第 41 條規定，申報金融機構完成高資產帳戶審查之最

後期限為 108 年 12 月 31 日、完成較低資產帳戶及實體帳戶

審查之最後期限為 109 年 12 月 31 日，復依第 50 條第 1 項

及第 51 條規定，申報金融機構依本辦法盡職審查程序認定

為應申報帳戶者，應於次年 6 月申報該帳戶相關資訊，即申

報金融機構於 108 年間盡職審查認定為應申報帳戶(包括新

帳戶及全部高資產帳戶，亦可能包括部分較低資產帳戶)，

應於 109年 6月向稅捐稽徵機關申報該帳戶相關資訊。

六十、 第 50 條第 1 項第 7 款所稱申報金融機構為義務人或債務人

支付或計入帳戶持有人之金額包括哪些？

答：申報金融機構為存款帳戶及保管帳戶以外帳戶之義務人或債

務人，支付或計入該帳戶持有人之金額，包括支付帳戶持有

24

人之全部或部分贖回金額，及依具現金價值保險契約或年金

保險契約，支付帳戶持有人之金額(未限於第 21 條所定現金

價值部分)等。

六十一、 何謂合理致力(第 50條第 2項第 1款)？

答：申報金融機構於辨識既有帳戶為應申報帳戶及次二曆年度之

末日期間，確實嘗試取得應申報帳戶持有人之稅籍編號及出

生日期資訊。如每年至少 1 次透過郵件、親自、電話、傳真

或電子郵件聯繫帳戶持有人。倘申報金融機構依第 49 條規

定應與其關係實體合併計算客戶持有之金融帳戶總餘額或價

值，就其關係實體持有資訊進行電子紀錄搜尋等，即符合合

理致力。

六十二、 申報資訊如為不同幣別時，應如何申報(第 50 條第 1 項)？

答：申報資訊如為不同幣別，申報金融機構應擇定單一計價幣別，

並依第 50條第 1項第 8款規定於申報時載明該計價幣別。

六十三、 代金融機構進行盡職審查及申報作業之服務提供者是否有

資格或條件限制？是否應簽立契約(第 52條)？

答：第 52 條明定申報金融機構對於本辦法規定之盡職審查及申

報義務，得授權他人代理。該他人未有資格或條件限制，未

以訂有服務合約之服務提供者為限，且相關申報及審查責任

仍歸屬申報金融機構。

六十四、 金融機構授權他人代為收取相關文件，不論係以書面或電

子形式，是否亦適用本辦法規定(第 52條)？

答：金融機構授權他人代為收取相關文件，不論係以書面形式或

電子形式，亦適用第 52 條規定，惟相關申報及審查責任仍

歸屬金融機構。