harmonisierung zahlungsverkehr schweiz - topal solutions ag
TRANSCRIPT
17. September 2015
Hanni Halter
Harmonisierung ZahlungsverkehrSchweiz
Product Manager Banking Products, Card and Payment Solutions
Payment Initiation pain.001 und Payment Status Report pain.002
Breakout Session Überweisungen
Jürgen WintermantelProduct Manager Products, Services & Directbanking
1
Inhaltsverzeichnis
Section 1 ISO 20022 Verwendung und Nutzen 4Section 2 Das Überweisungsverfahren pain.001 7Section 3 Payment Status Report pain.002 17Section 4 Ausblick 24Section 5 Appendix 26
2
Vorstellung der Moderatoren
Hanni Halter UBS Switzerland AG – Banking Products
Product Manager Payment Products
• Projekt UBS Harmonization ISO Payments
• Einsatzgebiete
– SEPA Credit Transfer
– Schweizer Überweisungsverfahren
– Payment Status Report
– CtB-Projekte in UBS Payment Solutions
Visitenkarte
Vorstellung der Moderatoren
Jürgen WintermantelZürcher Kantonalbank –Products, Services & Directbanking
Produktmanager Zahlungsverkehr Projekte ZKB Migration ZV CH ZKB Pricing & Billing LEON
Einsatzgebiete SEPA Credit Transfer (pain.001) Payment Status Report (pain.002) Cash Management Meldungen (camt) eBanking Zahlungen E-Rechnung weitere
Jürgen WintermantelProducts, Services & DirectbankingProduktmanager ZahlungsverkehrMitglied des Kaders
Neue Hard 9, ZürichTelefon 044 292 23 40Fax 044292 21 [email protected]
BriefadressePostfach, 8010 Zürich
ISO 20022 Verwendung und NutzenSection 1
5
Verwendung ISO 20022 Credit Transfer Meldungsfluss
Finanzinstitut A Finanzinstitut B
Status / Avisierung /Kontoauszug
Rechnungsstellung(mit neuem ES)
pain.001
Zahlungs-auftrag
pain.002
camt.052
camt.053
camt.054
Avisierung /Kontoauszug
camt.052
camt.053
camt.054
Interbank-zahlung
Clearing
Interbank-zahlung
pacs.008 pacs.008
Legende: Geldfluss ISO-Meldungsfluss Belegfluss
Empfängerder Zahlung
Auftraggeber der Zahlung
Für EU/EWR Länder Verwendung für nationale und crossborder SEPA Zahlungen Pflicht (EU Verordnung),in der Schweiz Anwendung für alle nationale und internationalen Zahlungen möglich
6
Nutzenaspekte ISO 20022Aufgrund der diversen Vorteile unterstützen u.a. EPC (SEPA) und SWIFT die Verwendung von ISO 20022
Thema Beschreibung
• Einfachere Kommunikation mit Supportstellen, unabhängig von Software-Hersteller oder Finanzinstitut
• Automatisierung bei Zahlungspflichtigen und Zahlungsempfängern
• Verwendung einheitliche Meldungsstandards
• Gleiche Behandlung durch alle Finanzinstitute erhöht die Flexibilität bei der Zusammenarbeit mit mehreren Finanzinstituten
• Weniger komplexe Entwicklung, Wartung und Unterhalt seitens der Software-Partner
• Allfällige Erweiterungen mit weniger Komplexität aufgrund Verwendung des XML-Standards
Einheitliche Validierung
Einheitliche Status und Fehlercodes
Durchgängige Kundenreferenzen
Weniger Verarbeitungsfehler
Einheitliche Meldungstypen
Flexibilität
Quelle: Schweizer Business Rules
Vorteile für Kunden Vorteile Software-Partner
Das Überweisungsverfahren pain.001Section 2
Das Überweisungsverfahren mit «pain.001»
BankKunden Kunden
Software
Handlungsbedarf: Umstellung auf ISO 20022 Meldungsstandard Anpassung IBAN (Obligatorium ab 2020) Prozesse optimieren (effizientes Cash Management)
Bank
Bestehende Überweisungsverfahren
Neues Überweisungsverfahren im ISO 20022 Standard
Kunden KundenSoftware
pain.001: Zahlungsauftrag
pain.002: Payment Status Report
camt.xxx: Cash Management
DTA und/oder EZAG
Belastungsanzeige, Kontoauszug (pdf; physisch, MT940, MT942)
Customer Credit Transfer Initiation «pain.001»
Generell
Geltungs-bereich
Geschäftsfälle/Zahlungsarten
Elektronische Beauftragung von Überweisungsaufträgen
Basis ist das ISO-20022-XML-Schema «pain.001.001.03»
Gültig für alle heutigen Zahlungsarten in der Schweiz (national, grenzüberschreitend, SEPA usw.)
Inland Oranger ES (ESR) in CHF & EUR Roter ES in CHF & EUR Bank- oder Postzahlung in CHF & EUR Bank- oder Postzahlung in FW Ausland SEPA-Überweisung Ausland, alle WährungenZahlungen ohne Finanzinstitut im In- und Ausland Zahlungsanweisung Inland in CHF Bankcheck/Postcash im In- und Ausland
alle Währungen
Prüfung der Zahlungsart Identifizierung anhand
Schlüsselelemente (Bsp.: Payment Method)
Validierung erfolgt gegen die Vorgaben zu dieser Zahlungsart
Beispiel: Bei Zahlungsart 1 (ESR) wird geprüft, ob das Element «Creditor Account» eine ESR-Teilnehmernummer enthält und die Elemente zu «Creditor Agent» nicht vorhanden sind.
Kernelemente des «pain.001»
Angaben über den Zahlungspflichtigen: – Name/Vorname, Wohnsitz des Zahlungspflichtigen – Kontonummer des Zahlungspflichtigen – Finanzinstitut des Zahlungspflichtigen
Angaben über den Zahlungsempfänger: – Name/Vorname, Wohnsitz des Zahlungsempfängers – Kontonummer des Zahlungsempfängers – Finanzinstitut des Zahlungsempfängers
Angaben zur Überweisung: – Vergütungsbetrag – Vergütungswährung – Ausführungsdatum – Referenznummer, Mitteilung an den Zahlungsempfänger
Quelle: Schweizer Business Rules
Ausserdem …..
… sind abhängig von der Zahlungsart einzelne dieser Informationen
obligatorisch (z.B. Ausführungsdatum, End-to-End ID) fakultativ (z.B. strukturierte/unstrukturierte Adresse) ungültige Kombinationen (z.B. B- und C-Level Elemente wie Payment Method und
Referenzen)
Einzelne Angaben müssen je nach Zahlungsart eine bestimmte Ausprägung aufweisen, z.B. Kontonummer als IBAN.
Zusätzlich enthalten ISO-20022-Überweisungsmeldungen verschiedene Kontroll- oder Steuerungselemente wie …
Meldungsreferenz & Erstellungszeitpunkt Anzahl Transaktionen in der Meldung & Prüfsumme Meldungsabsender Zahlungsmethode & Zahlungsart Buchungs- und Anzeigeninstruktionen etc.
die nicht direkt mit der Überweisung etwas zu tun haben.
Quelle: Schweizer Business Rules
Meldungsstruktur und Inhalte des «pain.001»
A-Level: Meldungsebene, «Group Header»Elemente sind für die gesamte XML-Meldung gültig. Dieser Block kommt einmal vor.
B-Level: Zahlungsgruppenebene, «Payment Information»Enthält Informationen zum …. Zahlungspflichtigen Schlüsselelemente wie Zahlungsart (Payment Method) oder das gewünschte Ausführungsdatum (Requested Execution Date),
welche für alle Transaktionen (C-Level) dieses B-Levels gelten.
Dieser Block kommt mindestens einmal vor und enthält in der Regel mehrere C-Level.
C-Level: Transaktionsebene, «Credit Transfer Transaction Information».Enthält alle Angaben zum … Zahlungsempfänger Weitere Informationen zur Transaktion
(Übermittlungsinformationen, Zahlungszweck usw.)
Dieser Block kommt mindestens einmal pro B-Level vor und enthält allezum B-Level zugehörigen C-Level (Transaktionen).
Das neue Format bietet zusätzliche Möglichkeiten
Berücksichtigung der Bedürfnisse von Kunden sowie Banken
Zusätzliche Namensfelder für Dritt-Beteiligte (Ultimate Creditor/Debtor)
Beispiel: Ultimate Debtor (<UltmtDbtr>) Vom Kontoinhaber abweichender Auftraggeber (Kontoinhaber ist z.B. die Tochter einer AG; die Zahlung wird
von der Inhouse-Bank (= Auftraggeber) ausgeführt, aber ‚on behalf of‘ Tochter)
Dient unter anderem zur eindeutigen Identifizierung des richtigen Debitors von Zahlungseingängen bei einer Payment Factory
Zusätzliche Referenzierungsmöglichkeiten Beispiel: End To End Identification (<EndToEndID>) Zur eindeutigen, auftraggeberseitigen Identifizierung der Transaktion
Wird im gesamten Überweisungsprozess unverändert bis zum Empfänger weitergeleitet (Kontoauszug)
Zusätzliche Zahlungsgründe (Purpose Codes)
Beispiel: Purpose (<Purp>) Für die eindeutige Kennzeichnung der Überweisungsart
SALA für Löhne bzw. Gehälter, PENS für Renten, GOVT, SSBE, BENE für die Zahlungen öffentlicher Kassen, etc.
Payment Status Report pain.002Section 3
15
Payment Status Report pain.002Ausprägungen
Definition
• Information des Auftraggebers über den Status einer Instruktion – positiv oder negativ, also Annahme oder Ablehnung
• Die Instruktion (Zahlungsauftrag) kann eine Banküberweisung oder eine Lastschrift sein
• Der Status bezieht sich jeweils auf bestimmte Elementen und Referenzen aus der ursprünglichen Instruktion.
• Die Schweizer Empfehlungen sehen sowohl positive (Akzeptanz) wie auch negative Status (Ablehnung, Zurückweisung) einer Instruktion vor.
• SEPA Regelwerk sieht nur einen negativen Status (Ablehnung, Zurückweisung einer Instruktion vor)
• Im weiteren sind auch Informationen über hängige (Instruktionen in Bearbeitung) möglich
• Der Payment Status Report kann für inländische und grenzüberschreitenden Szenarien verwendet werden.
Anwendung
“ Die Statusmeldung ist eine direkte, augenblickliche Antwort des Finanzinstituts auf die empfangene «Customer Credit Transfer Initiation»-Meldung.
Schweizer Business Rules, Kapitel 6.1
Der Payment Status Report bestätigt die Entgegennahme oder Ablehnung eines Auftragesdurch ein Finanzinstitut. Es handelt sich nicht um eine Ausführungsbestätigung.
16
Validierungsprozess
• Schema/Syntax
• Formale Prüfung
• Autorisierung
pain.001 camt.052camt.053
• Bonität
• Limiten
• Warnungen
• Komplettierung
• Annullationen
Zusätzliche bank-fachliche
Validierung
• Buchung
Reporting
ValidierungA-/B-/C-Level und
bankfachlich
ReportingStatus
Report 1
pain.002 pain.002
Bank
KundenSoftware
Kundennutzen durch korrekte Anwendung von Statusnachrichten pain.002 und Reporting camt.052/053:Sichere und effiziente Nachverfolgung des Status eines Zahlungsauftrages
3a) Optional*) Additional Optional Services
Ku
nd
en
/ S
oft
ware
An
bie
ter
Fin
an
zin
stit
ut
1
2
3
3
4
4
3a
Auftragsstatus (vor Verbuchung)
Auftragsbestätigung(nach Verbuchung)
Consecutive Status
ReportsAOS*
17
Die Statusmeldung kann eine Antwort auf die ganze Meldung oder auch nur auf einzelne B- oder C-Levelsder Meldung sein
Status pro Messageebene
SEPA Credit Transfer SEPA Direct Debit
Status der gesamten Meldung
Status der gesamtenMeldung
Status der Zahlungspflichtigen-/
Belastungsseite
Status der Zahlungsempfänger-/
Gutschriftsseite
Status der Transaktion, Gutschriftsseite
Status der Transaktion, Belastungsseite
Document (Message)
A-Level
Group Header (1..1)
B-Level
Payment Information (1..n)
C-Level
Credit Transfer Transaction Information (1..n)
18
Überprüfung von Syntax und Semantik war erfolgreich über sämtliche A-, B- und C-Levels (inkl. Customer Profile [zum Beispiel Berechtigungsprüfung auf Stufe Konto]).
Die gesamte Meldung wurde entgegengenommen und wird verarbeitet.
ACCP (Accepted Customer Profile)
PART(Partially Accepted)
RJCT(Rejected)
Beschreibung
Ein B-Level oder mehrere B-Levels waren nicht korrekt(mind. 1 korrekter).
Ein C-Level oder mehrere C-Levels von einem B-Level waren nicht korrekt (mind. 1 korrekter).
Ganze Meldung wird abgewiesen. A-Level ist nicht korrekt, oder alle B- oder C-Levels sind
nicht korrekt. Wenn B-Level «PmtInf»: Alle Transaktionen des ent-
sprechenden B-Levels werden abgewiesen.
Einheitliche Status- und Fehlercodes vereinfachen die Kommunikation
Status- und Fehlercodes
Status Auswirkungen
Ganze Meldung wird zurückgewiesen. Fehler werden zurück geliefert.
ISO registrierte Reason Codes zwecks Nachvollzug des Fehlers.
Quelle: Schweizer Business Rules
Entspricht heutiger Interpretation von «Warnungen» und «Korrekturen», z.B. Valuta-Korrektur, verkettete Clearingnummern.
Es gibt möglicherweise Warnungen/Korrekturen (ACWC), aber keine Fehler.Die Meldung/Transaction wurde entgegen-genommen und wird verarbeitet.
ACWC(Accepted with Change)
Nur ein Teil der Meldung wird verarbeitet (mindestens eine Transaktion).
Nur die fehlerhaften Transaktionen werden zurückgeliefert mit «Transaction Status» = «RJCT».
19
Reject (RJCT) Reason Codes gemäss Schweizer Empfehlungen
ISO-Code Fehler
AC01 Fehlerhafte Kontonummer
AGNT Falscher Agent
AM01 Betrag muss grösser 0 sein
AM02 Unzulässiger Betrag
AM03 Unzulässige Währung
AM10 Fehlerhafte Prüfsumme
AM18 Wert «Number Of Transactions» entspricht nicht der Anzahl Transaktionen
BE01 Kundenidentifikation passt nicht zum angegebenen Konto
BE09 Wert «Country Code» ist ungültig
CH03 Wert «Requested Execution Date» bzw. «Requested Collection Date» liegt zu weit in der Zukunft
CH04 Wert «Requested Execution Date» bzw. «Requested Collection Date» liegt zu weit in der Vergangenheit
CH07 Element ist nicht im B- und C-Level zu verwenden
CH11 Wert «Creditor Identifier» ist inkorrekt
CH15 Inhalt von «Remittance Information/Structured» grösser als 140 Zeichen
CH16 Inhalt ist formal inkorrekt
CH17 Element ist nicht zugelassen
CH20 Anzahl Dezimalstellen nicht kompatibel mit Währung
CH21 Bedingtes Pflichtelement fehlt
CURR Fehlerhafte Währung
DT01 Ungültiges Datum
DT06 Ausführungsdatum wird auf den nächsten Bankwerktag/Postwerktag gesetzt (dieser Code führt nicht zu einer Rückweisung, er dient nur zur Information)
DU01 Wert «Message Identification» ist nicht eindeutig.
DU02 Wert «Payment Information Identification» ist nicht eindeutig in der Meldung
DU05 Element «Instruction Identification» ist nicht eindeutig im B-Level
MD01 Kein Mandat (Zahlungsermächtigung) vorhanden
RC01 Fehlerhafter Bank Identifikator
RR12 Ungültige Identifikation
20
Der Status Report erleichtert das MonitoringDie Problemanalyse kann zeitnah gestartet und damit entsprechend gegengesteuert werden
Zeitnahe Problemanalyse und Rückmeldung
• Kunden können auf Ausführungsprobleme schnell reagieren• Cut-Off Zeiten können eingehalten werden• Eine zeitgerechte Ausführung von wichtigen Zahlungen kann gewährleistet
werden
• Nachrichten lassen sich computergestützt auswerten
• Verbesserung der Zahlungstransparenz
Technische Validierung der eingelieferten Instruktion
• Ausbleiben einer Statusmeldung gibt möglicherweise Rückschlüsse auf Fehler im Kommunikationskanal
Validierung Kommunikations-kanal
Ausblick Section 4
Umgang mit den AOS (Additional Optional Services)
AOS des «pain.001» und «pain.002» MeldungZusätzliche Akteure pain.001
Batch Booking pain.001
Weitergehende Duplikats-Prüfungen pain.001
Creditor Agent bei Check pain.001
Verarbeitung trotz Syntaxfehler pain.001
Zusätzliche Statusmeldung pain.002
Statusmeldung ohne Group Status pain.002
Erweiterter Umfang von Status Report pain.002
Status in Statusmeldungen «pain.002» pain.002
Die Art und Weise der Anwendung der AOS soll auf dem Finanzplatz Schweiz weiter harmonisiert werden.
AppendixSection 5
24
• Internetseite «Harmonisierung des Zahlungsverkehrs in der Schweizwww.ubs.com/harmonisierung-zahlungsverkehr
UBS Internet
• SIX-Website zur Harmonisierung Zahlungsverkehr Schweiz (allgemeine Information)www.migration-pt.ch/de/home/migration.html
• Publikationen für Kunden, Softwarehersteller und Banken)www.migration-pt.ch/de/shared/migration-pt/publications.html
• Swiss Usage Guide»: Anwendungsfälle (Zahlungsarten) mit Feldregeln und Beispielen, wie die ISO-20022-Meldungen (Kunde-an-Bank bzw. Bank-an-Kunde) gemäss den Schweizer Empfehlungen www.migration-pt.ch/de/shared/migration-pt/news/2015/sug1.html
• Validierungs-Plattform für die fachlichen Validierung von ISO-20022-Meldungen mit den Regeln in den Schweizer Business Rules und Implementation Guidelineswww.six-interbank-clearing.com/de/home/standardization/iso-payments/customer-bank/validation-platform-iso-20022.html
Informationen Finanzplatz Schweiz
Weiterführende Informationen und Updates
Zürcher Kantonalbank Internet
• Internetseite «Harmonisierung des Zahlungsverkehrs in der Schweiz https://www.zkb.ch/de/un/fk/zahlungen-rechnungen/zv-migration.html
25
Dokumente und Zielgruppen
Zielgruppe des Dokuments bzw. Hilfsmittels
Dokument bzw. Hilfsmittel
Kleinere Softwarehersteller
Kundenberater bei Finanzinstituten
Grössere Softwarehersteller und IT von Finanzinstituten
Swiss Usage Guide x x (x)
Schweizer Business Rules
(x) (x) x
Schweizer Implementation Guidelines
(x) – x
Validierungsplattform Kunde-Bank
x – x
26
Meldungsstruktur und Inhalte des «pain.001»
Angaben zur Meldung im A-Level
27
Meldungsstruktur und Inhalte des «pain.001»
Auftragsinformationen im B-Level
28
Meldungsstruktur und Inhalte des «pain.001»
Transaktionsdetails im C-Level
29
Rückmeldestati im pain.002 für Fehler in pain.001
Gesamtes File validiert und Syntax korrekt
Fehler aufA-Level
Alle B-Level zurückge-wiesen
Einige B-Levelzurückge-wiesen
Alle C-Levels in allen B-Levels zurück-gewiesen
Alle C-Levelsin einem B-Level zurückge-wiesen
Einige C-Level in einemB-levelzurückge-wiesen
ACCP RJCT RJCT PART RJCT PART PART
n.a. n.a. RJCT RJCT RJCT RJCT PART
n.a. n.a. n.a. n.a. RJCT RJCT RJCT
Document (Message)
A-Level
Group Header (1..1)
B-Level
Payment Information (1..n)
C-Level
Credit Transfer Transaction Information (1..n)
pain.001
30
Die Struktur der Meldung gliedert sich wie folgt:
• Ebene A: Meldungsebene, «Group Header»
• Ebene B: Informationen zur Zahlungsgruppe, «Original Group Information And Status»
• Ebene C: Information zu einzelnen Zahlungsgruppen (Level B), «Original Payment Information And Status»
• Ebene D: Informationen zu einzelnen Transaktionen (Level C), «Transaction Information And Status»
pain.002 Meldungsstruktur / Inhalt
Quelle: Schweizer Business Rules
Document (Message)
A-Level
Group Header (1..1)
B-Level
Original Group Information and Status (1..1)
C-Level
Original Payment Information andStatus (0..n)
D-Level
Transaction Information andStatus (0..n)