UPDATE- SDR-related changes to the ClearPort API / Decommissioning of Many-to-Many Allocation Support

UPDATE- SDR-related changes to the ClearPort API / Decommissioning of Many-to-Many Allocation Support

- To
- CME ClearPort API Users
- #
- 20130104
- Notice Date
- 04 January 2013

NOTICE TO ALL CME ClearPort API (CPAPI) v2.0 users

Date: January 4, 2013

Re: UPDATE- SDR-related changes to the ClearPort API / Decommissioning of Many-to-Many Allocation Support

Please be advised- This is an update to a notice which was originally sent on December 21, 2012 (and again on January 2, 2013) and communicated changes to the ClearPort API, which are currently scheduled for production deployment on Sunday, January 6, 2013 (for the January 7th business date).

The changes mentioned below, with regards to EFS/EOO and EFR transactions, specifically, will be deferred until no later than the February 28th business date. A follow-up notice will communicate the exact production date once it becomes available. The functionality to support SDR submissions and Real-Time Reporting of the bilateral component of EFS/EOO and EFR transactions will remain in the New Release environment and CME Group strongly encourages ClearPort API users to start testing this functionality to ensure there are no negative impacts to their proprietary trading systems, and to be production ready as soon as possible.

Please note- the decommissioning of Many-to-Many allocation support and the SDR-related changes for OPNT transactions are still scheduled for production deployment on Sunday, January 6, 2013 (for the January 7th business date).

These changes are scheduled for deployment to the New Release environment on Wednesday, January 3, 2013:

Decommissioning of support for Many-to-Many Allocations in ClearPort (all Asset Classes) -

Going forward, only one side of a trade can be submitted to ClearPort with allocations (i.e., with the trade quantity split across multiple accounts). If a trade is submitted with multiple accounts on both the buy- side and the sell-side, the trade will be rejected by ClearPort. If a many-to-many allocated deal occurs bilaterally and it’s intended to clear through CME ClearPort, it must be broken into multiple one-to-many allocated trade submissions.

SDR-related changes to support reporting on Credit, FX, and Commodities swap transactions -

The ClearPort API now supports additional fields required for market participants (and service providers to them) to use the ClearPort gateway to send real-time (RT) and/or primary economic terms (PET) to

CME Repository Service (SDR). Swap transactions (as defined by Dodd-Frank) traded on CME’s Designated

Contract Markets (NYMEX, COMEX, CME, and CBOT) or off-exchange markets pursuant to DCM rules which are accepted for clearing will be reported to CME SDR by CME Clearing.

Relevant trades types submitted to CME for clearing which are impacted include OPNT, EFS/EOO, and EFR (in the aforementioned DCMs), with CME Equity Index Futures and CME Equity Index Options on Futures as the only exceptions (participants must report these transactions directly to an approved SDR).

The cleared component of OPNT trades submitted through the ClearPort API will automatically be reported by CME Clearing to the CME SDR. The bilateral component of OPNT trades submitted through the ClearPort API can also be reported by CME Clearing to the CME SDR, if specified. The bilateral component of EFS/EOO/EFR trades submitted through the ClearPort API will automatically be sent to CME SDR. Once accepted for Clearing as a futures position, no further SDR reporting occurs.

New SDR-related attributes and ClearPort API-specific changes for swap transactions -

The ClearPort API will support a number of new attributes to facilitate reporting of cleared swap data by CME Clearing to the CME SDR. The changes will also allow CME SDR Users to report RT and/or PET data on any bilateral swap transaction in the Credit, FX, or Commodities asset classes. Each is listed in the table below with a description of its usage and syntax.

Attribute

Usage

Syntax

Legal Entity Identifiers (LEIs) / CFTC Interim Compliant Identifiers (CICIs)

Inbound (Optional): Can be specified “instead of” or “in addition to” existing firm identifiers (No Src). If “instead of”, the LEI/CICI must be registered for that firm with CME Group.

Outbound (Present): Will appear on outbound trade confirmations for swap transactions. If not specified on the inbound trade submission, a CME- generated identifier will be returned.

New Source “N” on firm Party Role blocks. 20- byte LEI/CICI is specified in the ID attribute.

Example:

Please Note- If a party to a swap trade has not yet registered their LEI / CICI with CME Group, a temporary 20-byte identifier (starting with prefix the “CME”) will be generated for that firm and

will be returned as the LEI / CICI for that firm on outbound trade status reports.

Universal Swap

Indicators (USIs)

Inbound (Optional): Block USI(s) and/or Bilateral USI(s) can be specified optionally.

Outbound (Present): Bilateral USI(s) will be generated (and appear on outbound trade confirmations) if not specified on the inbound trade submission.

Block USI(s) will be generated for one-to- many allocated deals (and appear on outbound trade confirmations) if not specified on the inbound trade submission.

Cleared USIs will be generated (and appear on outbound cleared trade confirmations) as each allocation clears.

Please Note- For multi-leg transactions, USI are leg-specific. See LegNo and RegLegRefID attributes for more information.

A new Regulatory Trade ID block at allocation- level (Bilateral USIs and Cleared USIs for 1-to- many allocated deals) or side-level (Cleared USIs for one-to-one) or trade level (Block USI and/or Bilateral USI for one-to-one). The ID attribute represents the Transaction ID component of the USI and the Src attribute represents the company Namespace component of the USI. The Typ attribute indicates whether it’s the Current USI (0), the Previous USI (1), or the Block USI (2).

Example:

