Unlocking Payment System Design: 19 Core Account Models Explained

1. Account Essence and Basic Models

The foundation of any payment solution lies in distinguishing real (entity) accounts that hold actual funds and are subject to strict regulations, from virtual accounts that are bookkeeping entries linked to underlying real accounts.

1.1 Virtual‑Real Account Model

Real accounts include bank settlement accounts, payment‑institution accounts, central‑bank reserve accounts, and inter‑bank deposit accounts. They have independent numbers, are regulated by the Non‑Bank Payment Institution Supervision Regulations and the RMB Settlement Account Management Measures, and can serve as asset proof.

Virtual accounts are non‑financial bookkeeping entries created within a platform for internal accounting, user experience, or business operations. The actual money resides in a linked real account. Typical examples are Alipay’s “零钱” (small change) account, e‑commerce seller fund accounts, and internal ERP settlement accounts. Virtual accounts describe fund ownership and purpose without moving physical cash, but the platform must ensure fund safety and transparency.

1.2 Balance Structure Model

A balance‑structure model clarifies the different states of money within a single account.

Single‑Balance Model : Only one balance exists (e.g., a simple wallet). It cannot distinguish frozen, in‑transit, or pending settlement funds.

Multi‑Balance Model : Multiple sub‑balances record different fund states or purposes. The total balance equals the sum of all sub‑balances.

Total Balance :

Total balance = Available balance + Frozen balance + In‑transit balance + …

Available Balance : Funds the user can spend or withdraw.

Frozen Balance : Temporarily locked funds (e.g., pre‑authorizations, disputes).

In‑Transit Balance : Funds that have been debited but not yet settled.

Pending Settlement Balance : Completed transactions awaiting the settlement cycle.

Credit Limit / Credit Balance : Platform‑granted credit, effectively a negative balance.

Example transaction flow (payment of 100 units):

Available balance -100
In‑Transit balance +100
# after settlement
In‑Transit balance -100
Total balance -100

1.3 Accounting Subject Mapping Model

This core model links front‑end business operations with back‑end general‑ledger accounts, ensuring that business, fund, and financial ledgers are reconciled.

2. Account Hierarchy and Relationship Models

2.1 Account Hierarchy Model

Accounts can be organized in tree‑like structures to support centralized control, settlement, and internal accounting.

Single‑Level Flat Accounts : All accounts exist at the same level with no parent‑child relationship (e.g., Alipay’s wallet).

Multi‑Level Tree Accounts : Parent‑child relationships allow a mother account to control child accounts, enabling fund aggregation and permission inheritance.

Typical patterns:

All‑Virtual Model : Both mother and child accounts are virtual (e.g., a large group’s internal fund‑pool).

Mother‑Real / Child‑Virtual Model : Mother is a real bank account; children are virtual seller accounts (common in e‑commerce two‑clearance).

Mother‑Virtual / Child‑Real Model : Mother is virtual, children are real (used by corporate treasury platforms).

2.2 Cross‑Institution Account Mapping Model

2.2.1 Payment Account / Reserve Custody Account

Regulations require all user funds to be fully deposited in a central custodian account at the central bank. Internally, each user gets a dedicated virtual payment account linked to the custodian.

Balance relationship:

Custodian account balance (bank entity account) = "Customer reserve deposit" asset balance = "Payable – customer reserve" liability balance = Σ all payment‑account balances (customer ledger)

2.2.2 Network Union (UnionPay) Institutional Account

During daytime processing, payment institutions freeze the amount in the UnionPay virtual account; settlement clears the amount at day‑end.

2.2.3 CIPS Zero‑Balance Account (Second‑Generation Settlement Account)

CIPS uses zero‑balance accounts for intra‑day payment recording; at day‑end the central bank’s HVPS clears the balances.

2.2.4 Bank Settlement Account / Payment Account (Same‑Name Binding)

The user’s bank account is bound to the payment institution’s virtual account, forming the basis for quick‑pay, pre‑authorization, and other services.

3. Advanced Applications and Derived Models

3.1 Fund‑Pool Models

Fund‑pools are not separate account types but configurations that combine hierarchy and business rules to achieve centralized fund control, liquidity optimization, and cost reduction.

3.1.1 Physical Fund‑Pool

Implemented as a mother‑real/child‑virtual or mother‑real/child‑real structure, where actual cash is transferred to a central bank account and then allocated to subsidiaries.

3.1.2 Virtual Fund‑Pool

All accounts remain virtual; the pool only performs net‑position offsetting without physical cash movement, reducing inter‑company interest costs.

3.1.3 One‑Pool‑Many‑Accounts

A single real mother account serves millions of virtual child accounts (e.g., e‑commerce two‑clearance). This model enables one entity‑level account to service massive user bases while maintaining individual accounting records.

3.1.4 Global Fund‑Pool

Combines multi‑level nesting, cross‑institution mapping, and multi‑currency management. Typically built with regional treasury management systems (TMS) to provide a central‑radiating structure for worldwide fund visibility, control, and net‑settlement.

3.2 Payment‑Tool and Account Separation Model

This design decouples the authentication/authorization layer (payment tools) from the fund‑storage layer (accounts), improving security, scalability, and user experience.

The account layer records ownership, amount, and state of funds, while the tool layer verifies the user and authorizations. A many‑to‑many binding layer defines rules such as per‑transaction limits, daily caps, and applicable scenarios. If a tool is lost, it can be unbound or frozen without affecting the underlying funds.

4. Design Guidelines

Combine Multiple Models : For a multinational e‑commerce platform, integrate mother‑real/child‑virtual settlement accounts, multi‑currency sub‑balances, cross‑institution mappings, and virtual fund‑pools to achieve efficient capital use.

Balance Business, Compliance, and Performance : Ensure the model supports split‑payment, supply‑chain finance, and global collection while meeting regulations (e.g., Non‑Bank Payment Institution Regulations, AML, reserve‑fund rules). Use sharding, hot‑cold data separation, and read‑write splitting for high concurrency.

Prioritize Compliance and Risk Control : Implement KYC/KYB, account classification (I/II/III), transaction limits, and authorization channels. Reconcile business, fund, and financial ledgers daily to detect and resolve discrepancies.