專利名稱：保密巨額證券交易系統(tǒng)和方法
技術領域：
本發(fā)明涉及一種方法，用于管理信息以將巨額證券交易(block-trading)意向會聚(focus)到保密交叉書(crossing book)中，并且通過諸如因特網之類的計算機網絡來執(zhí)行巨額證券交易。
背景技術：
在公共證券市場上，市場機構和交易心理對于高效的信息傳播和價格發(fā)現(xiàn)產生阻礙。市場參與者披露關于大的交易意向的決定通常表示在保密性和流動性之間的折衷。在此使用的術語“市場參與者”指的是具有交易證券的能力的任何人或公司；市場參與者的示例包括經紀自營商、機構、套利基金、統(tǒng)計套利交易和其他財產權交易操作以及在電子通信網絡(ECN)上交易的私人投資者。
通過公開地披露例如大的積極的購買意向的細節(jié)，市場參與者承擔了逆反價格作用的風險——其他交易者可能把他的購買意向視作股票比它當前的價格更值錢的指示。具有合法的銷售意向的其他市場參與者和尋求短期交易利潤的市場做成者將“減少”他們的出售(offer)(變?yōu)椴惶e極的出售者)，導致市場價格的提高。還有由于“前跑”(其他市場參與者通過預測由于大的被披露的訂單而導致的價格變動作出的購買行為)而導致的在經驗上可證明的逆反價格作用的風險。
可以通過將大的訂單劃分為許多小部分來在一定程度上保持保密性以避免引起興趣，但是當交易者極其小心地隱藏其存在時，這個過程不能迅速地填單，或者如果當它以較快的速率工作時，關于訂單存在的信息泄露，導致與上述的訂單顯示問題非常相同的效果。
在任何一種情況下，都失去了經濟上高效的交易，因為與傳播信息相關聯(lián)的交易成本太高。
在紐約股票交易場地上交易大巨額證券也被規(guī)則所阻礙，所述規(guī)則被設計來保護表示短期交易意向的場內經紀人的意向和專業(yè)經紀交易商本身的財產權交易意向。場內經紀人可以使用機構訂單來參與，取得與在相對方(contraside)進入的流動性相等的部分，以使用由較大的機構訂單提供的安全網來獲得短期投機位置；或者通過以一美分的更好價格來截取相對方的流動性而進行在機構訂單上的“美分跳躍(penny jump)”，而不是允許它填寫機構訂單。專業(yè)經紀交易商利用包括美分跳躍的各種方法來從關于機構行為的信息提取利潤；不變的是，這些行為導致逆反價格變動和較低的對機構訂單的填寫率。
交易大巨額證券的另一個公知的困難是有時被稱為“購買者的后悔”的問題。當交易者發(fā)出巨額證券并且迅速地將其填單時，所述交易者的自然反應是相信容易填單表示這是一個差的交易決定——或者有非常多的相對方，其余產隨后將價格向相反方向驅動，或者所述巨額證券的價格太具吸引力，導致太快的接受。這種“購買者的后悔”效果使得客戶不滿意，并且不可能在未來通過這同一渠道來發(fā)出類似的訂單，因為迅速填單將被感知為用于提供防止差交易的這種渠道的失敗。
在限制信息傳播的同時匹配交易意向和執(zhí)行巨額證券交易的一種公知的方法由POSIT匹配系統(tǒng)采用。POSIT匹配系統(tǒng)使得可以累積交易意向，并且以設定的間隔來啟動匹配序列。市場參與者在系統(tǒng)中發(fā)出保密的訂單，并且不知道在相同方或相對方上的其他訂單的數量或積極性，直到所述匹配被釋放為止。這種方法沒有提供任何機制來向可能具有幾乎匹配的價格但是重疊的訂單數量的交易者通知他們可以以僅僅他們的價格的小改變來實現(xiàn)交易。而且，通過作為黑箱，它不能提供這樣的信息，該信息將向交易者指示在特定證券中在系統(tǒng)中存在流動性，以便他們將知道撤回他們已經下在其他地方的訂單以參與POSIT匹配。這種方法還不能在系統(tǒng)的參與者對于給定的證券具有比通常更高的意向時，允許廣播可能誘惑交易者輸入訂單的、基于在系統(tǒng)中的行為的信息，這是填單率因而會預期更高的指示。它也不能提供參與者在他的或她的選擇時啟動交易的能力。通過中途對所有的交易定價，它也不能任何這樣的機制，其中，具有適度大小的巨額證券的耐心交易者能夠從將趨向于逆向驅動價格的更大或更急切的巨額證券訂單獲得更好的價格。最后，它不向市場參與者提供通過可以導致發(fā)現(xiàn)巨額證券交易的公平價格的處理而協(xié)商或以其它方式積極參與價格形成的能力。
試圖管理用于幫助巨額證券交易的信息的另一種系統(tǒng)是LiquidNet交易系統(tǒng)。這種系統(tǒng)的用戶直接地從他們的訂單管理系統(tǒng)提供關于他們的交易意向的數據。當用戶指示匹配已經在系統(tǒng)中表達的相對意向的意向時，所有匹配的用戶接收進入協(xié)商會話的邀請。如果這個邀請被接受，則交易者被預期可靠并且以良好的信譽來協(xié)商交易；使用所述系統(tǒng)但是不能以良好的信譽來協(xié)商和達成交易的那些交易者從系統(tǒng)中被逐出。在LiquidNet系統(tǒng)中，交易者在任何人已經進入協(xié)商之前就知道了相反意向的存在；雖然這種泄露有用于誘使交易者進入協(xié)商過程，但是它也向可能或可能不具有對于交易的確定意愿的多方泄露了關于在參與者的訂單管理系統(tǒng)中的訂單的信息。因此，所述系統(tǒng)依賴于網絡成員的“公平操作”，這限制了參與具有相似目的的機構的鄉(xiāng)村俱樂部。這不能提供這樣的一種系統(tǒng)，其中，具有交易意向的一方僅僅可以被披露到以合理的價格在所述系統(tǒng)內具有確定的、以電子方式可執(zhí)行的相對訂單的多方，并且通過這個規(guī)則，允許具有不同動機和交易層次的多方包括銷售方公司和套利基金的參與。LiquidNet信息管理模型由于泄露了關于沒有確定的交易傾向的參與者訂單的一方的信息而未能實現(xiàn)在對于保密性的需要和對于共享某些信息以便及時地聚焦(focus)巨額證券意向的需要之間的適當平衡，這可以通過下述手段來實現(xiàn)，所述手段向交易者指示在系統(tǒng)內有交易意向而不披露具有所述意向的一方，直到交易者已經被暴露為具有確定的交易傾向。它也不能提供防止可由巨額證券交叉(crossing)系統(tǒng)實現(xiàn)的賭博的保護，其中，發(fā)現(xiàn)具有第二參與者的訂單的一方的唯一手段是發(fā)出積極競價的大巨額證券訂單，所述巨額證券訂單然后很可能被執(zhí)行。由于允許所有大小的訂單，因此LiquidNet系統(tǒng)也不能提供對購買者的后悔問題的解決方案，其中，很容易地完全填寫大訂單的購買者以后害怕相對方具有更大的出售訂單，其余值有可能使得價格下降。
Harborside Plus提供了另一種系統(tǒng)來用于根據交易意向信息的管理而幫助巨額證券的交叉。在Harborside系統(tǒng)中，當交易者感興趣于以當前的中間價格來購買或銷售至少25,000股的股票時，請求交易者被要求向他們的數據庫中發(fā)送意向指示。這些意向指示被電子地存儲，并且在依賴于客戶的交易風格的特定數目的分鐘后失效(例如，套利基金或經紀人趨向于迅速地交易，因此他們的指示將在僅僅幾分鐘后失效)。當在證券的雙方中有IOI時，通過彈出式窗口來通知銷售交易者，銷售交易者將繼續(xù)召喚客戶來達成交易。交易者的調解意欲保證該系統(tǒng)不被當事實上沒有交易意向時卻將輸入IOI的那些交易者濫用，因為對關系的損害將使得這個交易者不太可能在未來將被再次召喚。這個系統(tǒng)不期望下述的交易系統(tǒng)，其中，通過要求交易者輸入確定的、電子可執(zhí)行的訂單而自動地強制公平行為，所述訂單可以或者在到達時被執(zhí)行，或者在所述訂單的擁有者接收回關于其他交易者的意向的任何信息之前被暴露從而在這種系統(tǒng)中的任何另一方執(zhí)行。它也不能提供用于自動化由所述銷售交易者執(zhí)行的協(xié)商處理的任何手段。因為涉及銷售交易者，因此它不能提供交易者從計算機系統(tǒng)期望的匿名，其中，使得交易者能夠直接地彼此協(xié)商，而不向可能或可能不被完全信任的第三人泄露信息。最后，Harborside系統(tǒng)不能期望這樣的機制，當存在僅僅一方的交易意向的證據時，其誘使其他交易者表達他們的證券交易興趣。最后，它不能期望下述可能性表示關于一方的交易意向的信息而不披露該方，以便聚焦此時的對所述證券的意向，而不向沒有表達確定的交易傾向的多方泄露影響價格的信息。
試圖管理信息以幫助巨額證券交易的系統(tǒng)的第四個示例是LiquidNetTracker設施，它被納斯達克股票市場部署，并且是共同未決的美國專利申請第09/870,845號的主題，美國專利申請第09/870,845號的全文通過引用被并入在此。LiquidNet Tracker使得用戶能夠輸入對于交易的確定訂單，并且向可能的相對方示出關于這個訂單的信息。在LiquidNet Tracker系統(tǒng)中，使用對于納斯達克參與者通過自動化確認和交易(ACT)系統(tǒng)提交的結算信息的實時訪問來識別相對方。通過選擇性地僅僅以可能的相對方為目標，意欲避免向能夠在機構訂單上領先或者以其它方式濫用此信息來獲得短期交易利潤的其他交易者泄露信息。但是，因為Liquidity Tracker系統(tǒng)僅僅選擇相對方，因此，信息接受者將知道第一參與者是購買者還是銷售者，即訂單輸入參與者側未被保密。這個信息的一些接受者可能被誘使停止或者甚至反轉它們的交易方向而不是接受訂單，以希望以后看見更好的價格。雖然通過選擇目標而帶來的保密性級別適合于比可以在公共賬簿(book)上顯示的訂單稍微大的訂單，但是有這樣的情況其中，具有較大機構巨額證券的交易者將對于這個保密性級別感到不合意。
在這個環(huán)境中，非常需要一種保密的交叉系統(tǒng)，它使得用戶能夠發(fā)出將不被示出給任何人的訂單，但是將仍然引起可以幫助將交易者在同一證券上同時聚集在一起的信息事件。
為了是有成果的而非破壞性的，在交易協(xié)商過程中的信息事件應當避免兩個問題1.偏好泄露問題。一旦交易者已經顯示了對于購買(銷售)可互換的項目的意向，則看見此意向的其他參與者將提高(降低)他們對于這個項目投下的價值。在公平交易(equity trading)中，示出大購買(銷售)訂單導致其他方修改或取消他們采取相對位置的意圖。另一方面，由于不表達偏好，交易者完全丟失了對于交易的機會。
2.購買者的后悔問題。當購買可互換的項目時，當與預期相比更容易地達成交易時，購買者趨向于假定這可能對于其他方是極好的交易。在公平交易的情況下，當完全填寫了大巨額證券訂單時，交易者將假定相對方的訂單甚至更大，當它在市場上起作用時，其余值將隨后逆向影響價格。這個問題對于迎合大機構的系統(tǒng)尤其尖銳。

