ByteDance · Risk Foundation

Risk
Foundation

Authoring, verifying and investigating risk decisions 连接策略配置、支付验证与风险分析

I designed three connected parts of ByteDance's risk foundation: the REP rule engine for strategy teams, payment verification for consumers, and the Risk Detection workspace for operations. These workflows consume existing risk factors; the risk-factor platform itself was outside my scope. 我负责三类相互连接的风控体验：面向策略团队的 REP 规则引擎、面向支付用户的验证组件，以及面向运营团队的风险感知平台。设计会调用既有风险因子，但风险因子平台本身不在我的主责范围内。

Role Experience design角色平台体验设计 Scope REP · Verification · Risk Detection范围 REP · 验证 · 风险感知 Users Strategy · Consumers · Operations用户策略 · 支付用户 · 运营 Risk decision lifecycle风险决策生命周期

00.1 · Project overview

Three workflows support one risk decision lifecycle

A customer may only see an approval, a block or an extra verification step. Producing that result requires risk signals, executable rules, customer verification and feedback from live operations. I owned the experience design for REP, verification and Risk Detection; the upstream factor platform was a dependency, not part of my ownership.

Decision input · Dependency

Risk factors

Existing signals used in rule configuration and verification.

Decision logic · Owned

REP rule engine

Turns strategy knowledge into governed, executable rules.

Decision assurance · Owned

Verification

Confirms identity or payment-method ownership when risk is elevated.

Decision feedback · Owned

Risk Detection

Finds anomalies, investigates impact and returns evidence to strategy teams.

Scope boundary

The work connected three products without presenting them as one user journey. Strategy authors, payment customers and risk operators use different surfaces; shared objects, states and version context keep their work connected.

00.2 · Foundation context

One decision foundation, three distinct user groups

Risk Foundation provides real-time, asynchronous and offline decision services for financial and payment risk. REP is the strategy workspace; verification appears in customer payment journeys; Risk Detection supports operations after rules are live.

System map linking products, risk signals, the rule engine, verification and operational feedback — **The shared foundation is technical, not organizational:** each group keeps a clear responsibility.Evidence from verification and live operations returns to the strategy team with object and version context.

Responsibility model

Strategy authors define decisions, customers complete required checks, and operators investigate live anomalies

The design had to connect these responsibilities without implying that one person operates the entire lifecycle.

Author rules→Verify when needed→Investigate outcomes→Revise strategy

REP · Strategy author

Risk strategist

Authors, tests and releases rules while managing dependencies and versions.

Verification · Customer

Payment customer

Completes an identity or ownership check when a transaction requires more evidence.

Risk Detection · Operator

Risk operations

Finds anomalies, investigates affected entities and sends evidence back to strategy teams.

Rule engine · REP

A governed path from rule authoring to release

This part follows the work of risk strategists as they create rules, group them into Categories, compose a Project decision flow, create a version and gather evidence before release.

Users: risk strategistsResearch: 6 REP usersScope: Rule → Category → Project → Version → Release

01.1 · Research and framing

The release risk came from missing context, not missing features

I observed six REP users across rule creation, Category management, Project composition, versioning, monitoring and release. The repeated failure was loss of context between objects and states: users could complete each step, but could not reliably judge what had changed or what the change would affect.

Relationships were hard to see

Rule, Category, Project and Snapshot links were split across pages, so users reconstructed dependencies from memory.

Change impact was unclear

Users could edit a flow but had little help judging upstream changes, node traffic or differences from the online version.

Release work was easy to leave unfinished

Monitoring, approval and release lived across surfaces; an approved version could still miss the final release step.

REP user journey across rule authoring, project versioning, monitoring and release — **Research output:** issues were grouped by task stage and then reframed around context, evidence and handoff.This prevented a list of local UI fixes from replacing the larger workflow problem.

01.2 · REP design response

Keep identity, dependency and release status visible at each handoff

The information architecture follows the production chain instead of a collection of features. A rule remains traceable as it enters a Category, a Project, a version and finally a controlled release.

01AuthorCreate a rule with progressive logic controls

02OrganizeGroup rules and expose references

03ComposeBuild a Project decision flow

04ValidateCompare with the online version

05ReleaseApprove and roll out gradually

REP rule workspace with ownership, Category, status and actions — **Rule workspace**Search, ownership, business context and dependencies appear together before an edit begins.

REP Project canvas with a start node and an initial connected node — **Project canvas**A minimal runnable structure gives users a concrete starting point without treating Save as release.

REP release process from version creation through monitoring, approval and rollout — **Version contract**Both rule-level and Project-level entry points produce the same governed object: a Project version with an explicit baseline, evidence and release status.

Release principle

Save confirms an edit; it does not create a release. Version creation, monitoring, approval and rollout remain separate states so users can see what is committed and what is still reversible.

Payment verification · Consumer

Protect the payment without making the customer guess

Verification adds friction by design. The experience must explain why a check is required, what information is needed, how many attempts remain and what alternative is available if the current method fails.

Users: payment customersMethods: PIN · OTP · Card · Face · LivenessRecovery: method switch · appeal

02.1 · Verification and recovery

Each state answers four questions: why, what, how long and what next

The components use a consistent state model across verification methods while adapting instructions to the evidence being requested. Failure states preserve remaining attempts, explain lockouts and offer a safe alternative instead of ending the payment journey without direction.

Set expectations before input

Explain the purpose, the requested evidence and any privacy-sensitive action before asking the customer to proceed.

Keep progress and attempts visible

Processing, success, retry and lockout states use the same structure so status does not need to be inferred.

Provide a credible way out

Customers can switch methods when available or enter an ownership appeal when a payment method has been restricted.

Payment PIN verification initial state — **Consistent verification states**Instructions, attempts and next steps remain in predictable positions across methods.

Sheet for switching to another available verification method — **Method switching**The system shows only methods that are currently usable instead of sending customers through repeated failures.

Card ownership appeal review screen before upload — **Ownership appeal**Customers review captured evidence before submission and can resubmit only the item that failed review.

Risk Detection · Operations

Move from an anomaly to evidence a strategy team can use

Operators first confirm the time window and rule context, then investigate the affected merchant, related entities and behavior sequences. The output is an evidence package, not another dashboard screenshot.

Users: risk operationsGoal: explain and scope anomaliesLoop: detect → investigate → hand off → recheck

03.1 · Operational investigation

A five-step path keeps monitoring and investigation connected

Operators compare actual, preset and historical values, confirm the triggering rule and owner, and then move through object, relationship and behavior evidence. Each step narrows the question before the next query adds more complexity.

01DetectConfirm the anomalous window

02ContextCheck threshold, rule and owner

03ObjectReview merchant and fund status

04NetworkInspect shared entities and paths

05BehaviorCompare individual and group sequences

Risk analysis workspace with trends, thresholds, performance metrics and event details — **Confirm before investigating**Trend, threshold, request volume, impact and event records establish whether the signal warrants deeper analysis.

Object evidenceMerchant identity, operating status, credit, overdue history and funds are reviewed in one context.

Relationship graph with risk nodes, filters and density metrics — **Relationship evidence**Query scope and depth are controlled before operators expand shared devices, email addresses or phone numbers.

Individual entity behavior sequence across registration, login, card binding and transactions — **Individual sequence**Request, device, IP and risk labels explain how one subject moved through the system.

Multi-entity behavior sequence comparing volume and value over time — **Group comparison**Aligned timelines expose convergence while the event table keeps the pattern traceable to specific subjects.

Investigation output

The handoff contains the affected object, relationship path, behavior evidence, time window, rule context and owner. This gives the strategy team a specific problem to evaluate and a baseline for checking whether the next rule change works.

Shared · Scale and evaluation

Reuse the decision contract, not a page template

Across products and markets, the stable layer is the object model, state language, permission model and release contract. Business-specific thresholds, metrics, approvers and rollout settings remain configurable.

Evidence, not claims

This case study does not publish sensitive loss or enforcement data

Internal evaluation considered release lead time, verification completion, detection-to-action time and appeal resolution. I have not presented those measurement areas as public results.

Strategy efficiencyConfiguration, validation and release timeRelease lead time

Payment riskVerification, intervention and loss indicatorsVerification / risk loss

OperationsTime from anomaly detection to actionDetection to action

Customer recoveryAppeal completion, handling time and restorationAppeal resolution

Shared · Reflection

What changed in how I design complex operational products

Clarity is not the same as removing expert capability

Professional tools need hierarchy, context and progressive disclosure while preserving the precision experts rely on.

State is part of the information architecture

In a high-risk workflow, state must communicate responsibility, next action and recovery, not only system progress.

Platform consistency belongs in contracts

Shared objects, release rules and status language scale better than forcing every business into the same screen.

Feedback must return with context

Verification and operational findings are useful to strategy teams only when they retain the affected object, version and time window.

00.1 · Project Overview

四类能力如何共同支持一次风险决策

用户最终看到的是放行、拦截或额外验证，但每个结果都依赖风险信号、规则执行、用户验证和运行反馈。我的工作集中在规则引擎、验证组件与风险感知平台，并在这些流程中接入既有风险因子。

Decision input · 使用能力

风险因子

在规则配置与验证场景中按需调用既有风险信号

Decision logic

REP 规则引擎

将风险经验组织为可执行、可发布的策略

Decision assurance

风控验证组件

在需要额外校验时确认身份与支付方式归属

Decision feedback

风险感知平台

实时感知异常，并支持事中处置与事后归因

Experience lens

风险因子提供输入，REP 执行判断，验证处理高风险交易，风险感知检查线上表现。它们由不同角色使用，但需要共享对象、状态和版本上下文，才能让一次线上异常回到下一轮策略调整。

00.2 · Foundation Context

Risk Foundation 如何连接策略、验证与运行反馈

Risk Foundation 为金融及支付风控提供稳定、高性能的实时、异步与离线决策服务，同时为策略和运营团队提供日常研发、配置、测试、发布、验证与风险感知能力。REP 是全球策略中心，FEP 等上游服务提供可调用的风险信号；规则引擎、验证组件与风险感知平台共同支撑线上决策。

Risk Foundation 将多种业务产品与规则引擎、实时风控决策和风险感知连接为持续反馈的决策闭环 — **Foundation 是产品与风控能力之间的决策底座：**业务请求进入规则引擎，并形成实时风控决策。风险感知持续监测决策效果与异常，把反馈回流产品场景和规则优化。

