US Equities

Document Version 1.1
Document Date October 13, 2020

This document is an FAQ maintained by the MEMX Member Experience and Market Ops teams.

Getting Started Trading

What are the general steps required to become a Member?

  1. Establish network connectivity
  2. Complete the MEMX Member Application & Submit Documentation
  3. Initialize and Setup the MEMX Operations Portal
  4. Platform/MDE Testing
  5. Formal Certification

What is the on-boarding process for Extranet Providers?

MEMX partners with approved network providers that operate financial extranets that aggregate multiple customers. They typically provide low cost, value-added services including connectivity for the MEMX exchange, order entry facilitation, and receipt of multicast market data. Approved Extranet Providers will be listed on our User Portal, including provider contact information and a link to the firm’s website. In order to be approved as and maintain status as a MEMX Extranet Provider, the provider is required to meet and maintain certain requirements, including monthly reporting obligations.

Can one become a market data subscriber without becoming a Member?

Yes, market data can be consumed by entities other than exchange members, or prior to exchange membership.

Membership Application

What are the application steps for a new trading member?

  1. Collect information. Member goes to our on-boarding site at and completes the on-boarding process.
  2. Generate documents. The system uses the collected information from the on-boarding process to pre-populate the on-boarding documents.
  3. Collect electronic signature(s). MEMX sends completed documents to users for electronic signature by Authorized Signer(s).
  4. Email approval. MEMX will email the Authorized Signer that all documents have been received and are in good order.
  5. Members send supporting documents when appropriate. Broker-Dealers applying for membership also need to send a set of supporting documents.

What are the minimum document requirements to become a member?

  • Member Application
  • User Agreement
  • Router Agreement
  • Clearing Letter
  • Connectivity Services Agreement

What additional services are available that require further documentation?

  • Sponsored Access Application
  • Market Maker Application
  • Service Bureau Application
  • Extranet Application
  • Market Data User Agreement

What is required to become a market data subscriber only?

Complete a Market Data User Agreement and request connectivity for distribution of the data.


Which data centers host the MEMX exchange?

MEMX has a data center presence in Secaucus NY4, Chicago ORD1 and Chicago CH1. The primary trading platform is in the NY4 Secaucus data center and secondary data center is in Chicago. MEMX equalizes latency for order entry and market data dissemination to all participants in the NY4 location, but does not equalize from NY5. MEMX supports connectivity via direct cross-connects, Extranet Providers and Telco Providers.

Facility Primary DR UAT Equalization Address
Equinix NY4 Yes No Yes Yes 755 Secaucus Rd, Secaucus NJ 07094
Cyxtera ORD1 No Yes Yes No 350 E Cermak Rd, 7th Fl Chicago IL 60616
Equinix CH1 No Yes Yes No 350 E Cermak Rd, 5th Fl Chicago IL 60616

What connectivity methods are available?

Users may choose any of the following access methods:

  • Direct Colocation Connection (DCC)
  • Telco Provider
  • Extranet Provider

Further details on connectivity are available in the xNET Connectivity Specification available at

What kind of physical connectivity will be offered to access MEMX?

All user DCC network connections must be single mode optical fiber. The xNET supports 10G, 25G, 40G, and 100G Ethernet interface types. 40G may only be provisioned as a 4 X 10G Ethernet port-channel. 100G may be provisioned as a 4 X 25G Ethernet port-channel or a 1 X 100G Ethernet interface. The connection termination will be dictated by the choice of Ethernet interface selected.

For resiliency, MEMX requires participants to connect through redundant “A” and “B” feeds and DCC connections are provisioned in A/B pairs. Each A/B connection pair terminates at different network devices at the xNET. A/B path diversity for multicast data distribution is required and maintained regardless of user interface configuration or preference. It is recommended that users advertise their source networks on both interfaces for maximum redundancy.

Both order entry and market data will be available over a single connection. Everyone will have the fastest path to our markets. We will offer a level playing field for everyone and never charge a higher fee for faster access to our markets.

What are the steps to begin network connectivity testing?

Trading on MEMX

What technical specifications are available?

Technical specifications are available at and include the following documents.

