Bankwesen, Treasury und ISO-20022-Konnektivität
Zahlungen ausgehend, Kontoauszüge eingehend, in jeder Währung automatisch abgestimmt
Treasury-Teams geben Zahlungen noch manuell erneut ein und gleichen Auszüge von Hand ab
Viele Treasury-Teams erfassen Zahlungen in Bankportalen, sammeln Auszüge in unterschiedlichen Formaten von jeder Bank und stimmen Konten zum Monatsende in Tabellen ab. Jeder manuelle Schritt ist eine Verzögerung, ein Kostenfaktor und eine Gelegenheit für Betrug oder Fehler.
Die Banken stellen außerdem auf ISO 20022 um, den internationalen Standard für Finanznachrichten, der reichere, strukturierte Daten trägt als die älteren SWIFT-MT-Formate. Systeme, die ihn nicht erzeugen und lesen können, geraten gegenüber ihren Banken ins Hintertreffen.
Was sich für Sie ändert
Durchgängige Verarbeitung
Freigegebene Zahlungsläufe verlassen das ERP als signierte Dateien oder API-Aufrufe, und Auszüge kommen in einer Form zurück, die das ERP selbst zuordnet.
Ein schnellerer Abschluss
Mehrwährungsabstimmung, die täglich läuft, statt manueller CSV-Uploads und Tabellenkorrekturen am Monatsende.
Jede Ausnahme bei einer Person
Abgelehnte Zahlungen und nicht zugeordnete Zeilen landen mit dem Grund in einer Ausnahmewarteschlange und gehen nie in einem Postfach verloren.
Was wir liefern
Host-to-Host- und direkte Bankanbindung
Verbindungen über SFTP, EBICS und SWIFT sowie Open-Banking- und direkte Bank-APIs, je nach Bank und Land gewählt.
Erzeugung von Zahlungsdateien
ISO-20022-pain.001-Zahlungsdateien aus Ihren Zahlungsläufen, validiert gegen die Variante jeder Bank und signiert oder verschlüsselt, wie sie es verlangt.
Status- und Ablehnungsbehandlung
pain.002-Statusberichte werden zurückgelesen, sodass jede Zahlung als angenommen, abgelehnt oder ausstehend erscheint, mit dem Grundcode der Bank.
Einlesen von Kontoauszügen
camt.053- und MT940-Tagesauszüge und Intraday-Berichte werden gesammelt, auf Lücken und Duplikate geprüft und ins ERP geladen.
Interbanken-Nachrichten für Banken und Fintechs
pacs-Nachrichten für Überweisungen und ihren Status zwischen Finanzinstituten, angebunden an die Hauptbücher des Core Banking.
Mehrwährungsabstimmung
Zuordnungsregeln, die offene Posten über Währungen und Konten hinweg automatisch ausgleichen und den Rest an eine Ausnahmewarteschlange geben.
Bank-Testnachweise und Runbooks
Die Testfälle jeder Bank werden ausgeführt und für Ihre Prüfer aufgezeichnet, dazu Warnungen bei fehlenden Dateien, fehlgeschlagenen Überweisungen und ablaufenden Schlüsseln oder Zertifikaten.
So arbeiten wir
Banken und Abläufe erfassen
Wir listen Ihre Banken, Konten, Zahlungsarten und heutigen manuellen Schritte auf und vereinbaren, welche Abläufe zuerst gehen.
Jedes Format spezifizieren
Wir arbeiten mit dem Implementierungsleitfaden jeder Bank und schreiben die Zuordnung, einschließlich Signierung, Verschlüsselung und Dateibenennung.
Konnektoren bauen
Wir bauen Zahlungsexport, Statusimport, Auszugsimport und Zuordnung, mit automatisierten Tests für jedes Format.
Mit jeder Bank testen
Wir führen die vereinbarten Testfälle in der Testumgebung der Bank aus und beheben, was die Validierung der Bank zurückweist.
Bank für Bank live gehen
Wir stellen eine Bank nach der anderen um, wobei der laufende Prozess als Rückfall bereitsteht, bis der neue sich bewährt hat.
Überwachen und betreuen
Wir beobachten Überweisungen, Schlüssel und den Ablauf von Zertifikaten und planen Formatänderungen, sobald Banken sie ankündigen.
Seitwärts scrollen, um die ganze Zeichnung zu sehen.
ERP zur Bank: Zahlungen hinaus, Kontoauszüge herein
Freigegebene Zahlungen verlassen das ERP als signierte ISO-20022-Dateien über einen host-to-host-Kanal. Statusberichte und Kontoauszüge kommen denselben Weg zurück und werden offenen Posten zugeordnet. Ablehnungen und nicht zugeordnete Zeilen gehen mit dem Grund an Ihr Team.
- Primärer Ablauf
- Asynchron
- Fehlerpfad
Der Ablauf in 10 Schritten
Der Ablauf Schritt für Schritt
- Von ERP nach Integrationsschicht: Freigegebener Zahlungslauf, über REST/JSON · IDoc (primärer Ablauf).
- Von Integrationsschicht nach Sicherer Bankkanal: Signierte und verschlüsselte Zahlungsdatei, über ISO 20022 pain.001 · OpenPGP (primärer Ablauf).
- Von Sicherer Bankkanal nach Bank: An die Bank übermittelt, über SFTP H2H (primärer Ablauf).
- Von Bank nach Sicherer Bankkanal: Statusberichte und Kontoauszüge, über pain.002 · camt.053 · MT940 (asynchron).
- Von Sicherer Bankkanal nach Integrationsschicht: Abgeholt und validiert, über SFTP H2H (asynchron).
- Von Integrationsschicht nach Abstimmungs-Engine: Kontoauszugszeilen, über camt.053 (asynchron).
- Von Abstimmungs-Engine nach ERP: Zugeordnete Buchungen verbucht, über REST/JSON (primärer Ablauf).
- Von Integrationsschicht nach Treasury- und Finanzteam: Abgelehnte Zahlungen mit Grundcode, über pain.002 RJCT (Fehlerpfad).
- Von Abstimmungs-Engine nach Treasury- und Finanzteam: Nicht zugeordnete Zeilen: eine Abstimmungsdifferenz (Fehlerpfad).
- Von Treasury- und Finanzteam nach ERP: Korrigiert und erneut übermittelt (Fehlerpfad).
Seitwärts scrollen, um die ganze Zeichnung zu sehen.
Open Banking: Daten und Zahlungen mit Einwilligung des Kunden
Der Kunde erteilt seine Einwilligung, der Konnektor hält die Tokens, und jeder Aufruf bei der Bank wird autorisiert und protokolliert. Wenn eine Einwilligung abläuft oder zurückgezogen wird, fragt die App den Kunden erneut, statt stillschweigend zu scheitern.
- Primärer Ablauf
- Asynchron
- Fehlerpfad
Der Ablauf in 7 Schritten
Der Ablauf Schritt für Schritt
- Von Kunde nach Ihre App oder Plattform: Erteilt Einwilligung (primärer Ablauf).
- Von Ihre App oder Plattform nach Open-Banking-Konnektor: Konto- und Zahlungsanfragen, über REST/JSON (primärer Ablauf).
- Von Open-Banking-Konnektor nach Bank-APIs oder Aggregator: Autorisierte API-Aufrufe, über OAuth 2.0 · FAPI · REST (primärer Ablauf).
- Von Bank-APIs oder Aggregator nach Open-Banking-Konnektor: Salden, Transaktionen und Zahlungsstatus, über REST/JSON · webhook (asynchron).
- Von Open-Banking-Konnektor nach ERP oder Hauptbuch: Vereinheitlichte Transaktionen, über REST/JSON (primärer Ablauf).
- Von Bank-APIs oder Aggregator nach Open-Banking-Konnektor: Einwilligung abgelaufen oder zurückgezogen, über HTTP 401 · 403 (Fehlerpfad).
- Von Open-Banking-Konnektor nach Ihre App oder Plattform: Kunde um Erneuerung der Einwilligung gebeten (Fehlerpfad).
Standards, Formate und Kanäle
Wir bauen nach dem Implementierungsleitfaden jeder Bank, nicht allein nach dem Standard. Die Nennung eines Produkts bedeutet keine Partnerschaft mit seinem Anbieter.
- Banking-Standards und -Kanäle
- ISO 20022
- pain.001
- pain.002
- camt.052
- camt.053
- camt.054
- MT940
- MT942
- Swift
- EBICS
- SFTP (H2H)
- OpenPGP
- PSD2
- Berlin Group NextGenPSD2
- UK Open Banking Standard
- FAPI
Nachweis im Produktivbetrieb
Für eine Tier-1-Bank und einen regionalen Mischkonzern aus der Golfregion haben wir SAP S/4HANA über ISO 20022 an regionale Bankkanäle angebunden. Zahlungen werden signiert, Ausnahmen landen in Dead-Letter-Queues, und die Abstimmung über die Bankkonten ist automatisch.
So beginnen
Klare Anforderungen an Banken und Formate gehen direkt in ein Angebot. Mehrere Banken, Länder oder eine undokumentierte Altschnittstelle beginnen meist mit dem Blueprint Studio oder der Brownfield-Diagnosebrücke.
Wie es weitergeht
Beratungsvorgespräch
Ein kostenlose 30-minütige Online-Vorberatung: Wir gehen Ihre Ziele, Systeme und Rahmenbedingungen durch.
Readiness-Review
In einer kostenlose 48-stündige Readiness-Review prüft ein Principal Architect Ihr Projekt gegen die 6-Punkte-Definition of Ready und empfiehlt den passenden Track.
Wahl des Tracks
Projekte mit klarem Leistungsumfang erhalten innerhalb von 3–5 Werktagen ein verbindliches Angebot. Projekte in der Konzeptphase starten im Blueprint Studio. Ein laufendes System, das ausfällt, nicht dokumentiert ist oder integriert werden muss, beginnt mit einer Diagnose von 1–2 Wochen. Blueprint Studio und Diagnose haben jeweils ein festes Honorar, das im Angebot genannt wird.
Umsetzung in fünf Phasen
Mobilisierung, Sprints mit Live-Demonstrationen, Integration und Härtung, Abnahme und Inbetriebnahme, dann Managed Services. Nach dem Start folgt eine Gewährleistungsfrist, danach optional Support und Wartung.
Projekte mit festem Ergebnis und Managed Services rund um die Uhr
Lieferung mit festem Umfang und Meilensteinen unter benannten Delivery-Leads sowie Application Managed Services rund um die Uhr unter SLA-Governance.
Eingebettete Spezialisten und strategische Verstärkung
Nearshore und vor Ort eingesetzte Principal Engineers und Spezialisten sowie eingebettete Lösungs-, Transformations-, PQC- und Integrationsarchitekten.
Fragen und Antworten
Was ist ISO 20022, und warum ist es wichtig?
ISO 20022 ist der internationale Standard für Finanznachrichten. Seine XML-Nachrichten tragen strukturierte Daten wie vollständige Namen, Adressen und Verwendungszwecke, die die älteren SWIFT-MT-Formate nicht können. Banken und Zahlungssysteme sind darauf umgestiegen, sodass darauf aufgebaute Zahlungs- und Auszugsdateien besser abgestimmt werden und Compliance-Prüfungen häufiger bestehen.
Mit welchen Bankformaten und Kanälen arbeiten Sie?
Wir nutzen pain.001 für Zahlungen, pain.002 für Status, camt.052, camt.053 und camt.054 für Kontoberichte und pacs-Nachrichten zwischen Banken. Wir lesen auch die MT940- und MT942-Auszüge, die viele Banken noch senden. Der Transport erfolgt über Host-to-Host-SFTP, EBICS, SWIFT oder Bank-APIs. Jede Bank hat ihre eigene Variante jedes Formats, deshalb bauen wir nach ihrem Implementierungsleitfaden.
Welche ERP-Systeme können Sie an Banken anbinden?
SAP S/4HANA, Oracle Fusion Cloud ERP und NetSuite, Microsoft Dynamics 365, Odoo und Sage sowie Treasury- und individuelle Systeme. Hat das ERP ein eigenes Bankkommunikationsmodul, konfigurieren und erweitern wir es, statt daran vorbei zu bauen.
Wie sichern Sie Zahlungsdateien ab?
Zahlungsdateien werden signiert und verschlüsselt, wie jede Bank es verlangt, und laufen nur über den vereinbarten Kanal. Schlüssel und Zertifikate liegen in Ihrem Key Vault oder Hardware-Sicherheitsmodul, nie im Code. Dateien werden vor dem Versand validiert, und jede Überweisung wird protokolliert, sodass Sie nachvollziehen können, wer jede Zahlung freigegeben und gesendet hat.
Was geschieht, wenn eine Auszugszeile nicht zugeordnet wird?
Sie landet auf einer Prüfliste mit den wahrscheinlichen Kandidaten und dem Grund, warum sie nicht passte, etwa ein abweichender Betrag oder eine fehlende Referenz. Ihr Team gleicht sie dort aus, und die Regeln lassen sich anpassen, damit derselbe Fall beim nächsten Mal zugeordnet wird. Nichts wird ins Hauptbuch gebucht, ohne eine von Ihnen freigegebene Zuordnung.
Was bestimmt das Tempo einer Bankintegration?
Meist die Bank, nicht der Code. Jede Bank legt ihre Onboarding-Schritte, Testfenster und Freigaben fest, und manche brauchen Verträge oder Schlüsselaustausch, bevor das Testen beginnen kann. Nach der Zuordnung erhalten Sie einen Plan je Bank und beginnen mit der Bank zu testen, die zuerst bereit ist.
Was geschieht, wenn eine Bank ihr Format ändert?
Banken kündigen Formatänderungen vorher an, wie viele beim Wechsel von SWIFT MT auf ISO 20022. Wir verfolgen diese Mitteilungen für die Banken, die wir anbinden, bewerten die Auswirkungen und planen die Änderung samt Tests mit der Bank vor ihrer Frist.
Bereit zu bauen? Fragen Sie nach einem Angebot.
Senden Sie Ihre Anforderungen oder Ausschreibung. Unsere Architekten prüfen sie und liefern ein verbindliches Angebot mit festem Umfang.
Wie es weitergeht
Readiness-Review
In einer kostenlose 48-stündige Readiness-Review prüft ein Principal Architect Ihr Projekt gegen die 6-Punkte-Definition of Ready und empfiehlt den passenden Track.
Verbindliches Angebot
Nach Architekturvalidierung kostenfrei erhalten Sie innerhalb von 3–5 Werktagen ein verbindliches Angebot mit festem Leistungsumfang: Meilensteine, Architektur, Teamstruktur und SLAs. Wir unterzeichnen auf Wunsch eine Geheimhaltungsvereinbarung (NDA) mit Ihnen, bevor Sie Ihre Anforderungen teilen.
Mobilisierung
Sobald Sie unterzeichnen, beginnen unsere Engineering-Pods innerhalb von 5–10 Werktagen nach Vertragsunterzeichnung mit Sprint 0.
Umsetzung in fünf Phasen
Mobilisierung, Sprints mit Live-Demonstrationen, Integration und Härtung, Abnahme und Inbetriebnahme, dann Managed Services. Nach dem Start folgt eine Gewährleistungsfrist, danach optional Support und Wartung.