00.3 · Users & Jobs

三类用户在同一条风险链路中分别完成什么

策略人员在 REP 中编写、验证和发布规则；支付用户在被要求时完成身份或支付方式验证；运营人员发现异常、分析影响并把证据反馈给策略团队。三段流程相互依赖，但责任边界需要保持清楚。

Risk loop · 风险闭环

策略人员写规则，用户完成必要验证，运营把异常反馈给策略团队

三类能力不是由同一角色操作的连续页面，而是由不同用户共同完成的闭环：策略人员通过 REP 制定与发布规则；C 端用户在支付场景完成必要验证；运营人员通过风险感知发现问题，再将洞察反馈给策略同学持续优化。

REP 写策略→C 端安全验证→风险感知→策略优化

REP · Strategy author

风控策略人员

在 REP 中编写、管理、测试和发布风控策略，并根据反馈持续调整规则。

Verification · End user

C 端支付用户

在系统要求时完成身份或支付方式验证，并在失败时获得明确的重试、切换或申诉路径。

Risk Detection · Operator

风控运营人员

发现异常与风险问题，分析原因并将洞察反馈给策略同学，推动下一轮优化。

Rule Engine · REP

规则引擎 REP

第一部分聚焦风控策略人员的真实工作：如何创建与管理规则、组织规则集与项目、理解版本变化，并把一条策略安全地推进到审核与发布。

用户：风控策略人员研究：6 位真实 REP 用户范围：Rule → Category → Project → Version → Release

01.1 · REP User Research

沿着真实任务走一遍，问题不在单个页面，而在对象与状态之间的断点

我基于 6 位真实 REP 用户的调研反馈，将他们从创建规则到验证、审核与发布的实际任务还原为 Journey Map。研究帮助团队从零散的功能诉求中识别出更稳定的问题模式：用户需要在复杂对象之间保持上下文，在关键变更前获得可解释的证据，并清楚知道下一步由谁完成。

6位真实 REP 用户参与调研

6个核心任务阶段被系统梳理

3条跨阶段问题线索进入设计定义

01 · Rule

创建 / 管理规则

Pain point

搜索只覆盖当前分页；规则名称、状态与 Snapshot 反馈分散；复杂 if-else 层级难以组织。

02 · Category

创建 / 管理规则集

Pain point

Category 与决策流的挂载关系不可见，规则内容显示不完整。

03 · Project

创建 / 管理规则项目

Pain point

主流与子流层级、上游改动影响和节点流量不清；节点难搜索，Snapshot 差异难理解。

04 · Version

创建 / 管理项目版本

Pain point

线上版本与历史版本边界模糊，Difference 内容过长，用户难以定位真正发生变化的位置。

05 · Validate

验证

Pain point

Monitor 层级过深，指标无法解释具体问题；逐节点查看、缩放和移动成本高。

06 · Release

审核与发布

Pain point

审核与发布跨 Sky 和 REP，用户审批后容易忘记回来发布，也可能误带入他人的规则。

“点了 Snapshot 之后，我不知道有没有建立一个 Snapshot。”

REP user · Rule management

“我需要查看每一个节点的流向，并跟线上流量比较。”

REP user · Validation

“提交审核之后，我会忘记回来发布。”

REP user · Release

查看原始 User Journey Map 完整记录用户目标、触点、痛点与机会点

基于 6 位 REP 用户真实调研整理的完整 User Journey Map，覆盖规则、规则集、规则项目、版本、验证和发布阶段

为保护内部信息，研究内容在作品集中仅保留与体验问题和设计机会相关的归纳。

01.2 · Synthesized Persona

REP 风控策略人员：在复杂对象与高风险发布之间，持续寻找可判断的确定性

这是一位基于 6 位真实 REP 用户共同特征形成的综合角色原型，不对应任何单一受访者。画像保留研究中反复出现的任务、行为和判断压力，用于帮助团队围绕同一类核心用户做设计决策。

Primary job

把风险知识准确地写成规则，并有把握地让它安全上线

工作目标

快速找到、创建和复用正确的规则，避免重复配置。
理解规则、规则集、项目与版本之间的真实关系。
在发布前判断改动范围、线上差异与潜在风险。
让审核、发布与回滚过程连续、可追溯。

典型行为

先通过搜索与筛选定位对象，再进入具体编辑任务。
频繁在 Rule、Category、Project 与 Version 之间切换。
依赖 Snapshot、历史版本、线上对比和 Monitor 结果做判断。
在 Sky 完成审核后返回 REP 发布，与多角色接力协作。

01对象看得见名称、关系、状态与版本清楚呈现

02上下文不断点跨层级、跨页面仍知道正在处理什么

03变更有证据影响、差异与验证结果能够解释

04责任有归属当前由谁处理、下一步做什么明确

01.3 · Competitive Analysis

三种规则系统：从快速表达、结构化约束到资产化治理

我拆解了 Stripe Radar、Adyen Dynamic 3D Secure 与阿里云风险识别。三者对应不同复杂度：Stripe 聚焦单条支付决策，Adyen 用专用表单约束 3DS 策略，阿里云则把字段、事件和策略拆成可复用资产。横向比较帮助我判断 REP 既要写得快，也要在复杂规模下保持关系、证据与发布安全。

Stripe Radar Rules 页面，展示 Request 3DS、Allow、Block 和 Manual Review 四类规则入口与规则表现 — **01 · Entry**
规则入口直接按支付决策结果分类，同时在同一页面保留命中表现和测试环境提示，让创建动作与规则效果保持在一个工作语境中。

Stripe Radar Request 3DS 规则创建抽屉，包含条件输入、属性提示和常用规则参考 — **Request 3DS**结果优先 · 语法辅助

Stripe Radar 新规则测试结果，展示历史匹配金额、争议、退款、拦截和正常交易等结果 — **Test before adding**历史匹配 · 影响判断

Stripe Radar Allow 规则创建抽屉，说明命中后支付不会被拦截或进入人工审核 — **Allow**明确放行结果

Stripe Radar Block 规则创建抽屉，说明 Allow 规则优先于 Block 规则 — **Block**显式说明优先级

Stripe Radar Review 规则创建抽屉，说明命中支付进入人工审核及其与 Allow、Block 的关系 — **Review**人工判断作为结果

以决策结果作为创建入口

用户先选择验证、放行、拦截或人工审核，再编写条件。规则因此被表达为清楚的 “Action if Condition”，降低了从业务判断到系统配置之间的翻译成本。

用紧凑 DSL 支持专业效率

单行表达式配合属性高亮、语法提示、常用示例和文档入口，让熟练用户快速完成配置；但当分支和依赖增加时，线性表达对整体结构的解释能力会下降。

把冲突关系写进规则说明

Allow、Block 与 Review 的执行关系直接出现在创建文案中，用户不必离开当前任务查找优先级。但这种隐含层级更适合少量独立规则，规模扩大后仍需要可视化的关系治理。

发布之前先建立证据

Test rule 用历史支付呈现潜在命中与结果分布；没有样本时也明确说明无法判断有效性。验证不只是“能否运行”，而是帮助策略人员理解业务影响与不确定性。

Adyen Dynamic 3D Secure Rules 页面，展示默认 3DS 策略、规则执行顺序和账户层级说明 — **Default & order**默认策略 · 触发顺序

Adyen Add Rule 页面，以发行国家、用户国家、支付方式、设备、金额、风险分数和 BIN 等条件配置 3DS 动作 — **Structured builder**支付条件 · 3DS 动作

用支付维度代替规则语法

发行国家、用户国家、支付方式、设备、金额、风险分数与 BIN 被直接做成结构化字段。用户不需要学习 DSL，也更不容易写出无效语法，但可表达的组合受预设字段和表单结构限制。

默认策略为所有支付提供兜底

Always 与 Prefer no 先定义未命中动态规则时的基础行为，避免策略出现空白区。专用 3DS 场景因此更容易建立一致预期，但产品语言仍偏系统配置，需要用户理解认证机制。

把优先级与账户范围纳入治理

页面明确展示 Trigger order，并说明先评估 Merchant Account、再评估 Company Account。相比扁平规则列表，它更早处理规则冲突与作用域问题，适合多商户账户的支付运营语境。

配置完成不等于能够安全判断

从这组界面看，保存前没有展示历史命中、潜在支付影响或不确定性。用户可以清楚地填写规则，却仍难回答它会影响多少交易、是否增加支付摩擦，以及是否值得上线。

阿里云新建字段抽屉，配置字段名、显示名、类型、分类、描述与来源 — **Field schema**定义语义 · 类型 · 来源

阿里云新建事件页面，通过注册、登录、修改密码等事件模板填充字段 — **Event template**场景模板 · 快速建模

阿里云事件字段选择器，可搜索手机号及其脱敏、哈希和业务变体字段 — **Reuse fields**技术名 · 业务显示名

阿里云事件字段下拉与新建自定义字段入口，支持扩展事件数据模型 — **Extend schema**已有字段 · 自定义扩展

阿里云事件管理列表，展示事件编码、状态、已配置策略数、更新时间和操作 — **Event inventory**编码 · 状态 · 引用数量

阿里云事件导入抽屉，从已有事件中选择并导入到当前场景 — **Import events**跨场景复用

阿里云策略管理列表，展示版本、运行状态、审核状态、优先级、关联事件与运行操作 — **Strategy governance**版本 · 优先级 · 运行状态

阿里云策略管理按事件筛选，并在事件下区分正式策略与旁路策略 — **Branch strategy**正式路径 · 旁路验证

先建设资产，再编排决策

字段、事件与策略被拆成独立对象：字段沉淀统一语义，事件组合业务上下文，策略引用事件形成判断。模型能支撑跨场景复用，也比单条规则更适合长期治理。

模板、导入与自定义共同扩展

用户既可以从注册、登录等模板开始，也能导入已有事件或新增自定义字段。这兼顾了标准化与业务差异，但如果缺少命名、去重和引用治理，自定义能力也会迅速制造新的资产噪音。

规模化治理进入列表主视图

事件编码、配置策略数、版本、优先级、审核和运行状态都进入列表，并提供试运行、正式运行与旁路。相比前两者，它对复杂生命周期的覆盖更完整。

