CN101194284A - 基于规则的证券订单处理 - Google Patents

Abstract

通过规则引擎(140)对证券交易执行和资产运作请求的订单进行鉴别以自动批准。规则引擎(140)具有用户可配置的规则。规则提供不同的结果，以向用户提供应用的可选范围，并向用户提供可选参数。为了增加范围，对照可用的规则设置来处理交易。先处理适用于账户级别的规则，然后处理适用于注册代表(111)、办公室、或公司(110)的规则。

Description

基于规则的证券订单处理

相关申请参考引用

在此公开的本发明与Syed K.Quraishi等人于2000年4月7日提交的、题目为Rules Based Order Processing(基于规则的订单处理)、申请号为No.60/195,196的、待审的美国临时专利申请相关，并要求其优先权。上述申请被引入本文作为参考。

计算机程序清单附录

在CD-ROM中包括计算机程序清单附录，其内容包括多个文件，在此完全引入上述文件。

发明背景

发明领域

在此公开的本发明涉及计算机系统，更具体的说，涉及用于订单执行和资产运作处理的基于规则的系统。

背景技术

在证券业中，传统的处理订单的方法是用于客户打电话给他的证券经纪人的情况。通常在这种情况下，该证券经纪人与证券商公司进行联系，而该证券商公司在各种贸易交换现场都有职员或与职员联系的途径。客户的订单由为他工作的注册代表来审阅，并且在把该用户订单传送到正确的交换现场专家那里执行之前，该订单在该注册代表的公司里面会进行多次审阅。

最近，已经建立了许多在线贸易公司，这些公司允许客户使用他们的个人计算机来下订单，用以在象互联网那样的网络上执行。

在人工智能领域，在已知的基于规则的系统中，一个或者多个条件触发一个规则，导致该条件得出的想要的结果。

尚存在与现有的技术相关的许多问题。首先，证券贸易的管理环境非常复杂而且经常变化。为了实现与管理环境的一致，不同的证券公司具有不同的环境和不同的策略。当市场条件有利时，经常出现雇用注册代表，这导致了立即培训的问题。当市场条件不利时，规模减小导致责任的重新分配，这也需要对那些在规模减小中留下的特定个体进行新的培训。就如同涉及大量金钱的环境一样，总有潜在的欺诈行为。

发明内容

根据本发明，可以通过为客户订单和资产运作请求，特别是在证券业中，提供自动处理过程的技术来克服上述现有技术的问题。

根据本发明，这通过提供规则引擎来实现。设计和配置规则引擎，来(1)防止在订单处理、批准和执行过程中的问题；(2)确保与管理要求一致；(3)对于使用该规则引擎的不同证券商公司，实施不同的策略；并且允许证券商公司实时地、灵活地设置他们自己的适于该公司内部不同的管理等级级别的策略。

从下面结合附图对本发明的具体描述中，使本发明的前述的和其它的特点、方面和优点将变得更加明了。

附图简要说明

从下面的描述中，本发明的系统的目的、特点和优点将更加明了，其中，

图1是根据本发明的一个方面的订单管理系统的示意图。

图2是根据本发明的一个方面的规则引擎的示意图。

图3A和3B描述了根据本发明的一个方面的示例性规则格式。

图4是根据本发明的一个方面的用于设置图2中的规则引擎的流程图。

图5是规则分配更新处理的流程图。

图6是示例性的规则分配定义画面。

图7是示例性的规则代码定义画面。

图8是由如图7所示画面产生的规则的示例性参数画面。

图9是根据本发明的一个方面的用于规则处理的示例性过程的流程图。

优选实施例的详细说明

图1是根据本发明的一个方面的订单批准系统的示意图。网络100与多个证券商公司内部网络110相连，并具有通过通信界面130连接的规则引擎140。在这个例子中，规则引擎140服务于多个不同的公司，其中每个公司具有各自不同的策略和文化。典型的证券商公司具有多个注册代表111，注册代表111与客户112通信。在一些情况下，注册代表或者支援台的助理将访问证券商网络来帮助处理来自客户的订单安排或资产运作请求。

证券商公司可能具有多个办公室，其中每个办公室有一个主管113。在公司级别上，可能还有主管人员114负责所有的办公室。典型情况下，当公司策略规定的时候，在被发送给交易现场的专家执行之前，特定的交易将被发送给批准台115以得到批准。

