PULSE — Risque.
Scorer, inspecter, agir — dans les limites des preuves enregistrées. PULSE expose un explorateur de décisions, tandis que la complétude de la motivation, l’usage de modèles et les actions en aval dépendent du workflow producteur.
Ce que PULSE possède
- Scoring conçu pour des événements sélectionnés de checkout, de compte, de remboursement, de paiement sortant et de schéma suspect, lorsque ces intégrations fournissent des données
- Un moteur règles d’abord ; l’indicateur ML observé est un stub et ne doit pas être présenté comme un décisionnement ML déployé
- Des résultats de step-up conçus tels que 3DS, re-vérification, revue manuelle ou hold, sous réserve d’intégration en aval
- Des références de décisions et d’alertes pouvant transmettre du travail à DOCKET là où le workflow de dossiers correspondant est configuré
SENTINEL est la surface de gouvernance prévue pour les règles et les seuils, tandis que PULSE consomme les versions applicables. Vérifiez que la décision produite enregistre et applique réellement la version de politique référencée ; l’architecture seule ne prouve pas la parité à l’exécution et n’empêche pas la dérive.
Lire un Decision Record
Compliance Console → Risque → Explorateur de décisions est la surface PULSE observée. Les filtres et enregistrements peuvent exposer les champs de résultat, de score, de règle, de version, d’entrée et de corrélation, mais la motivation est partielle dans le statut revu. Traitez les champs absents comme Non enregistré par le moteur, pas comme PASS. La puce ML est un stub ; les décisions à règles seules doivent afficher la version de modèle comme Non applicable.
Une boucle de gouvernance conçue pour l’ajustement
Trouver le motif
Utilisez les filtres disponibles de l’explorateur pour former une hypothèse ; validez la complétude des sources avant de qualifier un cluster de schéma de faux refus.
Proposer le changement
Rédigez un changement de seuil ou de règle dans SENTINEL là où c’est activé. La simulation d’impact historique doit être vérifiée plutôt que présumée.
Approbation à quatre yeux
N’utilisez un second réviseur autorisé que là où cette action prend en charge un maker-checker configuré. Confirmez l’activation et la preuve de version avant la mise en service.
Suivre la scorecard
Générez la scorecard PRISM à la demande et comparez les mesures convenues à la baseline. La planification et le comportement de rollback sont des capacités distinctes à vérifier.
Chargebacks et representment
Le workflow de chargeback conçu peut relier un litige aux décisions, preuves et dossiers lorsque ces enregistrements sont intégrés. Un pack de representment ne peut inclure que des données réellement détenues, comme les enregistrements 3DS, de livraison ou de communication. Le SLA DOCKET, l’affectation et le comportement maker-checker doivent être vérifiés pour ce workflow.
Une décision n’est reconstructible que dans la mesure où son moteur a enregistré les identifiants de règles, seuils, instantanés, versions et événements de revue ultérieurs. La motivation PULSE est partielle dans la surface revue ; l’information manquante doit rester explicite plutôt que d’être inférée après coup.
Vous voulez le manuel complet en PDF ? Écrivez-nous et nous vous l’enverrons — le bouton ouvre votre application e-mail, ou copiez l’adresse ci-dessous.
Demander le manuel par e-mailoffice@e-kmc.io