FIX实施指南: 固定收益的FIX过程

简介

这一部分以及对FIX协议的改进是债券市场协会和FPL全球固定收益委员会共同努力的结果。本节概述了FIX消息如何用于支持以下固定收益资产类别的固定收益交易活动:

• 美国国债（US Treasury Bonds）
• 美国公司债券（US Corporate Bonds）
• 市政证券（Municipal Securities）
• 机构证券（Agency Securities）
• 待公布抵押贷款支持证券（To-Be-Announced (TBA) Mortgage Backed Securities）
• 欧洲主权债券（Euro Sovereign Bonds）
• 欧洲公司债券（Euro Corporate Bonds）
• 美国和欧洲商业票据（US and European Commercial Paper）

使用模型描述为两个对手方之间的使用模型，一个发起者和一个应答者。

请注意，本节应作为起点，仅用于为读者的FIX实现提供指导。完整的细节可以在FIX协议规范文档中找到。

消息对话

在固定收益交易中，交易对话通常以以下两种方式之一开始:

• 一方向其客户发送报价，客户对产品做出回应。
• 利害关系方发起询价或投标/要约请求。一旦对话开始，交易就可以达成。交易的分配可以在“交易前”或“交易后”直接与交易对手进行。

下面的图表试图说明可能发生的各种对话，以促进FI交易，以及根据对话的起始点使用的消息流。

请注意，这些图表还将通过绿色圆圈显示消息对话中的下一步，而不显示对话期间可能发生的错误条件(即一方收到未知CUSIP)。

意向书 (Indication of Interest)

报价使用意向书(indication of interest, IOI)消息类型进行通信。报价的接收者可以选择忽略IOI消息或通过使用报价响应（Quote Response）消息类型响应特定的IOI消息。

意向书(IOI)，有时是expression of interest (EOI)，是金融中的一种表达方式，表明买方在股票市场上购买证券的非约束性兴趣，通常是在该证券可供购买之前。IOI不是必需的，但是当一家公司决定发行IOI时，它们主要在两个场合使用:在首次公开募股(IPO)之前，以及在机构进行大宗交易(block trade)之前。

报价可以由回应者连续地发送给发起方，只要发起方希望接收。发起方可以选择忽略不响应发送的消息，或者通过向响应方发送报价响应（Quote Response）消息以“击中”或“解除”该要约来响应感兴趣的要约。下面的图1演示了消息流。应答者将在协商交易图中的“B”处拾取消息对话流(见下一
节)。

Figure 1: Indication of Interest/Offerings

协商交易/询价/投标或报价请求

协商交易对话不仅可以通过上述的报价或IOI发起，还可以通过“my bid or offer”，询价/投标/报价请求(inquiry/bid or offer request)发起，两者都使用报价请求（Quote Request）消息类型。“my bid/offer”消息与询价/投标/报价请求(inquiry/bid or offer request)消息之间的区别在于，在“my bid、offer”消息中，发起者发送报价请求（Quote Request）消息，其中包含为所讨论证券设置的“我的买入价/卖出价”价格。应答者将回复一条报价（Quote ）消息。对话的其余部分将遵循下面描述的对话，并在下面的“我的出价/报价”图中进行说明。

询价、投标或要约请求/要求（ inquiry, bid or offer request/wanted）以发起方的报价请求（Quote Request）开始。应答方可以主动向其交易对手发送报价（Quote ）消息，以启动谈判贸易对话，但这种安排应得到相关交易对手的双边同意。

在协商对话中，发起方会向应答方发送报价请求（Quote Request）消息，询问某一证券，询问符合某些规定和参数的一组证券，询问某一证券的bid或offer或quote。如果被应答方选择不提供报价，则可以发送报价请求拒绝（Quote Request Reject）消息并携带适当的拒绝原因代码。此时当前对话将终止。或者，应答者可以用报价（Quote ）消息响应报价请求（Quote Request）。报价消息将为发起者所请求的证券提供定价级别。

