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

知识库

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

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

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

X-001冲突U01 开通与授信

客群分段码是否真的下发到了 SDK

说法一(R1§三)
P003 客群分段码(segCode)共 40 位,由审批引擎在开户后输出并返回给 SDK。
说法二(R3§①、R3§待确认清单)
前端代码全仓检索,没有见到任何读取 segCode/SEG_CODE 的字段。
矛盾客群分段码究竟有没有下发到 SDK、接口里是否真的存在这个字段,两边说法对不上,待后端确认。
涉及:P003 客群分段码出处:R1§三·R3§①
登记原文P003 / R1§三（segCode 40 位，开户后审批引擎输出并返回 SDK）/R3§①·R3§待确认清单（前端代码全仓未见 segCode/SEG_CODE 字段）: 口径矛盾：segCode 是否真的下发到 SDK/接口存在；仅登记不裁决
○ 待收口
X-002冲突U01 开通与授信

哪些开通状态可以进入开户申请落地页

说法一(旧登记 L012)
受理开户申请必须处于开通状态 T211(初始态)。
说法二(01§D.6)
代码查实,T211/T017/T022/T023 四个状态都统一进入申请落地页。
矛盾旧规则只允许 T211,代码实际放行四个状态,范围不同;L012 已按 01 篇改写为四态并记为口径变化,请复核旧登记的来源。
涉及:L012 规则:开户申请受理的状态前提P006 开通/KYC 状态出处:01§D.6·R5§①
登记原文L012 现有登记（受理开户须 OPEN_STATUS=T211 初始态）/01§D.6（T211/T017/T022/T023 统一进申请落地页）: 范围不同：旧规则只允许 T211，代码查实四态均可进入；本文件已按 01 篇改写 L012 并登记为口径变化，请复核旧登记来源
○ 待收口
X-003冲突U01 开通与授信

开户段的反欺诈引擎是一次调用还是两次

说法一(02§引擎矩阵、R2)
激活反欺诈引擎(CFMC)是在授信开户之后调用。
说法二(R10§5)
开户初审走的是 MIDAFS 反欺诈引擎(接口 88100019)。
矛盾开户段反欺诈到底是「开户后激活」还是「开户初审」,时点与身份是否同一个引擎不明,目前分别登记为 F-20 与 F-54 两个函数,待风控确认是否合并。
涉及:F-20 激活反欺诈(CFMC,ICRC-MIDAFS)F-54 开户反欺诈初审(ICRC-MIDAFS 88100019)出处:02§引擎矩阵·R10§5
登记原文02§引擎矩阵/R2（CFMC 激活反欺诈=授信开户后调用）/R10§5（MIDAFS 开户初审走 88100019）: 开户段反欺诈引擎的时点/身份是否同一（开户后激活 vs 开户初审）不明，分别立 F-20 与 F-54，待风控确认是否合并
○ 待收口
X-004冲突U02 支付消费

支付结果是否回传商户、失败后能否重试

说法一(02§关键字段与门槛)
支付成功→进通用结果页并触发外部回调;失败→错误提示,可重试。
说法二(02§D.3/D.4、02§用户旅程)
支付结果不回传商户;失败后不可在页内重试。
矛盾同一篇内对「是否外部回调」和「失败能否重试」表述相反;D 节是逐行查代码得出的,速览段疑为旧口径残留。
涉及:N015 消费支付交易A-04 受理支付交易出处:02§关键字段与门槛 vs 02§D.3
登记原文02§关键字段与门槛（'成功→COMMON_RESULT 页+外部回调；失败→错误提示可重试'）/02§D.3/D.4 与 02§用户旅程（'结果回传商户=无'、'失败不可页内重试'）: 同篇内对'外部回调'与'失败可重试'表述相反；D 节为代码逐行查实，速览段疑为旧口径残留
○ 待收口
X-005冲突U02 支付消费

付款页展示的费率到底是头息率还是月费率

说法一(02§D.2)
付款页每一档展示的是 UPFRONT_ADMIN_FEE 这个字段的百分比,页面上标为 admin fee。
说法二(R4§3 出参对照、02§业务规则速览)
UPFRONT_ADMIN_FEE 对应的是头息(service fee),真正的 admin fee 对应月费率(MONTH_INST_HANDLE_FEE_RATE);速览段又说付款页只展示 admin fee%,service fee 不单独列示。
矛盾如果 D.2 的字段名准确,付款页展示的其实是 service fee 而不是 admin fee,与速览段和 R4 的命名对照相反。
涉及:N015 消费支付交易P036 费率口径常量组出处:02§D.2 vs R4§3·02§业务规则速览
登记原文02§D.2（付款页每档展示 UPFRONT_ADMIN_FEE% 标为 admin fee）/R4§3 出参（UPFRONT_ADMIN_FEE=头息/service fee；admin fee=MONTH_INST_HANDLE_FEE_RATE）+ 02§业务规则速览（付款页仅展示 admin fee%，service fee 不单独列示）: 付款页实际渲染的字段究竟是头息率还是月费率——若 D.2 字段名准确，则付款页展示的是 service fee 而非 admin fee，与速览段及 R4 命名对照矛盾
○ 待收口
X-006冲突U02 支付消费

产品库的「Merchant CPM」是否就是付款码被扫

说法一(02§消费渠道,产品口径)
Merchant CPM = 付款码被扫。
说法二(R10§4、02§后端事实增补)
系统里 CPM 的语义已证实为被扫,但「产品库里的 Merchant CPM 模块名是否就指这个」仍需 PM 确认。
矛盾不是结论相反,而是同一名词在产品模块与系统语义上是否指同一对象尚未闭合,待 PM 一句话确认。
涉及:N079 QRIS 付款码(CPM 被扫)出处:02§后端事实增补
登记原文02§消费渠道 Merchant CPM=付款码被扫（产品口径）/R10§4·02 / 02§后端事实增补（CPM 系统语义已证=被扫，但'产品库 Merchant CPM 模块名是否即指此仍需 PM 确认'）: 同一名词的产品模块与系统语义是否同一对象未闭合，登记待 PM 一句话确认（非结论矛盾，属口径未对齐）
○ 待收口
X-007冲突U03 取现 Instant Cash

每月还款日是固定 10 号,还是按开户年份分两代

说法一(03§RIPLAY 试算字段,《RIPLAY Instant Cash May 2025》)
P129 RIPLAY 披露每月还款日为每月 10 日。
说法二(_待确认清单-风控后端SA-20260813 后端第 5 条)
2025 年前开户的账户 1 号出账、10 号还款;2025 年后开户的 25 号出账、次月 3 号还款;试算的账期(billingCycle)由引擎按账户下发。
矛盾RIPLAY 对客披露固定 10 日,后端实际是两代账期规则(3 号/10 号)并由引擎按账户下发,两者口径不一致。
涉及:P129 RIPLAY 披露内容字段组P133 账期参数组出处:03§RIPLAY 试算字段·_待确认清单-风控后端SA-20260813
登记原文P129 RIPLAY 每月还款日=每月 10 日(《RIPLAY Instant Cash May 2025》)/_待确认清单 后端5条:2025 年前开户 1 号出账·10 号还款,2025 年后开户 25 号出账·次月 3 号还款;试算 billingCycle 由引擎下发: 口径矛盾:RIPLAY 披露固定 10 日,后端为两代账期规则(3 号/10 号)且引擎按账户下发
○ 待收口
X-008冲突U03 取现 Instant Cash

取现头息率现网是 6% 还是 3%

说法一(R4§1、L237)
取现放款时一次性扣除的砍头息为 6%。
说法二(03§用券后 RIPLAY,《RIPLAY 更新优化 0507》)
RIPLAY 展示折后 admin fee 的示例为 upfront fee 3% = Rp30,000。
矛盾头息率 6% 与示例 3% 不一致;示例可能只是举例值但没有标注,需 PM 确认现网头息率。
涉及:L237 规则:取现放款一次性扣砍头息P036 费率口径常量组出处:R4§1·R4§2②·03§用券后 RIPLAY
登记原文L237/R4§1 取现砍头息=6%/03§用券后 RIPLAY 显示折后 admin fee 示例:upfront fee 3%=Rp30,000(《RIPLAY 更新优化 0507》): 头息率 6% vs 示例 3%;示例可能仅为举例值但未标注,需 PM 确认现网头息率
○ 待收口
X-009冲突U03 取现 Instant Cash

低价/特殊取现的最小金额是 500K 还是 2K

