Tool zum Abruf von Kontoauszügen per PHP Volksbank

Hallo liebe Leute.

Ich habe mal ein paar Fragen und weiss nicht wie und wo ich die richtig platzieren kann.

Daher bitte ich um Nachsicht und einen Hinweis, sollte mein Thread hier deplaziert sein.

Für einen Verein begleite ich ehrenamtlich die Mitgliedsverwaltung.

Diese ist kompett webbasiert. Ein ziemlich fitter PHP-Programmierer hat das Ganze von Grund auf programmiert.
Es ist eine komplette Individualsoftware.

Die Software libsepa wurde lizensiert und eingebunden, um die Iban neuer Mitglieder direkt bei Eingabe zu überprüfen.

Einmal im Jahr wird eine Lastschriftdatei erzeugt, in ein externes Online-Bankingprogramm eingelesen und an die Bank übertragen.

Dann werden händisch die Kontoauszüge gezogen und die Lastschriftrückläufer ebenfalls händisch erfasst.

Nun gibt es den Wunsch, diese Arbeit zu automatisieren.

Außerdem soll es zukünftig eine Möglichkeit geben, online in den Verein einzutreten. Hierzu soll nach einem Opt-In-Verfahren, das neue Mitglied eine vorläufige Nummer erhalten. Der ermittelte Erstbeitrag und die Kontoinformationen werden ebenfalls genannt.

Wenn das neue Mitglied den Betrag unter Angabe der vorläufigen Nummer auf das Konto überwiesen hat (Zahlungseingang), soll eine Nachricht rausgehen, dass die Mitgliedschaft nun gültig ist.

Danach wird für dieses mitten im Jahr eingetretene Mitglied ebenfalls eine Lastschrift erstellt.

Nun kommen meine Fragen:
Gibt es eine Möglichkeit, automatisiert per PHP zyklisch (täglich) die aktuellen Kontobewegungen von einem Volksbank-Konto abzuholen, und zu parsen?
Gibt es Codeschnipsel oder Softwareprodukte wie z. B. libsepa, mit denen man das integriert in den eigenen PHP-Code realisieren kann (natürlich auch kostenpflichtig).

Wie gewährleiste ich, dass der ausschließlich der Abruf der Informationen automatisiert werden soll. Wie kann ich dafür sorgen, dass ein automatischer Dienst, der den Abruf realisiert, zu 100% nicht mehr Rechte bekommt als eben den Abruf der Umsatzinformationen.


Welche Lösungsansätze gibt es für solche Problemstellungen?

Ich bitte um Schlagworte, Tipps, Lösungen, Denkansätze.

Vielen lieben Dank bereits im Voraus.

Gruß

absolute_beginner

Das kommt etwas drauf an, wie "groß" das Ganze ist und wie viel es kosten darf. Bis letzte Woche wäre das recht einfach über HBCI abbildbar gewesen. Entweder über eine Bankingsoftware, die "von außen gesteuert", also z.B. per Befehlszeile, Umsätze regelmäßig abholt und bereitstellt. Diese Umsatzdatei (heutzutage kommt das üblicherweise im CAMT-Format als XML-Datei von der Bank) kann dann von der Vereinsverwaltung gelesen und interpretiert werden und die entsprechenden Schritte dann unternommen werden. Hierfür gibt es auch entsprechende Parser-Bibliotheken, z.B. von der Firma Subsembly. Alternativ könnte man aber auch von dem Programm, mit dem man die Umsätze abholt, diese als CSV-Datei für die Verwaltung bereitstellen lassen und diese dann mehr oder weniger direkt verarbeiten.

Spätestens zum 14.9. (Startdatum der Zahlungsverkehrsverordnung PSD2) ist das nicht mehr so einfach, weil es dann die sogenannte 2-Faktor-Authentisierung benötigt, das heißt, je nach Bank ist bei jedem Login - alternativ mindestens alle 90 Tage - eine TAN zusätzlich nötig. Damit ist der Abruf dann nicht mehr komplett automatisierbar - irgendwer muß die TAN ja erzeugen und eingeben.

