April 24, 2002 

Honorable Thomas J. Erickson 

Commissioner 

Commodity Futures Trading Commission 

1155 21st Street, N.W. 

Washington, D.C. 20581 

On behalf of the subcommittee on standardization, we are pleased to forward you the 

enclosed Recommendations for Standardization of Protocol and Content of Order Flow 

Data. In May 2001, a subcommittee of the CFTC Technology Advisory Committee was 

formed to address the need for standardization of order flow data relating to both content 

and protocol. This report contains the subcommittee's recommendations, which cover 

five broad areas and represent the efforts of a wide cross-section of the futures and 

options community. 

The subcommittee recommends that the Commission mandate the standardization of data 

content and calls for the voluntary implementation of a protocol standard. For both 

content and protocol, we recommend separation into three sections: 1) order routing; 2) 

clearing; and 3) back office. These recommendations are consistent with the 

subcommittee's findings and with the feedback received from a wide range of industry 

participants. We also recommend that the content standard be implemented throughout 

the industry by June 30, 2003 and that this date be used as a benchmark for the protocol 

standardization as well. Our final recommendations call for support from both industry 

participants and the Commission, as we recognize that without this support, we have little 

hope of seeing these recommendations become a reality. 

In determining these recommendations, the subcommittee recognized the many benefits 

to standardization of both content and protocol. Some of these benefits may not be as 

apparent during the transition phase, but they will be clear once the standards are 

implemented. Content standardization will harmonize the information that flows through 

the current protocols being used. This will allow more industry participants to connect 

with one another, which will result in a more cost effective and efficient order flow 

process. By agreeing to utilize the same data requirements in each processing system, 

regulators would have an easier time investigating market violations, and firms and 

exchanges would be better able to analyze risk. Having the industry agree to utilize the 

same data requirements for each processing system will provide timely information from 

one end of order flow to the other. The standardization of data content will also reduce 

barriers to entry and promote regulatory compliance. 

Although the subcommittee is recommending that there be a voluntary, not mandated, 

move towards protocol standardization, we believe that there are numerous benefits to 

this type of standardization as well. A standardized protocol for the futures industry is in 

line with similar initiatives throughout the financial services community, including the 

equities market, where there has been an evolution that has resulted in one protocol being 
used more predominantly than all others. Standardized protocols will mean faster entry 

into the markets and a giant step towards straight-through processing. 

As noted above, the subcommittee recommends an implementation date of June 30, 2003 

for both the content and protocol standardization. As we are recommending that the 

standardization of content be mandated, the subcommittee believes that this date can be 

realistically met by the industry. With respect to protocol standardization, we believe 

that even though the report calls for a voluntary implementation of the standard, it is 

important to show the priority that this implementation should have with industry 

participants. This date also acts as a target to aim at when allocating funds and other 

resources to operations projects throughout the next year. 

Industry support, both from industry participants and the Commission, is an important 

part of the subcommittee's recommendations. We recommend that the CFTC widely 

circulate this report, so that it can be viewed as a high priority for the industry. The 

subcommittee also believes that as part of the implementation of these recommendations, 

an implementation committee should be formed. This committee should be comprised of 

representatives from all areas of the industry, including software and system providers, 

regulators, trade association representatives and other users in order to ensure all issues 

are addressed. It would be the responsibility of this committee to move the 

implementation process forward and continue to ensure that the industry is on board with 

the recommendations. 

The subcommittee recommends that the implementation start with the exchanges, as their 

cooperation is vital to the success of this initiative. By ensuring that they recognize the 

importance of this project, the industry can better determine when these initiatives can be 

implemented. 

The subcommittee recognizes that there may be substantial costs associated with the 

implementation of the standardized protocol. However, given that these costs will be 

different for all participants, we did not feel that it was appropriate to estimate the costs 

involved in implementing the standardized protocol and feel that this is an issue for the 

implementation committee to address. In any case, the subcommittee strongly believes 

that any implementation costs are far outweighed by the benefits of standardization. 

The subcommittee, comprised of members of the CFTC Technology Advisory 

Committee and representing a wide range of interests, called on numerous advisors to 

provide their opinions and guide us in this project. These advisors came from various 

sectors in the financial services community, including users of the protocol and 

individuals who have worked on similar initiatives in the bond and securities arenas. 

They were able to provide the subcommittee with valuable information by sharing their 

knowledge with us and assisted us in developing the recommendations of this report. We 

would like to take this opportunity to thank each of them for their insight. 
We would also like to thank each of the members of the subcommittee for their time and 

commitment to this project. Their dedication ensured that this report fully addressed the 

issues and, given the urgency of this matter, that the report was completed expeditiously. 

We welcome the opportunity to discuss our recommendations with you and the other 

members of the Advisory Committee and we are looking forward to taking an active part 

in the development of the next phase of this initiative. 

Sincerely, 

The Standardization Subcommittee 
Recommendations for 

Standardization of 

Protocol and Content of 

Order Flow Data 

Commodity Futures Trading Commission 

Technology Advisory Committee 

Subcommittee on Standardization

 
Table of Contents 

Summary and Introduction.......................................... 1 

Formation of Subcommittee........................................ 2 

Goals of the Subcommittee......................................... 3 

Issues Addressed by Subcommittee............................. 4 

Similar Projects in the Industry.................................... 5 

Data Requirement Comparison.................................... 8 

Subcommittee Recommendations................................ 11 

Industry Feedback.................................................... 14 

Conclusion.............................................................. 16 

Exhibit A – Subcommittee Members............................. 18 

Exhibit B – Subcommittee Advisors.............................. 19 

Exhibit C – Data Requirements.................................... 20 

Exhibit D – Order Flow Chart....................................... 36 

 
Summary and Introduction In May 2001, the CFTC Technology Advisory Committee 

formed a subcommittee to address the issue of 

standardization of protocol and content in the futures 

industry. The subcommittee, comprised of users, 

regulators and exchange representatives, researched 

the necessity of ensuring the specific data was included 

in processing systems, as well as the need for the 

industry to use specific protocol. The subcommittee was 

also given the task of determining how to ensure 

compliance with any proposed standards and the role 

that the Commission should take in ensuring this 

compliance. 

In order to complete this task, the subcommittee 

gathered information from users within the futures 

industry, as well as entities that are working on similar 

projects throughout the financial services community. 

The subcommittee discussed the benefits of 

recommending a standard and any obstacles that may 

occur. Possible remedies for these obstacles were 

proposed, so that any problems could be properly 

addressed. Finally, the subcommittee discussed ways in 

which industry buy-in could be obtained and possible 

dates for implementation of the recommendations. 

The subcommittee submitted an interim report to the 

Technology Advisory Committee and discussed its 

proposals at the committee’s November 2001 meeting. 

The interim report was also posted on the CFTC’s 

website and widely distributed throughout the industry, 

mainly through various industry groups, including 

Futures Industry Association, Managed Funds 

Association and National Introducing Brokers 

Association. Comments that the subcommittee received 

have been incorporated into the report. 

As various areas of the financial services industry move 

towards straight-through processing and T + 1 

settlement, protocol standardization is seen as a way to 

enable these initiatives to happen more quickly. 

Straight-through processing is a hot issue in the futures 

industry as well, and content and protocol 

standardization can facilitate the process. 

 

The subcommittee’s report also includes information on 

protocol standardization and straight-through processing 

from an international standpoint. This will help the 

industry determine the global effects of the 

subcommittee’s recommendations. 

The subcommittee recommends to the Technology 

Advisory Committee that standards for both protocol and 

content be implemented in order to increase efficiencies 

in processing and regulation. The implementation of 

these standards should also reduce the costs of doing 

1

 
business which would increase the industry’s customer 

base and provide a more effective way for firms to 

analyze risk. 

Content standardization is seen as a necessary first step 

in this process. With unanimous consent from the 

subcommittee and strong support from the industry, the 

subcommittee recommends that content standardization 

be mandated for the industry. By ensuring that all 

necessary data fields are included in whichever 

protocols are used, the industry can ensure a level 

playing field for its participants. 

Given that other areas of the financial services 

community have either recommended a protocol 

standard or are in the process of doing so, the 

subcommittee believes that there will be a built-in 

incentive for the futures industry to implement a standard 

as well. As the lines between asset classes become 

more and more blurred and as futures entities look 

toward securities as a way to expand business, the 

standardization of a protocol makes good business 

sense for those in the futures industry. For these 

reasons, the subcommittee does not recommend that 

there be a formal mandate, but rather a voluntary 

initiative with a strong recommendation from the 

Technology Advisory Committee, Commission and other 

industry groups for the standardization of protocol. 

Additionally, the subcommittee realizes that technology 

is continuously advancing and what may be the most 

advanced protocol at one point in time may soon be 

overshadowed by other advancements. Therefore, the 

subcommittee does not recommend a specific protocol 

in this report. We recognize, however, that the FIX 

protocol is widely used in other areas in the financial 

industry and is a natural choice to implement as the 

standard for futures as well. 

The subcommittee recommends that the industry 

implement the mandated content standard by June 30, 

2003. This is also recommended as the date for the 

voluntary implementation of the protocol standardization. 

