ISO20022 Handbuch zur TKB-Implementation Handbuch für Kunden und Softwarepartner Version 1.0 März

Transkript

1 Version 1.0 März

2 Inhaltsverzeichnis 1 Änderungsnachweis 3 2 Hinweise zum Handbuch Bestimmungen und Grundlagen 3 3 Kontakt / Support 3 4 ISO20022 Harmonisierung des Schweizer Zahlungsverkehrs 3 5 Zielgruppe des Handbuchs 4 6 Testmöglichkeiten ISO Testplattform SIX 4 7 Einlieferzeiten und Annahmeschluss 4 8 Kommunikationskanäle Voraussetzungen 4 9 XML-Schema 5 10 AOS Additional Optional Services 5 11 Initiation «pain.001» pain.001 Struktur Unterstütze Zahlungsarten Inland Ausland Gruppierung von Zahlungen Lohn- und Kreditorenzahlungen Unterstützte Zahlungsarten Doppeleinlesekontrolle DropOnError Maximale Grösse von Zahlungsdateien Synchrone / asynchrone Verarbeitung Steuerung der Belastungsanzeige Batch-Booking Sammel- oder Einzelverbuchung Mögliche Kombination Batch-Booking und Steuerung der Belastungsanzeige Lohn- und Rentenzahlungen Priorität EndToEndID Validierung und Rückmeldungen «pain.002» 9 12 Kontoreporting camt 9 13 pain.001 Implementation und Validierung A-Level pain B-Level pain C-Level pain Version 1.0 März

3 1 Änderungsnachweis Version Datum Änderung Kapitel März 2018 Erste publizierte Version - 2 Hinweise zum Handbuch Dieses Handbuch beschreibt im Detail das gesamte E-Banking-Angebot der Thurgauer Kantonalbank (nachstehend TKB genannt) im neuen ISO Zahlungsverkehr. Das Handbuch befasst sich primär mit den Details zur elektronischen Schnittstellen zwischen Kunde und dem TKB E-Banking. Anregungen und Fragen können an folgende Adresse gerichtet werden: Channel Management Thurgauer Kantonalbank Bankplatz Weinfelden e-banking-news@tkb.ch 2.1 Bestimmungen und Grundlagen Die Implementation orientiert sich an den Empfehlungen des Schweizer ISO20022 Standards die Schweizer Empfehlungen bestehen aus den Dokumenten Schweizer Business Rules Swiss Usage Guide Schweizer Implementation Guidelines Die entsprechenden Dokumente sind unter abrufbar. TKB-spezifische Validierungen sind gekennzeichnet. 3 Kontakt / Support Für fachliche oder technische Fragen steht unser E-Business Beratungsteam zur Verfügung. Telefon: e-banking@tkb.ch 4 ISO20022 Harmonisierung des Schweizer Zahlungsverkehrs Der Schweizer Zahlungsverkehr wird in den nächsten Jahren auf der Basis des international anerkannten Standards ISO vereinheitlicht. Dabei werden die bis heute sehr verschiedenen Zahlungssysteme der Finanzinstitute zusammengeführt, alle bisherigen Formate sowie Verfahren abgelöst und die Einzahlungsscheine durch die neue QR-Rechnung ersetzt. Version 1.0 März

4 5 Zielgruppe des Handbuchs Das Handbuch ist relevant für Kunden, welche Zahlungsdateien aus einer Buchhaltungs- oder Zahlungssoftware direkt über das E-Banking oder über die Offline-Schnittstelle einliefern aber auch für Kunden, welche elektronische Konto- oder ESR-Daten in die Buchhaltungs- oder Zahlungssoftware einlesen. Das Handbuch richtet sich ebenfalls an die IT Verantwortlichen in den Unternehmen und an die Softwareunternehmen, die für Kunden Softwarepakete entwickeln (z.b. ERP Pakete, Zahlungssysteme). 6 Testmöglichkeiten Die TKB bietet Kunden sowie Softwarelieferanten an, pain.001-testzahlungsdateien zu prüfen eine eigene und öffentlich zugängliche Testplattform steht nicht zur Verfügung. Bei Bedarf werden für Softwarelieferanten zudem Testverträge zur eigenen Abwicklung über eine anonymisierte Umgebung zur Verfügung gestellt. Empfehlung: Bevor Sie Ihre Systeme produktiv auf die neuen ISO-Formate umstellen, empfiehlt die TKB, der Bank anonymisierte Testdateien zur Verfügung zu stellen. 6.1 ISO Testplattform SIX Der Finanzplatz Schweiz stellt für das Testen von ISO20022 Dateien eine bankunabhängige Testplattform zur Verfügung. Dieses zentrale Validierungsportal stützt sich auf die Empfehlungen der Schweizer Finanzindustrie für den Kunde-Bank-Datentausch. Hier kann vorwiegend die strukturelle Konformität der generierten XML- Meldungen überprüft werden. Link zur ISO Testplattform SIX: Hinweis: Allfällige bankspezifische Abweichungen werden dabei nicht berücksichtigt. 7 Einlieferzeiten und Annahmeschluss Die TKB empfiehlt bei Massenzahlungen, diese vorvalutiert einzuliefern. Zahlungen, welche gleichentags ausgeführt werden müssen, können bis spätestens 11:55 Uhr mit Ausführungstag «heute» eingeliefert resp. freigegeben werden. Nach 12:00 Uhr eingelieferte Zahlungen mit Ausführungsdatum «heute» werden am nächsten Bankwerktag ausgeführt. Das Ausführungsdatum darf am Lieferdatum maximal 365 Kalendertage in der Zukunft liegen 10 Kalendertage in der Vergangenheit liegen Hinweis: Das Ausführungsdatum bestimmt den Verarbeitungsbeginn des Zahlungsauftrags bei der TKB. Die TKB hat keinen Einfluss darauf, wann die Gutschrift effektiv auf dem Konto des Begünstigten erfolgt. 8 Kommunikationskanäle Die ISO20022 Meldungsformate können über folgende Kommunikationskanäle mit der Thurgauer Kantonalbank ausgetauscht werden: TKB E-Banking Offlineschnittstelle mittels Buchhaltungs- oder Zahlungssoftware TKB EBICS (voraussichtlich ab Q2 2018) Die TKB erstellt nach Einlieferung einer pain.001 Zahlungsdatei eine entsprechende Statusmeldung den pain.002. Im TKB E-Banking wird der Status der Zahlungsdatei sofort nach dem Hochladen in der Übersicht der Zahlungsdateien angezeigt. 8.1 Voraussetzungen Um die Kommunikationskanäle nutzen resp. ISO20022-Meldungen mit der TKB austauschen zu können, sind aktive E-Banking Verträge und/oder gültige Vereinbarungen notwendig. Version 1.0 März

