Kommunikationshandbuch FATCA. Teil 3 - Datenübermittlung über die Massendatenschnittstelle ELMA für Massendatenmelder nach XML-Schema 2.

Transkript

1 Kommunikationshandbuch FATCA für Massendatenmelder nach XML-Schema 2.0 Version: 2.5 Stand:

2 Informationen zum vorliegenden Dokument Verfahrensbezeichnung Dokumententitel Verantwortlicher Autor FATCA Massendatenschnittstelle ELMA für Massendatenmelder nach XML-Schema 2.0 Bundeszentralamt für Steuern - Bereich FATCA Erstellt am Zuletzt geändert am Dokumentablage Internetauftritt des Bundeszentralamtes für Steuern - Steuern International - FATCA - Kommunikationshandbuch Änderungshistorie Dokument Version XML Schema Version Datum Änderung Initiale Erstellung Diverse Diverse Diverse Diverse Vollständige Überarbeitung - Aktualisierung auf XML Schema siehe Anlage zum Infobrief 04/ siehe Anlage zum Infobrief 06/ Aktualisierung Seite 2 von 47

3 Dokument Version XML Schema Version Datum Änderung Insbesondere: Redaktionelle Anpassungen wichtige Neuerungen zur Beistellung der TIN bezüglich der Notice des IRS Anpassungen im Aufbau der DocRefID meldezeitraumabhängige Besonderheiten bei der Datenübermittlung Anpassungen aufgrund Änderungen am ELAN-Umfeld (ELMA-Header und ELMA-Rückmeldungen) Umstellung des Signaturverfahrens auf RSASSA-PSS zum und des Hashverfahrens auf SHA-256 (Anpassungen im Abschnitt Erstellung Signaturdateien) Seite 3 von 47

4 Inhaltsverzeichnis Informationen zum vorliegenden Dokument... 2 Änderungshistorie... 2 Inhaltsverzeichnis... 4 Abbildungsverzeichnis... 5 Tabellenverzeichnis Allgemeines Copyright Zweck des Dokuments Rechtliche Grundlagen Vereinfachte Darstellung des Verfahrens Was ist NEU? Schemaumstellung auf XML Grundlagen zum Aufbau des Datensatzes (XML) Abgrenzung zum XML-Upload über BOP Anforderungen zum Datensatz Steuernummer/US-TIN Aufbau der DocRefID MessageRefID GIIN PoolReport (nicht zu verwenden) Dateigrößenbeschränkung Verwendung optionaler Datenelemente Längenbeschränkung Zeichensatz und -beschränkung Unzulässige Zeichen und Zeichenkombinationen Verwendung UTF Anzahl ReportingFI und ReportingGroups innerhalb einer Lieferung FilerCategory zum Reporting FI oder Sponsor NilReport AccountClosed Meldearten, Datenübermittlung und Korrekturen Seite 4 von 47

5 6.1. Zeitpunkt der Übermittlung Korrekturen Versand von Massendaten über die Grundlagen von ELMA/XSD (NEU) FATCA_ELMA_XSD - Lieferdatei Zeichenbeschränkung für die Aufbau ELMAHeader Namenskonventionen Namenskonventionen Datendatei Namenskonvention Signaturdateien Erstellung Signaturdateien Aufbau der Verbindung Übertragung einer XML- und Signaturdatei an ELMA Rückmeldungen zur Datenlieferung Vorabprüfung im BZSt: ELMA-Prüfungen (NEU) FATCA_ELMA_XSD - Antwortdatei Liste der möglichen ELMA Status-Meldungen (Fehlermeldungen) Abfolge der ELMA-Dateiprüfung ELMA-Prüfungen - -Rückmeldung Fachliche Prüfungen im BZSt: FATCA-Backend Prüfungen in den USA - Notification/US-EmpfangsbestätigungAnFI (NEU) Abholung Rückmeldedatei(en) Namenskonvention für die Rückmeldedatei Beispieldateien für Datenlieferungen Referenzdokumente/Verweise Abkürzungsverzeichnis/Glossar Abbildungsverzeichnis Abbildung 1: Wurzelknoten ELMAFC Abbildung 2: Aufbau ELMAHeader Abbildung 3: ELMA5-Zertifkikat für den Verbindungsaufbau und die Signaturdatei generieren.. 27 Abbildung 4: Aufbau des standardisierten ELMAProtokolls Abbildung 5: Eingangsbestätigung über die Weiterleitung der Daten an das FATCA-System (Backend) Seite 5 von 47

6 Tabellenverzeichnis Tabelle 1: Was ist NEU... 9 Tabelle 2: Unzulässige Zeichen Tabelle 3: Unzulässige Zeichenkombinationen Tabelle 4: Beispiele für Zeichenkombinationen mit Apostroph und SQL-Befehlen Tabelle 5: Meldearten Tabelle 6: Systematik bei der Verwendung von CorrMessageRefID und CorrDocRefID Tabelle 7: Befüllung des ELMAHeaders Tabelle 8: Aufbau es Dateinamens einer Datendatei Tabelle 9: Inhalte ELMAProtokoll Tabelle 10: ELMA Status-Meldung fehlerfreie Verarbeitung in ELMA Tabelle 11: Liste der möglichen ELMA Status-Meldungen (Fehlermeldungen) Tabelle 12: Abfolge der ELMA-Prüfungen und deren Fehlercodes Tabelle 13: Weitere Gründe für eine Nicht-Verarbeitung/-Abholung Tabelle 14: Beispieldateien für Datenlieferungen Tabelle 15: Übersicht der Referenzdokumente/Verweise Seite 6 von 47

7 1. Allgemeines Das (KHB FATCA) ist die führende Referenz für die Kommunikation im Verfahren FATCA. Es enthält nähere Informationen zur Datenübermittlung nach dem FATCA-Abkommen und beschreibt und konkretisiert die fachlichen Vorgaben des amtlich vorgeschriebenen Datensatzes. Das KHB FATCA besteht aus folgenden Teilen: Teil 1 - Registrierung Teil 2 - Datenübermittlung über das BZStOnline-Portal Alle weiteren Dokumentationen sind nur als ergänzende Information zu betrachten. Bei eventuellen Widersprüchen gilt das vorliegende Dokument Copyright Die vorliegende technische Dokumentation dient der Information der am FATCA-Verfahren beteiligten Gruppen. Weitergehende Veröffentlichungen, Nachdruck, Vervielfältigungen oder die Speicherung - gleich in welcher Form, ganz oder teilweise - sind nur mit vorheriger schriftlicher Zustimmung des BZSt zulässig Zweck des Dokuments Im vorliegenden Teil 3 wird das Verfahren zur Datenübermittlung von Massendaten über die (Kommunikationsverfahren) im BZSt beschrieben. Es wird darauf hingewiesen, dass das vorliegende Dokument keine amtliche Datensatzbeschreibung nach 117c Abgabenordnung (AO) (vgl. Abschnitt 11) und 8 Abs. 3 FATCA-USA-UmsV darstellt, diese allerdings durch weitere Erläuterungen oder auch Vorgaben konkretisiert bzw. ergänzt Rechtliche Grundlagen Am 31. Mai 2013 wurde das Abkommen zwischen der Bundesrepublik Deutschland und den Vereinigten Staaten von Amerika zur Förderung der Steuerehrlichkeit bei internationalen Sachverhalten und hinsichtlich der als Gesetz über die Steuerehrlichkeit bezüglich Auslandskonten bekannten US-amerikanischen Informations- und Meldebestimmungen (FATCA- Abkommen) unterzeichnet. Das Zustimmungsgesetz zum Abkommen ist am 16. Oktober 2013 in Kraft getreten (BGBl. II S. 1363). Das FATCA-Abkommen wurde damit am 11. Dezember 2013 wirksam. Seite 7 von 47