对象越完整，关系越容易失去

字段、事件与策略分散在多个模块，关系主要藏在下拉框、数量和表格操作中。用户能管理每类资产，却难在同一视图理解引用链、变更影响、线上差异与下一步动作。

Horizontal comparison

复杂度越高，设计重心越要从“创建成功”转向“持续可判断”

三个产品没有绝对优劣，它们服务的是不同规模的问题。横向比较的价值，是识别哪些能力应该成为 REP 的快速路径，哪些必须成为复杂系统的治理底座。

Dimension	Stripe Radar	Adyen	阿里云风险识别
对象结构	Rule单条规则直接承载条件与支付结果。	Default + Dynamic Rule默认 3DS 策略叠加特定条件规则。	Field → Event → Strategy分层资产再进入版本、优先级与运行治理。
表达方式	结果优先的 DSLAction if Condition，专业用户输入效率高。	条件优先的表单支付字段结构化，语法门槛低但表达范围受限。	对象配置与编排模板、导入和自定义支持复杂场景，操作链路更长。
验证证据	最强创建前查看历史命中、交易结果与无样本不确定性。	较弱能明确配置 3DS 行为，但截图中缺少历史影响预估。	运行能力多、证据分散有试运行和旁路，列表中看不到结果如何支撑判断。
治理能力	轻量规则类型和隐含优先级适合少量独立规则。	中等明确触发顺序、默认行为与 Merchant / Company 作用域。	完整资产复用、状态、版本、审核、优先级与运行模式覆盖更广。
主要优势	学习快、反馈近，适合快速调整单条支付决策。	专业场景约束明确，降低常见 3DS 配置错误。	可扩展、可复用，适合多业务场景与长期策略资产管理。
主要局限	复杂关系、协作、版本与发布治理不足。	专用性强，复杂分支与发布影响难以表达。	认知和导航成本最高，对象关系与变更影响不够直观。

Implications for REP

三类竞品模式对应三种实际需求

REP 需要吸收三者最有效的部分，同时解决它们共同遗漏的问题：对象关系、变更影响与发布责任必须在任务推进中持续可见。

让简单规则保持简单

借鉴 Stripe 的结果优先入口和 Adyen 的结构化字段，为高频支付条件提供快速路径；复杂用户再逐步进入表达式、If / Else 与高级变量，而不是一开始面对全部能力。

把对象关系从下拉框里拿出来

Rule、Category、Project 与 Version 的归属、引用、优先级和线上状态需要在当前页面持续可见。用户不应靠跳转与记忆重建一条规则最终影响了哪条决策流。

复用必须和资产治理一起设计

模板、导入与自定义能提升扩展性，但必须同时提供全量搜索、命名规范、字段来源、使用次数、引用位置和重复检测，避免“可复用”最终变成“找不到可信资产”。

把验证变成发布门槛，而不是附加工具

在创建 Version 前展示历史命中、样本路径、节点流量、线上差异与潜在业务影响；没有足够样本时明确表达不确定性，再决定 Monitor、旁路或灰度策略。

让治理状态直接回答下一步

版本、审批、优先级、Monitor、灰度、正式运行与回滚不只是一组标签。每个状态都要说明当前发生了什么、由谁处理、可以做什么，以及失败后如何恢复。

Design direction for REP

竞品没有直接提供 REP 的答案。Stripe 适合快速表达简单规则，Adyen 强调支付维度约束，阿里云更重视资产治理。REP 需要根据任务复杂度组合这些模式，同时保留对象关系、版本差异和发布证据。

01.4 · REP Problem Framing

六个阶段暴露出同一个问题：用户无法持续判断“现在是什么、改变了什么、下一步做什么”

问题不在缺少功能，而在复杂任务中持续失去上下文。将调研反馈按任务链聚类后，我把分散诉求收束为三类会直接影响操作效率与发布安全的问题。

规则对象很多，但关系、状态与版本不可见

搜索只覆盖当前分页，Category 与决策流的挂载关系不清；规则状态、Snapshot 是否创建及多人编辑后的线上差异分散在不同页面，用户需要反复跳转确认。

项目结构能搭出来，但变更影响难以判断

主流、子流和二级子流的关系不直观，上游改动及节点流量影响缺少提示；Snapshot、线上版本与历史版本的差异也难以快速定位。

验证与发布跨越多个界面，任务难以闭环

Monitor 层级深且指标缺少线上对比，用户需要逐节点和样本排查；审核又跨越 Sky 与 REP，Approve 后容易遗漏 Release，甚至误带入其他人的规则。

01.5 · REP Information Architecture

让用户始终知道自己在哪、正在改变什么、下一步由谁完成

方案不再按分散功能组织页面，而是把 Rule、Category、Project、Version 与 Release 连接成一条规则生产链，在对象切换时持续保留关系、状态和变更上下文。

围绕 REP 规则生产链组织平台

Rule

条件If / ElseTag状态

Category

规则集优先级命中关系引用

Project

规则流节点Snapshot变更影响

Version

HistoryDiffOnlineRollback

Release

MonitorApprovalGrayscaleEnable

01.7 · REP Solution / Rule Workspace

让规则在列表里带着上下文出现，在变更前先看见影响

规则页不再只是配置入口，而是策略人员查找、判断和维护规则资产的工作台。设计围绕三个连续问题展开：能否快速找到目标规则，能否理解它的责任与业务上下文，以及能否在修改或删除前判断真实影响。

REP Rules 默认状态页，展示规则名称和 ID、创建与更新人员、时间、Category、搜索筛选与行级操作 — **Rule asset workspace** 将规则身份、负责人、更新时间、业务归属与关键操作收敛在同一视野，让用户不必在多个页面之间重新拼接上下文。

找得到

用全量搜索、组合筛选和时间排序，从持续增长的规则资产中迅速定位目标。

看得懂

同时呈现唯一 ID、Creator、Updater、Category 与时间，帮助用户判断归属和活跃度。

改得稳

通过 Snapshot 差异、引用校验和不可逆确认，让高风险操作建立在影响证据之上。

01 · Precision retrieval

从“记得名字”转向按资产线索定位

策略人员经常只记得规则名称片段、维护人或大致修改时间。检索系统因此不依赖单一命名，而是把搜索、人员、业务归属和时间组合成一套渐进式定位方式。

SEARCH同时匹配 Rule Name 与唯一 ID，并覆盖全部分页。
FILTERCreator、Updater 与 Category 支持搜索、多选和结果回显。
RECENCY默认按更新时间倒序，并提供时间区间与快捷范围。

Rules 搜索交互说明，展示默认、聚焦、无结果和搜索结果状态 — **Search across the asset base**状态被完整设计，但作品集只保留与任务判断直接相关的证据。

Create Snapshot 弹窗，并列比较前后版本的 Category 和规则逻辑差异 — **Evidence before commitment**把版本差异、变更意图与后续发布衔接放进同一次确认。

02 · Controlled change

生成 Snapshot 前，先看清改变了什么

支付风控规则的修改可能直接改变线上决策。Snapshot 不只是保存版本，而是将旧版本、新版本和变更说明组织成一次可审阅的提交，为后续 Project 发布留下明确证据。

DIFF并列比较版本，以颜色聚焦 Category 与逻辑中的真实差异。
INTENT要求补充 Description，让版本历史同时记录为什么改变。
HANDOFF成功反馈明确说明 Snapshot 将在 Project 发布时被选择。

Dependency-aware actions

删除不再只是确认一条规则，而是先确认它影响了什么。 系统先校验规则是否被有效 Category 与 Project 引用；存在依赖时展示引用位置并阻止删除，无依赖时才进入不可逆确认，把误操作保护从一句警告升级为关系证据。

完整交互证据Search、人员与 Category 筛选、时间范围、排序循环及 Actions 状态

Creator、Updater 与 Category 筛选交互说明 — **People & Category**搜索、多选与回显

Create time 与 Update time 日期范围筛选说明 — **Time range**区间与快捷时间范围

Create time 与 Update time 排序循环说明 — **Sorting**默认、升序、降序与取消

Rules 行级操作、创建 Snapshot 与删除依赖校验流程 — **Actions**快照、复制与依赖保护

详细状态作为设计完整性的支撑证据收纳在这里，主叙事仍聚焦策略人员如何更快定位资产，并在变更前获得足够安全感。

03 · Rule authoring

把业务判断翻译成可执行、可复用的规则结构

策略人员不是在“写代码”，而是在表达一组可解释的风险判断。创建页先确定规则身份与业务归属，再用 IF → THEN 建立最小决策骨架；只有当场景需要时，才逐步加入条件组、ELSEIF、ELSE 与更复杂的取值方式。

REP Create Rule 页面，包含规则名称、Category、描述，以及 IF 条件与 THEN 动作的结构化编辑区 — **Structured rule authoring** 页面从资产身份进入判断逻辑：Rule name 与 Category 解决归属，IF 定义何时命中，THEN 定义命中后执行什么，让阅读顺序与策略人员的思考顺序一致。

先定义身份

名称、Category 与描述先回答“这条规则属于哪里、为什么存在”，让后续复用和追溯有稳定锚点。

沿用判断语言

以 IF → THEN 映射“满足什么条件，就执行什么动作”，降低策略逻辑与界面结构之间的翻译成本。

复杂度按需出现

默认只展示最小可用骨架，再逐步增加条件、分支与嵌套，避免简单规则被完整能力压垮。

在 Create Rule 页面中快速新建 Category 的弹窗 — **Inline Category creation**缺少归属对象时，在当前任务中即时补齐。

04 · Task continuity

不离开规则创建页，也能补齐缺失的 Category

Category 是规则复用与 Project 编排的中间层，但用户常在创建规则时才发现目标分类不存在。就地创建把“先退出、去管理分类、再返回重填”的中断，压缩为一次轻量补充。

CONTEXT弹窗保留当前规则内容与编辑位置，不打断已经形成的判断。
MINIMUM只收集名称与描述，快速生成当前任务所需的最小分类对象。
RETURN创建成功后回到原流程继续编排，减少跨页面往返与遗漏。

Progressive logic composition

