第419章 CR-2021-1247！
审查在北京进行。
央行数字货幣研究所的技术审查组办公地点在西城区一栋不起眼的灰色建筑里，三楼，走廊尽头左转。
一间没有窗户的会议室改成的临时工作间，日光灯管是那种偏白偏冷的色温，照得桌面上的文件和屏幕都泛著一层淡青色。
门口掛著一块塑料牌子，白底黑字：“dcep技术评审·閒人免进“。
牌子下面贴了张a4纸列印的补充说明：手机存放於门外储物柜，违者取消审查资格。
工作间里有四张桌子，八台电脑，四个人。
桌子之间隔了半人高的挡板，不完全封闭，能听到隔壁翻页和敲键盘的声音。
暖气开得不高，有人在椅背上搭了件羽绒服。
角落里有个饮水机，旁边摞著一次性纸杯，纸杯上印著“中国人民银行“的標誌，很小，灰色的。
他们从十一月中旬开始工作。
任务是对四家候选方的技术方案进行代码级审查。
每家候选方提交的原始码包都封装在独立的虚擬环境里，物理隔离，不联网。
审查人员只能在指定终端上操作，不能拷贝，不能截图，不能携带任何存储设备进出工作间。
每天的审查日誌自动上传至內部伺服器，审查人员对日誌没有编辑权限。
四个人分两组，每组负责两家。
负责微光科技代码包的是一组，两个人。
一个姓刘，中科院软体所出来的，三十七岁，在央行研究所干了六年，主要方向是分布式系统安全。
头髮有点少，习惯用右手食指推眼镜。
另一个姓孙，年轻一些，三十出头，清华计算机系毕业，做密码学的，说话很少，打字很快。
十二月第二周，周三，上午十点。
刘工在审查微光支付模块的第三层接口调用链。
前两层他已经看完了。
第一层是核心交易引擎，代码质量在四家里排第一，异步架构的实现很漂亮，他在审查笔记里標了个“优“。
第二层是清算对接层，跟银联和人行的接口对接规范，没有问题。
第三层是核心交易逻辑和外部服务之间的衔接层。
所有第三方数据服务的调用都经过这里。
代码结构很乾净，注释规范，命名清晰，接口文档和实际代码的一致性在他审过的四家里是最高的。
工行的代码包里有三处文档和代码不一致的地方，建行有五处。
微光到目前为止，零。
他逐行扫。
大部分接口都是常规的。
银联清算接口，標准的。
人行徵信查询接口，標准的。
第三方支付通道接口，建行、农行、交行各一个，標准的。
运营商实名认证接口，三大运营商都有，標准的。
每个接口都有完整的鉴权流程、超时处理、异常回退、降级策略，写得很规矩。
第47个接口。
他的光標停了。
abyss-creditscore-v3.2。
他把接口名称看了两遍。
“abyss“。
这个名字不在央行技术標准的白名单里。
他在脑子里过了一遍国內持牌徵信服务供应商的名录，百行徵信、芝麻信用、鹏元徵信、前海徵信、中诚信、中智诚，没有一个叫“abyss“的。
他先点开了接口的配置文件。
接口类型標註为“外部数据服务“。
服务端地址是一个內网域名，说明abyss的服务部署在微光自己的伺服器集群里，但接口命名规范遵循的是外部服务的格式。
这意味著它在架构设计上被归类为“外部引入“，但实际运行在內部环境中。
他又点开了调用日誌。
日均调用量：12.7万次。
在微光支付模块所有外部接口中排第三，仅次於银联清算和人行徵信。
调用场景覆盖信用评估、风控决策、额度调整三个核心环节。
平均响应时间：23毫秒。
超时率：0.002%。
返回数据结构复杂，栏位数是標准徵信接口的四到五倍，包含常规徵信报告里看不到的维度。
他往下翻了一页。
接口文档里有一段简短的描述：“abyss信用评分引擎，提供多维度用户信用画像及实时风控评分服务。“
一句话，没有更多说明，没有供应商资质信息，没有数据来源声明，没有合规备案编號，没有服务等级协议。
“老孙。“
孙工从隔壁桌抬起头，他正在审工行的密钥管理模块，屏幕上全是加密算法的参数配置。
“你看一下这个。“
孙工走过来，弯腰看屏幕。
刘工用光標指著那行接口名称。
日光灯的光打在屏幕上有一点反光，孙工侧了一下头避开。
“abyss？“
“没见过。“
“我也没见过。“
孙工拉了把椅子坐下来，自己操作了一会儿。
他从接口调用链往上追溯了两层，找到了abyss在微光整体架构中的位置。
不是一个普通的第三方服务。
它嵌得很深。
跟微光自己的信用评估模块是紧耦合关係，数据通道是双向的，不仅abyss向微光返回评分结果，微光的用户行为数据也在持续回流给abyss。
微光的信用购產品、风控决策引擎、用户额度管理系统，底层都在调用这个接口。
如果把abyss从架构里抽掉，微光整个信用评估体系的数据基础会塌掉一大块。
“这东西是微光自己的还是外部的？“
“接口命名规范是外部服务的格式，但耦合程度像內部的。“
“代码仓库里有abyss的源码吗？“
刘工在文件目录里搜了一下，没有。
微光提交的代码包里不包含abyss的原始码，只有调用接口的客户端sdk。
这进一步说明abyss是一个独立的系统，不属於微光dcep方案的交付范围，但微光的dcep方案在运行时依赖它。
两个人对著屏幕看了五分钟，饮水机发出一声咕嚕，气泡在水桶里翻了一下。
“记一笔？“孙工问。
“记一笔。“
刘工打开了审查报告的模板文件。
他们的工作不是判断这个接口有没有问题，是如实记录审查中发现的所有非標准项。
判断是上面的事。
上面会看报告，会开会，会决定要不要追问，要不要让微光补充说明。
他们不需要管那些。
他在模板里找到“非標准外部服务“栏目，新建了一条记录。
审查编號：cr-2021-1247。
审查日期：2021年12月15日。
审查对象：微光科技·dcep技术方案·支付模块·第三层接口。
发现项：外部数据服务接口“abyss-creditscore-v3.2“，未在央行技术標准白名单內，无供应商资质备案，调用频次高（日均12.7万次），与核心业务逻辑深度耦合，数据双向通道，原始码未包含在交付范围內。
风险等级：待评估。
备註栏他犹豫了一下。
光標在空白处闪了几秒。
打了一行字，刪了，又打了一行。
“外部数据服务abyss，待评估。“
最终就留了这一句，简洁的，中性的，不带任何判断倾向。
保存，关闭文件。
他端起桌上的保温杯喝了一口水，拧上盖子，放回桌角。
保温杯是他从家里带的，不锈钢的，杯身有一道磨痕。
孙工已经回到了自己的位置上，继续审工行的密钥管理。
隔板那边传来均匀的敲键盘声。
刘工推了推眼镜，继续往下审第48个接口。
…………
审查报告在周五下班前提交。
四家候选方的代码审查报告统一匯总，共计147页。
由审查组组长签字確认后封装成加密文件包，通过內部系统提交至数字货幣研究所技术评审委员会。
加密文件包的时间戳是2021年12月17日17:42:31。
cr-2021-1247在第89页。
备註栏第三行：“外部数据服务abyss，待评估。“
这行字存进了央行的档案系统。
没有人通知微光。
央行数字货幣研究所的技术审查组办公地点在西城区一栋不起眼的灰色建筑里，三楼，走廊尽头左转。
一间没有窗户的会议室改成的临时工作间，日光灯管是那种偏白偏冷的色温，照得桌面上的文件和屏幕都泛著一层淡青色。
门口掛著一块塑料牌子，白底黑字：“dcep技术评审·閒人免进“。
牌子下面贴了张a4纸列印的补充说明：手机存放於门外储物柜，违者取消审查资格。
工作间里有四张桌子，八台电脑，四个人。
桌子之间隔了半人高的挡板，不完全封闭，能听到隔壁翻页和敲键盘的声音。
暖气开得不高，有人在椅背上搭了件羽绒服。
角落里有个饮水机，旁边摞著一次性纸杯，纸杯上印著“中国人民银行“的標誌，很小，灰色的。
他们从十一月中旬开始工作。
任务是对四家候选方的技术方案进行代码级审查。
每家候选方提交的原始码包都封装在独立的虚擬环境里，物理隔离，不联网。
审查人员只能在指定终端上操作，不能拷贝，不能截图，不能携带任何存储设备进出工作间。
每天的审查日誌自动上传至內部伺服器，审查人员对日誌没有编辑权限。
四个人分两组，每组负责两家。
负责微光科技代码包的是一组，两个人。
一个姓刘，中科院软体所出来的，三十七岁，在央行研究所干了六年，主要方向是分布式系统安全。
头髮有点少，习惯用右手食指推眼镜。
另一个姓孙，年轻一些，三十出头，清华计算机系毕业，做密码学的，说话很少，打字很快。
十二月第二周，周三，上午十点。
刘工在审查微光支付模块的第三层接口调用链。
前两层他已经看完了。
第一层是核心交易引擎，代码质量在四家里排第一，异步架构的实现很漂亮，他在审查笔记里標了个“优“。
第二层是清算对接层，跟银联和人行的接口对接规范，没有问题。
第三层是核心交易逻辑和外部服务之间的衔接层。
所有第三方数据服务的调用都经过这里。
代码结构很乾净，注释规范，命名清晰，接口文档和实际代码的一致性在他审过的四家里是最高的。
工行的代码包里有三处文档和代码不一致的地方，建行有五处。
微光到目前为止，零。
他逐行扫。
大部分接口都是常规的。
银联清算接口，標准的。
人行徵信查询接口，標准的。
第三方支付通道接口，建行、农行、交行各一个，標准的。
运营商实名认证接口，三大运营商都有，標准的。
每个接口都有完整的鉴权流程、超时处理、异常回退、降级策略，写得很规矩。
第47个接口。
他的光標停了。
abyss-creditscore-v3.2。
他把接口名称看了两遍。
“abyss“。
这个名字不在央行技术標准的白名单里。
他在脑子里过了一遍国內持牌徵信服务供应商的名录，百行徵信、芝麻信用、鹏元徵信、前海徵信、中诚信、中智诚，没有一个叫“abyss“的。
他先点开了接口的配置文件。
接口类型標註为“外部数据服务“。
服务端地址是一个內网域名，说明abyss的服务部署在微光自己的伺服器集群里，但接口命名规范遵循的是外部服务的格式。
这意味著它在架构设计上被归类为“外部引入“，但实际运行在內部环境中。
他又点开了调用日誌。
日均调用量：12.7万次。
在微光支付模块所有外部接口中排第三，仅次於银联清算和人行徵信。
调用场景覆盖信用评估、风控决策、额度调整三个核心环节。
平均响应时间：23毫秒。
超时率：0.002%。
返回数据结构复杂，栏位数是標准徵信接口的四到五倍，包含常规徵信报告里看不到的维度。
他往下翻了一页。
接口文档里有一段简短的描述：“abyss信用评分引擎，提供多维度用户信用画像及实时风控评分服务。“
一句话，没有更多说明，没有供应商资质信息，没有数据来源声明，没有合规备案编號，没有服务等级协议。
“老孙。“
孙工从隔壁桌抬起头，他正在审工行的密钥管理模块，屏幕上全是加密算法的参数配置。
“你看一下这个。“
孙工走过来，弯腰看屏幕。
刘工用光標指著那行接口名称。
日光灯的光打在屏幕上有一点反光，孙工侧了一下头避开。
“abyss？“
“没见过。“
“我也没见过。“
孙工拉了把椅子坐下来，自己操作了一会儿。
他从接口调用链往上追溯了两层，找到了abyss在微光整体架构中的位置。
不是一个普通的第三方服务。
它嵌得很深。
跟微光自己的信用评估模块是紧耦合关係，数据通道是双向的，不仅abyss向微光返回评分结果，微光的用户行为数据也在持续回流给abyss。
微光的信用购產品、风控决策引擎、用户额度管理系统，底层都在调用这个接口。
如果把abyss从架构里抽掉，微光整个信用评估体系的数据基础会塌掉一大块。
“这东西是微光自己的还是外部的？“
“接口命名规范是外部服务的格式，但耦合程度像內部的。“
“代码仓库里有abyss的源码吗？“
刘工在文件目录里搜了一下，没有。
微光提交的代码包里不包含abyss的原始码，只有调用接口的客户端sdk。
这进一步说明abyss是一个独立的系统，不属於微光dcep方案的交付范围，但微光的dcep方案在运行时依赖它。
两个人对著屏幕看了五分钟，饮水机发出一声咕嚕，气泡在水桶里翻了一下。
“记一笔？“孙工问。
“记一笔。“
刘工打开了审查报告的模板文件。
他们的工作不是判断这个接口有没有问题，是如实记录审查中发现的所有非標准项。
判断是上面的事。
上面会看报告，会开会，会决定要不要追问，要不要让微光补充说明。
他们不需要管那些。
他在模板里找到“非標准外部服务“栏目，新建了一条记录。
审查编號：cr-2021-1247。
审查日期：2021年12月15日。
审查对象：微光科技·dcep技术方案·支付模块·第三层接口。
发现项：外部数据服务接口“abyss-creditscore-v3.2“，未在央行技术標准白名单內，无供应商资质备案，调用频次高（日均12.7万次），与核心业务逻辑深度耦合，数据双向通道，原始码未包含在交付范围內。
风险等级：待评估。
备註栏他犹豫了一下。
光標在空白处闪了几秒。
打了一行字，刪了，又打了一行。
“外部数据服务abyss，待评估。“
最终就留了这一句，简洁的，中性的，不带任何判断倾向。
保存，关闭文件。
他端起桌上的保温杯喝了一口水，拧上盖子，放回桌角。
保温杯是他从家里带的，不锈钢的，杯身有一道磨痕。
孙工已经回到了自己的位置上，继续审工行的密钥管理。
隔板那边传来均匀的敲键盘声。
刘工推了推眼镜，继续往下审第48个接口。
…………
审查报告在周五下班前提交。
四家候选方的代码审查报告统一匯总，共计147页。
由审查组组长签字確认后封装成加密文件包，通过內部系统提交至数字货幣研究所技术评审委员会。
加密文件包的时间戳是2021年12月17日17:42:31。
cr-2021-1247在第89页。
备註栏第三行：“外部数据服务abyss，待评估。“
这行字存进了央行的档案系统。
没有人通知微光。