8 Mit Ermächtigung des 117c Abgabenordnung (AO) wurde die FATCA-USA-Umsetzungsverordnung (FATCA-USA-UmsV) erlassen (BGBl. I 2014 S. 1222). Die Verordnung, datiert auf den 28. Mai 2014, wurde zuletzt am 20. Dezember 2016 (BGBl. I 2016 S. 3000) geändert. Am 1. Februar 2017 (BStBl. I 2017, 305) hat das BMF ein neues Schreiben betreffend Anwendungsfragen im Zusammenhang mit dem gemeinsamen Meldestandard (CRS) sowie dem FATCA-Abkommen veröffentlicht, siehe BMF-Anwendungsschreiben im Abschnitt 11. Das neue Schreiben ersetzt vollumfänglich das FATCA-Anwendungsschreiben aus November 2015 (BStBl I 2015 Seite 897). Alle FATCA-Meldungen haben auf elektronischem Wege und unter Beachtung des amtlichen Datensatzes nach 117c Abgabenordnung (AO) an das BZSt zu erfolgen. Der aktuelle, auf der Internetseite des BZSt unter der Rubrik Vorschriften (vgl. amtliche Datensatzbeschreibung im Abschnitt 11) veröffentlichte FATCA-XML-Datensatz entspricht dem amtlichen Datensatz, der für alle FATCA-Meldungen an das BZSt Gültigkeit hat Vereinfachte Darstellung des Verfahrens Die meldenden deutschen Finanzinstitute (FI) sind verpflichtet, sich entsprechend des FATCA- Abkommens und der FATCA-USA-Umsetzungsverordnung bei der Bundessteuerbehörde der Vereinigten Staaten von Amerika (IRS) registrieren zu lassen und eine Internationale Identifikationsnummer für Intermediäre (Global Intermediary Identification Number (GIIN)) zu beantragen. Für eine Übermittlung von Daten an das BZSt ist zunächst eine Anmeldung und ein gültiges Zertifikat für das BZStOnline-Portal (BOP) für die meldende Stelle erforderlich. Weitere Erläuterungen dazu können im Teil 1 (vgl. Abschnitt 11) nachgelesen werden. Für die Datenübermittlung nach dem FATCA-Abkommen an das BZSt stehen zwei Übermittlungsarten zur Verfügung: Die manuelle Übermittlung von Daten im BZStOnline-Portal via Formular Die Datenübermittlung für Einzeldatenmelder über das FATCA-Formular im BZStOnline- Portal ist im Teil 2 (vgl. Abschnitt 11) beschrieben. Die Übermittlung von XML-Massendaten Erläuterungen zum Registrierungs- und Freischaltungsprozess, als Voraussetzung zur Übermittlung einer Datenlieferung über die, sind im Teil 1 (vgl. Abschnitt 11) zu finden. Im vorliegenden Dokument wird die Übermittlung von XML-Massendaten über die beschrieben. Seite 8 von 47

9 Mit dem Eingang eines Datensatzes beim BZSt erhält der Sender eine Rückmeldung über das Ergebnis der Verarbeitung bei FATCA, das sogenannte Verarbeitungsprotokoll FATCA. Wird eine FATCA-Datenlieferung eines Finanzinstituts an die zuständige US-amerikanische Bundessteuerbehörde (IRS) weitergeleitet, wird das BZSt vom IRS innerhalb einer bestimmten Frist über das Ergebnis der Verarbeitung der Datenlieferung in Form einer sog. Notification unterrichtet. Diese wird - in einer durch das BZSt aufbereiteten Form auch unmittelbar an den Sender der ursprünglichen Datenlieferung als sog. US-EmpfangsbestätigungAnFI weitergereicht. Zu den Verarbeitungsprotokollen und US-EmpfangsbestätigungenAnFI (Notifications) wurden separate Dokumente erstellt, die auf der Internetseite des BZSt abgerufen werden können, vgl. Abschnitt Was ist NEU? In diesem Kapitel werden kurz die wichtigsten Änderungen bezüglich der Datenübermittlung zum FATCA-Abkommen behandelt. Das Schema und die Geschäftsregeln werden in der vorliegenden Veröffentlichung ausführlich erläutert. Alle Neuerungen/Änderungen treten am in Kraft und gelten für jegliche Datenübertragungen an das BZSt und Datenempfänge vom BZSt: Grundlagen von ELMA / XSD Abschnitt 7 Änderungen beim Aufbau des ELMA-Headers, der bei der Datenübertragung einer XML- Datei an das BZSt gefüllt werden muss. Rückmeldungen ELMA Abschnitt 9.1 Änderungen am Aufbau der ELMA- Rückmeldungen, die nach dem Versand einer XML-Datei an das BZSt/an das sendende Finanzinstitut zurückgegeben werden Prüfungen in den USA Notification/ US-EmpfangsbestätigungAnFI Tabelle 1: Was ist NEU Abschnitt 9.3 Die USA haben Schemaänderungen zu den Rückmeldungen aus USA (Notifications) vorgenommen. Da die Notifications durch das BZSt aufbereitet und an die Finanzinstitute in Form einer US-EmpfangsbestätigungAnFI (UEFI) weitergegeben werden, musste das Schema zu den UEFIs und die sich daraus ergebenden Korrekturvorschriften ebenso angepasst werden. Seite 9 von 47

