This topic provides guidance for firms participating in the CME Group portfolio margin of interest rate swaps/futures program to migrate to a CME-hosted Optimization model.

This topic covers high level impacts to assist users in understanding and scheduling system changes.

Contents

Revision History

Portfolio Margin Program and Optimizer Service

The portfolio margin program is designed to provide margin efficiencies across a single legal entity by identifying listed interest rate products which can offset cleared swap IRS market risk. The program aims to reduce the combined risk of the segregated and cleared swaps account.

Running the Optimizer software is the mechanism clearing firms use to optimize portfolio risk. Prior to 2025, all participating Clearing Members used the CME Group Optimizer software installed in their infrastructure. Optimizer software evaluates the ideal allocation of interest rate futures and options to transfer between segregated and OTC accounts to provide margin efficiencies. As an output, Optimizer generates transfers, each having two sides (buy and sell) which are booked at CME Group using standard Clearing Firm message queue setup.

Additional program details are available in Portfolio Margining for OTC Interest Rate Swaps.

Hosted Optimization

To alleviate operational burdens and improve efficiency, in 2025 CME Group is offering a new optimization mechanism which is hosted on CME Group infrastructure and available to users exclusively over the CME CORE API Service. This new service will continue to leverage the capabilities available in the Optimizer software, but is available over the CME CORE API, a web-based API accessible over the internet.

Impacted Systems and Processes

The following changes are relevant to Clearing Members who choose to participate in the Portfolio Margin program.

User Entitlements and Onboarding

Hosted Optimization requires new entitlements to ensure only authorized users are able to interact with cleared Optimization workflows. Authorization occurs at the user, firm and margin account level. Users will need to set up a service account with an API ID that will be entitled to the new workflow.

Service Account Creation and Entitlement Process

1. Create an Account (If Applicable): If you don’t already have an account, please register.

2. Generate an API ID: Go to My Profile > My Account > APIs, then create and claim an API ID under Auth Type=”Basic Auth”.

   1. The API ID used for the Margin Optimization Service must be dedicated solely to the new workflow. Users with an existing API ID should create a new one for this purpose.

3. Submit the Request Form: Complete the request form available here and enter your newly created API ID. Ensure you click ‘Submit’ to initiate the entitlement workflow at CME Group.

4. Verification Process: The Enterprise Application and System Entitlements (“EASE”) team will contact the CME ClearPort Verification Officer designated for your firm to confirm access authorization for clearing data usage in the service.

5. Onboarding Completion: Upon successful verification, the CME Group post trade services team will reach out to finalize the onboarding process. As part of this process, they will ensure the API ID is entitled to the CORE API, which is a mandatory general authorization step.

Non-authorized users will receive an authorized error with the code 401 or 403 if attempting to interact with Optimization workflows. See Error Handling.

When testing, please note authentication and entitlement follows the same Basic Auth pattern as the CME CORE existing API, which is described in Margin Service API - Authentication and Entitlement.

API URL

The Optimization service will utilize the CME CORE post trade URLs. 

Test Environment:

https://posttrade.api.uat.cmegroup.com/MarginServiceApi/

Please contact the CME post trade service team regarding the production environment URL after completion of testing.

Service endpoints are described in the User Interface section.

Testing Expectations

• UT environment testing (expected testing: functional):

  • Testing may be available for a limited set of available dates and cycles. Users can interact with the ‘status’ endpoint, described below, which provides detail on which dates and cycles are available for Optimization. Users may experience errors when submitting requests for dates and cycles that are not available.

  • The UT environment is not a production copy. This is important because the service performs account validation from UT environment data and will flag accounts as invalid that are not set up in the test environment or have no IRS trades in the test environment. It is recommended that users build their positions data with test accounts matching CME Group test accounts. If that is not possible, please work with posttradeservices@cmegroup.com to ensure there are accounts enabled in the UT environment that match production identifiers and, as needed, contain IRS trades to limit account validation errors. Please request a maximum of five new test accounts.

  • The UT environment is not expected to be used for number matching against the deployable Optimizer software in production. Please see production environment testing below.

  • The UT environment is expected to be the sole environment for testing the ‘accept transfers’ endpoint (see below), since this workflow pushes live transfer records to the clearing system. All other upstream workflows prior to the transfers endpoint can also be tested in production, see production environment testing below.

