Deposit Troubleshooting

About This Page

What: Common exceptions during deposit — organized by "what symptom the user/operations sees," with troubleshooting paths and handling methods Audience: Operations staff handling deposit issues, product managers who need to understand exception flows Prerequisites: Matching & Auto-CreditReading time: 7 minutes Owner: Deposit Operations Lead

Key Takeaways: Deposit exceptions are classified by symptom — statement not arrived, five-dimension mismatch, over-limit interception, and no corresponding application are the four most common categories, each with corresponding diagnostic paths and handling methods.

---

Quick Navigation — What you might want to do:

• User says "money hasn't arrived"? -> Quick Diagnosis Flowchart
• How to manually handle matching failure? -> Scenario 1 (with step-by-step Runbook)
• eDDA authorization/debit failed? -> Scenario 7 / Scenario 8
• Received system alert? -> Monitoring & Alerts (with statement backlog Runbook)
• Look up rejection reason code? -> Rejection Reason Codes
• Look up error code meaning? -> Quick Lookup by Error Code

Symptom -> Scenario Quick Lookup

Not sure which scenario to go to? Use this diagram:

---

Quick Lookup by Error Code

When encountering a specific error code, look it up directly in this table:

Error Code	Meaning	Jump To
MFISAC01	eDDA account number error	Scenario 7
MPP01006	eDDA phone number mismatch	Scenario 7
MPP01007	eDDA name mismatch	Scenario 7
MPP01008 / MPP02013	eDDA bank phone not registered	Scenario 7
MPP04000~04004	eDDA verification code issues	Scenario 7
MPP06001	eDDA account status abnormal	Scenario 7
ECH09001	eDDA general authorization failure	Scenario 7
BRC_8I1	Hang Seng eDDI insufficient balance	Scenario 8
BRC_8RZ	Hang Seng eDDI account abnormal	Scenario 8
BRC_8RW+FP2414	Hang Seng authorization not found	Scenario 8
BRC_8RW+FP2415	Hang Seng authorization not active	Scenario 8
BRC_8RW+FP2417	Hang Seng exceeded authorization limit	Scenario 8
MPP02020/MPP02023	HSBC authorization cancelled/non-existent	Scenario 8
MPP02021	HSBC payment account closed	Scenario 8
MPP02022/MPP05000	HSBC exceeded debit limit	Scenario 8
MPP02038/MPP02039	HSBC authorization dormant/expired	Scenario 8
Rejection codes 1~15	Deposit rejection reasons	Rejection Reason Codes
Apply.status=5	Deposit reversed	Scenario 5
DepositType=5	Risk control high risk	Scenario 9

Complete error codes -> Unified Error Code Center

---

Quick Diagnosis: User Says "Money Hasn't Arrived"

When receiving user feedback "I already transferred but the money hasn't arrived," troubleshoot in this order:

Most "money hasn't arrived" cases are because the bank statement hasn't reached the system yet — different banks have vastly different statement arrival times. BOCHK may be delayed by hours, EWB requires manual upload. Bank statement timing -> Deposit Quick Reference - Processing Time

Scenario Frequency Distribution

Frequency	Scenario	Estimated %	Meaning
High	Scenario 1 (matching failure), Scenario 2 (no application)	~70%	Encountered almost daily, operations must be most proficient
Medium	Scenario 3 (amount discrepancy), Scenario 4 (timeout), Scenario 7 (eDDA authorization), Scenario 8 (eDDA debit)	~25%	Several times per week, need to be familiar with troubleshooting paths
Low	Scenario 5 (reversal), Scenario 6 (duplicate), Scenario 9 (risk control)	~5%	Several times per month, but high impact, must strictly follow procedures

Recommendation: New operations staff should first master Scenario 1 and Scenario 2 handling procedures, covering 70% of daily tickets.

---

Scenario 1: Statement Arrived But Not Matched High Frequency

Symptom: Flow table has a statement record (status = 0 pending), Apply table has an application (status = 0 pending), but the matching engine didn't pair them.

Possible Causes and Handling:

Cause	Investigation	Handling
Amount difference exceeds tolerance	Compare Flow.amount and Apply.amount	Operations confirms the discrepancy reason, then manually matches in OA
Name mismatch	Compare Flow.en_name and user's registered name	May be English name format issue, operations confirms then manually matches
Currency mismatch	Compare Flow.currency and Apply.currency	User may have selected wrong currency, need to reject and resubmit
Outside date window	Compare Flow arrival date and Apply creation date	Application may be too early or too late, operations can manually match
Card number mismatch	Compare Flow.customer_account and Apply.bank_card_number	User may have transferred from a different card

Operations Action: In the OA backend matching list, find this statement and application, confirm the matching relationship, then manually create a deposit task.

Step-by-Step Runbook: Received "Matching Failed" Ticket

Minute 1 — Locate the problem

1. Search in OA statement list using the transfer amount and date provided by user
2. Search in OA application list using user UID

Minutes 2~5 — Compare dimension by dimension 3. Compare amount: Flow.amount vs Apply.amount, is the difference within tolerance? 4. Compare name: Flow.en_name vs user's registered English name, note name order 5. Compare currency: Flow.currency vs Apply.currency 6. Compare date: Is the statement arrival date within the application's matching window?

Minutes 5~10 — Execute handling 7. If matching pair found but skipped by system -> Click "Manual Match" in OA 8. If amount difference exceeds tolerance -> Confirm discrepancy reason (fees/wrong amount), modify application amount then re-match 9. If genuinely not matching -> Mark statement as "pending follow-up", contact user to confirm transfer details

Not resolved after 15 minutes -> Escalate to Deposit Product Manager

---

Scenario 2: User Transferred Money But Didn't Submit Application High Frequency

Symptom: Bank statement arrives in the system, but no corresponding deposit application can be found.

This is one of the most common exception scenarios — the user transferred money in their banking app but forgot or didn't know they need to submit a deposit application in the moomoo App.

System Handling: The AbnormalDepositJob scheduled task automatically detects such statements, attempts to identify the user through bank card number and name, then creates an abnormal deposit record.

Operations Action:

1. View in OA abnormal deposit list (permission: ABNORMAL_DEPOSIT_VIEW)
2. Confirm the user corresponding to the statement
3. Choose handling method:
   • Successful processing: Create application on behalf of user and credit the account
   • Hold: Wait for user to submit application themselves
   • Follow up: Contact user to confirm

Preventive Measures

From a product perspective, the way to reduce such exceptions is to guide users to submit an application in the App before transferring — many deposit pages automatically create an application before transfer.

Step-by-Step Runbook: Orphan Statement Found (Statement Without Application)

Minute 1 — Confirm statement information

1. View the statement in OA abnormal deposit list
2. Record: amount, currency, remitter name, bank card number

Minutes 2~5 — Identify user 3. Search by bank card number in bank card system -> Find corresponding user UID 4. If card number doesn't match -> Search by remitter name -> May find multiple users 5. If name also doesn't match -> Mark as "cannot identify"

Minutes 5~15 — Execute handling 6. Identified unique user -> Select "Successful Processing" in OA, create application on behalf of user and credit 7. Identified multiple candidate users -> Mark as "pending follow-up", contact user to confirm 8. Cannot identify -> Hold, wait for user to contact proactively or submit application themselves

Not resolved after 30 minutes -> Escalate to Deposit Product Manager

---

Scenario 3: Amount Inconsistency Medium Frequency

Symptom: User says "I transferred 50,000," but the statement shows 49,950.

Bank transfers may incur fees, especially for inter-bank and cross-border transfers. The matching engine has a tolerance mechanism to handle differences within a reasonable range.

Within tolerance range: Auto-match, Apply.real_amount records the actual credited amount (49,950), user sees "Deposit successful HKD 49,950."

Exceeds tolerance range: Matching engine returns assisted match or no match. Operations needs to confirm the discrepancy reason:

• Bank fees -> Confirm match, credit at actual arrived amount
• User transferred wrong amount -> Confirm with user then handle
• Operations can also modify the application amount in OA then re-match