發(fā)明內容
本發(fā)明的系統(tǒng)和方法提供了對于上述的機構巨額證券交叉的問題的新穎解決方案。
所述系統(tǒng)的一個優(yōu)選實施例通過不示出交易者意欲交易的方直到最后的協(xié)商步驟來限制交易偏好的披露。在輸入合理定價的訂單時，系統(tǒng)將符號(symbol)設為“積極”狀態(tài)。這向其他參與者指示已經輸入了這個證券的訂單，而沒有披露它是購買還是銷售訂單。
在所述優(yōu)選實施例中，如果價格至少像巨額證券價格范圍(BPR)的消極端那樣積極，則系統(tǒng)確定它們“合理”。根據當前的市場價格、在符號中的近來變動性、以及流動性(liquidity)來計算BPR，并且在圖形用戶界面(GUI)上向交易者示出BPR。在所述優(yōu)選實施例中，通過預測交易者可能在下一個60秒中看見的價格范圍來計算BPR，并且以60秒的間隔來重新計算這個范圍。在一個替代實施例中，“合理”的價格被認為是在訂單輸入時分別針對購買或銷售訂單的、在偏離國家最佳買方出價(Bid)或賣方索價(Offer)的給定數目的百分比(cent)(或其分數)內的價格。
看見符號積極標志并且感興趣于交易同一證券的第二參與者可以選擇輸入訂單。如果它是相對方并且在價格上足夠積極以交叉(cross)第一參與者的訂單，則在第一參與者的限制內執(zhí)行所述交易。
通過要求所有交易者僅僅以大巨額證券數量的倍數輸入訂單來解決購買者的后悔問題。這個數量被選擇得稍微大于通常被發(fā)送到經紀自營商的訂單的通常大小。例如，對于流動性最大的證券，系統(tǒng)可以被配置來使用100,000股的大巨額證券數量。結果，交易者預期在系統(tǒng)中的多數訂單僅僅用于這個大巨額證券數量的一個單位。結果，當交易者接收到在100.000股的訂單上的完整填寫時，這不以任何方式來指示在系統(tǒng)中的相對方的訂單應當被預期更大——很可能它也是100,000股訂單，并且所述完整的填寫僅僅是系統(tǒng)的強制大巨額證券大小的反映。在一個替代實施例中，只能以這個大巨額證券數量輸入訂單，并且在填寫后從沒有余值。在另一個替代實施例中，交易者還承諾在完成交易之后的30分鐘內不在市場上交易，并且同意能夠進行任意的審計，以驗證遵守了自愿的限制，或者當認為需要驗證時如此。
在已經降低了購買者的后悔的可能性的情況下，則有可能使得交易者通過“存在相對方”的標志來當在系統(tǒng)中有近乎匹配的相對方訂單時對此知道。因為兩個訂單的大小很有可能相同，因此關于在兩方存在匹配訂單的信息不指示在不久的將來的任何反向價格變動如果兩個交易者取消了匹配，則他們每個將在正常的市場上交易，并且他們各自的交易將彼此平衡，而沒有凈價影響。因此，存在相對方的信息與下述假設一致當前市場價格是對于大巨額證券達成交易的公平價格。為了避免一些交易者可能僅僅在積極符號上輸入訂單以便看見相對方存在的標志并且然后立即消除的可能性，在所述優(yōu)選實施例中所述的系統(tǒng)讓常駐的(resident)訂單一旦輸入相對方訂單則立即看見相對方存在標志，但是延遲向輸入了相對方訂單的第二參與者示出所述標志，并且如果相對方存在的情況持續(xù)則僅僅在30秒后示出這個標志。這向常駐的訂單提供了30秒的時間窗口，以便通過提高價格積極性來執(zhí)行新輸入的訂單，或者在向第二參與者披露其存在之前取消他或她的訂單。對于常駐的訂單的第一優(yōu)點是激勵了輸入將把符號狀態(tài)設置為“積極”的訂單，由此增強了在系統(tǒng)中的流動性，這繼而將吸引對于獲得所述流動性感興趣的其他交易者。
在一個優(yōu)選實施例中，交易者可以以任何價格來輸入訂單，但是僅僅根據在系統(tǒng)聲明的“巨額證券價格范圍”內定價的訂單來發(fā)出積極符號和相對方存在標志。根據國家市場最佳買方出價或賣方索價和股票的近來變動性來確定所述巨額證券價格范圍，以便提供關于交易者最可能執(zhí)行大巨額證券交易的價格范圍的指南。例如，所述巨額證券價格范圍可以簡單地被取為從國家最佳買方出價減去百分之五到國家最佳買方出價加上百分之五的范圍。如果所有的交易者知道當前的BPR，則他們知道輸入在這個范圍內的訂單將使得向參與者顯示積極符號標志?？匆姺e極符號標志并且意欲購買大宗股票的第二參與者然后以巨額證券賣方索價(BPR的頂部)來輸入購買訂單；如果使得積極符號標志被設置的第一訂單仍然打開(open)并且是銷售訂單，則第二參與者將具有肯定的填單。相反，如果這樣的積極性購買訂單未填單，則第二參與者將知道或者第一訂單已經被取消，或者它也是購買訂單。如果第二參與者相反輸入了消極訂單——例如以巨額證券買方出價來購買的訂單，則那個訂單將很可能在到達時不被填寫，即使在第一參與者是銷售者的情況下也是如此。相反，第一參與者將看見“相對方存在”的消息，并且可能選擇降低他或她的價格以鎖定所述交易。如果第一參與者不采取這樣的行動，則在30秒后，第二參與者將知道引起積極符號標志的第一參與者的訂單事實上是消極銷售者，并且可以選擇提高他或她的價格以滿足其間的合理價格。只要兩個參與者看見相對方存在標志，他們就可以修改他們的價格，直到完成了交易；更急切的交易者將更有可能更快地提高價格積極級別，即使在沒有除了BPR指南之外的任何顯示價格的情況下也導致自然的價格發(fā)現(xiàn)過程。
在所述優(yōu)選實施例中，在相對方存在情況下的交易者不接收關于他們的對方的價格變動的信息；他們僅僅期望將他們的訂單定價在他們所認為的公平價格，并且希望另一方將進行相同的行為。在一個替代實施例中，交易者看見相對方已經提高或降低了他們的價格積極性，并且可以使用這個信息來確定是否值得類似地提高他們自己的價格積極性級別。如果每個交易者繼而以最小百分之一(或其他預設)的間隔來如此，則兩者將大約在原始購買和銷售價格之間的中途滿足。
在圖1中給出了本發(fā)明的優(yōu)選計算機系統(tǒng)實施例的示意圖。
所述系統(tǒng)優(yōu)選地包括交易幫助系統(tǒng)100(在此也稱為Cloud9)。所述交易幫助系統(tǒng)100通過諸如因特網的通信網絡80和諸如FIX網絡90的金融信息交換網絡來連接到參與者。系統(tǒng)100通過賣方的網絡70來從賣方60接收市場數據。參與者通過在每個參與者的工作站中安裝的圖形用戶界面(GUI)來訪問系統(tǒng)。訂單被傳遞到執(zhí)行引擎50。當所述執(zhí)行引擎接收到匹配訂單時，自動交易所述匹配訂單。Cloud9包括網絡服務器子系統(tǒng)110，負責到每個客戶GUI的連接；金融信息交換(FIX)服務器120，用于提供到事務部門(back-office)系統(tǒng)和客戶訂單管理系統(tǒng)的連接；以及，訂單管理子系統(tǒng)130，負責實現(xiàn)在此所述的系統(tǒng)的訂單處理邏輯。幫助模塊140建立意欲將意向聚焦在交易上和驅使用戶進行該交易的信息事件。交易幫助系統(tǒng)100在事務數據庫150中跟蹤其訂單的狀態(tài)。相對于巨額證券價格范圍來評估訂單的價格積極性，這是通過分析服務器160計算的訂單的價格可以是(a)比BPR更消極或(b)積極，意味著價格在BPR內或比BPR更積極。執(zhí)行引擎50通過通信網絡80來接收訂單，并且電子地將它們存儲在事務容錯數據庫(賬簿51)中；它通過這個同一網絡向交易幫助系統(tǒng)100回報執(zhí)行情況。在一個替代實施例中，執(zhí)行引擎50可以作為Cloud9系統(tǒng)100內的附加部件而駐留在本地。
參與者使用圖形用戶界面20來向系統(tǒng)中輸入訂單。當執(zhí)行所述訂單時，使用FIX協(xié)議來向他們的發(fā)起經紀人95和向他們自己的公司的訂單管理系統(tǒng)(OMS)10報告結果以處理。
優(yōu)選的是，要求所有的訂單是“大巨額證券訂單”，這意味著它們的大小必須是大巨額證券數量的倍數。例如，如果大巨額證券數量是100,000，則GUI僅僅允許作為100,000股的倍數的訂單。所述訂單可以是限制的或更好的，或者被釘住到市場指標，諸如在國家市場上的最佳買方出價和賣方索價之間的中點。所有被驗證的巨額證券訂單被立即傳遞到執(zhí)行引擎50，在此，它們被存儲在賬簿51中。在一個替代實施例中，接受任何大小的訂單。
Cloud9和執(zhí)行引擎50優(yōu)選地在先入先服務的基礎上處理訂單。
GUI20使得感興趣于交易給定證券的大巨額證券的交易者能夠點擊在主屏幕的頂部上的框中顯示的證券符號，以引發(fā)訂單輸入對話框，并且按照他或她的預先配置的偏好而自動填充所述訂單輸入對話框的字段。交易者將按照需要來編輯這些字段，并且按下被標注為“提交”的按鈕以發(fā)出訂單。
如果新輸入的訂單匹配先前的賬簿訂單(所述新訂單針對同一證券，但處于相對方，并且具有等于或更好于長期有效(standing)賬簿訂單的價格)，則執(zhí)行引擎50自動地以長期有效訂單的價格來執(zhí)行交易，并且電子地向自動化確認和交易(ACT)40服務報告所述交易以獲得合并記錄帶(consolidated tape)，并且電子地向發(fā)起經紀人的結算公司30報告所述交易。還向圖形用戶界面20發(fā)送執(zhí)行的通知，以通知所述交易的交易者。如果另一方面在所述賬簿中沒有匹配的訂單，則將所述新的訂單保持存儲在所述賬簿中來作為長期有效訂單。在一個優(yōu)選實施例中，客戶可以選擇將它們的訂單由第三方經紀人發(fā)起，在這種情況下，還經由FIX向發(fā)起經紀人的事務部門系統(tǒng)95報告所述交易。
為了提高交易的可能性，所述系統(tǒng)的訂單管理器130連接到幫助模塊140，當新輸入的訂單未找到匹配但是作為長期有效訂單被存儲在賬簿51中時，其自動地采取行動。在一個優(yōu)選實施例中，僅僅被合理地定價的訂單受到幫助；用于交易大巨額證券的合理價格范圍(巨額證券價格范圍)由分析服務器60計算，并且每60秒更新一次地在交易者的圖形用戶界面20上被給出。幫助器140的目的是產生將激勵其他交易者輸入同一證券的訂單的信息事件，而不泄露訂單的價格或交易方。
在一個優(yōu)選實施例中，根據在系統(tǒng)的數據庫150中已知的訂單的狀態(tài)，當幫助器140起作用時，有兩種可能的行動流。
在第一種情況下，當新輸入的訂單未找到匹配時，系統(tǒng)的狀態(tài)是在系統(tǒng)內沒有合理定價的相對方訂單。向預訂這個證券的所有方遞送一個消息，用于指示在所述系統(tǒng)內新輸入的訂單的符號主題現(xiàn)在是“積極的”(如果它已經是積極的，則省略這個步驟)。圖形用戶界面20將在訂單輸入對話框205之上的橙色框215內顯示積極符號，如圖2所示。所述系統(tǒng)優(yōu)選地使得看見積極符號并且感興趣于交易這個證券的大巨額證券的第二參與者能夠通過點擊所述符號而引發(fā)訂單輸入對話框。所述系統(tǒng)優(yōu)選地按照第二參與者的預先配置的偏好來填充訂單輸入對話框205的所有字段。第二參與者在知道所述符號是“積極”的情況下行動。因此，他將明白預先輸入了使得所述符號變得積極的第一訂單，并且這個第一訂單被定價在BPR內。利用這個信息，如果第一訂單處于相對方并且仍然打開，則第二參與者可以選擇以巨額證券賣方索價(巨額證券買方出價)來提交限制購買(銷售)訂單，以必要地保證交易。在一個優(yōu)選實施例中，一旦符號變得積極，則它將保持積極至少60秒；結合BPR更新而檢查符號行為狀態(tài)，并且只有當它已經積極超過60秒并且在BPR更新的預定時間在所述系統(tǒng)內沒有更多的合理定價的訂單當前被打開時，才將符號行為狀態(tài)設置為消極。在一個替代實施例中，所述符號的積極狀態(tài)被實時地更新以反映是否此時在系統(tǒng)中有合理定價的訂單。在另一個替代實施例中，除了顏色之外，GUI還顯示當前在系統(tǒng)內打開的合理定價的訂單的數量。
在第二種情況下，系統(tǒng)的狀態(tài)是在相對方已經有合理定價的訂單，但是它的積極性不足以滿足由新輸入的訂單提供的限制價格。在這種情況下，幫助模塊140將立即向具有合理定價的長期有效相對方訂單的所有參與者發(fā)送一個消息，讓他們知道現(xiàn)在在系統(tǒng)內存在合理定價的相對方訂單。圖形用戶界面20通過加亮在訂單輸入對話框205上部的黃色框225中的符號而顯示“相對方存在”的消息，如圖2所示。使得符號積極的第一參與者將因此看見現(xiàn)在存在相對方。所述系統(tǒng)優(yōu)選地使得所述第一參與者能夠以積極的價格來重新定價所述訂單，并且替換所述訂單以便執(zhí)行第二參與者的訂單。在一個優(yōu)選實施例中，所述系統(tǒng)自動將BPR的積極端(aggressive end)作為默認價格以激勵將導致交易的策略；交易者可以然后按照期望來修改訂單參數。在一個替代實施例中，所述系統(tǒng)使得用戶能夠配置積極訂單類型，以將其限制為BPR或偏離當前國家市場中間價格的可配置百分比數量(或其分數)的較好者，并且這種積極訂單類型因此是在相對方存在情況下的默認類型。在一個優(yōu)選實施例中，用戶通過下述方式而被允許輸入將使得系統(tǒng)試圖執(zhí)行相對方的訂單的訂單點擊具有所述符號的所述黃色框，然后按下被標注用于此目的的單個按鈕。在一個替代實施例中，用戶界面20使得交易者選擇新的價格，并且按下被標注為“替換”的按鈕。如果沒有一個具有長期有效訂單的交易者提高他們的價格積極性，并且在30秒后仍然有長期有效相對方訂單，則始發(fā)相對方訂單的第二參與者將優(yōu)選地也知道在系統(tǒng)內有長期有效相對方訂單。所述系統(tǒng)優(yōu)選地通過黃色框來顯示這個信息，如上對于第一參與者所述；并且所述第二參與者可以選擇提高他的或她的價格積極性以達成交易。所述30秒延遲意欲阻止交易者探測所述系統(tǒng)以發(fā)現(xiàn)是否存在相對方，然后其后試圖立即取消。這個安全機制有效地使得不從當前的市場太遠地去除BPR，以便在30秒間隔期間，新輸入的訂單面對由具有長期有效訂單的交易者之一執(zhí)行的實際機會。在一個替代實施例中，沒有30秒延遲，并且所有交易者被同時通知相對方存在的情況，但是有有效的5秒的最短時間，在此期間，不會取消訂單。在另一個替代實施例中，所有用戶立即接收相對方存在的消息，并且沒有有效的最短時間的條件。在一個替代實施例中，交易者可以配置GUI20，以便當出現(xiàn)相對方存在情況時自動以積極的價格來替換他們的訂單。在這個最后的實施例中，如果在系統(tǒng)內有多個訂單具有自動重新定價指令并且競爭以執(zhí)行同一相對方訂單，則系統(tǒng)按照價格時間優(yōu)先級來執(zhí)行訂單長期有效訂單首先競爭價格來填寫進入的相對方訂單，然后如果兩個訂單具有相同的積極價格限制，則競爭輸入時間，優(yōu)先級賦予所輸入的第一訂單。
用于計算巨額證券價格范圍(BPR)的優(yōu)選算法尋求根據股票的變動性而確定在接著的60秒內交易大巨額證券訂單的合理價格。在所述優(yōu)選實施例中，這個范圍是基于自從最后一次更新BPR起交易已經以其被報告到合并記錄帶的價格，從而從國家最佳買方出價和賣方索價的當前中點上下取對稱價格范圍。這個范圍相對于所述中點上下擴展一個數量，所述數量直接關聯(lián)于自從最近的BPR更新起所觀察的價格變動性。
首字母縮寫詞