The subcommittee believes that the date is far enough in 

the future for it to lessen the burden that the 

implementation will cause for the industry, but not so far 

that it will not be given the attention that is needed to 

properly implement. 

Formation of Subcommittee The CFTC Technology Advisory Committee, chaired by 

Commissioner Tom Erickson, was formed to advise the 

Commission on the impact and implications of 

technological innovation in the financial services and 

commodity markets. At the Committee’s meeting in May 

2001, one of the more pressing issues that arose dealt 

2 

 
with the concept of standardized protocol and content. 

Numerous members of the Committee articulated the 

need for straight-through processing to the customer. 

With industry members utilizing multiple trading systems 

and going through multiple exchanges, straight-through 

processing was impossible, as many different protocols 

were used. Also, the lack of standardized content made 

it difficult for those regulating the markets to effectively 

monitor the activity. The Committee determined that the 

time to deal with these issues was now and that it was 

important that the industry find answers immediately, 

rather than waiting to make a decision. A subcommittee 

was formed, which was headed by Scott Johnston of the 

Chicago Mercantile Exchange and Yvonne Downs of the 

National Futures Association. Volunteers for the 

subcommittee came from all areas of the industry – 

exchanges, regulators, ECNs, and users (see Exhibit A 

for a list of the subcommittee’s members). 

Commissioner Erickson also participated on the 

subcommittee in order to observe firsthand the workings 

of the subcommittee. 

As the subcommittee is comprised of individuals with a 

strong business background, it looked at the 

standardization problem from a business operations 

standpoint, not a technical standpoint. This allowed the 

subcommittee to focus on policy, rather than determining 

what the most technologically advanced protocol would 

be. However, the subcommittee also realized that it 

would need input from others in the financial services 

industry, including those with strong technology 

experience. Therefore, the subcommittee invited several 

industry participants to act as advisors to the 

subcommittee and share their expertise (see Exhibit B 

for listing of the subcommittee’s advisors). 

Goals of the Subcommittee In its first meeting, the subcommittee decided to look at 

the standardization problem from various perspectives in 

order to determine what was needed. From a user’s 

perspective, protocol standardization is necessary, as it 

is increasingly difficult to do business with numerous 

entities, each of which uses a different protocol to 

transmit information. This can be an inefficient and 

illogical way to run processing systems because 

transactions can not automatically run end-to-end. 

From a regulator’s standpoint, the standardization of 

protocol content is needed, as not all protocols contain 

the necessary data requirements. Specifically, account 

numbers and user IDs, which are essential to monitoring 

the activity of the market, are not included in all 

protocols. This means that regulators have a difficult 

time investigating market violations. 

3 

 
Therefore, the subcommittee decided to assess whether 

the industry would be behind its proposal. The 

subcommittee also decided to determine the ways in 

which the Commission might support the standardization 

effort. 

Issues Addressed by Subcommittee The subcommittee and its advisors met several times 

over the course of the last year to discuss the issues that 

would affect the implementation and acceptance of a 

standard for content and protocol. Both the benefits and 

obstacles were addressed from a variety of different 

angles. 

BENEFITS OF STANDARDIZATION 

The subcommittee highlighted the benefits of developing 

industry standards for protocol and content. By 

standardizing the protocol and its content, more people 

would be able to connect to one another, which would 

make the entire process more cost effective. If 

standardization resulted in lower costs, the number of 

customers in the industry would increase, as would the 

value of the marketplace. Also, if more entities were 

utilizing the same protocol with the same data fields, the 

ability to analyze risk would be enhanced. Protocol 

standardization would result in a level playing field, 

which would go beyond the individual exchanges. 

Numerous changes within the futures industry 

compound the need for a standardized protocol. The 

advent of electronic trading and the expansion of trading 

to a globalized marketplace have increased the number 

of outside vendors. Given the development of new 

products, including security futures products, it is 

imperative that the industry find the fastest way to bring 

these new products to market. The use of different 

protocols amid all these changes has made things more 

challenging for the industry. 

Due to the multitude of counterparties that are used, 

managed fund entities have been unable to fully 

automate their systems. Standardization would allow 

their operations, including the back office aspect, to be 

more efficient. This is because each user has to 

translate each of the different protocols to its own 

system to make things flow automatically. This is less

efficient than creating a standard for the industry as a 

whole to use. 

From the FCMs’ viewpoint, protocol standardization is 

very desirable. Their customers have many different 

requirements and FCMs spend a great deal of time 

translating their systems to fit these various 

requirements. Standardization has been needed for a 

long time and is now on the forefront due to the 

4 

 
expanded use of electronic trading and automated order 

routing systems. There will be a competitive advantage 

for those firms who follow the standard. 

All of these benefits have increased the amount of buy-in 

from the industry. Customers, intermediaries, 

exchanges and regulators all see the direct benefits to 

having a standardized protocol for the industry. 

OBSTACLES TO STANDARDIZATION 

The subcommittee and its advisors also discussed the 

pitfalls that it would have to overcome in order to get 

industry buy-in on protocol standardization. There was 

concern that the subcommittee would get pushback from 

the industry if standardization was mandated. Some 

thought that it might be better if the subcommittee 

focused on recommending guidelines, rather than a 

mandate for the industry. If a standardized protocol 

were to be developed, it should be the result of customer 

demand, not government mandate. Because everyone 

thinks that theirs is the most effective and efficient, 

getting the entire industry to agree on a particular 

protocol would be difficult. There was also some 

comment that competition among protocols is good for 

the industry. There was concern that if a particular 

protocol were mandated as the standard, it would stay in 

place for several years, even though something better 

might come along. 

Another problem that the subcommittee would have to 

contend with concerned independent software vendors. 

Currently, ISVs have little incentive to move to a protocol 

standard. Although ISVs may hear from their customers 

that they want standardization, this has traditionally been 

a low priority, as security futures products and other 

more pressing items have taken precedence. The 

subcommittee would need to convince the ISVs that 

standardization is important to the industry and that it 

would need to be made a top priority. 

In order to overcome these obstacles, the subcommittee 

discussed the ways in which we could get the industry to 

adhere to a standard. It was generally believed that 

competition among ISVs would force them to move to 

the standard, even if they were unwilling to do so at the 

beginning. In any case, security futures products will 

move the financial industry to integrate more, in both 

derivatives and cash instruments. Also, the 

subcommittee would need to come up with a strong 

incentive for the industry to move towards a standard. 

The incentive could be positive or negative, but should 

be effective. 

Similar Projects in the Industry It was discussed that the subcommittee should be 

5 

 
cognizant of what other groups are doing, as the Bond 

Markets Association and FIA are working on similar 

initiatives and MFA had a similar project several years 

ago. The subcommittee noted that it is important that 

our work not run afoul of other industry trends. Towards 

that end, the subcommittee contacted representatives 

from the BMA and FIA, and had the Chairman of MFA’s 

Standards and Technology Committee act as an advisor 

to the subcommittee. 

MANAGED FUNDS ASSOCIATION STANDARDS AND 

TECHNOLOGY COMMITTEE 

Several years ago, a subcommittee of the MFA Statistics 

and Standards Committee was formed to develop 

consistent, logical standards for the electronic 

transmission of data to and from various participants in 

the managed futures industry. This committee included 

representatives from all parts of the industry. 

The MFA Committee’s goal was to provide clear, 

comprehensive, practical-to-implement standards to be 

used by everyone in the industry in the hope that this 

would improve the efficiency, accuracy and cost 

structure of interchanging data with one another. 

The MFA Committee determined that an industry 

standard for content and protocol was necessary. The 

Committee also compiled a substantial document that 

listed each type of financial instrument’s data 

requirements, in order to ensure that each financial 

instrument could be included in the protocol. At the time 

of MFA’s recommendations, it was unable to obtain 

industry buy-in, as there was not a pressing need for 

standardization in the industry. However, the 

representative from MFA’s Committee indicated that 

they would support the subcommittee’s 

recommendations for standardization. 

FIX/FIA RELEASE OF FIX VERSION 4.3 

FIA has been working with the FIX Technical Committee 

and Derivatives Working Group to add futures and 

options to version 4.3 of FIX, which would allow for 

additional capabilities. The Financial Information 

eXchange (FIX) Protocol is a language which defines 

specific kinds of electronic messages for communicating 

securities transactions between two parties. FIX defines 

only the format of the messages and the session-level 

interaction between two applications -- it is not a 

software application in its own right. The FIX Protocol is 

not owned by any legal entity. Rather, it is maintained 

and improved by a committee structure comprised of 

fund managers, brokers, and other industry participants. 

Representatives from FIX that acted as advisors to the 

6 

 
subcommittee recommended that the subcommittee not 

mandate the use of a particular version of protocol; 

rather, the subcommittee should encourage people to 

use the current version. If it is cost effective, people will 

race to come up to speed and use the protocol. 

The FIX subcommittee is made up of firms, exchanges, 

ISVs and customers. The FIX subcommittee has looked 

at both simple and complex trades, both from a floor and 

an electronic standpoint. FIX version 4.3 was completed 

in August 2001 and futures components were added to 

the standard. Two changes were made with respect to 