5 9 XML-Schema Implementationsübersicht der XML-Schema XML-Meldung - Zahlungsverkehr pain.001 pain.002 XML-Meldung - Kontoreporting camt.052 camt.053 camt.054 / camt.054esr XML-Schema pain ch.02.xsd pain ch.02.xsd XML-Schema camt xsd camt xsd camt xsd camt xsd camt xsd camt xsd Die Versionen (02 / 04) können über das TKB E-Banking eingestellt werden. Aktueller Standard ist die Version 02. Kunden mit ausschliesslichem Offline-Zugang melden sich bei E-Banking Support für eine allfällige Umstellung auf Version 04. Empfehlung: Die TKB empfiehlt frühzeitig auf die Version 04 umzustellen. 10 AOS Additional Optional Services Aktuell werden keine AOS unterstützt. Werden AOS spezifische Werte im pain.001 mitgeliefert, werden diese soweit als möglich ignoriert. Ist eine Ignorierung nicht möglich, so wird die komplette Zahlungsdatei abgelehnt. 11 Initiation «pain.001» «pain» steht für «Initiation» und ist ein XML-basiertes Nachrichtenformat im ISO-Standard. Dieses Format kommt sowohl bei Überweisungen als auch bei Lastschriften zur Anwendung und löst mit der Harmonisierung des Schweizer Zahlungsverkehrs die bisherigen DTA-Zahlungsdateien ab. Somit ist es für Unternehmen unumgänglich auf das pain-format umzustellen pain.001 Struktur A-Level «Group Header» en zur Zahlungsdatei darf nur einmal pro File vorkommen B-Level en zur Belastungsseite muss mindestens einmal vorkommen und enthält C-Level. C-Level «Creditor Transfer» en zur Begünstigtenseite muss mindestens einmal pro B- Level vorkommen. Version 1.0 März

6 11.2 Unterstütze Zahlungsarten Inland Zahlungsart 1 ESR 2.1 ES 1-stufig 2.2 ES 2-stufig 3 Inland CHF/EUR 4 Inland Fremdwährung Zusatzinformation - Begünstigter Postkonto Method Begünstigter Bankkonto TRF / TRA - - Local Instrument CH01 CH02 CH03 Muss nicht geliefert werden Muss nicht geliefert werden Service Level Darf nicht SEPA sein Darf nicht SEPA sein Darf nicht SEPA sein Darf nicht SEPA sein Darf nicht SEPA sein Creditor Account (Begünstigter) ESR- Teilnehmernummer Postkonto IBAN oder Kontonummer IBAN oder Kontonummer IBAN oder Kontonummer Creditor Agent Darf nicht geliefert werden Darf nicht geliefert werden V1: IID (BC) V2: IID (BC) oder Postkontonummer der Bank V3: Postkontonummer der Bank und Name der Bank V1: IID (BC) V2: BIC Inland V1: BIC Inland V2: IID (BC) und Name inkl. Adresse der Bank V3: Name und Adresse der Bank Währung CHF / EUR CHF / EUR CHF / EUR CHF / EUR Alle ausser CHF / EUR Ausland Zahlungsart 5 SEPA 6 Ausland Method TRF / TRA Local Instrument Darf nicht geliefert werden Darf nicht geliefert werden Service Level SEPA Darf nicht SEPA sein Creditor Account (Begünstigter) IBAN IBAN oder Kontonummer Creditor Agent BIC V1: BIC International V2: Bankcode (ohne IID) und Name inkl. Adresse der Bank V3: Name und Adresse der Bank Währung EUR Alle Wichtig: Die Angaben zum Finanzinstitut werden nicht aus der IBAN interpretiert. Je nach Zahlung muss ein entsprechender Wert (BIC, IID) mitgegeben werden. Ist dieser nicht enthalten oder entspricht dieser nicht mit der IBAN, so wird die entsprechende Zahlung abgelehnt. Version 1.0 März

