Material: Teil 17. Dashboard für Zahlungen und Risikosignale

Lektion 1 von 5 im Modul «Teil 17. Dashboard für Zahlungen und Risikosignale»

Sie sehen die Lektion ohne Anmeldung an. Anmelden, um Ihren Fortschritt zu speichern und Tests zu absolvieren.

Quelle

Teil 17. Mart für Zahlungen und Risikosignale

Zahlungsdaten sind deshalb gefährlich, weil eine technisch einfache Aggregation als Risikoentscheidung wirken kann. Der Lern-Mart mart_payment_risk_signals ist kein Scoring-Engine. Es ist ein Beobachtungs-Mart: welche Transaktionen sind mit einem Risiko-Flag versehen und welche Beträge/Kanäle Aufmerksamkeit erfordern.

Granularität

Für den Risiko-Mart auf Transaktionsebene gilt die Granularität:

eine Zeile pro `transaction_id`

Wenn der Mart nach Kunde oder Tag aggregiert, handelt es sich um ein anderes Datenprodukt. Es ist nicht zulässig, einen Mart auf Transaktionsebene stillschweigend auf Kundenebene zu ändern, selbst wenn das SQL kürzer wird.

Was zu prüfen ist

transaction_id ist not null und unique;
der Betrag ist nicht null;
das Risiko-Flag wird als Lernsignal der Quelle behandelt;
es tauchen keine direkten PII auf;
Transaktionen ohne Risiko-Flag werden nicht ohne Spezifikation aus der

vorgelagerten Schicht entfernt;

der Reviewer sieht, wo der Schwellenwert eine Lernregel ist.

Schlechter Ansatz

where risk_flag = true

Ein solcher Filter kann für einen bestimmten Mart zulässig sein, aber nur wenn die Spezifikation sagt: „der Mart enthält nur Risikoereignisse". Wenn der Konsument alle Transaktionen mit Risiko-Merkmal erwartet, bricht der Filter die Vollständigkeit.

Qwen-Abfrage

Lies stg_card_transactions, mart_payment_risk_signals und die Spezifikationen.
Bestimme die Granularität, welche Transaktionen einbezogen sind, welche
ausgeschlossen sind und welche Prüffakten für den Risiko-Mart nötig sind.
Ändere die Dateien nicht.

Minimale Ausgabe

Erstellen Sie eine Notiz zum Risiko-Mart:

Mart:
Granularität:
Quelle des Risiko-Flags:
Einbezogene Zeilen:
Ausgeschlossene Zeilen:
Prüffakten:
Manuelle Fragen des Reviewers:

Erläuterung für den Leser

Der Risiko-Signal-Mart wirkt einfach: Transaktionen mit risk_flag nehmen, große Beträge hinzufügen, eine Liste liefern. Aber genau hier fängt der Agent am häufigsten an, sich Geschäftslogik auszudenken. Er kann entscheiden, dass Risiko nur das Quell-Flag ist. Oder dass Risiko ein Betrag über einem Schwellenwert ist. Oder dass nach Kunde aggregiert werden muss, weil das für den Bericht bequemer ist. All diese Entscheidungen sind möglich, aber keine darf ohne Spezifikation erscheinen.

Im Lernprojekt ist mart_payment_risk_signals kein Scoring-Modell. Das ist grundsätzlich. Scoring verlangt Methodik, Erklärbarkeit, Qualitätskontrolle, rechtliche und Risiko-Prozesse. Hier dient der Mart dem Lernen von SDD: zeigen, wie man die Signalquelle von der Entscheidung trennt, die Granularität auf Transaktionsebene von der Aggregation auf Kundenebene, die Beobachtung von der Aussage.

Auch der Schwellenwert für große Beträge ist eine Lernregel und keine bankwirtschaftliche Wahrheit. Wenn der Schwellenwert nur im SQL steht, versteht der Reviewer nicht, ob es eine vorübergehende Vereinfachung, eine Produktanforderung oder eine Annahme des Agenten ist. Deshalb muss der Schwellenwert in der Spezifikation, der Prüfnotiz und dem Reviewer-Bericht auftauchen. Dann kann ein künftiger Autor ihn ohne versteckten Drift durch eine andere Methodik ersetzen.

Dieses Kapitel lehrt eine wichtige Frage: „welche Zeile stellt der Mart dar?" Wenn die Zeile eine Transaktion ist, dann ist transaction_id der Schlüssel, und der Kunde kann sich wiederholen. Wenn die Zeile ein Kunde ist, werden andere Felder, andere Tests und eine andere Spezifikation benötigt. Man darf diese Varianten nicht als austauschbar betrachten, nur weil beide helfen, über Risiko zu sprechen.

Übung

Beschreiben Sie zwei Varianten des Risiko-Marts: auf Transaktionsebene und auf Kundenebene. Geben Sie für jede die Granularität, den Konsumenten und an, warum das SQL der einen Variante nicht stillschweigend durch die andere ersetzt werden darf.

Typischer Fehler

Das Lern-risk_flag in eine reale Entscheidung zu verwandeln. Im Bankbereich erfordert eine solche Entscheidung ein eigenes Modell, Erklärbarkeit, Governance-Prozesse und eine rechtliche Prüfung. In diesem Band ist das Risiko-Flag ein Signal für den SDD-Prozess, kein Scoring-Produkt.