PULSE — Riesgo.
Puntuar, inspeccionar, actuar — dentro de la evidencia registrada. PULSE expone un explorador de decisiones, mientras que la completitud de la justificación, el uso de modelos y las acciones posteriores dependen del flujo productor.
Qué posee PULSE
- Scoring diseñado para eventos seleccionados de checkout, cuenta, reembolso, payout y patrones sospechosos cuando esas integraciones aportan datos
- Un motor basado en reglas; el indicador de ML observado es un stub y no debe presentarse como decisión por ML desplegada
- Resultados de step-up diseñados como 3DS, reverificación, revisión manual o retención, sujetos a la integración posterior
- Referencias de decisiones y alertas que pueden traspasar trabajo a DOCKET donde el flujo de casos pertinente esté configurado
SENTINEL es la superficie de gobernanza prevista para reglas y umbrales, mientras que PULSE consume las versiones aplicables. Verifique que la decisión productora registra y aplica realmente la versión de política referenciada; la arquitectura por sí sola no prueba paridad en runtime ni evita la deriva.
Leer un Decision Record
Compliance Console → Riesgo → Decision Explorer es la superficie observada de PULSE. Los filtros y los registros pueden exponer campos de resultado, score, regla, versión, entrada y correlación, pero la justificación es parcial en el estado revisado. Trate los campos ausentes como No registrado por el motor, no como PASS. El chip de ML es un stub; las decisiones solo con reglas deberían mostrar la versión del modelo como No aplicable.
Un bucle de gobernanza diseñado para el ajuste
Encontrar el patrón
Use los filtros disponibles del explorador para formular una hipótesis; valide la completitud de las fuentes antes de llamar a un clúster patrón de falsos rechazos.
Proponer el cambio
Redacte un cambio de umbral o regla en SENTINEL donde esté habilitado. La simulación de impacto histórico debe verificarse en lugar de asumirse.
Aprobación a cuatro ojos
Use un segundo revisor autorizado solo donde esa acción soporte el maker-checker configurado. Confirme la evidencia de activación y versión antes del release.
Vigilar la scorecard
Genere la scorecard de PRISM bajo demanda y compare las métricas acordadas con la línea base. La programación y el comportamiento de rollback son capacidades separadas a verificar.
Chargebacks y representment
El flujo de chargebacks diseñado puede enlazar una disputa con decisiones, evidencia y casos cuando esos registros están integrados. Un paquete de representment puede incluir solo los datos realmente disponibles, como registros de 3DS, entrega o comunicación. El comportamiento de SLA, asignación y maker-checker de DOCKET debe verificarse para este flujo.
Una decisión es reconstruible solo en la medida en que su motor registró IDs de reglas, umbrales, snapshots, versiones y eventos de revisión posteriores. La justificación de PULSE es parcial en la superficie revisada; la información ausente debe permanecer explícita en lugar de inferirse a posteriori.
¿Quiere el manual completo en PDF? Escríbanos y se lo enviamos — el botón abre su aplicación de correo, o copie la dirección de abajo.
Solicitar el manual por correooffice@e-kmc.io