Refund & Reversal

About This Page

What: Product logic of three refund/reversal mechanisms in the deposit system — when to use which, what the system does, and what to do when it fails Audience: Product managers who need to understand the complete refund picture Prerequisites: Deposit Methods Overview, Deposit Quick ReferenceReading time: 8 minutes Owner: Deposit Product Manager

Key Takeaways: The deposit system has three reverse operations — task reversal (deduct credited funds), flow refund (mark only, no account movement), and BST bank refund (Airstar exclusive). Their usage scenarios and system behaviors are completely different.

---

Quick Navigation — What you might want to do:

• Received refund request, not sure which path? -> Refund Decision Tree
• Want to understand the differences between three mechanisms? -> Three Refund Mechanisms Comparison
• Reversal failed, what to do? -> Refund Failure & Recovery
• Want to see how operations handles it? -> Reversal Operations Manual
• Want to modify reversal process? -> Deposit Change Guide - Modify Reversal Process
• Want to check reversal-related status codes? -> Deposit Quick Reference - Reversal Reference Data

Three Refund Mechanisms Comparison

The deposit system has three "reverse operations for completed transactions." Although they all look like "money came back" from the user's perspective, the system behavior is completely different:

	Task Reversal	Flow Refund	BST Bank Refund (REFUNDED)
One sentence	Deduct credited funds from securities account	Mark bank statement as "refunded," no securities account movement	Airstar Bank proactively returns credited funds
Initiated by	Operations manually	Operations manually	Bank automatically triggers
Fund impact	Yes — SBA deducts from securities account	No — only marks statement status	Yes — system automatically executes SBA deduction
Precondition status	Apply.status = 2 (completed)	Flow.status = 0 (pending)	Deposit already completed
Result status	Apply.status = 5, Task.status = REVERSE	Flow.result = 3 (RESULT_REFUND)	Deposit record marked REFUNDED
Permission required	CASH_IN_TASK_REVERSE	CASH_IN_FLOW_HANDLE	System automatic, no permission needed
Reversible	Not reversible	Not reversible	Not reversible
API entry	/deposit/reverse	/flow/refund, /flow/refund-batch	Airstar API callback
Use case	Bank chargeback, incorrect crediting, risk control interception	Statement cannot be matched and needs bank return, erroneous statement cleanup	Airstar BST exclusive — bank post-hoc compliance refund
Applicable banks	All	All	Airstar only

Core Distinction

Task reversal moves real money (deducts from securities account); flow refund only marks statement status, securities account balance remains unchanged. Confusing these two operations causes fund discrepancies — if task reversal should have been done but only flow refund was performed, the funds in the user's securities account won't be deducted back.

---

Task Reversal

Task reversal is the "heaviest" refund operation — it deducts funds already credited to the user's securities account.

Status Flow

System Execution Steps

When operations clicks "Reverse," the system executes in sequence:

1. Status validation: Confirm Apply.status = 2 (completed) and not currently processing
2. SBA reverse orchestration: Call turnAround('CashDepositReverse', ...) to deduct funds from securities account
3. Status update: Apply.status -> 5 (reversed), Task.status -> REVERSE
4. Bank card unbinding: If it was a card-binding deposit (notice_type = BIND_CARD), automatically unbind that bank card
5. User notification: Send reversal notification (App push + message center)

Preconditions

Condition	Description
Application status = Completed (2)	Only completed deposits can be reversed. Processing (1) is not allowed
Permission CASH_IN_TASK_REVERSE	Operator must have reversal permission
Sufficient securities account balance	Reversal requires deducting from the account; insufficient balance causes SBA Procedure failure

SBA Reverse Orchestration

The core of task reversal is the SBA (Server Bank Account) reverse Procedure. The system first checks whether the original deposit's SBA Procedure status is PROCEDURE_STATUS_END_OK (i.e., the original deposit genuinely succeeded), then calls turnAround to execute the reverse operation.

Essence of the reverse operation: Execute each step of the original deposit Procedure in reverse — what was originally a "company account -> securities account" fund transfer, the reverse is "securities account -> company account."

Code Locations

• Task reversal entry: deposit/src/app/Business/Deposit.php:877-935 — reverse() method
• SBA reverse call: deposit/src/app/Business/SOA/SBA/Deposit.php:309 — turnAround('CashDepositReverse', ...)
• Reversal middleware: deposit/src/app/Business/Tasks/Deposit.php:276-287 — reverseMiddleware()
• Apply status constant: deposit/src/app/Business/Apply.php — STATUS_REVERSE = 5
• Task status constant: deposit/src/app/Classes/Task/Status.php — REVERSE = 5
• API entry: DepositController::reverseAction() — /deposit/reverse
• Batch reversal: DepositController::batchAction() — /deposit/batch with action=reverse

