As I have said in past articles and since every swaps market participant and every swaps market regulator recognises that transaction reporting has been something of a disaster, we are all waiting to see what the regulators will do about it. Recently, two swaps regulators went in somewhat different directions on this subject.
First, the CFTC issued two no-action letters (“NALs”) and a proposed rule on trade reporting in the US. The first NAL (Letter 15-24) “provide relief from certain Commission regulations to permit SEFs and DCMs to correct clerical or operational errors that cause a swap to be rejected for clearing and thus become void ab initio; and the relief allows counterparties to resubmit the trade with the correct terms. The Error Trade No-Action Letter also permits SEFs and DCMs to correct clerical or operational errors discovered after a swap has been cleared. It allows counterparties to execute a trade to offset the cleared trade and also submit a new trade with the correct terms.”
The second NAL (Letter 15-25) extends “the time period for relief previously provided in No-Action Letter 14-108, from September 30, 2015 to March 31, 2016, with certain modifications. This [NAL] provides relief to SEFs from the requirement to obtain documents that are incorporated by reference in a trade confirmation issued by a SEF, as required under Commission Regulation 37.6(b), prior to issuing the confirmation and from the requirement that a SEF maintain such documents as records, as required in Commission Regulations 37.1000, 37.1001 and 45.2(a). This letter also provides new relief from the requirement in Commission Regulation 45.3(a) that a SEF report confirmation data contained in the documents that the SEF incorporates by reference in a confirmation.”
The proposed rule “eliminate[s] the Form TO annual notice reporting requirement for otherwise unreported trade options in Commission regulation 32.3(b). Instead, a Non-SD/MSP would only need to provide notice to the Commission’s Division of Market Oversight (DMO) within 30 days after entering into trade options (whether reported or unreported) that have an aggregate notional value in excess of $1 billion in any calendar year or, in the alternative, a Non-SD/MSP would provide notice by email to DMO that it reasonably expects to enter into trade options, whether reported or unreported, having an aggregate notional value in excess of $1 billion during any calendar year. Additionally, the Commission proposes that Non-SD/MSPs would under no circumstances be subject to part 45 reporting requirements in connection with their trade options.”
That’s about it, so the CFTC has really stepped up to the plate this time! And US swaps trade reporting remains pretty much a disaster.
ESMA’s process for clarifying requirements is to address them in regular updates to their Q&A document, found on their web site. The primary reporting changes are contained in questions 20a and 20b.
Question 20a is actually two. “Are all fields specified in the Annex of the Commission Delegated Regulation (EU) No 148/2013 mandatory? Can some fields be left blank?” The answer: “In general, all fields specified in the RTS are mandatory. Nevertheless, two different instances need to be acknowledged, namely:
- The field is not relevant for a specific type of contract/trade, [okay to be left blank] and
- The field is relevant for a given type of contract/trade, however:
- there is a legitimate reason why the actual value of this field is not being provided at the time the report is being submitted, or
- none of the possible values provided for in the Annex of the Commission Implementing Regulation … apply to the specific trade [okay to be populated with NA].”
We’ll see some of the fields that fall into these categories when we look at the spreadsheet below.
Question 20b, while shorter, is much more inclusive: “How are TRs [Trade Repositories] expected to verify completeness and accuracy of the reports submitted by the reporting entities?” This is the first question ESMA has addressed on report validation, so every aspect of its answer is important.
To begin with, the phrasing of the question implies that the TRs are responsible for both the completeness and accuracy of the reports. Completeness is relatively verifiable, based on the data requirements for each field, contained in a spreadsheet published by ESMA. Even the accuracy of some fields could be verified. For example, the “clearing threshold” field pertains to whether the reporting counterparty is above the clearing threshold, and presumably can be checked against records held elsewhere.
However, most of the data elements are not all that verifiable by the TR. Even simple things, like the LEIs of the parties to the trade, are not really verifiable if that is the only identifier used, unless the TR checks the LEI against the issuer database to see if it exists. But that still doesn’t say it’s the right LEI. If any of the data elements in a report are inaccurate, either inadvertently or on purpose, and the TR has realtime no way of finding out, is it still responsible for verifying the accuracy? A crucial question.
Now let’s look at some of the answers in the ESMA document. “The table includes two levels of validations which should be performed by TRs:
- The first level validation refer to determining which fields are mandatory in all circumstances and under what conditions fields can be left blank or include the Not Available (NA) value, as clarified in TR Q&A 20a above.
- The second level validation refer to the verification that the values reported in the fields comply in terms of content and format with the rules set out in the technical standards. Where applicable, the logical dependencies between the fields are taken into account to determine the correct population of the fields. The second level validations are complemented with instructions on the fields which should be populated depending on the action type.”
Thus ESMA’s definition of verification is the kind of validation we have already seen by many repositories. They look to see if the data in the fields conforms to the rules, but not necessarily if it is accurate. No real improvement there. Now we have to look at the spreadsheet to see what’s required.
Looking at the Spreadsheet
The first question is what data elements are allowed to be blank. Some are expected, but are there any that are unexpected? In Table 1 (Parties) we find item 5 – Domicile of the Counterparty – which can be blank if the party ID contains the domicile. Thus validation here requires a two part check: does the ID contain the domicile, if not, is it populated here? Item 6 – Corporate sector – has the same condition, so another two-part check. There are several other ID’s that are optional, like broker, clearer, and reporter, and the hedging flag for financial parties, all expected and probably not checkable.
Under table 2 – Details of the transaction – we look at field 12 – price/rate. Here the field cannot be blank, but the rules allow a value of 999999999999999,99999, obviously in lieu of blank or NA. This will lead to the same instances we have seen in the US, where there is no actual price reported for some trades that should have one. There is no indication in the spreadsheet or the Q&A as to whether the TR is responsible for determining if a price is required. By the same token, the spreadsheet allows NA in field 13 – Price notation.
Where does that leave us?
So, are we in a better place on trade reporting with these regulatory releases? In the US, not at all. In the EU, a bit. And it is not a good place to be if you are a regulator, a customer, or even a market observer. We still know very little about what’s going on in the market from the trade reports. ESMA has started threatening to punish inaccurate swaps reporters, but it will have to find them first. Given that the TR business is a competitive one, and dealers do most of the reporting, don’t expect TRs to start trumpeting how tough they will be in verifying reports. So I guess it’s a pretty good place to be if you’re a swap dealer.