Coreal.
Book a working session →
← PLATFORM·P1 · Banking OS · Neobank

Neobank Super Wallet

A consumer-grade mobile wallet built directly on Coreal's double-entry core. One identity moves between fiat IBAN, Visa card, crypto custody and SEPA without losing journal integrity.

Live
EU + UK
Uptime
99.99%
TPS
10k
IBANVISASEPACRYPTO
01Capabilities

What ships in the box.

C-01

IBAN issuance

Personal & business IBANs via licensed sponsor or own EMI

C-02

Visa card issuing

Virtual instant + physical, 3DS, tokenization, Apple/Google Pay

C-03

Crypto custody

Multi-chain custody with KYT screening on every move

C-04

SEPA rails

SCT/SCT Inst, mandates, recurring, dunning

C-05

Fiat/crypto switching

Spread-managed conversion with audit-grade journaling

C-06

Full KYC/KYT

OCR · liveness · sanctions · ongoing monitoring · SAR filing

02Technical deep dive

How it works under the hood.

Five sections covering the structural decisions, the data model under them, and the operational characteristics you can show to an architecture review or a regulator.

§ 01

Why one ledger for fiat and crypto

Most wallets that started as fiat-only bolt crypto onto a separate database when they add it. The result is two ledgers, two reconciliations, two truth sources, and a permanent class of edge cases where fiat balance and crypto balance disagree about who owes what to whom. Coreal Super Wallet is built on a single double-entry core where every fiat IBAN, every Visa authorisation, every BTC/USDC custody movement and every SEPA settlement posts to the same ledger as a typed entry. Currency is a column, not a separate system. Reconciliation drift across all asset classes runs at 0.00 bps because there is nothing to reconcile — there is only one set of postings.

§ 02

Card authorisation lifecycle

When a Coreal-issued Visa card is presented at a merchant, the authorisation request hits the card processor, is forwarded over the issuer interface to the wallet service, and is matched against the customer subaccount tree. The available balance is calculated as posted balance minus the sum of open auth-blocks. If the auth passes risk and balance checks, a blocking entry is journaled (Dr customer:available · Cr customer:blocked) with the auth ID, scheme reference and merchant category. The auth then either captures (block → settled, with the cleared amount), partially captures (block split into settled + released), or expires after the scheme TTL (typically 7–30 days). Every state transition is a posting. The card processor never holds authoritative state.

§ 03

Crypto custody and KYT

The crypto custody module integrates Fireblocks (or an equivalent MPC custodian) for key management. Coreal does not hold raw private key material; what Coreal holds is the policy layer that decides which transactions are allowed to be signed. Every inbound deposit and outbound withdrawal is screened against a Chainalysis KYT result before the corresponding ledger posting is finalised. A flagged result (sanctions exposure, mixer interaction, dark-market provenance) routes the transaction to a manual review case in the operator workspace, with the wallet credit blocked until the analyst clears it. The customer sees a "pending review" status; the regulator sees a complete decision trail.

§ 04

Fiat ↔ crypto switching

Switching between fiat and crypto inside the wallet is not a forwarded request to an exchange — it is a position adjustment on the Coreal treasury book. The customer sees a quote (with spread), confirms, and the trade posts as four entries: customer fiat debit, customer crypto credit, treasury fiat credit, treasury crypto debit. Coreal's treasury then nets exposures across all customers and hedges externally on a managed cadence (typically every 5–15 minutes during market hours, longer during low-volume windows). Customers get instant settlement; the firm carries managed FX risk.

§ 05

Onboarding and tier progression

A first-time customer can hold up to €1,000 in balance after passing Tier 1 KYC: telco-verified identity, name + DOB, sanctions screening. To go beyond that — to receive an IBAN, hold higher balance, or use crypto — they progress to Tier 2: OCR-extracted government ID, liveness check, address verification, expanded sanctions/PEP screening. Each tier has explicit limit multipliers on transactions per day, balance, single transaction, and cumulative volume. The BPM engine enforces these at the gateway layer: a customer attempting an out-of-tier action sees an in-app step-up flow that resumes the original transaction once verified.

03Data model

Core entities & key fields.

The handful of entities you would design first if you were building this from scratch. Naming and field shape match what an audit firm or counterparty would expect.

ENTITYPURPOSEKEY FIELDS
customer_accountTop-level customer record with hierarchy of subaccountsid · tier · status · primary_currency · created_at · risk_score
subaccountCurrency-specific balance pocket under a customerid · customer_id · currency · type (available/blocked/savings) · balance · updated_at
postingImmutable double-entry ledger recordid · ts · debit_account · credit_account · amount · currency · ref · journal
cardIssued card token + lifecycle stateid · customer_id · pan_token · scheme · state · 3ds_enrolment · last_used
auth_blockOpen card authorisation against subaccountid · card_id · merchant · amount · scheme_ref · expires_at · state
kyt_eventOn-chain transaction screening resultid · tx_hash · provider · risk_score · flags · decision · case_id
04Request lifecycle

From input to settled state.

The path a single operation takes through the system. Every step is journaled and replayable.

1. Auth ingressCard processor sends auth-request over ISO-8583 / scheme webhook
2. Risk + tier checkWallet service validates balance, tier limits, velocity, device + scheme risk score
3. Block postingDouble-entry write: Dr available · Cr blocked, journaled with idempotency key
4. Auth responseApprove/decline returned to processor within p95 < 80ms (target 50ms)
5. SettlementCapture file matched against blocks; partial/full captures and reversals journaled
6. ReconciliationDaily settlement file reconciled with posted-block sum; delta target = 0.00
05Operational characteristics

What this looks like in production.

SLO-01
Auth p95
< 80ms

Authoriser end-to-end including risk + balance check

SLO-02
Reconciliation drift
0.00 bps

Daily across PSP, scheme, custodian, ledger

SLO-03
Onboarding p95
38 seconds

Tier 1 (telco-verified) · OCR + liveness for Tier 2 typically 90s

SLO-04
Failover (PSP)
< 200ms

Provider gateway swaps to secondary on outage

SLO-05
Audit log retention
7 years

Immutable, queryable, regulator-ready

SLO-06
Throughput sustained
14,200 tps

Hot-path postings without queueing

06Architecture

Behind the surface.

Mobile BFF (Node 20) → wallet service (Spring 6) → core ledger (PostgreSQL with double-entry constraints) → PSP/BaaS gateway → card processor + crypto custodian. KYT events flow through Kafka into a graph store with real-time alerting.

07Integrations

Vendors & rails.

VisaMastercardSEPA via sponsorOpen Banking PSD2SumsubOnfidoChainalysis KYTFireblocks
08Regulatory posture

EMI sponsor in EEA · CASP perimeter ring-fenced under MiCA · GDPR DPIA on telco signal usage · DORA-aligned ICT controls.

09Adjacent products

The rest of the platform.