Wahrscheinlich haben die meisten von uns bereits einen Brief von ihrer Bank im Briefkasten gefunden: Ab dem kommenden Jahr ist SEPA (Single Euro Payments Area) zum 01. Februar 2014 Pflicht.
Wir möchten einen kleinen Überblick verschaffen und zeigen, welche Hindernisse uns bei der Umsetzung für unsere Kunden im Wege standen.
Was ist SEPA?
Zum 01. Februar 2014 wird ein europaweit einheitliches Verfahren im Euro-Zahlungsverkehrsraum für bargeldlose Zahlungen (Überweisungen, Lastschriften) mit dem Namen SEPA gestartet. Teilnehmer dieses Verfahrens sind die 28 EU-Staaten, Island, Liechtenstein, Norwegen, Monaco und die Schweiz. Dabei sind alle Kontoinhaber, egal ob Privatperson, Unternehmen oder Verein betroffen.
Die wohl wichtigste Änderung ist, dass nationale Kontonummer und Bankleitzahl zugunsten der IBAN (= International Bank Account Number) und des BIC (= Business Identifier Code) entfallen.
Doch ist der BIC überhaupt noch notwendig? Da die IBAN in ihrer Zusammensetzung bereits eine Banknummer beinhaltet, wird der BIC spätestens zum 01. Februar 2016 entfallen. Bis es soweit ist, gibt es Regelungen und Fristen, die es einzuhalten gilt. Unterschieden wird dabei sowohl, ob es sich um Privatpersonen, Unternehmen oder um Vereine handelt, als auch ob die SEPA-Zahlung inländisch oder grenzüberschreitend in der EU durchgeführt wird. Die folgende Tabelle zeigt, welche Nummern für welchen Transaktionsfall angegeben werden müssen:
Quelle: https://www.sepadeutschland.de
Fasst man den Inhalt der Tabelle zusammen, so kann man sagen, dass nur noch bei grenzüberschreitenden SEPA-Zahlungen bis zum Februar 2016 der BIC angegeben werden muss. Danach entfällt sie komplett. Privatkunden können bei ihren Banken außerdem bis zum Februar 2016 mit ihrer bisherigen Kontonummer und Bankleitzahl weiterarbeiten.
Unsere Erfahrungen und Probleme
Für einen Kunden mit einem Self-Service-Kundenportal haben wir die Umsetzung der SEPA-Einführung mitbegleitet. Die Änderungen zogen sich durch alle architektonischen Schichten. Das Kernsystem war das zentrale Vertragstool. Die hier hinterlegten Kontonummern und Bankleitzahlen mussten über ein bestimmtes Schema in IBAN und BIC umgewandelt werden. Weiterhin wurden für die Umstellung auch alle betroffenen Webservices entsprechend ergänzt. Die Webservices beliefern das Frontend mit Daten, wie in unserem Fall das Kundenportal. Während der lesende Teil trivial ist, muss der speichernde Aufruf der Webservices um die Validierung von Prüfsummen in der IBAN ergänzt werden.
Bei der Implementierung mussten wir einige Hürden überspringen und haben dabei einige Erkenntnisse gewonnen:
Der BIC ist nicht für alle Filialen eindeutig
Die Bestandskonten wurden mit Hilfe der Services des Bank Verlages SEPA-konform umgewandelt. Während die altbekannten Bankleitzahlen für jede Bankfiliale eineindeutig waren, gibt es bei dem BIC Unterschiede. Die letzten 3 Zeichen in der Definition eines BIC stehen für die Bankfilialen zur Verfügung, müssen aber nicht zwingend genutzt werden. Das hatte Auswirkungen auf unser Frontend. Bisher wurde bei der Eingabe einer Kontonummer der jeweilige Bankname angezeigt, was aber bei einem nicht eindeutigen BIC zu falschen Ergebnissen führen kann. Für diesen Fall haben wir zusätzliche Tabellen angelegt, die mehrere Filialen auf ihre Hauptfiliale mappen. Die Hauptfiliale haben wir dann unter einem von uns manuell angelegtem, gekürzten Namen für die Ausgabe hinterlegt.
Ein Beispiel für den genannten Fall war der BIC der Commerzbank COBADEFFXXX, die sowohl für die Hauptfiliale, als auch für einige Unterfilialen verwendet wurde.
Usability vs. Datenschutz: SEPA-Mandat als vorbefülltes PDF
Führt ein Kunde Änderungen bei seinem Lastschriftverfahren durch, so ist es notwendig, dass dieser ein SEPA-Mandat ausfüllt und unterschrieben an den Zahlungsempfänger zurückschickt.
Bei der Änderung des Bankeinzuges wurde dem Kunden bisher eine E-Mail als Bestätigung gesendet. Die erste Idee war also, ihm ein vorausgefülltes PDF-Formular mit seinen Daten ebenfalls über E-Mail zukommen zu lassen. Diese Idee wurde schnell wieder verworfen, da es sich um einen großen Datenschutz-Fauxpas gehandelt hätte. Während die Bankverbindungsdaten in der Bestätigungsemail nämlich bis auf die letzten Stellen unkenntlich gemacht werden, würde das bei dem SEPA-Mandat nicht viel bringen. Ersetzt man die Bankverbindungsdaten durch Platzhalter, so wäre das Mandat ungültig. Schickt man das Mandat im Klartext raus, verteilt man die Bankverbindungsdaten an alle, die auf der Leitung mitlesen.
Unser Ansatz ist nun, dem Kunden bei der Änderung der Daten weiterhin eine E-Mail zu schicken, in der ein Link auf einen sicheren Bereich im Kundenportal platziert ist. Hier kann sich der Kunde, nachdem er sich eingeloggt hat, sein vorbefülltes Formular nun herunterladen und es an den Zahlungsempfänger zurückschicken.
Big Bang Release mit Folgen
Das Kernsystem, welches die Bankverbindungsdaten der Kunden hält, unterstützt keine Versionierung von Schnittstellen und Services. Neben dem Produktivsystem gibt es außerdem aufgrund von Lizensierungsschwierigkeiten nur ein einziges weiteres Testsystem, welches sich die betroffenen Umsysteme teilen. Dies führt natürlich zu einer großen Abhängigkeit und zu einem großen Risiko. Die Implementierung, die Testphasen und das Release mussten für alle Systeme vereinheitlicht werden. Es ging viel Zeit und Arbeit verloren, auftretende Fehler zurückzuverfolgen, da sie von unterschiedlichsten Quellen stammen konnten. Die terminliche Vorgabe hat uns außerdem unter großen Druck gesetzt.
Um dem Risiko entgegenzutreten, war es notwendig eine hohe Testabdeckung für die betroffenen Systeme zu erzielen. Diese erreichten wir durch die Erstellung von Small- und Large-Tests. Während in dem Small-Test mit der Hilfe von Unittests einzelne Programmkomponenten getestet wurden, konnten im Large-Test mit der Hilfe von Mocks und automatisierten Tests mit HTMLUnit das gesamte Zusammenspiel der einzelnen Komponenten getestet werden.
Ein weiteres Problem stellte sich erst bei einem finalen Test heraus: Das Vertragstool, das in der Vergangenheit bereits einige Migrationen von Daten aus unterschiedlichen Quellen durchlaufen hatte, zeigte beim Test Probleme in der Datenqualität auf. So gab es viele Karteileichen oder redundante Datensätze, die es aufzuräumen oder zu korrigieren galt. Dies erforderte vor allem Zeit, um die Korrekturen durchzuführen. Die strenge Begrenzung auf das Release-Datum sorgte für Überstunden und massiven Druck, da zwischen den Abnahmetests und dem Release nur sehr wenig Pufferzeit eingeplant wurde.
Der Termin rückt näher
Wir haben es letztendlich geschafft mit unseren Änderungen Anfang Oktober live zu gehen. Trotz der vielen Abhängigkeiten verlief das Release weitgehend reibungslos. Die Deadline, der 01. Februar 2014, steht vor der Tür. Für alle, die sich bisher vor der Umstellung gedrückt haben bleibt also nicht mehr viel Zeit. Wir wünschen euch viel Erfolg bei der Umsetzung!
Was waren eure Probleme?
Hattet ihr ebenfalls Probleme oder Erfahrungen mit der Umstellung auf SEPA? Erzählt uns und unseren Lesern davon und hinterlasst einen Kommentar!
Schreibe einen Kommentar