10 3. Schemaumstellung auf XML 2.0 Die US-amerikanische Bundessteuerbehörde (IRS) hat am 1. September 2016 auf seiner Internetseite ( die finale Version seines neuen FATCA-XML-Schemas Version 2.0 veröffentlicht. Das Schema 2.0 ersetzt das Schema 1.1 vollständig. Das alte Schema Version 1.1 wird nicht mehr unterstützt. Die Umstellung des Schemas gilt zeitraumunabhängig für alle Meldezeiträume und Meldearten (Erstmeldungen, Korrekturmeldungen und Löschmeldungen). Für die Inhalte des neuen Schemas und die fachlichen Vorgaben wird im Übrigen auf die amtliche Datensatzbeschreibung (vgl. Abschnitt 11) verwiesen. 4. Grundlagen zum Aufbau des Datensatzes (XML) Die FATCA-Daten werden mit Hilfe eines ELMA-Headers an die übertragen. Dabei werden die Metadaten des ELMA5-Verfahrens wie ein Umschlag um die eigentlichen FATCA-Dateninhalte herumgelegt. Der Aufbau der XML-Struktur beginnt jeweils mit dem Wurzel-Element ELMAFC. Dieses Element ist der Wurzelknoten für die gesamte zu übertragene Datei und stellt den Einstieg in die Baumstruktur dar. Danach folgt der ELMAKOM-Abschnitt. Dieser beinhaltet die Teile ELMAHeader und ELMAVerfahren. ELMAHeader und ELMAVerfahren sind Bestandteil einer jeden ELMA- Lieferung und nicht verfahrensspezifisch. Der ELMAHeader enthält alle Informationen des Senders für die Fachverfahrens- und Sender-Zuordnung. Unter ELMAVerfahren ist das fachverfahrensspezifische XML einzubetten. Der verpflichtende Aufbau der verfahrensspezifischen FATCA-Inhalte ergibt sich aus der amtlichen Datensatzbeschreibung (vgl. Abschnitt 11). Die XML Schema Definitionen zu der an das BZSt zu übertragenden XML-Datei sind unter FATCA 2.0 XSD im Abschnitt 11 zu finden. Für den vollständigen Aufbau einer an die zu übertragenden Lieferung wird auf die weitergehenden Erläuterungen im Abschnitt 7.1 verwiesen. Die eigentlichen FATCA-Daten entsprechen weitestgehend den Vorgaben des von der US- Amerikanischen Bundessteuerverwaltung (IRS) entwickelten FATCA XML Schemas. Hierzu existiert ein vom IRS veröffentlichter User Guide (vgl. User Guide FATCA im Abschnitt 11). Für diesen liegt eine nichtamtliche Übersetzung in die deutsche Sprache vor, die als weitere Hilfestellung zum technischen und allgemeinen Verständnis des Schemas herangezogen werden kann, vgl. Nichtamtliche deutsche Übersetzung des FATCA XML Schema v2.0 User Guide im Abschnitt 11. Seite 10 von 47

11 4.1. Abgrenzung zum XML-Upload über BOP FATCA ermöglicht es eine XML-Datendatei über einen Upload-Client im BZStOnline-Portal an das BZSt zu übertragen. Der Aufbau der XML-Datendatei folgt denselben Regeln wie bei der Übertragung an die. Daher sind bzgl. des Aufbaus der XML-Datei insbesondere die Kapitel 5; 6 und 7 zu beachten. Die Rückmeldung zu einer über das BZSTOnline-Portal übertragenen Datei ist nicht im BOP- Postfach abrufbar. Da der Upload die Übertragung über ELMA darstellt, sind die Rückmeldungen nur im zugehörigen Download-Verzeichnis, nicht aber am gleichen Ort im BOP, wo die Datei hochgeladen wurde, abrufbar. Um ohne direkte SFTP-Verbindung diese Rückmeldungen abzuholen, besteht aus dem BOP heraus die Möglichkeit, den Inhalt des Download-Verzeichnisses abzurufen. Der Weg dorthin führt über folgende Navigation im BOP: BOP Formulare & Leistungen / Alle Formulare / weitere Formulare / Dienste / Abholung von ELMA5-Protokollen. Die Inhalte der Rückmeldungen sind dann jedoch wieder identisch mit einer per SFTP über das ELMA-Upload-Verzeichnis übertragenen Datei (vgl. Abschnitt 9). Eine kurze Benutzeranleitung finden Sie im BOP unter "Formulare & Leistungen / Versand von Massendaten (ELMA5) nach Auswahl des betreffenden Fachverfahrens. Bitte beachten Sie, dass für den Upload von XML-Dateien ebenfalls eine Freischaltung für die sowie die Einbindung des Zertifikats im Browser erforderlich ist. 5. Anforderungen zum Datensatz 5.1. Steuernummer/US-TIN Die Angaben zur Steuernummer/US-TIN (US-amerikanische Steueridentifikationsnummer) zum verwaltenden Rechtsträger (Sponsor), Vermittler (Intermediary) und der beherrschenden Person (SubstantialOwner) sind optional, müssen aber bei Füllung den Formaten XXXXXX.XXXXX.XX.XXX, XXX-XX-XXXX, XX-XXXXXXX oder XXXXXXXXX entsprechen. Der ausstellende Staat muss nicht angegeben werden. Sollte allerdings eine Angabe in diesem Feld erfolgen, wird die Eintragung US (Vereinigte Staaten von Amerika) erwartet. Die Angaben zur Steuernummer/TIN (US-amerikanische Steueridentifikationsnummer) zum Kontoinhaber/zur beherrschenden Person sind für Meldezeiträume ab 2017 gemäß der FATCA- USA-Umsetzungsverordnung (FATCA-USA-UmsV) verpflichtend (vgl. 8 Abs. 5 FATCA-USA- UmsV). Seite 11 von 47

12 Die Steuernummer/TIN muss bei Füllung den Formaten XXXXXX.XXXXX.XX.XXX, XXX-XX-XXXX, XX- XXXXXXX oder XXXXXXXXX entsprechen. Der ausstellende Staat muss nicht gefüllt werden. Ist allerdings eine Angabe in diesem Feld erfolgt, wird die Eintragung US (Vereinigte Staaten von Amerika) erwartet. Die rechtzeitige Beschaffung der US-TIN stellt für Melder bisweilen eine große Herausforderung dar. Daher hat die US-amerikanische Bundessteuerbehörde (IRS) am 25. September 2017 für FATCA geänderte Leitlinien betreffend die Ermittlung und Meldung von Steueridentifikationsnummern und Geburtsdaten durch Finanzinstitute veröffentlicht (vgl. Notice , Abschnitt 11). Danach führt die bloße Nichtbeistellung einer US-TIN für die Meldezeiträume 2017, 2018 und 2019 nicht zu einer sog. Erheblichen Nichteinhaltung im Sinne des Art. 5 Abs. 2 FATCA-Abkommen (significant non-compliance), wenn durch das betroffene Finanzinstitut (zuvor) die nachfolgenden Maßnahmen (vgl. Notice , Abschnitt 11) ergriffen werden/beachtet wurden. Diese nachfolgenden Regelungen gelten mit Ausnahme der Angabe des Geburtsdatums sowohl für natürliche Personen (Individuals) als auch für Organisationen (Organisations) als Kontoinhaber bzw. als beherrschende Personen. 1. Das Finanzinstitut beschafft und meldet im Falle einer natürlichen Person (stattdessen) das Geburtsdatum jedes Kontoinhabers und jeder beherrschenden Person, deren US- TIN nicht gemeldet werden kann, 2. das Finanzinstitut fordert von jedem Kontoinhaber jährlich die fehlende US-TIN an und 3. das Finanzinstitut durchsucht - vor der Übermittlung der FATCA-Meldungen für den Meldezeitraum seine elektronisch durchsuchbaren Daten auf Hinweise zu fehlenden US-TINs. Ist für einen Kontoinhaber auch unter Beachtung der in den geänderten Leitlinien genannten Maßnahmen eine Meldung der US-TIN nicht möglich, ist diese mit AAAAAAAAA (9 x Großbuchstabe A ) zu melden. Wir weisen Sie jedoch ausdrücklich darauf hin, dass die Regelungen der FATCA-USA-UmsV betreffend die Pflicht zur Beistellung einer US-TIN durch die Veröffentlichung der geänderten Leitlinien des IRS unberührt bleiben. Auch die Leitlinien des IRS entbinden nicht von der bestehenden Melde- und Sorgfaltspflicht, die US-TIN bereitzustellen. Da nicht angedacht ist, die in der Notice beschriebene Übergangslösung zu verlängern, bzw. von der Meldepflicht der US-TIN dauerhaft abzusehen, ist es insgesamt weiterhin zwingend notwendig die US-TIN zu beschaffen Aufbau der DocRefID Ab Ende März 2018 sind bei der Angabe einer DocRefID (ausgenommen {-} und {.}) keine Sonderzeichen, wie {_}, {+}, {@}, {&}, {!} und {*}, mehr zulässig und würden zu einer Abweisung des Reports oder gegebenenfalls der gesamten Lieferung führen. Seite 12 von 47

13 Die Änderungen betreffen den Aufbau für das Element DocRefID aller Lieferungen für sämtliche Meldezeiträume, die ab diesem Zeitpunkt beim BZSt eingegangen sind/eingehen. Die DocRefID muss aus mindestens 21 Zeichen (und höchstens 200 Zeichen) bestehen und folgenden Aufbau aufweisen: 1) 19-stellige GIIN des Elements ReportingFI im Format XXXXXX.XXXXX.YY.ZZZ (X = {A-Z}, {0-9} (ohne Großbuchstabe O); Y = {A-Z}; Z = {0-9} (ISO-Ländercode)) 2) Punkt als Trennzeichen (.) 3) Eine nur einmal zu verwendende Zeichenkombination, welche ausschließlich aus Buchstaben ({a-z}, {A-Z}), Ziffern ({0-9}) und den Sonderzeichen {-} und {.} bestehen darf (1-179 Zeichen). Beispiele für den Vorgaben entsprechende IDs: S519K SL cc2-37cb-42a9-ad74-06bb5746b60b 127BM ME abc8a e847890ba3b13a646 Die DocRefID muss dem o. a. Format entsprechen und über alle versandten/zu sendenden Lieferungen eindeutig sein. Sie darf nur einmalig vergeben und für nur eine einzige Datenlieferung verwendet werden. Somit ist für die Elemente zum ReportingFI, ggf. zum Sponsor oder Intermediary sowie zu den einzelnen AccountReports oder Nullmeldungen jeweils eine eigene (eindeutige - d.h. einzigartige und somit nur einmal verwendete) DocRefID zu vergeben. Sollte keine eigene GIIN vorhanden sein und daher der fest vorgegebene Wert TA.276 für das meldende Finanzinstitut verwendet werden müssen, ist, um die Eindeutigkeit der DocRefID zu gewährleisten, für die unter 3) genannte ergänzende Zeichenkombination folgender Aufbau zu verwenden: a) eigene BZSt-Nummer (BZ und 9-stellige Zahlenkombination) b) eigene Benutzerkonto-ID des BOP (10-stellige Zahlenkombination) c) frei wählbare, fortlaufende Nummer Beispiele für den Vorgaben entsprechende IDs: TA.276.BZ cc2-3b.b60b TA.276.BZ MZ2016BA183cd56 Bei Änderung der GIIN in Folgenachrichten ist darauf zu achten, dass in diesen Fällen die führende Kolumne der DocRefID (vgl. dazu 1)) ebenfalls entsprechend geändert werden muss MessageRefID In dem Feld MessageRefID ist eine eindeutige Referenzkennung für die Meldung anzugeben. Diese ID ist allerdings nur einmalig zu vergeben und nur für eine Datenlieferung zu verwenden. Seite 13 von 47