7 11.3 Gruppierung von Zahlungen Die Gruppierung von Aufträgen (=B-Level) innerhalb einer Zahlungsdatei (=A-Level) beeinflusst die effektive Buchung resp. den Inhalt des Kontoauszugs. Pro B-Level ist jeweils nur ein Ausführungsdatum und Belastungskonto möglich. Ebenfalls muss ein B-Level währungsrein (gleiche Währung) sein und dieselben Speseninstruktionen (ChargeBearer) beinhalten, sofern eine Sammelbuchung erfolgen soll. Die Speseninstruktionen gelten für den gesamten C-Level. Die TKB empfiehlt die Gruppierung von B-Leveln; denn nur so bleibt der direkte Bezug zwischen Auftrag (= B- Level) und Buchung im Kontoauszug bestehen Lohn- und Kreditorenzahlungen Falls Sie Lohn- und Kreditorenzahlungen in einer Zahlungsdatei übermitteln, sind Lohnzahlungen in separaten Aufträgen/B-Levels zu bilden. Damit stellen Sie die korrekte Steuerung der Anzeige sicher Unterstützte Zahlungsarten Die TKB unterstützt alle vorgesehenen Zahlungsarten, ausser Zahlungsanweisungen (Zahlungsart 7) und Bankcheck (Zahlungsart 8) Doppeleinlesekontrolle Die Doppeleinlesekontrolle wird aktuell lediglich auf Basis der «MessageId» durchgeführt. Dabei wird geprüft, ob mittels identischem Vertrag die gleiche «MessageId» innerhalb der letzten 90 Tage bereits eingeliefert wurde. Empfehlung: Prüfen Sie den effektiven Status der Zahlungsdatei jeweils im E-Banking. Treten beim Hochladen von Zahlungsdateien Probleme auf oder sind Sie unsicher, ob eine Zahlungsdatei effektiv verarbeitet wird, melden Sie sich beim E-Banking Support DropOnError Der DTA-spezifische Parameter «DropOnError» wird im ISO nicht unterstützt; dementsprechend werden auch gültige pain.001 Zahlungsdateien mit mitgegebenem «DropOnError» Wert abgelehnt Maximale Grösse von Zahlungsdateien Die maximale Anzahl an Transaktionen in einer XML-Zahlungsdatei ist gemäss ISO-Standard auf maximal 99'999 beschränkt. Hinweis: Eine bei der TKB eingelieferte Zahlungsdatei darf maximal 32'000 Transaktionen enthalten und die maximale Dateigrösse von 16 MB nicht überschreiten Synchrone / asynchrone Verarbeitung Aus Performance-Gründen stellt die TKB bei einer Zahlungsdatei mit mehr als 50 Transaktionen von einer synchronen auf eine asynchrone Verarbeitung der Zahlungsdatei um. Beim Hochladen einer Zahlungsdatei im TKB E-Banking wird bei der asynchronen Verarbeitung keine Bestätigung angezeigt. Die Zahlungsdatei erhält dabei vorerst den Status "in Arbeit". Eine Verarbeitung von grösseren Zahlungsdateien kann einige Minuten dauern. Der Status der Zahlungsdatei muss dabei in der Übersicht der Zahlungsdateien überprüft werden Steuerung der Belastungsanzeige Folgende Elemente zur Steuerung der Belastungsanzeige stehen zur Verfügung: NOA = Keine Anzeige SIA = Einzelanzeige CND = Sammelanzeige ohne Details CWD = Sammelanzeige mit Details «leer» = Vordefinierte Regelung der TKB (siehe auch Kapitel "Mögliche Kombination von Batch- Booking und Steuerung der Belastungsanzeige") Version 1.0 März

