Blogpost

Effiziente Batchverarbeitung für Verification of Payee (VoP): Eine detaillierte Architektur

Verification of Payee stellt hohe Anforderungen an die effiziente und schnelle Verarbeitung von Finanztransaktionen. Werfen Sie in diesem Blogbeitrag einen Blick auf eine durchdachte Architektur für ein Batchverarbeitungssystem, das speziell für die Verification-of-Payee(VoP)-Lösung BV VoP powered by msg entwickelt wurde.

196
6 Minuten Lesezeit
Headergrafik, Batchverarbeitung für VoP, Verification of Payee

In dieser Collection enthalten:

Collection öffnen

Einführung

In der digitalen Zahlungsverkehrswelt ist die effiziente und schnelle Verarbeitung von Finanztransaktionen entscheidend, insbesondere im Umfeld von Verification of Payee (VoP). Das pain.001-Format ist der Standard für Zahlungsanfragen im SEPA-Raum und spielt eine zentrale Rolle bei der strukturierten sowie maschinenlesbaren Übermittlung von Zahlungsinformationen. Innerhalb des VoP-Kontexts ermöglicht das pain.001-Format die Übermittlung einer Vielzahl von Zahlungsanfragen, wobei eine einzelne Datei mehrere hundert bis tausende Transaktionen enthalten kann.

In diesem Artikel werfen wir einen Blick auf eine durchdachte Architektur für ein Batchverarbeitungssystem, das speziell für die Verification-of-Payee-Lösung BV VoP powered by msg entwickelt wurde.

Das Hauptziel dieses Systems ist es, große Mengen von Batchdateien (Zahlungsverkehrsdateien) im pain.001-Format so zu verwalten, dass die Hauptanwendung nicht überlastet wird. Das ist besonders wichtig, um die Leistung und Verfügbarkeit des VoP-Dienstes sicherzustellen. Durch die Implementierung dieser Architektur wird die asynchrone Verarbeitung von Zahlungsverkehrsdateien im pain.001-Format optimiert, was sowohl den Durchsatz als auch die Zuverlässigkeit des Dienstes erheblich verbessert.

Problemstellung

Ein synchrones Anfrage-/Antwortmodell zur Verarbeitung von Batchdateien bringt mehrere Herausforderungen mit sich:

  • Echtzeiteinschränkungen: Echtzeitverarbeitung kann zu Verzögerungen und Fehlern führen, insbesondere wenn Abhängigkeiten nicht reagieren.
  • Blockierung von API-Anfragen: Durch eine synchrone Verarbeitung von großen Batchdateien im pain.001-Format kann die Hauptanwendung überlasten und deren Fähigkeit zur effizienten Bearbeitung anderer Anfragen verringern.
  • Auto-Scaling-Risiken: In Kubernetes-Umgebungen kann übermäßiges Auto-Scaling von Containern zu erhöhten Kosten führen, ohne die zugrunde liegenden Probleme effektiv zu lösen.

Empfohlene Lösung

Um die oben genannten Herausforderungen zu bewältigen, wird ein Batchverarbeitungssystem empfohlen, das im Hintergrund arbeitet. Dieser Ansatz gewährleistet eine asynchrone Aufgabenverwaltung, was zu einer besseren Ressourcennutzung, höherer Fehlertoleranz und einer verbesserten Leistung der Hauptanwendung führt.

High-Level-Lösungsarchitektur

High-Level-Lösungsarchitektur, VoP, Verification of Payee, pain.001

Abbildung 1: High-Level-Lösungsarchitektur

