Catorce módulos. Tres anillos. Un registro.

Use GATE para encuadrar quién o qué parte está bajo revisión, qué se registró realmente y qué condición sigue abierta. Por sí solo no establece un programa KYC/KYB completo, un flujo de UBO ni un servicio de onboarding disponible de forma general.

Superficie actual: KYC alojado y lecturas de partes; la revisión está tras un feature flag; la captura de UBO está ausente en el estado revisado.

• Superficies UI/de lectura observadas de KYC alojado y partes
• Ruta de revisión presente tras un feature flag, no asumida para cada tenant
• La captura de UBO está ausente en el estado revisado y sigue siendo un requisito de validación
• Diseñado para transmitir el contexto de identidad registrado a los flujos de screening, políticas y casos
• El step-up, la reverificación y la evidencia documental requieren configuración a nivel de recorrido

PULSE está pensado para conectar las señales de riesgo disponibles con una decisión que pueda cuestionarse. En el estado revisado, la propuesta honesta es una UI exploratoria con justificación parcial — no un scoring completo en tiempo real, ni explicación universal, ni resultados probados contra el fraude.

Superficie actual: Decision Explorer con justificación parcial; el indicador de ML es un stub, no la afirmación de un modelo activo.

• Decision Explorer observado y superficies UI/de lectura de justificación parcial
• Patrón de decisión basado en reglas; cualquier uso de modelos es opcional y se valida por separado
• El indicador de ML actual es un stub y no debe presentarse como un modelo activo
• Las acciones diseñadas incluyen aprobar, step-up, revisar y retener cuando estén configuradas
• El contexto ausente de entradas, umbrales o versiones permanece explícito en lugar de inferirse

SWITCH hace inspeccionables la ruta propuesta, el tráfico retenido y el contexto de ruta disponible. Un ejercicio delimitado puede probar el patrón de control, pero la conectividad PSP en vivo, el rendimiento del enrutamiento, la resiliencia y los niveles de servicio deben probarse por separado.

Superficie actual: lecturas parciales de configuración de enrutamiento y traza de ruta de pago; no se infiere ningún proveedor en vivo ni failover automático.

• Superficies UI/de lectura parciales observadas de configuración de enrutamiento
• Lecturas observadas de la traza de ruta de pago para los datos fixture disponibles
• Los factores de enrutamiento diseñados incluyen estado del proveedor, elegibilidad, geografía, coste y contexto de riesgo
• El comportamiento de payouts, reintentos y fallback depende de proveedores conectados y políticas validadas
• La UI no establece tráfico de producción, redundancia de proveedores ni failover automático

LEDGER puede aportar un ancla financiera sólida cuando la fuente, el estado de los asientos y el contexto de conciliación están disponibles. El resultado fiscal sigue siendo un cálculo sensible a las entradas: la jurisdicción, la fuente del tipo, la fecha de base y el informe previsto deben validarse en lugar de asumirse.

Superficie actual: los libros son el área observada más sólida; los tipos impositivos son estáticos y deben mostrarse con la fecha de su base de cálculo.

• Superficies UI/de lectura observadas orientadas a libros y finanzas
• Tipos impositivos estáticos en el estado revisado; exponga siempre la fecha de la base de cálculo aplicable
• Diseñado para conservar entradas fiscales, base y resultado como un snapshot de decisión fechado
• El comportamiento de conciliación, wallets y exportación sigue dependiendo del flujo de trabajo y de la integración
• Ninguna afirmación de presentación automática, corrección fiscal universal ni libros inmutables

SENTINEL está pensado para responder qué política y qué disposición informaron una acción. La superficie revisada puede demostrar ese patrón de control, pero no la completitud actual de las listas de sanciones, ni un maker-checker universal, ni la aplicación automatizada, ni el cumplimiento regulatorio.

Superficie actual: las lecturas de screening y políticas usan una lista de screening DEMO; la cobertura de listas y los feeds en vivo no están establecidos.

• Superficies UI/de lectura observadas de screening y políticas
• La fuente de screening actual es una lista DEMO y debe etiquetarse como tal
• El contexto de políticas diseñado incluye condiciones de geografía, producto, edad y método de pago
• El versionado, la aprobación y el rollback dependen del flujo de gobernanza configurado
• La entrega de reglas en runtime y los feeds de screening externos requieren integración y validación

PRISM puede ayudar a un piloto a preguntarse si los mismos hechos registrados producen una vista operativa y de evidencia útil. La reproducibilidad depende de datos fuente completos, definiciones, versiones y lógica de exportación; la UI actual no prueba un reporting de producción programado.

Superficie actual: dashboards y scorecards generadas bajo demanda; el reporting programado, la monitorización contractual de niveles de servicio y las salidas aceptadas por autoridades no están establecidos.

• Superficies UI/de lectura de dashboards observadas para los datos operativos disponibles
• Las scorecards se generan bajo demanda en el estado revisado, no de forma programada automática
• Las comparaciones diseñadas requieren una línea base, definiciones y un periodo de informe acordados
• Los cuestionarios y extractos siguen dependiendo del propósito, el rol y los datos fuente
• No se afirma monitorización contractual pública de niveles de servicio, ni informes aceptados por autoridades, ni resultados KPI de clientes