圖1是本發(fā)明的優(yōu)選計算機系統(tǒng)實施例的示意圖。
圖2描述了優(yōu)選的GUI，其中打開了訂單輸入對話框。
圖3(a)和3(b)描述了一種優(yōu)選的系統(tǒng)和方法的操作，包括所述系統(tǒng)與參與者和相關聯(lián)的公司的電子系統(tǒng)的交互。
圖4示出了在一個優(yōu)選實施例中的、從結算角度來看的交易的生命周期。
圖5描述了當處理新票據時優(yōu)選地執(zhí)行的步驟。
圖6描述了用于處理取消票據消息的優(yōu)選步驟。
圖7描述了用于處理有效訂單的優(yōu)選步驟。
圖8描述了優(yōu)選的觀看列表配置對話框。
圖9描述了用于計算BPR的優(yōu)選方法的步驟。
圖10描述了優(yōu)選的GUI，其中識別了被觀看的證券。
具體實施例方式
下面是本發(fā)明的優(yōu)選和替代實施例的功能描述。
關鍵特征。下面是本發(fā)明的特征的優(yōu)選列表1.巨額證券的保密交叉。訂單被傳送到匹配引擎，所述匹配引擎將利用價格時間優(yōu)先級來交叉(cross)訂單，并且報告鎖定(locked-in)的交易以結算。所述匹配引擎可以駐留在遠端。
2.大巨額證券數量。必須以對于每個證券配置的大巨額證券數量的倍數來輸入所有的訂單。大巨額證券大小阻止賭博，并且通過激勵用戶使用同一訂單數量而減輕“購買者的后悔”問題或者在完整的填單之后處于錯誤方的擔憂。
3.積極符號標志。當系統(tǒng)確定在證券的雙方都有巨額證券意向時，該系統(tǒng)將使積極符號告警。這將聚焦在短時間窗口中的訂單輸入，由此提高填單概率。
4.相對方存在標志。當輸入近乎匹配的相對方訂單時，將提醒在系統(tǒng)中具有合理定價的訂單的交易者。30秒后，也向具有該新訂單的參與者提醒存在接近的匹配。相對方存在標志聚焦訂單的價格，以最大化交易的概率。
5.到事務部門的FIX連接。Cloud9支持用于直接地或通過FIX服務機構來向購買方訂單管理系統(tǒng)遞送FIX執(zhí)行的機制，支持相對于發(fā)起經紀人的購買方客戶的日末(end of day)匿名。
6.FIX票據應用。多個客戶可以從他們的訂單管理系統(tǒng)投放股份到Cloud9(符號、數量和交易方)共享，然后使用GUI 20逐漸達到所投放的數量。OMS可以被更新以跟蹤獨立的工作訂單，或者僅僅在填單時如此，這依賴于客戶的配置。
7.API/GUI訪問。Cloud9可以提供使用來自機構交易者的輸入而設計的具有自家品牌的交易前端，它顯著地顯示用于感興趣的證券的觀看列表的積極符號，并且當設置了相對方存在標志時向交易者提示達成交易。API也可以被公布以使得被許可的第三方從他們自己的前端建立訪問。
本發(fā)明包括一種優(yōu)選的架構，用于將所述系統(tǒng)與參與者和相關聯(lián)的公司——諸如發(fā)起經紀人或他們的結算公司——的電子系統(tǒng)集成。圖3(a)和3(b)中表示了這種集成的概覽。這些附解了導致在參與者C和E之間的交易的流程，如下所述。在系統(tǒng)中已經有長期有效訂單的情況下，新參與者輸入相對方訂單。系統(tǒng)發(fā)出相對方存在標志；參與者將長期有效訂單修改為較高價格積極性級別，從而導致被執(zhí)行的交易。
所述系統(tǒng)優(yōu)選地通過下述步驟來幫助在上述示例中的交易1.在步驟1中，用戶優(yōu)選地使用圖形用戶界面20來向系統(tǒng)中輸入訂單。
2.系統(tǒng)優(yōu)選地在步驟2中分配記錄的經紀人，并且根據記錄的經紀人和客戶ID來針對任何信用限制而驗證所述訂單。所述訂單信息被存儲在數據庫150中。
3.在步驟3中，訂單管理器130將所述訂單傳送到執(zhí)行引擎50，并且期望從執(zhí)行引擎返回的訂單更新消息，用于指示是否所述訂單在進入時被填寫，被存儲為有效限制訂單，或如果所述訂單無效則被取消。
4.在發(fā)現(xiàn)所述訂單在執(zhí)行引擎中未執(zhí)行或取消時，OM 130向幫助模塊140通知訂單輸入事件。
5.幫助模塊140發(fā)現(xiàn)在系統(tǒng)中有相對方存在；它立即向常駐的相對方發(fā)送“存在相對方”消息，并且在30秒的延遲后調度用于向剛剛輸入新訂單的交易者發(fā)布這同一消息的事件。
6.在步驟6中，向常駐的訂單提供相對方存在的消息。優(yōu)選地，立即完成這一操作。在一個替代實施例中，在10秒延遲后發(fā)送相對方存在標志，以在泄露關于所述訂單的信息之前向第二參與者提供嘗試更積極的價格的時間。
7.步驟7優(yōu)選地發(fā)生在發(fā)送了第一相對方存在消息后的30秒如果相對方存在的情況持續(xù)，則向新訂單提供所述相對方存在消息。
8.在步驟8中，所述常駐訂單，使用服務機構來用于他們到系統(tǒng)的FIX連接的發(fā)起客戶在他們的GUI 200上接收相對方存在標志，并且修改所述訂單以提高價格積極性。
9.在步驟9中，OM 130傳送修改訂單請求，并且更新在OM數據庫150中的所述訂單的狀態(tài)。
10.在步驟10中，OM 130向執(zhí)行引擎50傳遞修改訂單消息。
11.在步驟11中，執(zhí)行引擎50確定新的價格積極性足以鎖定交易，并且優(yōu)選地使用結算對方信息而將這個交易報告給ACT。在一個替代實施例中，僅僅對于記錄帶報告所述交易，并且扣留結算信息，直到當日的末尾以延遲向發(fā)起經紀人通知所述交易的時間。
12.執(zhí)行引擎50優(yōu)選地向訂單管理器130報告所述執(zhí)行；OM 130更新在它的數據庫150中的訂單的狀態(tài)，并且更新所消耗的信用。
13.在步驟13中，訂單管理器130向網絡服務器110和FIX服務器120報告所述交易。
14.網絡服務器110和FIX服務器120向它們各自的客戶轉發(fā)所述執(zhí)行消息。
15.第二客戶通過服務機構來接收FIX執(zhí)行情況。
16.在交易處理的最后步驟中，向發(fā)起經紀人發(fā)送所述執(zhí)行的完結拷貝(drop copy)。在所述優(yōu)選實施例中，這在一天的末尾時進行；在一個替代實施例中，它立即被執(zhí)行，并且直接向發(fā)起經紀人通知他們發(fā)起的所有交易行為。
設施所述系統(tǒng)優(yōu)選地包括下面的設施或子系統(tǒng)1.網絡服務器110。網絡服務器子系統(tǒng)使得客戶能夠通過圖形用戶界面200來訪問系統(tǒng)。優(yōu)選地，這是可以用于向系統(tǒng)中輸入訂單的唯一界面。所有的用戶必須下載交易應用程序(GUI)或者開發(fā)提供了滿意的對積極符號和相對方存在標志的可見性的GUI。網絡服務器110優(yōu)選地支持經由所公布的API而連接到交易者前端。
2.FIX服務器120。FIX服務器是使得客戶可以連接以便按照FIX協(xié)議來交換金融信息消息的計算機系統(tǒng)；在打開源代碼庫中可以獲得FIX服務器的源代碼。Cloud9 FIX服務器優(yōu)選地被配置來接收票據(新建，取消，取消/替換)和訂單狀態(tài)請求消息。它將推出包括訂單更新和填單的執(zhí)行。它優(yōu)選地支持與客戶訂單管理系統(tǒng)的直接連接以及通過服務機構的連接。FIX服務器也可以用于向發(fā)起經紀人遞送執(zhí)行消息(具有“完成”狀態(tài))以在交易處理后建立。通常，這些消息將在一天的末尾被發(fā)出，但是，客戶優(yōu)選地也可以請求系統(tǒng)在需要時向他們的經紀人通知一日內的執(zhí)行情況。
3.訂單管理器130。Cloud9訂單管理器處理訂單和隨后的交易消息，將它們傳送到執(zhí)行引擎以存儲和執(zhí)行。優(yōu)選的是，通過跟蹤何時所述訂單被定價為至少與BPR一樣好或被消極地定價，它從分析服務器160接收BPR更新消息，并且維護在其訂單上的價格積極性標志。
4.幫助模塊140。訂單管理器130優(yōu)選地包括一個部件，其負責通過仔細地發(fā)布關于訂單的信息而幫助匹配訂單進入系統(tǒng)，如在此所述。
5.訂單管理數據庫150。訂單管理器130優(yōu)選地跟蹤在交易和可完全恢復的結構化查詢語言(SQL)數據庫中的訂單狀態(tài)。它還包含報告模塊，其負責報告所述交易以便結算，以及向對應的自我管理組織(SRO)產生每日的強制性報告。
6.分析服務器160。分析服務器160接收數據反饋，用于向所述服務器通知每個符號的市場行為狀態(tài)(開始，停止，交易暫停)、所有的納斯達克和NYSE(紐約證券交易所)列出的股票的內部最佳買方出價和賣方索價(價格、總體大小和時間戳)、來自國家市場系統(tǒng)合并記錄帶的最后銷售交易數據。服務器優(yōu)選地將這個信息存儲到數據高速緩沖存儲器中，并且執(zhí)行分析計算以確定巨額證券價格范圍。它負責向預訂方公布每個符號、內部報價價格變化、BPR更新消息和交易暫停。
7.幫助臺。所述系統(tǒng)優(yōu)選地包括幫助臺子系統(tǒng)，它包括用戶界面，諸如萬維網GUI。幫助臺操作員可以訪問這個界面以增加/刪除/修改與各個交易者相關聯(lián)的客戶公司、發(fā)起經紀人或GUI帳戶。所述幫助臺使得交易操作人員能夠根據訂單ID或通過公司和符號來查詢所述系統(tǒng)，跟蹤隨著客戶的訂單進入系統(tǒng)的事件序列，并且通過所述系統(tǒng)向希望調用幫助臺的交易者提供關于他們的訂單的歷史的詳細響應。
8.系統(tǒng)操作管理。所述系統(tǒng)優(yōu)選地還包括系統(tǒng)操作控制臺子系統(tǒng)，它使得系統(tǒng)操作員能夠管理所有的Cloud9設施的功能實現(xiàn)。除了常見的系統(tǒng)操作職責之外，系統(tǒng)優(yōu)選地還使得操作員能夠執(zhí)行其他的職責，包括安全性；審計；管理一天末尾和一天開始的事件的批處理；容量計劃；以及管理內部帳戶(操作員和幫助臺)的權限。
9.匹配引擎50。匹配引擎50可以是電子通信網絡或諸如納斯達克SuperMontage設施的第三方電子交易書。在一個替代實施例中，所述系統(tǒng)本身包括作為在Cloud9系統(tǒng)中的獨立部件的匹配引擎。下面更全面地說明上述特征的優(yōu)選實現(xiàn)。
FIX服務器。Cloud9優(yōu)選地使用FIX協(xié)議來用于當必要時的事務部門與客戶訂單管理系統(tǒng)10和發(fā)起經紀人的集成。圖4示出了從結算角度來看的交易的生命周期?？蛻魞?yōu)選地能夠在用于使用系統(tǒng)的兩種模型之間選擇。第一模型使用票據來幫助管理多個市場目的地上的傾向(liability)。票據是來自客戶的訂單管理系統(tǒng)的布置(placement)，其幫助交易者對他們在每個市場目的地中處理多少股進行記帳(市場目的地是交易者可以執(zhí)行訂單的地方，諸如本系統(tǒng))。票據的目的是保證在所有目的地上布置的總股數從不超過客戶的整個訂單的全部股數，其為客戶的訂單管理系統(tǒng)10所知道。當交易者使用票據時，已經從OMS輸入的票據出現(xiàn)在GUI 20上，并且可以僅僅針對這些票據來輸入訂單。
優(yōu)選地，如果訂單在同一證券中、在同一方和具有不大于先前輸入的票據的大小，則選擇使用票據的客戶才能向系統(tǒng)中輸入所述訂單。所述系統(tǒng)優(yōu)選地通過當交易者選擇使用票據時執(zhí)行下述步驟來更新事務部門和第三方系統(tǒng)。
1.在步驟410中，向系統(tǒng)100內輸入作為沒有價格的FIX訂單的票據。所述票據承載系統(tǒng)映射到特定GUI的終端ID。交易者看見票據顯示在他的/她的GUI上。
2.在步驟420中，交易者針對這個票據而輸入訂單，我們將所述訂單在此稱為“子”訂單。這個子訂單處于與所述票據相同的證券和一方，并且其數量被選擇為交易者配置的默認訂單數量或票據數量的較小者。所述系統(tǒng)優(yōu)選地驗證所述訂單，并且將其傳遞到執(zhí)行引擎。在所述優(yōu)選實施例中，訂單輸入事件經由Order Status(訂單狀態(tài))＝New(新)的FIX執(zhí)行消息而被報告到OMS。在一個替代實施例中，客戶OMS僅僅當完成交易時接收執(zhí)行消息(參見下面)。
3.當針對這個訂單而發(fā)生交易時，執(zhí)行引擎優(yōu)選地向ACT報告以獲得記錄帶和結算(步驟430)；然后向Cloud9通知所述交易。在所述優(yōu)選實施例中，Cloud9系統(tǒng)然后經由API通知GUI，并且經由FIX通知客戶的訂單管理系統(tǒng)。
4.系統(tǒng)優(yōu)選地使得交易者能夠在交易日的末尾之前啟動分配處理(按照用戶的選擇來執(zhí)行步驟440)。為了獲得日內的匿名，優(yōu)選地不向發(fā)起經紀人通知所述交易，直到一天結束，但是如果不向發(fā)起經紀人通知所述交易者，就不能完成所述分配處理。為了支持一天結束的分配，GUI優(yōu)選地使得交易者能夠首先點擊用于請求系統(tǒng)向發(fā)起經紀人報告所述交易的按鈕。這將使得發(fā)起經紀人的系統(tǒng)預先準備好所述分配處理。在一個替代實施例中，經由FIX執(zhí)行消息而立即向發(fā)起經紀人通知每個交易。
5.在步驟450中，系統(tǒng)優(yōu)選地向執(zhí)行經紀人發(fā)送包括客戶ID的FIX執(zhí)行消息。
6.優(yōu)選的系統(tǒng)在一天的末尾執(zhí)行下述(步驟460)。
a.向執(zhí)行經紀人發(fā)送FIX執(zhí)行消息，包括客戶ID。如果已經在步驟450中發(fā)送了它，則可以復制類似的消息。
b.向發(fā)起經紀人的結算公司發(fā)送交易總結文件。它包含涉及結算的信息，包括符號、所購買或銷售的股份和相對方的MPID。
c.OATS報告以發(fā)起經紀人的名義提供了訂單跟蹤和執(zhí)行的總結。所述系統(tǒng)自動地向發(fā)起經紀人發(fā)送OATS報告以轉發(fā)到NASD。在一個替代實施例中，它直接地向NASD發(fā)送報告。這些文件傳輸是電子的，并且利用文件傳輸協(xié)議(FTP)。
在所述優(yōu)選實施例中，使得用戶能夠選擇不需要使用票據、而是使得交易者可以在訂單輸入步驟420開始所述處理的的替代配置。剩余的流程與如上所述的相同。
在一個替代實施例中，系統(tǒng)100由發(fā)起經紀人駐留(host)用于使用所述系統(tǒng)的所有客戶，并且包括交易處理后的子系統(tǒng)，這可以被本領域的技術人員容易地實現(xiàn)或者通過專門的賣方而購得。在這個替代實施例中，不需要一日末尾的匿名，并且可以立即分派經紀人執(zhí)行報告。
FIX服務器120優(yōu)選地支持用于提供到客戶訂單管理系統(tǒng)10的連接的多種聯(lián)網方案。例如，客戶的OMS可以直接地連接到所述FIX服務器，或者它可以通過FIX服務機構與FIX服務器120通信，其中所述FIX服務機構扇出(fan out)在單個FIX服務器120和多個客戶之間的連接。
FIX服務器120優(yōu)選地當票據無效或當客戶被配置成不使用票據時拒絕票據；票據拒絕消息優(yōu)選地在文本字段中承載可理解的拒絕原因。如果因為訂單數量小于這個證券的大巨額證券數量而發(fā)送拒絕消息，則優(yōu)選地對拒絕消息的消息文本中的信息提供正確的LBQ。在所述優(yōu)選實施例中，F(xiàn)IX服務器120優(yōu)選地支持下面的輸入消息FIX新訂單、取消訂單、取消/替換和訂單狀態(tài)請求。如果客戶使用票據，則輸出的消息優(yōu)選地包括與給定的票據的子訂單相關聯(lián)的訂單更新(承載底層票據的訂單ID的FIX執(zhí)行消息)。不使用票據的客戶優(yōu)選地僅僅接收填單(FIX執(zhí)行消息)。在一個替代實施例中，不使用票據的客戶接收與經由GUI輸入的訂單相關聯(lián)的每個事件的訂單更新消息，其中包括新訂單確認消息，以便OMS可以逐個事件地跟蹤所操作的總體大小以及已經被填寫的大小。
FIX服務器優(yōu)選地支持萬維網配置屏幕，所述配置屏幕使得操作員能夠建立和定制新的客戶連接，而不要求新的軟件發(fā)布。如上所述，F(xiàn)IX購買方客戶優(yōu)選地可以被配置用于(a)僅僅FIX執(zhí)行或(b)支持票據和執(zhí)行報告。FIX發(fā)起經紀人客戶優(yōu)選地被配置成僅僅接收執(zhí)行。在一個替代實施例中，有可能配置發(fā)起經紀人的FIX連接以接收被發(fā)送到發(fā)起客戶的OMS的每個消息的完結拷貝。除了在每個填單上發(fā)送的執(zhí)行消息之外，配置選項優(yōu)選地還包括這樣的選項，即當完成訂單時發(fā)送最后的FIX執(zhí)行消息，其中訂單狀態(tài)字段被設置成“完成”，以便指示這個訂單上的工作完成。
訂單管理器。訂單管理器130作為消息處理器。在下面的段落中，描述了各種消息的處理。
所述系統(tǒng)優(yōu)選地使得用戶能夠輸入新票據消息。新票據消息是FIX新訂單消息，其中Order Type(訂單類型)＝Market(市場)，并且沒有限制價格。具有限制價格的FIX訂單將被拒絕。在一個替代實施例中，可以通過應用程序編程接口(API)提交這個消息。
在步驟510接收到票據后，優(yōu)選地在處理新票據的同時執(zhí)行下面的步驟(參見圖5)●驗證。在步驟520，系統(tǒng)優(yōu)選地通過首先驗證在FIX新訂單消息中的字段來處理新訂單。票據必須具有有效的客戶ID、交易者ID(映射到唯一的GUI)、證券和交易方(購買或銷售)，并且必須與這個證券的巨額證券數量至少一樣大。Cloud9優(yōu)選地接受被識別為“市場”訂單和“未持有”的FIX訂單(票據)，并且拒絕具有限制價格的票據。在替代實施例中，不強制對價格和未持有狀態(tài)的限制?？蛻魞?yōu)選地僅僅被允許在每一方具有每個證券一個票據；如果先前的票據仍然保留，則將拒絕同一證券的第二購買票據或第二銷售票據。如果先前的票據被填寫或取消，則可以輸入第二票據；它將替換在GUI前端上的第一票據。一個替代實施例采用使得能夠對于每個證券顯示多個票據的前端，并且客戶被允許發(fā)出任何數量的票據。將忽略其他商業(yè)FIX訂單屬性。優(yōu)選地，使用原因代碼在GUI上顯示被拒絕的票據。
●處理。所述系統(tǒng)優(yōu)選地在其數據庫150中存儲有效的票據。然后，在步驟540經由網絡服務器110將所述票據顯示在客戶GUI上，并且在步驟530經由FIX 120向客戶OMS進行往回確認。下面的表格給出了在所述優(yōu)選實施例中的票據消息中的必需字段。

