保密巨额证券交易系统和方法

专利名称：保密巨额证券交易系统和方法
技术领域：
本发明涉及一种方法，用于管理信息以将巨额证券交易(block-trading)意向会聚(focus)到保密交叉书(crossing book)中，并且通过诸如因特网之类的计算机网络来执行巨额证券交易。
背景技术：
在公共证券市场上，市场机构和交易心理对于高效的信息传播和价格发现产生阻碍。市场参与者披露关于大的交易意向的决定通常表示在保密性和流动性之间的折衷。在此使用的术语“市场参与者”指的是具有交易证券的能力的任何人或公司；市场参与者的示例包括经纪自营商、机构、套利基金、统计套利交易和其他财产权交易操作以及在电子通信网络(ECN)上交易的私人投资者。
通过公开地披露例如大的积极的购买意向的细节，市场参与者承担了逆反价格作用的风险——其他交易者可能把他的购买意向视作股票比它当前的价格更值钱的指示。具有合法的销售意向的其他市场参与者和寻求短期交易利润的市场做成者将“减少”他们的出售(offer)(变为不太积极的出售者)，导致市场价格的提高。还有由于“前跑”(其他市场参与者通过预测由于大的被披露的订单而导致的价格变动作出的购买行为)而导致的在经验上可证明的逆反价格作用的风险。
可以通过将大的订单划分为许多小部分来在一定程度上保持保密性以避免引起兴趣，但是当交易者极其小心地隐藏其存在时，这个过程不能迅速地填单，或者如果当它以较快的速率工作时，关于订单存在的信息泄露，导致与上述的订单显示问题非常相同的效果。
在任何一种情况下，都失去了经济上高效的交易，因为与传播信息相关联的交易成本太高。
在纽约股票交易场地上交易大巨额证券也被规则所阻碍，所述规则被设计来保护表示短期交易意向的场内经纪人的意向和专业经纪交易商本身的财产权交易意向。场内经纪人可以使用机构订单来参与，取得与在相对方(contraside)进入的流动性相等的部分，以使用由较大的机构订单提供的安全网来获得短期投机位置；或者通过以一美分的更好价格来截取相对方的流动性而进行在机构订单上的“美分跳跃(penny jump)”，而不是允许它填写机构订单。专业经纪交易商利用包括美分跳跃的各种方法来从关于机构行为的信息提取利润；不变的是，这些行为导致逆反价格变动和较低的对机构订单的填写率。
交易大巨额证券的另一个公知的困难是有时被称为“购买者的后悔”的问题。当交易者发出巨额证券并且迅速地将其填单时，所述交易者的自然反应是相信容易填单表示这是一个差的交易决定——或者有非常多的相对方，其余产随后将价格向相反方向驱动，或者所述巨额证券的价格太具吸引力，导致太快的接受。这种“购买者的后悔”效果使得客户不满意，并且不可能在未来通过这同一渠道来发出类似的订单，因为迅速填单将被感知为用于提供防止差交易的这种渠道的失败。
在限制信息传播的同时匹配交易意向和执行巨额证券交易的一种公知的方法由POSIT匹配系统采用。POSIT匹配系统使得可以累积交易意向，并且以设定的间隔来启动匹配序列。市场参与者在系统中发出保密的订单，并且不知道在相同方或相对方上的其他订单的数量或积极性，直到所述匹配被释放为止。这种方法没有提供任何机制来向可能具有几乎匹配的价格但是重叠的订单数量的交易者通知他们可以以仅仅他们的价格的小改变来实现交易。而且，通过作为黑箱，它不能提供这样的信息，该信息将向交易者指示在特定证券中在系统中存在流动性，以便他们将知道撤回他们已经下在其他地方的订单以参与POSIT匹配。这种方法还不能在系统的参与者对于给定的证券具有比通常更高的意向时，允许广播可能诱惑交易者输入订单的、基于在系统中的行为的信息，这是填单率因而会预期更高的指示。它也不能提供参与者在他的或她的选择时启动交易的能力。通过中途对所有的交易定价，它也不能任何这样的机制，其中，具有适度大小的巨额证券的耐心交易者能够从将趋向于逆向驱动价格的更大或更急切的巨额证券订单获得更好的价格。最后，它不向市场参与者提供通过可以导致发现巨额证券交易的公平价格的处理而协商或以其它方式积极参与价格形成的能力。
试图管理用于帮助巨额证券交易的信息的另一种系统是LiquidNet交易系统。这种系统的用户直接地从他们的订单管理系统提供关于他们的交易意向的数据。当用户指示匹配已经在系统中表达的相对意向的意向时，所有匹配的用户接收进入协商会话的邀请。如果这个邀请被接受，则交易者被预期可靠并且以良好的信誉来协商交易；使用所述系统但是不能以良好的信誉来协商和达成交易的那些交易者从系统中被逐出。在LiquidNet系统中，交易者在任何人已经进入协商之前就知道了相反意向的存在；虽然这种泄露有用于诱使交易者进入协商过程，但是它也向可能或可能不具有对于交易的确定意愿的多方泄露了关于在参与者的订单管理系统中的订单的信息。因此，所述系统依赖于网络成员的“公平操作”，这限制了参与具有相似目的的机构的乡村俱乐部。这不能提供这样的一种系统，其中，具有交易意向的一方仅仅可以被披露到以合理的价格在所述系统内具有确定的、以电子方式可执行的相对订单的多方，并且通过这个规则，允许具有不同动机和交易层次的多方包括销售方公司和套利基金的参与。LiquidNet信息管理模型由于泄露了关于没有确定的交易倾向的参与者订单的一方的信息而未能实现在对于保密性的需要和对于共享某些信息以便及时地聚焦(focus)巨额证券意向的需要之间的适当平衡，这可以通过下述手段来实现，所述手段向交易者指示在系统内有交易意向而不披露具有所述意向的一方，直到交易者已经被暴露为具有确定的交易倾向。它也不能提供防止可由巨额证券交叉(crossing)系统实现的赌博的保护，其中，发现具有第二参与者的订单的一方的唯一手段是发出积极竞价的大巨额证券订单，所述巨额证券订单然后很可能被执行。由于允许所有大小的订单，因此LiquidNet系统也不能提供对购买者的后悔问题的解决方案，其中，很容易地完全填写大订单的购买者以后害怕相对方具有更大的出售订单，其余值有可能使得价格下降。
Harborside Plus提供了另一种系统来用于根据交易意向信息的管理而帮助巨额证券的交叉。在Harborside系统中，当交易者感兴趣于以当前的中间价格来购买或销售至少25,000股的股票时，请求交易者被要求向他们的数据库中发送意向指示。这些意向指示被电子地存储，并且在依赖于客户的交易风格的特定数目的分钟后失效(例如，套利基金或经纪人趋向于迅速地交易，因此他们的指示将在仅仅几分钟后失效)。当在证券的双方中有IOI时，通过弹出式窗口来通知销售交易者，销售交易者将继续召唤客户来达成交易。交易者的调解意欲保证该系统不被当事实上没有交易意向时却将输入IOI的那些交易者滥用，因为对关系的损害将使得这个交易者不太可能在未来将被再次召唤。这个系统不期望下述的交易系统，其中，通过要求交易者输入确定的、电子可执行的订单而自动地强制公平行为，所述订单可以或者在到达时被执行，或者在所述订单的拥有者接收回关于其他交易者的意向的任何信息之前被暴露从而在这种系统中的任何另一方执行。它也不能提供用于自动化由所述销售交易者执行的协商处理的任何手段。因为涉及销售交易者，因此它不能提供交易者从计算机系统期望的匿名，其中，使得交易者能够直接地彼此协商，而不向可能或可能不被完全信任的第三人泄露信息。最后，Harborside系统不能期望这样的机制，当存在仅仅一方的交易意向的证据时，其诱使其他交易者表达他们的证券交易兴趣。最后，它不能期望下述可能性表示关于一方的交易意向的信息而不披露该方，以便聚焦此时的对所述证券的意向，而不向没有表达确定的交易倾向的多方泄露影响价格的信息。
试图管理信息以帮助巨额证券交易的系统的第四个示例是LiquidNetTracker设施，它被纳斯达克股票市场部署，并且是共同未决的美国专利申请第09/870,845号的主题，美国专利申请第09/870,845号的全文通过引用被并入在此。LiquidNet Tracker使得用户能够输入对于交易的确定订单，并且向可能的相对方示出关于这个订单的信息。在LiquidNet Tracker系统中，使用对于纳斯达克参与者通过自动化确认和交易(ACT)系统提交的结算信息的实时访问来识别相对方。通过选择性地仅仅以可能的相对方为目标，意欲避免向能够在机构订单上领先或者以其它方式滥用此信息来获得短期交易利润的其他交易者泄露信息。但是，因为Liquidity Tracker系统仅仅选择相对方，因此，信息接受者将知道第一参与者是购买者还是销售者，即订单输入参与者侧未被保密。这个信息的一些接受者可能被诱使停止或者甚至反转它们的交易方向而不是接受订单，以希望以后看见更好的价格。虽然通过选择目标而带来的保密性级别适合于比可以在公共账簿(book)上显示的订单稍微大的订单，但是有这样的情况其中，具有较大机构巨额证券的交易者将对于这个保密性级别感到不合意。
在这个环境中，非常需要一种保密的交叉系统，它使得用户能够发出将不被示出给任何人的订单，但是将仍然引起可以帮助将交易者在同一证券上同时聚集在一起的信息事件。
为了是有成果的而非破坏性的，在交易协商过程中的信息事件应当避免两个问题1.偏好泄露问题。一旦交易者已经显示了对于购买(销售)可互换的项目的意向，则看见此意向的其他参与者将提高(降低)他们对于这个项目投下的价值。在公平交易(equity trading)中，示出大购买(销售)订单导致其他方修改或取消他们采取相对位置的意图。另一方面，由于不表达偏好，交易者完全丢失了对于交易的机会。
2.购买者的后悔问题。当购买可互换的项目时，当与预期相比更容易地达成交易时，购买者趋向于假定这可能对于其他方是极好的交易。在公平交易的情况下，当完全填写了大巨额证券订单时，交易者将假定相对方的订单甚至更大，当它在市场上起作用时，其余值将随后逆向影响价格。这个问题对于迎合大机构的系统尤其尖锐。