与证券商网络相关的内部网络110具有作为到更大的网络110的接口的网关116。规则引擎140可能运行在服务局模式以为多个证券商公司提供服务，或者作为选择，规则引擎140可以在一个单独的证券商公司内部运行以在该公司内部自动化订单处理。

典型情况下，规则引擎140具有系统管理员141，系统管理员141将有权访问规则引擎系统的所有担保级别。一致管理员142可以服务于所有的证券商公司，或者作为选择，每个证券商公司可以有单独的一致管理员。

在这个例子中，多个数据库，即150-1、150-2、150-3、150-4、150-5、150-6和150-7提供规则引擎在执行订单或资产管理自动化时使用的信息。当天(Intra-day)PNB数据库150-1维持(交易)额度和资产(收支)差额信息，比如发生在一个交易日内的账户交易，从而使当前的信息总是对规则引擎可用。PONA数据库150-2是账户拥有者的姓名和地址的在线数据库。PROM数据库150-3是市场产品主数据库，它维持了最新的每个担保措施的信息，该信息可能对提交给规则引擎140的订单或者被规则引擎批准的交易是重要的。该数据库随时通过网络100获取当前的信息。MAXX数据库150-4是额度和资产差额信息数据库，它在每个交易日的结尾进行更新。KUST数据库150-5是表明对于特定的客户是否特定表格有案可查的文献数据库。这样的表格的例子可能是由客户签署的保证金协议。如果这样的协议有案可查，KUST数据库将反映这个事实。ACAM数据库150-6是在特定用户的账户里面可用的现金的参考。PCAT参考数据库包含账户正在处于证券商之间的传递模式的指示。

多个订单执行处理过程160可以用于以来自规则引擎140的不同类型的证券来接收被批准的交易订单。订户(SUBSCRIBE)订单执行系统160-1处理养老金交易。顶级(TOPS)订单执行系统160-2处理批准的证券和股票预购订单，并且也可能在多个交易所170执行交易。MIPS订单执行和处理系统160-4处理共有基金交易。AMPS过程165响应来自证券商公司的请求执行从一个账户到另一个账户的资金转账。

参考一个示例订单。最终用户112使用可用的电话系统117给他的注册代表111打电话并且下订单。注册代表和证券商公司1^#110相联系，证券商公司1^#将此订单通过网络100和通信界面130发送到规则引擎140以得到确认。确认过程将在后文详细描述。利用来自数据库150的信息，规则引擎将采取下文描述的动作。这些动作中的一个可以是自动批准处理订单，即通过将其发送到交易所或交易市场进行处理。如果是这种情况，规则引擎把这个订单发送到一个选择的订单执行处理过程160，然后通过网络100再被发送到交易所或交易市场170以执行。执行的结果返回并合并到数据库中。最终用户可以是个人或者机构。一些最终用户112’可能不通过注册代表而直接或者间接连接到证券商网络。

最终用户112或112’可能具有多个账户，而且有时可能请求从一个账户转移资产到另一个账户。该请求被发送到规则引擎140，并且如果该请求在受到规则分析后被批准，转账将使用AMPS处理过程165来执行。

规则引擎也可以对用户120提供服务，用户120可以是个人或者机构。

图2是根据本发明的一个方面的规则引擎的示意图。规则存储器200是存储器区域，其中存储单独的规则以用于评估提交的订单和其他交易请求。对规则的任何改变记录在日志处理过程210中。日志处理过程允许产生各种报告并且允许基于来自规则存储器的规则备份来恢复故障的或者崩溃的数据库。

规则管理处理过程220允许在实时的基础上创建和修改规则，并且允许在通常情况下由通过通信界面与规则引擎交互的授权用户来察看，下文将详细介绍。订单/交易处理230允许通过通信界面240接收的订单或交易服从规则的应用，其中所述规则涉及订单所来源的账户、注册代表、办公室和证券商公司。

规则引擎有选择地产生下列的审计报告。

规则分配报告列出了在相应的证券商公司的每个适用的级别上的分配或者未分配的规则。所述级别包括账户、投资专家(注册代表)办公室和公司。它列出对于证券商公司的规则引擎分配所作的任何改变、以及进行这种改变的个人的私人标识符。

规则日志文件列出相对于规则分配所作的任何改变。该报告反映了在改变之前和之后的分配级别，以及进行这种改变的个人的私人标识符和进行这种改变的时间。

