How difficult will it be to fulfill SEC Rule 606 obligations? On the surface it may seem straightforward. Unfortunately, it actually is very complex, considering all the parties involved. A typical agency brokerage will now have to provide its institutional clients with a 606(b)(3) report that outlines the routes that its orders follow, including fees and rebates associated with those orders for many downstream firms, likely incorporating information from venues the brokerage is unfamiliar with.
The following use case exemplifies a common scenario between a broker and its routing destinations. We will then explore several different methods for collecting the data needed to meet SEC requirements and how each method affects information leakage.
Consider a typical agency brokerage (“Broker A”). Broker A has several institutional customers. It provides those customers with a good high-touch experience – ensuring they get the best possible service and the best possible executions. As a result of the updated 606 regulations released in late 2018, Broker A will have to provide these customers with a 606(b)(3) report outlining the routes that their orders take, the fees or rebates associated with those routes, liquidity, and some additional information.
Broker A has agreements with two large banks (IB1 and IB2) and one algorithm aggregator (AA1). Neither IB1 nor IB2 charge or rebate for orders – they offer their execution services as a free service to Broker A. AA1 charges 2 mils per share but offers additional reporting services. Both Broker A and its 606 vendor think this shouldn’t be a problem – each report should have no more than three rows, and the fees are easy to calculate. There will be a little bit of work to do in order to determine liquidity, but by and large the creation of the report should be fairly easy.
Or should it? In actuality, the report that Broker A is required to produce will likely contain dozens of rows and include fee and rebate information for firms that Broker A may have never heard of, and certainly doesn’t do business with. The recently released FAQs make it clear that even a modicum of discretion is sufficient to trigger a “look-through” requirement, where Broker A will need to disclose all of the routes and fees and rebates used by IB1, IB2 and AA1 for Broker A’s orders. Suddenly, this apparently simple report has become incredibly complex. Each of the banks use advanced trading algorithms that route each order to dozens of dark pools, ATSs and exchanges, creating and canceling orders hundreds of times a second. On top of this, AA1 routes to many such banks, including IB1 and IB2, algorithm aggregators, and other destinations. What once appeared to be a simple report has turned into a complex web of data management.
How, then, does Broker A comply with the regulations? The first step is to obtain the data. An immediate suggestion might be for IB1, IB2 and AA1 (“Downstream Brokers”) to add the data to the FIX messages already being used for transmitting orders. Unfortunately, this misses a substantial amount of information. This addresses only executed orders and there is really no mechanism to transmit orders that are not executed back to Broker A (“Introducing Broker”). Additionally, doing this would likely require other data in the FIX message to be replaced, thereby losing information that was previously available.
In addition to the difficulty in obtaining the data, look-through may have unintended consequences because it provides opportunities for substantial “information leakage.” Information leakage is the unwanted disclosure of information. In the case of disclosing information about an institutional customer, it may alert sophisticated investors of directionality of trading, allowing them to trade ahead of the customer, in turn increasing the cost of a trade for that customer. For Downstream Brokers, it may disclose proprietary or trade secret information, which in turn may be used to cause harm to the broker.
Some information leakage is inherent and indeed intended in the rule – the routes and fees used by brokers have historically been proprietary information. However, virtually any implementation of the data transmission will require more leakage than required by the rule. The goal is to reduce this leakage while still allowing the Introducing Broker to comply with the regulation. Here we review several different scenarios for transmitting the necessary data between participants and review the information leakage impact in each scenario.
The following scenarios are presented in order of most information leakage (worst case) to least information leakage (best case).
Upstream Disclosure
The Downstream Broker discloses all routes, trades, and fee/rebate relationships to the Introducing Broker. In this instance, the Downstream Broker is the only one disclosing any information above the regulation. However, Downstream Brokers are unlikely to be willing to do this. This information effectively puts all the results of proprietary trading strategies in the hands of the Introducing Broker. A sophisticated firm may be able to take this information and reverse engineer the strategies used by the Downstream Broker, thereby causing them harm.
Downstream Disclosure
The Introducing Broker discloses to the Downstream Broker which customer each order is for. Here, the Introducing Broker is the only firm disclosing information over and above the regulated disclosure. There are several concerns with this method. First, the introducing broker may not wish to disclose which clients are using their services. Since the introducing broker is using the Downstream Broker for execution, there may be concern that the Downstream Broker may be able to “poach” the customer. Additionally, the customer may not wish to be disclosed – oftentimes, an institution will use several different brokers to attempt to conceal their trading strategies. A sophisticated Downstream Broker may be able to aggregate the information from multiple Introducing Brokers to determine specific positions and trading strategies of the customer.
Downstream Disclosure with Obfuscation
The Introducing Broker discloses to the Downstream Broker that several orders go together for 606(b)(3) purposes, but not which client they are for. In this instance, the Introducing Broker again is the only firm disclosing information over and above the regulated disclosure. Since the actual client is not disclosed, the primary concerns center around the directionality of trading rather than the specific client. A sophisticated Downstream Broker can analyze grouped orders to determine directionality of trades, and therefore make trading decisions that adversely affect trades for the customer.
Aggregated Upstream Disclosure
The Downstream Broker aggregates all 606(b)(3) information for orders that are 606(b)(3) eligible for the Introducing Broker at the parent-order level. In this case, the Executing Broker is disclosing more information than required by the rule because the information is aggregated to the order level, rather than the customer level. Because this method does not disclose details of the routes and decisions the Downstream Broker made, it is very unlikely that even a sophisticated counterparty could use this information to reverse engineer the strategies used. The only information disclosed by this method, above the rule, is which orders were routed to which destinations, rather than simply aggregating this information to the customer level.
Third Party Integrated Look Through
Both the Introducing Broker and the Downstream Broker use the same non-trading third-party firm, such as S3, and that third-party firm traces the information behind the scenes, thereby allowing the Introducing Broker to produce the required look-through data without ever seeing the details behind those numbers. In this case, neither party is disclosing any information above what is required in the rule to the other. Since many brokers use third-party firms to handle best execution and regulatory reporting, this allows no information leakage to occur, while still complying with the report. The downside of this method is that it requires both parties to be using the same third-party firm that has this capability.
S3 offers a solution that helps brokers produce these regulatory reports. The mechanism that offers the least amount of information leakage is Recursive Routing Analysis (“RRA”), which, as described in Third Party Integrated Look Through (above), handles all the look-through information to be determined behind the scenes and without disclosure to any other trading firm. If an Introducing Broker client of S3 requires data from other sources, we support all of the mechanisms mentioned above. If a Downstream Broker and client of S3 needs to send look-through data to an Introducing Broker that is not an S3 client, S3 recommends, and will support producing, the Aggregated Upstream Disclosure for delivery to the Introducing Broker, giving them all the information necessary to comply with the regulations.
As can be seen, the new 606(b)(3) adds a substantial amount of work to all involved parties and may have unintended disclosures. But, by using appropriate solutions, the adverse effects of this rule can be mitigated.