8 11.11 Batch-Booking Sammel- oder Einzelverbuchung Folgende Elemente zur Steuerung des Batch-Booking stehen zur Verfügung: TRUE = Zahlungen werden als Sammelbuchung zusammengefasst und verbucht FALSE = Zahlungen werden als Einzelzahlungen verbucht «leer» = Wird kein Wert mitgeliefert, wird dies als «TRUE» interpretiert Mögliche Kombination Batch-Booking und Steuerung der Belastungsanzeige Batch-Booking TRUE (oder leer) FALSE Lohnzahlung JA NEIN JA NEIN Leer CND CWD NOA DbtrAcct.Tp.Prtry im pain.001 NOA NOA NOA SIA RJCT SIA CWD CWD RJCT CND CND RJCT Kombinationen werden abgelehnt / Kombinationen wenn Prtry «Leer»; durch TKB definiert / gültige Kombinationen; werden so verarbeitet Beispiel: Sind in einer Zahlungsdatei zwei B-Level mit jeweils 50 C-Level enthalten und weisen die jeweiligen Instruktionen auf dem B-Level gültige Instruktionen (bspw. BatchBooking «TRUE» oder «Leer»), so erfolgen zwei Sammelbuchungen mit je 50 Transaktionen. Ist hingegen BatchBooking auf beiden B-Level auf «FALSE» gesetzt, so erfolgen 100 Einzelbuchungen. Hinweis: Produktspezifische Anzeigearten können durch Mitgabe der Werte nicht übersteuert werden. Sofern diese aber korrekt sind, werden diese ignoriert. Kombinationen welche nicht erlaubt sind führen zur Ablehnung der Zahlungsdatei Lohn- und Rentenzahlungen Lohn- resp. Rentenzahlungen müssen sofern diese als solche behandelt werden sollen im B-Level mit SALA oder PENS gekennzeichnet sein. Eine Kennzeichnung auf C-Level wird ignoriert. Diese Kennzeichnung steuert lediglich den sfluss; bspw. wird die Einsicht von Lohnzahlungen ohne entsprechende Berechtigung verhindert (bspw. mit einem anderen E-Banking Vertrag). Für die Art der Verbuchung resp. der sgehalt der Anzeige, werden andere Elemente benötigt Priorität Die TKB unterscheidet nicht in der Dringlichkeit der Verarbeitung von Zahlungsaufträgen sämtliche Zahlungen werden prioritär behandelt EndToEndID Die End-to-End-ID wird durch den Auftraggeber bzw. dessen Zahlungssoftware vergeben. Die End-to-End-ID wird über die gesamte Verarbeitungskette unverändert weitergeleitet. Diese ID dient Ihnen zur Identifikation der Zahlung im Kontoauszug (camt) sowie, um im Falle von Rückleitungen den Ursprungsauftrag in Ihrem Buchhaltungssystem zuordnen zu können. Die TKB empfiehlt, pro C-Level innerhalb einer Zahlungsdatei eine eindeutige Identifikationsnummer zu vergeben. Version 1.0 März

9 11.16 Validierung und Rückmeldungen «pain.002» Die XML-Meldung «Customer Status Report» (pain.002) wird zur des Kunden über den Status von übermittelten Überweisungsaufträgen «pain.001» durch das Finanzinstitut verwendet. Sie wird auf der Basis des ISO XML-Schemas «pain » eingesetzt. Folgende Status einer Zahlungsdatei sind möglich und werden entsprechend in einer pain.002 bestätigt: ACCP Accepted Customer Profile Datei ist korrekt und wird verarbeitet ACWC Accepted with Change Datei wurde korrigiert und wird verarbeitet, allfällige fehlerhafte Zahlungen werden dabei gelöscht PART Partially Accepted; korrekte Teile der Datei werden verarbeitet RJCT Rejected; Datei wird nicht verarbeitet (ACTC Accepted Technical Validation) Wird von der TKB nicht unterstützt) Hinweis: Zahlungsdateien mit strukturellen Fehlern können inhaltlich nicht validiert werden. Diese werden ohne spezifischen Fehlerhinweis abgelehnt. Die Rückmeldungen (pain.002) werden direkt in der entsprechenden Buchhaltungs- oder Zahlungssoftware implementiert und i.d.r. unmittelbar nach dem Hochladen einer Zahlungsdatei heruntergeladen. Sofern die Zahlungsdateien manuell im TKB E-Banking hochgeladen werden, steht die Rückmeldung ebenfalls zur Verfügung. Die Rückmeldung befindet sich in den Details zur hochgeladenen Zahlungsdatei (Menu «Zahlungen» - «Zahlungsdatei DTA / XML»). In der Lasche «Zusammenfassung» befindet sich ein «Exportieren»- Button dort kann die Rückmeldung («Protokoll XML pain.002 (ISO20022) generieren») heruntergeladen werden. Die TKB empfiehlt, in jedem Fall die Rückmeldung (pain.002) zu prüfen. 12 Kontoreporting camt Angebot der TKB für das Kontoreporting im ISO-Format. camt.052 camt.053 camt.054 camt.054esr Intraday Kontoauszug Kontoauszug Kontoauszug mit Sammelbuchungs-Auflösung Detailinformationen zu ESR / LSV Gutschriften Mehrmalige Generierung / Auslieferung mit jeweils zusätzlichen Buchungen möglich. Enthält auch pendente Buchungen. Entspricht heutigem MT940 Tagesend-Auszug. Enthält nur gebuchte Buchungen mit Vortages-End-Saldo. Auflösung von Zahlungsaufträgen, ESR- oder LSV-Eingängen. Ohne Saldo Auflösung von ESR / LSV Gutschriften Hinweis: Die camt-meldungen können mit dem bisherigen Reportingangebot (MT940 etc.) kombiniert werden. Version 1.0 März