Tolerance rules by currency and bank -> Deposit Quick Reference - Matching Tolerance

---

Scenario 4: Timeout Without Crediting Medium Frequency

Symptom: User submitted application, but bank statement hasn't arrived for a long time.

The system automatically handles timeout applications in two phases:

Phase 1: Auto-notification. After the application exceeds a certain number of days, the system sends a message reminding the user to upload transfer proof, helping operations confirm whether the transfer has been completed.

Phase 2: Auto-rejection. After notification is sent and another certain number of days pass without receiving a statement or proof, the system automatically rejects the application, notifying the user "Due to not receiving funds for an extended period, crediting cannot be processed. Please confirm with your bank whether a refund is needed."

Timeout days vary by bank and deposit method — FPS typically notifies within 1 day (since FPS should arrive in seconds), while overseas remittances may wait 10 days. Specific configuration -> Deposit Quick Reference - Timeout Configuration

Special case: Proof supplement required. ATM/counter transfers and similar methods may require users to upload proof. If proof is unclear or incomplete, operations will request supplementation. Over 20 trading days without supplementation -> Auto-rejection.

Timeout Days Calculated in Trading Days

All timeout calculations are based on the HKEX trading calendar, excluding weekends and Hong Kong public holidays.

---

Scenario 5: Reversal Needed (Withdrawing Credited Funds) Low Frequency

Symptom: Deposit has been completed (status=completed), but funds need to be returned.

Reversal is a low-frequency but high-impact operation. Possible triggers:

Cause	Description
Bank chargeback	Bank requests funds to be returned
Incorrect crediting	Discovered crediting error, such as matching to wrong user
Risk control interception	Risk control system detects anomaly after crediting
BST bank refund	Airstar Bank proactively refunds (REFUNDED status)

Reversal Troubleshooting Decision Tree

Step-by-Step Runbook: Reversal Failure Investigation

Minute 1 — Confirm current status

1. Find the target deposit application in OA, confirm Apply.status:
   • If = 2 (completed) -> Can be reversed
   • If = 1 (processing) -> Reversal not allowed, wait for completion
   • If = 5 (reversed) -> Already reversed, no repeat operation needed
2. Confirm the operator has CASH_IN_TASK_REVERSE permission

Minutes 2~5 — Investigate failure reason 3. Check SBA logs, confirm the CashDepositReverse Procedure execution status:

• PROCEDURE_STATUS_END_OK -> SBA considers it successful, check if Apply status has been updated
• Insufficient balance error -> Check user's securities account available balance and positions
• Service timeout/connection failure -> SBA service may be down

4. If insufficient balance:
   • Check user's current position occupation amount
   • Check if there are in-transit withdrawal tasks
   • Calculate available balance vs reversal amount difference

Minutes 5~10 — Recovery operations 5. Insufficient balance: Freeze account -> Notify user to release funds -> Reinitiate reversal after balance is sufficient 6. SBA error: Confirm service has recovered -> Reinitiate reversal 7. Status abnormal: Contact deposit development team to verify original deposit's SBA records, use manual compensation if necessary

Not recovered after 10 minutes -> Escalate to Deposit Technical Lead

Reversal Process:

1. Operations initiates reversal in OA (permission: CASH_IN_TASK_REVERSE)
2. System checks status — reversal not allowed for those currently processing
3. Execute reversal: SBA executes CashDepositReverse reverse Procedure
4. Update application and task status to "reversed" (Apply.status = 5)
5. If it was a card-binding deposit, synchronously unbind the bank card
6. Notify user that deposit has been withdrawn

After reversal, application status becomes 5 (reversed), funds are deducted from the securities account.

Flow Refund (different from task reversal): If the bank statement hasn't been matched and credited yet (Flow.status = 0), it can be directly marked as flow refund (Flow.result = 3), no securities account fund movement involved.

Complete comparison of three refund mechanisms -> Refund & Reversal Operations procedure -> Reversal/Refund Guide

---

Scenario 6: Duplicate Deposit Low Frequency

