本体协作平台
trista · 本体管理员
本体登记表

知识库

全库 981 个构件(2026-08-17 按说明书 v2 全量重抽),按纲要六类构件组织,规则=函数·规则型。(二期数据接地:对象 1/86 · 属性 2/245 · 关系 0/107,在详情页维护)

确认进度19/981· 已确认=锁定,改前先解锁
批量导入变更记录别名索引字段索引
全部 279冲突 57缺口 202接口候选 20│○ 待收口 189✓ 已收口 13收口进度14/279

这里不做判断,只记录结论:PM / 风控 / 后端把口径定下来之后,在对应条目上记一笔「定了什么、谁定的」。冲突记完可以顺手把说法错了的那条构件标成「待改」,提醒回去改。

G-001缺口U01 开通与授信

授信申请结果码 1006/1008 是什么意思

缺什么:P092 授信申请结果码 中 1006、1008 两个码的业务含义没有登记。 为什么缺/线索:IT 知识库收录的 405 个接口契约里都没有这两个码,待后端确认(01§待确认、待确认清单·问后端第 2 条)。
涉及:P092 授信申请结果码出处:01§待确认·_待确认清单§问后端2
登记原文P092 授信申请结果码: 1006/1008 语义待后端（IT KB 405 个契约无此码）
○ 待收口
G-002缺口U01 开通与授信

申请被置为待面签/待补料,是谁写入的

缺什么:P006 开通/KYC 状态 里的 T017/T022/T023(待 Video Banking 面签、待补料等中间态)由谁写入没有登记——是引擎裁决参数自动置的,还是审核人员人工操作。 为什么缺/线索:出处只列了状态值,没有写写入方(R5§①)。
涉及:P006 开通/KYC 状态出处:R5§①
登记原文P006 开通状态 T017/T022/T023: 缺写入方：谁把申请置为待 VB/待补料（引擎裁决参数还是审核人工）
○ 待收口
G-003缺口U01 开通与授信

开通拒绝码由哪个引擎产出、命中规则是什么

缺什么:P087 开通拒绝码 中 B 开头的拒绝码由哪个引擎产出没有登记——是 F-21 KYC 预筛决策(IKYC)还是 F-54 开户反欺诈初审(MIDAFS);各码对应的反欺诈命中规则和阈值也没有。 为什么缺/线索:命中规则和阈值在风控策略包里,文档和代码都不持有(01§D.2、R10§5)。
涉及:P087 开通拒绝码F-21 KYC 预筛决策F-54 开户反欺诈初审出处:01§D.2·R10§5
登记原文P087 开通拒绝码: 缺写入方：B 系码由哪个引擎产出（IKYC F-21 / MIDAFS F-54）；各码反欺诈命中规则/阈值在风控策略包
○ 待收口
G-004缺口U01 开通与授信

预授信额度是谁算出来的

缺什么:P073 预授信额度 由谁写入、由哪个函数产出没有登记——是离线模型跑出来的,还是引擎实时算的。 为什么缺/线索:出处只写了这个字段的存在,没有写产出方(01§A、01§后端补充事实)。
涉及:P073 预授信额度出处:01§A·01§后端补充事实
登记原文P073 预授信额度: 缺写入方与产出函数（离线模型 or 引擎）
○ 待收口
G-005缺口U01 开通与授信

引擎建议额度对应的输出字段名不明

缺什么:P072 引擎建议额度 在引擎输出里对应哪个字段名没有找到。 为什么缺/线索:后端系统地图只写到引擎会给建议额度,未见字段名(R10§5)。
涉及:P072 引擎建议额度出处:R10§5
登记原文P072 引擎建议额度: 引擎输出字段名未见
○ 待收口
G-006缺口U01 开通与授信

钱包账户中级户对应的等级码不明

缺什么:P076 钱包账户等级 里"中级户"对应的取值(mpcLevel)没有找到,目前只见到 01=初级户、03=Prime。 为什么缺/线索:出处只出现了 01 和 03 两个字面值(01§D.3、01§D.5)。
涉及:P076 钱包账户等级出处:01§D.3·01§D.5
登记原文P076 钱包账户等级: 中级户 mpcLevel 取值字面未见（仅见 01 初级/03 Prime）
○ 待收口
G-007缺口U01 开通与授信

钱包锁定/冻结/解锁动作没有建档

缺什么:P077 钱包状态 的写入方没有建档——钱包侧的锁定、冻结、解锁等动作没有登记为动作构件。 为什么缺/线索:出处只观测到状态值,没有对应的动作(R5§⑧)。
涉及:P077 钱包状态出处:R5§⑧
登记原文P077 钱包状态: 写入方（钱包侧锁定/冻结/解锁动作）未建档
○ 待收口
G-008缺口U01 开通与授信

锁定码 U/N 含义及与账单状态的优先级不明

缺什么:P005 冻结/拦截码(锁定码) 里在用的 U、N 两个码业务含义没有给出;锁定码与账单状态(acctStmtStatus)谁优先也没有说明。 为什么缺/线索:优先级关系待 PM/后端确认(R1§五)。
涉及:P005 冻结/拦截码(锁定码)出处:R1§五
登记原文P005 blockCode: 在用码 U/N 语义未见；与 acctStmtStatus 优先级待 PM/后端
○ 待收口
G-009缺口U01 开通与授信

客群分段码第 3-40 位含义待补

缺什么:P003 客群分段码 共 40 位,第 3-40 位每一位的含义没有登记。 为什么缺/线索:待 PM 补充(R1§三)。
涉及:P003 客群分段码出处:R1§三
登记原文P003 segCode: 3-40 位含义待 PM 补充
○ 待收口
G-010缺口U01 开通与授信

风险码完整字典和 Risk Flag 具体值缺失

缺什么:P004 风险码(风险标签集) 的完整取值字典和对应的策略包版本没有;文档里"Risk Flag=XXXX"占位符的实际取值也没有。 为什么缺/线索:IT 知识库未收录风险码字典(R1§四、R10§6);Risk Flag 具体值待 PM 补。
涉及:P004 风险码(风险标签集)出处:R1§四·R10§6
登记原文P004 riskCode: 完整字典与策略包版本 IT KB 未收录；Risk Flag=XXXX 待 PM 补值
○ 待收口
G-011缺口U01 开通与授信

开户流程从申请到激活的端到端链路未闭合

缺什么:N073 开户流程实例 在开户系统(MEG)侧落哪张表、表结构如何没有;从申请→审批→落额→激活的端到端运行链路没有串起来。 为什么缺/线索:MEG 侧落表结构没进 IT 知识库(R10§3、R10§6)。
涉及:N073 开户流程实例出处:R10§3·R10§6
登记原文N073 开户流程实例: MEG 侧落表结构未入 IT KB；apply→审批→落额→激活端到端运行链未闭合
○ 待收口
G-012缺口U01 开通与授信

能否开 Prime 户的判定方和规则不明

缺什么:"能否开通 Prime 钱包账户"这个标志(P086 子字段 canOpenPrimeAcct)由谁判定、按什么规则判定没有登记。 为什么缺/线索:出处只见到该标志被使用,未见判定逻辑(01§D.5)。
涉及:P086 子字段 canOpenPrimeAcct出处:01§D.5
登记原文P086.canOpenPrimeAcct: 判定方/判定规则未见
○ 待收口
G-013缺口U01 开通与授信

落地页放行标志 withoutUaAndMpc 的含义不明

缺什么:L195 规则(落地页准入放行)依赖的标志(withoutUaAndMpc)业务含义没有登记——什么场景下会"没有 UA 和 MPC"没有写清。 为什么缺/线索:出处只有"该标志为真时直接放行、不做钱包状态阻断"这一条判断(01§D.1)。
涉及:L195 规则:落地页准入放行标志出处:01§D.1
登记原文L195 withoutUaAndMpc: 标志语义未见（何种上下文缺 UA/MPC）
○ 待收口
G-014缺口U01 开通与授信

视频面签由谁执行、面签记录如何标识不明

缺什么:A-52 执行 Video Banking 面签 由哪个系统或团队执行没有登记;面签记录也没有唯一标识字段。 为什么缺/线索:出处只写到有面签环节(01§D.5)。
涉及:A-52 执行 Video Banking 面签出处:01§D.5
登记原文A-52 执行 Video Banking 面签: 面签方（系统/团队）归属未见；VB 面签记录 identity 未见
○ 待收口
G-015缺口U01 开通与授信

授信额度锁定:触发参数与解锁路径都不明

缺什么:A-23 锁定授信额度 有两处空白——① 触发参数(params)未见:什么条件、按什么入参判定"额度异常"没有记载;② 解锁路径未见:锁定后如何恢复(自动解除还是人工、走哪个动作)没有记载。 为什么缺/线索:R5§① 只给出状态值 ACTIVE_CREDIT_FREEZED(已开户但额度异常被锁定)与状态机位置,未描述触发与解除机制。待风控/后端补。
涉及:A-23 锁定授信额度N002 信贷账户P006 开通/KYC 状态出处:R5§①
登记原文A-23 锁定授信额度: 解锁动作与路径未见
○ 待收口
G-016缺口U01 开通与授信

安全问答核身的题库和判定阈值不在文档里

缺什么:F-55 安全问答核身判定 用的具体题目和判定通过的阈值没有登记。 为什么缺/线索:题库和阈值存在后台数据库/策略里,文档和代码都不持有(01§待确认)。
涉及:F-55 安全问答核身判定出处:01§待确认
登记原文F-55 安全问答核身判定: 题库具体题目与判定阈值在后台 DB/策略
○ 待收口
G-017缺口U01 开通与授信

开户段三个引擎的输出字段不明

缺什么:F-20 激活反欺诈、F-53 人脸比对与名单库查询、F-54 开户反欺诈初审 三个引擎的输出字段没有登记,目前只有名字没有内容。 为什么缺/线索:引擎矩阵和后端地图只列了引擎名和调用点(02§引擎矩阵、R10§4.01)。
涉及:F-20 激活反欺诈F-53 人脸比对与名单库查询F-54 开户反欺诈初审出处:02§引擎矩阵·R10§4.01
登记原文F-20 激活反欺诈 / F-53 人脸比对 / F-54 开户初审: outputs 字段未见（壳）
○ 待收口
G-018缺口U01 开通与授信

开户段五类上报/提交记录缺唯一标识

缺什么:N031 推荐码提交、N033 协议同意、N038 GPS 定位记录、N039 App List 采集记录、N040 CNC 风控上报事件 五类记录都没有登记唯一标识字段。 为什么缺/线索:出处只见提交/上报动作,未见记录的标识列(01§D.5、01§D.7、R10§4.01)。
涉及:N031 推荐码提交N033 协议同意N038 GPS 定位记录N039 App List 采集记录N040 CNC 风控上报事件出处:01§D.5·01§D.7·R10§4.01
登记原文N031/N033/N038/N039/N040 identity: 登记未见身份标识列（推荐码提交、协议同意、GPS/App List/CNC 记录）
○ 待收口
G-019缺口U01 开通与授信

OCR SDK 版本号无法在前端证实

缺什么:F-44 OCR 证件识别 用的 SDK 版本(Advance.AI v3.0.3)只有 PRD 口径,前端代码里没有版本字符串可以证实。 为什么缺/线索:版本以 App 原生侧为准(01§待确认)。
涉及:F-44 OCR 证件识别出处:01§待确认
登记原文F-44 OCR SDK 版本: Advance v3.0.3 为 PRD 口径，前端无版本串可证，版本以原生侧为准
○ 待收口
G-020缺口U01 开通与授信

授信拒绝原因码取值表缺失

缺什么:P095 授信拒绝原因码 的全部取值和含义没有登记。 为什么缺/线索:出处只提到有这个字段(01§A)。
涉及:P095 授信拒绝原因码出处:01§A
登记原文P095 授信拒绝原因码: 取值表未见
○ 待收口
G-021缺口U01 开通与授信

OCR 提交结果状态除成功码外取值不明

缺什么:P091 OCR 提交结果状态 只见到 5000 一个取值,其余取值和含义没有登记。 为什么缺/线索:出处只出现 5000 这一个值(01§D.5)。
涉及:P091 OCR 提交结果状态出处:01§D.5
登记原文P091 OCR 提交结果状态: 除 5000 外其余取值未见
○ 待收口
G-022缺口U01 开通与授信

推荐码提交后能否撤销不明

缺什么:A-20 受理推荐码提交 后能否撤销、撤销路径是什么没有登记。 为什么缺/线索:目前卡片里写的可逆性是推断,没有出处证实(01§D.5)。
涉及:A-20 受理推荐码提交出处:01§D.5
登记原文A-20 受理推荐码提交: 可逆性（撤销路径）未见，卡内为推断
○ 待收口
G-023缺口U01 开通与授信

授信结果轮询超时后用户落到哪个页面

缺什么:A-56 受理授信提交并送审 后前端每 2 秒查一次结果、最多查 10 次(amsAccountQueryApplyResult),10 次用完仍无结果时用户落到哪个页面没有明说。 为什么缺/线索:推断是"处理中"页,但出处未写明(01§D.4)。
涉及:A-56 受理授信提交并送审出处:01§D.4
登记原文A-56 轮询超时: amsAccountQueryApplyResult 2s×10 轮询耗尽后的落点未明说（推断为 processing 页）
○ 待收口
G-024缺口U02 支付消费

商户订单三个单号如何对应、商户写入字段无归属

缺什么:N077 商户订单 上有三个标识(order_no、mpcOrderNo、MER_BIZ_NO),彼此的对应关系没有说明;由商户侧写入的字段(订单总额 totalAmt、商品清单 goodsList)写入方是外部商户系统,本体里没有对应的写入方类型可挂。 为什么缺/线索:出处只见字段名(02§D.1)。
涉及:N077 商户订单出处:02§D.1
登记原文N077 商户订单: order_no / mpcOrderNo / MER_BIZ_NO 三个标识的对应关系未明；商户侧写入字段（totalAmt/goodsList）无本体写入方类型（写入方=商户系统）
○ 待收口
G-025缺口U02 支付消费

取现风控挑战没有独立单号,结果写入方未建档

缺什么:N078 风控挑战(取现挑战码 1212)没有独立单号,缺唯一标识;P109 挑战结果 的写入方——人脸比对(IKYC)或 OTP 平台——没有建档为函数构件。 为什么缺/线索:出处只见挑战码和结果字段(02§D.3、R3§⑥)。
涉及:N078 风控挑战P109 挑战结果出处:02§D.3·R3§⑥
登记原文N078 风控挑战（取现 1212）: 取现挑战无独立单号，身份标识缺；挑战结果 P109 写入方（IKYC 人脸比对/OTP 平台）未建档为函数
○ 待收口
G-026缺口U02 支付消费

QRIS 付款码字段不明,PayLater 出码无实证

缺什么:N079 QRIS 付款码(CPM 被扫) 的码串字段、出码流水字段名和码的有效时长没有登记;PayLater 额度作为付款码资金源在生产上真实存在的证据也没有。 为什么缺/线索:IT 知识库查不到相关记录(R10§6)。
涉及:N079 QRIS 付款码(CPM 被扫)出处:R10§6
登记原文N079 QRIS 付款码: 码串/出码流水字段名与时效未见；PayLater 作 CPM 资金源的生产实证 IT KB 查不到
○ 待收口
G-027缺口U02 支付消费

支付引擎入参场景码值和裁决结果字典缺失

