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.