System Introduction

1. System Overview

A deposit refers to the process by which an investor transfers funds into their securities account. This process involves multiple steps to ensure that funds are transferred into the investor’s account securely and accurately.

The Whale system includes functionalities for processing deposit applications, matching bank transaction records, deposit review, separately handling deposits made during account opening, reconciliation, and deposit record inquiry. In response to regulatory and risk-control requirements, the system is designed with multi-role, workflow-based characteristics to balance high deposit efficiency and low capital risk.

Because different brokerage firms have different requirements for deposits—some requiring rapid deposits while others require precise matching of bank transaction records before posting—the system supports two deposit workflows, as follows:

Prerequisites

You must obtain the following authorizations to use the system functions properly.

Permission Name	Permission Description
Permission to manage funding parameters, bank statements, and deposits	Permission to manage bank statements, deposit and withdrawal records/methods, bank cards, foreign-exchange services, and funding guidelines; and permission to manage funding parameters.

2. Operation Guide

Deposit Configuration

Funding Parameter Configuration

📍

Business Parameters Settings > Funding Parameters

1. Company Bank Accounts

Before a customer makes a deposit, the corresponding company bank accounts must be added in the backend and the deposit methods under each company bank account must be configured.

Operation button descriptions:

• Create: Add company bank account information for the brokerage as needed.
• Edit: Manually edit existing company bank account information.

1. Currency

Before a customer makes a deposit, the deposit currencies must be configured.

Operation button descriptions:

• Create: Add currencies as required by the brokerage.
• Edit: Manually edit existing currency entries.

Customer Bank Cards

📍

Funds Management > Customer Bank Cards

Customers must have their bank card information configured with the broker. Bank cards can be added either by the customer via the client app or by the backend.

Operation button descriptions:

• Bulk Add: Add bank card information in batches according to a template.
• Add Bank Card: Add a single bank card.
• Recycle Bin: Display deleted bank card records.
• Set Rejection Reason: Configure reasons for rejecting a bank card.
• Review: Perform backend review of a bank card.
• View Notes: View related notes for a bank card.
• Delete: Delete bank card information.
• Update Deposit Witness Status: Associate the customer’s deposit details to update the bank card’s deposit witness status from “Pending Witness” to “Witnessed.”

eDDA Authorization

📍

Funds Management > Customer Bank Cards

If a customer intends to deposit via eDDA, eDDA authorization is required. Once the customer has authorized eDDA, the corresponding record is available in the backend.

Operation button descriptions:

• Refresh: Retrieve the latest eDDA authorization records.
• Notes: Configure notes for the authorization record.
• Change Status: Modify the status of an authorization record.
• Delete: Manually delete authorization records that are in-progress.

Bank-Related Information Configuration

When configuring customer or company bank account information, the “common bank list,” “country/region enumeration values,” and “bank region list enumeration values” used by the system can all be configured in the backend.

1. Card Issuing Banks

📍

Funds Management > App Management > Card Issuing Banks

Operation button descriptions:

• Create: Add a single entry to the list of common banks for each region.
• Edit: Edit existing entries in the bank list.

2. User Card Binding - Country/Region

📍

Funds Management > App Management > User Card Binding - Country/Region

3. Bank Region List

📍

Funds Management > App Management > Bank Region List

Operation button descriptions:

• Create: Add a single bank region list entry.
• Edit: Edit existing bank region list entries.
• Delete: Delete bank region list entries.

Deposit Guidance Configuration

On the client deposit page, the backend can configure operation guidance and deposit parameters.

1. Deposit Guidance

2. Deposit Parameters

📍

Funds Management > App Management > Deposit Parameters

Operation button descriptions:

• Create: Create a single deposit parameter entry.
• Edit: Edit existing deposit parameter entries.
• Delete: Delete deposit parameter entries.
• Publish: Apply the configured deposit parameter to the client display.
• Unpublish: Make the configured deposit parameter unavailable for client display.
• Copy: Quickly create a new deposit parameter by copying an existing one.
• Approval: If deposit parameters are configured to require work order approval, all the above operations will require work order approval after submission.

Multiple Receiving Bank Configuration

• If the client needs to display multiple receiving banks under the same deposit method depending on the customer’s chosen bank, refer to the following configuration screenshot.

Deposit Operations

📍

Menu path: Funds Management - Deposit

Deposit Applications

A deposit application is submitted by the user and includes four main elements: currency, requested amount, receiving bank card, and remarks. WHALE users can manually assist customers with deposits into securities accounts and may reject submitted applications, submit them for approval, and perform other operations.

• Create (Deposit Application)

Applicable when an operator contacts backend staff to perform manual deposit posting. The operator must sequentially select the customer and enter the deposit currency, method, receiving bank, amount, remarks, and supporting documents (if any).

• Reject: If the customer’s submitted deposit application information is incorrect or the user deems the application invalid, the operator may perform the Reject operation.
• Delete: If the customer’s submitted deposit application information is incorrect or the user deems the application invalid, the operator may also delete the target record via the Delete button.
• Edit: If an issue is discovered with an application prior to submission, the operator may correct it via the Edit button after confirming with the customer. Edits require work order approval; changes take effect only after approval.
  • Editable fields: currency, deposit method, receiving bank, amount, deposit fee, remarks, supporting documents (re-upload).

