关于如何建立简单的风险控制系统

作者：CoinEx X全球大使

设计一个简单的交易风险控制系统

章鱼贸易是一个专注于数字货币交易的团队。自进入市场以来的两年中，我们逐步完善了交易系统，并经历了几轮剧烈的市场波动。成熟的风险控制系统是所有交易团队的标准。在这里，我们分享一些经验，也许可以激发一些新朋友。

交易类

在设计风险控制系统之前，首先要了解的是，您正在进行哪种交易，知名的风险在哪里？例如，如果您在进行套利，那么您基本上将不会持有敞口，因此，当市场急剧波动时，您只需要确保您计算出的头寸正确，订单被撤回即可，只需等待风浪通过。相反，如果您正在执行策略以维持头寸，那么在剧烈波动的情况下，您要做的就是不惜一切代价执行策略订单。如果错过机会，您将损失或减少收入。

不同交易类的风险控制策略肯定不同。本文之后的系统设计基于套利策略。它简要介绍了如何构建可用于套利策略的风险控制系统。

接触

套利策略的核心是试图将您的敞口保持在0，即所有交易都被套期。因此，正确计算自己的位置是关键一步。通常，我们可以使用API从交易所获取实时头寸，但是在某些特殊情况下，交易所给您的头寸可能是错误的或延迟的。这会引起问题。在头寸计算错误的情况下，该程序会错误套期保值，并且随着价格的变化，空头风险会累积更多的损失（当然，有时它可能是一种获利，但是对于风险控制系统，我们仅考虑不利情况）

因此，在计算头寸时，必须考虑以下两种情况：

接口异常

• 此处可能有多种例外情况，例如交换维护升级，或者可能是API调用被过于频繁地阻止。它的表现是您无法通过界面获得新的头寸（余额）。在这种情况下，您应该停止下订单并取消现有的挂单，停止交易一段时间，并等待异常被取消后再继续。

• 另一个需要注意的情况是，如果您获得“异常”头寸，您是否愿意采用它：例如，交易所突然告诉您您的头寸已变为0，这在没有交易的情况下通常是不可能的。在这种情况下，发生了错误的消息，警报并手动检查了问题。

位置延迟

• 头寸的变化是由订单引起的。当交易所的清算失败时，将存在一个问题，即订单已被执行，但头寸没有改变。订单的交易信息将由交易所推送。在这里，我们只需要重新计算应该在本地可用的职位数。如果交换器返回的数据与交换器之间的差距较大，则应关闭以进行检查。

此外，该策略应具有及时弥补风险的逻辑。通常的做法是弥补一些时间并慢慢弥补，以避免在计算头寸后由于来回订单而造成的损失。根据经验，通常每15到30秒就可以组成一个订单。

待处理订单跟踪

无论策略类如何，您都必须跟踪订单，直到交易所通知您订单完成/取消。下面列出了一些常见异常。看看您的策略在什么情况下会“中风”？

市场失灵，您阅读的市场比实际市场晚5秒钟以上，并且针对该市场的订单将不被执行。这些未结算的订单会累积形成单边风险吗？

订单被拒绝，例如，交易所升级了订单的准确性参数，导致交易对上的所有订单请求都被拒绝。在这种情况下，会不会正确执行货币对冲？

下订单超时时，由于超时，您所有待处理的订单均未收到答复，但实际上已成功下达订单，但您未收到订单ID。一段时间后，您会意外地发现某些订单已完成，或者您的职位已意外地发生了变化。

ws push延迟，您使用ws push来订阅订单的更新状态，但是ws push处于断开/延迟状态，您无法更新订单的状态，某些订单已关闭并且您不知道如何处理错误公差？

通常，我们的策略是控制策略的总订单量。例如，我们定义了一个下订单的渠道。在每个通道上，我们只允许一个订单存在。如果之前的订单未正确清除，则不会继续发出新的订单。这样，我们的策略所持有的总风险就是我们可以在每个渠道下订单的总金额，这可以防止在异常情况下出现最坏的重复订单情况。

此外，一般而言，订单金额越高，订单承担的风险就越高。因此，当系统中的某些订单跟踪存在问题时，减少订单数量或限制在大订单渠道中下订单的订单将有助于控制风险。

容错能力