14 Das heißt, eine erneute Verwendung der ID für zukünftige Meldezeiträume ist nicht zulässig und führt zur Abweisung der Datenlieferung! Die MessageRefID muss mindestens aus 21 bis maximal 200 Zeichen bestehen und folgenden Aufbau aufweisen: 1) Inhalt aus dem Element SendingCompanyIN [19-stelliges GIIN-Format] (XXXXXX.YYYYY.ZZ.CCC) 2) Punkt als Trennzeichen (.) 3) Eine nur einmal zu verwendende Zeichenkombination, welche aus Buchstaben, Ziffern und den Sonderzeichen +, _, -,. bestehen darf. Beispiel für den Vorgaben entsprechende MessageRefID: S519K SL dd1-56cb-42b7-cf32-07dd4536c51c 5.4. GIIN Internationale Identifikationsnummer für Intermediäre (eindeutige Kennung). Die GIIN (Global Intermediary Identification Number) ist eine vom IRS vergebene eindeutige Identifizierungsnummer für Finanzinstitute (vgl. Registrierung beim IRS in Abschnitt 11) PoolReport (nicht zu verwenden) Der Begriff PoolReport bezeichnet eine Datenelementgruppe im FATCA XML-Datenschema. Die Datenelementgruppe PoolReport findet für Datenlieferungen meldender deutscher Finanzinstitute keine Anwendung und ist daher nicht zu verwenden. Eine Lieferung, die die Datenelementgruppe PoolReport beinhaltet, führt zur Abweisung der Lieferung. Dies gilt auch wenn die Datenelemente nicht befüllt sind! 5.6. Dateigrößenbeschränkung Die Größe einer einzelnen Datei, die über ELMA an das BZSt übermittelt werden soll, darf 100 MByte nicht überschreiten. Eine Überschreitung dieser Maximalgröße führt zur Abweisung der kompletten Lieferung Verwendung optionaler Datenelemente Wird bei einer Lieferung eine optionale Datenelementgruppe (Kardinalität 0-n) wie z.b. Sponsor oder Intermediary nicht benötigt, sollte diese komplett weggelassen werden. Andernfalls ist zwingend die Schemadefinition einzuhalten. Seite 14 von 47

15 Wenn also z.b. ein Sponsor keine TIN hat, ist das Datenelement TIN zu entfernen, da eine leere TIN nicht schemavalide ist Längenbeschränkung Die Länge der einzelnen Felder wird nunmehr direkt im Schema vorgegeben. Eine zusätzliche Begrenzung durch das BZSt gibt es nicht Zeichensatz und -beschränkung Unzulässige Zeichen und Zeichenkombinationen Grundsätzlich gilt für die elektronische Übermittlung an das BZSt der Standard Lateinische Zeichen in Unicode 1. Mit diesem Standard hat die Koordinierungsstelle für IT-Standards (KoSIT) die Teilmenge der zulässigen Lateinischen Zeichen des Unicode Standard abschließend festgelegt. Diese Teilmenge wird jedoch für das Verfahren FATCA durch Vorgaben des IRS weiter eingeschränkt. Die nachfolgende Tabelle enthält alle Zeichen, die aufgrund der IRS-Vorgaben als unzulässig gelten und deren Verwendung zur Abweisung einer Lieferung führen. In der hinteren Spalte wird dargestellt, durch welche Zeichenkombination diese Zeichen zu ersetzen sind um eine Abweisung grds. zu vermeiden: Zeichen Englischer Name Deutscher Name Ersetzen des Zeichens notwendig durch & Ampersand kaufmännisches Und & < Less Than kleiner als < > Greater Than größer als > Apostrophe Apostroph &apos; Quotation Mark Anführungszeichen " Tabelle 2: Unzulässige Zeichen Die nachfolgende Tabelle enthält Zeichenkombinationen, die aufgrund der IRS-Vorgaben ebenfalls als unzulässig gelten. Hier besteht nur die Möglichkeit diese Zeichenkombinationen nicht zu verwenden (ein Ersetzen der Zeichen ist nicht möglich), da die Lieferung ansonsten abgewiesen wird. 1 Seite 15 von 47