Operations

• Direct Posting: Because different broker users have different timeliness requirements for deposits, Direct Posting helps users process deposit workflows quickly. After receiving the customer’s deposit application, the user needs only to supplement bank transaction information to complete the posting. Direct Posting is preset to require approval; if approval is not needed, contact operations to configure.
  • Requires Approval: In the Direct Posting dialog, confirm that the information is correct and click [Submit for Approval]; the record will flow to the Deposit Review page and will be posted after approval.
  • No Approval Required: In the Direct Posting dialog, confirm that the information is correct and click [Confirm Posting] to post directly.

Requires Approval

No Approval Required

• Voucher Association: If the posting operation involves multiple applications, you may enter the Voucher Association page to perform batch postings.

On the Voucher Association page, all applications awaiting posting are filtered and presented for operator selection; after verification, submit to post.

Deposit Matching

The data on this page come from deposit entries in bank statements. If a brokerage’s business rules require matching bank transaction records to deposit records before posting, and bank transaction information has been synchronized to the system, operators can manually process such records on the Deposit Matching page. Processing methods are divided into two main categories: Associate (match and post) and Deposit Return.

Processing Method	Definition
Associate	Automatically associate and post based on whether fields in the bank statement—such as payer bank account, payer name, currency, and amount—match the deposit record.
Deposit Return	The process of returning funds to the customer’s bank card when the customer has not been properly onboarded or when the customer’s account cannot be credited due to account risk or other reasons.
Withdrawal Return	Used when a customer’s withdrawal is rejected by the customer’s receiving bank and the returned funds appear as an inflow in the bank transactions; this function pairs the returned funds back to the customer’s account. (Because these appear as inflows in the bank transactions, they are placed on the Deposit Matching page to distinguish them from normal deposits.)

• Associate: For bank statement deposit records that the system cannot automatically match, operators can follow the system’s prompts to confirm and then proceed with posting or other actions.
  • The Associate page will auto-compare fields to match users by name; after confirming accuracy, click [Associate].

Deposit Return: If for various reasons a deposit cannot be credited to the customer’s securities account, use this function to process a refund. The operator must enter the customer’s bank card information, confirm accuracy, and click [Confirm] to flow the record to the Deposit Review page for approval.

Withdrawal Return: Because the Deposit Matching page’s data come from inflows in bank transaction records, if a customer’s withdrawal is rejected by the bank and appears as an inflow, the operator should associate the withdrawal’s transaction reference and process the record using the [Withdrawal Return] function.

Deposit Review

After operators process records on the Deposit Matching page based on bank transaction inflows, downstream review personnel will approve the processed results before posting can occur. For deposits associated with normal postings where the securities account was still under the customer’s account at the time of deposit, the backend will perform a separate approval for such records.

• Account Opening in Progress: Select the target record and click [Approve] to enter the details page, verify the information, and initiate a work order approval.

• Account Opened: Select the target record and click [Approve] to enter the details page, verify the information, and approve.

• Deposit Return: Select the target record and click [Approve] to summon the approval work order; after confirming the information is correct, approve to proceed.

• Withdrawal Return: Select the target record and click [Approve]; after confirming the information is correct, approve directly—no work order approval process is required.

Bank‑Securities Deposit

After bank‑securities account opening, users can deposit via the bank‑securities channel. When the system receives a bank notification, it will automatically match the user and post the deposit without manual intervention.

eDDA Deposit

After eDDA authorization is completed, users may deposit via eDDA. When the system receives a bank notification, it will automatically match the user and post the deposit without manual intervention.

FPS (Faster Payment System)

For FPS transfers, after the bank statement is received, the system can automatically match the bank statement entries with deposit applications and, if matched, automatically post the deposit.

Deposits During Account Opening

• If the customer selects transfer verification as the verification type, deposits must be processed via deposit applications; see “Deposit Applications” for details.
• If the customer selects cheque verification and the client app did not submit a deposit application, the bank transaction record must be used as the basis for posting; see “Deposit Matching” for details.

Because deposit workflows and account-opening workflows can run concurrently, deposits may be posted while the account-opening process is still in progress. For such deposit records, users can track the corresponding account-opening status on this page.

Users can view the real-time status under “Account Opening Status.” If the customer’s account-opening process fails, it can be [Rejected] (batch operations are supported).

Deposit Reconciliation

To ensure the accuracy of fund flows, business operations must compare bank transaction records with the system’s deposit records to improve deposit accuracy. Bank transaction records originate from two sources: ① API integration (automatically generated), and ② manual import.

• Reconciliation: Users may refresh bank transactions for a target period; the system will automatically match bank transactions with the system’s deposit records. After the reconciliation completes, review the “Reconciliation Result” column in the list; if discrepancies exist, further investigation and handling are required.

Deposit Records

The Deposit Records page logs the full lifecycle status of deposits. Users may query, export, or import records at any time.

• If a user performed a Direct Posting deposit without entering bank transaction information, they can bulk import bank transaction records on this page via [Import Bank Transactions].

• For cheque deposits that have been frozen, they may be manually unfrozen in the backend before the “Estimated Unfreeze Time,” or allowed to be automatically unfrozen by the system.

• After submitting a manual unfreeze request, it must await work order approval.