Bei Railslove blicken wir auf eine lange Tradition von Projekten zurück, die zumindest immer am Rande etwas mit dem Thema Zahlungsverkehr zu tun hatten. Neben Kreditkartenzahlungen, Wallets und Bitcoin werden auch direkte Bank-Integrationen immer wieder angefragt. Hierzu gibt es zwei Standards, welche einen programmatischen Zugriff auf Bankkonten ermöglichen: HBCI/FinTS und EBICS. Um eine ganz grobe Unterscheidung einzuführen: Ersteres ist eher populär im Bereich von Homebanking-Software, während letzteres eher auf die Bedürfnisse von Geschäftskunden zugeschnitten ist.
„Banking is hard“
- Random dude on the street
Mit EBICS lassen sich z.B. automatisch Kontoauszüge in unterschiedlichen Formaten (MT940, CAMT) abrufen, aber auch das Einreichen von SEPA-Lastschriften und SEPA-Überweisungen wird durch einen EBICS-Zugang ermöglicht. Leider bieten nicht alle Banken Ihren Kunden einen EBICS-Zugang an und dieser ist bei den meisten Banken auch mit einer einmaligen oder monatlichen Gebühr verbunden.
Ein weiterer Punkt, welcher in unseren Augen EBICS gerade für Startups und kleinere Unternehmen bislang unattraktiv gemacht hat, ist die Integration von EBICS in neue Web-Anwendungen, da die Landschaft der EBICS-Implementierungen sehr stark von kommerziellen Angeboten beherrscht wird und in der Regel Java- und/oder Windows-Systeme bedient. Leider sieht es mit bestehenden Bibliotheken für Ruby ebenso spärlich aus, also haben wir uns vor zwei Monaten zum Ziel gesetzt DIE EBICS-Implementierung für Ruby zu entwickeln. Der ganze Standard ist durchweg frei verfügbar, allerdings existiert keine belastbare Referenz-Implementierung. Somit ist man bis auf 350 Seiten PDF und einige XML-Beispiele größtenteils auf sich allein gestellt.
Eigentlich hätte ich erwartet von seltsamen propriäteren Lösungen und eigenwilligen Formaten erschlagen zu werden, allerdings war eher der Gegenteil der Fall :-). Klar, es kommt einem so vor, als wenn das zugehörige Gremium einmal mit dem Einkaufswagen durch eine große Shopping-Mall der Standards gefahren ist, aber nichtsdestotrotz fügt sich alles zu einem durchaus sinnigen Gesamtbild zusammen. So finden unter anderem AES-Verschlüsselung, RSA-Signaturverfahren und XMLSIG Verwendung.
Was bleibt, ist also viel Fleißarbeit und viel Try and Error. Als schwierigster Part erwies sich die notwendige Signatur der Autragsdaten: Zwar wird hierzu RSA verwendet, jedoch bietet die OpenSSL-Implementierung von Ruby (noch) keinen Support für RSA-EMSA-PSS. Dieser Teil musste somit noch implementiert werden.
Die grundlegenden Funktionen des Standards können jetzt schon mit unserem EPICS Gem angesprochen werden, als nächster großer Posten steht noch die „Verteilte Unterschrift“ auf dem Programm, ein meiner Meinung nach sehr interessantes Feature, bei dem Auftragsdaten von mehreren Teilnehmern digital unterzeichnet werden müssen bevor diese von der Bank verarbeitet werden. Komplexe Szenarien wie ein „Vier-Augen-Prinzip“ sind somit also direkt in den Standard eingebaut. Interessanterweise wurde eine sehr ähnliche Funktion (technisch sowie konzeptionell) in Form von multi signature addresses ins Bitcoin-Protokoll aufgenommen.
Auf Basis des EBICS Clients bieten wir unterschiedliche Lösungen an, die es noch einfacher machen, eine bestehende Anwendung mit dem EBICS System zu verbinden. Du möchtest mehr erfahren? Sprich uns an!
Take a look at: https://github.com/railslove/epics
Railslove is a full-service Web Development Agency for all things Ruby and Rails, with a heavy focus on financial applications.
