Page Comparison

CME GC Allocator API is a JSON RESTful API that provides support for General Collateral (GC) Repo customers to manage their post-trade GC allocations and substitutions.

GC Repos are a type of Repo transaction that trade trades against a specified “basket” of underlying collateral. Post-execution, the GC Repo seller allocates the specific piece(s) of collateral from the “basket” to fulfill the GC trade obligation. Upon allocation, the value of the GC trade obligations for cash considerations are determined.

...

For US and EU Repos on GC Allocator API, the InstrumentGUID for AON instruments is always retained.

Revision History

...

A registered OAuth API ID is required to access the CME GC Allocator API Allocator API services. API IDs for CME Group Logins are created and managed in the CME Customer Center under My Profile.

New Clients

New clients - should start by Creating a CME Group Login.

• Once a client creates and activates their CME Group Login ID, they can login to CME Customer Center under My Profile and create an OAuth API ID.

Clients with Existing CME Group Logins

• Clients with existing CME Group Login ID can login to CME Customer Center and under My Profile create an OAuth API ID.
• Clients with existing CME Group Login ID and existing Basic Auth API ID can convert the Basic Auth API ID to an OAuth API ID under the API Management section of the CME Group Login under My Profile.

Contact For CME GC Allocator API access and more information, contact Global Account Management (GAM) for CME GC Allocator API access and more information.

Testing and Certification

Certification is required for GC Allocator API Allocator API services. Please contact Certification Support for Electronic Trading (CSET).

...

Roles are required for CME GC Allocator API.

• GC Allocator API Allocator API - - Allocator (Trader/Clerk)
• External Workstation - Allocator (Trader/Clerk)
• External Workstation - GC Allocator Viewer

...

System Availability

CME GC Allocator API is available in Production beginning 12:05 PM Central Time Sunday afternoon through 9 PM Central Time Friday. 

...

For GC Repos - underlying price override is applicable to allocations of a GC Repo Trade; once allocations are cancelled canceled by the GCC (Global Command Center), the trade remains unallocated and reallocation can then be enacted by GCC via a customer request.

...

1. Customer 1 notifies their counterparty of an intent to substitute the allocation they made previously, by submitting a POST to /notifications, using a CollateralNotificationRequestMessage to indicate which allocation, and what quantity will be substituted; gets back an HTTP 200 (OK) with a CollateralNotificationResponseMessage showing their notification.
2. Customer 2 polls for notifications, by submitting a GET request including the AcknowledgementStatus parameter to /notifications/search?acknowledgementStatus=NOTIFIED; gets back an HTTP 200 (OK) with a CollateralNotificationResponseMessage indicating the allocation on which Customer 1 submitted their notification, as well as an identifier for the notification itself. 
   

   Info
   The two customers will receive different notificationGuids.

3. Customer 2 acknowledges notification by submitting a POST to /notifications/acknowledgements/, using a CollateralNotificationRequestMessage to indicate which allocation's notification they were responding to; gets back an HTTP 200 (OK) with an updated CollateralNotificationResponseMessage record
   

   Info
   A notification must be sent prior to a substitution, but it is not required that the notification be acknowledged.

4. (Optional) Customer 1 searches for acknowledged notifications by submitting a GET request including the AcknowledgementStatus parameter to /notifications/search?acknkowledgementStatusacknowledgementStatus=ACKNOWLEDGED; gets back an HTTP 200 (OK) CollateralNotificationResponseMessage with their allocation, showing that their notification has been acknowledged (NOTE: because acknowledgement is not required prior to substitution, this field will be set to ACKNOWLEDGED on the seller's side as soon as the notification is submitted).
5. Customer 1 substitutes their allocation by submitting a POST to /collateral/substitutions/, using a CollateralRequestMessage to define the substitution; gets back an HTTP 200 (OK) with links to the original allocation, the substitution, and the remaining allocation if appropriate.

...

1. Customer contacts the Global Command Center (GCC) and requests the cancellation of a GC Trade allocation.
2. The GCC cancels the GC Trade allocation and sends the Notification Request message to indicate the cancellation; receives an HTTP 200 (OK) with a Collateral Notification Response Message showing the notification.
3. Customer polls for notifications by submitting a GET request including the Acknowledgment Status parameter to /notifications/search?acknowledgementStatus=NOTIFIED; receives an HTTP 200 (OK) with a Collateral Notification Response Message indicating the allocation on which GCC submitted cancellation.
4. (Optional) Customer requests GC Trade allocation for the previously cancelled canceled GC allocator.
5. GCC allocates collateral by submitting a POST to /collateral, using a Collateral Request Message specifying their allocation; receives an HTTP 200 (OK) with a link to the allocation
6. Customer polls for notifications, by submitting a GET request including the Acknowledgement Status parameter to /notifications/search?acknowledgementStatus=NOTIFIED; receives an HTTP 200 (OK) with a Collateral Notification Response Message indicating the allocation on which GCC submitted their notification, as well as an identifier for the notification itself.

...