Interim Report: 

Recommendations for 

Standardization of 

Protocol and Content of 

Order Flow Data 

Commodity Futures Trading Commission 

Technology Advisory Committee 

Subcommittee on Standardization
 

November 27, 2001 

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 crosssection of the futures and options community. 

The subcommittee, comprised of members of the CFTC 

Technology Advisory Committee and representing a 

wide range of interests, also 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. 

Sincerely, 

The Standardization Subcommittee 
 

Table of Contents 

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

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

 Goals of the Subcommittee......................................... 2 

 Issues Addressed by Subcommittee............................. 3 

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

 Data Requirement Comparison.................................... 7 

 Subcommittee Recommendations................................ 9 

 Conclusion.............................................................. 12 

 Exhibit A – Subcommittee Members............................. 13 

 Exhibit B – Subcommittee Advisors.............................. 14 

 Exhibit C – Data Requirements.................................... 15 

 Exhibit D – Order Flow Chart....................................... 31 
 

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

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

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

The subcommittee recommends that the industry 

implement the recommended standard by June 30, 

2003. This date is far enough in 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. 

1 
 

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 

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

2 
 

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. 

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 six months in order 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 

an industry standard for protocol and content. If the 

protocol were standardized to contain necessary 

information, 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 have 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 

things to be more efficient, including back office 

operations. This is because each user has to translate 

each of the different protocols to its own system to make 

things flow automatically. This was less efficient than 

creating a standard for the industry as a whole to use. 

3 
 

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 

expanded use of electronic trading and EORS. 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. There are many 

different protocols and versions of protocols available 

and everyone uses something that is slightly different. 

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 ISVs. Currently, ISVs have little 

incentive to move to a protocol standard. Additionally, 

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. 

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

4 
 

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

cognizant of what other groups are doing, as the Bond 

Markets Association and Futures Industry Association 

are working on similar initiatives and the Managed 

Funds Association had a similar project several years 

ago. The subcommittee noted that it is important that 

they not run afoul of other industry trends. Towards that 

end, the subcommittee contacted representatives from 

the BMA and FIA, as well as the Chairman of MFA’s 

Standards and Technology Committee. 

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 

5 
 

fund managers, brokers, and other industry participants. 

Representatives from FIX 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 stressed 

that each of the other versions has inherent limitations 

and that FIX version 4.3 is the most comprehensive, upto-date protocol in the financial services industry. 

BOND MARKETS ASSOCIATION VOLUNTARY 

PROTOCOLS INITIATIVE 

The Bond Market Association 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 

6 
 

the same language. By developing a common protocol, 

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

add more instruments as the process continues. 

As part of BMA’s initiative, 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 fixedincome securities in its version 4.2 in an effort to improve 

the global trading process. Working on a joint initiative 

with FIX will enable 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. 

Data Requirement Comparison NFA provided the subcommittee with the data fields 

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. 

7 
 

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 

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 

8 
 

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: 

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. 

9 
 

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 industry. The comparison of the data 

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

the requirements listed in the 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 

standardization of the data components is key to any 

standardization effort in the industry. 

2. PROTOCOL STANDARDIZATION 

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. 

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. 

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 

timeframe for the implementation of the 

recommendations 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 of June 30, 

2003 was agreed upon. This is the date that the 

10 
 

subcommittee strongly recommends that all futures 

participants start utilizing the standard by that time. 

As the subcommittee is recommending voluntary 

implementation of the standard rather than mandatory 

use of the protocol, this date should not result in an 

undue burden on the industry. It was also determined 

that new companies should begin utilizing the standard 

upon 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 recommendations were sent to FIA, MFA, 

FIX, and BMA, as well as the National Introducing 

Brokers Association for comment. 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 

interim 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 

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

11 
 

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 

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. 

12 
Exhibit A – Subcommittee Members 

Chris Concannon 

Vice President of Strategic Planning and 

General Counsel 

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 

Chairman and Founder 

e-Pit Systems, Inc. 

351 California Street, 14th Floor 

San Francisco, CA 94104 

Scott Johnston 

Managing Director and Chief Information Officer 

Chicago Mercantile Exchange 

30 South Wacker Drive 

Chicago, IL 60606-7499 

Hank Mlylarski 

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 

13 
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 

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 

14 
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
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
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)
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)

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

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

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

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

Regulator

Information added 

at Clearing

Information added by 

Firm (post-execution)

Informatio

at Exec

Information a

Terminal O

Order Entry by 

Customer

1

2

3

4

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

*Order ID (37)-Account ID (1) *Clearing Member ID(528) *Give Up Firm ID -Product Code (461) -Option Type -Verb (5-Open/Close (77) -Price (4-Commodity Code (55) -Order T*Trading Session ID (336) -Duratio-Contract Month (200) -Strike( 2-Contract Year (200) -Quantity 

Account 

Relationship 

Data 

All information 

passed to 

Terminal Operator

RelinforetrAtt

Data 

Attachments Clearing Member 

Data 

Product 

Master

- = User entered information * = System generated info
2. Info Added by Entry of Terminal Opera

-Trader ID *Time Order Entere

*Exchange Origin -Logon ID (466)

-Subgroup ID *Terminal ID-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
Regulat

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