Symptom: Same user submitted multiple applications with same amount on the same day, or the same bank statement was processed twice.

System Deduplication Mechanisms:

Level	Mechanism	Description
Application level	Duplicate detection flag	Multiple applications from same user with same amount on same day are flagged
Statement level	Unique index	Bank transaction ID + bank type form a unique index, preventing duplicate import of the same statement
Reconciliation level	Duplicate scanning	Periodic reconciliation task scans statements with same amount/name/account/date, generating suspected duplicate reports

After operations receives a duplicate alert, they review to confirm which is real and which is duplicate, then reject the duplicate application (rejection reason code 8: duplicate application).

---

Scenario 7: eDDA Authorization Failed Medium Frequency

Symptom: User submitted eDDA authorization in the App, but it hasn't taken effect for a long time or directly failed.

Troubleshooting Path:

Common Error Codes and Handling:

Error Code	Meaning	Handling Suggestion
MFISAC01	Bank account number error	Guide user to verify bank account number and resubmit
MPP01006	Phone number doesn't match bank binding	Guide user to confirm bound phone number in banking app
MPP01007	Name doesn't match bank account	Verify if registered name matches bank account name
MPP01008 / MPP02013	Bank phone not registered	Guide user to contact bank to bind phone
MPP04000 / MPP04003 / MPP04004	Verification code issues	Guide user to re-obtain verification code
MPP06001	Bank account status abnormal	Guide user to contact bank about account status
ECH09001	General authorization failure	Reauthorize after confirming information is correct

Operations Action: View setup_eddis table in OA backend, confirm edda_status and error_code. If it's a correctable error (e.g., name mismatch), contact user to correct then reinitiate authorization.

Complete error code table -> eDDA Direct Debit Deposit - Authorization Failure Error Codes

---

Scenario 8: eDDA Debit Rejected Medium Frequency

Symptom: eDDA authorization is active, but bank rejects the debit request. Apply status becomes rejected.

Troubleshooting Path:

1. Confirm setup_eddis.edda_status = 2 (authorization active)
2. Check hsbc_eddis or hs_eddis table's reject_code / reject_message
3. Handle according to the table below

Hang Seng Common Rejection Codes:

Error Code	Meaning	Handling Suggestion
BRC_8I1	Insufficient balance	Remind user to top up and retry. Note: bank may charge a fee and cancel authorization
BRC_8RZ	Bank account abnormal	Guide user to contact Hang Seng Bank
BRC_8RW + FP2414	Authorization not found	Authorization may have been cancelled, guide user to reauthorize
BRC_8RW + FP2415	Authorization not active	Guide user to activate eDDA at Hang Seng Bank
BRC_8RW + FP2417	Exceeded authorization limit	Guide user to reduce amount or contact bank to adjust limit

HSBC Common Rejection Codes:

Error Code	Meaning	Handling Suggestion
MPP02020 / MPP02023	Authorization cancelled/non-existent	Guide user to reauthorize
MPP02021	Payment account closed	Guide user to contact HSBC
MPP02022 / MPP05000	Exceeded debit limit	Guide user to contact bank to adjust limit
MPP02038 / MPP02039	Authorization dormant/expired	Guide user to reauthorize

Special Note: When Hang Seng has insufficient balance (BRC_8I1), the bank may automatically cancel the eDDA authorization. After resolving the balance issue, the user may still need to complete reauthorization before depositing again.

Complete error codes -> eDDA Direct Debit Deposit - Hang Seng/HSBC Debit Rejection Error Codes

---

Scenario 9: Risk Control Interception Low Frequency

Symptom: Matching succeeded but not auto-credited, DepositType marked as HIGH_RISK(5).

Possible Causes:

Interception Type	Check Service	Trigger Condition	Handling
Blacklist hit	hk-deposit-blacklist-go	User/bank card/associated information is on the blacklist	Joint review with risk control team to decide whether to release
High-risk country	SWIFT code check	Remittance source country is on high-risk list	AML compliance review
Online account opening region restriction	Whitelist service	Online account opening + non-FPS + no HK region bank card	Confirm user identity then decide whether to release

