Reversal / Refund Guide

About this page

What: Operational procedures, prerequisites, and risk warnings for deposit reversals and withdrawal reversals Audience: Operations staff with reversal permissions Prerequisites: Deposit Troubleshooting, Withdrawal TroubleshootingReading time: 3 minutes Owner: Withdrawal Operations Lead

Key takeaway: A reversal is a reverse operation that claws back funds that have already been credited or remitted. It is high-risk and irreversible -- always confirm the bank-side status before proceeding to prevent fund-state inconsistency.

---

Reversal vs. Refund

Term	Direction	Meaning
Deposit Reversal	Securities Account -> User's bank	Credited funds are clawed back (e.g., bank chargeback, erroneous credit)
Withdrawal Reversal	User's bank -> Securities Account	Remitted funds are returned (e.g., bank return, erroneous withdrawal)
BST Refund (REFUNDED)	Bank returns funds after successful deposit	Unique to Airstar BST -- the bank initiates a post-facto refund

What they have in common: all three involve a reverse fund movement on a completed transaction -- high impact, no second undo.

---

Deposit Reversal

Runbook: Deposit Reversal

Trigger: Received bank chargeback / discovered erroneous credit / post-facto Risk Control interception Assessment: Confirm application status = Completed (2); account balance is sufficient Action: Follow the steps below to execute the reversal Verification: Go through the "Post-Reversal Verification Steps" item by item

Prerequisites

• Deposit application status must be 2 (Completed)
• Required permission: CASH_IN_TASK_REVERSE
• Applications still in processing (status 1) cannot be reversed

Steps

1. Locate the target deposit application in OA
   • CRM path: Deposit Funds -> Processed -> Find the corresponding deposit task -> Click "Reverse"
2. Confirm the reversal reason:
   • Bank refund (chargeback) -- The bank requests the funds be returned
   • Erroneous credit -- Matching error; funds were credited to the wrong user
   • Risk Control interception -- Risk Control detected an anomaly after the credit
3. Click "Reverse" to initiate the operation
4. The system executes:
   • Updates application status to 5 (Reversed)
   • SBA executes a reverse Procedure (claws back funds from the securities account)
   • If the deposit was made via card binding, the bank card is unlinked
   • Sends a notification to the user

Pre-Reversal Checklist

Before executing a reversal, confirm each of the following:

#	Check Item	CRM Field / How to Check	Pass Condition
1	Application status	Apply.status	= 2 (Completed); not in processing
2	Account available balance	Securities account query	>= reversal amount (user may have already used the funds for trading)
3	Any in-flight withdrawals	Withdrawal task list filtered by same UID	No in-progress withdrawal tasks (to avoid balance conflicts)
4	Any position occupancy	Position query	Confirm that the balance after reversal still covers position margin
5	Reversal reason confirmed	Operations judgment	A clear, traceable reversal reason (chargeback / erroneous credit / Risk Control)
6	Large-amount confirmation	Apply.amount	If over HKD 500K, consider freezing the account before proceeding

Post-Reversal Verification Steps

After the reversal is executed, confirm the following states have been correctly updated:

#	Verification Item	Expected Result
1	Application status	Apply.status = 5 (Reversed)
2	SBA Procedure	Reverse Procedure executed successfully (check SBA logs)
3	Securities account balance	Reversal amount has been deducted
4	Bank Card binding	If the deposit was via card binding, the bank card has been unlinked
5	User notification	Reversal notification sent (App push + message center)

Risk Warnings

Must confirm before reversal

• Does the user's securities account have sufficient balance? (If the user has already traded or withdrawn the deposited funds, the balance may be insufficient)
• The reversal operation is irreversible -- once executed, it cannot be undone
• For large amounts, consider freezing the account before proceeding

---

Withdrawal Reversal

Runbook: Withdrawal Reversal

Trigger: Bank returned the funds / discovered erroneous withdrawal / post-facto Risk Control interception Assessment: Confirm task status = Completed (4); funds have actually been remitted Action: Follow the steps below to execute the reversal Verification: Confirm task status = Reversed (5); SBA reverse operation succeeded

Prerequisites

• Withdrawal task status must be 4 (Completed)
• Funds have actually been remitted to the bank

Steps

1. Locate the target withdrawal task in OA
2. Confirm the reversal reason:
   • Bank return -- The bank returned the remitted funds
   • Erroneous withdrawal -- Withdrawal information was incorrect (e.g., wrong user)
   • Post-facto Risk Control interception -- Risk Control detected an anomaly after the withdrawal was completed
3. Initiate the reversal (action: REVERSE)
4. The system executes:
   • Updates task status to 5 (REVERSE)
   • SBA executes the reverse fund operation
   • Notifies the user that the withdrawal has been reversed

Bank Return Scenarios

A bank return is the most common trigger for withdrawal reversals. Possible reasons:

• Incorrect beneficiary account information (account number / name mismatch)
• Receiving bank refuses to credit
• Cross-border remittance returned by an intermediary bank

Upon receiving a bank return notification:

1. Confirm the returned funds have arrived in the company account
2. Execute the withdrawal reversal
3. Notify the user and guide them to re-initiate the withdrawal (if bank information needs correction)