Wenn der Verein groß und finanziell potent genug ist, könnte man auf den Firmenkundenstandard EBICS setzen. Dies ist unter'm Strich ein Filetransfer - Umsatz-Dateien von der Bank zum Kunden und Zahlungsverkehrsdateien vom Kunden zur Bank. Damit ist das, was Euch vorschwebt, auf jeden Fall lösbar. Aber EBICS ist entsprechend teuer, zwar von Bank zu Bank unterschiedlich, aber es gibt nicht unterhebliche laufende Bankgebühren und die nötige Software ist auch "in einer anderen Klasse" und entsprechend teuer (meist mit regelmäßigen Wartungsvertragskosten).

Praktisch ist es noch dazu so, dass HBCI-Zugänge nur für "natürliche Personen" erstellt werden, es muß also "jemand" den Abruf erledigen. Wobei es durchaus möglich ist, dass der jemand einen nur-Abruf-Zugang erhält, also keine Zahlungen mit seinem Zugang veranlassen kann.

Im Falle von EBICS ist das Ganze gar kein Problem, da können die Berechtigungen sehr fein unterschieden werden und da gibt es auch die Möglichkeit, einen sog. "technischen Teilnehmer" einzurichten, der NUR Dateien übertragen kann. Damit kann er dann Umsätze abholen und (nicht unterschriebene) Zahlungsverkehrsdateien auf den Bankrechner senden. Diese können dann von berechtigten Personen im Nachgang auf dem Bankrechner signiert werden (mit Einzel- oder Mehrfachzeichnungsberechtigungen - auch zeit- und orts-unabhängig voneinander) und damit zur Ausführung gebracht werden.

Es hängt also alles davon ab, um was genau es geht. Wenn es sich um einen Verein in der Größe des FC Bayern handelt, dann ist das über EBICS alles problemlos machbar, wenn es sich "nur" um die "Freunde der Feuerwehr Hintertupfing" handelt, dann wäre das viel zu teuer und zu aufwändig mit EBICS. Dann müßte man wohl auf eine "halbautomatische" Lösung via HBCI hinaus.

So wie ich das lese, wirst Du HBCI verwenden "müssen". Eine vollständige Automatisierung ist damit nicht machbar, siehe 2-Faktor-Authorisierung gemäß PSD2. Zwar machen viele VR-Banken von der Ausnahme "TAN zum Login nur alle 90 Tage" Gebrauch, aber wann die TAN-Abfrage wirklich kommt, kann man vorher nie sagen - das weiß man erst, wenn sie da ist. Wenn also bei der Abfrage niemand zugegen ist, dann geht es nicht weiter und die Abfrage wird abgebrochen. Und TAN-Anforderungen des Bankrechners falsch zu beantworten oder abzubrechen ist keine gute Idee, wenn man das mehrach macht, wird der Zugang gesperrt.

Parser als Freeware sind mir nicht bekannt. Die FinTS-API und die FinTS-Tools von Subsembly wären "Baukästen", um daraus soetwas zu entwickeln, was Dir vorschwebt. Allerdings ist das kommerzielle Software, die lizenziert und damit bezahlt werden muss. Ich gehe davon aus, dass das insoweit nicht das Richtige für Dich ist. Auch finde ich für das, was Du planst, den Weg "alles incl. Parsen" selbst zu machen, den falschen Weg. Die Banken ändern ständig irgendwas an ihren Systemen und Dialogen und Dateiformaten - das musst Du dann jedes Mal selbst nachvollziehen und dann bist Du dauernd damit beschäftigt, die Lösung am Laufen zu halten. Bei einem Großkonzern mag das angehen, bei einem kleinen Verein ist es Unfug, sich so etwas anzutun.

Ich würde Dir einen anderen Weg empfehlen. Die gesamte Bank-Kommunikation würde ich (so weit wie möglich automatisiert) über ein Banking-Programm durchführen. Dieses liefert die Umsätze des Bankkontos nach der regelmäßigen Bankkommunikation in Form einer Exportdatei in einem bestimmten Format - z.B. eben als CSV-Datei. Diese kannst Du dann direkt in die Softwareumgebung übernehmen und weiterverarbeiten und die bereitgestellte Datei dann löschen. Du verarbeitest ohne weiteres geparse die Umsätze und machst daraus, was Du möchtest. Bei der nächsten Kommunikation wird wieder eine Datei bereitgestellt, verarbeitet und danach gelöscht. Ganz simpel.