先让简单判断一眼可读，再为复杂策略提供足够深度。 每条条件统一为 Field → Operator → Value，THEN 延续相同结构表达执行结果；ELSEIF、ELSE、条件组与嵌套只在用户主动添加时展开，并通过折叠保留整体决策路径。

规则编排交互证据IF / ELSEIF / ELSE 分支、THEN 动作与 Add Condition 的完整状态

添加 IF、ELSEIF、ELSE 与 THEN 的分支交互说明 — **Branching**图内下拉查看完整分支状态

Add Condition 的字段、操作符、取值、条件组与复杂嵌套交互说明 — **Add condition**图内下拉查看条件组与复杂取值

长图保留完整异常、嵌套与取值状态，作为方案可实现性的证据；主叙事只呈现支撑设计判断的关键结构，确保读者先理解“为什么这样设计”。

05 · Rule lifecycle

规则创建之后，仍然需要可审阅、可比较、可追责

一条支付风控规则会被持续修改并被多个决策流引用。详情页因此不只是“查看结果”，而是当前规则的事实基线：用户从这里确认内容与归属，进入编辑，管理 Snapshot，并追溯每一次变更。

Rule Details 默认显示 Rule info，包含规则名称、Category、描述、IF 条件与 THEN 动作 — **Single source of truth** 默认落在 Rule info，让策略人员先确认当前规则身份、业务归属与完整判断逻辑；Snapshot 和 Operation history 作为同一资产下的版本与审计视图持续可达。

先确认当前事实

详情页完整呈现 Rule info 与决策逻辑，避免用户在编辑前依赖记忆判断当前状态。

再比较内容版本

Snapshot 保存可选择、可对比的内容证据，并关联 Operator、时间和使用关系。

最后追溯操作

Operation history 独立回答谁在何时改了什么，为协作、审计与异常归因留下记录。

06 · Controlled editing

让用户始终知道自己正在修改哪个版本

编辑页保留与创建页一致的 IF → THEN 结构，同时在标题旁明确当前版本与 In use 状态。策略人员能够理解修改发生在哪条基线上，并预期 Update 后进入新的版本记录。

BASELINE版本号与使用状态常驻，避免在未知基线上直接修改。
CONTINUITY查看与编辑使用同一逻辑结构，减少重新理解与定位成本。
COMMITUpdate 表达一次受控变更提交，而不是静默覆盖线上事实。

Edit Rule 页面，显示当前 V4 In use 版本并允许修改 Category、条件与动作 — **Edit with a visible baseline**当前版本、使用状态与规则内容同屏。

Rule Snapshot 列表，展示版本、Operator、操作时间、决策流关系和 Compare 操作 — **Version evidence**选择两个 Snapshot 后进入内容对比。

07 · Snapshot governance

版本列表不仅回答“有哪些”，还要说明“在哪里被使用”

版本本身不足以支持发布判断。Snapshot 列表同时暴露 Operator、时间与 Flow relationship，帮助用户先理解版本的来源和影响范围，再选择两个版本进入比较。

SELECT显式选择两个版本后才激活 Compare，约束比较对象。
RELATION展示 Category 与 Project 的引用关系，连接内容版本和线上影响。
STATUSIn use 状态突出当前事实，避免历史版本与线上版本混淆。

08 · Evidence & audit

内容差异与操作记录分开表达，分别服务决策判断和责任追溯

Compare V8 and V9 弹窗，并列展示版本信息、Category 和规则逻辑差异 — **Compare snapshots**并列 Diff、差异高亮与只看变更。

Rule Operation history 页面，展示 Operator、操作时间与修改内容 — **Operation history**谁、何时、把什么从旧值改为新值。

Two layers of trust

Snapshot 让策略人员相信“内容可以被还原和比较”，Operation History 让团队相信“行为可以被追溯和解释”。 两层证据共同把规则编辑从一次页面操作，提升为可审计的风险决策资产管理。

01.6 · REP Core Journey

从规则创建、Category 成组，到 Project 决策流发布

REP 的核心旅程不从版本发布开始。策略人员先创建 Rule，再通过 Category 组织规则，随后在 Project 中完成决策流编排；确认 Project 结构后才创建版本，并进入监控、审批、灰度与正式发布状态。

End-to-end REP journey

先完成 Rule、Category 与 Project 的策略结构，再生成可发布版本；版本通过观察与审批后逐步进入真实流量。

01 · Strategy setup创建规则、成组并编排 Project

Rule

创建规则

定义条件、判断逻辑与执行结果，形成可复用的最小策略单元。

策略人员

规则成组

按策略目标组织相关规则，明确优先级、命中关系与引用范围。

策略人员

Project

创建 Project（决策流）

将 Category 编排进主流与子流节点，确认执行顺序、依赖和流量关系。

策略人员

发布决策流确认 Project 结构后创建 Snapshot / Version，进入版本生命周期↓

02 · Version lifecycle监控、审批与发布

Created

版本已创建

确认变更内容、生效业务与基础配置。

策略人员

Monitoring

监控任务运行中

等待平台收集规则表现与影响数据。

系统执行

Monitored

结果可判断

检查命中、异常与潜在业务影响。

策略人员

Processing

等待审批

审批人基于完整上下文做出决定。

审批人

Approved

允许发布

选择灰度阶段、流量范围与观察条件。

策略人员

Grayscale

逐步生效

用真实流量验证安全与业务表现。

策略 × 业务

Enable

正式在线

标记生效版本，并保留创建与回滚入口。

系统执行

Exception paths

Skip monitor、Skip grayscale、审批拒绝与 Rollback 被视为高风险例外路径：保留专业用户的处理弹性，同时通过权限、风险提示、原因记录和审计降低捷径被滥用的可能。

01.8 · REP Solution / Rule Project

从最小可运行结构开始，把规则组织成可发布的决策流

Rule Project 是策略人员把 Rule 与 Category 组织为实际执行路径的画布。设计不要求用户面对空白空间从零理解节点系统，而是默认给出 Start node 与一个已连接的 Untitled node，让第一步从“如何开始”变成“这个节点应该承载什么决策”。

新建 Rule Project 默认画布，包含 Start node、已连接的 Untitled node、项目名称、Save 与 Create version 操作 — **Minimum viable decision flow** 默认结构只保留一个入口、一个待定义节点和一条连接；项目命名、保存、建版本与画布工具固定在稳定位置，让用户先理解决策流的基本语法，再逐步增加复杂度。

先给可运行骨架

Start node 与 Untitled node 默认连接，空状态本身已经示范节点和 Router 的关系。

保存不等于发布

Save 只持久化当前画布，并用明确反馈确认成功或失败，不制造已经上线的错觉。

版本是一次承诺

Create version 要求描述并带入完整节点内容，为后续验证与发布建立稳定快照。

01 · Project name

先进入画布，再在原位置完成项目命名

新项目先以 Untitled Rule Project 进入可编辑画布，避免命名表单阻断用户理解结构。点击标题即可进入行内编辑，提交或取消都发生在原位置，画布上下文始终保留。

DEFAULT使用可识别的临时名称，先让用户进入任务。
INLINE点击标题直接编辑，自动选中默认名称并减少清除成本。
REVERSIBLE确认与取消边界清楚，避免一次命名动作打断画布编排。

Rule Project 名称从 Untitled Rule Project 进入行内编辑、输入新名称、确认或取消的交互流程 — **Rename in context**临时名称、编辑、确认和取消形成完整闭环。

02 · More actions

把默认兜底与变更追溯放进受控入口，让画布聚焦编排

More Actions 承接使用频率较低、但会影响整条决策流的治理动作。Default decision 提供无规则命中时的明确兜底，Operation History 则记录修改前后内容、操作者与时间，让策略人员既能处理例外，也能追溯责任。

Rule Project More Actions 中 Default decision 与 Operation History 的完整交互说明 — **Default decision & operation history** 图内向下滚动查看默认决策编辑、保存反馈，以及变更前后内容的完整追溯记录；点击可打开高清原图。

Save 成功显示 All changes are saved，失败显示 Changes can not saved, retry later

03 · Save

Save 只确认画布已保存，不代表已经形成可发布版本

成功和失败反馈都直接说明当前草稿是否被系统接收。它与 Create version 被刻意拆开：前者保护工作进度，后者才把当前节点结构固化为后续验证、审批与发布可以引用的版本。

Create Version 弹窗，展示版本号、Creator、版本描述和节点内规则内容 — **Create an auditable version**描述意图，并在提交前审阅节点与规则内容。

04 · Create version

在形成版本之前，先确认意图与实际内容一致

Create Version 不只是输入版本描述。弹窗同时展开 Node / Category 及其 Rule 内容，让策略人员在提交前检查“我想发布什么”和“系统实际将固化什么”是否一致。

INTENT版本描述记录为什么形成这次版本，支持后续协作理解。
CONTENT节点、Category 与 Rule 结构在同一确认中可审阅。
HANDOFF创建成功后进入可验证、可审批、可发布的版本链路。

05 · Node status & connections

用节点状态与连接语法，把复杂决策流保持为一条可解释的路径

节点承担 Rule 或 Substream，Router 表达流向关系；hover 后出现的 Action bar 只提供当前节点允许的操作。用户通过“增加下级 / 同级节点”和明确连接点扩展结构，而不是随意拖动节点制造难以解释的拓扑。

Rule Project 节点状态、Router、增加上下级节点、Action bar、连接点和连接反馈的完整交互说明 — **Node grammar & connection** 图内向下滚动查看完整交互：Node / Router 状态、hover 操作、上下级添加、连接点与 Action bar；点击可打开高清原图。

From draft to governed flow

命名、治理动作、保存、版本化与节点编排构成五层清晰的操作边界。 设计让策略人员先理解画布与全局能力，再逐步固化可恢复、可审阅和可追溯的决策结构，把复杂画布转化为可以安全发布的决策资产。

01.9 · REP Solution / Release & Version Handoff

发布的不是一条孤立规则，而是包含这次变更的 Project 新版本

Rule 与 Rule Project 提供两个发布入口，但最终都必须形成同一种受治理对象：明确规则 Snapshot、目标 Project、基线版本与节点关系的新 Project Version。创建成功只完成版本交接，后续仍需通过 Monitor、审批与灰度才能进入真实流量。

Two entry points, one version contract

