Contact us
/// Center · Operations Console

Run the whole operation from one screen.

An operation is queues, money on two rails, and a team with different clearances. Center puts all of it on one surface — and makes every privileged action explain itself in writing before it runs.

Contact usAll products
360°
Customer view
Audited
Reason-required actions
6 roles
Superadmin →︎ auditor
Live
Breakers · providers · queues
/// 01

Operators see problems before customers do

The day starts on the overview: system health, breakers, providers, and the work arriving as queues with the clock visible — KYC reviews pending, reconciliation breaks open, approvals waiting. Error triage dedupes the alert stream — 142 occurrences of one signature become a single row to acknowledge and resolve — so noise never buries the real incident.

  • [ 01 ]KYC review, reconciliation breaks, and approvals as counted queues
  • [ 02 ]Breakers and provider health on the engineering side
  • [ 03 ]Error triage that correlates the stream — resolve once, not 142 times
/// 02

Discipline by default

Every privileged action — a freeze, a credit, a retire — opens a dialog that states its blast radius and demands a written reason, and the reason lands in an immutable audit log. Production actions make the operator type PROD before the button enables. Email and phone stay masked until revealed on purpose, and money metrics sit behind a financial role.

  • [ 01 ]Reason-required dialogs on every privileged action
  • [ 02 ]Immutable audit log — who did what, and why, in writing
  • [ 03 ]Masked PII with reveal-on-purpose; money metrics gated by role
  • [ 04 ]Credits above the threshold wait for a second operator's approval
/// 03

From a queue to a customer in one click

The users list is the entry point; User 360 is the destination: balance, lifetime flow, cards, devices, KYC tier, and 184 transactions for one customer on a single screen. Every money row drills down — a €120.00 transfer opens to show both ledger legs posted, double-entry and balanced, with sender and receiver one click away.

/// 04

The team is managed in the same place

Operators, invites, and roles live in the console itself — superadmin, ops, compliance, engineer, support, auditor — with each operator's recent actions on their record. Role changes route through a reason dialog, and nobody can change their own role or deactivate themselves; a second superadmin must.

/// Features
The day at a glance — system, signals, queues, and who did what.
/// 01

The deployment on one screen

The overview opens the day. System health across maintenance, the API bridge, database, and cache. Signals for breakers, providers, and unresolved errors. The work as counted queues — 12 KYC reviews pending with the oldest at 5h 02m, 8 reconciliation breaks with €18,240 ready to credit, 2 approvals waiting. Recent privileged actions and per-provider health sit below. Nothing on this screen requires a second tool.

  • [ 01 ]System, signals, and queues in one vertical read
  • [ 02 ]Every card links to the queue it counts
  • [ 03 ]Provider health per rail — degraded, up, recovering
The copilot dock — context on tap, read-only, honest about its limits.
/// 02

The operator copilot

A copilot dock opens beside any view with context-aware starters — why are top-ups failing, summarize open incidents. It is read-only and will not execute actions. And it degrades honestly: until the model endpoint is wired, the dock says so plainly instead of fabricating answers.

Thirty days at a glance — 42,180 users, €1.84M in, funnels and flow on one screen.
/// 03

Insights

The operation on one screen: 42,180 users, 12,408 active, a 61.8% activation rate, a 96.4% success rate, and money flow of +€1.84M in and −€1.52M out over 30 days. KYC and onboarding funnels sit alongside, so a drop in activation is visible the week it starts. Money metrics stay behind the financial role.

×142 of one signature, one row — acknowledge, resolve, move on.
/// 04

Error triage

The alert stream arrives deduplicated. 142 occurrences of one WebhookSignatureError — affecting 38 users — collapse into a single critical row with acknowledge and resolve actions, and the view refreshes every 10 seconds. Operators resolve signatures, not pages of noise.

  • [ 01 ]One row per error signature, counted
  • [ 02 ]Affected users attached to each signature
  • [ 03 ]Acknowledge and resolve as audited actions