说法一(索引 L120,09 篇)
特殊取现页若免息额度小于最小取现金额(500K,后台字段)则该档不可选。
说法二(L053/L057/L047)
低价可用额度小于 Rp2,000 才算「额度已用完」,每档最小金额 = max(档位下限, 2000),500K 只是推荐金额档而不是门槛。
矛盾适用范围有重叠但结论不同——低价/特殊取现的最小金额到底是 500K 还是 2K。
涉及:L120 规则:特殊取现页免息额度门槛L053 规则:低价取现额度用完判定L057 规则:低价档最小金额展示态L047 规则:常规取现统一最低金额N017 取现支用出处:03§最低取现金额门槛·03§取现入口门槛·索引 L120
登记原文L120(索引,09 篇):特殊取现页免息额度<最小取现金额(500K 后台字段)则不可选/L053/L057/L047:低价可用额度<2K 才'额度已用完',档 minLimit=max(档位下限,2000),500K 为推荐金额档非门槛: 范围重叠结论不同:低价/特殊取现最小金额 500K vs 2K
○ 待收口
X-010冲突U03 取现 Instant Cash

支用态可取的枚举值有几个

说法一(R5§⑦)
P010 支用态(cashState)有 5 个取值(W/AC/OPC/REPAY_FIRST_CREDIT/NOT_AVILABLE_CREDIT)。
说法二(R3§①状态类)
cashState 取值「同 ACCOUNT_STATE」,即 9 个取值(W/AC/NAC/RFC/OPC/NU/HN/HF/HO)。
矛盾枚举全集不一致——支用态能否取 NU/HN/HF/HO;两处引用的代码行号也不一致(R5 140-158 vs R3 124-142)。
涉及:P010 支用态(派生)P009 综合账户态(派生)出处:R5§⑦·R3§①
登记原文P010 cashState 取值 R5§⑦(5 值 W/AC/OPC/REPAY_FIRST_CREDIT/NOT_AVILABLE_CREDIT)/R3§①状态类 cashState 取值'同 ACCOUNT_STATE'(9 值 W/AC/NAC/RFC/OPC/NU/HN/HF/HO): 枚举全集不一致(cashState 是否可取 NU/HN/HF/HO);行号亦不一致(R5 140-158 vs R3 124-142)
○ 待收口
X-011冲突U03 取现 Instant Cash

额占率超上限时,主页还展不展示低价引导

说法一(L241,一期口径)
用户持有 DJ 低价权益即展示主页低价引导标记。
说法二(L056,二期口径)
须同时满足持有 DJ 权益且额占率低于第一价格区间上限才展示。
矛盾额占率≥上限时是否展示结论相反;二期是收紧版,但前端是否已承载该判定未查实,现网生效的是哪个版本待确认。
涉及:L241 规则:主页低价权益引导(一期口径)L056 规则:主页低价引导条件(二期收紧)出处:03§主页低价权益引导标记
登记原文L241 一期:持 DJ 权益即展示低价引导/L056 二期:持 DJ ∧ 额占率<第一价格区间上限才展示: 范围重叠结论不同(额占率≥上限时展示与否);二期为收紧版但前端承载与否未查实,现网生效版本待确认
○ 待收口
X-012冲突U03 取现 Instant Cash

取现「四引擎串行」实际单笔只过三道

说法一(03§业务规则速览)
决策引擎为「四引擎串行」。
说法二(03§用户旅程5)
反欺诈→刷脸→首借/复借,虽称四个引擎,但首借与复借二选一,单笔实际只过三个。
矛盾「四引擎」指的是引擎矩阵里的四个实例,单笔取现实际串行三道闸(首借/复借二选一),表述容易被误读。
涉及:N017 取现支用N012 决策引擎/规则包出处:03§用户旅程5·03§业务规则速览
登记原文03§业务规则速览 决策引擎:'四引擎串行'/03§用户旅程5:'反欺诈→刷脸→首借/复借'称四个引擎但按首支/复支二选一实际单笔过三个: 表述口径:'四引擎'指矩阵四个实例,单笔实际串行三闸(首支/复支二选一),易误读
○ 待收口
X-013冲突U04 账单与账期、常规还款

账单到期日每月 10 号,是否只对 2025 年前开户成立

说法一(04§账期规则,PM 2026-08-13)
2025 年后开户的账户,最后还款日为次月 3 号(L251)。
说法二(05§提前还款费率,《RIPLAY PayLater - New 2025-05》)
账单到期日为每月 10 日。
矛盾RIPLAY 对全体用户写每月 10 日,而 PM 两代规则下 2025 年后开户是次月 3 号;RIPLAY 的口径是否只对 2025 年前开户成立待确认。
涉及:L251 规则:2025 年后开户的账期(25 号出账/3 号还款)P133 账期参数组出处:04§账期规则·05§提前还款费率
登记原文L251 / 04§账期规则（PM 2026-08-13：2025 年后开户次月 3 号还款）/05§提前还款费率《RIPLAY PayLater - New 2025-05》：账单到期日为每月 10 日: 范围重叠结论不同：RIPLAY 对全体写每月 10 日，PM 两代规则下 2025 年后开户为次月 3 号；RIPLAY 是否只对 2025 前开户成立待确认
○ 待收口
X-014冲突U04 账单与账期、常规还款

核销门槛是 121 天以上还是 180 天以上

说法一(05§E.6)
核销准入门槛为账龄档 AGE_CD>4,即 121-180 天的账户也可通过。
说法二(05§E.6 引述、催收框架口径)
产品侧惯称「180+ 核销」。
矛盾核销准入门槛 AGE_CD>4 与 DPD≥181 两个口径不一致。
涉及:L269 规则:呆账核销人工上传流程P132 账龄档出处:05§E.6
登记原文L269 / 05§E.6（核销门槛 AGE_CD>4，121-180 天可过）/产品侧惯称'180+核销'（05§E.6 引述、催收框架口径）: 口径矛盾：核销准入门槛 AGE_CD>4 vs DPD≥181
○ 待收口
X-015冲突U04 账单与账期、常规还款

对客所说的「利息」与后端账目并不对应

说法一(05§E.1)
现金贷产品(801002)的利息桶恒为 0,对客所谓「息费」实际由罚息、分期手续费、违约金组成。
说法二(对客话术、前端字段)
字段 minimumRepayInterestFee、LOAN_PAID_OUT_INT_AMT 都称为「利息」。
矛盾对客口径里的「利息」与后端记账桶实际不符,对客话术可能误导用户。
涉及:N005 借据(IOU)N018 还款交易出处:05§E.1·05§关键字段
登记原文05§E.1（现金贷 801002 利息桶恒为 0，'息费'实为罚息+分期手续费+违约金）/对客话术/前端字段 minimumRepayInterestFee、LOAN_PAID_OUT_INT_AMT 称'利息': 口径矛盾：对客'利息'与后端桶实际不符，对客话术会误导
○ 待收口
X-016冲突U04 账单与账期、常规还款

提前还款违约金 8%/10% 的「待统一」标记已过时

说法一(R4§6 待确认表)
提前还款违约金 8% 与 10% 两个值需 PM 统一。
说法二(03§、_待确认清单 PM 15 条,2026-08-13)
PM 已确认两个值的差异是有意为之。
矛盾数值本身不冲突,只是 R4 仍挂着陈旧的「待统一」标记未同步。
涉及:P036 费率口径常量组出处:R4§6·03§·_待确认清单
登记原文R4§6 待确认表（提前还款违约金 8%/10% 需 PM 统一）/03§/_待确认清单 PM 15 条（2026-08-13 确认差异有意为之）: 陈旧待确认标记未同步：值不冲突，但 R4 仍标待统一
○ 待收口
X-017冲突U05 减压与重组(灵活还款四路:月最低还款/账单分期/逾期重组·协商/转分期)

月最低还款本金占比在灵活码的哪几位

说法一(05§E.3,后端公式)
月最低还款本金 = 本金 × 比例,比例取灵活码(FlexCode)第 4-6 位。
说法二(R1§二)
灵活码第 5-6 位为月最低还款本金占比,第 4 位是「按月重置最低还款配置」标志。
矛盾同一个比例的位段编号不一致(4-6 vs 5-6);R1 是 PM 权威口径,E.3 是代码实证,尚未裁决。
涉及:P002 灵活码N019 月最低还款申请出处:05§E.3·R1§二
登记原文05§E.3 后端公式『本金×比例(FlexCode 第 4-6 位)』/R1§二 Flex 第 5-6 位=月最低还款本金占比(第 4 位=reset monthly repayment config): 同一比例的位段编号不一致(4-6 vs 5-6);R1 为 PM 权威、E.3 为代码实证,未裁决
○ 待收口
X-018冲突U05 减压与重组(灵活还款四路:月最低还款/账单分期/逾期重组·协商/转分期)

预付页「剩余总金额」是剩余本金还是本息费合计