futures: 1) data elements, such as CTI codes and origin 

were added and 2) enhanced spread functionality was 

included. Also, account numbers and terminal operator 

IDs were captured. They also added futures-style giveups and higher level allocations. Representatives from 

the standardization subcommittee were present at many 

of the FIX subcommittee’s weekly conference calls that 

discussed these issues in order to obtain a better 

understanding of FIX’s objectives. 

In discussing FIX and its wide use in the securities 

industry, several of the subcommittee members and 

advisors remarked that FIX version 4.3, which is the 

most recent version of the protocol, is flexible and has 

capabilities for futures trading. While other versions of 

FIX are able to be utilized, the subcommittee noted that 

each of the other versions has inherent limitations and 

that FIX version 4.3 is the most comprehensive, up-todate version. 

BOND MARKETS ASSOCIATION VOLUNTARY 

PROTOCOLS INITIATIVE 

The BMA represents securities firms and banks that 

underwrite, trade and sell debt securities both 

domestically and internationally. The BMA also strives 

to standardize market practices and commonly used 

documentation, both to promote efficiency and to reduce 

costs. One of the projects currently underway at the 

BMA is the Voluntary Protocol Initiative. The primary 

objective of this initiative is to assure the development of 

an industry-wide messaging standard for essential 

transaction functions in fixed income securities. The 

goal in pursuing this objective is to promote efficiency 

and expedite initiatives related to straight-through 

processing and T+1 settlement. 

In its research, the BMA noted several benefits to 

standardization of protocols. In order to permit the 

numerous electronic platforms to connect and 

communicate in a seamless way, they all have to speak 

the same language. By developing a common protocol, 

7 

 
the BMA will make the specifications available to all 

platforms to promote expansion of electronic commerce 

in the bond markets. Additionally, an active industrywide standardization initiative will create a variety of new 

responsibilities and opportunities for technology 

professionals and help to create the infrastructure that 

these professionals need to develop connectivity 

innovations for their customers. Keeping abreast of the 

diversity of e-commerce ideas, as they pertain to 

straight-through processing, will also be a beneficial byproduct. 

In pursuing the concept of a standardized protocol for its 

industry, the BMA developed four business practice 

documents, each relating to a specific industry product. 

Municipal securities, agency securities, U.S. Treasury 

securities, and corporate bonds were the initial focus, 

and these plain English documents spell out the 

business practices and processes involved in trading 

these instruments. The documents cover market 

participants and the trade process, pre-execution 

communications and the post-trade process. Just 

recently, the BMA also developed a TBA mortgage 

backed securities document. The BMA will add more 

instruments as the process continues. 

As part of the BMA’s initiative, the BMA and FIX have 

agreed to combine efforts to develop a common industry 

protocol for global fixed-income market securities. This 

is expected to alleviate incompatibility concerns among 

the various electronic trading platforms. FIX added 

fixed-income securities in its version 4.2 in an effort to 

improve the global trading process. Working on a joint 

initiative with FIX will enable the BMA to obtain more 

buy-in on the proposal of a standardized protocol for the 

bond market industry, as FIX is widely used in the 

securities industry and has a solid reputation. 

INTERNATIONAL INITIATIVES 

In addition to looking at standardization initiatives in the 

United States financial services community, the 

subcommittee also reviewed many of the processes that 

were being undertaken globally as well. Many 

international securities and derivatives exchanges have 

either moved to straight-through processing or are in the 

process of doing so. As cross border settlements are a 

necessary part of international business, straight-through 

processing would help to facilitate this process. A 

common messaging protocol is seen as a tremendous 

asset in enabling straight-through processing to become 

a reality. 

Data Requirement Comparison NFA provided the subcommittee with the data fields 

8 

 
required for its surveillance system in order to ensure 

that all necessary data was included. The CME and the 

Chicago Board of Trade also provided the subcommittee 

with their data requirements, so that a variety of 

requirements could be analyzed. 

The goal in this analysis was to establish a standard that 

outlines the data fields needed for the order flow 

process, beginning with the customer and ending with 

the customer. Standards have historically been defined 

by the regulators who needed the information in order to 

effectively monitor the markets; however, with the 

passage of the Commodity Futures Modernization Act 

and rapid changes taking place in the industry, a broader 

participative approach to standardization appears 

necessary. 

In reviewing this information, NFA noted that there are 

several components to the order flow process and that 

data is captured in each step, either for regulatory or 

business purposes. For example, when the customer 

enters the order (Step 1), the data that is entered 

includes general order information (commodity, contract 

month and year, quantity, price, type of order, order 

specifications, etc.) and his account number. All of this 

information is required by CFTC Regulation 1.35(a-1), as 

is the information that would be generated automatically 

by the system. System-generated information includes 

the order ID#, clearing member ID#, and the time that 

the order was entered in the system. All of the above 

information is necessary for regulatory purposes, as it 

helps prevent against manipulation of the trade. 

Information that is needed from a business standpoint 

would include the time that the order was confirmed to 

the customer, the type of routing system used and the 

origin of the order (e.g. – off-exchange). Once all of this 

information is entered/generated in the system, the 

information is passed to the terminal operator. 

The information that is added by the terminal operator 

(Step 2) includes such data as the trade ID#, logon ID# 

and CTI code. All of this information is required by 

CFTC Regulation 1.35(e) and is necessary for monitors 

of the system to determine if the parameters defined for 

these trades will generate the proper exceptions. The 

data generated by the system includes the terminal ID# 

and the time that the order was entered. This 

information is also necessary from a regulatory 

standpoint, as it allows orders to be tracked more 

accurately. 

Step 3 in the order flow process concerns the 

information that is gathered at the time that the order is 

executed. Again, some of this information is entered into 

the system at the exchange and some is automatically 

9 

 
generated. Entered information includes quantity and 

price, the trader ID# and the remaining quantity (for 

partial fills), which is all information required by the 

regulations, in order to adequately guard against trade 

manipulations. Other items are those that are generated 

automatically and include the time that the trade was 

matched and the time that the trade was reported. It 

should also be noted that on an electronic exchange, 

trades are matched automatically and there is no manual 

entry done at the exchange. 

The next steps of the order flow process (Steps 4 and 5) 

deal with information that is automatically added by the 

systems after the order is executed. As the order moves 

back to the firm, information such as the transaction 

code and the time that the trade was sent to clearing are 

now captured. These fields are required by CFTC 

Regulation 1.35 and provide an audit trail for the 

regulators to follow when analyzing a transaction. 

Information that is added at the clearinghouse includes 

the final settlement price and similar information required 

by the regulations (in this case, CFTC Regulation 

16.01(b)). This allows firms to correctly report the 

realized and unrealized balances in their customers’ 

accounts and is needed to accurately reflect pay/collect 

information. As the information is pushed to the 

regulator (Step 6), no new information is added. Rather, 

the information is gathered in the surveillance system, so 

that trades can be tracked for impropriety and markets 

can be monitored for manipulation. 

Attached as Exhibit C is a spreadsheet that outlines the 

data fields required for futures, or options on futures 

products during the entire order flow process. The 

spreadsheet is broken into three areas: 

1) the information captured during order/trade 

process; 

2) the information captured for regulatory reporting 

purposes; and 

3) the information for back office/administrative 

purposes. 

To facilitate the understanding of the order flow process 

and the specific data fields required along the way, we 

have enclosed as Exhibit D a flowchart. It is not intended 

to be an exhaustive depiction of the various types of 

order routing systems, but rather a pictorial of a typical 

order flow process from customer/trader order initiation, 

to routing, to execution/trade matching, to post-execution 

and clearing. 

As part of the subcommittee’s review, it was noted that 

the following information was not necessarily being 

captured throughout the order flow process, but was 

necessary for regulatory purposes: 

10 

 
a) ultimate account ID; and 

b) initiating trader/user ID. 

Our review also entailed looking at work done by the 

MFA on standards for electronic transmission and FIX 

Protocol efforts underway by the Exchanges. The MFA 

project was quite extensive and detailed encompassing 

all areas of managed futures operations. We also looked 

into the FIX Protocol initiative originally undertaken to aid 

firms trading equity products. 

Subcommittee Recommendations As a result of discussions with individuals from the 

futures industry and the work done on standardization in 

other areas of the financial services community, the 

subcommittee makes the following recommendations to 

the Technology Advisory Committee. 

1. CONTENT STANDARDIZATION 

Based on the need for specific data requirements in the 

regulation of electronic markets, the subcommittee 

recommends that data requirements be standardized for 

the futures and options industry. The comparison of the 

data requirements for NFA, the CME and the CBOT, as 

well as the requirements listed in MFA Committee’s 

report and the CFTC’s comments, show that certain data 

fields are universally needed for accurate and timely 

monitoring of the trading activity on the exchanges. The 

systems that possess all necessary data are not only 

adequate from a regulatory standpoint, but also add 

value to the order flow of the user, which will increase 

the user’s competitive advantage. The standardization 

of the data components is key to any standardization 

effort in the industry. 

Through the feedback that the subcommittee received 

from industry members, it was apparent that content 

standardization should not only be implemented, but that 

this implementation should be mandatory. Therefore, 

