3) Double-reporting of derivatives trades is a significant risk.
Minor differences in counterparty and trade identifiers can make the same trade appear to be different when applying the EMIR regulatory reporting rules automatically. This can occur when a delegator (small bank) checks the Trade Repository data to ensure its designated reporter (large bank) has properly reported the relevant derivatives trades. If the small bank cannot find its trades because of differences between its own internal entity or trade identifiers and the reporting bank’s entity or trade identifiers, the small bank may upload its “missing” trades with a different ID. In this case, the trade is double reported.
Another example is when a trade is executed or reported through an electronic platform such as a SEF or TriOptima, and the reporting is delegated. In this case, the Unique Trade Identifier (UTI) may not be fully incorporated in the chain of parties, leading to confusion and potential double reporting after the fact. Even with common Legal Entity Identifier (LEI) and Unique Trade Identifier (UTI) schemes, it is difficult or impossible to capture and validate the entire chain of data. There is a high propensity for breaking the “data integrity chain” when a trade passes through multiple institutions processing the trade with different systems, data validation and enrichment processes.
4) Under-reporting of derivatives trades is also a risk.
A common example of under-reporting is when a trade is done with a local subsidiary of a global institution. For example, the U.K. branch of a large Dutch bank may trade a foreign currency swap with a U.K. bank to whom it also delegates its reporting obligation. The FX swap is traded strictly for hedging purposes.
Under EMIR, the FX swap trade must be reported to a Trade Repository because it is made by a foreign subsidiary of Dutch bank subject to EMIR. In contrast, under U.K. law a FX swap specified as a “hedge” does not need to be reported to a Trade Repository. Since both the delegating and reporting institutions are in the U.K. following U.K. law, the reporting institution elects to not report the trade under the U.K.’s “hedge” exception.
While this action complies with U.K. law, it violates EMIR unless the trade is reported by the U.K. subsidiary to its parent in Amsterdam, then subsequently reported to a Trade Repository. If this additional step is not taken then the Dutch parent bank has violated its EMIR reporting obligations.
5) Legacy data capture and reporting infrastructures hinder effective application of reporting rules at a granular level.
As banks globalized in the 1990’s, IT systems were often regionalized by country and continent to make them manageable. Regional entities had separate transaction capture, data processing and reporting systems, often enforced by country-level regulatory regimes.
This silo-based infrastructure continues to exist in most parts of the world, presenting tremendous challenges delegating cross-border derivatives trade reporting. Trades with counterparties in multiple jurisdictions often involve two or more incompatible data stores and trade processing systems. These data sources are expected to feed regulatory rules engines that determine whether to report the trade to a Trade Repository, and to which trade repository to sent it. If the underlying data itself is not normalized, and the systems do not communicate in a timely manner, it can be impossible to fulfill the rule requirements.
6) Real time and end of day reporting infrastructures are fundamentally different.
EMIR requires only end of day reporting, while Dodd-Frank requires intraday (aka “real time”) reporting of derivatives trades, modifications and cancellations. At first look, a firm with real time reporting capability may appear to have EMIR’s end of day challenge well-handled. However, fundamental differences in the way data is managed between a “real time” and batch-driven reporting IT infrastructure present significant complexities.
Real time processing is heavily message-based and utilizes incremental updates, meaning that trades are often reported very quickly – in some cases even before the terms and conditions are 100% complete and accurate. Although a Trade Repository’s CSV and/or FpML messaging interface should not accept erroneous or incomplete data there is no way for the Trade Repository to determine, beyond missing data fields or incorrect formats, whether the reported trade data received is accurate. Throughout the trading day reporting institutions incrementally resolve these data issues through re-submissions and updates to the trade record. This is a fundamentally different process than that required for end-of-day batch reporting under EMIR.
Under EMIR if one or both of the counterparties are FCs or NFC+s, the trade record must be enriched by valuation and/or collateral details. These valuations and collateral details are normally computed on a periodic basis, rather than real time, and may be added after the end of the day. If the bank’s reporting infrastructure is designed for real-time, the trade must be queued internally until the valuation and collateral enrichment can be done. This causes high system overhead and complexity to monitor incomplete trade messages as they sit in a queue, or must first be persisted to a staging database.
Another example is where a trade is done, then quickly cancelled or reversed. Under an intraday reporting regime such as Dodd-Frank, the trade and its cancellation must both be reported. In contrast, under EMIR’s end-of-day regime, only those trades which exist at the end of the day must be reported. From an EMIR regulatory reporting standpoint it is as if the trade never occurred. Under either regime the trade data must be processed and filtered differently.
Likewise, the timing of cancellation and modification messages around daily “time cutoffs” in the morning or evening can have a significant impact on whether a trade is reported on a particular day.
Global banks offering delegated trade reporting services to their clients must consider how their IT infrastructures are designed, and whether end-of-day batch runs can be executed in the same environment as intraday reporting. This can cause significant IT system workloads, repeatedly processing and filtering the same data, challenges batching trades properly, and other related challenges.
Although delegated derivatives trade reporting under EMIR may appear to reduce costs for smaller institutions, there are significant issues for both delegating and reporting counterparties. It remains to be seen how these challenges will be handled across the financial industry in the coming years.