说法一(R3§②预付字段表)
预付介绍页的 Remaining total amount 取账户剩余本金(accountInfo.accountPrinAmt / ACCOUNT_PRIN_AMT)。
说法二(05§K-S-2607③、预付门槛节)
该字段已改为 ACCT_SUM_PAID_OUT,即本金+利息+罚息+费用合计。
矛盾R3 仍写修正前口径,与 05 修正后的口径不一致(试算的 AMOUNT 仍用剩余本金,两处一致)。
涉及:N052 预付门槛任务A-62 核销预付门槛出处:R3§②·05§K-S-2607③
登记原文R3§②预付字段表:Remaining total amount=accountInfo.accountPrinAmt(ACCOUNT_PRIN_AMT)/05§K-S-2607③/预付门槛节:PrepayIntro Remaining total amount 已改为 ACCT_SUM_PAID_OUT(本金+利息+罚息+费用): R3 仍写修正前口径,与 05 修正后不一致(试算 AMOUNT 仍用剩余本金两处一致)
○ 待收口
X-019冲突U05 减压与重组(灵活还款四路:月最低还款/账单分期/逾期重组·协商/转分期)

月最低还款新借据的期数由灵活码哪组位段约束

说法一(05§月最低还款 0119)
新借据的期数由灵活码第 13-14/15-16 位判断。
说法二(R1§二)
第 13-16 位是新借据最大/最小期数,第 24-27 位是借新还旧新借据可选最小/最大期数;05 正文又称前端不读这些位,档位由引擎返回。
矛盾「新借据(13-16 位)」与「借新还旧新借据(24-27 位)」两组期数位并存,到底哪组约束月最低还款生成的新借据未写明。
涉及:P002 灵活码N019 月最低还款申请出处:05§月最低还款·R1§二
登记原文05§月最低还款(0119):新借据期数由 Flex 第 13-14/15-16 位判断/R1§二:第 13-16 位=新借据最大/最小期数、第 24-27 位=借新还旧新借据可选最小/最大期数;05 正文称前端不读、档位由引擎返回: 『新借据(13-16)』与『借新还旧新借据(24-27)』两组期数位并存,哪组约束月最低还款新借据未写明
○ 待收口
X-020冲突U05 减压与重组(灵活还款四路:月最低还款/账单分期/逾期重组·协商/转分期)

重组「≥2 笔、≤10 笔」门槛是否只对多借据分支适用

说法一(05§业务规则速览)
重组门槛为借据 ≥2 笔且 ≤10 笔。
说法二(05§D.4)
逾期重组直入分支(OVERDUE_RESTRUCTURE)不选借据,借据列表为空。
矛盾速览段没有限定分支;L093 已写成仅多借据分支(MULTI_SETTLE)适用,速览的表述范围过宽,请审核确认。
涉及:L093 规则:多借据选择分支(MULTI_SETTLE)N021 逾期重组申请A-10 受理逾期重组申请出处:05§业务规则速览·05§D.4
登记原文05§业务规则速览『重组门槛 ≥2 笔、≤10 笔』/05§D.4 OVERDUE_RESTRUCTURE 直入分支 LOAN_LIST=null(不选据): 速览未限定分支;已在 L093 写成仅 MULTI_SETTLE 适用,速览表述范围过宽,请审核确认
○ 待收口
X-021冲突U05 减压与重组(灵活还款四路:月最低还款/账单分期/逾期重组·协商/转分期)

核销准入实际门槛比「180+ 核销」更宽

说法一(05§E.6)
核销准入真实门槛为账龄档 AGE_CD>4,即 AGE_CD=5/6(121-180 天)也能通过。
说法二(产品侧惯称)
「180+ 核销」。
矛盾核销准入口径存在偏差;核销动作本身归其他单元处理,此处只记录口径差异。
涉及:P132 账龄档出处:05§E.6
登记原文05§E.6 核销准入真实门槛 AGE_CD>4(AGE_CD=5/6 即 121-180 天也能过)/产品侧惯称『180+ 核销』: 核销准入口径偏差(本单元仅登记,核销动作归其他单元)
○ 待收口
X-022冲突U06 质押与额度成长(LimitUp 专属)

重新授信入口的准入条件,PRD 与代码不一致

说法一(L122,07§重新风险授信流程 PRD 版)
首页展示重新申请入口需满足未逾期、在押本金≤50K、距授信拒绝日期>30 天等条件。
说法二(L123,07§额度成长来源/R6 代码版)
代码不含在押条件,改为营销码第 14/19 位不在 {1,3} 内,且按「距上次核额日(creditDate)」超过 reapplyCreditIntervalMinDays 判断;R6 里 reapplyCreditDataConfirmDays 也按「上次核额起」而非「拒绝日」计算。
矛盾适用范围重叠但准入条件不同——PRD 有在押本金条件且从拒绝日起算,代码无在押条件且从上次核额日起算。
涉及:L122 规则:重新授信入口条件(PRD 版)L123 规则:重新授信入口条件(代码版)N024 重新授信申请(reapply)P001 营销码出处:07§重新风险授信流程·07§额度成长来源·R6
登记原文L122(07§重新风险授信流程 PRD 版)/L123(07§额度成长来源/R6 代码版): 范围重叠结论不同:PRD 门槛含'在押本金≤50K'与'距授信拒绝日期>30 天',代码版无在押条件、改为 marketCode 第14/19位∉{1,3}且按'距上次核额日 creditDate'>reapplyCreditIntervalMinDays;R6 reapplyCreditDataConfirmDays 亦按'上次核额起'而非'拒绝日'
○ 待收口
X-023冲突U06 质押与额度成长(LimitUp 专属)

质押杠杆率 1.55 倍是含本金还是纯增量

说法一(09§产品定位与额度口径)
常规杠杆率(regularLeverageRatio)是本金的倍数,含本金。
说法二(09§核心能力、07 示例)
质押 Rp100K@1.55x = 新增 Rp155K 额度。
矛盾若 1.55 是含本金倍数,新增额度应为 +55K,示例却是 +155K(不含本金的纯增量);与「新增额度 = min(质押额×总杠杆率, …)」公式如何对应待裁定。
涉及:P017 质押杠杆信息组N025 质押申请L112 规则:定存质押新增额度公式出处:09§核心能力·09§产品定位与额度口径·07§后端事实增补
登记原文09§产品定位与额度口径(regularLeverageRatio=本金的倍数,含本金)/09§核心能力/07 示例(质押 Rp100K@1.55x=+Rp155K 额度): 口径矛盾:若 1.55 为含本金倍数,新增应为 +55K;示例却为 +155K(不含本金的纯增量);与 min 公式的'质押额×总杠杆率'如何对应待裁
○ 待收口
X-024冲突U06 质押与额度成长(LimitUp 专属)

前端兜底会误禁营销码首位为 0 的合法质押比例档

说法一(R1§一,PM 2026-08-13)
营销码第 5-7 位为质押比例,首位为 0 的取值(如 030=30%)是合法值。
说法二(L103,前端兜底)
首位非 1 或全 000 视为无有效杠杆率,禁止质押。
矛盾设计与实现不一致——按 R1 首位 0 的比例档合法,前端按旧字典会误禁;现网只下发首位 1 暂不出错。
涉及:P001 营销码L103 规则:前端质押杠杆率兜底判定出处:R1§一·09§待确认/风险
登记原文R1§一 第5-7位(030=30% 合法值,PM 2026-08-13)/L103 前端兜底(首位非 1/全 000 禁押): 口径矛盾(设计 vs 实现):按 R1 首位 0 的比例档合法,前端兜底按旧字典会误禁;现网仅下发首位 1 暂不致错
○ 待收口
X-025冲突U06 质押与额度成长(LimitUp 专属)

Y001→Y001_R1 升级用的产品调整枚举是哪个

说法一(07§实时提升杠杆率、10§杠杆率实时更新)
更新风险码用的产品调整类型枚举为 801002_09。
说法二(07§示例、R2§三)
触发 Y001→Y001_R1 升级的枚举为 801001_09(10 篇两者并列)。
矛盾同一次升级在不同段落写成两个不同枚举值,是否按产品码分两个枚举待核。
涉及:P004 风险码(风险标签集)A-31 执行调额出处:07§实时提升杠杆率·10§杠杆率实时更新·R2§三
登记原文07§实时提升杠杆率/10§(801002_09 更新 RiskCode)/07§示例·R2§三(801001_09 触发 Y001→Y001_R1): 同一 Y001→Y001_R1 升级在不同段落分别写为 ProductCdAdjTypeList 枚举 801002_09 与 801001_09(10 篇两者并列),是否按产品码分两枚举待核
○ 待收口
X-026冲突U06 质押与额度成长(LimitUp 专属)

定存清单是否只对 Prime 会员开放

