Counterparty Radar - Methodology

Methodology

A broader overview of Counterparty Radar can be found here. On this page, we describe the key decisions made when collecting, standardising, and cleaning the data. For any queries not addressed below, please email: cr@fx-markets.com.

Background: The data underpinning Counterparty Radar is found in Form N-PORT filings published by the US Securities and Exchange Commission.

Every mutual fund regulated by the SEC has to complete the form individually, in a standardised way. Each filing – completed monthly, but released to the public quarterly – contains a wealth of point-in-time data on a fund’s holdings, both in aggregate and in itemised form. For example, funds report their sensitivity to credit and interest rate movements, as well as realised and unrealised gains and losses, inflows and outflows. For cash assets, the quarterly snapshot lists all of the individual bonds or stocks held by the fund. For derivatives, the disclosures include the value of the trade, the settlement date, the underlying and – crucially – the identity of the counterparty. Each of the resulting filings can run to hundreds of pages when printed.

Because of the potentially sensitive nature of the information, there is a 60-day lag between the quarter-end reporting date, and the publication of the data.

At the moment of publication, Counterparty Radar begins its work, trawling every filing for information on each fund’s derivatives positions and its choice of counterparty – nine fields provide the necessary data on foreign exchange forwards, while 10 fields have to be scoured to compile the options dataset.

But while the forms and its fields may be standardised, there are variations in the way funds complete them – and some errors. Counterparty Radar has to smooth away those variations, and either correct filings errors, or discard the erroneous data. This process is described below.

Quarters: most but not all filings are made at the end of a regular quarter, eg March 31 for Q1. But not all funds use that quarterly calendar. As an example, funds belonging to some asset managers have a financial year that ends on August 31, meaning their first quarter runs to November 30. Counterparty Radar buckets the filings, capturing all those made in the standard calendar quarter. So filings made by funds in January, February and March are included in the Q1 data, regardless of their manager’s own calendar.

Remaining maturity: this is calculated for each trade using the number of days between the filing date and the trade’s settlement date. These figures are static, they are not updated as the trade approaches the settlement date – the next quarter’s snapshot simply updates a fund’s positions, removing any trades that settled between the two sets of filings.

Trade value: The filings give the exact amounts bought and sold, in the relevant currency. To enable comparison, we convert each trade into a USD value. To achieve this for FX forwards, Counterparty Radar takes the value of the trade’s USD leg, if available. If there is no USD leg, it converts the bought leg into USD using exchange rates at the time of the filing.

To weed out cases of misreporting, Counterparty Radar calculates an implied rate by looking at the amounts of currency bought and sold in each leg. It then checks this implied rate against the actual exchange rate at the time of reporting. If an error is obvious and the fix is clear – for example, the two legs have been transposed – then the trade info is amended. If the error is obvious but the fix is not clear, or is clearly the result of a reporting error, it is removed from the dataset. This affects a very small proportion of all forwards trades, but errors by individual managers can in some cases result in the removal of a large proportion of that firm’s transactions – one example is Putnam Investments, where funds will frequently report bought and sold amounts in different currencies that imply a nonsensical exchange rate. 

A larger share of options trades are lost because – unlike forwards – the forms do not require the two currencies to be disclosed. In many cases, funds use other fields to specify the currency pair, allowing Counterparty Radar to capture it. For now, exotic options have also been excluded from the dataset. 

Regions: To shine a light on regional strength, all trades are allocated to one of five buckets. The G10 bucket includes trades only where both legs are G10 currencies. Non-G10 is everything else.

The three geographical buckets contain trades that either pair a G10 currency with a non-G10 currency, or consist of two non-G10 currencies, a small slice of the total. For trades with a G10 and non-G10 leg, the latter determines where the trade is counted. So, USD/ZAR would be treated as an EMEA trade.

Trades with two non-G10 legs – for example, AUD/DKK or BRL/ZAR – will be counted in both of the relevant regional buckets. This creates a small amount of double-counting, but the alternative would be an under-count.

Dealer names: The filings include a field for the name of the dealer counterparty. These are not uniform – many legacy legal entity names appear, for example – so they have to be mapped to one group. In some cases, the field is left blank, or contains a name that is not the actual counterparty – other intermediaries, for example. These trades are classed as ‘counterparty not identifiable’ and make up less than 1% of the dataset, by market share.

AQR Capital Management is a special case, as it’s understood the firm reports the names of its prime brokers in this field, rather than the executing broker – these trades are also included in ‘counterparty not identifiable’. No other fund manager appears to report in this way.

Fund manager names: the filings give fields for the name of the sub fund and the legal owner of those funds. These are individually assigned to fund managers based on FX Markets research. For some sub funds, it was not possible to easily assign the trades to a specific fund manager – these have also been classified as ‘counterparty not identifiable’. Again, this represents less than 1% of all trades by market share.

Deleted trades: other than circumstances mentioned above, trades can be removed from the dataset if they lack currency codes and settlement dates.

Impact of cleaning: to illustrate the effect of the various steps taken when cleaning the data, for Q4 2020, around 3,000 trades – or just over 3% of the total – were removed from the FX forwards dataset.