从 Rule 发起，适合把一项明确变更快速带入相关 Project；从 Project 发起，适合在完整节点上下文中统一检查多条规则。 两条路径共享同一份版本契约，避免“规则已发布”和“决策流已上线”被误认为同一件事。

01 · Rule-centered release

先选择进入版本的规则 Snapshot，再明确目标 Project 与基线

Release Rule 将 New / Edited 状态、Rule Version、Updater、Category 变化和 Snapshot 动作放在同一张表中；下一步再选择目标 Project 及当前 In use 版本。用户因此能在提交前回答：哪些变更会被带入、它们将基于哪个线上事实形成新版本。

Release Rule 弹窗，先选择规则与 Snapshot，再选择目标 Project 和基线版本 — **Release rule into a governed project version** 规则选择、Category 变化、Snapshot 状态与目标 Project 基线同屏，发布前先确认完整影响范围。

02 · Explicit handoff

创建成功只代表新版本已经生成，下一步仍是验证而非上线

成功弹窗明确说明新的 Project Version 已包含本次规则变更，同时将主行动指向 Create monitor task。Close 保留退出路径，Monitor 则承接推荐路径，用真实表现数据为后续审批与发布建立证据。

规则发布成功弹窗，确认新 Project Version 已创建，并引导创建 Monitor Task — **Created, not live** 成功反馈同时说明结果与下一步，避免用户把“版本已创建”误解为“规则已在线”。

03 · Project-centered version

从 Project 发起时，在节点上下文中选择、补齐并比较规则 Snapshot

Create Version 按 Node 展开当前决策流中的规则，支持搜索、筛选 New / Edited 内容，并为每条规则选择已有 Snapshot 或即时创建 Snapshot。Compare 在最终创建前提供跨节点复核，让 Project 版本记录的不是抽象编号，而是一份可解释的内容集合。

Rule Project Create Version 弹窗，按节点选择或创建规则 Snapshot，并支持比较后创建版本 — **Assemble the version in project context** 节点、规则状态、Snapshot 与 Compare 共同定义这次 Project Version 实际包含什么。

Release confidence

发布信心来自三次确认：内容被选对、依赖被说清、上线前仍有验证。 双入口提升专业用户的工作效率，而统一的 Project Version、Monitor 与审批链路确保任何入口都不会绕开风险治理。

01.10 · REP Solution / Pre-release Monitor

让新版本先在小流量中产生证据，再决定是否进入审批

Monitor Task 把版本发布前的验证从一次主观确认，转化为限定时间窗口内的并行观察。策略人员不仅要看到新版本跑完了，还要判断决策分布是否合理、与线上版本差异发生在哪里，以及系统和特征链路是否健康。

先定义证据

明确运行时长、观察因子与是否输出决策结果，避免任务结束后才发现数据不足。

再对照线上

从总体决策到 Rule Hit 逐层比较，找到新旧版本产生差异的真实位置。

最后检查健康度

把引擎、Feature 与 System Error 纳入审批前检查，避免用异常数据支持发布。

01 · Create monitor task

从目标版本进入 Monitor，空状态直接给出下一步

版本列表保留 Monitoring 与 In use 状态，右侧面板在没有结果时不制造空洞仪表盘，而是解释为什么暂无数据，并将 Create monitor task 作为唯一主行动。入口与目标版本同屏，减少“我正在验证哪个版本”的不确定。

Rule Project Version Management 中打开 Monitor 面板并创建 Monitor Task — **Start from a known version** 版本状态、验证入口与空状态行动同屏，任务从明确对象开始。

02 · Configure evidence

创建任务时先定义观察窗口、决策输出与关键 Factor

配置弹窗用 15 mins、30 mins、2 hrs、4 hrs、1 d 与 Custom 提供渐进式时间选择，同时明确是否输出决策结果，并允许添加 Factor。它把“跑一次看看”转化为一份可复述的验证计划：观察多久、看什么、最终比较什么。

Monitor Task 创建弹窗，配置运行时长、决策结果输出和 Factor — **Define the observation contract** 时长、结果输出与 Factor 共同决定任务完成后能否支持发布判断。

03 · Monitoring

运行中持续解释已执行多久、何时结束，以及用户仍能做什么

运行状态展示版本信息、监控时间、已运行时长、预计结束时间和结果刷新频率，并保留 Stop。加载反馈不再只是一个旋转图标，而是让策略人员知道系统仍在工作、数据何时出现，以及必要时如何停止任务。

Monitor Task 运行中，显示运行进度、结束预期、结果刷新频率和 Stop 操作 — **Progress with an exit** 运行时间、结束预期、刷新节奏与停止能力共同降低等待焦虑。

From task state to decision evidence

Monitor 完成不是流程终点，而是审批判断的起点。 结果页需要从总体分布逐层下钻到线上差异、规则命中与错误健康度，让“是否可以发布”有可复核的证据，而不是依赖一次成功状态。

04 · Monitor results

先建立整体基线：样本量、Factor、最终决策与 Risk Action

Overview 从 Total volume 开始，依次呈现 Factor results、Final decision results 与 Risk action results。策略人员先确认样本是否足够，再核对 Pass、Review、Block 的决策分布，最后检查风险动作是否符合支付场景预期，为 Submit approval 建立完整基线。

Monitor Result Overview，展示总量、Factor 结果、最终决策与 Risk Action 分布 — **Read volume before outcome** 图内向下滚动查看完整结果：样本量、Factor、最终决策、Risk Action 及审批入口。

05 · Compare to online

把新版本与线上版本放在同一尺度上，差异才能被判断

开启 Compare to online version 后，Factor、Final decision 与 Risk Action 使用成对色阶呈现 Monitor / Online 数值，并分别保留请求级差异。策略人员既能看总体偏移，也能回到事件、支付方式、业务线和具体动作定位分歧。

Monitor Version 与 Online Version 的 Factor、最终决策、Risk Action 和请求级差异对比 — **Compare distribution, then inspect disagreement** 图内向下滚动查看决策与 Risk Action 的总体分布及请求级差异，再定位到具体业务事件。

06 · Rule hit comparison

沿 Node、Category 与 Rule 下钻，找到差异由哪条策略产生

Rule Hit 将监控版本与线上版本的命中率并列，并用 Difference 标识异常偏移。按 Node 与 Category 保留上下文后，策略人员不必从总体决策反向猜测原因，而能直接定位到造成变化的具体 Rule。

Rule Hit 页面按 Node、Category 和 Rule 对比 Monitor 与 Online 命中率 — **Trace the delta to a rule** 从节点结构保留策略语境，用命中率差异快速定位需要复核的规则。

07 · Error notice

在提交审批前，先确认引擎、Feature 与系统链路是否可信

Error Notice 先汇总决策引擎、Feature 与 System 的 Normal / Abnormal 状态，再展开 Feature Error Ratio。策略人员既能判断异常发生在哪一层，也能识别哪些特征正在持续产生错误，避免把链路问题误判为规则效果并据此推进发布。

Monitor Error Notice 页面，展示决策引擎、Feature 与 System Error 状态，以及 Feature Error Ratio — **Do not approve on broken evidence** 系统健康状态与特征错误比例同屏，先保证证据可信，再进入 Submit approval。

Evidence before approval

发布前必须回答三个问题：样本是否足够、行为差异是否可解释、运行链路是否健康。 Monitor Task 用 Overview、Online Compare、Rule Hit 与 Error Notice 依次回答这三个问题，把小流量观察沉淀为可审批、可追溯的发布证据。

Payment Verification · Consumer

验证中心

第二部分转向 C 端支付用户。验证不是后台审核工具，而是在高风险支付与异常交易场景中增加必要确认，降低资金损失，同时用清晰解释、可完成的动作和可恢复的结果建立支付安全感。

用户：C 端支付用户目标：提升支付安全度与安全感范围：验证 → 保障 → 申报 → 恢复

02.1 · Verification Experience

在增加安全校验时，也让用户知道为什么、如何完成、资金如何被保护

风控验证发生在用户最敏感的支付时刻。体验需要同时守住三件事：只在必要场景增加摩擦，用用户能理解的方式说明原因，并在异常发生后提供明确的资金保障与恢复路径。

01必要验证根据风险场景触发恰当的验证强度，不把所有用户都当作风险用户。

02清晰解释说明验证与资金安全的关系，但不暴露可能被绕过的内部策略。

03结果可恢复失败、异常或未授权交易都有明确的下一步、处理预期与补救入口。

01 · Payment PIN

同一个验证动作，在每个状态都回应用户最关心的问题

PIN 验证发生在支付即将完成的敏感时刻。状态设计从“我该做什么”逐步转向“系统正在做什么”“结果是什么”与“还能如何恢复”，既隐藏真实密码，也把等待、剩余机会和安全限制讲清楚。

Payment PIN 初始状态，显示六位密码输入位、忘记密码入口与数字键盘 — 01 · Ready

初始状态

聚焦唯一任务，保留 Forgot PIN 作为无法继续时的恢复出口。

Payment PIN 输入中状态，已输入位以圆点隐藏 — 02 · Entering

输入中

用圆点即时反馈输入进度，不暴露数字内容，并允许逐位删除。

Payment PIN 验证中状态，输入完成后显示加载反馈 — 03 · Verifying

验证中

输入完成后锁定操作并给出明确进度，避免重复提交或误以为页面失效。

Payment PIN 验证成功状态，显示 Verified 与安全盾牌图标 — 04 · Verified

验证成功

用短暂而明确的成功确认闭合验证，再把用户带回原支付任务。

Payment PIN 验证失败但仍可重试，提示剩余尝试次数 — 05 · Retry

验证失败，仍可尝试

清空错误输入并告知剩余次数，让用户理解风险正在升级但仍有恢复空间。

Payment PIN 多次验证失败后暂时禁用，说明安全原因与可再次尝试的时间 — 06 · Locked

验证失败，暂无剩余次数

终止继续输入，说明临时限制与恢复时间，避免安全拦截变成无解释的死路。

输入始终私密只呈现完成进度，不展示、回显或记录真实 PIN。

反馈匹配风险等级从处理中性反馈到错误提醒，再到锁定说明，强度逐级增加。

失败必须可恢复仍可重试时说明机会；机会耗尽时说明原因、等待时间和后续出口。

02 · One-time password

