Harmonisierung Zahlungsverkehr Schweiz - Breakout Session Überweisungen Payment Initiation pain.001 und Payment Status Report pain.002 - Topal ...
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Harmonisierung Zahlungsverkehr Schweiz Breakout Session Überweisungen Payment Initiation pain.001 und Payment Status Report pain.002 Hanni Halter Product Manager Banking Products, Card and Payment Solutions Jürgen Wintermantel Product Manager Products, Services & Directbanking 17. September 2015
Inhaltsverzeichnis
Section 1 ISO 20022 Verwendung und Nutzen 4
Section 2 Das Überweisungsverfahren pain.001 7
Section 3 Payment Status Report pain.002 17
Section 4 Ausblick 24
Section 5 Appendix 26
1
Vorstellung der Moderatoren
Hanni Halter
UBS Switzerland AG – Banking Products
Product Manager Payment Products
Visitenkarte
• Projekt UBS Harmonization ISO Payments
• Einsatzgebiete
– SEPA Credit Transfer
– Schweizer Überweisungsverfahren
– Payment Status Report
– CtB-Projekte in UBS Payment Solutions
2
Vorstellung der Moderatoren
Jürgen Wintermantel
Zürcher Kantonalbank –
Products, Services & Directbanking Jürgen Wintermantel Neue Hard 9, Zürich
Products, Services & Telefon 044 292 23 40
Directbanking Fax 044292 21 37
Produktmanager Zahlungsverkehr Produktmanager Zahlungsverkehr
Mitglied des Kaders
Juergen.wintermantel@zkb.ch
www.zkb.ch
Projekte Briefadresse
ZKB Migration ZV CH Postfach, 8010 Zürich
ZKB Pricing & Billing
LEON
Einsatzgebiete
SEPA Credit Transfer (pain.001)
Payment Status Report (pain.002)
Cash Management Meldungen (camt)
eBanking Zahlungen
E-Rechnung
weitere
Section 1 ISO 20022 Verwendung und Nutzen
Verwendung ISO 20022 Credit Transfer Meldungsfluss
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
Auftraggeber Rechnungsstellung Empfänger
der Zahlung (mit neuem ES) der Zahlung
Status /
Avisierung / Avisierung /
Kontoauszug Kontoauszug
pain.002 Zahlungs- camt.052
auftrag
camt.052 camt.053
pain.001
camt.053 camt.054
camt.054
Interbank- Interbank-
Finanzinstitut A zahlung zahlung Finanzinstitut B
pacs.008 pacs.008
Clearing
Legende: Geldfluss ISO-Meldungsfluss Belegfluss
5
Nutzenaspekte ISO 20022
Aufgrund der diversen Vorteile unterstützen u.a. EPC (SEPA) und SWIFT die Verwendung von ISO 20022
Thema Beschreibung
Einheitliche • Gleiche Behandlung durch alle Finanzinstitute erhöht die Flexibilität bei der
Validierung Zusammenarbeit mit mehreren Finanzinstituten
Einheitliche Status und • Einfachere Kommunikation mit Supportstellen, unabhängig von Software-
Fehlercodes Hersteller oder Finanzinstitut
Durchgängige
• Automatisierung bei Zahlungspflichtigen und Zahlungsempfängern
Kundenreferenzen
Weniger
• Verwendung einheitliche Meldungsstandards
Verarbeitungsfehler
Einheitliche • Weniger komplexe Entwicklung, Wartung und Unterhalt seitens der
Meldungstypen Software-Partner
• Allfällige Erweiterungen mit weniger Komplexität aufgrund Verwendung
Flexibilität
des XML-Standards
Quelle: Schweizer Business Rules
Vorteile für Kunden Vorteile Software-Partner
6
Section 2 Das Überweisungsverfahren pain.001
Das Überweisungsverfahren mit «pain.001»
Bestehende Überweisungsverfahren
DTA und/oder EZAG
Belastungsanzeige, Kontoauszug (pdf; physisch, MT940,
Kunden Kunden MT942)
Software Bank
Neues Überweisungsverfahren im ISO 20022 Standard
pain.001: Zahlungsauftrag
pain.002: Payment Status Report
Kunden Kunden
Software
camt.xxx: Cash Management Bank
Handlungsbedarf:
Umstellung auf ISO 20022 Meldungsstandard
Anpassung IBAN (Obligatorium ab 2020)
Prozesse optimieren (effizientes Cash Management)Customer Credit Transfer Initiation «pain.001»
Generell
Elektronische Beauftragung von
Überweisungsaufträgen
Geltungs- Basis ist das ISO-20022-XML-Schema Prüfung der Zahlungsart
«pain.001.001.03»
bereich Identifizierung anhand
Gültig für alle heutigen Zahlungsarten in Schlüsselelemente
der Schweiz (national, (Bsp.: Payment Method)
grenzüberschreitend, SEPA usw.)
Validierung erfolgt gegen die
Inland Vorgaben zu dieser Zahlungsart
Oranger ES (ESR) in CHF & EUR
Roter ES in CHF & EUR Beispiel:
Bei Zahlungsart 1 (ESR) wird geprüft, ob
Bank- oder Postzahlung in CHF & EUR
das Element «Creditor Account» eine
Bank- oder Postzahlung in FW ESR-Teilnehmernummer enthält und die
Geschäftsfälle/ Ausland Elemente zu «Creditor Agent» nicht
SEPA-Überweisung vorhanden sind.
Zahlungsarten
Ausland, alle Währungen
Zahlungen ohne Finanzinstitut im In- und
Ausland
Zahlungsanweisung Inland in CHF
Bankcheck/Postcash im In- und Ausland
alle WährungenKernelemente 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 RulesMeldungsstruktur 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 alle
zum 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 ()
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 ()
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 ()
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.Section 3 Payment Status Report pain.002
Payment Status Report pain.002
Ausprägungen
• Information des Auftraggebers über den Status einer Instruktion – positiv oder
negativ, also Annahme oder Ablehnung
• Die Instruktion (Zahlungsauftrag) kann eine Banküberweisung oder eine
Definition
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)
Anwendung
• 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.
“
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 Auftrages
durch ein Finanzinstitut. Es handelt sich nicht um eine Ausführungsbestätigung.
15Validierungsprozess
Kundennutzen durch korrekte Anwendung von Statusnachrichten pain.002 und Reporting camt.052/053:
Sichere und effiziente Nachverfolgung des Status eines Zahlungsauftrages
Kunden / Software Anbieter
Auftragsstatus Auftragsbestätigung
Kunden (vor Verbuchung) (nach Verbuchung)
Software
Consecutive
Status Status AOS*
3 4 Reporting
Report 1 Reports
pain.001 pain.002 pain.002 camt.052
camt.053
1 3 3a 4
Validierung Zusätzliche bank-
A-/B-/C-Level und fachliche
Reporting
bankfachlich Validierung
Finanzinstitut
2
• Schema/Syntax • Bonität • Buchung
• Formale Prüfung • Limiten
Bank • Autorisierung • Warnungen
• Komplettierung
• Annullationen
3a) Optional
*) Additional Optional Services 16Status pro Messageebene
Die Statusmeldung kann eine Antwort auf die ganze Meldung oder auch nur auf einzelne B- oder C-Levels
der Meldung sein
Document (Message)
SEPA Credit Transfer SEPA Direct Debit
A-Level
Status der gesamten Status der gesamten
Group Header (1..1)
Meldung Meldung
B-Level
Payment Information (1..n) Status der Status der
Zahlungspflichtigen-/ Zahlungsempfänger-/
Belastungsseite Gutschriftsseite
C-Level
Credit Transfer Transaction
Information (1..n)
Status der Transaktion, Status der Transaktion,
Gutschriftsseite Belastungsseite
17Status- und Fehlercodes
Einheitliche Status- und Fehlercodes vereinfachen die Kommunikation
Status Beschreibung Auswirkungen
ACCP Überprüfung von Syntax und Semantik war erfolgreich über Die gesamte Meldung wurde
sämtliche A-, B- und C-Levels (inkl. Customer Profile [zum entgegengenommen und wird
(Accepted Beispiel Berechtigungsprüfung auf Stufe Konto]). verarbeitet.
Customer Profile)
ACWC Entspricht heutiger Interpretation von «Warnungen» und Es gibt möglicherweise
«Korrekturen», z.B. Valuta-Korrektur, verkettete Warnungen/Korrekturen (ACWC), aber
(Accepted with
Clearingnummern. keine Fehler.
Change)
Die Meldung/Transaction wurde entgegen-
genommen und wird verarbeitet.
PART Ein B-Level oder mehrere B-Levels waren nicht korrekt Nur ein Teil der Meldung wird
(mind. 1 korrekter). verarbeitet (mindestens eine
(Partially Accepted)
Ein C-Level oder mehrere C-Levels von einem B-Level Transaktion).
waren nicht korrekt (mind. 1 korrekter). Nur die fehlerhaften Transaktionen
werden zurückgeliefert mit «Transaction
Status» = «RJCT».
RJCT Ganze Meldung wird abgewiesen. Ganze Meldung wird zurückgewiesen.
A-Level ist nicht korrekt, oder alle B- oder C-Levels sind Fehler werden zurück geliefert.
(Rejected)
nicht korrekt. ISO registrierte Reason Codes zwecks
Wenn B-Level «PmtInf»: Alle Transaktionen des ent- Nachvollzug des Fehlers.
sprechenden B-Levels werden abgewiesen.
Quelle: Schweizer Business Rules
18Reject (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
19Der Status Report erleichtert das Monitoring
Die Problemanalyse kann zeitnah gestartet und damit entsprechend gegengesteuert werden
• Kunden können auf Ausführungsprobleme schnell reagieren
Zeitnahe
• Cut-Off Zeiten können eingehalten werden
Problemanalyse
und Rückmeldung • Eine zeitgerechte Ausführung von wichtigen Zahlungen kann gewährleistet
werden
Technische
Validierung der • Nachrichten lassen sich computergestützt auswerten
eingelieferten • Verbesserung der Zahlungstransparenz
Instruktion
Validierung
• Ausbleiben einer Statusmeldung gibt möglicherweise
Kommunikations-
Rückschlüsse auf Fehler im Kommunikationskanal
kanal
20Section 4 Ausblick
Umgang mit den AOS (Additional Optional Services)
AOS des «pain.001» und «pain.002» Meldung
Zusätzliche Akteure pain.001
Batch Booking pain.001
Weitergehende Duplikats-Prüfungen pain.001 Die Art und Weise der
Creditor Agent bei Check pain.001
Anwendung der AOS soll auf
dem Finanzplatz Schweiz weiter
Verarbeitung trotz Syntaxfehler pain.001 harmonisiert werden.
Zusätzliche Statusmeldung pain.002
Statusmeldung ohne Group Status pain.002
Erweiterter Umfang von Status Report pain.002
Status in Statusmeldungen «pain.002» pain.002Section 5 Appendix
Weiterführende Informationen und Updates
Informationen Finanzplatz Schweiz UBS Internet
• SIX-Website zur Harmonisierung Zahlungsverkehr Schweiz • Internetseite «Harmonisierung des Zahlungsverkehrs
(allgemeine Information) in der Schweiz
www.migration-pt.ch/de/home/migration.html www.ubs.com/harmonisierung-zahlungsverkehr
• 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 Zürcher Kantonalbank Internet
(Kunde-an-Bank bzw. Bank-an-Kunde) gemäss den
Schweizer Empfehlungen • Internetseite «Harmonisierung des Zahlungsverkehrs
www.migration-pt.ch/de/shared/migration- in der Schweiz
pt/news/2015/sug1.html https://www.zkb.ch/de/un/fk/zahlungen-rechnungen/zv-
migration.html
• Validierungs-Plattform für die fachlichen Validierung von
ISO-20022-Meldungen mit den Regeln in den Schweizer
Business Rules und Implementation Guidelines
www.six-interbank-
clearing.com/de/home/standardization/iso-
payments/customer-bank/validation-platform-iso-
20022.html
24Dokumente und Zielgruppen
Zielgruppe des Dokuments bzw. Hilfsmittels
Dokument bzw. Kleinere Kundenberater bei Grössere Softwarehersteller
Hilfsmittel Softwarehersteller Finanzinstituten und IT von Finanzinstituten
Swiss Usage Guide x x (x)
Schweizer Business
(x) (x) x
Rules
Schweizer
Implementation (x) – x
Guidelines
Validierungsplattform
x – x
Kunde-Bank
25Meldungsstruktur und Inhalte des «pain.001»
Angaben zur Meldung im A-Level
26Meldungsstruktur und Inhalte des «pain.001»
Auftragsinformationen im B-Level
27Meldungsstruktur und Inhalte des «pain.001»
Transaktionsdetails im C-Level
28Rückmeldestati im pain.002 für Fehler in pain.001
Alle C-Levels Alle C-Levels Einige C-Level
Gesamtes File in allen in einem in einem
validiert und Alle B-Level Einige B-Level B-Levels B-Level B-level
Syntax Fehler auf zurückge- zurückge- zurück- zurückge- zurückge-
korrekt A-Level wiesen wiesen gewiesen wiesen wiesen
Document (Message)
A-Level
ACCP RJCT RJCT PART RJCT PART PART
Group Header (1..1)
B-Level
Payment Information (1..n) n.a. n.a. RJCT RJCT RJCT RJCT PART
C-Level
Credit Transfer
Transaction
n.a. n.a. n.a. n.a. RJCT RJCT RJCT
Information (1..n)
pain.001
29pain.002 Meldungsstruktur / Inhalt
Document (Message) Die Struktur der Meldung gliedert sich wie folgt:
A-Level
Group Header (1..1)
• Ebene A: Meldungsebene, «Group Header»
B-Level • Ebene B: Informationen zur Zahlungsgruppe,
Original Group Information and Status (1..1) «Original Group Information And Status»
C-Level
Original Payment Information and
• Ebene C: Information zu einzelnen Zahlungsgruppen
Status (0..n) (Level B), «Original Payment Information And Status»
D-Level • Ebene D: Informationen zu einzelnen Transaktionen
Transaction Information and (Level C), «Transaction Information And Status»
Status (0..n)
Quelle: Schweizer Business Rules
30Sie können auch lesen
