7. Identifying the Client for Transaction Reporting Purposes

The aim of transaction reporting is to enable regulators to identify potential market abuse. To that end they view the identity of the client as being key to their detection efforts. As such the FCA requires a BIC or FRN to be reported where one is available as this identifies the client to the FCA allowing them to link that client’s trading across the market. Where a BIC or FRN is not available an internal code allocated by the firm is to be used which is unique to that client and the only code used to refer to that client. As such it must be used consistently across all business areas of the firm when referencing that client to the FCA.

Example scenario 1: client places orders directly with the firm

In the above scenario underlying entity A is our client. The client code for that client is used to identify the client or where a BIC or FRN is available that must be used on the transaction report.

There are however, a number of scenarios which can arise in which we must consider who is our client. These are detailed below.

7.1. Agents as clients: COBs 2.4.3

A common scenario that arises is where an entity acts as agent for an underlying entity or fund. Under COBs 2.4.3 we are to treat the agent that is providing the orders as our client rather than the underlying entity or fund in favour of whom those orders are being placed.

To enable compliance with this requirement most data systems use the concept of parent and child relationships where the agent is set up as a Parent entity with the underlying client being set up as a Child entity. When a trade is executed by the agent on behalf of the underlying entity the BIC or FRN associated with the Parent entity is transaction reported as the client rather than the underlying entity (see details in section 7.2. below).

Example scenario 2: agent as client

Above the client of the firm is Agent A. Client C is the client of the Agent A. COBs 2.4.1 states that where the firm receives instructions from Agent A, then Agent A is to be treated as its client. This means Agent A should be identified as the client in the transaction reports. Further, confirmations should be submitted to Agent A and not Client C.

Where Order Placer A is acting as agent for Client C unless agreed per below, A would be our client and A’s details would be included in the transaction report. In this scenario it is possible for both A and C to have been on-boarded as clients of the firm. Typically, this would create a parent/child relationship in the client reference data. A common scenario is where Agent A is a fund manager and the client C is a fund. Where this arises both parties are on-boarded by the firm and their relationship is maintained in the client static data.

7.2. Portfolio managers as clients

Where the firm trades on behalf of a client which is a fund whose orders are being placed by a fund manager the firm is required to identify the fund manager in the transaction report rather than the fund for which the trade was executed.[1]TRUP v3, 9.7.5 In this scenario the fund manager is acting as an agent for the fund and placing orders as agent for the fund. To accommodate this requirement, as in section 7.1. above, agent as client funds are normally set up on the client data system as Child entities with the fund manager as Parent entities.

The transaction reports submitted with have the BIC, FRN or client code for the relevant fund manager whilst the trade will settle against the fund.

Example 3: Portfolio manager as agent for a fund

Where a portfolio manager A is placing orders on behalf of a fund, they are in effect acting as agent for the fund C. In this scenario as above the portfolio manager’s FRN or BIC must be included on the transaction report.

7.3. Scenarios in which the agent is not to be treated as our client

COBs 2.4.3 (2) provides for a scenario in which the parties agree that the underlying entities rather than the agent placing the orders is to be treated as the client.

For this to apply:

  • a written agreement between the firm and the agent is required identifying each of the underlying entities to which the arrangement applies; and
  • the underlying entities must not be associated as Child entities of the agent for each underlying entity subject to the agreement

Example 4: Underlying entity is agreed to be treated as the client and not the agent

In this scenario the agent has specifically requested and agreed in writing for the firm to treat the underlying entity Fund C as our client. To do so Fund C would have to have been through a full on boarding process and Terms of Business would have to have been signed by C. Where this has been agreed we must identify Fund C on the transaction report and not the order placers A or B.

When in doubt as to which entity to identify as the client you should contact Compliance. Such arrangements must not be entered into without engagement of Compliance.

7.4. Multiple fund managers

There can be some scenarios where a single fund is managed by more than one fund manager. Care must be taken in this situation as the same rules apply, the fund manager placing the order must be treated as the client. As such both fund managers would have to be on-boarded as client of the firm. With two fund managers placing orders for a single fund there must be the appropriate links in the client static to ensure that the correct fund manager is identified when an order is placed.

7.5. Block and allocation trades

Fund managers will also execute trades as a block for subsequent allocation to their funds. One trade can be allocated amongst several funds after the trade has been completed. Where this arises a block trade is undertaken and then normally later the same day an allocation instruction is received from the fund manager. This will tell the firm which funds to allocate the trade to and in what proportions.

From a transaction reporting perspective this can be handled in one of several ways. Bearing in mind that the regulator wishes to see what is going on in terms of who is the originator of the trade economics must only be reported once.

  • The block trade is reported as a single trade against the fund manager. The subsequent allocations are suppressed from transaction reporting
  • The block trade is suppressed from reporting and only the allocations are reported using the time and price for the block trade
  • The block trade is reported and then cancelled when the subsequent allocations are made using the time and price from the block trade. This approach should be avoided as it creates noise in terms of reported and then cancelled trades
  • The initial block trade is booked out to an internal account. On receipt of the allocation instructions a series of transactions are booked out against the internal account with the fund manager identified as the client

   [ + ]

1. TRUP v3, 9.7.5