CME GC Allocator API

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 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.

The CME GC Allocator API supports the following functions:

• All GC Repo Customers can search and retrieve GC Repo trades and associated allocations for their firm on demand

• GC Repo sellers may view and submit GC allocations and substitutions for their firm’s trades

• GC Repo buyers may view GC allocations and substitutions for their firm’s trades

• Underlying Bond Price Override for GC Repo Trades

Support for GC Substitutions is permitted for the U.S. market only.

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

Onboarding

CME GC Allocator API uses OAuth, an open protocol that supports secure authorization in a simple, standard method and decouples authentication from authorization.

See: Client API Service Adoption using OAuth 2.0 Protocol

Authorization

A registered OAuth API ID is required to access the CME GC 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 > My Profile to 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.

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

Testing and Certification

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

Roles

Roles are required for CME GC Allocator API.

• GC Allocator API - Allocator (Trader/Clerk)

• External Workstation - Allocator (Trader/Clerk)

• External Workstation - GC Allocator Viewer

Connectivity

GC Allocator API Connectivity

Internet Connectivity

Dedicated Connectivity

Customers connecting to the CME GC Allocator API via dedicated connectivity will be required to manage failover between primary and secondary regions in their client systems using the URLs and IPs in the table above.
As a convenience, CME also provides the following URLs which are managed by CME to always point to the correct IPs (primary or secondary) based on current environment conditions:

• Production: posttrade-ll-btec.api.cmegroup.com/gca/v2

• New Release: https://posttrade-ll-btec.api.uat.cmegroup.com/gca/v2

GC Allocator UI Connectivity

To access the GC Allocator UI, Customers must authenticate via the Single Sign-On (SSO) portal where whitelisting of the SSO portal IP listed below may be required.

System Availability

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

Functional Specification

Allocations

For both U.S. and EU markets, GC Repo sellers may submit trade allocations for their firm’s trades. GC Repo trades are subject to submission deadlines and validations.

Substitutions

Substitutions are available for a subset of GC Repo instruments in the U.S. Market only. GC Repos can be traded with ‘rights of substitution’ (pre-listed or custom). Substitutions allow the GC Repo seller to recall and replace collateral from active allocations.

Upon substitution, the cash considerations and principal value of the collateral of the trade are re-established.

Underlying Bond Price Override for GC Repo Trades

Cancels and amends are considered "top day" while the markets are still open for the same business date.

Underlying price override is enacted when the bond is not priced correctly or is null for an untradeable instrument.

Underlying bond price override only applies to EU Repos.

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

Validations

Validations are performed on allocations and substitutions for: type of underlying instrument, time, price, quantity, rights of substitution, and number of collateral (trades can have a maximum number of different bonds allocated to them). 

Alerts and Warnings

Alerts and warnings are sent for various events, including:

• New GC Repo trades executed on Global Front End Application (GFE)

• Unallocated GC Repo trades approaching allocation deadline

• New GC Repo trade allocations

• Notification of intent to substitute

• GC Repo trade substitutions

• Trade Collateral approaching its maturity date (U.S. markets only)

Timers

Soft and hard deadlines are set for allocations and substitutions.

Timestamps

All timestamps have microsecond precision.

Scenarios

Scenario One -  Customer Allocation

In this scenario, a customer searches their firm's trades for those which are not allocated, and then look up and allocate valued collateral.

1. Customer searches their firm's trades for those which have not been fully allocated by submitting a GET request, including Status parameters to the endpoint:
   Individual search requests for collateralStatus=NONE and/or PARTIAL
   Search:
   - /trades/search?collateralStatus=NONE
   - /trades/search?collateralStatus=PARTIAL
   Return: HTTP 200 (OK) with a TradeResponseMessage in response for each request.

2. The Customer looks up the collateral allocations for one of those trades by submitting a GET request including the Side GUID to the endpoint /collateral/trades/ABC123; gets back an HTTP 200 (OK) with a CollateralResponseMessage with one allocation.

3. Customer looks up valid collateral for the general collateral on the repo instrument by submitting a GET request including the Side GUID to the endpoint /instrument/trades/ABC123; gets back an HTTP 200 (OK) with an InstrumentResponseMessage listing all eligible underlying collateral.

4. Customer allocates collateral by submitting a POST to /collateral, using a CollateralRequestMessage specifying their allocation; gets back an HTTP 200 (OK) with a link to the allocation.

Scenario Two - Customer Substitution

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 1 submitted their notification, as well as an identifier for the notification itself. 

    

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.

    

4. (Optional) Customer 1 searches for acknowledged notifications by submitting a GET request including the AcknowledgementStatus parameter to /notifications/search?acknowledgementStatus=ACKNOWLEDGED; gets back an HTTP 200 (OK) CollateralNotificationResponseMessage with their allocation, showing that their notification has been acknowledged.

6. 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.

Scenario Three - Underlying Bond Price Override for GC Trades

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 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.