发起者将通过使用报价响应（Quote Response）消息类型来响应来自应答者的报价（Quote ）。Quote Response消息类型可用于结束对话、接受（“hit/lift” Quote）或还价（counter Quote）。发起方的“hit/lift”响应向应答方表示，发起方同意价格水平和数量，并希望完成交易。另一方面，如果发起方回应了还价（counter Quote），那么谈判可以继续，直到一方决定终止对话或交易完成。

对于发起方的“hit/lift”消息或还价消息，应答方可以使用报价（Quote ）消息类型回复另一条“counter”消息，用报价状态报告（Quote Status Report）结束谈判对话，或给发起方一个执行报告（Execution Report）消息，表明交易已经完成。此执行报告消息可能包括也可能不包括应计利息、交易总额等信息的计算。

最后，如果发起方认为从应答方收到的执行报告消息中存在差异，则发起方可以使用“不知道交易”(Don’t Know Trade，又称DK交易)消息类型“拒绝”该交易信息。解决错误或差异将手动完成，目前超出了该协议的建议使用范围。

下一页的图表“谈判贸易”说明了这个流程，并提供了一些可以在某些字段中使用哪些值的附加细节。

Figure 2: My Bid/Offer

Figure 3: Negotiated Trade/Bid or Offer Request

带外协商订单

“带外”交易是指通过其他方式进行的交易，如通过电话口头或通过替代交易系统平台进行的交易。在此对话中，假定应答方能够使用FIX协议以电子方式发送完整的贸易信息。发起方可以通过新订单（New Order）消息类型或通过交易对手双方商定的其他方式(即口头或通过替代交易系统平台)发起订单。

当发起者使用新订单（New Order）消息类型下订单时，应答者可以使用执行报告（ Execution Report）消息类型接受订单或拒绝其他订单。如果订单被拒绝，对话框结束。如果订单被接受，谈判可以在带外或“脱机”开始。当谈判完成，交易条款达成一致时，被应答者将向发起方发送执行报告消息，以确认交易已完成。交易条款在Execution Report消息中被重申。

如果发起方认为从应答方收到的执行报告消息中存在差异，则发起方可以使用“不知道交易”(又称DK交易)消息类型“拒绝”该交易信息。解决错误或差异将手动完成，目前超出了该协议的建议使用范围。

Figure 4: Out-of-Band Negotiated Trade

分配指令

发起者可以通过三个不同的选项来传达分配指令:

• 预分配订单（Pre-allocated Order）——在此选项中，当订单下给应答者时，发起方将在新订单（New Order）消息中传达分配指令。
• 交易前分配（Pre-trade allocation）——在此选项中，发起方将使用分配（Allocation ）消息在单独的消息中向被应答方传达分配指令。分配消息在向被应答者下订单后，但在被应答者完成交易之前发送。
  交易后分配（Post-trade allocation）——在此选项中，发起方将在应答者完成交易后，使用分配消息以单独的消息向应答者传达分配指令。

对于发起方，选项2和3表示相同的消息流。主要的区别是当分配消息被发送时——在选项2中它是在交易完成之前发送的，而在选项3中它是在交易完成之后发送的。

一旦交易完成，应答者准备根据分配指令采取行动，假设发起者的分配指令中没有错误，无论发起者使用哪个选项来传达这些分配指令，应答者的消息流都是相同的。

请注意，这些选项适用于固定收益，因为FI的简单交易实践-没有“当天完成”的概念，一组配置适用于单个订单，通常在一次执行中完成。

在预分配订单场景中，发起者将发送一个新订单消息，其中包括应答者在交易完成后分配交易所需的分配信息。但是请注意，如果无法识别一个帐户，或者一个分配实例的数量不符合合约（instrument）的最小数量/最小增量规则，或者分配数量的总和不等于大宗交易数量，则必须拒绝整个请求。如果通过新订单消息发送了错误的分配，则使用带有适当拒绝代码的执行报告消息拒绝整个新订单消息。

如果接受并执行（filled）了预分配的订单，应答者将使用执行报告消息类型将该信息传递给发起者，并根据标准协议使用设置所有适当的状态值。

在消息流的这一点上，应答者将开始根据新订单消息中已经提供的分配指令分配交易，并根据图5所示的消息流(从AllocationReport开始)将该信息传递回应答者。

Figure 5: Allocations

