作者介绍：林小冲，现就职于兴证风险管理有限公司，硕士毕业于武汉大学金融学专业，注册会计师，2021年加入兴证风险管理有限公司，目前主要负责场外衍生品业务的风控及信息化建设工作。
2021年是国内权益衍生品很火热的时候，市场上创新业务层出不穷，给风控工作带来不小的挑战。场外衍生品业务的风控工作包括场外期权定价模型开发、估值与风控指标计算、簿记台账复核、交易审批与结算复核、盯市管理、压力测试、交易对手信用风险管理，以及各类报表的制作与报送等工作，大多数与运营支持密切相关。各家公司有其自身的业务习惯，大大增加外部供应商提供标准化系统的难度，因此不少公司选择自研系统解决难题。在这一背景下，我们通过自研开发的方式，推动场外风控工作的数字化转型，弥补外购系统在风控功能上的不足，完善量化风控体系。
场外业务信息化建设难点
为加强场外业务风险管理，我们于2021年末起启动数字化转型工作，目标是实现各类风控工作的自动化处理，进而串联各个业务流程，优化风险管理模式。我们在数字化转型过程遇到的难点主要有以下三方面：
2.外部供应商开发周期较长
场外业务的IT需求变化快，外部供应商实现需求的速度较慢。与供应商合作开发一般需要经历“提出需求、商务谈判、开发排期、部署确认”等过程，开发周期较长。部分业务也不适合外部化，例如场外期权定价模型属于公司的技术秘密，不适合交由外部供应商在系统中部署。另外，场外衍生品业务有明显的先发优势特征，如果等到市场技术足够成熟，可能已失去先发优势。
3.自研建设系统的成本较高
自建系统需要较多资源投入，业务与技术相融合成难题。场外衍生品系统主要流行三种建设模式——全部自研、全部外购以及兼而有之。其中，全部自研的成本过高，不少公司倾向于以自研为主，少部分需求通过外购系统实现。自研过程中最重要的是业务和技术的紧密融合，这一点是决定项目成败的关键，应避免在流程管理、需求确认、责任划分等环节互相推诿。不少公司选择在业务部门中成立IT团队，减少组织架构分离带来的负面影响，使业务需求能够得到及时响应。
探索量化自研之路
1.探索历程
回顾建设历程，公司风控工作的数字化转型大致分为三个阶段：在第一阶段，公司多年以来形成的手工处理经验，以“口口相传”的方式传承至笔者这一代，风控日常工作高度依赖Excel工具；到了第二阶段，优先选择成熟业务进行RPA（机器人流程自动化）改造，尽量减小对现有业务的冲击，工作方式更接近于Excel自动化处理；到了第三阶段，待RPA流程积累到一定数量，业务逻辑趋于成熟，再开始调整代码风格，引入前端、后端和数据库，逐步降低Excel的使用频率。
2.权衡利弊做自研
笔者是在合规风控部从事场外业务风控工作，后台部门的资源有限，自研工作需要从多角度权衡利弊，比如技术障碍、需求复杂度、预期成效等因素。首先，要根据自身的技术实力判断计划可行性，虽然风控自身最了解需求，但可能遇到较多技术障碍，很难按大型专业团队的技术标准进行自研；其次，既希望做出成绩，又希望开发和维护成本尽可能低，就需要平衡研发投入与产出的关系，优先解决“投入小但效果立竿见影”的工作，难题靠后解决或者合理放弃；最后，项目上线以后，手工工作虽然有所减少，但开发和维护工作都会有增加，也会分化出运营、开发和运维等岗位职责，小团队可能不支持进行一步职责划分。每家公司的情况不一，笔者仅结合自身工作环境和条件，分享一下适合小团队的技术选择。
在Web前端方面，大致有两条路线。一条路线是传统的“html+css+js”技术框架，优势是支持定制化页面开发，缺点在于开发成本较高，对后端开发者还有额外的学习成本。另一条路线是，现如今前端开发的门槛已经逐渐降低，可以引入“低代码”开发框架，从而应对频繁变化的前端交互需求。这条路线的优势是学习曲线平坦，维护成本低，缺点是页面设计不如传统方式灵活。两条路线都有其明显的优缺点，可以根据自身条件进行选择。
在数据库方面，不同业务场景可以选择不同数据库。例如灵活的场外期权要素适合用Json格式储存，这种格式也更容易扩展和解析。具体选择数据库时，既可以用支持Json格式的关系型数据库进行储存，也可以考虑直接用非关系型数据库存储（如文档型数据库）。在衍生品定价时，可以用Redis作为缓存数据库，减少重跑计算任务的耗时。总之，数据库的选择应该结合具体业务场景，当然也要避免用小众的数据库。
在后端方面，如果有成熟的技术团队，一般选择Java和Python结合。考虑到笔者主要从事风控工作，早期业务中存在大量Excel文件，Java对数据分析的支持较弱，而且引入Java对后台小团队不太合适，故主要用Python进行后端开发，仅在少数业务中使用了Java。作为在互联网行业流行的Go语言，在业务中也有一定的应用，例如命令行工具和各类服务接口的开发，其低维护成本与高性能表现值得关注，也为快速开发容器应用程序提供了便利。另外，后端工作与运维有一定联系，引入容器技术有助于简化部署工作并提高生产力。
反思过去与展望未来
1.步步为营，稳扎稳打
回顾建设过程，最痛苦的是从RPA调整为前后端项目的过渡期间。由于新功能需要进行测试，与老业务并行，导致日常工作翻倍。尽管如此，选择用RPA进行过渡或是一个不错的选择，而不是直接飞跃到自研系统阶段。主要原因有二，一是早期笔者对业务习惯不够熟悉，难以精准表达业务逻辑；二是原有的手工业务不能停止，否则会对下游业务产生较大影响。从效果上来看，中期阶段的RPA改造大幅减轻了工作压力，良好的效果给改造工作带来动力。
2.沉淀自己，厚积薄发
深入理解业务逻辑是将技术应用于实际场景中的关键。在日常运营工作中，需要不断沉淀自己的业务知识和经验，发现更好的业务方案。在开发工作中，抓住核心需求，节约开发成本，并探索新技术应用于业务的可能性。工作思路不断往返于不同角色之间，融合业务经验与技术，呈现更好的解决方案。
3.反思不足，学习先进
过去的建设目标不够清晰，在单体系统中实验性地开发了各类功能，功能高度一体化，耦合度过高导致维护工作越来越繁重，扩展性逐渐变差。后期调整项目时，做了大量的解耦工作，把单体系统拆分为多个子系统和服务。从事后角度来看，如果早期的业务目标就足够清晰，越早考虑耦合性问题越好，但如果业务目标不够清晰，需要较长时间的探索，单体系统是比较好的过渡形式。
