FIX(Financial Information eXchange)协议是一种用于国际金融交易的电子通信协议。解析FIX消息可能需要专门的工具或库,以下是一些可以在线解析FIX消息或提供相关工具的资源:

  • FIX Message Decoder by ValidFIX这是一个在线工具,可以将原始的FIX消息解码为易于理解的格式。您可以将FIX消息粘贴到网站的输入框中,它会显示出消息的字段和值。网址通常是 validfix.com/fix-decoder/,但请注意,网站和服务可能会变更。

  • FIX Analyser by FIX Trading CommunityFIX Trading Community提供了一个分析工具,可以帮助理解和调试FIX消息。您可以访问他们的官网 fixtrading.org 并搜索相关工具。

  • FIX Parser Online Tool您可能会找到一些在线的FIX解析器,这些工具允许您输入FIX消息,并将其解析为更加可读的格式。搜索“FIX parser online tool”可能会找到一些此类服务。

  • Open Source Libraries有一些开源库可以帮助您在自己的系统中解析FIX消息,例如QuickFIX(C++和Java版本)、SimpleFIX(Python)、Fix8(C++)等。这些库通常在GitHub上可以找到。

  • 专业软件一些交易和分析软件内置了FIX消息的解析功能,例如Bloomberg Terminal、Thomson Reuters Eikon等,尽管这些不是在线工具,但如果您在金融行业工作,可能已经可以访问这些资源。

在使用这些在线工具时,请注意安全和隐私问题。如果您的FIX消息包含敏感信息,最好不要在公共平台上解析这些消息,或者使用本地解析工具来保证信息安全。

Tag 150 (ExecType)

Tag 150是一个执行报告(Execution Report)消息中的一个字段,用于指示订单的执行状态。这个字段的名称是 "ExecType"。

Tag 150 (ExecType)的取值及其含义如下:

  • 0 = New(新订单):表示这是一个新的订单。

  • 1 = Partial fill(部分成交):表示订单没有完全成交,只有部分成交。

  • 2 = Fill(完全成交):表示订单已经完全成交。

  • 3 = Done for day(结束当日交易):表示订单已经结束,对于当天不会有更多的执行。

  • 4 = Canceled(已撤销):表示订单已经被撤销。

  • 5 = Replace(已替换):表示原始订单已经被替换,通常是因为修改订单的请求。

  • 6 = Pending Cancel(撤销待定):表示订单的撤销请求已经被接收,但是撤销尚未执行。

  • 7 = Stopped(已停止):表示订单已经被交易所停止。

  • 8 = Rejected(已拒绝):表示订单已经被拒绝。

  • 9 = Suspended(已挂起):表示订单已经被挂起。

  • A = Pending New(新订单待定):表示新订单的处理尚未完成。

  • B = Calculated(已计算):表示订单已经被计算,例如,保证金已经计算。

  • C = Expired(已过期):表示订单已经过期。

  • D = Restated(已重申):表示订单已经被修改,但不是因为撤销或替换请求。

  • E = Pending Replace(替换待定):表示替换订单的请求已经被接收,但是替换尚未执行。

  • F = Trade(成交):表示订单已成交。

  • G = Trade Correct(成交更正):表示成交已经被更正。

  • H = Trade Cancel(成交取消):表示成交已经被取消。

  • I = Order Status(订单状态):表示这是一个关于订单状态的报告。

这个列表并不是完整的,因为不同的FIX协议版本可能会有一些差异,并且实践中可能会有额外的自定义扩展。交易所和经纪商通常会在他们的FIX规范文档中详细说明他们支持的ExecType值及其含义。

在处理FIX消息时,理解每个Tag的含义以及它们的取值是至关重要的,因为它们决定了如何解释和响应消息。标签150(ExecType)就是用来帮助接收者了解订单执行的当前阶段和状态。

LastPx /LastShares /LastQty

在fix成交报告中,我如何获取此次成交的总金额?价格*股数,

在FIX协议中,成交报告消息通常包含了成交价格和成交数量,从而可以计算出此次成交的总金额。这些信息分别由以下两个标签(Tag)表示:

  • LastPx (最后成交价格): Tag 31,表示最后(最新)成交的价格。

  • LastShares (最后成交数量): Tag 32,表示最后成交的股数或合约数。

计算此次成交的总金额,您可以使用以下公式:

 

