01A implementação num só ecrã
A visão geral abre o dia. Estado do sistema em manutenção, ponte de API, base de dados e cache. Sinais de breakers, fornecedores e erros por resolver. O trabalho em filas contadas — 12 revisões KYC pendentes com a mais antiga a 5h 02m, 8 divergências de reconciliação com €18,240 prontos a creditar, 2 aprovações em espera. Em baixo, as ações privilegiadas recentes e o estado de cada fornecedor. Nada neste ecrã exige uma segunda ferramenta.
- Sistema, sinais e filas numa só leitura vertical
- Cada cartão liga à fila que conta
- Estado dos fornecedores por rail — degradado, ativo, a recuperar
02O copiloto do operador
Um dock de copiloto abre ao lado de qualquer vista com sugestões contextuais — porque falham os carregamentos, resumir incidentes abertos. É só de leitura e não executa ações. E falha com honestidade: enquanto o endpoint do modelo não estiver ligado, o dock di-lo claramente em vez de inventar respostas.
03Insights
A operação num só ecrã: 42,180 utilizadores, 12,408 ativos, taxa de ativação de 61.8%, taxa de sucesso de 96.4% e fluxo de dinheiro de +€1.84M de entrada e −€1.52M de saída em 30 dias. Os funis de KYC e onboarding ficam ao lado, para que uma quebra na ativação seja visível na semana em que começa. As métricas de dinheiro ficam atrás do perfil financeiro.
04Triagem de erros
O fluxo de alertas chega deduplicado. 142 ocorrências de um mesmo WebhookSignatureError — a afetar 38 utilizadores — reduzem-se a uma única linha crítica com ações de reconhecer e resolver, e a vista atualiza a cada 10 segundos. Os operadores resolvem assinaturas, não páginas de ruído.
- Uma linha por assinatura de erro, contabilizada
- Utilizadores afetados associados a cada assinatura
- Reconhecer e resolver como ações auditadas
05Utilizadores, pesquisáveis por qualquer campo
12,408 contas pesquisáveis por nome, email, telefone ou ID, com KYC e estado da conta em cada linha e separadores para KYC pendente, verificado, rejeitado, bloqueado e arquivado. Cada linha abre um User 360 — saldos, cartões, dispositivos, nível de KYC e histórico completo de um cliente num só ecrã.
06Fila de revisão KYC
As revisões pendentes chegam como uma fila contada com o relógio visível — 12 na demo, cada linha com o fornecedor, o estado, o motivo mais recente e há quanto tempo o requerente espera. Uma nova tentativa de liveness parada há 5h 02m aparece a vermelho. Aprove, rejeite ou reponha na consola; cada decisão exige motivo, é auditada e altera o estado da conta em todo o lado de uma só vez.
- Pendentes, pré-concluídos, rejeitados e todos, em separadores
- Motivos na linha — revisão de morada, nova tentativa de liveness, revisão de documento
- Tempo de espera visível, o mais antigo assinalado
07Drill-down do ledger
Cada linha de dinheiro abre até ao fundo. A transferência TR-90211 — um pagamento peer-to-peer concluído de €120.00 — mostra remetente, destinatário e as duas pernas do ledger lançadas: um débito de −€120.00 e um crédito de +€120.00, em partida dobrada e equilibrado. Nenhuma vista-resumo se interpõe entre o operador e o ledger.
08Carregamentos em cripto
Os depósitos on-chain são linhas de pleno direito, não uma exportação vinda de outro lado. Um carregamento concluído na rede Base mostra 250.00 USDC a creditar o ledger em EUR, com a taxa de câmbio, a comissão, o endereço da carteira e o hash da transação na gaveta. Os dois rails, uma consola, rastreável até à chain.
09Reconciliação
Os depósitos SEPA recebidos são associados automaticamente aos utilizadores; as exceções caem numa fila de trabalho contada — linhas associadas prontas a creditar, um ordenante desconhecido com dois candidatos e separadores para prontos, a rever, não associados e histórico. Creditar é um clique quando a correspondência é limpa e uma decisão fundamentada quando não é — e todo o crédito manual exige motivo, com limites de montante lidos da configuração.
- Associar um pagamento a um utilizador, depois creditar e reconciliar
- Ordenantes ambíguos retidos para revisão, com os seus candidatos
- Relatórios bancários importados diretamente para a fila
10Tracer
Cole uma referência e obtenha a história completa. O trace 9F21-0716 abre como um trace de hops — pedido submetido, ledger validado face à política, cotação do fornecedor registada, confirmação on-chain na Base a 12 de 12, liquidação entregue — cada hop cronometrado, de +42ms a +22s. Só de leitura por desenho: o Tracer explica, nunca altera.
- Uma referência, todos os hops do pedido à liquidação
- A política e a cotação aplicadas em cada hop, registadas
- Chave de idempotência visível no trace
11Caixa de aprovações
Os créditos acima do limite aguardam um segundo operador. A caixa divide-se entre o que aguarda a sua aprovação e o que pediu — um crédito de cortesia de €500.00 e um reembolso de carregamento falhado de €120.00 de um lado, o seu próprio estorno de comissão de €40.00 à espera de um cossignatário do outro. Não pode aprovar itens que pediu; pode retirá-los.
12O registo de auditoria
18,942 ações de operadores numa tabela append-only: hora, operador, ação, alvo, o motivo escrito e o pedido subjacente com o seu código de resposta. As ações do sistema entram na mesma linha que as humanas. Filtre por operador, ação ou data; exporte para CSV quando alguém de fora da consola pedir.
- Append-only — as entradas nunca são editadas nem removidas
- Motivo e pedido associados a cada linha
- Filtrável, paginado, exportável
13Inspeção e replay de webhooks
18,204 eventos de fornecedores recebidos, cada um com a verificação de assinatura na linha. Um evento falhado pode ser reproduzido para reaplicar um resultado perdido — exige motivo, sem notificações duplicadas — mas só se a assinatura for válida; assinaturas inválidas não são de confiança e o replay fica bloqueado. Revelar um payload bruto envia PII sem máscara para o seu navegador, por isso fazê-lo gera um evento de auditoria.
14Feature flags e configuração remota
38 chaves tipadas em 8 áreas — interruptores, montantes, enums — para cartões, carregamentos, KYC e o resto da superfície de runtime. Cada chave mostra quem a alterou por último e quando; cada alteração tem diff, motivo e auditoria. Um limite de gastos ou a troca de um fornecedor é uma edição na consola, não uma release na store.
- Controlos tipados — sem strings de configuração em texto livre
- Histórico por chave: quem, o quê, quando, porquê
- As alterações têm efeito sem release da app
15Kill switches
Quando algo tem de parar, pára aqui. Um congelamento global coloca o ecrã de manutenção no arranque da app; os kill switches por funcionalidade cortam cartões, carregamentos, transferências ou KYC individualmente — 4 ativos, 0 desativados na demo. Um bypass de OTP para QA fica atrás do seu próprio interruptor, desligado por defeito. Cada alteração é registada e com dupla confirmação.
16Operadores e funções
A equipa gere-se onde o trabalho acontece. Seis contas de operador cobrem funções de superadmin a auditor, e cada registo mostra a sua atividade auditada recente. As alterações de função passam por um diálogo de motivo, e ninguém pode alterar a própria função nem desativar-se a si mesmo — tem de ser um segundo superadmin.
- Seis funções — superadmin, ops, compliance, engineer, support, auditor
- As ações recentes de cada operador no seu registo
- Sem autopromoção, sem autodesativação
Uma ação privilegiada explica-se antes de correr. Congelar o cartão 4417 abre um diálogo que indica o raio de impacto, exige um motivo escrito e — por ser produção — obriga o operador a escrever PROD antes de o botão de confirmar ficar ativo. O motivo fica no registo de auditoria imutável, junto à própria ação.
18Circuit breakers e estado dos providers
A equipa de engenharia acompanha em direto os circuit breakers e o estado dos providers. Quando um provider se degrada, o estado do breaker aparece na consola antes de chegarem os tickets de suporte — e a recuperação também.
19Back office de payment links
Os links criados pelos clientes têm uma vista de operador: 214 links entre pagos, ativos e expirados na demo, cada um com a transferência de liquidação associada e uma ligação para abrir no Tracer com o trace completo. Revogar um link não é um reembolso — a consola avisa-o antes de avançar.
20Whitelists de acesso e PII mascarada
O acesso à consola é feito por whitelist e o que os operadores veem é minimizado por defeito: email e telefone ficam mascarados até serem revelados de propósito, e as métricas financeiras ficam atrás do perfil financeiro. Ver mais é um ato deliberado e registado.
21Créditos manuais e carregamentos
Carregar o saldo de um utilizador é um fluxo de primeira classe na consola, não uma escrita na base de dados. Cada crédito leva um motivo por escrito, e os créditos acima do limite passam pela caixa de aprovações para validação de um segundo operador.
22Operações de cartões
Cartões de toda a base: congelar e descongelar com o raio de impacto indicado, variantes de cartão geridas por programa e cada cartão acessível a partir do User 360 a que pertence. As ações destrutivas têm a mesma caixa de diálogo com motivo obrigatório que todas as outras.
23Contas bancárias
As contas bancárias da plataforma têm vista própria, e os extratos bancários importados alimentam diretamente a fila de reconciliação. O canal por onde o dinheiro realmente circula está na mesma consola que o ledger onde ele chega.
24Paleta de comandos e pesquisa
⌘K abre a paleta de qualquer ecrã; a pesquisa aceita nome, email, telefone ou ID e leva ao registo certo. A consola foi feita para ser usada só com o teclado num dia mau.
25Campanhas, referrals e códigos de convite
As ferramentas de growth vivem na mesma consola: campanhas configuradas e acompanhadas, programas de referral monitorizados, códigos de convite emitidos e revogados. A equipa de operações gere promoções sem uma segunda ferramenta de administração.
26Versões da app e separadores mobile
Veja que versões da app estão em utilização e configure remotamente a disposição dos separadores da app mobile. A estrutura da app é operável a partir da consola — mudar um separador é configuração, não uma release.
27Conteúdo, FAQ e chat
O conteúdo da app, as entradas de FAQ e o chat com clientes são geridos na consola. Quem responde a um pedido de suporte tem o User 360 a um clique, e não noutro separador de outro sistema.
28Operações crypto
A vertente crypto tem secção própria: visão geral, wallets, registo de ativos e ações crypto — ao lado da fila de carregamentos. Os operadores veem a superfície on-chain com a mesma profundidade do ledger fiat.
29Exportações
Os dados saem limpos quando é preciso: exportação CSV do registo de auditoria e das tabelas operacionais, filtrada exatamente como está no ecrã. O que um auditor pede é um download, não um ticket para a engenharia.
30Whitelabel e ambientes
A consola funciona sob a sua marca — a instalação de demonstração é YourBrand, não a nossa. Um banner permanente indica o ambiente, as vistas de produção têm um selo prod e as ações em produção obrigam o operador a escrever PROD. Ninguém confunde o ambiente em que está.