12,408 accounts — search by anything, land on a User 360.
/// 05

Users, searchable by anything

12,408 accounts searchable by name, email, phone, or ID, with KYC and account status on every row and tabs for pending KYC, verified, rejected, blocked, and archived. Every row opens into a User 360 — balances, cards, devices, KYC tier, and full history for one customer on a single screen.

The KYC queue — 12 pending, reasons on the row, the clock always visible.
/// 06

KYC review queue

Pending reviews arrive as a counted queue with the clock visible — 12 in the demo, each row carrying the provider, the status, the latest reason, and how long the applicant has waited. A liveness retry stuck at 5h 02m shows in red. Approve, reject, or reset in-console; every decision is reason-required, audited, and moves the account's status everywhere at once.

  • [ 01 ]Pending, precompleted, rejected, and all as tabs
  • [ 02 ]Reasons on the row — address review, liveness retry, doc review
  • [ 03 ]Waiting time visible, the oldest flagged
TR-90211 opened — both legs posted, double-entry and balanced.
/// 07

Ledger drill-down

Every money row opens all the way down. Transfer TR-90211 — a completed €120.00 peer-to-peer payment — shows sender, receiver, and both ledger legs posted: a −€120.00 debit and a +€120.00 credit, double-entry and balanced. No summary view stands between an operator and the ledger.

250.00 USDC in, euros credited — rate, fee, and tx hash in the drawer.
/// 08

Crypto top-ups

On-chain deposits are first-class rows, not an export from somewhere else. A succeeded Base-network top-up shows 250.00 USDC crediting the EUR ledger, with the exchange rate, the fee, the wallet address, and the transaction hash in the drawer. Both rails, one console, traceable down to the chain.

SEPA deposits matched to users — clean rows credit in one click, odd ones wait.
/// 09

Reconciliation

Incoming SEPA deposits match to users automatically; the exceptions land in a counted work queue — matched rows ready to credit, an unknown payer holding two candidate matches, and tabs for ready, needs review, unmatched, and history. Crediting is one click when the match is clean and a reasoned decision when it is not — and every manual credit is reason-required, with amount limits read from config.

  • [ 01 ]Match a payment to a user, then credit and reconcile
  • [ 02 ]Ambiguous payers held for review with their candidates
  • [ 03 ]Bank reports imported straight into the queue
9F21-0716 traced — five hops, each timed, read-only end to end.
/// 10

Tracer

Paste a reference and get the whole story. Trace 9F21-0716 opens as a hop trace — request submitted, ledger validated against policy, provider quote recorded, on-chain confirmation on Base at 12 of 12, settlement delivered — each hop timed, from +42ms to +22s. Read-only by design: Tracer explains, it never mutates.

  • [ 01 ]One reference, every hop from request to settlement
  • [ 02 ]The policy and quote each hop applied, recorded
  • [ 03 ]Idempotency key visible on the trace
Two-person co-sign — your requests and their approvals, never the same person.
/// 11

Approvals inbox

Credits above the line wait for a second operator. The inbox splits into what awaits your approval and what you have requested — a €500.00 goodwill credit and a €120.00 failed top-up refund on one side, your own €40.00 fee reversal awaiting a co-signer on the other. You cannot approve items you requested; you can withdraw them.

18,942 actions — actor, reason, and request on every row, append-only.
/// 12

The audit log

18,942 operator actions in an append-only table: time, operator, action, target, the written reason, and the underlying request with its response code. System actions land in the same spine as human ones. Filter by operator, action, or date; export to CSV when someone outside the console asks.

  • [ 01 ]Append-only — entries are never edited or removed
  • [ 02 ]Reason and request attached to every row
  • [ 03 ]Filterable, paginated, exportable
Inspect and replay — signatures checked, payload reveals audited.
/// 13

Webhook inspection and replay

18,204 inbound provider events, each with its signature verification on the row. A failed event can be replayed to re-apply a missed verdict — reason-required, no duplicate notifications — but only if its signature is valid; invalid signatures are not trusted and replay is blocked. Revealing a raw payload sends unmasked PII to your browser, so doing it writes an audit event.