成交总金额 = LastPx * LastShares

在FIX协议的新版本中,Tag 32 (LastShares) 已经被 Tag 14 (CumQty - 累计成交数量) 和 Tag 151 (LeavesQty - 剩余数量) 所取代,而且 "LastShares" 的概念被 "LastQty" 所取代。因此,Tag 32 可能在某些FIX版本中已不再使用,您应该查阅您正在使用的FIX版本的具体规范。

  • LastQty (最后成交数量): Tag 32 或 Tag 14,取决于FIX的版本,表示最后成交的数量。

所以,如果您在处理FIX消息时需要确定成交总金额,首先要找到对应的成交价格和成交数量的标签,然后进行乘法计算。确保您参考的是正确的FIX协议版本的文档,因为标签的定义和使用可能会有所不同。

此外,在某些情况下,成交报告消息中可能会直接提供成交的总金额,这通常由 Tag 6 (AvgPx - 平均价格) 表示,它是指所有成交的平均价格,但并不是所有的执行报告都会包含这个字段。如果您需要计算特定成交的总金额,应使用 LastPx 和 LastQty 来进行计算。

LastQty /CumQty

在FIX协议中,LastQty(或旧版本中的LastShares)和CumQty是两个不同的概念,它们都与执行报告(Execution Report)消息中的成交数量有关。以下是它们的区别:

  1. LastQty (FIX Tag 32):

    1. LastQty表示最近一次执行(成交)的数量。

    2. 它只反映单个成交事件中的数量,不是多个成交事件的累积。

    3. 每次执行报告都会有一个LastQty,说明最新的成交量。

    4. 在旧版本的FIX协议(4.2及之前)中,这个字段叫做LastShares

  2. CumQty (FIX Tag 14):

    1. CumQty表示自订单创建以来的累计执行数量。

    2. 它是一个累计值,包含了订单在其生命周期内所有执行(成交)的总数量。

    3. 每次执行报告时,CumQty都会更新以反映目前为止的全部累积成交量。

    4. 它用于追踪订单从开始到现在一共执行了多少份额或数量。

例如,假设有一个订单被分多次成交:

  • 第一次执行报告:LastQty=100,CumQty=100(这是第一次成交,所以最近成交量和累积量相同)。

  • 第二次执行报告:LastQty=50,CumQty=150(这是第二次成交,所以LastQty是这次成交的数量,而CumQty是两次成交的总和)。

  • 第三次执行报告:LastQty=25,CumQty=175(这次成交了25个单位,累积成交量现在是175个单位)。

这样,通过查看每次的LastQty,可以知道最近一次成交了多少,而CumQty则提供了订单从开始到现在的全部成交数量。这两个值通常在执行报告(Execution Report)的FIX消息中一起使用,以给出对订单执行情况的全面描述。

OrderQty /LeavesQty /CumQty

  1. OrderQty (订单数量): 这是交易者想要买入或卖出的证券数量。它表示原始订单的总数量。

  2. LeavesQty (剩余数量): 这是尚未成交的订单数量。它等于原始订单数量减去已成交的数量。随着部分订单成交,这个数字会逐渐减小。

  3. CumQty (累计成交数量): 这是订单已经成交的数量。随着部分订单的成交,这个数字会增加。

在金融交易中,如果用户在部分成交后决定修改或撤销剩余的订单,这通常涉及到发送订单修改(Order Cancel/Replace Request)或订单撤销(Order Cancel Request)的指令。以下是在用户部分成交后又改单或撤单的例子:

初始状态:

  • OrderQty: 1000股(用户提交的原始买单数量)

  • LeavesQty: 1000股(尚未成交的数量)

  • CumQty: 0股(累计成交数量)

部分成交后:

  • OrderQty: 1000股

  • LeavesQty: 700股(假设市场上成交了300股)

  • CumQty: 300股

现在,用户决定修改剩余的订单数量,比如减少到只剩下400股(而不是原来的700股),或者用户决定完全撤销剩余的订单。以下是两种情况的处理:

改单 (Order Modification) 用户发送一个订单修改请求,将剩余数量减少到400股。

修改后:

  • OrderQty: 400股(修改后的订单总数量,这里假设用户不仅想要修改剩余数量,而是整个订单的新数量)

  • LeavesQty: 100股(400股中已经成交了300股,所以剩余100股未成交)

  • CumQty: 300股