说法一(L301,09§后端事实增补,IT KB 实证)
定存清单只对 Prime(Premium)会员可取。
说法二(09§质押流程,PRD)
展示用户持有的符合条件的存单,没有会员前提。
矛盾适用范围重叠但结论不同;且「Prime」指的是钱包档位还是 LimitUp Premium 会员也不明确。
涉及:L301 规则:定存清单仅 Prime 会员可取N006 定存存单N025 质押申请出处:09§后端事实增补·09§质押流程
登记原文L301(09§后端事实增补:定存清单只对 Prime(Premium)会员可取)/09§质押流程(展示用户持有的符合条件存单,无会员条件): 范围重叠结论不同:IT KB 实证称定存清单仅 Prime 会员可取,PRD 流程未设会员前提;且'Prime'指钱包档位还是 LimitUp Premium 未明
○ 待收口
X-027冲突U07 会员与营销

会员还款提额比例是 3% 还是 6%

说法一(10§会员权益表,二期 0609;R1 取值 03)
会员有效期内还款提额比例为 3%。
说法二(10§还款提额率)
现网营销码第 3-4 位为 06,即 6%(数据源 A 亦为 06)。
矛盾PRD 值 3% 与现网 6% 不一致;L147/L149 已各按出处分别登记。
涉及:L147 规则:会籍 ACTIVE 时提额奖励参数L149 规则:还款提额比例读取P001 营销码P052 会员套餐/权益组出处:10§会员权益·10§还款提额率
登记原文10§会员权益 表(二期 0609 还款提额 3%;R1 03=3%)/10§还款提额率(现网 marketCode 3-4 位=06→6%;数据源 A 06): 会员有效期内还款提额比例 PRD 值 3% 与现网 6% 不一致(registry X-2);L147/L149 各按出处登记
○ 待收口
X-028冲突U07 会员与营销

低价权益能否与利率类优惠券叠加

说法一(L060,02§低价权益)
低价权益与利率券可叠加,例如 3%×0.7=2.1%。
说法二(L357,11§券叠加规则,PM 2026-08-13)
低价权益与 Admin Fee 利率类券互斥,只能生效一个。
矛盾适用范围重叠但结论相反;R4§4 仍写「叠加规则待 PM」属于陈旧口径。
涉及:L060 规则:低价权益与利率券叠加L357 规则:低价权益与利率类券互斥N048 营销权益券(EQUITY)出处:02§低价权益·11§券叠加规则·R4§4
登记原文L060 / 02§低价权益(低价权益与利率券可叠加,3%×0.7=2.1%)/L357 / 11§券叠加规则(低价权益×Admin Fee 利率类券互斥,PM 2026-08-13): 范围重叠(低价权益×利率类券)结论相反;R4§4 仍写'叠加规则待 PM'为陈旧口径
○ 待收口
X-029冲突U07 会员与营销

支付立减券列表排序,PRD 与代码不同

说法一(源 PRD《PL coupon 列表展示支付立减劵 0812》)
按发放日期倒序。
说法二(11§、代码)
排序模式为最近到期优先(sortMode=20151002),券商店里按面值降序。
矛盾SMP 券排序口径 PRD 与代码不同;知识库已注明「以代码为准」,此处仅记录差异。
涉及:N049 SMP 支付立减券N029 优惠券使用选择出处:11§优惠券(PL coupon 列表)
登记原文源 PRD《PL coupon 列表展示支付立减劵 0812》按发放日期倒序/11§/代码 sortMode=20151002 最近到期 + store 面值降序: SMP 券排序口径 PRD 与代码不同;KB 已注'以代码为准',仍登记不改写
○ 待收口
X-030冲突U07 会员与营销

营销码 3-4 位示例值 99 与位段口径不符

说法一(《QRIS 支付页展示会员提额比例 1105》)
示例为 06=6%、99=99%。
说法二(R1§一 第 3-4 位)
该位段直读为整数百分比,99 不是合法值。
矛盾PRD 示例值 99 与位段口径不符;知识库以 R1 为准。
涉及:P001 营销码出处:10§还款提额率·R1§一
登记原文《QRIS 支付页展示会员提额比例 1105》'06=6%,99=99%'/R1§一 第 3-4 位(99 非合法值,直读整数): PRD 示例值 99 与位段口径不符;KB 以 R1 为准
○ 待收口
X-031冲突U07 会员与营销

会员费交易的商户名由谁决定

说法一(10§App/页面改造,0515)
钱包交易列表中会员交易的商户名由 Limit up Member 改为 Pay to limit up premium。
说法二(R7§2.3)
前端代码未见专用的会员交易商户名常量,商户名由后端 MERCHANT_NAME 决定。
矛盾PRD 口径与前端代码踪迹不一致(可能是后端下发),待后端确认。
涉及:N037 交易流水(记录)N028 会员购买/续费出处:10§App/页面改造·R7§2.3
登记原文10§App/页面改造(钱包交易列表商户名 Limit up Member→Pay to limit up premium,0515)/R7§2.3(代码未见专用会员交易商户名常量,商户名由后端 MERCHANT_NAME 决定,待后端): PRD 口径与前端代码踪迹不一致(可能后端下发),待后端确认
○ 待收口
X-032冲突U07 会员与营销

PRD 承诺的会员调额补偿机制在系统里没找到入口

说法一(10§购买月会员流程)
接口失败/超时时记录到补偿表,后续手动补偿。
说法二(R10§4-10)
会员购买记录表(t_limit_up_member_record)四种状态分列,DAO 只有插入和主键查询,没有补偿扫描入口。
矛盾PRD 承诺的补偿机制在 IT KB 中未见落地入口;不算直接矛盾,但需人工核实补偿表实体。
涉及:N058 调额补偿记录A-45 会员调额人工补偿P176 会员购买记录字段组出处:10§杠杆率实时更新·R10§4-10
登记原文10§购买月会员流程(接口失败/超时记录到补偿表后续手动补偿)/R10§4-10(t_limit_up_member_record 四状态分列,DAO 只有插入+主键查,无补偿扫描入口): PRD 承诺的补偿机制在 IT KB 未见落地入口;非直接矛盾但需人工核实补偿表实体
○ 待收口
X-033冲突U08 治理与观测(支撑流程、埋点、后台配置、Risk Workbench)

埋点目录里 creditline 分区计数前后不一致

说法一(参考/R8-埋点事件目录 §0 文件总览)
creditline.js 分区数为 36。
说法二(参考/R8-埋点事件目录 §1 表格)
逐行实列 38 个顶层分区。
矛盾同一文件内计数不一致(表格 38 vs 总览 36)。
涉及:N041 内部埋点事件记录出处:参考/R8-埋点事件目录.md
登记原文参考/R8-埋点事件目录.md§0 文件总览 creditline.js 分区数=36/参考/R8-埋点事件目录.md§1 表格实列 38 个顶层分区: 同一文内计数不一致（表格逐行 38 vs 总览 36）
○ 待收口
X-034冲突U08 治理与观测(支撑流程、埋点、后台配置、Risk Workbench)

埋点目录 deposit-liquidity 分区计数不一致

说法一(参考/R8-埋点事件目录 §0)
deposit-liquidity.js 分区数为 14。
说法二(参考/R8-埋点事件目录 §5)
表格 13 行,并注「实含 13 个」。
矛盾计数不一致,14 vs 13。
涉及:N041 内部埋点事件记录出处:参考/R8-埋点事件目录.md
登记原文参考/R8-埋点事件目录.md§0 deposit-liquidity.js 分区数=14/参考/R8-埋点事件目录.md§5 表格 13 行 + 注「实含 13 个」: 计数不一致 14 vs 13
○ 待收口
X-035冲突U08 治理与观测(支撑流程、埋点、后台配置、Risk Workbench)

埋点目录里 allo-pay-upgrade 分区计数不一致

说法一(参考/R8-埋点事件目录 §0)
allo-pay-upgrade.js 分区数为 7。
说法二(参考/R8-埋点事件目录 §6)
表格 6 行,并注「实含 6 个」。
矛盾计数不一致,7 vs 6。
涉及:N041 内部埋点事件记录出处:参考/R8-埋点事件目录.md
登记原文参考/R8-埋点事件目录.md§0 allo-pay-upgrade.js 分区数=7/参考/R8-埋点事件目录.md§6 表格 6 行 + 注「实含 6 个」: 计数不一致 7 vs 6
○ 待收口
X-036冲突U08 治理与观测(支撑流程、埋点、后台配置、Risk Workbench)

开户成功事件上报的分流,由前端还是后端决定

