Deposit Quick Reference
About This Page
What: All deposit-related reference data — status codes, limits, tolerances, processing times, field definitions. This page is the single source of truth; other pages reference rather than duplicate Audience: Product managers and operations staff who need to look up specific numbers/codes Prerequisites: None, consult anytime Reading time: Reference type, search as needed Owner: Deposit Product Manager
Quick Navigation — What you might want to do:
- Look up a status code meaning? -> Deposit Status Codes
- Look up a bank's matching tolerance? -> Matching Tolerance Rules
- Look up a bank's TransType code? -> Bank Channel Type Codes (TransType)
- Look up timeout before auto-rejection? -> Timeout and Auto-Rejection Configuration
- Look up deposit type (DepositType)? -> Deposit Type
- Look up database sharding rules? -> Database Sharding Strategy
Deposit Status Codes
Apply Status
| Status Code | Meaning | Description |
|---|---|---|
| 0 | Pending | User has submitted, waiting for bank statement arrival and matching |
| 1 | Processing | Matched/debit confirmed, SBA crediting in progress |
| 2 | Completed | Deposit successful, funds have reached securities account |
| 3 | Rejected | Timeout rejection or operations rejection |
| 4 | Withdrawn | User cancelled proactively |
| 5 | Reversed | Credited funds have been withdrawn |
Flow Status
| Status Code | Meaning | Description |
|---|---|---|
| 0 | Pending | Bank statement just arrived, waiting for matching |
| 1 | Processed | Matched and deposit completed |
| 2 | Error | Processing failed, manual intervention required |
| 3 | Locked | Operations locked for investigation |
| 4 | In-transit | Funds in transit, unconfirmed |
| 9 | Deleted | Marked as invalid |
Match Result Codes
| Result Code | Meaning | Next Step |
|---|---|---|
| 0 | No match | Skip, wait for next round |
| 1 | Assisted match | Written to match table, awaiting operations confirmation |
| 2 | Full match | Enters auto-credit decision |
Currency & Auto-Credit Limits
| Currency | Code | Single Auto-Credit Limit | Daily Auto Count Limit |
|---|---|---|---|
| HKD (Hong Kong Dollar) | 1 | 2,000,000 | 10 per user |
| USD (US Dollar) | 2 | 300,000 | 10 per user |
| CNH (Offshore RMB) | 3 | 2,000,000 | 10 per user |
| JPY (Japanese Yen) | 4 | 40,000,000 | 10 per user |
| SGD (Singapore Dollar) | 5 | 350,000 | 10 per user |
Boundary Note: Limits are assessed per transaction (not cumulative), using closed intervals (<=), meaning amounts exactly equal to the limit can still be auto-credited. Exceeding the limit doesn't fail — it just cannot be auto-credited and requires operations manual confirmation. The daily 10-transaction limit is calculated per calendar day (00:00~24:00 HKT), regardless of trading days.
Why These Limits?
| Currency | Limit | Design Rationale |
|---|---|---|
| HKD 2 million | Covers 99%+ of normal deposits. Deposits exceeding 2 million are extremely rare, and the larger the amount, the greater the risk and impact of mismatching | |
| USD 300K | Approximately equal to HKD 2 million (at ~6.5 exchange rate), maintaining equivalent limits across currencies | |
| CNH 2 million | Set equal to HKD | |
| JPY 40 million | Approximately equal to HKD 2 million (at ~0.05 exchange rate) | |
| SGD 350K | Approximately equal to HKD 2 million (at ~5.7 exchange rate) | |
| Daily 10 transactions | Normal users rarely deposit more than 3 times a day. 10 provides ample margin while preventing abnormal batch deposits |
If Change Needed: Modify Auto-Credit Limits
Code location: deposit/src/app/Business/Match/MatchBase.php (approximately lines 38-44)
MAX_AUTO_DEPOSIT_AMOUNT_HKD = 2000000
MAX_AUTO_DEPOSIT_AMOUNT_USD = 300000
MAX_AUTO_DEPOSIT_AMOUNT_CNH = 2000000
MAX_AUTO_DEPOSIT_AMOUNT_JPY = 40000000
MAX_AUTO_DEPOSIT_AMOUNT_SGD = 350000
MAX_AUTO_DEPOSIT_COUNT = 10 // Daily per-user limitCommon change scenarios:
- Raise/lower a currency's limit -> Modify the corresponding constant value. Note: this affects auto-credit decisions for all banks
- Adjust daily count limit -> Modify
MAX_AUTO_DEPOSIT_COUNT - Use different limits for a specific bank -> Need to override the limit check logic in that bank's Match class (currently all banks share the same limits)
Matching Tolerance Rules
Standard Tolerance
Formula: Apply.amount - tolerance <= Flow.amount <= Apply.amount (statement amount can be at most "tolerance" less than application, closed interval)
| Scenario | Currency | Tolerance |
|---|---|---|
| Local transfer | HKD / CNH / JPY | 0 ~ 20 |
| Local transfer | USD / SGD | 0 ~ 3 |
| Cross-region/Cross-bank | HKD / CNH / JPY | 0 ~ 420 |
| Cross-region/Cross-bank | USD / SGD | 0 ~ 60 |
Boundary Note: When the difference is exactly equal to the tolerance value, it still counts as a match. Example: HKD local tolerance 20: application 50,000, statement 49,980 -> match successful. Cross-region tolerance is larger because intermediary bank fees are unpredictable.
Bank-Specific Tolerances
Different banks have their own tolerance standards. "Auto-credit tolerance" is used for fully automatic crediting decisions; "assisted match tolerance" is used to generate candidate match pairs for manual confirmation — the latter is more lenient.
| Bank | Currency | Auto-Credit Tolerance | Assisted Match Tolerance |
|---|---|---|---|
| BOCHK | HKD | 0~20 | 0~20 |
| BOCHK | USD | 0~3 | 0~3 |
| HSBC | HKD | 0~65 | 0~420 |
| HSBC | USD | 0~14 | 0~60 |
| ICBC Asia | HKD | 0~20 | 0~20 |
| ICBC Asia | USD | 0~55 | 0~55 |
| DBS | HKD | 0~350 | 0~350 |
| DBS | USD | 0~50 | 0~50 |
| EWB | HKD | — | 0~420 |
| EWB | USD | — | 0~60 |
| EWB Sub-account | All currencies | 0~40 | 0~100 |
| ZA Sub-account | HKD | 0~350 | 0~350 |
| ZA Sub-account | USD | 0~50 | 0~50 |
| Singapore ICBC | HKD | 0~500 | 0~500 |
| Singapore ICBC | USD | 0~70 | 0~70 |
Matching Time Windows
| Statement Type | Matching Window | Applicable Banks/Scenarios |
|---|---|---|
| Standard statement | Statement date -3 days ~ +2 days | Most banks' regular statements |
| BOCHK statement | Statement date -3 days ~ +4 days | BOCHK B2E (greater statement delay) |
| Real-time statement | Statement arrival time ~ +2 days | MT910, BST and other real-time pushes |
| Real-time FPS | Statement arrival time -1 hour ~ +2 days | FPS (allows statement slightly earlier than application) |
| Non-real-time statement | Statement date -3 days ~ +2 days | Batch-imported historical statements |
Boundary Note: "Days" in time windows are calculated as calendar days (not trading days). "-3 days" means
application date - 3 x 24 hours, precise to the second. "Statement date" uses arrival timestamp (precise to the second) for real-time statements, and transaction date (precise to day, using 00:00:00) for batch statements.
Why Different Statement Types Use Different Windows?
| Window | Design Rationale |
|---|---|
| Standard -3/+2 days | User may apply first then transfer (apply up to 3 days early), or transfer first then apply (apply up to 2 days late). Covers the vast majority of normal operation sequences |
| BOCHK +4 days | B2E pulls only 3 times daily + 2-hour format conversion; statements may enter the system 1~2 days after the transaction, hence an additional 2-day extension |
| FPS -1 hour | FPS arrives in seconds, but user may transfer first then apply (bank statement arrives seconds to tens of seconds before application). -1 hour covers this "transfer before apply" scenario |
| Real-time +2 days | Real-time statements are precise to the second, using more precise time comparison rather than day-level comparison, reducing mismatching risk for same-amount same-user multiple deposits |
Timeout and Auto-Rejection Configuration
After application timeout, the system automatically handles in two phases: first notification (reminder to upload proof), then rejection. Days are calculated in HKEX trading days.
| Bank | Deposit Method | Notification Days | Rejection Days (after notification) |
|---|---|---|---|
| ICBC/Hang Seng/BOCHK | FPS | 1 | 1 |
| ICBC/Hang Seng/BOCHK | Online banking same-bank | 1 | 1 |
| ICBC/Hang Seng/BOCHK | Online banking cross-bank (HKD) | 2 | 1 |
| ICBC/Hang Seng/BOCHK | Online banking cross-bank (USD/CNH) | 4 | 1 |
| ICBC/Hang Seng/BOCHK | ATM | 2 | 1 |
| ICBC/Hang Seng/BOCHK | Cheque | 2 | 1 |
| HSBC | Online banking same-bank | 1 | 1 |
| HSBC | Online banking cross-bank | 4 | 1 |
| EWB | All methods | 4 | 1 |
| ZA Sub-account | All methods | No notification | 10 |
Proof supplement timeout: If proof supplement required and not provided within 20 trading days -> Auto-rejection. If proof provided but no statement within 10 trading days -> Auto-rejection.
Boundary Note: "Days" in the timeout table are calculated in HKEX trading days (excluding weekends and Hong Kong public holidays). Proof supplement timeout is calculated in trading days. The two standards differ — deposit timeout uses trading days because banks only process transfers on trading days.
If Change Needed: Adjust Timeout Rejection Days
Code location: deposit/src/app/Business/AutoNoticeReject.php (approximately lines 371-424)
Timeout notification and rejection days are configured by bank and deposit method through the getConfig() method, returning a structure of:
[
'notice_day' => notification days, // Trading days after application creation to send notification
'reject_day' => rejection days, // Trading days after notification sent to auto-reject
]Common change scenarios:
- Adjust notification days for a specific bank/method -> Modify the
notice_dayvalue in the corresponding branch ofgetConfig() - Adjust proof supplement timeout -> Search for
supplementrelated constants (current: not provided=20 days, provided but no statement=10 days) - Add timeout configuration for a new bank -> Add a new conditional branch in
getConfig() - Disable auto-notification for a bank (like ZA sub-account mode) -> Set
notice_daytonullor a special marker
Notes:
- Days are calculated in HKEX trading days (excluding weekends and public holidays); trading calendar maintained in
deposit/config/directory - Modifying notification days affects the timing of push messages sent to users
- After rejection, the system automatically sends a rejection notification to the user (rejection reason code=9 timeout)
Auto-Processing Hours
| Method | Operating Hours | Suspension Period |
|---|---|---|
| BST Bank-Securities | Monday 08:00 ~ Friday 16:00 | — |
| eDDA (HSBC/Hang Seng) | Monday 07:00 ~ Saturday 10:00 | — |
| Airstar BST | Working day business hours | — |
| FPS | Similar to BST | — |
| Matching engine | 7x24 (every 3 minutes) | Auto-credit subject to above hour restrictions |
Daily 16:00~16:10 is the account reconciliation suspension period; all auto-deposit processing is paused.
Auto-Credit Processing Hours (by Currency)
Different currencies have different auto-credit start times — USD starts 2 hours later than other currencies to avoid USD settlement period interference:
| Currency | Start Time | End Time | Saturday | Description |
|---|---|---|---|---|
| HKD | 07:00 | Next day 04:00 | Closes at 09:55 | Covers full HK stock trading day |
| USD | 09:01 | Next day 04:00 | Closes at 09:55 | Later than HKD, avoids USD settlement interference |
| CNH | 07:00 | Next day 04:00 | Closes at 09:55 | Same as HKD |
| JPY | 07:00 | Next day 04:00 | Closes at 09:55 | Same as HKD |
| SGD | 07:00 | Next day 04:00 | Closes at 09:55 | Same as HKD |
Statements outside processing hours are still matched by the matching engine but won't trigger auto-credit — downgraded to assisted match awaiting operations confirmation.
Configuration location: deposit/src/app/Business/DepositConfigNew.php (USD special start time approximately line 440, Saturday close approximately line 498)
2412 Suspension Windows (applies to all auto-credits):
| Suspension Period | Reason | Impact Scope |
|---|---|---|
| 08:55 ~ 09:00 | Pre-market reconciliation | All auto-credits suspended |
| 16:05 ~ 16:10 | Post-market reconciliation | All auto-credits suspended |
Configuration location: deposit/src/app/Business/DepositConfigNew.php:603-641
eDDA Bank Maintenance Windows:
| Bank | Maintenance Period | Impact |
|---|---|---|
| Hang Seng | Sunday 00:00 ~ 08:30 | Does not accept eDDI requests |
| HSBC | Sunday 00:00 ~ 12:00 | Does not accept eDDI requests |
eDDI instructions submitted during maintenance windows enter Blank status and auto-activate in the next working period. See eDDA Direct Debit Deposit - Processing Hours & Maintenance Windows.
Processing Time Reference
| Method | Fastest | Typical | Slowest |
|---|---|---|---|
| eDDA | Minutes | ~5 minutes | Hours (bank-side delay) |
| BST Bank-Securities | ~10 minutes | ~10 minutes | Next trading day (non-business hours) |
| Airstar BST | ~10 minutes | ~10 minutes | Next trading day |
| FPS | 3 minutes | 3~5 minutes | Next matching cycle |
| Online banking same-bank | 2 hours | 2 hours | Same day |
| Online banking cross-bank | 2 days | 2~3 days | 4 days (foreign currency) |
| ATM/Counter | 2 hours | 2 hours | Next trading day 11:00 |
| Bill payment | 2 hours | 2 hours | Next trading day |
| Cheque | 2 days | 2~3 days | 3 days |
| Overseas remittance | 3 days | 5 days | 5+ days |
Bank Statement Arrival Times
Complete comparison of each bank's statement collection method, protocol, arrival time and collection service -> Bank Statement Collection - Summary Comparison Table
Rejection Reason Codes
| Code | Meaning | Typical Scenario |
|---|---|---|
| 1 | Unclear information | Proof/information is illegible |
| 2 | Online banking information missing | Online banking transfer missing required information |
| 3 | ATM information missing | ATM proof missing required information |
| 4 | Bank account information missing | Missing bank account information |
| 5 | Securities account abnormal | User's account status has issues |
| 6 | Transaction cancelled | Bank cancelled the transaction |
| 7 | Application merged | Multiple applications processed together |
| 8 | Duplicate application | System detected duplicate deposit |
| 9 | Timeout | Funds not received for extended period |
| 10 | Other (HK region) | Hong Kong region other reasons |
| 11 | Other (Mainland) | Mainland region other reasons |
| 12 | Other (Overseas) | Overseas region other reasons |
| 14 | Account mismatch | Transferor doesn't match applicant |
| 15 | Insufficient transfer information | Transfer proof information incomplete |
Deposit Method Codes
| Code | Key | Name | Mode |
|---|---|---|---|
| 1 | bst | BST Bank-Securities Transfer | Direct |
| 2 | atm | ATM/Counter | Push |
| 3 | fps | FPS | Push |
| 4 | bp | Bill Payment | Push |
| 5 | ebank | Online Banking Transfer | Push |
| 6 | check | Cheque | Push |
| 7 | subAccount | Overseas Remittance | Push |
| 8 | edda | eDDA Hang Seng | Pull |
| 9 | eddaHSBC | eDDA HSBC | Pull |
| 10 | bstAsb | Airstar BST | Direct |
Deposit Type
| Code | Type | Description |
|---|---|---|
| 1 | NORMAL | Standard flow — auto-credit after statement matching |
| 2 | PRE_APPROVAL | Pre-approval — used for online account opening scenarios |
| 3 | ABNORMAL | Abnormal mode — manually created by operations in the statement system |
| 4 | TRANS_AUTO | Auto-approval — auto-approved after frontend precise matching |
| 5 | HIGH_RISK | High risk — hit risk control rules, requires manual review |
| 11 | NORMAL_HOLD | Hold mode — freeze first then credit |
| 21 | STOCK_HOLD | Stock DCA hold mode — eDDI deposit then freeze, reserved for stock DCA deduction |
| 31 | FUND_PURCHASE_HOLD | Fund purchase hold mode — eDDI deposit then freeze, reserved for fund purchase |
HOLD Type Note: Codes 11/21/31 are collectively called HOLD types (
HOLD_LIST = [11, 21, 31]). Deposits of these types have funds frozen by the system after crediting, reserved for corresponding investment operations. Freeze release timing is controlled by the investment-side system, not under the deposit system's jurisdiction.Configuration location:
deposit/src/app/Common/EddiDepositType.php
Notification Types
| Code | Type | Trigger Scenario |
|---|---|---|
| 1 | Standard deposit notification | Deposit completed |
| 2 | Online account opening card binding notification | Online account opening first deposit card binding success |
| 3 | Post-card-binding deposit notification | Online account opening post-card-binding deposit completed |
| 4 | Mainland pre-account-opening notification | Mainland pre-account-opening deposit credited |
Core Field Descriptions
Apply Key Fields
| Field | Business Meaning |
|---|---|
uid | User ID (moomoo number), determines which shard table the application is stored in |
amount | User's applied deposit amount |
real_amount | Actual credited amount, may be less than applied amount due to fees |
currency | Currency: HKD / USD / CNH |
deposit_method | Deposit method code (see table above) |
status | Application status (0~5, see table above) |
export_bank_id | Paying bank ID (user side) |
import_bank_id | Receiving bank ID (company side) |
bank_card_number | User's bank account number, used by matching engine for card number comparison |
area | Paying bank region: HK / CN / OS |
notice_type | Notification type (1~4, see table above) |
deal_type | Processing method: bst (bank-securities) / eddi (eDDA/eDDI direct debit) / auto (script automatic) / manual (manual) |
supplement_status | Proof supplement status: 0=not required / 1=pending supplement / 2=supplemented |
reject_reason | Rejection reason (see rejection reason code table) |
expected_time | Expected completion time |
founder | Creator ID, 0=user-initiated, >0=operations-created |
Flow Key Fields
| Field | Business Meaning |
|---|---|
trans_type | Bank/transaction type code, determines which shard table the statement is stored in |
amount | Actual credited amount |
currency | Currency |
en_name | Remitter English name, used by matching engine for name comparison |
cn_name | Remitter Chinese name |
customer_account | Remitter bank account number, used by matching engine for card number comparison |
date | Arrival date (YYYYMMDD), used by matching engine for date comparison |
type | Transfer type (counter/online banking/FPS etc.) |
status | Statement processing status (0~9, see table above) |
uid | Matched user ID, initially 0 |
apply_id | Matched application ID, initially 0 |
abnormal | Abnormal flag: 0=normal / 1=abnormal statement |
Match Key Fields
| Field | Business Meaning |
|---|---|
flow_id | Associated statement ID |
apply_id | Associated application ID |
uid | User ID |
status | Match status: 0=pending confirmation / 1=confirmed / 2=ignored |
The match table is a temporary table — after match confirmation or crediting completion, records are cleaned up to maintain table size.
Database Sharding Strategy
Core tables in the deposit system are sharded by the following rules:
| Table | Sharding Rule | Shard Key | Example |
|---|---|---|---|
applys | uid % 100 | User ID | applys_42 = users whose uid ends in 42 |
flows | {trans_type}_{YYYYMM} | Bank type + month | flows_218_202604 = April 2026 HSBC statements |
tasks | (id / 1000) % 100 | Task ID | tasks_05 |
setup_eddis | Not sharded | — | Full storage |
hsbc_eddis / hs_eddis | Not sharded | — | Full storage |
matches | Not sharded (temporary table) | — | Periodically cleaned after matching completion |
Configuration Location
- Apply sharding logic:
deposit/src/app/Business/Apply.php—table()method - Flow sharding logic:
deposit/src/app/Business/Flow.php:80—CREATE_WHEN_TABLE_NOT_FOUNDconfiguration
Scheduled Task Quick Reference
All deposit-related Cron tasks summary:
Matching Related
| Task Name | Frequency | Bank | Related Page |
|---|---|---|---|
match:ccbasia | Every 3 minutes | CCB Asia | Matching Engine |
match:ewb | Every 3 minutes | EWB | Matching Engine |
match:boc | Every 3 minutes | BOCHK | Matching Engine |
match:hangseng | Every 3 minutes | Hang Seng | Matching Engine |
match:hsbc | Every 3 minutes | HSBC | Matching Engine |
match:main icbc-new | Every 3 minutes | ICBC | Matching Engine |
match:main za-sub-account | Every 3 minutes | ZA | Matching Engine |
Monitoring Related
| Task Name | Frequency | Responsibility | Related Page |
|---|---|---|---|
monitor:flow-monitor | Every 30 minutes | Statement backlog alert | Deposit Troubleshooting |
abnormal-deposit:search | Every 30 minutes | Orphan statement scanning | Deposit Troubleshooting |
abnormal-deposit:update-status | Every 3 minutes | Abnormal deposit status update | Deposit Troubleshooting |
Reconciliation Related
| Task Name | Frequency | Responsibility | Related Page |
|---|---|---|---|
bank_reconciliation:generate | 16:15 daily | Daily reconciliation report | — |
bank_reconciliation:generate --date=yesterday USD | 09:05 daily | Previous day USD reconciliation | — |
crmbos_reconciliation:generate | Hourly | CRM-BOS inter-system reconciliation | — |
Configuration Location
All Cron definitions: deposit/doc/crontab.sh
Bank Channel Type Codes (TransType)
| Code | Bank | Type |
|---|---|---|
| 101 | MSB BST | BST |
| 102 | CMB BST | BST |
| 201 | Hang Seng Bank | Direct |
| 202 | ICBC Asia | Direct |
| 204 | MSB | Direct |
| 205 | CMB | Direct |
| 203 | Bank of Communications BANKCOMM | Direct |
| 206 | CCB Asia | Direct |
| 207 | VELO Bank | Direct |
| 208 | DBS | Direct |
| 209 | ANZ Bank | Direct |
| 217 | EWB Sub-account | Direct |
| 218 | HSBC MT910 | Direct |
| 219 | SCB Sub-account | Direct |
| 220 | Singapore ICBC Sub-account SGICBC_SUBACC | Direct |
| 221 | ZA Bank | Direct |
| 301 | BOCHK B2E | Direct |
| 302 | Hang Seng eDDA/eDDI (deposit direct debit) | eDDA |
| 303 | HSBC eDDA/eDDI (deposit direct debit) | eDDA |
| 304 | Airstar BST | BST |
| 401 | DWOLLA | US stock Dwolla deposit |
| 501 | US_IPO | US stock IPO fund return |
| 502 | INC_FT_TRANS | INC Futu fund inter-transfer |
Note: eDDA (authorization) and eDDI (debit instruction) are both deposit protocols, not involving withdrawals. Hang Seng/HSBC withdrawal channels use corporate online banking transfers.
Refund & Reversal Reference Data
Reversal Related Status Codes
| Data Object | Field | Reversal-Related Value | Meaning |
|---|---|---|---|
| Apply | status | 5 | Reversed — credited funds have been withdrawn |
| Task | status | REVERSE | Task has been reversed |
| Flow | result | 3 (RESULT_REFUND) | Statement marked as refund (does not affect securities account) |
Reversal API Endpoints
| API | Method | Purpose | Permission |
|---|---|---|---|
/deposit/reverse | POST | Single deposit task reversal | CASH_IN_TASK_REVERSE |
/deposit/batch (action=reverse) | POST | Batch deposit task reversal | CASH_IN_TASK_REVERSE |
/flow/refund | POST | Single statement refund marking | CASH_IN_FLOW_HANDLE |
/flow/refund-batch | POST | Batch statement refund marking | CASH_IN_FLOW_HANDLE |
/flow/unlock (is_refund=1) | POST | Unlock statement and mark refund | CASH_IN_FLOW_HANDLE |
Reversal Preconditions Quick Reference
| Operation | Precondition Status | Permission | Other Requirements |
|---|---|---|---|
| Task reversal | Apply.status = 2 (completed) | CASH_IN_TASK_REVERSE | Securities account balance >= reversal amount |
| Flow refund | Flow.status = 0 (pending) | CASH_IN_FLOW_HANDLE | None |
| Unlock refund | Flow.status = 3 (locked) | CASH_IN_FLOW_HANDLE | None |
Reversal-Related Code Locations
- Task reversal entry:
deposit/src/app/Business/Deposit.php:877-935—reverse() - SBA reverse orchestration:
deposit/src/app/Business/SOA/SBA/Deposit.php:309—turnAround('CashDepositReverse') - Reversal middleware:
deposit/src/app/Business/Tasks/Deposit.php:276-287—reverseMiddleware() - Flow refund:
deposit/src/app/Business/BankFlow.php:674-724—refund() - Unlock refund:
deposit/src/app/Business/BankFlow.php:1639-1695—unlock() - Apply status constant:
deposit/src/app/Business/Apply.php—STATUS_REVERSE = 5 - Task status constant:
deposit/src/app/Classes/Task/Status.php—REVERSE = 5 - Flow result constant:
deposit/src/app/Business/BankFlow.php—RESULT_REFUND = 3
Complete refund mechanism description -> Refund & Reversal Operations procedure -> Reversal/Refund Guide
After Reading
| I want to... | Go to |
|---|---|
| Understand a rule's business meaning | Matching & Auto-Credit |
| See eDDA authorization/debit error codes | eDDA Direct Debit Deposit |
| Troubleshoot deposit issues by symptom | Deposit Troubleshooting |
| Push deposit parameter changes | Deposit Change Guide |
| Look up more terms and abbreviations | Glossary |
| Understand refund and reversal mechanisms | Refund & Reversal |