交易引擎填充或杀死答案

【问题标题】：Trading Engine Fill or Kill交易引擎填充或杀死
【发布时间】：2015-01-03 23:10:25
【问题描述】：

我目前正在尝试实现一个交易引擎。我的代码可以成功创建和填写限价单和市价单。此外，我希望我的引擎能够成功执行“Fill or Kill”订单。不幸的是，我不知道如何为这个“填充或杀死”编写算法。有谁知道是否有一个有效的算法来做到这一点？

以下是一些交易知识较少的人的背景知识。通常要购买的资产按以下方式排序：

Price      Amount  
$200       3  
$300       4
$350       2.5
$400       1.11

如果一个人想购买资产，一个简单的算法从上到下进行，以便为客户提供最佳价值。不必完全购买整排。例如，如果我想要 4 个苹果，代码将以 200 美元的价格卖给我 3 个，以 300 美元的价格卖给我 1 个（从上到下）。

现在，某些卖家可能会提供“Fill or Kill”的选项。这意味着不能部分购买给定行。所以现在让我们说第二行被指定为“Fill or Kill”：

Price           Amount       
$200            3  
$300            4  (Fill or Kill)    
$350            2.5
$400            1.11

在这种情况下，如果我想要 4 个苹果，我不能从第二排买少于 4 个。所以现在我有两个明显的选择。我可以以 4*$300=$1200 从第二排买 4 个苹果，或者我可以从第一排买三个苹果，从第三排买一个苹果，价格为 (3*$200)+(1*350)= $850。现在在这种情况下，第二种选择是更好的选择。不幸的是，情况并非总是如此，具体取决于不同的价格和订单数量。

这些表将在 SQL 中实现并按价格排序。我正在尝试在 php 中实现这个算法。任何帮助将不胜感激。

【问题讨论】：

您从哪个 API 获得市场数据？

标签： php sql algorithm trading

【解决方案1】：

“执行或终止”订单的目的是确保以所需价格向市场放置头寸。因此，交易应立即完整或根本不进入市场。 FOK 指令禁止经纪人部分履行。在将订单放入队列/预订之前，您需要 1:1 的订单与市场匹配。

“不部分履行”是“履行或终止”（以及“全部或无”）订单与“立即或取消”订单的区别。 IoC 订单允许部分填写并在账簿中等待以递增方式获得更多库存，直到订单到期时间。

FOK 订单和 AON 订单的区别在于，不能立即执行的 AON 在执行或取消之前一直保持有效。 AON 一直在书中等待完全匹配。如果没有立即完全匹配，则 FOK 将被丢弃。

Fill or Kill 的高效算法？

有“Multi Fill or Kill”和“Single Fill or Kill”两种形式。

单填或杀

这可能是更容易的一个。这是订单与市场的 1:1 匹配。如果没有直接的顺序匹配，就杀死。如果您使用 SQL 命令执行此操作，则您有 WHERE 等于比较。

单一意味着：如果订单不能立即满足相同或更大大小的单一订单，则订单将被拒绝。

多重填充或杀死

这可能是你所追求的算法。

Multi 表示：填写多个内部订单。

据说 FOK 订单禁止经纪人部分履行。这只适用于与外部的订单簿通信。在内部，会发生“立即内部部分填充”，直到订单被“填充”。

对于传入的 FOK 订单，您创建一个 OrderEventGroup。匹配器可能在账簿上有多个订单，允许满足传入的 FOK 订单，但前提是必须添加在一起。在 MatchEvent 上，OrderEventGroup 填充了与订单约束匹配的相反订单。您在订单簿中匹配订单，其中数量/价格低于或等于请求的数量和价格。您填充 OrderEventGroup，直到 FOK.order.amount 等于 OrderEventGroup.amountTogether。如果 OrderEventGroup.amountTogether 根本不加总和/或花费的时间超过您定义为“立即”执行时间的时间，则 FOK 订单将被终止。

您会得到一笔交易，其中可能有多个匹配步骤，价格可能不同。但这没有传达。订单报告包含：“已填充”和“价格”、“数量” - 其中价格是 OrderEventGroup 的平均价格。订单提交者甚至不知道他的订单是针对多个其他订单执行的。

好处：消除了订单提交者的执行风险。坏事：你得到的是平均价格，却不知道 OrderEventGroup 中的最低最高价格或收集的逆向订单的数量。

填充并杀死

然后，有“填充和杀戮”。订单被执行到可以立即以请求价格执行的数量的范围内。订单的其余部分被终止/取消。这些订单可能以“部分成交”状态结束。除了 FOK.order.amount 不必等于 OrderEventGroup.amountTogether 之外，该算法与 2. 中的相同。 OrderEventGroup.amountTogether 允许更低（部分填充）。

使用的匹配算法主要是纯时间优先（FIFO）算法，因为这种算法最大化有效订单数。（一些市场使用 Pro-Rata 匹配。介于两者之间的是 LIFFE 和 CME 算法，两者都结合了 fifo 和 pro-rata 的元素。）

【讨论】：

@JensAndreKoch：这样做有什么好处？
FOK订单的优势？由于 FOK 订单未显示在订单簿中，因此您可以使用它安全地“测试”市场。归结为：是否有即时流动性？
@JendsAndreKoch：我不认为问题是关于这个的。也许我错了。
我希望你没有投反对票，因为你不知道。 "I would like my engine to have the ability to successfully fill "Fill or Kill" orders."我写了答案：实施行情检查，检查订单是否匹配，如果不匹配，取消。我说过这个订单有时间限制。也许他的意思不是“Fill OR Kill”，而是“Fill AND Kill”，部分填充并丢弃无与伦比的其余部分。
@JensAndreKoch：我不确定你在说什么。我认为这更像是一个最大化和最小化的问题，而不是需要快速的东西？

【解决方案2】：

应该有一个伪多项式动态规划解，类似于背包的解。维护一个表格，对于所有

【讨论】：

【解决方案3】：

您可以跳过具有“填充或终止”属性的报价并选择下一个产品。然后重复跳过的报价并找到两种解决方案之间最便宜的组合。

【讨论】：

【解决方案4】：

首先，FOK 不要坐在订单簿上。它们就像 IOC（立即或取消）并且有效时间为零。如果它们不执行，它们将立即被取消。

All Or None 订单，甚至更少受支持和更少标准，可能具有一天结束的 TIF 或在取消之前有效。在这种情况下，它们不会显示，并且会在它们能够显示时执行。

现在，如果按照我们的方式，您是想遵守证券法，还是这只是一个玩具系统？ FOK 不像限价、市价或 IOC 订单那样标准化。有些场所甚至可能没有实施它们，而有些场所则有不同的定义。

但是，如果您尝试遵守 RegNMS，则不能跳过书的内部以更深入地填写（通过要求进行交易）。我只在 NBBO 上看到过 FOK 订单（最佳出价/报价，内部），但我想我只在我记得的地方使用过它们。

所以算法会很简单，看看书的内部是否有足够的大小，如果有，就执行它。如果你想更宽松一点，你可以工作到一个新的水平，但是在 RegNMS 下，如果另一个场地也显示出该水平的规模（再次通过罢工进行交易），一个场地就无法做到这一点。不过，这是订单类型的重点，以防止泄露您的购买/出售意图。

【讨论】：