说法一(旧登记 L172)
前端按风险码和额度分支上报——风险码含 Y002 且额度≠0 时上报 PAYLATER_APPROVED+LOAN_ACC_OPENED,Y001 走另一路。
说法二(参考/R7 §1.1/§1.5、功能说明/13 §后端事实增补)
事件名由后端 eventNameList 下发;PAYLATER_APPROVED 与 LIMITUP 不得混报。
矛盾开户上报分流的判定主体不同(前端按风险码/额度分支 vs 后端配置下发);现行正文未见前端分支,旧口径存疑,尚未裁决。
涉及:L172 规则:开户成功事件上报分支N042 对外归因上报事件P068 对外上报事件名P004 风险码(风险标签集)出处:参考/R7-通知触达与交易流水.md·功能说明/13-埋点与监控.md
登记原文旧登记 L172（Y002∧limit≠0→PAYLATER_APPROVED+LOAN_ACC_OPENED；Y001→…）/参考/R7-通知触达与交易流水.md§1.1/§1.5 + 功能说明/13-埋点与监控.md§后端事实增补（事件名由后端 eventNameList 下发；PAYLATER_APPROVED 与 LIMITUP 不得混报）: 开户上报分流的判定主体不同（前端按 riskCode/limit 分支 vs 后端配置下发）；现行正文未见前端分支，旧口径存疑，未裁决
○ 待收口
X-037冲突U08 治理与观测(支撑流程、埋点、后台配置、Risk Workbench)

PIN 态的来源该记为「构造」还是「事实」

说法一(注册表原登记)
P024 PIN 态(密码状态)的来源标为构造。
说法二(功能说明/12 §A、§后端事实增补)
passwordStatus 是后端下发的状态枚举。
矛盾来源轴口径不同;本次已改为「事实」(凭证状态是对世界原样记录),请复核。
涉及:P024 PIN 态(密码状态)出处:功能说明/12-支撑流程(账户安全·引导·结果页).md
登记原文registry P024 origin=构造/功能说明/12-支撑流程(账户安全·引导·结果页).md§A/§后端事实增补 passwordStatus 为后端状态枚举: 来源轴口径：本次改为事实（凭证状态为世界原样记录），请复核
○ 待收口
X-038冲突U09 参考层字典(横切属性与枚举正本)

质押比例位段设计与前端兜底不一致(与 X-024 同题)

说法一(L103,前端兜底)
营销码质押位首位非 1 或全 000 = 无有效杠杆率,禁止质押。
说法二(R1§一 5-7 位 PM 口径、L393)
三位数×0.01,030=30% 为合法值。
矛盾适用范围重叠但结论不同——首位 0 的合法比例档(如 030)会被前端兜底误禁;现网只下发首位 1 暂不出错,R1 已标注「配置首位 0 档位前必须先修前端」。
涉及:P001 营销码L103 规则:前端质押杠杆率兜底判定L393 规则:营销码 5-7 位质押比例读法出处:R1§一·_待确认清单(挂起技术项 09/R1)
登记原文L103(前端兜底:首位非 1/全 000=无有效杠杆率禁质押)/R1§一 5-7 位 PM 口径(×0.01,030=30% 为合法值)/L393: 范围重叠结论不同:首位 0 的合法比例档(如 030)会被前端兜底误禁;现网只下发首位 1 暂不致错,R1 已标『配首位 0 档位前必须先修前端』,登记不裁决
○ 待收口
X-039冲突U09 参考层字典(横切属性与枚举正本)

营销码 3-4 位取值 00 是 0% 还是 2%

说法一(R1§一 第 3-4 位)
取值「00 = 2%(默认)」。
说法二(R3§⑦ getMemberPremiumPercent)
00 或缺失读为 0。
矛盾说法三(L149):非会员/过期一律按 2% 兜底。
涉及:P001 营销码L149 规则:还款提额比例读取出处:R1§一·R3§⑦·registry L149
登记原文R1§一 第 3-4 位取值『00=2%(默认)』/R3§⑦ getMemberPremiumPercent『00/缺失→0』/ L149『非会员/过期一律 2% 兜底』: 口径矛盾:00 读为 0% 还是 2%——疑 R1 把非会员兜底 2% 写进了位段取值;需 PM 明确 00 的位段含义
○ 待收口
X-040冲突U09 参考层字典(横切属性与枚举正本)

R1 引用纪律把营销码与灵活码的 3-4 位写混了

说法一(R1 引用纪律第 6 条)
灵活码第 3-4 位为直读整数百分比(非枚举映射)。
说法二(R1§一/§二)
营销码第 3-4 位才是直读比例;灵活码第 3-4 位是月最低可用性/重置标志(布尔位)。
矛盾属文内笔误——直读百分比是营销码 3-4 位,灵活码 3-4 位是布尔位;引用者易错。
涉及:P001 营销码P002 灵活码出处:R1 引用纪律·R1§一§二
登记原文R1 引用纪律第 6 条『Flex 第 3-4 位为直读整数百分比(非枚举映射)』/R1§一/§二(Market 3-4 位=直读比例;Flex 3-4 位=月最低可用性/重置标志): 文内笔误:直读百分比是 Market code 3-4 位,Flex 3-4 位是布尔位;引用者易错
○ 待收口
X-041冲突U09 参考层字典(横切属性与枚举正本)

营销码 5-7 位叫「杠杆率」还是「质押比例」

说法一(R2§二 营销码行)
第 5-7 位为质押杠杆率。
说法二(R1§一,2026-08-13)
第 5-7 位为定存质押比例(×0.01)。
矛盾术语未同步——R2 仍称「杠杆率」,R1 已改为「质押比例」;建议 R2 回改。
涉及:P001 营销码出处:R2§二·R1§一
登记原文R2§二 marketCode 行『质押杠杆率(5-7)』/R1§一 5-7 位『定存质押比例×0.01』(2026-08-13): 术语未同步:R2 仍称『杠杆率』,R1 已改『质押比例』;建议 R2 回改
○ 待收口
X-042冲突U09 参考层字典(横切属性与枚举正本)

质押提额的计算口径,PRD 版与实现版是否等价

说法一(L112,PRD 版)
质押提额 = 本金 × 杠杆率(代码倍数口径),或按比例 0-100%+最大值,或按存单金额区间给固定金额(二选一)。
说法二(R1§一、R10§4,07/09 篇实现事实版)
新增额度 = min(质押额×总杠杆率, 质押额+剩余杠杆额度)。
矛盾同一计算口径有两种表述,是否等价需 PM/后端确认。
涉及:L112 规则:定存质押新增额度公式N025 质押申请P017 质押杠杆信息组出处:registry L112·R1§一·R10§4
登记原文L112 质押提额=本金×杠杆率(代码倍数口径)/比例 0-100%+最大值 或 按存单金额区间固定金额(二选一)/R1§一/R10§4(07/09) 额度公式 新增额度=min(质押额×总杠杆率, 质押额+剩余杠杆额度): 同一计算口径两种表述(PRD 版 vs 实现事实版),是否等价需 PM/后端确认;登记不改写
○ 待收口
X-043冲突U09 参考层字典(横切属性与枚举正本)

账单逾期判定「每月 10 日」只对 2025 年前开户成立

说法一(L063)
账单到期(每月 10 日)未还清 → 状态由 N 转 O(逾期)。
说法二(_待确认清单-风控后端SA-20260813 后端 5 条)
账期分两代——2025 年后开户 25 号出账、次月 3 号还款,宽限期 10 天。
矛盾「每月 10 日」只对 2025 年前开户成立;L063 需按开户代际写全适用范围。
涉及:L063 规则:账单最后还款日与逾期转态N045 账单P133 账期参数组出处:registry L063·_待确认清单-风控后端SA-20260813
登记原文L063『到期(每月 10 日)未还清→N→O』/_待确认清单 后端 5 条:账期两代规则(2025 年后开户=25 号出账·次月 3 号还款;宽限期 10 天): 口径矛盾:『每月 10 日』仅对 2025 年前开户成立;L063 需按开户代际写全适用范围(U04 处理)
○ 待收口
X-044冲突U09 参考层字典(横切属性与枚举正本)

前一账期状态是否存在 O(逾期)值

说法一(R5§⑧)
账单状态 CURR_STMT_STATUS 后端只观测到 U/N/F 三个值。
说法二(R3§①)
前端 currentState 取值为 U/N/F/O。
矛盾取值集不同——O 是否存在于前一账期状态;后端字典未确认。
涉及:P198 前一账期账单状态出处:R5§⑧·R3§①
登记原文R5§⑧ CURR_STMT_STATUS 后端仅观测到 U/N/F/R3§① currentState 取值 U/N/F/O: 取值集差异(O 是否存在于前一账期状态);后端字典未确认
○ 待收口
X-045冲突U09 参考层字典(横切属性与枚举正本)

质押划转状态,前端与后端值集对不上