Operations Action:

1. Filter deposit_type = 5 in OA deposit task list
2. View associated risk control check results
3. Discuss handling with risk control team: release for crediting or return funds
4. Blacklist supports setting expiration time — users under temporary risk observation are automatically released upon expiry

Risk Control Interception ≠ Deposit Failure

The HIGH_RISK flag only downgrades auto-crediting to manual review. After review approval, crediting can proceed normally.

Step-by-Step Runbook: Received Risk Control Intercepted Deposit

Minute 1 — Confirm interception information

1. Filter deposit_type = 5 (HIGH_RISK) in OA deposit task list
2. Record: user UID, deposit amount, currency, bank, interception reason

Minutes 2~5 — Categorize and handle 3. Blacklist hit -> Check hk-deposit-blacklist-go hit records

• Is it a temporary blacklist (has expiration time)? -> Wait for automatic release upon expiry
• Is it a permanent blacklist? -> Transfer to risk control team for decision

4. High-risk country hit -> Check SWIFT code, confirm remittance source country
   • Contact compliance team for AML (anti-money laundering) review
5. Online account opening region restriction -> Confirm user's account opening method and card binding situation
   • If user has a compliant HK region bank card -> May be system misjudgment, contact development to confirm
   • If genuinely doesn't meet conditions -> Inform user they need to bind an HK region bank card

Minutes 5~15 — Execute decision 6. Risk control/compliance team decides to release -> Manually approve deposit in OA, system auto-credits 7. Risk control/compliance team decides to return -> Follow refund process 8. Risk control/compliance team needs more time -> Deposit maintains HIGH_RISK status, inform user "under review"

Record: All risk control interception handling results must be recorded in OA to form an audit trail

No decision after 4 hours -> Escalate to Risk Control Team Lead

---

Scenario 10: ICBC Suspected Duplicate Statement Low Frequency

Symptom: Same deposit appears with two matching records, or user reports being double-credited.

Root Cause: ICBC has no unique transaction ID; statement deduplication relies on composite fields (amount+date+card number+remarks). When ICBC has T-1 late-arriving statements (arriving in the system the day after the transaction date), duplicates may form with statements that arrived on the same day.

Troubleshooting Path:

Step-by-Step Runbook: ICBC Duplicate Statement Investigation

Minute 1 — Confirm whether it's truly a duplicate

1. Search flows table by amount+date+card number: are there two nearly identical statements?
2. Compare created_at of the two statements: is one same-day arrival and one T-1 late?
3. Compare remarks field: are they exactly the same?

Minutes 2~5 — Assess impact 4. Check whether both statements have been successfully matched (check matches table) 5. If only one matched -> The other is an orphan statement, not a major issue 6. If both matched and credited to the same user -> User was double-credited

Minutes 5~10 — Handle 7. One matched, one unmatched: Execute flow refund marking on the unmatched duplicate (Flow.result=3) 8. Both credited: Reverse the extra deposit via task reversal process 9. Record the event, notify user (if already double-credited, reverse first then notify)

Not resolved after 15 minutes -> Escalate to Deposit Technical Lead

Prevention: If ICBC statement deduplication logic is adjusted, regression testing for T-1 scenarios is required

ICBC Special Characteristics

ICBC is the second largest deposit source (~12.3%), but has the most system limitations. See ICBC Known System Limitations.

---

Rejection Reason Codes

When an application is rejected, the system records a rejection reason code. Common reasons:

Code	Meaning	Typical Scenario
1	Unclear information	Information submitted by user is illegible
4	Bank account information missing	Required bank information is missing
5	Securities account abnormal	User's account status is abnormal
7	Application merged	Multiple applications processed together
8	Duplicate application	Duplicate deposit detected
9	Timeout	Funds not received for extended period
14	Account mismatch	Transferor doesn't match applicant

Complete 15 reason codes -> Deposit Quick Reference - Rejection Reason Codes

---

Operations Tool List

