Kontoauszug-Parsing und Einkommensprüfung mit Produktionsgenauigkeit

Einer aus einem Kontoauszug abgeleiteten Einkommenszahl können Sie erst dann vertrauen, wenn drei Dinge zutreffen: Die Extraktion übersteht die chaotischen PDFs, die Kunden tatsächlich hochladen, jede abgeleitete Zahl lässt sich auf die Transaktionen zurückführen, aus denen sie stammt, und Sie messen die Genauigkeit an einem zurückgehaltenen Set, das Ihren echten Verkehr widerspiegelt statt an den sauberen Demo-Dateien. Lassen Sie eines davon weg, und die Zahl ist eine Schätzung, die sich mit einem Dezimalpunkt schmückt.

Kontoauszug-Parsing gehört zu den Problemen, die für etwa einen Nachmittag als gelöst erscheinen. Sie verdrahten einen Extraktor, füttern ihn mit vier PDF-Auszügen von zwei Banken, sehen zu, wie er Transaktionen herauszieht und die Gehaltsgutschriften aufsummiert, und die Zahl stimmt. Dann richten Sie ihn auf einen Monat echter Anträge, und die Genauigkeit, die Sie zu haben glaubten, verpufft. Das Demo-Set waren die einfachen 10 Prozent. Die übrigen 90 sind die eigentliche Arbeit.

Das Dokument ist der schwierige Teil, nicht das Modell

Der Großteil des Scheiterns bei der Einkommensprüfung passiert, bevor überhaupt eine Einkommenslogik läuft. Es passiert bei der Extraktion, denn “ein Kontoauszug” ist nicht ein einziges Format.

Der reale eingehende Verkehr umfasst nativ digitale PDFs mit sauberer Textebene, Scans von Ausdrucken, Handyfotos von Scans, Bildschirm-Exporte aus Mobile-Apps, CSV-Downloads und gelegentlich eine passwortgeschützte Datei, bei der das Passwort das Geburtsdatum des Kunden in einem Format ist, das niemand dokumentiert hat. Jede Bank legt die Spalten anders an. Manche packen Soll und Haben in eine vorzeichenbehaftete Spalte, manche in zwei. Der Saldo wird über die Seiten hinweg fortgeschrieben, und der laufende Saldo ist Ihr bester Freund für die Validierung, sofern Sie ihn lesen können.

Die erste Entscheidung ist daher das Routing. Erkennen Sie, ob ein Dokument eine nutzbare Textebene hat, und wählen Sie in diesem Fall den strukturierten Pfad; greifen Sie erst dann auf OCR für Kontoauszüge zurück, wenn es sein muss, denn OCR führt Fehler auf Zeichenebene genau bei den Ziffern ein, auf die es ankommt. Eine 1, die als 7 fehlgelesen wird, verändert die Einkommenszahl, gegen die ein Kredit vergeben wird.

Richten Sie den Extraktor auf ein strukturiertes Ledger aus und halten Sie jedes Feld an dieses Schema:

• Transaktionsdatum, Buchungsdatum, Verwendungszweck, Betrag, vorzeichenbehaftete Richtung und laufender Saldo
• Identität des Kontoinhabers und Kontonummer, für die Entity Resolution über mehrere Auszüge hinweg
• Grenzen des Abrechnungszeitraums, damit Sie wissen, über welches Fenster Sie messen
• Anfangs- und Endsaldo, die die Abstimmung verankern

Dieser letzte Punkt ist die günstigste Qualitätsprüfung, die Sie je bauen werden. Summieren Sie die Transaktionen der Reihe nach, verrechnen Sie sie mit dem Anfangssaldo und bestätigen Sie, dass Sie beim ausgewiesenen Endsaldo landen. Wenn das nicht aufgeht, haben Sie eine Transaktion übersehen, einen Betrag fehlgelesen oder eine Seite verloren. Verweisen Sie das Dokument dann in eine Prüf-Queue, statt ein Ledger durchzureichen, von dem Sie wissen, dass es fehlerhaft ist. Extraktion ohne diese Abstimmung ist Extraktion, die Sie nicht verteidigen können.

Aus Transaktionen eine Einkommenszahl machen

Sobald Sie ein sauberes Ledger haben, ist die Einkommenserkennung ein Klassifikations- und Aggregationsproblem, und genau hier bauen Teams entweder etwas Ehrliches oder etwas, das sich selbst schmeichelt.

Der naive Ansatz summiert alles, was wie eine Gutschrift aussieht. Das ist von der ersten Sekunde an falsch. Eingehende Überweisungen zwischen den eigenen Konten des Kunden, Kreditauszahlungen, Rückerstattungen, Stornierungen und einmalige Geschenke sind allesamt Gutschriften, und keine davon ist Einkommen. Sie mitzuzählen bläht die Tragfähigkeit auf, also genau die Richtung, in die Ihre Fehler nicht zeigen sollen.