发明内容
本发明的系统和方法提供了对于上述的机构巨额证券交叉的问题的新颖解决方案。
所述系统的一个优选实施例通过不示出交易者意欲交易的方直到最后的协商步骤来限制交易偏好的披露。在输入合理定价的订单时，系统将符号(symbol)设为“积极”状态。这向其他参与者指示已经输入了这个证券的订单，而没有披露它是购买还是销售订单。
在所述优选实施例中，如果价格至少像巨额证券价格范围(BPR)的消极端那样积极，则系统确定它们“合理”。根据当前的市场价格、在符号中的近来变动性、以及流动性(liquidity)来计算BPR，并且在图形用户界面(GUI)上向交易者示出BPR。在所述优选实施例中，通过预测交易者可能在下一个60秒中看见的价格范围来计算BPR，并且以60秒的间隔来重新计算这个范围。在一个替代实施例中，“合理”的价格被认为是在订单输入时分别针对购买或销售订单的、在偏离国家最佳买方出价(Bid)或卖方索价(Offer)的给定数目的百分比(cent)(或其分数)内的价格。
看见符号积极标志并且感兴趣于交易同一证券的第二参与者可以选择输入订单。如果它是相对方并且在价格上足够积极以交叉(cross)第一参与者的订单，则在第一参与者的限制内执行所述交易。
通过要求所有交易者仅仅以大巨额证券数量的倍数输入订单来解决购买者的后悔问题。这个数量被选择得稍微大于通常被发送到经纪自营商的订单的通常大小。例如，对于流动性最大的证券，系统可以被配置来使用100,000股的大巨额证券数量。结果，交易者预期在系统中的多数订单仅仅用于这个大巨额证券数量的一个单位。结果，当交易者接收到在100.000股的订单上的完整填写时，这不以任何方式来指示在系统中的相对方的订单应当被预期更大——很可能它也是100,000股订单，并且所述完整的填写仅仅是系统的强制大巨额证券大小的反映。在一个替代实施例中，只能以这个大巨额证券数量输入订单，并且在填写后从没有余值。在另一个替代实施例中，交易者还承诺在完成交易之后的30分钟内不在市场上交易，并且同意能够进行任意的审计，以验证遵守了自愿的限制，或者当认为需要验证时如此。
在已经降低了购买者的后悔的可能性的情况下，则有可能使得交易者通过“存在相对方”的标志来当在系统中有近乎匹配的相对方订单时对此知道。因为两个订单的大小很有可能相同，因此关于在两方存在匹配订单的信息不指示在不久的将来的任何反向价格变动如果两个交易者取消了匹配，则他们每个将在正常的市场上交易，并且他们各自的交易将彼此平衡，而没有净价影响。因此，存在相对方的信息与下述假设一致当前市场价格是对于大巨额证券达成交易的公平价格。为了避免一些交易者可能仅仅在积极符号上输入订单以便看见相对方存在的标志并且然后立即消除的可能性，在所述优选实施例中所述的系统让常驻的(resident)订单一旦输入相对方订单则立即看见相对方存在标志，但是延迟向输入了相对方订单的第二参与者示出所述标志，并且如果相对方存在的情况持续则仅仅在30秒后示出这个标志。这向常驻的订单提供了30秒的时间窗口，以便通过提高价格积极性来执行新输入的订单，或者在向第二参与者披露其存在之前取消他或她的订单。对于常驻的订单的第一优点是激励了输入将把符号状态设置为“积极”的订单，由此增强了在系统中的流动性，这继而将吸引对于获得所述流动性感兴趣的其他交易者。
在一个优选实施例中，交易者可以以任何价格来输入订单，但是仅仅根据在系统声明的“巨额证券价格范围”内定价的订单来发出积极符号和相对方存在标志。根据国家市场最佳买方出价或卖方索价和股票的近来变动性来确定所述巨额证券价格范围，以便提供关于交易者最可能执行大巨额证券交易的价格范围的指南。例如，所述巨额证券价格范围可以简单地被取为从国家最佳买方出价减去百分之五到国家最佳买方出价加上百分之五的范围。如果所有的交易者知道当前的BPR，则他们知道输入在这个范围内的订单将使得向参与者显示积极符号标志。看见积极符号标志并且意欲购买大宗股票的第二参与者然后以巨额证券卖方索价(BPR的顶部)来输入购买订单；如果使得积极符号标志被设置的第一订单仍然打开(open)并且是销售订单，则第二参与者将具有肯定的填单。相反，如果这样的积极性购买订单未填单，则第二参与者将知道或者第一订单已经被取消，或者它也是购买订单。如果第二参与者相反输入了消极订单——例如以巨额证券买方出价来购买的订单，则那个订单将很可能在到达时不被填写，即使在第一参与者是销售者的情况下也是如此。相反，第一参与者将看见“相对方存在”的消息，并且可能选择降低他或她的价格以锁定所述交易。如果第一参与者不采取这样的行动，则在30秒后，第二参与者将知道引起积极符号标志的第一参与者的订单事实上是消极销售者，并且可以选择提高他或她的价格以满足其间的合理价格。只要两个参与者看见相对方存在标志，他们就可以修改他们的价格，直到完成了交易；更急切的交易者将更有可能更快地提高价格积极级别，即使在没有除了BPR指南之外的任何显示价格的情况下也导致自然的价格发现过程。
在所述优选实施例中，在相对方存在情况下的交易者不接收关于他们的对方的价格变动的信息；他们仅仅期望将他们的订单定价在他们所认为的公平价格，并且希望另一方将进行相同的行为。在一个替代实施例中，交易者看见相对方已经提高或降低了他们的价格积极性，并且可以使用这个信息来确定是否值得类似地提高他们自己的价格积极性级别。如果每个交易者继而以最小百分之一(或其他预设)的间隔来如此，则两者将大约在原始购买和销售价格之间的中途满足。
在图1中给出了本发明的优选计算机系统实施例的示意图。
所述系统优选地包括交易帮助系统100(在此也称为Cloud9)。所述交易帮助系统100通过诸如因特网的通信网络80和诸如FIX网络90的金融信息交换网络来连接到参与者。系统100通过卖方的网络70来从卖方60接收市场数据。参与者通过在每个参与者的工作站中安装的图形用户界面(GUI)来访问系统。订单被传递到执行引擎50。当所述执行引擎接收到匹配订单时，自动交易所述匹配订单。Cloud9包括网络服务器子系统110，负责到每个客户GUI的连接；金融信息交换(FIX)服务器120，用于提供到事务部门(back-office)系统和客户订单管理系统的连接；以及，订单管理子系统130，负责实现在此所述的系统的订单处理逻辑。帮助模块140建立意欲将意向聚焦在交易上和驱使用户进行该交易的信息事件。交易帮助系统100在事务数据库150中跟踪其订单的状态。相对于巨额证券价格范围来评估订单的价格积极性，这是通过分析服务器160计算的订单的价格可以是(a)比BPR更消极或(b)积极，意味着价格在BPR内或比BPR更积极。执行引擎50通过通信网络80来接收订单，并且电子地将它们存储在事务容错数据库(账簿51)中；它通过这个同一网络向交易帮助系统100回报执行情况。在一个替代实施例中，执行引擎50可以作为Cloud9系统100内的附加部件而驻留在本地。
参与者使用图形用户界面20来向系统中输入订单。当执行所述订单时，使用FIX协议来向他们的发起经纪人95和向他们自己的公司的订单管理系统(OMS)10报告结果以处理。
优选的是，要求所有的订单是“大巨额证券订单”，这意味着它们的大小必须是大巨额证券数量的倍数。例如，如果大巨额证券数量是100,000，则GUI仅仅允许作为100,000股的倍数的订单。所述订单可以是限制的或更好的，或者被钉住到市场指标，诸如在国家市场上的最佳买方出价和卖方索价之间的中点。所有被验证的巨额证券订单被立即传递到执行引擎50，在此，它们被存储在账簿51中。在一个替代实施例中，接受任何大小的订单。
Cloud9和执行引擎50优选地在先入先服务的基础上处理订单。
GUI20使得感兴趣于交易给定证券的大巨额证券的交易者能够点击在主屏幕的顶部上的框中显示的证券符号，以引发订单输入对话框，并且按照他或她的预先配置的偏好而自动填充所述订单输入对话框的字段。交易者将按照需要来编辑这些字段，并且按下被标注为“提交”的按钮以发出订单。
如果新输入的订单匹配先前的账簿订单(所述新订单针对同一证券，但处于相对方，并且具有等于或更好于长期有效(standing)账簿订单的价格)，则执行引擎50自动地以长期有效订单的价格来执行交易，并且电子地向自动化确认和交易(ACT)40服务报告所述交易以获得合并记录带(consolidated tape)，并且电子地向发起经纪人的结算公司30报告所述交易。还向图形用户界面20发送执行的通知，以通知所述交易的交易者。如果另一方面在所述账簿中没有匹配的订单，则将所述新的订单保持存储在所述账簿中来作为长期有效订单。在一个优选实施例中，客户可以选择将它们的订单由第三方经纪人发起，在这种情况下，还经由FIX向发起经纪人的事务部门系统95报告所述交易。
为了提高交易的可能性，所述系统的订单管理器130连接到帮助模块140，当新输入的订单未找到匹配但是作为长期有效订单被存储在账簿51中时，其自动地采取行动。在一个优选实施例中，仅仅被合理地定价的订单受到帮助；用于交易大巨额证券的合理价格范围(巨额证券价格范围)由分析服务器60计算，并且每60秒更新一次地在交易者的图形用户界面20上被给出。帮助器140的目的是产生将激励其他交易者输入同一证券的订单的信息事件，而不泄露订单的价格或交易方。
在一个优选实施例中，根据在系统的数据库150中已知的订单的状态，当帮助器140起作用时，有两种可能的行动流。
在第一种情况下，当新输入的订单未找到匹配时，系统的状态是在系统内没有合理定价的相对方订单。向预订这个证券的所有方递送一个消息，用于指示在所述系统内新输入的订单的符号主题现在是“积极的”(如果它已经是积极的，则省略这个步骤)。图形用户界面20将在订单输入对话框205之上的橙色框215内显示积极符号，如图2所示。所述系统优选地使得看见积极符号并且感兴趣于交易这个证券的大巨额证券的第二参与者能够通过点击所述符号而引发订单输入对话框。所述系统优选地按照第二参与者的预先配置的偏好来填充订单输入对话框205的所有字段。第二参与者在知道所述符号是“积极”的情况下行动。因此，他将明白预先输入了使得所述符号变得积极的第一订单，并且这个第一订单被定价在BPR内。利用这个信息，如果第一订单处于相对方并且仍然打开，则第二参与者可以选择以巨额证券卖方索价(巨额证券买方出价)来提交限制购买(销售)订单，以必要地保证交易。在一个优选实施例中，一旦符号变得积极，则它将保持积极至少60秒；结合BPR更新而检查符号行为状态，并且只有当它已经积极超过60秒并且在BPR更新的预定时间在所述系统内没有更多的合理定价的订单当前被打开时，才将符号行为状态设置为消极。在一个替代实施例中，所述符号的积极状态被实时地更新以反映是否此时在系统中有合理定价的订单。在另一个替代实施例中，除了颜色之外，GUI还显示当前在系统内打开的合理定价的订单的数量。
在第二种情况下，系统的状态是在相对方已经有合理定价的订单，但是它的积极性不足以满足由新输入的订单提供的限制价格。在这种情况下，帮助模块140将立即向具有合理定价的长期有效相对方订单的所有参与者发送一个消息，让他们知道现在在系统内存在合理定价的相对方订单。图形用户界面20通过加亮在订单输入对话框205上部的黄色框225中的符号而显示“相对方存在”的消息，如图2所示。使得符号积极的第一参与者将因此看见现在存在相对方。所述系统优选地使得所述第一参与者能够以积极的价格来重新定价所述订单，并且替换所述订单以便执行第二参与者的订单。在一个优选实施例中，所述系统自动将BPR的积极端(aggressive end)作为默认价格以激励将导致交易的策略；交易者可以然后按照期望来修改订单参数。在一个替代实施例中，所述系统使得用户能够配置积极订单类型，以将其限制为BPR或偏离当前国家市场中间价格的可配置百分比数量(或其分数)的较好者，并且这种积极订单类型因此是在相对方存在情况下的默认类型。在一个优选实施例中，用户通过下述方式而被允许输入将使得系统试图执行相对方的订单的订单点击具有所述符号的所述黄色框，然后按下被标注用于此目的的单个按钮。在一个替代实施例中，用户界面20使得交易者选择新的价格，并且按下被标注为“替换”的按钮。如果没有一个具有长期有效订单的交易者提高他们的价格积极性，并且在30秒后仍然有长期有效相对方订单，则始发相对方订单的第二参与者将优选地也知道在系统内有长期有效相对方订单。所述系统优选地通过黄色框来显示这个信息，如上对于第一参与者所述；并且所述第二参与者可以选择提高他的或她的价格积极性以达成交易。所述30秒延迟意欲阻止交易者探测所述系统以发现是否存在相对方，然后其后试图立即取消。这个安全机制有效地使得不从当前的市场太远地去除BPR，以便在30秒间隔期间，新输入的订单面对由具有长期有效订单的交易者之一执行的实际机会。在一个替代实施例中，没有30秒延迟，并且所有交易者被同时通知相对方存在的情况，但是有有效的5秒的最短时间，在此期间，不会取消订单。在另一个替代实施例中，所有用户立即接收相对方存在的消息，并且没有有效的最短时间的条件。在一个替代实施例中，交易者可以配置GUI20，以便当出现相对方存在情况时自动以积极的价格来替换他们的订单。在这个最后的实施例中，如果在系统内有多个订单具有自动重新定价指令并且竞争以执行同一相对方订单，则系统按照价格时间优先级来执行订单长期有效订单首先竞争价格来填写进入的相对方订单，然后如果两个订单具有相同的积极价格限制，则竞争输入时间，优先级赋予所输入的第一订单。
用于计算巨额证券价格范围(BPR)的优选算法寻求根据股票的变动性而确定在接着的60秒内交易大巨额证券订单的合理价格。在所述优选实施例中，这个范围是基于自从最后一次更新BPR起交易已经以其被报告到合并记录带的价格，从而从国家最佳买方出价和卖方索价的当前中点上下取对称价格范围。这个范围相对于所述中点上下扩展一个数量，所述数量直接关联于自从最近的BPR更新起所观察的价格变动性。
首字母缩写词





