Meeting Date:
Thursday, January 17, 2013
CFTC Staff:
Nancy Doyle, Salman Banaei, Clay Pederson
Organization(s):
ICAP
External Attendees:
Patrick McCarty, Mark Beeston, John Nixon
Additional Information:
ICAP came to discuss its January 16, 2013 comment letter, and continuing request for some form of no-action relief. ICAP intends to register as a SEF operator, but observes that there is a part of its business that, despite the obvious advantage of SEFs, is not a viable means of reducing system-wide basis risk. It is concerned that in the absence of no-action relief, the SEF rule will disturb if not eliminate an important venue for market participants.
ICAP says the SEF rules should address “true trading activity” are ill-suited to the swap transactions that result from ICAP:’s “bulk risk mitigation services.” ICAP’s RESET and REMATCH do basis risk reduction services, and have existed for over 10 years, providing hundreds of trillions of dollars of valuable risk reduction benefits to swap market participants. Those services involve a computer used to do something similar to compression of episodic risk on interest rate bases for large swap dealers. Under the system, there is non-continuous, non-real time, non-negotiated, non-discretionary, unilateral portfolio risk reduction exercise. Translation: participants announce to ICAP’s BRMS system what risk they want to offload, and commit to participation in whatever deal is dealt to them, and then ICAP’s computer matches up swap deals internally in a daisy-chain of multi-lateral deals, where things are offset internally and the result non-offset risk of all the trades is all that sees the market.
There is a resulting trade out of all of it that does see the market – the net of the risks that are not offset. ICAP says it would be actually distortional to the market, and not reflective of true price, to report all the non-discretionary trades, and if parties had to bring all the multi-lateral trades to market, it would be prohibitive expensive for them to do it and they would probably just sit on more risk, which is counter to the goals of Dodd-Frank.
ICAP observed that reporting all of its (essentially) compression trades to the market will not only not help create a true price or price transparency, but might very well confuse the market or permit other market participants to take advantage of the ongoing price compression activities, which happen over a period of time, thus exposing participants in ICAP’s risk mitigation matching system to price changes and making this form of risk mitigation uneconomic for its customers.
ICAP proposes that the transactions generated as a result of its basis risk reduction services not be required to be executed on a SEF. They argue that these transactions are not arms-length transactions, are not negotiated, are not price-forming, and are generated by a service designed for risk reduction, not risk assumption. ICAP’s system amends existing exposure for short periods of time, and is ill-suited to a trader seeking to put on new material risk. They emphasized that in their view, no one is really “trading,” and ICAP needed the Commission’s assistance to ensure that its valuable service could continue to do risk reduction for market participants.
ICAP representatives said that if the CFTC were disinclined to exempt these activities entirely from the SEF rule, the CFTC could give it 6-12 months of a safe harbor while the CFTC further considers the matter. It also expressed interest of whether the trade that results from its computer-based system could be viewed as a block trade so that it does not go into the central order limit book.
ICAP observed that the Commission had permitted other exemptions from mandatory clearing, such as for end-users and inter-affiliates. It stated that it needed relief before or at the time the SEF rule came into place. It observed that the Commission could specifically reserve its antifraud and anti-evasion authority and put on other regulatory or oversight conditions as it saw fit.
ICAP emphasized that even if the Commission requires transactions generated by its matching system to be executed on a SEF, it should adopt a block-trade-like rule that will permit execution always from the SEF, in essence.
