Hong Kong investor identification regime: BCANs and order tagging

The Hong Kong Investor Identification Regime at trading level requires relevant intermediaries to assign a Broker-to-Client Assigned Number to each relevant client and tag applicable securities orders sent to SEHK. The regime supports regulator access to client-originated trading identities.

What HKIDR does

The Hong Kong Investor Identification Regime (HKIDR) adds an identity tag to relevant securities orders executed on the Stock Exchange of Hong Kong (SEHK). It was launched on 20 March 2023. A relevant licensed corporation or registered institution assigns a Broker-to-Client Assigned Number (BCAN) to a relevant client and tags the BCAN to the client’s applicable order. The intermediary also submits the client’s identification data to SEHK’s data repository under the prescribed arrangements. The regime is designed to let regulators trace trading activity to the originating client; it is not a public disclosure of the client’s identity with every market-data print. The SFC’s FAQs address product scope, clients, data collection, consent, BCAN assignment, aggregation, and special situations.

Who is responsible in the chain

The regime applies to relevant registered institutions and SFC-licensed corporations that handle orders within scope. A firm should map its complete order chain: the client, account holder, intermediary, any routing intermediary, and the exchange participant that submits the order. Each participant should understand which activity it performs, whether it is the client-facing firm or a routing intermediary, and what identifier must travel with the order. Outsourcing order routing does not remove the need for an effective control framework. Contracts and operating procedures should define BCAN generation, data validation, transmission, exception handling, and records. Where several intermediaries are involved, the SFC’s FAQ on chains of relevant registered intermediaries is particularly useful; firms should not improvise identifier substitution.

BCAN assignment and uniqueness

A BCAN is an assigned identifier used to link an order to the relevant client identity in the protected reporting system. The intermediary needs a controlled method to generate and assign it, keep the mapping accurate, and prevent accidental sharing between clients. Account numbers, trading names, or an employee’s code are not substitutes for the prescribed BCAN. A client with multiple accounts or relationships can raise questions about whether the regime permits or requires multiple BCANs; the SFC has specific FAQs on that issue. A robust process records the client identifier, account relationship, BCAN status, effective date, and any change or deactivation. Test the mapping against sample order records before enabling order flow and whenever a migration or system change occurs.

Client identification data and consent

Intermediaries must collect and submit the required client identification data, subject to the regime’s rules and the client’s category. The data elements differ for individuals and corporate clients. Explain the collection purpose and applicable consent requirements in the onboarding process, and keep evidence of the notice or express consent where required. The SFC updated its client-identification data FAQs in April 2025, so operational guidance should be checked against the latest official materials. A firm should limit access to identity data, protect transmission and storage, and maintain procedures for correcting inaccurate data. If a client refuses to provide required information or consent, staff should follow the relevant SFC guidance and firm policy rather than inventing a workaround or tagging an unrelated identity.

Which orders and products are covered

HKIDR applies to relevant securities orders to be executed on SEHK, subject to the SFC’s defined scope and specified exclusions or treatments. Staff should not assume every instrument traded in Hong Kong is covered simply because it has a stock code. The regime’s FAQs address product scope and clarify how products such as listed securities, derivatives, and other instruments should be treated. A firm should maintain a product eligibility table owned by compliance and technology, and update it when the SFC or Exchange changes the scope. The order system should reject or quarantine a covered order if the required client identity or BCAN is missing or invalid. The scope test should be made at the product and transaction level, not from a customer’s general account label.

Aggregated orders and intermediaries

Aggregation can make identification more complex. If a firm combines client orders before routing to the exchange, its system must preserve the relationship between each relevant client and the order flow in the way the SFC requires. A single aggregated order should not cause the firm to tag the house account or one customer arbitrarily. The SFC’s FAQ on aggregated orders explains how the regime applies in those circumstances. Firms should model both the parent order and allocations, preserve timestamps, and be able to reconstruct the originating clients. Similar care is needed when a routing intermediary receives an order from another intermediary: the chain should transmit the proper identifier and data without loss or duplication.

Errors, system outages, and reconciliation

An order rejected for a missing or invalid BCAN should be handled through a documented exception queue. Staff should identify whether the problem is a client-master issue, a data-format issue, or an upstream transmission failure; correct the source; and retain an audit trail. Never reuse a valid BCAN for a different client just to clear the queue. Reconcile submitted orders with the intermediary’s records and investigate unmatched or incorrectly tagged trades. For a system outage, follow approved business-continuity procedures and any regulatory or exchange instructions; do not assume an alternative reporting route is available without checking. Test disaster recovery, vendor changes, and new product onboarding. Senior management should receive meaningful incident reporting, especially for recurring breaks or potential data exposure.

Privacy, security, and exam takeaways

The regime requires client identity information to reach an authorized repository; it does not eliminate confidentiality duties. Restrict access on a need-to-know basis, encrypt data in transit and at rest where appropriate, monitor access, and retain records for the prescribed period. A privacy notice should be accurate about collection, use, and disclosure. In an exam scenario, distinguish BCAN tagging from ordinary exchange member identification, identify the relevant intermediary, check whether the order and product are in scope, confirm client data and consent controls, and test whether an aggregation or routing chain changes the handling. If information is missing, the correct control is escalation and correction under procedure, not an invented identifier.

How to analyze an exam scenario

Start with the legal entity, product, transaction, and event. Identify the statute or exchange rule that applies, then test each element and exception against the facts. Keep separate concepts separate: an internal policy, an SFC guideline, an Exchange rule, and a statutory duty may have different legal status and scope. Record the dates and persons involved before reaching a conclusion.