Benutzerhandbuch

Das TrustStack-ORION-Benutzerhandbuch.

Ein praktischer Leitfaden für Operatoren, Analysten, Händler-Admins und Integratoren — fünf Apps und vierzehn registrierte Module, mit klarer Trennung von beobachteten Oberflächen und Ziel-Workflows.

Für wen dieses Handbuch ist

TrustStack ist für Händlerteams im eigenen Tenant und anbieterseitige Compliance-Operations über mehrere Tenants konzipiert. Die Navigation hängt von Rolle, Entitlement, Feature-Flags und Konfiguration ab; ein hier beschriebener Screen kann daher in einer Umgebung fehlen oder nur lesbar sein.

Wie die Plattform organisiert ist

Das geprüfte Register enthält vierzehn Module in drei Ringen. Core — GATE, PULSE, SWITCH, LEDGER, SENTINEL, PRISM — und Add-ons — STUDIO, TRAVEL, AURA, MoR — sind verkaufbare Entitlements. Plattform — DOCKET, VAULT, HELM, FORGE — ist als always_on-Fabric registriert; Zugriff bleibt rollen- und konfigurationsabhängig. Status ui bestätigt eine Oberfläche oder Leseansicht, nicht allgemeine Verfügbarkeit oder Vollständigkeit.

Module sollen fünf Apps verbinden: Compliance Console, Client & Onboarding Portal, Developer Portal, Evidence Portal und Admin Console. Eine App steht für ein Publikum, ein Modul für eine Fähigkeit. Ein Screening-Ergebnis kann Arbeit an DOCKET übergeben und VAULT-Nachweise referenzieren, wenn Integrationen, Felder und Zugriffskontrollen eingerichtet sind.

Der eine Gedanke zum Behalten

Signale rein → prüfbare Entscheidungen raus.

Ein Decision Record soll ein Ergebnis mit dem tatsächlich erfassten Kontext verbinden: Regeln, Schwellen, Inputs, Versionen, Korrelation und Review-Ereignissen, soweit anwendbar. Fehlende Felder heißen Nicht vom System erfasst oder Nicht anwendbar. Nachweisexport gibt es nur auf unterstützten, konfigurierten Oberflächen; er beweist nicht, dass jedes Ereignis oder Dokument erfasst wurde.

Konventionen in diesem Handbuch

  • Screen-Pfade schreiben wir als App → Bereich → Screen, z. B. Compliance Console → Fälle → Falldetail.
  • Modulnamen stehen in Versalien (GATE, PULSE); dieselben Namen erscheinen in Navigation, Entitlements und Audit-Events.
  • Nummerierte Prozeduren beschreiben beabsichtigte Produktpfade; prüfen Sie Version, Entitlement und Feature-Flag, bevor Sie sie als exakte Anleitung nutzen.
  • Hervorhebungen markieren audit-relevantes Verhalten — Dinge, auf die ein Prüfer später schaut.
01

Erste Schritte

Vom Scope zur begrenzten ersten Entscheidungsübung: Betriebsmodelle, Entitlements, Einrichtung, Validierung und Betriebskadenz.

02

Die fünf Apps

Compliance Console, Client & Onboarding Portal, Developer Portal, Evidence Portal, Admin Console — wer welche App wofür nutzt.

03

GATE — Verifizieren

Beobachtete Hosted-KYC- und Parteioberflächen mit entworfenen Tiering-, Screening-, Review- und Re-Verifizierungsabläufen; aktuelle UBO- und Review-Grenzen gelten.

04

PULSE — Risiko

Der beobachtete Decision Explorer für regelbasierte Risikoentscheidungen; Begründung ist partiell, der aktuelle ML-Indikator ein Stub.

05

SWITCH — Zahlungen

Partielle Routing-Konfigurations- und Zahlungspfad-Leseoberflächen; Live-Prozessoren, automatischer Failover und Produktionsresilienz sind nicht belegt.

06

LEDGER — Steuern & Finanzen

Beobachtete Steuer- und Ledger-Leseoberflächen mit statischen Raten; Steuerergebnisse, Filings und Ledger-Integrität brauchen Scope-Validierung.

07

SENTINEL — Policy

Beobachtete Screening- und Policy-Flächen mit gekennzeichneter Demoliste; Anbieterabdeckung, Lifecycle-Aktionen und Maker-Checker sind konfigurationsabhängig.

08

PRISM — Einblicke

Beobachtete Dashboards und Generate-now-Scorecards; geplantes Reporting, SLA-Monitoring und Report-Vollständigkeit sind nicht belegt.

09

Add-ons — STUDIO, TRAVEL, AURA, MoR

Bedingte Add-on-Leseoberflächen für Moderation, Travel Rule, Coverage und Merchant of Record; Entitlement ist nur eines mehrerer Gates.

10

Plattform-Ring — DOCKET, VAULT, HELM, FORGE

Das im Register als always_on markierte Plattform-Fabric: rollenbasierte Fall-, Nachweis-, Admin- und Developer-Flächen mit workflow-spezifischer Abdeckung.

11

Nachweise & der Prüfpfad

Decision-Record- und Nachweiskonzepte, beobachtete begrenzte Lese-/Exportflächen, Verifikationsgrenzen und bedingter Prüferzugang.

12

Das Szenario-Universum

Was die interaktiven Szenarien auf e-kmc.io zeigen, welche Fixtures sie nutzen und was sie bewusst nicht beweisen.

13

Glossar

Das Plattform-Vokabular: Decision Record, Beweispaket, Vier-Augen-Prinzip, Entitlement, Tenant und mehr.

Das komplette Handbuch als PDF? Hinterlassen Sie uns Ihre E-Mail — wir senden es Ihnen zu.

Handbuch anfordern