Regulatory Reporting: warum das Konto die Meldepflicht bestimmt, nicht der Kunde

Regulatory Reporting im Zahlungsverkehr: Welche Meldepflichten bei internationalen Zahlungen gelten

Regulatory Reporting bezeichnet Angaben in Zahlungsnachrichten, die Banken für gesetzliche oder regulatorische Meldungen benötigen. Welche Angaben erforderlich sind, hängt von den Vorgaben der beteiligten Länder und Banken ab. Eine wichtige Rolle spielen dabei der Debtor Agent und der Creditor Agent, also die Bank des Zahlers und die Bank des Zahlungsempfängers.

Entscheidend ist jedoch nicht allein der Standort der Bank. Nationale Regelungen können zusätzlich von der Ansässigkeit der beteiligten Parteien, dem Betrag, der Währung oder der Art der Zahlung abhängen. Für Unternehmen mit internationalen Bankverbindungen entsteht dadurch eine praktische Herausforderung: Eine Zahlung kann zusätzliche regulatorische Angaben benötigen, obwohl der eigentliche Geschäftsvorgang unverändert bleibt.

Was bedeutet Regulatory Reporting im Zahlungsverkehr?

Viele Staaten erfassen Daten zu grenzüberschreitenden Zahlungen. Diese Informationen werden beispielsweise für Zahlungsbilanzstatistiken, Devisenkontrollen oder andere regulatorische Zwecke verwendet. Banken benötigen dafür teilweise zusätzliche Angaben vom Auftraggeber. Dazu kann insbesondere der wirtschaftliche Zweck einer Zahlung gehören.

ISO 20022 stellt dafür das Element RgltryRptg bereit. Es enthält Informationen, die aufgrund regulatorischer oder gesetzlicher Anforderungen benötigt werden. In pain.001 sind bis zu zehn Regulatory Reporting Blöcke pro Zahlung vorgesehen. Das ist erforderlich, weil unterschiedliche regulatorische Anforderungen auf der Seite des Zahlers und auf der Seite des Zahlungsempfängers bestehen können.

Regulatory Reporting und Purpose Code sind nicht dasselbe

Regulatory Reporting darf nicht mit dem Purpose Code verwechselt werden. Der Purpose Code im Element Purpbeschreibt den Zweck einer Zahlung innerhalb der Zahlungsnachricht und kann von Banken und anderen Beteiligten im Zahlungsprozess verwendet werden.

Das Element RgltryRptg ist dagegen ausdrücklich für Informationen vorgesehen, die aufgrund regulatorischer oder gesetzlicher Anforderungen benötigt werden. Ein landesspezifischer Meldecode gehört deshalb nicht automatisch in das Feld Purp. Entscheidend sind die Vorgaben des jeweiligen Landes, der Bank und des verwendeten Zahlungsformats.

Mehr zur Unterscheidung zwischen Zahlungszweck und regulatorischen Angaben finden Sie hier: Purpose Code in ISO 20022: Bedeutung, Codeliste und Praxis in SEPA

Debtor Agent und Creditor Agent: Welche Bank ist betroffen?

Für Regulatory Reporting sind die Rollen innerhalb der Zahlungsnachricht wichtig.

Zusätzlich gibt es die Initiating Party. Das ist die Partei, die eine Zahlungsdatei einreicht. Dabei kann es sich um den Zahler selbst, eine Payment Factory, ein Shared Service Center oder einen Dienstleister handeln.

Bei der Prüfung regulatorischer Anforderungen muss insbesondere betrachtet werden, welche Anforderungen für den Debtor Agent und den Creditor Agent gelten. Zusätzlich können nationale Vorschriften weitere Kriterien heranziehen. Dazu gehören beispielsweise die Ansässigkeit des Zahlers oder Zahlungsempfängers, der Betrag und das Zielland.

Beispiel Frankreich: Regulatory Reporting hängt auch von der Ansässigkeit ab

Frankreich zeigt, warum eine reine Betrachtung des Bankstandorts nicht ausreicht. Die französische Zahlungsbilanz erfasst wirtschaftliche Transaktionen zwischen Gebietsansässigen und Gebietsfremden. Die Ansässigkeit ist damit ein wesentliches Kriterium.

Für bestimmte grenzüberschreitende Zahlungen französischer Unternehmen gelten zusätzliche statistische Meldeanforderungen. Bei Zahlungen von oder an in Frankreich ansässige Unternehmen mit Gegenparteien außerhalb des SEPA Raums werden für bestimmte Transaktionen oberhalb von 50.000 Euro zusätzliche Angaben verlangt. Dazu gehört unter anderem ein Wirtschaftscode zur Klassifizierung der Zahlung.

