Standards Implementation aus Sicht

Marktinfrastruktur Erfahrungen aus dem SIC4 Projekt

Andreas Galle

17. Oktober 2013

17. Oktober 2013 Seite

Agenda

2

Wo sind die Grenzen einer Marktinfrastruktur?

Wir sind nicht auf der grünen Wiese - Umgang mit der Legacy

Standards-Migration – wie vermeide ich Stolpersteine

ISO 20022 – Kostenfalle oder Chancen-Katalysator

Standard ist nicht gleich Standard - Gefahr der Babylonisierung

Alles klar?

17. Oktober 2013 Seite

Wo sind die Grenzen einer Marktinfrastruktur ?

3

17. Oktober 2013 Seite

Wo sind die Grenzen einer Marktinfrastruktur ?

• Die Grenzen der Marktinfrastruktur bestimmen auch die Grenzen der

Marketpractice und Service Rules.

• Duale Marktinfrastruktur in der Schweiz: eine Marketpractice für SIC, eine

Marketpractice für PostFinance?

• Geographisch: eine Marketpractice für die Schweiz?

• Marketpractice und Service Rules nur für den nationalen Verkehr oder auch

cross-border Transaktionen?

• Marketpractice pro Dienstleistung: Überweisungen und Lastschriften?

4

17. Oktober 2013 Seite

Die Marketpractice entlang der Financial Value Chain

5

Zahler Finanzinstitut A CSM Finanzinstitut B Zahlungsempfänger

Zahlungsauftrag

Belastungsanzeige

Credit Transfer Credit Transfer Gutschriftsanzeige

Ausführungsquittung Empfangsquittung

CGI Guidelines

SEPA-Rulebooks

CGI Guidelines

IPF

17. Oktober 2013 Seite

Wir sind nicht auf der grünen Wiese !

6

17. Oktober 2013 Seite

Die Legacy

Kunde Bank Schnittstelle:

• DTA

• EZAG

• SWIFT FIN

• XML Gutschriftsanzeige

• EGA

Intebankschnittstelle:

• SIC Standard

• SWIFT FIN

Für jeden Standard existieren eigene Service Rules. Das resultiert in

umfangreichen Mapping Vorschriften beim Übergang von einem Standard zum

anderen.

7

17. Oktober 2013 Seite

Der Umgang mit der Legacy bei Koexistenz der Standards:

Zentrale vs dezentrale Konvertierung

• Dezentrale Konvertierung: Last wird auf Teilnehmer abgeschoben

• Zentrale Konvertierung im SIC4: Problem des Informationsüberhangs bei der

Konvertierung von ISO20022 nach den legacy Standards:

Restriktion im ISO20022 damit das Problem nicht entsteht

Truncation , die überzählige Information geht verloren

Truncation, die überzählige Information ist durch das Institut des Begünstigten auf

einem anderen Kanal abrufbar, z.B. Web-Interface.

Rückwärtskompatibilität:

• Da kein Big Bang möglich, muss die neue Infrastruktur rückwärtskompatible sein.

• SIC4: mit dem „Legacy Adapter“ werden die „alten“ Standards unterstützt.

Security

• Wenn Sender-Standard ungleich Empfänger-Standard ist die durchgehende end-

to-end Sicherheit nicht gewährleistet.

8

17. Oktober 2013 Seite

Migration – ausgewählte Aspekte

9

17. Oktober 2013 Seite

Aspekte einer Migration der zentralen Infrastruktur auf ISO 20022

• Parallelbetrieb einer Zahlungsverkehr-Infrastruktur ist (fast) nicht möglich.

Da immer 2 Konto in einer Transaktion involviert sind besteht die Gefahr von Deadlocks

modifizierenden Zugriff auf ein Konto nur von einem Prozess möglich

• Bei der zentralen Infrastruktur ist daher nur ein Big Bang möglich. Daher muss

Rückwärtskompatibilität gewährleistet sein, damit auf Teilnehmerseite nicht alle

zu einem bestimmten Zeitpunkt umschalten müssen.

• Umstellung der Teilnehmer auf den neuen Standard:

Der Teilnehmer bestimmt den Zeitpunkt selbst. Risiko, dass sich die Migration verzögert

bzw. auf das End-Date konzentriert.

Orchestrierte Migration, wie in SIC4 vorgesehen. 3-4 Migrationsfenster über 1½ Jahre.

Fensterzuteilung durch Marktinfrastruktur-Provider in Absprache mit dem Teilnehmer.

Zweck: regelmässige Volumenverteilung, Risiko-Minderung

10

17. Oktober 2013 Seite

Aspekte einer Migration der zentralen Infrastruktur auf ISO 20022

• Probleme während der Umstellungsphase: Informationsüberhang bei Migration

ISO 20022 nach Legacy-Format.

Lösungen in SIC 4: Truncation, überzählige Info ist über Web-Portal abrufbar.

• Abhängigkeiten: externe Releases, SWIFT, SEPA, interne Releases bei

Teilnehmer während der Umstellungsdauer.

• Decommissioning der alten Standards muss geplant werden. Verbindliches End-

Date setzen.

11

17. Oktober 2013 Seite

Mit einem neuen Standard ist noch kein Blumentopf zu

gewinnen.

12

Warum sich die Migration nach ISO 20022 trotzdem lohnt

17. Oktober 2013 Seite

Wo liegt der Nutzen einer Migration auf ISO 20022 ?

• Migration auf ISO 20022 bringt vorerst nur Kosten

• ISO 20022 Grundlage für neue Dienstleistungsangebote.

• Vermehrte Automatisierung dank höherem Grad der Standardisierung. Keine

Standard- und Medienbrüche entlang der Financial Value Chain. Einsparung

Kosten.

• Konsequenz: nicht nur die Frontendsysteme müssen umgestellt werden, auch

die Applikationen des Middle und Back Office.

ISO 20022 Standard als Katalysator für Innovationen. Damit Erschliessung

neuer Revenues.

ISO 20022 Standard als Enabler für Erhöhung des Automatisierungsgrades.

Damit Kostensenkung in operativen Prozessen.

13

17. Oktober 2013 Seite

Mit ISO 20022 sind nicht alle Probleme bezüglich

Durchgängigkeit gelöst

14

Die Gefahr der Babylonisierung ist latent vorhanden

17. Oktober 2013 Seite

Über die Grenzen der Marketinfrastruktur und damit der

Marketpractice hinweg

• Nicht kompatibler Zeichensatz (kyrillisch, arabisch, chinesische Zeichen) kann

eine Meldung unlesbar machen. Screening und Filtering ist nicht automatisisert

möglich

• AOS und Variants können im Grenzbereich zu Problemen (z.B. Rückweisungen,

Non-STP Verarbeitung) führen.

• Grundsatz: die Marketpractice der Empfängerinfrastruktur berücksichtigen

z.B. Retail-Zahlungen in den EU-Raum müssen SEPA-kompatible sein.

15

17. Oktober 2013 Seite 16

Vielen Dank für Ihre Aufmerksamkeit.