Manual de usuario

El manual de usuario de TrustStack ORION.

Una guía práctica para operadores, analistas, administradores de comercios e integradores — organizada en torno a cinco apps y catorce módulos registrados, separando las superficies observadas de los flujos objetivo.

Para quién es este manual

TrustStack está diseñado para equipos de comercios que trabajan en su propio tenant y para operaciones de cumplimiento del lado del proveedor que trabajan entre tenants. La visibilidad de la navegación depende del rol, el entitlement, los feature flags y la configuración; una pantalla mostrada en este manual puede, por tanto, estar ausente o ser de solo lectura en un entorno concreto.

Cómo se organiza la plataforma

El registro revisado contiene catorce módulos en tres anillos. Core — GATE, PULSE, SWITCH, LEDGER, SENTINEL, PRISM — y Add-ons — STUDIO, TRAVEL, AURA, MoR — son entitlements comercializables. Plataforma — DOCKET, VAULT, HELM, FORGE — está registrado como tejido always_on, pero el acceso sigue dependiendo del rol y de la configuración. El estado de registro ui confirma una interfaz o superficie de lectura, no disponibilidad general ni completitud.

Los módulos están diseñados para conectar cinco apps: la Compliance Console, el Client & Onboarding Portal, el Developer Portal, el Evidence Portal y la Admin Console. Una app es una audiencia; un módulo es una capacidad. Un resultado de screening puede traspasar trabajo a un caso de DOCKET y referenciar evidencia de VAULT cuando las integraciones, campos y controles de acceso pertinentes están configurados.

La única idea que hay que retener

Señales que entran → decisiones inspeccionables que salen.

Un Decision Record está diseñado para conectar un resultado con el contexto que el flujo productor realmente registró: reglas, umbrales, entradas, versiones, correlación y eventos de revisión cuando proceda. Los campos ausentes deben leerse como No registrado por el motor o No aplicable. La exportación de evidencia está disponible solo en superficies soportadas y configuradas; no es prueba de que cada evento o documento fuera capturado.

Convenciones usadas aquí

  • Las rutas de pantalla se escriben como App → Sección → Pantalla, p. ej. Compliance Console → Casos → Detalle del caso.
  • Los nombres de módulos van en mayúsculas (GATE, PULSE); los mismos nombres aparecen en la navegación, los entitlements y los eventos de auditoría.
  • Los procedimientos numerados describen rutas de producto previstas; confirme la versión desplegada, el entitlement y el feature flag antes de tratarlos como instrucciones exactas.
  • Los recuadros señalan comportamiento relevante para auditoría — lo que un revisor o examinador mirará más adelante.
01

Primeros pasos

Del scoping a un primer ejercicio de decisión acotado: modelos de entrega, entitlements, configuración, validación y cadencia operativa.

02

Las cinco apps

Compliance Console, Client & Onboarding Portal, Developer Portal, Evidence Portal, Admin Console — quién usa qué app y para qué.

03

GATE — Verificar

Superficies observadas de KYC alojado y partes, con flujos diseñados de niveles, screening y reverificación; aplican los límites actuales de UBO y revisión.

04

PULSE — Riesgo

El explorador de decisiones observado para decisiones de riesgo basadas en reglas; la justificación es parcial y el indicador de ML actual es un stub.

05

SWITCH — Pagos

Lecturas parciales de configuración de enrutamiento y ruta de pago; la conectividad en vivo, el failover y la resiliencia en producción no están establecidos.

06

LEDGER — Impuestos y finanzas

Lecturas fiscales y contables observadas con tablas de tipos estáticas; resultados fiscales, presentaciones e integridad contable requieren validación acotada.

07

SENTINEL — Políticas

Superficies observadas de screening y políticas con una lista de demostración etiquetada; cobertura de proveedores y maker-checker dependen de la configuración.

08

PRISM — Análisis

Superficies observadas de dashboards y scorecards bajo demanda; el reporting programado y la completitud de los informes no están establecidos hoy.

09

Add-ons — STUDIO, TRAVEL, AURA, MoR

Lecturas condicionales de add-ons para moderación de contenido, travel rule, cobertura y merchant of record; el entitlement es solo uno de varios gates.

10

Anillo de plataforma — DOCKET, VAULT, HELM, FORGE

El tejido always_on del registro: superficies de casos, evidencia, administración y desarrollo condicionadas por rol, con cobertura específica por flujo.

11

Evidencia y pista de auditoría

Conceptos de Decision Record y evidencia, superficies acotadas de lectura/exportación, límites de verificación y acceso condicional para revisión externa.

12

El universo de escenarios

Qué demuestran los escenarios interactivos de e-kmc.io, qué fixtures usan y qué deliberadamente no prueban.

13

Glosario

El vocabulario de la plataforma: Decision Record, paquete de evidencia, maker-checker, entitlement, tenant y el resto.

¿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 correo office@e-kmc.io