在交易前分配（Pre-trade allocation）场景中，发起者将在下达订单之后，但在执行报告消息表明交易完成之前，使用AllocationInstruction消息类型向应答者发送分配指令。另一方面，在交易后分配场景中，发起者将在收到指示交易完成的执行报告消息后向被应答者发送分配指令——同样使用AllocationInstruction消息类型。

在接受请求之前，应答者应确定所有账户都是已知的，每个分配实例的数量符合合约（instrument ）的最小数量/最小增量规则，并且分配数量之和等于大宗交易数量。如果发现任何错误，应答者必须使用AllocationInstructionAck消息和适当的拒绝原因代码拒绝整个分配。在这种情况下，无论交易已经完成还是等待完成，订单仍然是有效订单。拒绝AllocationInstruction消息并不等同于拒绝在这种情况下放置的订单。发起者可以向应答者发送一个新的AllocationInstruction消息，其中包含正确的指令和信息。

如果应答者接受AllocationInstruction，消息流将继续，如图5所示，应答者将发送AllocationReport消息，以便在适当的情况下传递净货币和应计利息的子帐户级别的计算。在此阶段，发起者仍然可以选择拒绝已验证/计算的分配消息，因为每个分配的子帐户的净金额、总金额等计算存在差异。发起方也可以向应答方返回确认已验证/计算的消息已被接受。发起者的响应都是通过使用AllocationReportAck消息类型进行通信的。

Figure 6: Confirmation and Affirmation

图6展示了在发起者确认分配计算后，应答者将使用的每个已分配帐户实例(AllocationInstruction消息中的子帐户)的确认过程的消息流。

确认（Confirmation ）消息是可选消息，应答者可以使用该消息报告、确认或提出交易中每个分配实例的预订/确认状态的异常。当“确认”状态报告给启动者时，这表明分配的交易已经准备好了。每个确认（Confirmation ）消息将报告单个“票据”的详细信息，因此帐户名称、费用、净资金和结算信息将使用为单个帐户交易指定的字段报告。

一旦从应答方接收到“确认”，发起方通过发送带有“确认”状态的ConfirmationAck消息拥有最终发言权。但是，如果发起方不同意应答方的“确认”，发起方可以使用状态为“已拒绝”的ConfirmationAck消息发送拒绝，并提供拒绝的原因。

向第三方或虚拟匹配工具(“VMU”)提交交易后报告

图7说明了发起者和应答者向第三方或VMU发送贸易通知以进行贸易匹配所需的消息。

Figure 7: Post Trade 3rd Party or VMU Trade Reporting

分配指令（Allocation Instruction）消息类型由发起者用于报告一个或多个订单并阻止交易以及相关的分配给第三方或VMU以进行交易匹配。

应答方将根据第三方的需求、消息类型使用交易捕获报告（Trade Capture Report）或执行报告（Execution Report）向第三方报告交易。此通知将适用于大宗交易。

消息使用明细

本节提供消息中特定字段使用的一些详细信息。这些使用指南是对规范主要卷中已经描述的用法的补充。这些使用指南讨论了基准协议所要求的固定收益要求，或对固定收益使用作出具体说明。

一般使用规则

1. 在任何消息中使用以下价格字段时，必须出现PriceType字段: Price, BidPx, OfferPx, MktBidPx, MktOfferPx, MidPx。
2. AvgPx字段通常表示为“par的百分比”。如果不是，例如在某些确认（Confirmation ）的情况下，AvgParPx和LastParPx已被添加用于传达票面价格的百分比，这将推动从协商价格计算结算。
3. 在包含NoLegs重复块的任何消息的块中使用LegBidPx或LegOfferPx时，LegPriceType必须存在。
4. 在传递价格信息的所有交易和交易后消息中，限价或执行价格总是分别以Price或LastPx形式传递，并适当设置PriceType。根据特定资产类别的市场惯例，可以使用其他字段来补充报价或执行价格，例如YieldData组件块和/或SpreadOrBenchmark组件块。收益率和价差应该只交流衍生信息，而不是协商价格。
5. 除新单（New Order Single ）以外，所有用于FI交易的FIX消息都支持单一合约（instrument ）的“直接（outrights）”交易和两种合约的交易——卖出一种合约同时买入另一种合约作为替代。在美国，后者通常被称为“掉期（swaps）”，在其他地区，它们被称为“开关（switches）”，涉及买卖具有不同合约结算月的期货合约的双合约交易被称为“滚转（rolls）”。NoLegs重复块用于识别和链接交易双方。可以使用LegSwapType代替交易一侧的LegQty，以指示应答方根据另一条腿的数量计算LegQty。要提交掉期（swap ）或滚动（roll ）的新订单，请使用New Order Multileg而不是New Order Single。
6. LastPxPar在Execution Report、Allocation和Trade Capture Report 消息中有条件地必填，当LastPx用一个不是“票面百分比”的PriceType表示时(即当LastPx表示为“折扣”或“收益”PriceType时，LastPxPar必须用等效的“票面百分比”来表示价格)。
7. 当SettlType不是“regular”时，必须指定SettlType。SettlType " future "需要一个SettlDate的值。

