Le manuel utilisateur TrustStack ORION.
Un guide pratique pour opérateurs, analystes, administrateurs marchands et intégrateurs — organisé autour de cinq applications et de quatorze modules enregistrés, en séparant surfaces observées et workflows cibles.
À qui s’adresse ce manuel
TrustStack est conçu pour les équipes marchandes travaillant dans leur propre tenant et pour les opérations de conformité côté fournisseur travaillant sur plusieurs tenants. La visibilité de la navigation dépend du rôle, de l’entitlement, des feature flags et de la configuration ; un écran présenté dans ce manuel peut donc être absent ou en lecture seule dans un environnement donné.
Comment la plateforme est organisée
Le registre revu contient quatorze modules en trois anneaux. Core — GATE, PULSE, SWITCH, LEDGER, SENTINEL, PRISM — et Add-ons — STUDIO, TRAVEL, AURA, MoR — sont des entitlements vendables. Plateforme — DOCKET, VAULT, HELM, FORGE — est enregistré comme socle always_on, mais l’accès reste dépendant du rôle et de la configuration. Le statut de registre ui confirme une interface ou une surface de lecture, pas une disponibilité générale ni une complétude.
Les modules sont conçus pour relier cinq applications : la Compliance Console, le Client & Onboarding Portal, le Developer Portal, l’Evidence Portal et l’Admin Console. Une application est un public ; un module est une capacité. Un résultat de screening peut transmettre du travail à un dossier DOCKET et référencer des preuves VAULT lorsque les intégrations, champs et contrôles d’accès pertinents sont configurés.
La seule idée à retenir
Un Decision Record est conçu pour relier un résultat au contexte réellement enregistré par le workflow producteur : règles, seuils, entrées, versions, corrélation et événements de revue le cas échéant. Les champs manquants doivent indiquer Non enregistré par le moteur ou Non applicable. L’export de preuves n’est disponible que sur des surfaces prises en charge et configurées ; il ne prouve pas que chaque événement ou document a été capturé.
Conventions utilisées ici
- Les chemins d’écran s’écrivent App → Section → Écran, p. ex. Compliance Console → Dossiers → Détail du dossier.
- Les noms de modules sont en capitales (GATE, PULSE) ; les mêmes noms apparaissent dans la navigation, les entitlements et les événements d’audit.
- Les procédures numérotées décrivent des chemins produit prévus ; confirmez la version déployée, l’entitlement et le feature flag avant de les traiter comme des instructions exactes.
- Les encadrés signalent les comportements pertinents pour l’audit — ce qu’un réviseur ou un examinateur regardera plus tard.
Premiers pas
Du cadrage à un premier exercice de décision délimité : modèles de fourniture, entitlements, mise en place, validation et cadence opérationnelle.
02Les cinq applications
Compliance Console, Client & Onboarding Portal, Developer Portal, Evidence Portal, Admin Console — qui utilise quelle application, et pour quoi.
03GATE — Vérifier
Surfaces observées de KYC hébergé et de parties, avec tiering, screening, revue et re-vérification conçus ; limites actuelles UBO et de revue.
04PULSE — Risque
L’explorateur de décisions observé pour des décisions de risque règles d’abord ; la motivation est partielle et l’indicateur ML actuel est un stub.
05SWITCH — Paiements
Lectures partielles de configuration de routage et de chemins de paiement ; connectivité réelle, bascule et résilience de production non établies.
06LEDGER — Fiscalité & Finance
Lectures observées de fiscalité et de livres avec des taux statiques ; résultats fiscaux, dépôts et intégrité des livres exigent une validation délimitée.
07SENTINEL — Politique
Surfaces observées de screening et de politique avec liste de démonstration étiquetée ; couverture des prestataires et maker-checker selon configuration.
08PRISM — Analyses
Tableaux de bord observés et scorecards à la demande ; le reporting planifié et la complétude des rapports ne sont pas établis par le statut actuel.
09Add-ons — STUDIO, TRAVEL, AURA, MoR
Lectures conditionnelles d’add-ons : modération de contenu, travel rule, couverture et merchant of record ; l’entitlement n’est qu’un gate parmi d’autres.
10Anneau plateforme — DOCKET, VAULT, HELM, FORGE
Le socle plateforme always_on du registre : dossiers, preuves, administration et développement soumis aux rôles, avec couverture propre au workflow.
11Preuves & piste d’audit
Concepts de Decision Record et de preuve, surfaces observées de lecture/export délimitées, limites de vérification et accès conditionnel pour la revue externe.
12L’univers des scénarios
Ce que démontrent les scénarios interactifs d’e-kmc.io, quelles fixtures ils utilisent et ce qu’ils ne prouvent délibérément pas.
13Glossaire
Le vocabulaire de la plateforme : Decision Record, pack de preuves, maker-checker, entitlement, tenant, et le reste.
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