the subcommittee recommends that all protocols be 

enhanced to include the standard data fields by the 

recommended implementation date. The required 

standardization of content is an important step towards 

straight-through processing. 

In an effort to make the content standardization 

possible, the subcommittee recommends that the 

content be divided into three sections: 1) order routing; 

2) clearing; and 3) back office. This will enable changes 

to more easily implemented as each area can be 

focused on at various times and by the individuals who 

are directly affected by each section. 

2. PROTOCOL STANDARDIZATION 

11 

 
The subcommittee also recommends that the 

Technology Advisory Committee and the Commission 

support the idea for a standardized protocol for the 

industry. Given the need for automated straight-through 

processing of transactions, the multitude of protocols 

currently in use makes this extremely costly and timeconsuming. A standard protocol for the industry will 

allow users to run their processing systems from end-toend with little effort. 

The subcommittee further recommends that the data 

flow for protocols be divided into three sections, in order 

to more easily implement the recommendation. The 

sections are the same as those listed in the content 

standardization recommendation: 1) order routing; 2) 

clearing; and 3) back office. 

It should be noted, however, that the subcommittee’s 

recommendation is that the utilization of a standardized 

protocol be considered as best practice guidance. We 

do not recommend that the CFTC, or any regulatory 

body, mandate that a particular protocol be used. The 

subcommittee would like a particular protocol to be 

selected and have it be known that it is in the industry 

participants’ best interests to utilize this protocol. 

Additionally, while the subcommittee does not 

specifically recommend that a particular protocol be 

used, we recognize that FIX version 4.3 is an example of 

protocol that includes the data necessary for regulatory 

purposes. FIX is able to handle complex products and 

addresses almost all of the needs of the industry. In 

addition, as FIX is utilized throughout the securities 

industry and is expected to become the voluntary 

standard for the bond markets as well, this protocol may 

be able to be implemented with little upheaval to the 

futures industry. The subcommittee was conscious not 

to simply adopt FIX as other protocols may become 

available, but nonetheless noted that FIX 4.3 does 

contain the data necessary for futures related activity. 

3. IMPLEMENTATION/COMPLIANCE 

Once the subcommittee finalized its recommendations 

concerning content and protocol standardization, the 

recommendation of a timeframe for implementation was 

discussed. The first date suggested was the 

implementation date for security futures products, as this 

was a date for profound changes in the industry. 

However, given that the industry does not currently know 

when the SFP implementation date will be, it was 

decided that a more firm date should be selected. As 

the subcommittee wanted the date to be close enough to 

show up on a firm’s radar screen, but far enough to 

cause minimal disruption to a firm’s operations, the date 

12 

 
of June 30, 2003 was agreed upon by the subcommittee. 

This is the date that the subcommittee strongly 

recommends that all protocols be changed to include the 

required data content standards outlined by the 

subcommittee. Further, we also recommend that this 

date be used as a guideline for when futures participants 

begin using the agreed-upon protocol standard. By 

having such a target date in mind, the industry can better 

allocate its resources to implement the recommended 

protocol. 

The subcommittee recognizes that this date is highly 

optimistic and, given the changing face of the industry, 

may not be easy for all firms to implement the protocol 

standard by that date. It should be noted again, 

however, that the subcommittee’s recommendation is for 

a voluntary implementation of the selected protocol, not 

a mandated use. Therefore, the subcommittee believes 

that this date should not result in an undue burden on 

the industry. It was also recommended that new 

companies should begin utilizing the standard upon the 

company’s start-up, as this would prevent them from 

having to switch to a different protocol at a later date. 

4. INDUSTRY SUPPORT 

The subcommittee also advocates obtaining support for 

the recommendations from various industry groups. 

Therefore, the subcommittee’s interim report was sent to 

FIA, MFA, FIX, NIBA and the BMA for comment. 

Several of these associations sent formal comment 

letters to the subcommittee and all have indicated they 

generally support the subcommittee’s efforts. Further, 

the subcommittee and its advisors suggest launching an 

extensive marketing campaign through various industry 

publications, which will focus on the importance of 

standardization for the industry. 

The subcommittee believes that industry buy-in will be 

easier to achieve than ever before, as several factors 

are now in place in the financial services community. 

First, there are protocols that have all necessary 

components and contain enough flexibility to make them 

ideal for the futures industry. As noted earlier in this 

report, one such protocol is FIX version 4.3. Second, 

FIX is used extensively in the securities industry and is 

currently part of the standardization initiative in the bond 

markets as well. As many asset classes are utilizing 

FIX, the use of this particular standard in the futures 

industry may result in substantial cost savings. Firms 

may even offer lower fees to those that use FIX, or 

whatever standard is agreed upon, as opposed to 

another protocol. The cost savings will increase 

competition in the industry, which will expand its overall 

business. From a regulatory perspective, a standardized 

13 

 
protocol with standardized content will ensure that trades 

can easily be followed from end to end. 

5. COMMISSION SUPPORT 

Finally, the subcommittee strongly recommends that the 

Commission support and advocate standardization of 

content as mandatory and standardization of a protocol 

of order flow data as a “best practice” for new and 

existing markets. Implementing standards for both 

protocol and content should increase efficiencies in 

processing and regulation. Standardization should also 

reduce the costs of doing business, which should 

increase the industry’s customer base and provide a 

more effective way for firms to analyze risk. 

Industry Feedback As noted earlier in this report, the subcommittee sent its 

interim report to a variety of trade associations affiliated 

with the financial services industry, in order to obtain 

their support for this initiative. Comments from these 

organizations were also solicited, so that the 

subcommittee could ensure that all relevant areas were 

addressed. 

NATIONAL INTRODUCING BROKERS ASSOCIATION 

The comments that the subcommittee received from 

NIBA indicated that there is strong support from the 

association for the recommendations outlined in the 

interim report. With the changes taking place in the 

industry, procedures must necessarily change to meet 

the industry’s needs and NIBA believes that the 

subcommittee has adequately identified and addressed 

these needs and changes. There was concern from 

NIBA regarding the costs, especially to smaller FCMs 

and exchanges, as well as introducing brokers, of 

implementing the recommendations. Additionally, NIBA 

was concerned that the time frame for implementation 

[which was listed as December 31, 2002 in the draft that 

NIBA received] might be too soon for smaller firms to 

implement. 

FUTURES INDUSTRY ASSOCIATION 

FIA, in its comment letter to the subcommittee, stressed 

that the association has been very active in promoting 

standardization. Through its Tech Working Group, FIA 

prepared a gap analysis of the FIX protocol and helped 

enhance FIX 4.3 to be ready to support futures. FIA 

supports moving towards a standardized protocol for the 

industry, particularly with respect to the coordination of 

exchanges and clearinghouses. 

FIA is also a proponent of the concept of standardizing 

data content for order flow and related information, as 

14 

 
the entire industry is subject to the same business and 

regulatory drivers. The standardization of the message 

content will aid all industry participants when they are 

communicating with multiple parties. However, FIA 

believes that the content standardization should be 

limited to order flow messages, rather than broadening 

the scope to include clearing and regulatory functions. 

FIA believes strongly that standardization, while still the 

objective of the futures industry, is a business decision 

among firms and exchanges. Further, FIA indicated that 

they prefer that the subcommittee endorse 

standardization without adopting it as a best practice and 

to stop short of calling for standardization by a specific 

date. If a timeframe were mandated, this might put 

additional strain on an industry that is already under 

significant financial challenges. Also, there was some 

question as to whether a voluntary initiative could be 

voluntary if supported and advocated as a best practice 

by the CFTC. 

Finally, FIA indicated that it may be premature to 

highlight FIX 4.3 as a viable standardized protocol, as it 

is new and thus unproven in the marketplace. 

BOND MARKETS ASSOCIATION 

As the BMA is completing a similar initiative in the bond 

industry and had a key senior member of its staff 

participate as an advisor to this subcommittee, BMA is 

extremely supportive of the subcommittee’s efforts in this 

area. 

CFTC TECHNOLOGY ADVISORY COMMITTEE 

During the November 2001 CFTC Technology Advisory 

Committee meeting, it was suggested that the 

subcommittee determine the costs involved with the 

implementation of these recommendations. It was also 

mentioned that an implementation date of June 2003 

might be too optimistic, given the other challenges facing 

the futures industry. 

THE SUBCOMMITTEE’S RESPONSE 

The subcommittee’s report attempted to address the 

concerns noted from industry representatives. The 

subcommittee did not receive any feedback that might 

suggest that content standardization is either 

unnecessary or would be burdensome to implement. 

Therefore, the subcommittee made no changes to its 

recommendation that data content be standardized in all 

protocols. 

By stressing that the protocol standardization is a 

15 

 
voluntary initiative, one which will no doubt be driven by 

a business need, the subcommittee’s report intends to 

alleviate concerns that this is an initiative sponsored by 

the Commission. We believe that it is important for the 

government agency that oversees the industry to 

support any decisions made with the thought of the 

industry’s best interests. The fact that the subcommittee 

is part of a CFTC advisory committee is not meant to 

imply that a government mandate is imminent or 

necessary. Rather, it should be looked on as a positive 