缺什么:P104 支付场景标识 传给引擎的场景枚举真实码值没有;P106 放款反欺诈引擎决策-消费 及相邻引擎决策字段(P108)的输出裁决字典(放行/挑战/拒绝各是什么码)也没有;风险码字典与策略包版本同样缺。 为什么缺/线索:IT 知识库查不到(R4§3、R10§6)。
涉及:P104 支付场景标识P106 放款反欺诈引擎决策-消费出处:R4§3·R10§6
登记原文P104 支付场景标识 / P106·8 引擎决策: 引擎入参场景枚举真实码值与引擎输出裁决字典（放行/挑战/拒绝码）未见；RiskCode 字典与策略包版本 IT KB 查不到
○ 待收口
G-028缺口U02 支付消费

QRIS 主扫两种形态只有 PM 口述,缺书面来源

缺什么:P105 QRIS 码形态 里"主扫有两种形态"的说法目前只有 PM 口述(2026-07-16),没有书面 PRD 依据。 为什么缺/线索:三篇 QRIS 源 PRD 都没有明写主扫两形态,待归档补源(02§QRIS 主扫的两种形态)。
涉及:P105 QRIS 码形态出处:02§QRIS 主扫的两种形态
登记原文P105 QRIS 码形态: PM 口述口径（2026-07-16），源 PRD 三篇 QRIS 文档未显式记载主扫两形态，待归档补源
○ 待收口
G-029缺口U02 支付消费

虚拟卡属性写入方未建档,自动补足规则待 PM

缺什么:N011 VDC 虚拟借记卡 的几个属性——P111 VDC 卡限额、P114 VDC 最近一次支付时间、卡号后四位——写入方是卡系统/支付枢纽,但没有建档;自动补足(Auto top-up)从信贷额度还是钱包补、触发阈值是多少也没有定。 为什么缺/线索:补足来源与阈值在 03 篇标为待 PM(02§VDC Auto top-up、03§待确认)。
涉及:N011 VDC 虚拟借记卡P111 VDC 卡限额P114 VDC 最近一次支付时间出处:02§VDC Auto top-up·03§待确认
登记原文N011 VDC 属性写入方: VDC limit（P111）、最近支付时间（P114）、卡号后四位写入方=卡系统/支付枢纽，未建档；Auto top-up 补足来源（额度 vs 钱包）与触发阈值 03 篇标待 PM
○ 待收口
G-030缺口U02 支付消费

消费费率现网值和积分兑换规则缺失

缺什么:消费的 admin fee 月费率、年利率、service fee 率在现网的实际值没有;积分兑换率和兑换上限的业务规则也没有。 为什么缺/线索:费率由引擎按账户实时计算,前端没有静态表,待 PM/后端给值(R4§6、02§待确认);积分规则待 PRD。
出处:R4§6·02§待确认
登记原文两费现网值: 消费 admin fee 月费率、年利率、消费 service fee 率现网值为引擎按账户算，前端无静态表，待 PM/后端；积分兑换率/上限业务规则待 PRD
○ 待收口
G-031缺口U02 支付消费

外部商户接入规范不在知识库

缺什么:外部商户正式接入的规范(查单、结果回调的契约细节)没有,目前只有 L027 规则(SDK 关闭不回传支付结果)这一条。 为什么缺/线索:接入规范不在 IT 知识库里,由收单侧提供(02§待确认)。
涉及:L027 规则:SDK 关闭不回传支付结果出处:02§待确认
登记原文L027 商户接入契约: 对外部商户正式接入 spec（查单/回调契约细节）不在 IT KB，由收单侧提供
○ 待收口
G-032缺口U02 支付消费

支付全流程没有埋点,漏斗无法度量

缺什么:A-04 受理支付交易 从付款页拉单→试算→提交→结果全程零埋点,没有可观测的指标;另外代码里的结果轮询守卫(isUpScene 未定义、coreTransPayUnionPayLoanResult 未被调用)是死分支。 为什么缺/线索:PM 2026-08-13 确认暂不立项补埋点(02§D.4、02§经营与体验关注点)。
涉及:A-04 受理支付交易出处:02§D.4·02§经营与体验关注点
登记原文A-04 支付漏斗观测: payment 页拉单→试算→提交→结果全程零埋点，feedback 不可度量（PM 2026-08-13 暂不立项）；轮询守卫 isUpScene 未定义/coreTransPayUnionPayLoanResult 未调用为死分支
○ 待收口
G-033缺口U02 支付消费

各类优惠券能否叠加、谁优先没有统一规则

缺什么:低价权益、支付立减券、Admin Fee 券三者之间能否叠加、叠加时谁优先,没有统一的叠加规则。 为什么缺/线索:代码里没有统一的叠加器,PRD 也没有成文,待 PM(R4§4)。
出处:R4§4
登记原文券叠加规则: 低价权益/支付立减券/Admin Fee 券之间能否叠加与优先级无统一叠加器、PRD 未成文，待 PM
○ 待收口
G-034缺口U02 支付消费

付款码只对 Prime 钱包开放,但档位判据未建档

缺什么:L220 规则(付款码出码仅 Prime 钱包档放行)依赖的钱包档位属性(mpcLevel/Prime)没有单独建档,目前引用时以 N003 Allo Wallet 钱包账户 代替;"什么算 Prime 档"的具体判据也没有。 为什么缺/线索:档位判据待 U01/钱包侧给出(R10§4·02)。
涉及:L220 规则:付款码出码仅 Prime 档N003 Allo Wallet 钱包账户出处:R10§4·02
登记原文L220 CPM 出码 Prime 档: 钱包档位属性（mpcLevel/Prime）未在本单元建档，refs 以 N003 代；具体档位判据待 U01/钱包侧
○ 待收口
G-035缺口U02 支付消费

钱包支付场景 ALLO_PAY 是否仍有效待 PM

缺什么:支付场景 ALLO_PAY(钱包支付)是否还是一个有效的业务场景没有定论。 为什么缺/线索:SDK 里对应的路由(SERVICE_PAYMENT)没有注册,跳转必然失败,对应页面文件(pages/service/Payment.vue)是无人引用的孤儿文件——待 PM 确认(02§关键字段与门槛、02§D.1)。
出处:02§关键字段与门槛·02§D.1
登记原文scene=ALLO_PAY 钱包支付: SDK 内路由 SERVICE_PAYMENT 未注册、导航必失败；pages/service/Payment.vue 为孤儿文件——ALLO_PAY 是否仍是有效业务场景待 PM
○ 待收口
G-036缺口U02 支付消费

试算方案等"构造类"对象该算实体还是事件

缺什么:N046 试算方案 在注册表里标为"构造"类型,而按手册二分法这次记成了事件,两处不一致;同一批标为构造的对象(N045 账单~N072 工单)如何映射到实体/事件也没有统一说法。 为什么缺/线索:需要审核统一口径(注册表索引 vs 手册第 2 章§2.1)。
涉及:N046 试算方案出处:registry-index vs handbook-ch2 §2.1
登记原文N046 试算方案对象类型: 注册表标 type=构造，本轮按二分记事件；需审核统一（同批 N045~N072 构造类如何映射实体/事件）
○ 待收口
G-037缺口U03 取现 Instant Cash

取现挑战记录缺标识,挑战后查放款结果流程不详

缺什么:N082 风控挑战记录 在取现侧没有唯一标识字段(现有的 RULE_CODE_LIST_PARTNER 只是挑战类型清单,不是标识);用户完成 OTP/刷脸挑战之后,如何继续查询放款结果的流程也没有写清。 为什么缺/线索:出处只写到挑战下发(03§D.4)。
涉及:N082 风控挑战记录出处:03§D.4
登记原文N082: 取现侧挑战记录标识字段未见(RULE_CODE_LIST_PARTNER 为清单);挑战完成(OTP/刷脸)后续查放款结果的流程未详
○ 待收口
G-038缺口U03 取现 Instant Cash

取现借款审批决策的取值字典和落库字段缺失

缺什么:P127 取现借款审批决策(首借/复借审批)的取值字典和落库字段没有登记。 为什么缺/线索:风险码字典与策略包版本在 IT 知识库查不到(R10§6)。 [2026-08-27 合并 G-165 的出处:03§业务规则速览、02§引擎矩阵、R10§4.03、03§口径补充中均未见取值字典。]
涉及:P127 取现借款审批决策出处:R10§6
登记原文P127: 首借/复借审批决策取值字典与落库字段未见(RiskCode 字典/策略包版本 IT KB 查不到)
○ 待收口
G-039缺口U03 取现 Instant Cash

刷脸反欺诈在取现侧的输出落库字段不明

缺什么:F-17 刷脸反欺诈(CLCF) 在取现链路里的输出结果落到哪个字段没有登记。 为什么缺/线索:引擎矩阵只列了调用点(02§引擎矩阵)。
涉及:F-17 刷脸反欺诈出处:02§引擎矩阵
登记原文F-17: 刷脸反欺诈(CLCF)取现侧输出落库字段未见
○ 待收口
G-040缺口U03 取现 Instant Cash

RIPLAY 披露内容由谁配置、流程如何未建档

缺什么:P129 RIPLAY 披露内容字段组 的写入方——合规/产品配置合同模板的动作——没有建档;合同模板的配置流程也没有。 为什么缺/线索:出处只写了披露字段内容(03§RIPLAY)。
涉及:P129 RIPLAY 披露内容字段组出处:03§RIPLAY
登记原文P129: RIPLAY 披露内容写入方(合规/产品配置合同模板动作)未建档;合同模板配置流程未见
○ 待收口
G-041缺口U03 取现 Instant Cash

引擎判断首借还是复借的依据字段不明

缺什么:L023 规则(首支走首账前审批)和 P122 曾借款标记 背后,引擎判断一笔取现算首借还是复借的判据存在数据库里,具体字段名和表没有登记。 为什么缺/线索:需要业务方确认(03§口径补充、R10§5)。
涉及:L023 规则:首支走首账前审批P122 曾借款标记出处:03§口径补充·R10§5
登记原文L023 / P122: 引擎侧首借/复借切换判据存 DB,字段名与表未见(需业务方确认)
○ 待收口
G-042缺口U03 取现 Instant Cash

放款资金入钱包的最后一跳链路未闭合

缺什么:A-26 放款 的资金最终进入 Allo Wallet 钱包(R072 放款至钱包)这最后一跳经过哪些系统没有串起来。 为什么缺/线索:IT 知识库里该链路未闭合(R10§6)。
涉及:A-26 放款R072 放款至(钱包)出处:R10§6
登记原文A-26 / R072: 放款资金落 Allo Wallet 的最后一跳链路在 IT KB 未闭合
○ 待收口
G-043缺口U03 取现 Instant Cash

高额度挽留问卷的内容和作答去向不明

缺什么:N043 UI 展示记录 中的高额度挽留问卷,问卷题目内容、用户作答提交后落到哪、作答事件如何记录都没有登记,目前只知道弹窗的触发条件和节流规则。 为什么缺/线索:出处只写了弹窗触发(03§高额度挽留问卷弹窗)。
涉及:N043 UI 展示记录出处:03§高额度挽留问卷弹窗
登记原文N043 挽留问卷: 问卷内容/提交落库/作答事件未见,只知弹窗触发与节流
○ 待收口
G-044缺口U03 取现 Instant Cash

低价档各档费率、适用人群、发券规则待 PM

缺什么:P035 低价档字段组 在现网各档的费率值(0/0.5/1.5/2.5%)、每档适用哪些人群、对应的券怎么发,都没有登记。 为什么缺/线索:这些是营销/后台配置,不在代码里,待 PM(R4§6、03§口径补充)。
涉及:P035 低价档字段组出处:R4§6·03§口径补充
登记原文P035 低价档: 现网各低价档费率值(0/0.5/1.5/2.5%)与适用人群、券发放规则为营销/后台配置,待 PM
○ 待收口
G-045缺口U03 取现 Instant Cash

低价引导二期"第一价格区间上限"具体值不明

缺什么:L056 规则(主页低价引导二期收紧条件)里"额占率低于第一个价格区间上限才展示"的那个上限值是多少没有登记。 为什么缺/线索:该值是营销配置,前端没有判定常量(03§主页低价权益引导标记、R4§6)。
涉及:L056 规则:主页低价引导二期条件出处:03§主页低价权益引导标记·R4§6
登记原文L056: 额占率二期'第一个价格区间上限值'为营销配置,前端无判定常量
○ 待收口
G-046缺口U03 取现 Instant Cash

常规与低价取现页产品号取法不同,多产品账户会否算错

缺什么:L240 规则(取现试算入参)里,常规取现页的产品号动态取账户第一个贷款计划(loanPlans[0]),低价取现页却写死为 9022;一个账户有多个产品号时两页会不会试算到不同产品,没有答案。 为什么缺/线索:待后端确认(03§待确认)。
涉及:L240 规则:取现试算入参约束出处:03§待确认
登记原文L240: 常规页 LOAN_CODE 动态取 loanPlans[0] vs 低价页硬编码 9022,多产品号账户下是否试算到不同产品待后端
○ 待收口
G-047缺口U03 取现 Instant Cash

取现授权 15 项检查的完整清单缺失

缺什么:L235 规则(取现授权须过 15 个检查点)的完整清单没有,目前只知道第一项是锁定码检查、另有两道额度检查。 为什么缺/线索:出处只给了部分(03§后端事实增补)。
涉及:L235 规则:取现授权 15 项检查出处:03§后端事实增补
登记原文L235: 取现授权 15 个检查点全清单未见(仅知锁定码第一 + 两道额度检查)
○ 待收口
G-048缺口U03 取现 Instant Cash

支用结果动作码六个值有四个含义不明

缺什么:P041 支用提交结果码(风控挑战码) 中的动作码(ACTION_CODE)共六个值,其中 LR、LA、LACLNL、LACLNH 四个的业务含义没有登记,只知道 LRCLNR/LRCLNL 表示额度受限(QUOTA_LIMIT)。 为什么缺/线索:出处只见前端对那两个值的处理(R3§⑥其它场景码)。
涉及:P041 支用提交结果码(风控挑战码)出处:R3§⑥其它场景码
登记原文P041 ACTION_CODE: 六值中 LR/LA/LACLNL/LACLNH 语义未见(仅知 LRCLNR/LRCLNL→QUOTA_LIMIT)
○ 待收口
G-049缺口U03 取现 Instant Cash

取现"已批已扣未放款"作废单如何处理未建档

缺什么:P124 取现订单/协议状态 中的 S08 作废单——审批通过、钱已扣、但没放款——后续怎么处理、怎么补偿没有建档为动作,系统也没有自愈机制。 为什么缺/线索:出处只观测到该状态(R5§⑧)。
涉及:P124 取现订单/协议状态出处:R5§⑧
登记原文P124 S08: S08 作废单(批了、扣了钱、未放款)的处理/补偿动作未建档,无自愈
○ 待收口
G-050缺口U03 取现 Instant Cash

取现用券核销归哪个系统、放款失败券会否退回不明

缺什么:A-38 核销优惠券 在取现侧,利率券(INT_RG)和普通券通过 MES_INFO 核销时归哪个系统负责(NBS 200002 还是 IMEG 88200056)没有登记;放款失败时券状态会不会回滚也没有。 为什么缺/线索:出处只见核销调用(03§D.4、R10§4.11)。
涉及:A-38 核销优惠券出处:03§D.4·R10§4.11
登记原文A-38 取现侧: INT_RG/普通券经 MES_INFO 核销的系统归属(NBS 200002/IMEG 88200056)与放款失败时券状态是否回滚未见
○ 待收口
G-051缺口U03 取现 Instant Cash