Protocol Description
MEMX-TCP A Session Level TCP-based transport protocol for reliable delivery of business messages. 
MEMX-UDP A Session Level UDP-based transport protocol for best-effort delivery of business messages. 
MEMO SBE The native binary protocol used for order submission on MEMX. 
MEMO FIX The Classic FIX (ASCII Tag/Value) protocol used for the exchange of information related to securities transactions on MEMX. 
MEMOIR Depth A real-time full depth-of-book feed offered directly from MEMX. 
MEMOIR Top A real-time top-of-book feed offered directly from MEMX that provides the best bid and best offer on the exchange. 
MEMOIR Last Sale A real-time trade feed offered directly from MEMX that provides reporting, cancellation and correction of exchange executions. 
Drop Copy A Drop Copy in Classic FIX protocol providing information related to trades executed on MEMX.

What order entry protocols are supported?

Participants will electronically access the exchange using Classic FIX (ASCII Tag/Value) and/or a native binary protocol called MEMO (MEMbers Orders). A common message standard and data schema is used for both. These protocols will allow members to submit, modify, and cancel orders, receive acknowledgments and execution reports, and be notified of exchange trading status. Technical specifications are available at

Why did you choose FIX 5.0, and why don’t you support FIX 4.2?

We chose FIX 5.0 SP2 for two main reasons. First, in keeping with our desire to move the industry forward, we wanted to use the latest version of the FIX standard which originally came out in 2006 (it was updated with service pack 2 in 2009). While FIX 4 is in wide use, it is nearing the two-decade old mark and has material architectural shortcomings as well as significant accidental complexities common for something that old. Secondly is the architectural change in FIX 5.0 that addressed what we believed to be the main issue in FIX4, the introduction of the Transport Independence Framework. This construct, called FIXT, decouples the FIX Session and Application layers, allowing application messages to be sent over any viable transport technology, one of which is the FIX Session Protocol. Said another way, the classic FIX Tag/Value formatted messages do not need to be sent using the FIX Session protocol. One can also send these messages over a simple TCP connection for example, something that we do with external (like NSCC) integrations.

FIX 5.0 also allows us specify a common data schema for our MEMO order entry protocol and use that schema for both the SBE and FIX versions of MEMO. This eases the migration from FIX to binary if firms desire. If your platform currently adheres to the FIX 4.2 standard, you can use our schemas, refactor your application logic and then bolt on your FIX 5 engine of their choice for transport. “FIXT” is the label used to identify the separate session layer specification and to identify the FIX Session version being used. 

What market data protocols are supported?

MEMX data products include Depth, Top of Book, and Last Sale, as well as historical versions of each. Participants will be able to consume MEMOIR (MEMber’s Order Information Record) data products via a streaming multicast protocol, TCP/IP (Transmission Control Protocol/InternetProtocol), and through the use of modern APIs in the cloud for historical products. Technical specifications are available at

Does MEMX provide pre-trade risk controls on incoming orders?

Yes, MEMX provides a system of integrated pre-trade risk management to help participants monitor and control their interactions with the exchange. All incoming orders are processed against a set of risk filters designed to help prevent erroneous orders. These controls are dynamically configurable by members and can be assigned to an individual session, or an aggregated set of sessions in a group. The risk checks are applied in a consistent manner to all participant orders in order to mitigate risk without incurring latency disadvantage.

What trading controls does MEMX offer to its Members?

  • Order size
    • Maximum notional value per order
    • Maximum shares per order
    • Percent of average daily volume of a security including the ability to specify the minimum average daily volume of the securities for which such control will be activated.
  • Price of an order including percentage-based and dollar-based controls.
  • Restrict trading
    • By trading session (pre-market and post-market)
    • Easy to Borrow Lists
    • Restricted symbol list
    • Block ISO
    • Block short sale orders
    • Only allow trading in test symbols
  • Duplicate orders
  • Overall rate of orders
  • Credit controls measuring both gross and net exposure that warn when approached and, when breached, prevent submission of either all new orders or Market Orders only.
  • Functionality that permits Users to block new orders submitted, to cancel all open orders, or to both block new orders and cancel all open orders. Furthermore, the Exchange offers risk functionality that automatically cancels a User’s orders to the extent the User loses its connection to the Exchange.
  • Self trade prevention