图1是本发明的优选计算机系统实施例的示意图。
图2描述了优选的GUI，其中打开了订单输入对话框。
图3(a)和3(b)描述了一种优选的系统和方法的操作，包括所述系统与参与者和相关联的公司的电子系统的交互。
图4示出了在一个优选实施例中的、从结算角度来看的交易的生命周期。
图5描述了当处理新票据时优选地执行的步骤。
图6描述了用于处理取消票据消息的优选步骤。
图7描述了用于处理有效订单的优选步骤。
图8描述了优选的观看列表配置对话框。
图9描述了用于计算BPR的优选方法的步骤。
图10描述了优选的GUI，其中识别了被观看的证券。
具体实施例方式
下面是本发明的优选和替代实施例的功能描述。
关键特征。下面是本发明的特征的优选列表1.巨额证券的保密交叉。订单被传送到匹配引擎，所述匹配引擎将利用价格时间优先级来交叉(cross)订单，并且报告锁定(locked-in)的交易以结算。所述匹配引擎可以驻留在远端。
2.大巨额证券数量。必须以对于每个证券配置的大巨额证券数量的倍数来输入所有的订单。大巨额证券大小阻止赌博，并且通过激励用户使用同一订单数量而减轻“购买者的后悔”问题或者在完整的填单之后处于错误方的担忧。
3.积极符号标志。当系统确定在证券的双方都有巨额证券意向时，该系统将使积极符号告警。这将聚焦在短时间窗口中的订单输入，由此提高填单概率。
4.相对方存在标志。当输入近乎匹配的相对方订单时，将提醒在系统中具有合理定价的订单的交易者。30秒后，也向具有该新订单的参与者提醒存在接近的匹配。相对方存在标志聚焦订单的价格，以最大化交易的概率。
5.到事务部门的FIX连接。Cloud9支持用于直接地或通过FIX服务机构来向购买方订单管理系统递送FIX执行的机制，支持相对于发起经纪人的购买方客户的日末(end of day)匿名。
6.FIX票据应用。多个客户可以从他们的订单管理系统投放股份到Cloud9(符号、数量和交易方)共享，然后使用GUI 20逐渐达到所投放的数量。OMS可以被更新以跟踪独立的工作订单，或者仅仅在填单时如此，这依赖于客户的配置。
7.API/GUI访问。Cloud9可以提供使用来自机构交易者的输入而设计的具有自家品牌的交易前端，它显著地显示用于感兴趣的证券的观看列表的积极符号，并且当设置了相对方存在标志时向交易者提示达成交易。API也可以被公布以使得被许可的第三方从他们自己的前端建立访问。
本发明包括一种优选的架构，用于将所述系统与参与者和相关联的公司——诸如发起经纪人或他们的结算公司——的电子系统集成。图3(a)和3(b)中表示了这种集成的概览。这些附解了导致在参与者C和E之间的交易的流程，如下所述。在系统中已经有长期有效订单的情况下，新参与者输入相对方订单。系统发出相对方存在标志；参与者将长期有效订单修改为较高价格积极性级别，从而导致被执行的交易。
所述系统优选地通过下述步骤来帮助在上述示例中的交易1.在步骤1中，用户优选地使用图形用户界面20来向系统中输入订单。
2.系统优选地在步骤2中分配记录的经纪人，并且根据记录的经纪人和客户ID来针对任何信用限制而验证所述订单。所述订单信息被存储在数据库150中。
3.在步骤3中，订单管理器130将所述订单传送到执行引擎50，并且期望从执行引擎返回的订单更新消息，用于指示是否所述订单在进入时被填写，被存储为有效限制订单，或如果所述订单无效则被取消。
4.在发现所述订单在执行引擎中未执行或取消时，OM 130向帮助模块140通知订单输入事件。
5.帮助模块140发现在系统中有相对方存在；它立即向常驻的相对方发送“存在相对方”消息，并且在30秒的延迟后调度用于向刚刚输入新订单的交易者发布这同一消息的事件。
6.在步骤6中，向常驻的订单提供相对方存在的消息。优选地，立即完成这一操作。在一个替代实施例中，在10秒延迟后发送相对方存在标志，以在泄露关于所述订单的信息之前向第二参与者提供尝试更积极的价格的时间。
7.步骤7优选地发生在发送了第一相对方存在消息后的30秒如果相对方存在的情况持续，则向新订单提供所述相对方存在消息。
8.在步骤8中，所述常驻订单，使用服务机构来用于他们到系统的FIX连接的发起客户在他们的GUI 200上接收相对方存在标志，并且修改所述订单以提高价格积极性。
9.在步骤9中，OM 130传送修改订单请求，并且更新在OM数据库150中的所述订单的状态。
10.在步骤10中，OM 130向执行引擎50传递修改订单消息。
11.在步骤11中，执行引擎50确定新的价格积极性足以锁定交易，并且优选地使用结算对方信息而将这个交易报告给ACT。在一个替代实施例中，仅仅对于记录带报告所述交易，并且扣留结算信息，直到当日的末尾以延迟向发起经纪人通知所述交易的时间。
12.执行引擎50优选地向订单管理器130报告所述执行；OM 130更新在它的数据库150中的订单的状态，并且更新所消耗的信用。
13.在步骤13中，订单管理器130向网络服务器110和FIX服务器120报告所述交易。
14.网络服务器110和FIX服务器120向它们各自的客户转发所述执行消息。
15.第二客户通过服务机构来接收FIX执行情况。
16.在交易处理的最后步骤中，向发起经纪人发送所述执行的完结拷贝(drop copy)。在所述优选实施例中，这在一天的末尾时进行；在一个替代实施例中，它立即被执行，并且直接向发起经纪人通知他们发起的所有交易行为。
设施所述系统优选地包括下面的设施或子系统1.网络服务器110。网络服务器子系统使得客户能够通过图形用户界面200来访问系统。优选地，这是可以用于向系统中输入订单的唯一界面。所有的用户必须下载交易应用程序(GUI)或者开发提供了满意的对积极符号和相对方存在标志的可见性的GUI。网络服务器110优选地支持经由所公布的API而连接到交易者前端。
2.FIX服务器120。FIX服务器是使得客户可以连接以便按照FIX协议来交换金融信息消息的计算机系统；在打开源代码库中可以获得FIX服务器的源代码。Cloud9 FIX服务器优选地被配置来接收票据(新建，取消，取消/替换)和订单状态请求消息。它将推出包括订单更新和填单的执行。它优选地支持与客户订单管理系统的直接连接以及通过服务机构的连接。FIX服务器也可以用于向发起经纪人递送执行消息(具有“完成”状态)以在交易处理后建立。通常，这些消息将在一天的末尾被发出，但是，客户优选地也可以请求系统在需要时向他们的经纪人通知一日内的执行情况。
3.订单管理器130。Cloud9订单管理器处理订单和随后的交易消息，将它们传送到执行引擎以存储和执行。优选的是，通过跟踪何时所述订单被定价为至少与BPR一样好或被消极地定价，它从分析服务器160接收BPR更新消息，并且维护在其订单上的价格积极性标志。
4.帮助模块140。订单管理器130优选地包括一个部件，其负责通过仔细地发布关于订单的信息而帮助匹配订单进入系统，如在此所述。
5.订单管理数据库150。订单管理器130优选地跟踪在交易和可完全恢复的结构化查询语言(SQL)数据库中的订单状态。它还包含报告模块，其负责报告所述交易以便结算，以及向对应的自我管理组织(SRO)产生每日的强制性报告。
6.分析服务器160。分析服务器160接收数据反馈，用于向所述服务器通知每个符号的市场行为状态(开始，停止，交易暂停)、所有的纳斯达克和NYSE(纽约证券交易所)列出的股票的内部最佳买方出价和卖方索价(价格、总体大小和时间戳)、来自国家市场系统合并记录带的最后销售交易数据。服务器优选地将这个信息存储到数据高速缓冲存储器中，并且执行分析计算以确定巨额证券价格范围。它负责向预订方公布每个符号、内部报价价格变化、BPR更新消息和交易暂停。
7.帮助台。所述系统优选地包括帮助台子系统，它包括用户界面，诸如万维网GUI。帮助台操作员可以访问这个界面以增加/删除/修改与各个交易者相关联的客户公司、发起经纪人或GUI帐户。所述帮助台使得交易操作人员能够根据订单ID或通过公司和符号来查询所述系统，跟踪随着客户的订单进入系统的事件序列，并且通过所述系统向希望调用帮助台的交易者提供关于他们的订单的历史的详细响应。
8.系统操作管理。所述系统优选地还包括系统操作控制台子系统，它使得系统操作员能够管理所有的Cloud9设施的功能实现。除了常见的系统操作职责之外，系统优选地还使得操作员能够执行其他的职责，包括安全性；审计；管理一天末尾和一天开始的事件的批处理；容量计划；以及管理内部帐户(操作员和帮助台)的权限。
9.匹配引擎50。匹配引擎50可以是电子通信网络或诸如纳斯达克SuperMontage设施的第三方电子交易书。在一个替代实施例中，所述系统本身包括作为在Cloud9系统中的独立部件的匹配引擎。下面更全面地说明上述特征的优选实现。
FIX服务器。Cloud9优选地使用FIX协议来用于当必要时的事务部门与客户订单管理系统10和发起经纪人的集成。图4示出了从结算角度来看的交易的生命周期。客户优选地能够在用于使用系统的两种模型之间选择。第一模型使用票据来帮助管理多个市场目的地上的倾向(liability)。票据是来自客户的订单管理系统的布置(placement)，其帮助交易者对他们在每个市场目的地中处理多少股进行记帐(市场目的地是交易者可以执行订单的地方，诸如本系统)。票据的目的是保证在所有目的地上布置的总股数从不超过客户的整个订单的全部股数，其为客户的订单管理系统10所知道。当交易者使用票据时，已经从OMS输入的票据出现在GUI 20上，并且可以仅仅针对这些票据来输入订单。
优选地，如果订单在同一证券中、在同一方和具有不大于先前输入的票据的大小，则选择使用票据的客户才能向系统中输入所述订单。所述系统优选地通过当交易者选择使用票据时执行下述步骤来更新事务部门和第三方系统。
1.在步骤410中，向系统100内输入作为没有价格的FIX订单的票据。所述票据承载系统映射到特定GUI的终端ID。交易者看见票据显示在他的/她的GUI上。
2.在步骤420中，交易者针对这个票据而输入订单，我们将所述订单在此称为“子”订单。这个子订单处于与所述票据相同的证券和一方，并且其数量被选择为交易者配置的默认订单数量或票据数量的较小者。所述系统优选地验证所述订单，并且将其传递到执行引擎。在所述优选实施例中，订单输入事件经由Order Status(订单状态)＝New(新)的FIX执行消息而被报告到OMS。在一个替代实施例中，客户OMS仅仅当完成交易时接收执行消息(参见下面)。
3.当针对这个订单而发生交易时，执行引擎优选地向ACT报告以获得记录带和结算(步骤430)；然后向Cloud9通知所述交易。在所述优选实施例中，Cloud9系统然后经由API通知GUI，并且经由FIX通知客户的订单管理系统。
4.系统优选地使得交易者能够在交易日的末尾之前启动分配处理(按照用户的选择来执行步骤440)。为了获得日内的匿名，优选地不向发起经纪人通知所述交易，直到一天结束，但是如果不向发起经纪人通知所述交易者，就不能完成所述分配处理。为了支持一天结束的分配，GUI优选地使得交易者能够首先点击用于请求系统向发起经纪人报告所述交易的按钮。这将使得发起经纪人的系统预先准备好所述分配处理。在一个替代实施例中，经由FIX执行消息而立即向发起经纪人通知每个交易。
5.在步骤450中，系统优选地向执行经纪人发送包括客户ID的FIX执行消息。
6.优选的系统在一天的末尾执行下述(步骤460)。
a.向执行经纪人发送FIX执行消息，包括客户ID。如果已经在步骤450中发送了它，则可以复制类似的消息。
b.向发起经纪人的结算公司发送交易总结文件。它包含涉及结算的信息，包括符号、所购买或销售的股份和相对方的MPID。
c.OATS报告以发起经纪人的名义提供了订单跟踪和执行的总结。所述系统自动地向发起经纪人发送OATS报告以转发到NASD。在一个替代实施例中，它直接地向NASD发送报告。这些文件传输是电子的，并且利用文件传输协议(FTP)。
在所述优选实施例中，使得用户能够选择不需要使用票据、而是使得交易者可以在订单输入步骤420开始所述处理的的替代配置。剩余的流程与如上所述的相同。
在一个替代实施例中，系统100由发起经纪人驻留(host)用于使用所述系统的所有客户，并且包括交易处理后的子系统，这可以被本领域的技术人员容易地实现或者通过专门的卖方而购得。在这个替代实施例中，不需要一日末尾的匿名，并且可以立即分派经纪人执行报告。
FIX服务器120优选地支持用于提供到客户订单管理系统10的连接的多种联网方案。例如，客户的OMS可以直接地连接到所述FIX服务器，或者它可以通过FIX服务机构与FIX服务器120通信，其中所述FIX服务机构扇出(fan out)在单个FIX服务器120和多个客户之间的连接。
FIX服务器120优选地当票据无效或当客户被配置成不使用票据时拒绝票据；票据拒绝消息优选地在文本字段中承载可理解的拒绝原因。如果因为订单数量小于这个证券的大巨额证券数量而发送拒绝消息，则优选地对拒绝消息的消息文本中的信息提供正确的LBQ。在所述优选实施例中，FIX服务器120优选地支持下面的输入消息FIX新订单、取消订单、取消/替换和订单状态请求。如果客户使用票据，则输出的消息优选地包括与给定的票据的子订单相关联的订单更新(承载底层票据的订单ID的FIX执行消息)。不使用票据的客户优选地仅仅接收填单(FIX执行消息)。在一个替代实施例中，不使用票据的客户接收与经由GUI输入的订单相关联的每个事件的订单更新消息，其中包括新订单确认消息，以便OMS可以逐个事件地跟踪所操作的总体大小以及已经被填写的大小。
FIX服务器优选地支持万维网配置屏幕，所述配置屏幕使得操作员能够建立和定制新的客户连接，而不要求新的软件发布。如上所述，FIX购买方客户优选地可以被配置用于(a)仅仅FIX执行或(b)支持票据和执行报告。FIX发起经纪人客户优选地被配置成仅仅接收执行。在一个替代实施例中，有可能配置发起经纪人的FIX连接以接收被发送到发起客户的OMS的每个消息的完结拷贝。除了在每个填单上发送的执行消息之外，配置选项优选地还包括这样的选项，即当完成订单时发送最后的FIX执行消息，其中订单状态字段被设置成“完成”，以便指示这个订单上的工作完成。
订单管理器。订单管理器130作为消息处理器。在下面的段落中，描述了各种消息的处理。
所述系统优选地使得用户能够输入新票据消息。新票据消息是FIX新订单消息，其中Order Type(订单类型)＝Market(市场)，并且没有限制价格。具有限制价格的FIX订单将被拒绝。在一个替代实施例中，可以通过应用程序编程接口(API)提交这个消息。
在步骤510接收到票据后，优选地在处理新票据的同时执行下面的步骤(参见图5)●验证。在步骤520，系统优选地通过首先验证在FIX新订单消息中的字段来处理新订单。票据必须具有有效的客户ID、交易者ID(映射到唯一的GUI)、证券和交易方(购买或销售)，并且必须与这个证券的巨额证券数量至少一样大。Cloud9优选地接受被识别为“市场”订单和“未持有”的FIX订单(票据)，并且拒绝具有限制价格的票据。在替代实施例中，不强制对价格和未持有状态的限制。客户优选地仅仅被允许在每一方具有每个证券一个票据；如果先前的票据仍然保留，则将拒绝同一证券的第二购买票据或第二销售票据。如果先前的票据被填写或取消，则可以输入第二票据；它将替换在GUI前端上的第一票据。一个替代实施例采用使得能够对于每个证券显示多个票据的前端，并且客户被允许发出任何数量的票据。将忽略其他商业FIX订单属性。优选地，使用原因代码在GUI上显示被拒绝的票据。
●处理。所述系统优选地在其数据库150中存储有效的票据。然后，在步骤540经由网络服务器110将所述票据显示在客户GUI上，并且在步骤530经由FIX 120向客户OMS进行往回确认。下面的表格给出了在所述优选实施例中的票据消息中的必需字段。