Ein Unternehmen mit französischer Gesellschaft oder französischer Niederlassung sollte deshalb nicht davon ausgehen, dass eine Zahlung allein deshalb ohne zusätzliche Angaben verarbeitet werden kann, weil sie über ein standardisiertes ISO 20022 Format eingereicht wird.

Beispiel Vereinigte Arabische Emirate: Purpose Angaben bei grenzüberschreitenden Zahlungen

Die Zentralbank der Vereinigten Arabischen Emirate verlangt bei grenzüberschreitenden Transaktionen die Erfassung des Zahlungszwecks. Dafür existieren vorgegebene Purpose Codes. Finanzinstitute müssen die entsprechenden Angaben bei den betroffenen Transaktionen erfassen und an die Zentralbank melden.

Für Unternehmen bedeutet das: Bei Zahlungen über Konten in den Vereinigten Arabischen Emiraten muss geprüft werden, welche Purpose Angaben die jeweilige Bank verlangt und in welchem Feld diese übermittelt werden müssen. Fehlende oder falsche Angaben können zu manueller Bearbeitung, Rückfragen oder einer Ablehnung durch die beteiligte Bank führen. Die konkrete Verarbeitung richtet sich nach den Vorgaben der jeweiligen Bank und des verwendeten Zahlungswegs.

Beispiel Indien: Purpose Codes bei internationalen Zahlungen

Auch im indischen Zahlungsverkehr spielen Purpose Codes bei grenzüberschreitenden Transaktionen eine wichtige Rolle. Banken verwenden diese Angaben zur regulatorischen Klassifizierung von Zahlungen unter den indischen Devisenvorschriften.

Bei Zahlungen nach Indien sollte deshalb vor der Einreichung geklärt werden, welcher Purpose Code für den konkreten Geschäftsvorgang erforderlich ist. Der passende Code sollte nicht geschätzt werden. Im Zweifel sollte er mit dem Zahlungsempfänger oder einer der beteiligten Banken abgestimmt werden.

Wie ist Regulatory Reporting in ISO 20022 aufgebaut?

Das Element RgltryRptg stellt mehrere Felder für regulatorische Angaben bereit. Welche davon tatsächlich verwendet werden dürfen oder müssen, hängt vom ISO 20022 Schema, dem Land und den Vorgaben der Bank ab.

Debit Credit Reporting Indicator

Der Debit Credit Reporting Indicator zeigt, auf welche Seite sich die regulatorische Information bezieht. DEBTbezeichnet die Seite des Zahlers, CRED die Seite des Zahlungsempfängers.

BOTH kann technisch vorgesehen sein. Ob dieser Wert unterstützt wird, hängt jedoch von der jeweiligen Implementierung ab. Banken können die technisch möglichen ISO 20022 Felder zusätzlich einschränken. Die DZ BANK erlaubt beispielsweise DEBT und CRED, aber nicht BOTH.

Authority

Im Bereich Authority kann angegeben werden, für welche Behörde die regulatorischen Informationen bestimmt sind. Dazu gehören unter anderem Name und Land der Behörde.

Ob diese Felder unterstützt oder verlangt werden, ist bankabhängig. Auch hier kann die Bank Implementierungsregeln vorgeben, die enger sind als das eigentliche ISO 20022 Schema.

Details

Innerhalb von Details werden die eigentlichen regulatorischen Angaben übertragen. Dazu können beispielsweise ein Typ, ein Land, ein Code, ein Betrag oder zusätzliche Informationen gehören.

Welche Informationen erforderlich sind, richtet sich nach den jeweiligen nationalen Anforderungen.

Code und Information

Im Feld Code kann ein regulatorisch vorgegebener Wert übertragen werden. Information dient für zusätzliche Angaben, sofern diese nach dem jeweiligen Regelwerk erforderlich sind.

Auch Länge und Anzahl der unterstützten Angaben können durch die Bank eingeschränkt werden. Technisch gültiges ISO 20022 bedeutet deshalb nicht automatisch, dass eine Zahlungsdatei die Vorgaben der ausführenden Bank erfüllt.

Warum bankindividuelle ISO 20022 Vorgaben wichtig sind

ISO 20022 definiert eine umfangreiche Struktur für Zahlungsnachrichten. Banken müssen jedoch nicht jedes technisch mögliche Feld in jeder Ausprägung unterstützen. Die konkrete Implementierung kann deshalb von Bank zu Bank unterschiedlich sein.

Ein Beispiel liefert die DZ BANK. In ihren Vorgaben für den Auslandszahlungsverkehr werden einzelne Felder innerhalb von Regulatory Reporting unterstützt, andere führen zu einer Verarbeitung außerhalb des Straight Through Processing.