Does MEMX support mass cancels?

Yes, mass cancel functionality is in the MEMO spec and is accessible via the MEMO port. It is called MassCancelRequest. MEMX supports the canceling of an order via any active MEMO SBE session regardless of the session that the original order was transmitted on. Additionally, this flexibility allows MEMX to offer a batch cancel function, via any active session which can be used by a participant to cancel all or a subset of its orders in one or more symbols with a single command to the Exchange. Members can use this facility as a “purge port” or for other mass cancel type functions. 

What are the fees for connecting and market data?

Initially, there are no fees charged for physical connectivity, logical ports or market data. There will always be transparency around our costs, and we will always charge a fair and reasonable cost for our services.

What are the transaction fees for MEMX?

MEMX operates a maker-taker model (rebate to provide/fee to remove liquidity). Our fee schedule is posted at

Which order types and modifiers will be supported?

MEMX accepts three order types (market, limit, pegged), six modifiers (ISO, reserve, non-display, post only, book only, re-pricing) and five time-in-force instructions (IOC, FOK, Day, RHO, GTT). Review the MEMX Rule Book for more details on order type functionality.

Does MEMX route to away markets?

MEMX Execution Services LLC, a registered broker-dealer pending regulatory approval, will route to away markets displaying protected quotations to comply with Reg NMS. A combination of proprietary exchange data feeds and CQS/UQDF data feeds from the Securities Information Processors (SIPs) will be used for the decisions regarding when and where to route orders.

NOTE: Routing is not currently enabled on the exchange.

Does MEMX provide directed routing to other markets?

No, MEMX will route as described above in compliance with Reg NMS but does not have order types or routing strategies for directed routing to away markets.

What symbology is used?

MEMX uses the CMS symbol convention which separates the root and the suffix.

Protocol Details

MEMO (MEMbers Order)

What is the difference between Replay and Stream modes?

The mode is defined by the configuration of the port and is advertised to the client after login. The current protocol specification provides more in the “Request Modes” section.

Is it possible to have both Replay/Stream behaviors for the same session?

No, a server (i.e. – a session) operates in one mode only per the current specification. Depending on the service being recovered, the recovery server will be in either streaming or replay mode. e.g.: MEMO will always be conducted over “streaming” mode, while MEMOIR multicast feeds will offer a gap recovery “replay” mode server.

Please explain exchange matching engine failover and how it affects my session connectivity.

Order entry sessions do not connect directly to a matching engine, as such a matching engine failure should not affect a customer’s order entry or market data connections. Should a matching engine fail, any orders sent during the failure will be rejected via MEMO. Market data feeds will also continue to operate. 

What if my MEMO Port fails?

Should a MEMO Port fail (e.g.: hardware failure), the MEMX team will take appropriate action to recover the port.  Customer’s will reconnect on the same IP address/port to the recovered MEMO port. Any messages missed messages can be replayed allowing customers to continue from the point of failure. The same would hold true for market data feeds.

Can I start a session with an old identifier?

The start of session message will always send a new and unique session identifier. While the specification does allow a previous session identifier to be sent in the streaming or replay request, MEMX does not currently plan to support the replay of previous sessions. Should the replay of a different/previous session identifier be requested a “Stream Rejected”/”Replay Rejected” message with error code “P” will be transmitted in response.

How many sessions does a MEMO port support?

Most MEMX-TCP servers will accept only one concurrent connection from a client.

Is disconnecting the TCP session equivalent to a graceful logout?

Yes, disconnecting from the TCP server is the accepted procedure for logging out as stated in the current specification: “Once the client no longer wishes to receive messages, the client should initiate a TCP disconnection.”

Should I expect heartbeat messages at regular intervals regardless of other messages on the connection?

No. You should treat the receipt of any message from the server as a heartbeat for the purposes of keeping the connection alive, and the server will not send heartbeats unless no messages have been sent within the heartbeat interval. Per the specification: “Any message counts as a heartbeat for the purposes of keeping a session alive.”

