Thema: Teil 17. Mart für Zahlungen und Risikosignale
Schwierigkeitsgrad: Mittel
Geschätzte Lernzeit: 2,5–3 Stunden
Voraussetzungen: Grundlegende SQL-Kenntnisse (SELECT, WHERE, JOIN, GROUP BY)
Verständnis des Konzepts von Data Marts und Warehouse-Schichten
Vertrautheit mit der Methodik Specification-Driven Development (SDD)
Grundlegendes Verständnis der Bank- und Zahlungsdomäne
Vorstellung von den Prinzipien im Umgang mit PII und Risikosignalen
Lernziele: Die Granularität (grain) des Risikosignal-Marts auf Operationsebene bestimmen und festhalten und sie von einer Aggregation nach Kunde oder Tag unterscheiden.
Erklären, warum der Filter risk_flag = true ohne explizite Spezifikation als Breaking Change für den Beobachtungs-Mart gilt.
Eine Notiz zum Risiko-Mart nach Vorlage mit Angabe der Granularität, der Signalquelle, der Prüffakten und der manuellen Fragen des Reviewers erstellen.
Die Rolle der Signalquelle (stg_card_transactions) von der Rolle der Entscheidung trennen und das Lern-Risk-Flag nicht in ein Scoring-Produkt verwandeln.
Manuelle Fakten für den Reviewer formulieren: wo der Schwellenwert für hohe Beträge liegt, welche Operationen ein- bzw. ausgeschlossen sind und wo PII auftauchen.
Übersicht: Kapitel 17 des Lehrbuchs behandelt den Entwurf des Marts mart_payment_risk_signals – eine Beobachtungsschicht, nicht eine Scoring-Engine. Der Mart aggregiert Zahlungsoperationen, die in der Quelle mit einem Risk-Flag markiert sind, und erfasst hohe Beträge/Kanäle, die Aufmerksamkeit erfordern. Die Kernidee des Kapitels: Eine technisch einfache Aggregation im Zahlungsbereich sieht leicht wie eine Risikoentscheidung aus und muss daher strikt vom Scoring getrennt werden. Die Lernenden üben, die Granularität auf Operationsebene festzulegen (eine Zeile pro transaction_id), risk_flag als Signal der Quelle zu behandeln, Operationen ohne Flag nicht ohne explizite Spezifikation zu verwerfen, direkte PII zu vermeiden und Schwellenwerte für hohe Beträge explizit in Spezifikation, Prüfnotiz und Reviewer-Bericht festzuhalten. Das Kapitel entwickelt die Fähigkeit, die Frage zu stellen „welche Zeile repräsentiert dieser Mart?" und zu verstehen, dass Marts auf Operations- und auf Kundenebene unterschiedliche Datenprodukte mit unterschiedlichen Anforderungen sind.
Schlüsselkonzepte: Beobachtungs-Mart vs. Scoring-Engine: mart_payment_risk_signals ist ein Beobachtungs-Mart. Er erfasst, welche Operationen mit einem Risk-Flag markiert sind und welche Beträge/Kanäle Aufmerksamkeit erfordern. Dies ist KEIN Scoring-Modell: Scoring erfordert eine eigene Methodik, Erklärbarkeit, Qualitätskontrolle und juristische Prüfung. Hier ist risk_flag ein Signal für den SDD-Prozess, keine Produktentscheidung.
Granularität (grain) des Marts: Für einen Mart auf Operationsebene ist die Granularität streng festgelegt: eine Zeile pro transaction_id. transaction_id not null und unique sind obligatorische Invarianten. Wenn der Mart nach Kunde oder Tag aggregiert, handelt es sich um ein anderes Datenprodukt mit anderer Spezifikation und anderen Tests.
Risk-Flag als Signal der Quelle: Im Lernprojekt wird risk_flag als Übungssignal der Quelle stg_card_transactions behandelt, nicht als Ergebnis eines analytischen Modells. Lernende dürfen keine eigene Risikodefinition (z. B. „Betrag über Schwellenwert") erfinden und ohne Spezifikation auf SQL anwenden.
Vollständigkeit des Marts vs. Filter risk_flag = true: Der Filter where risk_flag = true ist nur zulässig, wenn die Spezifikation explizit sagt: „der Mart enthält nur Risikoereignisse". Wenn der Konsument alle Operationen mit Risikoindikator erwartet, bricht ein solcher Filter die Vollständigkeit. Dies ist eine typische Falle: Der Agent „vereinfacht" das SQL, ohne den Vertrag zu prüfen.
Schwellenwert für hohe Beträge als Übungsregel: Der Schwellenwert für hohe Beträge in mart_payment_risk_signals ist eine Übungsregel, keine Bankenwahrheit. Wenn der Schwellenwert nur im SQL steht, versteht der Reviewer nicht, ob es eine vorübergehende Vereinfachung, eine Produktanforderung oder eine Vermutung des Agenten ist. Der Schwellenwert muss in der Spezifikation, der Prüfnotiz und dem Reviewer-Bericht erscheinen.
Schutz vor PII: Im Risiko-Mart dürfen keine direkten PII (Name, Reisepass, vollständige Kartennummer) erscheinen. Aggregate, Masken und Identifikatoren sind zulässig, aber keine rohen personenbezogenen Daten. Diese Anforderung muss in den Prüffakten verifiziert werden.
Operationen ohne Risk-Flag: Operationen ohne risk_flag dürfen nicht ohne explizite Spezifikation aus der vorgelagerten Schicht entfernt werden. Wenn im Mart nur ein Teil der Transaktionen landet, muss der Reviewer den Ausschlussgrund sehen.
Notiz zum Mart (minimale Ausgabe): Am Ende der Analyse erstellt der Agent eine Markdown-Notiz mit sechs Feldern: Mart, Granularität, Quelle des Risk-Flags, eingeschlossene Zeilen, ausgeschlossene Zeilen, Prüffakten, manuelle Fragen des Reviewers. Das diszipliniert, Fakten von Vermutungen zu trennen.
Qwen-Anfrage für die SDD-Analyse: Standardisierter Prompt: „Lies stg_card_transactions, mart_payment_risk_signals und specs. Bestimme die Granularität, welche Operationen eingeschlossen, welche ausgeschlossen sind und welche Prüffakten für den Risiko-Mart nötig sind. Ändere keine Dateien." – dies fixiert den Vertrag des Agenten als Beobachter, nicht als Editor.
Unterschied zwischen Marts auf Operations- und Kundenebene: Dies sind zwei verschiedene Datenprodukte. Mart auf Operationsebene: Schlüssel ist transaction_id, Kunde wiederholt sich, Tests sind Eindeutigkeit und not null der ID. Mart auf Kundenebene: Schlüssel ist customer_id, Aggregate nach Beträgen/Kanälen, Tests sind andere Vollständigkeit und Konsistenz. Das SQL des einen darf nicht stillschweigend durch das andere ersetzt werden.
Wichtige Termine: Übungskontext des Bandes: Der Mart wird im Kontext des SDD-Trainings betrachtet, nicht einer realen Produktion. Daher sind alle „Regeln" (Betragsschwellenwert, Interpretation von risk_flag) Übungskonstrukte.
Moment der Festlegung der Granularität: Die Entscheidung über die Granularität wird VOR dem Schreiben des SQL getroffen, in der Spezifikationsphase. Eine Änderung der Granularität im Nachhinein ist ein Breaking Change für Konsumenten.
Moment des Auftretens des Schwellenwerts in Artefakten: Der Schwellenwert für hohe Beträge muss gleichzeitig in specs, in der Prüfnotiz und im Reviewer-Bericht festgehalten werden, damit ein zukünftiger Autor die Methodik ohne versteckten Drift ersetzen kann.
Übungsaufgaben: Name: Übung 1. Notiz zum Mart nach Vorlage
Problem: Gegeben ist eine specs-Datei mit der Beschreibung von mart_payment_risk_signals und ein SQL-Skript des Marts, das den Filter WHERE risk_flag = true AND amount > 10000 verwendet. Ohne die Dateien zu ändern, füllen Sie die Markdown-Vorlage aus: Mart, Granularität, Quelle des Risk-Flags, eingeschlossene Zeilen, ausgeschlossene Zeilen, Prüffakten, manuelle Fragen des Reviewers. Erklären Sie, welche Risiken das aktuelle SQL birgt.
Lösung: Schritt 1. Mart: mart_payment_risk_signals. Schritt 2. Granularität: eine Zeile pro transaction_id (wenn die Spezifikation dies bestätigt). Schritt 3. Quelle des Risk-Flags: stg_card_transactions.risk_flag, behandelt als Signal der Quelle. Schritt 4. Eingeschlossene Zeilen: Operationen, bei denen risk_flag = true UND amount > 10000 (gemäß aktuellem SQL). Schritt 5. Ausgeschlossene Zeilen: alle Operationen mit risk_flag = false oder amount <= 10000 – potenziell breaking Ausschluss, wenn die Spezifikation alle Operationen mit Risikoindikator verlangt. Schritt 6. Prüffakten: transaction_id unique und not null; amount not null; Schwellenwert 10000 in specs festgehalten; keine PII. Schritt 7. Manuelle Fragen des Reviewers: Warum wurde der Schwellenwert 10000 gewählt? Ist es eine Produktanforderung oder eine Vermutung des Agenten? Müssen alle Operationen mit Risk-Flag im Mart sein? Wo ist der Betragsfilter in specs festgehalten?
Komplexität: intermediate
Name: Übung 2. Vergleich zweier Granularitätsvarianten
Problem: Beschreiben Sie zwei Varianten des Risiko-Marts: Operationsebene und Kundenebene. Geben Sie für jede Granularität, Konsumenten, Schlüsselfelder an und erläutern Sie, warum das SQL der einen Variante nicht stillschweigend durch die andere ersetzt werden darf.
Lösung: Variante A – Operationsebene: Granularität = eine Zeile pro transaction_id. Schlüssel ist transaction_id. Konsument: Fraud-Monitoring-Team, das jede markierte Operation sehen muss. Felder: transaction_id, customer_id (wiederholt sich), amount, channel, risk_flag, threshold_marker. Variante B – Kundenebene: Granularität = eine Zeile pro customer_id pro Periode. Schlüssel ist customer_id + period. Konsument: Produktanalyse, die einen Ausschnitt „wie viele Risikooperationen hat ein Kunde und auf welchen Betrag" benötigt. Felder: customer_id, period, ops_count, total_risk_amount, channels_set. Das SQL der einen Variante darf nicht stillschweigend durch die andere ersetzt werden: Der Konsumentenvertrag ändert sich, es sind unterschiedliche Vollständigkeitsprüfungen erforderlich (Eindeutigkeit von transaction_id vs. Eindeutigkeit des Paares customer_id+period), unterschiedliche JOINs zu Quellen und unterschiedlicher Schutz vor Doppelzählung.
Komplexität: intermediate
Name: Übung 3. Suche nach einem typischen Fehler
Problem: Finden Sie den typischen Fehler in der folgenden Mart-Beschreibung: „mart_payment_risk_signals ist ein Scoring-Modell, das auf Grundlage von risk_flag und eines Betrags über 50000 die Entscheidung über die Sperrung einer Operation trifft. Der Mart enthält nur Operationen, die unser Modell als riskant eingestuft hat." Formulieren Sie die Beschreibung so um, dass sie dem SDD-Vertrag eines Beobachtungs-Marts entspricht.
Lösung: Schritt 1. Fehler Nr. 1: Der Mart wird als „Scoring-Modell" bezeichnet. Der Mart mart_payment_risk_signals ist eine Beobachtungsschicht, kein Scoring. Schritt 2. Fehler Nr. 2: „trifft die Entscheidung über die Sperrung". Die Sperrentscheidung ist ein Produkt-/Risikoprozess, nicht eine Funktion des Marts. Schritt 3. Fehler Nr. 3: „auf Grundlage von risk_flag UND Betrag über 50000" – ein vom Agenten erfundenes kombiniertes Kriterium, das nicht in specs festgehalten ist. Schritt 4. Fehler Nr. 4: „enthält nur Operationen, die unser Modell als riskant eingestuft hat" – der Filter bricht die Vollständigkeit, wenn die Spezifikation alle Operationen mit Risikoindikator verlangt. Korrekte Formulierung: „mart_payment_risk_signals ist ein Beobachtungs-Mart mit der Granularität eine Zeile pro transaction_id. Enthält Operationen aus stg_card_transactions mit Risikoindikator; markiert zusätzlich Operationen mit Betrag über dem in specs festgelegten Übungsschwellenwert. Ist kein Scoring und trifft keine Risikoentscheidungen. Keine PII."
Komplexität: intermediate
Name: Übung 4. Formulierung manueller Fragen an den Reviewer
Problem: Vor Ihnen liegt das SQL des Marts: SELECT transaction_id, customer_id_hash, amount, channel FROM stg_card_transactions WHERE risk_flag = true. Formulieren Sie mindestens fünf manuelle Fragen an den Reviewer, die die Notiz zum Mart enthalten muss.
Lösung: Frage 1. Ist der Filter risk_flag = true eine Anforderung der Spezifikation oder eine Vermutung des SQL-Autors? Wenn die Spezifikation alle Operationen mit Risikoindikator verlangt, bricht der Filter den Vertrag. Frage 2. Wie genau wird customer_id gehasht und ist dies gemäß PII-Richtlinie zulässig? Frage 3. Warum wurden genau die Felder transaction_id, customer_id_hash, amount, channel gewählt? Reicht dies dem Konsumenten des Marts? Frage 4. Gibt es in der Quelle Operationen mit risk_flag IS NULL und wohin sollen diese gehören? Frage 5. Wo ist der Übungsschwellenwert für hohe Beträge festgehalten – in specs, im Code oder nirgends? Frage 6 (optional). Warum ist die Granularität des Marts die Operation und nicht der Kunde, und ist diese Wahl mit dem Konsumentenvertrag abgestimmt?
Komplexität: intermediate
Fallstudien: Name: Fallstudie 1. Stillschweigende Ersetzung der Granularität von Operations- auf Kundenebene
Szenario: In einem Fintech-Startup bat das Analytics-Team einen KI-Agenten, das SQL des Risikosignal-Marts zu „vereinfachen". Der Agent sah, dass der Konsument einen Ausschnitt nach Kunden benötigte, und ersetzte das SELECT durch eine Aggregation GROUP BY customer_id, wodurch die Eindeutigkeit von transaction_id entfernt wurde. Das SQL wurde 30 Zeilen kürzer, bestand die Linter-Prüfung und gelangte unter demselben Namen mart_payment_risk_signals in die Produktion.
Aufgabe: Der Fraud-Monitoring-Konsument stellte fest, dass dieselbe Operation „verloren ging", wenn ein Kunde an einem Tag mehrere Risikotransaktionen durchgeführt hatte: Im Mart wurden Beträge aggregiert, und die einzelnen Transaktionen ließen sich nicht mehr unterscheiden. Zusätzlich wurde der Eindeutigkeitsschlüssel gebrochen: Es entstanden Zeilen, die nicht dem ursprünglichen Granularitätsvertrag entsprachen. Die Untersuchung des Vorfalls dauerte 2 Arbeitstage, und die Quartalsberichterstattung musste neu berechnet werden.
Lösung: Das Team führte eine strenge Regel ein: Marts auf Operations- und auf Kundenebene sind unterschiedliche Datenprodukte mit unterschiedlichen Namen und unterschiedlichen Spezifikationen. In specs wurden Granularität und Liste der Pflichtfelder explizit festgehalten. In der Notizvorlage wurde der Punkt „Hat sich die Granularität gegenüber der Spezifikation geändert?" als obligatorische manuelle Frage des Reviewers hinzugefügt. Außerdem wurde ein Test-Vertrag eingeführt: Für Marts auf Operationsebene prüft CI, dass COUNT(*) der DISTINCT transaction_id aus der Quelle entspricht.
Ergebnis: Nach Einführung der Regel gab es ein Quartal lang keine wiederholten Granularitätsvermischungen. Die Review-Zeit für Mart-SQLs verkürzte sich durch die standardisierte Notizvorlage. Das Team konnte beide Datenprodukte ehrlich pflegen: mart_payment_risk_signals_ops (Operationsebene) und mart_customer_risk_profile (Kundenebene).
Gewonnene Erkenntnisse: Granularität ist ein Mart-Vertrag, kein Optimierungsdetail des SQL.
Kürzeres SQL bedeutet nicht richtigeres SQL.
Der Eindeutigkeitstest des Schlüssels ist eine obligatorische Invariante für Marts auf Operationsebene.
Die Vorlage für die Mart-Notiz muss die Granularität als eigenes Feld explizit festhalten.
Verwandte Konzepte: Granularität (grain) des Marts
Unterschied zwischen Marts auf Operations- und Kundenebene
Notiz zum Mart (minimale Ausgabe)
Vollständigkeit des Marts vs. Filter risk_flag = true
Name: Fallstudie 2. Schwellenwert für hohe Beträge, nur im SQL festgehalten
Szenario: Im Banking Data Lake entstand der Mart mart_payment_risk_signals mit einem fest einprogrammierten Schwellenwert amount > 50000 zur Markierung „großer Operationen". Der Schwellenwert wurde vom Analysten intuitiv gewählt und nur im SQL festgehalten. Die Mart-Spezifikation erwähnte „große Operationen markieren", aber ein konkreter Wert fehlte.
Aufgabe: Ein halbes Jahr später forderte das Compliance-Team einen Bericht: Welche Operationen gelten genau als groß und auf welcher Grundlage? Der Reviewer konnte die Logik der Schwellenwertwahl nicht rekonstruieren: War es eine regulatorische Anforderung, eine Produktbeschränkung oder eine persönliche Vermutung des Autors? Zusätzlich stellte sich heraus, dass parallel in einer anderen Abteilung ein Mart mit dem Schwellenwert 30000 existierte, was zu Berichtsabweichungen führte.
Lösung: Das Team führte eine Regel ein: Jede numerische Regel (Schwellenwert, Limit, Koeffizient) muss in specs als Parameter mit Angabe der Quelle (Produktanforderung, regulatorisch, Übungsregel) festgehalten werden. Die Mart-Notiz muss obligatorisch einen Abschnitt „Schwellenwerte und ihre Herkunft" enthalten. In specs erschien das Feld large_amount_threshold = 50000 (Übungsregel, erfordert Verifikation durch das Produktteam).
Ergebnis: Innerhalb eines Quartals gelang es, die Schwellenwerte auf einen einheitlichen Wert zu bringen und ihre Herkunft festzuhalten. Künftige Mart-Autoren erhielten die Möglichkeit, den Schwellenwert ohne versteckten Drift zu ersetzen, da die Regelquelle nun dokumentiert war. Die Anzahl der Abweichungen zwischen Marts verschiedener Teams sank.
Gewonnene Erkenntnisse: Jede „magische Zahl" im SQL ist eine potenzielle Quelle versteckten Drifts.
Schwellenwerte müssen mit Metadaten einhergehen: wer hat sie festgelegt, warum, wann überprüfen.
Die Mart-Notiz ist kein Bericht über den Code, sondern ein Dokument über die Absichten des Autors.
Im Lernprojekt werden Schwellenwerte explizit als Übungsregeln markiert, nicht als Bankenwahrheit.
Verwandte Konzepte: Schwellenwert für hohe Beträge als Übungsregel
Notiz zum Mart (minimale Ausgabe)
Manuelle Fragen des Reviewers
Name: Fallstudie 3. Filter risk_flag = true ohne Spezifikation
Szenario: Ein Analyst bat einen KI-Agenten, einen „Mart für Risikooperationen" zu erstellen. Der Agent fügte, ohne die Spezifikation zu prüfen, die Bedingung WHERE risk_flag = true ins SQL ein. Der Mart enthielt nun nur Operationen, die von der Quelle als riskant markiert waren. Der Linter-Test bestand, und der Mart wurde veröffentlicht.
Aufgabe: Zwei Wochen später stellte sich heraus, dass der Audit-Konsument ALLE Operationen mit Risikoindikator im Mart erwartet hatte, einschließlich solcher, bei denen risk_flag einen nicht-binären Wert hat (z. B. Zwischenstatus). Ein Teil der Audit-Prüfungen ergab die falsche Schlussfolgerung „alles sauber", obwohl tatsächlich ein Teil der Operationen durch den Filter ausgefallen war. Entdeckt wurde dies erst bei der Untersuchung eines Vorfalls mit einer Kundenbeschwerde.
Lösung: Das Team formalisierte die Qwen-Anfrage als obligatorischen ersten Schritt: „Lies stg_card_transactions, mart_payment_risk_signals und specs. Bestimme die Granularität, welche Operationen eingeschlossen, welche ausgeschlossen sind und welche Prüffakten für den Risiko-Mart nötig sind. Ändere keine Dateien." Ohne diese Anfrage begann der Agent keine Analyse. Außerdem wurde in specs das explizite Feld included_rows_definition mit Aufzählung der Ein-/Ausschlusslogik hinzugefügt.
Ergebnis: Die Anzahl der Fälle, in denen der Filter risk_flag = true ohne Begründung auftauchte, sank. In die Notizvorlage wurden separate Zeilen „Eingeschlossene Zeilen" und „Ausgeschlossene Zeilen" aufgenommen, die VOR jeder SQL-Änderung ausgefüllt werden. Ein Quartal lang gab es keinen einzigen Vorfall im Zusammenhang mit stillschweigender Mart-Filterung.
Gewonnene Erkenntnisse: „Vereinfachung" des SQL ohne Abgleich mit der Spezifikation ist eine häufige Ursache für Breaking Changes.
Ein Filter auf einem binären Feld in der Quelle erfordert eine explizite Angabe in specs.
Die standardisierte Qwen-Anfrage fixiert die Rolle des Agenten als Beobachter.
Die Mart-Notiz diszipliniert die Trennung von „eingeschlossen/ausgeschlossen".
Verwandte Konzepte: Vollständigkeit des Marts vs. Filter risk_flag = true
risk_flag als Signal der Quelle
Qwen-Anfrage für die SDD-Analyse
Notiz zum Mart (minimale Ausgabe)
Lerntipps: Beginnen Sie mit der Frage „welche Zeile repräsentiert dieser Mart?" und halten Sie die Antwort fest, BEVOR Sie ins SQL schauen. Dies ist die häufigste Fehlerquelle.
Halten Sie stets drei Artefakte nebeneinander: specs, SQL und Mart-Notiz. Jede Abweichung zwischen ihnen ist ein Anlass für eine manuelle Frage des Reviewers.
Erstellen Sie eine Checkliste: transaction_id unique/not null? amount not null? Quelle des risk_flag angegeben? Keine PII? Schwellenwert in specs festgehalten?
Behandeln Sie risk_flag als Signal der Quelle, nicht als Entscheidung. Im Lernprojekt ist dies eine prinzipielle Grenze, die keine „Verbesserungen" zulässt.
Versuchen Sie nicht, das SQL eines Marts auf Operationsebene zu einem Aggregat nach Kunde zu „kürzen" – dies sind unterschiedliche Datenprodukte. Wenn der Konsument ein Aggregat benötigt, erstellen Sie einen separaten Mart mit separater Spezifikation.
Der Filter WHERE risk_flag = true ist ein rotes Tuch, wenn specs keine explizite Phrase „der Mart enthält nur Risikoereignisse" enthalten. Betrachten Sie ihn standardmäßig als Breaking Change.
Nutzen Sie die Notizvorlage als Disziplin: Füllen Sie die Felder „Eingeschlossene Zeilen" und „Ausgeschlossene Zeilen" VOR dem Schreiben des SQL aus – das zwingt zu explizitem vertraglichem Denken.
Markieren Sie alle „magischen Zahlen" im SQL (Schwellenwerte, Limits, Koeffizienten) und fordern Sie deren Vorhandensein in specs. Sonst erinnert sich nach einem halben Jahr niemand mehr, woher sie stammen.
Zusätzliche Ressourcen: Lehrbuch des Kurses (Teil 17): Abschnitt „Teil 17. Mart für Zahlungen und Risikosignale" – Hauptquelle, Kapitel Granularität, Was zu prüfen ist, Schlechter Ansatz, Qwen-Anfrage, Minimale Ausgabe, Analyse für den Leser, Übung, Typischer Fehler, Kontrollfragen.
Spezifikation des Marts: Datei specs für mart_payment_risk_signals – obligatorischer Kontext zum Ausfüllen der Mart-Notiz.
SQL des Marts: Datei mart_payment_risk_signals – Analyseobjekt, wird vom Agenten im Übungsszenario nicht editiert.
Staging-Schicht der Quelle: stg_card_transactions – enthält das ursprüngliche risk_flag als Signal der Quelle.
Methodik SDD: Specification-Driven Development – übergeordneter Rahmen, in dem der Risiko-Mart ein Beobachtungsartefakt ist, keine Entscheidung.
Vorlage für die Mart-Notiz: Minimale Ausgabe: Mart / Granularität / Quelle des Risk-Flags / Eingeschlossene Zeilen / Ausgeschlossene Zeilen / Prüffakten / Manuelle Fragen des Reviewers.
Kontrollfragen des Kapitels: Drei Fragen am Ende des Abschnitts: (1) warum Marts auf Operations- und Kundenebene nicht vermischt werden dürfen; (2) wann der Filter risk_flag = true den Vertrag bricht; (3) welches manuelle Faktum der Reviewer prüfen muss.
Zusammenfassung: Teil 17 führt eine zentrale SDD-Disziplin für die Zahlungsdomäne ein: Der Mart mart_payment_risk_signals ist eine Beobachtungsschicht, keine Scoring-Engine und keine Quelle für Risikoentscheidungen. Die Granularität des Marts wird strikt als „eine Zeile pro transaction_id" festgelegt, und jeder Versuch, sie durch eine Aggregation nach Kunde oder Tag zu ersetzen, ist die Schaffung eines neuen Datenprodukts mit eigener Spezifikation, nicht eine „Optimierung" des bestehenden. risk_flag wird als Signal der Quelle stg_card_transactions behandelt, nicht als Produktentscheidung; der Filter WHERE risk_flag = true ist nur bei expliziter Angabe in specs zulässig. Der Schwellenwert für hohe Beträge ist eine Übungsregel, die in specs, Prüfnotiz und Reviewer-Bericht dokumentiert sein muss, sonst wird sie zu einer versteckten magischen Zahl. Direkte PII gelangen nicht in den Mart. Die Hauptfertigkeit des Kapitels ist das Ausfüllen der standardisierten Vorlage für die Mart-Notiz (Mart / Granularität / Quelle des Risk-Flags / Eingeschlossene Zeilen / Ausgeschlossene Zeilen / Prüffakten / Manuelle Fragen des Reviewers), die Rolle der Signalquelle nicht mit der Rolle der Entscheidung zu verwechseln und Beobachtung von Schlussfolgerung zu trennen.