所述系統(tǒng)優(yōu)選地使得用戶能夠輸入取消/替換票據消息。取消/替換票據優(yōu)選地被提交為FIX取消/替換訂單，它具有先前打開的票據的ClientTicketID和新票據的ClientTicketID。在一個替代實施例中，這個消息可以通過API被提交。在所述優(yōu)選實施例中，所述系統(tǒng)在接收到取消/替換票據消息時執(zhí)行下面的步驟。
●驗證。如果新數量減去已經被填寫的數量(新的“剩余量”)小于符號的系統(tǒng)大巨額證券數量，或者如果它小于作為打開訂單在執(zhí)行引擎上發(fā)出的總股數(小于工作量的剩余量)，則本發(fā)明的系統(tǒng)主題優(yōu)選地拒絕取消/替換消息。
●處理。如果它接受所述請求，則Cloud9優(yōu)選地修改要應用到任何后續(xù)的訂單輸入事件的票據大小，并且經由網絡服務器110來向客戶GUI提供所述改變。它優(yōu)選地還經由FIX向客戶的OMS對所述改變進行往回確認。
所述系統(tǒng)優(yōu)選地使得用戶能夠輸入取消票據請求。取消票據消息是具有先前打開的票據的ClientTicketID的FIX取消訂單消息。在一個替代實施例中，可以通過API來提交這個消息。本發(fā)明的系統(tǒng)主題如下處理取消票據消息(參見圖6)。
●驗證。所述系統(tǒng)優(yōu)選地通過保證它指向打開的票據而在步驟610驗證取消請求消息的字段。
●處理。如果存在打開的訂單，則在步驟620，系統(tǒng)將首先試圖取消與所述票據相關聯(lián)的所有打開的訂單，然后在步驟630使用空中的(inflight)消息來報告在取消之前進行的任何執(zhí)行630(當所有相關聯(lián)的訂單被填寫或取消并且Cloud9訂單管理器的數據庫與執(zhí)行引擎的數據庫在任何填單的狀態(tài)上一致時，這個“清除”處理結束)。如果有的話，當已經清除了任何打開的訂單時，在步驟640，所述系統(tǒng)將使用指示被取消的大小的結果來確認取消票據。在步驟650中，經由網絡服務器來向客戶GUI來通知成功的取消票據請求。
所述系統(tǒng)優(yōu)選地使得用戶能夠輸入新訂單消息。優(yōu)選地通過GUI或API來提交新訂單消息，并且所述新訂單消息包括以限制價格或更好價格來購買或銷售給定證券的給定數量的大巨額證券份額的請求。在所述優(yōu)選實施例中，用戶也可以選擇釘住的價格限制，在這種情況下，所述訂單將被限制在絕對限制價格和釘住限制價格之間的不太積極的價格上。新的訂單消息優(yōu)選地被處理如下。
驗證。所述系統(tǒng)優(yōu)選地驗證訂單用于在所支持的證券中的大巨額證券數量的倍數。在一個替代實施例中，所述訂單可以用于任何數量。在優(yōu)選的訂單驗證處理中的另一個步驟是驗證所述訂單包含價格字段。在一個替代實施例中，如果用戶已經選擇了釘住價格，則這個要求被放棄，在這種情況下，釘住的訂單可以沒有限制地浮動。在所述優(yōu)選實施例中支持的釘住(Peg)類型釘住到NBBO中點或根本沒有釘住。替代實施例支持附加的釘住屬性，這是本領域的技術人員公知的。所述系統(tǒng)優(yōu)選地還驗證訂單方是購買或銷售。一個替代實施例還支持短銷售訂單。所述參數PegOffset確定偏離訂單應該被定價的所述釘住值(NBBO中點)的百分比數量(或其分數)。如果訂單不釘住，則優(yōu)選地忽略PegOffset屬性。所述系統(tǒng)優(yōu)選地使用可理解的錯誤代碼來向GUI客戶報告被拒絕的訂單。如果客戶使用票據，則所述驗證步驟還優(yōu)選地檢查所述訂單不超過相關聯(lián)的票據的大小，并且處于與票據相同的一方。如果輸入所述訂單的客戶對于發(fā)起經紀人具有信用限制，則作為所述驗證處理的一部分，所述系統(tǒng)優(yōu)選地驗證所述訂單未違反所述信用限制；將在下面更詳細地描述信用驗證處理。
在所述優(yōu)選實施例中，IOC訂單被拒絕為無效，因為它們可以用于探測關于導致了符號積極標志的長期有效訂單的信息，而不向所述長期有效訂單的擁有者示出相對方存在標志。在一個替代實施例中，接受IOC訂單，但是長期有效訂單的擁有者可以看見閃動的相對方存在標志(例如，符號從橙色向黃色迅速改變，然后返回到橙色)。在另一個替代實施例中，接受IOC訂單，并且IOC訂單不導致發(fā)送出任何標志，而不管是積極符號標志還是相對方存在標志。
訂單屬性。所述優(yōu)選實施例的系統(tǒng)期望找到在下表中給出的新訂單消息中的必需字段。


處理。所述系統(tǒng)優(yōu)選地通過下面的步驟來處理有效的訂單(參見圖7)。
●在驗證(步驟710)后，在步驟720中立即向執(zhí)行引擎?zhèn)鬟f有效訂單。響應將指示所述訂單是被拒絕，還是被接受并且作為打開的訂單而被放在賬簿中，還是具有執(zhí)行掛起。來自執(zhí)行引擎的狀態(tài)經由網絡服務器被報告到GUI客戶。
●如果客戶使用FIX票據，則所述系統(tǒng)優(yōu)選地經由FIX將訂單狀態(tài)向回報告為被接受或被拒絕(步驟730)；執(zhí)行掛起狀態(tài)將被報告為在FIX中的打開狀態(tài)(隨后的鎖定執(zhí)行消息將跟隨)。所述FIX訂單狀態(tài)更新消息承載相關聯(lián)的票據的ID。
●如果執(zhí)行引擎指示所述訂單是打開的，則所述系統(tǒng)將通過幫助器來啟動處理740，其目的是提高交易的可能性。
○所述系統(tǒng)優(yōu)選地確定是否所述價格在巨額證券價格范圍(BPR)的最新公布值內，并且如果肯定，則將所述訂單標注為“積極”。對于這個評估，使用市場數據高速緩沖存儲器來定價釘住訂單。
○如果訂單被標注為“積極”，則所述系統(tǒng)優(yōu)選地確定是否在系統(tǒng)中存在積極的相對方訂單。如果存在，則立即向沒有它的常駐相對方發(fā)送相對方存在標志，并且在ContraPresentDelay秒的延遲后調度重新評估相對方存在狀態(tài)的事件。如果在這個所調度事件的情況下第一參與者的訂單和至少一個相對方訂單仍然積極并且在BPR內，則系統(tǒng)向第一參與者發(fā)送相對方存在標志。
○如果訂單被標注為“積極”并且所述符號沒有已經處于積極狀態(tài)，則將符號設置在積極狀態(tài)中，并且產生積極符號消息。
●在步驟750中，所述系統(tǒng)等待相對方訂單到達；如同在驗證步驟710開始的這個流程中那樣，處理每個相對方訂單。優(yōu)選地，以常駐訂單的限制價格執(zhí)行具有相等或更好的價格的相對方訂單。
所述系統(tǒng)優(yōu)選地使得用戶能夠輸入取消訂單消息。取消訂單是具有對應于先前的新/替換的訂單的ClientOrderID的GUI/API消息。在一個替代實施例中，也可以經由FIX來接收取消訂單請求。
驗證。如果訂單ID是無效的或者指向在Cloud9中未知為打開的訂單，則拒絕取消訂單請求。
處理。系統(tǒng)100優(yōu)選地通過下面的步驟來處理取消訂單請求。
●Cloud9 OM 130向執(zhí)行引擎50傳遞有效取消訂單請求。
●執(zhí)行引擎50將使用被取消的股份來響應。取消響應可以在執(zhí)行的后面。對于已經被填寫的或過期的訂單，拒絕取消請求。
●在從執(zhí)行引擎50接收到成功的取消響應時，○將訂單狀態(tài)更新推送到GUI客戶20和分析服務器160。
○如果客戶使用FIX票據，則還經由FIX報告狀態(tài)更新。
○釋放被分配到這個訂單的信用。
○通過“相對方存在”標志檢查是否存在相對方，并且如果不再滿足相對方存在條件則去除所述標志。
○注意取消訂單不去除積極符號標志。
所述系統(tǒng)還使得用戶能夠輸入取消/替換訂單請求以修改先前的訂單。在所述優(yōu)選實施例中，取消/替換訂單是指向(ClientOrderID)有效的先前新/替換訂單的GUI/API消息。在一個替代實施例中，也可以經由FIX來輸入這個消息。
驗證。ClientOrderID必須指向有效的訂單。如果取消/替換請求指向已經在Cloud9內已知為被取消、過期或被填寫的訂單，則所述系統(tǒng)優(yōu)選地拒絕所述取消/替換請求。在所述優(yōu)選實施例中，所述系統(tǒng)支持交易之前的信用檢查。因此，如果要通過取消/替換請求來提高訂單的大小，則系統(tǒng)首先驗證新大小將不超過用戶帳戶的信用限制。不能通過信用驗證的替換訂單請求被拒絕為無效，其中通過原因代碼來說明信用原因。
取消/替換訂單處理。Cloud9 OM 130通過將取消/替換訂單消息傳遞到執(zhí)行引擎來處理它們。執(zhí)行引擎50將以包括被填寫的股份、剩余的打開股份和平均價格的訂單狀態(tài)來響應。
●交易消息。將把狀態(tài)更新經由網絡服務器110推送到GUI客戶。
●如果客戶使用FIX票據，則還經由FIX報告狀態(tài)更新。
●如果取消/替換修改了訂單的大小，則取消和替換被分配到這個訂單的信用量以反映新的訂單。
交易消息。執(zhí)行引擎50經由交易消息向訂單管理器130報告交易。來自執(zhí)行引擎的每個交易消息報告僅僅涉及兩個訂單的鎖定交易。
執(zhí)行引擎50將獨立的訂單與多個相對方訂單的賬簿匹配(一對多的匹配)?？梢杂卸鄠€遵循匹配檢查的獨立交易，其中每個將獨立地被處理。
因為交易是單個事務，因此所述交易的兩個分支(leg)應當作為一個單元被報告。
所述系統(tǒng)的優(yōu)選實施例期望找到在交易消息中的下列字段。

處理交易消息。系統(tǒng)100優(yōu)選地通過下面的步驟來處理來自執(zhí)行引擎50的交易消息。
●對于使用票據或者請求FIX執(zhí)行的客戶，向相關聯(lián)的GUI客戶并且經由FIX報告兩個填單。
●根據交易價格更新信用以反映所消耗的實際信用量。
●如果交易者使用票據并且在所述票據上的剩余數量小于這個符號的大巨額證券數量，則使在票據上的剩余數量過期。
●向網絡服務器發(fā)送巨額證券記錄帶消息，以遞送到觀看此證券的GUI。所述巨額證券記錄帶消息優(yōu)選地包含下面的字段。