Der umgekehrte Weg geht genauso. Deine Anwendung schreibt eine Übergabedatei - sei es direkt eine SEPA-XML-Datei oder auch wieder eine CSV-Datei mit den Zahlungsaufträgen - das können Überweisungen oder aber auch Lastschriften sein. Diese Datei wird in die Zahlungsverkehrssoftware eingelesen und an den Bankrechner übertragen. Dies muss in jedem Falle von einer Person gemacht werden, weil der Auftrag ja signiert werden muss - also irgendwie unterschrieben - sei es mit TAN oder HBCI-Schlüssel oder was auch immer. Durch ein derartiges Vorgehen sparst Du Dir, ewig auf die Veränderungen auf Bankseite eingehen zu müssen, denn das macht der Softwarehersteller durch seine Updates. Du hast die "interne Schnittstelle" durch die Export- und Import-Dateien, die bleibt gleich. Electronic-Banking selbst zu programmieren - auch unter Verwendung von Bibliotheken - ist hochkomplex und nicht einfach mal zu machen. Du steckst da sehr viel Forschungsarbeit rein und ob Du ans Ziel gelangst ist alles andere als sicher. Quasi die Neuerfindung des Rades - das bringt's einfach nicht.

Praktisch würde ich Dir raten, Dir mal "Subsembly BankingZV" anzuschauen. Das ist das Banking-Programm von Subsembly für die professionelle Verwendung - incl. Lastschriften usw. Der große Vorteil dieses Programmes (zumindestens der Windows-Version, mit der arbeite ich) ist, dass es eine CommandLine-Schnittstelle hat. Du kannst also das Programm via Aufrufzeile beauftragen, ein oder mehrere Konten abzurufen und die neuen Umsätze in einer entsprechenden Export-Datei bereitzustellen. Das geht dann ganz von allein und Du kannst es weiterverarbeiten. Entsprechend kannst Du auch über die Befehlszeile das Programm starten und bereitgestellte Lastschriften oder Zahlungen einlesen, die dann im Programm vorliegen. Zur Ausführung muss dann "ein Mensch" das Programm von Hand starten und die Aufträge mit Signatur oder TAN oder wie auch immer übertragen. Fertig. Das Programm muß zwar natürlich lizenziert werden, aber die Kosten sind im Gegensatz zu manch anderen Programmen überschaubar und wohl die bei weitem günstigste Lösung, das zu realisieren, was Dir vorschwebt.

Die Geschichte mit dem Abgleich kannst Du in Deiner Umgebung an Hand der vorliegenden Umsätze problemlos machen. Nun ja, so problemlos wie die Neumitglieder erkenn- und auswertbare Verwendungszwecke in Ihre Zahlungen reinschreiben... Und bei den Lastschriften geht es ähnlich - Du erzeugst in Deiner Anwendung die entsprechenden Lastschriften und übergibst sie ans Bankprogramm und überträgst sie. In der Anwendung stehen die Beiträge dann gleich auf bezahlt - bzw. dann, wenn in den Umsätzen der verbuchte Sammler wieder erscheint. Falls bei einzelnen Mitgliedern die Lastschrift nicht eingelöst wird, kommt für jede Zahlung ein Umsatz mit RETOURE. In der Retoure sit eine eindeutige Kennzeichnung, die Du vorher der Lastschrift mitgegeben hast, wieder zu finden und damit kannst Du das dann dem Mitgliedskonto automatisiert wieder rückbelasten.