让一次性验证码既能证明身份，也不会制造新的不确定

OTP 验证把安全确认延伸到用户持有的手机号。界面需要保护接收方信息、说明验证码已发送到哪里，并管理倒计时、重发与错误次数，让外部消息链路中的等待仍然可理解、可恢复。

OTP 初始状态，显示脱敏手机号、四位验证码输入框、重发倒计时与数字键盘 — 01 · Sent

初始状态

确认验证码发送至脱敏手机号，并用倒计时解释何时可以重新获取。

OTP 输入中状态，验证码逐位显示且重发入口可用 — 02 · Entering

输入中

逐位反馈输入位置；倒计时结束后开放 Resend，避免用户反复请求验证码。

OTP 验证中状态，验证码提交后显示加载反馈并暂停输入 — 03 · Verifying

验证中

提交后暂停输入和重发，用清晰的处理中反馈防止重复验证。

OTP 验证成功状态，显示 Verified 与安全盾牌图标 — 04 · Verified

验证成功

明确确认手机号验证完成，再返回被暂时中断的支付流程。

OTP 验证失败但仍可重试，验证码输入框标红并提示剩余尝试次数 — 05 · Retry

验证码错误，仍可尝试

保留错误码帮助校对，同时提示剩余机会与 Resend，避免只告诉用户“失败”。

OTP 多次验证失败后暂时禁用，说明安全原因与可再次尝试的时间 — 06 · Locked

验证失败，暂无剩余次数

停止继续输入与重发，说明临时限制和恢复时间，阻断暴力尝试但保留预期。

接收方信息最小披露只展示足够用户确认的脱敏手机号，不扩大个人信息暴露。

重发节奏可理解倒计时解释等待，Resend 只在允许时出现，减少重复消息与焦虑。

错误预算透明说明剩余次数；耗尽后暂停验证并给出恢复时间，平衡安全与可达性。

03 · Card verification

用用户掌握的卡片信息确认持卡关系，同时控制敏感信息暴露

卡验证要求用户补全卡号，以确认当前操作人与已绑定卡片之间的关系。界面先用卡组织与尾号帮助用户确认验证对象，再通过格式化输入、按钮状态、错误次数和临时锁定，把高敏信息输入变成可判断、可中止的安全动作。

卡验证初始状态，展示 Mastercard 卡组织、卡片尾号、完整卡号输入框与禁用的 Next 按钮 — 01 · Ready

初始状态

用卡组织和尾号确认目标卡片；输入未完成前保持 Next 禁用。

卡验证输入完成状态，完整卡号按四位分组并启用 Next 按钮 — 02 · Complete

输入完成

按四位分组降低校对成本，提供一键清除，并在格式完整后启用下一步。

卡验证处理中状态，输入区域暂时禁用且 Next 按钮显示加载反馈 — 03 · Verifying

验证中

提交后冻结输入与清除操作，按钮原位显示进度，避免重复请求。

卡验证成功状态，显示 Verified 与安全盾牌图标 — 04 · Verified

验证成功

清楚确认卡片验证完成，并继续原本被风控暂停的支付动作。

卡号验证失败但仍可重试，输入框标红并提示剩余尝试次数 — 05 · Retry

卡号错误，仍可尝试

错误与输入框就近关联，明确剩余次数，并停用 Next 直到信息被修改。

卡号多次验证失败后暂时禁用，说明安全原因与可再次尝试的时间 — 06 · Locked

验证失败，暂无剩余次数

终止继续猜测卡号，说明临时限制与恢复时间，保护账户和卡片安全。

先确认验证对象卡组织与尾号帮助用户识别卡片，不提前暴露完整账户信息。

敏感输入可控分组降低输入错误，一键清除提供控制感，提交后不保留非必要信息。

限制需要有解释错误提示与尝试次数逐步升级；耗尽后说明安全原因和恢复时间。

04 · Biometric verification

把生物识别留在支付语境里，并为识别失败准备可信的退路

本组以 iOS Face ID 为例，展示生物识别如何直接发生在订单确认页上，让用户始终知道自己正在授权哪笔支付。实际方案同时支持 Android 的系统级人脸、指纹等生物识别能力，并沿用各平台熟悉的原生反馈：成功后无缝继续；偶发失败允许重试；持续失败则切换到其他验证方式，避免把生物识别变成唯一入口。

订单确认页上的人脸识别中状态，Face ID 图标覆盖在支付场景之上 — 01 · Recognizing

识别中

保留订单金额、支付方式与下单按钮，让用户始终理解本次验证授权的对象。

订单确认页上的人脸验证成功状态，Face ID 图标显示勾选反馈 — 02 · Verified

验证成功

以系统熟悉的成功反馈确认身份，不增加额外完成页，直接继续支付。

人脸未识别提示，提供 Try Face ID Again 与 Cancel 操作 — 03 · Retry

未识别，允许重试

将偶发识别失败视为可恢复状态，主操作直接重试，同时允许取消本次授权。

人脸未识别提示，提供 Change verification method 与 Cancel 操作 — 04 · Fallback

持续失败，切换验证方式

不再要求重复尝试当前生物识别，转向 PIN、OTP 或卡验证，保证安全流程仍然可完成。

验证不脱离支付语境金额、订单与支付方式持续可见，让用户知道自己正在授权什么。

优先使用系统反馈沿用设备熟悉的生物识别状态，减少额外解释与学习成本。

生物识别不是死路一次失败可重试，持续失败提供替代验证，兼顾安全、可达性与完成率。

05 · Liveness verification

在打开镜头之前建立预期，在自动采集过程中持续给出方向

活体验证不只是一次自拍，而是一段包含环境准备、相机授权、画面质量判断、自动捕捉与结果恢复的连续体验。流程先帮助用户创造可识别条件，再说明相机用途，并用实时边框和状态文案降低“是否拍到了、还要等多久”的不确定。

活体验证准备页，提示正对镜头、移除眼镜帽子口罩并确保光线充足 — 01 · Prepare

拍摄准备

在开启相机前说明入框、遮挡物和光线要求，先减少可预防的识别失败。

活体验证相机授权页，说明相机用途并提供 Access camera 操作 — 02 · Permission

请求相机权限

在权限请求前说明为什么需要镜头、将拍摄什么，以及权限可在系统设置中修改。

活体验证取景页，引导用户将面部放入椭圆框并说明照片将自动拍摄 — 03 · Position

将面部放入框内

用单一轮廓约束距离与位置，并提前告知照片会自动拍摄，不要求用户寻找快门。

活体验证自动捕捉状态，绿色边框确认入框并提示 Hold steady — 04 · Capturing

保持稳定，自动捕捉

边框变绿确认构图合格，短句提示保持稳定，让用户知道系统已经接管拍摄。

活体验证照片已捕捉并处理中，轮廓进度与文案确认自拍已获取 — 05 · Processing

已捕捉，处理中

明确照片已经拍到，用户无需继续保持姿势；进度反馈承担等待解释。

活体验证成功状态，模糊人脸背景上显示 Face scan successful — 06 · Verified

活体检测成功

用明确结果结束采集，并模糊背景中的面部画面，降低结果页的隐私暴露。

活体验证无法识别人脸，提供 Retake selfie 操作 — 07 · Retake

未识别，重新拍摄

把失败转化为直接可执行的 Retake selfie，不要求用户自行判断如何回到拍摄页。

活体验证多次失败后停止尝试，提示稍后再试并提供 Got it 操作 — 08 · Locked

尝试耗尽，稍后再试

停止重复采集，清楚说明当前无法继续，避免用户在高敏验证中无限重拍。

先改善采集条件在相机开启前解释光线、遮挡与构图要求，从源头降低无效采集。

权限与自动拍摄透明说明相机用途和自动捕捉机制，实时反馈当前画面是否达到要求。

敏感失败不过度循环一次失败提供重拍；持续失败停止采集，并允许稍后或改用其他验证方式。

Design improvements

把验证中的卡点，转化为可以继续完成的安全路径

验证能力上线后，我继续从不可用、失败与退出等边缘场景检视体验。改进并不是降低安全要求，而是在相同风险强度下，为用户提供更清楚、更连续的完成方式。

Improvement 01 · Method switching

当前验证方式不可用时，用户能否安全地切换？

可以。 PIN、OTP 与卡号验证均增加 Verify another way，让用户不必退出当前支付流程；选择面板只呈现当前账户、设备与风险策略允许使用的验证方式。

只展示真实可用的方式根据设备能力、账户绑定状态与渠道可达性动态筛选候选项。

切换不等于降低风险强度备选方式仍需满足本次交易对应的安全等级，不能成为绕过校验的入口。

保留当前支付上下文切换过程中不丢失订单、金额与风险状态，减少退出后重新发起的不确定。

Post-launch impact 用户验证通过率提升，PSR 同步增长

可切换路径减少了单一验证方式不可用造成的中断，让更多用户完成安全校验，并进一步改善 Payment Success Rate。

Payment PIN 验证页增加 Verify another way 验证方式切换入口 — 01 · PIN

重置之外也能切换

Verify another way 与 Reset 并列，不必先退出 PIN 验证。

OTP 验证页在重发倒计时旁增加 Verify another way 入口 — 02 · OTP

等待期间保留替代路径

验证码未送达时可直接切换，不必反复等待或重发。

卡号验证页在 Next 按钮下方增加 Verify another way 入口 — 03 · Card

主操作之外保留出口

入口靠近 Next 按钮，既不抢夺主任务，也不会被忽略。

验证方式选择面板提供生物识别、WhatsApp 或短信验证码和卡号验证 — 04 · Selection

统一呈现当前可用方式

集中展示生物识别、WhatsApp／短信与卡号验证。

Improvement 02 · Verification readiness

当用户缺少可用验证方式时，能否在风险发生前主动补齐？

可以。 我们将同一套信息补全组件复用在订单完成、提现完成、退款完成、进入 TikTok Pay，以及 Buy Now, Pay Later 服务页面等高相关节点。在取得明确同意的前提下，引导用户保存手机号、设置 PIN 或启用设备支持的生物识别。

选择自然且高意图的触点优先出现在交易完成与支付服务入口，不打断正在进行的核心任务。

只补当前账户缺失的信息同一组件根据账户状态和设备能力，动态呈现手机号、PIN 或生物识别引导。

