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. This document focuses on foreign exchange forwards, but much of it applies equally to the other instruments we cover. For any queries not addressed below, please email: cr@risk.net.

Background: The data underpinning Counterparty Radar currently comes from two sources: Form N-PORT filings submitted to the US Securities and Exchange Commission (SEC) and US life insurer Quarterly Statements collected by the National Association of Insurance Commissioners (NAIC).

Every mutual fund and ETF 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.

US life insurers also submit a standardised quarterly statement, reporting their derivatives positions in Schedule DB, providing many of the same data points.

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 of the N-PORT filings, and a similar lag for when the NAIC releases the Schedule DB data.

At the time of publication, Counterparty Radar begins its work, trawling every filing for information on each fund’s derivatives positions and its choice of counterparty – for both filing types, nine fields provide the necessary data on foreign exchange forwards.

But while the forms and its fields may be standardised, there are variations in the way funds and life insurers 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: US life insurers file at the end of a regular quarter, e.g. March 31 for Q1. However, not all mutual funds and ETFs 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 or life insurer’s positions, removing any trades that settled between the two sets of filings.

Trade value: The N-PORT 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.

Life insurers, while not consistently reporting the bought and sold amounts of each currency, do provide the notional value of each trade, converting non-USD trades using the appropriate foreign exchange rate.

To weed out cases of misreporting with N-Port filings, 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.

In the case of life insurers, all trades without a notional value are removed.

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 identified’ and make up less than 1% of the dataset, by market share, for N-PORT filings, and a little over 10% of the dataset with schedule DB filings.

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 identified’. 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 N-PORT filings in Q4 2020, around 3,000 trades – or just over 3% of the total – were removed from the FX forwards dataset.

For US life insurers in Q4 2022, only nine FX forwards trades - or 0.1% of the total – were removed.