在緊急時，所述系統(tǒng)優(yōu)選地使得交易者能夠使用單個請求取消他們在系統(tǒng)內所發(fā)出的所有的訂單。CancelAllClientOrders是來自網絡服務器的消息，用于請求取消已經通過給定的GUI而輸入的所有訂單。在一個替代實施例中，也可以經由FIX來提供這個消息。因為執(zhí)行引擎50不知道客戶ID，因此Cloud9 OM將通過獨立地取消具有打開狀態(tài)的與這個客戶相關聯(lián)的每個訂單，作為獨立的取消訂單請求處理這些訂單，從而處理取消全部消息。
為了跟蹤與相對方存在或積極符號指示符相關聯(lián)的訂單的價格積極性，在所述優(yōu)選實施例中的訂單管理器130從分析服務器160預訂關于具有打開訂單的證券的BPR更新消息。每當刷新BPR時，OM 130檢查在打開訂單上的“積極”標志，并且如下更新所述標志。
如果訂單上的價格積極性標志發(fā)生改變，則對于這個證券的所有訂單重新評估是否有相對方存在情況，并且當對于訂單存在被定價為至少與BPR一樣積極的相對方時，將相對方存在標志更新為打開狀態(tài)，或者如果不再存在合格的相對方，則將相對方存在標志更新為關閉狀態(tài)。如果這導致訂單上的相對方存在狀態(tài)中的改變，則系統(tǒng)優(yōu)選地向被影響的GUI客戶發(fā)送相對方存在消息。
所述優(yōu)選實施例的系統(tǒng)還根據BPR更新消息來更新訂單的積極狀態(tài)。如果所述符號處于積極狀態(tài)、已經處于這個狀態(tài)至少60秒并且在BPR中不再有任何訂單，則所述符號被設置為消極狀態(tài)，并且網絡服務器發(fā)送積極符號消息，其中ActiveSymbolStatus(積極符號狀態(tài))＝NotActive(消極)。
退訂BPR更新消息。在一個替代實施例中，在任何BPR更新消息上更新積極符號狀態(tài)，并且即使所述符號處于積極狀態(tài)少于60秒，也可以將積極符號狀態(tài)設置為消極狀態(tài)。在另一個替代實施例中，在國家市場最佳買方出價和賣方索價價格的每次改變和每次訂單輸入或取消事件時，更新所述積極符號，以保證所述積極符號標志總是指示此時在系統(tǒng)中存在至少與BPR的消極端一樣積極地被定價的、活動可執(zhí)行訂單。
執(zhí)行引擎。在所述優(yōu)選實施例中的執(zhí)行引擎50是通過諸如因特網的通信網絡80來與訂單管理器130通信的去耦系統(tǒng)。在一個替代實施例中，執(zhí)行引擎50駐留在與Cloud9系統(tǒng)100相同的設施中，并且所述兩個系統(tǒng)通過內聯(lián)網來通信。在另一個替代實施例中，執(zhí)行引擎50是在Cloud9系統(tǒng)內的部件；在所有這些實施例中，執(zhí)行引擎50的功能被描述如下。執(zhí)行引擎50接收“匿名”的訂單，這意味著所述訂單被去除了購買方客戶ID，并且取代為由內部訂單ID和發(fā)起經紀人ID來識別所述訂單。執(zhí)行引擎50通過下述方式來處理新輸入的訂單通過查看是否存在與輸入的訂單匹配的常駐訂單，并且使用利用價格時間優(yōu)先級而排名的常駐訂單來執(zhí)行交易，如下詳細所述。
在所述優(yōu)選實施例中的執(zhí)行引擎50是用于在失敗時恢復關于任何Cloud9交易的真實狀態(tài)的記錄賬簿。
執(zhí)行引擎50的優(yōu)選實施例支持限制訂單和被釘住到NBBO中點的訂單。在一個替代實施例中，也支持本領域的技術人員公知的其他訂單類型。例如，一種替代的執(zhí)行引擎可以支持價格自行處理(discretion)訂單，其可以針對市場訂單以限制價格來執(zhí)行，但是可以自動地提高他們的價格積極性以觸發(fā)與輸入的限制訂單的匹配，直至預定的自行處理量。在一個替代實施例的另一個示例中，所述系統(tǒng)使得交易者能夠輸入訂單，所述訂單是以后根據數量加權平均價格(VWAP)在前行時間間隔中被定價的，諸如從交易時間到一天的末尾的VWAP或在諸如半小時間隔的特定時間間隔上的VWAP。
可以將在所述優(yōu)選實施例中的訂單描述為具有可選Peg的限制訂單。要求所有的訂單具有限制價格；如果它們也具有釘住價格，則所述訂單被當作被定價在限制和釘住值之間的更消極的價格。在匹配檢查事件的情況下，定價釘住訂單，然后將釘住訂單看作與具有限制或釘住價格的更消極者的限制訂單相同。所述釘住值是NBBO中點加上釘住偏移量。
在所述優(yōu)選實施例中，用戶將使用Peg作為對于限制訂單的保護，以確保如果市場迅速地改變，則它們的訂單不以與NBBO價格相比較以很積極的級別突然出現(xiàn)(stand)的價格來交易。GUI 20以下述方式來建議了使用Peg的這種方式通過將所述特征表示為“價格保護”，并且提供選項“在超過偏離NBBO中點價格的百分之<n>的情況下不交易”。
因為在所述系統(tǒng)中有釘住訂單和限制訂單，因此也可以不在訂單輸入時觸發(fā)匹配，而是作為將使得釘住訂單的價格與相對方訂單的限制價格交叉的NBBO價格改變的結果來觸發(fā)匹配。
因此，在本發(fā)明的所述優(yōu)選實施例中，可以在新訂單輸入時或者在使得釘位訂單與其他訂單交叉的NBBO價格改變時觸發(fā)匹配。所述系統(tǒng)優(yōu)選地實現(xiàn)下述處理來識別這樣的匹配。
執(zhí)行引擎50優(yōu)選地包括這樣的部件，用于使用在本領域公知的信息高速緩存技術來從數據提供器60接收所有的報價更新消息，并且跟蹤當前的最佳買方出價和最佳賣方索價。它優(yōu)選地還使得執(zhí)行引擎50的部件能夠預訂給定證券的價格更新，其后，每當給定的證券的最佳買方出價或最佳賣方索價改變時它將接收到消息。
執(zhí)行引擎50優(yōu)選地維護在一方具有一個或多個限制訂單并且在另一方具有一個或多個釘住訂單的符號的列表，并且預訂在這個列表中的所有證券的NBBO價格改變。對于本說明書，具有限制價格的釘住訂單既被視為釘住訂單，又被視為限制訂單。對于在這個列表中的符號，執(zhí)行引擎50將通過下述方式來處理每個NBBO價格改變通過定價證券的所有釘住訂單，然后按照價格時間優(yōu)先級對購買方和賣方索價方的所有訂單進行排名。
所述系統(tǒng)優(yōu)選地通過下述方式來進行識別匹配通過首先獲得排名最前的購買訂單，并且以價格時間優(yōu)先級來處理在這個訂單和銷售訂單之間的交易。如果仍然存在未被填單的銷售訂單，則所述系統(tǒng)進行到排名其次的購買訂單，并且再次以價格時間優(yōu)先級來處理與還未被填單的銷售訂單的交易。
執(zhí)行引擎50將優(yōu)選地如下觀察在主市場上的交易暫停。當證券被暫停時，將拒絕所有現(xiàn)有的和新的訂單。執(zhí)行引擎50從數據賣方60獲得證券交易狀態(tài)。如果數據賣方60不能提供服務或對應的通信網絡70失敗，則執(zhí)行引擎不處理任何交易，而是僅僅等待重新建立至關重要的服務。
對于分析服務器160，在所述優(yōu)選實施例中的市場數據饋送包含市場暫停信息以及級別1和最后的銷售數據。
如果新訂單觸發(fā)了匹配，則執(zhí)行引擎優(yōu)選地使用預期的總匹配數量來向Cloud9 OM 130立即報告執(zhí)行掛起。這個報告的信息量是情報性的而僅僅用于幫助器140，而不保證交易將被結算，如下所述。
如在本領域內所公知的那樣，優(yōu)選地將作為單個事務處理交易，以避免在失敗時系統(tǒng)報告交易的一方而沒有另一方的風險。所述處理包括下列步驟。
1.按照需要來向調節(jié)組織報告交易，并且更新在數據庫中的訂單狀態(tài)。在所述優(yōu)選實施例中，向納斯達克ACT系統(tǒng)報告交易。匹配引擎立即向ACT報告以便用于數據傳播(記錄帶報告)和結算。
2.當交易成功地被鎖定以結算(ACT確定交易報告并且分配ACT報告ID)時，執(zhí)行引擎50優(yōu)選地向訂單管理器130發(fā)送確定的交易報告消息。優(yōu)選地使用用于計算NBBO中點的最近買方出價的時間戳和最近賣方索價的時間戳以及處理所述執(zhí)行的時間戳來報告涉及釘住訂單的交易。
執(zhí)行引擎50如下處理輸入的消息新訂單處理。新訂單是來自OM 130的消息。優(yōu)選地如下處理它。
●如果有的話，識別匹配訂單，并且以狀態(tài)向訂單管理器130確認訂單輸入。
●如果訂單未被填寫但是導致在一方有限制訂單而在另一方有釘住訂單的情況，則登記所述證券的NBBO價格更新。
●如上所述處理任何交易取消訂單。取消訂單是來自Cloud9的、取消打開訂單的請求。優(yōu)選地如下處理它。
●驗證是否取消訂單請求承載指向在賬簿51中的訂單的有效訂單ID。
●如果所述訂單已經被交易，則拒絕所述取消訂單請求消息。
●如果所述訂單還沒有被交易○在執(zhí)行引擎數據庫(賬簿51)中將訂單狀態(tài)標注為被取消。
○向訂單管理器130報告成功的取消狀態(tài)。
在所述優(yōu)選實施例中，可以在任何時間修改或取消訂單。在一個替代實施例中，要求訂單具有10秒的最小有效時間以向其他參與者提供合理的時間來對由幫助器140觸發(fā)的事件——諸如積極符號標志或相對方存在標志——作出反應。
所述系統(tǒng)優(yōu)選地還使得訂單管理器130能夠請求取消與給定的發(fā)起經紀人相關聯(lián)的所有訂單或者取消全部訂單。執(zhí)行引擎50通過下述方式來處理這樣的集體取消訂單請求通過首先識別所有被影響的訂單，然后按照訂單的輸入時間來處理取消訂單請求。
執(zhí)行引擎50優(yōu)選地使用30秒的心跳來驗證與訂單管理器130的連接。在丟失連接時，所述系統(tǒng)優(yōu)選地取消所有的訂單。
網絡服務器。所述系統(tǒng)優(yōu)選地包括應用程序編程接口，它使得客戶GUI20能夠通過諸如因特網的通信網絡80而連接到網絡服務器110。網絡服務器110使得客戶前端應用程序能夠訪問Cloud9交易服務，諸如查看BPR更新，以及向系統(tǒng)中輸入訂單。
如果檢測到丟失了到客戶的連接，則Cloud9優(yōu)選地試圖使用執(zhí)行引擎50來取消所有客戶的訂單。在一個替代實施例中，系統(tǒng)使得客戶能夠選擇其中連接的丟失不導致打開訂單的取消的配置；選擇這個替代配置的客戶然后在緊急時必須調用幫助臺來取消訂單。
網絡服務器110向訂單管理器傳遞交易行為消息(訂單，取消/替換，取消)，并且向客戶往回傳遞響應和未經請求的消息。它也存儲客戶GUI配置，諸如在屏幕上的窗口的位置和大小和交易者希望觀看的證券的列表。這些示例不構成窮盡的列表，而是意欲僅僅用于說明性目的；其他配置參數被存儲來支持通常的GUI顯示選項，這可以容易地被本領域的技術人員明白。
在一個優(yōu)選實施例中，GUI使得交易者能夠當可用信用量低于執(zhí)行大巨額證券交易通常所需要的美元金額時查看由系統(tǒng)產生的警報。在一個替代實施例中，不顯示信用警報，并且用戶僅僅在訂單輸入請求失敗時發(fā)現(xiàn)沒有足夠的信用。
在本發(fā)明的所述優(yōu)選實施例中，GUI 20使得交易者能夠訪問用于幫助管理證券的觀看列表的對話框。觀看列表的目的是限制從所述系統(tǒng)向交易者所感興趣的符號的信息流動。在所述優(yōu)選實施例中，所述系統(tǒng)還使得交易者能夠查看是否有其他人當前正在通過打開的GUI觀看給定的符號(對此感興趣是因為這將提高交易的可能性)。在一個替代實施例中，GUI 20使得用戶能夠看見觀看證券的交易者的數量。GUI 20將登記僅僅被觀看的證券的BPR更新消息以及積極符號和相對方存在消息的接收。在所述優(yōu)選實施例中，API允許GUI登記任何證券的BPR/積極/相對方存在消息，并且獨立地登記證券的獨立列表的報價更新消息。優(yōu)選的GUI 20一次僅顯示一個證券的NBBO價格，即訂單輸入對話框打開的那個，如圖2所示。在一個替代實施例中，GUI預訂所有被觀看的證券的NBBO更新，并且這些價格被顯示在下拉列表中的符號的旁邊。
為了管理觀看列表，用戶優(yōu)選地能夠增加單獨的符號，或者增加被分類為處于已知證券組諸如工業(yè)組或部門中的所有符號。所述系統(tǒng)優(yōu)選地還使得用戶能夠以Excel文件的形式來提交它們自己的證券組，并且向系統(tǒng)中加載這些組，在此，簡單地將它們加到交易者可能從其選擇以填充他的或她的觀看列表的證券組列表。
圖8示出了優(yōu)選的觀看列表配置對話框。用戶能夠增加符號或符號組。改變處于掛起狀態(tài)，直到用戶保存了所述改變。用戶也可以返回到先前保存的觀看列表或從Excel電子表格加載一組證券，其中該Excel電子表格例如可以從它們的OMS或流水帳(blotter)獲得。
所述觀看列表優(yōu)選地由客戶管理，并且保存在服務器上。
在一個優(yōu)選實施例中，網絡服務器110跟蹤哪些符號正在被兩個或更多的GUI “觀看”。如果向交易者觀看列表增加符號以使得觀看客戶的數量達到2，則網絡服務器110將向預訂積極符號消息的所有GUI廣播消息，以指示所述符號被觀看。如果觀看GUI的數量降到1，則網絡服務器向預訂積極符號更新的GUI廣播消息以指示這個符號不再被觀看。在一個替代實施例中，所述消息在用戶增加或去除對于符號的觀看的任何時間被發(fā)送，并且提供所述符號、時間戳和觀看所述符號的各方的更新數量。
GUI 20優(yōu)選地通過下述方式來顯示在交易者的觀看列表中并且處于積極狀態(tài)或者存在相對方的所有符號通過彩色編碼的矩形在GUI的頂部加亮它們，使用橙色來用于積極符號，黃色來用于相對方存在。在一個替代實施例中，類似于即時信使應用程序，通過臨時的彈出式屏幕來顯示用于指示被觀看的符號已經變得積極或具有相對方存在的消息。在另一個替代實施例中，這些彈出式消息保持可見，直到采取行動——或者通過點擊以產生訂單輸入對話框并且響應于所述消息而輸入訂單，或者通過點擊“關閉”或“最小化”按鈕以關閉彈出式窗口或者將其縮小到屏幕底部的橫條上。
在所述優(yōu)選實施例中的交易者GUI 20具有這樣的選項，即示出或不示出處于“被觀看”狀態(tài)的其觀看列表上的符號(即至少另一個交易者正在觀看這個符號)。如果他們選擇看見這些符號，當它們不“積極”或具有相對方存在時，以比所述其他兩種顏色不太顯眼的第三種顏色來表示它們，因為不立即需要交易者的注意；在所述優(yōu)選實施例中，GUI 20在所述積極和相對方存在矩形的旁邊的灰色矩形中提供了被觀看的符號。
網絡服務器110優(yōu)選地提供讓遠程客戶訪問系統(tǒng)服務的API。所述API優(yōu)選地使得用戶能夠在使用任何交易服務之前通過基本的驗證(用戶名密碼)來打開會話。在一個替代實施例中，客戶使用證書來驗證其本身。優(yōu)選地通過SSL會話來進行用戶憑證(credential)的交換，其中SSL會話使用網絡服務器公共密鑰來交換加密密鑰。一旦驗證了用戶，則所述會話映射到用戶的身份。
網絡服務器API優(yōu)選地提供下面的函數。
●獲得部門列表每個公司可以選擇性地具有通過部門或其他證券分組形式而布置的證券。可以針對每個客戶公司配置所述證券分組。該API返回與客戶的公司和組名相關聯(lián)的證券的列表。
●獲得證券列表所述系統(tǒng)具有被配置的證券的列表。這個功能返回那個列表。所述列表的每個元素是符號、公司名稱和部門。
●設置和獲得交易者默認值所述系統(tǒng)使得客戶能夠存儲默認參數。下面的列表不意欲是窮盡的，而是包含特別感興趣的一些交易者默認值；其他對于本領域的技術人員將是顯然的。
○默認下單量。訂單輸入對話框將默認地使用這個符號的最小數量(大巨額證券數量)或者使用交易者的總票據大小——如果這個交易者使用票據的話——來填充數量字段。
○默認價格。所述訂單輸入對話框將使用經由下面的規(guī)則之一而選擇的限制價格來填充價格字段NBBO的積極端、NBBO的消極端、NBBO中點、BPR的積極端、BPR的消極端或BPR中點。
○默認TIF。訂單輸入對話框將使用這個秒數來填充有效時間字段。
○默認觀看列表管理(證券，部門)。所有觀看列表管理被前端處理，并且被保存在服務器上。
○默認釘住(Peg)和偏移。訂單輸入對話框將默認地選擇或不選擇釘住選項，并且如果選擇的話，則它對于購買訂單增加這個百分比數量來作為釘住偏移，或者對于銷售訂單從中點釘住價減去這個百分比數量。
○僅僅票據化訂單。這個選項確定是否交易者希望針對通過票據而保留的大小來檢查訂單。如果不選擇這個選項，則即使在沒有對應的票據時，交易者也將能夠輸入訂單。
○設置和獲得部門觀看列表保存和檢索組成部門或其他組的證券的列表。
○設置和獲得符號觀看列表保存和檢索在給定的觀看列表中的證券的列表。
●設置和獲得GUI默認值○票據管理格柵(Grid)用于在顯示票據列表的窗口打開或隱藏的情況下啟動應用程序的選項。
○票據管理格柵定義字體、字段順序、列大小、列類型、首標和字段＝列映射。
○積極符號列表(打開或關閉)。用于在顯示積極符號列表的窗口打開或關閉的情況下啟動應用程序的選項。
○顏色改變(是，否)GUI優(yōu)選地允許用戶選擇這個選項，以便當訂單已經被提交到系統(tǒng)并且任何字段已經被編輯時，加亮在訂單輸入對話框中的訂單的這個字段。當已經編輯了一字段時，用戶可以按下“替換”按鍵以經由取消/替換訂單消息來向所述系統(tǒng)發(fā)送新值。加亮已經被編輯的字段有助于用戶管理訂單。
●獲得心跳間隔。用于確定是否在GUI 20和網絡服務器110之間的連接是有效的周期性心跳的秒數。所述系統(tǒng)優(yōu)選地向這個參數施加下界，以避免由于連接管理職責而使網絡服務器110過載。在一個替代實施例中，所述參數可以僅僅在服務器上被設置，并且不經由API被提供。
●獲得票據獲得用戶的票據。在交易日內，用戶只能具有每個符號/交易方一個票據。如果取消所述票據，則大小遞減到未被執(zhí)行的大小。具有相同符號和交易方的新票據替換在列表中的條目。
●獲得訂單獲得所有訂單的列表。
●獲得訂單狀態(tài)。返回ClientOrderID的訂單細節(jié)。
●提交新訂單將新訂單排隊到系統(tǒng)中。將跟隨有OnOrderUpdate或OnOrderReject事件的異步調用。
●替換訂單這個函數將替換訂單請求排隊。調用者使得訂單狀態(tài)在返回時為“掛起的替換”。將跟隨有OnOrderUpdate或OnOrderReject事件的異步調用。被替換的訂單細節(jié)與新訂單細節(jié)+OrigClientOrder ID字段相同。數量是包括被填寫的大小的總數量。
●取消訂單這個函數將被取消的訂單請求排隊。調用者使得訂單狀態(tài)在返回時為“掛起的曲線”。將跟隨有OnOrderUpdate或OnOrderCancelled事件的異步調用。
●執(zhí)行交易。這個函數請求向發(fā)起經紀人報告這個交易以建立分配處理。這將在交易日的末尾被自動進行。
●獲得針對(ClientOrderID，Symbol或全部)請求/響應的交易以檢索交易細節(jié)。優(yōu)選地有這個請求的三種版本。獲得針對訂單的交易，針對在證券中的所有訂單的交易或針對這個GUI客戶的所有交易。
下面是API事件-即由系統(tǒng)產生和通過API推送到GUI 20的消息。
●OnTicketUpdate在新的、替換的和取消的票據事件時引發(fā)這個事件。
●OnOrderUpdate在訂單狀態(tài)改變時引發(fā)的事件。這包括對于上面請求或通過其他渠道的訂單管理響應。
●OnOrderReject響應于在這個會話中輸入的新/替換訂單請求而引發(fā)事件。
●OnCancelReject當拒絕取消請求時引發(fā)事件。
●當在通過這個API或其他渠道輸入的交易者訂單之一中有交易時，引發(fā)OnTrade事件。
網絡服務器110的優(yōu)選實施例還提供了用于預訂每個證券的市場數據的接口。字段包括(NBBO買方出價、要求和記錄帶時間戳(TapeTimeStamp))、(BPR低和高)、巨額證券記錄帶(最后和總的數量)、積極符號、相對方存在、證券狀態(tài)(打開、關閉、暫停等)和時間戳。在這個接口的優(yōu)選實施例中提供的功能是●預訂請求/響應這個功能優(yōu)選地向客戶的預訂列表增加在請求消息中提供的證券的列表。所述請求針對所請求的字段返回那個條目的當前數據的快照。對于被觀看的字段的后續(xù)改變將引發(fā)具有所述改變的更新事件(OnUpdate)。
●退訂請求/響應去除預訂請求。
●OnUpdateEvent向預訂者通知在預訂條目中的字段改變。
●開始積極符號饋送請求/響應返回其中設置了積極符號標志的所有符號的列表。在調用之后，積極符號標志改變中的所有狀態(tài)改變將導致OnActiveSymChange(符號，打開/關閉)。
●停止積極符號饋送請求/響應終止上述事件通知。
●OnActiveSymChange事件向預訂者通知積極符號標志改變。
研究數據存儲。所述系統(tǒng)優(yōu)選地存儲允許操作員和研究人員評估當用戶輸入訂單時在符號中的交易者行為的指示符如何與填單率相關聯(lián)的信息。這個信息通過市場化媒體和對交易站的參觀而在引導系統(tǒng)的使用朝向導致更大成功的工作流發(fā)展中扮演了重要的角色。例如，如果在未被觀看的證券的訂單的輸入后的填單率極低或空，則交易者可以被告知將在系統(tǒng)上的他們的交易聚焦在由其他交易者觀看的證券中。所述系統(tǒng)優(yōu)選地還可以被再配置成修改何時發(fā)出標志的規(guī)則以改善系統(tǒng)中的填單率。例如，如果確定在存在三個或更多的觀看證券的交易者時填單率比兩個時顯著更高，則可以重新配置所述系統(tǒng)，以僅僅當GUI用戶的總數是三個或更多而不是二個或更多時發(fā)出被觀看的符號消息。上述的示例意欲用于說明性目的，而不是提供窮盡的列表；基于上面給出的參數的修改的其他優(yōu)化對于本領域的技術人員將是顯然的。
交易者行為度量可以在幫助臺上獲得，并且在每天的末尾被導出到永久數據倉庫以離線分析，以便找到在可能的系統(tǒng)配置設置和較高的填單率之間的關聯(lián)。
感興趣的度量是●訂單行為(輸入，BPR積極性改變；取消/過期)●填單
●票據●可以看見符號積極標志(在觀看列表上，作為符號或作為部門的一部分)的交易者的數量●可以看見BPR更新的交易者(預訂者)的數量●可以看見報價更新的交易者(預訂者)的數量下面的數據表(A-D)以標準的逗號分界(CSV)格式被存儲。
表A.票據表

