Inkasso-Automatisierung bleibt regelkonform, wenn die Conduct-Regeln in einer Policy Engine leben, die das Modell nicht umgehen kann. Das Modell rankt Konten und schlägt Aktionen vor; es sendet nichts. Eine separate Schicht setzt Häufigkeits-Caps, Ruhezeiten, Cease-Contact-Flags und Widerspruchs-Holds gegen eine aktuelle Sicht des Kontos durch und entscheidet dann, was raus darf. Halte diese zwei Aufgaben getrennt, und die meisten Conduct-Fehler erreichen nie einen Schuldner.
Der Grund, warum das im Inkasso mehr zählt als fast überall sonst im Kreditgeschäft, ist, dass die regulierte Einheit der Kontakt selbst ist. Eine Kreditentscheidung ist ein einzelnes Ereignis, das man im Nachhinein prüfen kann. Inkasso ist ein Strom von Aktionen gegen eine Person, die bereits unter finanziellem Druck steht, in den USA vom FDCPA und seiner Umsetzung in Regulation F geregelt, in Großbritannien von den FCA-CONC-Regeln und der Consumer Duty. Ein Anruf nach 21 Uhr Ortszeit, ein achter Anrufversuch innerhalb eines Sieben-Tage-Fensters, eine Forderung auf eine Schuld, der der Verbraucher bereits schriftlich widersprochen hat: jedes ist für sich ein Verstoß, und Automatisierung lässt einen ihn tausendfach begehen, bevor es jemand bemerkt.
Setze die Regeln dorthin, wo das Modell nicht hinreicht
Der Fehler, den wir sehen, ist, dass Teams ein Modell die Regeln aus Daten lernen lassen wollen. Es wird Ruhezeiten nicht zuverlässig lernen, und selbst wenn, kann man einem Aufseher keine Gewichtsmatrix zeigen und sie eine Kontrolle nennen. Kontaktregeln sind deterministisch und gehören in eine deterministische Schicht.
Konkret teilen wir das System in ein Ranking-Modell und eine Policy Engine. Das Modell scored Konten nach Heilungswahrscheinlichkeit, bestem Kanal und erwarteter Rückführung. Es sendet nie etwas. Sein Output ist eine gerankte Liste vorgeschlagener Aktionen. Die Policy Engine nimmt jede vorgeschlagene Aktion und prüft sie gegen harte Nebenbedingungen:
- Häufigkeits-Caps pro Kanal und insgesamt, gezählt über die exakten Fenster, die die Regulierung vorschreibt, statt einer rollierenden Näherung. Die Belästigungsvermutung von Regulation F etwa hängt an mehr als sieben Anrufen in sieben Tagen, also muss die Zählung auf den Anruf genau sein.
- Ruhezeiten in der lokalen Zeitzone des Schuldners, was eine zuverlässige Zeitzone pro Konto erfordert und einen Fallback, wenn man sie nicht hat.
- Cease-Contact- und Cease-and-Desist-Flags, die einen Kanal oder alle Kanäle in dem Moment unterdrücken, in dem sie erfasst werden.
- Widerspruchs-Holds, die die Inkasso-Aktivität auf den bestrittenen Betrag stoppen, bis der Widerspruch geklärt und die erforderliche Validierung gesendet ist.
- Cooling-off-Fristen, nachdem eine Zahlungsvereinbarung getroffen oder gebrochen wurde.
Scheitert eine Nebenbedingung, wird die Aktion verworfen oder verschoben, und der Grund in den Datensatz geschrieben. Der Score des Modells hat kein Stimmrecht darüber, ob ein unterdrückter Kontakt rausgeht. Das ist die wichtigste Designentscheidung im ganzen System, und sie ist bewusst langweilig.
Der Point-in-Time-Zustand ist der eigentliche Fehlermodus
Sobald die Regel-Schicht existiert, bricht als Nächstes die Datenzufuhr. Die Policy Engine kann perfekt sein und trotzdem einen Anruf an jemanden autorisieren, der gestern gezahlt hat, weil das gelesene Feature im nächtlichen Batch berechnet wurde und die Zahlung heute Morgen buchte.
Der Inkasso-Zustand bewegt sich schnell. Zahlungen buchen, Vereinbarungen werden getroffen und gebrochen, Widersprüche eingelegt, Härtefälle erklärt, ein Konto wird verkauft oder zurückgerufen. Jede dieser Änderungen verändert, welches Treatment rechtmäßig ist. Das Engineering-Problem ist also Point-in-Time-Korrektheit: Die Entscheidung muss das Konto so lesen, wie es im Moment der Aktion ist, nicht wie es zum Feature-Compute-Zeitpunkt war.
- Baue den Feature Store so, dass Kontakt-Eligibility-Features entweder beim Lesen berechnet oder in dem Moment invalidiert werden, in dem das zugrunde liegende Ereignis landet. Ein veraltetes Eligibility-Flag ist ein Compliance-Defekt, keine Latenz-Unannehmlichkeit.
- Achte auch auf Leakage in den Trainingsdaten. Wurde dein Heilungswahrscheinlichkeits-Modell auf Features trainiert, die still Post-Decision-Informationen enthielten, sind seine Scores optimistisch und drängen Kontakt auf Konten, die sich ohnehin selbst geheilt hätten.
- Führe Lineage vom Rohereignis über das Feature zur Aktion. Wenn etwas schiefgeht, willst du einen konkreten Anruf zurückverfolgen auf den exakten Zahlungsdatensatz, Widerspruchsdatensatz und Flag-Zustand, die live waren, als die Policy Engine lief.
Entity Resolution sitzt unter all dem. Gehören zwei Konten derselben Person und behandelt man sie als getrennt, sind die Häufigkeits-Caps konstruktionsbedingt falsch. Inkasso-Bücher sind voll von doppelten und fast-doppelten Parteien, also gehört ihre Auflösung zur Compliance-Fläche und kann nicht auf einen späteren Datenqualitätslauf warten.
Teste die Treatment-Pfade, nicht nur das Modell
Modell-Teams bewerten den Ranker mit den üblichen Metriken. Das sagt nichts darüber, ob das automatisierte Treatment innerhalb der Regeln bleibt. Man braucht ein Eval-Set, das um die Nebenbedingungen selbst herum gebaut ist.
Wir konstruieren Szenario-Fälle, die je eine Regel adressieren: ein Konto, das bei der nächsten Aktion einen Häufigkeits-Cap überschreitet, eines, das mitten in der Sequenz in Ruhezeiten eintritt, eines, bei dem ein Widerspruch zwischen Scoring und Senden landet, eines mit einem vor einer Stunde gesetzten Cease-Contact-Flag. Das System besteht nur, wenn die Policy Engine in jedem Fall die richtige Aktion unterdrückt. Diese laufen in der CI, sodass eine Änderung am Ranking-Modell oder an der Feature-Pipeline keinen unterdrückten Pfad still wieder aktivieren kann.
Zwei weitere Dinge verdienen sich hier ihren Platz. Erstens ein False-Positive-Budget auf Kontakt: Automatisierung macht es billig, mehr Menschen zu erreichen, und Menschen zu erreichen, die von allein geheilt hätten, ist verschwenderisch und unter der Pflicht der Consumer Duty, vorhersehbaren Schaden zu vermeiden, ein Conduct-Risiko. Halte das System an eine erklärte Obergrenze unnötiger Kontakte. Zweitens Drift-Monitoring auf den Eingaben, die das Treatment steuern, besonders Zeitzonen-Abdeckung, Widerspruchsraten und der Anteil an Konten, die Caps erreichen. Bewegen die sich, hat sich deine Compliance-Haltung mit ihnen bewegt, ob die Genauigkeitsmetrik des Modells es bemerkt hat oder nicht.
Straight-Through-Processing ist das Ziel für die routinemäßige Mehrheit der Konten, und es ist erreichbar. Aber Straight-Through heißt nur, dass der Mensch aus dem Senden entfernt ist, nicht aus dem Design. Der Audit-Trail, die Policy-Versionen, die Unterdrückungs-Datensätze: das ist, was ein Aufseher und eine Aufsicht lesen, wenn sie fragen, ob die Maschine sich benommen hat. Baue sie zuerst, und die Automatisierung hält. Schraube sie nachträglich an, und du rekonstruierst Absicht aus Logs, die nie dafür gedacht waren, sie zu tragen.
Häufige Fragen
Kann ein Modell Kontaktzeitpunkt und -kanal selbst entscheiden?
Es kann sie vorschlagen, aber die Häufigkeits-Caps, Ruhezeiten und Cease-Contact-Flags müssen von einer Regel-Schicht durchgesetzt werden, die das Modell nicht überstimmen kann. Das Modell rankt; die Policy Engine entscheidet, was gesendet werden darf.
Wie beweist ihr, dass eine automatisierte Inkasso-Aktion regelkonform war?
Jede ausgehende Aktion trägt einen Audit-Datensatz: den gelesenen Kontozustand, die Policy-Version, die sie autorisiert hat, den Modell-Score und den Zeitstempel. Fragt eine Aufsicht, warum ein Schuldner zu einer bestimmten Zeit einen Anruf erhielt, spielt man den Datensatz ab, statt die Absicht zu rekonstruieren.
Was bricht zuerst, wenn man Treatment-Pfade automatisiert?
Meist ist der Kontozustand, der die Entscheidung speist, veraltet. Eine Zahlung wurde gebucht oder ein Widerspruch eingelegt, nachdem das Feature berechnet wurde, und das System handelt auf einem Bild des Kontos, das nicht mehr stimmt. Point-in-Time-Aktualität zählt hier mehr als Modellgenauigkeit.