Die Architektur umfasst mehrere Schlüsselkomponenten, die zusammenarbeiten, um Batchdateien effektiv zu verarbeiten:

  • Akzeptanz der Batchverarbeitungsdatei: Der VoP-Server empfängt eine Batchverarbeitungsdatei im pain.001-Format mit mehreren Transaktionsanfragen zur Zahlungsüberprüfung.
  • Validierung, Dateisplitting und Datenbankeintrag: Nach dem Empfang validiert der VoP-Server das Datenformat und die Integrität. Dabei werden große Dateien in kleinere Pakete aufgeteilt. Gültige Einträge werden in der VoP-Datenbank mit einer eindeutigen Kennung für jede Batchverarbeitung protokolliert. Dadurch kann jeder Batch (Teilstück) parallel verarbeitet werden, um die Verarbeitungsgeschwindigkeit zu erhöhen.
  • Messaging an Redis-Server via PUB/SUB-Mechanismus: Nach der Validierung der Batchdatei wird eine Nachricht mit der eindeutigen Kennung an einen Redis-Server gesendet, der als Nachrichtenbroker fungiert. Der PUB/SUB-Mechanismus (Publish/Subscribe) ist ein Kommunikationsmuster, bei dem Sender (Publisher) Nachrichten an Themen (Topics) senden, ohne dass sie wissen, wer die Empfänger (Subscriber) sind. Subscriber hingegen abonnieren bestimmte Themen und erhalten automatisch alle Nachrichten, die an diese Themen gesendet werden.
    Ein wesentlicher Vorteil des PUB/SUB-Mechanismus ist die Entkopplung von Sender und Empfänger. Diese Entkopplung ermöglicht eine flexible und skalierbare Architektur, da neue Subscriber ohne Änderungen an den Publishern hinzugefügt werden können. Außerdem können Publisher Nachrichten senden, ohne sich um die Anzahl oder den Zustand der Subscriber kümmern zu müssen, was die Wartung und Erweiterung des Systems erleichtert.
    Zusätzlich ermöglicht der PUB/SUB-Mechanismus eine asynchrone Verarbeitung von Nachrichten. Dies erhöht die Effizienz und Reaktionsfähigkeit des Systems, da Publisher nicht auf die Verarbeitung von Nachrichten durch Subscriber warten müssen. Durch die Verwendung von Redis als Nachrichtenbroker profitieren wir von dessen hoher Geschwindigkeit und Zuverlässigkeit bei der Übertragung von Nachrichten, was zu einer insgesamt verbesserten Performance führt.
  • Nachrichtenverarbeitung: Ein Redis-Subscriber in einem separaten Container hört auf neue Nachrichten und verarbeitet die entsprechenden Batchdateien.
    • Verarbeitung der Datensätze:
      • Der Subscriber verarbeitet jeden Datensatz, indem er:
        • Die VoP-Datenbank abfragt, um die Zahlungsdetails zu validieren.
        • Gegebenenfalls externe Systeme für Transaktionen aufruft, die eine externe Validierung erfordern.
      • Nach der Verarbeitung aller Datensätze werden die Ergebnisse in der Datenbank gespeichert.
      • Die Hauptanwendung bietet separate Endpunkte, um den Status der Anfrage zu überprüfen und die verarbeiteten Dateien herunterzuladen.
    • Diesen Prozess nutzt Redis als Nachrichtenwarteschlange, was die Verifizierungsanfragen von der Verarbeitungslogik entkoppelt und die Skalierbarkeit sowie die Fehlertoleranz verbessert.

Schwachstellen und vorgeschlagene Verbesserungen

Ein kritischer Aspekt der System-Resilienz ist die Verfügbarkeit des Redis-Clusters. Es wird ein 3-Node-Setup vorgeschlagen, um Cache-Replikate zu verwalten und potenzielle Ausfallrisiken zu mindern. Die Nodes sind so verteilt, dass eine hohe Verfügbarkeit und Fehlertoleranz gewährleistet ist. Zum Beispiel könnte ein Node in einem Rechenzentrum und die anderen beiden Nodes in separaten geografischen Standorten platziert werden, um das Risiko eines gleichzeitigen Ausfalls aufgrund von Standortproblemen zu minimieren.

