# The FIX Protocol > The FIX Protocol is an open standard for exchanging trading messages, such as orders and fills, between the systems of financial institutions and exchanges. It has an application layer that defines the meaning and flow of messages and a session layer that delivers them in order. Some exchanges for listed derivatives use it to enter orders and to distribute copies of execution reports. - URL: https://www.derivatives-compass.org/en/data-systems/fix-protocol/ - Area: Data and Systems › Data Standards - Last reviewed: 2026-10-21 - 日本語版: https://www.derivatives-compass.org/ja/data-systems/fix-protocol/index.md ## Key points - FIX has a message-meaning layer and a session layer for ordering and resends, and FIX 4.4 messages use tag=value form or FIXML. - FIX has versions such as 4.2, 4.4, and 5.0 SP2, and the fields of the same execution report differ by version. - Some listed-derivatives exchanges use FIX to enter orders and to distribute copies of execution reports. - The FIX specification defines how to handle duplicate, resent, corrected, and canceled execution reports and gaps in sequence numbers. - The connection methods of J-GATE, the derivatives trading system of the Osaka Exchange, include API and OUCH. Some of the counterparties that send execution reports to your trade management system, such as exchanges and brokers, use [FIX](https://www.derivatives-compass.org/en/glossary/fix-protocol/) as one of their message formats. If you know how the ingestion should behave when a report arrives twice or a sequence number is skipped, system staff and business staff can talk from the same assumptions. ## What FIX is FIX (Financial Information eXchange) is a standard that lets financial institutions, exchanges, and vendors exchange trading messages in a common form. The FIX Trading Community develops and maintains it, and the specification is public. It is a protocol that defines the structure, content, and procedures of messages, independent of the type of network[^fix-tc]. The asset classes covered include equities, bonds, and foreign exchange, as well as listed derivatives and [OTC derivatives](https://www.derivatives-compass.org/en/glossary/otc-derivative/). The messages are organized into pre-trade, trade, and post-trade[^fix-tc]. | Stage | What it covers | Example messages (MsgType) | | ---------- | -------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | | Pre-trade | Market data, quotes | Market Data Request (V), Quote (S) | | Trade | Orders and executions | New Order - Single (D), [Execution Report](https://www.derivatives-compass.org/en/glossary/execution-report/) (8) | | Post-trade | Allocation, confirmation, reporting, position management | Allocation Instruction (J), Trade Capture Report (AE), Position Report (AP) | ## Layers, syntax, and versions FIX is defined in two layers, a session layer and an application layer. The session layer handles the delivery of data, and the application layer defines the business content[^fix44-levels]. The session layer does not acknowledge each message individually. The sender numbers messages in a session with MsgSeqNum (sequence numbers) starting from 1, and the receiver detects a gap in the numbers and asks for a resend[^fix44-optimistic]. In the FIX 4.4 specification, there are two syntaxes, tag=value and FIXML. The business message flow is the same, and the syntaxes only express the same content in different ways. The tag=value syntax lists numeric tags and values in the form "tag=value", using the control character SOH (0x01) to separate fields. FIXML is an XML syntax. It has no session layer, so it can be carried inside a FIX session or over another protocol[^fix44-syntax]. The current specification also has formats such as binary and JSON, in addition to the traditional tag=value format[^fix-tc]. The next example is an Execution Report (MsgType 8) that reports a futures fill, written in the FIX 4.4 tag=value syntax[^orch-fields]. The message name and MsgType are those of the FIX 4.4 definition[^orch-msgtypes]. **Sample 1: Execution report for a futures fill (FIX 4.4 tag=value syntax; excerpt, hypothetical example)** ```text 8=FIX.4.4| 9=243| 35=8| 34=2087| 49=SELLSIDE1| 56=BUYSIDE1| 52=20261021-01:23:45.200| 37=ORD-000123| 11=CL-000045| 17=EXEC-000789| 150=F| 39=1| 1=ACCT-DUMMY| 55=DUMMYFUT| 167=FUT| 200=202612| 54=1| 38=10| 32=4| 31=1234.5| 14=4| 151=6| 6=1234.5| 60=20261021-01:23:45.123| 75=20261021| 10=041| ``` In practice the message is sent as one line, with an SOH after each field. Here, to make it easier to read, SOH is shown as `|` and each field is on its own line. BodyLength (9) and CheckSum (10) are values calculated on the original form without the line breaks. The instrument (DUMMYFUT), the order and execution IDs, the account, the firm identifiers (SELLSIDE1, BUYSIDE1), the quantities, the prices, and the dates and times are all hypothetical dummy values, so this excerpt cannot be used for a connection as it is. The version is FIX 4.4. Note two points. ExecType (150) is F (Trade), so this is a report of a new fill. LastQty (32) and LastPx (31) are the quantity and price of this fill, and CumQty (14) and LeavesQty (151) are the cumulative and remaining quantities of the order. The same fill written in FIXML looks like this[^fixml-schema]. **Sample 2: The same fill in FIXML (FIXML 4.4; excerpt, hypothetical example)** ```xml ``` This is an excerpt of FIXML 4.4, and all values are hypothetical dummy values. A FIXML message has no attributes that correspond to BodyLength and CheckSum. Short attribute names replace the tag numbers: ExecType becomes ExecTyp, OrdStatus becomes Stat, and ClOrdID becomes ID. The quantities, prices, and dates and times are attributes of the ExecRpt element, while the instrument fields go in an Instrmt element and the order quantity in an OrdQty element. The header fields are attributes of the Hdr element. Dates and times use the XML date and date-time formats (2026-10-21 and 2026-10-21T01:23:45.123Z). ### How versions work FIX moved from the 4.x versions, through the 5.0 service packs, to "FIX Latest" in 2009. FIX Latest is updated through extension packs, which are the units in which the specification is extended bit by bit. The FIX Trading Community strongly recommends using FIX Latest. As of October 2026, it also continues to support 4.2 and 4.4 for older implementations[^fix-tc-versions]. In FIX 5.0, the session layer is separated from the application layer and has its own version name, FIXT. The application layer is written as "FIX.x.y" and the session layer as "FIXTx.y"[^legacy-fixt]. 5.0 SP2 is a specification of December 9, 2013, and includes 19 extension packs[^legacy-sp2]. Field names and usage differ by version. The following table compares how FIX 4.2 and FIX 4.4 express the cancellation and correction of a fill[^orch-42-44]. | Version | How cancellation and correction are expressed | Name of the quantity field (tag 32) | | ------- | ------------------------------------------------------------------------------------------ | ----------------------------------- | | FIX 4.2 | A fill is ExecType 1 or 2. Cancels and corrections are distinguished by ExecTransType (20) | LastShares | | FIX 4.4 | Expressed by ExecType (150) F, G (correct), and H (cancel). There is no ExecTransType | LastQty | ExecType in FIX Latest also has F, G, and H[^orch-42-44]. Even within the same version, each counterparty differs from the standard. Cboe Futures Exchange uses a subset of FIX 4.2 and lists its differences from the standard in its specification[^cboe]. The ASX 24 specification for the [drop copy](https://www.derivatives-compass.org/en/glossary/drop-copy/) (an arrangement in which an exchange delivers copies of execution reports) is based on extension pack 196 of FIX 5.0 SP2[^asx-intro]. When you read a counterparty's specification, look at both the version of the standard and the differences that the specification sets. ## Use in derivatives Some exchanges for listed derivatives outside Japan use FIX to enter orders and to distribute copies of execution reports. Cboe Futures Exchange uses FIX for order entry and drop copy for futures and options[^cboe]. A drop copy is an arrangement in which an exchange delivers copies of the messages on a participant's orders and fills over a separate connection. The ASX 24 specification gives two example uses: receiving the fills of several users of the same firm together, and a [clearing member](https://www.derivatives-compass.org/en/glossary/clearing-member/) checking its customers' fills together[^asx-intro]. In ASX 24, the Execution Report of a drop copy carries the same business information as the Execution Report sent to the submitter of the order, and CopyMsgIndicator (797) is Y[^asx-er]. **Figure 1: Flow of orders, execution reports, and the drop copy** The solid lines show orders going from the firm's own system to the exchange (the venue) and execution reports coming back from the exchange to the firm's own system. The dotted line is a copy of the execution report that the exchange delivers to the clearing member over a connection separate from order entry. For OTC derivatives, extension packs of 5.0 SP2 addressed the trade capture requirements of the [Commodity Futures Trading Commission (CFTC)](https://www.derivatives-compass.org/en/glossary/cftc/) (extension pack 77). They also addressed the identification of standardized credit default swaps that are subject to clearing (extension pack 83)[^legacy-sp2]. The FIX Trading Community explains that FIX is also used for regulatory reporting such as to the CFTC[^fix-tc-reg]. ### Relation to FpML and the CDM [FpML](https://www.derivatives-compass.org/en/glossary/fpml/) is an XML standard that represents the information of an OTC derivative trade[^boj-fpml]. FIX is a standard for exchanging order and fill messages. The contents of FpML are covered on the [FpML](https://www.derivatives-compass.org/en/data-systems/fpml/) page. FIX 4.4 has a way to connect the two standards. An FpML product specification can be placed inside the Instrument block that represents the instrument. SecurityID (48) holds the XML of the FpML specification or a URL that points to it, and SecurityIDSource (22) is set to I (ISDA/FpML Product Specification)[^fix44-fpml]. The [ISDA CDM](https://www.derivatives-compass.org/en/glossary/isda-cdm/) is a data model of trades and events, and it can also be expressed in the forms of standards such as FIX, FpML, and ISO 20022, for exchange and storage[^finos-cdm]. ## Points to handle when ingesting executions An execution report that arrives by FIX can arrive more than once, can skip a sequence number, and can be followed later by a correction or cancellation. The specification defines how to handle each case. How ingested executions are entered and checked is covered on the [Trade Capture and Approval](https://www.derivatives-compass.org/en/internal-operations/trade-capture/) page. ### Duplicates and resends FIX has two markers for resends. A message with PossDupFlag (43) of Y is a resend with the same sequence number and the same content. If the receiver has already received a message with that number, it ignores it, and if not, it processes the message as usual[^fix44-posdup]. The only fields that change in a resend are CheckSum, OrigSendingTime, SendingTime, BodyLength, and PossDupFlag[^fix44-ordered]. A message with PossResend (97) of Y is the same content sent again under a new sequence number. The receiver checks fields such as the order number to decide whether it has already received the content[^fix44-posdup]. For an execution report, ExecID is one clue. CONNEQTOR is a Tokyo Stock Exchange service that handles quote requests and quotes. Its connection specification defines how to treat an Execution Report that a participant's system sends with PossResend set to Y. If the ExecID is a value already received, CONNEQTOR judges it to be already received and discards it[^conneqtor]. If the received number is smaller than expected and PossDupFlag is not set, this is a serious error. The specification strongly recommends disconnecting the session and having a person respond[^fix44-recovery]. ### Gaps and the Resend Request If the received number is larger than expected, messages are missing. The receiver asks for a resend with a Resend Request (MsgType 2). It puts the first missing number in BeginSeqNo (7) and the last in EndSeqNo (16), and sets EndSeqNo to 0 to ask for "everything after that"[^orch-resend]. Messages after the missing number are not processed before the missing ones are received[^fix44-ordered]. The sender either resends with the original number and PossDupFlag set to Y, or skips the numbers of messages it will not resend with a Gap Fill in a Sequence Reset (MsgType 4). Administrative messages such as Logon and Heartbeat are not resent and are skipped with a Gap Fill[^fix44-recovery]. A resent execution report is processed as usual if the original was not received, even when PossDupFlag is Y[^fix44-posdup]. ### Corrections and cancellations In FIX 4.4 and later, the type of an execution report is distinguished by ExecType. A new fill is F (Trade). A report that cancels a fill that was reported in error is H (TradeCancel), and one that corrects it is G (TradeCorrect). Each refers to the ExecID of the original fill in ExecRefID (19)[^fix44-correct]. In FIX 4.2, a fill is expressed by ExecType 1 or 2, and cancels and corrections are distinguished by ExecTransType[^orch-42-44]. When a fill is corrected more than once, ExecRefID refers to the ExecID of the last correction. A cancellation report cannot itself be canceled. To fix a canceled fill, you send a new F report, not a G[^fix44-correct]. CumQty, LeavesQty, and AvgPx in a correction report reflect the state of the order at the time of the correction, not the values at the time of the original fill. When a fill is canceled on the same day, CumQty decreases by the canceled quantity and LeavesQty increases by the same amount, and the order quantity does not change[^fix44-correct]. The next example shows the sequence from logon to the execution report, a gap in sequence numbers, a resend, a cancellation, and a correction[^orch-seq]. **Sample 3: Sequence from logon through execution report, resend, cancellation, and correction (FIX 4.4; excerpt, hypothetical example)** ```text R>S 35=A|34=1|98=0|108=30| S>R 35=A|34=1|98=0|108=30| S>R 35=8|34=2|37=ORD-000123|17=EXEC-000789|150=F|39=1|32=4|31=1234.5|14=4|151=6| S>R 35=8|34=4|37=ORD-000123|17=EXEC-000791|150=H|19=EXEC-000789|39=1|14=6|151=4| R>S 35=2|34=2|7=3|16=0| S>R 35=8|34=3|43=Y|122=20261021-01:23:46.000|37=ORD-000123|17=EXEC-000790|150=F|39=2|32=6|31=1235.0|14=10|151=0| S>R 35=8|34=4|43=Y|122=20261021-01:23:47.000|37=ORD-000123|17=EXEC-000791|150=H|19=EXEC-000789|39=1|14=6|151=4| S>R 35=8|34=5|37=ORD-000123|17=EXEC-000792|150=G|19=EXEC-000790|39=1|32=6|31=1235.5|14=6|151=4| ``` Each line is one message, with SOH shown as `|`. S>R is a message from the side that delivers the fills to the side that receives them, and R>S is the reverse. Assume that the receiver (R) has logged on to the deliverer (S). This is an excerpt: fields 8, 9, 10, 49, 52, and 56 are omitted, and the resent lines keep only OrigSendingTime (122), which FIX 4.4 adds to resends. The firms, the order and execution IDs, the quantities, the prices, and the dates and times are all hypothetical dummy values. The version is FIX 4.4. Note the following. Number 4 arrives after number 2 (assume that MsgSeqNum (34) number 3 was lost). When the Resend Request asks for number 3 onward (number 4 is held until 3 arrives), the resent 3 and 4 have PossDupFlag (43) of Y and keep their original numbers. The last G message refers to the ExecID (EXEC-000790) of the fill to be corrected in ExecRefID (19). ### Identifiers in an execution report An execution report has the three identifiers below. Check the counterparty's specification to see which one to use for detecting duplicates and for identifying the original fill. | Identifier | Assigned by | Note | | ------------ | ------------------------------- | ---------------------------------------------------------------------------------------------------------- | | OrderID (37) | The seller (broker or exchange) | Unique within a trading day. It need not change when the order changes | | ClOrdID (11) | The side that submits the order | Chained at each cancel or change. It is not always unique in a drop copy that combines several connections | | ExecID (17) | The seller | An identifier for each execution report, and correction and cancellation reports have their own values | The scope in which ExecID must be unique is a single trading day or the life of an order that spans several days. Firms that take multi-day orders may design OrderID and ExecID to include the date so that they stay unique across days[^orch-ids]. Counterparties also differ. In the ASX 24 drop copy, ClOrdID is the value entered on the original connection, and on a connection that reports the activity of several connections together it is not always unique. The OrderID assigned by the exchange is unique and can be used to identify an order[^asx-er]. ### Example of instrument, account, and position An instrument is represented by Symbol (55) or by the pair of SecurityID (48) and SecurityIDSource (22). SecurityIDSource has defined values such as ISIN (4), exchange symbol (8), and Bloomberg symbol (A). The delivery month of a future goes in MaturityMonthYear (200) in the form YYYYMM[^orch-fields]. The account is Account (1). Consider a hypothetical example in which the ingesting side designs its [position](https://www.derivatives-compass.org/en/glossary/position/) update this way: F adds, H offsets, and G replaces. For a buy order of 10 futures contracts, suppose the same four reports as in the message sequence above arrive. The FIX specification does not define this design. | ExecID of the report | ExecType | Content of the report | Long position after ingestion | | -------------------- | ---------------------------- | --------------------------------------- | ----------------------------- | | EXEC-000789 | F | Fill of 4 contracts bought | 4 contracts | | EXEC-000790 | F | Fill of 6 contracts bought | 10 contracts | | EXEC-000791 | H (ExecRefID is EXEC-000789) | Cancellation of the 4-contract fill | 6 contracts | | EXEC-000792 | G (ExecRefID is EXEC-000790) | Price correction of the 6-contract fill | 6 contracts | The G report does not change the number of contracts and corrects the fill price from 1235.0 to 1235.5. If you process reports in the order they arrive and the cancellation EXEC-000791 arrives before EXEC-000790, the position is temporarily 0 contracts. In the FIX specification, messages after a missing number are not processed before the missing ones[^fix44-ordered]. ## Derivatives at Japan Exchange Group Japan Exchange Group (JPX) calls the derivatives trading system of the Osaka Exchange J-GATE. The connection methods to J-GATE include API and OUCH for trading. API is a common connection method that can receive market information and can submit, amend, and cancel orders. OUCH is a method for submitting, amending, and canceling orders only. Market information is received by API or ITCH[^jpx-jgate]. The data of the messages on each user's orders and fills that J-GATE distributes through OMnetAPI is provided as drop copy data. Only trading participants of the Osaka Exchange can use the drop copy data[^jpx-alt]. The connection methods that these JPX pages list are API, OUCH, ITCH, and OMnetAPI, and FIX is not among them. ## What this page does not cover The definitions of all FIX messages and fields, the differences in specification between counterparties, and the linking of fills through securities firms in Japan are not covered on this page. [^fix-tc]: FIX Trading Community, "The FIX Protocol" (accessed October 21, 2026), "An Introduction to the FIX Protocol," "What It Is (and Isn't)," and "The FIX Protocol's Scope and Reach." [^orch-msgtypes]: FIX Trading Community, FIX Orchestra (OrchestraFIX44.xml, as of extension pack 311 of FIX 4.4), the code list of MsgType (35) and the definition of the TradeCaptureReport message (AE, abbreviated TrdCaptRpt). [^fix44-levels]: FIX Protocol Limited, "FIX 4.4 Specification with 20030618 Errata," Volume 2, page 3, "Introduction." [^fix44-optimistic]: Same, Volume 2, pages 3–4, "Sequence Numbers" and "Message Acknowledgment," and page 6, "Session Protocol." [^fix44-syntax]: Same, Volume 1, page 14, "FIX Protocol Syntax," page 18, "Message Format" and "Field Delimiter," and page 23, "FIXML Syntax." [^orch-fields]: FIX Orchestra (OrchestraFIX44.xml, as of extension pack 311 of FIX 4.4), the definitions of tag numbers and field names. BodyLength and CheckSum are calculated by the methods on pages 4 and 26 of Volume 2 of FIX 4.4, and the example was created without copying the example in the specification. [^fixml-schema]: Liquid Technologies, documentation of the FIXML 4.4 schema (the elements and attributes ExecRpt, Hdr, Instrmt, OrdQty, and FIXML, and the date and date-time types). [^fix-tc-versions]: FIX Trading Community, "The FIX Protocol" (accessed October 21, 2026), "How It Works." [^legacy-fixt]: FIX Trading Community, "Legacy FIX Specifications" (accessed October 21, 2026), the FIX 5.0 section: the Transport Independence framework and the mention of FIXT 1.1. [^legacy-sp2]: Same page, the "FIX 5.0 Service Pack 2 Specifications (9 December 2013)" section. Extension pack 77 covers the CFTC trade capture requirements, and 83 covers the identification of standardized credit default swaps subject to clearing. [^orch-42-44]: FIX Orchestra, the definitions of ExecTransType (20), ExecType (150), and tag 32 in FIX 4.2 (extension pack 310), FIX 4.4 (extension pack 311), and FIX Latest (extension pack 312). [^cboe]: Cboe, "Cboe Titanium Cboe Futures Exchange FIX Specification" (accessed October 21, 2026), "Introduction." [^asx-intro]: ASX Operations Pty Limited, "ASX 24 FIX Drop Copy Specification V2.05" (October 2023), page 4, "1. FIX Drop Copy Introduction" and "1.1. Supported Versions." [^asx-er]: Same specification, page 24, the note at the start of Execution Report and the descriptions of OrderID (37) and ClOrdID (11). CopyMsgIndicator (797) being Y is in the same place. [^fix-tc-reg]: FIX Trading Community, "The FIX Protocol" (accessed October 21, 2026), "The FIX Protocol's Scope and Reach." [^boj-fpml]: TC68 Domestic Committee Secretariat, "Overview of ISO 20022" (March 2015; in Japanese), page 6, footnote 13. [^fix44-fpml]: FIX 4.4, Volume 1, pages 38–39, "Specifying an FpML product specification from within the FIX Instrument Block." I in SecurityIDSource (22) is ISDAFpMLSpecification in the FIX Orchestra definition. [^finos-cdm]: FINOS, "Common Domain Model- An Overview" (October 2023), page 3, the "Mapping" row, and page 4, "CDM vs. FpML." [^fix44-posdup]: FIX 4.4, Volume 2, page 4, "Possible Duplicates" and "Possible Resends," and page 11, "Standard Message header." [^fix44-ordered]: Same, Volume 2, pages 3–4, "Ordered Message Processing" and "Possible Duplicates." [^conneqtor]: Tokyo Stock Exchange, "CONNEQTOR FIX Connection Specification (Investor/Connection)" (in Japanese), 2.1 "System Overview" and 6.4 "Application-Level Resend Messages." [^fix44-recovery]: FIX 4.4, Volume 2, page 8, "Message Recovery." [^orch-resend]: FIX Orchestra (OrchestraFIX44.xml, as of extension pack 311 of FIX 4.4), the definitions of ResendRequest (2), BeginSeqNo (7), and EndSeqNo (16). [^fix44-correct]: FIX 4.4, Volume 4, pages 11–13, the description of Execution Report (Trade Cancel, Trade Correct, and the treatment of a cancellation on the day). ExecRefID (19) is as defined in FIX Orchestra. [^orch-seq]: FIX Orchestra (OrchestraFIX44.xml), the definitions of Logon (A), ResendRequest (2), PossDupFlag (43), OrigSendingTime (122), and ExecRefID (19). FIX 4.4, Volume 2, pages 4 and 8. [^orch-ids]: FIX Orchestra (OrchestraFIX44.xml), the descriptions of OrderID (37) and ExecID (17). The descriptions say to consider including the date for multi-day orders. That OrderID need not change when the order changes is on page 12 of Volume 4 of FIX 4.4. [^jpx-jgate]: Japan Exchange Group, "Derivatives Trading Systems (J-GATE)," "2. J-GATE Connectivity Methods" (accessed October 21, 2026). [^jpx-alt]: Japan Exchange Group, "Alternative Data Service J-GATE," the "Drop Copy Data" section (accessed October 21, 2026). ## Sources - [The FIX Protocol](https://fixtrading.org/standards/fix-protocol/) — FIX Trading Community - [FIX 4.4 Specification with 20030618 Errata](https://fixtrading.org/packages/fix-4-4-specification-with-20030618-errata/) — FIX Protocol Limited - [FIX Orchestra, FIX Standard (OrchestraFIX42.xml、OrchestraFIX44.xml、OrchestraFIXLatest.xml)](https://github.com/FIXTradingCommunity/orchestrations/tree/master/FIX%20Standard) — FIX Trading Community - [Docs for schema item ExecRpt in Financial Information eXchange (FIX)](https://schemas.liquid-technologies.com/fixml/4.4/execrpt.html) — Liquid Technologies - [Legacy FIX Specifications](https://fixtrading.org/legacy-fix-specifications/) — FIX Trading Community - [Cboe Titanium Cboe Futures Exchange FIX Specification](https://www.cboe.com/document/tech-spec/content/technical-specifications/cboe-titanium-cboe-futures-exchange-fix-specification) — Cboe Global Markets - [ASX 24 FIX Drop Copy Specification V2.05](https://www.asxonline.com/content/dam/asxonline/public/documents/NTP%20document%20library/Protocol%20technical%20specifications/asx-fix-drop-copy-specification.pdf) — ASX Operations Pty Limited - [ISO 20022 の概要](https://www.boj.or.jp/paym/iso/isotc68/data/1ISO20022gaiyo.pdf) — TC68 国内委員会事務局（日本銀行金融研究所） - [Common Domain Model- An Overview](https://www.finos.org/hubfs/Projects%20%2B%20SIGs/CDM%20-%20Common%20Domain%20Model/CDM%20Overview.pdf) — FINOS - [Derivatives Trading Systems (J-GATE)](https://www.jpx.co.jp/english/systems/derivatives-trading/01.html) — 日本取引所グループ - [Alternative Data Service J-GATE](https://www.jpx.co.jp/english/markets/paid-info-alternative/j-gate/index.html) — 日本取引所グループ - [CONNEQTOR FIX接続仕様書（投資家/接続編）](https://jpxsystem.com/doc/cq/doku.php?id=spec%3Ajp%3Aconnection) — 東京証券取引所