Unternehmen müssen deshalb drei Ebenen unterscheiden:

1. Das technische ISO 20022 Schema.

2. Die regulatorischen Anforderungen des jeweiligen Landes.

3. Die konkreten Formatvorgaben der ausführenden Bank.

Erst das Zusammenspiel dieser drei Ebenen entscheidet darüber, welche Angaben tatsächlich in einer Zahlungsdatei benötigt werden.

Was passiert, wenn Regulatory Reporting Angaben fehlen?

Die Folgen unterscheiden sich nach Land, Bank und Zahlungsweg. Mögliche Konsequenzen sind Rückfragen durch die Bank, manuelle Bearbeitung statt Straight Through Processing, Verzögerungen bei der Ausführung oder Gutschrift sowie die Ablehnung einer Zahlung.

Auch fehlerhafte oder unvollständige regulatorische Meldungen durch das Finanzinstitut können eine Folge sein. Die konkreten Auswirkungen lassen sich deshalb nicht pauschal für alle Länder beschreiben.

Für Unternehmen ist entscheidend, die erforderlichen Angaben bereits vor der Einreichung der Zahlungsdatei zu bestimmen.

Muss die Bank Regulatory Reporting ergänzen?

Banken können Informationen ergänzen, die ihnen bereits vorliegen. Den wirtschaftlichen Hintergrund einer konkreten Zahlung können sie jedoch nicht immer eindeutig aus ihren eigenen Daten ableiten.

Deshalb müssen Unternehmen je nach Land und Zahlungsart selbst Informationen zum Geschäftsvorgang bereitstellen. Hinzu kommt, dass regulatorische Codes international nicht einheitlich standardisiert sind. Länder verwenden unterschiedliche Codelisten, Regeln und technische Anforderungen.

Eine zentrale weltweit gültige Liste aller regulatorischen Zahlungsanforderungen existiert nicht…

Ist Regulatory Reporting auch bei SEPA Zahlungen relevant?

Regulatory Reporting ist vor allem im internationalen Zahlungsverkehr relevant. Die Aussage, dass Unternehmen das Thema bei Zahlungen innerhalb von SEPA grundsätzlich ignorieren können, wäre jedoch zu pauschal.

Auch das SEPA Regelwerk sieht das ISO 20022 Element Regulatory Reporting technisch vor. Ob Angaben tatsächlich erforderlich sind, hängt von der jeweiligen Zahlung, den beteiligten Ländern und den nationalen Anforderungen ab.

Besonders relevant wird die Prüfung bei internationalen Kontostrukturen, Zahlungen außerhalb des SEPA Raums und Bankverbindungen in Ländern mit umfangreichen Devisen oder Meldevorschriften.

Wo finden Unternehmen Informationen zu Regulatory Reporting Anforderungen?

Eine wichtige Referenz ist CGI MP Appendix B Local Country Rules. Die Common Global Implementation Market Practice Gruppe dokumentiert dort länderbezogene Anforderungen für Zahlungsnachrichten. Die Dokumente sind über Swift verfügbar und werden regelmäßig aktualisiert.

Eine weitere Quelle sind die Market Practice Dokumente der Payments Market Practice Group. Sie erläutern die Verwendung von Purpose, Category Purpose und Regulatory Reporting innerhalb von ISO 20022.

Für die praktische Umsetzung sollten zusätzlich die Vorgaben der jeweiligen Zentralbank oder Aufsichtsbehörde geprüft werden. Ebenso wichtig sind die Formatbeschreibungen der ausführenden Bank. Sie bestimmen, welche ISO 20022 Elemente tatsächlich unterstützt werden.

Wenn der richtige Code nicht eindeutig bestimmt werden kann, sollte er mit dem Zahlungsempfänger oder einer der beteiligten Banken abgestimmt werden.

Regulatory Reporting vor dem Versand prüfen

Internationale Zahlungsdateien müssen nicht nur technisch valide sein. Sie müssen auch die länderspezifischen und bankindividuellen Anforderungen erfüllen.

Der npX Banking Connector prüft Zahlungsdateien vor der Einreichung gegen hinterlegte Vorgaben und macht fehlende Pflichtangaben sichtbar, sofern diese Anforderungen im System entsprechend konfiguriert sind. Dadurch können Fehler erkannt werden, bevor eine Zahlungsdatei an die Bank übermittelt wird.

Weitere Informationen zum npX Banking Connector finden Sie hier: Banking-Connector

Wer internationale Bankverbindungen nutzt, sollte Regulatory Reporting deshalb bereits beim Aufbau seiner Zahlungsprozesse berücksichtigen. Eine neue Bankverbindung kann zusätzliche Format und Meldeanforderungen mit sich bringen.