step that the Commission is aware of the industry’s 

needs and is attempting to address those needs in a 

proactive way. 

While the subcommittee recognizes that a 

recommended implementation date of June 2003 might 

be considered optimistic by industry participants, the 

subcommittee nonetheless felt that such a date was 

necessary to stress the importance of protocol 

standardization to the industry. A date keeps a focus on 

the initiative and provides industry representatives with 

something to strive for when making business decisions 

for the future. The subcommittee’s call for voluntary 

implementation means that each participant can look at 

its own business needs and determine for itself whether 

or not to implement the standard and at what time to do 

so.

The subcommittee has numerous advisors from around 

the industry participating on this project and we welcome 

representatives from the various industry associations to 

assist us in the implementation of the recommendations 

as we move forward on this initiative. 

The subcommittee also believes that it may be in the 

industry’s best interest to form a separate committee of 

users and regulators to continue to evaluate data 

content and protocols as the technology progresses. 

We believe it may be most effective to utilize people 

from many of the trade associations that were solicited 

for comments, as they have a clear understanding and 

interest in this initiative. This newly formed committee 

can also act as an advisor to firms and other users who 

are moving forward to the standardized protocol by the 

recommended implementation date. 

Conclusion Through its extensive discussions and research into the 

various aspects of the financial services industry, the 

subcommittee noted that now more than ever the time is 

right for the industry to have a standardized protocol and 

content. Standardization will enable regulators to more 

effectively monitor the markets and will also enable firms 

to operate more efficiently and with greater cost savings. 

As we see a convergence of the various sectors of the 

financial services industry, the need for standardization 

16 

 
 

becomes even greater. The recommendations made in 

this report will enable the futures industry to move 

towards straight-through processing and will benefit not 

just futures, but other areas of the financial services 

community as well. 

17 
Exhibit A – Subcommittee Members 

Chris Concannon 

Vice President of Strategic Planning 

The Island ECN, Inc. 

50 Broad Street, 6th Floor 

New York, NY 10004 

George Crapple 

Co-Chairman and Co-CEO 

The Millburn Corporation 

1270 Avenue of the Americas, 11th Floor 

New York, NY 10020 

Yvonne Downs 

Senior Vice President of Compliance 

National Futures Association 

200 W. Madison, Suite 1600 

Chicago, IL 60606-3447 

Richard Friesen 

Managing Partner 

Friesen Consulting 

132 Ridge Road 

Fairfax, CA 94930 

Scott Johnston 

Managing Director and Chief Information Officer 

Chicago Mercantile Exchange 

30 South Wacker Drive 

Chicago, IL 60606-7499 

Hank Mlynarski 

President 

BrokerTec Futures Exchange, LLC 

One Evertrust Plaza 

Jersey City, NJ 07302 

Brett Paulson 

Senior Vice President and Chief Information Officer 

Board of Trade Clearing Corporation 

141 W. Jackson, Suite 1460 

Chicago, IL 60604 

17 
Exhibit B – Subcommittee Advisors 

Scott Atwell 

FIX Technology Committee 

American Century 

4500 Main Street 

Kansas City, MO 64111 

Tom Basso 

Chief Executive Officer 

Trendstat Capital Management Inc. 

4300 N. Miller Road, #141 

Scottsdale, AZ 85251 

John Barun 

Partner 

Capital Markets Consulting LLC 

29 S. LaSalle St., Suite 800 

Chicago, IL 60603 

Clarence Delbridge 

Executive Vice President 

FC Stone, LLC 

141 W. Jackson Blvd., Suite 2730 

Chicago, IL 60604 

Daniel Doscas 

Fixed Income Working Group, 

FIX Protocol Ltd. 

Director, Merrill Lynch 

4 World Financial Center FL 16 

New York, NY 10080 

James W. Marvin 

Managing Director, Sales and Marketing 

Crosslinks Systems, Inc. 

3 New York Plaza 

New York, NY 10004 

Tom McCabe 

FIA/FIX Committee 

Managing Director 

Chicago Board of Trade 

141 W. Jackson Blvd. 

Chicago, IL 60604 

Jim Northey 

Principal 

LaSalle Technology Management, Inc. 

Consultant to the Chicago Board Options 

Exchange 

400 South LaSalle Street 

Chicago, IL 60605 

Michael O’Conor 

FIX U.S. Steering Committee 

Managing Director 

Merrill Lynch & Co., Inc. 

4 World Financial Center 

250 Vesey Street 

New York, NY 10080 

Joseph Sack 

Senior Vice President 

Bond Markets Association 

40 Broad Street 

New York, NY 10004 

Michael Schaefer 

Executive Vice President 

Salomon Smith Barney, Inc. 

388 Greenwich Street, 7th Floor 

New York, NY 10013 

Dino Scouras 

Vice President Fixed Income Systems 

Lehman Brothers, Inc. 

101 Hudson St., 33rd Floor 

Jersey City, NJ 07310 

18 
This page blank. 

19 
ORDERS TABLE (Data originated at firms)

Field Data type Description Tag Number CFTC Rule

EXCHANGE_ORIGIN Text Exchange of order origination

EXCHANGE_EXECUTION Text Exchange of execution

ROUTING_SYSTEM Text Routing System

ORDER_ID Text A unique identifier assigned to each order 37 1.35(a-1)

ORDER_REF_ID Number

Other unique number generated by system or 

exchange as available

SPREAD_ORDER_ID Text

Spread match number to link specific leg 

information together

CLEARING_MEMBER_ID Text Firm the trader clears through 528 1.35(a-1)

TERMINAL_ID Text ID of the terminal connection

TERMINAL_GROUP_ID Text Identification of the physical group of terminals

BRANCH_CODE Text

Code indicating the city location of the device 

used to enter the order

SUB_GROUP Text ID of the trader subgroup

LOGON_ID Text ID of the trader using the terminal 466

TIME_ORDERENTRY Date/Time

Date/time order was entered into system or 

received by the trading desk 1.35(a-1)

TIME_ORDERENTRY_SOURCE Text

Indicator defining source of timestamp, i.e. order 

routing system, internet, deck management 

system, manually, timestamp machine, or fill

5(b)(2) and 

5(d)(10)

TRADING_SESSION Text Session order was entered in 336

TIME_ORDERMATCH Date/Time Date/time order was sent to be matched 1.35(a-1)

TIME_CONFIRMED Date/Time Date/time order was confirmed to customer Optional

CUSTACCT_ID Text Customer account number 1 1.35(a-1)

OMNIBUS_ACCT_INDICATOR Text Indicator if omnibus account

CTI_CODE Text Trade Identifier code5(b)(2) and 5(d)(10)

 1—For orders placed by an executing broker 

for his own account.

5(b)(2) and 

5(d)(10)

 2—For orders placed by an executing broker 

for a firm proprietary account.

5(b)(2) and 

5(d)(10)

 3—For orders placed by an executing broker 

for another broker who also has access to the 

system

5(b)(2) and 

5(d)(10)

 4—For orders placed by an executing broker 

on behalf of a customer.

5(b)(2) and 

5(d)(10)

VERB Text B=Buy; S=Sell (only if not a spread) 54 1.35(a-1)

PRODUCT_CAT Text F=Futures, C=Call; P=Put (only if not a spread) 461 1.35(a-1)

OPTION_TYPE Text American or European Option

SPREAD_TYPE Text

Type of spread order placed e.g. calendar, 

butterfly, crush, etc.

OPEN/CLOSE_TRANS Text Opening or Closing Transaction 77 1.33(a)

COMMODITY_CODE Text Unique product identifier (only if not a spread) 55 1.35(a-1)

CONTRACT_YEAR Text yyyy (only if not a spread) 200 1.35(a-1)

CONTRACT_MONTH Text mm (only if not a spread) 200 1.35(a-1)

SHORT_TERM_OPTION_DATE Text dd (only if not a spread)

STRIKE Number (only if not a spread) 202 1.35(a-1)

ORIGINAL_ORDER_QUANTITY Number The original quantity of the order 1.35(a-1)

TOTAL_MATCHED_QUANTITY Number

The total quantity of the order that has been 

matched

CANCELLED_ORDER_QUANTITY Number

The total quantity of the order that has been 

cancelled

 Page 20
PRICE Number Order price in raw tick format 44 1.35(a-1)

FORMAT_ORDER_PRICE Text Order price in human readable format

SPREAD_DIFFERENTIAL Number Order price in spread differential (raw ticks)

BLOCK_SIZE Number

The incremental block size that would be used to 

fill the given quantity—e.g., a block size of 10 

would mean that the given quantity of, say 50, 

would be filled at a minimum of 10 contracts at a 

time.

ORDER_TYPE Text

Price specific order designation: e.g., market 

order, limit order, stop limit, market on close. 40 1.35(a-1)

ORDER_RESTRICTION_CODE Text

Code indicating the type of restriction placed on 

an order (stop, trigger, immediate or cancel, fill 

or kill)

STOP_PRICE Number Stop price on order

LIMIT_PRICE Number Limit price on order

DISCRETIONARY_INDICATOR Text Code if order was discretionary

DISCRETIONARY_POINTS Number Number of points allowed for discretion