所述系统优选地使得用户能够输入取消/替换票据消息。取消/替换票据优选地被提交为FIX取消/替换订单，它具有先前打开的票据的ClientTicketID和新票据的ClientTicketID。在一个替代实施例中，这个消息可以通过API被提交。在所述优选实施例中，所述系统在接收到取消/替换票据消息时执行下面的步骤。
●验证。如果新数量减去已经被填写的数量(新的“剩余量”)小于符号的系统大巨额证券数量，或者如果它小于作为打开订单在执行引擎上发出的总股数(小于工作量的剩余量)，则本发明的系统主题优选地拒绝取消/替换消息。
●处理。如果它接受所述请求，则Cloud9优选地修改要应用到任何后续的订单输入事件的票据大小，并且经由网络服务器110来向客户GUI提供所述改变。它优选地还经由FIX向客户的OMS对所述改变进行往回确认。
所述系统优选地使得用户能够输入取消票据请求。取消票据消息是具有先前打开的票据的ClientTicketID的FIX取消订单消息。在一个替代实施例中，可以通过API来提交这个消息。本发明的系统主题如下处理取消票据消息(参见图6)。
●验证。所述系统优选地通过保证它指向打开的票据而在步骤610验证取消请求消息的字段。
●处理。如果存在打开的订单，则在步骤620，系统将首先试图取消与所述票据相关联的所有打开的订单，然后在步骤630使用空中的(inflight)消息来报告在取消之前进行的任何执行630(当所有相关联的订单被填写或取消并且Cloud9订单管理器的数据库与执行引擎的数据库在任何填单的状态上一致时，这个“清除”处理结束)。如果有的话，当已经清除了任何打开的订单时，在步骤640，所述系统将使用指示被取消的大小的结果来确认取消票据。在步骤650中，经由网络服务器来向客户GUI来通知成功的取消票据请求。
所述系统优选地使得用户能够输入新订单消息。优选地通过GUI或API来提交新订单消息，并且所述新订单消息包括以限制价格或更好价格来购买或销售给定证券的给定数量的大巨额证券份额的请求。在所述优选实施例中，用户也可以选择钉住的价格限制，在这种情况下，所述订单将被限制在绝对限制价格和钉住限制价格之间的不太积极的价格上。新的订单消息优选地被处理如下。
验证。所述系统优选地验证订单用于在所支持的证券中的大巨额证券数量的倍数。在一个替代实施例中，所述订单可以用于任何数量。在优选的订单验证处理中的另一个步骤是验证所述订单包含价格字段。在一个替代实施例中，如果用户已经选择了钉住价格，则这个要求被放弃，在这种情况下，钉住的订单可以没有限制地浮动。在所述优选实施例中支持的钉住(Peg)类型钉住到NBBO中点或根本没有钉住。替代实施例支持附加的钉住属性，这是本领域的技术人员公知的。所述系统优选地还验证订单方是购买或销售。一个替代实施例还支持短销售订单。所述参数PegOffset确定偏离订单应该被定价的所述钉住值(NBBO中点)的百分比数量(或其分数)。如果订单不钉住，则优选地忽略PegOffset属性。所述系统优选地使用可理解的错误代码来向GUI客户报告被拒绝的订单。如果客户使用票据，则所述验证步骤还优选地检查所述订单不超过相关联的票据的大小，并且处于与票据相同的一方。如果输入所述订单的客户对于发起经纪人具有信用限制，则作为所述验证处理的一部分，所述系统优选地验证所述订单未违反所述信用限制；将在下面更详细地描述信用验证处理。
在所述优选实施例中，IOC订单被拒绝为无效，因为它们可以用于探测关于导致了符号积极标志的长期有效订单的信息，而不向所述长期有效订单的拥有者示出相对方存在标志。在一个替代实施例中，接受IOC订单，但是长期有效订单的拥有者可以看见闪动的相对方存在标志(例如，符号从橙色向黄色迅速改变，然后返回到橙色)。在另一个替代实施例中，接受IOC订单，并且IOC订单不导致发送出任何标志，而不管是积极符号标志还是相对方存在标志。
订单属性。所述优选实施例的系统期望找到在下表中给出的新订单消息中的必需字段。


处理。所述系统优选地通过下面的步骤来处理有效的订单(参见图7)。
●在验证(步骤710)后，在步骤720中立即向执行引擎传递有效订单。响应将指示所述订单是被拒绝，还是被接受并且作为打开的订单而被放在账簿中，还是具有执行挂起。来自执行引擎的状态经由网络服务器被报告到GUI客户。
●如果客户使用FIX票据，则所述系统优选地经由FIX将订单状态向回报告为被接受或被拒绝(步骤730)；执行挂起状态将被报告为在FIX中的打开状态(随后的锁定执行消息将跟随)。所述FIX订单状态更新消息承载相关联的票据的ID。
●如果执行引擎指示所述订单是打开的，则所述系统将通过帮助器来启动处理740，其目的是提高交易的可能性。
○所述系统优选地确定是否所述价格在巨额证券价格范围(BPR)的最新公布值内，并且如果肯定，则将所述订单标注为“积极”。对于这个评估，使用市场数据高速缓冲存储器来定价钉住订单。
○如果订单被标注为“积极”，则所述系统优选地确定是否在系统中存在积极的相对方订单。如果存在，则立即向没有它的常驻相对方发送相对方存在标志，并且在ContraPresentDelay秒的延迟后调度重新评估相对方存在状态的事件。如果在这个所调度事件的情况下第一参与者的订单和至少一个相对方订单仍然积极并且在BPR内，则系统向第一参与者发送相对方存在标志。
○如果订单被标注为“积极”并且所述符号没有已经处于积极状态，则将符号设置在积极状态中，并且产生积极符号消息。
●在步骤750中，所述系统等待相对方订单到达；如同在验证步骤710开始的这个流程中那样，处理每个相对方订单。优选地，以常驻订单的限制价格执行具有相等或更好的价格的相对方订单。
所述系统优选地使得用户能够输入取消订单消息。取消订单是具有对应于先前的新/替换的订单的ClientOrderID的GUI/API消息。在一个替代实施例中，也可以经由FIX来接收取消订单请求。
验证。如果订单ID是无效的或者指向在Cloud9中未知为打开的订单，则拒绝取消订单请求。
处理。系统100优选地通过下面的步骤来处理取消订单请求。
●Cloud9 OM 130向执行引擎50传递有效取消订单请求。
●执行引擎50将使用被取消的股份来响应。取消响应可以在执行的后面。对于已经被填写的或过期的订单，拒绝取消请求。
●在从执行引擎50接收到成功的取消响应时，○将订单状态更新推送到GUI客户20和分析服务器160。
○如果客户使用FIX票据，则还经由FIX报告状态更新。
○释放被分配到这个订单的信用。
○通过“相对方存在”标志检查是否存在相对方，并且如果不再满足相对方存在条件则去除所述标志。
○注意取消订单不去除积极符号标志。
所述系统还使得用户能够输入取消/替换订单请求以修改先前的订单。在所述优选实施例中，取消/替换订单是指向(ClientOrderID)有效的先前新/替换订单的GUI/API消息。在一个替代实施例中，也可以经由FIX来输入这个消息。
验证。ClientOrderID必须指向有效的订单。如果取消/替换请求指向已经在Cloud9内已知为被取消、过期或被填写的订单，则所述系统优选地拒绝所述取消/替换请求。在所述优选实施例中，所述系统支持交易之前的信用检查。因此，如果要通过取消/替换请求来提高订单的大小，则系统首先验证新大小将不超过用户帐户的信用限制。不能通过信用验证的替换订单请求被拒绝为无效，其中通过原因代码来说明信用原因。
取消/替换订单处理。Cloud9 OM 130通过将取消/替换订单消息传递到执行引擎来处理它们。执行引擎50将以包括被填写的股份、剩余的打开股份和平均价格的订单状态来响应。
●交易消息。将把状态更新经由网络服务器110推送到GUI客户。
●如果客户使用FIX票据，则还经由FIX报告状态更新。
●如果取消/替换修改了订单的大小，则取消和替换被分配到这个订单的信用量以反映新的订单。
交易消息。执行引擎50经由交易消息向订单管理器130报告交易。来自执行引擎的每个交易消息报告仅仅涉及两个订单的锁定交易。
执行引擎50将独立的订单与多个相对方订单的账簿匹配(一对多的匹配)。可以有多个遵循匹配检查的独立交易，其中每个将独立地被处理。
因为交易是单个事务，因此所述交易的两个分支(leg)应当作为一个单元被报告。
所述系统的优选实施例期望找到在交易消息中的下列字段。

处理交易消息。系统100优选地通过下面的步骤来处理来自执行引擎50的交易消息。
●对于使用票据或者请求FIX执行的客户，向相关联的GUI客户并且经由FIX报告两个填单。
●根据交易价格更新信用以反映所消耗的实际信用量。
●如果交易者使用票据并且在所述票据上的剩余数量小于这个符号的大巨额证券数量，则使在票据上的剩余数量过期。
●向网络服务器发送巨额证券记录带消息，以递送到观看此证券的GUI。所述巨额证券记录带消息优选地包含下面的字段。