---

BST Deposit Refund (REFUNDED)

Runbook: BST Refund

Trigger: Received Airstar API REFUNDED status alert Assessment: Confirm the refund reason (Airstar API error message) Action: Verify balance rollback -> Notify user -> Guide re-deposit Verification: Securities account balance has been correctly deducted; user has been notified

This is an anomaly status unique to Airstar BST -- CMB / CMBC do not have a refund mechanism.

Trigger Conditions

• Bank-side post-facto detection of a transaction anomaly (compliance issue) triggers a refund
• Bank Risk Control system post-facto interception

System Behavior

1. Receives the REFUNDED status from the Airstar API
2. System automatically triggers a reversal: claws back funds already credited to the securities account
3. Updates the deposit record status
4. Triggers an alert notifying Operations

Operations Action

1. Confirm the refund reason (check the error message returned by the Airstar API)
2. Verify that the user's securities account balance has been correctly rolled back
3. Notify the user and explain the reason
4. If a re-deposit is needed, guide the user to initiate a new deposit

REFUNDED vs. FAILED

• FAILED -- The bank rejected the deposit instruction; funds never arrived; no reversal needed
• REFUNDED -- The deposit succeeded but the bank later returned the funds; the system must execute a reversal; more complex

---

Reversal Operation Comparison

	Deposit Reversal	Withdrawal Reversal	BST Refund
Initiated by	Operations (manual)	Operations (manual) / Bank return	Bank (automatic)
Fund direction	Clawed back from securities account	Returned to securities account	Clawed back from securities account
Pre-condition status	Completed (2)	Completed (4)	Completed
Result status	Reversed (5)	Reversed (5)	REFUNDED
Banks involved	All	All	Airstar only
Permission	CASH_IN_TASK_REVERSE	--	System automatic

---

Bank Statement Refund Operation

A bank statement refund is different from a task reversal -- it only marks the bank statement status and does not affect the securities account balance. It is used when a bank statement has not yet been matched to a deposit.

Runbook: Bank Statement Refund

Trigger: Orphaned statement cannot be matched / bank confirms erroneous transfer / erroneous statement needs cleanup Assessment: Confirm Flow.status = 0 (Pending); confirm the statement should not be credited Action: Mark the statement as refunded in OA Verification: Flow.result = 3 (RESULT_REFUND)

Entry Points

Operation	OA Path	Applicable Scenario
Single refund	Statement list -> Select -> Refund	Mark a single statement as refunded
Batch refund	Statement list -> Batch select -> Batch refund	Month-end cleanup of multiple unmatchable statements
Unlock and refund	Statement list -> Locked statement -> Unlock and refund	Locked statements confirmed for refund after investigation

Post-Operation Verification

#	Verification Item	Expected Result
1	Statement disposition result	Flow.result = 3 (RESULT_REFUND)
2	Statement status	Flow.status = 1 (Processed)
3	Securities account balance	Unchanged (statement refund does not affect the securities account)

Statement refund != actual fund return

A statement refund is only an internal system marker -- the actual fund return on the bank side requires separate coordination with the bank. After marking the refund, notify the bank relationship team to arrange the actual refund.

---

Refund Management Module

Refund management is a business process independent of reversals, used to handle scenarios where funds need to be returned to the client (e.g., third-party transfer refunds, non-compliant deposit refunds, etc.).

Refund vs. Reversal

Dimension	Refund	Deposit Reversal
Initiated by	Customer Service / Client	Operations
Impact	Returns funds to the client's bank	Claws back credited funds
Process	Three-step review	Single-step operation
CRM module	Refund Management	Deposit Funds -> Processed

Three-Step Process

Step 1: Register Refund

Dimension	Description
Trigger	Customer Service receives a client refund request
Action	CRM -> Refund Management -> Refund List -> Register Refund
Content	Register the refund via bank statement records; link related deposit instructions; attach supporting refund documents
Verification	Refund record status changes to "Pending Review"

Step 2: Review Refund

Dimension	Description
Trigger	Pending review records appear in the refund list
Action	CRM -> Refund Management -> Refund List -> Review
Assessment	Review whether the refund materials are complete and compliant
Approved	Refund record status changes to "Pending Processing"
Not approved	Return to Customer Service; request supplementary materials or re-contact the client

Step 3: Process Refund

Dimension	Description
Trigger	Pending processing records appear in the refund list
Action	CRM -> Refund Management -> Refund Transfer -> Export refund transfer file
Execution	Operations staff manually processes the refund transfer (file-based)
Verification	After completion, mark the status as "Processed"; confirm the client's bank account received the refund

Refund transfer is file-based

Refund transfers are executed by exporting a file and uploading it to online banking (similar to normal withdrawals), not by automatic system transfer. The same dual-authorization process used for withdrawals must be followed.

Refund Operations Key Points