• Production environment testing (expected testing: number matching):

  • Users can interact with the production environment for testing by simply eliminating the ‘accept transfers’ endpoint portion of the workflow - all upstream endpoints can be used for informational or testing purposes and do not impact cleared trades. This is consistent with legacy testing of the deployable Optimizer software where it was recommended to test with a combination of test and production inputs, depending on the use case and scope of release.

  • The production environment should be used for number matching against the deployable Optimizer software. UT environment data is independently produced and not validated against production, making it an unsuitable alternative. If number matching is only allowable in the UT environment, please validate against the UT environment IRSMR3 margin report or a run of deployable Optimizer with only test environment data to ensure consistency.

Expected Inputs

*These files will continue to be produced but are not required to be passed as inputs to the hosted Optimizer service.

**These files are no longer produced by CME Group.

Clearing Members are expected to continue producing the Optimizer’s input Positions.csv and Configuration.json files and to maintain the state of portfolios in their books and records. No format changes are expected for these file payloads, please see example request messages.

Aside from Positions payload(s) and configuration data, Clearing firms are not expected to supply any other Optimizer inputs (i.e. marketdata_optimizer_cme, IRSDL, IRSPNL). Firms that are currently consuming these files can discontinue consuming these files when live with the new service.

Expected Outputs

User Interface

The existing CME CORE API service has been expanded to support the hosted optimization process. The test URL can be found in the API URL section above. In conjunction with CME Group and wider industry standards only secure communication channels are used. 

The following new API endpoints support hosted Optimization:

Hosted Optimization User Workflow Diagram

Hosted Optimization User Workflow Examples

1. Submit Optimize Request

Request Endpoint

Sample Request

Sample Response

The report contains:

• The Optimizer id (id in the 'portfolio' block). 

  • Note: this id has a one-to-one relationship with the user input payload, not the Optimized account. There can be many accounts in a single Optimize request payload or one, depending on the users’ preference.

  • In the example below the ID is this string: 123456e1-12b3-123z-a0cf-12ee3ee5e56d

• The FIXML trade capture for all positions in the payload.

• Position-level errors, for instance validation errors.

2. Optimized Reports

As part of the hosted optimizer service, two reports represent the most commonly used deployed Optimizer software reports.

All Optimizer reports are requested via GET messages to report endpoints containing the Optimize ID provided in the Optimize POST response above.

Report 1: FIXML Transfer Report Request Endpoint

Sample Request

Sample Response

The report contains a header with the following information: 

• Cycle date and cycle type

• Transfer records in FIXML format.

  • All transfer messages will be single-sided to comply with standard CME Clearing transfer message processing.

Report 2: Estimated Savings Report Request Endpoint

Sample Request

Sample Response

The report contains:

• Three margin states for each portfolio, expressed for both the F&O account and the IRS account:

  • Pre-optimization state (all F&O positions in SEG).

  • Current state: before position netting.

  • Post-Optimization state.

• Change in margin (savings), in dollar and percentage terms.

• Margin account IDs (PbAcctId) for all optimized accounts

• Clearing firm ID (clrMbrFirmId)

Mapping table of Optimizer software Estimated Savings Report to API estimated savings report.

Note additional fields are present as compared to the csv version of the report and it is also, therefore, a suitable replacement for the Margin Summary csv report.

Sample Response

3. Submit Transfer Request

Users can optionally choose to submit a request to a transfers endpoint. When triggered, the Hosted Optimization platform will submit the transfer records to Front End Clearing system.

Sample Request

Sample Response

The report contains a header with the following information: 

• Cycle date and cycle type

• Transfer records in FIXML format.

  • All transfer messages will be single-sided to comply with standard CME Clearing transfer message processing.

4. Status Request

This endpoint checks for the available date and cycle for which user can submit optimization request.

Sample Request

Sample Response

The response contains the following information all the available cycles:

• Code

• Date

Error Handling

The Optimization workflow is asynchronous and can result in errors in response to user requests at all three steps of the workflow (shown in 7.1 above).

Here are examples of errors for all user requests:

Errors - Optimize All-in-One Request

All below errors can be observed in response to the Optimizer all-in-one endpoint above.

Errors - Report Requests

The following table describes errors that may be encountered while interacting with report GET endpoints.

Errors - Transfers Endpoint

The following table describes errors that may be encountered while interacting with the Transfer endpoint.

Operational Timeline

The below timeline highlights the expected period for nightly optimization via the hosted Optimizer service.

The days users can expect optimization include all U.S. calendar days excluding weekends and January 1 holiday.

• Clearing firms can choose whether to Optimize on all other U.S. holidays, similar to the existing process, and should note running on a U.S. holiday will utilize T-1 risk data.

Expected daily optimization timeline, no delays:

Open

Expected daily optimization timeline, with upstream delays:

Open

Expected daily optimization timeline, with firm extensions:

Open