Die Methode, die standhält, sucht nach wiederkehrender Struktur:

• Gruppieren Sie Gutschriften nach normalisiertem Kontrahenten und nutzen Sie Entity Resolution, damit “ACME CORP PAYROLL”, “ACME CORP” und “ACME CO” zu einem Arbeitgeber zusammenfallen
• Prüfen Sie jede Gruppe auf Regelmäßigkeit im Intervall (monatlich, vierzehntägig, wöchentlich) und Stabilität im Betrag
• Trennen Sie Gehalt von Sozialleistungen, Rente, Mieteinnahmen und Entnahmen aus selbstständiger Tätigkeit, weil die Kreditrichtlinie sie unterschiedlich behandelt
• Unterscheiden Sie brutto-nahe von Netto-Werten; ein Auszug zeigt Eingänge nach Steuern, also ist jede Bruttozahl, die Sie ausweisen, eine Rekonstruktion und sollte als solche gekennzeichnet werden

Jeder klassifizierte Einkommensstrom braucht eine Lineage zurück zu den konkreten Transaktionen, die ihn erzeugt haben. Ein Underwriter, ein Prüfer oder eine Aufsichtsbehörde wird fragen, warum das System sagt, dass ein Kreditnehmer einen bestimmten Betrag verdient, und “das Modell hat entschieden” ist keine Antwort, die eine Modellrisiko-Prüfung nach SR 11-7 oder eine ECOA-Begründung einer Ablehnung übersteht. Die Transaktionsliste ist die Antwort.

Zwei Fehlermodi verdienen ausdrückliche Behandlung. Lookahead: Wenn Sie einen unvollständigen letzten Monat verwenden, den der Abrechnungszeitraum nicht vollständig abdeckt, unter- oder überschätzen Sie die Monatszahl, also schneiden Sie auf vollständige Zeiträume zu. Drift: Zahlungsbeschreibungen von Arbeitgebern, Auszugsvorlagen und App-Exportformate ändern sich im Lauf der Zeit, und ein Parser, der letztes Quartal abgestimmt wurde, verschlechtert sich klammheimlich. Überwachen Sie Extraktionskonfidenz und die Erfolgsquote der Abstimmung als Zeitreihe, damit Sie die Verschlechterung sehen, bevor ein Kreditausschuss sie sieht.

Benchmarking, oder Sie fliegen im Blindflug

Sie können keine Produktionsgenauigkeit behaupten ohne ein Eval-Set, das die Produktion widerspiegelt. Das ist die Disziplin, die ein System, das Sie einer Aufsichtsbehörde vorlegen können, von einem Skript unterscheidet, das einmal funktioniert hat.

Bauen Sie das Set bewusst auf. Ziehen Sie echte Dokumente über die Banken, Formate und Kanäle hinweg, die Sie tatsächlich erhalten, in den Anteilen, in denen Sie sie erhalten, und lassen Sie Menschen den Ground Truth labeln: die korrekten Transaktionen und die korrekte Einkommenszahl je Strom. Nehmen Sie die hässlichen Fälle absichtlich mit auf. Ein Benchmark, der nur aus sauberen PDFs besteht, misst den Teil des Problems, den Sie bereits gelöst haben.

Messen Sie dann auf zwei Ebenen. Die Extraktionsgenauigkeit auf Feldebene sagt Ihnen, ob das Ledger stimmt. Die Genauigkeit auf Entscheidungsebene sagt Ihnen, ob die finale Einkommenszahl innerhalb der Toleranz landet, die Ihre Kreditrichtlinie zulässt. Das sind unterschiedliche Fragen, und die zweite ist die, auf die es bei einer Kreditentscheidung ankommt.

• Weisen Sie den Fehler auf die Einkommenszahl aus, nicht nur die Extraktionsgenauigkeit pro Feld
• Verfolgen Sie Ihr False-Positive-Budget explizit: wie oft das System eine falsche Zahl selbstbewusst akzeptiert, denn das ist der Fehler, der bis zu einer Genehmigung durchdringt
• Kalibrieren Sie eine Konfidenzschwelle und leiten Sie alles darunter an die manuelle Prüfung weiter, damit Straight-Through-Processing die Dokumente abdeckt, die Sie wirklich gut parsen, und Menschen den Long Tail auffangen
• Führen Sie den Benchmark bei jeder Modell- oder Parser-Änderung erneut aus und bewahren Sie die Ergebnisse als Teil des Audit-Trails auf

Eine aus einem Auszug abgeleitete Einkommenszahl ist eine Schätzung mit einem Konfidenzband, und die ehrliche Version dieses Systems weist beides aus. Die Zahl, der Sie vertrauen können, ist die, die Sie auf Transaktionen zurückführen, gegen einen Endsaldo abstimmen und auf einem zurückgehaltenen Set verteidigen können, das aussieht wie die Kunden, die durch Ihre Tür kommen.