10 13 pain.001 Implementation und Validierung 13.1 A-Level pain.001 XML-Element XML-Tag Inhalt Group Header <GrpHdr> Angaben zur gesamten Zahlungsdatei A-Level kann nur einmal innerhalb einer Zahlungsdatei vorkommen. Group Header + Message <MsgId> Eindeutige Identifikation der Meldung Doppelverarbeitungskontrolle Die MsgId darf während 90 Tagen nur einmal vorkommen (sofern Original-File nicht gelöscht ist). Für dieses Element ist nur der SWIFT- Zeichensatz zugelassen. Group Header +Creation Date Time <CreDtTm> Datum und Uhrzeit der Dateierstellung Empfehlung: Soll dem effektiven Erstellungsdatum/- zeitpunkt entsprechen. Group Header +Number Of s NbOfTxs Total der eingelieferten Transaktionen (in B- resp. C-Level). Eine Zahlungsdatei darf bei der TKB maximal 30'000 Transaktionen beinhalten. Group Header +Control Sum CtrlSum Kontrollsumme aller eingelieferten Transaktionen Empfehlung: Kontrollsumme sollte im A-Level geliefert werden. Group Header +Initiating Party InitgPty en zum Einlieferer Mindestens ein Subelement (Nm / Id / OridId / Othr / PrvtId / CtctDtls) muss mitgeliefert werden. Wichtig: FwdgAgt wird nicht unterstützt Transaktionen werden abgelehnt B-Level pain.001 XML-Element XML-Tag Inhalt <PmtInf> Angaben zum B-Level B-Level können mehrfach innerhalb einer Zahlungsdatei vorkommen. + PmtInfId Eindeutige Identifikation des B-Level Der Identifikation muss innerhalb der gesamten Meldung eindeutig sein, diese wird im Status Report «pain.002» als Referenz verwendet. Für dieses Element ist nur der SWIFT- Zeichensatz zugelassen. +Batch Booking BtchBookg Steuerung der Verbuchungsart (Sammeloder Einzelbuchung) Empfehlung: TRUE wird empfohlen; hierbei werden sämtliche Transaktionen innerhalb eines B-Level als Sammelbuchung verbucht. Bei TRUE müssen alle Transaktionen zudem dieselbe Währung und Spesenoptionen aufweisen. Bei FALSE erfolgt eine Einzelbuchung pro Wird kein Wert mitgegeben, wird dies als TRUE interpretiert. +Number Of s NbOfTxs Total der eingelieferten Transaktionen (innerhalb B-Level). Wird nicht validiert - Die Prüfung erfolgt mit dem entsprechenden Element des A-Levels. +Control Sum CtrlSum Kontrollsumme aller eingelieferten Transaktionen (innerhalb B- Level) Wird nicht validiert - Die Prüfung erfolgt mit dem entsprechenden Element des A-Levels. Version 1.0 März

11 XML-Element XML-Tag Inhalt + Type PmtTpInf Nähere Angaben zum Zahlungsauftrag Sub-Elemente dürfen nicht gleichzeitig auf Ebene Zahlungsauftrag (B-Level) und auf Ebene Einzelzahlung (C- Level) verwendet werden. + Type ++Instruction Priority InstrPrty Priorität des Zahlungsauftrags Wird nicht validiert. Die TKB verarbeitet Aufträge mit «NORM» oder «HIGH» mit identischer Priorität. + Type ++Service Level SvcLvl Weitere Angaben zum Zahlungsauftrag Hinweis: Subelement Cd muss geliefert werden. Wichtig: Prtry wird nicht unterstützt Transaktionen werden abgelehnt. + Type ++Local Instrument +++Code Cd Verwendung von ISO festgelegten Codes (External Code List) Hinweis: Nur «SEPA» und «URGP» sind erlaubt. Bei anderen Elementen wie «PRPT», «SDVA» werden die Transaktionen abgelehnt. + Type ++Local Instrument LclInstrm Zahlungsart Hinweis: Bei Verwendung dieses Elementes darf nur Subelemt Cd verwendet werden. Wichtig: Prtry wird nicht unterstützt Transaktionen werden abgelehnt. + Type ++Local Instrument +++Code Cd Verwendung von ISO festgelegten Codes (External Code List) Hinweis: Nur CH01, CH02 oder CH03 ist erlaubt. + Type ++Category Purpose CtgyPurp Angaben zum Zweck der Zahlung + Type ++Category Purpose +++Code Cd Verwendung von ISO festgelegten Codes (External Code List) Element muss verwendet werden, wenn Category Purpose verwendet wird. «SALA» = Salärzahlung «PENS» = Rentenzahlung Wichtig: Transaktionen mit anderen Werten oder ohne benötigte Rechte (Salär-Flag) werden abgelehnt. +Requested Execution Date ReqdExctnDt Ausführungsdatum des Zahlungsauftrages Wenn das gewünschte Ausführungsdatum mehr als 10 Tage in der Vergangenheit oder mehr als 365 Tage in der Zukunft liegt, wird die Meldung zurückgewiesen. Zahlungsaufträge mit gewünschtem Ausführungsdatum in der Vergangenheit werden automatisch auf das nächstmögliche Ausführungsdatum valutiert. Version 1.0 März