撤单 (Order Cancellation) 用户发送一个订单撤销请求,想要撤销所有剩余未成交的股票。

撤销后:

  • OrderQty: 1000股(原始订单数量保持不变)

  • LeavesQty: 0股(取消后没有剩余数量了)

  • CumQty: 300股(累计成交数量保持不变)

在实际操作中,改单或撤单请求会触发交易平台或交易所的相应处理流程,订单的最终状态将根据市场规则和系统的实现来确定。例如,部分交易平台可能会为修改后的订单生成一个新的订单ID,而保留原订单的CumQty和已成交的历史信息。撤单操作通常会关闭订单,CumQty显示订单的最终成交数量,而LeavesQty变为零,表示没有剩余数量。

请注意,以上例子假设用户对整个订单数量进行了修改,而不仅仅是剩余部分。具体的改单逻辑(包括是否允许改单、如何处理改单请求等)会依赖于交易平台或交易所的具体规定。

Tag 40(OrdType)

在fix里,如何判断下单是市价单还是限价单

在FIX (Financial Information eXchange) 协议中,订单类型由Tag 40(OrdType)来指定。判断下单是市价单还是限价单,就需要查看这个字段的值。下面是常见的订单类型对应的Tag 40的值:

  • 市价单(Market Order): 0

  • 限价单(Limit Order): 2

  • 止损单(Stop Order): 3

  • 止损限价单(Stop Limit Order): 4

  • 市价止损单(Market on Close Order): 5

  • 限价止损单(Limit on Close Order): B

  • ...

如果Tag 40的值是0,则表示该订单是市价单;如果值是2,则表示该订单是限价单。其他的值对应其他特定类型的订单。

在处理FIX消息时,你会解析出Tag 40的值,并根据这个值来判断订单到底是哪种类型。以下是一个简单的Python函数示例,用于判断一个FIX消息中的订单类型: def get_order_type(fix_message):""" Parse the FIX message and return the order type. :param fix_message: string representation of a FIX message. :return: string 'market' for market orders, 'limit' for limit orders, or 'other' for other types. """ order_type = fix_message.get(40) Assuming fix_message is a dict with tags as keysif order_type == '0':return 'market'elif order_type == '2':return 'limit'else:return 'other'示例FIX消息 fix_message = {... 其他标签 ...40: '2', 这里是Tag 40的值,'2' 代表限价单... 其他标签 ... } 获取并打印订单类型 order_type = get_order_type(fix_message) print(f"The order type is: {order_type}")

其它较常用fix字段

MsgType (Tag 35)

MsgType 字段用于定义FIX消息的类型,即它告诉接收者这条消息是什么类型的。几乎所有的FIX消息都会带有这个字段。以下是一些常见的MsgType取值:

  • 0 心跳(Heartbeat)

  • 1 测试请求(Test Request)

  • 2 重新发送请求(Resend Request)

  • 4 序列重置(Sequence Reset)

  • 5 注销(Logout)

  • 8 执行报告(Execution Report)

  • A 登录(Logon)

  • D 新订单 - 单(New Order - Single)

  • F 订单状态请求(Order Status Request)

  • AB 订单质量查询 (Order Mass Status Request)

  • ...

ClOrdID (Tag 11)

ClOrdID 字段用于唯一标识客户端提交的订单。该标识符通常由订单的发起者(例如交易终端或自动交易系统)生成,并且在相关的所有消息交换中保持不变,以便能够准确地参考订单。取值是一个字符串,没有标准格式,但必须在一个交易日内保持唯一。

TransactTime (Tag 60)

TransactTime 字段代表消息的发送时间,即交易的时间戳。它是根据全球协调时间(UTC)格式化的,并且通常精确到毫秒。取值的格式通常是YYYYMMDD-HH:MM:SS.sss。例如,20230315-22:35:17.456 表示2023年3月15日22时35分17秒456毫秒。

SecurityType (Tag 167)

SecurityType 字段用于标识相关证券的类型。它描述了交易中涉及的金融工具的具体种类。以下是一些常见的SecurityType取值:

  • CS 普通股(Common Stock)

  • OPT 期权(Option)

  • FUT 期货(Future)

  • GOVT 政府债券(Government Bond)

  • CASH 现金(For FX spot and forward trades)

  • ...

ClearingAccount (Tag 439)