在紧急时，所述系统优选地使得交易者能够使用单个请求取消他们在系统内所发出的所有的订单。CancelAllClientOrders是来自网络服务器的消息，用于请求取消已经通过给定的GUI而输入的所有订单。在一个替代实施例中，也可以经由FIX来提供这个消息。因为执行引擎50不知道客户ID，因此Cloud9 OM将通过独立地取消具有打开状态的与这个客户相关联的每个订单，作为独立的取消订单请求处理这些订单，从而处理取消全部消息。
为了跟踪与相对方存在或积极符号指示符相关联的订单的价格积极性，在所述优选实施例中的订单管理器130从分析服务器160预订关于具有打开订单的证券的BPR更新消息。每当刷新BPR时，OM 130检查在打开订单上的“积极”标志，并且如下更新所述标志。
如果订单上的价格积极性标志发生改变，则对于这个证券的所有订单重新评估是否有相对方存在情况，并且当对于订单存在被定价为至少与BPR一样积极的相对方时，将相对方存在标志更新为打开状态，或者如果不再存在合格的相对方，则将相对方存在标志更新为关闭状态。如果这导致订单上的相对方存在状态中的改变，则系统优选地向被影响的GUI客户发送相对方存在消息。
所述优选实施例的系统还根据BPR更新消息来更新订单的积极状态。如果所述符号处于积极状态、已经处于这个状态至少60秒并且在BPR中不再有任何订单，则所述符号被设置为消极状态，并且网络服务器发送积极符号消息，其中ActiveSymbolStatus(积极符号状态)＝NotActive(消极)。
退订BPR更新消息。在一个替代实施例中，在任何BPR更新消息上更新积极符号状态，并且即使所述符号处于积极状态少于60秒，也可以将积极符号状态设置为消极状态。在另一个替代实施例中，在国家市场最佳买方出价和卖方索价价格的每次改变和每次订单输入或取消事件时，更新所述积极符号，以保证所述积极符号标志总是指示此时在系统中存在至少与BPR的消极端一样积极地被定价的、活动可执行订单。
执行引擎。在所述优选实施例中的执行引擎50是通过诸如因特网的通信网络80来与订单管理器130通信的去耦系统。在一个替代实施例中，执行引擎50驻留在与Cloud9系统100相同的设施中，并且所述两个系统通过内联网来通信。在另一个替代实施例中，执行引擎50是在Cloud9系统内的部件；在所有这些实施例中，执行引擎50的功能被描述如下。执行引擎50接收“匿名”的订单，这意味着所述订单被去除了购买方客户ID，并且取代为由内部订单ID和发起经纪人ID来识别所述订单。执行引擎50通过下述方式来处理新输入的订单通过查看是否存在与输入的订单匹配的常驻订单，并且使用利用价格时间优先级而排名的常驻订单来执行交易，如下详细所述。
在所述优选实施例中的执行引擎50是用于在失败时恢复关于任何Cloud9交易的真实状态的记录账簿。
执行引擎50的优选实施例支持限制订单和被钉住到NBBO中点的订单。在一个替代实施例中，也支持本领域的技术人员公知的其他订单类型。例如，一种替代的执行引擎可以支持价格自行处理(discretion)订单，其可以针对市场订单以限制价格来执行，但是可以自动地提高他们的价格积极性以触发与输入的限制订单的匹配，直至预定的自行处理量。在一个替代实施例的另一个示例中，所述系统使得交易者能够输入订单，所述订单是以后根据数量加权平均价格(VWAP)在前行时间间隔中被定价的，诸如从交易时间到一天的末尾的VWAP或在诸如半小时间隔的特定时间间隔上的VWAP。
可以将在所述优选实施例中的订单描述为具有可选Peg的限制订单。要求所有的订单具有限制价格；如果它们也具有钉住价格，则所述订单被当作被定价在限制和钉住值之间的更消极的价格。在匹配检查事件的情况下，定价钉住订单，然后将钉住订单看作与具有限制或钉住价格的更消极者的限制订单相同。所述钉住值是NBBO中点加上钉住偏移量。
在所述优选实施例中，用户将使用Peg作为对于限制订单的保护，以确保如果市场迅速地改变，则它们的订单不以与NBBO价格相比较以很积极的级别突然出现(stand)的价格来交易。GUI 20以下述方式来建议了使用Peg的这种方式通过将所述特征表示为“价格保护”，并且提供选项“在超过偏离NBBO中点价格的百分之<n>的情况下不交易”。
因为在所述系统中有钉住订单和限制订单，因此也可以不在订单输入时触发匹配，而是作为将使得钉住订单的价格与相对方订单的限制价格交叉的NBBO价格改变的结果来触发匹配。
因此，在本发明的所述优选实施例中，可以在新订单输入时或者在使得钉位订单与其他订单交叉的NBBO价格改变时触发匹配。所述系统优选地实现下述处理来识别这样的匹配。
执行引擎50优选地包括这样的部件，用于使用在本领域公知的信息高速缓存技术来从数据提供器60接收所有的报价更新消息，并且跟踪当前的最佳买方出价和最佳卖方索价。它优选地还使得执行引擎50的部件能够预订给定证券的价格更新，其后，每当给定的证券的最佳买方出价或最佳卖方索价改变时它将接收到消息。
执行引擎50优选地维护在一方具有一个或多个限制订单并且在另一方具有一个或多个钉住订单的符号的列表，并且预订在这个列表中的所有证券的NBBO价格改变。对于本说明书，具有限制价格的钉住订单既被视为钉住订单，又被视为限制订单。对于在这个列表中的符号，执行引擎50将通过下述方式来处理每个NBBO价格改变通过定价证券的所有钉住订单，然后按照价格时间优先级对购买方和卖方索价方的所有订单进行排名。
所述系统优选地通过下述方式来进行识别匹配通过首先获得排名最前的购买订单，并且以价格时间优先级来处理在这个订单和销售订单之间的交易。如果仍然存在未被填单的销售订单，则所述系统进行到排名其次的购买订单，并且再次以价格时间优先级来处理与还未被填单的销售订单的交易。
执行引擎50将优选地如下观察在主市场上的交易暂停。当证券被暂停时，将拒绝所有现有的和新的订单。执行引擎50从数据卖方60获得证券交易状态。如果数据卖方60不能提供服务或对应的通信网络70失败，则执行引擎不处理任何交易，而是仅仅等待重新建立至关重要的服务。
对于分析服务器160，在所述优选实施例中的市场数据馈送包含市场暂停信息以及级别1和最后的销售数据。
如果新订单触发了匹配，则执行引擎优选地使用预期的总匹配数量来向Cloud9 OM 130立即报告执行挂起。这个报告的信息量是情报性的而仅仅用于帮助器140，而不保证交易将被结算，如下所述。
如在本领域内所公知的那样，优选地将作为单个事务处理交易，以避免在失败时系统报告交易的一方而没有另一方的风险。所述处理包括下列步骤。
1.按照需要来向调节组织报告交易，并且更新在数据库中的订单状态。在所述优选实施例中，向纳斯达克ACT系统报告交易。匹配引擎立即向ACT报告以便用于数据传播(记录带报告)和结算。
2.当交易成功地被锁定以结算(ACT确定交易报告并且分配ACT报告ID)时，执行引擎50优选地向订单管理器130发送确定的交易报告消息。优选地使用用于计算NBBO中点的最近买方出价的时间戳和最近卖方索价的时间戳以及处理所述执行的时间戳来报告涉及钉住订单的交易。
执行引擎50如下处理输入的消息新订单处理。新订单是来自OM 130的消息。优选地如下处理它。
●如果有的话，识别匹配订单，并且以状态向订单管理器130确认订单输入。
●如果订单未被填写但是导致在一方有限制订单而在另一方有钉住订单的情况，则登记所述证券的NBBO价格更新。
●如上所述处理任何交易取消订单。取消订单是来自Cloud9的、取消打开订单的请求。优选地如下处理它。
●验证是否取消订单请求承载指向在账簿51中的订单的有效订单ID。
●如果所述订单已经被交易，则拒绝所述取消订单请求消息。
●如果所述订单还没有被交易○在执行引擎数据库(账簿51)中将订单状态标注为被取消。
○向订单管理器130报告成功的取消状态。
在所述优选实施例中，可以在任何时间修改或取消订单。在一个替代实施例中，要求订单具有10秒的最小有效时间以向其他参与者提供合理的时间来对由帮助器140触发的事件——诸如积极符号标志或相对方存在标志——作出反应。
所述系统优选地还使得订单管理器130能够请求取消与给定的发起经纪人相关联的所有订单或者取消全部订单。执行引擎50通过下述方式来处理这样的集体取消订单请求通过首先识别所有被影响的订单，然后按照订单的输入时间来处理取消订单请求。
执行引擎50优选地使用30秒的心跳来验证与订单管理器130的连接。在丢失连接时，所述系统优选地取消所有的订单。
网络服务器。所述系统优选地包括应用程序编程接口，它使得客户GUI20能够通过诸如因特网的通信网络80而连接到网络服务器110。网络服务器110使得客户前端应用程序能够访问Cloud9交易服务，诸如查看BPR更新，以及向系统中输入订单。
如果检测到丢失了到客户的连接，则Cloud9优选地试图使用执行引擎50来取消所有客户的订单。在一个替代实施例中，系统使得客户能够选择其中连接的丢失不导致打开订单的取消的配置；选择这个替代配置的客户然后在紧急时必须调用帮助台来取消订单。
网络服务器110向订单管理器传递交易行为消息(订单，取消/替换，取消)，并且向客户往回传递响应和未经请求的消息。它也存储客户GUI配置，诸如在屏幕上的窗口的位置和大小和交易者希望观看的证券的列表。这些示例不构成穷尽的列表，而是意欲仅仅用于说明性目的；其他配置参数被存储来支持通常的GUI显示选项，这可以容易地被本领域的技术人员明白。
在一个优选实施例中，GUI使得交易者能够当可用信用量低于执行大巨额证券交易通常所需要的美元金额时查看由系统产生的警报。在一个替代实施例中，不显示信用警报，并且用户仅仅在订单输入请求失败时发现没有足够的信用。
在本发明的所述优选实施例中，GUI 20使得交易者能够访问用于帮助管理证券的观看列表的对话框。观看列表的目的是限制从所述系统向交易者所感兴趣的符号的信息流动。在所述优选实施例中，所述系统还使得交易者能够查看是否有其他人当前正在通过打开的GUI观看给定的符号(对此感兴趣是因为这将提高交易的可能性)。在一个替代实施例中，GUI 20使得用户能够看见观看证券的交易者的数量。GUI 20将登记仅仅被观看的证券的BPR更新消息以及积极符号和相对方存在消息的接收。在所述优选实施例中，API允许GUI登记任何证券的BPR/积极/相对方存在消息，并且独立地登记证券的独立列表的报价更新消息。优选的GUI 20一次仅显示一个证券的NBBO价格，即订单输入对话框打开的那个，如图2所示。在一个替代实施例中，GUI预订所有被观看的证券的NBBO更新，并且这些价格被显示在下拉列表中的符号的旁边。
为了管理观看列表，用户优选地能够增加单独的符号，或者增加被分类为处于已知证券组诸如工业组或部门中的所有符号。所述系统优选地还使得用户能够以Excel文件的形式来提交它们自己的证券组，并且向系统中加载这些组，在此，简单地将它们加到交易者可能从其选择以填充他的或她的观看列表的证券组列表。
图8示出了优选的观看列表配置对话框。用户能够增加符号或符号组。改变处于挂起状态，直到用户保存了所述改变。用户也可以返回到先前保存的观看列表或从Excel电子表格加载一组证券，其中该Excel电子表格例如可以从它们的OMS或流水帐(blotter)获得。
所述观看列表优选地由客户管理，并且保存在服务器上。
在一个优选实施例中，网络服务器110跟踪哪些符号正在被两个或更多的GUI “观看”。如果向交易者观看列表增加符号以使得观看客户的数量达到2，则网络服务器110将向预订积极符号消息的所有GUI广播消息，以指示所述符号被观看。如果观看GUI的数量降到1，则网络服务器向预订积极符号更新的GUI广播消息以指示这个符号不再被观看。在一个替代实施例中，所述消息在用户增加或去除对于符号的观看的任何时间被发送，并且提供所述符号、时间戳和观看所述符号的各方的更新数量。
GUI 20优选地通过下述方式来显示在交易者的观看列表中并且处于积极状态或者存在相对方的所有符号通过彩色编码的矩形在GUI的顶部加亮它们，使用橙色来用于积极符号，黄色来用于相对方存在。在一个替代实施例中，类似于即时信使应用程序，通过临时的弹出式屏幕来显示用于指示被观看的符号已经变得积极或具有相对方存在的消息。在另一个替代实施例中，这些弹出式消息保持可见，直到采取行动——或者通过点击以产生订单输入对话框并且响应于所述消息而输入订单，或者通过点击“关闭”或“最小化”按钮以关闭弹出式窗口或者将其缩小到屏幕底部的横条上。
在所述优选实施例中的交易者GUI 20具有这样的选项，即示出或不示出处于“被观看”状态的其观看列表上的符号(即至少另一个交易者正在观看这个符号)。如果他们选择看见这些符号，当它们不“积极”或具有相对方存在时，以比所述其他两种颜色不太显眼的第三种颜色来表示它们，因为不立即需要交易者的注意；在所述优选实施例中，GUI 20在所述积极和相对方存在矩形的旁边的灰色矩形中提供了被观看的符号。
网络服务器110优选地提供让远程客户访问系统服务的API。所述API优选地使得用户能够在使用任何交易服务之前通过基本的验证(用户名密码)来打开会话。在一个替代实施例中，客户使用证书来验证其本身。优选地通过SSL会话来进行用户凭证(credential)的交换，其中SSL会话使用网络服务器公共密钥来交换加密密钥。一旦验证了用户，则所述会话映射到用户的身份。
网络服务器API优选地提供下面的函数。
●获得部门列表每个公司可以选择性地具有通过部门或其他证券分组形式而布置的证券。可以针对每个客户公司配置所述证券分组。该API返回与客户的公司和组名相关联的证券的列表。
●获得证券列表所述系统具有被配置的证券的列表。这个功能返回那个列表。所述列表的每个元素是符号、公司名称和部门。
●设置和获得交易者默认值所述系统使得客户能够存储默认参数。下面的列表不意欲是穷尽的，而是包含特别感兴趣的一些交易者默认值；其他对于本领域的技术人员将是显然的。
○默认下单量。订单输入对话框将默认地使用这个符号的最小数量(大巨额证券数量)或者使用交易者的总票据大小——如果这个交易者使用票据的话——来填充数量字段。
○默认价格。所述订单输入对话框将使用经由下面的规则之一而选择的限制价格来填充价格字段NBBO的积极端、NBBO的消极端、NBBO中点、BPR的积极端、BPR的消极端或BPR中点。
○默认TIF。订单输入对话框将使用这个秒数来填充有效时间字段。
○默认观看列表管理(证券，部门)。所有观看列表管理被前端处理，并且被保存在服务器上。
○默认钉住(Peg)和偏移。订单输入对话框将默认地选择或不选择钉住选项，并且如果选择的话，则它对于购买订单增加这个百分比数量来作为钉住偏移，或者对于销售订单从中点钉住价减去这个百分比数量。
○仅仅票据化订单。这个选项确定是否交易者希望针对通过票据而保留的大小来检查订单。如果不选择这个选项，则即使在没有对应的票据时，交易者也将能够输入订单。
○设置和获得部门观看列表保存和检索组成部门或其他组的证券的列表。
○设置和获得符号观看列表保存和检索在给定的观看列表中的证券的列表。
●设置和获得GUI默认值○票据管理格栅(Grid)用于在显示票据列表的窗口打开或隐藏的情况下启动应用程序的选项。
○票据管理格栅定义字体、字段顺序、列大小、列类型、首标和字段＝列映射。
○积极符号列表(打开或关闭)。用于在显示积极符号列表的窗口打开或关闭的情况下启动应用程序的选项。
○颜色改变(是，否)GUI优选地允许用户选择这个选项，以便当订单已经被提交到系统并且任何字段已经被编辑时，加亮在订单输入对话框中的订单的这个字段。当已经编辑了一字段时，用户可以按下“替换”按键以经由取消/替换订单消息来向所述系统发送新值。加亮已经被编辑的字段有助于用户管理订单。
●获得心跳间隔。用于确定是否在GUI 20和网络服务器110之间的连接是有效的周期性心跳的秒数。所述系统优选地向这个参数施加下界，以避免由于连接管理职责而使网络服务器110过载。在一个替代实施例中，所述参数可以仅仅在服务器上被设置，并且不经由API被提供。
●获得票据获得用户的票据。在交易日内，用户只能具有每个符号/交易方一个票据。如果取消所述票据，则大小递减到未被执行的大小。具有相同符号和交易方的新票据替换在列表中的条目。
●获得订单获得所有订单的列表。
●获得订单状态。返回ClientOrderID的订单细节。
●提交新订单将新订单排队到系统中。将跟随有OnOrderUpdate或OnOrderReject事件的异步调用。
●替换订单这个函数将替换订单请求排队。调用者使得订单状态在返回时为“挂起的替换”。将跟随有OnOrderUpdate或OnOrderReject事件的异步调用。被替换的订单细节与新订单细节+OrigClientOrder ID字段相同。数量是包括被填写的大小的总数量。
●取消订单这个函数将被取消的订单请求排队。调用者使得订单状态在返回时为“挂起的曲线”。将跟随有OnOrderUpdate或OnOrderCancelled事件的异步调用。
●执行交易。这个函数请求向发起经纪人报告这个交易以建立分配处理。这将在交易日的末尾被自动进行。
●获得针对(ClientOrderID，Symbol或全部)请求/响应的交易以检索交易细节。优选地有这个请求的三种版本。获得针对订单的交易，针对在证券中的所有订单的交易或针对这个GUI客户的所有交易。
下面是API事件-即由系统产生和通过API推送到GUI 20的消息。
●OnTicketUpdate在新的、替换的和取消的票据事件时引发这个事件。
●OnOrderUpdate在订单状态改变时引发的事件。这包括对于上面请求或通过其他渠道的订单管理响应。
●OnOrderReject响应于在这个会话中输入的新/替换订单请求而引发事件。
●OnCancelReject当拒绝取消请求时引发事件。
●当在通过这个API或其他渠道输入的交易者订单之一中有交易时，引发OnTrade事件。
网络服务器110的优选实施例还提供了用于预订每个证券的市场数据的接口。字段包括(NBBO买方出价、要求和记录带时间戳(TapeTimeStamp))、(BPR低和高)、巨额证券记录带(最后和总的数量)、积极符号、相对方存在、证券状态(打开、关闭、暂停等)和时间戳。在这个接口的优选实施例中提供的功能是●预订请求/响应这个功能优选地向客户的预订列表增加在请求消息中提供的证券的列表。所述请求针对所请求的字段返回那个条目的当前数据的快照。对于被观看的字段的后续改变将引发具有所述改变的更新事件(OnUpdate)。
●退订请求/响应去除预订请求。
●OnUpdateEvent向预订者通知在预订条目中的字段改变。
●开始积极符号馈送请求/响应返回其中设置了积极符号标志的所有符号的列表。在调用之后，积极符号标志改变中的所有状态改变将导致OnActiveSymChange(符号，打开/关闭)。
●停止积极符号馈送请求/响应终止上述事件通知。
●OnActiveSymChange事件向预订者通知积极符号标志改变。
研究数据存储。所述系统优选地存储允许操作员和研究人员评估当用户输入订单时在符号中的交易者行为的指示符如何与填单率相关联的信息。这个信息通过市场化媒体和对交易站的参观而在引导系统的使用朝向导致更大成功的工作流发展中扮演了重要的角色。例如，如果在未被观看的证券的订单的输入后的填单率极低或空，则交易者可以被告知将在系统上的他们的交易聚焦在由其他交易者观看的证券中。所述系统优选地还可以被再配置成修改何时发出标志的规则以改善系统中的填单率。例如，如果确定在存在三个或更多的观看证券的交易者时填单率比两个时显著更高，则可以重新配置所述系统，以仅仅当GUI用户的总数是三个或更多而不是二个或更多时发出被观看的符号消息。上述的示例意欲用于说明性目的，而不是提供穷尽的列表；基于上面给出的参数的修改的其他优化对于本领域的技术人员将是显然的。
交易者行为度量可以在帮助台上获得，并且在每天的末尾被导出到永久数据仓库以离线分析，以便找到在可能的系统配置设置和较高的填单率之间的关联。
感兴趣的度量是●订单行为(输入，BPR积极性改变；取消/过期)●填单
●票据●可以看见符号积极标志(在观看列表上，作为符号或作为部门的一部分)的交易者的数量●可以看见BPR更新的交易者(预订者)的数量●可以看见报价更新的交易者(预订者)的数量下面的数据表(A-D)以标准的逗号分界(CSV)格式被存储。
表A.票据表

