Bank Card & Authorization
About This Page
What: Bank card lifecycle (statuses & verification), data model core fields, currency & account type bitmaps, card-channel capability matrix, card binding/unbinding rules & system flows, BST authorization model (CMB/Minsheng vs Airstar Mandate), eDDA authorization flow & extension fields, online account opening 3-in-1 flow, bank card API overview, and common exception scenarios with troubleshooting guide Audience: Product managers and Operations staff who need to understand bank card management business rules Prerequisites: Getting Started GuideReading time: 12 minutes Owner: Deposit Product Manager
Bank Card Lifecycle
Card Status
| Status Code | Name | Meaning | Typical Scenario | Operations Notes |
|---|---|---|---|---|
| 0 | Pending Approval | Card added but not yet active; cannot be used for deposits or withdrawals | Card added during online account opening, awaiting first deposit verification | If stuck for >24 hours, check whether the user completed the first deposit |
| 1 | Active | Card is functioning normally | Successful standard card binding; or activated after completing first deposit during online account opening | Normal state; usable for all deposit and withdrawal operations |
| 2 | Deleted | Card deactivated/deleted, irreversible | User unbinds or Operations deletes | Terminal state. User must re-bind the card; BST/eDDA authorizations are voided simultaneously |
Card Verification
Verification confirms the identity of the bank card holder — it is independent of "status." An active card can be unverified.
| Verification Code | Meaning | Trigger Scenario | Impact on Deposits/Withdrawals |
|---|---|---|---|
| 0 | Unverified | Default state | Deposits unaffected; first withdrawal to this card will be blocked |
| 1 | Verification in Progress | Credentials submitted, awaiting review | Deposits unaffected; withdrawal waits for verification to complete |
| 2 | Verified | Verification passed | No restrictions |
Verification Sources & Trigger Conditions:
| Source | Code | Trigger Scenario | Verification Method | User Action Required? |
|---|---|---|---|---|
| HK Online Account Opening Deposit | hk_online | User deposits via online account opening | Auto-verified upon successful deposit | No (automatic) |
| First Withdrawal | withdraw | User's first withdrawal to this card | Must upload bank statement/transfer screenshot | Yes |
| BST Binding | bst | BST Authorization/Mandate completed | Identity verified by bank; auto-verified | No (automatic) |
| eDDA Binding | edda | eDDA authorization completed | Identity verified by bank; auto-verified | No (automatic) |
| Manual Verification | manual | Operations approves manually in CRM | Operations reviews credentials and marks verified | No (Operations action) |
Verification Flow (First Withdrawal Scenario)
The first withdrawal to an unverified card is the most common verification trigger:
Lifecycle State Transitions
"Pending Approval" cards from online account opening: Created via the CheckSave API (operation=1 account opening in progress / operation=0 deposit in progress). Only after the first deposit succeeds does the system call TakeEffect to transition the card from Pending Approval to Active.
Storage Location & Database Tables
Bank card data is stored in the web_account database, managed by bankcard_service/ (PHP, port 20005).
| Table | Contents | Key Fields | Notes |
|---|---|---|---|
bank_card | Bank card master records | id, uid, number, status, verify, account_type | One row = one bank card |
bank_card_operation_log | Operation logs | card_id, operation, operator, created_at | Every bind/unbind/status change is logged; cannot be deleted |
bank_card_certificate | Verification credentials | card_id, file_url, status | Bank statements/transfer screenshots uploaded by users |
bank_info | Preset bank information | id, bank_name, bank_code, swift_code | Bank name/code/SWIFT/logo etc. (read-only) |
bank_card_asb_bst | Airstar BST extension | card_id, mandate_id, status | Airstar Mandate authorization information |
bank_card_edda | eDDA extension (Hang Seng) | card_id, limit_amount, status | Hang Seng eDDA authorization information |
bank_card_hsbc_edda | eDDA extension (HSBC) | card_id, mandate_identification, status | HSBC eDDA authorization information |
Operations troubleshooting tip: When investigating deposit/withdrawal issues, first check the card's status and verification (verify) in the bank_card table, then look up the corresponding extension table based on the channel type.
Bank Card Data Model
Core Fields
| Field | Business Meaning | Example | Common Operations Use |
|---|---|---|---|
id | Card unique ID | 12345 | Primary key for CRM bank card queries |
uid | User ID (moomoo ID) | 800001234 | Links to the user |
number | Bank account number | 012-345-678-901 | Match bank statements, verify card numbers |
bank_id | Preset bank ID (0 = custom bank) | 23 | bank_id > 0 uses preset info; = 0 requires manual entry |
bank_code | Internal bank code | CMBHK | Internal routing for deposit/withdrawal channels |
bank_swift | SWIFT code (required for HK cards) | CMBCHKHH | Required for international transfers |
area | Card region | hk / cn / us / other | Different regions have different required fields |
currency_type | Currency bitmap (see below) | 7 | Determines which currencies the card supports for deposits/withdrawals |
account_type | Account type bitmap (see below) | 2 | Determines which deposit/withdrawal channels the card supports |
status | Card status: 0/1/2 | 1 | 0=Pending Approval, 1=Active, 2=Deleted |
verify | Verification status: 0/1/2 | 2 | 0=Unverified, 1=Verification in Progress, 2=Verified |
third_party_flag | Third-party card flag | 0 | 0=Own card, 1=Third-party card (additional withdrawal restrictions) |
address_status | Address status | 0 | 0=Normal, 1=Abnormal (may affect withdrawals) |
Required Fields by Region
| Region | area Value | Required Fields | Optional Fields | Typical Banks |
|---|---|---|---|---|
| Hong Kong | hk | bank_swift, bank_name | bank_address | HSBC, Hang Seng, BOC, CMB(HK), Minsheng |
| Mainland China | cn | opening_address (branch address) | bank_province, bank_city | CMB, ICBC, CCB |
| United States | us | routing_number | bank_address | Bank of America, Chase |
| Other | other | bank_name | bank_swift, bank_address | Singapore, UK, and other overseas banks |
Currency Bitmap (currency_type)
The system uses a bitmap to represent which currencies a card supports — each bit represents one currency:
| Bit | Value | Currency | Description |
|---|---|---|---|
| 0 | 1 | HKD (Hong Kong Dollar) | HK stock trading, HKD deposits/withdrawals |
| 1 | 2 | USD (US Dollar) | US stock trading, USD deposits/withdrawals |
| 2 | 4 | CNH (Offshore RMB) | A-share connect trading, RMB deposits/withdrawals |
Combination examples:
| currency_type | Binary | Supported Currencies | Common For |
|---|---|---|---|
| 1 | 001 | HKD only | Single-currency HKD cards |
| 3 | 011 | HKD + USD | Dual-currency cards |
| 7 | 111 | HKD + USD + CNH | Most common — majority of Hong Kong bank cards |
Operations tip: If a user reports "cannot deposit/withdraw in a certain currency," first check whether the bank card's currency_type includes the corresponding currency bit. For example, currency_type = 3 does not support CNH deposits/withdrawals.
Account Type Bitmap (account_type)
Also uses a bitmap to represent which transfer capabilities the card supports:
| Bit | Value | Type | Meaning | How to Obtain |
|---|---|---|---|---|
| 0 | 1 | Regular | Standard bank card; supports manual transfer methods such as online banking/FPS | Automatically assigned at card binding |
| 1 | 2 | BST | BST channel bound (CMB/Minsheng/Airstar) | Automatically added by the system after BST Authorization is completed |
| 2 | 4 | eDDA | Direct Debit (eDDA) authorized (Hang Seng/HSBC) | Automatically added by the system after eDDA authorization is completed |
Combination examples:
| account_type | Binary | Meaning | Available Channels |
|---|---|---|---|
| 1 | 001 | Regular only | Online banking deposit, online banking/FPS withdrawal |
| 3 | 011 | Regular + BST | Above + BST deposit/withdrawal |
| 5 | 101 | Regular + eDDA | Above + Direct Debit (eDDA) deposit |
| 7 | 111 | Full capability | All deposit/withdrawal channels |
Account Type Is Set Automatically
account_type is not user-selected — it is set automatically by the binding/authorization flow. When a user completes BST Authorization, the card's account_type automatically gains the BST bit (|= 2); when eDDA authorization is completed, it gains the eDDA bit (|= 4). When unbound, the corresponding bit is cleared (&= ~2 or &= ~4).
Operations quick reference (no bitwise math needed):
- Values containing the BST bit: 2, 3, 6, 7 → BST channel available
- Values containing the eDDA bit: 4, 5, 6, 7 → Direct Debit (eDDA) available
- Regular only (no BST): 1, 5 → No BST channel
- Regular only (no eDDA): 1, 2, 3 → No Direct Debit (eDDA)
Operations troubleshooting: When a user reports "BST/eDDA deposit option not visible," check whether the account_type value is in the lists above.
Transfer Methods (methods)
Each card carries a list of transfer methods indicating available deposit/withdrawal channels:
| method Value | Type | Meaning | Corresponding Bank | Corresponding account_type Bit |
|---|---|---|---|---|
normal | Regular | Standard transfer (online banking/FPS/ATM, etc.) | All banks | bit 0 (Regular) |
bst_cmbhk | BST | CMB BST | China Merchants Bank (Hong Kong) | bit 1 (BST) |
bst_cmbchk | BST | Minsheng BST | Minsheng Bank | bit 1 (BST) |
bst_asb | BST | Airstar BST | Airstar Bank | bit 1 (BST) |
edda_hase | eDDA | Hang Seng Direct Debit (eDDA) | Hang Seng Bank | bit 2 (eDDA) |
edda_hsbc | eDDA | HSBC Direct Debit (eDDA) | HSBC | bit 2 (eDDA) |
Card-Channel Capability Matrix
The bank card's account_type determines which deposit/withdrawal channels are available:
| Account Type | Online Banking Deposit | BST Deposit | eDDA Deposit | BST Withdrawal | Online Banking Withdrawal | FPS Withdrawal |
|---|---|---|---|---|---|---|
| Regular (1) | ✓ | — | — | — | ✓ | ✓ |
| BST (2) | ✓ | ✓ | — | ✓ | ✓ | ✓ |
| eDDA (4) | ✓ | — | ✓ | — | ✓ | ✓ |
| BST + eDDA (6) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
Channel Filtering Logic
Users can bind multiple cards of different types. When initiating a deposit or withdrawal, the system filters available deposit methods or withdrawal channels based on the selected card's account_type and methods list.
App display rules:
- User selects a Regular card → App only shows "Online Banking Deposit"; BST/eDDA options are hidden
- User selects a BST card → App shows both "Online Banking Deposit" and "BST Deposit" options
- User selects an eDDA card → App shows both "Online Banking Deposit" and "eDDA Deposit" options
Withdrawal display rules follow the same logic: the card's account_type determines which withdrawal channel buttons are shown.
Card Binding / Unbinding Rules
Binding Rules
| Rule | Description | Behavior When Violated |
|---|---|---|
| HK cards must have SWIFT | bank_swift is required when binding a Hong Kong bank card (except "Other Bank") | Card binding API returns a parameter validation error |
| Mainland cards must have branch address | opening_address is required when area = cn | Same as above |
| US cards must have routing number | routing_number is required when area = us | Same as above |
| Card number uniqueness | The same uid + number combination cannot be bound twice | Prompt: "This card is already bound" |
| Preset banks take priority | When bank_id > 0, preset bank information (name/code/SWIFT) is used; when bank_id = 0, manual entry is required | Custom banks require users to confirm information accuracy themselves |
| Online account opening cards | Created via CheckSave, status = 0 (Pending Approval); transitions to status = 1 after first deposit succeeds | Cannot be used for deposits/withdrawals while pending |
| Deleted cards can be re-bound | For the same uid + number, if the old card has status=2, a new binding record can be created | The new card is a fresh record (new id); BST/eDDA authorizations from the old card are not inherited |
Card Binding System Flow
Unbinding Rules
| Scenario | Steps | Prerequisites | Operations Notes |
|---|---|---|---|
| Regular card unbinding | Set status = 2 | No in-progress deposits/withdrawals | Confirm no pending Procedures |
| BST card unbinding | 1. Cancel BST Authorization (CancelBst) → 2. account_type &= ~2 → 3. Set status = 2 | CMB/Minsheng require bank-side authorization cancellation; Airstar requires Mandate cancellation | BST Authorization voided; BST channel becomes unavailable. Complete any outstanding withdrawals first |
| eDDA card unbinding | 1. Cancel eDDA authorization → 2. account_type &= ~4 → 3. Set status = 2 | Hang Seng/HSBC eDDA authorization must be invalidated first | Direct Debit (eDDA) channel becomes unavailable |
| BST + eDDA card unbinding | Cancel both authorizations separately as above, then delete the card | Both authorizations must be invalidated first | All channel authorizations voided |
Unbinding Is Irreversible
status = 2 is a terminal state — deleted cards cannot be recovered; the user must re-bind the card. Unbinding BST/eDDA means the corresponding BST Authorization or Direct Debit authorization is also voided.
Common user question: "I accidentally unbound my bank card — what do I do?" — The only option is to re-bind the card. For BST cards, the user also needs to go through the BST Authorization flow again. For eDDA cards, the user needs to complete eDDA authorization again.
Operations note: Before unbinding, always check whether the card has any in-progress deposit/withdrawal Procedures. When there is an in-progress withdrawal (especially in pending(transfer_manual) status), do not unbind — wait for the withdrawal to complete before proceeding.
BST Authorization & Bank Cards
In the BST channel, bank card management and BST authorization (Mandate) are tightly coupled — a user cannot bind a card without authorization, nor authorize without binding a card.
Authorization Model Differences
| Dimension | CMB / Minsheng | Airstar |
|---|---|---|
| Core Identifier | Bank card number | mandate_id |
| Binding Flow | Bank-side BST Authorization completed → notifies moomoo | moomoo initiates Mandate authorization → bank confirms |
| Authorization Initiator | Bank-side only | moomoo can initiate |
| Unbinding Impact | Canceling authorization = BST unavailable | Canceling Mandate = BST unavailable |
| Multi-market | Each market requires separate authorization (HK/US/HKCC) | Single authorization auto-maps to 3 markets (HK/US/HKCC) |
| Communication | SM2 Socket bidirectional link (real-time push) | REST API (requires polling for results) |
| Authorization States | 2 states (Active/Inactive) | 6 states (including WAITING, FAIL, CANCEL) |
| Auto-verification | Successful authorization → card auto-verified (verify=2) | Successful authorization → card auto-verified (verify=2) |
CMB/Minsheng BST Authorization Flow
CMB and Minsheng BST Authorization is initiated on the bank side; moomoo passively receives it:
CMB vs Minsheng differences:
| Dimension | CMB | Minsheng |
|---|---|---|
| Service name | cmb_stock_trans | ms_stock_bank_transaction |
| Market granularity | Each market authorized separately (HK/US/HKCC each require individual setup) | Each market authorized separately |
| Withdrawal payee | Chinese name | English name (payee_name must be in English) |
| Transaction reference field | bank_tx_seq | OrgRefNo |
| Error recovery | sync_bst_data_helper compensation | Auto-reconnect + re-pull |
Airstar Mandate Deep Dive
Airstar uses mandate_id rather than the bank card number as the core identifier for the BST relationship. This means:
- Deposits: Linked to the corresponding bank card and user via mandate_id
- Withdrawals: Authorization validity is confirmed via mandate_id before sending withdrawal instructions
- Queries: All BST-related status queries use mandate_id as the primary key
3-market auto-mapping: After a user completes a single Mandate authorization, the system automatically creates BST bindings for HK (Hong Kong stocks), US (US stocks), and HKCC (Stock Connect) markets. When the user trades HK stocks, US stocks, or A-shares on moomoo, deposits and withdrawals all go through the same BST channel.
Airstar Authorization Flow (User Perspective)
| Step | User Action | User Experience | Expected Duration |
|---|---|---|---|
| 1 | Select Airstar bank deposit in moomoo | BST deposit option displayed | — |
| 2 | Tap "Authorize" | Redirected to Airstar authorization page | — |
| 3 | Confirm authorization on Airstar page | Enter bank password/verification code | 1–2 minutes |
| 4 | Authorization complete, return to moomoo | "Authorization Successful" displayed | Seconds |
| 5 | Ready to deposit/withdraw | BST channel available | — |
Airstar Authorization Flow (System Perspective)
Airstar BST Card Extension Fields (BankCardAsbBst)
| Field | Meaning | Operations Use |
|---|---|---|
account_name | Customer name | Verify cardholder identity |
account_number | Customer bank account number | Verify bank account number |
mandate_id | BST authorization ID | Core identifier — primary key for querying BST status and troubleshooting |
status | Authorization status (see table below) | Determine whether BST channel is available |
reject_code | Authorization rejection code | Investigate authorization failure reasons |
created_at | Authorization creation time | Confirm authorization timeline |
updated_at | Last updated time | Confirm status change time |
Mandate Status Codes:
| Status Code | Meaning | Can Deposit/Withdraw? | Operations Notes |
|---|---|---|---|
| 0 | Unauthorized (CLOSE) | No | Initial state or canceled. User must re-initiate authorization |
| 1 | Processing (PROCESSING) | No | Awaiting bank confirmation; typically completes in seconds to minutes. If still PROCESSING after 5 minutes → check airstar_service logs |
| 2 | Authorized (OPEN) | Yes | Normal state; BST channel available |
| 3 | Waiting (WAITING) | No | Online account opening only — awaiting first deposit. Automatically transitions to OPEN(2) upon successful deposit |
| 4 | Authorization Failed (FAIL) | No | Check reject_code for failure reason. Common causes: bank-side Risk Control block, user information mismatch |
| 5 | Authorization Canceled (CANCEL) | No | User or Operations canceled. User can re-initiate authorization |
Only status=2 (OPEN) allows deposits/withdrawals — this is the first step when Operations investigates "BST not working."
For the detailed Mandate state machine → Internal BST Overview § BST Authorization
eDDA Authorization & Bank Cards
For the deposit-focused view of eDDA authorization (how authorization enables Direct Debit deposits) → Card Binding & Deposit Authorization § eDDA
eDDA Authorization Flow
The eDDA authorization flows for Hang Seng and HSBC are similar with minor differences:
eDDA Card Extension Fields
Hang Seng and HSBC eDDA authorization information is bound to the bank card:
| Field | Meaning | Hang Seng | HSBC | Operations Use |
|---|---|---|---|---|
limit_amount | Per-transaction/period limit cap | Yes | Yes | Check whether limit was exceeded when a user reports "Direct Debit failed" |
limit_periodicity | Limit period | Yes | Yes | Y=Year / H=Half-year / Q=Quarter / M=Month / P=Per-transaction |
expiry_date | Expiration date | Yes | Yes | 9999999=Permanent; check for expiration |
status | Enabled status | 0=Disabled / 2=Enabled | 0=Disabled / 1=Authorizing / 2=Enabled | status=2 required for Direct Debit |
mandate_identification | Bank-side unique identifier | N/A | Yes | Used when cross-referencing with HSBC |
Hang Seng vs HSBC eDDA differences:
| Dimension | Hang Seng | HSBC |
|---|---|---|
| Service name | sba_hase_eddi | sba_hsbc_eddi |
| Authorization confirmation | Synchronous (seconds) | Asynchronous SFTP report (T+0 to T+1) |
| Status values | 2 states (0/2) | 3 states (0/1/2 — includes "Authorizing") |
| Report download | Not required | Requires hsbc_edda_report service to periodically fetch |
| Limit modification | Requires re-authorization | Requires re-authorization |
eDDA Is for Deposits Only
eDDA/eDDI is a Direct Debit channel that can only be used for deposits (debiting from the user's bank account into the Securities Account). Withdrawals do not use eDDA — Hang Seng/HSBC withdrawals go through the corporate online banking channel (hase / hsbc), where Operations completes the manual transfer via the bank's online banking portal.
Bank Card API Overview
Core APIs exposed by the bank card service — corresponding to CRM and App operations:
App-Facing APIs
| API | Trigger Scenario | Effect | Notes |
|---|---|---|---|
AddBankCard | User adds a bank card in App | Creates bank_card record, status=1 | Includes parameter validation (SWIFT/address/uniqueness) |
GetBankCardList | User views bank card list | Returns all cards with status≠2 | Includes methods list for frontend to display available channels |
DeleteBankCard | User unbinds a bank card | status → 2 (Deleted) | First checks for no in-progress deposits/withdrawals |
CheckSave | Card added during online account opening flow | Creates bank_card record, status=0 (Pending Approval) | operation=1 account opening in progress / operation=0 deposit in progress |
TakeEffect | First deposit succeeds during online account opening | status 0→1 (Pending Approval → Active) | Called automatically by the deposit service |
CRM-Facing APIs
| API | Operations Action | Effect | Use Case |
|---|---|---|---|
GetBankCardInfo | View bank card details | Returns all card fields + extension info | Get complete card information during troubleshooting |
UpdateBankCard | Modify bank card information | Updates specified fields | Correct erroneous SWIFT/address, etc. |
ManualVerify | Manually approve verification | verify → 2 | Operations marks as verified after reviewing credentials |
UpdateThirdPartyFlag | Modify third-party card flag | third_party_flag updated | Correct misidentification |
BatchTakeEffect | Batch-activate Pending Approval cards | Multiple cards status 0→1 | Online account opening batch processing |
Bank Card Exception Scenarios
| # | Scenario | Symptom | Possible Cause | Troubleshooting Steps | Operations Action |
|---|---|---|---|---|---|
| 1 | BST not working | User reports BST deposit/withdrawal unavailable | Mandate is not in OPEN status | 1. Check bank_card_asb_bst.status = 2 (OPEN) 2. Check account_type is 2/3/6/7 (contains BST bit) | Not OPEN → guide user to re-authorize |
| 2 | eDDA Direct Debit failed | Error prompt during deposit | eDDA not enabled or limit exceeded | 1. Check eDDA status = 2 2. Check limit_amount for limit breach 3. Check expiry_date for expiration | Not enabled → re-authorize; limit exceeded → wait for limit reset or increase limit |
| 3 | Channel not showing after binding | BST/eDDA options not displayed in App after card binding | account_type not set correctly | 1. Check account_type value: BST needs 2/3/6/7, eDDA needs 4/5/6/7 2. Check methods list | Missing account_type → check whether authorization flow completed |
| 4 | Online account opening card unusable | Pending Approval card cannot deposit/withdraw | First deposit not completed | 1. Check status = 0 2. Check whether first deposit succeeded 3. Check whether TakeEffect was executed | Deposit succeeded but card not activated → manual BatchTakeEffect |
| 5 | Verification failure blocking withdrawal | First withdrawal to unverified card blocked | Card unverified (verify=0) | 1. Check verify field 2. Check for pending credential review | Guide user to upload bank statement; or Operations uses ManualVerify |
| 6 | Third-party card restrictions | third_party_flag=1 card has withdrawal restrictions | System identified as non-owner card | 1. Check third_party_flag 2. Confirm whether it is actually a third-party card | Misidentified → correct with UpdateThirdPartyFlag |
| 7 | Missing SWIFT causing withdrawal failure | Bank error during withdrawal | HK card bound without SWIFT (legacy data) | 1. Check whether bank_swift is empty | Operations uses UpdateBankCard to add SWIFT |
| 8 | Currency not supported | User's selected currency cannot be deposited/withdrawn | currency_type does not include the corresponding currency | 1. Check currency_type bitmap | Guide user to bind a bank card that supports the currency |
Online Account Opening
For the deposit-focused view of online account opening (including user journey and exception handling) → Card Binding & Deposit Authorization § Airstar Online Account Opening 3-in-1
Airstar 3-in-1 Flow
Airstar Bank supports online account opening — new customers can complete the entire zero-to-trading flow within the moomoo App:
| Step | Action | Description | System Operations | Data Changes |
|---|---|---|---|---|
| 1 | Open Securities Account | Complete KYC identity verification | Account system creates trading account | — |
| 2 | Mandate Authorization | Authorize Airstar for BST | CreateAuth → bank confirms | BankCardAsbBst.status = 3 (WAITING) bank_card.status = 0 (Pending Approval) |
| 3 | First Deposit | Complete first deposit into Securities Account | Deposit succeeds → TakeEffect | bank_card.status 0→1 (Active) BankCardAsbBst.status 3→2 (OPEN) |
Value: The traditional flow requires users to switch between multiple systems (moomoo for account opening → bank branch or online banking for authorization → back to moomoo for deposit). The 3-in-1 flow compresses these three steps into a seamless in-app experience, significantly reducing new customer drop-off rates.
Online Account Opening vs Standard Activation
| Dimension | Online Account Opening (New Users) | Standard Activation (Existing Airstar Account) |
|---|---|---|
| Prerequisites | No Airstar bank account needed | Must already have an Airstar bank account |
| Where | Entirely within moomoo App | Initiated in moomoo App; may require bank-side confirmation |
| Flow | Account opening → Authorization → First deposit, all in one | Authorization → Deposit, two steps |
| Initial card status | status = 0 (Pending Approval) | status = 1 (Active) |
| Initial Mandate status | status = 3 (WAITING) | status = 2 (OPEN) |
| Minimum deposit | Required (see table below) | No minimum |
| Acquisition value | High — lowers barriers for new customers | Medium — only for existing Airstar customers |
First Deposit Requirements
The first deposit for online account opening has a minimum amount requirement, higher than standard deposits:
| Currency | Online Account Opening Minimum | Standard Deposit Minimum | Behavior When Not Met |
|---|---|---|---|
| HKD | 10,000 | No minimum | App prompts "First deposit must be ≥ 10,000 HKD" |
| USD | 1,500 | No minimum | App prompts "First deposit must be ≥ 1,500 USD" |
| CNH | 10,000 | No minimum | App prompts "First deposit must be ≥ 10,000 CNH" |
The purpose is to ensure new customers have sufficient funds to trade, avoiding ineffective conversions where users "open accounts but never trade."
Online Account Opening User Journey
Online Account Opening Exception Handling
| # | Exception Scenario | Stuck At | Data State | Operations Action |
|---|---|---|---|---|
| 1 | Account opened but authorization failed | Mandate Authorization | bank_card.status=0, BankCardAsbBst.status=4(FAIL) | Guide user to re-initiate authorization (no need to re-open account) |
| 2 | Authorization succeeded but deposit failed | First Deposit | bank_card.status=0, BankCardAsbBst.status=3(WAITING) | Guide user to re-initiate deposit (must meet minimum amount) |
| 3 | Deposit succeeded but card not activated | TakeEffect | bank_card.status=0 (should be 1) | Manual BatchTakeEffect or investigate TakeEffect API |
| 4 | Stuck in Pending Approval for a long time | User did not complete deposit | bank_card.status=0, BankCardAsbBst.status=3 | Contact user to remind them to complete the first deposit |
Airstar Only
CMB and Minsheng do not support the online account opening 3-in-1 flow — BST Authorization must be completed on the bank side. Online account opening is an Airstar BST-exclusive acquisition feature, particularly well-suited for marketing campaigns (e.g., "Deposit and get commission-free trades").
For full limits → Withdrawal Rules Handbook § Three-Tier Limit System
After Reading
| I want to... | Go to |
|---|---|
| Learn about card binding & authorization from the deposit perspective | Card Binding & Deposit Authorization |
| Learn about BST Mandate state machine | Internal BST Overview |
| Learn about SBA orchestration model | SBA Fund Orchestration |
| See overall architecture and data flow | System Architecture & Data Flow |
| Look up bank card-related error codes | Unified Error Code Center |