ClearingAccount 字段用于表示结算账户的代码,这是用于结算交易的账户。在不同的交易所或清算机构中,这个账户的表现形式可能会有所不同。通常,它是一个由经纪公司或清算行分配给客户或交易者的特定代码。

HandlInst (Tag 21)

HandlInst 字段指示如何处理订单。它告诉交易所或执行系统订单必须如何被执行。以下是一些常见的HandlInst取值:

  • 1 自动执行,仅限价格优先(Automated execution order, private, no Broker intervention)

  • 2 自动执行,允许经纪人干预(Automated execution order, public, Broker intervention OK)

  • 3 手动执行(Manual order, best execution)

这些字段的实际取值和含义可能取决于特定的市场实践或者交易所的规则。使用这些字段时,建议查阅相关交易所或网络经纪公司的FIX规范文档,了解具体的取值和使用场景。

以下是一个交易场景的示例,其中包括下单、改单请求、部分成交报告以及撤单请求。请注意,为了简单起见,一些固定字段将仅在第一次时列出。

固定字段:

  • 8=FIX.4.2: FIX协议版本

  • 9=[BodyLength]: 消息体长度(这是一个计算值,必须根据消息的实际内容计算得出)

  • 49=SENDER: 发送方标识符

  • 56=TARGET: 接收方标识符

  • 34=[MsgSeqNum]: 消息序列号(每个新消息都有唯一的序列号)

  • 52=[SendingTime]: 发送时间(消息发送的时间戳)

下单 (New Order - Single):

  • 35=D: 消息类型为"新订单 - 单(New Order - Single)"

  • 11=ORDER1234: 客户订单ID为"ORDER1234"

  • 21=1: 处理指令,自动执行无经纪人干预

  • 55=AAPL: 证券代码为"AAPL"

  • 54=1: 买卖方向,1表示买

  • 60=20230401-09:30:00.000: 交易时间戳

  • 38=100: 订单数量,购买100份

  • 40=2: 订单类型,限价单

  • 44=150.00: 订单价格,每份150美元

  • 10=[CheckSum]: 消息的校验和

改单请求 (Order Cancel/Replace Request):

  • 35=G: 消息类型为"改单请求(Order Cancel/Replace Request)"

  • 11=ORDER1235: 新的客户订单ID为"ORDER1235"

  • 41=ORDER1234: 原客户订单ID为"ORDER1234"

  • 60=20230401-09:31:00.000: 交易时间戳

  • 38=50: 修改后的订单数量,减少到50份

  • 44=155.00: 修改后的订单价格,每份155美元

  • 10=[CheckSum]: 消息的校验和

部分成交报告 (Execution Report - Partial Fill):

  • 35=8: 消息类型为"执行报告(Execution Report)"

  • 11=ORDER1234: 客户订单ID为"ORDER1234"

  • 17=EXEC1234: 执行ID为"EXEC1234"

  • 150=1: 执行类型,1表示部分成交(Partial Fill)

  • 39=1: 订单状态,1表示部分成交

  • 14=30: 累计成交数量,成交了30份

  • 6=152.00: 平均成交价格,152美元

  • 60=20230401-09:32:00.000: 交易时间戳

  • 10=[CheckSum]: 消息的校验和

撤单请求 (Order Cancel Request):

  • 35=F: 消息类型为"撤单请求(Order Cancel Request)"

  • 11=ORDER1236: 新的客户订单ID为"ORDER1236"

  • 41=ORDER1234: 原客户订单ID为"ORDER1234"

  • 60=20230401-09:33:00.000: 交易时间戳

  • 10=[CheckSum]: 消息的校验和

请注意,为了使例子简单,我省略了每个消息的BodyLengthCheckSum字段的实际计算值。在真实环境中,这些字段会根据消息内容的实际长度进行计算以确保消息的完整性。此外,根据实际应用场景,可能还需要提供更多的字段或者在一些交易所中使用不同的字段。因此,实际操作时应该参考具体的FIX协议实现和交易所规则。

Logo

开放原子开发者工作坊旨在鼓励更多人参与开源活动,与志同道合的开发者们相互交流开发经验、分享开发心得、获取前沿技术趋势。工作坊有多种形式的开发者活动,如meetup、训练营等,主打技术交流,干货满满,真诚地邀请各位开发者共同参与!

更多推荐