38 typed keys — runtime config edited in-console, no release required.
/// 14

Feature flags and remote config

38 typed keys across 8 areas — toggles, amounts, enums — for cards, top-ups, KYC, and the rest of the runtime surface. Each key shows who changed it last and when; each change is diffed, reasoned, and audited. A spend limit or a provider switch is an edit in the console, not a store release.

  • [ 01 ]Typed controls — no free-text config strings
  • [ 02 ]Per-key history: who, what, when, why
  • [ 03 ]Changes take effect without an app release
Global freeze and four per-feature switches — logged, double-confirmed.
/// 15

Kill switches

When something must stop, it stops from here. A global freeze puts the maintenance screen on app launch; per-feature kill switches cut cards, top-ups, transfers, or KYC individually — 4 live, 0 disabled in the demo. An OTP bypass for QA sits behind its own switch, off by default. Every change is logged and double-confirmed.

Six operators, superadmin to auditor — no one edits their own clearance.
/// 16

Operators and roles

The team is managed where the work happens. Six operator accounts run roles from superadmin to auditor, each record showing its recent audited activity. Role changes go through a reason dialog, and nobody can change their own role or deactivate themselves — a second superadmin must.

  • [ 01 ]Six roles — superadmin, ops, compliance, engineer, support, auditor
  • [ 02 ]Each operator's recent actions on their record
  • [ 03 ]No self-promotion, no self-deactivation
Blast radius stated, reason required, PROD typed — then the button enables.
/// 17

Reason-required actions

A privileged action explains itself before it runs. Freezing card 4417 opens a dialog that states the blast radius, demands a written reason, and — because this is production — makes the operator type PROD before the confirm button enables. The reason lands in the immutable audit log next to the action itself.

/// And more

Breakers & provider health

The engineering side watches breakers and provider health live. When a provider degrades, the breaker state is visible in the console before the support tickets arrive — and so is the recovery.

Payment-links back office

The links customers create have an operator view: 214 links across paid, active, and expired in the demo, each with its settlement transfer attached and an open-in-Tracer link for the full trace. Revoking a link is not a refund — the console says so before you do it.

Sign-in whitelists & masked PII

Console access is whitelisted, and what operators see is minimized by default: email and phone stay masked until revealed on purpose, and money metrics sit behind the financial role. Seeing more is a deliberate, logged act.

Manual credits and funding

Funding a user is a first-class console flow, not a database write. Every credit carries a written reason, and credits above the threshold route through the approvals inbox for a second operator's sign-off.

Card operations

Cards across the whole base: freeze and unfreeze with the blast radius stated, card variants managed per program, and every card reachable from the User 360 it belongs to. Destructive actions get the same reason-required dialog as everything else.

Bank accounts

The platform's bank accounts have their own view, and imported bank reports feed the reconciliation queue directly. The rail the money actually moves on is visible in the same console as the ledger it lands in.

Command palette and search

⌘K opens the palette from anywhere; search takes a name, email, phone, or ID and lands on the right record. The console is built to be driven from the keyboard on a bad day.

Campaigns, referrals, and invite codes

The growth surfaces live in the same console: campaigns configured and tracked, referral programs monitored, invite codes issued and revoked. Ops runs promotions without a second admin tool.

App versions and mobile tabs

See which app versions are in the field, and configure the mobile app's tab layout remotely. The app shell is operable from the console — a tab change is config, not a release.

Content, FAQ, and chat

In-app content, FAQ entries, and the customer chat are operated in-console. The person answering a support thread has the User 360 one click away, not in another tab of another system.

Crypto operations

The crypto side has its own section: a crypto overview, wallets, an asset registry, and crypto actions — alongside the top-ups queue. Operators see the on-chain surface with the same depth as the fiat ledger.

Exports

The data leaves cleanly when it needs to: CSV export on the audit log and operational tables, filtered exactly as displayed. What an auditor asks for is a download, not an engineering ticket.