Bei VR gibt es mehrere mögliche Zugangsvarianten. Einmal PIN/TAN mit TAN über Girokarte+TAN-Generator oder als TAN via Smartphone-App. Diese Verfahren führen zu der "halbautomatischen" Arbeit wie geschildert. Dann gibt es noch HBCI mit VR-Networld-Card (eine Chipkarte mit Schlüsseln). Diese muß zur Übertragung in einen Chipkartenleser gesteckt werden und an diesem eine Karten-PIN eingegeben werden. Also auch halbautomatisch. Schließlich gibt es noch den HBCI-Zugang mit Schlüsseldatei. Da steckt der bei der Initialisierung erzeugte Schlüssel in einer Datei - auch über eine PIN gesichert. Das letztere Verfahren ist im Hinblick auf PSD2 "fragwürdig", hier kommt es auf die einzelne VR-Bank an, ob sie das Verfahren noch anbietet, schon abgeschafft hat oder ob da nach Privat- und Firmenkunden unterschieden wird. Da ist jede VR-Bank selbstständig, wie sie es handhabt. Alles in Allem würde ich mich aber mit HBCI mit Schlüsseldatei nicht mehr beschäftigen, das wird wohl kein ewiges Leben mehr haben. Ich würde Dir ein PIN&TAN-Verfahren für den halbautomatischen Betrieb empfehlen. Für die Verfahren mit Chipkarten kommen übrigens ausschließlich kommerzielle Banking-Programme in Frage, diese sind so kompliziert zu programmieren, dass es keine einzige nichtkommerzielle Anwendung gibt, die das kann.

Noch zwei Anmerkungen:

Der Abruf plus Export plus Upload irgendwohin kann ja darauf reduziert werden, stündlich/täglich/wöchentlich einen BatchJob aufzurufen, der der Reihe nach über CLI den Abruf macht, den Export macht und das Ergebnis dann per SFTP oder irgend einem anderen Protokoll dort hinlädt, wo Du es weiterverarbeitest. Sinnig ist, wenn jemand in den letzten Tagen des 90-Tage-Zeitraums "zuschaut" und dann ggf. die Login-TAN eingibt.

Zu den Zahlungsaufträgen: Selbst die XML zu schreiben ist natürlich schön, diese kann auch problemlos in die Bankingsoftware eingelesen und damit übertragen werden. ABER: Ich würde es nicht so machen. Erster Grund ist, dass es heute leider nicht mehr so wie zu DTAUS-Zeiten ist, wo das Format einmal in den 60ern erfunden wurde, dann um 2000 rum auf EUR angepaßt wurde und so weitergelebt hat, bis es aufgegeben wurde. Heutzutage wird das XML-Format alle Nase lang fortgeschrieben und verändert, das muss dann jedes Mal nachgezogen werden. Das sollte man sich genau so wenig antun, wie die Umsatzdateien selbst zu parsen. Das kann die Bankingsoftware, die eh laufend angepaßt wird, viel besser. Weiterer Nachteil: Wenn man eine XML schreibt, dann kommen im Kopf "Summen" hinein, das heißt, man muss alle Zahlungen bereits kennen, um das richtig zu schreiben. Ich finde es da viel praktischer, wenn man sich auf das CSV-Importformat der Bankinganwendung zurückzieht. Da kann man in eine Datei immer wenn es anfällt einen Zahlungssatz reinschreiben, schön nacheinander und irgendwann. Wenn man dann meint, es sollte ausgeführt werden, dann transferiert man diese Datei einfach auf den Rechner mit der Bankingsoftware, löscht bzw. verschiebt sie auf dem Ursprungssystem und liest sie in die Bankingsoftware ein. Dort kann man die Zahlungen ggf. nochmal durchschauen und prüfen und dann als Einzelaufträge versenden oder ggf. als Sammelauftrag. Die XML für die Übertragung generiert die Software im Hintergrund selbstständig. Wenn Du Dir die Arbeit machst und selbst eine XML schreibst, wird diese beim Import sowieso wieder aufgedröselt und hinterher passend neu geschrieben. Auch dieses Holen der Zahlungs-CSV und Einlesen kann wieder über einen Batch vollautomatisch gemacht werden. Nur das Absenden und signieren muss dann der zuständige Mensch machen.

Alles in Allem sollte sich da eine sehr komfortable weitgehend automatisierte Lösung bauen lassen, die umter'm Strich auch noch verhältnismäßig günstig wird.

Bezüglich PHP werfe ich mal noch folgende PHP-Klasse hier rein:
https://github.com/nemiah/phpFinTS


HBCIFM99 kannte ich noch gar nicht - werden aber ab 2020 auch Lizenzgebühren für die DDBAC-Nutzung fällig...