16 Zeichenkombination Englischer Name Deutscher Name -- Double Dash Doppelter Bindestrich /* Slash Asterisk Schrägstrich Sternchen &# Ampersand Hash kaufmännisches Und Doppelkreuz Tabelle 3: Unzulässige Zeichenkombinationen Die folgende Tabelle zeigt beispielhaft weitere Kombinationen, die der IRS als potentiell schädlich betrachtet. D. h. es erfolgt eine Abweisung der Lieferung, wenn in den gelieferten Daten an einer beliebigen Stelle in einem Wort ein (oder mehrere) Sonderzeichen enthalten ist und dieses unmittelbar von einer Buchstabenkombination gefolgt wird, die gleichzeitig einen SQL-Befehl darstellt (Groß- oder Kleinschreibung ist in dem Zusammenhang unerheblich). Auch hier gilt, dass in einem solchen Fall die Problematik besteht, dass das Sonderzeichen nicht durch ein Ersatzzeichen ersetzt werden kann. Stattdessen wird empfohlen, das Sonderzeichen schlicht entfallen zu lassen (z.b. statt D Andressa nur DAndressa). Beispiele für Zeichenkombinationen mit Apostroph und SQL-Befehlen AND AS IN MIN OR SUM and as in min or sum AND AS IN MIN OR SUM and as in min or sum Tabelle 4: Beispiele für Zeichenkombinationen mit Apostroph und SQL-Befehlen Verwendung UTF-8 Für die Erstellung von Inhalten einer XML-Datei, die mittels ELMA versandt werden soll, ist die UTF-8-Codepage zu verwenden. Abweichende Codepage-Varianten werden nicht unterstützt. Auch die XML-Rückmeldungen des BZSt zu der eingereichten Datei werden mit der UTF-8- Codepage zurückgeliefert Anzahl ReportingFI und ReportingGroups innerhalb einer Lieferung Nur ein ReportingFI innerhalb einer Lieferung zulässig In einer Lieferung dürfen nur Kontoreports bzw. ein Nilreport zu einem meldenden Finanzinstitut enthalten sein. Enthält eine Lieferung Meldungen zu mehr als einem meldenden Finanzinstitut, so wird die Lieferung abgewiesen. Seite 16 von 47

17 Nur eine ReportingGroup für den gleichen Sponsor/Intermediary Eine ReportingGroup (Reportgruppe) fasst die zwischen einem Finanzinstitut bzw. Meldestelle und dem BZSt auszutauschenden Daten eines Finanzinstituts mit gleichem verwaltenden Rechtsträger (Sponsor) und gleichem Vermittler (Intermediary) zusammen. Eine neue Reportgruppe muss daher jeweils nur für einen weiteren Sponsor/Intermediary aufgemacht werden. Sind z.b. alle AccountReports vom selben ReportingFI ohne Sponsor oder Intermediary, ist lediglich eine Reportgruppe pro Lieferung anzugeben FilerCategory zum Reporting FI oder Sponsor In den Datenelementgruppen ReportingFI oder Sponsor sind im Datenelement FilerCategory zwingend Eintragungen zu machen. Für das ReportingFI sind die Werte FATCA601-FATCA606, FATCA610 und FATCA611 und für den Sponsor die Werte FATCA607-FATCA609 zulässig. Wurde in dem Datensatz ein Sponsor angegeben (für diesen ist dann eine Eintragung im Element FilerCategory immer zwingend), darf im ReportingFI keine FilerCategory angegeben werden. Dies würde zur Abweisung führen. Eine Erläuterung zu den Werten finden Sie im aktuellen FATCA XML Schema v2.0 User Guide oder in der Nichtamtlichen deutschen Übersetzung des FATCA XML Schema v2.0 User Guide (vgl. Abschnitt 11) NilReport Das Datenelement NilReport (Nullmeldung) bietet einem Finanzinstitut die Möglichkeit anzuzeigen, dass für einen bestimmten Meldezeitraum keine meldepflichtigen Konten bestehen. Die Einreichung einer Nullmeldung ist rein optional. Sollte sich herausstellen, dass die Angabe einer Nullmeldung falsch war, ist die ursprüngliche Nullmeldung zwingend aufzuheben (FATCA3). Die meldepflichtigen Konten sind anschließend (nach erfolgreicher Aufhebung der Nullmeldung) mit der Meldeart FATCA1 dem BZSt neu zu übermitteln AccountClosed Für die Meldung eines geschlossenen oder vollständig an ein anderes FI übertragenen Kontos kann das Element AccountClosed genutzt werden. Dieses Datenelement gibt an, dass das Konto während des Kalenderjahres aufgelöst wurde. Überträgt ein Kontoinhaber die Beträge von einem Konto (oder Kontotyp) auf ein anderes Konto (oder einen anderen Kontotyp) beim selben Finanzinstitut, ist das Konto nicht als geschlossen zu melden. Seite 17 von 47

18 6. Meldearten, Datenübermittlung und Korrekturen Der Zeitpunkt einer Lieferung bzw. Korrekturlieferung bedingt die zu verwendende Meldeart. Es sind bestimmte Zeiten und Fristen bei der Lieferung von Daten zu berücksichtigen, da sich daraus unterschiedliche Reaktionen/Konsequenzen bei der Verwendung der Meldeart ergeben. Nachfolgende Erläuterungen geben nur einen kurzen Überblick über die möglichen Meldearten. Ausführlichere Erläuterungen zu diesem Themenbereich, insbesondere die zu berücksichtigen Besonderheiten, befinden sich im Dokument Verarbeitungsprotokolle FATCA, vgl. Abschnitt 11. Die Meldeart kennzeichnet, um welche Art von Daten es sich bei der Lieferung handelt. Es gibt die nachfolgenden vier Meldearten, die im Feld DocTypeIndic möglich sind: FATCA1 FATCA2 FATCA3 FATCA4 New Data Corrected Data Void Data Amended Data Tabelle 5: Meldearten FATCA1: Neue Daten (New Data) Diese Meldeart wird zur erstmaligen Übermittlung von bestimmten Datensätzen an den IRS verwendet oder zur erneuten Übermittlung von zuvor gelöschten Daten (per Void-Datensendung = Löschmeldung (FATCA3)). FATCA2: Korrigierte Daten (Corrected Data) Diese Meldeart wird für Datensätze verwendet, die erneut an das BZSt übermittelt werden sollen, nachdem durch eine US-EmpfangsbestätigungAnFI auf ein Problem im Zusammenhang mit einigen in der Datei enthaltenen Datensätzen hingewiesen wurde. Diese Meldeart ist nur dann zu verwenden, wenn eine Aufforderung durch das BZSt (US- EmpfangsbestätigungAnFI) zur Korrektur der Daten vorliegt. FATCA3: Ungültige Daten (Void Data) Diese Meldeart wird grundsätzlich zum Löschen bereits eingereichter Datensätze verwendet. Bei der Verwendung von Void Data müssen die Inhalte des ursprünglichen Datensatzes (ausgenommen MessageRefID, DocRefIds und DocTypeIndic) analog 1:1 beibehalten werden und lediglich mit der Meldeart FATCA3 gekennzeichnet und übermittelt werden. Soll ein Datensatz aufgehoben werden, da die Versendung beispielsweise nur irrtümlich erfolgte und ist danach auch nicht beabsichtigt, neue Daten mit der Meldeart Neue Daten (FATCA1) zu senden, können Rückfragen seitens des IRS an das BZSt nicht ausgeschlossen werden. Dies liegt daran, dass der IRS nach einer Meldung mit der Meldeart Ungültige Daten (FATCA3) grundsätzlich eine neue Meldung mit der Meldeart Neue Daten (FATCA1) erwartet. Seite 18 von 47

19 FATCA4: Geänderte Daten (Amended Data) Diese Meldeart wird zur Änderung eines oder mehrerer bereits an das BZSt übermittelter und vom IRS angenommener Datensätze verwendet, bei denen zu einem späteren Zeitpunkt durch den Datensender festgestellt wird, dass sie fehlerhafte Informationen enthalten. Die Verwendung von Amended Data ist nur in Folge einer US-EmpfangsbestätigungAnFI (Notification) ohne Beanstandungen erlaubt. Nähere Informationen zu den vorstehenden Ausführungen ergeben sich aus den Dokumenten Verarbeitungsprotokolle FATCA und US-EmpfangsbestätigungAnFI (Notification), vgl. Abschnitt Zeitpunkt der Übermittlung Meldende deutsche Finanzinstitute haben ihre FATCA-Daten bis zum 31. Juli des auf den Meldezeitraum folgenden Kalenderjahres im Wege der Datenfernübertragung an das Bundeszentralamt für Steuern zu übermitteln ( 8 Abs. 3 der FATCA-USA-Umsetzungsverordnung). Ein festgelegter Endzeitpunkt der Übermittlung von Erst- und Korrekturmeldungen ist derzeit nicht vorgesehen. Es wird darauf hingewiesen, dass bei Zuwiderhandlung der obliegenden gesetzlichen Verpflichtung in Bezug auf FATCA die Einleitung eines Bußgeldverfahrens (vgl. 5 Abs. 1 Nr. 5a Finanzverwaltungsgesetz) droht Korrekturen Bei Einreichung korrigierter, ungültiger oder geänderter Daten muss eine CorrMessageRefID angegeben werden, die auf die MessageRefID aus der ursprünglichen Lieferung Bezug nimmt. Soll ein Report geändert oder gelöscht werden, so muss darüber hinaus eine CorrDocRefID angegeben werden, die auf die DocRefID des ursprünglich gemeldeten Reports verweist. Das bedeutet, eine Änderungsmeldung muss sich immer, also auch bei mehreren aufeinanderfolgenden Korrekturen, auf die konkrete Erstmeldung beziehen. Beispiel (mit fiktiven Werten): Datenelementgruppe Erstmeldung Korrekturmeldung Element Wert Element Wert MessageHeader MessageRefId M1 MessageRefId (neu vergeben) M2 CorrMessageRefId (aus Originalmeldung) M1 Seite 19 von 47

20 ReportingFI DocRefId F1 DocRefId (neu vergeben) CorrMessageRefId (aus Originalmeldung) CorrDocRefId (aus Originalmeldung) Report DocRefId R1 DocRefId (neu vergeben) CorrMessageRefId (aus Originalmeldung) CorrDocRefId (aus Originalmeldung) Tabelle 6: Systematik bei der Verwendung von CorrMessageRefID und CorrDocRefID F2 M1 F1 R2 M1 R1 Die Korrektur einer Meldung ist auch über ein anderes Meldeverfahren als das der Erstmeldung möglich, z.b. Übermittlung der Erstmeldung über ELMA, Korrektur über BOP. Welcher Korrekturweg zu welchem Zeitpunkt zulässig ist, hängt von der zugrundeliegenden Ausgangssituation ab. Die Korrekturwege und die damit einhergehenden Erläuterungen sind im Dokument Verarbeitungsprotokolle FATCA ausführlich dargestellt, vgl. Abschnitt Versand von Massendaten über die Die wurde durch das ITZBund (ehemals ZIVIT) für die Übertragung von Massendaten entwickelt. Die Zielgruppe sind Institutionen, die im Rahmen der verschiedenen steuerlichen Verfahren auf elektronischem Wege verschlüsselte Massendaten an das BZSt übertragen wollen Grundlagen von ELMA/XSD (NEU) Die Finanzinstitute übertragen über die XML-Dateien. Mit den XML-Dateien werden die fachlichen Daten zu FATCA (Nutzdaten) wie meldepflichtiges Konto und Angaben zum Finanzinstitut an das BZSt gemeldet. Neben diesen fachlichen Daten sind in der Datei zudem Metadaten wie Absender der Daten, Verfahrensbezug etc. (Kopfdaten) zu übermitteln. Die Metadaten des ELMA5-Verfahrens werden wie ein Umschlag um die eigentlichen FATCA- Dateninhalte herumgelegt. Seite 20 von 47

21 Der Aufbau der gesamten XML-Struktur wurde aufgrund der Vielzahl an neuen Verfahren weiterentwickelt und standardisiert. Diese Änderungen sind ab dem für alle ab diesen Zeitpunkt für das Verfahren FATCA zu übersendenden Lieferungen an das BZSt gültig. Der Aufbau des XMLs beginnt jeweils mit dem Wurzel-Element ELMAFC. Dieses Element ist der Wurzelknoten für die gesamte zu übertragene Datei und stellt den Einstieg in die Baumstruktur dar. Danach folgt der ELMAKOM-Abschnitt. Dieser beinhaltet die Teile ELMAHeader und ELMAVerfahren. ELMAHeader und ELMAVerfahren sind Bestandteil einer jeden ELMA-Lieferung und nicht verfahrensspezifisch. Der ELMAHeader enthält alle Informationen des Senders für die Fachverfahrens- und Sender-Zuordnung. Unter ELMAVerfahren ist das fachverfahrensspezifische XML einzubetten. Diese Elemente müssen IMMER in der vorgegebenen Anordnung verwendet werden. Abbildung 1: Wurzelknoten ELMAFC FATCA_ELMA_XSD - Lieferdatei Die für die zu übertragende XML-Datei zu verwendenden Schema-Definitionen FATCA_ELMA_XSD stehen als ZIP-Archiv für den Download zur Verfügung, vgl. Abschnitt 11 zur Verfügung. Die folgenden beiden Dateien sind Bestandteil des ZIP-Archives im Unterordner FATCA und sind zwingend zusammen zu nutzen: externelma ELMAFC_ xsd (Root-Knoten) ELMAKOM_FC_ xsd ELMA_Standard_Elemente_ xsd nutzdaten FATCA_ xsd Seite 21 von 47

22 FatcaXML_v2.0.xsd isofatcatypes_v1.1.xsd oecdtypes_v4.2.xsd stffatcatypes_v2.0.xsd Hinweise zur Verwendung: Die für den Upload erzeugte XML-Datei ist vor der Versendung zwingend gegen das zuvor genannte, vollständige XSD (gesamter ZIP-Ordner) zu validieren. Neben den ELMA- Komponenten ELMAFC, ELMAKOM und FATCA sind in der XML-Datei die Nutzdaten, die sich aus dem FATCA-XML ergeben, in das FATCA_OECD-Element zu übertragen. Die XSD-Dateien werden von der Datei ELMAFC ausgehend referenziert. Die Namespace -Einsetzungen sind zu beachten. Für jeden Namespace-Prefix darf das Attribut xmins:prefix nur einmal vorkommen. Das Attribut xsi:schemalocation darf nur einmal vorkommen. Erstellungsdatum (ELMA-Header). Dieses Feld muss mit dem Datum des Tages des Uploads der Dateien ins ELMA-Verzeichnis gefüllt werden. Die Reihenfolge der einzelnen Elemente in der Schema Definition muss im XML eingehalten werden; eine Nichtbeachtung führt zur Abweisung der Lieferung. Die Reihenfolge der Elemente ist durch die XSD eindeutig festgelegt Zeichenbeschränkung für die Für die erstellte XML-Dateien verwenden grundsätzlich ohne Einschränkungen die UTF-8 Codepage. Hinweis: Ersatzzeichen dürfen in den ELMA-Elementen (ELMAFC, ELMAKOM, ELMAHeader, ELMAVerfahren) nicht verwendet werden. Dies führt zur Abweisung der Lieferung. Über die Abweisung aufgrund eines Zeichenfehlers wird der Benutzerkontoinhaber per informiert, vgl. Abschnitt 9.1. Kommentare dürfen im gesamten XML Schema entsprechend den Konventionen verwendet werden. Sie werden aber vollständig ignoriert und nicht genutzt. Seite 22 von 47

23 7.3. Aufbau ELMAHeader Abbildung 2: Aufbau ELMAHeader Seite 23 von 47

24 Die nachfolgende Tabelle beschreibt die Befüllung des neuen ELMAHeaders. Feldname Anzahl Zeichen Typ Kardinalität Inhalt/ Erläuterung Bemerkungen ELMAKOMVersion DatenArt 10 1 ELMA_FC Siehe Vorgabe des Fachverfahrens. Für FATCA ELMA_FC AuthSteuernummer 11 an 1 Die verwendete BZSt-Nummer des Anwenders AccountID 10 an 1 10-stellige Zahl Account-ID des verwendeten Zertifikats ErstellungsDatum 19 an 1 Tagesdatum des Uploads der Dateien Ist benutzerabhängig. Beginnt mit BZ oder BX gefolgt von 9 Ziffern. Beispiel: BZ Wichtig: Großschreibung beachten! Die AccountID wird im privaten Bereich des BOP-Benutzerkontos unter Mein BOP -> Mein Benutzerkonto als Benutzerkonto-ID angezeigt. Dieses Feld ist mit dem Erstellungsdatum zu füllen. Die Übertragungszeit wird nur informationshalber genutzt. Form: Jahr-Monat- TagTStunde:Minute:Sekunde Beispiel: T13:20:00 KundeneigeneID 255 an 0..1 Kann für die Zuordnung der gesendeten Datei zum kundeneigenen Informationssystem verwendet werden. UUID Unbegrenzt an 0..1 Kennzeichnung der Datenlieferung Hexadezimal notierte Zahl UUID Beispiel: 550e8400-e29b- 11d4-a Verarbeitungslauf ENUM 0..1 PRODUKTIONS- LAUF oder TESTLAUF Unterscheidung des Dateneingangs zwischen Test- und Produktivdatenübermittlung. Seite 24 von 47

25 Feldname Anzahl Zeichen Typ Kardinalität Inhalt/ Erläuterung Bemerkungen Bei einem leeren Feld handelt es sich immer um Produktionsdaten. Auf der Produktionsumgebung werden Dateien mit TESTLAUF abgewiesen. Tabelle 7: Befüllung des ELMAHeaders 7.4. Namenskonventionen Jede Lieferung besteht immer aus 2 Dateien (Datendatei und Signaturdatei). Die Datendatei enthält die in den ELMA-Header eingebettete FATCA-Meldung während mit der Signaturdatei die Datenintegrität und die Authentizität des Senders festgestellt wird Namenskonventionen Datendatei Der vom Sender generierte Dateiname besteht nur aus den kleinen Buchstaben [a-z] und den Ziffern [0-9]. Im speziellen Teil des Dateinamens (DateiId) dürfen zusätzlich große Buchstaben verwendet werden[a-z]. Die Verwendung von abweichenden Zeichen (öäüß usw.) führt zu einer Abweisung der Datenlieferung. Die einzelnen Bestandteile des Dateinamens werden mit einem Unterstrich _ getrennt. Zwischen dem Dateinamen und dem Suffix wird ein Punkt. als Trennzeichen verwendet. Der Dateiname der Datendatei endet mit dem xml Suffix. Dateinamen sind über alle Meldezeiträume hinweg eindeutig zu vergeben. Ein bereits für die Übertragung verwendeter Dateiname (Produktion oder Test) darf nicht erneut genutzt werden. Dies gilt auch im Fehlerfall, bspw. bei einer formalen Abweisung durch die ELMA-Prüfung. Während der Eingangsprüfung wird über die Eingangsdatei ein Hash gebildet, welcher zusammen mit dem Dateinamen gespeichert wird. Bei einer Abweisung ist daher immer ein neuer Dateiname zu bilden und im Datensatz mindestens ein Zeichen zu ändern. So erkennt die ELMA-Prüfung, dass es sich bei der Datenlieferung nicht um eine versehentliche Doppellieferung handelt. Die Elemente <BZStNr> und <AccountID> des Dateinamens müssen mit den Feldern in der ELMA- Header-Struktur (vgl. Abschnitt 7.3) innerhalb der Datei übereinstimmen. Der grundsätzliche Aufbau des Dateinamens folgt folgendem Schema: m5_fc_<bzstnr>_<accountid>_<dateiid>.xml Beispiel: m5_fc_bz _ _fatca0001.xml Seite 25 von 47

26 Die Bestandteile des Dateinamens unterliegen klar definierten Regeln. Diese sind in der nachfolgenden Tabelle beschrieben. Feldname Anzahl Zeichen Typ Kardinalität Inhalt/ Erläuterung Bemerkungen m5 2 an 1 ELMA-Dateikennung konstant _ 1 1 Unterstrich konstant fc 2 an 1 Produktbezeichnung/ Verfahrenskürzel konstant _ 1 1 Unterstrich konstant <BZStNr> 11 an 1 11-stellige alphanumerische Senderkennung, die der BZSt-Nummer des versendenden FI oder Dienstleisters entspricht und zur BOP-Nutzung vergeben wurde benutzerabhängig beginnt mit bz oder bx gefolgt von 9 Ziffern Beispiel: bz Wichtig: Kleinschreibung beachten! _ 1 1 Unterstrich konstant <AccountID> 10 an 1 10-stellige Zahl Account-ID des verwendeten Zertifikats Die AccountID wird im privaten Bereich des BOP- Benutzerkontos unter Mein BOP -> Mein Benutzerkonto als Benutzerkonto-ID angezeigt, (vgl. Tabelle 7Fehler! Verweisquelle konnte nicht gefunden werden.). _ 1 1 Unterstrich konstant <DateiID> 1-12 an 1 Von der versendenden Stelle (FATCA- Verantwortlicher des FIs oder des versendenden Dienstleisters) zu vergebender, interner Max. 12 Zeichen. Darf nur Zeichen aus [a-z, A-Z, 0-9] enthalten. Es sind keine Sonderzeichen, Leerzeichen oder Unterstriche (_) erlaubt. Seite 26 von 47

27 Kurzname für die Datendatei. Dieser Bezeichner wird in FATCA nicht geprüft und dient nur der internen Zuordnung des Versenders. Eine naheliegende Option für Dienstleister ist die Codierung des FI, in dessen Auftrag die Datendatei erstellt wird. Tabelle 8: Aufbau es Dateinamens einer Datendatei Namenskonvention Signaturdateien Zur Übertragung der Datendatei ist eine Signaturdatei erforderlich, deren Dateiname dem Namen der Datendatei, ergänzt um den Suffix.sig, entspricht, vgl. Tabelle Erstellung Signaturdateien Jede Datendatei ist zusammen mit der zugehörigen Signaturdatei gemeinsam zu übertragen. Basis der Signaturdatei ist ein spezielles ELMA5-Zertifikat, das im BZStOnline-Portal generiert werden muss. Mit dem Abschluss der Registrierung im BZStOnline-Portal erhalten Sie eine Zertifikatsdatei im PFX-Format. Dieses Zertifikat ist für die Massendatenübertragung über ELMA mit einer eigenen SFTP-Verbindung in diesem Format nicht nutzbar. Für den SFTP-Verbindungsaufbau zum ELMA- Server und für die Signaturerstellung wird das Zertifikat im PEM-Format bzw. PKK-Format benötigt. Es handelt sich dabei um dieselbe Schlüsselinformation. Das benötigte PEM-Zertifikat kann im BZStOnline-Portal unter Formulare & Leistungen -> Versand von Massendaten (ELMA5) -> ELMA5-Zertifikat generieren generiert werden. Abbildung 3: ELMA5-Zertifkikat für den Verbindungsaufbau und die Signaturdatei generieren Seite 27 von 47

28 Nach erfolgtem Download verfügen Sie neben der.pfx-datei über eine weitere Datei mit der.pem-endung, die Ihnen die Authentifizierung bei der Übermittlung Ihrer Massendaten ermöglicht. Auf Linux Maschinen wird das PEM-Format für die SFTP-Datenübertragung verwendet. Auf Windows Systemen ist das PEM-Format vor der Verwendung mit dem puttygen.exe-programm in das PPK-Dateiformat zu konvertieren. Im Rahmen der Anpassung an die neuesten Sicherheitsstandards muss zur Erstellung der Signaturdatei ab Dezember 2018, spätestens September 2019, als Signaturverfahren RSASSA- PSS 2 mit folgenden Parametern verwendet werden: Hashverfahren: SHA-256 Mask Generation Function: MGF1 mit SHA-256 Länge des Salts: 32 Byte Trailer Field: 0xBC Die Umstellung der Signaturverfahren erfolgt stufenweise. Ab September 2019 ist zwingend das Signaturverfahren RSASSA-PSS mit dem Hashverfahren SHA-256 zu nutzen. Einlieferungen nach dem bisherigen Signaturverfahren (RSASSA-PKCS1-v1_5 mit SHA-512) werden ab diesem Zeitpunkt abgewiesen. Wir empfehlen daher eine frühzeitige Umstellung des Signaturverfahrens. Auf Linux Systemen kann für die Erstellung der Signaturdatei das OpenSSL Command Line Tool verwendet werden. (Die aktuelle Version kann unter bezogen werden.) Öffnen Sie per Tastenkombination "Alt" + "F2" den Anwendungsstarter und geben Sie den Begriff "Terminal" ein. Führen Sie das Programm mit Return aus. Wechseln Sie in das Verzeichnis der Datendatei und führen Sie im Terminal-Fenster die folgende Kommandozeile aus. openssl dgst sha256 binary out <Dateiname-mit-Suffix>.sig \ 3 -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 -sign ~ 4 /.ssh/elster.pem <Dateiname-mit-Suffix> Enter pass phrase for key: <Passphrase> Nach Eingabe der Passphrase wird die Signaturdatei erstellt. 2 RSASSA-PSS ist in PKCS #1 ab Version 2.1 standardisiert. Die aktuelle Version 2.2 finden Sie in RFC 8017 unter 3 Das Zeichen \ stellt die Fortsetzung der Eingabe in einer neuen Zeile dar. Wird die Eingabe nicht in einer neuen Zeile fortgesetzt, kann dies entfallen. 4 Das Zeichen ~ referenziert das Home-Verzeichnis des Anwenders. Hier kann auch der komplette Pfad angegeben werden. Seite 28 von 47

29 Auf Windows Systemen erfolgt die Eingabe aus dem Kommandozeilen-Fenster (Aufruf mittels cmd.exe). Wechseln Sie in das Verzeichnis der Datendatei. Die elster.pem Schlüsseldatei muss im selben Verzeichnis liegen. Andernfalls ist diese im folgenden Aufruf mit einer Pfadangabe zu versehen. Führen Sie im Kommandozeilen-Fenster die folgende Kommandozeile aus. Substituieren Sie [Pfadangabe] durch das Installationsverzeichnis der openssl.exe Datei. [Pfadangabe]\\openssl.exe dgst sha256 binary \ 5 out <Dateiname-mit-Suffix>.sig -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 -sign elster.pem <Dateiname-mit-Suffix> Enter pass phrase for key: <Passphrase> Nach Eingabe der Passphrase wird die Signaturdatei erstellt. Die Passphrase wird bei jeder Signaturerstellung verwendet und sollte daher dauerhaft und sicher hinterlegt werden. Namenskonventionen zur Signaturdatei ergeben sich aus Abschnitt Aufbau der Verbindung Die Einlieferung einer ELMA-Datei erfolgt über eine Rechner-zu-Rechner-Kopplung per SFTP. Der zu verwendende DNS-Name ist: elma5p.bfinv.de (IP-Adresse: ). Es ist zu beachten, dass zur Konfiguration der Serververbindung nur dieser DNS-Name zu verwenden ist und nicht die resultierende IP-Adresse. Das BZSt behält sich vor, die IP-Adresse jederzeit ohne Vorankündigung zu ändern. 8. Übertragung einer XML- und Signaturdatei an ELMA Die XML-Datei ist in der Übertragungsart binär via SFTP in das ELMA-Upload-Verzeichnis zu übertragen. Bei Verwendung einer abweichenden Übertragungsart wird bei einem File-Transfer von einem Windows-basierten System die Signaturdatei nicht mehr zur Datendatei passen weil im Rahmen des Transfers bspw. das Zeilenende CR/LF in das Unix-Format LF des Zielrechners gewandelt wird. Der Sender würde einen Hinweis auf einen Signaturfehler erhalten. Es ist immer zuerst die Datendatei und anschließend die korrespondierende Signaturdatei in das Upload-Verzeichnis auf dem ELMA-Server einzustellen. Zu jeder Datendatei ist eine zugehörige Signaturdatei zu übermitteln, vgl. Abschnitt Das Zeichen \ stellt die Fortsetzung der Eingabe in einer neuen Zeile dar. Wird die Eingabe nicht in einer neuen Zeile fortgesetzt, kann dies entfallen. Seite 29 von 47

30 Hinweis: Unter Windows kann das kostenfreie Tool WinScp in der aktuellen Version verwendet werden. Bei älteren Versionen sind die notwendigen Encryption Cipher nicht Bestandteil des Programms. Die Verbindung zum ELMA-Server schlägt dann fehl (vgl. Hinweise im Logfile der Software). In diesen Fällen ist ein Update der Programmversion notwendig. Für den Verbindungsaufbau zum ELMA-Server mit dem WinScp Programm muss das.pem- Zertifikat aus dem BZStOnline-Portal auf ihren lokalen Rechner heruntergeladen und die.pem- Datei in das PPK-Format konvertiert werden. Hierfür wird eine bestehende Putty Installation und der Key-Generator PuTTYgen.exe benötigt. Anschließend ist die PEM-Datei mit dem Load Befehl in das Programm PuTTYgen.exe hochzuladen. Die Nutzung der Datei wird durch die Eingabe der zum Benutzerkonto gehörenden Passphrase freigeschaltet. Nach dem Import des privaten Schlüssels kann das Zertifikat in dem PuTTY-eigenen PPK-Format mit Save private key gespeichert werden. Im WinScp Programm ist der Name der konvertierten PPK-Datei, der vollständige DNS-Name des ELMA-Servers und die BZSt-Nummer (in Kleinbuchstaben) mit zugehöriger Passphrase für die Herstellung der Verbindung einzutragen. Es ist immer zuerst die Datendatei und danach die korrespondierende Signaturdatei in das Upload-Verzeichnis auf dem ELMA-Server einzustellen. Die Signaturdatei hat eine Länge von 256 Byte. Beim Upload einer Datei mittels SFTP ist diese zunächst mit der Endung.tmp zu übertragen. Datendatei: m5_fc_<bzstnr>_<accountid>_<dateiid>.xml.tmp Signaturdatei: m5_fc_<bzstnr>_<accountid>_<dateiid>.xml.sig.tmp Erst nach erfolgreichem Transfer ist auf die erforderliche Zielendung (.xml,.sig) umzubenennen. Dadurch wird vermieden, dass Verarbeitungsjobs beim Datenempfänger bereits noch im Upload- Vorgang befindliche Dateien in den Zugriff nehmen. Es ist stets zuerst die Signaturdatei und erst danach die korrespondierende Datendatei umzubenennen. Nach dem Upload ist dann die Dateimaske zu setzen. Der Lieferant muss dabei sicherstellen, dass die UNIX-Datei-Rechte für eingelieferte Dateien auf 0660 (Eigentümer = R/W, Gruppe = R/W, Andere = <kein Zugriff>) stehen. Seite 30 von 47