如果您的策略在某些不稳定的交易所上运行，则当该交易所失败或被维护时，该策略是否可以容错地成为风险控制系统的头等大事。我们有几次与交易所失败有关的回撤，可以说，高昂的教训并没有被夸大。

关于容错，建议使用“白名单”方法进行处理，即默认情况下，任何未知错误都会导致保险丝熔断，然后上网一段时间，将一些已知且不严重的异常分类为白色列出并允许它偶尔发生但不会引起保险丝，从而提高系统运行效率。

以下是一些常见的异常（或错误）：

订单被拒绝

订单超时

长时间没有订单/帐户推送

长时间无法接受市场推动

IP禁令

头寸错误（例如，您启动了孩子和母亲帐户的转帐，一侧扣除了钱，但另一侧未添加）

处理上述异常的核心原则是重试，融合和警报。例如，由于余额不足，订单被拒绝。这种情况偶尔会发生，这是相对正常的情况，可以放开。但是，如果在一分钟内连续发生多次，则应对其进行报警和融合，并手动检查其变化。在某人难以值班的时候（例如，早上四点或五点），保险丝机构用于避免连续的大量损失。

保险丝

保险丝机构的设计只是一个计数器加一个延迟设备，也就是说，当第一次发生错误时，系统会熔断1秒钟，当第n次发生时，系统会熔断n * n秒（如果返回）。在此期间正常，则清除计数器。

一般而言，仅在下订单时需要执行熔断，而其他需要熔断的组件（例如市场连接或Websocket连接的订单推送）则需要进行熔断。

保险丝机制的功能是避免因重复重试而造成的大量损失，或者在发生异常时触发交换机的IP禁令。

稍微**些的保险丝策略包括慢速启动机制。例如，在保险丝的末端仅允许少量的订购操作，而允许大量的订购，直到成功率超过阈值。

记录

日志是风险控制系统故障后复查的重要部分。该日志可以帮助您查看发生风险事件时异常事件如何绕过系统。

如果您将交换和策略视为调用链上游和下游的系统，则日志记录系统基本上需要记录以下部分：市场推动，订单指令，订单推动。市场推送和订单推送都是交易所提供的信息，当客户收到推送时，必须记录原始消息和时间戳，以便于查找问题。订单订单是策略发送的信号，还需要记录时间戳。通过比较以上三个日志，我们可以恢复订单的完整决策和生命周期。

将每个事件的日志和相关订单信息打印到一行中，使我们能够轻松地从日志中提取有效信息。将内部订单ID串联使用，可以通过ID查找订单生命周期中的所有日志，这与Internet公司广泛使用的日志系统的设计没有太大区别。

日志系统的关键部分是存储和检索。建议使用ELK或TICK系列存储桶来管理日志。简单的风险控制系统仅需将日志保留7天。如果没有人检查超过7天，那应该不是什么大问题。

失败审查

**的优先级是故障的恢复。发生异常时，通常会伴随损失。我们希望通过日志系统恢复发生故障时系统接收到的信号，并检查是否存在不合理的逻辑。例如，交易所的市场出现了一些延误，该策略未能及时融合，导致订单延误增加和损失。然后，我们必须在出现问题时检查市场，以查看是否有任何线索表明市场已经延迟。例如，我下了一个订单，并且希望它能吸收订单簿中的一部分流动性，但是所推动的市场没有这部分信息，因此我知道该订单尚未进入匹配引擎及时。该通道应融合。

有时，交易所提供的信息可能使您无法准确地区分异常情况。此时，您需要整理日志并与交易所的技术支持进行交流，以使他们了解客户端上的异常情况。也许他们可以添加一些辅助信息来帮助您下次查找此类问题。例如，市场延迟的问题，现在交易所基本上会带来匹配的时间戳。如果该策略发现市场时间戳明显滞后，则可以及时融合以避免风险。

摘要

以上是一个简单的交易风险控制系统。我们的系统基于以上内容，基于重复的故障和风险事件，以及各种补丁程序。当然，除了交易执行风险外，还有其他类似系统的风险，例如插入市场销和资产转移失败。这些需要建立在交易系统的外围，并使用控制信号来指示交易系统停止交易，取消订单并继续。风险规避。此外，如果条件允许，编写应用程序，订阅手机上的风险控制事件以及控制交易开关，可以使您进一步沉迷于数字货币交易的世界。欢迎来到维修站。