The 'P' in 'SEPA' is for Pain // Das "S" in "SEPA" steht für Schmerzen
(German version below)
We're in the middle of our first SEPA mass direct debit. Here is small and cynical look behind the scenes:
As you might know, all our management software is written by us, even the banking parts. With the old system we got a so called DTA file once a month. That's a certain construct, made by the German Central Credit Committee in 1976, the digital stone age. The formats, the process and the surrounding legal conditions were well known, tested and well functioning over many decades.
Some day the EU decided to normalize bank transactions within the Euro payments area. We were excited to see new and common specifications for all these very old standards. We were excited to be able to deducty money from students who come from Spain, Italy or Poland. We have even been excited to see that the needed files are now XML files and therefore easy to handle.
But. Now we're obliged to inform everyone about the upcoming deduction 2 weeks in advance. Most of you aren't interested in the exact date of the deduction and we don't want to send you too many emails, because they might end up in your SPAM folder. But who knows, maybe some people are happy to receive these emails.
But let's go on: our management system creates this direct debit file, does calculations and accounting for paid fees, and sends all the needed information via email to everyone. And that's where the problems start: a few hours later we receive emails saying "I'm leaving at the end of the month and I already closed my bank account". At this point, the direct debit file is already at the bank, has been signed and we can't stop single debits anymore. In case someone transfered missing money to our account in the meantime, we have the same problem.
Yesterday evening we went live. After a lot of testing, we were finally sure that everything is working on our side. To be safe, we stopped the automated sending of emails and made a backup of the database and then pressed the big red button. The system created a direct debit file and everything looked fine, as it should.
We uploaded the file to the bank, which replied in a pretty unhelpful way: "error in line 1". After some speculation, we found out: the XML file is of course UTF-8 encoded, so it can contain characters from all kinds of languages. But if the file starts with a bit pattern which means "this is a UTF-8 encoded file", the bank doesn't accept it. Okay, no problem, we just removed that bit pattern, since it is optional anyway.
Next try, fingers crossed, error in line 40,000. In that line is a name that contains a turkish i without the dot. It's a totally normal UTF-8 character, but the bank can't deal with it. Okay, next step. There have also been a few wrong BICs. You would think that the bank can deal with things like trailing spaces or lower case letters. But okay, we've also corrected that. After that, we found even more characters, the bank doesn't support, like š. Other characters like ë are working without any problem. Pretty weird stuff.
Highlight of the evening was the "internal server error" we got from the bank after we "fixed" all the character encoding issues. After all the bank finally accepted the file and we started sending the emails. That's what we did so far. Right now we can just sit there and wait. Let's see how many other suprises SEPA will hold for us.
Oh, by the way: the format of the new direct debit files is called "Payments Initiation", or in short: PAIN.
Update 2016-09-12: Nowadays sending the emails to inform our members about the deductions and creating the actual .pain file is a separate process. Meaning that once we sent the emails our members have 2 days to tell us that we should not deduct the membership fee (e. g. not enough money on the bank account, changed bank account details, ...).
Aktuell läuft unsere allererste SEPA Massenlastschrift. Hier ein etwas zynischer Blick hinter die Kulissen:
Wie ihr vielleicht wisst, ist unsere Verwaltungssoftware und auch der Teil, der Mitgliedsbeiträge und Banking macht komplett selbst geschriebene Software. Bisher kam da einmal im Monat eine sogenannte DTA-Datei raus. Ein besonderes Konstrukt der Deutschen Kreditwirtschaft von 1976, der digitalen Steinzeit. Das Format, der Ablauf und die rechtlichen Rahmenbedingungen waren aber bekannt, erprobt und haben über Jahrzehnte gut funktioniert.
Die EU hat eines Tages aber beschlossen, dass Transaktionen zwischen Banken im Euro-Zahlungsraum vereinheitlicht werden sollen. Wir haben uns gefreut, dass Banksachen mal neu spezifiziert und vereinheitlicht wurden. Wir haben uns gefreut, dass wir in Zukunft auch bei Studenten aus Spanien, Italien, oder Polen abbuchen können, anstatt die erstmal zur nächsten Bank schicken zu müssen. Wir haben uns sogar gefreut, dass die nötigen Dateien jetzt im XML-Format vorliegen und damit einfach handhabbar sind.
Aber. Wir müssen 2 Wochen vor einer Abbuchung alle informieren, wann wir wie viel abbuchen. Die meisten von euch interessiert das genaue Abbuchungsdatum nicht und wir wollen auch nicht zu viele E-Mails verschicken. Irgendwann werden die nämlich einfach alle als SPAM aussortiert. Aber wer weiß, vielleicht freut sich ja jemand über diese E-Mails.
Also weiter: Unser System erstellt die Abbuchungsdatei, verrechnet die Beträge in der Datenbank, und schickt alle nötigen Infos per E-Mail. Und da fangen die Probleme auch schon an: wenige Stunden später kommen z.B. die ersten Antworten mit dem Text "ich ziehe zum Ende des Monats aus und mein Bankkonto ist bereits geschlossen". Die Abbuchungsdatei liegt zu diesem Zeitpunkt bereits bei der Bank und wurde signiert und wir können einzelne Abbuchungen nicht mehr stoppen.
Gestern abend war es dann so weit. Nach ausgiebigen Tests waren wir uns sicher, dass alles funktioniert. Wir haben sicherheitshalber den Versand von E-Mails mal angehalten, eine Backup der Datenbank gemacht und dann auf den großen roten Knopf gedrückt. Das System hat eine Abbuchungsdatei erstellt, alles sah gut aus.
Die Datei haben wir direkt an die Bank hochgeladen, die sehr aussagekräftig meinte: "Fehler in Zeile 1". Nach viel Rätselraten haben wir dann herausgefunden: die XML-Datei ist natürlich UTF-8 codiert, darf also alle möglichen Zeichen aus allen möglichen Sprachen enthalten. Wenn die Datei mit einem Bitmuster beginnt, das "hier kommt UTF-8" bedeutet, nimmt die Bank die Datei jedoch nicht mehr an. Okay, geschenkt, nehmen wir das halt raus, das ist sozusagen optional.
Nächste Datei hochgeladen, Daumen gedrückt, Fehler in Zeile 40.000. Da steht ein Name mit einem türkischen i ohne Punkt. Das ist ein ganz normales Zeichen des UTF-8 Zeichensatzes, aber die Bank kann es eben nicht. Nagut, weiter. Es hing dann noch ein einigen falschen BICs. Man könnte erwarten, dass die Bank zumindest solche Dinge wie ein übriges Leerzeichen am Ende verarbeiten kann, aber okay, ist auch geschenkt. Nachdem wir dann noch einige BICs korrigiert hatten (größtenteils waren nur Leerzeichen zuviel), sind wir aber auf noch mehr UTF-8 Zeichen gestoßen, die der Bank nicht schmecken, z.B. š. Andere UTF-8 Zeichen, wie z.B. das ë funktionieren jedoch. Sehr komisch alles.
Krönender Abschluss des Abends war dann ein "Interner Serverfehler" der Bank. Irgendwann hat die Bank die Datei schließlich akzeptiert und wir haben angefangen, die E-Mails rauszuschicken. Das ist der aktuelle Stand. Jetzt können wir nur noch abwarten. Und dann sehen wir schon, was uns noch so um die Ohren fliegt.
Oh, übrigens: das Format der neuen Dateien heißt "Payments Initiation", oder kurz: PAIN.
Update 2016-09-12: Heutzutage sind das verschicken der SEPA Informations E-Mails und die Erstellung der .pain Datei voneinander getrennte Abläufe. Dies hat den Vorteil, dass die Mitglieder nun 2 Tage nach der E-Mail Zeit haben uns über geänderte Kontodaten zu Informieren oder das zum Zeitpunkt der Abbuchung der Mitgliedsbeiträge zu wenig Geld auf dem Konto sein wird.