表B.訂單表

表C.交易表

表D.觀看列表

分析服務器在所述優(yōu)選實施例中的分析服務器160通過下述方式來跟蹤國家最佳買方出價和賣方索價價格通過監(jiān)聽賣方報價饋送60，并且當產生最佳價格的報價被取消或者被具有更好價格的新報價來改善時，更新所述NBBO價格。優(yōu)選地使用本領域的技術人員公知的方法來在高速緩沖存儲器中存儲當前的NBBO價格。除了NBBO價格之外，分析服務器160根據近來的報價和交易數據來計算巨額證券買方出價和巨額證券賣方索價。
分析服務器的主要功能是產生下面的消息●NBBO價格改變。
●巨額證券價格范圍更新。
分析服務器將存儲所有被支持的證券的、全天的最后銷售數據和內部買方出價或賣方索價的所有改變。在表格E和F中描述了需要被存儲來分析的數據。
表E.內部市場價格更新


表F.最后銷售

每當在內部市場最佳買方出價價格或最佳賣方索價價格中有改變時，分析服務器160向所有連接的客戶遞送報價更新消息。所述更新消息承載新的買方出價價格或新的賣方索價價格和與改變這個買方出價或賣方索價的報價的出現(xiàn)或去除相關聯(lián)的時間戳。
分析服務器160優(yōu)選地還每60秒更新BPR，并且向訂單管理器130發(fā)送BPR更新消息以用于確定其訂單的價格積極性，并且向網絡服務器110發(fā)送所述BPR更新消息以用于向GUI客戶20廣播。
所述優(yōu)選實施例包括可替換的模塊，它負責計算BPR?？梢允褂帽绢I域技術人員公知的方法來計算BPR，諸如通過使巨額證券買方出價等于國家最佳買方出價減去百分之五以及使巨額證券報價等于國家最佳報價加上百分之五。在另一個示例中，與股票的歷史變動性成比例地設置要加到NBBO價格(從NBBO價格減去)的百分比數量，以便對于諸如技術問題之類的很變動的符號，變化可能大于百分之五，而對于諸如藍籌股公用事業(yè)股票之類的更穩(wěn)定股票，它將更小。
在本發(fā)明的所述優(yōu)選實施例中使用的算法分別考慮在過去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發(fā)出BPR更新消息。
信用管理。所述系統(tǒng)優(yōu)選地使得發(fā)起經紀人能夠設置在他們的客戶的賬戶上的信用限制。在所述優(yōu)選實施例中，根據總的美元限制來進行信用檢查，計算所購買的股份加上所銷售的股份的總值。將根據BPR的頂端或訂單的限制價格的較大者來對于訂單驗證信用，并且根據當訂單被完全地填寫、過期或取消(對于部分填單)時所消耗的實際信用量來調整信用。
●經紀人將被提供用于管理信用的萬維網帳戶；他們可以查看由客戶當前消耗的信用的級別，但是該信用級別僅僅被如下分級小于25％、25-50％、50-75％、大于75％。
●經紀人必須能夠以瞬即效應來提高今天的信用；或者，他們可以在每個交易日的開頭提高或降低發(fā)生刷新的信用量。經紀人還可以暫停信用；這具有對于日內和隨后日子的效應。如果暫停一日的信用，則系統(tǒng)將取消所有的打開訂單。
●經紀人可以以后對客戶結束暫停信用。暫停具有永久的效應，并且持續(xù)到下一日。在一天的末尾刷新信用。
●經紀人將能夠建立作為總數的百分比(默認值＝75％)的信用警報閾值；另外，每當可用信用降到低于太低而不能利用巨額證券系統(tǒng)的系統(tǒng)配置的美元金額MinCreditAmount(例如，二百萬美元)時，所述系統(tǒng)將產生警報。信用警報將被遞送到幫助臺人員，并且被推送到客戶GUI。
幫助臺。所述系統(tǒng)優(yōu)選地提供由處理來自客戶的調用(call)的人員使用的幫助臺界面。這個用戶界面可以是萬維網瀏覽器界面，并且通過公共密鑰加密和基于證書的驗證以及用戶名和密碼對來進行安全的訪問。所述界面優(yōu)選地使得用戶能夠觀看關于訂單的生命的詳細信息。用戶可以使用給定的符號和客戶ID來拉出訂單的列表以定位客戶正在調用的訂單。所述幫助臺界面使得其用戶能夠點擊感興趣的訂單，以便按照時間順序來查看下面的消息。
●票據——如果適用的話。
●訂單輸入請求。
●訂單輸入響應被拒絕(具有原因代碼)；執(zhí)行掛起；過期；打開。
●填單；●針對訂單發(fā)送的相對方存在標志。
●修改訂單請求和響應(被接受，被拒絕)。
●取消請求和響應(被接受，被拒絕)。
●過期。
另外，幫助臺操作員能夠看見在訂單的生命中的每個重要事件(輸入，取消，執(zhí)行)時的NBBO內部價格、分別在買方出價和賣方索價方看見的最近報價的時間戳、BPR價格和時間戳。這用于回答諸如為什么當輸入訂單時符號改變或不改變到積極狀態(tài)等的問題。
在一個替代實施例中，幫助臺操作員不能查看任何訂單的符號或交易方，以降低與知道機構客戶的交易意向的交易者相關聯(lián)的安全風險。在這個實施例中，幫助臺操作員通過下述方式來識別調用者的訂單通過拉出與交易者相關聯(lián)的訂單的列表，其中具有每個訂單的輸入時間和大小，以及在交易者的GUI 20上也是可見的ClientOrderID。幫助臺操作員與交易者合作來識別他或她正在查詢哪個訂單，然后通過點擊訂單以查看對應的行為軌跡而如上所述進行。
在所述優(yōu)選實施例中，幫助臺還使得其操作員能夠從下拉列表選擇客戶，并且查看與交易邏輯相關聯(lián)的他們的配置。下面的列表向幫助臺操作員提供更重要的用戶配置和使用統(tǒng)計；所述列表不意欲是窮盡的，其他可以被本領域的技術人員容易地理解。
●信用限制和所消耗的信用。
●交易者的行為訂單的數量、交易股數、交易美元。
●交易者列表；選擇一個來查看和編輯交易者選項。
●觀看列表管理(增加/去除符號，增加/去除工業(yè)組)。
●示出/不示出積極符號條●示出/不示出票據的下拉列表。
●默認的票據屬性。
所述優(yōu)選實施例也使得經紀人能夠使用對于幫助臺操作員的同一驗證和安全模型來訪問網頁。經紀人將使用這個頁面來用于信用管理目的。為了保持客戶的保密性，該界面優(yōu)選地以不披露客戶的交易細節(jié)的方式來限制被顯示到經紀人的信息。在這個實施例中，經紀人可以僅僅以總信用限制的百分比來查看由客戶消耗的信用量；例如，這個可以被分級為四個間隔小于25％、25-50％、50-75％和大于75％。另外，使得發(fā)起經紀人能夠通過下面的功能來修改客戶的信用。
○增加日內的信用。
○增加今天的信用，并且還提高隨后日子的刷新量。
○隨后日子的較低刷新量。
○暫停信用。
○結束暫停信用。
在一個替代實施例中，立即向發(fā)起經紀人報告所述交易，并且發(fā)起經紀人能夠查看所執(zhí)行的交易以及所消耗的信用的精確數量。在另一個替代實施例，發(fā)起經紀人還可以查看交易前的行為。
系統(tǒng)配置界面。所述系統(tǒng)優(yōu)選地使得操作員能夠在間斷時間系統(tǒng)維護時間表期間修改配置，并且增加/去除客戶或發(fā)起經紀人。
所述系統(tǒng)配置界面使得系統(tǒng)操作員能夠增加客戶，并且設置所需要的配置屬性以使得用戶能夠交易。新客戶公司必須從可用經紀人的列表選擇發(fā)起經紀人。所述發(fā)起經紀人優(yōu)選地對于在同一公司內的所有交易者是唯一的。在一個替代實施例中，同一公司可以使用多個發(fā)起經紀人，并且GUI 20讓交易者在訂單輸入時選擇發(fā)起經紀人。新公司可以選擇性地建立直接到FIX服務器120或通過發(fā)起經紀人95的FIX通信。在后一種情況下，發(fā)起經紀人代表其本身而從客戶向FIX服務器120轉發(fā)FIX消息。公司可以根據其工作流要求而選擇兩種模式的FIX連接可以建立FIX通道以僅僅接收執(zhí)行，或接收執(zhí)行和訂單更新?？梢越⑺鼈円暂斎肫睋歪槍νㄟ^票據而分配的大小來檢查GUI輸入的訂單，或者不使用票據而工作。當向系統(tǒng)增加客戶公司時，幫助臺人員將請經紀人建立客戶賬戶的任何信用限制，并且與用于一日末尾報告的客戶ID一致。優(yōu)選地要求新用戶來在系統(tǒng)上配置GUI/API訪問以能夠交易。在一個替代實施例中，還經由FIX接口而支持訂單輸入，并且不要求用戶使用GUI 20或API訪問。
優(yōu)選地，系統(tǒng)配置界面也使得系統(tǒng)操作員能夠向所支持的經紀人的列表增加發(fā)起經紀人。在一個替代實施例中，所述系統(tǒng)由單個發(fā)起經紀人操作，并且不能通過第三方經紀人關系而被訪問。在配置發(fā)起經紀人中，操作員將為發(fā)起經紀人創(chuàng)建用戶賬戶，以便如上所述管理他們的客戶的賬戶的信用。諸如電話號碼、傳真和電子郵件之類的經紀人聯(lián)系信息必須被輸入和存儲在系統(tǒng)數據庫150中；幫助臺人員將利用這個數據來為了信用問題而聯(lián)系經紀人。為了完成建立新發(fā)起經紀人的過程，優(yōu)選地執(zhí)行下面的步驟。
●經紀人必須建立FIX連接以接收所有執(zhí)行的完結拷貝。如果經紀人也被用作客戶的OMS的服務機構并且代表客戶發(fā)送票據，則這同一連接也將用于到客戶的FIX連接。
●建立包含每個交易的細節(jié)的、來自系統(tǒng)的一日末尾的文件傳輸，包括每個交易的購買方客戶的身份。
●可選地，使用銷售方交易細節(jié)來在一日的末尾建立向經紀人的結算公司的一日末尾的文件傳輸。
還使得操作員能夠增加或去除來自被支持用于交易的證券列表的證券。所述證券優(yōu)選地與本發(fā)明特有的參數值相關聯(lián)，諸如大巨額證券數量和由分析服務器160用來計算巨額證券價格范圍的參數。在下面的表中給出了證券的一組必需字段的示例。