For the provision of CMS symbology, will an appended suffix within tag 55 be rejected?

Yes, MEMX will reject if tag 55 contains both the symbol and the suffix.

Will the exchange reject a new order on the receipt of a duplicate ClOrdID?


The spec identifies a reason for a cancel reject as duplicate order ID, but not new order reject?

The early preview specification is currently missing several reasons, additional reasons will be provided in the next version.

For Cancel requests the specification states that either OrigClOrdID or OrderID fields must be present. Can both identifiers be present on the order?

Yes, however we will reject the order if the identifiers do not both reference the same order.

Is MassCancelRequest performed across the MPID + optional CancelGroupID?

The mass cancel is performed against the entire firm unless additional restrictions are applied such as side, symbol, and CancelGroupId etc.

Is there any setting to prevent or reject Mass Cancels for a session?

No, the exchange will not reject a mass cancel request based on a session or port setting.

Is ExecID unique for both sides of the same exchange cross?


Can we opt out of some server messages e.g. PendingNew/PendingCancel?


What message is sent back for Self Trade Prevention cancels?

ExecutionReport_Canceled will be sent for orders that were canceled as a result of this check.

What is the default setting for order routing? Does the exchange apply any default behavior if the order doesn’t contain this explicit instruction?

This field is mandatory and there is no default behavior.

Is the OrderID used in the MEMO specifications correlated with the OrderID in the MEMOIR Market Data specifications?

Yes. The MEMO ExecID in an ExecutionReport_New, ExecutionReport_Replaced, and ExecutionReport_Restatement message is correlated with the OrderID in the associated messages in MEMOIR Depth. For example, if an ExecutionReport_New is received, the MEMOIR Depth OrderID is the ExecID of the ExecutionReport_New message. If an ExecutionReport_New followed by an ExecutionReport_Restatement is received, the MEMOIR Depth OrderID is the ExecID of the ExecutionReport_Restatement message.

Do MEMO SBE and FIX protocols have 100% feature parity as far as trading functionality is concerned?

No.  MEMO FIX does not offer the ability to cancel on behalf of a different port nor does it offer the mass cancel functionality. These features are available only via SBE.

What is the max message rate supported for SBE TCP?

There is no fixed maximum messaging rate at the MEMO port (i.e. throttle). In the event that MEMO messages are sent faster than the system can process them TCP flow control will be used to indicate this to clients.

The heartbeat interval is configurable, any guidance regarding the interval range?

Unless clients request otherwise, MEMX will emit heartbeats at 1 second intervals, and time out clients after 5 seconds of inactivity. Many clients will find this sufficient.

What is an RST packet sent in response to invalid client request?

An RST packet is a TCP/IP packet control flag which will close a TCP connection immediately, causing the operating system to free the resources associated with the connection without waiting for additional information from the server-side. See RFC 793

Are all execution reports sequenced?


What messages are not sequenced?

All MEMO business layer messages from the client to the MEMX server are not sequenced. All MEMO business layer messages from the MEMX server to the client are sequenced.

MEMOIR Protocol Details

What is expected heartbeat interval to maintain Gap fill and Snapshot TCP connections throughout the day?

Sending heartbeats at a 1 second interval is sufficient, but configurable if necessary.

Are there limitations on number of packets per retransmission request, the timeliness of retrains requests, or the number of retransmission requests per day?

MEMX has yet to define any such limits.  They will be made available in upcoming spec versions/FAQs.

Can you tell me more about the “ReplayRequest”, “ReplayBegin”, “ReplayComplete”, “ReplayAllRequest” messages?

These are MEMX-TCP Session/Framing layer messages and are used as elements in the network stack for most MEMX protocols (i.e. MEMO, MEMOIR). They are covered in the MEMX-TCP document available with the protocol specifications.

Contacting MEMX

Who do I call if I have questions?

Who What Phone Email
Member Experience Sales and onboarding questions and inquiries 1-833-415-MEMX

Network Operations Connectivity provisioning and xNET questions 1-833-415-MOPS

Market Operations Market operations and service entitlement 1-833-415-MOPS