Zitat geschrieben von baconian
Meine Frage zielt auf die Protokolle HBCI/FinTS eher als auf AqBanking — gibt das Protokoll das überhaupt her? Es scheint nicht, das ist es, was mich so wundert.
Du kannst das ruhig glauben. Das
ist wirlich so, wie es ist. Ich war Anfang der 90er Jahre bei der Firma angestellt, die das einzige damals vorhandene Kundenprodukt entwickelt und angeboten hat. Damals wurde noch über BTX übertragen und es wurden ausschließlich via ScreenScraper die für Handbedienung vorgesehenen Bildschirmseiten ausgelesen. Irgendwann kam man - damals zählte noch die Onlinezeit für die Gebühren - darauf, dass man die Übertragung beschleunigen möchte. Deswegen haben wir mit einigen großen Banken zusammen (ich glaube das waren damals Commerz-, Dresdner- und Bayerische Vereinsbank) die Übertragung über reine "Datenseiten" entwickelt. Sichbare Seiten mussten es sein, weil ein großer Teil der eingesetzten BTX-Decoder die binäre Übertragung (die für sog. Telesoftware damals üblich war) nicht beherrscht haben.
Als Format wurde dann das bis vor kurzem übliche MT940/STA-Format entwickelt, welches auf Grundlage des SWIFT-Formates kreiert wurde. Allerdings wurde SWIFT wiederum nicht 1:1 übernommen, sondern es wurden einerseits "unnötige" Dinge rausgelassen und BTX- und kundenspezifische Erweiterungen hinzugenommen. Und nun kommt's: Zu dieser Zeit gab es bei allen Banken ausschließlich die Batch-Verarbeitung in der Nacht. Man konnte also Umsätze eines Tages grundsätzlich erst am nächsten Morgen nach Ende der Batch-Verarbeitung sehen. Somit bekam man also auch bei xmaliger Abfrage an einem Tag immer nur die Umsätze des Vortages übertragen. Damit war das Datum von/bis, das man abfragte, die kleinste mögliche Einheit und man bekam immer den kompletten Buchungstag ausgeliefert. Damals haben die Programme auch eine zweite Abfrage an einem Tag nicht durchgeführt, wenn dieser Buchungstag schon mal abgefragt worden war. So einfach war das. Damals hat niemand dran gedacht, dass es mal sowas wie Real-Time-Booking geben würde und man alle 5min weitere neue Umsätze dazu bekommen könnte. Das war einfach nicht vorgesehen. Das Übertragungsformat wurde dann später nach HBCI 1:1 übernommen und als Container in HBCI-Datensätze eingestellt, weil die Verarbeitungslogik für MT940 auf Bank- und Kundenseite bereits da war und man nur die reine Übertragung geändert hat. Vor Kurzem wurde dann das Format mit der SEPA-Einführung von MT940 auf SEPA-XML geändert. Wobei aber natürlich wieder nicht alle Banken die Umstellung mit gemacht haben, sondern es noch viele gibt, die die SEPA-Daten mit dem großen Hammer in MT940 einstellen, obwohl es da viele Felder für SEPA-Neuerungen gar nicht gibt. Es bleibt abzuwarten, wie lange es dauert, bis alle Banken das umgestellt haben. Hintergrund: Die Datenformate für Zahlungsaufträge wurden "von oben" vorgeschrieben, es war also ab dem endgültigen Startdatum SEPA verboten, noch Zahlungen in den alten Formaten anzunehmen - deswegen wurden da bei allen Banken die neuen Formate umgesetzt (oder HBCI in dem Bereich ersatzlos komplett stillgelegt), bei der Umsatzauslieferung gab es keinen Zwang, deswegen kann man da einfach weiterwursteln.
Und nun kam es wie es kommen musste. Banken-Rechenzentren sind sehr erfindungsfreudig und haben viel Selbstbewusstsein. Es gibt gibt zwar die div. Festlegungen (in HBCI und im Datenformat). Fast jedes Bank-RZ findet dann aber irgendwas, was sie "doof" finden und was sie viel besser können, also wird es einfach anders implementiert. Weiterhin gibt es welche, die es einfach nicht schaffen, das so zu implementieren, wie es Standard ist - also machen sie es so, wie sie es gerade hinkriegen oder wie sie es verstanden haben. Und auch wenn alle anderen eine gewisse Sache regelkonform machen, dann beharren sie trotzdem drauf, dass das Blödsinn ist und man selbst das viel besser gelöst hat und alle anderen falsch liegen.
Unterm Strich kommt dabei raus, dass HBCI bestenfalls ein netter Vorschlag ist, jedes Bank-RZ setzt ihn anders um. Deswegen müssen die "armen" Programmierer für Software auf der Kundenseite viele viele Sonderbehandlungen für einzelne Banken einbauen, da das Ganze sonst nicht läuft.
Was nun die Identifizierbarkeit des einzelnen Umsatzes betrifft: Es wurde gegenüber den Anfängen niemals was geändert in dem Bereich. Erstens haben die Banken selbst damit kein Problem - also packen sie es sowieso nicht an. Und die Hersteller von Kundensoftware konnten nicht drauf warten, dass die Bank das Problem löst (als es erstmal mit Real-Time-Booking aufkam) sondern mussten sich selbst was einfallen lassen, um sofort weiterarbeiten zu können. Und dann lief es ja wieder - und so blieb es bis zum heutigen Tag.
Wie hibiscus schrieb, wurde mit dem CAMT-Format für SEPA ein eindeutiger Zeitstempel pro Umsatz eingeführt. Aber der ist nur ein KANN-Feld und kein MUSS-Feld. Deswegen wurde das nur sehr vereinzelt auf Bankseite umgesetzt. Man muss sich das so vorstellen, dass die HBCI-Übertragung meistens nur so ein "Rucksack" ist, der am Kernbanksystem dranhängt. Der HBCI-Server erhält Daten vom Kernbanksystem, setzt diese entsprechend um und gibt sie an das Kundensystem nach außen weiter. Er ist letztlich darauf angewiesen, vom Kernbanksystem die Daten zu bekommen, die er benötigt. Sprich, einen eindeutigen Zeitstempel. Wenn es sowas im Kernbanksystem aber nicht gibt, dann kann der HBCI-Server nicht viel machen. Er könnte selbst einen generieren - nur hilft das nichts, weil er bei der nächsten Abfrage die Daten wieder neu vom Kernbanksystem erhält - wieder ohne Stempel. Und seinen eigenen Stempel vom letzten Mal kennt er nicht mehr. Somit wäre diese Kunstprogrammierung für die Erkennung quasi nur vom Kundensystem auf das Banksystem verlagert. Und darauf lassen sich BankEDVler natürlich niemals ein
Also weiterhin ohne.
Die einzige Gruppe, die ich kenne, die den Zeitstempel zuverlässig unterstützen ist das Rechenzentrum FI der Sparkassen. Bei allen anderen fehlt er oder ist er nicht zuverlässig - jedenfalls nicht so, dass ein Kundenprodukt sich darauf stützen könnte. Oder man macht wieder einen Sonderfall: Wenn Quelle = Sparkasse dann Dopplererkennung per Zeitstempel ansonsten per Kunstprogrammierung. Wird natürlich auch niemand machen, der nicht gerade eine Software schreibt, die ausschließlich mit Sparkassen kommuniziert.
Im Übrigen ist die Dopplererkennung nicht so schwierig. Dazu gibt es hier einige Abhandlungen im Forum. Unter anderem auch von mir.