Um Datenverluste zu vermeiden, sollte das System nach einem Neustart eines Redis-Servers automatisch die Datenbank nach ausstehenden Verarbeitungseinträgen scannen und diese erneut in die Warteschlange stellen. Dieser Mechanismus stellt sicher, dass alle Nachrichten, die aufgrund eines Ausfalls nicht verarbeitet wurden, wiederhergestellt werden. Durch die Kombination von Node-Verteilung und automatischer Wiederherstellung wird die Resilienz des Systems erheblich verbessert, da es in der Lage ist, auch bei Hardwareausfällen oder Netzwerkproblemen weiterhin zuverlässig zu arbeiten.

Zusätzliche Herausforderungen bei der Verarbeitung von Zahlungsverkehrsdateien

Ein zentrales Problem bei der Verarbeitung dieser Dateien ist, dass das Feld BIC (Bank Identifier Code) im pain.001-Format optional ist. Dies kann zu Schwierigkeiten führen, da der BIC für die korrekte Zuordnung der Empfängerbank und die weitere Bearbeitung der Zahlungsanfragen unerlässlich ist.

Um dieses Problem zu lösen, wird ein BIC-Picker-Service des Kooperationspartners Bank-Verlag genutzt. Dieser Service ermöglicht das Auflösen der Empfänger-IBAN zu dem entsprechenden BIC. Dadurch wird sichergestellt, dass alle notwendigen Informationen für die weiteren Verarbeitungsschritte innerhalb der VoP-Lösung BV VoP powered by msg bereitgestellt werden. Beim BIC-Picker-Service handelt es sich um eine REST-Schnittstelle, dessen Aufruf gesichert ist durch einen API-Key.

Fazit

In der heutigen schnelllebigen digitalen Zahlungslandschaft ist die effiziente Batchverarbeitung von Zahlungsverkehrsdateien im pain.001-Format von zentraler Bedeutung für die Gewährleistung einer zuverlässigen und schnellen Zahlungsabwicklung.

Die vorgestellte Architektur für die Verification-of-Payee-Lösung BV VoP powered by msg adressiert die Herausforderungen der synchronen Verarbeitung, indem sie ein asynchrones System implementiert, das sowohl die Leistung als auch die Verfügbarkeit des Dienstes optimiert. Durch den Einsatz von Technologien wie Redis zur Nachrichtenverarbeitung und einem durchdachten Datei-Management wird die Verarbeitungszeit erheblich verkürzt, während gleichzeitig die Fehlertoleranz erhöht wird.

Die Implementierung eines robusten BIC-Picker-Services zur Auflösung von optionalen BIC-Feldern zeigt, wie durch innovative Lösungen auch komplexe Herausforderungen in der Zahlungsabwicklung gemeistert werden können.

Insgesamt stellt diese Architektur einen bedeutenden Fortschritt dar, der nicht nur die Effizienz der VoP-Lösung steigert, sondern auch die Grundlage für zukünftige Erweiterungen und Verbesserungen im Bereich der Zahlungsverkehrsverarbeitung legt. In einer Zeit, in der Geschwindigkeit und Zuverlässigkeit entscheidend sind, positioniert sich die BV VoP-Lösung als zukunftssichere Antwort auf die Bedürfnisse des Marktes.

Raphael Mustafa

Raphael Mustafa

ist Senior IT Consultant bei msg for banking und verfügt als Fachinformatiker für Anwendungsentwicklung über mehrjährige Berufserfahrung. Insbesondere ist er spezialisiert auf Digital Banking mit Fokus auf containerbasierte Betriebsplattformen. Darüber hinaus bringt er als Certified Professional for Software Architecture (iSAQB) - Foundation Level (CPSA-F) fundiertes Wissen in Softwarearchitektur und objektorientiertem Design mit und wendet agile Methoden für effektive Softwareentwicklung an.

Schreiben Sie einen Kommentar

Sie müssen sich anmelden, um einen Kommentar zu schreiben.