说明用途并允许跳过解释信息如何用于支付验证、如何管理与存储，让主动补全建立在透明同意之上。

Post-launch impact 可验证信息覆盖率大幅提升

风控验证因此获得了更丰富的候选方式，降低单一验证渠道不可用时的支付中断。

保存手机号用于支付 OTP 验证的引导组件 — 01 · Phone

补全 OTP 触达基础

说明手机号用于支付验证，并明确隐私与后续管理方式。

设置 PIN 以保护支付的引导组件 — 02 · PIN

建立账户级验证凭证

把设置价值与后续可修改性讲清楚，降低创建顾虑。

iOS 设备启用 Face ID 支付验证的引导组件 — 03 · iOS Face ID

适配面容识别设备

强调信息仅保留在设备端，并可随时关闭。

iOS 设备启用 Touch ID 支付验证的引导组件 — 04 · iOS Touch ID

适配指纹识别设备

沿用同一信息结构，根据硬件能力替换方式与视觉。

Android 设备启用系统级生物识别支付验证的引导组件 — 05 · Android

统一表达生物识别能力

以平台通用术语覆盖人脸或指纹，保持跨设备一致。

02.2 · Payment Method Appeal

当支付方式被风控限制后，让用户通过验证所有权重新恢复使用

支付方式申诉不是孤立的客服流程，而是风险限制之后的恢复机制。当前方案覆盖 Apple Pay、Google Pay 与信用卡／借记卡（CCDC）：用户从受限支付方式直接进入申诉，通过补充关联卡片与持卡人身份证明，帮助系统区分真实风险与误判，并在审核通过后恢复该支付方式。

限制可理解

说明该支付方式暂时不可用，以及验证所有权后可能恢复。

入口可发现

在受影响场景中提供直接、连续的申诉入口。

举证有引导

按支付方式明确关联卡片与持卡人身份证明，减少无效提交。

进度有预期

说明当前状态、处理时间和用户是否还需行动。

恢复并回流

审核通过后恢复支付方式，并将有效申诉沉淀为误判信号。

Supported methods

同一套申诉骨架，针对不同支付方式替换品牌与凭证说明

三种介绍页共享安全说明、支付方式确认、两步举证任务与扫描入口；钱包品牌、关联卡片名称和顶部插图按 Apple Pay、Google Pay 与 CCDC 分别适配，既保持体验一致，也帮助用户确认正在恢复哪一种支付方式。

Apple Pay 支付方式申诉介绍页，要求扫描关联卡片和持卡人身份证明 — 01 · Apple Pay

验证钱包关联卡片

清楚标识 Apple Pay，并引导提交关联卡片与持卡人 ID 两项证明。

Google Pay 支付方式申诉介绍页，要求扫描关联卡片和持卡人身份证明 — 02 · Google Pay

复用钱包申诉结构

保持任务与操作一致，仅替换品牌标识和关联卡片描述。

信用卡或借记卡支付方式申诉介绍页，要求扫描支付卡片和持卡人身份证明 — 03 · CCDC

直接验证卡片所有权

针对信用卡／借记卡展示卡片尾号与持卡人姓名，强化申诉对象确认。

Appeal evidence

先证明支付卡所有权，再完成持卡人身份验证

完整申诉由支付卡证明与持卡人 ID 两类材料组成。默认流程直接调用相机扫描实体卡，同时支持上传卡片图片或虚拟卡 Bank statement；卡片材料完成后，再引导用户扫描证件正反面，在提交前逐张确认清晰度。

A · 默认路径：实体卡相机扫描

取景 → 确认 → 上传 → 完成

实体卡扫描页提示将卡片完整放入取景框并遮盖 CVV — 01 · Frame

先建立可用的拍摄条件

明确正反面、裁切、模糊与反光要求，并提醒遮盖 CVV。

实体卡正反面拍摄完成后的照片确认页 — 02 · Review

提交前允许确认与重拍

把质量判断留给用户，减少上传后才发现证据不可用。

实体卡照片上传中，页面锁定操作并显示 Uploading 状态 — 03 · Uploading

上传期间防止重复操作

锁定使用与重拍按钮，用明确进度反馈承接等待。

实体卡照片上传成功并显示 Uploaded 反馈 — 04 · Uploaded

即时确认材料已收到

成功反馈结束当前步骤，避免用户重复提交相同照片。

B · 替代路径：上传图片或 Bank statement

适用于虚拟卡或实体卡不在手边

卡片验证方式选择页，默认选择上传实体卡正反面图片 — 01 · Choose

先确认用户持有的卡类型

默认实体卡图片，同时明确提供虚拟卡选项。

手动上传实体卡正反面图片并说明格式、大小和质量要求 — 02 · Card photos

允许从相册补充卡片图片

分别上传正反面，并复用遮盖 CVV 与画质要求。

卡片验证方式选择页选择虚拟卡，并提示准备卡片账单 — 03 · Virtual card

虚拟卡转向账单证明

不要求不存在的实体卡，直接说明下一步所需材料。

上传虚拟支付卡 Bank statement，并说明卡号尾号、日期和文件要求 — 04 · Statement

把账单标准前置说明

要求匹配卡号尾号、近三个月且未加密，减少审核退回。

C · 持卡人证件扫描上传

准备与授权 → 正面 → 反面 → 上传完成

证件扫描准备页说明正反面拍摄要求、禁止使用的证件以及隐私授权 — 01 · Prepare

先说明质量与授权要求

解释不可裁切、模糊或反光，并在进入扫描前取得数据处理同意。

相机取景框引导用户拍摄身份证件正面 — 02 · Front capture

正面放入取景框

明确当前需要 Photo page，并允许从相册选择已有图片。

证件正面拍摄完成后确认信息清晰可读或重新拍摄 — 03 · Front review

确认正面信息可读

提交前提供 Confirm 与 Retake，减少低质量材料进入审核。

相机取景框引导用户拍摄身份证件反面 — 04 · Back capture

连续进入反面拍摄

保留相同取景和帮助入口，只切换当前所需证件面。

证件反面拍摄完成后确认信息清晰可读或重新拍摄 — 05 · Back review

确认反面信息可读

沿用正面确认逻辑，让两面材料在上传前达到一致质量。

证件反面照片上传中并禁用重复操作 — 06 · Uploading

上传时锁定重复操作

使用上传反馈承接等待，避免重复确认或重拍打断提交。

证件正反面上传完成并显示 Uploaded 成功反馈 — 07 · Uploaded

完成申诉材料上传

明确证件已收到，与前面的卡片证明共同构成完整审核材料。

D · 审核结果与支付方式恢复

已提交 → 重新提交／追加材料 → Inbox 通知恢复

申诉材料已提交并进入审核，通过时间线说明当前状态和预计审核时长 — 01 · Under review

已提交，进入审核

用时间线确认材料已收到、预计审核时长与后续通知渠道。

卡片照片因 CVV 暴露、证件因模糊而同时需要重新提交 — 02 · Resubmit

多项材料需要重提

逐项指出 CVV 暴露与证件模糊问题，让用户只修正不合格材料。

仅卡片照片因模糊或反光需要重新提交，证件材料保留 — 03 · Card issue

仅重提卡片照片

证件合格时不要求重复提交，只返回不合格的卡片材料。

仅持卡人证件因模糊或反光需要重新提交，卡片材料保留 — 04 · ID issue

仅重提持卡人证件

明确模糊或反光原因，并直接返回证件扫描路径。

审核需要更多信息时要求追加持卡人证件，不重复已有卡片步骤 — 05 · More evidence

追加所需证明

审核需要更多信息时只补充新增材料，不推翻已完成步骤。

Approved state · Silent recovery

申诉通过后不增加额外成功页：支付方式在收银台直接恢复为可用状态，并通过 Inbox 通知审核结果。用户在下一次支付时自然感知恢复，避免重复确认与流程打断。

Risk Sensing · Operations

风险感知平台

第三部分服务风控运营人员：确认线上异常的时间与影响范围，补齐对象、关系和行为证据，再把问题交给策略团队处理并复查调整后的表现。

用户：风控运营人员目标：发现风险并推动策略优化闭环：发现 → 归因 → 反馈 → 复验

03.1 · Operational Risk Loop

风险监控、对象分析与关系／行为证据如何串联

运营先确认异常窗口、阈值与规则上下文，再沿商户、关系网络和主体行为逐层分析。交接给策略团队的信息包括受影响对象、关联路径、关键行为、影响范围与责任人。

01感知异常发现趋势突变与指标偏移

02确认规则核对阈值、触发与责任人

03商户分析判断经营与资金风险状态

04关系分析识别风险连接与团伙网络

05行为分析还原单体与群体行为序列

发现与确认

识别异常窗口，核对真实值、阈值、影响量级与规则上下文。

对象下钻

从商户经营、授信、资金与风险状态判断问题落在哪类主体。

关系与行为归因

结合关系网络和行为序列，补齐异常的传播路径与关键证据。

反馈并复验

将洞察带回 REP 优化规则，并持续观察调整后的风险与业务表现。

风险分析页展示规则实时运行趋势、风险表现、影响数据和事件明细 — **Risk analysis** 进入单个风险问题后，以实际值、预设值和历史均值定位异常窗口，并将风险指标、交易影响与事件明细组织在同一条分析路径中。

定位异常窗口

在同一时间轴比较 Actual、Preset 与 Average，识别指标何时越过阈值。

判断风险表现

并列查看黑产率及关联特征，判断异常来自单一指标还是一组风险信号。

核对影响与事件

结合交易金额、拒绝率、用户量与事件决策明细，确认真实影响范围。

More info · Related context

补齐当前风险问题背后的规则与协作信息

风险数据只能说明发生了什么。点击 More info 后，运营还能确认问题所属业务线、告警与触发维度、真实值和阈值、触发时间、规则更新时间，以及需要同步的相关人员，避免脱离规则上下文做判断。

RULE业务线、告警维度与告警值说明问题由哪条规则、哪个切面触发。
THRESHOLD真实值、触发值与请求量帮助运营判断异常程度及样本规模。
OWNER触发时间、规则更新时间与 Push to 人员明确后续协作对象。

风险分析页打开 More info 抽屉，展示规则、告警维度、阈值、触发时间和协作人 — **More info**在不离开分析页的情况下补充当前风险问题的规则上下文。