12 XML-Element XML-Tag Inhalt +Debtor Dbtr en zum Auftraggeber der Zahlungsdatei Das Element ist gemäss ISO Vorgaben obligatorisch (mindestens Name). Die TKB wird aber bei der Zahlungsausführung immer den identifizierten Kontoinhaber als Auftraggeber mitgeben. Hinweis: Andere Elemente (Adresse) werden ignoriert. +Debtor Account DbtrAcct Angaben zum Belastungskonto Wichtig: Das Belastungskontos muss als IBAN geliefert werden. +Debtor Account ++ Id Angaben zum Belastungskonto +Debtor Account IBAN IBAN Angaben zum Belastungskonto Wichtig: Das Belastungskontos muss als IBAN geliefert werden. Andere Elemente wie «OTHR» werden abgelehnt. +Debtor Account ++Type Tp Steuerung der Belastungsanzeige Hinweis: Bei Verwendung dieses Elementes darf nur «Proprietary» verwendet werden. Wichtig: Transaktionen mit «Cd» werden abgelehnt. +Debtor Account ++Type +++Proprietary Prtry Steuerung der Belastungsanzeige Hinweis: Kann zur Anzeigesteuerung verwendet werden. Folgende Ausprägungen stehen zur Verfügung: «NOA» = keine Belastungsanzeige «CND» = Sammelanzeige ohne Details «CWD» = Sammelanzeige mit Details «SIA» = Einzelanzeige Wichtig: Bei Batch Booking «TRUE» ist nur «NOA», «CND» oder «CWD» zugelassen; bei Batch Booking «FALSE» ist nur «NOA» oder «SIA» zugelassen. Bei «SALA» oder «PENS» erfolgt aus Vertraulichkeitsgründen generell immer eine Sammelbelastung mit Sammelanzeige ohne Details. Sofern Zulässig, verarbeitet die TKB die Aufträge gemäss mitgelieferten Werten. Bei nicht zulässigen Elementen werden die Transaktionen abgelehnt. +Debtor Account ++Currency Ccy Währung des Belastungskonto Hinweis: Dieses Element wird ignoriert. +Debtor Agent DbtrAgt Angaben zur Bank des Auftraggebers Identifikation der Thurgauer Kantonalbank +Debtor Agent ++Financial Institution FinInstnId Angaben zur Bank des Auftraggebers Hinweis: Es darf nur die Variante «BIC» oder die Variante «BC-Nummer» verwendet werden. Die gleichzeitige Verwendung der Elemente BIC» und «ClrSysMmbId» ist nicht erlaubt. Version 1.0 März

13 XML-Element XML-Tag Inhalt +Debtor Agent ++Financial Institution +++BIC BIC BIC der TKB Bei Verwendung der Variante «BIC» ist die BIC der TKB «KBTGCH22» einzusetzen. Wichtig: Andere oder falsche BIC führen zur Ablehnung der Transaktionen. +Debtor Agent ++Financial Institution +++Clearing System Member ClrSysMmbId Identifikation des Clearing Systems zu Feld Member Hinweis: Darf nur mitgegeben werden, wenn «BIC» nicht verwendet wird. Wichtig: Nur Code «CHBCC» ist erlaubt. Element «Prtry» führt zur Ablehnung der Transaktionen. +Debtor Agent ++Financial Institution +++Clearing System Member ++++Member MmbId BC-Nummer der Bank des Auftraggebers Hinweis: Bei Verwendung der Variante «BC-Nummer» ist die BC-Nummer der TKB 784 einzusetzen. Wichtig: Andere oder falsche BC führen zur Ablehnung der Transaktionen. +Ultimate Debtor UltmtDbtr Angabe des für alle Einzelzahlungen (zum B- Level gehörende C-Level) gültigen ursprünglichen Auftraggebers Hinweis: Alle Angaben zum «UltmtDbtr» werden ignoriert. +Charge Bearer ChrgBr Angabe der Spesen- / Gebührenoptionen Hinweis: «SHAR» oder «SLEV» = die Spesen der Auftraggeberbank gehen zulasten des Auftraggebers, die Spesen der Bank des Begünstigten gehen zulasten des Begünstigten. «DEBT» = alle Spesen zulasten des Auftraggebers «CRED» = alle Spesen zulasten des Begünstigten Wenn keine Angaben gemacht werden, wendet TKB den Wert «SHAR» an. Wichtig: Die Verwendung dieses Elementes ist nur auf B- oder C-Level eines Zahlungsauftrags erlaubt. Zahlungsaufträge mit Charge Bearer auf B-Level und C- Level werden abgelehnt. Ebenfalls dürfen keine Spesenoptionen innerhalb eines B-Level vermischt werden. +Charges Account ChrgsAcct Belastungskonto der Spesen / Gebühren Hinweis: Das Element wird ignoriert. Wichtig: Sofern mitgeliefert, muss es im IBAN-Format sein, ansonsten werden die Transaktionen abgelehnt. Version 1.0 März

