Page tree
Skip to end of metadata
Go to start of metadata

RMI access is only available to clearing firms using a certified application.

1.  Clearing Firms wishing to access the RMI API in production, leveraging their certified application, must create a CME Group Login and submit it, along with the Schedule 6 Exhibit D, to their Global Account Manager. 

  • We recommend use of PROD in the CME Group Login name to distinguish it from any New Release API IDs. For example, API_RMI_CLEARINGFIRM_PROD.

2.  After the API has been entitled, the application will log into: https://rmi.cmegroup.com/rmi/

Customers requesting access to the New Release environment for certification will need to contact Global Account Management.

Clearing Member Firm (CMF) automated risk systems connect to the API using HTTPS user authentication via Web Services. HTTPS version 1.1 supports both session-less and session-based connections. RMI Risk Administrators will be provided an Application level ID and password from their Global Account Manager. CMF risk systems will use this information to populate the appropriate fields of the Logon message for the RMI API.

The Request ID must be incremental across all messages. Any message with a non-incremented Request ID will be rejected with a Business-level Reject with text: “The ReqId must be greater than the previous ReqId”.

Ping Request to the API

To ensure a RMI connection is still active, CMF risk systems can utilize the Ping Request capability. For session-based connections, this feature confirms that the API is available and the risk system is currently logged in. For session-less connections, this feature confirms that the API is available.

CME Group recommends that customers send pings to confirm session or API availability on an as-needed basis, no more frequently than every 20 seconds.

For a session-based connection, the ping request must use the cookie obtained from the Login message, otherwise, the Response message will be an error with the text: “Ping response without active session.” If the cookie for a session is lost, the session becomes unusable, and the user must re-login to receive a new cookie.

Ping Request Message Example

 Risk system ping request to the API using the FIXML User Request message with User Request Type=100:

<?xml version="1.0" encoding="utf-8"?>

    <FIXML v="FIX5.0 SP2" xv="130" s="2010-11-16" cv="CME.1000" xmlns="http://www.fixprotocol.org/FIXML-5-0-SP2">

        <UserReq UserReqID="123461" Username="rmi_test01" UserReqTyp="100">

            <Hdr SID="CMF" TID="CME" TSub="RMAPI"/>

        </UserReq>

    </FIXML>

Ping Response Message Example

Risk systems must specify a Request ID on each request, which is used to uniquely identify the response to its specific request. Below is an example of a Ping response message:

<?xml version="1.0" encoding="utf-8"?>

    <FIXML v="FIX5.0 SP2" xv="130" s="2010-11-16" cv="CME.1000" xmlns="http://www.fixprotocol.org/FIXML-5-0-SP2">

        <UserRsp UserReqID="123461" Username="rmi_test01" UserStat="100">UserStatText="Ping response with active session.">

            <Hdr SID="CME" SSub="RMAPI" TID="CMF"/>

        </UserRsp>

    </FIXML>

RMI Session Based Connection

For a session-based connection, the risk system logs in to begin the session. To end a session-based connection, the risk system must send a logoff request to terminate the session.

Customers may maintain a session-based connection all week (e.g., login on Sunday startup, log off on Friday) with the condition that there must be some activity on that session (such as a ping) within a twelve-hour interval. All session-based connections will be disconnected after the Friday close.

The following diagram shows the message flow for logging in and logging out of the API initiated by the client’s automated risk system on a session-based connection.

Session Based Login Request Message Example

Risk systems logging onto the API use the FIXML User Request message with User Request Type=1. Risk systems must include a Request ID for each request, which is used to uniquely identify the response to its specific request.

User Request Logon message example:

<?xml version="1.0" encoding="utf-8"?>

    <FIXML v="FIX5.0 SP2" xv="130" s="2010-11-16" cv="CME.1000" xmlns="http://www.fixprotocol.org/FIXML-5-0-SP2">

        <UserReq UserReqID="123456" UserReqTyp="1" Username="user123" Password="User!Pass5">

            <Hdr SID="CMF" TID="CME" TSub="RMAPI"/>

        </UserReq>

    </FIXML>

Session Based Login Response Message Example

Login Response message example:

<?xml version="1.0" encoding="utf-8"?>

    <FIXML v="FIX5.0 SP2" xv="130" s="2010-11-16" cv="CME.1000" xmlns="http://www.fixprotocol.org/FIXML-5-0-SP2">

        <UserRsp UserReqID="123456" Username="user123" UserStat="1">UserStatText="Logon Successful.">

            <Hdr SID="CME" SSub="RMAPI" TID="CMF"/>

        </UserRsp>

    </FIXML>

Session Based Logout Request Message Example

Risk systems requesting to logoff use the FIXML User Request message with User Request Type=2.

For a session-based connection, the Logoff request must use the cookie obtained from the Login message, otherwise, the Response message will be an error with the text: “The session cookie is missing from this request.”

Logout request message example:

<?xml version="1.0" encoding="utf-8"?>

    <FIXML v="FIX5.0 SP2" xv="130" s="2010-11-16" cv="CME.1000" xmlns="http://www.fixprotocol.org/FIXML-5-0-SP2">

        <UserReq UserReqID="123464" UserReqTyp="2" Username="user789">

             <Hdr SID="CMF" TID="CME" TSub="RMAPI"/>

        </UserReq>

    </FIXML>

Session-Based Logout Response Message Example

Logout response message example:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<FIXML v="FIX.5.0SP2" xv="130" cv="CME.1000" s="2010-11-16" xmlns="http://www.fixprotocol.org/FIXML-5-0-SP2">

    <UserRsp UserReqID="123464" Username="user789" UserStat="2" UserStatText="Logged off">

        <Hdr SID="CME" TID="CMF" SSub="RMAPI"/>

    </UserRsp>

</FIXML>

Session-Less Connection

For a session-less connection, the risk system must send its credentials in the header of each message for every message sent to the API. The username and password must be typed with a colon separating the two (i.e. username:password) and then convert from string to base64.

The following is an example entry in the header:

Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

Session-Less Request Message Example

The following message example details a client request to access the API on a session-less connection.

POST /webservices/gateway HTTP/1.1

Host: www.cmegroup.com/RMAPI;443

Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

Content-Type: text/xml

Content-Length: 311

Connection: close

(followed by a new line, in the form of a carriage return followed by a line feed)


<?xml version="1.0" encoding="utf-8"?>

    <FIXML v="FIX5.0 SP2" xv="130" s="2010-11-16" cv="CME.1000" xmlns="http://www.fixprotocol.org/FIXML-5-0-SP2">

        <PtyEntlmntDefReq ReqID=”123”>

            <Hdr SID="CMF" TID="CME" TSub="RMAPI"/>

            <PtyEntlmntUpd ListupdActn=”M”>

                <PtyDetl ID=”330” R=”1”>

                    <ReltdPtyDetl ID=”123456” R=”24”/>

                </PtyDetl>   

                <Entlmnt Ind=”N” Typ=”0” ID=”123”>

                    <AttribTyp=”4000” Value=”1”/>

                    <InstrmtScope Oper=”1” SecTyp=”FUT” SecGrp=”NN”/>

                </Entlmnt>

                <Entlmnt Ind=”N” Typ=”0” ID=”123”>

                    <AttribTyp=”4000” Value=”2”/>

                    <InstrmtScope Oper=”1” SecTyp=”FUT” SecGrp=”NN”/>

                </Entlmnt>

            </PtyEntlmntUpd>

        </PtyEntlmntDefReq>

    </FIXML>

Session-Less Server Response Message Example

The following message example details the API’s response to the client automated risk system’s session-less request.

HTTP/1.1 200 OK

Server: HTTPd/1.1

Date: Fri, 3 June 2011 10:19:07 GMT

Content-Length: 10476

Connection: close

Content-Type: text/xml

(followed by a new line, in the form of a carriage return followed by a line feed)


<?xml version="1.0" encoding="utf-8"?>

    <FIXML v="FIX5.0 SP2" xv="130" s="2010-11-16" cv="CME.1000" xmlns="http://www.fixprotocol.org/FIXML-5-0-SP2">

        <PtyEntlmntDefReqAck ReqID=”123” ReqStat=”0” ReqRslt=”0”>

            <Hdr SID="CME" SSub="RMAPI" TID="CMF"/>

        </PartyEntlmntDefReqAck>

    </FIXML>

All risk management services are offered by CME Group on a best-efforts basis. Clearing Member Firm (CMF) Risk Administrators only have access to the Execution Firms and Exchanges that they guarantee. Any attempt to take action on an Executing Firm and Exchange assigned to a different CMF will be rejected.