Whitelabel and environments

The console runs under your brand — the demo deployment is YourBrand, not ours. A persistent banner states the environment, production views carry a prod badge, and production actions make the operator type PROD. Nobody mistakes which deployment they are in.

/// In the product
/// The day at a glance
  • The overview — system, signals, and queues, the whole deployment on one screen.
  • The copilot dock — context-aware starters, read-only, honest when it isn't wired.
  • Insights — 42,180 users, €1.84M in over 30 days, money metrics behind the financial role.
  • Error triage — ×142 of one signature becomes a single row to acknowledge and resolve.
/// Money and customers
  • Users — 12,408 accounts, searchable by anything, the door to every User 360.
  • The KYC queue — 12 pending, reasons and waiting times visible, every decision audited.
  • A transfer opened — both ledger legs posted, double-entry and balanced.
  • Crypto top-ups — on-chain deposits credited to fiat, traceable down to the tx hash.
  • Reconciliation — SEPA deposits matched to users, every credit reason-required.
  • Tracer — one reference, every hop from request to settlement, timed.
/// Governance and control
  • Approvals — two-person co-sign on credits, and you can't approve your own.
  • The audit log — 18,942 actions with actor, reason, and request, append-only.
  • Webhooks — inspect and replay events, invalid signatures blocked from replay.
  • Feature flags — typed runtime config, every change diffed, reasoned, and audited.
  • Kill switches — global freeze and per-feature switches, logged and double-confirmed.
  • Operators — six accounts, roles from ops to auditor, every change with a reason.
  • Freezing a card — blast radius stated, reason required, type PROD to confirm.
/// FAQ

Running the back office, answered.

  • Operators act — freeze a card, issue a credit, retire a device — but every privileged action opens a dialog that states its blast radius and demands a written reason, and the reason lands in an append-only audit log. Production actions make the operator type PROD before the button enables.

  • Email and phone stay masked until revealed on purpose, and the reveal is itself an audited event. Money metrics — balances, flow — sit behind a financial role, so clearance decides who sees what, not just the login.

  • Layered controls: reason-required dialogs on every action, an immutable log of who did what and why, credits above a threshold that wait for a second operator's co-sign, and a rule that nobody approves their own request or changes their own role.

  • Both rails on one surface. Transactions list fiat and crypto side by side; a crypto top-up drills down to the rate, fee, wallet address, and transaction hash, and Tracer follows a single reference across every hop from request to settlement.

  • Six roles — superadmin, ops, compliance, engineer, support, auditor — each seeing exactly what its clearance allows. Role changes route through a reason dialog, and a second superadmin is required to grant them.

  • A global freeze and per-feature kill switches — cards, top-ups, transfers, KYC — each logged and double-confirmed. The overview surfaces breakers, provider health, and queues, so operators usually see the problem before customers do.

/// Evaluate

Sit in the operator's chair.

[ 01 ]

Guided console walkthrough

A live tour of the overview, queues, User 360, and the audit log — with a run through a reason-required action and a two-person approval.

[ 02 ]

Sandbox console

An operator login on a seeded deployment, with queues, transactions, and roles populated, so your ops and compliance leads can work it like a real shift.

[ 03 ]

Role-scoped test accounts

Logins across the six roles — from superadmin to auditor — to see exactly what each clearance can and cannot do.

[ 04 ]

Standalone or bundled

Evaluate Center over your own deployment or as the console that ships with Protocore Pay — your brand on the surface either way.

Request sandbox access
Availability

Ships with Protocore Pay, or runs standalone over your own deployment — under your brand.

In the ecosystem

Center is the back office behind the family — Pay's customers, Gateway's payment links, ATM's fleet lane, and the reconciliation queue vIBAN feeds.

Pick a product. Or take the core.

Everything above runs in production demos we can walk you through — standalone, whitelabel, or as one platform. Tell us what you're building and we'll show you the shortest path to it.

Contact us