每日订单日志对由规则引擎批准的订单以及那些没有被批准的订单提供查账索引文件证明。如果是第一笔交易，该报告详细记录了在下订单时客户账户中可用的资金；如果是最后一笔交易，该报告详细记录了可用的额度。

订单处理和执行日志详细记录了对于由规则引擎处理的订单的相关信息，该信息被发送到特定的订单和执行单元160来执行。该日志详细记录了是否规则引擎自动批准了该订单。它还详细记录了是否订单由于违反了一个或多个规则而需要额外的批准，并且同时列出被违反的规则。如果订单是手工批准的，该报告将指示批准该订单的个人的用户ID。

图3A和3B描述了根据本发明的一个方面的示例性规则格式。图3A示出了一个规则的例子，此规则停止了已经关闭了的账户的订单。这个例子显示了规则的编号、规则的类型、此规则可能被执行的可能级别、和对于此规则可用的可能结果。其他的字段是该规则常用的。这个规则非常简单，并且不具有图3B所示的规则的灵活性。

图3B显示的规则是这样一个规则，它显示了下的订单超过了由特定的证券商公司设定的信用限制参数。它也显示了规则编号1141和规则类型，但是在这里，可以为该规则设置四个可能的应用级别。特定的级别反映了不同范围的应用，即从最窄的账户级别到最广的账户级别(即公司级别)。除了能够为这个示例规则1141指定应用范围以外，还可以通过选择一个或者多个这里显示的可能结果来有选择地改变有关此规则的结果。在一些实施例中，当没有违反活动的规则时，缺省发生接收结果。

如上所述，特定规则的范围可以被设置为只适用于特定的账户、特定的注册代表、证券商公司的特定办公室、或证券商公司本身。也就是说对于特定的级别，规则的范围将适用于所有的交易，即根据所选择的范围，包括账户、注册代表、办公室或公司。

把规则集组成各自的类别是很方便的。这样的类别的例子包括：账户状态，账户限制，文档记录，代理商，保证金，优先购买权，订单大小、额度和收支差额，注册，折旧、股票监视、交易限制，抵押限制和适用性。

比如图3B所示的特定规则的应用可以具有由不同用户指定的结果。在这个例子中，可能结果包括停止、发送到批准列队、提供警告消息、和接受。例如，连同图3A一起讨论，基于已经关闭了的账户的订单应该被停止。如果一个人想要雇用新的销售代表，他可能想要预先通过把该销售代表的所有订单发送到批准列队来审阅。这样的规则可以被设置以具有上述结果，并最好在注册代表级别来设置。作为另外一个例子，如果特定的账户想要下订单并且该账户的资源已经用尽，基于提供给该账户的特定参数，一个警告消息可能是恰当的。在这个例子中，该结果应该施加到账户级别。最后，如果所有的规则适用于特定订单或者交易没有保留地被满足，则交易将被接受并被处理执行。

关于参数，可能伴随着特定规则的参数的例子将是交易限制，无论是金额数量作为参数、还是购买的有价证券作为参数。同样的，购买有价证券的订单可以被公司的监视列表检查，以考虑是否贴出警告消息。作为另外一个例子，对于购买廉价的有价证券，可能会有金额限制。每个这样的参数可以与特定的规则在任何特定级别上关联。

当前已经实现的完整的规则集包含在作为本说明书的附录A附加的CD-ROM上。

对于特定的范围(账户、注册代表、办公室或公司)，可以方便地使用工作表来列出每个规则，并且具有编号、规则名称、注释、规则类型(可选或强制)、缺省结果、以及允许结果的复核框和参数条目空白格，从而帮助证券商公司设置规则。

现在详细讨论规则管理过程220。与任何计算机系统相关的常规担保措施是可用的。分区的访问是强制性的，从而一个证券商公司不能访问别的公司的信息。在证券商公司内部，对于那些适用于用户的功能，权限由该用户的ID来限制。当新的证券商公司开始进入系统时，将发生一系列步骤。

图4是根据本发明的一个方面的用于设置图2中的规则引擎的流程图。对于每个证券商公司(400)，确定什么用户将能够有权在特定级别上激活或者阻止规则(410)。还确定将负责批准订单的用户(420)。被相关的证券商公司授权的特定用户为公司/办公室/注册代表/账户设置需要的规则(450)。可选的，可以对于特定的时间周期调用规则9000，这将引导所有的订单和交易到新证券商公司的批准台，以确保系统按计划运行。