Tool	Purpose	Required Permission
Application list	View/filter all deposit applications	CASH_IN_APPLY_VIEW
Statement list	View/filter bank statements	CASH_IN_FLOW_VIEW
Task approval	Confirm matching, approve/reject deposits	CASH_IN_TASK_APPROVAL
Abnormal deposit	Handle statements with no application/incorrect info	ABNORMAL_DEPOSIT_MODIFY
Reversal	Withdraw completed deposits	CASH_IN_TASK_REVERSE
Modify application	Correct application info then re-match	CASH_IN_APPLY_MODIFY

---

Monitoring & Alerts

The system monitors deposit exceptions through the following scheduled tasks:

Task Name	Frequency	Monitoring Content	Alert Condition
monitor:flow-monitor	Every 30 minutes (07:00~23:00)	Pending statement backlog	Pending statement count exceeds threshold
abnormal-deposit:search	Every 30 minutes	Orphan statements without matches	Statements found with no corresponding application
abnormal-deposit:update-status	Every 3 minutes	Abnormal deposit status	Abnormal status transitions
monitor:job	Continuous	Job queue health	Job execution failure/backlog
monitor:large-amount	Every hour	Large amount deposits	Deposits exceeding preset amount threshold
monitor:frozen-task	Every hour	Frozen deposit tasks	Tasks frozen for extended period

Configuration Location

All monitoring task definitions: deposit/doc/crontab.sh

Alert Handling Priority:

1. Statement backlog alert: Most urgent — may indicate a bank's statement collection service failure, affecting all deposits from that bank. First check if the corresponding collection service is running normally.
2. Job execution failure: Check failed job's error logs, usually bank API timeout or abnormal response.
3. Large amount deposit alert: Notify risk control team for assessment, not urgent but needs timely handling.

Step-by-Step Runbook: Received Statement Backlog Alert

Minute 1 — Locate impact scope

1. Review alert content: Which bank's statements are backing up? How many are backed up?
2. Check the latest statement arrival time for that bank -> Determine if it's "new statements not coming in" or "came in but not processed"

Minutes 2~5 — Diagnose cause 3. If "new statements not coming in" -> Check the corresponding bank's collection service status (hsbc_bank_flow_service, bochk_flow_go, etc.) 4. If "came in but not processed" -> Check if match:{bank} Cron task is executing normally 5. Check service logs for errors (bank API timeout, authentication failure, etc.)

Minutes 5~10 — Attempt recovery 6. Collection service error -> Restart service, observe if statements start flowing in 7. Matching task error -> Check DB connection, manually trigger a matching task 8. Bank API error -> Record error information, notify bank relationship team

Not recovered after 15 minutes -> Escalate to Technical Operations on-call

If Change Needed: Modify Abnormal Deposit Detection Rules

Code location: deposit/src/app/Business/AbnormalDeposit.php + deposit/src/app/Jobs/AbnormalDepositJob.php

Abnormal deposit detection logic: AbnormalDepositJob scheduled task (every 30 minutes) scans the flows table for records with status=0 (pending) that have remained unmatched beyond a certain time, attempting to identify users through bank card number and name.

Common change scenarios:

• Adjust orphan statement detection time threshold -> Modify the time window parameter in AbnormalDepositJob (current: marked after X minutes of statement arrival without matching)
• Modify user identification rules -> Modify card number/name matching logic in AbnormalDeposit.php
• Adjust abnormal deposit status update frequency -> Modify the cron expression for abnormal-deposit:update-status in deposit/doc/crontab.sh (current: every 3 minutes)
• Modify statement backlog alert threshold -> Modify threshold parameters in monitor:flow-monitor task
• Add new monitoring dimensions (e.g., alert by bank separately) -> In monitor:flow-monitor or add a new independent monitoring task

Notes:

• Abnormal deposit records require ABNORMAL_DEPOSIT_MODIFY permission to handle in OA
• Setting detection time threshold too short increases false positives (statements still within normal matching window are marked as abnormal)
• Setting too long delays discovery of orphan statements, impacting user experience

Step-by-Step Runbook: Job Execution Failure

Minute 1 — Confirm failed job

