Das geprüfte Maschinenregister definiert vierzehn Domänen in drei Ringen, derzeit alle mit Status ui. Tenant-Entitlements, Integrationsreife und Produktionsverfügbarkeit werden separat bestätigt; ein Registereintrag bedeutet nicht GA.
TrustStack Core — Registrierte Core-Domänen mit ui-/Leseflächen. Eine oder mehrere erst nach Funktions- und Integrationsvalidierung in den Umfang aufnehmen.
GATE · Verifizieren
Identitätskontext sichtbar machen, bevor sich der Umfang ändert.
Beobachtete UI-/Lesefläche · Registerstatus: ui · nicht GA
GATE macht sichtbar, wer oder welche Partei geprüft wird, was tatsächlich aufgezeichnet wurde und welche Bedingung offen bleibt. Es belegt für sich weder ein vollständiges KYC/KYB-Programm noch einen UBO-Workflow oder einen allgemein verfügbaren Onboarding-Service.
Aktuelle Oberfläche: gehostete KYC- und Parteien-Leseansichten; Review ist Feature-Flag-gesteuert; UBO-Erfassung fehlt im geprüften Stand.
Beobachtete gehostete KYC- und Parteien-UI-/Leseflächen
Review-Pfad hinter einem Feature Flag, nicht für jeden Tenant vorausgesetzt
UBO-Erfassung fehlt im geprüften Stand und bleibt eine Validierungsanforderung
Dafür konzipiert, aufgezeichneten Identitätskontext an Screening-, Policy- und Fall-Workflows weiterzugeben
Step-up, Re-Verifizierung und Dokumentnachweise erfordern eine Konfiguration für den jeweiligen Entscheidungsweg
Aufgezeichnete Signale in eine prüfbare Entscheidung übersetzen.
Beobachtete UI-/Lesefläche · Registerstatus: ui · nicht GA
PULSE soll verfügbare Risikosignale mit einer anfechtbaren Entscheidung verbinden. Im geprüften Stand ist die ehrliche Proposition eine explorative UI mit partieller Begründung — kein vollständiges Echtzeit-Scoring, keine universelle Erklärung und kein belegtes Fraud-Ergebnis.
Aktuelle Oberfläche: Decision Explorer mit partieller Begründung; der ML-Indikator ist ein Stub und kein Nachweis für ein aktives Modell.
Beobachteter Decision Explorer und partielle UI-/Leseflächen zur Begründung
Regelbasiertes Entscheidungsmuster; jede Modellnutzung ist optional und separat zu validieren
Der aktuelle ML-Indikator ist ein Stub und darf nicht als aktives Modell dargestellt werden
Konzipierte Aktionen umfassen Genehmigen, Step-up, Review und Hold, sofern konfiguriert
Fehlender Eingabe-, Schwellen- oder Versionskontext bleibt explizit, statt abgeleitet zu werden
Zahlungspfad, Auswahl und Grenzen sichtbar machen.
Beobachtete UI-/Lesefläche · Registerstatus: ui · nicht GA
SWITCH macht den vorgeschlagenen Pfad, gehaltenen Traffic und verfügbaren Pfadkontext prüfbar. Eine begrenzte Übung kann das Kontrollmuster testen; Live-PSP-Anbindung, Routing-Leistung, Resilienz und Service Levels müssen separat belegt werden.
Aktuelle Oberfläche: partielle Routing-Konfiguration und Zahlungspfad-Leseansichten; daraus sind weder Live-Provider noch automatischer Failover abzuleiten.
Beobachtete partielle UI-/Leseflächen zur Routing-Konfiguration
Beobachtete Zahlungspfad-Leseansichten für verfügbare Fixture-Daten
Konzipierte Routing-Faktoren umfassen Provider-Status, Eligibility, Geografie, Kosten und Risikokontext
Payout-, Retry- und Fallback-Verhalten hängt von angebundenen Providern und validierter Policy ab
Die UI belegt weder Produktions-Traffic noch Provider-Redundanz oder automatischen Failover
Beobachtete UI-/Lesefläche · Registerstatus: ui · nicht GA
LEDGER kann einen starken Finance-Anker liefern, wenn Quelle, Buchungsstatus und Rekonziliationskontext verfügbar sind. Das Steuerergebnis bleibt eingabeabhängig: Jurisdiktion, Satzquelle, Basisdatum und Berichtszweck müssen validiert und dürfen nicht vorausgesetzt werden.
Aktuelle Oberfläche: Bücher sind der stärkste beobachtete Bereich; Steuersätze sind statisch und müssen mit dem Datum ihrer Berechnungsgrundlage gezeigt werden.
Beobachtete UI-/Leseflächen für Bücher und Finanzen
Statische Steuersätze im geprüften Stand; stets das Datum der anwendbaren Berechnungsgrundlage ausweisen
Dafür konzipiert, Steuereingaben, Grundlage und Ergebnis als datierten Entscheidungs-Snapshot zu bewahren
Rekonziliation, Wallet- und Exportverhalten bleiben workflow- und integrationsabhängig
Keine Aussage zu automatischer Abgabe, universeller steuerlicher Richtigkeit oder unveränderlichen Büchern
Sichtbar machen, welcher Policy-Kontext die Entscheidung steuerte.
Beobachtete UI-/Lesefläche · Registerstatus: ui · nicht GA
SENTINEL soll beantworten, welche Policy und Disposition eine Aktion beeinflussten. Die geprüfte Oberfläche kann dieses Kontrollmuster demonstrieren, aber weder Vollständigkeit von Sanktionslisten noch universelles Vier-Augen-Prinzip, automatische Durchsetzung oder regulatorische Compliance.
Aktuelle Oberfläche: Screening- und Policy-Leseansichten nutzen eine DEMO-Liste; Listenabdeckung und Live-Feeds sind nicht belegt.
Beobachtete Screening- und Policy-UI-/Leseflächen
Die aktuelle Screening-Quelle ist eine DEMO-Liste und muss entsprechend gekennzeichnet sein
Der konzipierte Policy-Kontext umfasst Geo-, Produkt-, Alters- und Zahlartenbedingungen
Versionierung, Freigabe und Rollback hängen vom konfigurierten Governance-Workflow ab
Runtime-Regelbereitstellung und externe Screening-Feeds erfordern Integration und Validierung
Verfügbare Betriebsdaten in eine begrenzte Sicht übersetzen.
Beobachtete UI-/Lesefläche · Registerstatus: ui · nicht GA
PRISM kann in einer Evaluation prüfen helfen, ob dieselben aufgezeichneten Fakten eine nützliche Betriebs- und Nachweissicht ergeben. Reproduzierbarkeit hängt von vollständigen Quelldaten, Definitionen, Versionen und Exportlogik ab; die aktuelle UI belegt kein geplantes Produktionsreporting.
Aktuelle Oberfläche: Dashboards und auf Abruf erzeugte Scorecards; geplantes Reporting, SLA-Monitoring und regulatorfertige Ausgaben sind nicht belegt.
Beobachtete Dashboard-UI-/Leseflächen für verfügbare Betriebsdaten
Scorecards werden im geprüften Stand auf Abruf und nicht automatisch nach Zeitplan erzeugt
Konzipierte Vergleiche erfordern vereinbarte Baseline, Definitionen und Berichtszeitraum
Fragebögen und Auszüge bleiben zweck-, rollen- und quelldatenabhängig
Kein öffentliches SLA-Monitoring, regulatorfertiger Bericht oder Kunden-KPI-Ergebnis wird behauptet
MoR ist im geprüften Stand eine partielle ui-/Lesefläche; jede Bereitstellung hängt von Jurisdiktion, Lizenzierung, rechtlicher Prüfung und Vertrag ab.
Plattform-Ring — immer aktiv — Gemeinsame Fall-, Nachweis-, Administrations- und Entwicklerbasis in der Zielarchitektur. Zugriff und Verhalten bleiben rollen-, entitlement- und deploymentabhängig.
Die Zielverträge verbinden GATE-Identitätskontext mit SENTINEL-Screening, lassen PULSE gesteuerte Regel-Packs nutzen und Fälle in DOCKET eröffnen und führen verfügbare Audit-Ereignisse zu VAULT sowie Reporting-Daten zu PRISM. Exakte Produzenten, Felder und Durchsetzung werden je Workflow validiert; fehlende Nachweise werden nicht abgeleitet.