/// Platform architecture

One core, many surfaces — how the platform actually works.

A walk through the platform from the ledger up: the accounts, KYC, cards, and crypto that share one double-entry core, how a single payment moves from create to reconcile, and where the app layer, the operator console, and the regulated line each sit.

Talk to us See the products

/// The core

One ledger under everything.

At the center of the platform is a single account ledger. Every account — a customer wallet, a merchant balance, a fee account, a settlement account — is a node on that ledger, and every movement of value is a double-entry posting: one account debited, another credited, the two sides always equal. The ledger is append-only. Entries are never edited or deleted; a correction is a new, opposing entry, so the full history of how a balance reached its current value is always reconstructable. Accounts, KYC state, issued cards, and crypto addresses all attach to the same account model, which is why a card authorization, a bank transfer, and an on-chain deposit can post to one balance without a reconciliation layer stitching separate systems together.

[ 01 ]Double-entry: every posting balances, debits equal credits
[ 02 ]Append-only: corrections are new entries, never edits
[ 03 ]One account model for fiat, cards, and crypto
[ 04 ]KYC state travels with the account, not a side table

/// A payment, end to end

One payment, create to reconcile.

A payment is not one call but a short lifecycle, and each stage is a state the ledger and your systems can both see. Every state change emits a webhook, and every write is idempotent — the same key replays to the same result, so a retried request never double-charges.

[ 01 ]
Create
An intent is opened: amount, currency, the accounts involved. Nothing has moved yet — the ledger records a pending entry.
[ 02 ]
Authorize
The rail checks funds and risk and places a hold. For a card this is the authorization; for a transfer, the debit is reserved.
[ 03 ]
Capture
The held amount is committed. The ledger posts the double-entry that actually moves value between the two accounts.
[ 04 ]
Settle
Funds clear across the underlying rail — card scheme, bank, or chain — and settlement accounts reconcile to real money.
[ 05 ]
Reconcile
The platform matches its own postings against the rail's settlement report; anything that doesn't line up is flagged, not hidden.

Webhooks and idempotency live at every edge of this flow. Your systems learn that a payment moved by receiving an event, not by polling, and any request you retry after a timeout resolves — via its idempotency key — to the same result, so a repeat never double-charges. The service that runs authorize and capture is the payment gateway.

/// The app layer

Whitelabel apps on top, one platform underneath.

The core exposes capabilities; the app layer turns them into products. Each customer-facing app — web and mobile — is a whitelabel client that renders the same accounts, payments, and cards through its own brand. Theming is token-driven: colors, type, radius, and spacing come from a design-token system (PDS), so an operator restyles the entire surface by changing tokens, not by forking the app. The same platform can be pointed in very different directions — a consumer neobank, a merchant acquiring app, a card-issuing program, a crypto on/off-ramp, or an internal operations tool — without becoming five separate products. It is one platform wearing different skins, each configured rather than rebuilt.

[ 01 ]Whitelabel web + mobile clients on shared APIs
[ 02 ]Token-driven theming (PDS): restyle by config, not fork
[ 03 ]Five example directions — neobank, acquiring, issuing, ramp, ops
[ 04 ]New surfaces are configured, not rebuilt

/// Operations

Run it from the console, with a reason on the record.

Behind every app is an operator console. It is where a support agent looks up an account, a risk analyst freezes a card, or an operations lead reverses a posting. Read access is broad; privileged actions are not. Anything that moves money, changes limits, or touches a customer's funds requires a stated reason before it runs and writes an immutable audit entry — who acted, on what, when, and why. Access follows least privilege, so each operator sees and does only what their role allows. This is the model in Protocore Center, the operator console, and the same posture is built into every system on the platform: sensitive actions are deliberate, attributable, and reviewable after the fact.

[ 01 ]Broad read, gated write — privileged actions are the exception
[ 02 ]Reason-required before any fund-touching action
[ 03 ]Immutable audit trail: who, what, when, why
[ 04 ]Least privilege per operator role

/// The crypto bridge

Crypto and fiat on the same ledger.

Crypto is not a separate silo on the platform; a crypto address is just another account on the same ledger. An on/off-ramp converts between fiat and digital assets at the edge — a customer funds a balance with a card or a transfer and receives crypto, or sells crypto and withdraws to a bank account. On-chain value can settle through to a bank rail: an incoming on-chain payment is credited to the account, converted, and paid out to an IBAN, so the recipient sees ordinary money in an ordinary bank account. Because both legs post to one double-entry ledger, a movement that starts on-chain and ends in a bank transfer is a single reconciled history, not two systems reconciled by hand.

[ 01 ]A crypto address is an account like any other
[ 02 ]On/off-ramp: fiat and digital assets converted at the edge
[ 03 ]On-chain settlement through to an IBAN payout
[ 04 ]One reconciled history across both legs

/// The build surface

APIs, webhooks, and a sandbox to build against.

Everything the apps do, they do over a documented API — create an account, open a payment, issue a card, initiate a ramp. Illustrative calls look like POST /v1/wallets or POST /v1/payments; the shape is REST with an idempotency key on every write. State changes are delivered as webhooks, so your systems react to events instead of polling for them. Development happens against a sandbox tenant — an isolated copy of the platform with test rails, where you can run the full create-to-reconcile flow without moving real money. What each product exposes to you, and at which tier, is set by its access band; the per-product pages spell out what a given band includes.

[ 01 ]Documented REST API, idempotent writes
[ 02 ]Webhooks for every state change — event-driven, not polled
[ 03 ]Sandbox tenant with test rails, isolated from production
[ 04 ]Scope and limits set by per-product access bands

/// The honest boundary

Protocore builds the software. The licence holds the regulated line.

A payment product is two things fused together: the regulated permission to hold and move money, and the software that instructs, records, and reconciles it. Protocore builds the software. The regulated activity — holding customer funds, issuing accounts, moving money on a scheme — sits with the operator's own licence or a licensed partner: a bank, an EMI, or a payment institution. The platform is built to fit whatever regulated rails you bring, and to keep card data on the rail so it never touches your servers; it is not, and no software is, a substitute for that permission. Where the regulated line falls is a decision you make with your partner, and the architecture is designed to sit cleanly on either side of it.