意向书（Indication Of Interest）

IOI必须使用其中一组价格信息字段来指定价格信息(参见通用使用规则部分)。

IOIQty或NoLegs重复块都是必需的。如果使用NoLegs重复块，则在IOIQty字段中输入“0”(零)。IOIQty是必要的并用于单合约的出价。NoLegs重复块用于多腿合约(交换/切换/滚转) (swaps/switches/rolls)。在固定收入的使用中，只有两条腿——一条腿买和一条腿卖。

ValidUntilTime是IOI发送方可以指定提供的“确定时间”的地方。

报价请求（Quote Request）

在这条消息中，发起者可以使用QuotePriceType字段指定引用的形式。

ClOrdID字段已被添加到此消息中，允许发起者在请求QuoteType为“Tradable”和OrdType为“Limit”的报价时分配一个ClOrdID。

要提交“my bid/offer”报价请求，发起者需要指定QuoteType为“可交易”，OrdType为“Limit”。必须使用一组价格信息字段之一指定定价信息(请参阅一般使用规则一节)。

ValidUntilTime -由发起者使用，用于指示产生的报价必须有效的时间段。

ExpireTime -由发起者用于指示该报价请求到期的时间段

OrderQtyData组件块-当QuoteType为“可交易”时必需的

报价响应（Quote Response）

发起者将使用QuoteRespType字段来指示这是什么类型的响应，即“hit/lift”，“counter”等。

如果报价响应用于响应IOI(offering)消息，则IOIid是必需的，该字段将包含IOI消息的ID。

当QuoteRespType为“hit/lift”或“counter quote”时需要的字段:OrderQtyData组件块、Side、ValidUntilTime、ClOrdID(见下面段落)，以及价格信息字段集中的任意一个(见一般使用规则部分)。

在最初使用“hit/lift”QuoteRespType时，发起者需要分配一个ClOrdID。这个ClOrdID将在整个谈判过程中被重用，包括在“counter”中，直到谈判在成交中结束或谈判对话由任何一方终止。

在Quote的“counter quote”中，只有有限的一组数据元素可以根据安全类型进行更改。Price可能会发生变化，但在某些市场，所报价的合约（Instrument ）以及Parties 组件区块内的规定（Stipulations ）和结算代码（ClearingCode ）也可能发生变化。

在具有“my price”集的“counter quote”中，OrdType必须是“Limit”和价格信息字段集中的任意一个(请参阅通用使用规则部分)。

报价（Quote）

当QuoteType为" counter “或” Tradeable "时需要的字段:OrderQtyData组件块，Side, ValidUntilTime，以及价格信息字段集中的任意一个(参见通用使用规则部分)。

New Order – Single

对于OrdType，仅适用以下枚举:1(Market)，2(Limit)，D(先前引用)，E(先前指示)。

对于“limit”的OrdType，需要从一组价格信息字段(请参阅通用使用规则部分)中任选一个。

TradeDate是必需的，由发起方设置。

HandlInst是协议所要求的，但不是FI的必填字段。但是，为了遵守《议定书》，交易双方应就使用的价值达成双边协议。

New Order – Multileg

TradeOriginationDate用于市政新股发行市场。指定交易对手之间在实际交易日期之前达成主要协议的日期。

