Bank Cards and Withdrawal Authorization
About This Page
What: How bank card status and authentication affect withdrawals, how account_type determines available withdrawal channels, BST authorization prerequisites for withdrawal, first-time withdrawal authentication flow, channel routing and bank cards, withdrawal-related bank card exception troubleshooting Audience: Product managers and operations staff who need to understand "why a user cannot withdraw" Prerequisites: Withdrawal Methods OverviewReading time: 5 minutes Owner: Withdrawal Product Manager
Key Takeaway: Which withdrawal method a user can use depends on three dimensions of their bank card — status (whether the card is active), verify (whether it's been authenticated), and account_type (whether it has the BST bit). BST withdrawal additionally requires Mandate status to be OPEN. Understanding these three gates is the key to troubleshooting "user cannot withdraw".
Quick Navigation — what you might want to do:
- User can't see BST withdrawal option? → Withdrawal Channels and Card Type Relationship
- User's first withdrawal is blocked? → Card Authentication and First Withdrawal
- BST withdrawal unavailable? → BST Authorization and Withdrawal
- How does the system select a withdrawal channel? → Channel Routing and Bank Cards
- Withdrawal-related bank card issues? → Withdrawal-Related Bank Card Exceptions
Three Gates for Withdrawal
Before a user initiates a withdrawal, the system sequentially checks three dimensions of the bank card. If any one fails, withdrawal cannot proceed:
| Gate | Check Field | Pass Condition | Failure Behavior |
|---|---|---|---|
| 1. Card Status | status | = 1 (active) | "Bank card does not exist" or unable to select the card |
| 2. Card Authentication | verify | = 2 (authenticated) or not first withdrawal | "Bank account has not passed authentication", require uploading proof |
| 3. Channel Authorization | account_type + Mandate | BST channel requires BST bit + OPEN | BST option not displayed, or Confirm step blocks |
Deposit vs Withdrawal Bank Card Requirements
Deposit has more lenient bank card requirements — unauthenticated cards (verify=0) can deposit normally. Withdrawal has stricter requirements — first withdrawal to an unauthenticated card will be blocked, authentication must be completed first. This is because withdrawal involves funds leaving, and AML compliance requires confirming the receiving account belongs to the user.
Withdrawal Channels and Card Type Relationship
The bank card's account_type directly determines the user's available withdrawal channels:
| account_type | Meaning | Available Withdrawal Methods | Notes |
|---|---|---|---|
| 1 | Regular (only) | Online banking, FPS, CHATS, wire, etc. | Default state after card binding, no BST |
| 3 | Regular + BST | Above + BST withdrawal | Obtained after completing BST agreement |
| 5 | Regular + eDDA | Online banking, FPS, CHATS, wire, etc. | eDDA bit has no effect on withdrawal (eDDA is only for deposit) |
| 7 | Full capability | Same as account_type=3 | eDDA bit does not add withdrawal capability |
Key distinction: For deposits, every bit of account_type matters (Regular / BST / eDDA each enable different deposit channels). But for withdrawals, only the BST bit (bit 1) has practical impact — eDDA is a direct debit channel used only for deposits; withdrawals go through corporate online banking (hase / hsbc), unrelated to eDDA authorization.
Bank Card Requirements by Withdrawal Channel
| Channel | account_type Requirement | Additional Requirements | Notes |
|---|---|---|---|
auto_bs (BST) | Contains BST bit (2/3/6/7) | Mandate = OPEN | The only fully automated channel |
hsbc (HSBC online banking) | Regular is sufficient | None | Ops operates corporate online banking |
hase (Hang Seng online banking) | Regular is sufficient | None | Ops operates corporate online banking |
boc_fps (BOC FPS) | Regular is sufficient | None | Semi-auto |
cgb_fps_api (CGB FPS) | Regular is sufficient | None | Semi-auto |
sc (Standard Chartered) | Regular is sufficient | None | Semi-auto |
tele_transfer (Cross-border wire) | Regular is sufficient | bank_swift required | Non-HK banks auto-select this channel |
chats_rtgs | Regular is sufficient | None | HK large amounts (>= 1 million) |
boc (BOC same-bank) | Regular is sufficient | None | Manual operation |
manual (ICBC manual) | Regular is sufficient | None | Manual operation |
Operations Troubleshooting Points
When a user reports "cannot see BST withdrawal option", troubleshooting path:
- Check
bank_card.account_type— values containing BST bit: 2, 3, 6, 7 - Check Mandate status — must be OPEN(2)
- If
account_typedoes not contain BST bit → BST agreement not completed, guide user to complete agreement - If Mandate is not OPEN → refer to BST Authorization and Withdrawal
BST Authorization and Withdrawal
BST (Bank-Securities Transfer) is the only fully automated channel for withdrawals. The prerequisite for using BST withdrawal is that the BST authorization status is OPEN.
Mandate Status Impact on Withdrawal
| Mandate Status | Meaning | Can BST Withdraw | Ops Attention |
|---|---|---|---|
| 0 CLOSE | Not authorized | No | User needs to initiate authorization |
| 1 PROCESSING | Authorizing | No | Waiting for bank confirmation |
| 2 OPEN | Authorized | Yes | Normal state |
| 3 WAITING | Waiting for first deposit | No | Online account opening only, auto-transitions to OPEN after successful deposit |
| 4 FAIL | Authorization failed | No | Check reject_code |
| 5 CANCEL | Cancelled | No | User can re-initiate |
Only OPEN(2) allows BST withdrawal — this is the first step in troubleshooting "BST withdrawal unavailable".
Differences Across Three BST Banks for Withdrawal
| Dimension | CMB / CMBC | Airstar |
|---|---|---|
| Withdrawal instruction | Socket bidirectional link real-time push | REST API + two-phase polling |
| Arrival time | Seconds | Fast polling ~50 seconds + fallback sync up to 2 hours |
| CNH withdrawal | Does not use BST (protocol does not cover it, left for ops manual selection) | Supported (no restriction) |
| Bank-initiated withdrawal | Supported (user operates transfer-out in bank app) | Supported |
| Market granularity | Each market requires separate agreement | One authorization auto-binds 3 markets |
CNH Restriction: CMB/CMBC Do Not Use BST
This is an important boundary condition: CMB/CMBC + offshore RMB CNH = does not use BST.
Reason: CMB and CMBC BST interface protocols do not cover CNH currency automatic transfers. When the system detects this combination during channel routing, it sets method to null, leaving it for ops to manually select another channel (typically online banking or FPS).
Airstar is not subject to this restriction — Airstar's BST interface supports CNH.
Confirm Step Authorization Verification
The Confirm step of withdrawal approval mandatorily verifies BST authorization status:
Confirm step logic:
if method == auto_bs:
Check Mandate status
if status ≠ OPEN → Refuse to proceed, prompt "BST authorization status abnormal"
if status == OPEN → Pass, proceed to RemittanceIf Confirm is stuck with an authorization abnormality prompt → troubleshoot Mandate status, see Withdrawal Troubleshooting § BST Authorization Exception.
Complete BST authorization technical details → Bank Cards and Authorization § BST Authorization BST channel execution details → Channel Execution Manual § BST
Card Authentication and First Withdrawal
Bank card authentication (verify) is a gate unique to withdrawal — deposit does not check authentication status, but first withdrawal to an unauthenticated card will be blocked.
Authentication Status
| verify Value | Meaning | Impact on Withdrawal |
|---|---|---|
| 0 | Not authenticated | First withdrawal blocked, require uploading proof |
| 1 | Authenticating | Withdrawal waits for authentication to complete |
| 2 | Authenticated | No restriction |
Automatic Authentication (No User Action Needed)
The following scenarios will automatically mark a card as authenticated (verify=2), requiring no extra action from the user:
| Scenario | Source Code | Rationale |
|---|---|---|
| BST agreement successful | bst | Bank has verified identity |
| eDDA authorization successful | edda | Bank has verified identity |
| HK online account opening deposit successful | hk_online | Deposit transaction verified card ownership |
Practical implication: If a user first deposits through BST or eDDA, the card is automatically authenticated and withdrawal won't be blocked. Only when a user deposits through online banking/FPS/ATM and then tries to withdraw to that card for the first time will manual authentication be triggered.
First Withdrawal Authentication Flow
Why Authentication Is Required
AML compliance requires confirming the receiving account belongs to the user. Withdrawal means funds leaving a regulated securities account, so the compliance threshold is higher than for deposits.
Channel Routing and Bank Cards
The system automatically selects the withdrawal channel based on bank card attributes via calcMethod():
Routing decisions use the following bank card fields:
| Field | Role in Routing |
|---|---|
account_type | Determines if BST bit is present → decides whether BST channel is available |
bank_code | Determines if it's CMB/CMBC/Airstar → decides CNH restriction |
area | Determines if bank is in HK → non-HK banks use cross-border wire |
bank_swift | Required for cross-border wire, missing will cause withdrawal failure |
currency_type | Card must support the withdrawal currency, otherwise rejected |
How Ops Selects When method = null
When the system cannot automatically determine a channel, ops manually selects at the Confirm step, priority: Same-bank transfer > FPS > CHATS/RTGS > Cheque. See Withdrawal Methods Overview § Fall-through Logic When method = null.
Other Bank Card Restrictions
Beyond the three gates above, withdrawals have additional bank card-related restrictions:
| Restriction | Check Field | Behavior | Notes |
|---|---|---|---|
| Mainland China bank card | area = cn | "Withdrawal to mainland China bank accounts is not supported" | System directly blocks |
| A-share Connect CNH | Currency + bank region | "CNH can only be withdrawn to Hong Kong banks" | Only CNH + non-HK bank |
| Payoneer account | Bank type | "Payoneer accounts do not support withdrawal" | Business restriction |
| Third-party card | third_party_flag = 1 | Withdrawal subject to additional restrictions | Non-self-owned card requires extra review |
| Currency mismatch | currency_type bitmap | "Bank account currency does not match withdrawal currency" | e.g., card with currency_type=1 cannot withdraw USD |
| SWIFT missing | bank_swift is empty | Cross-border wire withdrawal fails | Historical data issue, ops supplements |
| Online account opening without deposit | status = 0 | "Card binding requires transfer >= HKD 10,000" | Pending review card cannot withdraw |
Withdrawal-Related Bank Card Exceptions
Below are bank card exception scenarios directly related to withdrawal — for the complete bank card exception list, see Bank Cards and Authorization § Exception Scenarios.
| # | Scenario | Symptom | Troubleshooting Steps | Ops Handling |
|---|---|---|---|---|
| 1 | BST withdrawal unavailable | User cannot see BST withdrawal option | ① Check if account_type contains BST bit (2/3/6/7) ② Check if Mandate status is OPEN(2) | account_type missing bit → agreement not completed; Mandate not OPEN → guide re-authorization |
| 2 | First withdrawal blocked | Prompt "Bank account has not passed authentication" | ① Check verify field ② Check if there's pending review proof | Guide user to upload bank statement; or ops ManualVerify |
| 3 | Pending review card cannot withdraw | Online account opening card unavailable | ① Check if status is 0 ② Check if first deposit succeeded ③ Check if TakeEffect was executed | Deposit succeeded but card not active → manual BatchTakeEffect |
| 4 | Confirm stuck | BST withdrawal stuck at Confirm step | Check Mandate status — if not OPEN, Confirm cannot proceed | Guide user to re-complete BST authorization |
| 5 | Currency not supported | Prompt "currency mismatch" during withdrawal | Check currency_type bitmap (HKD=1, USD=2, CNH=4) | Guide user to bind a bank card supporting that currency |
| 6 | SWIFT missing | Cross-border wire withdrawal fails | Check if bank_swift is empty | Ops UpdateBankCard to supplement SWIFT |
| 7 | Third-party card restriction | third_party_flag=1 withdrawal restricted | Check if third_party_flag is incorrectly marked | Incorrectly marked → UpdateThirdPartyFlag to correct |
Common Misconceptions
| Misconception | Fact |
|---|---|
| "eDDA authorization means you can use eDDA for withdrawal" | eDDA/eDDI is only for deposits (debiting from user's bank). Withdrawals go through corporate online banking channels (hase / hsbc), unrelated to eDDA authorization. The eDDA bit in account_type does not add any withdrawal capability |
| "Binding a card means you can withdraw" | Card binding is just the first step. First withdrawal to that card still requires authentication (verify=2); BST channel also requires BST authorization to be OPEN. All three gates must pass |
| "BST agreement means it always uses BST" | Not necessarily. CMB/CMBC + CNH withdrawal won't use BST even with BST agreement (protocol doesn't cover it); the system sets method to null for ops manual channel selection |
| "Card authentication failure = withdrawal rejected" | They are different things. Authentication is about the bank card itself ("is this card yours"), only checked on first withdrawal to that card. Withdrawal rejection can have many other reasons (insufficient balance, risk control intercept, etc.) |
What to Read Next
| I want to... | Go to |
|---|---|
| Understand the complete withdrawal lifecycle | Withdrawal Lifecycle |
| See BST channel execution details | Channel Execution Manual § BST |
| Understand deposit-side card binding and authorization | Bank Card Binding and Deposit Authorization |
| See the complete bank card data model | Bank Cards and Authorization |
| Troubleshoot when user cannot withdraw | Withdrawal Troubleshooting § User Cannot Initiate Withdrawal |
| BST authorization issues | Withdrawal Troubleshooting § BST Authorization Exception |