Bis jetzt gab es zwei Zahlungsverkehrsformate in der Schweiz für die Einreichung von Zahlungsaufträgen: EZAG der PostFinance und DTA für die Banken. Ab sofort gilt es, die ISO 20022-Meldung pain.001 zu verwenden und dazu noch das Protokoll pain.002 auswerten zu können.
In der Praxis wird aber schnell klar, dass das Format nicht zu unterschätzen ist und es doch ein weiter Weg ist bis die Salärfiles und Kreditorenzahlungen wieder zuverlässig vom Konto abgebucht werden. Meist werden von den Banken im Vorfeld ausreichende Tests verlangt bis eine gewisse Qualität erreicht ist. Und letztendlich werden immer noch „Penny-Tests in Produktion“ empfohlen, sodass bei den ersten reellen Zahlungsläufen keine Überraschungen auftreten.
Testbanken - Fluch oder Segen?
Früher wurden ab einem gewissen Zeitpunkt der Programmierung DTA-Files über den einen oder anderen Weg an die Bank übermittelt und meist gab es ein Feedback in Prosa, in welchem die noch auftretenden Fehler erklärt wurden. Mit der neuen Meldung pain.001 jedoch, haben die Swiss Interbank Clearing als schweizweite Hüterin des „Swiss Payment Standards“ und mehrere Banken nun sogenannte Testbanken eingeführt, welche es dem Kunden im Vorfeld ermöglichen sollen, autonom und realitätsnah zu testen, ohne dass ein Bankmitarbeiter jedes Mal involviert werden und ein individuelles Feedback geben muss.
Dabei hat sich bemerkbar gemacht, dass nicht immer klar ist, wie die Testbanken im gesamten Onboarding-Prozess genutzt werden sollen. Viele sind auch von den Rückmeldungen der Testbanken überfordert, weil es neben richtigen Fehler- auch Infomeldungen gibt, bei denen dann nicht klar ist, ob diese nun beseitigt werden müssen oder eben nur eine Empfehlung darstellen. Mit den Rückmeldungen alleine gelassen fühlen sich nicht nur Endkunden, die vor dem produktiven Einsatz einer Standardsoftware nur nochmal ein oder zwei Tests machen wollen, sondern auch die Softwarehersteller eben solcher Standardprodukte. Dieses Problem haben aber auch Grosskunden, die selbst programmieren und durchaus auch Bankmitarbeiter in Hotlines oder in der Zahlungsverkehrsberatung, die bei Unklarheiten die Meldungen ihrer eigenen Testbank erklären sollen.
Aufwandreduktion beim Entwickeln und beim End-To-End-Testen erreichen
Wie erreicht man nun, dass die Investitionen dieser Testbanken sich rentieren? Schliesslich sollen diese neuen Möglichkeiten ja alle Beteiligten entlasten.
Banken sollten deshalb Checklisten für Supportanfragen einführen, die dem Kunden direkt beim ersten Kontakt überreicht werden. Auch sollten die Mitarbeiter geschult werden und eine Liste an die Hand bekommen, welche Fehlermeldung wie zu verstehen ist.
Nach all diesen Ausführungen möchten wir an dieser Stelle aber auch alle involvierten Parteien ermutigen, die Testbanken rege einzusetzen und ein paar Tipps mit auf den Weg geben:
Fragen Sie frühzeitig bei Ihrer Bank nach dem Onboarding-Prozess. Dieser kann unterschiedlich aussehen, je nachdem, ob eine Testbank zur Verfügung steht oder nicht:
Mögliche Supportprozesse:
- Wenn Ihre Bank keine Testbank mit den bankeigenen Besonderheiten anbietet, nutzen Sie die Validierungsplattform der SIX.
- Die Rückmeldungen der Testbanken sind meist selbsterklärend. Schon allein mit nochmaligem Vergleich der Feld-Definition in den Implementation Guidelines sollten Programmierer sehr gut den Fehler finden und beseitigen können.
- Manche Testbanken bieten Beispieldateien an, die die Testbank per Knopfdruck erzeugt und die anschliessend sogar heruntergeladen werden können, um ein „Primus-Beispiel“ zu haben. Dieses klärt meist schon sehr viele Fragen.
- Fragen Sie sich, welche Zahlungsarten Sie benötigen und nutzen Sie die Beispieldaten der Testbanken zu den unterschiedlichen Zahlungsarten.
- Stellen Sie sicher, dass Sie alle notwendigen Dokumentationen besitzen. Zum einen natürlich die Implementation Guidelines und Beispieldateien der SIX, zum anderen bieten Banken meist noch eigene, komplementäre Implementation Guidelines für ISO 20022-Meldungen an, welche auf die individuelle Behandlung mancher Schlüsselfelder eingehen.
- Viele Testbanken erlauben es, Ihre eigene pain.001-Meldung mit den Auswertungsergebnissen angereichert als Kommentare wieder herunterzuladen. Hier wird sehr schnell deutlich, wo der Hase begraben liegt.
- Wenn Sie nicht weiterkommen, gehen Sie nicht ohne Screenshots aus der Testplattform bzw. nicht ohne die kommentierte pain.001-Meldung auf die Supporteinheiten Ihrer Bank zu, da dies meist zu unnötigen Rückfragen führt und eine schnelle Antwort verunmöglicht.
Und tritt doch einmal ein Fehler in der Produktion auf...
Sollte es doch mal zu einem Fehler in der Produktion kommen, sind gewisse Angaben unabdingbar für alle Support-Beteiligten, um eine rasche Antwort geben zu können:
- Dokumentieren Sie den genauen Wortlaut der Fehlermeldung, am besten mit Screenshots.
- Testen Sie die fehlerhafte pain.001-Meldung zuerst auf der Testplattform der Bank und dokumentieren Sie dortige Fehlermeldungen. Laden Sie die kommentierte XML-Meldung herunter. Dies hilft dem Support meist, den Fehler rasch zu lokalisieren.
- Bitte vergessen Sie auch nicht, die fehlerhafte pain.001-Meldung bereitzuhalten, falls vom Support gefordert.
- Daneben sind noch einigen Randparameter festzuhalten:
- Einlieferkanal
- Zeitpunkt des Uploads
- Filename, den das System/der Kanal vergeben hat
- Name des Users und Vertragsnummer, mit der eingereicht wurde
- Ggf. Vertragsnummer eines Kollektivvisums
Dieser Beitrag wurde von Frank Rebmann gepostet.
#Testing, #HarmonisierungZahlungsverkehr, #Testplattform
0 Kommentare:
Kommentar veröffentlichen