14 13.3 C-Level pain.001 XML-Element XML-Tag Inhalt Informa-tion CdtTrfTxInf Angaben zum C-Level C-Level können mehrfach innerhalb eines B-Levels vorkommen. + PmtId Identifikation der Einzelzahlung + ++Instruction InstrId Eindeutige Identifikation der Einzelzahlung Hinweis: Zulässig ist nur der SWIFT Zeichensatz Wichtig: Bei Duplikaten innerhalb des B-Level erfolgt eine Ablehnung der Transaktionen. + ++End To End EndToEndId Durchgängige Referenz der Einzelzahlung, die auch an den Begünstigten weitergeleitet wird. Hinweis: Zulässig ist nur der SWIFT Zeichensatz Wichtig: Es wird empfohlen, auch für die «EndToEndId» pro Transaktion eine eindeutige Referenz zu verwenden. Es erfolgt aber keine Duplikatsprüfung. + Type PmtTpInf Weitere Angaben zur Einzelzahlung Hinweis: Das Element darf nur auf B- oder C-Level, nicht aber auf beiden Level verwendet werden. + Type ++Instruction Priority InstrPrty Priorität der Einzelzahlung Hinweis: Das Element wird ignoriert. + Type ++Service Level SvcLvl Weitere Angaben zur Einzelzahlung Wichtig: Bei Verwendung dieses Elementes darf nur «Code» mitgegeben werden. «Proprietary» führt zur Ablehnung der Transaktionen. Version 1.0 März

15 XML-Element XML-Tag Inhalt + Type ++Service Level +++Code Cd Verwendung von ISO festgelegten Codes (External Code List) Hinweis: Nur «SEPA» = SEPA-Zahlung ist zulässig. Andere in der External Code List enthaltene Werte werden von TKB bei Verwendung auf Ebene Einzelzahlung (C-Level) ignoriert. Falls die Voraussetzung zur Abwicklung einer Einzelzahlung als SEPA-Zahlungen erfüllt sind, führt TKB diese Einzelzahlung automatisch als SEPA Zahlung aus, auch wenn der Code «SEPA» nicht gesetzt ist. Die Priorität der Zahlungsausführung («URGP») kann nur auf B-Level für den ganzen Zahlungsauftrag mitgegeben werden. + Type ++Service Level +++Proprietary + Type ++Local Instrument Prtry Proprietäre Codes Wichtig: Elemente mit «Prtry» führen zur Ablehnung der LclInstrm Art der Zahlung Wichtig: Bei Verwendung dieses Elementes darf nur «Proprietary» mitgegeben werden. «Code» führt zur Ablehnung der Transaktionen. + Type ++Local Instrument +++Code Cd Verwendung von ISO festgelegten Codes (External Code List) Wichtig: Elemente mit «Cd» führen zur Ablehnung der + Type ++Local Instrument +++Proprietary Prtry Proprietäre Codes (z.b. landesspezifische Codes) Hinweis: Nur «CH01», «CH02» oder «CH03» sind erlaubt. + Type ++Category Purpose CtgyPurp Angaben zum Zweck der Zahlung Hinweis: Sämtliche Elemente zum «CtgyPurp» werden ignoriert. +Amount Amt Zahlungsbetrag der Einzelzahlung Hinweis: Muss als «InstdAmt» mitgegeben werden. Wichtig: «EqvtAmt» mit «XchgRateInf» führen zur Ablehnung der Version 1.0 März

16 XML-Element XML-Tag Inhalt +Amount ++Instructed Amount InstdAmt Zahlungsbetrag der Einzelzahlung inkl. Angabe der Währung Hinweis: Betrag muss zwischen 0.01 und liegen. Die Zahlungswährung muss bei TKB zugelassen sein. Die Anzahl Stellen nach dem Komma darf nicht grösser sein als für die Zahlungswährung zugelassen. Bei Local Instrument/Proprietary «CH01», «CH02», «CH03» muss die Währung «CHF» oder «EUR» sein. Bei «SEPA» muss die Währung «EUR» sein. Wichtig: Abweichungen führen zur Ablehnung der +Charge Bearer ChrgBr Angabe der Spesen- / Gebührenoptionen Hinweis: «SHAR» oder «SLEV» = die Spesen der Auftraggeberbank gehen zulasten des Auftraggebers, die Spesen der Bank des Begünstigten gehen zulasten des Begünstigten. «DEBT» = alle Spesen zulasten des Auftraggebers «CRED» = alle Spesen zulasten des Begünstigten Wenn keine Angaben gemacht werden, wendet TKB den Wert «SHAR» an. Wichtig: Die Verwendung dieses Elementes ist nur auf B- oder C-Level eines Zahlungsauftrags erlaubt. Zahlungsaufträge mit Charge Bearer auf B-Level und C- Level werden abgelehnt. +Cheque Instruction ChqInstr Instruktionen zur Ausstellung eines Bankchecks Wichtig: Verwendung führt zur Ablehnung der +Ultimate Debtor UltmtDbtr Angabe des für diese Einzelzahlung (C-Level) gültigen ursprünglichen Auf-traggebers Hinweis: Alle Angaben zum «UltmtDbtr» werden ignoriert. +Intermediary Agent 1 +Creditor Agent IntrmyAgt1 Zwischenbank Wichtig: Verwendung führt zur Ablehnung der CdtrAgt Bank des Begünstigten Hinweis: Bei Verwendung von «CH01» oder «CH02» nicht zugelassen. Bei «CH03» oder Nichtverwendung von Local Instrument/Proprietary ist die Angabe einer Bank des Begünstigten (Creditor Agent) obligatorisch. Die gleichzeitige Verwendung von strukturierten unstrukturierten Adresselementen oder mehrerer Financial Institution s ist nicht zugelassen. Wichtig: Die Verwendung von «Address Type», «Department» oder «Sub Department» führt zur Ablehnung der Version 1.0 März