系統(tǒng)操作。在所述優(yōu)選實施例中的系統(tǒng)優(yōu)選地包括操作控制臺，用于提供服務器、網絡硬件和交易的集中管理。用于支持所需要的功能的操作軟件在最小地提供了下面的特征的版本上可購得●實時顯示所有服務器統(tǒng)計●問題總結●問題解決反饋●遠程管理/監(jiān)控●智能通知系統(tǒng)(警報)●警報顯示、確認和注釋●可聽見的警告●日志記錄●在線幫助操作員控制臺使得系統(tǒng)操作員可以執(zhí)行下面的遠程操作●系統(tǒng)啟動●系統(tǒng)重啟●系統(tǒng)關閉●系統(tǒng)部件重啟●系統(tǒng)部件關閉●系統(tǒng)部件啟動●系統(tǒng)備份●數據庫備份●內部一日啟動/關閉●一日末尾復位●執(zhí)行一日末尾的批處理所述系統(tǒng)另外使得操作人員能夠在一日的末尾產生每日的使用報告，并且從它們提取用于開賬單、研究、結算和OATS報告的必要信息。
操作人員優(yōu)選地還使用系統(tǒng)操作工具來創(chuàng)建結算總結，它包含具有交易雙方的經紀人ID的交易列表。與發(fā)起經紀人及其結算公司相關聯(lián)的交易總結包含所有的交易，其中，至少給定的經紀人發(fā)起了所述交易方之一。
所述系統(tǒng)優(yōu)選地還生成賬單報告，其包含涉及發(fā)起經紀人的所有填單的列表，以發(fā)送到所述經紀人。所述填單應當一對一地匹配日內的執(zhí)行報告。一日末尾的報告另外包含在日內報告中被屏蔽的客戶ID。如果由同一經紀人發(fā)起了交易的兩個分支，則將在總結文件中有兩個填單報告。
所述優(yōu)選實施例將下述的數據的兩個拷貝存儲到可移動介質以歸檔和分析。每當可能時，事件的日志記錄包含具有微秒精度的日期-時間戳。
●系統(tǒng)和應用程序日志在每個機器上的應用程序和系統(tǒng)日志被標注和保存。優(yōu)選地在一日的開始之前復位所述日志。
●配置審計記錄固件配置的一日開始和一日末尾的審計的細節(jié)(NT注冊表、應用程序配置等)。
●ACT消息應當有包含所有ACT消息的細節(jié)的獨立日志。優(yōu)選地在一日的開始之前復位這個日志。
●訂單和交易訂單和交易表在一日的末尾被復制到可移動介質。維護關于訂單狀態(tài)轉變的細節(jié)的獨立日志。優(yōu)選地在一日的開始之前復位日志和表。
●操作行為影響系統(tǒng)行為的操作員行為被記錄。所述記錄被標注時間戳，并且包括操作員的身份。優(yōu)選地在一日的開始之前復位這個日志。
優(yōu)選地在每個交易日的末尾將所有的系統(tǒng)行為日志和每日報告移動到永久存儲器。系統(tǒng)行為日志包含用于構造每個訂單和交易事件的交易邏輯和定價的足夠信息，包括解決價格爭議所需要的時間戳。
優(yōu)選地將系統(tǒng)配置為在偶然出故障的情況下使用基于下述考慮的處理而自動恢復服務。
●GUI的丟失。GUI 20是Cloud9服務的必需通道。如果網絡服務器110檢測到丟失了與客戶的連接，則在所述優(yōu)選實施例中，所有的訂單被自動取消，并且系統(tǒng)使用具有被取消的訂單的任何交易者的電話號碼向幫助臺人員產生警報。GUI 20將訂單狀態(tài)示出為“取消掛起”。在重新連接時，訂單狀態(tài)被更新為“被取消”。交易者可以拉出由于連接故障而被取消的訂單的列表，并且重新激活這些訂單；所述系統(tǒng)將它們當作新訂單，并且相應地處理它們。在一個替代實施例中，使得用戶能夠選擇一種配置，其中，他們的訂單在丟失與GUI的連接時將不被取消；在這個實施例中，用戶將調用幫助臺以當不能恢復連接時取消訂單。
●FIX的丟失。FIX連接丟失優(yōu)選地不導致訂單的取消，因為FIX不是通過其來管理可執(zhí)行訂單的通道。在丟失FIX連接時必須向操作員發(fā)出警報。在重新連接時，F(xiàn)IX客戶將按照FIX協(xié)議要求與服務器重新同步。在一個替代實施例中，可以使用FIX來在系統(tǒng)中輸入可執(zhí)行的訂單，并且所述系統(tǒng)支持一種配置，所述配置使得用戶能夠請求在丟失FIX連接時自動取消他們的訂單。
●分析服務器。如果分析服務器160停工，則在所述優(yōu)選實施例中的所述系統(tǒng)將繼續(xù)起作用，但是不能獲得由幫助器通常實現(xiàn)的功能的益處，諸如新積極符號消息或相對方存在消息。GUI 20還將不能接收報價更新和BPR更新消息。如果分析服務器160不能迅速地返回在線，則系統(tǒng)操作員可以指令將所述系統(tǒng)置于離線狀態(tài)中，其中，它拒絕任何進一步的訂單輸入，但是不取消現(xiàn)有的訂單。這些解決方案被描述為諸如在本發(fā)明中的交易系統(tǒng)之類的交易系統(tǒng)如何處理可靠性問題的示例，但是其他的解決方案容易由本領域的技術人員理解。例如，一種替代的方案是認為分析服務器160是重要的服務，并且在停工時自動將系統(tǒng)離線和取消所有的訂單。
●網絡服務器、訂單管理器和幫助器。這些服務與交易系統(tǒng)的重要功能緊密相關聯(lián)。因此，在所述優(yōu)選實施例中，將這些服務的故障認為是致命的；操作員將試圖在執(zhí)行引擎中取消所有的訂單，或者當檢測到連接丟失時自動取消這些訂單。Cloud9系統(tǒng)在檢測到這些服務的任何一個出故障時自動進入離線狀態(tài)。
通過系統(tǒng)管理控制臺來不斷地監(jiān)控所述系統(tǒng)的完整性，系統(tǒng)管理控制臺在獨立的系統(tǒng)上持續(xù)地運行，如果在交易日期間的任何時間，所述系統(tǒng)的完整性變得不確定，則所述系統(tǒng)自動切換到離線模式。此時取消所有的訂單。拒絕所有的另外訂單，直到所述系統(tǒng)返回到全工作狀態(tài)。
系統(tǒng)施加的符號積極標志在一個替代實施例中，所述系統(tǒng)自動地在所宣告的時間將所有的被觀看證券設置為積極狀態(tài)，并且在15分鐘的窗口內將這些符號保持積極。例如，所述系統(tǒng)可以在11:50將所有被查看的符號設置為積極狀態(tài)，并且將它們保持積極直到12:05。這個采用積極窗口的替代實施例有助于幫助將交易者的注意力聚焦于給定的時間，并且允許交易者參加而不會對于發(fā)出導致符號變?yōu)榉e極的第一訂單感到合意。它還通過限制交易者預期要向GUI 20貢獻空間的時間量而幫助交易者管理在它們的工作站屏幕上的空間。最后，通過利用由于POSIT匹配系統(tǒng)的市場化存在因此已經被交易者公知為與巨額證券交叉相關聯(lián)的調用窗口，這個替代實施例可以利用這樣的事實交易者已經用于查看此時的巨額證券交叉機會，并且聚焦于符號在Cloud9中的流動性，其中多個交易者正在觀看GUI 20。
在積極窗口終止時，符號的積極行為狀態(tài)返回到基于所述優(yōu)選實施例的描述而將呈現(xiàn)的狀態(tài)。因此，如果在所述積極窗口終止時，對于給定的符號在所述系統(tǒng)中有打開或近期取消的訂單，則所述符號將保持積極；未看見訂單行為的其他符號將返回到“被查看”狀態(tài)。只要符號保持在積極狀態(tài)中，則交易者可以連續(xù)地發(fā)出新訂單，其中這個操作不導致符號改變行為狀態(tài)。對于流動性很強的符號，這會潛在地導致符號保持處于積極狀態(tài)到交易日的末尾。在這個模式中，所述系統(tǒng)將通過相對方存在標志而使交易者聚焦于價格上，但是對于在時間上聚焦，則沒有進一步的需要。
被觀看的符號標志在一個替代實施例中，所述系統(tǒng)如同在所述優(yōu)選實施例中那樣，但是另外當至少兩個交易者觀看符號時向用戶指示。如果所述符號在他們自己的觀看列表上，則當有至少另一個交易者感興趣于所述符號時，他們將看見。例如，在交易者的觀看列表上的被觀看符號出現(xiàn)在用戶界面的頂部上的灰色框1020中，這類似于橙色積極符號標志1005和黃色相對方存在標志1010，如圖10所示。
其目的是向交易者提供提高填單的可能性的條件信息。當符號被觀看時，填單率將預期更高，因為至少一個交易者將在訂單輸入時看見符號變得積極。
當然，在他的或她自己的觀看列表上具有被觀看符號的交易者可以總是簡單地通過從他的觀看列表去除所述符號而發(fā)現(xiàn)是否除了他之外還有一個或兩個另外的交易者。為了使得系統(tǒng)更加用戶友好，一個替代實施例還在這種情況下向交易者示出是有一個另外交易者還是有兩個另外交易者正在觀看。這可以通過在被觀看的符號名稱旁邊的星號來完成，以便指示何時僅有一個另外交易者正在觀看。
在一個替代實施例中，所述系統(tǒng)向用戶示出在任何時間觀看這個符號的交易者的數量。
在計數正在觀看證券的交易者的數量時，系統(tǒng)優(yōu)選地查找實際上能夠看見積極符號標志的交易者。在一個實施例中，這是通過僅僅計數未被最小化和沒有被檢測為隱藏在另一個應用程序后面的GUI來實現(xiàn)的。例如，當接收到新積極符號或相對方存在消息時，在交易者的屏幕底部的托盤(tray)中的最小化條將以橙色或黃色閃動，并且示出與最近的這樣的消息相關聯(lián)的符號。
在另一個替代實施例中，不顯示觀看這個符號的交易者的數量，但是交易者可以在輸入訂單時知道觀看的交易方的數量。在其中交易者不知道是否符號被觀看直到提交訂單的這個替代實施例中，交易者還可以檢查“自動取消”框以請求如果沒有其他的交易者正在觀看符號則自動取消他的訂單，因為在這種情況下沒有人能夠看見積極符號標志并且填單率將非常低。在另一個替代實施例中，使得交易者能夠選擇應當正在觀看的交易者的最小數量，并且如果觀看交易者的實際數量更少，則自動取消訂單。
具有系統(tǒng)生成的調用(call)的替代實施例大巨額證券交叉系統(tǒng)的公知問題是大購買者和大銷售者同時輸入訂單的低可能性。本發(fā)明的大部分涉及在第一交易者已經輸入訂單后解決這個問題，但是它本身不提供關于何時應當最大激勵這個第一參與者發(fā)出訂單的指南。
在一個替代實施例中，所述系統(tǒng)如上所述操作，并且還產生系統(tǒng)產生的“調用”事件，其將交易者的興趣聚焦于對于證券存在購買和銷售意向的指示的時候。在另一個替代實施例中，不發(fā)送積極標志，并且所述調用僅僅是時間聚焦事件。優(yōu)選地經由一種算法來調度所述調用，所述算法確定何時填單的可能性最高。優(yōu)選地不使用未結算的交易信息(諸如在沒有任何銷售者的情況下披露購買意向的存在)，以便避免感知到信息泄露，由此交易者將感知到他們已經在系統(tǒng)中發(fā)出的訂單正在引起他們不能直接控制的不需要的信息事件。
所述調用的目的是當填單的可能性最大時吸引來自交易者的訂單輸入。例如，如果對于給定的證券發(fā)出訂單的第一交易者的平均填單率是5％，則當對于所述證券打開調用時的填單率可以是10％或15％；相反，當沒有調用時的填單率將低于5％；并且與任何調用無關地，對于在隨機時間發(fā)出訂單的交易者來說，整體平均值是5％。
作為最低限度，當在兩方都相互缺少交易者時，所述系統(tǒng)將產生調用以聚焦證券的訂單輸入。下面概述了用于產生調用的其他機會。為了避免信息泄露問題，這些調用將與BPR更新一起而不是與訂單輸入事件一起被報告。在一個替代實施例中，在半小時中發(fā)出它們，以進一步提高交易者的聚焦。

用于產生調用的算法優(yōu)選地基于下面的原理。
●在訂單輸入時不被觸發(fā)。調用將隨著BPR更新而被定時。這消除了如果交易者要看見他自己的訂單立即引起調用則發(fā)生的信息泄露的擔憂。
●1分鐘最小壽命。一旦已經啟動了調用，則它將保持打開長達足夠的時間，以使得交易者反應和響應于所述調用。
●兩方的。只有在兩方都有巨額證券意向的證據才發(fā)出調用。這降低了可能的賭博。
●對于訂單而言不一定。當在所述系統(tǒng)中沒有積極訂單時可能產生調用。這再次減輕了賭博問題。
●不公開的規(guī)則。再次減輕了賭博問題。而且允許更新算法(在上述規(guī)則的范圍內)，并且調整其保持合理的調用頻率。
優(yōu)選地可以獲得下面的數據以便確定何時應當產生調用。
●具有剩余數量的票據。
●打開訂單。
●過期訂單。
●交易。
●在記錄帶上的巨額證券刊載。
●使用異常高的容量在記錄帶上重復刊載。
用于發(fā)出調用的基于規(guī)則的方法第一替代實施例利用用于確定何時應當發(fā)出調用的基于規(guī)則的方案。對于每個符號，與BPR更新處理一起執(zhí)行行為評估處理。
如果尚未存在調用，則優(yōu)選地，應用下面給出的規(guī)則，以根據在系統(tǒng)(訂單，交易等)中和在市場上的行為來確定是否應當調用符號。如果任何布爾規(guī)則為真，則將調用所述符號。
如果符號已經被調用、已經被調用至少<60>秒(可配置的全局參數)并且在證券中沒有相對方存在標志，則系統(tǒng)優(yōu)選地去除所述調用。
下面以項目符號列出了導致調用的規(guī)則。
○訂單被輸入和已經過期。以后，在相對方輸入另一個訂單。在下一個BPR刷新時間，檢查是否已經在最后30分鐘(可配置的ActiveMaxDelayl)中針對這個符號投出(post)了調用，如果否定，則與新的BPR一起針對這個符號投出所述調用。
○訂單被輸入和已經過期。以后，在記錄帶上檢測巨額證券刊載(大于10000股或250,000美元，同樣地，它們全都是可配置的參數)，并且已經在最后90分鐘中針對這個符號投出了所述調用(可配置的ActiveMaxDelay2)。
○自行處理幫助臺操作員鍵入符號，并且點擊按鈕。
○訂單被輸入，并且在相對方存在票據。
○在已經在最后<30>分鐘內交易的符號中輸入訂單。
○常駐訂單被消極地定價，并且在BPR內的新訂單已經到達。
○常駐銷售訂單在BPR內，并且在記錄帶上檢測到重復的刊載，用于指示對于一巨額證券大小的賣方索價的集體購買。
上述列表意欲用于說明，并且不意欲是窮盡的。本領域的技術人員可以容易地理解可用于識別何時有更大的交易可能性的其他規(guī)則。
用于發(fā)出調用的計分功能方法具有調用的另一個替代實施例使用計分功能來確定何時產生調用，如下所述。
對于每個符號，與BPR更新處理一起執(zhí)行調用評估處理。如果在這個符號中當前有調用，則系統(tǒng)計算所述符號的行為分數和閾值，如下所述。如果所述分數超過所述閾值，則系統(tǒng)優(yōu)選地生成針對這個符號的調用。
如果符號已經被調用，符號已經被調用至少<60>秒(可配置的全局參數)并且在證券中沒有相對方存在標志，則所述系統(tǒng)優(yōu)選地去除所述調用。
所述系統(tǒng)優(yōu)選地經由兩個步驟來計算計分功能。
步驟1通過加上與下面的條件相關聯(lián)的加權而計算證券的購買方意向和銷售方意向。
●OpenOrderCondition(打開訂單條件)。當前打開和在BPR內定價的購買(銷售)訂單。
●PassiveOrderCondition(消極訂單條件)。當前打開但是比BPR更消極地定價的購買(銷售)訂單。
●ExpiredOrderCondition(過期訂單條件)。自從符號最后積極以來過期的購買(銷售)訂單。
●TicketCondition(票據條件)。具有剩余數量的購買(銷售)票據。
●BlockTapeCondition(巨額證券記錄帶條件)。自從符號最后積極以來在Cloud9上的大巨額證券填單。
●MarketPrintCondition(市場刊載條件)。對于至少<BlockQty＝10000>股或<BlockValue＝$250,000>的在記錄帶上的巨額證券刊載，其在中點之上(之下)被刊載，自從最后的BPR更新以來發(fā)生。
●RandomRefreshCondition(隨機刷新條件)。自從最后的BPR更新以來的在中點之上(之下)的重復刊載，其中總數量在<BlockQty＝10000>股或<BlockValue＝$250,000>之上，速率超過<LiquidityRatio＝2>乘以證券的平均容量。
●WatchListCount(觀看列表計數)。在交易者的觀看列表上具有這個符號的所述交易者的數量。
下表給出了加權的合理配置的示例。