低价权益与各类券的叠加优先级待 PM

缺什么:L060 规则(低价权益与利率券可叠加)之外,低价权益、支付立减券、Admin Fee 券之间叠加时谁优先没有统一规则。 为什么缺/线索:代码里没有统一的叠加器,待 PM(R4§4)。
涉及:L060 规则:低价权益与利率券叠加出处:R4§4
登记原文L060: 低价权益/支付立减券/Admin Fee 券叠加优先级无统一叠加器,待 PM
○ 待收口
G-052缺口U03 取现 Instant Cash

DBDP 风险标签是怎么打上去的未建档

缺什么:P004 风险码(风险标签集) 中 DBDP 标签的打标动作和圈选规则没有建档,目前只知道这个标签会强控相关字段。 为什么缺/线索:打标逻辑在风控侧(03§业务规则速览、R1§riskCode)。
涉及:P004 风险码(风险标签集)出处:03§业务规则速览·R1§riskCode
登记原文P004 DBDP: DBDP 标签的打标动作/圈选规则在风控侧,未建档(仅知字段强控)
○ 待收口
G-053缺口U03 取现 Instant Cash

虚拟卡自动补足的触发阈值和资金来源待 PM

缺什么:虚拟卡自动补足(VDC Auto top-up)的触发阈值,以及从信贷额度还是钱包补足,都没有定。 为什么缺/线索:待 PM 确认;当前前端仓库没有承载,归 U02 的 A-33 VDC 自动补足放款(03§待确认)。
涉及:A-33 VDC 自动补足放款出处:03§待确认
登记原文VDC Auto top-up: 触发阈值与补足来源(额度 vs 钱包)待 PM;本仓前端无承载(归 U02 A-33)
○ 待收口
G-054缺口U03 取现 Instant Cash

试算方案没有持久标识

缺什么:N046 试算方案 没有持久化的唯一标识,只是会话内的一次报价,作为对象无法落地追溯。 为什么缺/线索:出处只见会话内试算结果(03§D.2)。
涉及:N046 试算方案出处:03§D.2
登记原文N046 试算方案: 无持久标识(会话内报价),对象接地缺口
○ 待收口
G-055缺口U03 取现 Instant Cash

取现 OTP 结果值 1/2 的含义不明

缺什么:P044 挑战/OTP 链路字段 中 OTP 结果(OTP_RESULT)取值 1 和 2 分别代表什么没有登记。 为什么缺/线索:R7§取现 WhatsApp OTP 未给出,归 U12。
涉及:P044 挑战/OTP 链路字段出处:R7§取现 WhatsApp OTP
登记原文P044 OTP_RESULT: OTP_RESULT 1/2 语义未在本篇给出(R7/U12)
○ 待收口
G-056缺口U04 账单与账期、常规还款

还款宽限期 10 天从哪天起算

缺什么:宽限期 10 天的起算点没有说清——是「出账日到最后还款日」之间的缓冲(两代账期表面上是 9-10 天),还是「最后还款日之后到被标记逾期/上 A 锁定码」之间的缓冲。 为什么缺/线索:04§账期规则只写了 10 天但没写起点;R1§Block code 写的是「过了宽限日就上 A 码」,两者的关系待 PM/后端确认。
涉及:L255 规则:还款宽限期 10 天出处:04§账期规则·R1§Block code
登记原文L255 宽限期 10 天: 起算点未明：是出账日→最后还款日的缓冲（两代表面上为 9-10 天），还是最后还款日后至标记逾期/上 A 码的缓冲；与 R1'过宽限日→上 A'的关系待 PM/后端确认
○ 待收口
G-057缺口U04 账单与账期、常规还款

10 天 cutoff 规则和灵活码第 31 位是一回事吗

缺什么:灵活码第 31 位「按 cutoff day 出账/无 cutoff day」是否就是 04 篇说的 10 天 cutoff 归属规则,没有对上;另外借新还旧的新借据「默认跟随最近账单日」到底是什么意思,也没有说清。 为什么缺/线索:R1 对第 31 位只有一句位段说明,04§账期规则只讲 10 天规则,两边没互相引用。
涉及:L252 规则:cutoff day 10 天出账归属L253 规则:借新还旧新借据跟随最近账单日P002 灵活码出处:R1 第 31 位·04§账期规则
登记原文L252 / L253 cutoff day 与 Flex 第 31 位: R1 第 31 位'按 cutoff day 出账/无 cutoffday'是否即 04 篇的 10 天 cutoff 规则；借新还旧新借据默认 follow 最近账单日的准确含义
○ 待收口
G-058缺口U04 账单与账期、常规还款

退款是什么情况触发、退到哪里、能不能撤

缺什么:退款动作的触发条件(是客户多还/溢缴退款,还是商户发起退款,两种含义未分)、到账路径(退到钱包还是原路退回)、能否撤销、有什么前置条件,全部没有登记。 为什么缺/线索:04§待确认与「待确认清单·后端 3」都挂着这个问题;目前只知道两个技术锚点(ICPS 222111 退款接口、QRIS 的 refund-qris-payment 与 reversal),待后端补齐。 [2026-08-27 SEG2 核验补充具体问题:退款(A-36)与 VDC 撤销(A-58)写入不对称——A-58 写借据冲销与额度恢复,A-36 两者都不写,积分腿与钱包腿的返还写入方也空缺。请后端一次答清四条腿(PL/钱包/积分/立减)各自的回退路径与写入方。]
涉及:A-36 退款N053 退款单出处:04§待确认·_待确认清单 后端 3
登记原文A-36 退款: 触发条件（多还/溢缴 vs 商户退款两义）、到账路径（钱包 or 原路）、可逆性、前置条件全缺；已知锚点 ICPS 222111 / QRIS refund-qris-payment+reversal
○ 待收口
G-059缺口U04 账单与账期、常规还款

出账批处理怎么跑、利息怎么算,尚未闭合

缺什么:出账批量的具体步骤、计息规则、以及「当期账单状态」的后端取值字典(CURR_STMT_STATUS)都没有闭合;日终主批(cpsJob 00:00)是否就是出账批,也没有证实。 为什么缺/线索:R10§4-04、R5§⑧、05§E.7 各写了一部分,IT KB 里没有能把整条链串起来的材料。
涉及:A-40 出账P198 前一账期账单状态出处:R10§4-04·R5§⑧·05§E.7
登记原文A-40 出账: 出账批量 step、计息规则、CURR_STMT_STATUS 后端字典 IT KB 未闭合；日终主批 cpsJob 00:00 是否即出账批未证实
○ 待收口
G-060缺口U04 账单与账期、常规还款

「有当期欠款才出账单」这条旧规则还成立吗

缺什么:旧登记里「有当期欠款才出账单」这句话,在现有资料里找不到再次佐证;反而前端有一个「未使用账单」判断(当期账单金额与已还金额都为 0),暗示零金额账单是可能存在的。 为什么缺/线索:R5§③;需要后端确认零额账单会不会生成,再决定旧规则去留。
涉及:L062 规则:按账单日出账出处:R5§③
登记原文L062: '有当期欠款才出'旧登记语句现语料未再证实（isUnused=CUR_STMT_AMT===0&&STMT_PAID_AMT===0 暗示零额账单可存在）
○ 待收口
G-061缺口U04 账单与账期、常规还款

自动扣款的钱从哪来、能不能撤、时点是否确定

缺什么:自动扣款的资金来源(是否就是钱包 VA)、扣款后是否会生成一笔还款交易记录、能否撤销,都没有登记;「余额低于 Rp1,000 就跳过」这条过滤规则没有实现证据;扣款时点只有三天生产实测,没有正式口径。 为什么缺/线索:05§E.7 只有观测记录,没有后端规则文档。
涉及:A-60 自动扣款N018 还款交易出处:05§E.7
登记原文A-60 自动扣款: 扣款资金来源（是否即钱包 VA）、是否落 N018 实例、可逆性；Rp1,000 低余额过滤无实现证据；时点仅三天生产实测
○ 待收口
G-062缺口U04 账单与账期、常规还款

账龄档 1-9 各对应多少天、挂在账户还是借据上

缺什么:账龄档(AGE_CD)1-9 的完整取值与对应天数区间没有登记;它是账户级还是借据级的属性也不清楚。 为什么缺/线索:05§E.1、05§E.6、R1 里只零散用到个别值(如 >4 用于核销门槛),没有完整字典。
涉及:P132 账龄档出处:05§E.1·05§E.6·R1
登记原文P132 AGE_CD: 完整 1-9 取值与天数映射；宿主级别（账户 vs 借据）
○ 待收口
G-063缺口U04 账单与账期、常规还款

还款状态前后端两套取值怎么对应

缺什么:还款状态在后端只有成功/失败(S/F),前端却定义了处理中/成功/完成(P/S/C,轮询时还有 PENDING),两套取值集之间的对应关系没有统一。 为什么缺/线索:05§E.2 与 R7§2.3 各写各的,待统一。
涉及:P130 还款交易要素组出处:05§E.2·R7§2.3
登记原文P130 REPAY_STATUS: 后端 S/F 与前端 REPAYMENT_STATUSES P/S/C（及轮询 PENDING）取值集对应关系待统一
○ 待收口
G-064缺口U04 账单与账期、常规还款

交易流水的收支方向、会员商户名、与业务事件的对应关系

缺什么:交易流水的金额方向(哪些是收、哪些是支,正负号怎么定)没有定义;会员费交易显示的商户名要后端确认;流水记录和消费支付、还款这些业务事件是不是「同一件事的两个视角」、实例怎么对应,还没有建模决定。 为什么缺/线索:R7§2.3 只列了流水字段,方向与映射留白。
涉及:N037 交易流水(记录)N018 还款交易N015 消费支付交易出处:R7§2.3
登记原文N037 交易流水: 金额方向（收/支符号）无定义；会员交易商户名待后端；N037 与 N018/N015 等业务事件的实例对应关系（同一事实两视角）待建模决定
○ 待收口
G-065缺口U04 账单与账期、常规还款

逾期罚息日利率现网到底是多少

缺什么:罚息日利率(PENALTY_RATE)的现网实际值没有登记,0.3%/日只是 RIPLAY 披露口径。 为什么缺/线索:R4§6 费率表里此项留空,前端不持有该值,需向后端/参数表核对。
涉及:L064 规则:逾期账单罚息 0.3%/日P133 账期参数组出处:R4§6
登记原文L064 / P133 罚息日率: PENALTY_RATE 现网值（0.3%/日为 RIPLAY 口径）
○ 待收口
G-066缺口U04 账单与账期、常规还款

账期参数是谁在哪配置的

缺什么:账期参数组(出账日、还款日、宽限期等)的写入方——是哪个后台配置项或参数表在维护——没有建档。 为什么缺/线索:04§账期规则只写了规则值,没写来源系统。
涉及:P133 账期参数组出处:04§账期规则
登记原文P133 账期参数组: 写入方（后台配置项/参数表）未建档
○ 待收口
G-067缺口U04 账单与账期、常规还款

综合账户态九个取值分别是什么意思

缺什么:综合账户态的九个取值(W/AC/NAC/RFC/OPC/NU/HN/HF/HO)各自的业务含义,知识库里没有给出。 为什么缺/线索:R5§③只列出了取值,没有释义。
涉及:P009 综合账户态(派生)出处:R5§③
登记原文P009 综合账户态: 九值 W/AC/NAC/RFC/OPC/NU/HN/HF/HO 各值业务含义知识库未给出
○ 待收口
G-068缺口U04 账单与账期、常规还款

还款冲抵明细的标识与落表只是推测,冲正机制未见

缺什么:还款冲抵明细(一笔还款分别冲了哪些本金/利息/费用)的唯一标识字段和落表(推测为 TM_PAYMENT_HST)都只是推断;冲正/撤销机制没有找到。 为什么缺/线索:05§E.1 与 R10§4-04 只见到表名线索,待后端证实。
涉及:N083 还款冲抵明细出处:05§E.1·R10§4-04
登记原文N083 还款冲抵明细: 身份标识与落表（TM_PAYMENT_HST）为推断；冲正机制未见
○ 待收口
G-069缺口U04 账单与账期、常规还款

商户退款和多还退款是不是同一种「退款单」

缺什么:商户发起的退款(流水里 R 型记录、带商户名)与客户多还/溢缴产生的退款,是否应视为同一个「退款单」对象,没有定论。 为什么缺/线索:R7§2.2 与 04§业务视角各只描述其中一种。
涉及:N053 退款单出处:R7§2.2·04§业务视角
登记原文N053 退款单: 商户退款（R 型流水带 MERCHANT_NAME）与多还/溢缴退款是否同一对象
○ 待收口
G-070缺口U04 账单与账期、常规还款

「额度变更历史」产品要做,但接口还没定义

缺什么:「额度变更历史」(top-up、解押、调额等记录的查询)产品已确认需要(2026-08-13),但页面路由和接口还没有定义。 为什么缺/线索:04§待确认、待确认清单 SA 第 6 条;待 SA 定义,并注意不要与账单历史、交易历史混为一谈。
出处:04§待确认·_待确认清单 SA 6
登记原文04§待确认 额度变更历史: '额度变更历史（top-up/解押/调额记录）'产品已确认需要（2026-08-13），路由/接口待 SA 定义；不得与账单历史/交易历史混淆
○ 待收口
G-071缺口U04 账单与账期、常规还款

还款/退款/出账等动作缺少观测指标

缺什么:受理还款、受理提前结清、退款、出账、标记逾期、计收罚息、结清核销这些动作,大多没有登记观测指标和回看窗口(做完之后看什么数据、看多久来判断效果);目前只有受理还款可以从还款状态推出。 为什么缺/线索:各出处均未提供这类语料。
涉及:A-06 受理还款A-07 受理提前结清A-36 退款A-40 出账A-41 标记逾期A-42 计收罚息A-43 结清核销出处:—
登记原文A-06/A-07/A-36/A-40~A-43 feedback: 多数动作的观测指标与回看窗口语料未给出（仅 A-06 可由 REPAY_STATUS 推）
○ 待收口
G-072缺口U05 减压与重组(灵活还款四路:月最低还款/账单分期/逾期重组·协商/转分期)

预付门槛的读取与结算接口前端只是占位

缺什么:预付门槛任务的「读取预付状态」和「结算」两个接口在前端只是占位(未注册的开放问题 OQ-006),真实接口契约和预付金额的后端字段名(prepayAmount)待后端给出。 为什么缺/线索:05§D.4、R3§②。
涉及:N052 预付门槛任务A-62 核销预付门槛出处:05§D.4·R3§②
登记原文N052 / A-62: 预付状态读取与结算两接口在前端为占位(OQ-006 未注册),真实契约与 prepayAmount 后端字段名待后端
○ 待收口
G-073缺口U05 减压与重组(灵活还款四路:月最低还款/账单分期/逾期重组·协商/转分期)

预付门槛开关没进后台开关清单

