What a Digital Wallet Is, Architecturally
A digital wallet is a stored value system: it holds a balance on behalf of a user and enables that balance to be increased (by loading funds) or decreased (by spending or withdrawing). The engineering challenge is not the concept: it is maintaining balance integrity across concurrent transactions, managing payment instruments securely, and meeting the regulatory requirements that apply to whoever holds the float.
This post covers the core engineering decisions for teams building digital wallet products: ledger design, instrument tokenisation, regulatory classification, and the compliance integrations you will need before you can go live.
Ledger Design: Double-Entry and Balance Integrity
Every wallet balance is derived from a ledger (a record of credits and debits that nets to the current value). Double-entry bookkeeping is the standard: every transaction creates two entries (a debit on one account and a credit on another), so the ledger is always self-balancing and discrepancies are detectable.
The two states your ledger must track are pending and settled. A pending entry represents a transaction that has been initiated but not yet finalised: for example, a card authorisation or an in-flight transfer. A settled entry is irrevocable. Your UI should show available balance (settled minus pending outflows) and current balance (settled only) as distinct values. Conflating them is a common source of customer disputes.
Concurrent transaction handling is the hardest part of ledger engineering. When two operations attempt to debit the same wallet simultaneously, you need a concurrency strategy. Optimistic locking reads the current version of the balance row, performs the calculation, and writes the result with a version check: if another transaction updated the row between read and write, the write fails and retries. Pessimistic locking acquires a row-level lock before reading, preventing other transactions from modifying the row until the lock is released. Optimistic locking scales better under low contention; pessimistic locking is safer when contention is high (high-volume consumer wallets). Choose based on your expected concurrency profile.
Reconciliation must run continuously. Your wallet ledger, your payment processor's settlement files, and your bank account balances should agree at every reconciliation interval. Build automated reconciliation from the start: retrofitting it is expensive. For a detailed look at payment platform architecture and reconciliation design, see architecture of a modern payments platform. Flag breaks immediately; do not let them accumulate.
Payment Instrument Management
Users load wallets from external sources: bank accounts, cards, and other wallets. Each instrument type has different data sensitivity, different failure modes, and different regulatory treatment.
Card data must never touch your servers directly. Use a PCI DSS-compliant tokenisation provider (Stripe, Braintree, Adyen, or similar): the user's card details go to the provider, and you receive a token that represents the card. Your systems store only the token. If your database is breached, tokens are useless to an attacker. Attempting to build your own card vault without PCI Level 1 certification is not a viable path for most FinTech teams.
Bank account data (account number, routing number) is lower sensitivity than card data but still requires care. Plaid, Tink, and similar open banking providers handle bank account verification and ACH/SEPA origination. Direct debit mandates must be stored against the user record with full audit trail: regulators and payment networks will ask for them in disputes.
Model instruments as a separate entity from the wallet: one user can have multiple instruments, one instrument can be attached to multiple wallets in some designs, and instrument lifecycle (add, verify, suspend, remove) operates independently from wallet transactions.
Regulatory Classification by Wallet Type
The regulatory obligations on your wallet product depend on whether you are holding client money, who can load and redeem value, and whether value is redeemable for cash. Get this classification wrong and you are operating without a licence.
Closed-loop wallets hold value redeemable only with a specific merchant or within a specific platform (think gift cards or platform credits). Regulatory requirements are lighter: in most jurisdictions, closed-loop products are exempt from e-money regulations up to certain value limits (EU: EUR 200 stored / EUR 300 annual load; UK: GBP 200 stored). Above those limits, or if redemption for cash is permitted, the exemption typically does not apply.
Open-loop wallets (where the user can spend anywhere via a card network or bank transfer, or withdraw to a bank account) require a payment institution licence or e-money institution (EMI) licence in most jurisdictions. In the US, this means state-by-state Money Transmitter Licences (MTLs): 48 states require separate MTL applications, and compliance varies significantly by state. For the full landscape of US FinTech licensing requirements, see FinTech development in the US. The BitLicence is required for crypto-related activity in New York separately. In the EU, a passportable EMI licence from one member state covers the EEA. In the UK, post-Brexit EMI authorisation from the FCA is required independently.
Crypto wallets add Virtual Asset Service Provider (VASP) registration obligations in most jurisdictions: Financial Crimes Enforcement Network (FinCEN) in the US, FCA in the UK, and national competent authorities under MiCA in the EU (MiCA applied from December 2024).
If you are building on someone else's licence (a Banking-as-a-Service or e-money provider), understand what their licence covers and where your obligations begin. Delegation of regulated activity has limits and the regulator will look at who is ultimately responsible for compliance controls. Engineering teams that work with FinTech software development organisations experienced in wallet licensing can map these obligations before writing compliance-layer code.
KYC and Identity Verification
Any wallet that holds meaningful value or processes payments requires Know Your Customer (KYC) checks: identity verification, sanction screening, and in many cases, proof of address. The threshold for full KYC varies by jurisdiction and wallet type, but budget for it from day one.
The major identity verification providers used in FinTech wallet builds are Onfido, Jumio, and Stripe Identity. All three offer document capture (passport, driving licence, national ID), liveness checks, and database lookups against sanctions lists (OFAC, EU, UN). Differences matter at the margin: Onfido has strong coverage of African and Southeast Asian document types; Jumio is prevalent in US banking integrations; Stripe Identity is easy to embed if you are already on Stripe's payments stack.
Tiered KYC is common: lower-tier wallets (limited balance, limited monthly transaction volume) proceed with lighter identity checks; higher tiers unlock full wallet functionality after full KYC completion. Define your tiers in coordination with your compliance team and your licence obligations: regulators will audit the tier structure as part of any examination.
Fraud Controls
Wallet fraud falls into two main categories: account takeover and P2P abuse.
Account takeover occurs when an attacker gains access to a legitimate user's wallet. Mitigations include: device binding (a wallet session is tied to a verified device), push notification confirmation for high-value transactions, step-up authentication (re-authenticate before initiating a withdrawal), and velocity rules (flag or block unusual transaction patterns by amount, frequency, or geography). Monitor login events as carefully as transaction events: most account takeovers begin with a credential compromise, not a transaction exploit.
P2P abuse covers money mule activity, scam-facilitated transfers, and authorised push payment (APP) fraud. In the UK, the Payment Systems Regulator mandated reimbursement of APP fraud from October 2023: if your wallet is a Faster Payments participant, this applies to you. Controls include: cooling-off periods on new payees, confirmation of payee (CoP) matching, and real-time transaction risk scoring. Sardine and Sift are commonly integrated for real-time fraud scoring in wallet products.
Notifications and Real-Time Balance
Users expect instant push notifications on every wallet event: load, spend, transfer, and failed transaction. This is not just a UX expectation; in some jurisdictions it is a regulatory requirement (PSD2 strong customer authentication notifications in the EU/UK). Build your notification pipeline as a first-class system, not an afterthought.
Real-time balance updates require your wallet service to emit events on every confirmed ledger entry. A pub/sub pattern (Kafka, AWS SNS/SQS, or similar) keeps the notification pipeline decoupled from the transaction processing path. Do not poll for balance changes from the client: push from the server on settlement.
FAQ
What is the minimum viable architecture for a digital wallet?
An MVP wallet needs: a double-entry ledger (PostgreSQL with row-level locking works at early scale), a tokenisation integration for at least one payment instrument (card or bank account), a KYC integration, and a basic compliance policy (AML transaction monitoring, sanction screening). Do not defer ledger integrity or KYC: they cannot be retrofitted without stopping the product.
How do cross-currency wallets work?
Multi-currency wallets hold a separate ledger per currency denomination. FX conversion creates a pair of entries: a debit in the source currency and a credit in the target currency at a specified rate. The FX rate must be recorded on the transaction record: auditors and regulators will ask for it. Embedded FX providers include Currencycloud (now Visa), Equals Money, and iBanFirst for B2B use cases.
Which compliance integrations do US wallets typically need?
US wallet builds typically integrate: identity verification (Onfido, Jumio, or Stripe Identity), OFAC sanction screening (often included in the KYC provider), AML transaction monitoring (Sardine, Alloy, or Unit21), and bank account verification (Plaid or Finicity). If your wallet issues physical or virtual cards, add Marqeta or Lithic for card programme management. State MTL compliance typically requires a compliance management system (CMS): Hummingbird and Flagright are used by FinTech teams at the pre-Series B stage.