表B.订单表

表C.交易表

表D.观看列表

分析服务器在所述优选实施例中的分析服务器160通过下述方式来跟踪国家最佳买方出价和卖方索价价格通过监听卖方报价馈送60，并且当产生最佳价格的报价被取消或者被具有更好价格的新报价来改善时，更新所述NBBO价格。优选地使用本领域的技术人员公知的方法来在高速缓冲存储器中存储当前的NBBO价格。除了NBBO价格之外，分析服务器160根据近来的报价和交易数据来计算巨额证券买方出价和巨额证券卖方索价。
分析服务器的主要功能是产生下面的消息●NBBO价格改变。
●巨额证券价格范围更新。
分析服务器将存储所有被支持的证券的、全天的最后销售数据和内部买方出价或卖方索价的所有改变。在表格E和F中描述了需要被存储来分析的数据。
表E.内部市场价格更新


表F.最后销售

每当在内部市场最佳买方出价价格或最佳卖方索价价格中有改变时，分析服务器160向所有连接的客户递送报价更新消息。所述更新消息承载新的买方出价价格或新的卖方索价价格和与改变这个买方出价或卖方索价的报价的出现或去除相关联的时间戳。
分析服务器160优选地还每60秒更新BPR，并且向订单管理器130发送BPR更新消息以用于确定其订单的价格积极性，并且向网络服务器110发送所述BPR更新消息以用于向GUI客户20广播。
所述优选实施例包括可替换的模块，它负责计算BPR。可以使用本领域技术人员公知的方法来计算BPR，诸如通过使巨额证券买方出价等于国家最佳买方出价减去百分之五以及使巨额证券报价等于国家最佳报价加上百分之五。在另一个示例中，与股票的历史变动性成比例地设置要加到NBBO价格(从NBBO价格减去)的百分比数量，以便对于诸如技术问题之类的很变动的符号，变化可能大于百分之五，而对于诸如蓝筹股公用事业股票之类的更稳定股票，它将更小。
在本发明的所述优选实施例中使用的算法分别考虑在过去60秒中已经交易的最高和最低价格H和L以及当前的NBBO中点价格M，并且通过下面的步骤来计算巨额证券买方出价和巨额证券卖方索价[图9]●步骤910。确定如上所定义的给定证券的价格H、L和M。
●步骤920。通过往回查看最后的销售数据直到最后BPR更新的时间戳，找到与当前的NBBO中点最远刊载(print)的交易。设X表示在这个交易价格和当前的NBBO中点之间的绝对价格差。因此，X是H-M和M-L中的较大者。
●步骤930。设Z＝Y+(MaxBlockSpread/2-Y)*(1+1/(1+exp(-BETA*X))，其中，Y是对于每个证券设置的参数，用于对巨额证券买方出价和最佳卖方索价之间的差价设置下界，MaxBlockSpread是在所述差价上的上界，并且BETA是可以被例如设置为10.0的参数。
●步骤940。将巨额证券买方出价计算为等于M+Z，并且将巨额证券卖方索价计算为等于M-Z。
●步骤950。向订单管理器130和网络服务器110发出BPR更新消息。
信用管理。所述系统优选地使得发起经纪人能够设置在他们的客户的账户上的信用限制。在所述优选实施例中，根据总的美元限制来进行信用检查，计算所购买的股份加上所销售的股份的总值。将根据BPR的顶端或订单的限制价格的较大者来对于订单验证信用，并且根据当订单被完全地填写、过期或取消(对于部分填单)时所消耗的实际信用量来调整信用。
●经纪人将被提供用于管理信用的万维网帐户；他们可以查看由客户当前消耗的信用的级别，但是该信用级别仅仅被如下分级小于25％、25-50％、50-75％、大于75％。
●经纪人必须能够以瞬即效应来提高今天的信用；或者，他们可以在每个交易日的开头提高或降低发生刷新的信用量。经纪人还可以暂停信用；这具有对于日内和随后日子的效应。如果暂停一日的信用，则系统将取消所有的打开订单。
●经纪人可以以后对客户结束暂停信用。暂停具有永久的效应，并且持续到下一日。在一天的末尾刷新信用。
●经纪人将能够建立作为总数的百分比(默认值＝75％)的信用警报阈值；另外，每当可用信用降到低于太低而不能利用巨额证券系统的系统配置的美元金额MinCreditAmount(例如，二百万美元)时，所述系统将产生警报。信用警报将被递送到帮助台人员，并且被推送到客户GUI。
帮助台。所述系统优选地提供由处理来自客户的调用(call)的人员使用的帮助台界面。这个用户界面可以是万维网浏览器界面，并且通过公共密钥加密和基于证书的验证以及用户名和密码对来进行安全的访问。所述界面优选地使得用户能够观看关于订单的生命的详细信息。用户可以使用给定的符号和客户ID来拉出订单的列表以定位客户正在调用的订单。所述帮助台界面使得其用户能够点击感兴趣的订单，以便按照时间顺序来查看下面的消息。
●票据——如果适用的话。
●订单输入请求。
●订单输入响应被拒绝(具有原因代码)；执行挂起；过期；打开。
●填单；●针对订单发送的相对方存在标志。
●修改订单请求和响应(被接受，被拒绝)。
●取消请求和响应(被接受，被拒绝)。
●过期。
另外，帮助台操作员能够看见在订单的生命中的每个重要事件(输入，取消，执行)时的NBBO内部价格、分别在买方出价和卖方索价方看见的最近报价的时间戳、BPR价格和时间戳。这用于回答诸如为什么当输入订单时符号改变或不改变到积极状态等的问题。
在一个替代实施例中，帮助台操作员不能查看任何订单的符号或交易方，以降低与知道机构客户的交易意向的交易者相关联的安全风险。在这个实施例中，帮助台操作员通过下述方式来识别调用者的订单通过拉出与交易者相关联的订单的列表，其中具有每个订单的输入时间和大小，以及在交易者的GUI 20上也是可见的ClientOrderID。帮助台操作员与交易者合作来识别他或她正在查询哪个订单，然后通过点击订单以查看对应的行为轨迹而如上所述进行。
在所述优选实施例中，帮助台还使得其操作员能够从下拉列表选择客户，并且查看与交易逻辑相关联的他们的配置。下面的列表向帮助台操作员提供更重要的用户配置和使用统计；所述列表不意欲是穷尽的，其他可以被本领域的技术人员容易地理解。
●信用限制和所消耗的信用。
●交易者的行为订单的数量、交易股数、交易美元。
●交易者列表；选择一个来查看和编辑交易者选项。
●观看列表管理(增加/去除符号，增加/去除工业组)。
●示出/不示出积极符号条●示出/不示出票据的下拉列表。
●默认的票据属性。
所述优选实施例也使得经纪人能够使用对于帮助台操作员的同一验证和安全模型来访问网页。经纪人将使用这个页面来用于信用管理目的。为了保持客户的保密性，该界面优选地以不披露客户的交易细节的方式来限制被显示到经纪人的信息。在这个实施例中，经纪人可以仅仅以总信用限制的百分比来查看由客户消耗的信用量；例如，这个可以被分级为四个间隔小于25％、25-50％、50-75％和大于75％。另外，使得发起经纪人能够通过下面的功能来修改客户的信用。
○增加日内的信用。
○增加今天的信用，并且还提高随后日子的刷新量。
○随后日子的较低刷新量。
○暂停信用。
○结束暂停信用。
在一个替代实施例中，立即向发起经纪人报告所述交易，并且发起经纪人能够查看所执行的交易以及所消耗的信用的精确数量。在另一个替代实施例，发起经纪人还可以查看交易前的行为。
系统配置界面。所述系统优选地使得操作员能够在间断时间系统维护时间表期间修改配置，并且增加/去除客户或发起经纪人。
所述系统配置界面使得系统操作员能够增加客户，并且设置所需要的配置属性以使得用户能够交易。新客户公司必须从可用经纪人的列表选择发起经纪人。所述发起经纪人优选地对于在同一公司内的所有交易者是唯一的。在一个替代实施例中，同一公司可以使用多个发起经纪人，并且GUI 20让交易者在订单输入时选择发起经纪人。新公司可以选择性地建立直接到FIX服务器120或通过发起经纪人95的FIX通信。在后一种情况下，发起经纪人代表其本身而从客户向FIX服务器120转发FIX消息。公司可以根据其工作流要求而选择两种模式的FIX连接可以建立FIX通道以仅仅接收执行，或接收执行和订单更新。可以建立它们以输入票据和针对通过票据而分配的大小来检查GUI输入的订单，或者不使用票据而工作。当向系统增加客户公司时，帮助台人员将请经纪人建立客户账户的任何信用限制，并且与用于一日末尾报告的客户ID一致。优选地要求新用户来在系统上配置GUI/API访问以能够交易。在一个替代实施例中，还经由FIX接口而支持订单输入，并且不要求用户使用GUI 20或API访问。
优选地，系统配置界面也使得系统操作员能够向所支持的经纪人的列表增加发起经纪人。在一个替代实施例中，所述系统由单个发起经纪人操作，并且不能通过第三方经纪人关系而被访问。在配置发起经纪人中，操作员将为发起经纪人创建用户账户，以便如上所述管理他们的客户的账户的信用。诸如电话号码、传真和电子邮件之类的经纪人联系信息必须被输入和存储在系统数据库150中；帮助台人员将利用这个数据来为了信用问题而联系经纪人。为了完成建立新发起经纪人的过程，优选地执行下面的步骤。
●经纪人必须建立FIX连接以接收所有执行的完结拷贝。如果经纪人也被用作客户的OMS的服务机构并且代表客户发送票据，则这同一连接也将用于到客户的FIX连接。
●建立包含每个交易的细节的、来自系统的一日末尾的文件传输，包括每个交易的购买方客户的身份。
●可选地，使用销售方交易细节来在一日的末尾建立向经纪人的结算公司的一日末尾的文件传输。
还使得操作员能够增加或去除来自被支持用于交易的证券列表的证券。所述证券优选地与本发明特有的参数值相关联，诸如大巨额证券数量和由分析服务器160用来计算巨额证券价格范围的参数。在下面的表中给出了证券的一组必需字段的示例。


系统操作。在所述优选实施例中的系统优选地包括操作控制台，用于提供服务器、网络硬件和交易的集中管理。用于支持所需要的功能的操作软件在最小地提供了下面的特征的版本上可购得●实时显示所有服务器统计●问题总结●问题解决反馈●远程管理/监控●智能通知系统(警报)●警报显示、确认和注释●可听见的警告●日志记录●在线帮助操作员控制台使得系统操作员可以执行下面的远程操作●系统启动●系统重启●系统关闭●系统部件重启●系统部件关闭●系统部件启动●系统备份●数据库备份●内部一日启动/关闭●一日末尾复位●执行一日末尾的批处理所述系统另外使得操作人员能够在一日的末尾产生每日的使用报告，并且从它们提取用于开账单、研究、结算和OATS报告的必要信息。
操作人员优选地还使用系统操作工具来创建结算总结，它包含具有交易双方的经纪人ID的交易列表。与发起经纪人及其结算公司相关联的交易总结包含所有的交易，其中，至少给定的经纪人发起了所述交易方之一。
所述系统优选地还生成账单报告，其包含涉及发起经纪人的所有填单的列表，以发送到所述经纪人。所述填单应当一对一地匹配日内的执行报告。一日末尾的报告另外包含在日内报告中被屏蔽的客户ID。如果由同一经纪人发起了交易的两个分支，则将在总结文件中有两个填单报告。
所述优选实施例将下述的数据的两个拷贝存储到可移动介质以归档和分析。每当可能时，事件的日志记录包含具有微秒精度的日期-时间戳。
●系统和应用程序日志在每个机器上的应用程序和系统日志被标注和保存。优选地在一日的开始之前复位所述日志。
●配置审计记录固件配置的一日开始和一日末尾的审计的细节(NT注册表、应用程序配置等)。
●ACT消息应当有包含所有ACT消息的细节的独立日志。优选地在一日的开始之前复位这个日志。
●订单和交易订单和交易表在一日的末尾被复制到可移动介质。维护关于订单状态转变的细节的独立日志。优选地在一日的开始之前复位日志和表。
●操作行为影响系统行为的操作员行为被记录。所述记录被标注时间戳，并且包括操作员的身份。优选地在一日的开始之前复位这个日志。
优选地在每个交易日的末尾将所有的系统行为日志和每日报告移动到永久存储器。系统行为日志包含用于构造每个订单和交易事件的交易逻辑和定价的足够信息，包括解决价格争议所需要的时间戳。
优选地将系统配置为在偶然出故障的情况下使用基于下述考虑的处理而自动恢复服务。
●GUI的丢失。GUI 20是Cloud9服务的必需通道。如果网络服务器110检测到丢失了与客户的连接，则在所述优选实施例中，所有的订单被自动取消，并且系统使用具有被取消的订单的任何交易者的电话号码向帮助台人员产生警报。GUI 20将订单状态示出为“取消挂起”。在重新连接时，订单状态被更新为“被取消”。交易者可以拉出由于连接故障而被取消的订单的列表，并且重新激活这些订单；所述系统将它们当作新订单，并且相应地处理它们。在一个替代实施例中，使得用户能够选择一种配置，其中，他们的订单在丢失与GUI的连接时将不被取消；在这个实施例中，用户将调用帮助台以当不能恢复连接时取消订单。
●FIX的丢失。FIX连接丢失优选地不导致订单的取消，因为FIX不是通过其来管理可执行订单的通道。在丢失FIX连接时必须向操作员发出警报。在重新连接时，FIX客户将按照FIX协议要求与服务器重新同步。在一个替代实施例中，可以使用FIX来在系统中输入可执行的订单，并且所述系统支持一种配置，所述配置使得用户能够请求在丢失FIX连接时自动取消他们的订单。
●分析服务器。如果分析服务器160停工，则在所述优选实施例中的所述系统将继续起作用，但是不能获得由帮助器通常实现的功能的益处，诸如新积极符号消息或相对方存在消息。GUI 20还将不能接收报价更新和BPR更新消息。如果分析服务器160不能迅速地返回在线，则系统操作员可以指令将所述系统置于离线状态中，其中，它拒绝任何进一步的订单输入，但是不取消现有的订单。这些解决方案被描述为诸如在本发明中的交易系统之类的交易系统如何处理可靠性问题的示例，但是其他的解决方案容易由本领域的技术人员理解。例如，一种替代的方案是认为分析服务器160是重要的服务，并且在停工时自动将系统离线和取消所有的订单。
●网络服务器、订单管理器和帮助器。这些服务与交易系统的重要功能紧密相关联。因此，在所述优选实施例中，将这些服务的故障认为是致命的；操作员将试图在执行引擎中取消所有的订单，或者当检测到连接丢失时自动取消这些订单。Cloud9系统在检测到这些服务的任何一个出故障时自动进入离线状态。
通过系统管理控制台来不断地监控所述系统的完整性，系统管理控制台在独立的系统上持续地运行，如果在交易日期间的任何时间，所述系统的完整性变得不确定，则所述系统自动切换到离线模式。此时取消所有的订单。拒绝所有的另外订单，直到所述系统返回到全工作状态。
系统施加的符号积极标志在一个替代实施例中，所述系统自动地在所宣告的时间将所有的被观看证券设置为积极状态，并且在15分钟的窗口内将这些符号保持积极。例如，所述系统可以在11:50将所有被查看的符号设置为积极状态，并且将它们保持积极直到12:05。这个采用积极窗口的替代实施例有助于帮助将交易者的注意力聚焦于给定的时间，并且允许交易者参加而不会对于发出导致符号变为积极的第一订单感到合意。它还通过限制交易者预期要向GUI 20贡献空间的时间量而帮助交易者管理在它们的工作站屏幕上的空间。最后，通过利用由于POSIT匹配系统的市场化存在因此已经被交易者公知为与巨额证券交叉相关联的调用窗口，这个替代实施例可以利用这样的事实交易者已经用于查看此时的巨额证券交叉机会，并且聚焦于符号在Cloud9中的流动性，其中多个交易者正在观看GUI 20。
在积极窗口终止时，符号的积极行为状态返回到基于所述优选实施例的描述而将呈现的状态。因此，如果在所述积极窗口终止时，对于给定的符号在所述系统中有打开或近期取消的订单，则所述符号将保持积极；未看见订单行为的其他符号将返回到“被查看”状态。只要符号保持在积极状态中，则交易者可以连续地发出新订单，其中这个操作不导致符号改变行为状态。对于流动性很强的符号，这会潜在地导致符号保持处于积极状态到交易日的末尾。在这个模式中，所述系统将通过相对方存在标志而使交易者聚焦于价格上，但是对于在时间上聚焦，则没有进一步的需要。
被观看的符号标志在一个替代实施例中，所述系统如同在所述优选实施例中那样，但是另外当至少两个交易者观看符号时向用户指示。如果所述符号在他们自己的观看列表上，则当有至少另一个交易者感兴趣于所述符号时，他们将看见。例如，在交易者的观看列表上的被观看符号出现在用户界面的顶部上的灰色框1020中，这类似于橙色积极符号标志1005和黄色相对方存在标志1010，如图10所示。
其目的是向交易者提供提高填单的可能性的条件信息。当符号被观看时，填单率将预期更高，因为至少一个交易者将在订单输入时看见符号变得积极。
当然，在他的或她自己的观看列表上具有被观看符号的交易者可以总是简单地通过从他的观看列表去除所述符号而发现是否除了他之外还有一个或两个另外的交易者。为了使得系统更加用户友好，一个替代实施例还在这种情况下向交易者示出是有一个另外交易者还是有两个另外交易者正在观看。这可以通过在被观看的符号名称旁边的星号来完成，以便指示何时仅有一个另外交易者正在观看。
在一个替代实施例中，所述系统向用户示出在任何时间观看这个符号的交易者的数量。
在计数正在观看证券的交易者的数量时，系统优选地查找实际上能够看见积极符号标志的交易者。在一个实施例中，这是通过仅仅计数未被最小化和没有被检测为隐藏在另一个应用程序后面的GUI来实现的。例如，当接收到新积极符号或相对方存在消息时，在交易者的屏幕底部的托盘(tray)中的最小化条将以橙色或黄色闪动，并且示出与最近的这样的消息相关联的符号。
在另一个替代实施例中，不显示观看这个符号的交易者的数量，但是交易者可以在输入订单时知道观看的交易方的数量。在其中交易者不知道是否符号被观看直到提交订单的这个替代实施例中，交易者还可以检查“自动取消”框以请求如果没有其他的交易者正在观看符号则自动取消他的订单，因为在这种情况下没有人能够看见积极符号标志并且填单率将非常低。在另一个替代实施例中，使得交易者能够选择应当正在观看的交易者的最小数量，并且如果观看交易者的实际数量更少，则自动取消订单。
具有系统生成的调用(call)的替代实施例大巨额证券交叉系统的公知问题是大购买者和大销售者同时输入订单的低可能性。本发明的大部分涉及在第一交易者已经输入订单后解决这个问题，但是它本身不提供关于何时应当最大激励这个第一参与者发出订单的指南。
在一个替代实施例中，所述系统如上所述操作，并且还产生系统产生的“调用”事件，其将交易者的兴趣聚焦于对于证券存在购买和销售意向的指示的时候。在另一个替代实施例中，不发送积极标志，并且所述调用仅仅是时间聚焦事件。优选地经由一种算法来调度所述调用，所述算法确定何时填单的可能性最高。优选地不使用未结算的交易信息(诸如在没有任何销售者的情况下披露购买意向的存在)，以便避免感知到信息泄露，由此交易者将感知到他们已经在系统中发出的订单正在引起他们不能直接控制的不需要的信息事件。
所述调用的目的是当填单的可能性最大时吸引来自交易者的订单输入。例如，如果对于给定的证券发出订单的第一交易者的平均填单率是5％，则当对于所述证券打开调用时的填单率可以是10％或15％；相反，当没有调用时的填单率将低于5％；并且与任何调用无关地，对于在随机时间发出订单的交易者来说，整体平均值是5％。
作为最低限度，当在两方都相互缺少交易者时，所述系统将产生调用以聚焦证券的订单输入。下面概述了用于产生调用的其他机会。为了避免信息泄露问题，这些调用将与BPR更新一起而不是与订单输入事件一起被报告。在一个替代实施例中，在半小时中发出它们，以进一步提高交易者的聚焦。

用于产生调用的算法优选地基于下面的原理。
●在订单输入时不被触发。调用将随着BPR更新而被定时。这消除了如果交易者要看见他自己的订单立即引起调用则发生的信息泄露的担忧。
●1分钟最小寿命。一旦已经启动了调用，则它将保持打开长达足够的时间，以使得交易者反应和响应于所述调用。
●两方的。只有在两方都有巨额证券意向的证据才发出调用。这降低了可能的赌博。
●对于订单而言不一定。当在所述系统中没有积极订单时可能产生调用。这再次减轻了赌博问题。
●不公开的规则。再次减轻了赌博问题。而且允许更新算法(在上述规则的范围内)，并且调整其保持合理的调用频率。
优选地可以获得下面的数据以便确定何时应当产生调用。
●具有剩余数量的票据。
●打开订单。
●过期订单。
●交易。
●在记录带上的巨额证券刊载。
●使用异常高的容量在记录带上重复刊载。
用于发出调用的基于规则的方法第一替代实施例利用用于确定何时应当发出调用的基于规则的方案。对于每个符号，与BPR更新处理一起执行行为评估处理。
如果尚未存在调用，则优选地，应用下面给出的规则，以根据在系统(订单，交易等)中和在市场上的行为来确定是否应当调用符号。如果任何布尔规则为真，则将调用所述符号。
如果符号已经被调用、已经被调用至少<60>秒(可配置的全局参数)并且在证券中没有相对方存在标志，则系统优选地去除所述调用。
下面以项目符号列出了导致调用的规则。
○订单被输入和已经过期。以后，在相对方输入另一个订单。在下一个BPR刷新时间，检查是否已经在最后30分钟(可配置的ActiveMaxDelayl)中针对这个符号投出(post)了调用，如果否定，则与新的BPR一起针对这个符号投出所述调用。
○订单被输入和已经过期。以后，在记录带上检测巨额证券刊载(大于10000股或250,000美元，同样地，它们全都是可配置的参数)，并且已经在最后90分钟中针对这个符号投出了所述调用(可配置的ActiveMaxDelay2)。
○自行处理帮助台操作员键入符号，并且点击按钮。
○订单被输入，并且在相对方存在票据。
○在已经在最后<30>分钟内交易的符号中输入订单。
○常驻订单被消极地定价，并且在BPR内的新订单已经到达。
○常驻销售订单在BPR内，并且在记录带上检测到重复的刊载，用于指示对于一巨额证券大小的卖方索价的集体购买。
上述列表意欲用于说明，并且不意欲是穷尽的。本领域的技术人员可以容易地理解可用于识别何时有更大的交易可能性的其他规则。
用于发出调用的计分功能方法具有调用的另一个替代实施例使用计分功能来确定何时产生调用，如下所述。
对于每个符号，与BPR更新处理一起执行调用评估处理。如果在这个符号中当前有调用，则系统计算所述符号的行为分数和阈值，如下所述。如果所述分数超过所述阈值，则系统优选地生成针对这个符号的调用。
如果符号已经被调用，符号已经被调用至少<60>秒(可配置的全局参数)并且在证券中没有相对方存在标志，则所述系统优选地去除所述调用。
所述系统优选地经由两个步骤来计算计分功能。
步骤1通过加上与下面的条件相关联的加权而计算证券的购买方意向和销售方意向。
●OpenOrderCondition(打开订单条件)。当前打开和在BPR内定价的购买(销售)订单。
●PassiveOrderCondition(消极订单条件)。当前打开但是比BPR更消极地定价的购买(销售)订单。
●ExpiredOrderCondition(过期订单条件)。自从符号最后积极以来过期的购买(销售)订单。
●TicketCondition(票据条件)。具有剩余数量的购买(销售)票据。
●BlockTapeCondition(巨额证券记录带条件)。自从符号最后积极以来在Cloud9上的大巨额证券填单。
●MarketPrintCondition(市场刊载条件)。对于至少<BlockQty＝10000>股或<BlockValue＝$250,000>的在记录带上的巨额证券刊载，其在中点之上(之下)被刊载，自从最后的BPR更新以来发生。
●RandomRefreshCondition(随机刷新条件)。自从最后的BPR更新以来的在中点之上(之下)的重复刊载，其中总数量在<BlockQty＝10000>股或<BlockValue＝$250,000>之上，速率超过<LiquidityRatio＝2>乘以证券的平均容量。
●WatchListCount(观看列表计数)。在交易者的观看列表上具有这个符号的所述交易者的数量。
下表给出了加权的合理配置的示例。

步骤2作为购买方意向与销售方意向的乘积计算符号行为分数。
所述系统优选地如下计算阈值。如果从未调用符号，则所述阈值等于0。如果先前已经调用了符号，则这个符号的阈值将等于在这个符号中过期的、自从最后调用以来的时间的指数函数Threshold(阈值)＝MaxThreshold*EXP(-Beta*TimeDelay)参数MaxThreshold和Beta优选地对于每个证券是可配置的。
具有目标积极符号消息的替代实施例在一个替代实施例中，除了积极符号消息不被发送到已经将符号置于他们的观看列表上的所有交易者之外，所述系统如上所述操作；相反，该标志仅仅被发送到已经提供了已证明的交易意向信息的交易者，所述信息指示购买或销售这个证券的大巨额证券的可能意向。例如，这样的已证明的交易意向信息可以是经纪人在每个交易之后而发出的执行报告的完结拷贝，并且选择标准可以是公司已经在最后30分钟内净购买(净销售)至少10,000股的股票。在下面的共同未决的美国专利申请中广泛地说明了其他示例2000年6月1日提交的09/585,049、2000年12月29日提交的09/750,768和在2001年5月31日提交的09/870,845，其中每个的全文通过引用被并入在此。
具有系统提出的匹配价格的替代实施例在上述优选实施例中，交易者本身设置他们的订单上的价格条件，该价格条件将确定执行价格，而无需他们这一方的进一步干涉。
在他们的当前工作流中，机构交易者习惯于向经纪人发送市场订单，并且接受或拒绝经纪人可以提出来用于执行大巨额证券的价格。在这个意义上，可以认为，机构交易者是价格“接受者”而不是价格“建立者”。
电子交易系统具有下面问题输入订单的第一方正在写入其他方可以选择接受或不接受的价格；因此导致不利选择问题，其中，当他们犯错误并且提供了太积极的价格时，他们的价格往往将被接受。通过向第二订单的限制提供长期有效订单改进、或者如果价格交叉则使两者中途相遇来违反价格优先级的企图不起作用，因为这样的规则仅仅使得第二订单以消极订单开始，然后渐进地提高价格积极性，直到在长期有效订单的限制处发生匹配。
下述的替代实施例的目的是通过下述方式来解决这个问题通过使系统生成所提出的匹配价格，它不敏感于系统中的现有订单的价格。
在本发明的这个替代实施例中，所述系统对于限制订单和钉住订单如上所述执行，但是另外使得交易者能够输入新订单类型——在此我们将其称为“市场订单”。市场订单也可以可选地具有绝对限制价格，所述绝对限制价格继而可以被固定或钉住到市场指标，诸如国家最佳买方出价或卖方索价的中点。
将如下处理输入的市场订单。
在接收到市场订单时，如果当前没有相对方订单常驻在系统中，则它仅仅存储市场订单。如果有常驻的相对方订单，则系统将通过在具有统计分布的BPR内的价格来随机地确定可能的交易价格，所述统计分布诸如平坦分布(所述平坦分布是其中在BPR内的所有价格点等同可能地被选择)。在另一个示例中，所提出的交易价格敏感于在系统中的订单，并且用户通过允许系统使用订单信息来确定公平价格而服从于公平仲裁。例如，这样的一个实施例可以根据不平坦而是分段平坦的分布来生成随机的价格，其中两个平坦段在BPR中点之上和之下，以便当在系统中存在比购买订单更多的销售订单时向BPR中点之下的价格给予更大的概率，或者如果有更多的购买者，则反之。例如，可以使BPR中点之下的价格的概率等于P(低于中点)＝1/(1+EXP(Gamma X))，其中，Gamma是诸如2的正数，并且X是在BPR内定价的购买者股数和销售者股数之间的相对差X＝(购买数量-销售数量)/(购买数量+销售数量)。因此，如果有比销售意向更多的购买意向，则X→1，而在相反情况下，X→-1。用于生成价格的方法的这些示例意欲用于说明的目的，而不是作为穷尽的列表；本领域的技术人员可以容易地明白用于生成价格的其他机制。
已经确定了可能的交易价格时，系统将继续按照下面的逻辑来确定在此价格的交易的可行性。
1.如果随机生成的价格在两种订单的限制内，则以这个价格来执行交易，而不需要来自任何一方的进一步输入。
2.如果没有一个订单能够接受所提出的随机产生的价格，则向两方交易者提出这个价格，然后向他们提供其中接受或拒绝该价格的时间窗口。例如，时间窗口可以与BPR刷新时间或最小15秒当中的较长者同步。在这个时间窗口过期时，与新的BPR一起产生新随机生成的价格，并且只要具有在BPR内的双方的订单，则这个处理继续。
3.如果一个订单的限制价格足够积极以接受所提出的交易价格但是另一个订单不是这样，则将向较积极的交易者建议对于交易不足够积极的订单的价格，并且将向较不积极的交易者示出所述随机生成的价格。任何交易者都将不知道他们正在观看的价格是另一个交易者的限制还是随机生成的系统价格。在时间窗口过期时，产生新价格，并且只要具有在BPR内的双方的订单，则这个处理如上所述继续。
在一个替代实施例中，当仅仅一个交易者的限制与系统生成的价格重叠时，这个交易者可以选择接受另一个交易者的限制或向较不积极的交易者提出还价。在这个实施例中，较不积极的交易者没有看见价格，直到第一交易者采取行动或30秒的时间窗口过期。较积极的交易者可以在这个30秒窗口内取消它的订单，而不在任何点向其他交易者披露其存在。如果第一交易者不采取任何行动，则所述系统在30秒后自动地向第二和较不积极的交易者示出系统生成的价格。这个延迟覆盖了向所述优选实施例的常驻订单立即显示相对方存在标志。
竞争存在标志在本发明的一个替代实施例中，所述系统像如同在所述优选实施例中那样执行，但是另外提供一种使得交易者知道何时有购买(销售)证券的竞争的机制，从而诱使他们提高他们的价格积极性，由此还促进发现公平交易价格的处理。
在使用竞争存在标志的第一替代实施例中，所述系统简单地使得已经看见相对方存在标志的、在系统中具有订单的每个交易者知道是否在同一方有其他订单。
在具有竞争存在标志的第二替代实施例中，所述系统如同在刚才所述的第一替代实施例中那样执行，但是另外使得具有基于价格和时间优先级排名的较低匹配优先级的交易者能够看见其他交易者具有更高的匹配优先级；因而使得这个交易者提高他的订单的价格积极性。如果这变为新的最高匹配优先级订单，则其他交易者将继而被允许看见他的价格不再是最佳的。只要在一个环境中在同一方具有多个订单，并且存在一个或多个相对方，这个处理就继续。
工作订单和与第三方执行系统的集成在一个替代实施例中，所述系统如上所述操作，但是另外使得用户能够请求在等待在Cloud9中的匹配的同时他们的订单在市场上工作。
优选地要求请求工作订单选项的用户输入大于最小巨额证券数量的订单数量。附加的大小将以在本领域内被称作“随机刷新”订单的方式、通过自动化处理而被分派以便工作，所述自动化处理自动地将小片断置于常规市场上。今天，可以在市场上获得几个这样的自动化处理；本领域公知的一些自动化处理是随机刷新算法，其在市场上以最佳的价格发出小数量的股，并且每当所述小数量用尽时，生成要以新最佳价格来发出的新小订单。在最小和最大大小之间，例如在500和900股之间随机选择被刷新的数量。在另一个示例中，在几秒的随机延迟后刷新订单。可以购得其他更复杂的算法以通过将其缩小到独立执行的小片断而自动化订单的执行，诸如ITG的Quantex。诸如NyFIX Millennium之类的其他目的地使得完全隐藏的订单能够拦截在到第三市场目的地的途中的订单流。
在此所述的替代实施例还管理在除了Cloud9之外的一个或多个工作订单目的地上的订单。在这个实施例的一个版本中，所述系统将订单划分为几个组块(chunk)，在Cloud9上发出具有大巨额证券数量的订单；将具有系统可配置的数量(例如5000股)的其他订单传送到能够操作订单的外部目的地。每当目的地完成了其巨额证券时，系统确定是否在执行系统中已经发出的数量之外还有剩余的数量，并且如果如此则向已经完成其巨额证券的目的地发送系统可配置的数量或可用的余值当中的较小者。当一个外部目的地已经完成了组块并且没有留下剩余的数量，但是在其他市场目的地上仍然有未完成的巨额证券时，则取消花费了最长时间而没有接收到填单的未完成巨额证券，并且将其重新传送到报告已经完成其巨额证券的目的地。当除了Cloud9上的大巨额证券数量订单之外在任何地方都没有另外的未完成巨额证券时，系统向用户的GUI 20发送消息以通知已经完成了工作订单分量。然后，交易者可以发出另外的股以恢复操作订单，或者将大巨额证券数量本身转换为工作订单。
在这个替代实施例中，当在Cloud9中剩余的数量已经降到低于巨额证券数量时，所述系统优选地去除所述订单而不考虑分配标志。在另一个替代实施例中，在Cloud9中的剩余大小可以降低到低于大巨额证券数量，并且保持订单的效力以保持积极符号标志。在这个实施例中，如果价格要交叉(例如，如果一个订单被钉住到NBBO中点，并且另一个是限制订单)，也已经选择了工作订单选择的第二方可以接收针对这个Cloud9的部分填单。如果两个工作订单的Cloud9限制价格交叉，则所述系统优选地试图拉回被传送到第三方目的地的所有订单，以最大化可以在内部交易的大小。来自这个匹配事件的余值随后被重新分配到外部目的地。在另一个替代实施例中，任何交易者可以检查一个框以指定他们愿意从工作订单上的余值接收部分填单，并且可以可选地指定这样的填单必须满足的最小数量。
在另一个替代实施例中，在可预期填单的目的地发出有倾向(liable)的巨额证券订单的同时，以暂停的状态在执行引擎中发出在所述系统内输入的订单。例如，可以在巨额证券以暂停状态保持在Cloud9上的同时，将所述巨额证券置于POSIT上，以便进行有计划(scheduled)的交叉。所述系统优选地保持在Cloud9上的暂停订单对于积极符号标志而言的效力。在输入相对方订单时，这个替代实施例的系统优选地通过试图取消外部订单而拉回所述倾向(liability)。当这个取消成功(还没有填写订单)时，如同在所述优选实施例中那样发送相对方存在标志。
虽然在此示出和描述的实施例完全能够实现本发明的目的，但是显然地，根据上述描述，多种替换、修改和改变对于本领域的技术人员是显而易见的。这些替换、修改和改变在本发明的范围内，并且应当理解，在此所述的实施例仅仅被示出用于说明的目的，而不是用于限制的目的。
权利要求
1.一种用于帮助在计算机系统上交易证券的方法，包括以下步骤从第一用户电子地接收证券的第一购买或销售订单；确定所述第一订单被合理地定价；向第二用户发送所述证券的合理定价的订单存在的电子通知，但是不向所述第二用户通知所述第一订单的交易方；从所述第二用户接收第二订单，其中，所述第二订单是与所述第一订单相对的，并且在价格上足够地积极以交叉所述第一订单；以及以所述第一订单的限制价格来执行包括所述第一订单和所述第二订单的交易。
2.如权利要求1所述的方法，其中，确定所述第一订单被合理定价的所述步骤包括计算巨额证券价格范围。
3.如权利要求2所述的方法，其中，计算巨额证券价格范围的所述步骤基于近来或当前的市场价格。
4.如权利要求2所述的方法，其中，计算巨额证券价格范围的所述步骤基于所述证券的近来变动性。
5.如权利要求2所述的方法，其中，如果所述第一订单被定价为至少与所述巨额证券价格范围的消极端一样积极，则所述第一订单被确定为合理定价。
6.如权利要求2所述的方法，其中，计算巨额证券价格范围的所述步骤包括预测有可能在第一预定时间段中发生的价格范围。
7.如权利要求6所述的方法，其中，以大致等于所述第一预定时间段的时间间隔来重新计算所述巨额证券价格范围。
8.如权利要求1所述的方法，其中，确定所述第一订单被合理定价的所述步骤包括如果所述第一订单是购买订单，则将所述第一订单的限制价格与国家最佳买方出价相比较，并且如果所述第一订单是销售订单，则将所述第一订单的限制价格与国家最佳卖方索价相比较，其中，当接收到所述第一订单时，确定所述国家最佳买方出价或国家最佳卖方索价，并且其中，由于所述第一订单的限制价格处于所述限制价格所比较的所述国家最佳买方出价或国家最佳卖方索价的预定数量的百分比或百分比分数内，因此将所述第一订单确定为被合理定价。
9.如权利要求1所述的方法，还包括在接收到所述第二订单后，向所述第二用户发送电子相对方订单通知，所述相对方订单通知指示在所述系统内近乎匹配的相对方订单是积极的。
10.如权利要求9所述的方法，其中，所述第二用户仅仅在过去了第二预定时间段后接收所述相对方订单通知。
11.如权利要求1所述的方法，还包括在接收到所述第二订单后，向所述第一用户发送电子相对方订单通知，所述相对方订单通知指示在所述系统内近乎匹配的相对方订单是积极的。
12.如权利要求11所述的方法，其中，所述第一用户在接收到所述第二订单后立即接收所述相对方订单通知。
13.一种用于帮助证券交易的电子系统，包括交易帮助系统；金融信息交换网络，与所述交易帮助系统通信；通信网络，与所述交易帮助系统通信；一个或多个用户终端，与所述通信网络和所述金融信息交换网络通信；以及执行引擎，与所述通信网络通信；其中，所述交易帮助系统包括帮助模块、金融信息交换服务器、事务数据库和分析服务器。
14.如权利要求13所述的系统，其中，所述分析服务器通过将所述订单的价格积极性与所述订单所涉及的证券的巨额证券价格范围相比较而评估从所述用户接收的证券订单。
15.如权利要求14所述的系统，其中，要求所述订单是大于由经纪自营商接收的平均大小订单的巨额证券大小的倍数。
16.如权利要求14所述的系统，其中，所述分析服务器根据近来的市场价格和所述证券的变动性来计算所述巨额证券价格范围。
全文摘要
一种用于帮助在计算机系统上交易证券的方法，包括从第一用户电子地接收证券的购买或销售订单；确定该订单被合理地定价；向第二用户发送该证券的合理定价的订单存在的电子通知，但是不向该第二用户通知该第一用户的订单的交易方；从该第二用户接收第二订单，其中，该第二用户的订单是与该第一用户的订单相对的，并且在价格上足够地积极以交叉该第一用户的订单；并且以该第一用户的订单的限制价格执行包括该第一用户的订单和该第二用户的订单的交易。还描述了一种用于帮助证券交易的电子系统，其包括帮助模块、金融信息交换服务器、事务数据库和分析服务器。
文档编号G06Q40/00GK1853193SQ200480017566
公开日2006年10月25日 申请日期2004年6月22日 优先权日2003年6月24日
发明者亨里·维尔布罗伊克, 弗雷德·J·费德斯皮尔, 约翰·E·洛佩兹 申请人:传送金融集团股份有限公司