DURATION Text

Time specific order designation: e.g., Trading 

day only, Good until cancelled, Good until 

specified date... 59 1.35(a-1)

ORDER_EXPIRY_POINT Text

Date of order's expiration (e.g., if order is 

designated as ‘good until a specified date’, then 

this field would reflect that date. 1.35(a-1)

ORDER_ORIGIN Text

For exchanges which allow trading outside of the 

engine, this field is used to designate the origin 

(e.g. off-exchange)

1.38(b) and 

revised 4a

LINKED_ORDER_ID Text

If this order is tied to another one that was 

cancelled or if its part of a non standard spread 

combination

LINK_REASON Text The reason why the order is linked e.g. OCO

OPEN_CLOSE Text

Whether the order initiated or closed-out a 

position. 77

STATUS Text

Whether the order was matched (M) or cancelled 

(C).

INFO_SOURCE Text For NFA use

 Page 21
SPREAD ORDER LEG TABLE

Field Data type Description Tag Number CFTC Rule

SPREAD_ORDER_ID Text

Uniquely generated Spread match number to link 

specific leg information together

ORDER_SPREAD_LEG_NO Number

Generated number uniquely identifying the leg of 

the spread

VERB (BUY/SELL CODE) Text B = Buy; S = Sell

COMMODITY_CODE Text Unique product identifier of the leg 55 1.35(a-1)

CONTRACT_YEAR Text yyyy 200 1.35(a-1)

CONTRACT_MONTH Text mm 200 1.35(a-1)

PRODUCT_CAT Text F = Futures, C = Call, P = Put 461 1.35(a-1)

OPTION_TYPE Text American or European Option

STRIKE Number (only for options) 202 1.35(a-1)

 Page 22
TRADES TABLE (Data originated at exchanges)

Field Data type Description Tag Number CFTC Rule

TRADE_ID Text A unique identifier assigned to each trade 1.35(e)

TRANS_REF_ID Number

Other unique number generated by system or 

exchange as available, either to the trade as a 

whole or to each side of the trade.

TRADER_ID Text Unique identifier for user initiating trade

ORDER_ID Text

A unique identifier assigned to each component 

order in a trade 37 1.35(a-1)

CARD_SEQUENCE_NUMBER Text

Sequence number on the trader's card [open 

outcry]

5(b)(2) and 

5(d)(10)

LINE_SEQUENCE_NUMBER Text

Sequence number of trade listed on trader's card 

[open outcry]

5(b)(2) and 

5(d)(10)

SPREAD_ORDER_ID Text

Spread match number to link specific leg 

information together

TRANS_CODE Text

Code representing what type of transaction the 

