Clearing and Reconciliation System in Payment Platforms: Architecture, Processes, and Data Handling

1. Clearing and Reconciliation System

In a payment system, fund reconciliation is performed in the reconciliation center, matching the system‑saved accounting flow with the bank’s settlement flow and files to ensure the consistency of daily expected and actual amounts in the payment institution’s reserve accounts.

1.1 Funds Inflow Reconciliation

Funds flowing from the bank are controlled by the bank’s settlement schedule. The bank notifies the payment institution of recharge instructions in real time, aggregates them nightly, and deposits them into the institution’s bank account, providing a settlement file. The institution imports this file and matches it with its business data. If the amounts match, reconciliation succeeds; otherwise, two situations may arise: the bank reports more funds than the system (temporary挂账) or the system reports more funds than the bank (potential loss).

1.2 Funds Outflow Reconciliation

When a customer requests a withdrawal, the payment company sends a batch withdrawal request to the bank, which deducts the amount from the company’s bank deposit account. The bank later provides a settlement file indicating success or failure. Successful withdrawals are recorded directly in the customer’s account without further reconciliation in the center; failed withdrawals trigger a back‑charge to the customer’s account.

2. What Is Reconciliation?

2.1 Definition of Fund Reconciliation

In accounting, reconciliation ensures that ledger entries are correct (accuracy), supported by evidence (authenticity), and consistent across records (consistency). In a payment institution, fund reconciliation matches system‑saved accounting flows with bank settlement flows and files to guarantee that the institution’s reserve accounts reflect the same amounts as the bank’s actual settlements.

2.2 Role of the Reconciliation Center

The reconciliation center is the main module for clearing reconciliation. It receives data from the accounting system and the settlement system, matches them, and verifies that the bank’s actual account balance changes align with the internal account balance changes. Matched records are stored in historical bank‑flow and historical entry‑flow libraries.

3. Reconciliation Content and Data Sources

Step 1: Match entry flows with settlement flows to ensure each order’s bank result aligns with the system result. Step 2: Compare the reconciliation summary sheet with the bank statement, using balance‑offset methods to verify that all business‑level bank results match the actual funds received.

3.1 Reconciliation Business Process

Reconciliation Business Flowchart

3.2 Main Functions of the Reconciliation Center

The center processes settlement flows, classifies them, and generates summary sheets. It supports complete daily closing, comprehensive reporting (by entry date, bank date, settlement date, etc.), daily cut services, and auxiliary functions such as bank‑account management, business‑code queries, and error‑account verification.

4. Reconciliation Center Functional Module Analysis

4.1 Obtaining Fund Reconciliation Data

(1) Data is usually imported manually via a page, though some streams are auto‑matched or scheduled. (2) All settlement‑flow import functions should be unified under a single entry, with channel mapping logic. (3) Parsing and import logic differ across business types.

4.2 Settlement‑Flow Reconciliation

4.3 Reconciliation Logic

(1) One‑to‑One Reconciliation

Each entry flow matches a single bank flow. Business codes include B2C/B2B recharge, VISA, normal withdrawal, etc. Matching standard: (settlement channel + order number + amount) OR (bank name + business code + order number + amount).

(2) Many‑to‑Many Reconciliation

Multiple entry flows with the same order, channel, and amount may match multiple bank flows. The same matching standard applies. Example business codes: 410401 (refund), 410402 (inter‑bank refund), 410403 (Motopay refund).

(3) One‑to‑Many Reconciliation

Multiple entry flows are matched against a single bank flow, e.g., overseas settlement (code 520101) and related purchase‑back (code 400319).

4.4 Reconciliation Functions

(1) Internal Flow Offsetting

For operations like withdrawals where a back‑charge occurs, the system performs internal offsetting without involving the bank reconciliation center.

(2) Reconciliation Summary Confirmation

After confirming reconciliation results, successful records are moved to historical settlement and entry libraries; mismatched or multi‑account records are handled via classification, manual adjustment, or deletion.

(3) Flow Classification and Aggregated挂账

Multi‑account flows are classified and aggregated for挂账 (pending posting). Specific business codes (e.g., 700101‑700108) are allowed for pending posting.

(4) Settlement/Entry/Historical Flow Management

All settlement flows can be queried, modified, or deleted; entry flows are read‑only; historical flows are query‑only.

(5) Bank Balance Entry

Allows manual entry of actual bank balances, which are later reconciled and used for balance verification.

(6) Internal Account Posting

Supports posting of non‑bank internal accounts such as clearing funds, interest, and fees, without generating downstream vouchers.

(7) Pending Income挂账

Registers pending income from bank accounts; the debit side must be a bank‑deposit account, the credit side a pending‑account.

(8) Pending Income Confirmation

Confirms pending income vouchers, allowing subsequent offsetting and handling of differences.

(9) Pending Expense挂账

Registers pending expenses; the credit side must be a bank‑deposit account, the debit side a pending‑account.

(10) Pending Expense Confirmation

Confirms pending expense vouchers with similar validation rules.

5. Unexpected Data Recovery Logic

5.1 Unexpected Data Recovery

(1) Duplicate payment: the same internal order is paid multiple times. (2) Payment failure with amount mismatch: buyer’s paid amount differs from transaction amount. (3) Payment success with amount mismatch: order is marked successful but the paid amount differs due to network or bank issues.

5.2 Reconciliation and Exception Recovery Logic

(1) Use merchant‑successful orders as the reference.

Align backend order status with merchant status: if merchant order is successful and backend is initial/failure, update backend to success; otherwise, no change.

(2) No duplicate recovery.

Recover T‑day orders on T+1 day and avoid re‑processing the same data.

(3) Temporal differences.

Bank cut‑off times differ, leading to three cases: merchant has data but backend does not, backend has data but merchant does not, or both have data. These are treated as temporal differences.

6. Additional Promotional Content (Not Part of Technical Description)

Readers can scan QR codes or reply to the public account to join the top‑architect group, receive interview questions, or obtain surprise gift packages.