---

Flow Refund

Flow refund is much "lighter" than task reversal — it only marks the bank statement's disposition result as "refund," without affecting securities account balance.

When to Use Flow Refund

• Bank statement arrived in the system but cannot match to any deposit application, and is confirmed to need bank return
• Bank statement matched incorrectly (matched to wrong user), needs refund first then reprocessing
• Statement itself has issues (duplicate statement, test statement, etc.), needs cleanup

Status Flow

Three Operation Entry Points

Operation	API Entry	Scenario
Single refund	/flow/refund	Mark a single statement as refund
Batch refund	/flow/refund-batch	Batch mark multiple statements as refund
Unlock refund	/flow/unlock with is_refund=1	Unlock locked statement while marking as refund

Flow Refund vs Task Reversal

Dimension	Flow Refund	Task Reversal
Target object	Bank statement (Flow)	Deposit task (Task/Apply)
Precondition	Statement in pending status	Deposit completed (funds in securities account)
Fund movement	None	Yes (deducted from securities account)
Impact scope	Only marks statement	Updates Apply + Task + SBA + possible bank card unbinding
Usage frequency	Higher (daily statement cleanup)	Lower (only for abnormal situations)
Risk level	Low	High

Code Locations

• Flow refund entry: deposit/src/app/Business/BankFlow.php:674-724 — refund() method
• Unlock refund: deposit/src/app/Business/BankFlow.php:1639-1695 — unlock() with is_refund
• Refund result constant: deposit/src/app/Business/BankFlow.php — RESULT_REFUND = 3
• API entry: FlowController::refund(), FlowController::refundBatch()

---

BST Bank Refund (REFUNDED)

This is an abnormal status exclusive to Airstar BST — CMB and MSB BST do not have a refund mechanism.

Trigger Conditions

• Bank discovers transaction anomaly post-hoc (compliance issue), proactively initiates refund
• Bank risk control system intercepts post-hoc

System Behavior

REFUNDED vs FAILED

	REFUNDED	FAILED
Fund status	Deposit succeeded, bank refunds post-hoc	Bank rejected deposit, funds never arrived
System impact	Requires reversal (SBA reverse deduction)	No reversal needed, directly mark as failed
Complexity	High — credited funds may have been used for trading	Low — only status update needed
Operations involvement	Required — confirm refund reason, notify user	Usually not needed

---

Refund Decision Tree

When receiving a refund/reversal request, follow this path to determine which operation to use:

Key Judgments:

1. Have funds reached the securities account — Use task reversal if credited, flow refund if not
2. Who initiated — Operations manual goes through manual reversal, bank automatic goes through system handling
3. Is balance sufficient — When insufficient, need to coordinate first (user may have used funds for trading)

---

CRM Refund Management Process

When refund requests come through customer service channels, they follow the CRM refund management module's three-phase process. CRM is the "entry point" for refunds — it manages the approval process. After determining which refund path to take, the final execution still uses one of the three mechanisms described above.

Phase	Responsible Team	Key Actions	SLA
Registration	Customer Service	Record user complaint, fill in refund reason, link deposit record	Same day
Review	Business Operations	Verify refund basis, confirm whether to use reversal or flow refund, assess balance impact	1 working day
Processing	Finance	Execute system operation (reversal/flow refund), confirm bank-side fund return	1~3 working days

CRM Does Not Directly Operate Funds

The CRM refund management module only manages the approval process and does not directly operate securities account balances or bank funds. All actual fund operations are executed through SBA Procedures.

---

Refund Failure & Recovery

SBA Procedure Execution Failure

Symptom: After reversal operation is initiated, Apply status hasn't changed to 5, SBA logs show Procedure failure.

Possible Causes:

Cause	Manifestation	Handling
Insufficient securities account balance	SBA returns insufficient balance error	Contact user to top up balance, or coordinate with risk control to freeze account then handle
SBA service error	Procedure timeout or returns system error	Confirm SBA service status, retry reversal after service recovery
Original deposit Procedure status abnormal	PROCEDURE_STATUS_END_OK validation fails	Manual verification of original deposit's SBA execution records, use manual compensation if necessary

Special Handling for Insufficient Balance

This is the most common cause of reversal failure — the user may have already:

• Used funds to buy stocks (balance occupied by positions)
• Initiated a withdrawal (balance in transit)
• Performed other investment operations

Handling Path:

1. Confirm user's current available balance and position situation
2. If the shortfall is small: Wait for user to sell positions or withdrawal to arrive, then re-reverse
3. If the shortfall is large or urgent (e.g., bank chargeback): Freeze account -> Joint risk control handling -> Batch reversal
4. Do not attempt partial reversal — the system does not support reversing partial amounts, only full reversal