说法一(R3§⑥)
P057 质押划转状态(TRANSFER_STATUS)前端值集含 REVERSE_SUCC/SEND_SUCC/APPLY_SUCC/WAIT_CONDITION 等在途细分。
说法二(R5§⑧)
生产表 tm_trans_info 的状态集只有 TRAN_SUCC/TRAN_FAIL/CANCEL/TRAN_INIT。
矛盾前端定义的在途细分与 REVERSE_SUCC 在生产未见,后端的 CANCEL 前端未定义;哪一侧是正本待确认。
涉及:P057 质押划转状态N025 质押申请出处:R3§⑥·R5§⑧
登记原文P057 前端 TRANSFER_STATUS 值集(含 REVERSE_SUCC/SEND_SUCC/APPLY_SUCC/WAIT_CONDITION)/R5§⑧ tm_trans_info 生产状态集仅 TRAN_SUCC/TRAN_FAIL/CANCEL/TRAN_INIT: 前后端值集不一致:前端定义的在途细分与 REVERSE_SUCC 生产未见,后端 CANCEL 前端未定义;哪一侧为正本待确认
○ 待收口
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: 枚举取值字典未载(文档未见)
○ 待收口
IF-01接口候选U01 开通与授信

开户段四类受理动作可归并为「可受理」接口

建议:把授信申请(N013)、KYC 认证提交(N014)、推荐码提交(N031)三类申请事件的受理动作——受理开通申请(A-01)、受理 KYC 步骤提交(A-02)、受理推荐码提交(A-20)、受理授信提交并送审(A-56)——归并为一个「可受理」接口。 理由:这几个受理动作形状相同(都是提交时间+受理结论),且三类以上申请事件共用,分别登记等于同一规则抄多遍(出处 01§D.1、D.2、D.5)。
涉及:N013 授信申请(开户)N014 KYC 认证提交N031 推荐码提交A-01 受理开通申请A-02 受理 KYC 步骤提交A-20 受理推荐码提交A-56 受理授信提交并送审出处:01§D.1·01§D.2·01§D.5
登记原文此处或可归并接口「可受理」：受理开通申请 A-01 / 受理 KYC 步骤 A-02 / 受理推荐码 A-20 / 受理授信提交 A-56 形状相同（提交时间+受理结论），三类以上申请事件共用 候选:N013·N014·N031
○ 待收口
IF-02接口候选U01 开通与授信

KYC 子步若都要上报,可考虑「可上报」接口

建议:KYC 三个子步骤(OCR/人脸/问答)已参数化并入受理 KYC 步骤提交(A-02);如果后续各子步骤的规则要再抄一遍(例如都要做 CNC 上报、GPS 采集),可考虑把 KYC 认证提交(N014)、GPS 定位记录(N038)、CNC 风控上报事件(N040)归并为「可上报」接口。 理由:预防性建议(出处 01§D.7)——目前不重复,但一旦子步规则要复制第二遍就值得抽接口。
涉及:N014 KYC 认证提交N038 GPS 定位记录N040 CNC 风控上报事件A-02 受理 KYC 步骤提交出处:01§D.7
登记原文KYC 三子步（OCR/人脸/问答）已参数化并入 A-02，若后续各子步规则要抄第二遍（如均需 CNC 上报/GPS），可考虑「可上报」接口 候选:N014·N038·N040
○ 待收口
IF-03接口候选U02 支付消费

三类支用事件共用同一套准入闸门,可归并为「可支用」

建议:把消费支付交易(N015)、渠道侧支付(N016)、取现支用(N017)归并为一个「可支用」接口。 理由:三者共用邮箱未验证拦截(L015)、五级准入检查(L016)、PIN 必验(L017)、引擎串行过闸(L021/L022)以及下发风控挑战(A-27),同一句规则已在受理支付交易(A-04)与受理取现申请(A-05)各写一遍(出处 02§支用决策引擎矩阵、02§关键字段与门槛)。
涉及:N015 消费支付交易N016 渠道侧支付N017 取现支用A-04 受理支付交易A-05 受理取现申请A-27 下发风控挑战L015 规则:邮箱未验证拦截支用L016 规则:支用五级准入检查L017 规则:提交前必验 PIN出处:02§支用决策引擎矩阵·02§关键字段与门槛
登记原文此处或可归并接口「可支用」：消费支付 N015 / 渠道侧支付 N016 / 取现 N017 共用邮箱验证拦截 L015、五级准入 L016、PIN 必验 L017、引擎串行过闸（L021/L022）与挑战下发 A-27——同句已在 A-04 与 A-05 各写一遍 候选:N015·N016·N017
○ 待收口
IF-04接口候选U02 支付消费

凡需试算的场景共用定价引擎规则,可归并为「可试算」

建议:把消费支付(N015)、取现(N017)、月最低还款(N019)、账单分期(N020)、逾期重组(N021)、转分期(N022)以及 VDC 激活弹窗归并为一个「可试算」接口。 理由:这些场景共享「凡向用户展示试算结果必调定价引擎」(L192)与「试算档默认选中」(L052)两条规则(出处 R4§3)。
涉及:N015 消费支付交易N017 取现支用N019 月最低还款申请N020 账单分期申请N021 逾期重组申请N022 转分期(展期)申请L192 规则:展示试算结果必调定价引擎L052 规则:试算档默认选中出处:R4§3
登记原文此处或可归并接口「可试算」：消费支付/取现/最低还款/账单分期/转分期/逾期重组/VDC 激活弹窗共享 L192（必调定价引擎）与 L052（默认选中） 候选:N015·N017·N019·N020·N021·N022
○ 待收口
IF-05接口候选U03 取现 Instant Cash

取现/支付/还款受理共用三道门,可归并为「可受理」

建议:把取现支用(N017)、消费支付交易(N015)、还款交易(N018)的受理动作(A-04/A-05/A-06)归并为「可受理」接口。 理由:三者共享邮箱门(L015)、五级检查(L016)、PIN 门(L017),同一句规则要抄多遍(出处 03§D.1、索引 L015/L016/L017)。
涉及:N017 取现支用N015 消费支付交易N018 还款交易A-04 受理支付交易A-05 受理取现申请A-06 受理还款L015 规则:邮箱未验证拦截支用L016 规则:支用五级准入检查L017 规则:提交前必验 PIN出处:03§D.1·索引 L015/L016/L017
登记原文此处或可归并接口'可受理':取现/支付/还款受理动作 A-04/A-05/A-06 共享邮箱门(L015)、五级检查(L016)、PIN 门(L017)同一句要抄多遍 候选:N017·N015·N018
○ 待收口
IF-06接口候选U03 取现 Instant Cash

产生新借据的申请共用签约门,可归并「可签约」

建议:把取现支用(N017)、月最低还款(N019)、账单分期(N020)、逾期重组(N021)、转分期(N022)这类会产生新借据的申请归并为「新借据类/可签约」接口。 理由:「勾选已阅读同意 RIPLAY 且合同加载完成」这道提交门(L049)在受理取现(A-05)、受理账单分期(A-09)、受理逾期重组(A-10)、受理转分期(A-11)里抄了四遍(出处 03§D.4、索引 L049)。
涉及:N017 取现支用N019 月最低还款申请N020 账单分期申请N021 逾期重组申请N022 转分期(展期)申请L049 规则:RIPLAY 勾选与合同加载门A-05 受理取现申请A-09 受理账单分期申请A-10 受理逾期重组申请A-11 受理转分期(展期)申请出处:03§D.4·索引 L049
登记原文此处或可归并接口'新借据类/可签约':RIPLAY 勾选∧加载完成门(L049)在 A-05/A-09/A-10/A-11 抄四遍 候选:N017·N019·N020·N021·N022
○ 待收口
IF-07接口候选U04 账单与账期、常规还款

会落交易流水的事件可归并为「可入流水」接口

建议:把消费支付(N015)、渠道侧支付(N016)、取现(N017)、还款(N018)、退款单(N053)、转分期申请(N022)以及质押代偿归并为「可入流水」接口,统一落入交易流水(N037)。 理由:它们都以交易类型(TRANSACTION_TYPE)一行落入流水,且同一条 180 天/分页规则、同一详情分发规则要写多遍(出处 R7§2.1-2.2)。
涉及:N015 消费支付交易N016 渠道侧支付N017 取现支用N018 还款交易N053 退款单N022 转分期(展期)申请N037 交易流水(记录)出处:R7§2.1-2.2
登记原文此处或可归并接口「可入流水」：支付 N015 / 渠道侧支付 N016 / 取现 N017 / 还款 N018 / 退款 N053 / 展期申请 N022 / 质押代偿 都以 TRANSACTION_TYPE 行落入 N037，且同一条 180 天/分页规则、同一详情分发规则要写多遍 候选:N015·N016·N017·N018·N053·N022·N037
○ 待收口
IF-08接口候选U04 账单与账期、常规还款

