Aggregierte Open-Banking-Daten sind über Anbieter hinweg inkonsistent. Dieselbe Gehaltszahlung taucht bei jedem Aggregator mit anderem Feldlayout und anderer Vorzeichenkonvention auf, datiert auf den Buchungszeitpunkt statt darauf, wann das Geld tatsächlich floss. Bevor ein Modell sie liest, brauchst du eine Schicht, die jeden Anbieter auf ein kanonisches Schema abbildet und jede Zeile zu etwas anreichert, auf dem eine Kreditentscheidung stehen kann.
PSD2 gab allen Zugang zu Konten. Es gab niemandem ein gemeinsames Format. Zwei Aggregatoren, die dieselbe Bank abrufen, liefern Payloads, die auf Feldebene fast in nichts übereinstimmen, und ein dritter parst PDF-Auszüge in eine vierte Form. Baust du Features auf dem, was der erste Anbieter zufällig sendete, hast du dein Modell an diesen Anbieter gekoppelt. Am Tag, an dem du eine zweite Quelle hinzufügst, oder am Tag, an dem der erste einen API-Version-Bump liefert, bewegt sich deine Einkommenszahl aus Gründen, die nichts mit dem Kreditnehmer zu tun haben.
Ein Schema, und alles bildet sich darauf ab
Die erste Entscheidung ist, ein eigenes kanonisches Transaktionsmodell zu definieren und jeden Anbieter als Adapter hinein zu behandeln, nie umgekehrt. Der kanonische Datensatz fixiert Vorzeichenkonvention, Zeitzonenbehandlung, die Unterscheidung von Buchungs- und Valutadatum und einen einzigen Begriff der Gegenpartei. Jeder Aggregator bekommt eine Mapping-Schicht, die seine Eigenheiten in dieses Modell übersetzt, mit dem Roh-Payload für Lineage aufbewahrt.
- Vorzeichen und Richtung. Manche Anbieter signalisieren Belastungen mit negativem Betrag, manche mit einem separaten Indikatorfeld, manche mit beidem, und gelegentlich widersprechen sie sich. Der Adapter normalisiert auf eine Konvention und verwirft Datensätze, bei denen die zwei Signale kollidieren, statt zu raten.
- Daten. Buchungsdatum, Valutadatum und der Zeitstempel, zu dem der Aggregator den Datensatz abrief, sind drei verschiedene Dinge. Point-in-Time-Korrektheit hängt daran, das richtige zu wählen, also führt das kanonische Modell alle drei und nachgelagerte Features erklären, welches sie nutzen.
- Gegenpartei. Ein Anbieter gibt einen sauberen Merchant-Namen, ein anderer rohe Bank-Narrative, ein dritter eine IBAN und sonst nichts. Das Mapping bewahrt, was existiert, und markiert, was fehlt, damit die Anreicherung weiß, wie viel Arbeit übrig ist.
- Währung und Kontokontext. Multi-Währungs-Konten, Sub-Konten und Pots müssen auf die richtige Kontoidentität aufgelöst werden, bevor irgendetwas über sie hinweg saldiert wird.
Diese Schicht richtig zu bekommen ist unglamourös und ist der Ursprung des meisten Verlässlichkeitsgewinns. Wird ein neuer Anbieter angebunden, schreibst du einen Adapter, und der Rest der Pipeline ändert sich nicht.
Deduplizierung und Identität über Anbieter hinweg
Aggregation vervielfacht das Duplikatproblem. Ein einzelner Anbieter sendet Transaktionen bereits erneut und stellt Pending-Einträge als Settled neu aus. Ruf dasselbe Konto über zwei Anbieter ab, und du bekommst die Transaktion zweimal ohne gemeinsame Kennung. Entity Resolution ist, was überlappende Feeds in ein Ledger verwandelt.
Wir lösen jede Transaktion auf eine stabile Identität aus Betrag, normalisierter Gegenpartei, Buchungsdatum und aufgelöstem Konto auf, kollabieren dann Treffer und führen Herkunft auf dem überlebenden Datensatz. Zwei Dinge machen das schwerer als ein naiver Hash:
- Dieselbe Zahlung kann über Anbieter hinweg andere Beschreibungen und sogar leicht andere Daten tragen, also muss der Match Near-Misses tolerieren, ohne wirklich verschiedene Transaktionen zu mergen.
- Interne Überträge zwischen den eigenen Konten eines Antragstellers sind kein Einkommen und keine Ausgabe. Sind Konten über Anbieter hinweg aufgelöst, entfernt Netting diese Überträge. Verpass es, und jeder Übertrag bläht beide Seiten des Leistbarkeitsbilds auf.
Abstimmung ist die Prüfung, dass das funktioniert hat. Laufender Saldo minus summierte Transaktionen sollte pro Konto aufgehen. Tut es das nicht, gibt es eine Lücke im Feed, und eine Lücke untertreibt das Einkommen. Wir stimmen ab, bevor irgendetwas Nachgelagertes die Daten liest, und halten Konten zurück, bei denen das Ledger nicht aufgeht, statt auf einer Teilhistorie zu scoren.
Anreicherung, und was sie ändern darf
Anreicherung ist, wo eine Rohzeile zum Feature wird. Merchant-Auflösung, Kategorie, ob der Betrag wiederkehrend ist, ob eine Gutschrift nach Gehalt aussieht oder nach einem Same-Day-Übertrag von einer Person. Ein aufgelöstes Merchant-Verzeichnis plus Regeln behandelt die hochvolumigen, eindeutigen Gegenparteien bei nahezu perfekter Präzision und ohne Per-Call-Kosten. Ein Modell behandelt den Long Tail: unerkannte Merchants, Freitext-Zahlungen, Überträge, deren Zweck aus dem Muster erschlossen werden muss.
Zwei Nebenbedingungen halten die Anreicherung ehrlich.
Jedes angereicherte Attribut wird zum Buchungsdatum der Transaktion mit nur damals verfügbarer Information berechnet. Ein letzte Woche aktualisiertes Merchant-Verzeichnis darf nicht genutzt werden, um eine Transaktion von vor sechs Monaten so umzulabeln, dass gegenwärtiges Wissen in eine vergangene Entscheidung leakt. Das ist dieselbe Lookahead-Disziplin, die den nachgelagerten Feature Store regiert, in die Anreicherung hochgezogen, damit der Leak gar nicht erst in die Pipeline gelangt.
Die zweite Nebenbedingung ist ein False-Positive-Budget auf den Kategorien, die Entscheidungsgewicht tragen. Ein Café falsch zu lesen bewegt eine Kreditentscheidung kaum. Eine Kreditrückzahlung als Abo zu lesen oder eine Glücksspiel-Transaktion als Retail kann sie kippen. Wir setzen Präzisions- und Recall-Ziele pro Kategorie, gebunden daran, wie stark jede Kategorie in der Leistbarkeit wiegt, halten ein gelabeltes Eval-Set zurück, das den realen Merchant- und Zahlungsmix abbildet, und verfolgen die Kategorisierungsabdeckung pro Anbieter, sodass eine stille Schema-Änderung als Abdeckungsrückgang auftaucht.
Der Output von all dem ist ein normalisiertes, dedupliziertes, angereichertes Ledger mit Lineage zurück zum Roh-Payload für jedes Feld. Dieser Audit-Trail zählt, wenn eine Entscheidung angefochten wird und du genau zeigen musst, welcher Datensatz, von welchem Anbieter, zu welcher Abrufzeit, ein bestimmtes Feature erzeugt hat. Das Modell, das dieses Ledger liest, ist der einfache Teil. Die Schicht darunter bestimmt, ob das Modell den Kreditnehmer liest oder Anbieter-Rauschen.
Häufige Fragen
Warum nicht direkt auf der Antwort des Aggregators modellieren?
Weil dasselbe Konto über Anbieter und über Abrufe hinweg unterschiedlich aussieht: Feldnamen weichen ab, Vorzeichenkonventionen kippen, Pending-Einträge tauchen als Settled mit neuer Referenz wieder auf. Ein Modell, das auf der Form eines Anbieters trainiert wurde, bricht still, wenn du einen zweiten hinzufügst, und du merkst es in Produktion.
Wie geht ihr mit Anbietern um, die über dasselbe Konto uneins sind?
Wir lösen jede Transaktion aus Betrag, Gegenpartei, Buchungsdatum und Konto auf eine stabile Identität auf und führen Herkunft auf dem gewinnenden Datensatz. Melden zwei Feeds dasselbe Konto, hat einer meist reichere Merchant-Daten, der andere zuverlässigere Salden, also ist die Merge-Regel pro Feld statt Pick-a-Winner.
Was bricht am häufigsten, sobald Open-Banking-Daten live sind?
Consent-Ablauf und stille Schema-Änderungen. Eine Bank ändert ein Beschreibungsformat oder ein Aggregator liefert eine neue API-Version, und die Anreicherungsabdeckung sinkt ohne Fehler. Wir überwachen Field-Fill-Raten und Kategorisierungsabdeckung pro Anbieter, damit Drift als Metrik auftaucht, nicht als Support-Ticket.