The Global Technical Committee has reviewed and preliminarily approved the submitted proposal. The FIX Asia Pacific Technical Subcommittee recommends how to communicate a BCAN (Broker-to-Client Assigned Number) using FIX fields for Hong Kong ID regime. It includes an enhancement of the definition of the user-defined field BCANID(8018).
The document now enters a public comment period in which public review and feedback is encouraged. Once the public comment period closes, the GTC will review public comments before final approval by the GTC Governance Board.
Please post feedback, comments, and questions as replies to this discussion thread. The public comment period ends on May 18, 2022.
This proposal by the Subcommittee appears to be the same as what we had arrived at independently, so we agree with it. However the document is unclear in places about the distinction between the “BCAN Input Format” and the actual “BCAN”. The first of these is the concatenation of the “CE number” and the “BCAN”, separated by a “.”.
For example in section 6.3.1 the recommendation is that 448 should be the “BCAN” but in fact I suspect the intention is that this is an ID in the “BCAN Input Format”. (If this is only the BCAN itself then where is the CE number communicated?)
In our ROE we were explicit about the format of 448:
#### For on-exchange new order entry (35=D)
* The BCAN Field is entered using the Parties component:
| Name | Tag | Value |
|-------------------------|-----:|-------------------------------------------------|
| PartyID | 448 | BCAN Field with format \<CE_number.BCAN_value\> |
| PartyRole | 452 | '3' (Client) |
| PartyIDSource | 447 | 'D' (Proprietary) |
If this is the intention then 6.3.1 should refer to the “BCAN Input Format” rather than the “BCAN”.
More generally, the use of “BCAN” and “BCAN ID” seems loose in the proposal. Assuming these are the same thing, it would be better to use one consistent term throughout.
Perhaps a Glossary section at the start would clarify this.
On reflection we do have an issue with the proposal.
Broker-to-Client Assigned Number (BCAN) - PartyID(448)
PartyIDSource(447)=D
PartyRole(452)=3
This combination of 447=D and 452=3 is commonly used to convey the Client ID between a buyside and a broker. However under the new HKSE regulation the buyside may also need to provide the BCAN to the executing broker (roughly, when the buyside is an RRI under the regulation). If this proposal is adopted then it will not be possible to specify both the BCAN and the regular Client ID. It is highly likely that these are different IDs.
There seem to be a few obvious solutions:
use a different PartyRole, either existing such as ‘5’ Investor ID, or create one for BCAN specifically
retain the use of PartyRole ‘3’ for BCAN but use PartyIDSource ‘P’ Short Code rather than ‘D’ (as used for MiFID short code values) or create a new PartyIDSource for BCAN.
In summary, BCANs can be defaulted by the exchange participant on the order to the exchange if the buyside is a non-RRI counterparty. But in other cases the BCAN has to be passed down the chain of orders from the first RRI counterparty to the final exchange participant. In this second case using Client ID as the PartyRole causes a clash with the common use of this role for the actual Client ID.
The Asia Pacific Technical Subcommittee has published a revised version of the proposal. Please see the document history for details. The document has also been restructured to focus on the communication between the client and the exchange participant. The recommended practice only applies to that communication and it is now recommended to use PartyIDSource(447)=P (short code) to convey a BCAN.
The GTC has decided to extend the public comment period by another week until May 27, 2022. Please continue to post feedback, comments, and questions as replies to this discussion thread.
Hanno Klein
FIX Technical Director
FIX GTC co-chair for EMEA