Flow Refund Mis-operation

Symptom: Operations mistakenly marked a normal statement as refund, but that statement should have been used for matching a deposit.

Handling:

• Flow refund marking cannot be directly undone
• Need to manually create a new abnormal deposit (DepositType = ABNORMAL) in OA backend, replacing the mistakenly refunded statement
• Record operation log, annotate "flow refund mis-operation compensation"

---

Real Cases

Case 1: Standard Reversal — Bank Chargeback

Background: User A deposited HKD 100,000 via FPS, deposit succeeded. 3 days later, the bank notified that this FPS transaction had a chargeback initiated due to "unauthorized transaction."

Handling Process:

1. Operations received bank chargeback notification
2. Found corresponding deposit application in OA (Apply.status = 2)
3. Confirmed user's securities account available balance >= HKD 100,000
4. Confirmed no in-transit withdrawal tasks
5. Executed task reversal -> Apply.status -> 5
6. SBA executed CashDepositReverse, deducted HKD 100,000 from securities account
7. User received reversal notification

Result: Reversal successful, bank card automatically unbound (because it was a card-binding deposit).

Case 2: Insufficient Balance Reversal — User Already Traded

Background: User B deposited HKD 500,000 then bought HKD 450,000 worth of stocks. Subsequently operations discovered this deposit was incorrectly credited (matched to wrong user).

Handling Process:

1. Attempted reversal -> SBA returned insufficient balance (available balance only HKD 50,000, positions occupying HKD 450,000)
2. Froze user's account to prevent further trading
3. Contacted user to explain situation, requested selling positions
4. After user sold stocks, available balance recovered to >= HKD 500,000
5. Re-executed reversal -> Successful
6. Re-credited HKD 500,000 to the correct user

Lesson: Large deposit reversals should be executed ASAP (freeze account immediately upon discovering the issue) to avoid difficulty recovering after user uses the funds.

Case 3: Flow Refund — Unmatchable Orphan Statement

Background: An HKD 25,000 HSBC MT910 statement existed in the system for over 5 days. The matching engine scanned multiple times but couldn't pair it (no corresponding deposit application).

Handling Process:

1. Operations discovered the orphan statement in OA statement list
2. Verified: No user had submitted an HKD 25,000 deposit application
3. Contacted bank to confirm: This transfer was a customer misdirection (transferred to wrong recipient account)
4. Executed "Refund" marking on the statement in OA -> Flow.result = 3 (RESULT_REFUND)
5. Bank arranged fund return

Note: This operation only marks statement status, no securities account fund movement involved. Fund return is completed by the bank.

---

Reversal Time Reference

Operation	Expected Duration	Description
Task reversal (sufficient balance)	Seconds	SBA Procedure typically completes within seconds
Task reversal (insufficient balance)	Hours~days	Depends on user cooperation time to release funds
Flow refund	Instant	Only marks status, takes effect immediately
BST REFUNDED	Minutes	System auto-handles, but operations needs follow-up
Bank-side fund return	1~5 working days	Depends on bank processing speed and transfer type

---

Common Misconceptions

Misconception	Reality
"Reversal and refund are the same thing"	They're not. Task reversal deducts from the securities account (moves real money); flow refund only marks statement status (doesn't touch the securities account). Confusing them causes fund discrepancies
"Reversal can be retried after failure"	Can be retried, but investigate failure cause first (usually insufficient balance). Blindly retrying won't change the result
"Partial amount reversal is possible"	Not possible. The system only supports full reversal — either reverse all or reverse nothing. There's no "reverse 30,000 out of 50,000 HKD" operation
"Flow refund automatically returns funds to bank"	It doesn't. Flow refund is only an internal system marking; fund return requires separate bank-side handling
"All banks have the REFUNDED mechanism"	They don't. REFUNDED is a status exclusive to Airstar BST; CMB and MSB BST have no refund mechanism
"User can no longer see original deposit record after reversal"	They can. Reversal doesn't delete records, only changes status to "reversed" (5). Users can see this record and its reversal status in the App

---

After Reading

I want to...	Go to
See how operations handles reversals	Reversal/Refund Guide
Troubleshoot reversal failure issues	Deposit Troubleshooting - Reversal Failure
Check reversal-related status codes and APIs	Deposit Quick Reference - Reversal Reference Data
Modify reversal process	Deposit Change Guide - Modify Reversal Process
Understand deposit's complete lifecycle	Deposit Methods Overview
Understand post-matching reversal path	Matching & Auto-Credit - Post-Match Path

Was this page helpful?