PULSE — Risiko.
Scoren, prüfen, handeln — innerhalb der erfassten Nachweise. PULSE bietet einen Decision Explorer; Begründungstiefe, Modellnutzung und Folgeaktionen hängen vom erzeugenden Workflow ab.
Wofür PULSE zuständig ist
- Entworfenes Scoring ausgewählter Checkout-, Konto-, Refund-, Auszahlungs- und Muster-Events, wenn Integrationen Daten liefern
- Regelbasierte Engine; der beobachtete ML-Indikator ist ein Stub und kein deploytes ML-Decisioning
- Entworfene Step-up-Ergebnisse wie 3DS, Re-Verifizierung, Review oder Hold, abhängig von Folgeintegrationen
- Decision- und Alert-Referenzen, die bei konfiguriertem Fall-Workflow an DOCKET übergeben werden können
SENTINEL ist die vorgesehene Governance-Fläche für Regeln und Schwellen, PULSE konsumiert passende Versionen. Prüfen Sie, ob die erzeugte Entscheidung die referenzierte Policy tatsächlich erfasst und anwendet; Architektur allein beweist keine Runtime-Parität und verhindert keinen Drift.
Einen Decision Record lesen
Compliance Console → Risiko → Decision Explorer ist die beobachtete PULSE-Fläche. Filter und Records können Ergebnis-, Score-, Regel-, Versions-, Input- und Korrelationsfelder zeigen, doch die Begründung ist partiell. Fehlende Felder heißen Nicht vom System erfasst, nicht PASS. Der ML-Chip ist ein Stub; bei rules-only heißt Modellversion Nicht anwendbar.
Ein entworfener Governance-Zyklus fürs Tuning
Muster finden
Nutzen Sie verfügbare Filter für eine Hypothese; prüfen Sie Quellen-Vollständigkeit, bevor Sie einen Cluster als False-Decline-Muster bezeichnen.
Änderung vorschlagen
Entwerfen Sie eine Änderung in SENTINEL, wo aktiviert. Historische Auswirkungssimulation ist zu prüfen, nicht vorauszusetzen.
Vier-Augen-Freigabe
Eine zweite Person nur dort einsetzen, wo Maker-Checker konfiguriert ist. Aktivierung und Versionsnachweis vor Release bestätigen.
Scorecard beobachten
PRISM-Scorecard auf Abruf erzeugen und vereinbarte Maße gegen Baseline prüfen. Scheduling und Rollback sind separat zu verifizieren.
Chargebacks und Representment
Der entworfene Chargeback-Workflow kann Disputes mit Entscheidungen, Nachweisen und Fällen verbinden, wenn die Records integriert sind. Representment enthält nur tatsächlich vorhandene Daten wie 3DS, Zustellung oder Kommunikation. DOCKET-SLA, Zuweisung und Maker-Checker sind für diesen Workflow zu prüfen.
Eine Entscheidung ist nur anhand der erfassten Regel-IDs, Schwellen, Snapshots, Versionen und Review-Events rekonstruierbar. PULSE-Begründung ist partiell; fehlende Informationen bleiben explizit statt nachträglich ergänzt zu werden.
Das komplette Handbuch als PDF? Hinterlassen Sie uns Ihre E-Mail — wir senden es Ihnen zu.
Handbuch anfordern