图5是规则分配更新处理的流程图。在这个过程中，用户使用用户ID和密码登录(500)。通常这个用户是相关的证券商公司的一致经理。该用户选择要设置规则的特定级别(510)。执行检查来确定该用户是否有权在该级别上设置规则(520)。如果该用户没有权力(520-N)，则显示消息指示该用户没有在该级别上被授权，并且程序返回到步骤510之前。如果该级别适用于该用户(520-Y)，该用户调用分配更新函数(530)。适用于所选择的级别的所有规则的清单显示出来以进行编辑(540)。用户选择并编辑特定的规则(550)。如果该用户想要编辑更多的规则(560-Y)，则该用户继续编辑更多的规则(550)。如果该用户编辑规则完毕(560-N)，则把改变存储到规则中(570)，规则立刻生效，同时处理过程结束。

用户可能对规则应用的示例性编辑将是通过在指定的字段中输入如“Y”的指示符来启用该规则，或者是在该字段中输入“N”来禁用一规则。而且，可以设置和编辑规则参数，以及设置或编辑特定规则的结果。例如，当参数将要与特定规则相关时，参数字段接收指示符“Y”，其中该规则允许待激活的下拉菜单，允许输入与确定规则是符合还是违反相关的参数。如果是使用同样下拉菜单在以前建立的参数，这些参数可以被编辑。

尽管不是所有的用户被授权改变规则，在图5中显示的只读版本的规则分配更新处理(叫做规则分配列表函数)是类似的，但是缺乏规则更新能力。

图6是示例性的规则分配定义画面。在该特定画面中，在标有“ACT”(激活)的字段中，字符“P”指示，这是一个全强制系统级规则，没有全局系统管理员权限该规则不能被改变。字符“Y”指示，这是已经被激活的可选规则。如果规则是继承的，就象当察看特定注册代表的规则分配定义且全公司级规则有效时，继承的字段将依赖于在更高的级别上被激活而标识为“Y”。条目“N”将指示，在该级别相关的继承规则无效。前面已经讨论过结果字段。前面已经讨论过规则编号和规则说明，字段“PARM IND”指示，参数是否与规则有关。

规则也可以根据异常来设置。例如，如果想要对特定证券商公司的所有的注册代表上强加规则，可以强加该规则，并从该规则的应用中排除任何一个或者多个特定注册代表

对于每个证券商公司，可能希望有各自的系统管理员，以减少由全局系统管理员控制的担保权限。

图7是示例性的规则代码定义画面。如果想要为系统定义新的规则，并且假定已经被授权激活新的规则(比如系统管理员)，将使用这个画面来激活特定的规则并设置任何可用的参数。

图8是由如图6所示画面产生的一个规则的示例性参数画面。如果该新规则含有参数可用的指示(PARM IND＝Y)，图8的画面下拉出来以允许增加或编辑特定的参数。

图9是根据本发明的一个方面的用于规则处理的示例性过程的流程图。从一个或者多个前端系统接收订单，并检查该订单的基本格式(900)。进行检查以察看定制的规则设置是否对相应的证券商公司有效(905)。如果是的话(905-Y)，规则引擎将检查账户级别规则或账户范围以察看是否满足账户级别规则(910)。然后检查与注册代表有关的规则(915)，该订单所来自的特定办公室的规则(970)，以及适用于证券商公司的公司级别规则(包括系统级别规则和一致规则)(930)。一旦确定了对于所有检查(910～930)的所有的结果，审阅这些结果，以确定所要采取的正确行动(960)。如果结果是停止(960-停止)，提前以该订单所违反的规则的可用消息拒绝该订单(965)。如果结果是警告(960-警告)，则订单被发送到适当的订单执行处理过程，并且向证券商公司发送含有该警告的消息。如果结果是待批(960-待批)，则订单被发送到相应的证券商公司以获得批准，并且该订单所违反的特定规则的消息也一并发送。如果订单被证券商公司批准了(970-Y)，该订单被传递到适当的订单执行处理过程以执行(980)。如果订单没有从证券商公司被批准返回，则假定该订单被证券商公司拒绝。如果结果是被批准(960-被批准)，则该订单被传递到适当的订单执行处理过程(980)。

在一些实施例中，AMPS系统165的操作略有不同。由于证券商公司可能不是资金的保管者，传递资金的请求提前被停止，或者被发送给资金的保管者所在地的指定人来获得批准，而不是发送到证券商公司来获得批准，其中该传递资金的请求来自该证券商公司。