Key Point	Description
Refund differs from statement refund	Refund management involves actual fund return to the client; statement refund (reversal-guide section "Bank Statement Refund Operation") only marks the statement status and does not return funds
Refund SLA	From registration to the client receiving funds, it typically takes 3~5 business days (including review + bank processing time)
Cross-border refund	Cross-border transfer refunds may incur additional fees; inform the client in advance
Settlement date impact	Reversals and refunds affect T+1 settlement reports. Avoid initiating reversals/refunds after 16:00 on settlement days -- cross-settlement-day fund movements will change the day's settlement amount, requiring the settlement team to make manual adjustments

---

Reversal Failure Handling

Common Failure Causes and Resolution

Failure Cause	Symptom	Resolution	Estimated Recovery Time
Insufficient securities account balance	SBA returns insufficient balance error	Freeze account -> Contact user to release funds -> Retry	Hours to days
SBA service error	Procedure timeout or system error	Confirm SBA service status -> Retry after service recovery	Minutes to hours
Original Procedure status anomaly	PROCEDURE_STATUS_END_OK validation fails	Manually verify the original deposit SBA record -> Manual compensation	Requires developer assistance

Step-by-step Runbook: Reversal Failure Recovery

Minute 1 -- Confirm the failure

1. After clicking the reversal button, is Apply.status still 2 (not changed to 5)?
2. Check the error message returned by OA

Minutes 2~5 -- Identify the cause 3. Check SBA logs; search for the corresponding Task ID 4. Confirm the execution result of the CashDepositReverse Procedure 5. If insufficient balance: check the user's available balance and position occupancy

Minutes 5~15 -- Recovery actions 6. Insufficient balance:

• Freeze the user's account (prevent further trading / withdrawals)
• Contact the user to explain the situation
• After the user sells positions / withdrawal funds arrive, re-execute the reversal

7. SBA error:
   • Confirm SBA service has recovered
   • Re-click the reversal button
8. Procedure anomaly:
   • Do not retry repeatedly
   • Collect the information listed in the "Escalation Information Checklist" below
   • Escalate to the deposit development team

Over 15 minutes with no recovery -> Escalate to the on-call technical operations engineer

Information to Provide When Escalating to Development

When escalating a reversal failure to development, provide the following information all at once (to minimize back-and-forth):

#	Information	How to Obtain
1	Apply ID / Task ID	Top of the CRM deposit/withdrawal task detail page
2	SBA Task ID	Task detail page -> SBA records section
3	Procedure name and execution status	Search for the Task ID in SBA logs
4	Error message screenshot	The error page returned by the CRM reversal operation
5	User's current available balance	Securities account query page
6	Operation time (to the minute)	Alert time or operation time
7	Any in-flight withdrawals / position occupancy	Withdrawal task list + position query

Reversal SLA Reference

Operation	Normal Duration	Notes
Deposit reversal (sufficient balance)	Seconds	SBA Procedure typically completes in seconds
Deposit reversal (insufficient balance)	Hours to days	Depends on how quickly the user cooperates to release funds
Withdrawal reversal	Seconds	Funds returned to securities account
BST REFUNDED	Minutes	System auto-executes
Bank-side actual refund	1~5 business days	Depends on bank and transfer type

Batch Reversal

When multiple deposits need to be reversed (e.g., batch erroneous credits):

1. Filter target applications in the OA deposit list
2. Confirm each application meets the reversal prerequisites (check balance for each one)
3. Use the batch operation function (/deposit/batch with action=reverse)
4. Note: Batch reversal executes one by one -- if one fails (e.g., insufficient balance), it does not affect the others
5. After completion, confirm Apply.status = 5 for each application

---

If requirements change: Modifying the reversal flow

Code locations:

• Deposit reversal: deposit/src/app/Business/Deposit.php:877-935 (reverse() method)
• Withdrawal reversal: withdraw/src/app/Business/Tasks/Handler/Reverse.php
• SBA reverse Procedure: deposit/src/app/Business/SOA/SBA/Deposit.php:309 -- turnAround('CashDepositReverse')
• Reversal middleware: deposit/src/app/Business/Tasks/Deposit.php:276-287

Common change scenarios:

• Add an approval step before reversal -> Add an approval check before the reversal logic (currently reversals execute directly without secondary approval)
• Do not auto-unlink bank card after reversal -> Remove the unlinking logic in reverse()
• Add a reversal amount cap -> Add an amount check in the reversal prerequisites
• Modify reversal notification template -> Adjust the message template in the notification service

Detailed change guide -> Deposit Change Guide: Modifying the Reversal Flow Product perspective on refund mechanisms -> Refund and Reversal

After Reading

I want to...	Go to
Troubleshoot full deposit reversal scenarios	Deposit Troubleshooting
Troubleshoot withdrawal reversals and bank returns	Withdrawal Troubleshooting
Learn about Airstar REFUNDED technical details	BST Overview
Check freeze types and withdrawal rules	Withdrawal Rules Handbook
Look up status codes and error codes	Unified Error Code Center
Understand the product logic of the three refund mechanisms	Refund and Reversal
Look up reversal-related status codes and APIs	Deposit Reference: Refund and Reversal Data
Learn about CRM module operations	CRM Operations Guide
Learn about eDDA debit failure handling	eDDA Troubleshooting Guide

Was this page helpful?