1. Review alert content: Which job failed? How many times?
2. Check job queue status: Is it a single job failure or overall queue anomaly?

Minutes 2~5 — Categorize and diagnose 3. Matching related jobs (match:*) -> Check DB connection and query performance

• If DB slow queries -> May be large table data volume or index invalidation
• If DB connection timeout -> Check network and DB instance status

4. eDDA related jobs (EddiResultJob / EddiCreateJob) -> Check SBA service status
   • SBA timeout -> Usually a temporary issue, job framework will auto-retry
   • SBA returns error -> Check specific error code
5. Monitoring related jobs (monitor:*) -> Not urgent, but needs fixing to avoid alert loss
   • Check if monitoring target services are alive

Minutes 5~10 — Recovery 6. Single job failure -> Job framework usually auto-retries (max 3 times) 7. Queue anomaly -> Restart job worker process 8. DB issue -> Contact DBA to check instance status

Not recovered after 15 minutes -> Escalate to Technical Operations on-call

Escalation Decision Tree

When you're not sure who to escalate to, use this diagram:

Response Requirements & Escalation Paths

Scenario	Response Time	First-Line Handling	Escalation Target (when first-line cannot resolve)
Statement backlog alert	Within 15 minutes	Check if corresponding bank's collection service is alive	-> Technical Operations (service restart/investigation)
Matching failure (single)	Working hours within 1 hour	Verify statement and application info in OA backend, attempt manual matching	-> Deposit Product Manager (rule issues)
eDDA authorization failure	Working hours within 2 hours	Check error_code, guide user per error code table	-> Bank Relationship Team (bank-side issues)
eDDA debit rejected	Working hours within 2 hours	Check reject_code, guide user per error code table	-> Bank Relationship Team (bank-side issues)
Risk control interception	Working hours within 4 hours	View risk control check results	-> Risk Control Team (decide release or return)
Large amount deposit alert	Working hours within 4 hours	Notify risk control team for assessment	-> Risk Control Team + Compliance Team
User complaint "money hasn't arrived"	Working hours within 30 minutes	Troubleshoot per quick diagnosis flowchart	-> Deposit Product Manager (system issues) or Bank Relationship Team (bank issues)
Reversal request	Working hours within 2 hours	Confirm reversal reason, execute reversal operation	-> Deposit Product Manager + Settlement Team
Job execution failure	Within 30 minutes	Check failed job's error logs	-> Technical Operations (infrastructure issues) or corresponding bank service developer

Time Note: Working hours refers to HKT 09:00~18:00 Monday to Friday. Alerts during non-working hours are handled at the start of the next working day, but statement backlog alerts and job failures require 24x7 response.

---

Common Misconceptions

Misconception	Reality
"User says money hasn't arrived means system failure"	70% of cases are because bank statement hasn't reached the system, or user forgot to submit application. Follow the diagnosis flowchart first
"Alerts require immediate handling of all issues"	Prioritize: statement backlog > job failure > matching failure. Not all alerts are urgent
"Rejection means deposit failure"	Rejection only closes the current application. User can submit a new application
"User automatically gets refund after reversal"	Reversal only deducts funds from the securities account. Bank refund is a separate process requiring independent operation
"HIGH_RISK deposits definitely have problems"	Not necessarily. May be temporary risk observation or region restriction. Most are released after review

---

After Reading

I want to...	Go to
Bank card binding/authorization causing deposit exceptions	Card Binding & Deposit Authorization - Deposit-Related Bank Card Exceptions
Understand matching mechanism (to troubleshoot failure reasons)	Matching & Auto-Credit
Look up tolerance, timeout, reason code numbers	Deposit Quick Reference
See eDDA authorization/debit error codes	eDDA Direct Debit Deposit
See operations-side eDDA troubleshooting guide	eDDA Troubleshooting Guide
See bank statement arrival times	Bank Statement Collection
Check operations daily guide	Manual Matching Guide
Check all error codes and status codes	Unified Error Code Center
Understand refund and reversal complete mechanism	Refund & Reversal

Was this page helpful?