TradeDate是必需的，由发起者指定。

对于多腿订单，如果以下字段不适用于交易的所有腿，则与NoLegs重复块中的每个腿相关联的NestedParties组件块将被使用:Account, AccountType, NoAllocs重复块，SettlType和SettlDate。

执行报告（Execution Report）

此消息应该始终使用SettlType“future”，并为SettlDate赋值。如果发起方在规定组件块中提供了信息，则被请求方必须重复和回应规定组件块中的信息。

对于多腿，当OrdStatus为“new”时，仅使用执行报告消息的NoLegs块进行交换/交换/滚转。每条腿的部分成交或全部成交(OrdStatus)的执行报告将分开报告，每条腿的执行价格将以LastPx、AvgPx和LastPxPar(如果适用)的形式传达。

当“OrdStatus”为“partial”、“filled”或“calculated”时，以下字段是必需的:PriceType、Price

当ExecType为“trade”或“trade correct”时，以下字段是必需的:LastQty, LastPx, AvgPx, LastPxPar(有条件适用时)

当OrdStatus被“filled”或“calculated”时，如果NumDaysInterest被填充且不为零，则需要以下字段:AccruedInterestRate, AccruedInterestAmt

当订单状态被“filled”或“calculated”时，需要GrossTradeAmt和NetMoney。

在适用的情况下，根据安全类型以及当OrdStatus是“filled”或“calculated”时，需要NumDaysInterest。

对于在到期时一次性支付的证券类型，需要利息期限来代替应计利息。

分配指令（Allocation Instruction）

当发起者向第三方或VMU发送分配指令消息时，有条件地需要ReversalIndicator和MatchType。

此消息应该始终使用SettlType“future”，并为SettlDate赋值。

GrossTradeAmt ——发起者在交易后发送分配时需要发送此信息。

对于融资交易，如有必要，使用QtyType和ContractMultiplier来确定数量的表达方式，并在OrderQty中指定要分配的大宗现金金额，在AllocQty中指定要分配给每个基金的现金金额。

分配报告（Allocation Report）

应答者须在报告分配及计算时发送此资料。

应答者在报告分配和计算时需要NetMoney。

在报告分配时，需要从应答者那里得到NumDaysInterest, AccruedInterestAmt和AccruedInterestRate，并计算可以获得或可用的安全类型。

对于在到期时一次性支付的证券类型，需要利息期限来代替应计利息。

在报告分配和计算时，需要从应答者那里得到AllocNetMoney。

AllocAccruedInterestAmt是必须的，如果该值不为零，那么在用计算报告分配时需要从应答者那里得到。应该为每个分配实例计算AllocAccruedInterestAmt并进行适当的四舍五入。这意味着AllocAccruedInterestAmt的总和并不总是与AccruedInterestAmt匹配。

如果值不为零，则在计算返回分配时，需要从应答者那里得到AllocInterestAtMaturity。对于到期一次性支付的证券类型，需要使用AllocInterestAtMaturity来代替AllocAccruedInterestAmt。类似于AccruedInterestAmt, AllocInterestAtMaturity的总和并不总是匹配InterestAtMaturity。

对于融资交易，使用与上述分配指令相同的数量规则。

交易捕获报告（Trade Capture Report）

此消息应该始终使用SettlType“future”，并为SettlDate赋值。

Parties 组件块是必需的。

GrossTradeAmt和NetMoney是必需的。

NumDaysInterest在信息适用的地方是必需的。

如果使用NumDaysInterest且不为零，则需要AccruedInterestRate。

AccruedInterestAmt 对于需要利息的证券类型是必须的。

对于在到期时一次性支付的证券类型，需要InterestAtMaturity 来代替AccruedInterestAmt 。

Instrument component block

符号（Symbol）——当没有适用的符号时，使用“[N/A]”。对于公司债券，可以在这一领域使用发行证券的公司的符号或股票代码。

SecurityID和SecurityIDSource都是必需的。

SecurityType是必需的。

对于MBA、TIPS、ABS，当因子不等于1(1)时，是有条件需要的。

OrderQtyData component block

OrderQty将以票面金额表示。

原文