Complexity from simplicity – the INTC story

Complexity from simplicity - the INTC story

The replacement of the INTC code when aggregating client orders is one of the changes proposed by ESMA in its recent review of MiFIR Transaction Reporting.  On the surface this is to be welcomed, but do ESMA’s proposals go far enough?

How INTC currently works

When investment firms aggregate orders across more than one client, they are required to enter a value of ‘INTC’ in the relevant Buyer or Seller identification code field in their MiFIR transaction reports.

It is by necessity that firms must use the ‘INTC’ aggregate client account as it’s generally not possible to allocate individual fills to specific clients until the aggregated order has been completed and an average price is known.  For example, if a firm is buying 100,000 Vodafone shares on behalf of three clients where Client A wants 25,000 shares, Client B wants 30,000 shares and Client C wants 45,000 shares, when reporting a first execution fill of 9,000 shares it’s not possible to accurately allocate the shares pro rata to all three clients in a single transaction report, so they must be linked using the INTC account.

Essentially, the ‘INTC’ account is used to facilitate the reporting of the market-side executions and ‘warehouse’ the Vodafone shares until the order is completed.  Once the order is fulfilled, e.g. 100,000 shares at an average price of 113 pence then the three allocation transaction reports can be made showing the shares switching from the ‘INTC’ account into the accounts of client A (25,000), client B (30,000) and client C (45,000) all at the average price of £1.13 GBP.

The INTC rules

Use of INTC comes with a few simple rules:

  1. The INTC account must be flat at the end of each reporting day.
  2. INTC can only be used where orders from more than one client are being aggregated prior to execution. A client here, means a single LEI or single National Client Identifier.
  3. The timestamp on the allocations must be the time of the first fill trade
  4. Allocations would be at the average price of each of the fills.

These rules seem simple enough, however in practice, they do lead to a great deal of complexity when trying to apply them to real world activity.  This has led reporting firms and system providers alike to struggle with certain real-world scenarios. A few examples are shown below:

  • Firstly, ensuring the INTC account is flat at the end of the day.  Firms that work orders over midnight UTC are effectively required to close their books at midnight and apply the allocations based on the fills accrued at that point, then start again with any post-midnight fills.  This of course would double the amount of allocation transaction reports required but also presents a scenario in which most systems have not considered. Trading in the APAC region often faces this challenge.
  • Secondly, some asset managers group orders across entities.  This is primarily driven by their best execution policy and group trading arrangements.  Where this happens, scenarios arise where only a portion of the fills may be allocated to reportable activity. 
  • Thirdly, where systems operate at sub-fund or sleeve level but they roll up to the same LEI, INTC should not be used.  Many systems are unable to cope with this.
  • Fourthly, regulators have asked where INTC is used for multiple client orders, but some allocations relate to the same LEI that they are rolled up into a single allocation for that LEI so that there are never two allocations with the same LEI for the same group order.

ESMA’s proposal

Challenges with the INTC account have led ESMA to suggest some changes which will allow NCAs to more easily review how an order is being reported.  ESMA is proposing that the generic and consistently applied ‘INTC’ account code is replaced by a code, internal to the investment firm but that uniquely links the market-side execution reports and the client-side allocation reports.

What makes sense about ESMA’s proposal

In terms of usefulness, it makes sense to replace the generic ‘INTC’ code with a unique code that links market side executions with the related client-side allocations.  This linkage is currently often difficult to do, particularly for firms that aggregate multiple orders in the same financial instrument at different points or throughout the same trading day.  It will also make it easier for firms to ensure that the ‘INTC’ account is flat at the end of every day and to more efficiently identify which specific transaction reports are leaving a position in the ‘INTC’ account.


However, not proposing a separate field for what is effectively a “Group Order ID” could be a missed opportunity as it could have involved fewer coding changes for firms.  Importantly, it would have linked transaction reporting data with the related order record-keeping information. This would be hugely advantageous from a market abuse detection perspective.  The “Order ID” could also be applied to non-INTC related trades to further enhance the effectiveness of surveillance more broadly.

Additionally, ESMA’s final report does not provide guidance or direction for instances where client orders are aggregated across more than one investment firm within the same financial group. This is a scenario where we have seen several firms have difficulties.

Time will tell whether the FCA will follow ESMA’s lead or propose to use this as an opportunity to go further and create a powerful link between transaction and order data.

  • While ESMA’s proposed changes to MiFIR Transaction Reporting are at least a few years away, adequate implementation time will be required for firms to make the necessary changes.  For a conversation with Simon or one of our regulatory subject matter experts about these changes or how to get your transaction reporting into better shape, please contact us.  

  • Read our recent Industry Q&A on ESMA’s proposals here.