Merchant analysis · Object context

先判断商户处在什么经营与资金状态

指标异常被确认后，第一步不是马上归因，而是回到承载风险的商户对象。通过统一画像把经营、授信、额度、逾期、退款、资金与历史处置放在同一上下文中，运营可以快速判断这是短期波动、持续恶化，还是已被处置但仍在传播的风险。

从商户 ID 到一张可判断的风险全景

页面以基础信息和核心额度为锚点，再向下展开经营交易、退款、账户资金、现金流、逾期与历史调整记录，减少跨系统查证。

IDENTITY国家、类型、等级、经营品类与入驻时间说明对象是谁。
CAPACITY授信、可用额度、定价与打款比例说明其资金承载能力。
RISK逾期、退款、余额和历史处置说明风险是否已经影响经营。

商户风险画像汇总基础信息、授信、额度、逾期、交易、退款和资金情况 — **商户全景画像**将分散的经营与资金信号收拢为一个可判断的对象上下文。

多个商户的额度账户状态、逾期状态和历史处置信息对比 — **状态对比**把暂停、冻结、关闭、无逾期与有逾期等状态并列，帮助运营识别风险状态组合及处置是否一致。

Graph analysis · Relationship evidence

再判断风险是否通过关系网络聚集与传播

单个对象的异常不一定等于孤立风险。关系分析允许运营围绕用户、邮箱、设备、手机号等节点逐跳展开网络，结合黑产率、欺诈率、逾期率与关系密度，识别共享要素、团伙聚集和风险传播路径。

先控制查询复杂度，再逐层扩展证据

首次进入时通过场景示例说明一至四跳、定制视图与路径查询的差异，避免运营直接拉取过大的关系图，也让不同经验水平的用户知道该从哪里开始。

SCOPE业务线、场景、节点类型与时间范围限定查询边界。
DEPTH跳数与简化程度控制关系深度和信息噪声。
PATH路径查询聚焦两个对象之间最值得验证的关联。

关系分析查询引导展示一跳至四跳、定制视图和路径查询 — **关系查询引导**把复杂图分析拆成可理解、可控制的查询步骤。

关系网络画布展示节点、关系指标、筛选器、图例和缩略图 — **网络概览**通过颜色、标签和总览指标识别风险节点、关系密度与异常聚集。

关系网络节点详情展示用户属性、风险标签和一跳关联节点 — **节点证据**从图上的异常点进入属性与一跳关联，验证共享身份、设备或联系方式。

Entity behavior · Sequence evidence

最后用行为序列回答“风险是怎样发生的”

对象画像与关系网络告诉运营“谁值得关注”，行为分析则把注册、登录、账户操作、绑卡和交易重新放回时间轴。RDC 同时支持单体追踪与多体对比：前者还原个体路径，后者识别群体在相近时间窗口中的趋同行为。

C1 · 单体

单体行为分析：还原一个主体的完整动作链

按时间排列关键动作，结合高频注册、高频交易和行为标签快速定位异常节点；点击节点继续查看请求、设备、IP、国家、身份与风险标签，判断一次动作是孤立事件还是连续风险路径的一部分。

单体行为序列按时间展示注册、登录、账户操作、绑卡和交易动作 — **单体行为序列**在一条时间线上还原关键动作、频次、标签与相邻事件。

单体动作信息弹窗展示动作类型、风险标签、请求、设备和 IP 信息 — **动作上下文**点击序列节点查看请求级信息，确认异常发生的设备、IP 与身份环境。

单体聚合动作详情展示动作数量、标签、设备、IP 和交易明细 — **聚合证据**当一个节点包含多次动作时，继续展开共同属性与逐笔明细。

C2 · 多体

多体行为序列对比：寻找群体趋同与异常时间窗口

将多个主体的注册、登录、账户操作、绑卡与交易按统一时间轴对齐，用气泡大小和颜色比较用户量、交易金额与请求量。运营既能发现某个时间窗口内的群体聚集，也能回到事件列表确认具体主体、动作与发生时间。

从群体形态回到可核验事件

图形负责暴露趋同模式，事件表负责验证模式是否由真实风险主体构成。两者联动避免只凭“图看起来异常”就下结论。

PATTERN识别动作在相近时间段内是否集中出现。
VOLUME比较用户数、请求数和交易金额的异常放大。
VERIFY回到主体 ID、动作类型和时间明细验证样本。

多体行为序列以气泡图比较多个动作类型在时间轴上的用户数、金额和请求数 — **多体序列对比**用统一时间尺度暴露群体行为的集中、放大与趋同。

多体行为序列下方展示主体、动作类型、时间和操作明细表 — **事件核验**在群体模式下方保留逐条事件证据，让运营从聚合判断回到可追溯对象。

分析终点是一个可交接的问题包

对象证据说明谁受影响，关系证据说明风险如何连接，行为证据说明风险怎样发生；再与异常窗口、规则阈值、影响范围和责任人合并，形成可交给策略团队继续判断、优化与复验的完整上下文。

Shared · Scale Across Businesses

跨业务复用的是对象、状态与发布规则，不是页面模板

跨业务复用集中在规则对象、发布标准、权限、状态和异常恢复；场景、指标、市场与风险容忍度继续由各业务配置。这样既减少重复设计，也不会把不同产品强行塞进同一套页面。

TikTok内容、直播、电商与创作者支付场景

Resso音乐订阅与数字内容支付场景

Melolo内容消费、虚拟权益与本地支付场景

Pico硬件、账户与全球消费场景

所有需要支付服务的字节海外产品通过一致的信息结构、状态语言和发布机制，逐步扩展到不同产品形态与市场。

Shared · Value & Measurement

如何判断平台体验是否有效

风控与资损数据不适合公开，因此这里不使用无法核验的结果数字。项目评估围绕四组内部指标展开：策略发布效率、支付验证表现、异常处理周期与申诉恢复。

Evaluation framework

效率指标必须和风险控制、正常用户影响一起看

单看发布速度会掩盖误拦截或变更风险。评估时需要同时观察策略交付、风险损失、验证完成情况与申诉恢复，避免用单一效率指标代表整体质量。

策略效率配置、验证与发布耗时Release lead time

支付安全验证完成、风险拦截与资金损失Verification / risk loss

运营处理异常发现、归因与反馈所需时间Detection to action

用户恢复申诉完成、处理时效与恢复率Appeal resolution

Shared · Reflection

这组项目改变了我处理复杂平台问题的方式

专业工具的“简单”来自清晰，而不是删减能力

面对复杂规则，设计需要建立层级、上下文和渐进披露，让专家保留表达能力，也让协作角色能够快速理解。

状态机本身就是信息架构

高风险链路中的状态不仅说明系统进度，还要说明当前责任人、下一步和失败后的恢复方式。

平台化设计要统一决策骨架，而不是统一所有界面

核心旅程、发布标准与状态语言保持一致；业务特有的场景、指标与合规要求则应保留配置空间。

验证结果与线上异常必须回到策略团队

验证和风险分析如果停在各自页面，策略人员仍然看不到规则的真实影响。反馈需要带着对象、版本和时间上下文回到 REP。

RiskFoundation

Three workflows support one risk decision lifecycle

One decision foundation, three distinct user groups

Strategy authors define decisions, customers complete required checks, and operators investigate live anomalies

Risk strategist

Payment customer

Risk operations

A governed path from rule authoring to release

The release risk came from missing context, not missing features

Keep identity, dependency and release status visible at each handoff

Protect the payment without making the customer guess

Each state answers four questions: why, what, how long and what next

Move from an anomaly to evidence a strategy team can use

A five-step path keeps monitoring and investigation connected

Reuse the decision contract, not a page template

This case study does not publish sensitive loss or enforcement data

What changed in how I design complex operational products

四类能力如何共同支持一次风险决策

Risk Foundation 如何连接策略、验证与运行反馈

一套决策底座多种业务语境

三类用户在同一条风险链路中分别完成什么

策略人员写规则，用户完成必要验证，运营把异常反馈给策略团队

风控策略人员

C 端支付用户

风控运营人员

规则引擎 REP

沿着真实任务走一遍，问题不在单个页面，而在对象与状态之间的断点

创建 / 管理规则

创建 / 管理规则集

创建 / 管理规则项目

创建 / 管理项目版本

验证

审核与发布

REP 风控策略人员：在复杂对象与高风险发布之间，持续寻找可判断的确定性

工作目标

典型行为

三种规则系统：从快速表达、结构化约束到资产化治理

以决策结果作为创建入口

用紧凑 DSL 支持专业效率

把冲突关系写进规则说明

发布之前先建立证据

用支付维度代替规则语法

默认策略为所有支付提供兜底

把优先级与账户范围纳入治理

配置完成不等于能够安全判断

先建设资产，再编排决策

模板、导入与自定义共同扩展

规模化治理进入列表主视图

对象越完整，关系越容易失去

复杂度越高，设计重心越要从“创建成功”转向“持续可判断”

三类竞品模式对应三种实际需求

让简单规则保持简单

把对象关系从下拉框里拿出来

复用必须和资产治理一起设计

把验证变成发布门槛，而不是附加工具

让治理状态直接回答下一步

六个阶段暴露出同一个问题：用户无法持续判断“现在是什么、改变了什么、下一步做什么”

让用户始终知道自己在哪、正在改变什么、下一步由谁完成

围绕 REP 规则生产链组织平台

让规则在列表里带着上下文出现，在变更前先看见影响

找得到

看得懂

改得稳

从“记得名字”转向按资产线索定位

生成 Snapshot 前，先看清改变了什么

把业务判断翻译成可执行、可复用的规则结构

先定义身份

沿用判断语言

复杂度按需出现

不离开规则创建页，也能补齐缺失的 Category

规则创建之后，仍然需要可审阅、可比较、可追责

先确认当前事实

再比较内容版本

最后追溯操作

让用户始终知道自己正在修改哪个版本

版本列表不仅回答“有哪些”，还要说明“在哪里被使用”

内容差异与操作记录分开表达，分别服务决策判断和责任追溯

从规则创建、Category 成组，到 Project 决策流发布

End-to-end REP journey

创建规则

Risk
Foundation

一套决策底座
多种业务语境