借据与账单共享「足额到账即结清」规则,可归入「可核销」

建议:借据(N005)是核销/结清对象;账单(N045)与借据共享「足额到账→F/结清」这条同形规则(L074、L270),可一并归入手册已有的「可核销」接口。 理由:两者结清判定形状相同,分别写会重复(出处 R5§③、R5§⑧)。
涉及:N005 借据(IOU)N045 账单L074 规则:账单足额到账结清L270 规则:借据结清与可用额度推导出处:R5§③·R5§⑧
登记原文「可核销」（手册已知接口）：借据 N005 为核销/结清对象；账单 N045 与借据 N005 共享'足额到账→F/结清'同形规则（L074 / L270） 候选:N005·N045
○ 待收口
IF-09接口候选U05 减压与重组(灵活还款四路:月最低还款/账单分期/逾期重组·协商/转分期)

五类还款侧申请事件同形,可归并为「可受理」

建议:把月最低还款(N019)、账单分期(N020)、逾期重组(N021)、转分期(N022)、协商方案确认(N023)五类申请事件归并为「可受理」接口。 理由:五者形状相同(提交→受理结论三态/四态、验 PIN、RIPLAY 合同随单),RIPLAY 勾选门(L049)已对 A-05/A-09/A-10/A-11 重复抄写(出处 05§D.1、05§D.3、06§D)。
涉及:N019 月最低还款申请N020 账单分期申请N021 逾期重组申请N022 转分期(展期)申请N023 协商方案确认L049 规则:RIPLAY 勾选与合同加载门出处:05§D.1·05§D.3·06§D
登记原文此处或可归并接口『可受理』:N019/N020/N021/N022/N023 五类申请事件同形(提交→受理结论三态/四态、PIN、RIPLAY 合同随单),L049(RIPLAY 勾选)已对 A-05·A-09·A-10·A-11 抄写 候选:N019·N020·N021·N022·N023
○ 待收口
IF-10接口候选U05 减压与重组(灵活还款四路:月最低还款/账单分期/逾期重组·协商/转分期)

三个借新还旧类功能是一个能力,可归并为「可借新还旧」

建议:把月最低还款(N019)、账单分期(N020)、逾期重组(N021)归并为「可借新还旧」接口。 理由:三者共用同一 INBS 工单(i200029)与四态流程状态(FLOW_STATUS),受理闸门(L272~L275)对三者同写;PM 口径为「三个功能、一个能力」(出处 05§E.4)。
涉及:N019 月最低还款申请N020 账单分期申请N021 逾期重组申请L272 规则:借新还旧闸门①无在途工单L273 规则:借新还旧闸门②灵活码首位L275 规则:借新还旧闸门④逐借据期数资格出处:05§E.4
登记原文此处或可归并接口『可借新还旧』:N019/N020/N021 三申请共用 INBS i200029 工单与 FLOW_STATUS 四态,受理闸门 L272~5 对三者同写(PM 口径『三个功能、一个能力』) 候选:N019·N020·N021
○ 待收口
IF-11接口候选U06 质押与额度成长(LimitUp 专属)

质押/解押/支取/重新授信/补料可归并「可受理」

建议:把重新授信申请(N024)、质押申请(N025)、解押申请(N026)、存单提前支取(N027)、补充资料上传(N032)归并为「可受理」接口。 理由:它们同为客户申请事件、同走受理三态,受理类规则(验 PIN、开关、在途检查)已在多处重复(出处 09§质押流程、07§重新风险授信流程)。
涉及:N024 重新授信申请(reapply)N025 质押申请N026 解押申请N027 存单提前支取N032 补充资料上传出处:09§质押流程·07§重新风险授信流程
登记原文此处或可归并接口:可受理——质押申请/解押申请/存单提前支取/重新授信申请/补充资料上传同为客户申请事件、同走受理三态,受理类规则(验 PIN、开关、在途)已在多处重复 候选:N024·N025·N026·N027·N032
○ 待收口
IF-12接口候选U06 质押与额度成长(LimitUp 专属)

三类可质押资产共用杠杆门控,可归并为「可质押」

建议:把定存存单(N006)、钱包现金(代建 TD,N003)、积分账户(N004)三类资产归并为「可质押」接口。 理由:三者共用杠杆率门控与释放调度规则(出处 09§核心能力、09§后端事实增补)。
涉及:N006 定存存单N003 Allo Wallet 钱包账户N004 积分账户出处:09§核心能力·09§后端事实增补
登记原文此处或可归并接口:可质押——定存存单/钱包现金(代建 TD)/积分三类资产共用杠杆率门控与释放调度 候选:N006·N003·N004
○ 待收口
IF-13接口候选U07 会员与营销

权益券与支付立减券共享同一状态机,可归并为券族接口

建议:把营销权益券(N048)与 SMP 支付立减券(N049)归并为「可发放/可核销券族」接口。 理由:两者共享「发放→可用→使用/作废/过期」状态机,以及发放/作废权益券(A-37)、角标计数、锁定码展示门等同一句规则(出处 11§优惠券、R3§④)。
涉及:N048 营销权益券(EQUITY)N049 SMP 支付立减券A-37 发放/作废权益券出处:11§优惠券·R3§④
登记原文此处或可归并接口:可发放/可核销券族——N048 权益券与 N049 SMP 券共享'发放→可用→使用/作废/过期'状态机与 A-37 发放/作废、角标计数、blockCode 展示门等同句规则 候选:N048·N049
○ 待收口
IF-14接口候选U07 会员与营销

会员购买/留资/推荐码提交同为申请事件,可并入「可受理」

建议:把会员购买/续费(N028)、留资提交(N030)、推荐码提交(N031)并入 IF-01 的「可受理」接口。 理由:三者均为客户申请类事件,受理动作同形(出处 10§购买月会员流程、11§留资、11§MGM)。
涉及:N028 会员购买/续费N030 留资提交N031 推荐码提交出处:10§购买月会员流程·11§留资·11§MGM
登记原文此处或可归并接口:可受理(IF01)——N028 会员购买、N030 留资提交、N031 推荐码提交均为客户申请类事件,受理动作同形 候选:N028·N030·N031
○ 待收口
IF-15接口候选U07 会员与营销

各类营销物件同由一个配置动作产出,可归并「可配置营销物」

建议:把营销活动(N061)、权益 Benefit(N062)、SMP 支付立减券规则配置(N085)、App 内营销落地页配置(N064)、留资 H5 落地页配置(N065)、运营位(N066)、会员套餐配置(N056)归并为「可配置营销物」接口。 理由:它们都由同一个参数化的配置动作——配置营销活动与权益(A-46)——产出(出处 11§SMP 活动配置、09§营销系统配置)。
涉及:N061 营销活动N062 权益 BenefitN085 SMP 支付立减券规则配置N064 App 内营销落地页配置N065 留资 H5 落地页配置N066 运营位N056 会员套餐配置A-46 配置营销活动与权益出处:11§SMP 活动配置·09§营销系统配置
登记原文此处或可归并接口:可配置营销物——N061/N062/N085/N064/N065/N066/N056 均由 A-46 参数化配置 候选:N061·N062·N085·N064·N065·N066·N056
○ 待收口
IF-16接口候选U08 治理与观测(支撑流程、埋点、后台配置、Risk Workbench)

八类受理动作前都要验 PIN,可归并为「可验密」接口

建议:把消费支付(N015)、取现(N017)、还款(N018)、转分期(N022)、质押(N025)、解押(N026)、会员购买(N028)、重新授信(N024)归并为「可验密(PIN-gated)」接口。 理由:「提交前必验 PIN」(L017)这同一句规则挂在 8 类受理动作前面,目前是挂在 PIN 校验(A-49)上作为族级门(出处 功能说明/12 §A)。
涉及:N015 消费支付交易N017 取现支用N018 还款交易N022 转分期(展期)申请N025 质押申请N026 解押申请N028 会员购买/续费N024 重新授信申请(reapply)A-49 PIN 校验L017 规则:提交前必验 PIN出处:功能说明/12-支撑流程(账户安全·引导·结果页).md§A
登记原文此处或可归并接口「可验密（PIN-gated）」：L017 同一句规则挂在 8 类受理动作（支付/取现/还款/转分期/质押/解押/购会员/reapply）前，现挂 A-49 作族级门 候选:N015·N017·N018·N022·N025·N026·N028·N024
○ 待收口
IF-17接口候选U08 治理与观测(支撑流程、埋点、后台配置、Risk Workbench)

五类观测记录共用同一上报动作,可归并为「可上报」

