01Das Deployment auf einem Screen
Die Übersicht eröffnet den Tag. Systemzustand von Wartung, API-Bridge, Datenbank und Cache. Signale zu Breakern, Anbietern und ungelösten Fehlern. Die Arbeit als gezählte Warteschlangen – 12 offene KYC-Prüfungen, die älteste seit 5h 02m, 8 Abstimmungsdifferenzen mit €18,240 zur Gutschrift bereit, 2 Freigaben ausstehend. Darunter folgen die letzten privilegierten Aktionen und der Zustand je Anbieter. Nichts auf diesem Screen erfordert ein zweites Tool.
- System, Signale und Warteschlangen in einer vertikalen Ansicht
- Jede Karte verlinkt auf die Warteschlange, die sie zählt
- Anbieterzustand je Rail – eingeschränkt, aktiv, in Erholung
02Der Operator-Copilot
Ein Copilot-Dock öffnet sich neben jeder Ansicht mit kontextbezogenen Einstiegsfragen – warum Aufladungen fehlschlagen, offene Incidents zusammenfassen. Er ist schreibgeschützt und führt keine Aktionen aus. Und er fällt ehrlich aus: Solange der Modell-Endpoint nicht angebunden ist, sagt das Dock das klar, statt Antworten zu erfinden.
03Insights
Der Betrieb auf einem Screen: 42,180 Nutzer, 12,408 aktiv, eine Aktivierungsrate von 61.8 %, eine Erfolgsquote von 96.4 % und ein Geldfluss von +€1.84M Eingang und −€1.52M Ausgang in 30 Tagen. KYC- und Onboarding-Funnels stehen daneben, sodass ein Einbruch bei der Aktivierung in der Woche sichtbar wird, in der er beginnt. Geldkennzahlen bleiben der Finanzrolle vorbehalten.
04Fehler-Triage
Der Alert-Stream kommt dedupliziert an. 142 Vorkommen eines einzigen WebhookSignatureError – 38 Nutzer betroffen – werden zu einer kritischen Zeile mit den Aktionen „Bestätigen“ und „Lösen“ zusammengefasst, und die Ansicht aktualisiert sich alle 10 Sekunden. Operatoren lösen Signaturen, nicht Seiten voller Rauschen.
- Eine Zeile pro Fehlersignatur, gezählt
- Betroffene Nutzer an jeder Signatur
- Bestätigen und Lösen als auditierte Aktionen
05Nutzer, durchsuchbar nach allem
12,408 Konten, durchsuchbar nach Name, E-Mail, Telefonnummer oder ID, mit KYC- und Kontostatus in jeder Zeile und Tabs für ausstehende KYC, verifiziert, abgelehnt, gesperrt und archiviert. Jede Zeile öffnet eine User 360 – Salden, Karten, Geräte, KYC-Stufe und die vollständige Historie eines Kunden auf einem Screen.
06KYC-Prüfwarteschlange
Ausstehende Prüfungen kommen als gezählte Warteschlange mit sichtbarer Uhr – in der Demo 12, jede Zeile mit Anbieter, Status, letztem Grund und der bisherigen Wartezeit des Antragstellers. Ein hängender Liveness-Retry bei 5h 02m erscheint rot. Freigeben, ablehnen oder zurücksetzen direkt in der Console; jede Entscheidung erfordert eine Begründung, wird auditiert und ändert den Kontostatus überall gleichzeitig.
- Ausstehend, vorab abgeschlossen, abgelehnt und alle als Tabs
- Gründe in der Zeile – Adressprüfung, Liveness-Retry, Dokumentenprüfung
- Wartezeit sichtbar, die älteste markiert
07Ledger-Drilldown
Jede Geldzeile lässt sich bis auf den Grund öffnen. Transfer TR-90211 – eine abgeschlossene Peer-to-Peer-Zahlung über €120.00 – zeigt Sender, Empfänger und beide gebuchten Ledger-Seiten: eine Belastung von −€120.00 und eine Gutschrift von +€120.00, doppelte Buchführung und ausgeglichen. Keine Zusammenfassung steht zwischen Operator und Ledger.
08Krypto-Aufladungen
On-Chain-Einzahlungen sind vollwertige Zeilen, kein Export von anderswo. Eine erfolgreiche Aufladung im Base-Netzwerk zeigt 250.00 USDC, die dem EUR-Ledger gutgeschrieben werden, mit Wechselkurs, Gebühr, Wallet-Adresse und Transaktions-Hash in der Seitenleiste. Beide Rails, eine Console, bis zur Chain nachvollziehbar.
09Abgleich
Eingehende SEPA-Einzahlungen werden Nutzern automatisch zugeordnet; die Ausnahmen landen in einer gezählten Arbeitswarteschlange – zugeordnete Zeilen bereit zur Gutschrift, ein unbekannter Zahler mit zwei möglichen Treffern sowie Tabs für bereit, Prüfung nötig, nicht zugeordnet und Verlauf. Die Gutschrift ist ein Klick, wenn die Zuordnung sauber ist, und eine begründete Entscheidung, wenn nicht – und jede manuelle Gutschrift erfordert eine Begründung, mit Betragslimits aus der Konfiguration.
- Zahlung einem Nutzer zuordnen, dann gutschreiben und abstimmen
- Mehrdeutige Zahler samt Kandidaten zur Prüfung zurückgehalten
- Bankberichte direkt in die Warteschlange importiert
10Tracer
Referenz einfügen und die ganze Geschichte erhalten. Trace 9F21-0716 öffnet sich als Hop-Trace – Anfrage übermittelt, Ledger gegen Richtlinie validiert, Anbieter-Quote erfasst, On-Chain-Bestätigung auf Base bei 12 von 12, Settlement zugestellt – jeder Hop mit Zeitstempel, von +42ms bis +22s. Bewusst schreibgeschützt: Tracer erklärt, er verändert nie etwas.
- Eine Referenz, jeder Hop von der Anfrage bis zum Settlement
- Die je Hop angewandte Richtlinie und Quote, festgehalten
- Idempotency-Key im Trace sichtbar
11Freigabe-Posteingang
Gutschriften oberhalb der Grenze warten auf einen zweiten Operator. Der Posteingang trennt, was auf Ihre Freigabe wartet und was Sie selbst angefragt haben – auf der einen Seite eine Kulanzgutschrift über €500.00 und eine Erstattung für eine fehlgeschlagene Aufladung über €120.00, auf der anderen Ihre eigene Gebührenstornierung über €40.00, die auf einen Mitzeichner wartet. Eigene Anfragen können Sie nicht freigeben; Sie können sie zurückziehen.
12Das Audit-Log
18,942 Operator-Aktionen in einer Append-only-Tabelle: Zeit, Operator, Aktion, Ziel, die schriftliche Begründung und die zugrunde liegende Anfrage mit ihrem Antwortcode. Systemaktionen landen im selben Strang wie menschliche. Nach Operator, Aktion oder Datum filtern; als CSV exportieren, wenn jemand außerhalb der Console danach fragt.
- Append-only – Einträge werden nie bearbeitet oder entfernt
- Begründung und Anfrage an jeder Zeile
- Filterbar, paginiert, exportierbar
13Webhook-Prüfung und Replay
18,204 eingehende Anbieter-Ereignisse, jedes mit seiner Signaturprüfung in der Zeile. Ein fehlgeschlagenes Ereignis lässt sich per Replay erneut anwenden, um ein verpasstes Ergebnis nachzuholen – mit Begründungspflicht und ohne doppelte Benachrichtigungen –, aber nur bei gültiger Signatur; ungültigen Signaturen wird nicht vertraut, und der Replay wird blockiert. Das Einblenden eines rohen Payloads sendet unmaskierte PII an Ihren Browser und schreibt deshalb ein Audit-Ereignis.
14Feature-Flags und Remote-Konfiguration
38 typisierte Schlüssel in 8 Bereichen – Schalter, Beträge, Enums – für Karten, Aufladungen, KYC und den Rest der Laufzeitoberfläche. Jeder Schlüssel zeigt, wer ihn zuletzt wann geändert hat; jede Änderung wird per Diff dargestellt, begründet und auditiert. Ein Ausgabenlimit oder ein Anbieterwechsel ist eine Änderung in der Console, kein Store-Release.
- Typisierte Steuerelemente – keine Freitext-Konfigurationsstrings
- Historie pro Schlüssel: wer, was, wann, warum
- Änderungen wirken ohne App-Release
15Kill Switches
Wenn etwas stoppen muss, stoppt es von hier aus. Ein globaler Freeze zeigt beim App-Start den Wartungsscreen; Kill Switches pro Funktion schalten Karten, Aufladungen, Überweisungen oder KYC einzeln ab – in der Demo 4 aktiv, 0 deaktiviert. Ein OTP-Bypass für QA liegt hinter einem eigenen Schalter, standardmäßig aus. Jede Änderung wird protokolliert und doppelt bestätigt.
16Operatoren und Rollen
Das Team wird dort verwaltet, wo gearbeitet wird. Sechs Operator-Konten decken Rollen von Superadmin bis Auditor ab, jeder Datensatz zeigt die jüngste auditierte Aktivität. Rollenänderungen laufen über einen Begründungsdialog, und niemand kann die eigene Rolle ändern oder sich selbst deaktivieren – das muss ein zweiter Superadmin tun.
- Sechs Rollen – Superadmin, Ops, Compliance, Engineer, Support, Auditor
- Die jüngsten Aktionen jedes Operators im Datensatz
- Keine Selbstbeförderung, keine Selbstdeaktivierung
17Aktionen mit Begründungspflicht
Eine privilegierte Aktion erklärt sich, bevor sie läuft. Das Sperren von Karte 4417 öffnet einen Dialog, der die Auswirkungen benennt, eine schriftliche Begründung verlangt und – weil es sich um Produktion handelt – den Operator PROD eintippen lässt, bevor die Bestätigungsschaltfläche aktiv wird. Die Begründung landet im unveränderlichen Audit-Log neben der Aktion selbst.
18Circuit Breaker & Provider-Status
Das Engineering beobachtet Circuit Breaker und Provider-Status live. Wenn ein Provider nachlässt, ist der Breaker-Status in der Konsole sichtbar, bevor die Support-Tickets eintreffen — und ebenso die Erholung.
19Backoffice für Payment Links
Die Links, die Kunden erstellen, haben eine Operator-Ansicht: 214 Links in den Status bezahlt, aktiv und abgelaufen in der Demo, jeweils mit zugehöriger Settlement-Überweisung und einem Link „In Tracer öffnen“ für den vollständigen Trace. Einen Link zu widerrufen ist keine Rückerstattung — die Konsole weist Sie darauf hin, bevor Sie es tun.
20Login-Whitelists & maskierte PII
Der Zugriff auf die Konsole ist per Whitelist geregelt, und was Operatoren sehen, ist standardmäßig minimiert: E-Mail und Telefonnummer bleiben maskiert, bis sie gezielt eingeblendet werden, und Finanzkennzahlen liegen hinter der Finanzrolle. Mehr zu sehen ist eine bewusste, protokollierte Handlung.
21Manuelle Gutschriften und Funding
Einen Nutzer mit Guthaben auszustatten ist ein vollwertiger Konsolen-Ablauf, kein Datenbank-Write. Jede Gutschrift enthält eine schriftliche Begründung, und Gutschriften oberhalb des Schwellenwerts laufen über den Freigabe-Posteingang zur Bestätigung durch einen zweiten Operator.
22Kartenverwaltung
Karten über den gesamten Bestand: Sperren und Entsperren mit benanntem Wirkungsbereich, Kartenvarianten pro Programm verwaltet und jede Karte direkt aus dem zugehörigen User 360 erreichbar. Destruktive Aktionen erhalten denselben Dialog mit Begründungspflicht wie alles andere.
23Bankkonten
Die Bankkonten der Plattform haben eine eigene Ansicht, und importierte Bankberichte speisen direkt die Abstimmungswarteschlange. Der Zahlungsweg, über den das Geld tatsächlich fließt, ist in derselben Konsole sichtbar wie das Ledger, in dem es ankommt.
24Befehlspalette und Suche
Mit ⌘K öffnen Sie die Palette von überall; die Suche nimmt Name, E-Mail, Telefonnummer oder ID entgegen und führt zum richtigen Datensatz. Die Konsole ist dafür gebaut, an einem schlechten Tag allein per Tastatur bedient zu werden.
25Kampagnen, Empfehlungen und Einladungscodes
Die Wachstumsfunktionen leben in derselben Konsole: Kampagnen konfiguriert und verfolgt, Empfehlungsprogramme überwacht, Einladungscodes ausgegeben und widerrufen. Das Ops-Team steuert Promotions ohne zweites Admin-Tool.
26App-Versionen und mobile Tabs
Sehen Sie, welche App-Versionen im Einsatz sind, und konfigurieren Sie das Tab-Layout der mobilen App aus der Ferne. Die App-Hülle lässt sich aus der Konsole steuern — eine Tab-Änderung ist Konfiguration, kein Release.
27Content, FAQ und Chat
In-App-Inhalte, FAQ-Einträge und der Kundenchat werden direkt in der Konsole betrieben. Wer einen Support-Thread beantwortet, hat das User 360 einen Klick entfernt — nicht in einem anderen Tab eines anderen Systems.
28Krypto-Operationen
Der Kryptobereich hat einen eigenen Abschnitt: Krypto-Übersicht, Wallets, Asset-Register und Krypto-Aktionen — neben der Top-up-Warteschlange. Operatoren sehen die On-Chain-Seite mit derselben Tiefe wie das Fiat-Ledger.
29Exporte
Die Daten verlassen das System sauber, wenn es nötig ist: CSV-Export für das Audit-Log und operative Tabellen, genau so gefiltert wie angezeigt. Was ein Prüfer anfordert, ist ein Download, kein Engineering-Ticket.
30Whitelabel und Umgebungen
Die Konsole läuft unter Ihrer Marke — das Demo-Deployment heißt YourBrand, nicht wie wir. Ein dauerhaftes Banner nennt die Umgebung, Produktionsansichten tragen ein Prod-Badge, und Produktionsaktionen verlangen die Eingabe von PROD. Niemand verwechselt, in welchem Deployment er sich befindet.