步驟2作為購買方意向與銷售方意向的乘積計算符號行為分數。
所述系統(tǒng)優(yōu)選地如下計算閾值。如果從未調用符號，則所述閾值等于0。如果先前已經調用了符號，則這個符號的閾值將等于在這個符號中過期的、自從最后調用以來的時間的指數函數Threshold(閾值)＝MaxThreshold*EXP(-Beta*TimeDelay)參數MaxThreshold和Beta優(yōu)選地對于每個證券是可配置的。
具有目標積極符號消息的替代實施例在一個替代實施例中，除了積極符號消息不被發(fā)送到已經將符號置于他們的觀看列表上的所有交易者之外，所述系統(tǒng)如上所述操作；相反，該標志僅僅被發(fā)送到已經提供了已證明的交易意向信息的交易者，所述信息指示購買或銷售這個證券的大巨額證券的可能意向。例如，這樣的已證明的交易意向信息可以是經紀人在每個交易之后而發(fā)出的執(zhí)行報告的完結拷貝，并且選擇標準可以是公司已經在最后30分鐘內凈購買(凈銷售)至少10,000股的股票。在下面的共同未決的美國專利申請中廣泛地說明了其他示例2000年6月1日提交的09/585,049、2000年12月29日提交的09/750,768和在2001年5月31日提交的09/870,845，其中每個的全文通過引用被并入在此。
具有系統(tǒng)提出的匹配價格的替代實施例在上述優(yōu)選實施例中，交易者本身設置他們的訂單上的價格條件，該價格條件將確定執(zhí)行價格，而無需他們這一方的進一步干涉。
在他們的當前工作流中，機構交易者習慣于向經紀人發(fā)送市場訂單，并且接受或拒絕經紀人可以提出來用于執(zhí)行大巨額證券的價格。在這個意義上，可以認為，機構交易者是價格“接受者”而不是價格“建立者”。
電子交易系統(tǒng)具有下面問題輸入訂單的第一方正在寫入其他方可以選擇接受或不接受的價格；因此導致不利選擇問題，其中，當他們犯錯誤并且提供了太積極的價格時，他們的價格往往將被接受。通過向第二訂單的限制提供長期有效訂單改進、或者如果價格交叉則使兩者中途相遇來違反價格優(yōu)先級的企圖不起作用，因為這樣的規(guī)則僅僅使得第二訂單以消極訂單開始，然后漸進地提高價格積極性，直到在長期有效訂單的限制處發(fā)生匹配。
下述的替代實施例的目的是通過下述方式來解決這個問題通過使系統(tǒng)生成所提出的匹配價格，它不敏感于系統(tǒng)中的現(xiàn)有訂單的價格。
在本發(fā)明的這個替代實施例中，所述系統(tǒng)對于限制訂單和釘住訂單如上所述執(zhí)行，但是另外使得交易者能夠輸入新訂單類型——在此我們將其稱為“市場訂單”。市場訂單也可以可選地具有絕對限制價格，所述絕對限制價格繼而可以被固定或釘住到市場指標，諸如國家最佳買方出價或賣方索價的中點。
將如下處理輸入的市場訂單。
在接收到市場訂單時，如果當前沒有相對方訂單常駐在系統(tǒng)中，則它僅僅存儲市場訂單。如果有常駐的相對方訂單，則系統(tǒng)將通過在具有統(tǒng)計分布的BPR內的價格來隨機地確定可能的交易價格，所述統(tǒng)計分布諸如平坦分布(所述平坦分布是其中在BPR內的所有價格點等同可能地被選擇)。在另一個示例中，所提出的交易價格敏感于在系統(tǒng)中的訂單，并且用戶通過允許系統(tǒng)使用訂單信息來確定公平價格而服從于公平仲裁。例如，這樣的一個實施例可以根據不平坦而是分段平坦的分布來生成隨機的價格，其中兩個平坦段在BPR中點之上和之下，以便當在系統(tǒng)中存在比購買訂單更多的銷售訂單時向BPR中點之下的價格給予更大的概率，或者如果有更多的購買者，則反之。例如，可以使BPR中點之下的價格的概率等于P(低于中點)＝1/(1+EXP(Gamma X))，其中，Gamma是諸如2的正數，并且X是在BPR內定價的購買者股數和銷售者股數之間的相對差X＝(購買數量-銷售數量)/(購買數量+銷售數量)。因此，如果有比銷售意向更多的購買意向，則X→1，而在相反情況下，X→-1。用于生成價格的方法的這些示例意欲用于說明的目的，而不是作為窮盡的列表；本領域的技術人員可以容易地明白用于生成價格的其他機制。
已經確定了可能的交易價格時，系統(tǒng)將繼續(xù)按照下面的邏輯來確定在此價格的交易的可行性。
1.如果隨機生成的價格在兩種訂單的限制內，則以這個價格來執(zhí)行交易，而不需要來自任何一方的進一步輸入。
2.如果沒有一個訂單能夠接受所提出的隨機產生的價格，則向兩方交易者提出這個價格，然后向他們提供其中接受或拒絕該價格的時間窗口。例如，時間窗口可以與BPR刷新時間或最小15秒當中的較長者同步。在這個時間窗口過期時，與新的BPR一起產生新隨機生成的價格，并且只要具有在BPR內的雙方的訂單，則這個處理繼續(xù)。
3.如果一個訂單的限制價格足夠積極以接受所提出的交易價格但是另一個訂單不是這樣，則將向較積極的交易者建議對于交易不足夠積極的訂單的價格，并且將向較不積極的交易者示出所述隨機生成的價格。任何交易者都將不知道他們正在觀看的價格是另一個交易者的限制還是隨機生成的系統(tǒng)價格。在時間窗口過期時，產生新價格，并且只要具有在BPR內的雙方的訂單，則這個處理如上所述繼續(xù)。
在一個替代實施例中，當僅僅一個交易者的限制與系統(tǒng)生成的價格重疊時，這個交易者可以選擇接受另一個交易者的限制或向較不積極的交易者提出還價。在這個實施例中，較不積極的交易者沒有看見價格，直到第一交易者采取行動或30秒的時間窗口過期。較積極的交易者可以在這個30秒窗口內取消它的訂單，而不在任何點向其他交易者披露其存在。如果第一交易者不采取任何行動，則所述系統(tǒng)在30秒后自動地向第二和較不積極的交易者示出系統(tǒng)生成的價格。這個延遲覆蓋了向所述優(yōu)選實施例的常駐訂單立即顯示相對方存在標志。
競爭存在標志在本發(fā)明的一個替代實施例中，所述系統(tǒng)像如同在所述優(yōu)選實施例中那樣執(zhí)行，但是另外提供一種使得交易者知道何時有購買(銷售)證券的競爭的機制，從而誘使他們提高他們的價格積極性，由此還促進發(fā)現(xiàn)公平交易價格的處理。
在使用競爭存在標志的第一替代實施例中，所述系統(tǒng)簡單地使得已經看見相對方存在標志的、在系統(tǒng)中具有訂單的每個交易者知道是否在同一方有其他訂單。
在具有競爭存在標志的第二替代實施例中，所述系統(tǒng)如同在剛才所述的第一替代實施例中那樣執(zhí)行，但是另外使得具有基于價格和時間優(yōu)先級排名的較低匹配優(yōu)先級的交易者能夠看見其他交易者具有更高的匹配優(yōu)先級；因而使得這個交易者提高他的訂單的價格積極性。如果這變?yōu)樾碌淖罡咂ヅ鋬?yōu)先級訂單，則其他交易者將繼而被允許看見他的價格不再是最佳的。只要在一個環(huán)境中在同一方具有多個訂單，并且存在一個或多個相對方，這個處理就繼續(xù)。
工作訂單和與第三方執(zhí)行系統(tǒng)的集成在一個替代實施例中，所述系統(tǒng)如上所述操作，但是另外使得用戶能夠請求在等待在Cloud9中的匹配的同時他們的訂單在市場上工作。
優(yōu)選地要求請求工作訂單選項的用戶輸入大于最小巨額證券數量的訂單數量。附加的大小將以在本領域內被稱作“隨機刷新”訂單的方式、通過自動化處理而被分派以便工作，所述自動化處理自動地將小片斷置于常規(guī)市場上。今天，可以在市場上獲得幾個這樣的自動化處理；本領域公知的一些自動化處理是隨機刷新算法，其在市場上以最佳的價格發(fā)出小數量的股，并且每當所述小數量用盡時，生成要以新最佳價格來發(fā)出的新小訂單。在最小和最大大小之間，例如在500和900股之間隨機選擇被刷新的數量。在另一個示例中，在幾秒的隨機延遲后刷新訂單。可以購得其他更復雜的算法以通過將其縮小到獨立執(zhí)行的小片斷而自動化訂單的執(zhí)行，諸如ITG的Quantex。諸如NyFIX Millennium之類的其他目的地使得完全隱藏的訂單能夠攔截在到第三市場目的地的途中的訂單流。
在此所述的替代實施例還管理在除了Cloud9之外的一個或多個工作訂單目的地上的訂單。在這個實施例的一個版本中，所述系統(tǒng)將訂單劃分為幾個組塊(chunk)，在Cloud9上發(fā)出具有大巨額證券數量的訂單；將具有系統(tǒng)可配置的數量(例如5000股)的其他訂單傳送到能夠操作訂單的外部目的地。每當目的地完成了其巨額證券時，系統(tǒng)確定是否在執(zhí)行系統(tǒng)中已經發(fā)出的數量之外還有剩余的數量，并且如果如此則向已經完成其巨額證券的目的地發(fā)送系統(tǒng)可配置的數量或可用的余值當中的較小者。當一個外部目的地已經完成了組塊并且沒有留下剩余的數量，但是在其他市場目的地上仍然有未完成的巨額證券時，則取消花費了最長時間而沒有接收到填單的未完成巨額證券，并且將其重新傳送到報告已經完成其巨額證券的目的地。當除了Cloud9上的大巨額證券數量訂單之外在任何地方都沒有另外的未完成巨額證券時，系統(tǒng)向用戶的GUI 20發(fā)送消息以通知已經完成了工作訂單分量。然后，交易者可以發(fā)出另外的股以恢復操作訂單，或者將大巨額證券數量本身轉換為工作訂單。
在這個替代實施例中，當在Cloud9中剩余的數量已經降到低于巨額證券數量時，所述系統(tǒng)優(yōu)選地去除所述訂單而不考慮分配標志。在另一個替代實施例中，在Cloud9中的剩余大小可以降低到低于大巨額證券數量，并且保持訂單的效力以保持積極符號標志。在這個實施例中，如果價格要交叉(例如，如果一個訂單被釘住到NBBO中點，并且另一個是限制訂單)，也已經選擇了工作訂單選擇的第二方可以接收針對這個Cloud9的部分填單。如果兩個工作訂單的Cloud9限制價格交叉，則所述系統(tǒng)優(yōu)選地試圖拉回被傳送到第三方目的地的所有訂單，以最大化可以在內部交易的大小。來自這個匹配事件的余值隨后被重新分配到外部目的地。在另一個替代實施例中，任何交易者可以檢查一個框以指定他們愿意從工作訂單上的余值接收部分填單，并且可以可選地指定這樣的填單必須滿足的最小數量。
在另一個替代實施例中，在可預期填單的目的地發(fā)出有傾向(liable)的巨額證券訂單的同時，以暫停的狀態(tài)在執(zhí)行引擎中發(fā)出在所述系統(tǒng)內輸入的訂單。例如，可以在巨額證券以暫停狀態(tài)保持在Cloud9上的同時，將所述巨額證券置于POSIT上，以便進行有計劃(scheduled)的交叉。所述系統(tǒng)優(yōu)選地保持在Cloud9上的暫停訂單對于積極符號標志而言的效力。在輸入相對方訂單時，這個替代實施例的系統(tǒng)優(yōu)選地通過試圖取消外部訂單而拉回所述傾向(liability)。當這個取消成功(還沒有填寫訂單)時，如同在所述優(yōu)選實施例中那樣發(fā)送相對方存在標志。
雖然在此示出和描述的實施例完全能夠實現(xiàn)本發(fā)明的目的，但是顯然地，根據上述描述，多種替換、修改和改變對于本領域的技術人員是顯而易見的。這些替換、修改和改變在本發(fā)明的范圍內，并且應當理解，在此所述的實施例僅僅被示出用于說明的目的，而不是用于限制的目的。
權利要求
1.一種用于幫助在計算機系統(tǒng)上交易證券的方法，包括以下步驟從第一用戶電子地接收證券的第一購買或銷售訂單；確定所述第一訂單被合理地定價；向第二用戶發(fā)送所述證券的合理定價的訂單存在的電子通知，但是不向所述第二用戶通知所述第一訂單的交易方；從所述第二用戶接收第二訂單，其中，所述第二訂單是與所述第一訂單相對的，并且在價格上足夠地積極以交叉所述第一訂單；以及以所述第一訂單的限制價格來執(zhí)行包括所述第一訂單和所述第二訂單的交易。
2.如權利要求1所述的方法，其中，確定所述第一訂單被合理定價的所述步驟包括計算巨額證券價格范圍。
3.如權利要求2所述的方法，其中，計算巨額證券價格范圍的所述步驟基于近來或當前的市場價格。
4.如權利要求2所述的方法，其中，計算巨額證券價格范圍的所述步驟基于所述證券的近來變動性。
5.如權利要求2所述的方法，其中，如果所述第一訂單被定價為至少與所述巨額證券價格范圍的消極端一樣積極，則所述第一訂單被確定為合理定價。
6.如權利要求2所述的方法，其中，計算巨額證券價格范圍的所述步驟包括預測有可能在第一預定時間段中發(fā)生的價格范圍。
7.如權利要求6所述的方法，其中，以大致等于所述第一預定時間段的時間間隔來重新計算所述巨額證券價格范圍。
8.如權利要求1所述的方法，其中，確定所述第一訂單被合理定價的所述步驟包括如果所述第一訂單是購買訂單，則將所述第一訂單的限制價格與國家最佳買方出價相比較，并且如果所述第一訂單是銷售訂單，則將所述第一訂單的限制價格與國家最佳賣方索價相比較，其中，當接收到所述第一訂單時，確定所述國家最佳買方出價或國家最佳賣方索價，并且其中，由于所述第一訂單的限制價格處于所述限制價格所比較的所述國家最佳買方出價或國家最佳賣方索價的預定數量的百分比或百分比分數內，因此將所述第一訂單確定為被合理定價。
9.如權利要求1所述的方法，還包括在接收到所述第二訂單后，向所述第二用戶發(fā)送電子相對方訂單通知，所述相對方訂單通知指示在所述系統(tǒng)內近乎匹配的相對方訂單是積極的。
10.如權利要求9所述的方法，其中，所述第二用戶僅僅在過去了第二預定時間段后接收所述相對方訂單通知。
11.如權利要求1所述的方法，還包括在接收到所述第二訂單后，向所述第一用戶發(fā)送電子相對方訂單通知，所述相對方訂單通知指示在所述系統(tǒng)內近乎匹配的相對方訂單是積極的。
12.如權利要求11所述的方法，其中，所述第一用戶在接收到所述第二訂單后立即接收所述相對方訂單通知。
13.一種用于幫助證券交易的電子系統(tǒng)，包括交易幫助系統(tǒng)；金融信息交換網絡，與所述交易幫助系統(tǒng)通信；通信網絡，與所述交易幫助系統(tǒng)通信；一個或多個用戶終端，與所述通信網絡和所述金融信息交換網絡通信；以及執(zhí)行引擎，與所述通信網絡通信；其中，所述交易幫助系統(tǒng)包括幫助模塊、金融信息交換服務器、事務數據庫和分析服務器。
14.如權利要求13所述的系統(tǒng)，其中，所述分析服務器通過將所述訂單的價格積極性與所述訂單所涉及的證券的巨額證券價格范圍相比較而評估從所述用戶接收的證券訂單。
15.如權利要求14所述的系統(tǒng)，其中，要求所述訂單是大于由經紀自營商接收的平均大小訂單的巨額證券大小的倍數。
16.如權利要求14所述的系統(tǒng)，其中，所述分析服務器根據近來的市場價格和所述證券的變動性來計算所述巨額證券價格范圍。
全文摘要
一種用于幫助在計算機系統(tǒng)上交易證券的方法，包括從第一用戶電子地接收證券的購買或銷售訂單；確定該訂單被合理地定價；向第二用戶發(fā)送該證券的合理定價的訂單存在的電子通知，但是不向該第二用戶通知該第一用戶的訂單的交易方；從該第二用戶接收第二訂單，其中，該第二用戶的訂單是與該第一用戶的訂單相對的，并且在價格上足夠地積極以交叉該第一用戶的訂單；并且以該第一用戶的訂單的限制價格執(zhí)行包括該第一用戶的訂單和該第二用戶的訂單的交易。還描述了一種用于幫助證券交易的電子系統(tǒng)，其包括幫助模塊、金融信息交換服務器、事務數據庫和分析服務器。
文檔編號G06Q40/00GK1853193SQ200480017566
公開日2006年10月25日 申請日期2004年6月22日 優(yōu)先權日2003年6月24日
發(fā)明者亨里·維爾布羅伊克, 弗雷德·J·費德斯皮爾, 約翰·E·洛佩茲 申請人:傳送金融集團股份有限公司