01Hela driftsättningen på en skärm
Översikten inleder dagen. Systemhälsa för underhåll, API-bryggan, databasen och cachen. Signaler för breakers, leverantörer och olösta fel. Arbetet som räknade köer – 12 KYC-granskningar väntar där den äldsta är 5h 02m, 8 avstämningsavvikelser med €18,240 redo att krediteras, 2 godkännanden i väntan. Senaste privilegierade åtgärder och hälsa per leverantör finns längre ned. Inget på den här skärmen kräver ett annat verktyg.
- System, signaler och köer i en lodrät läsning
- Varje kort länkar till kön det räknar
- Leverantörshälsa per rail – försämrad, uppe, återhämtar sig
02Operatörs-copiloten
En copilot-dock öppnas bredvid valfri vy med kontextmedvetna startfrågor – varför misslyckas påfyllningar, sammanfatta öppna incidenter. Den är skrivskyddad och utför inga åtgärder. Och den fallerar ärligt: tills modellens endpoint är kopplad säger docken det rakt ut i stället för att hitta på svar.
03Insikter
Verksamheten på en skärm: 42,180 användare, 12,408 aktiva, en aktiveringsgrad på 61.8%, en lyckandegrad på 96.4% och ett pengaflöde på +€1.84M in och −€1.52M ut över 30 dagar. KYC- och onboardingtrattar finns bredvid, så att en nedgång i aktivering syns samma vecka den börjar. Pengamåtten ligger bakom finansrollen.
04Felsortering
Larmflödet kommer deduplicerat. 142 förekomster av samma WebhookSignatureError – som påverkar 38 användare – slås ihop till en enda kritisk rad med åtgärderna kvittera och lös, och vyn uppdateras var 10:e sekund. Operatörer löser signaturer, inte sidor av brus.
- En rad per felsignatur, räknad
- Påverkade användare kopplade till varje signatur
- Kvittera och lös som reviderbara åtgärder
05Användare, sökbara på vad som helst
12,408 konton som går att söka på namn, e-post, telefon eller ID, med KYC- och kontostatus på varje rad och flikar för väntande KYC, verifierade, avvisade, blockerade och arkiverade. Varje rad öppnas i en User 360 – saldon, kort, enheter, KYC-nivå och fullständig historik för en kund på en enda skärm.
06KYC-granskningskö
Väntande granskningar kommer som en räknad kö med klockan synlig – 12 i demon, där varje rad visar leverantör, status, senaste orsak och hur länge den sökande har väntat. Ett liveness-omförsök som fastnat på 5h 02m visas i rött. Godkänn, avslå eller återställ i konsolen; varje beslut kräver en motivering, loggas och ändrar kontots status överallt på en gång.
- Väntande, förberedda, avslagna och alla som flikar
- Orsaker på raden – adressgranskning, liveness-omförsök, dokumentgranskning
- Väntetid synlig, den äldsta flaggad
07Drill-down i huvudboken
Varje pengarad öppnas hela vägen ned. Överföring TR-90211 – en genomförd peer-to-peer-betalning på €120.00 – visar avsändare, mottagare och båda bokförda huvudboksposter: en debitering på −€120.00 och en kreditering på +€120.00, dubbel bokföring och i balans. Ingen sammanfattningsvy står mellan en operatör och huvudboken.
08Krypto-påfyllningar
Insättningar on-chain är förstklassiga rader, inte en export från någon annanstans. En lyckad påfyllning på Base-nätverket visar 250.00 USDC som krediterar EUR-huvudboken, med växelkurs, avgift, plånboksadress och transaktionshash i panelen. Båda rails, en konsol, spårbart ända ned till kedjan.
09Avstämning
Inkommande SEPA-insättningar matchas mot användare automatiskt; undantagen hamnar i en räknad arbetskö – matchade rader redo att krediteras, en okänd betalare med två möjliga matchningar, och flikar för redo, kräver granskning, omatchade och historik. Kreditering är ett klick när matchningen är ren och ett motiverat beslut när den inte är det – och varje manuell kreditering kräver en motivering, med beloppsgränser hämtade från konfigurationen.
- Matcha en betalning mot en användare, kreditera och stäm av
- Tvetydiga betalare hålls för granskning tillsammans med sina kandidater
- Bankrapporter importeras direkt till kön
10Tracer
Klistra in en referens och få hela historien. Trace 9F21-0716 öppnas som ett stegspår – begäran skickad, huvudbok validerad mot policy, leverantörsoffert registrerad, on-chain-bekräftelse på Base vid 12 av 12, avräkning levererad – varje steg tidsatt, från +42ms till +22s. Skrivskyddat med avsikt: Tracer förklarar, den ändrar aldrig något.
- En referens, varje steg från begäran till avräkning
- Policyn och offerten som varje steg tillämpade, registrerade
- Idempotensnyckel synlig i spåret
11Godkännandeinkorg
Krediteringar över gränsen väntar på en andra operatör. Inkorgen delas upp i det som väntar på ditt godkännande och det du har begärt – en goodwill-kreditering på €500.00 och en återbetalning av en misslyckad påfyllning på €120.00 på ena sidan, din egen avgiftsåterföring på €40.00 som väntar på en medsignerare på den andra. Du kan inte godkänna poster du själv begärt; du kan dra tillbaka dem.
12Auditloggen
18,942 operatörsåtgärder i en append-only-tabell: tid, operatör, åtgärd, mål, den skriftliga motiveringen och den underliggande begäran med svarskod. Systemåtgärder hamnar i samma ryggrad som mänskliga. Filtrera på operatör, åtgärd eller datum; exportera till CSV när någon utanför konsolen frågar.
- Append-only – poster redigeras eller tas aldrig bort
- Motivering och begäran kopplade till varje rad
- Filtrerbar, paginerad, exporterbar
13Webhook-inspektion och replay
18,204 inkommande leverantörshändelser, var och en med sin signaturverifiering på raden. En misslyckad händelse kan spelas upp igen för att tillämpa ett missat utfall – motivering krävs, inga dubbla aviseringar – men bara om dess signatur är giltig; ogiltiga signaturer är inte betrodda och replay blockeras. Att visa en rå payload skickar omaskerade personuppgifter till din webbläsare, så det skapar en auditpost.
14Feature flags och remote config
38 typade nycklar i 8 områden – växlar, belopp, enum-värden – för kort, påfyllningar, KYC och resten av körtidsytan. Varje nyckel visar vem som ändrade den senast och när; varje ändring jämförs, motiveras och loggas. En utgiftsgräns eller ett leverantörsbyte är en ändring i konsolen, inte en release i appbutiken.
- Typade kontroller – inga fritextsträngar i konfigurationen
- Historik per nyckel: vem, vad, när, varför
- Ändringar gäller utan apprelease
15Kill switches
När något måste stoppas stoppas det härifrån. En global frysning visar underhållsskärmen vid appstart; kill switches per funktion stänger av kort, påfyllningar, överföringar eller KYC var för sig – 4 aktiva, 0 inaktiverade i demon. En OTP-bypass för QA ligger bakom sin egen brytare, avstängd som standard. Varje ändring loggas och dubbelbekräftas.
16Operatörer och roller
Teamet hanteras där arbetet sker. Sex operatörskonton har roller från superadmin till auditor, och varje post visar den senaste granskade aktiviteten. Rolländringar går via en motiveringsdialog, och ingen kan ändra sin egen roll eller inaktivera sig själv – det måste en andra superadmin göra.
- Sex roller – superadmin, ops, compliance, engineer, support, auditor
- Varje operatörs senaste åtgärder på dess post
- Ingen självbefordran, ingen självinaktivering
17Åtgärder som kräver motivering
En privilegierad åtgärd förklarar sig själv innan den körs. När kort 4417 fryses öppnas en dialog som anger vad som påverkas, kräver en skriftlig motivering och – eftersom det är produktion – får operatören att skriva PROD innan bekräftaknappen aktiveras. Motiveringen hamnar i den oföränderliga auditloggen intill själva åtgärden.
18Brytare och leverantörshälsa
Ingenjörssidan följer brytare och leverantörshälsa i realtid. När en leverantör försämras syns brytarens status i konsolen innan supportärendena kommer in — och det gör återhämtningen också.
19Back office för betallänkar
Länkarna som kunderna skapar har en operatörsvy: i demon 214 länkar fördelade på betalda, aktiva och utgångna, var och en med sin avvecklingsöverföring kopplad och en länk för att öppna den i Tracer för hela spårningen. Att återkalla en länk är inte en återbetalning — det säger konsolen innan du gör det.
20Vitlistade inloggningar och maskad PII
Åtkomsten till konsolen är vitlistad, och det operatörerna ser minimeras som standard: e-post och telefon förblir maskerade tills någon medvetet visar dem, och penningmått ligger bakom den finansiella rollen. Att se mer är en medveten, loggad handling.
21Manuella krediteringar och påfyllning
Att fylla på en användares konto är ett fullvärdigt flöde i konsolen, inte en skrivning i databasen. Varje kreditering har en skriftlig orsak, och krediteringar över tröskelvärdet går via godkännandeinkorgen för en andra operatörs godkännande.
22Kortadministration
Kort i hela basen: frys och tina upp med påverkansområdet angivet, hantera kortvarianter per program, och nå varje kort från den User 360 det tillhör. Destruktiva åtgärder får samma dialogruta med orsakskrav som allt annat.
23Bankkonton
Plattformens bankkonton har en egen vy, och importerade bankrapporter matar avstämningskön direkt. Rälsen som pengarna faktiskt rör sig på syns i samma konsol som huvudboken de landar i.
24Kommandopalett och sök
⌘K öppnar paletten varifrån som helst; sök på namn, e-post, telefon eller ID och landa på rätt post. Konsolen är byggd för att styras med tangentbordet en dålig dag.
25Kampanjer, värvning och inbjudningskoder
Tillväxtytorna finns i samma konsol: kampanjer som konfigureras och följs upp, värvningsprogram under övervakning, inbjudningskoder som utfärdas och återkallas. Ops driver erbjudanden utan ett separat adminverktyg.
26Appversioner och mobilflikar
Se vilka appversioner som är i drift och konfigurera mobilappens flikar på distans. Appens skal styrs från konsolen — en flikändring är konfiguration, inte en release.
27Innehåll, FAQ och chatt
Innehåll i appen, FAQ-poster och kundchatten hanteras i konsolen. Den som svarar i en supporttråd har User 360 ett klick bort, inte i en annan flik i ett annat system.
28Kryptoadministration
Kryptodelen har en egen sektion: en kryptoöversikt, wallets, ett tillgångsregister och kryptoåtgärder — vid sidan av kön för påfyllningar. Operatörer ser on-chain-ytan lika djupt som fiatboken.
29Exporter
Datan lämnar systemet rent när den behöver det: CSV-export från granskningsloggen och operativa tabeller, filtrerad exakt som den visas. Det en revisor ber om är en nedladdning, inte ett utvecklingsärende.
30Whitelabel och miljöer
Konsolen körs under ditt varumärke — demon heter YourBrand, inte vårt namn. En ständig banner anger miljön, produktionsvyer har en prod-badge och produktionsåtgärder kräver att operatören skriver PROD. Ingen förväxlar vilken miljö de befinner sig i.