证券商公司有能力响应规则违犯来定制返回的消息，以适合他们特定的偏好。

尽管已经详细地描述和展示了本发明，应该很清楚地理解，该描述和展示只是用于展示和举例，而不是对本发明的限制。

Claims (26)

1.一种规则引擎，包括：

a.用于接收至少一个交易的输入电路；

b.其中存储规则的存储介质，至少一个规则具有适用于能够被用户选择的交易的多个结果。

2.如权利要求1所述的规则引擎，其中所述多个结果中的一个结果包括向用户提供警告信息。

3.如权利要求1所述的规则引擎，其中所述多个结果中的一个结果包括禁止执行由所述交易所请求的订单。

4.如权利要求1所述的规则引擎，其中所述多个结果中的一个结果包括向用户传递所述至少一个交易以获得批准。

5.如权利要求1所述的规则引擎，其中所述多个结果中的一个结果包括自动批准随所述交易提交的订单。

6.一种规则引擎，包括：

a.用于接收至少一个交易的输入电路；

b.其中存储规则的存储介质，至少一个规则具有能够被用户有选择设置的应用范围。

7.如权利要求6所述的规则引擎，其中所述应用范围能够被设置到账户级别。

8.如权利要求6所述的规则引擎，其中所述应用范围能够被设置到注册代表级别。

9.如权利要求6所述的规则引擎，其中所述应用范围能够被设置到办公室级别。

10.如权利要求6所述的规则引擎，其中所述应用范围能够被设置到公司级别。

11.如权利要求6所述的规则引擎，其中所述应用范围能够被设置到全局级别。

12.如权利要求6所述的规则引擎，其中规则附有当违反规则时发送的消息。

13.如权利要求12所述的规则引擎，其中所述消息的文本能够被选定级别的用户改变。

14.一种规则引擎，其特征在于包括：

a.用于接收至少一个交易的输入电路；

b.其中存储规则的存储介质，至少一个规则具有能够被用户有选择设置的参数。

15.一种处理交易的方法，包括通过按照增加范围的顺序施加规则来检查该交易的步骤。

16.如权利要求13的方法，其中规则是这样施加的：首先在账户级别施加规则，然后在注册代表级别施加规则，然后在办公室级别施加规则，然后在公司级别施加规则，然后在全局级别施加规则。

17.如权利要求13的方法，其中所述规则包括一致规则。

18.一种装置，包括：

a.客户处理过程，用于产生和发送包括执行订单的交易；

b.规则引擎，用于从所述客户处理过程接收所述交易并且向所述交易施加至少一个用户可配置的规则；以及

c.至少一个执行处理过程，当所述规则引擎应用该规则导致被批准的结果时，用于从所述规则引擎接收所述订单并执行所述订单。

19.如权利要求18所述的装置，其中所述至少一个用户可配置的规则包括至少一个具有用户可配置的结果的规则。

20.如权利要求19所述的装置，其中用户可配置的结果从下面的组中选择：

(1)将所述订单传递到处理过程以便于执行；

(2)将所述订单传递到用户以得到批准；

(3)向用户提供有关所述订单的警告；以及

(4)拒绝所述订单。

21.如权利要求20所述的装置，其中将所述订单传递到处理过程以便于执行包括将所述订单传递到下面的组中的一个：

(1)用于执行股票或者优先购买权的处理过程；

(2)用于执行共有基金交易的处理过程；以及

(3)用于在固定收入票据中执行交易的处理过程。

22.如权利要求18所述的装置，其中所述至少一个用户可配置的规则包括具有用户可配置的应用范围的至少一个规则。

23.如权利要求18所述的装置，其中所述至少一个用户可配置的规则包括具有用户可配置的参数的至少一个规则。

24.一种装置，包括：

a.客户处理过程，用于产生和发送包括在账户之间转移资产请求的交易；

b.规则引擎，用于从所述客户处理过程接收所述交易并且向所述交易施加至少一个用户可配置的规则；以及

c.至少一个执行处理过程，当所述规则引擎应用该规则导致被批准的结果时，用于从所述规则引擎接收所述请求并按照所述请求转移资产。

25.如权利要求24所述的装置，其中所述至少一个用户可配置的规则包括具有用户可配置的应用范围的至少一个规则。

26.如权利要求24所述的装置，其中所述至少一个用户可配置的规则包括具有用户可配置的参数的至少一个规则。

Images