缺什么:重组预付门槛开关(restructurePrepaySwitch)没有收录进后台开关清单,它在哪被读取、默认值是什么都缺。 为什么缺/线索:R6§一 的开关清单里没有它,只在 05 篇的修订记录 #4 里出现过。
涉及:P062 后台开关组 子项 restructurePrepaySwitch出处:05§预付门槛判定来源同步换轨·R6§一
登记原文P062.restructurePrepaySwitch: R6 开关清单未收录该开关(仅见 05 revision #4),消费点与默认值缺
○ 待收口
G-074缺口U05 减压与重组(灵活还款四路:月最低还款/账单分期/逾期重组·协商/转分期)

展期资格(ZQ01)是按什么条件圈的人

缺什么:展期资格 ZQ01 的圈选条件和策略在风控侧,知识库里是空白;目前只知道是定期筛选,再由人工通过 Workbench 上传。 为什么缺/线索:06§口径补充、R9§一。
涉及:F-65 ZQ01 展期资格圈选出处:06§口径补充·R9§一
登记原文F-65 ZQ01 圈选: 筛选条件/策略在风控侧留白;仅知定期筛+人工 Workbench 上传
○ 待收口
G-075缺口U05 减压与重组(灵活还款四路:月最低还款/账单分期/逾期重组·协商/转分期)

转分期的现网费率是多少

缺什么:转分期的现网费率(日利率 DAY_INT_RATE_INSTALLMENT、手续费率 ADMIN_FEE_RATE)不掌握,它们放在 ICPS 生产参数表里,代码仓和 IT KB 都不持有。 为什么缺/线索:06§待确认、待确认清单 #1;需向后端取。
涉及:P145 转分期费用组出处:06§待确认·_待确认清单#1
登记原文P145 转分期费率: 现网 DAY_INT_RATE_INSTALLMENT/ADMIN_FEE_RATE 值(ICPS 生产参数表),代码仓与 IT KB 均不持有
○ 待收口
G-076缺口U05 减压与重组(灵活还款四路:月最低还款/账单分期/逾期重组·协商/转分期)

逾期重组/协商方案的减免比例现网值

缺什么:逾期重组方案与协商还款方案中,本金、利息、罚息的减免比例现网实际值没有登记。 为什么缺/线索:R4§6;减免比例由风险侧上传,前端不持有。
涉及:P140 协商方案要素组P141 逾期重组方案要素组出处:R4§6
登记原文P140 / P141 减免比例: 逾期重组与协商方案的本金/利息罚息减免比例现网值(风险上传,前端不持有)
○ 待收口
G-077缺口U05 减压与重组(灵活还款四路:月最低还款/账单分期/逾期重组·协商/转分期)

协商方案确认后怎么放款/换据,后端链路看不见

缺什么:协商还款方案下挂的状态机在后端没有闭合;客户确认方案之后的放款或换据链路,从 SDK 侧看不到。 为什么缺/线索:R10§6、05§D.5。
涉及:N051 协商还款方案A-12 受理协商方案确认出处:R10§6·05§D.5
登记原文N051 协商还款方案: 方案下挂状态机后端未闭合;A-12 确认后放款/换据链路 SDK 不可见
○ 待收口
G-078缺口U05 减压与重组(灵活还款四路:月最低还款/账单分期/逾期重组·协商/转分期)

月最低还款通道后端是否也检查灵活码首位

缺什么:借新还旧受理闸门②要求灵活码首位为 1,但月最低还款(MINI_REPAY)通道的后端闸门是否也同样检查首位,没有写明(前端读的是第 3 位)。 为什么缺/线索:05§E.4。
涉及:L273 规则:借新还旧闸门②灵活码首位P002 灵活码出处:05§E.4
登记原文L273: MINI_REPAY 通道后端闸门是否同样查 FlexCode 首位(前端读第 3 位)未写明
○ 待收口
G-079缺口U05 减压与重组(灵活还款四路:月最低还款/账单分期/逾期重组·协商/转分期)

「逐借据期数资格」后端用哪个字段判

缺什么:借新还旧闸门④「纳入的借据须满足期数条件」,后端具体用哪个字段判定没有登记;把它对应到灵活码第 20-23 位只是推断。 为什么缺/线索:05§E.4。
涉及:L275 规则:借新还旧闸门④逐借据期数资格P002 灵活码出处:05§E.4
登记原文L275: 『逐借据期数资格』后端具体判定字段;与 Flex 20-23 位的对应为推断
○ 待收口
G-080缺口U05 减压与重组(灵活还款四路:月最低还款/账单分期/逾期重组·协商/转分期)

重组名单和方案通过什么工具上传

缺什么:逾期重组方案、预付名单、协商方案的上传工具和工单流程(是否走 Workbench 的 Universal List)没有写明。 为什么缺/线索:05§逾期重组(0716)、R9。
涉及:A-48 上传重组名单与方案出处:05§逾期重组(0716)·R9
登记原文A-48 上传渠道: 逾期重组方案/预付名单/协商方案的上传工具与工单流程(是否走 Workbench Universal List)未写明
○ 待收口
G-081缺口U05 减压与重组(灵活还款四路:月最低还款/账单分期/逾期重组·协商/转分期)

试算业务场景码全集有没有前端没见过的值

缺什么:试算业务场景码(BIZ_SCENE)的完整取值集不清楚——除了前端出现过的,后端是否还有其他场景值,需后端给;它和交易码是否应归并,待审核。 为什么缺/线索:R3§待确认。
涉及:P136 试算业务场景码(BIZ_SCENE)P039 交易码出处:R3§待确认
登记原文P136 BIZ_SCENE: 全集是否还有前端未出现的场景值,需后端;与 P039 的归并关系待审核
○ 待收口
G-082缺口U05 减压与重组(灵活还款四路:月最低还款/账单分期/逾期重组·协商/转分期)

转分期一次能不能对多笔借据

缺什么:转分期一次能否作用于多笔借据没有定论——接口参数是数组(loanReorgList),但用户旅程只描述单笔。 为什么缺/线索:06§D。
涉及:R017 作用于(改期)N022 转分期(展期)申请出处:06§D
登记原文R017: 转分期一次是否可对多笔借据(loanReorgList 为数组,旅程为单笔)
○ 待收口
G-083缺口U05 减压与重组(灵活还款四路:月最低还款/账单分期/逾期重组·协商/转分期)

展期的最长期数、最低本金现网值

缺什么:展期后端硬门槛「新期数上限 12 期」「最低剩余本金 Rp500,000」是 UAT 参数,现网实际值待后端。 为什么缺/线索:06§后端事实增补。
涉及:L281 规则:展期后端硬门槛(期数/本金)出处:06§后端事实增补
登记原文L281/12: MAX_TERM=12 / MIN_BAL_PRIN=500000 为 UAT 参数,现网值待后端
○ 待收口
G-084缺口U05 减压与重组(灵活还款四路:月最低还款/账单分期/逾期重组·协商/转分期)

展期入口的「白名单用户」是不是就是 ZQ01

缺什么:展期入口规则里的「白名单用户」是否就等于风险码里含 ZQ01 的用户,只是推断,源 PRD《1230》没有明写。 为什么缺/线索:05§展期入口。
涉及:L097 规则:还款模块展期入口展示条件P004 风险码出处:05§展期入口
登记原文L097 白名单: 『白名单用户』是否即 riskCode∋ZQ01(推断),PRD《1230》未明写
○ 待收口
G-085缺口U06 质押与额度成长(LimitUp 专属)

额度成长任务(Mission)后端在哪、规则值是多少

缺什么:额度成长任务的后端实现系统没有指认(IT KB 零命中,不要绑到 igame-app);任务达成条件、奖励额度、Top-up 倍数的现网值,以及任务状态由谁写入,都缺。 为什么缺/线索:08§待确认/风险、R10§4 08。
涉及:N059 额度成长任务N035 任务完成P165 任务状态出处:08§待确认/风险·R10§4 08
登记原文N059/N035/P165: Mission 后端实现系统未指认(IT KB 0 命中,勿绑 igame-app);任务达成条件/奖励额度/Top-up 倍数现网值;任务状态写入方
○ 待收口
G-086缺口U06 质押与额度成长(LimitUp 专属)

提额记录的标识字段与类型全集

缺什么:提额记录的唯一标识字段名与落表没有登记;提额记录类型的取值全集也不完整(现有取值是前端常量加 PRD 拼合出来的)。 为什么缺/线索:07§实时提升杠杆率、R3§⑥。
涉及:N057 提额记录P055 提额记录类型出处:07§实时提升杠杆率·R3§⑥
登记原文N057: 提额记录身份标识字段名与表;类型取值全集(P055 由前端常量+PRD 拼合)
○ 待收口
G-087缺口U06 质押与额度成长(LimitUp 专属)

调额补偿记录由哪个动作产生、能否撤销

缺什么:调额补偿记录是在会员购买链路落表时产生,还是在调额失败分支才产生,以及表名,都没有登记;人工补偿动作能否撤销也缺。 为什么缺/线索:07§实时提升杠杆率、10§。
涉及:N058 调额补偿记录A-45 会员调额人工补偿出处:07§实时提升杠杆率·10§
登记原文N058: 补偿记录产出动作(会员购买链路落表 vs 调额失败分支)与表名;A-45 可逆性
○ 待收口
G-088缺口U06 质押与额度成长(LimitUp 专属)

重新授信成功后新额度走哪个动作落地

缺什么:重新授信(reapply)成功后,新额度是通过「授信裁决落地」还是「执行调额」写进账户,没有证实。 为什么缺/线索:07§重新风险授信流程。
涉及:P164 reapply 引擎核定额度A-13 受理重新授信申请A-22 授信裁决落地A-31 执行调额出处:07§重新风险授信流程
登记原文P164/A-13: reapply 成功后新额度落地走哪个动作(A-22 授信裁决落地 vs A-31 调额)未证实
○ 待收口
G-089缺口U06 质押与额度成长(LimitUp 专属)

风险标签「XXXX」的具体值待补

缺什么:规则里写的 Risk Flag=XXXX 具体是什么值,还没有填上。 为什么缺/线索:R1§四;待 PM 补值。
涉及:L318 规则:特定风险标签下的处理P004 风险码出处:R1§四
登记原文L318: Risk Flag=XXXX 具体值待 PM 补
○ 待收口
G-090缺口U06 质押与额度成长(LimitUp 专属)

提额入口渠道 04~08 是什么

缺什么:提额入口渠道(EnterLimitChannel)的取值 04~08 没有见到含义。 为什么缺/线索:R3§⑦只见到部分取值。
涉及:P056 提额入口渠道出处:R3§⑦
登记原文P056: EnterLimitChannel 04~08 取值未见
○ 待收口
G-091缺口U06 质押与额度成长(LimitUp 专属)

质押本金优先字段还没上线

缺什么:风控团队拟提供的「质押本金优先」字段(pledgeBalanceAmount)尚未实现,上线计划未定。 为什么缺/线索:R3§③。
涉及:P017 质押杠杆信息组出处:R3§③
登记原文P017: pledgeBalanceAmount(risk team 拟提供的质押本金优先字段)未实现,上线计划未定
○ 待收口
G-092缺口U06 质押与额度成长(LimitUp 专属)

质押成功邮件由谁发

缺什么:质押锁定成功后给客户的邮件通知,发送方没有登记——前端没有发,待后端/营销确认。 为什么缺/线索:R7§1.5。
涉及:L308 规则:质押成功邮件通知出处:R7§1.5
登记原文L308: 质押成功邮件发送方(前端未发,待后端/营销)
○ 待收口
G-093缺口U06 质押与额度成长(LimitUp 专属)

LimitUp 名单怎么维护、范围是什么

缺什么:LimitUp 相关名单的维护流程、所在系统、能否撤销都缺;SHOPEE/BPJS 白名单与 Beta/Gamma 放量名单的具体范围需要找风控。 为什么缺/线索:07§后端事实增补。
涉及:A-66 维护 LimitUp 相关名单出处:07§后端事实增补
登记原文A-66: 名单维护流程/系统/可逆性;SHOPEE/BPJS 白名单与 Beta/Gamma 放量名单具体范围需找风控
○ 待收口
G-094缺口U06 质押与额度成长(LimitUp 专属)

「Prime 会员」指钱包档位还是 LimitUp 会员

缺什么:「定存清单只对 Prime(Premium)会员可取」里的 Prime,是指钱包账户等级里的 Prime,还是 LimitUp 的 Premium 会员,没有说清。 为什么缺/线索:09§后端事实增补。
涉及:L301 规则:定存清单仅 Prime 会员可取出处:09§后端事实增补
登记原文L301: 'Prime(Premium)会员'含义(钱包档位 Prime vs LimitUp Premium)
○ 待收口
G-095缺口U06 质押与额度成长(LimitUp 专属)

可用额度到底谁是唯一写入方

缺什么:可用额度的写入方没有定下来——支用、还款等多个动作都会改它,尚未确定单一写入方。 为什么缺/线索:07§额度构成;归 U03 核。
涉及:P147 可用额度出处:07§额度构成
登记原文P147: 可用额度单一写入方(支用/还款多写入)——本单元未定,U03 核
○ 待收口
G-096缺口U06 质押与额度成长(LimitUp 专属)

存单本金由谁写入、存单靠什么字段标识

缺什么:存单本金的写入方没有建档(存款域的购买事件未登记);定存存单的唯一标识字段名也缺。 为什么缺/线索:09§核心能力。
涉及:P160 存单本金N006 定存存单出处:09§核心能力
登记原文P160/N006: 存单本金写入方(存款域购买事件未建档);存单身份字段名
○ 待收口
G-097缺口U06 质押与额度成长(LimitUp 专属)

定存流动性价格 ID 存在哪

缺什么:定存流动性价格 ID 的字段名和落表没有登记。 为什么缺/线索:09§价格权益与额占率定价。
涉及:P153 定存流动性价格 ID出处:09§价格权益与额占率定价
登记原文P153: 定存流动性价格 ID 字段名/落表
○ 待收口
G-098缺口U06 质押与额度成长(LimitUp 专属)

质押物代偿在什么情况下触发、归谁管

缺什么:质押物代偿(RMS 代偿)的触发前提——什么样的欠款或逾期状态会触发——以及归属哪个职能域,都没有登记。 为什么缺/线索:09§后端事实增补。
涉及:A-65 执行质押物代偿出处:09§后端事实增补
登记原文A-65: RMS 代偿触发前提(何种欠款/逾期态触发)、职能域归属
○ 待收口
G-099缺口U06 质押与额度成长(LimitUp 专属)

营销码第 5-7 位现网实际取值分布

缺什么:营销码第 5-7 位(定存质押比例)在现网的实际取值分布不掌握。 为什么缺/线索:09§待确认/风险;待以现网数据/营销配置核对。
涉及:P001 营销码出处:09§待确认/风险
登记原文P001 第5-7位: 现网取值分布(待以现网/营销配置核对)
○ 待收口
G-100缺口U06 质押与额度成长(LimitUp 专属)

Y001_R1 标签是什么意思、权益差在哪

缺什么:风险码里 Y001_R1 标签的业务含义,以及它与 Y001 的权益差异,没有登记。 为什么缺/线索:07§业务代码字段、R2§三。
涉及:P004 风险码出处:07§业务代码字段·R2§三
登记原文P004 Y001_R1: Y001_R1 标签的业务含义/权益差异
○ 待收口
G-101缺口U06 质押与额度成长(LimitUp 专属)

补充资料传错了能不能重传

缺什么:补充资料上传这一动作能否撤销、能否重传,没有登记。 为什么缺/线索:07§额度成长来源。
涉及:A-19 受理补充资料上传出处:07§额度成长来源
登记原文A-19: 补充资料上传可逆性(可否重传)
○ 待收口
G-102缺口U06 质押与额度成长(LimitUp 专属)

协议同意记录存在哪张表、有哪些字段

缺什么:协议同意记录的字段名与落表没有登记(推测是 t_protocol_consent)。 为什么缺/线索:09§T&C 协议、R10§4 01。
涉及:N033 协议同意P061 协议同意记录字段组出处:09§T&C 协议·R10§4 01
登记原文N033/P061: 协议同意记录字段名与表(t_protocol_consent 推测)
○ 待收口
G-103缺口U06 质押与额度成长(LimitUp 专属)

计费类规则改挂属性后没有门控,职能域归属待定

缺什么:质押新增额度公式、解押存单提前支取 0% 结算、任务奖励额度上限等计费类规则改挂到属性后,不再有门控(gate)承载;「账务/风控运营」这个职能域只是暂定名。 为什么缺/线索:handbook-ch5;待审核归并。
涉及:L112 规则:定存质押新增额度公式L117 规则:曾质押存单提前支取 0% 结算L134 规则:任务奖励额度上限不由营销码编码出处:handbook-ch5
登记原文gate 门类: L112/L117/L134 等计费类改挂属性后无 gate;'账务/风控运营'职能域为本单元暂定,待审核归并
○ 待收口
G-104缺口U07 会员与营销

会员状态除了「有效」还有哪些值

缺什么:会员态里的 status 除了 ACTIVE 之外的取值没有登记——过期、未激活分别怎么表示。 为什么缺/线索:10§两个独立信号。
涉及:P051 会员态组 子项 status出处:10§两个独立信号
登记原文P051.status: member.status 除 ACTIVE 外的取值(过期/未激活如何表示)
○ 待收口
G-105缺口U07 会员与营销

会员购买记录的四个状态是什么

缺什么:会员购买记录表(t_limit_up_member_record)四个状态的具体取值与含义没有登记。 为什么缺/线索:R10§4-10。
涉及:P176 会员购买记录字段组出处:R10§4-10
登记原文P176 记录状态: t_limit_up_member_record 四状态具体取值与含义
○ 待收口
G-106缺口U07 会员与营销

会员费能不能退、购买能不能撤销

缺什么:会员费是否可退、会员购买是否可撤销,没有见到口径。 为什么缺/线索:10§购买月会员流程。
涉及:A-16 受理会员购买出处:10§购买月会员流程
登记原文A-16 reversibility: 会员费是否可退/购买是否可撤销,未见口径
○ 待收口
G-107缺口U07 会员与营销

会员费除了钱包支付还有别的方式吗

缺什么:会员费「默认钱包支付」之外,是否还存在其他支付方式,没有登记。 为什么缺/线索:10§购买月会员流程。
涉及:A-16 受理会员购买出处:10§购买月会员流程
登记原文A-16 支付方式: '默认钱包支付'之外是否存在其他会员费支付方式
○ 待收口
G-108缺口U07 会员与营销

会员购买成功后有没有 push/邮件/WA 通知

缺什么:会员购买后前端只有 UI 弹窗,push、邮件、WhatsApp 通知由后端/营销承担,但渠道和文案没有见到。 为什么缺/线索:R7§1.5。
涉及:A-16 受理会员购买出处:R7§1.5
登记原文会员购买通知: 前端仅 UI 弹窗,push/邮件/WA 通知由后端/营销承担,渠道与文案未见
○ 待收口
G-109缺口U07 会员与营销

会员费流水的商户名归属与交易类型

缺什么:会员费在交易流水里显示的商户名(Pay to limit up premium)由后端哪一方决定、对应哪种交易类型,没有登记。 为什么缺/线索:R7§2.3。
涉及:N037 交易流水(记录)P037 交易类型出处:R7§2.3
登记原文N037 会员费流水: 商户名 Pay to limit up premium 的后端归属与交易类型映射
○ 待收口
G-110缺口U07 会员与营销

调额补偿表叫什么、人工补偿从哪操作

缺什么:调额补偿记录的表名、字段,以及人工补偿的操作入口和流程,都没有登记。 为什么缺/线索:R10§4-10;IT KB 里没有补偿扫描入口。
涉及:N058 调额补偿记录A-45 会员调额人工补偿出处:R10§4-10
登记原文N058 / A-45: 补偿表实体名、字段、人工补偿操作入口与流程(IT KB 无扫描入口)
○ 待收口
G-111缺口U07 会员与营销

SMP 立减券的品类码、规则主键和状态全集是什么

缺什么:N085 SMP 支付立减券规则配置与 P050 立减规则组中,券品类码(如 80010004)各代表什么、券规则的唯一主键是哪个字段、SMP 券状态的全部取值,都没有登记。 为什么缺/线索:出处 11§待确认;语料里只见零星码值,完整字典未出现。
涉及:N085 SMP 支付立减券规则配置P050 立减规则组出处:11§待确认
登记原文N085 / P050: SMP 券品类码(80010004 等)含义、券规则主键、SMP 券状态全值
○ 待收口
G-112缺口U07 会员与营销

多次核销券的「剩余次数」角标由谁展示

缺什么:配置了多次核销的券,卡券左上角要显示当前剩余可用次数,但这个角标由哪一端渲染没有登记——PayLater SDK 前端仓库里没有渲染它。 为什么缺/线索:出处 11§支付立减券规则(源 PRD 有此要求,规则 L342);承载方待确认。
涉及:L342 规则:多次核销券剩余次数角标出处:11§支付立减券规则
登记原文L342: 多次核销'剩余次数角标'承载方(本仓未渲染)
○ 待收口
G-113缺口U07 会员与营销

期限券「多选多张+底部确认」交互落在哪一端

缺什么:N029 优惠券使用选择中,源 PRD 要求的按 PayLater 期限配置的券可「一次多选多张、底部确认」交互,SDK 前端仓库没有实现,不知道由哪个端承载。 为什么缺/线索:出处 11§按 PL 期限配置;归属待确认。
涉及:N029 优惠券使用选择出处:11§按 PL 期限配置
登记原文N029 期限券多选: 源 PRD'多选多张+底部确认'交互本仓未落地,归属待确认
○ 待收口
G-114缺口U07 会员与营销

优惠券的权威账本归哪个系统管

缺什么:N048 营销权益券与 N049 SMP 支付立减券的权威账本(券的发放/使用/状态最终以谁为准)归哪个系统所有,没有定论。 为什么缺/线索:出处 R10§4-11、11§后端事实增补;已知券核销经营销服务(NBS 200002),但其下游链路未闭合,IT KB 也未裁定。
涉及:N048 营销权益券(EQUITY)N049 SMP 支付立减券出处:R10§4-11·11§后端事实增补
登记原文N048/N049 权威账本: 券的权威账本 owner(NBS 200002 下游未闭合)IT KB 未裁定
○ 待收口
G-115缺口U07 会员与营销

直减预算账本的字段、额度和归属系统未知

缺什么:N086 直减预算账本(promo_budget)有哪些字段、预算额度多少、归属哪个系统,都没有登记。 为什么缺/线索:出处 11§后端事实增补;仅知这个账本存在。
涉及:N086 直减预算账本出处:11§后端事实增补
登记原文N086: promo_budget 账本字段、额度、归属系统
○ 待收口
G-116缺口U07 会员与营销

可配置化留资页是否还采集姓名

缺什么:留资校验规则从 0508 可配置化版起移除了 OTP 发送与验证,但该版本是否仍采集用户姓名、姓名如何校验,没有写明。 为什么缺/线索:出处 11§营销落地页可配置化(规则 L354);源 PRD 未提及。
涉及:L354 规则:留资校验(可配置化版)出处:11§营销落地页可配置化
登记原文L354: 0508 版留资是否仍采集姓名及其校验
○ 待收口
G-117缺口U07 会员与营销

留资 H5 的后端系统、落库表和记录标识未知

缺什么:A-18 受理留资提交后,留资数据由哪个后端系统接收、落在哪张表、N030 留资提交记录的唯一标识字段是什么,都没有登记。 为什么缺/线索:出处 11§留资类营销落地页;留资 H5 部署在 mvp.allobank.com,不在 SDK 代码仓内,无法从代码查实。
涉及:A-18 受理留资提交N030 留资提交出处:11§留资类营销落地页
登记原文A-18 / N030: 留资 H5 后端系统与落库表(mvp.allobank.com 仓外)、留资记录身份字段
○ 待收口
G-118缺口U07 会员与营销

MGM 推荐关系怎么落库、推荐提额怎么生效

缺什么:R044 推荐关系落在哪张表(推测在 MGM 系统 imgm/imgm-h5)、A-20 受理推荐码提交后 MGM 推荐提额(100K/200K)由哪个动作生效、任务(Mission)的后端系统是哪个,都没有登记。 为什么缺/线索:出处 R10§4-08、10§会员权益;IT KB 未闭合。
涉及:R044 推荐A-20 受理推荐码提交出处:R10§4-08·10§会员权益
登记原文R044 / A-20: MGM 推荐关系落库(imgm/imgm-h5)、MGM 提额 100K/200K 的生效动作、Mission 后端系统
○ 待收口
G-119缺口U07 会员与营销

营销码前两位 01→00 的批量变更规则

缺什么:用户的 P001 营销码可随时变更、支持把前两位从 01(需购买会员)批量改成 00,但批量变更的规则(谁发起、依据什么、多久一次)没有登记。 为什么缺/线索:出处 10§客群识别与会员资格(规则 L339);操作在 Emma/Cindy 侧,需向其确认。
涉及:P001 营销码L339 规则:营销码前两位批量变更出处:10§客群识别与会员资格
登记原文L339: market code 前两位 01→00 批量变更规则(Emma/Cindy 侧)
○ 待收口
G-120缺口U07 会员与营销

会员权益(返现/立减)怎么生效、由谁承载

缺什么:P052 会员套餐/权益组中,CT BU 支付 5% 返现、Indomaret 立减这两项权益的生效机制和承载系统没有登记;Allo Pay+ 与 Allo Prime 两档在营销权益上的差异也未写明。 为什么缺/线索:出处 10§会员权益、10§待确认;权益差异待 PM 确认。
涉及:P052 会员套餐/权益组出处:10§会员权益·10§待确认
登记原文P052 权益内容: CT BU 支付 5% 返现、Indomaret 立减的生效机制与承载系统;Allo Pay+ 与 Allo Prime 营销权益差异待 PM
○ 待收口
G-121缺口U07 会员与营销

运营位键名全清单和 SMP 活动 id 体系未知

缺什么:P060 运营位组各活动的运营位键(POSITION_KEY)全清单、P058 活动配置组的 SMP 活动 id 编号体系,没有登记。 为什么缺/线索:出处 11§待确认;前端只见部分键名。
涉及:P060 运营位组P058 活动配置组(increase limit)出处:11§待确认
登记原文P060 / P058: 各活动 POSITION_KEY 全清单、SMP 活动 id 体系
○ 待收口
G-122缺口U07 会员与营销

会员套餐价格变动时历史报价如何留痕

缺什么:N056 会员套餐配置的现网四档价格随后台配置可变,但历史报价如何留快照(购买当时的价格记在哪、怎么追溯)这一数据机制没有登记。 为什么缺/线索:出处 10§现网套餐价格;仅知价格可配置。
涉及:N056 会员套餐配置出处:10§现网套餐价格
登记原文N056: 现网四档价格随配置可变,历史报价须留快照(数据机制)
○ 待收口
G-123缺口U07 会员与营销

会员卡可见门控里的「人工审核」指哪一种审核

缺什么:会员卡可见性规则写「特殊用户人工审核通过后」可见,但这里的「人工审核」是指开户阶段的人工审核,还是会员资格的审核,没有说明。 为什么缺/线索:出处 10§会员卡可见性门控;原文表述模糊。
出处:10§会员卡可见性门控
登记原文10§'特殊用户人工审核通过后': '人工审核'指开户人工审核还是会员资格审核,未明
○ 待收口
G-124缺口U08 治理与观测(支撑流程、埋点、后台配置、Risk Workbench)

内部埋点事件没有唯一标识,完整事件字典未整理

缺什么:N041 内部埋点事件记录没有登记唯一标识字段;完整事件字典(label/category/action 全集)也未逐事件枚举。 为什么缺/线索:出处 13-埋点与监控§待确认、R8-埋点事件目录§前言、R10§6;事件字典由 BI 从代码导出维护,IT KB 中没有 PayLater 专属字典。
涉及:N041 内部埋点事件记录出处:功能说明/13-埋点与监控.md§待确认·参考/R8-埋点事件目录.md§前言·参考/R10-后端系统与服务地图.md§6
登记原文N041: 身份标识未载；完整事件字典（label/category/action 全集）未逐事件枚举，由 BI 从代码导出维护，IT KB 无 PayLater 专属字典
○ 待收口
G-125缺口U08 治理与观测(支撑流程、埋点、后台配置、Risk Workbench)

对外上报事件名 38 个只登记了约 33 个

缺什么:P068 对外上报事件名共 38 个,知识库只列出 R7/R8 中点名的约 33 个,其余几个未登记。 为什么缺/线索:出处 R7-通知触达与交易流水§1.1;事件名由后端下发,前端语料中未见全集。
涉及:P068 对外上报事件名出处:参考/R7-通知触达与交易流水.md§1.1
登记原文P068: 38 个 eventName 仅列出 R7/R8 点名的约 33 个，其余未载
○ 待收口
G-126缺口U08 治理与观测(支撑流程、埋点、后台配置、Risk Workbench)

「客户回收」是什么业务动作、模板填什么

缺什么:A-55 执行工单中的「客户回收」这一类,其业务含义没有定义;P066 Workbench 上传模板字段组中客户回收模板(CUSTOMER_RECOVERY)的字段也未说明。 为什么缺/线索:出处 R9-NY-Risk-Workbench 操作手册§二;模板字段以系统模板为准。
涉及:P066 Workbench 上传模板字段组A-55 执行工单出处:参考/R9-NY-Risk-Workbench操作手册.md§二
登记原文P066 / A-55 客户回收: CUSTOMER_RECOVERY 模板字段未说明（以系统模板为准）；「客户回收」业务语义未定义
○ 待收口
G-127缺口U08 治理与观测(支撑流程、埋点、后台配置、Risk Workbench)

Workbench 工单上传后能否撤销、被拒后走向何处

缺什么:A-53 上传 Universal List 文件后能否撤销、怎么撤销;A-54 审核工单被拒绝后的路径和 N072 工单拒绝态的取值;工单号字段名——都没有登记。 为什么缺/线索:出处 R9-NY-Risk-Workbench 操作手册;手册只写了正常的上传→审核→执行路径。
涉及:A-53 上传 Universal List 文件A-54 审核工单N072 工单出处:参考/R9-NY-Risk-Workbench操作手册.md
登记原文A-53 / A-54 / N072: 上传后撤销方式、审核拒绝路径与工单拒绝态取值、工单号字段名均未载
○ 待收口
G-128缺口U08 治理与观测(支撑流程、埋点、后台配置、Risk Workbench)

开通问卷的奖励档算法和选项枚举未知

缺什么:F-43 开通问卷奖励档算法只有名字没有内容,P193 开通问卷奖励档的档位枚举、问卷各题的选项枚举都没有登记。 为什么缺/线索:出处 12-支撑流程§待确认;以 PRD/风控为准。
涉及:F-43 开通问卷奖励档算法P193 开通问卷奖励档出处:功能说明/12-支撑流程(账户安全·引导·结果页).md§待确认
登记原文F-43 / P193: 开通问卷奖励档算法与档位枚举（以 PRD/风控为准）；问卷选项枚举未载
○ 待收口
G-129缺口U08 治理与观测(支撑流程、埋点、后台配置、Risk Workbench)

HomeV2 引导标志的受众是否已放宽到全体 Y001

缺什么:后端下发的 HomeV2 欢迎/导览标志(hv2WelcomeShownFlag/hv2TourShownFlag)的受众范围,是否已放宽为全体 Y001 用户,没有确认。 为什么缺/线索:出处 _待确认清单-风控后端SA-20260813(#4);待后端确认。
涉及:L177 规则:HomeV2 引导标志下发出处:_待确认清单-风控后端SA-20260813.md
登记原文L177: hv2 flag 受众是否已放宽为全体 Y001 待后端确认（待确认清单#4）
○ 待收口
G-130缺口U08 治理与观测(支撑流程、埋点、后台配置、Risk Workbench)

LimitUp 交互引导标志由谁下发、按什么规则

缺什么:P192 LimitUp 交互引导标志(limitUpInteractiveGuidanceFlag)由哪个后端系统写入、按什么规则下发,没有登记。 为什么缺/线索:出处 12-支撑流程§B;前端只读不写。
涉及:P192 LimitUp 交互引导标志出处:功能说明/12-支撑流程(账户安全·引导·结果页).md§B
登记原文P192: limitUpInteractiveGuidanceFlag 的写入方/后端下发规则未载
○ 待收口
G-131缺口U08 治理与观测(支撑流程、埋点、后台配置、Risk Workbench)

后台开关里 settingImage 字段是什么

缺什么:P062 后台开关组中,配置拉取失败时会被重置的 settingImage 字段的业务含义没有登记。 为什么缺/线索:出处 R6-后台开关与配置项§附;仅在重置逻辑里见到该字段。
涉及:P062 后台开关组出处:参考/R6-后台开关与配置项.md§附
登记原文P062 settingImage: 拉取失败时被重置的 settingImage 字段含义未载
○ 待收口
G-132缺口U08 治理与观测(支撑流程、埋点、后台配置、Risk Workbench)

PIN 校验支持的全部场景键名未逐一登记

缺什么:A-49 PIN 校验的参数中,场景映射表(VERIFY_PIN_SCENE_MAP)的全部场景键名没有逐一登记。 为什么缺/线索:出处 12-支撑流程§A;只登记了主要场景。
涉及:A-49 PIN 校验出处:功能说明/12-支撑流程(账户安全·引导·结果页).md§A
登记原文A-49 params: VERIFY_PIN_SCENE_MAP 全部场景键名未逐一载
○ 待收口
G-133缺口U08 治理与观测(支撑流程、埋点、后台配置、Risk Workbench)

PIN 受理结果码的成功码和其他结果码未知

缺什么:P182 PIN 受理结果码(MED 码)中,成功码是什么、以及 B099/B271/B272 之外还有哪些结果码,没有登记。 为什么缺/线索:出处 12-支撑流程§后端事实增补;仅见这三个错误码。
涉及:P182 PIN 受理结果码出处:功能说明/12-支撑流程(账户安全·引导·结果页).md§后端事实增补
登记原文P182: PIN 链路成功码及 B099/B271/B272 以外的结果码未载
○ 待收口
G-134缺口U08 治理与观测(支撑流程、埋点、后台配置、Risk Workbench)

协议同意记录的表结构和场景枚举未整理

缺什么:N033 协议同意记录的落表(t_protocol_consent)结构和字段没有进知识库;用户在哪些场景下需要同意协议的场景枚举也未整理。 为什么缺/线索:出处 R10§4.01;P061 协议同意记录字段组归 U11 处理。
涉及:N033 协议同意P061 协议同意记录字段组出处:参考/R10-后端系统与服务地图.md§4.01
登记原文N033: t_protocol_consent 表结构/字段未入 KB；协议同意场景枚举未整理（P061 归 U11）
○ 待收口
G-135缺口U08 治理与观测(支撑流程、埋点、后台配置、Risk Workbench)

App List 采集因 emoji 应用名每天静默丢 2%

缺什么:N039 App List 采集记录存在数据质量缺口——应用名含 emoji 时会导致整批记录静默丢失,约占每天 2%;App 侧的采集表也没有登记。 为什么缺/线索:出处 13-埋点与监控§后端事实增补。
涉及:N039 App List 采集记录出处:功能说明/13-埋点与监控.md§后端事实增补
登记原文N039: emoji 应用名致 ~2%/天整批静默丢失——数据质量缺口；App 侧采集表未载
○ 待收口
G-136缺口U08 治理与观测(支撑流程、埋点、后台配置、Risk Workbench)

观测类记录算客户事件还是 SDK 上报动作的产物

缺什么:N038 GPS 定位记录、N039 App List 采集记录、N040 CNC 风控上报事件、N041 内部埋点事件记录、N042 对外归因上报事件这五类观测记录,建模上应视为客户事件(不挂产出动作),还是视为 SDK 隐式动作 A-50 上报事件的产物(现按后者登记),没有定论。 为什么缺/线索:出处 handbook-ch5 §5.5#13 与现登记 A-50 口径不同;需审核定夺。
涉及:N038 GPS 定位记录N039 App List 采集记录N040 CNC 风控上报事件N041 内部埋点事件记录N042 对外归因上报事件A-50 上报事件出处:handbook-ch5 §5.5#13 vs 现登记 A-50
登记原文N038~N042 product_of: 观测记录是否按 5.5#13 视为客户事件（去 product_of）还是 SDK 隐式动作产物（现填 A-50），需审核定夺
○ 待收口
G-137缺口U08 治理与观测(支撑流程、埋点、后台配置、Risk Workbench)

上报配置和灰度阈值要不要拆成独立对象

缺什么:N070 功能开关配置(后台配置包)中,开户事件上报配置(amsEventReportConfig OPEN_ACCT)、App List 采集灰度(APP_LIST_COLLECTION)、后台配置中心阈值,是否应各自拆成独立对象,没有定论。 为什么缺/线索:出处 R6-后台开关与配置项、R7§1.1;交审核决定。
涉及:N070 功能开关配置(后台配置包)出处:参考/R6-后台开关与配置项.md·参考/R7-通知触达与交易流水.md§1.1
登记原文N070: 是否将 amsEventReportConfig(OPEN_ACCT)/APP_LIST_COLLECTION 灰度/后台配置中心阈值拆为独立对象，交审核
○ 待收口
G-138缺口U08 治理与观测(支撑流程、埋点、后台配置、Risk Workbench)

结果页族的文案和通用状态机未入库

缺什么:通用结果页族(COMMON_RESULT 等)各页文案没有登记;「处理中→成功→失败/待进一步操作」这一通用状态机也没有建为构件。 为什么缺/线索:出处 12-支撑流程§C、§待确认;文案以 PRD 为准,状态机被视为 UI 而非业务对象。
出处:功能说明/12-支撑流程(账户安全·引导·结果页).md§C·§待确认
登记原文结果页族（COMMON_RESULT 等）: 各结果页文案以 PRD 为准；通用状态机（处理中→成功→失败/待进一步操作）未建为构件（视为 UI，非业务对象）
○ 待收口
G-139缺口U08 治理与观测(支撑流程、埋点、后台配置、Risk Workbench)

质押成功邮件和会员购买通知到底有没有发

缺什么:质押成功后的邮件通知、会员购买后的通知,前端都没有发送动作,是否由后端/营销触达、通过什么渠道,没有登记。 为什么缺/线索:出处 R7-通知触达与交易流水§1.5;待后端/营销确认,归 U09/U10。
出处:参考/R7-通知触达与交易流水.md§1.5
登记原文R7 §1.5 质押成功邮件 / 会员购买通知: 前端未发，待后端/营销确认是否触达（归 U09/U10）
○ 待收口
G-140缺口U09 参考层字典(横切属性与枚举正本)

客群分段码 3-40 位含义、是否真的下发未确认

缺什么:P003 客群分段码第 3-40 位逐位含义没有登记;这个码是否真的存在于接口里也不确定;写入方登记为 A-22 授信裁决落地,但只是根据 R1 描述推断。 为什么缺/线索:出处 R1§三、R3 待确认清单;前端全部代码里都找不到读取该字段(segCode/SEG_CODE)的地方;位含义待 PM 补充,是否存在待后端确认。
涉及:P003 客群分段码A-22 授信裁决落地出处:R1§三·R3 待确认清单
登记原文P003 segCode: 第 3-40 位逐位含义待 PM 补充;前端代码全仓未见 segCode/SEG_CODE 读取,是否真实存在于接口待后端确认;写入方 A-22 为 R1 描述推断
○ 待收口
G-141缺口U09 参考层字典(横切属性与枚举正本)

风险码字典、Risk Flag 值、Y001_R1 规则未知

缺什么:P004 风险码的取值全字典与对应的策略包版本;规则中「Risk Flag=XXXX」的实际值;Y001_R1 标签是否有独立的业务规则——都没有登记。 为什么缺/线索:出处 R1§四、R10§6;IT KB 明确「查不到清单」,Risk Flag 值待 PM 补。
涉及:P004 风险码(风险标签集)出处:R1§四·R10§6
登记原文P004 riskCode: 取值全字典与策略包版本(IT KB『查不到清单』);Risk Flag=XXXX 的实际值;Y001_R1 是否有独立业务规则
○ 待收口
G-142缺口U09 参考层字典(横切属性与枚举正本)

锁定码 U/N 含义、全集、优先级和加速终止触发码

缺什么:P005 冻结/拦截码(锁定码)在用的 11 个码中 U、N(大写)含义未给出;39 码全集及各自语义未登记;锁定码与账单状态等账户状态字段(acctStmtStatus)谁优先没有说明;借据状态置为 T「锁定码加速终止」由哪些码触发也不清楚。 为什么缺/线索:出处 R1§五、R5§⑧;优先级关系 R1 标注待 PM/后端。
涉及:P005 冻结/拦截码(锁定码)出处:R1§五·R5§⑧
登记原文P005 blockCode: 在用 11 码中 U、N(大写)语义未给出;39 码全集与语义;与 acctStmtStatus 等账户状态字段的优先级关系(R1 标待 PM/后端);LOAN_STATUS=T『锁定码加速终止』由哪些码触发
○ 待收口
G-143缺口U09 参考层字典(横切属性与枚举正本)

营销码 8-10 位杠杆额度上限的编码单位待确认

缺什么:P001 营销码第 8-10 位表示杠杆额度上限,其编码单位未确认(按 003=300K、010=1 mio 推断单位为 100K);第 5-7 位质押比例的现网取值分布也未核对。 为什么缺/线索:出处 R1§一、R4§6;单位待 PM 确认,取值分布待以现网/营销配置核对。
涉及:P001 营销码出处:R1§一·R4§6
登记原文P001 marketCode 8-10 位: 杠杆额度 cap 编码单位(003=300K/010=1 mio 推断单位 100K)待 PM 确认;5-7 位现网取值分布待核
○ 待收口
G-144缺口U09 参考层字典(横切属性与枚举正本)

综合账户态 NU/HN/HF/HO 四个值是什么意思

缺什么:P009 综合账户态的 NU/HN/HF/HO 四个取值的业务含义,任何一篇都没有给出。 为什么缺/线索:出处 R3§①、R5§③;现有标注疑为推断。
涉及:P009 综合账户态(派生)出处:R3§①·R5§③
登记原文P009 stmtState: NU/HN/HF/HO 四值语义未在任何篇给出(疑标注为推断)
○ 待收口
G-145缺口U09 参考层字典(横切属性与枚举正本)

开通状态数字变体与 T 码的映射、1006/1008 含义

缺什么:P006 开通/KYC 状态在表单层的数字变体(currentPlaylaterStatus 1017/1022)与 T017/T022 的对应关系只是推断;授信结果码 1006/1008 的语义未知。 为什么缺/线索:出处 R5§①、_待确认清单(问后端第 2 条)。
涉及:P006 开通/KYC 状态出处:R5§①·_待确认清单
登记原文P006 OPEN_STATUS: 表单层数字变体 currentPlaylaterStatus 1017/1022 与 T017/T022 的映射为推断;授信结果码 1006/1008 语义(问后端第 2 条)
○ 待收口
G-146缺口U09 参考层字典(横切属性与枚举正本)

前一账期账单状态字典与出账批量规则未闭合

缺什么:P198 前一账期账单状态(CURR_STMT_STATUS)的后端字典未确认;出账批量的步骤和计息规则也没有闭合。 为什么缺/线索:出处 R5§⑧、R10§4(04)/§6;IT KB 未闭合。
涉及:P198 前一账期账单状态出处:R5§⑧·R10§4(04)/§6
登记原文P198 currentState: CURR_STMT_STATUS 后端字典未确认;出账批量 step 与计息规则 IT KB 未闭合
○ 待收口
G-147缺口U09 参考层字典(横切属性与枚举正本)

钱包状态由谁改写、钱包等级全部码值未知

缺什么:P199 钱包账户状态的锁定/冻结/解锁/销户动作没有建档,写入方未登记;P076 钱包账户等级的中级户码值未见,03=Prime 只是推断,全部取值待后端。 为什么缺/线索:出处 R5§⑧、功能说明/01。
涉及:P199 钱包账户状态P076 钱包账户等级出处:R5§⑧·功能说明/01
登记原文P199 mpcStatus / P076 mpcLevel: 钱包锁定/冻结/解锁/销户动作未建档(writer=null);mpcLevel 中级户码值、03=Prime 为推断,全值待后端
○ 待收口
G-148缺口U09 参考层字典(横切属性与枚举正本)

交易流水由谁写入、子类型全集与收支方向未定

缺什么:P037 交易类型、P038 交易状态、P203 子交易类型这些流水字段的写入动作没有建档(登记表里没有「记流水」动作,写入方未登记);子交易类型(SUB_TRANSACTION_TYPE)全集未知;交易金额的收支方向前端没有定义;会员费交易的商户名待后端确认。 为什么缺/线索:出处 R7-通知触达与交易流水§2.3/2.4;收支方向 R7 标待补。
涉及:P037 交易类型P038 交易状态P203 子交易类型出处:R7§2.3/2.4
登记原文P037/P038/P203 流水字段: 流水记录写入动作未建档(登记表无『记流水』动作,writer=null);SUB_TRANSACTION_TYPE 全集;交易金额收支方向前端无定义(R7 待补);会员交易商户名待后端
○ 待收口
G-149缺口U09 参考层字典(横切属性与枚举正本)

业务场景码的后端全集未给出

缺什么:P204 业务场景码(BIZ_SCENE)前端只见到四个值(借新还旧 JXHJ、月最低还款 MINI_REPAY、在贷重组 MULTI_SETTLE、逾期重组 OVERDUE_RESTRUCTURE),后端全集未知。 为什么缺/线索:出处 R3 待确认清单;待后端给出。
涉及:P204 业务场景码出处:R3 待确认清单
登记原文P204 BIZ_SCENE: 前端仅见 JXHJ/MINI_REPAY/MULTI_SETTLE/OVERDUE_RESTRUCTURE,后端全集待给
○ 待收口
G-150缺口U09 参考层字典(横切属性与枚举正本)

产品码 9022 与 801002 是否同一产品的两套编号

缺什么:P205 产品码的写入方未明(产品配置动作没有建档);取现试算用的 9022(LOAN_CODE)与核心系统 ICPS 的现金贷产品码 801002(PRODUCT_CD)是否是同一产品的两套编号未确认;消费产品号未登记;低价取现页硬编码 9022、常规取现页动态取值,这两条路径在多产品号账户下会怎样表现也不清楚。 为什么缺/线索:出处 R3§⑥、R1§五、_待确认清单;多产品号双路径行为列为挂起技术项。
涉及:P205 产品码出处:R3§⑥·R1§五·_待确认清单
登记原文P205 LOAN_CODE/PRODUCT_CD: 写入方未明(产品配置动作未建档,null);9022(tryLoan LOAN_CODE)与 801002(ICPS PRODUCT_CD 现金贷)是否同一产品两套编号;消费产品号;低价页硬编码 9022 与常规页动态取值双路径在多产品号账户下的行为(挂起技术项)
○ 待收口
G-151缺口U09 参考层字典(横切属性与枚举正本)

还款方式后端字段名到底叫什么(TYPE/METHOD)

缺什么:P207 还款方式的后端字段名不确定——规则 L067 写作 REPAY_TYPE=VA,但这个名字又与前端的还款类型常量(REPAYMENT_TYPES:IOURepay/BillRepay)重名,到底是 REPAY_TYPE 还是 REPAY_METHOD 待核。 为什么缺/线索:出处 R3§⑥、规则登记 L067;两处命名不一致。
涉及:P207 还款方式L067 规则:客户还款仅走钱包代扣出处:R3§⑥·registry L067
登记原文P207 REPAY_METHOD: L067 写作 REPAY_TYPE=VA,与 REPAYMENT_TYPES(IOURepay/BillRepay)重名——后端字段名到底是 REPAY_TYPE 还是 REPAY_METHOD 待核
○ 待收口
G-152缺口U09 参考层字典(横切属性与枚举正本)

取现审批动作码 LR/LA 等四个值含义未知

缺什么:P214 取现审批结果动作码(ACTION_CODE_TYPE)中,LR/LA/LACLNL/LACLNH 四个值的业务含义未知(目前只知道 LRCLNR/LRCLNL 对应额度受限 QUOTA_LIMIT);写入方按首借走 F-07 首账前借款审批引擎、复借走 F-19 借款复借审批二选一登记,但只是推断。 为什么缺/线索:出处 R3§⑥;仅从常量名和部分映射推得。
涉及:P214 取现审批结果动作码F-07 首账前借款审批引擎F-19 借款复借审批出处:R3§⑥
登记原文P214 ACTION_CODE_TYPE: LR/LA/LACLNL/LACLNH 四值语义(仅知 LRCLNR/LRCLNL→QUOTA_LIMIT);写入方首支 F-07/复支 F-19 二选一为推断
○ 待收口
G-153缺口U09 参考层字典(横切属性与枚举正本)

支用提交结果码全集和挑战类型清单码值未知

缺什么:P041 支用提交结果码(风控挑战码)除已知的 0004、1212 之外还有哪些值;P216 取现挑战类型清单(RULE_CODE_LIST_PARTNER)里各成员码值是什么——都没有登记。 为什么缺/线索:出处 R3§⑥、R2§六;前端只处理了两个码。
涉及:P041 支用提交结果码(风控挑战码)P216 取现挑战类型清单出处:R3§⑥·R2§六
登记原文P041/P216 挑战码: 提交结果码全集(0004/1212 之外);RULE_CODE_LIST_PARTNER 成员码值
○ 待收口
G-154缺口U09 参考层字典(横切属性与枚举正本)

质押类型九个取值待 PM 确认,是否与提额记录类型同物

缺什么:P043 质押/提额记录类型(pledgeType)的九个取值,业务含义都是根据常量名推断的,尚未经 PM 确认;它与 P055 提额记录类型是否是同一个东西、要不要合并,也没有定论。 为什么缺/线索:出处 R3§⑥、登记 P055;待 PM 确认,同物则合并。
涉及:P043 质押/提额记录类型P055 提额记录类型出处:R3§⑥·registry P055
登记原文P043 pledgeType: 九个取值的业务含义均据常量名推断,待 PM 确认;是否即『提额记录类型』P055 同物待并
○ 待收口
G-155缺口U09 参考层字典(横切属性与枚举正本)

借据订单/协议状态适用哪些交易、由谁写入

缺什么:P202 借据订单/协议状态(INBS AgreementStatus)适用于哪些交易(取现、借新还旧、账单分期是否都走 INBS 订单)、由哪个动作写入,没有登记;它挂在 N005 借据上只是推断。 为什么缺/线索:出处 R5§⑧、功能说明/05§E.5。
涉及:P202 借据订单/协议状态(INBS)N005 借据(IOU)出处:R5§⑧·功能说明/05§E.5
登记原文P202 AgreementStatus: 适用交易范围(取现/借新还旧/账单分期是否都走 INBS 订单)与写入动作;host 取 N005 为推断
○ 待收口
G-156缺口U09 参考层字典(横切属性与枚举正本)

借据处理标志除「已核销」外还有哪些值

缺什么:P201 借据处理标志(LOAN_PROCESS_FLAG)除 W=已核销之外的其他取值和含义未登记。 为什么缺/线索:出处 R5§⑧;后端观测仅见 W。
涉及:P201 借据处理标志出处:R5§⑧
登记原文P201 LOAN_PROCESS_FLAG: 除 W=已核销外的取值
○ 待收口
G-157缺口U09 参考层字典(横切属性与枚举正本)

账龄码 1-9 各档对应多少天、挂账户还是借据

缺什么:P218 账龄码(AGE_CD)1-9 各档对应的天数区间和单位没有明确(每档≈30 天是反推的);这个字段是账户级还是借据级也未确定。 为什么缺/线索:出处 R1§五。
涉及:P218 账龄码出处:R1§五
登记原文P218 AGE_CD: 1-9 各档天数区间与单位(≈30 天为反推);是否账户级还是借据级
○ 待收口
G-158缺口U09 参考层字典(横切属性与枚举正本)

还款后营销码处理状态除 END 外还有哪些值

缺什么:P209 还款后营销码处理状态(MARKET_CODE_HANDLE_STATUS)除 END 之外的其他取值未登记。 为什么缺/线索:出处规则登记 L069;仅见 END 一值。
涉及:P209 还款后营销码处理状态L069 规则:还款后营销码处理出处:registry L069
登记原文P209 MARKET_CODE_HANDLE_STATUS: END 之外的取值
○ 待收口
G-159缺口U09 参考层字典(横切属性与枚举正本)

各类费率的现网值缺一整张表

缺什么:P036 费率口径常量组的现网值整张表都缺:低价档费率与适用人群、取现/消费月费率与年利率现网档、头息现网档、replan 现网值、额占率价格区间上限、阶梯定价 X、会员月/年费价格与有效期天数、罚息日率(PENALTY_RATE)现网值、重组减免比例、转分期现网费率(生产参数表 DAY_INT_RATE_INSTALLMENT/ADMIN_FEE_RATE)。券叠加规则 PM 已收口(低价×立减可叠加、利率类互斥),但代码里没有统一的叠加器。 为什么缺/线索:出处 R4§6、_待确认清单(问后端 1);这些值多为引擎按账户计算或后台/营销配置,前端不持有,待 PM/后端。
涉及:P036 费率口径常量组出处:R4§6·_待确认清单(问后端 1)
登记原文P036 费率常量组现网值: R4§6 全表:低价档费率与人群、取现/消费月费率与年利率现网档、头息现网档、replan 现网值、额占率价格区间上限、阶梯定价 X、会员月/年费价格与有效期天数、PENALTY_RATE 现网值、重组减免比例、转分期现网费率(DAY_INT_RATE_INSTALLMENT/ADMIN_FEE_RATE 生产参数表);券叠加规则已 PM 收口(低价×立减可叠、利率类互斥)但代码无统一叠加器
○ 待收口
G-160缺口U09 参考层字典(横切属性与枚举正本)

5,000 万与 2,000 万两个额度上限常量是什么关系

缺什么:两个额度上限常量的关系不明:总信用额度天花板(ALLO_MAX_CREDIT_LIMIT=50,000,000)与另一常量(TOTAL_LIMIT_MAX=20M)——后者是产品天花板还是时光轴切档参数? 为什么缺/线索:出处 R3§①、规则登记 L136/L386。
涉及:L386 规则:总额度不超产品天花板L136 规则:时光轴切档比较出处:R3§①·registry L136
登记原文L386 / L136: ALLO_MAX_CREDIT_LIMIT=50,000,000 与 TOTAL_LIMIT_MAX=20M 两常量的关系(天花板 vs 时光轴切档参数?)
○ 待收口
G-161缺口U09 参考层字典(横切属性与枚举正本)

账户总欠款口径是否含未出账部分

缺什么:P223 账户总欠款(ACCOUNT_AMT)与本金/利息/罚息三项的合计口径未明,尤其是否包含未出账部分;写入方是核心记账,但该动作没有建档。 为什么缺/线索:出处 R3 待确认清单;口径待 PM。
涉及:P223 账户总欠款出处:R3 待确认清单
登记原文P223 accountAmt: ACCOUNT_AMT 与本金/利息/罚息三项的合计口径(是否含未出账)待 PM;写入方=核心记账未建档
○ 待收口
G-162缺口U09 参考层字典(横切属性与枚举正本)

账户接口若干字段的写入方与借款计划列表归属未定

缺什么:账户信息接口中,账户利息额(accountIntAmt)、是否展示存款(showDeposit)、邮箱是否需验证(emailVerifyRequired)、取现额度比例(cashLimitRate)几个字段的写入方未登记;现金分期计划列表(loanPlans/LOAN_PLANS)没有单独登记——它疑似是 N002 信贷账户到 N005 借据的链接,而不是 R005 关系下的产品挂载。 为什么缺/线索:出处 R3§①、关系登记 R005;待 U03/U04 核。
涉及:N002 信贷账户N005 借据(IOU)出处:R3§①·registry R005
登记原文R3① 部分字段写入方: accountIntAmt/showDeposit/emailVerifyRequired/cashLimitRate 写入方未明(null);loanPlans(LOAN_PLANS 现金分期计划列表)未单登——疑为 N002→N005 链接而非 R005 的产品挂载,待 U03/U04 核
○ 待收口
G-163缺口U09 参考层字典(横切属性与枚举正本)

灵活码后端字典是否与 PM 位段口径一致

缺什么:P002 灵活码的后端字典(FLEX_CODE)是否与 R1§二 的位段口径一致未核实(五轴已复核,子字段正本由 U05 登记)。 为什么缺/线索:出处 R1§二、R3§①;R3 标注「取值表代码未见,待后端补」。
涉及:P002 灵活码出处:R1§二·R3§①
登记原文P002 flexCode: 五轴已复核;sub_fields 正本由 U05 登;R3 标『取值表代码未见,待后端补』——后端 FLEX_CODE 字典是否与 R1§二 一致待核
○ 待收口
G-164缺口U09 参考层字典(横切属性与枚举正本)

首借/复借引擎切换判据、征信源和质押本金字段待确认

缺什么:N012 决策引擎中,首借专用审批(88200227)与普通审批(88200102)的切换判据存在数据库里,需业务方确认;审批引擎(MIDAPS)的征信源 SLIK/Shopee/Toko 在观测窄窗内未见调用,但不等于停用;风控团队拟提供的质押本金优先字段(pledgeBalanceAmount)尚未上线。 为什么缺/线索:出处 R10§5、R3§③。
涉及:N012 决策引擎/规则包出处:R10§5·R3§③
登记原文N012 决策引擎: 首借专号 88200227 与普通审批 88200102 的切换判据存 DB 需业务方确认;MIDAPS 征信源 SLIK/Shopee/Toko 窄窗未见≠停用;pledgeBalanceAmount 字段(risk team 拟提供)未上线
○ 待收口
G-166缺口finalize

开通问卷奖励档的取值字典未登记

缺什么:P193 开通问卷奖励档的枚举取值字典没有登记。 为什么缺/线索:出处 12-支撑流程§C、§待确认;文档中未见。
涉及:P193 开通问卷奖励档出处:功能说明/12-支撑流程(账户安全·引导·结果页).md§C·§待确认
登记原文P193: 枚举取值字典未载(文档未见)
○ 待收口
G-170缺口finalize

客户的 MPC 用户 ID 与钱包账户的 MPC 账户 ID 是不是同一个字段

缺什么:N001 客户 标识写 MpcID/mpc_uid,N003 钱包账户 标识写 mpcId,字面几乎相同;文档未明确二者是同一字段还是两个字段。 为什么缺/线索:纲要示例明确 mpc_uid=人的标识、acct_no=账户的标识;若钱包账户实际用的也是 mpc_uid,则钱包与客户 1:1 绑定、钱包账户可能没有独立主键——待后端确认字段名。
涉及:N001 客户N003 钱包账户出处:01§D.1·R5§⑧·纲要 2.1
登记原文客户的 MPC 用户 ID 与钱包账户的 MPC 账户 ID 是不是同一个字段
○ 待收口
G-178缺口finalize

取现审批动作码 6 个值里 4 个含义没登记

缺什么:P214 取现审批结果动作码(ACTION_CODE) 取值 LR/LA/LRCLNR/LRCLNL/LACLNL/LACLNH,只有 LRCLNR/LRCLNL(=额度限制 QUOTA_LIMIT)有解释,其余 4 个语义未登记。 为什么缺/线索:前端只按 LRCLNR/LRCLNL 分流失败页,其余码未消费;码由借款审批引擎(F-19)返回,含义在风控侧——按字面疑为 额度有效性(L/ A)×借款策略(R/A)×新额度对比(CLNR/CLNL/CLNH)的组合,待风控确认。
涉及:P214 取现审批结果动作码F-19 借款复借审批出处:03§D.4·R3
登记原文P214 取现审批结果动作码:LR/LA/LACLNL/LACLNH 语义待补
○ 待收口
G-180缺口finalize

自动扣款和代偿产生的还款,要不要和客户主动还款分成两个对象

缺什么:N018 还款交易 定义为客户发起的事件(无 product_of);但自动扣款(A-60,ICPS 批量)和质押代偿(A-65,RMS 调度)也产生还款记录,它们是机构动作的产物(应有 product_of)。现在三者同对象记录,product_of 无法两全。 为什么缺/线索:纲要 5.5#13「客户发起的是事件、机构动作留下的是产物」是两类;同一业务事实(一笔钱冲抵账单)来源不同。待定:①拆「系统还款」事件对象(product_of=A-60·A-65),与 N018 并列;或②N018 加「发起方」属性(客户/自动扣款/代偿)区分。另 A-60 自动扣款是否真落为还款实例亦待后端确认。
涉及:N018 还款交易A-60 自动扣款A-65 执行质押物代偿出处:04§D·05§E.1·纲要 2.1/5.5#13
登记原文系统发起的还款是否拆独立事件对象
○ 待收口
G-182缺口audit-2026-08-20

渠道侧支付缺交易状态/撤销状态属性

缺什么:N016 渠道侧支付 身上只有支付场景标识(P104)与 QRIS 码形态(P105),没有交易状态/撤销状态属性——A-58 撤销 VDC PL 支付对它的状态改写无属性可挂(提交结果码 P041 已补挂,但撤销态不属于提交结果)。 为什么缺/线索:02§VDC 只见撤销结果(成功/失败)返回,未见渠道侧支付自身的状态字段;待后端给出渠道侧支付的状态字段名与取值。
涉及:N016 渠道侧支付A-58 撤销 VDC PL 支付出处:02§VDC·纲要 2.4
登记原文N016 渠道侧支付:缺交易状态/撤销状态属性,A-58 撤销写入无处挂;待后端补字段名
○ 待收口
G-183缺口audit-seg1

授信核准时写营销码/客群码的时点没有出处

缺什么:L210 说核准落地时写初始额度与 marketCode/segCode/riskCode、拒绝时在 marketCode 第 19 位记重授状态,但「什么时点写、由谁写」在知识库里找不到出处。 为什么缺/线索:01§D.4 只写结果码分流,R5§① 只给状态流转,R1§一只定义位段取值不给写入时点;现有依据实为登记表 F-07 的 note。待风控/后端确认写入时点。
涉及:L210 核准落地写码A-22 授信裁决落地P001 营销码P003 客群分段码出处:SEG1 核验 2026-08-27
登记原文授信核准时写营销码/客群码的时点没有出处
○ 待收口
G-184缺口audit-seg1

开户段采集类事件缺记录主键

缺什么:N038 GPS 定位记录 与 N039 App List 采集记录 都是按次追加的真实观测事件,但没有记录主键——数不清、指不准单条。 为什么缺/线索:R8§12.3 只写 amsGpsReportEvents 回传 gpsInfo+bizType+channel;R10§109 写 appListData 落 t_user_app_list_report(单行整串 JSON)。待后端给出两张上报表的行主键字段名。
涉及:N038 GPS 定位记录N039 App List 采集记录A-50 上报事件出处:SEG1 核验 2026-08-27
登记原文开户段采集类事件缺记录主键
○ 待收口
G-185缺口audit-seg1

Video Banking 面签记录缺场次号

缺什么:N075 是由 VB 面签方执行、有四态结果并驱动账户状态的真实业务事件,但没有身份标识——同一申请多次面签无法区分。 为什么缺/线索:01§D.5 分支表与 R5§19 状态机只写结果经 amsAccountSubmitVbResult(VB_NOTIFY) 回传。待 VB/COMMON_VIDEO 侧给出面签场次号。
涉及:N075 Video Banking 面签记录A-52 执行 Video Banking 面签出处:SEG1 核验 2026-08-27
登记原文Video Banking 面签记录缺场次号
○ 待收口
G-186缺口audit-seg1

授信裁决记录与开通问卷提交的主键是推断的

缺什么:N074 授信裁决记录 现用「APP_NO+裁决时间」、N034 开通问卷提交 现用「客户+提交时间」,两者都是推断的复合键,知识库未给真实主键;N034 的问卷题目/答案结构也全未载,名下唯一属性还是算出来的奖励档。 为什么缺/线索:01§D.4 只有一次结果查询接口;12§51/§77 只给路由与「奖励档算法以 PRD/风控为准」。待后端/PM 补。
涉及:N074 授信裁决记录N034 开通问卷提交P193 奖励档出处:SEG1 核验 2026-08-27
登记原文授信裁决记录与开通问卷提交的主键是推断的
○ 待收口
G-187缺口audit-seg1

对外归因上报事件的身份标识不合格

缺什么:N042 现填身份标识「归因 ID = MpcID+MdcID+allo-app」,这是设备/用户级归因标识,同一客户所有上报共用,数不清单条事件;且 MpcID 已是客户(N001)的身份标识,借用违纲要 2.1。 为什么缺/线索:待后端给出单条上报记录的标识(如上报流水号),在此之前身份标识应留空。
涉及:N042 对外归因上报事件N001 客户P190 上报防重标记出处:SEG1 核验 2026-08-27
登记原文对外归因上报事件的身份标识不合格
○ 待收口
G-188缺口audit-seg1

邮箱验证与 OTP 验证动作未建档

缺什么:KYC 能力表里的通用 OTP 验证(COMMON_OTP)与邮箱验证(COMMON_EMAIL_VERIFY)两项能力在登记表里没有动作卡;P237 需邮箱验证 只有下发方(A-01),「客户完成验证后由谁改写这个标记」没有构件承载。 为什么缺/线索:01§B 实名认证/KYC 能力表列了这两项;全表 grep COMMON_OTP 零命中。参照已有的 G-007(钱包动作未建档)。
涉及:P237 需邮箱验证A-01 受理开通申请N013 授信申请出处:SEG1 核验 2026-08-27
登记原文邮箱验证与 OTP 验证动作未建档
○ 待收口
G-189缺口audit-seg1

开通拒绝码只登了 B 系,D/S 两族取值缺失

缺什么:P087 开通拒绝码 的完整码族是 8147+Bxxx/Dxxx/Sxxx,但取值字典只登了 81470000 与 10 个 B 系码,D 系、S 系一个取值都没有。 为什么缺/线索:01§D.2 只给了 B 系后台语义表,D/S 两族仅在括注里提及。待后端补两族取值表。(与 G-003 不同:G-003 问的是产出引擎与命中规则,不覆盖取值缺失)
涉及:P087 开通拒绝码F-21 KYC 预筛决策F-54 开户反欺诈初审出处:SEG1 核验 2026-08-27
登记原文开通拒绝码只登了 B 系,D/S 两族取值缺失
○ 待收口
G-190缺口audit-seg1

渠道标识既是对象身份又登了一条同名属性

缺什么:N010 接入渠道 的身份标识是 app_id,而 P096 渠道标识 的口径就是「调起 SDK 的渠道 app_id」,同一列登了两处。 为什么缺/线索:纲要 2.1 身份标识记在对象上;但 P096 被 7 条规则当 refs 引用(L003/L004/L011/L170/L171/L193/L213),直接退役会造成断头引用。需定:把这些 refs 改指 N010 后退役 P096,还是保留 P096 作为可引用的字段登记。
涉及:P096 渠道标识N010 接入渠道出处:SEG1 核验 2026-08-27
登记原文渠道标识既是对象身份又登了一条同名属性
○ 待收口
G-191缺口audit-seg1

授信申请的双主键与裁决结果码的归属

缺什么:① N013 授信申请 的身份标识并列「APP_NO + 流程实例 flowId」两个主键,flowId 又被 N014 借作身份前缀,应确定谁是主键、flowId 是否降为流程标识属性;② P092 授信申请结果码 挂在客户事件 N013 上但由机构动作 A-22 写入,按观测/干预分离更应挂在裁决记录 N074 上。 为什么缺/线索:两处都影响叙事与图谱,牵动多段,留待人工定。
涉及:N013 授信申请N014 KYC 认证提交N074 授信裁决记录P092 授信申请结果码出处:SEG1 核验 2026-08-27
登记原文授信申请的双主键与裁决结果码的归属
○ 待收口
G-192缺口audit-seg1

账单日期字段登了两处:结构组与单值属性并存

缺什么:P027 账单日期组(结构组,宿主账单)的子字段已含 STMT_DATE 账单日、PMT_DUE_DATE 最后还款日、dueMonth 账期月,而 P239 账单日、P241 本期还款日、P240 账单月份 三条单值属性登的是同一批字段、同宿主同写入方(A-40),属重复登记。 为什么缺/线索:P239/P240/P241 来自 2026-08-19 拆分 P016 日期/系统组(拆分本身对:P016 横跨账户与账单两类宿主),但拆出的账单侧三条与既有的 P027 撞车。需定:退役三条单值并入 P027,还是拆散 P027 保留单值。 同类现象全库还有 20+ 组(额度组 P012 vs P147/P220/P221/P222、账单金额组 P026 vs P028/P029 等),建议随账单段(SEG4)统一定口径。
涉及:P027 账单日期组P239 账单日P240 账单月份P241 本期还款日P012 额度组P026 账单金额组出处:SEG1 核验 2026-08-27
登记原文账单日期字段结构组与单值属性重复登记
○ 待收口
G-193缺口audit-reject

反欺诈防重造成的 1,345 笔「假拒绝」怎么处置

缺什么:反欺诈按交易参考号防重,同键再次进入即硬编码「审批拒绝」且不回放首次结论(L249),超时重试的客户会被误判拒绝,且关联旧账单永不结清。生产存量 1,345 笔 / 1,334 客户。登记表记了机制与误判指纹,但没有任何构件承载这批存量怎么处置——谁来识别、要不要主动补偿或重放、旧账单如何结清、客户侧要不要通知,都没有动作卡。 为什么缺/线索:03§放款链路把它标为「已知生产问题」,未给处置方案。需风控 + 运营给结论:是批量重放补单、人工核销旧账单,还是仅改防重键策略防新增。识别口径已有(误判指纹=审批拒绝 + 申请号为空 + 风控侧查无审批记录)。 [2026-08-27 已出决策材料:桌面《假拒绝存量处置-风控运营.html》与 artifact 7e6abc1c,含识别指纹、四步机制、三方案对比(A 重放补单 / B 人工核销 / C 改防重键防新增)与 5 个待答问题;A 与 B 的分岔点=这批客户当初有没有实际到账,须账务先跑数。]
涉及:L249 反欺诈防重假拒绝F-18 放款反欺诈-取现P126 取现反欺诈决策N005 借据N045 账单出处:SEG2/SEG3 拒绝路径核验 2026-08-27
登记原文反欺诈防重假拒绝存量 1345 笔无处置构件
○ 待收口
G-194缺口audit-reject

风控拒绝(BE002)最终落哪个失败页没登记

缺什么:取现失败类型(P125)只登了三个分流——通用失败页、在途页、额度限制页,而反欺诈拒绝(BE002)属于哪一类没有明写;派生函数 F-59 的输入里虽含结果码,但取值字典没有把 BE002 映射到具体页面。 为什么缺/线索:03§取现失败分流只列了三页,未说明风控拒绝的落点(推测走通用失败页,但知识库无明文)。待前端/PM 确认。
涉及:P125 取现失败类型F-59 取现结果分流派生P126 取现反欺诈决策出处:SEG2/SEG3 拒绝路径核验 2026-08-27
登记原文BE002 风控拒绝落哪个失败页未登记
○ 待收口
G-195缺口audit-seg2

商户订单没有状态属性

缺什么:N077 商户订单 的定义自陈「有订单号与生命周期(待支付→已支付→退款)」,但名下只有订单总额(P100)与商品清单(P101),状态字段与取值一条没有。 为什么缺/线索:02§D.1 入口契约与 D.5 交易详情均未给出订单状态字段名。待收单/商户侧补。(现有 G-024 只覆盖三个单号的对应关系,不含状态)
涉及:N077 商户订单P100 订单总额A-04 受理支付交易出处:SEG2 核验 2026-08-27
登记原文商户订单没有状态属性
○ 待收口
G-196缺口audit-seg2

四个对象的身份标识待补(通知/收单机构/Biller/RIPLAY 合同)

缺什么:本轮核验按纲要 2.1 清空了四个自造或借用的身份标识,均待补真实标识—— · 通知(N068):KB 只登触发时机/渠道/文案键,无触达流水号 · 收单机构(N080):原借用了 GL 内部户科目(P119),那是科目的标识不是机构的 · 账单出票方 Biller(N081):KB 唯一出处是定价引擎入参的场景字符串(大小写不敏感),不能当身份;若后端确认它只有场景字符串、无主档,应改判为属性(宿主 N015,与支付场景标识 P104 并列)后退役本对象 · RIPLAY 合同(N047):原填「合同版本」是模版键,数出来是版本数不是合同份数 为什么缺/线索:四者都是真对象(有生命周期、是业务实体或事件),缺的只是标识。
涉及:N068 通知N080 收单机构N081 账单出票方N047 RIPLAY 合同出处:SEG2 核验 2026-08-27
登记原文四个对象的身份标识待补(通知/收单机构/Biller/RIPLAY 合同)
○ 待收口
G-197缺口audit-seg2

积分账户的账户号字段名仍未拿到

缺什么:G-167 已定结论「积分账户是独立对象,有自己的账户号」,但字段名至今没拿到,身份标识仍写着「字段名待补」。 为什么缺/线索:KB 只见查积分余额接口返回可用余额,未见账户号。待后端补。
涉及:N004 积分账户G-167出处:SEG2 核验 2026-08-27
登记原文积分账户的账户号字段名仍未拿到
○ 待收口
G-198缺口audit-seg2

风控挑战通过后怎么回到原流程没写清

缺什么:下发风控挑战(A-27)的副作用里原写着「客户完成 OTP/刷脸后续查(路径未详)」——挑战通过之后系统怎么接回原来的支付/取现流程、由谁发起续查、失败几次算终止,都没有构件承载。 为什么缺/线索:02§D.3 只写「刷脸成功后续回轮询、失败进失败页」,取现侧 03§D.4 同样一笔带过。待前端/后端补链路。
涉及:A-27 下发风控挑战P109 挑战结果P041 支用提交结果码出处:SEG2 核验 2026-08-27
登记原文风控挑战通过后怎么回到原流程没写清
○ 待收口
G-199缺口audit-seg2

退款的触发条件与可逆性都没有口径

缺什么:退款(A-36)是本段唯一一张前置条件为空的动作卡,而退款不可能无条件——至少要有:原交易已成功入账、退款金额不超过原交易金额(部分退可多次但累计不超)、账期窗口、原交易未被撤销(与 A-58 互斥)。这四条登记表里一条都没有。另外卡面原写「不可逆」而 note 写「可逆性待后端」,自相矛盾,现已改为显式待确认。 为什么缺/线索:04§待确认明写「退款(多还/溢缴)的触发条件与到账路径待后端补」。与 G-058 是同一批问题的不同侧面。
涉及:A-36 退款N053 退款单P121 退款类型G-058出处:SEG2 核验 2026-08-27
登记原文退款的触发条件与可逆性都没有口径
○ 待收口
G-200缺口audit-seg2

两个反欺诈函数的输出落点未见

缺什么:激活反欺诈(F-20)与 KYC 预筛决策(F-21)的产物落到哪个字段没有登记,outputs 此前是空串(纲要 2.5 规定计算型第一阶段的最低义务就是 id+名+outputs),现已改为显式 none 并指向本缺口。 为什么缺/线索:两者的 note 都自陈「输出留白」。待风控给出决策字段名。
涉及:F-20 激活反欺诈F-21 KYC 预筛决策出处:SEG2 核验 2026-08-27
登记原文两个反欺诈函数的输出落点未见
○ 待收口
G-201缺口audit-seg2

通知动作在支付段没有任何触发规则

缺什么:下发通知(A-39)在本段挂 0 条规则,而支付段确实有三种触达(VDC 补足失败的两套 Push、VDC 支付的 RIPLAY 邮件、取现 WhatsApp OTP)——这些触发条件目前都写在别的动作卡的副作用里,没有独立规则挂到 A-39。 为什么缺/线索:A-39 现有的三条前置条件全部来自别的业务段(会员/质押)。属覆盖缺口,不是「本来就没规则」。补登时须与 L036/L038 的既有表述去重。
涉及:A-39 下发通知L036 VDC 未激活自动充值失败L038 PL 部分超限失败P120 VDC 支付失败 Push 模版出处:SEG2 核验 2026-08-27
登记原文通知动作在支付段没有任何触发规则
○ 待收口
G-202缺口audit-seg2

通知的送达状态无属性,却声明要观测送达率

缺什么:下发通知(A-39)的副作用是 none(宣称不留痕),但它的观测指标写着「触达送达率/打开率」「OTP 触达→完成验证转化」——能观测就说明送达状态与触达时间落了库,却一个属性都没建档。 为什么缺/线索:R7 全篇只登触发时机、渠道与文案键,无送达状态字段。待后端补;补齐前这两个指标实际不可度量。
涉及:A-39 下发通知N068 通知G-196出处:SEG2 核验 2026-08-27
登记原文通知的送达状态无属性,却声明要观测送达率
○ 待收口

数据源:PayLater 产品知识库 2026-08-13 版 × 本体知识库说明书 v2 · 2026-08-17 全量重抽(9 单元并行判定+合并校验)· 冲突只登记不判断 · 「缺口」为按纲要三态纪律显式暴露的待补项;冲突登记不改写,结论在「缺口·冲突」页收口