建议:把 GPS 定位记录(N038)、App List 采集记录(N039)、CNC 风控上报事件(N040)、内部埋点事件记录(N041)、对外归因上报事件(N042)归并为「可上报」接口。 理由:五者共享同一个参数化上报动作(A-50)以及只追加/防重的口径(出处 功能说明/13 §对外/风控上报、参考/R8 §12)。
涉及:N038 GPS 定位记录N039 App List 采集记录N040 CNC 风控上报事件N041 内部埋点事件记录N042 对外归因上报事件A-50 上报事件出处:功能说明/13-埋点与监控.md§对外/风控上报·参考/R8-埋点事件目录.md§12
登记原文此处或可归并接口「可上报」：N038~N042 五类观测记录共享同一参数化上报动作 A-50 与只追加/防重口径 候选:N038·N039·N040·N041·N042
○ 待收口
IF-18接口候选U08 治理与观测(支撑流程、埋点、后台配置、Risk Workbench)

各类「只弹一次」的引导弹窗可归并为「可一次性展示」

建议:把 welcome、tour、引导、问卷、挽留弹窗等归并为「可一次性展示」接口,统一用 UI 展示记录(N043)承载。 理由:它们共享「只弹一次」的三层记录形状(出处 功能说明/12 §B)。
涉及:N043 UI 展示记录出处:功能说明/12-支撑流程(账户安全·引导·结果页).md§B
登记原文此处或可归并接口「可一次性展示」：welcome/tour/引导/问卷/挽留弹窗共享「只弹一次」三层记录形状（N043） 候选:N043
○ 待收口
IF-19接口候选U09 参考层字典(横切属性与枚举正本)

支用/还款类事件的状态枚举同形,可归并为「可受理」

建议:把消费支付(N015)、取现(N017)、还款(N018)、月最低还款(N019)、账单分期(N020)、逾期重组(N021)、转分期(N022)归并为「可受理」接口。 理由:各自的状态枚举(SPENDING_STATUS/CASH_LOAN_STATUS/REPAY_STATUS/extensionStatus/jxhjOrderStatus)共用 P/S/C(+F)三四态形状,且「同步受理≠终态」(L385)这条规则要对整族生效(出处 R3§⑥、R5§④⑧、R7§2.3)。
涉及:N015 消费支付交易N017 取现支用N018 还款交易N019 月最低还款申请N020 账单分期申请N021 逾期重组申请N022 转分期(展期)申请L385 规则:跨系统同步受理+异步回执出处:R3§⑥·R5§④⑧·R7§2.3
登记原文此处或可归并接口『可受理』:N015/N017/N018/N019/N020/N021/N022 各自的状态枚举(SPENDING_STATUS/CASH_LOAN_STATUS/REPAY_STATUS/extensionStatus/jxhjOrderStatus)共用 P/S/C(+F)三四态形状,且『同步受理≠终态』(L385)要对全族生效。 候选:N015·N017·N018·N019·N020·N021·N022
○ 待收口
IF-20接口候选U09 参考层字典(横切属性与枚举正本)

锁定码对支用拦截、对还款放行的规则可归并为「可锁定/可管控」

建议:把消费支付(N015)、取现(N017)、还款(N018)归并为「可锁定/可管控」接口。 理由:锁定码(blockCode)各字符对支付/取现的拦截、对还款不拦截(L381)这套规则在受理支付(A-04)、受理取现(A-05)、受理还款(A-06)各处重复引用(出处 R1§五、R5§②)。
涉及:N015 消费支付交易N017 取现支用N018 还款交易P005 冻结/拦截码(锁定码)L381 规则:还款方向不受锁定码拦截A-04 受理支付交易A-05 受理取现申请A-06 受理还款出处:R1§五·R5§②
登记原文此处或可归并接口『可锁定/可管控』:blockCode 各字符对支付/取现的拦截、对还款的不拦截(L381)在 A-04/A-05/A-06 各处重复引用。 候选:N015·N017·N018
○ 待收口
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 撤销写入无处挂;待后端补字段名
○ 待收口
X-047冲突audit-seg1

GPS 强制授权弹窗:L170 与 L362 重复登记

说法一
L170 保留强制授权半句(现状,与 note 自陈矛盾)
说法二
L170 收敛为纯基础上报,强制授权归 L362
涉及:L170L362A-50出处:SEG1 核验 2026-08-27
登记原文GPS 强制授权弹窗:L170 与 L362 重复登记
○ 待收口
X-048冲突audit-seg1

同一开通状态 T017 下,进申请落地页还是直接进面签

说法一
T017 走申请落地页(L012 现状)
说法二
T017 直接进面签(L005 现状);L012 集合应剔除 T017
涉及:L012L005A-01N013出处:SEG1 核验 2026-08-27
登记原文同一开通状态 T017 下,进申请落地页还是直接进面签
○ 待收口
X-049冲突audit-seg1

钱包初级户刷脸成功后:先升中级还是直接升高级

说法一
两条是串行两步(刷脸后升中级→提交时再升高级)
说法二
两条是互斥分支,条件须补触发时点
涉及:L009L010A-25N003出处:SEG1 核验 2026-08-27
登记原文钱包初级户刷脸成功后:先升中级还是直接升高级
○ 待收口
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
登记原文授信申请的双主键与裁决结果码的归属
○ 待收口
X-050冲突audit-seg1

钱包账户借用客户的 mpcId 作身份标识

说法一
钱包账户是独立对象,须向后端要它自己的账号标识
说法二
钱包账户不是独立对象,mpcLevel/mpc_status 改判为客户属性后退役
涉及:N003 钱包账户N001 客户P199 钱包账户状态P076 钱包账户等级出处:SEG1 核验 2026-08-27
登记原文钱包账户借用客户的 mpcId 作身份标识
○ 待收口
X-051冲突audit-seg1

采集/上报类事件算不算动作的产物

说法一
保留 product_of=A-50(视为隐式上报动作的产物)
说法二
清空 product_of(视为设备/客户侧观测事件)
涉及:N038 GPS 定位记录N039 App List 采集记录N042 对外归因上报事件A-50 上报事件出处:SEG1 核验 2026-08-27
登记原文采集/上报类事件算不算动作的产物
○ 待收口
X-052冲突audit-seg1

开户授信链路的服务编号两处对不上

说法一
88200102 是同一引擎的另一跳编号,登记表可沿用
说法二
88200102 是取现复借专号,开户段应改为 88100024/10106,F-07 函数名须改
涉及:F-07 贷前/首账前借款审批引擎A-56 受理授信提交并送审出处: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
登记原文积分账户的账户号字段名仍未拿到
○ 待收口
X-053冲突audit-seg2

渠道侧支付要不要并进消费支付交易

说法一
并入 N015(承载差异不构成两个实体)
说法二
保留两个对象(需说清业务边界并补状态属性)
涉及:N015 消费支付交易N016 渠道侧支付P104 支付场景标识R065 经…收单R066 代付给(Biller)G-182出处:SEG2 核验 2026-08-27
登记原文渠道侧支付要不要并进消费支付交易
○ 待收口
X-054冲突audit-seg2

组合支付守恒式到底含几条腿

说法一
守恒式四项(现状,含钱包/PL/积分/立减)
说法二
守恒式五项(补定存腿 depositAmt)
涉及:L019 组合支付守恒L345 券金额服务端重算P102 组合支付金额构成出处: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
登记原文通知的送达状态无属性,却声明要观测送达率
○ 待收口
X-055冲突audit-seg2

虚拟卡支付的 300 万上限到底是单笔还是日累计

说法一
300 万=每日限额的可调上限(L038 冗余,应退役并入 L037)
说法二
300 万=单笔硬上限(L038 应改写为「单笔不得超过 Rp3.000.000,独立于每日限额」)
涉及:L037 差额超每日剩余上限失败L038 PL 部分超 3M 失败L039 每日限额默认与上限P112·P113出处:SEG2 核验 2026-08-27
登记原文虚拟卡支付的 300 万上限到底是单笔还是日累计
○ 待收口
X-056冲突audit-seg2

展示类规则挂在动作上时,四道门都套不上

说法一
owl_status=建模约定不进 OWL 的规则 gate 可留空,合规检查豁免
说法二
为展示类规则新增第五道门(如「展示门」),纲要相应放宽
涉及:L031L032L035L052L028A-51 展示引导与弹窗记录出处:SEG2 核验 2026-08-27
登记原文展示类规则挂在动作上时,四道门都套不上
○ 待收口
X-057冲突audit-seg2

等本等费分摊该不该单独立一个函数

说法一
退役 F-34,算法并入 F-08 口径
说法二
保留 F-34,为逐期还款计划单建属性作其产物
涉及:F-34 等本等费分摊F-08 定价引擎试算P034 试算方案字段组出处:SEG2 核验 2026-08-27
登记原文等本等费分摊该不该单独立一个函数
○ 待收口

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