SEF/DCM Data Layout Overview and Implementation Reference
Version 2.3.0.1
National Futures Association CONFIDENTIALITY: This message and any attachments are sent on a confidential basis and are intended solely for the use of the person or entity to whom they are addressed. This message and any attachments may contain information that is privileged, confidential, exempt from disclosure and/or subject to federal privacy legislation. If the recipient of this message is not the intended recipient, please notify the sender immediately and then delete this message and any attachments. You are hereby notified that reliance on, disclosure or dissemination of, and distribution or copying of this message and any attachments is strictly prohibited.
Data File Overview ........................................................................................................................................................................................................................................................... 5
File Format ...................................................................................................................................................................................................................................................................... 10
SEF Escalation Procedures ............................................................................................................................................................................................................................................. 14
SEF Profile Questionnaire .............................................................................................................................................................................................................................................. 14
Order Carryover Activity ................................................................................................................................................................................................................................................ 19
Position Monitoring .................................................................................................................................................................................................................................................... 52
Clearing Member ........................................................................................................................................................................................................................................................ 57
Clearing Member Contact ........................................................................................................................................................................................................................................... 59
Side Matrix ................................................................................................................................................................................................................................................................. 82
This document outlines the data requirements necessary for NFA to conduct trade practice and market surveillance for a swap execution facility (SEF) or designated contract market (DCM). NFA currently uses an electronic system to conduct surveillance for both designated futures contract markets and retail OTC currency trading facilities. This system can essentially be broken down into two parts: Trade Practice Surveillance and Market Surveillance/Supervision. In order to conduct adequate trade practice surveillance, we must obtain data to essentially recreate the events of the trading day. As a result, not only do we collect information about trade executions, but we also collect information about orders, whether filled or unfilled, off-exchange activity, and the supporting data that tells us who is trading and what is being traded. For Market Surveillance/Supervision, we add data to determine open interest, aggregate positions and delivery issues. Given the timing of data flows from the various participants in the exchange process, we perform most of our surveillance functions on a trade day + 1 basis. Specifically, we load the prior day's transactions into our relational database and then "replay" that trading day using our filters to highlight the behaviors that merit further scrutiny. The following listing of data requirements represents an attempt to define the minimum bits of information we would require to "recreate" the trading day for a SEF or DCM. We have used existing trading systems and the CFTC’s final SEF regulations as our guide in developing these requirements but we recognize that further modifications may be necessary to fully capture all aspects of SEF activity. This document provides data layouts for both SEF and DCM exchanges. Throughout the document, references to SEF generally also refer to DCM unless specifically noted otherwise.
Data File Overview The data file requirements consists of a number of core data files that are to be submitted on a nightly basis to NFA’s SFTP server. There may be multiple asset classes traded on a SEF’s platform. For each report type, the asset classes may be combined into a single file or separate files may be submitted for each asset class. The general naming convention for each of the reports is as follows: Single file submissions:
ReportType_YYYYMMDD.xml
e.g. Msg_20110815.xml, Deal_20110815.xml
Report by asset class:
ReportType_AssetClass_YYYYMMDD.xml
e.g. Msg_IR_20110815.xml, Msg_CD_20110815.xml, Deal_IR_20110815.xml, Deal_CD_20110815.xml
* See Product Matrix for list of AssetClass designations. * See Required Nightly Files for a list of ReportType designations.
Note: NFA will not begin processing an asset class until all data files have been submitted for each asset class. Additionally, the SEF must provide an explicit list of files that will be submitted using the SEF_DataFileSubmission_List.xlsx Excel file templete. The files listed in this template will be added to NFA’s SEF system to identify the expected files on a nightly basis. The template only needs to be submitted once. Any file changes need to be communicated to NFA in advance for future file changes. Each file/report contains an AssetClass attribute that must be populated according the AssetClass descriptors defined in the Product Matrix.
Asset Class Description AssetClass Value/Descriptor
Note: The use of the “ALL” AssetClass descriptor may only be used when submitting a single file for any given report and may not be used in combination with any other AssetClass descriptors. For example, the Trader report may be submitted in any of the following formats:
1. SEF has a list of traders for the SEF that are not segmented according to asset class.
Recommended Submission: Submit a single Trader report using the “ALL” AssetClass descriptor.
2. SEF has a list of traders for the SEF that are segmented according to asset class
Recommended Submission 1: Submit a single Trader report and merge traders from each of the asset classes into a single data file. The
AssetClass attribute for each trader record should contain the appropriate AssetClass descriptor (e.g. IR, CD).
Recommended Submission 2: Submit individual Trader reports for each of the asset classes. The AssetClass attribute for each trader record
should contain the appropriate AssetClass descriptor (e.g. IR, CD).
3. SEF has a list of traders that apply to IRS and CDS asset classes and another list of traders that apply to commodity and currency asset
classes.
Recommended Solution 1: Submit a single Trader report and merge traders from each of the asset class groups into a single data file. The
AssetClass attribute for each trader record should contain the appropriate AssetClass descriptor (e.g. IR, CD).
Recommended Solution 2: Submit individual Trader reports for each of the asset classes. The AssetClass attribute for each trader record
should contain the appropriate AssetClass descriptor (e.g. IR, CD).
If it is not possible to distinguish between the IRS and CDS traders, then either:
a) Submit that list of traders in separate files under each respective AssetClass descriptor.
b) Submit single list of traders in single file using the “ALL” descriptor, but the data must be unique within the date file (see File
Required Nightly Files Below is a comprehensive list of all the required data files that need to be sent on a nightly basis. The ReportType abbreviations in parenthesis indicate the root node for each message type and must be used as part of the file naming convention. Files must be submitted as comprehensive reports – delta files are not acceptable. Exchange Activity
Messages (Msg) – The orderbook captures all order messages for central limit orderbook, RFQs, public and private auctions, and workups.
Deals (Deal) – All executed deals
Daily Activity (DailyAct) – Daily trade activity for each product.
Connection Activity (ConnAct) – Logs connection activity for traders/APIs
Product/Strategy
Product Master (ProdMstr) – Captures product attributes that are relatively static in nature
Tradable Instruments (TradeInstr) – Captures product attributes that are relatively dynamic in nature
Strategy (Strat) – Strategy layout provides information about each of the legs of a strategy/spread
Position Monitoring (PosMonitor) – Captures market surveillance limits and levels
Limit Grouping Relationship (LmtGrpRel) – Captures grouping relationships for market surveillance limits and levels
Static Data
Clearinghouse (ClrHs) – List of all affiliated clearing houses
Clearing Member (ClrMb) – List of clearing member firms
Clearing Member Contact (ClrMbCon) – List of contacts for each of the clearing member firms
Executing Firm (Firm) – List of exchange’s executing firms
Executing Firm Contact (FirmCon) – List of contacts for each of the executing firms
The layout for each of the required files will contain asterisk(s) next to the attribute names. These asterisks represent the column or group of columns (key) that must be unique per file. For example, in the Message report, the unique key consists of (BatchDate, SefId, AssetClass, SeqId). If more than one record is submitted that violates the above key, the file will be considered invalid.
Delivery Standards
Trade Day: For purposes of NFA's processing, a trade day is defined as the time span between the SEF's market open time and the subsequent market close time. Any activity that occurs within this time span will be considered part of the SEF's trading day and should be included in the batch file submission for that day. Generally, NFA expects a 5:00 PM (Eastern) closing time for each SEF; however, NFA also recognizes that individual SEFs may have already implemented different closing times. NFA can support alternative closing times as long as they provide sufficient time for file submission prior to NFA's deadline of 10:00PM (Eastern). In cases where the market is set to operate 24 hours a day with no open or close (except for an opening at the beginning of the week and a close at the end), then the SEF would have the following options:
1. If the SEF must impose a temporary break in 24 hour trading in order to provide settlement for clearing, then the SEF should use this break
as the end of its trading day for purposes of batch submission. Again, please note that the break should be set to provide sufficient time for file submission prior to NFA's deadline of 10:00PM (Eastern).
2. If the SEF has no break for settlement, then NFA would request an artificial break at 5:00 PM Eastern. Thus, using Friday, January 6, 2012 as
a batch day example, the batch file submission would include all activity after 5:00:00 PM (Eastern) on Thursday, January 5, 2012 through 5:00:00 PM (Eastern) on Friday, January 6, 2012. Note that if the SEF closes its 24 hour market at a specific time at the end of the week, then this time could be used as the cutoff for each day. Please contact NFA for guidance in this area.
NFA recognizes that the imposition of an artificial cutoff for purposes of batch submission may result in situations where a continuum of
market activity spans multiple batch dates. For example, an RFQ session may straddle the 5:00 PM cutoff whereby a quote is requested just prior to the batch cutoff while the actual dealer responses come after. In such scenarios, the SEF should adhere strictly to the cutoff time and split this continuum of market activity between the two batch dates.
Overall, note that the data submitted in the batch files must match the official numbers the SEF publishes on its website to the public. In other words, volume as well as price statistics for the day should agree with the data derived from the corresponding batch date submission.
NFA has developed and utilizes an Information Security Plan ("Plan") to protect its electronic data. The Plan is based on, and in some instances incorporates the guidelines for recommended security controls for information systems as outlined in the National Institute of Standards and Technology, Special Publication 800-53 (NIST SP 800-53), Revision 2, dated December 2007. NIST SP 800-53 was developed by NIST to assist federal government agencies, or other nongovernmental organizations, in implementing the Federal Information Security Management Act of 2002 (FISMA). NFA's systems containing data for which NFA acts a custodian for the CFTC have been accredited as being in compliance with these guidelines. NFA has applied the guidelines to NFA's other electronic systems, including the SWAP system in which the swap trade data is maintained.
Contact Request Procedure
The contact request procedure allows your firm to create contacts. Contacts are required in order for NFA to be able to send processing reports and for security
verification purposes. Use the Contact Request form to create your contact list.
There are two types of contacts that can be established:
Email Contacts
Email contacts receive the daily validation/discrepancy reports and missing file(s) report. At least one email contact is required to receive these
reports so that NFA can notify the SEF of processing issues with their files.
Security Contacts
Security contacts are those individuals that are authorized to request and authorize password or IP address changes. At least one security
contact is required in order to request password or IP address changes.
Security Request Procedure
The security request procedure allows your firm to make a request to change your FTP password or your IP address. Use the Security Request form to establish
your FTP account, change your password, or change your IP address information.
The escalation procedure is in place in the event that your firm is unable to submit your files, cannot receive daily reports, or any other technical issues.
Please call NFA Operations at (312) 781-1368
SEF Profile Questionnaire
Each SEF must complete a SEF Profile Questionnaire which consists of questions related to the operational details of the SEF as well as information such as asset
classes and execution methods.
Strategy Orders
A strategy order is a combination of multiple orders (legs) that work together as a single trading strategy. As part of market surveillance/trade practice, NFA will require that strategy orders be reported with enough information to determine the impact of these strategies on the orderbook. As a result, a file called the Strategy report will need to be included as part of your daily submission that describes the components of the SEF’s strategy orders. Each leg for the strategy should be reported as an entry in the strategy report. For example, a calendar spread should have two entries in the strategy report and butterflies should have three legs. Strategy orders may be traded in one of several ways. For example, they may trade Strategy-to-Strategy or the Strategy may be legged into and traded against outright orders. In either case, the underlying legs of a Strategy order must be defined in the strategy report. Strategies are to be reported in the Messages report as a single line item and each leg of the strategy is to be reported in the Strategy report. Product and tradable instrument fields should be left null and the Strategy Code (StratCode) is used to identify the underlying legs of the strategy using the Strategy Report. Price and quantity should be entered according to industry or SEF conventions. When quantity and side refer to an individual leg of a strategy in the Message, that leg must be reported as RefLegInd=1 in the Strategy report. See the Strategy layout for additional details.
CLOB The CLOB is the SEF’s central limit order book. Each tradable instrument should be reported under a unique SessionId. Report all firm price
messages. These messages include those that are actionable by the participant.
Workup A Workup is a session type that is spawned from price discovery (deal) in another session. Workup orders are basically “expandable” orders in which additional quantity may be traded after a buyer and seller have been previously matched. Workups must always be tied to an initial order that gets matched. The workup will be conducted in its own session separately from the initial order, but will be tied together in the Messages report using LinkMsgId attribute. When one message can be clearly identified as that which initiated the workup, enter the message’s MsgId into the LinkMsgId attribute of the workup’s initial messages. For example, enter the MsgId of the aggressing order into the LinkMsgId attribute of all messages that are part of the workup session. When messages cannot be identified as the initiator of the workup, enter the MsgId for one side of the deal. The Messages layout will provide additional details for workup orders.
Orders that get migrated to a workup session must be able to tie back to the CLOB order prior to the workup session. If the MsgID changes when the order gets
migrated, then the LinkMsgId must be populated with the MsgId from the original CLOB order. The same will be true if a Workup Order gets migrated back to
the CLOB after session expiration.
Auctions An auction is a session type that is held to facilitate settlement of a large number of contracts at once, at a fixed cash settlement price. The auction takes place
in two stages. Stage I is typically where participating dealers submit bid/offer prices and a fixing price is established. Stage II is when the actual auction occurs
after the fixing price has been established and where participants can enter orders at the fixing price.
All messages that are generated during the Phase I price fixing are to be submitted. All messages that are generated during Stage II will be required to be
submitted in the Messages report.
Private Auction A private auction auction is a session type that is held to facilitate settlement of a large number of contracts at once. The private auction has two stages (can
occur simultaneously). Stage 1 includes market participants submitting bid/offer prices. The SEF may or may not establish hidden fixed price range. Stage II
begins with the matching of trades for participants who have crossed bid/offer prices. The primary difference between a private auction and a traditional
auction is that deals may be done at different prices. All messages that are generated during both phases should be submitted. In addition, if a fixed price range
is established, even for validation purposes; this reference price should be listed in the deal record under RefPrice.
Request for Quote (RFQ) All RFQ messages must be submitted including those RFQs not resulting in a deal. Report all price changes that occur during the life of the RFQ.
Actionable Indicative Message (AIM) Sessions AIM describes sessions that are hybrids of CLOB/RFQ. The Session type captures the situation where dealers broadcast quotes to the market. Market
participants may then choose to act upon the quote (specifying quantity). The dealer then has a last look, where they can accept or reject the reply.
To limit the volume of indicative quotes we receive, report only the indicative quotes that were acted upon (the live quote). Each acted upon indicative quote is
a new session (SessionId) of type (SessionType) AIM.
The general flow of events of an AIM session is as follows:
1. Indicative quote that was acted upon is the first message reported by the session – the visibility of this message is Public, all remaining visibilities are
private.
2. Subsequent messages may include where the user specifies quantity or the dealer either confirms (CONF) or rejects (REJECT) the deal. If a negotiation
begins, report these messages under the same SessionId.
Request for Cross (RFC) Sessions The Request for Cross (RFC) session type is used to identify the pre-cross, affirmation session. The affirmation process identifies the request for and potential
confirmation of orders that are to be crossed in the market. Once the cross is affirmed, the orders should be moved to the CLOB session type. Each request for
cross should have a unique Session Id.
Orderbook (ORD) Sessions The order book (ORD) session type is used to identify an orderbook as defined in §37.3(a)(3) that is not explicitly a central limit order book (CLOB). Often, this
session type is refered to as a bulletin board. ORD will provide for resting and aggressing firm orders that have no last-look functionality. Typically, ORD
transactions are executed exclusively by aggressing orders, consequentially the order book has no matching algorithm.
Permitted Method of Execution (PME) Sessions The Permitted Method of Execution (PME) session type is used to identify any activity that is not representative any other session types, yet, is permissible for
permitted transactions. This session type should only be used in consultation with NFA.
Voice Request for Quote (VRFQ) Sessions The Voice Request for Quote (VRFQ) session type is used to identify RFQ activity that includes a voice compontent to its audit trail. This session type should only
For SEF's listing the same instrument on separate platforms/liquidity pools, the MktSegId field is used to segregate messages by platform/liquidity pool. For
example, if a SEF has two platforms each making the same instrument available to trade:
a) SEF's fully electronic CLOB (ECLOB)
b) hybrid voice and electronic CLOB (HVCLOB)
and these platforms do not interact (i.e. an ECLOB bid cannot cross with an HVCLOB offer) the MktSegId field is used to explicitly identify which liquidity pool the
order can interact with. For SEF's w/o multiple liquidity pools in the same instrument, the tag can be the same as SefId. The field will prevent NFA from bundling
orders that cannot interact when reconstructing order books and provide a descriptor for why the messages will not interact.
Order Carryover Activity No matter whether the batch cutoff is real or artificial, the SEF may have outstanding orders that span multiple batch dates (e.g., Good Until Cancelled orders). Generally, there are three approaches to handling such orders in the batch file submission:
1. SEF Cancels All Open Orders – If the SEF automatically cancels all open orders at the end of the day, then the SEF should simply send a DELETE record for each cancelled order in its messages file.
2. SEF Re-adds Orders the Next Day with Same Order Id - If the SEF temporarily cancels orders at the end of the day and then re-adds them on
the next trading day using the same order id as the original entry, then it should utilize the ACTIVE/INACTIVE transaction types. In this case, the INACTIVE message should be applied to orders that are temporarily cancelled at the end of the day (with intent to carry over) and the ACTIVE message must be applied to these same orders as they are added to the next trading day.
In situations where open orders can potentially carry over to the next trading day but must first be reaffirmed by the trader before becoming active, the carryover may be handled on the following day by utilizing an ADD message for the reaffirmed order. This ADD message should contain the same message ID as the original order from the previous day and should also include any accompanying price or quantity changes. If you feel this approach applies to your SEF, then please contact NFA for further guidance on proper presentation.
3. SEF does nothing – If the SEF does not explicitly cancel or re-add Good Until Cancelled orders over the span of multiple trading days but
instead, simply leaves them open until they are filled or cancelled by the traders, then the SEF must notify NFA so NFA can properly track these orders internally across multiple days.
Regardless of the approach used, the SEF should notify NFA as to how it intends to handle carryover orders.
Product Identification As a part of its ongoing effort to support regulatory mandates, the International Swaps and Derivatives Association ("ISDA") has coordinated key industry
representatives in the creation of standardized taxonomies (classifications) for OTC derivatives. Although they are being developed independently, these
taxonomies are intended to support the CFTC's efforts to develop standardized "Unique Product Identifiers" for OTC Swaps and their derivative instruments.
Standardized product identification is essential for NFA's surveillance program so in an effort to support industry-wide standards, NFA is incorporating the IDSA
OTC taxonomy framework into its data specification. In this regard, it is important to first note that NFA references each instrument on two levels:
First, the more general and static characteristics of each standardized instrument such as asset class, whether the instrument is a swap or option, and
the exact underlying are all captured by entries in the Product Master file.
Second, the more specific and dynamic characteristics that are unique to each iteration of a standardized instrument such as tenor, effective date offset,
and strike price (for options) are all captured by entries in the Tradable Instrument file.
Within this two-tier structure, the ISDA taxonomies apply directly to the Product Master file. The actual terms from these taxonomies as they relate to the
Product Master are presented in the Product Matrix, an adjunct document which is published separately from this functional specification. Thus, for purposes of
reporting products in the Product Master, SEFs should utilize the same standardized terms outlined in the Product Matrix.
Automated Trading Systems (ATS)
Scenario Trader.PrinBus
Trader ID represents a pure Automated Trading System ATS
Primarily Automated Trading Program with a GUI used occasionally to troubleshoot/adjust pricing parameters ATS
Automated Trade Reccomendation/Signal system that prompts GUI order entry NATS
GUI order entry which uses algorithmic execution NATS
Trader trades using Voice Broker NATS
Trader ID represents an individual using only GUI (Pure Manual Entry) NATS
Description: Messages captures all activity for central limit orderbook (CLOB), RFQs, public and private auctions, AIM, and workups.
Notes: For CLOB sessions, only submit indicative messages that are able to be acted upon. For AIM sessions, only report order message with
indicative prices that are acted upon. Do not report system generated messages created by strategy auto-leggers.
Frequency: Daily received along with the nightly batch
Filename: Asset classes in single file: Msg_YYYYMMDD.xml (e.g. Msg_20110521.xml)
Asset classes broken out into separate files: Msg_AssetClass_YYYYMMDD.xml (e.g. Msg_cd_20110521.xml)
Mapping Req Data Type Description Sample Data
Report Block
Component Block
Sub Component Block
Attribute Name
Msg
BatchDate * DATE Batch date of message (YYYY-MM-DD) 2011-07-01
SefId * STRING(30) Swap execution facility ID
AssetClass * STRING(10) Asset class See Product Matrix
SeqId * STRING(30) Unique ID for each message. Must be unique for each batch date. Used primarily for communication purposes between regulator and SEF. Must be unique per asset class.
MsgId STRING(50) A unique identifier (per asset class) used to group together related messages. The MsgId must not be reused while the swap is active. The goal is to observe how an order changed over its lifetime by grouping together messages using a common ID. MsgId should get migrated to workup/auction session if MsgIds can be maintained between sessions. If migrated orders get a new msg id then the LinkMsgId field should be populated to tie the CLOB
order that spawned the workup with the workup messages.
SessionId STRING(50) The SessionID denotes an instance of a method of price discovery and trade execution. SEF's have various forms of price discovery (CLOB, RFQ, Workup, Auction, etc). These modes of price discovery are described by SessionType. The SessionId represents an instance of one of these methods. All CLOB messages will have the same SessionId. Each auction, RFQ,workup, or AIM session will be identified by its own distinct SessionId. Strategy orders will also be identified by their own distinct SessionId.
SessionType STRING(5) Describes the form of price discovery indexed by the SessionID. Note: New session types may be added over time.
RFQ = Request for quote AUC = Auction WKP = Workup CLOB = Central limit order book AIM = Actionable indicative message DARK = Private auction matching RFC = Request for cross ORD = Orderbook PME = Permitted Method of Execution VRFQ = Voice Request for Quote See Session Concepts for further detail
SessionEndDate C TIMESTAMP Date/time of session expiration. Sessions with user defined timed expirations will have SessionEndDate's reflecting the user definition. SessionEndDate is primarily for RFQ, AUC, and WKP session types. For CLOB session types, this attribute can be left blank.
SessionVisibility STRING(1) Used to indicate whether a message is broadcast to the entire market which would be public or a smaller subset of the market which would be private. Typically, CLOB would be public and RFQ would be private. Some sessions may have
both a private and a public phase to it. For workups, tag the message visibility according to the public/private phase at the time that the order was entered, modified, matched, etc. Note that this field represents a trader’s ability to participate in the market but does not preclude them from viewing activity.
BaseProd STRING(10) Base product See Product Matrix
SubProd C STRING(10) Sub product. Required for all asset classes except CU.
See Product Matrix
MsgDate TIMESTAMP(6) Date/time the message took place. Enter date/time for each message component.
2011-08-12 10:18:00.000
MsgTransType STRING(20) Text that describes the action taken on the order (e.g. size/price changes). Order component must be submitted on the same day the transaction occurs.
ADD = New order, RFQ, or Auction MODIFY = Price or quantity modification to order or RFQ. Workup modification by customer or dealer. REJECT = Order or workup rejected by dealer. RFQ rejected by dealer after customer acceptance based upon last look. CANCEL = Order, cancelled by customer DELETE = Order pulled by SEF (was never a deal) RESP = RFQ response quote from dealer ACCEPT = RFQ accepted by customer (offer to deal) CLOB_ACCEPT = Requester Matches with CLOB price for SEFs where RFQ can interact with the CLOB. CONF = RFQ, AIM confirmation from dealer (dealer has one last look between acceptance and confirmation)
VOLMATCH = Consignment or confirmation volume matches that are later aggregated into a consolidated deal record between counterparties, during a workup or auction.
MATCH = Order, RFQ, or workup filled in entirety (no remaining quantity) PARTIAL_MATCH = Order, RFQ, or workup partially filled (remaining quantity) CONT_MATCH = Contigent match SESSION = Session change. If order moves from one session type to another (i.e. CLOB to WKP). Only use for session changes where the MsgId does not change from one session to the next.INACTIVE = Order retains its MsgId but is taken out of the orderbook ACTIVE = Places inactive order back into orderbook with orginal MsgId
ModReason C STRING(20) Used only for modify (MsgTransType=MODIFY) messages to describe the reason for the MsgTransType modification. Leave null for all other MsgTransType transaction types (e.g. order type, duration changes, etc).
QT = Quantity change PR = Price change QT/PR = Quantity and price change VS = Manual user generated visibility change. Not intended to capture systematic visibility changes (e.g. workup timed transition from private to public)
CancelReason C STRING(20) Used only for cancel (MsgTransType=CANCEL) messages to describe the reason for the MsgTransType modification. Leave null for all other MsgTransType transaction types.
USER = User cancelled SYSTEM = System or User Preference cancelled
MsgTypePr C STRING(20) Price specific order designation. Leave blank for RFQ, WKP, AUC sessions.
MARKET = Market order – An order to buy/sell a product at the bid/offer price currently available in the marketplace. MIT – Market if touched – An order to buy/sell a product below (or above) the market. When the trigger price is touched, the order is submitted as a market order. STOP = Stop order – Stop order becomes a market order at the
specified stop price. LIMIT = Limit order – An order to buy/sell at a specified price or better. STOP LIMIT = Stop limit – Stop limit order becomes limit order at specified stop price. LIT = Limit if touched – An order to buy or sell a product below (or above) the market at the limit price or better. When the trigger price is touched, the order becomes a limit order. TOP = order set to either best bid or offer price. Order will be cancelled if no longer best bid or offer.
MsgTypeQt C STRING(20) Quantity specific order designation. Required for orders with specific order designation
AON = All or none – Filled only if the entire quantity is available to be executed. ICEBERG = Order where only a portion of the order is publicly disclosed.
CTICode STRING(1) Customer Type Indicator Code (CTI) Distinguishes for whom and on what type of account the trades are being placed. http://www.nfa.futures.org/news/newsNotice.asp?ArticleID=1362
1—For orders placed by an executing broker for his own account. 2—For orders placed by an executing broker for a firm proprietary account. 3—For orders placed by an executing broker for another broker who also has access to the system 4—For orders placed by an executing broker on behalf of a customer.
TradeInstrId C STRING(50) SEF unique ID for each tradable instrument. Leave blank for strategy message – strategy messages will populate the StratCode.
StratCode C STRING(100) Unique strategy identifier used to lookup leg components of the strategy in the Strategy layout. Required only if message is a strategy order.
Designated by SEF
Side STRING(2) Directional exposure participant is willing to take. For definitions, see Side Matrix.
B = Bid O = Offer BO = RFQ with no side specified i.e., Request for market– (RFQ only)
Qty NUMBER(24,4) Contract quantity (number of lots) – Order quantity MODIFY messages should submit
the new size – not the increment/decrement. Match orders should specify the actual quantity that is matched. Where contract sizes have not been defined, the notional value may be entered.
NotionalUnitType STRING(100) The unit of measure applicable for the notional quantity
See Product Matrix
QtyRemain NUMBER(24,4) Displayed quantity remaining of order at time of message. For a partial fill, the quantity of remaining contracts to fill. Enter zero for full matches and cancels.
MinFillQty C NUMBER(24,4) The minimum deal size that would be used to fill the given quantity. For example, a MinFillQty of 10 would mean that an order Qty of 50 would be filled at a minimum increment of 10 contracts at a time. MinFillQty can be left blank unless the trader explicitly designates minimum fill quantity. Not required for streaming quote messages.
Price C NUMBER(20,8) The negotiated price of the instrument. For strategy orders, enter the differential price. For options, enter the premium. If option trades in volatility, enter derived premium, if possible. Required for all sessions other than initial add in RFQ and options traded in volatility (OptVol).
MidMarketMark NUMBER(20,8) The mid-market mark of the swap represents an objective value that provides counterparties with a baseline to assess swap valuations for other purposes (§ 23.431).
OptVol C NUMBER(20,8) If option is traded in volatility (i.e.FX), then populate volatility here. If option trades in premium, then derive implied volatility
OptQuoteType C STRING(1) Describes how the trader quoted the message. Conditionally required on order being an option.
Strike NUMBER(20,8) Strike price for an option. If message is entered as a delta option, populate derived strike, if possible. For CU, must be reported in base currency.
PriceStatus C STRING(5) An indication of whether the price quoted is firm (immediately executable) or indicative (allows quoter a "second look" before execution). Not required for CANCEL, REJECT, or DELETE transaction types (MsgTransType).
FIRM = Firm Price IND = Indicative Price
PriceCont C NUMBER(20,8) Contingency price - If the order is contingent (e.g. "Stop") the price at which the stop is elected.
QtyHidden C NUMBER(24,4) Contingency quantity - "Additional quantity" hidden from the current Public Session) (e.g. icebergs). The manner in which hidden quantity is decremented is dependent on the SEF’s system.
Sessions are CLOB, RFQ, etc.
SplitPriority C STRING(1) Indicator that quantity on the message has split priority within the order book. Conditionally required if order has split priority.
Y = Specifies message quantity has split orderbook priority.
Null/N = Specifies message quantity has same orderbook priority.
MsgDuration C STRING(10) Time specific order designation for CLOB orders and other applicable session types ( e.g., trading day only, good until cancelled, good until specified date). Leave blank for market type orders that are not time sensitive.
GTC = Good ‘Til cancelled – Remains in force until executed, canceled or the contact expires. GTD = Good ‘Til date/time – Remains in force until the specified date/time or through the end of the specified date unless executed, canceled, or the contract expires. GAT = Good after time - Order becomes active at the specified date/time FOK = Fill or kill – Orders are canceled if not immediately filled in whole. FAK = Fill and kill – Orders are immediately filled in whole or in part. Any remaining quantity is eliminated.
ExpiryDate C TIMESTAMP Used in conjunction with MsgDuration to 2011-02-11 10:01:29
specify the date/time of an order's expiration. Must include the date and optionally may include the time. For example, if order is designated as ‘good until a specified date’, then this field would reflect that date/time. Applies to individual CLOB orders that have an explicit expiration date. * Not required for GTC, FOK, or IOC orders.
CptyOrigin C STRING(30) A coding scheme to identify the counterparty for market surveillance/clearing purposes. Required for futures transactions.
MsgInputDevice C STRING(20) ID of the terminal connection for systems external to SEF. Used to track algorithmic (algo) or black box trading where a trader might be using multiple trading strategies on different terminals. The ID provided must allow NFA to identify the person responsible for the order. Conditionally required if ATS is used.
Designated by SEF (e.g. login ID)
RouteType C STRING(30) Routing type to clearing house. Conditionally required if order clears.
DESG = User specifically designates the clearing house. AUTO = Uses SEF algorithm to determine clearinghouse.
TrdSysId STRING(100) ID of the trading system the message was entered. Note: submission by asset class is still required if this value is optionally supplied.
Designated by SEF
MktSeg
MktSegId STRING(100) Market segment id. Enter multiple MktSeg entries if the order interacts with multiple liquidity pools. There should be at most one MktSegID when MsgTransType = "MATCH" or "PARTIAL_MATCH"
/MktSeg
Link
LinkMsgId C STRING(50) The LinkMsgId and LinkMsgReason work together to link complex orders together. These fields are repeatable. For example, there would be two entries for an OCO order that occurs during a workup. There are two
primary conditions where these fields would be populated as described below: Conditional Order (Parent-Child) – Conditional orders are triggered based on events of other orders. Enter the parent MsgId in this field for “child” orders that are associated with a “parent” order. If a grouping ID is available, that value may be used instead of the parent MsgId. Workup – Enter MsgId for aggressing message that spawned the workup. RFQ - Enter the MsgId if RFQ was spawned from a dealer quote.
LinkMsgReason C STRING(10) The reason why the order is linked. The LinkMsgReason is used in conjunction with the LinkMsgId to describe the linkage.
WKP = Workup RFQ = Request for proposal OCO = One cancels the other linked by message id. OCA = One cancels all linked by message id, MCO = Multiple cancels others linked by message id. OCOG = One cancels the other linked by grouping id. OCAG = One cancels all linked by grouping id, MCOG = Multiple cancels others linked by grouping id. RFC = Request for cross CR = Cancel Replace MO = Managed Order
/Link
Pty
ID STRING(50) ID of the trader at executing firm responsible for the message. For ATS messages, this is the ID for the person responsible for the ATS system at the time the message was sent.
R STRING(10) Swap Counterparty identifier. Equivalent to a customer account number. The CFTC has indicated that all counterparties must have IDs which are unique across all trading venues.
24 = Counterparty
/Pty
Pty
ID STRING(50) The exchange member firm providing access to the exchange. The executing firm ID could be the same as the clearing member if the firm is also a member of the clearing house. This value is assigned by each exchange and therefore varies from exchange to exchange.
R STRING(10) 1 = Executing firm ID
/Pty
Pty
ID C STRING(50) Clearing member ID. Required for all cleared transactions.
R C STRING(10) Firm which the executing firm clears through – member of the clearing house. Required for all cleared transactions. This element may be repeated.
4 = Clearing member firm
/Pty
Pty
ID STRING(50) Use this field to identify the applicable clearinghouse(s), if they are known at the time of the order. This is a list of one or more clearing houses that could clear the trade, since it is may not be known at order time which clearing house will eventually clear the trade. This element may be repeated.
BILAT = Bilateral swap or where it is unknown at the time of order entry whether or not the swap will be cleared.
R STRING(10) 21 = Clearing organization
Priority C Number indicating the priority of the clearinghouse from the perspective of the customer, with 1 being highest priority.
/Pty
Pty
ID STRING(50) Give-up clearing member firm ID. If order is placed for a customer with the intention of giving it up from one clearing member firm to
another (e.g. execution occurs with clearing member firm A but the position is moved to clearing member firm B). This is typically a post trade allocation, but enter if known at time of order.
R STRING(10) 14 = Give-up clearing member firm ID
/Pty
Pty
ID C STRING(50) If message is entered by voice broker firm, enter the voice broker firm’s ID (only relevant for SEFs with voice brokerage).
R C STRING(10) 7 = Voice broker firm ID
/Pty
Pty
ID C STRING(50) If message is entered by voice broker, enter the voice broker’s ID (only relevant for SEFs with voice brokerage).
R C STRING(10) 36 = Voice broker ID
/Pty
Pty
ID C STRING(50) System entry logon ID. Required for futures transactions only.
R C STRING(10) 44 = Logon ID
/Pty
PtyQt
ID C STRING(50) RFQ dealer
R C STRING(10) Use this field to identify the executing firms the request was sent to/from. The RFQ party id is required for RFQs and is left blank for all other transactions. This element may be repeated once for each party. If the request was sent to 3 parties, then this element should exist 3 times in the RFQ request data. The id used should be in the executing firm report.
Deals Description: Executed deals - We assume that each electronic system would transmit complete order information (see Orders above) so the data
contained in this deal file will be limited. In addition, we assume that each execution would generate at least two rows in this file – each referencing the underlying order which lead to the match. Thus, any given match may have more than two rows if the trade is a combination or if multiple orders were necessary to complete the transaction.
Frequency: Daily received along with the nightly batch
Filename: Asset classes in single file: Deal_YYYYMMDD.xml (e.g. Deal_20110521.xml)
Asset classes broken out into separate files: Deal_AssetClass_YYYYMMDD.xml (e.g. Deal_cd_20110521.xml)
Mapping Req Data Type Description Sample Data
Report Block
Component Block
Sub Component Block
Attribute Name
Deal
BatchDate * DATE Batch date of order (YYYY-MM-DD)
SefId * STRING(30) Swap execution facility ID
AssetClass * STRING(10) Asset class See Product Matrix
DealId * STRING(50) Unique swap identifier (per asset class) assigned to each swap. Both sides of a swap will have the same DealId but will have different MsgId. DealId should match Unique Swap Identifier in deal record that is sent to SDR. This should be at a clearing level, or an allocation level.
PriorUSI C STRING(50) Conditionally required for transactions with a pre-allocated USI or an adjusted USI. Populate with the prior USI of the aggregated transaction.
MsgId C STRING(50) Links deal to originating message. Conditionally required when deal source is "EXCH".
Designated by SEF
BaseProd STRING(10) Base product See Product Matrix
SubProd C STRING(10) Sub product. Required for all asset classes except CU.
See Product Matrix
MatchDate TIMESTAMP(6) Date and time when matched or when dealer accepts RFQ (YYYY-MM-DD HH:MM:SS.FF6). Should equal the MsgDate on the message MATCH or PARTIAL_MATCH record.
ClearDate C TIMESTAMP(6) Date and time when deal was sent to the clearinghouse (not when the deal cleared). A blank clearing date indicates that the trade was not sent to clearing. (YYYY-MM-DD HH:MM:SS.FF6) Required for all cleared deals.
ReportDate C TIMESTAMP(6) For off-exchange deals, the time the deal was reported to the public. Required for off-exchange deals.
DealSource STRING(20) The source of where the order came from. EXCH = Exchange activity BLOCK = Off exchange block trade EDRP = Exchange of derivatives for related positions XFER = Transfers CUST = Portfolio Compression Transactions GIV = Giveup VOICE = Voice trade BUST = SEF busted trade MAN = Manually entered deal, exclusively used for post-trade entries (Futures Only) VRFQ = Voice Request for Quote
CTICode STRING(1) Customer Type Indicator Code (CTI) Distinguishes for whom and on what type of account the trades are being placed. http://www.nfa.futures.org/news/newsNotice.asp?ArticleID=1362
See CFTC rule 37.205(ii)
1—For trades placed by an executing broker for his own account. 2—For trades placed by an executing broker for a firm proprietary account. 3—For trades placed by an executing broker for another broker who also has access to the system 4—For trades placed by an executing broker on behalf of a customer.
TradeInstrId STRING(50) SEF unique ID for each tradable instrument.
StratCode C STRING(100) Unique strategy identifier used to lookup leg components of the strategy in the Strategy layout. Conditionally required for transactions executed as a strategy without an
ExecGroupId C STRING(20) Use this to group together multiple executions that trade as part of a strategy. For example, a butterfly spread should have 6 deal records each with the same ExecGroupId. Each partial fill executions for a strategy will have unique ExecGroupIds.
EffDate DATE Effective start date of swap. Submit adjusted date. EffDate should match with that which is sent to SDR/clearing.
2011-07-31
MatDate DATE End date of swap – maturity/settlement date. Submit adjusted date. MatDate should match with that which is sent to SDR/clearing.
2021-07-31
Side * STRING(1) Directional exposure participant is willing to take. For definitions, see Side Matrix.
B = Bid O = Offer
Qty NUMBER(24,4) Contract quantity – Enter contract size as defined by the CFTC for the product. It is expected that a contact size will eventually be defined in each SEF’s contact spec. Prior to the CFTC’s definitions or where contract sizes have not been defined, the notional value may be entered.
NotionalUnitType STRING(100) The unit of measure applicable for the notional quantity
See Product Matrix
SecondaryQty C NUMBER(24,4) Notional quantity of second currency. This is conditionally required for cross currency transactions
SecondaryNotionalUnitType C STRING(100) The unit of measure applicable for the notional quantity for the second currency. This is conditionally required for cross currency transactions
See Product Matrix
Price NUMBER(20,8) The negotiated price as sent to clearing. For distressed CDS, enter up front fee into Price field when trading the up front fee. If option trades in volatility, then enter derived premium that was sent to clearing or the agreed upon premium.
SecondaryPrice C NUMBER(20,8) The price for the second rate. This is conditionally required for cross currency transactions.
RefPrice C NUMBER(20,8) For private match sessions Only, enter the best public representative price available at the time of the deal. For example, if a CLOB exists, enter the BBO; if indicative market exists, enter the best indicate bid/offer. If neither is applicable, a financial model or algorithm is acceptable. For buys enter the bid price; for sells enter the offer price.
UpFrontFee C NUMBER(20,8) If an upfront fee is a negotiable term in the pricing of the deal, include the dollar amount of the upfront fee. Not intended for options premiums.
Commission C NUMBER(20,8) If a commission is paid to a broker include the amount of the commission.
OptVol C NUMBER(20,8) If option is traded in volatility (i.e.FX), then populate volatility here. If option trades in premium, then derive implied volatility
OptQuoteType C STRING(1) Describes how the trader quoted the message. Conditionally required for an option.
P = Premium V = Volatility S = Strike
Strike C NUMBER(20,8) Strike price for an option. If deal is entered as a delta option, populate derived strike agreed upon by traders. Conditionally required for an option. For CU, must be reported in base currency.
OptSpot C NUMBER(20,8) Options – Spot rate
OptFwd C NUMBER(20,8) Options – Forward rate
ExecType STRING(4) Identifies instruments as required or permitted transactions on a SEF. Required for Swaps transactions.
REQ = Required PERM = Permitted
Pty
ID STRING(50) ID of the trader at executing firm responsible for the message. For ATS messages, this is the ID for the person responsible for the ATS system at the time the message was sent.
R STRING(10) 12 = Executing trader ID
/Pty
Pty
ID STRING(50) Unique counterparty ID
R STRING(10) Swap Counterparty identifier. Equivalent to a customer account number. Enter execution
account ID for allocation/bundled orders. According to the CFTC, allocation details will be available from the SDR. The CFTC has indicated that all counterparties must have IDs which are unique across all trading venues.
/Pty
Pty
ID STRING(50) The exchange member firm providing access to the exchange. The executing firm ID could be the same as the clearing member if the firm is also a member of the clearing house. This value is assigned by each exchange and therefore varies from exchange to exchange.
R STRING(10) 1 = Executing firm ID
/Pty
Pty
ID C STRING(50) Clearing member ID. Required for all cleared transactions.
R C STRING(10) Firm which the executing firm cleared through – member of the clearing house. Required for all cleared transactions.
4 = Clearing member firm
/Pty
Pty
ID STRING(50) Use this field to identify the applicable clearinghouse.
BILAT = Bilateral swap or where it is unknown at the time of the deal whether or not the swap will be cleared.
R STRING(10) 21 = Clearing organization
/Pty
Pty
ID C STRING(10) SDR that deal was reported to. Required for Swaps transactions.
DDR = DTCC Data Respository ITV = ICE Trade Vault CME = Chicago Mercantile Exchange
STRING(50) Give-up clearing member firm ID. If order is placed for a customer with the intention of giving it up from one clearing member firm to another (e.g. execution occurs with clearing member firm A but the position is moved to clearing member firm B). This is typically a post trade allocation, but enter if known at time of order.
R STRING(10) 14 = Give-up clearing member firm ID
/Pty
Pty
ID C STRING(50) If message is entered by voice broker firm, enter the voice broker firm’s ID (only relevant for SEFs with voice brokerage).
R C STRING(10) 7 = Voice broker firm ID
/Pty
Pty
ID C STRING(50) If message is entered by voice broker, enter the voice broker’s ID (only relevant for SEFs with voice brokerage).
Daily Activity Description: Daily trade activity for each tradable instrument or strategy. This report is not a messages report, but rather, a market summary report.
Notes: SEF should provide daily price information that the SEF believes best reflects their market. The SEF is required to report the price (e.g. market open price) and the source of the price (e.g. bid, mid price, indicative price, etc). The daily activity report is to be submitted to both NFA and the CFTC. According to CFTC Rule16.01 this information also needs to be published to the public.
Frequency: Daily received along with the nightly batch.
Filename: Asset classes in single file: DailyAct_YYYYMMDD.xml (e.g. DailyAct_20110521.xml)
Asset classes broken out into separate files: DailyAct_AssetClass_YYYYMMDD.xml (e.g. DailyAct_cd_20110521.xml)
Mapping Req Data Type Description Sample Data
Report Block
Component Block
Sub Component Block
Attribute Name
DailyAct
BatchDate * DATE Batch date of order (YYYY-MM-DD)
SefId * STRING(30) Swap execution facility ID
AssetClass * STRING(10) Asset class See Product Matrix
TradeInstrId C STRING(50) SEF unique ID for each tradable instrument. Not required when StratCode is used.
StratCode C STRING(100) Unique identifier of the strategy. Not required when TradeInstrId is used.
Open
Price NUMBER(20,8) Official opening price
Type STRING(5) Price type indicator for opening price. BID = Best bid opening price ASK = Best ask opening price TRANS = Transaction opening price IND = Indicative opening price FIRM = Firm opening price MID = Mid bid/ask opening price
/Open
High
Price NUMBER(20,8) High price for the day
Type STRING(5) Price type indicator for high price. BID = Best bid high price ASK = Best ask high price TRANS = Transaction high price
Connection Activity Description: Optional file that tracks the log on/off activity to the exchange. CFTC prefers submission of this report if the SEF is tracking connection
activity. Used primarily to identity misuse of logon IDs.
Notes: Connection activity must be reported even if that connection does not result in any message or deal activity.
Frequency: Daily received along with the nightly batch.
Filename: Asset classes in single file: ConnAct_YYYYMMDD.xml (e.g. ConnAct_20110521.xml)
Asset classes broken out into separate files: ConnAct_AssetClass_YYYYMMDD.xml (e.g. ConnAct_cd_20110521.xml)
Mapping Req Data Type Description Sample Data
Report Block
Component Block
Sub Component Block
Attribute Name
ConnAct
BatchDate * DATE Batch date of order (YYYY-MM-DD)
SefId * STRING(30) Swap execution facility ID
AssetClass * STRING(10) Asset class See Product Matrix. Enter “ALL” if applies to all asset classes.
ActType * STRING(3) Logon activity type ON = Log on OFF = Log off
ActDate * TIMESTAMP Date/time of logon activity (i.e., time of log on or log off)
2021-07-31 15:22:47
MsgInputDevice C STRING(20) ID of the terminal connection for systems external to SEF. Used to track algorithmic (algo) or black box trading where a trader might be using multiple trading strategies on different terminals. The ID provided must allow NFA to identify the person responsible for the order.
Designated by SEF
MktSegId C STRING(100) Market segment. Required if SEF has multiple liquidity pools.
Pty
ID * STRING(50) ID of the trader at executing firm responsible for the message. For ATS messages, this is the ID for the person responsible for the ATS system.
ID STRING(50) The exchange member firm providing access to the exchange. The executing firm ID could be the same as the clearing member if the firm is also a member of the clearing house. This value is assigned by each exchange and therefore varies from exchange to exchange.
Data File Layouts – Product/Strategy Product Master
Description: Captures product attributes that are relatively static in nature (i.e. the standardized terms that will appear in your rulebook for each swap product).
Notes: Typically, only commodity swaps will settle in cash or delivery.
All other asset classes will typically settle in cash.
Frequency: Daily received along with the nightly batch
Filename: Asset classes in single file: ProdMstr_YYYYMMDD.xml (e.g. ProdMstr 20110521.xml)
RptLevAgg C NUMBER(20) Aggregate quantity which triggers reporting requirements. Required if exchange has reporting level for product.
Deprecated
PosLmtAgg C NUMBER(20) Aggegate position limit. Required if exchange has position limit for product.
Deprecated
AcctLevAgg C NUMBER(20) Aggegate accountability level. Required if exchange has accountability level for product.
Deprecated
UniqueProdIdCFTC C STRING(50) CFTC’s unique ID (UPI) for every product. Required for Swaps transactions (Usage of this field is pending CFTC clarification).
UPITicker C STRING(50) Standard CFTC UPI contract ticker. Required for Swaps transactions (Usage of this field is pending CFTC clarification).
Tradable Instruments Description: Captures product attributes that are relatively dynamic in nature. Only include tradable instruments that had message or trade activity for
the day.
Frequency: Daily received along with the nightly batch
Filename: Asset classes in single file: TradeInstr_YYYYMMDD.xml (e.g. TradeInstr 20110521.xml)
AcctType C STRING(10) Account type ON = Onshore OFF = Offshore
Coupon C NUMBER(20,8) Standard coupon amount for CDS contracts. Conditional on asset class being CDS.
e.g. 100, 500
RecoveryRate C NUMBER(20,8) Recovery rate. Conditional on asset class being CDS.
LmtMvSize C NUMBER(20,8) Allowable price movement which defines allowable trading range for the day.
LotSize NUMBER(20) Lot size of contract defined at the tradable instrument level. Enter 1 if notional sizes are used.
MinTickSize NUMBER(20,8) Incremental price move. Minimum size quote can change.
Mult C NUMBER(10,4) Multiplier used to convert abbreviated price information into real dollars (leave null if not applicable). Multiplier is meant for a constant conversion of minimum tick size to dollars. Only applicable if there is a linear relationship between tick price changes and resulting dollar values.
OptionType C STRING(5) Option type. Required for options. C = Call, Fixed-rate payer; If long first currency in pair P = Put, Fixed-rate receiver; If short first currency in pair
OptionUnitType C STRING(100) The unit of measure applicable for the option type . This is conditionally required for currency options.
See Product Matrix
ExoticType C STRING(10) Required for exotic products (This includes instruments that do not explicitly include optionality)
A = Amortizing CAP = Cap FLR = Floor CF = Cap/Floor DC = Compounding KI = Knock-in KO = Knock-out KIKO = Knock-in Knock-out NT = No Touch DN = Double No-Touch OT = One Touch
DO = Double One-Touch AS = Asian NC = Cancelable S = Straddle CMS = Constant Maturity Swaps CMSSO = Constant Maturity Swap Spread Option XX = Other Exotic Option Type
TriggerDirectionA C STRING(10) Identifies the direction of a trigger to a barrier level or predetermined trigger rate for an option to be exercisable or payable. This further defines TriggerRateA. Conditionally required for ExoticTypes with 1 or more triggers. For Knock-In Knock-Out type options, this is the Knock-In Trigger Direction.
AtOrAbove = Greater than or equal to the trigger rate. AtOrBelow = Less than or equal to the trigger rate.
TriggerRateA C NUMBER(20,8) Rate at which an ExoticType event is triggered. Trigger is further defined by TriggerDirection A. Conditionally required for ExoticTypes with 1 or more triggers. For Knock-In Knock-Out type options, this is the Knock-In Trigger Rate
TriggerDirectionB C STRING(10) Identifies the direction of a trigger to a barrier level or predetermined trigger rate for an option to be exercisable or payable. Further defines TriggerRateB. Conditionally required for ExoticTypes with 2 or more triggers. For Knock-In Knock-Out type options, this is the Knock-Out Trigger Direction.
AtOrAbove = Greater than or equal to the trigger rate. AtOrBelow = Less than or equal to the trigger rate.
TriggerRateB C NUMBER(20,8) Rate at which an ExoticType event is triggered. Trigger is further defined by TriggerDirection B. Conditionally required for ExoticTypes with 2 triggers. For Knock-In Knock-Out type options, this is the Knock-Out Trigger Rate
OptionStyle C STRING(20) Options Style. Required for options. A = American E = European B = Burmudian
Strike C NUMBER(20,8) Strike price for an option. If Delta is populated, Strike should be null. For CU, must be reported in base currency.
Delta C NUMBER(20,8) Delta for an option. If Strike is populated, Delta should be null.
OptionExpiry C TIMESTAMP Expiration date for an option. Required for
QuantityFrequency C STRING(50) Specifies the frequency at which the quantity is deemed to apply for the purposes of calculating the total quantity/notional. This is mandatory for applicable commodity swaps.
PerBusinessDay = Once per commodity business day PerCalculationPeriod = Once per calculation period PerCalendarDay = Once per Calendar Day PerHour = Once per Hour PerMonth = Once per Month PerSettlementPeriod = Once per Settlement Period Term = Once per term of the trade
InfLagPeriodMult C NUMBER(10) The offsetting period multiplier from the payment date for which the inflation index is observed. This is conditionally required for applicable inflation derivatives with a determinable inflation lag.
InfLagPeriod C STRING(10) The offsetting period type from the payment date for which the inflation index is observed. This is conditionally required for applicable inflation derivatives with a determinable inflation lag.
D = Day W = Week M = Month Y = Year
FTrdDate DATE First trade date For rolling contracts, this value will be trade date. For contracts with a futures-like defined window (i.e. indexed CDS), this should be first trade date available.
FIntentDate C DATE First date to submit intention of delivery (commodity)
FNoticeDate C DATE First date to submit notice of delivery (commodity)
FDelvDate C DATE First date of delivery (commodity)
LTrdDate DATE Last trade date For rolling contracts, this value will be trade date. For contracts with a futures-like defined window (i.e. indexed CDS), this should be last trade date available.
LIntentDate C DATE Last date to submit intention of delivery (commodity)
LNoticeDate C DATE Last date to submit notice of delivery (commodity)
LDelvDate C DATE Last date of delivery (commodity)
OpenDate C TIMESTAMP Market open date/time for cleared tradable instruments with defined trading schedules.
CloseDate C TIMESTAMP Market close date/time for cleared tradable instruments with defined trading schedules.
SuspStartDate C TIMESTAMP Date/time when a product is temporarily delisted.
2011-08-12 10:18:00
SuspEndDate C TIMESTAMP Date/time when product is relisted.
Clearable STRING(1) Indicates whether the tradable instrument will be cleared or not. . Swaps not cleared may also need to be reported depending on the services agreement.
Y = Clearable N = Not clearable
ExecType C STRING(4) Identifies instruments as required or permitted transactions on a SEF. Required for Swaps transactions.
REQ = Required PERM = Permitted
SFixedRate C NUMBER(20,8) Identifies the fixed rate of instrument if this is a static element of the instrument. Required for IRS where fixed rate is not negotiated
ClearingSym
ClearSymId C STRING(100) Where clearing symbols exist and are readily available, use a concatenation of the Clearing house on which the product is cleared and the clearing house's clearing code/symbol when the product is specific to the clearinghouse. The concatenation between these two values should be separated by an underscore. For example, Henry Hub Natural Gas swaps cleared by ICE = ICE_H. This field is repeatable if the product can clear at more than one clearing house.
See Product Matrix
/ClearingSym
RptLev C NUMBER(20) Quantity which triggers reporting requirements. Required if exchange has reporting level for tradable instrument.
Deprecated
PosLmt C NUMBER(20) Positions limit. Required if exchange has position limit for tradable instrument.
Strategy Description: Strategy layout provides information about each of the legs of a multi-legged order. Strategy legs should be reported from the buy
perspective. The strategy is reported as a single order in the orderbook and the individual legs of the strategy are defined in this strategy layout. The StratCode is used to link the order in the orderbook to the underlying legs in this strategy file.
Notes: For example, a butterfly strategy would have 3 rows in this file to describe the 3 legs of the butterfly. A calendar spread would have 2 legs to describe each calendar leg.
Frequency: Daily received along with the nightly batch.
Filename: Asset classes in single file: Strat_YYYYMMDD.xml (e.g. Strat 20110521.xml)
Asset classes broken out into separate files: Strat_AssetClass_YYYYMMDD.xml (e.g. Strat_cd_20110521.xml)
Mapping Req Data Type Description Sample Data
Report Block
Component Block
Sub Component Block
Attribute Name
Strat
BatchDate * DATE Batch date (YYYY-MM-DD)
SefId * STRING(30) Swap execution facility ID
AssetClass * STRING(10) Asset class See Product Matrix. Enter “ALL” if applies to all asset classes.
StratCode * STRING(100) Unique identifier of the strategy
RefLegInd NUMBER(1) Leg reported in the Messages report. Contains Side and Qty conventions reported in the single line item in the Message Report.
0=Unreported leg 1=Reported leg in Message
TradeInstrId C STRING(50) Tradable instrument identifier for the strategy leg. For cash/bond legs, leave this blank and fill in the CashLegId.
CashLegId C STRING(50) For cash/bond strategy legs, enter the bond CUSIP number in this field and leave the TradeInstrId blank. For Non-Swap/Non-Bond legs, enter an identifiable ticker and leave the TradeInstrId blank.
StratDesc C STRING(1000) Text description of the strategy
LeggingInd STRING(2) Indicates whether the strategy trades as a strategy or leg into outrights.
L = Legs into outrights S = Trades as a strategy LS = works both outright and strategy
NumLegs NUMBER(3) Number of legs in the strategy For a calendar spread, this would be 2.
Leg NUMBER(3) Number associated with this specific leg of this specific strategy
Arbitrarily assign leg numbers to the leg. A calendar spread, for example, could label the near month as 1 and the far leg as 2.
Ratio C NUMBER(3) Number of contracts of this leg per contract of the strategy. Only provide if the ratio is known ahead of the trade. Will not be required for dynamic products that are determined real-time (in these cases, NFA will determine leg pricing from the Deal)
Side STRING(1) When buying the strategy, this is the verb for the leg. Example: A butterfly strategy has 3 legs; the first and last legs are offers and the middle leg is a bid. Legs 1 and 3 would be “O” and leg 2 would be “B”.
B = Bid O = Offer
LotSize NUMBER(20) Lot size of contract defined at the Strategies. Enter 1 if notional sizes are used.
Position Monitoring Description: Identifies all applicable position monitoring limits and levels.
Frequency: Daily received along with the nightly batch
Filename: Asset classes in single file: PosMon_YYYYMMDD.xml (e.g. PosMon 20110521.xml)
Asset classes broken out into separate files: PosMon_AssetClass_YYYYMMDD.xml (e.g. PosMon_cd_20110521.xml)
Mapping Req Data Type Description Sample Data
Report Block
Component Block
Sub Component Block
Attribute Name
PosMon
BatchDate * DATE Batch date (YYYY-MM-DD)
SefId * STRING(30) Swap execution facility ID
AssetClass * STRING(10) Asset class See Product Matrix
GroupId * STRING(50) Exchange unique ID for grouping of tradable instruments
LimitName * STRING(50) Standard limit/level naming convention
LimitDesc C STRING(1000) The Exchange description of the limit in free text form.
PosMonitorType* STRING(10) Identifies the limit/level type POSLMT = Position Limit ACCTLEV = Accountability Level RPTLEV = Reportable Level POSSTL = Position Limit Preceding Settlement ACCTSTL = Accountability Level Preceding Settlement OTHER = Other level/limit
PosMonitorDesc C STRING(1000) Description of Limit – required for PosMonitorType "OTHER"
LimitType * STRING(20) Identifies the type of position monitoring limit/level
SINGLETRANS = Single Trade Volume AGGVOLNET = Net Aggregate Daily Volume AGGVOLGROSS = Gross Aggregate Daily Volume ALLMONTHS = For All Months Accumulated FRONTMONTH = For Front Month
AssetClass * STRING(10) Asset class See Product Matrix. Enter “ALL” if applies to all asset classes.
LEI C STRING(30) Legal entity identifier. LEI is required if entity has an LEI. CFTC will require using a legal entity identifier. The exact date of implementation is unknown. The CICI code should be used in the interim.
Name STRING(100) Clearing house name
Addr1 STRING(60) Enter adequate business address information using Addr1 – Addr2, as necessary.
Addr2 STRING(60)
Addr3 STRING(60)
City STRING(20)
State STRING(4) Required for US address.
PostCode STRING(15) Postal code. Required for US address.
AssetClass * STRING(10) Asset class See Product Matrix. Enter “ALL” if applies to all asset classes.
LEI C STRING(30) Legal entity identifier. LEI is required if entity has an LEI. CFTC will require using a legal entity identifier. The exact date of implementation is unknown. The CICI code should be used in the interim.
Name STRING(100) Clearing member firm name
SSNTaxId STRING(9) Last 4 digits of Tax ID.
Addr1 STRING(60) Enter adequate business address information using Addr1 – Addr2, as necessary.
Addr2 STRING(60)
Addr3 STRING(60)
City STRING(20)
State C STRING(4) Required for US address.
PostCode C STRING(15) Postal code. Required for US address.
CtryCode STRING(4) Country code
Phone
STRING(25) Business telephone number
Fax STRING(25) Fax number
Email STRING(50) Business email address
StartDate TIMESTAMP Date firm became clearing member. 2011-08-12 10:18:00
Clearing Member Contact Description: List of all contacts for each of the clearing member firms. Must report at least one clearing member compliance contact.
Frequency: Daily received along with the nightly batch.
Filename: Asset classes in single file: ClrMbCon_YYYYMMDD.xml (e.g. ClrMbCon 20110521.xml)
Executing Firm Description: List of exchange’s executing (child) firms and parent (affiliate) firms. The exchange member firm providing access to the exchange. The
executing firm ID could be the same as the clearing member if the firm is also a member of the clearing house. This value is assigned by each exchange and therefore varies from exchange to exchange. Fields other than BatchDate, SefId, AssetClass, LEI (when available), and name are optional for affiliate parent firm entries. Enter executing and affiliate firms using Pty R=1 and identify relationship between parent and child firms in the Executing Firm – Affiliate relationship report. Preferably only include firms that had messages or trade activity for the day and for any open orders/activity.
Frequency: Daily received along with the nightly batch.
Filename: Asset classes in single file: Firm_YYYYMMDD.xml (e.g. Firm 20110521.xml)
AssetClass * STRING(10) Asset class See Product Matrix. Enter “ALL” if applies to all asset classes.
LEI C STRING(30) Legal entity identifier. LEI is required if entity has an LEI. CFTC will require using a legal entity identifier. The exact date of implementation is unknown. The CICI code should be used in the interim.
Name STRING(100) Executing firm name
SSNTaxId STRING(9) Last 4 digits of Tax ID.
RegType C STRING(10) Firm registration type for swaps firms only. MSP = Major swap participant SD= Swap dealer CEU = Commercial end user OTHER = Registration not specified above.
Addr1 C STRING(60) Enter adequate address information using Addr1 – Addr2, as necessary.
PARENT = For parent affiliate firms if address information is not applicable.
Trader Description: List of all traders. SEF should use what is available to uniquely identify traders. The executing trader ID used in this report should be the
same ID used in the messages/deals reports. Preferably only include traders that had messages or trade activity for the day and for any open orders/activity. The full list of traders can be submitted instead if more convenient.
Frequency: Daily received along with the nightly batch.
Filename: Asset classes in single file: Trader_YYYYMMDD.xml (e.g. Trader 20110521.xml)
Asset classes broken out into separate files: Trader_AssetClass_YYYYMMDD.xml (e.g. Trader_cd_20110521.xml)
Mapping Req Data Type Description Sample Data
Report Block
Component Block
Sub Component Block
Attribute Name
Trader
BatchDate * DATE Batch date of order (YYYY-MM-DD)
SefId * STRING(30) Swap execution facility ID
AssetClass * STRING(10) Asset class See Product Matrix. Enter “ALL” if applies to all asset classes.
SSNTaxId STRING(9) Last 4 digits of SSN for US traders;
DOB DATE Trader’s date of birth (YYYY-MM-DD)
LName STRING(36) Trader’s last name. Required for individuals.
FName STRING(62) Trader’s first name. Required for individuals.
Addr1 STRING(60) Enter adequate business address information using Addr1 – Addr2, as necessary.
Addr2 STRING(60)
Addr3 STRING(60)
City STRING(20)
State C STRING(4) Required for US address
PostCode C STRING(15) Postal code. Required for US address
CtryCode STRING(4) Country code
Phone
STRING(25) business telephone number
Fax STRING(25) Fax number
Email STRING(50) business email address
PrinBus STRING(4) Principle business type ATS = Automated trading system e.g. Trader ID represents a pure Automated Trading System
e.g. Trader ID represents an individual using only GUI (Pure Manual Entry); Auto Trade Recommendation/Signal system that prompts GUI order entry
StartDate TIMESTAMP Date trader commenced trading 2011-08-12 10:18:00
EndDate C TIMESTAMP Date trader ended trading. Leave null if trader is active.
Pty
ID * STRING(50) ID of the trader at executing firm responsible for the message. For ATS messages, this is the ID for the person responsible for the ATS system at the time the message was sent.
R STRING(10) 12 = Executing trader ID
/Pty
Pty
ID *
STRING(50) Executing firm ID
R STRING(10) The exchange member firm providing the trader with access to the exchange (e.g Goldman Sachs). This element may be repeated if the trader is associated with multiple firms.
Description: List of all counterparties/beneficial owner of swap. (Used if CFTC Unique Counterparty ID is not available). Preferably only include counterparties that had messages or trade activity for the day and for any open orders/activity.
Frequency: Daily received along with the nightly batch.
Filename: Asset classes in single file: Cpty_YYYYMMDD.xml (e.g. Cpty 20110521.xml)
Asset classes broken out into separate files: Cpty_AssetClass_YYYYMMDD.xml (e.g. Cpty_cd_20110521.xml)
Mapping Req Data Type Description Sample Data
Report Block
Component Block
Sub Component Block
Attribute Name
Cpty
BatchDate * DATE Batch date of order (YYYY-MM-DD)
SefId * STRING(30) Swap execution facility ID
AssetClass * STRING(10) Asset class See Product Matrix. Enter “ALL” if applies to all asset classes.
LEI C STRING(30) Legal entity identifier. LEI is required if entity has an LEI. CFTC will require using a legal entity identifier. The exact date of implementation is unknown. The CICI code should be used in the interim.
SSNTaxId STRING(9) Last 4 digits of SSN for individuals; Last 4 digits of Tax ID for entities other than individuals.
Name C STRING(100) Counterparty full name. Required for counterparties other than individuals. Not required for individuals.
LName C STRING(36) Counterparty’s last name. Required for individuals.
FName C STRING(62) Counterparty’s first name. Required for individuals.
Addr1 STRING(60) Enter adequate business address information using Addr1 – Addr2, as necessary.
PostCode C STRING(15) Postal code. Required for US address
CtryCode STRING(4) Country code
Phone
STRING(25) Telephone number
Fax STRING(25) Fax number
Email STRING(50) Email address
StartDate TIMESTAMP Date counterparty commenced trading 2011-08-12 10:18:00
EndDate C TIMESTAMP Date counterparty ended trading
CustomerAccountID C STRING(50) The customer's account ID number. Conditionally required for entities that have multiple accounts under a single position account holder. This is required for all futures counterparties.
Pty
ID * STRING(50) Unique counterparty identifier (customer account number). Must tie back to the counterparty entered into the messages and deals layout.
R
STRING(10) 24 = Counterparty
/Pty
Pty
ID C STRING(50) The Position Account ID at the clearing house that will receive the position.
Voice Broker Description: List of all voice brokers. Required if SEF uses voice brokers. Preferably only include voice brokers that had messages or trade activity for the
day and for any open orders/activity.
Frequency: Daily received along with the nightly batch.
Filename: Asset classes in single file: VoiceBroker_YYYYMMDD.xml (e.g. VoiceBroker 20110521.xml)
Voice Broker Firm Description: List of all voice broker firms. Required if SEF uses voice brokers. Preferably only include voice broker firms that had messages or trade
activity for the day and for any open orders/activity.
Frequency: Daily received along with the nightly batch.
Filename: Asset classes in single file: VoiceBrokerFirm_YYYYMMDD.xml (e.g. VoiceBrokerFirm 20110521.xml)
AssetClass * STRING(10) Asset class See Product Matrix. Enter “ALL” if applies to all asset classes.
LEI C STRING(30) Legal entity identifier. LEI is required if entity has an LEI. CFTC will require using a legal entity identifier. The exact date of implementation is unknown. The CICI code should be used in the interim.
Name STRING(100) Voice broker firm name
Addr1 STRING(60) Enter adequate address information using Addr1 – Addr2, as necessary.
Addr2 STRING(60)
Addr3 STRING(60)
City STRING(20)
State C STRING(4) Required for US address
PostCode C STRING(15) Postal code. Required for US address
CtryCode STRING(4) Country code
Phone
STRING(25) Telephone number
Fax STRING(25) Fax number
Email STRING(50) Email address
StartDate TIMESTAMP Date voice broker commenced 2011-08-12 10:18:00
AssetClass * STRING(10) Asset class See Product Matrix. Enter “ALL” if applies to all asset classes.
TradingPriv * STRING(30) Designated by SEF
StartDate
TIMESTAMP Start date/time of trading privilege. 2011-08-12 10:18:00
EndDate TIMESTAMP End date/time of trading privilege.
Pty
ID * STRING(50) This is the ID of the trader or voice broker. This ID should be associated with only one trader/voice broker and that trader/voice broker should use the same ID.
R STRING(10) 12 = Executing trader ID 36 = Voice broker ID
/Pty
Pty
ID * STRING(50) The exchange member firm providing access to the exchange. The executing firm ID could be the same as the clearing member if the firm is also a member of the clearing house. This value is assigned by each exchange and therefore varies from exchange to exchange.
AssetClass * STRING(10) Asset class See Product Matrix. Enter “ALL” if applies to all asset classes.
Pty
ID * STRING(50) The child/affiliate exchange member firm providing access to the exchange. The executing firm ID could be the same as the clearing member if the firm is also a member of the clearing house. This value is assigned by each exchange and therefore varies from exchange to exchange. This is the same value that is entered into the message/deals reports.
R STRING(10) 1 = Child/affiliate executing firm ID
/Pty
Pty
ID * STRING(50) Parent firm that has a relationship to the child/affiliate firm above. Required to aggregate data under single parent firm.
AssetClass * STRING(10) Asset class See Product Matrix. Enter “ALL” if applies to all asset classes.
StartDate TIMESTAMP Start date of trading privilege. 2011-08-12 10:18:00
EndDate TIMESTAMP End date of trading privilege.
Pty
ID * STRING(50) Unique counterparty ID
R STRING(10) Swap Counterparty identifier. Equivalent to a customer account number.
24 = Counterparty
/Pty
Pty
ID * STRING(50) The exchange member firm providing access to the exchange. The executing firm ID could be the same as the clearing member if the firm is also a member of the clearing house. This value is assigned by each exchange and therefore varies from exchange to exchange.
Executing Firm – Clearing Member Relationship Description: Relationship of the executing firms to the clearing member firms (i.e. clearing member firm list per executing firm)
Frequency: Daily received along with the nightly batch.
Filename: Asset classes in single file: FirmClrMbRel_YYYYMMDD.xml (e.g. FirmClrMbRel 20110521.xml)
AssetClass * STRING(10) Asset class See Product Matrix. Enter “ALL” if applies to all asset classes.
StartDate
TIMESTAMP Start date of trading privilege. 2011-08-12 10:18:00
EndDate TIMESTAMP End date of trading privilege.
Pty
ID * STRING(50) Clearing member ID
R STRING(10) Firm which the executing firm clears through – member of the clearing house. This element may be repeated.
4 = Clearing member firm
/Pty
Pty
ID * STRING(50) The exchange member firm providing access to the exchange. The executing firm ID could be the same as the clearing member if the firm is also a member of the clearing house. This value is assigned by each exchange and therefore varies from exchange to exchange.
Clearing/Post Trade Data Requirements Clearing and post trade data requirements are outlined in two separate reference documents entitled “SEF/DCM Clearing Implementation Reference” and "SEF/DCM Large Trader Implementation Reference". These documents provide a minimum set of data requirements for clearing house reporting and outline any additional post trade reporting as it becomes necessary, either by regulatory mandate or exchange rules.
References
Product Matrix
Please refer to SEF_ProductMatrix Reference document.
Side Matrix This table describes what bid/offer means in each of the asset classes from the perspective of the counterparty.
CDS IRS Commodity FX/Currency Equity
AssetClass CD = Credit IR = Rate CO = Commodity CU = Currency EQ = Equity
Side
Bid Examples: B = Buy default protection B = Short risk B = Buy CDS B = Pay periodic payments
Options B = Buyer of options contract
Strategy B = References directional position in far term tradable instrument for spreads. For butterflies, references middle term.
Fixed/Float B = Pay fixed
Fixed/Fixed Float/Float B = Party paying terms of leg 1
Options B = Buyer of options contract
Strategy B = References directional position in far term tradable instrument for spreads. For butterflies, references middle term.
B = Pay fixed
Fixed/Fixed Float/Float B = Party paying terms of leg 1
Options B = Buyer of options contract
Strategy B = References directional position in near term tradable instrument for spreads. For butterflies, references middle term.
B = Receiver of forward rate (if Fwd-Fwd; then longer dated)
Fixed/Fixed Float/Float B = Party paying terms of leg 1
Options B = Buyer of options contract
Strategy B = References directional position in near term tradable instrument for spreads. For butterflies, references middle term. For reference: Near term = Buy side Far term = Sell side SEF will need to adjust the left and right had sides accordingly.
B = Pay fixed
Options B = Buyer of options contract
Strategy B = References directional position in near term tradable instrument for spreads. For butterflies, references middle term.
Offer Examples: O = Sell default protection
Fixed/Float O = Receive fixed
O = Receive fixed
O = Payer of forward rate (if Fwd-Fwd; then longer
CFI Codes ISO standard CFI Codes Pending CFTC's requirments for Trade Capture OPTIONS CHAR1 = O CHAR2 = Put/Call Code CHAR3 = Exercise Style Code (A = AMERICAN, E = EUROPEAN) CHAR4 = Classification (S = EQUITY, I = INDEX, O = OPTION, F= FUTURE, D = DEBT) CHAR5 = Settlement Method (P = PHYSICAL, C = CASH) CHAR6 = Sub-Classification Standard / Non-Standard Settlement Designation (S = STD SETTLEMENT or N = NON-STD SETTLEMENT) CHAR1 = R FUTURES CHAR1 = F CHAR2 = F CHAR3 = Classification (S = EQUITY, D = DEBT, I = INDEX) CHAR4 = Settlement Method (P = PHYSICAL, C = CASH) CHAR5 = Standard / Non-Standard Settlement Designation (S = STD SETTLEMENT or N = NON-STD SETTLEMENT) CHAR6 = X NOTE: When a particular CFI Code attribute does not apply to the use or context within a message then an X will be used.