(CPC-generated Bilateral USI for an outright swap)

Please Note- Unallocated sides of one-to-many allocated swap trades will be split into many Alloc blocks on outbound Trade Capture Reports, for the purpose of specifying the Bilateral USIs and Cleared USIs associated with that side.

Leg Number

Inbound (Optional): If specifying USIs on inbound multi-leg swap trade submissions, a unique leg number must be present for each Trade Leg.

Outbound (Present): Leg Numbers will be generated (and appear on outbound

trade confirmations) if not specified on

the inbound mutli-leg swap trade submission.

Example:

</TrdLeg>

</TrdLeg>

</TrdLeg>

Regulatory Leg

Reference ID

Inbound (Optional): If specifying USIs on inbound multi-leg swap trade

Example:

(CPC-generated Bilateral USIs for a multi-leg

submissions, each USI must reference a matching Trade Leg’s Leg Number.

Outbound (Present): A Regulatory Leg Reference ID must always be present on each USI of a multi-leg swap transaction’s outbound trade status report, regardless of whether the USI was generated by ClearPort or not.

swap):

<RegTrdID ID="CPB001004416803TN0000"

Src="1010000023" Typ="1" Evnt="1" LegRefID="2"/>

<RegTrdID ID="CPB002004416803TN0000" Src="1010000023" Typ="1" Evnt="1"

LegRefID="3"

Reporting

Counterparty

Inbound (Optional): Reporting Counterparty designation should be specified on the Reporting Counterparty side.

Outbound (Conditionally Present): Will appear on outbound trade confirmations

if specified on inbound trade submissions.

New Sub Type to Firm Party Role block(s). If Asset Manager or Active Trader side with no firm party role(s) specified, use Account Party Role block(s).

Example:

Example (alternate method):

<Pty ID="Acct_Number" R="24" Src="C"><Sub

Typ="49" ID="Y"/></Pty>

Initial / Bilateral SDR

Inbound (Optional): Initial/Bilateral SDR should be specified on the trade by referencing the LEI/CICI of the Initial/Bilateral SDR.

Outbound (Present): Will appear on outbound trade confirmations. Defaulted to CME SDR if not specified.

New Party Role (102) at the trade level (after trade-level RegTrdID).

Example:

CME SDR CICI: SNZ2OJLFK8MNNCLQOF39

DTCC SDR CICI: MLDY5N6PZ58ZE60QU102

Regulatory Report

Type

Inbound (Optional): Regulatory Report Type should be specified at the trade level.

Outbound (Present): Will appear on outbound trade confirmations. Defaulted to 1 (PET only) if not specified.

New TCR-level attribute (RegRptTyp).

1 = Primary Economic Terms Only (PET)

4 = Real Time Reporting + Primary Economic

Terms (RT/PET)

Example:

Block Trade

Allocation Indicator

Inbound (Optional): Block Trade Allocation Indicator should be specified at the side level.

Outbound (Present): Will appear on outbound trade confirmations. Defaulted to 2 (Allocated Trade) if not specified.

New Report Side-level attribute (BlckTrdAllocInd).

0 = Block to be allocated

1 = Block not to be allocated)

2 = Allocated trade

Example:

Confirmation

Method

Inbound (Optional): Confirmation

Method should be specified at the trade

New TCR-level attribute (CnfmMeth).

level.

Outbound (Conditionally Present): Will appear on outbound trade confirmations

if specified on inbound trade submissions.

0 = Non-electronic

1 = Electronic

Example:

Verification Method

Inbound (Optional): Verification Method should be specified at the trade level.

Outbound (Conditionally Present): Will appear on outbound trade confirmations

if specified on inbound trade submissions.

New TCR-level attribute (VerfMeth).

0 = Non-electronic

1 = Electronic

Example:

Regulatory Time

Stamp

Inbound (Optional): Regulatory Trade Timestamp should be specified at the trade level.

Outbound (Conditionally Present): Will appear on outbound trade confirmations

if specified on inbound trade submissions.

Trade Regulatory Timestamp block at the trade level (before RptSides).

Example:

Execution Venue

Type

Inbound (Optional): Execution Venue Type should be specified at the trade level.

Outbound (Present): Will appear on outbound trade confirmations. Defaulted to O (Off-facility) if not specified.

New TCR-level attribute (VenuTyp).

S = Swap Market/SEF/DCM O = Off-facility

Example:

Execution Venue

Inbound (Conditional Required): If Execution Venue Type is S (Swap Market/SEF/DCM) then the LEI/CICI of the Execution Venue becomes required.

Outbound (Present): Will appear on outbound trade confirmations if specified on inbound trade submissions.

New Party Role (73) at the trade level (after trade-level Initial SDR).

Example:

For additional info, message specs, and message samples please see the ClearPort Implementation Guides located here:

http://www.cmegroup.com/clearing/clearport/clearport-api.html

If you have questions please contact:

Market Operations Technical Support

24 Hour 6 Days a Week Support available from Sundays at 5PM ET to Fridays at 5PM ET

Phone: 800-275-6215 / 212-301-4720

CME Group is the world’s leading derivatives marketplace. The company is comprised of four Designated Contract Markets (DCMs).
Further information on each exchange's rules and product listings can be found by clicking on the links to CME, CBOT, NYMEX and COMEX.

Markets Home

Market Data Home

Services Home

Insights Home

Education Home

UPDATE- SDR-related changes to the ClearPort API / Decommissioning of Many-to-Many Allocation Support