The “P” in “SEPA” is for Pain
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, …).