record represents (00=Opening position, 

03=misclear, 07=firm adjustment, 08=firm 

transfer, 09=exchange for physical, 27=giveup or 

APS transfer, 30=trade, 60=Sell side = Issue Buy 

Side = Stop, 99= closing price 1.38(b)

TIME_PIT_RECEIVED Date/Time

Date and time when order is accepted by the 

broker either electronically or manually

5(b)(2) and 

5(d)(10)

TIME_PIT_SOURCE Text

Indicator defining source of timestamp, I.e. order 

routing system, Internet, deck management 

system, manually, timestamp machine or fill

5(b)(2) and 

5(d)(10)

TIME_TRADEMATCH Date/Time Date and time when matched 60

5(b)(2) and 

5(d)(10)

TIME_TRADETOCLEAR Date/Time Date and time when sent to clearing 229

5(b)(2) and 

5(d)(10)

AS-OF_INDICATOR Text Indicator if as-of trade

SESSION/SYSTEM Text Session trade occurred

PRODUCT_CAT Text F=Futures, C=Call; P=Put 461

5(b)(2) and 

5(d)(10)

OPTION_TYPE Text American or European Option

SPREAD_TYPE Text Type of spread order placed

OPEN/CLOSE_TRANS Text Opening or Closing Transaction 77

COMMODITY_CODE Text Unique product identifier 55

5(b)(2) and 

5(d)(10)

CONTRACT_YEAR Text yyyy 200

5(b)(2) and 

5(d)(10)

CONTRACT_MONTH Text mm 200

5(b)(2) and 

5(d)(10)

STRIKE Number 202

5(b)(2) and 

5(d)(10)

VERB Text B=Buy, S=Sell 54

5(b)(2) and 

5(d)(10)

SPLIT-FILL_INDICATOR Text

Indicator whether trade was part of a split fill; or 

larger side of split fill

PARTIAL_QUALIFIER Text

Indicator whether order was filled with one or 

more matching trades (P = partial fill, L = last 

partial fill)

QUANTITY Number

5(b)(2) and 

5(d)(10)

REMAINING_QTY Number

For a partial fill, the quantity of remaining 

contracts to fill

5(b)(2) and 

5(d)(10)

PRICE Number Order price in raw tick format 44 1.35(e)

 Page 23
FORMAT_TRADE_PRICE Text Order price in human readable format

DECIMAL_POSITION Number

Number to indicate where decimal point is in 

trade price

CABINET_PRICE_INDICATOR Text Code indicating if cabinet trade

SPREAD_DIFFERENTIAL Number Order price in spread differential (raw ticks)

CLEARED_FLAG Boolean For NFA use

GIVEUP_FIRM_NUMBER Text

For give-up trades, clearing firm number 

identifying the firm that will receive the position 

established.

APS_GUS_INDICATOR Text

Indicator for average price system or give-up 

code (T = transfer, O = offset, A = 

allocation/acceptance)

APS_GUS_TRANSACTION_ID Text

Unique number linking to GUS or APS system 

table

TIME_TRADE_REPORTED Date/Time

For off-exchange trades, the time the trade was 

reported to the exchange 113 1.38(b)

OTHER_TIMING_CODES Text

Other exchange timing codes and data to support 

time assigned for execution, such as "CTR 

Process Type", "Out-of-Sequence Indicator", 

"Error Codes", CTR start time, CTR end time, etc.

CLEARING_MEMBER_ID Text The applicable Clearing Member ID 528

5(b)(2) and 

5(d)(10)

CUSTACCT_ID Text Customer account number 1 1.35(a-1)

ACTION Text

A description of the clearinghouse action (e.g., 

option expiration, futures delivery, option 

exercise/assignment...)

 Page 24

It is important to also note that there will be trades for which there will be no corresponding orders. Specifically, the clearinghouse 

must perform various “housekeeping” type trades with respect to option exercise/assignment, futures delivery and options that 

expire out-of-the-money. Since no corresponding order information would exist for such trades, the existing trade data model 

would not provide sufficient data. Consequently, in order to accommodate these trades, an additional block will have to be added to 

the trade record. In this case, the supplemental block will include:
CROSS REQUEST TABLE

Field Data type Description Tag Number CFTC Rule

CROSS_TRADE_INDICATOR Text Indicator whether trade was a cross trade

CROSS_REQ_ID (only if not a spread)

CROSS_REQ_SPREAD_ID if spread

TIME_CROSS_REQUEST Date/Time Date the cross request was entered

COMMODITY_CODE Text Unique product identifier (only if not a spread) 55 1.35(a-1)

PRODUCT_CAT Text

F = Futures, C = Call, P = Put (only if not a 

spread) 461 1.35(a-1)

OPTION_TYPE Text American or European option

SPREAD_TYPE Text Type of spread order placed

CONTRACT_YEAR Text yyyy (only if not a spread) 200 1.35(a-1)

CONTRACT_MONTH Text mm (only if not a spread) 200 1.35(a-1)

STRIKE Number (only if not a spread) 202 1.35(a-1)

SPREAD_TYPE Text Type of spread order placed

CROSS_INTENT_CODE Text

Code indicating whether the cross request place 

was to either buy, sell or both

QUANTITY Number Quantity specified in the cross request

FIRM_NUMBER Text

Clearing firm number identifying the firm 

responsible 

BRANCH_CODE Text

Code indicating the city location of the device 

used to enter the order

PARTICIPANT Text

Participant number of the individual who entered 

the cross request

SUBGROUP Text

Subgroup of the individual who entered the cross 

request

MEMBER_REF_ID Text

Code that uniquely identifies the entity 

responsible for the cross request entered

 Page 25
CROSS REQUEST LEG

Field Data type Description Tag Number CFTC Rule

CROSS_REQUEST_SPREAD_ID Number (only if spread)

CROSS_REQUEST_SPREAD_LEG_NO Text

Generated number uniquely identifying the leg of 

the spread

COMMODITY_CODE Text Unique product identifier of the leg 55 1.35(a-1)

CONTRACT_YEAR Text yyyy 200 1.35(a-1)

CONTRACT_MONTH Text mm 200 1.35(a-1)

PRODUCT_CAT Text F = futures, C = call, P = put 461 1.35(a-1)

OPTION_TYPE Text American or European option

STRIKE Number (only if option) 202 1.35(a-1)

Page 26
REGULATORY - OPEN INTEREST BY FIRM

Field Data type Description Tag Number CFTC Rule

CLEARING_MEMBER_ID Text Name of the clearing member

EXCHANGE Text

Exchange designation of multilisted products 17.00(g)

REPORTING_DATE Date/Time 113 17.00(g)

CLEARING_MEMBER_ID Text Firm the trader clears through 17.00(g)

PRODUCT_CAT Text F=Futures, C=Call; P=Put 461 17.00(g)

OPTION_TYPE Text American or European Option 17.00(g)

OPEN/CLOSE_TRANS Text Opening or Closing Transaction 77

COMMODITY_CODE_1 Text

Exchange-assigned commodity 

code for the futures or option 

contract 55 17.00(g)

COMMODITY_CODE_2 Text

Exchange-C12assigned 

commodity code for the futures or 

option contract 17.00(g)

CONTRACT_YEAR_1 Text

Expiration date or delivery date of 

the reported futures or options 

contract 200 17.00(g)

CONTRACT_MONTH_1 Text

Expiration date or delivery date of 

the reported futures or options 

contract 200 17.00(g)

CONTRACT_DAY_1 Text

Expiration date or delivery date of 

the reported futures or options 

contract 17.00(g)

CONTRACT_YEAR_2 Text

True expiration date of an option 

identified by only year and month 17.00(g)

CONTRACT_MONTH_2 Text

True expiration date of an option 

identified by only year and month 17.00(g)

CONTRACT_DAY_2 Text

True expiration date of an option 

identified by only year and month 17.00(g)

CONTRACT_YEAR_3 Text

Expiration date or delivery month 

and year of the future or other 

instrument that a position is 

exercised into from a date-specific 

or flexible option 17.00(g)

CONTRACT_MONTH_3 Text

Expiration date or delivery month 

and year of the future or other 

instrument that a position is 

exercised into from a date-specific 

or flexible option 17.00(g)

CONTRACT_DAY_3 Text

Expiration date or delivery month 

and year of the future or other 

instrument that a position is 

exercised into from a date-specific 

or flexible option 17.00(g)

PROPRIETARY_OR_CUSTOMER Text "P" or "C"

EFP_BOUGHT Number

EFP_SOLD Number

EFS_BOUGHT Number
EFS_SOLD Number

STRIKE Number 202 17.00(g)

OPEN_LONG Number

Open long positions for firm at 

beginning of trading day 18.00(a)

OPEN_SHORT Number

Open short positions for firm at 

beginning of trading day 18.00(a)

TRADE_BOUGHT Number

Positions bought for firm on trading 

day 16.00(a)

TRADE_SOLD Number

Positions sold for firm on trading 

day 16.00(a)

CLOSE_LONG Number

Open long positions for firm at end 

of trading day 18.00(a)

CLOSE_SHORT Number

Open short positions for firm at 

end of trading day 18.00(a)

TRANSFERS_BOUGHT Number Buy transfers for day

TRANSFERS_SOLD Number Sell transfers for day

DELIVERY_ISSUES Number Delivery notices issued for day 17.00(g)

DELIVERY_STOPS Number Delivery notices stopped for day 17.00(g)

EXERCISE_BOUGHT Number Exercise notices for buy

EXERCISE_SOLD Number Exercise notices for sell

ASSIGN_BOUGHT Number Assignments for buy

ASSIGN_SOLD Number Assignments for sell

GIVEUP_BOUGHT Number Give ups of long positions

GIVEUP_SOLD Number Give ups of short positions

ADJUSTMENTS_LONG Number Adjustments to long positions

ADJUSTMENTS_SHORT Number Adjustments to short positions

REGULATORY - PAY COLLECT

Field Data type Description Tag Number CFTC Rule

REPORTING_DATE Date/Time 113 16.00(a)

CLEARING_MEMBER_ID Text Firm the trader clears through 528 16.00(a)

ORIGIN Text House or Customer 16.00(a)

PRODUCT_CAT Text F=Futures, C=Call; P=Put 461 16.00(a)

OPTION_TYPE Text American or European Option

COMMODITY_CODE Text Unique product identifier 55 16.00(a)

CONTRACT_YEAR Text yyyy 200 16.00(a)

CONTRACT_MONTH Text mm 200 16.00(a)

STRIKE Number 202 16.00(a)

GROSS_PAY_AMT Number

Total amount due from 

clearinghouse in specified contract

GROSS_COLLECT_AMT Number

Total amount due to clearinghouse 

in specified contract

NET_PAY_COLLECT Number

Net of payments due and from 

clearinghouse

REGULATORY - DAILY ACTIVITY

Field Data type Description Tag Number CFTC Rule

EXCHANGE_ID Text Unique identifier for an exchange
REPORTING_DATE Date/Time 113 16.00(a)

PRODUCT_CAT Text F=Futures, C=Call; P=Put 461 16.00(a)

OPTION_TYPE Text American or European Option

COMMODITY_CODE_1 Text

Exchange-assigned commodity 

code for the futures or options 

contract 55 16.00(a)

COMMODITY_CODE_2 Text

Exchange-assigned commodity 

code for a futures contract or other 

instrument that a position is 

exercised into from a date-specific 

or flexible option

CONTRACT_YEAR_1 Text

Expiration date or delivery date of 

the reported futures or option 

contract 200 16.00(a)

CONTRACT_MONTH_1 Text

Expiration date or delivery date of 

the reported futures or option 

contract 200 16.00(a)

CONTRACT_DAY_1 Text

Expiration date or delivery date of 

the reported futures or option 

contract

CONTRACT_YEAR_2 Text

True expiration date of an option 

identified by only year and month

CONTRACT_MONTH_2 Text

True expiration date of an option 

identified by only year and month

CONTRACT_DAY_2 Text

True expiration date of an option 

identified by only year and month

CONTRACT_YEAR_3 Text

Expiration date or delivery month 

and year of the future or other 

instrument that a position is 

exercised into from a date-specific 

or flexible option

CONTRACT_MONTH_3 Text

Expiration date or delivery month 

and year of the future or other 

instrument that a position is 

exercised into from a date-specific 

or flexible option

CONTRACT_DAY_3 Text

Expiration date or delivery month 

and year of the future or other 

instrument that a position is 

exercised into from a date-specific 

or flexible option

FIRST_NOTICE_DAY Date 

LAST_TRADING_DAY Date

DELTA_FACTOR Number

VOLUME_OF_TRADING Number

VOLUME_OF_EFP Number

VOLUME_OF_EFS Number

OPEN_INTEREST Number

DELIVERY_NOTICES Number
STRIKE Number 202 16.00(a)

OPENING_HIGH Number

Highest sale or bid during the 

opening period 16.01(b)

OPENING_LOW Number

Lowest sale or bid during the 

openting period 16.01(b)

OPENING_HIGH_TYPE Text 16.01(b)(1)(ii)

OPENING_LOW_TYPE Text 16.01(b)(1)(ii)

CLOSING_HIGH Number

Highest sale or bid during the 

closing period 16.01(b)

CLOSING_LOW Number

Lowest sale or bid during the 

closing period 16.01(b)

CLOSING_HIGH_TYPE Text 16.01(b)(1)(ii)

CLOSING_LOW_TYPE Text 16.01(b)(1)(ii)

HIGH_BID_ASK_ACT Text

Whether source of high was best 

bid, best ask or an actual 

transaction price 16.01(b)

LOW Number Low for day 16.01(b)

LOW_BID_ASK_ACT Text

Whether source of low was best 

bid, best ask or actual transaction 

price 16.01(b)

SETTLEMENT Number Final settlement price 63 16.01(b)

SETTLE_UNDERLYING Number Final settlement price in underlying

SETTLE_BID_ASK_ACT Text

Whether source of settle was best 

bid, best ask, nominal or actual 

transaction price 16.01(b)

REGULATORY - LARGE TRADER

Field Data type Description Tag Number CFTC Rule

CLEARING_MEMBER_ID Text Firm the account clears through 528 17.00(d),(e)

REPORTING_FIRM Text

Number assigned by the CFTC to 

identify reporting firms

CUSTACCT_ID Text Customer account number 1 17.00(d),(e)

SPECIAL_ACCOUNT_ID Text

Unique identifier assigned by the 

reporting firm to each special 

account

EXCHANGE_ID Text Unique identifier for an exchange

REPORTING_DATE Date/Time Date of large trader report 17.00(d),(e)

PRODUCT_CAT Text

F=Futures, C=Call Option, P=Put 

Option, N=Delivery Notice 

(Issue/Stop), EP=EFP, ES=EFS, 

T=Transfer Trades 461 17.00(d),(e)

OPTION_TYPE Text American or European Option

COMMODITY_CODE_1 Text

Exchange-assigned commodity 

code for the futures or options 

contract 55 17.00(d),(e)
COMMODITY_CODE_2 Text

Exchange-assigned commodity 

code for a futures contract or other 

instrument that a position is 

exercised into from a date-specific 

or flexible option

CONTRACT_YEAR_1 Text

Expiration date or delivery date of 

the reported futures or options 

contract 200 17.00(d),(e)

CONTRACT_MONTH_1 Text

Expiration date or delivery date of 

the reported futures or options 

contract 200 17.00(d),(e)

CONTRACT_DAY_1 Text

Expiration date or delivery date of 

the reported futures or options 

contract 17.00(d),(e)

CONTRACT_YEAR_2 Text

Expiration date or delivery month 

and year of the future or other 

instrument that a position is 

exercised into from a date-specific 

or flexible option 17.00(d),(e)

CONTRACT_MONTH_2 Text

Expiration date or delivery month 

and year of the future or other 

instrument that a position is 

exercised into from a date-specific 

or flexible option 17.00(d),(e)

CONTRACT_DAY_2 Text

Expiration date or delivery month 

and year of the future or other 

instrument that a position is 

exercised into from a date-specific 

or flexible option 17.00(d),(e)

STRIKE Text 202 17.00(d),(e)

LONG_POSITION_QTY Number

Long position, delivery notices, 

stopped, purchases of futures for 

cash, or purchases of swaps for 

cash 17.00(d),(e)

SHORT_POSITION_QTY Number

Short position, delivery notices 

issued, sales of futures for cash, or 

sales of swaps for cash 17.00(d),(e)

ADD_CHANGE_DELETE Text

Indicator for adding a new record 

or changing/deleting a previous 

record
BACK OFFICE - PRODUCT MASTER

Field Data type Description Tag Number CFTC Rule

PRODUCT_CAT Text

F=Futures, C=Call Option, P=Put 

Option 461

OPTION_TYPE Text American or European Option

COMMODITY_CODE Text Unique product identifier 55

STRIKE Number Zero if future contract 202

COMMODITY_NAME Text Descriptive name of commodity

CURRENCY_CODE Text USD = US dollars

SETTLEMENT_METHOD Text Cash or Delivery

CONTRACT_SIZE Number Underlying quantity size

CONTRACT_FACTOR Number Contract Multiplier

TICK Number Incremental price move

CONTRACT_UNIT_DESC Text e.g., cents per pound

POSITION_LIMIT Number

Quantity which, if reached, 

triggers reporting requirements

PRICE_LIMIT Number Contract daily price limit

OPEN_TIME Date/Time

Time of day when trading for the 

contract begins

CLOSE_TIME Date/Time

Time of day when trading for the 

contract ends

BACK OFFICE - MONTHLY PRODUCT MASTER

Field Data type Description Tag Number CFTC Rule

CHANGE_DATE Date/Time

Date of entry (greatest date will 

represent current specs)

PRODUCT_CAT Text

F=Futures, C=Call Option, P=Put 

Option 461

OPTION_TYPE Text American or European Option

COMMODITY_CODE Text Unique product identifier 55

CONTRACT_MONTH Text mm 200

CONTRACT_YEAR Text yyyy 200

STRIKE Text 202

LIMIT_MOVE_SIZE Number

Allowable price movement which 

defines allowable trading range for 

the day

FIRST_TRADE_DATE Date/Time

FIRST_INTENTION_DATE Date/Time

FIRST_NOTICE_DATE Date/Time

FIRST_DELIVERY_DATE Date/Time

LAST_TRADE_DATE Date/Time

LAST_NOTICE_DATE Date/Time

LAST_DELIVERY_DATE Date/Time

SUSPENSION_START_DATE Date/Time

SUSPENSION_END_DATE Date/Time

Page 32
BACK OFFICE - CONNECTION ACTIVITY

Field Data type Description Tag Number CFTC Rule

TERMINAL_ID Text ID of terminal connection

SUB_GROUP Text ID of the trader subgroup

LOGON_ID Text ID of the broker using the terminal 466

ACTION Text ON: Log on / OFF: Log off

ACTION_TIME Date/Time

Time of action (i.e., time of log on 

or log off) 

BACK OFFICE - TRADERS

Field Data type Description Tag Number CFTC Rule

LOGON_ID Text Trader's unique identifier 466

NAME Text For entities other than individuals

LAST_NAME Text

FIRST_NAME Text

ADDRESS1 Text

ADDRESS2 Text

ADDRESS3 Text

CITY Text

STATE Text

POSTAL_CODE Text

COUNTRY_CODE Text

TELEPHONE_DAY Text

TELEPHONE_EVENING Text

TELEPHONE_EMERGENCY Text

EMAIL Text

FAX Text

ENTITY_IS_INDIVIDUAL Bool

ENTITY_IS_SOLEPROP Bool

ENTITY_IS_TRUST Bool

ENTITY_IS_CORP Bool

ENTITY_IS_PARTNERSHIP Bool

ENTITY_IS_JOINT Bool

ENTITY_IS_OTHER Text

PRINCIPLE_BUSINESS Test Commercial, Hedge...

TRADING_PRIVLEDGES Text

START_DATE Date/Time

END_DATE Date/Time

BACK OFFICE - CLEARING MEMBERS

Field Data type Description Tag Number CFTC Rule

CLEARING_MEMBER_ID Text Clearing firm's unique identifier 528

NAME Text

LAST_NAME Text If clearing member is an individual

FIRST_NAME Text

 Page 33
ADDRESS1 Text

ADDRESS2 Text

ADDRESS3 Text

CITY Text

STATE Text

POSTAL_CODE Text

COUNTRY_CODE Text

TELEPHONE_DAY Text

TELEPHONE_EVENING Text

TELEPHONE_EMERGENCY Text

ENTITY_IS_INDIVIDUAL Bool

ENTITY_IS_SOLEPROP Bool

ENTITY_IS_TRUST Bool

ENTITY_IS_CORP Bool

ENTITY_IS_PARTNERSHIP Bool

ENTITY_IS_JOINT Bool

ENTITY_IS_OTHER Text

START_DATE Date/Time

END_DATE Date/Time

BACK OFFICE - CLEARING MEMBER CONTACTS

Field Data type Description Tag Number CFTC Rule

CLEARING_MEMBER_ID Text Clearing firm's unique identifier 528

CONTACT_TYPE Text Compliance, Legal, Financial, IT

LAST_NAME Text

FIRST_NAME Text

ADDRESS1 Text

ADDRESS2 Text

ADDRESS3 Text

CITY Text

STATE Text

POSTAL_CODE Text

COUNTRY_CODE Text

TELEPHONE_DAY Text

TELEPHONE_EVENING Text

TELEPHONE_EMERGENCY Text

EMAIL Text

FAX Text

BACK OFFICE - TRADER/CLEARING RELATIONSHIPS

Field Data type Description Tag Number CFTC Rule

LOGON_ID Text 466

CLEARING_MEMBER_ID Text 528

TERMINAL_ID Text

SUB_GROUP Text ID of the trader subgroup

START_DATE Date/Time

END_DATE Date/Time

 Page 34
GIVEUP_FIRM_ID Text

If trade is placed for a customer 

with the intention of giving it up 

from one clearing firm to another.

BACK OFFICE - ACCOUNT RELATIONSHIPS

Field Data type Description Tag Number CFTC Rule

LOGON_ID Text 466

SUB_GROUP Text ID of the trader subgroup

CLEARING_MEMBER_ID Text 528

CUSTACCT_ID Text

CONTROLLER_TYPE Text

O = Owner of the account; D = 

Discretion over account; B = Both 

Owner and Discretion; C = Clear 

account

ACCOUNT_TYPE Text Spec, Hedge, Error, Omnibus

OPEN_DATE Date/Time

CLOSE_DATE Date/Time

BACK OFFICE - TRADING PRIVILEGES

Field Data type Description Tag Number CFTC Rule

LOGON_ID Text 466

SUB_GROUP Text ID of the trader subgroup

CLEARING_MEMBER_ID Text 528

TRADING_PRIVLEGES Text

START_DATE Date/Time

END_DATE Date/Time

 Page 35

Regulator

Information added 

at Clearing

Information added by 

Firm (post-execution)

In

Info

Te

Order Entry by 

Customer

1

4

5 Data returned to both Exchange and Firm
1. Entry by Customer

*Order ID (37)-Account ID (1) *Clearing Member ID(52*Give Up Firm ID -Product Code (461) -Option Type -Open/Close (77) -Commodity Code (55) *Trading Session ID (336-Contract Month (200) -Contract Year (200) 

Account 

Relationship 

Data 

All informat

passed to 

Terminal Operator

Data 

Attachments Clearing Member 

Data 

Product 

Master

- = User entered information * = System 
2. Info Added by Entry of Termi

-Trader ID *Time O

*Exchange Origin -Logon 

-Subgroup ID *Termin-CTI Code 

*Action (log on or off) 

All info passed 

to execution by 

algorithm or 

Broker/ 

Market Maker 

Terminal 

Operator 

Data 

Action Log 

Data 
3. Info Added by Entry at Time of Execution

-Exchange Execution *Time Order Match *Trade ID *Time Trade Match (60)*Time Trade Reported (113) -Account ID (Traders)-Order Origin -Quantity-Linked Order ID -Price (44)-Link Reason -Remaining Quantity 

-Trader ID

All 

information 

passed to 

Firm
R

5. Info Added by Entry at Clearing

*Status

*Open/Close*Settlement (63) All info passed 

to Regulator in 

data feed

4. Info Added by Entry at Firm 

(post-execution)

*Time Confirmed

*Trans Code*Time Trade to Clear (229)*Ave Price Group ID (6)

All 

information 

passed to 

Clearing

Firm Data