17 XML-Element XML-Tag Inhalt +Creditor Cdtr Begünstigter der Einzelzahlung Hinweis: Ausser bei «CH01» muss das Element zwingend vorhanden sein. Zur Vermeidung von Rückfragen wird empfohlen, möglichst vollständige Angaben zum Begünstigten zu machen. Die gleichzeitige Verwendung von strukturierten und unstrukturierten Adresselementen ist nicht zugelassen. Wichtig: Die Verwendung von «Address Type», «Department» oder «Sub Department» führt zur Ablehnung der +Creditor Account CdtrAcct Kontonummer des Begünstigten +Creditor Account ++ Id Identifikation der Kontonummer des Begünstigten Empfehlung: Wenn immer möglich soll IBAN verwendet werden. +Creditor Account IBAN IBAN Kontonummer des Begünstigten im IBAN Format Zur Angabe der Kontonummer des Begünstigten ist die Verwendung des IBAN-Formats empfohlen. Die IBAN enthält eine Prüfziffer, anhand derer die Korrektheit der Kontonummer überprüft werden kann. Bei Angabe einer IBAN als Konto des Begünstigten und Angabe der BIC als Bank des Begünstigten müssen die Ländercodes in beiden Elementen zwingend übereinstimmen. Wichtig: Wenn «IBAN» verwendet wird, darf «Other» nicht vorkommen. +Creditor Account Other Othr Kontonummer des Begünstigten in anderem Format (nicht IBAN) +Creditor Account Other ++++ Id Kontonummer des Begünstigten in anderem Format (nicht IBAN) Hinweis: Muss mitgegeben werden, wenn «Other» verwendet wird. +Ultimate Creditor UlmtCdtr Endbegünstigter der Einzelzahlung Wichtig: Verwendung führt zur Ablehnung der +Instruction for Creditor Agent InstrForCdtrAgt Instruktion an die Bank des Begünstigten Wichtig: Verwendung führt zur Ablehnung der +Instruction for Debtor Agent InstrForDbtrAgt Instruktion an die Bank des Auftraggebers Wichtig: Verwendung führt zur Ablehnung der +Purpose Purp Weitere Angaben zur Einzelzahlung Wichtig: Verwendung führt zur Ablehnung der Version 1.0 März

18 XML-Element XML-Tag Inhalt +Regulatory Reporting RgltryRptg Angaben für die regulatorischen Meldepflichten Wichtig: Verwendung führt zur Ablehnung der RmtInf Mitteilungen an den Begünstigten der Einzelzahlung Hinweis: Muss zwingend ein Element «Ustrd» oder «Strd» mitgeben. ++Unstructured Ustrd Unstrukturierte Mitteilungen an den Begünstigten Hinweis: Element darf nur einmal vorhanden sein und maximal 140 Zeichen betragen. ++Structured Strd Strukturierte Mitteilungen an den Begünstigten Hinweis: Element darf nur einmal vorhanden sein. ++Structured +++Referred Document RfrdDocInf Wichtig: Verwendung führt zur Ablehnung der ++Structured +++Referred Document Amount RfrdDocAmt Wichtig: Verwendung führt zur Ablehnung der ++Structured +++Creditor Reference CdtrRefInf Wichtig: Darf nur «Code» mitgeben, «Proprietary» führt zur Ablehnung der Version 1.0 März

19 XML-Element XML-Tag Inhalt ++Structured +++Creditor Reference ++++Type +++++Code or Proprietary Code Cd Hinweis: Element muss bei «SEPA» vorhanden sein, wenn Creditor Reference vorhanden ist. In diesem Falle ist nur Code «SCOR» erlaubt. ++Structured +++Creditor Reference ++++Reference ++Structured +++Invoicer ++Structured +++Invoicee ++Structured +++Additional Remittance Ref ESR Referenznummer Hinweis: Element muss bei «CH01» verwendet werden und die ESR Referenznummer beinhalten. Invcr Rechnungssteller Wichtig: Verwendung führt zur Ablehnung der Invcee Rechnungsempfänger Wichtig: Verwendung führt zur Ablehnung der AddtlRmtInf Zusatzinformationen Wichtig: Verwendung führt zur Ablehnung der Version 1.0 März