# 第十七届“工行杯”全国大学生金融科技创新大赛

## 银龄e护

### 面向老年客户的家庭协同支付与可撤回授权服务项目计划书

---

## 摘要

随着人口老龄化程度加深，老年客户在日常金融活动中对家庭协助的需求越来越明显。水电燃气、物业、通信、医疗和生活消费等支付，通常金额较小、频率较高、时间要求明确。很多老年客户能够自己管理银行账户，但在具体操作上仍需要子女或其他家庭成员搭把手。

现在的家庭协助，常常依赖共享银行卡、支付密码、手机设备或账户登录信息。这样虽然能解决眼前的问题，却带来了几个明显风险：权限范围过大，账户信息容易暴露，交易过程不透明，家庭责任边界不清，授权也不容易及时撤回。

银行也面临另一种困难：为了防范风险，系统可能拦截非本人设备、异地操作或陌生收款方，但正常的家庭协助交易和异常交易并不总是容易区分。

“银龄e护”拟在银行已有账户和支付体系之上，增加一套面向家庭协助场景的精细授权机制。老年客户始终是账户主体和最终控制人，家庭成员只能在明确授权的范围内完成指定支付。授权可以限定协助对象、支付用途、单笔金额、累计金额、有效期限、收款方范围和支付渠道。系统再通过授权校验、风险识别、消息通知和审计留痕，给家庭协助划出清楚的边界。

本项目不涉及贷款、理财、保险等金融产品销售，也不把家庭成员设置为账户共同所有人。项目关注的是一个具体问题：

> 老年客户需要家人帮忙时，怎样在保留金融自主权的前提下获得支付协助？

项目拟形成业务流程、权限模型、风控规则、交互原型和技术架构设计，为养老金融、数字金融和金融安全服务提供一套可讨论、可验证的产品方案。

关键词：养老金融；适老化服务；家庭协同支付；最小权限；可撤回授权；金融安全

---

# 第一章 项目背景与建设必要性

## 1.1 政策背景

国务院办公厅发布的《关于发展银发经济增进老年人福祉的意见》提出，应围绕老年人的实际生活需求，拓展居家助老服务，支持生活用品代购、代收代缴等服务场景，为老年人提供更便利的生活服务。

国务院办公厅发布的《关于切实解决老年人运用智能技术困难的实施方案》提出，传统服务方式与智能化服务应当并行，重点解决老年人在金融服务、生活缴费和日常办事等高频场景中的数字应用困难。

国家金融监督管理总局发布的《关于银行业保险业做好金融“五篇大文章”的指导意见》将养老金融和数字金融列为重点方向，提出推动金融适老化改造，提升老年人金融服务体验，同时强化数字金融安全、数据安全和消费者权益保护。

参考文件：

- [关于发展银发经济增进老年人福祉的意见](https://app.www.gov.cn/govdata/gov/202401/15/511180/article.html)
- [关于切实解决老年人运用智能技术困难的实施方案](https://app.www.gov.cn/govdata/gov/202011/24/465255/article.html)
- [关于银行业保险业做好金融“五篇大文章”的指导意见](https://www.nfra.gov.cn/cn/view/pages/ItemDetail.html?docId=1161211&generaltype=0&itemId=928)

因此，养老金融不应只停留在养老储蓄、养老理财和养老保险等产品层面，也应覆盖老年客户的日常支付、账户管理、家庭协助和风险保护。

## 1.2 用户需求

老年客户的家庭协助需求通常有四个特点：

1. **事项明确。** 多数情况下，老人不是要把整个账户交给家人，而是需要有人完成某一笔缴费、购买某一类生活用品，或者在特定时间完成一项支付。
2. **关系长期。** 子女可能长期帮助父母处理生活缴费，但家庭关系存在，并不等于协助人应当拥有无限账户权限。
3. **既要方便，也要有自主权。** 老人希望家人能帮忙，也希望知道资金发生了什么变化。
4. **银行需要区分正常和异常。** 家庭协助不能全部放行，也不能把所有非本人操作都当作风险。

## 1.3 现有方式的问题

| 方式 | 解决的问题 | 主要不足 |
| --- | --- | --- |
| 共享银行卡或支付密码 | 家人可以直接完成支付 | 权限过大，难以限制用途和金额 |
| 家人直接使用老年客户手机 | 可以处理复杂线上流程 | 可能暴露验证码、设备信息和完整账户信息 |
| 全面代办或长期代理 | 适用于部分正式业务 | 办理成本较高，不适合日常小额支付 |
| 附属卡或关联账户 | 可以实现一定分离 | 通常不能细分用途、期限和撤回要求 |
| 风险系统统一拦截 | 可以降低一部分异常交易风险 | 可能误伤真实的家庭协助 |
| 银龄e护 | 在限定范围内提供协助 | 需要精细的授权、风控和审计机制 |

核心问题不是“是否允许家人帮助老人”，而是能否把家庭协助纳入正式、清晰、可控制的金融服务流程。

---

# 第二章 项目定位与建设目标

## 2.1 项目定位

“银龄e护”定位为银行个人金融服务中的家庭协同支付授权模块。

该模块不改变老年客户的账户主体地位，不新增家庭共同账户，也不赋予家庭成员完整账户操作权限，而是在原有账户和支付系统之上增加一套面向家庭协助的权限管理机制。

核心关系为：

> 老年客户是账户主体，家庭成员是受限协助人，银行系统负责身份确认、权限校验、风险识别和交易留痕。

## 2.2 总体目标

建立一套“本人可控、家属可帮、银行可管、过程可查、权限可撤”的家庭协同支付服务方案。

## 2.3 具体目标

1. 建立适用于生活缴费和小额消费的家庭协同支付授权模型。
2. 将协助权限拆分为对象、用途、金额、期限、收款方和渠道等要素。
3. 建立授权创建、授权使用、暂停、撤回和到期的完整生命周期。
4. 对超出授权范围的交易进行拒绝、二次确认或人工核验。
5. 向账户本人展示协助交易的金额、时间、用途和收款方。
6. 为不会使用智能手机或无法独立操作的老年客户保留营业网点和人工客服渠道。

---

# 第三章 业务模式设计

## 3.1 参与角色

### 账户本人

账户本人是老年客户，拥有账户主体地位，负责创建、确认、调整和撤销授权。

### 家庭协助人

家庭协助人可以是子女、配偶或其他由账户本人指定的家庭成员。协助人只能在授权范围内完成支付，不得转授权，也不得修改账户核心信息。

### 银行服务人员

银行服务人员负责身份核验、授权辅助、异常处理、争议处理和客户服务。

### 银行风险控制系统

风险控制系统负责对每一笔协助交易进行权限检查和风险评估，并根据风险等级采取放行、二次确认、人工核验或拒绝处理。

## 3.2 业务边界

银龄e护只处理日常支付协助，不处理以下业务：

- 贷款申请和贷款支用；
- 基金、理财、保险等投资类产品购买；
- 账户注销；
- 绑定手机号、登录密码和支付密码修改；
- 向陌生账户的大额转账；
- 现金取现；
- 向其他人员转授权；
- 涉及账户所有权变更的业务。

上述业务如确需办理，应当回到账户本人确认、营业网点办理或其他更高级别的身份核验流程。

---

# 第四章 授权模型设计

## 4.1 授权对象

授权对象必须是明确的个人，不允许使用“任何家庭成员”“所有亲属”等模糊对象。

每个协助人应当具有独立的协助人标识，授权关系与账户本人、协助人身份和授权版本绑定。

## 4.2 授权要素

| 要素 | 设计要求 |
| --- | --- |
| 授权编号 | 系统生成的唯一编号 |
| 授权人 | 老年客户账户本人 |
| 协助人 | 经过身份确认的家庭成员 |
| 授权类型 | 固定缴费、小额支付或一次性支付 |
| 用途范围 | 水电、物业、通信、医疗、生活消费等 |
| 收款方范围 | 指定平台、指定商户或白名单 |
| 单笔限额 | 单笔交易允许的最高金额 |
| 日累计限额 | 每日可使用的累计额度 |
| 月累计限额 | 每月可使用的累计额度 |
| 生效时间 | 授权开始时间 |
| 失效时间 | 授权结束时间 |
| 使用渠道 | 手机银行、指定支付渠道或网点辅助 |
| 当前状态 | 待确认、生效、暂停、撤销、到期 |
| 版本号 | 每次授权变更生成新版本 |
| 本人确认记录 | 确认方式、时间和设备 |

## 4.3 授权类型

### 固定缴费授权

适用于水费、电费、燃气费、物业费和通信费等周期性支付。收款方相对稳定，交易用途明确，金额波动相对有限，但仍应设置单笔和月度上限。

### 小额生活支付授权

适用于超市、药店、社区服务和指定生活商户。不允许协助人进行任意转账，只能在约定的消费类别或商户范围内使用。

### 一次性支付授权

适用于临时性缴费或偶发性支出。交易成功后，该权限自动失效，不形成长期授权关系。

### 紧急协助授权

只适用于特殊情况的一次性支付，需要账户本人进行更高等级确认，不应成为普通家庭协助的默认方式。

## 4.4 授权状态机

~~~text
草稿
  ↓
待本人确认
  ↓
已生效
  ├──→ 暂停
  │       └──→ 恢复
  ├──→ 撤销
  └──→ 到期
~~~

| 状态 | 含义 |
| --- | --- |
| 草稿 | 授权内容尚未完成 |
| 待本人确认 | 授权已填写，等待账户本人确认 |
| 已生效 | 协助人可以在权限范围内发起交易 |
| 暂停 | 暂时禁止使用，后续可恢复 |
| 撤销 | 授权永久失效，不能直接恢复 |
| 到期 | 达到有效期限，系统自动失效 |

授权撤回只影响尚未完成的新交易。已经完成的交易不会因为撤回授权而自动撤销，系统应保留原交易记录，并通过客服或争议处理流程解决后续问题。

---

# 第五章 交易处理流程

## 5.1 交易状态机

~~~text
交易发起
  ↓
身份识别
  ↓
授权策略校验
  ↓
交易风险评估
  ├──→ 正常通过
  ├──→ 二次确认
  ├──→ 人工核验
  └──→ 拒绝交易
~~~

交易通过后进入：

~~~text
待执行
  ↓
银行支付系统处理
  ├──→ 支付成功
  └──→ 支付失败
~~~

## 5.2 权限校验

系统首先判断：

1. 授权是否处于“已生效”状态；
2. 当前协助人是否与授权对象一致；
3. 交易用途是否属于授权用途；
4. 交易金额是否小于单笔限额；
5. 当日累计金额是否未超过日限额；
6. 当月累计金额是否未超过月限额；
7. 收款方是否属于授权范围；
8. 当前时间是否在授权有效期内；
9. 当前渠道和设备是否符合授权要求。

只要有一项硬性条件不满足，交易就不能直接通过。

## 5.3 风险评估

| 风险特征 | 判断内容 |
| --- | --- |
| 设备风险 | 是否为首次使用设备，设备是否存在异常 |
| 地理风险 | 当前地点是否与历史行为明显不符 |
| 收款方风险 | 是否为首次收款方，是否属于高风险名单 |
| 金额风险 | 是否明显高于历史平均金额 |
| 频率风险 | 是否在短时间内重复发起多笔交易 |
| 时间风险 | 是否在异常时间段操作 |
| 行为风险 | 是否连续尝试突破授权范围 |
| 关系风险 | 协助人是否刚建立关系，是否频繁变更 |

## 5.4 风险决策

| 风险等级 | 处理方式 |
| --- | --- |
| 低风险 | 自动通过并向账户本人发送通知 |
| 中风险 | 要求账户本人进行二次确认 |
| 高风险 | 暂停交易，进入人工核验或直接拒绝 |

系统应当给出能看懂的原因提示：

- 本次交易不属于已授权用途。
- 本次交易超过单笔金额限制。
- 当前收款方不在授权范围内。
- 当前授权已经暂停或到期。
- 检测到异常设备，需要账户本人确认。

---

# 第六章 系统技术架构

## 6.1 总体架构

~~~text
老年客户端、家庭协助端、银行管理端
                    ↓
              API 接入层
                    ↓
          身份与授权管理服务
                    ↓
          支付预检查与权限引擎
                    ↓
       风险识别引擎与人工核验模块
                    ↓
         支付执行、消息通知、审计系统
~~~

## 6.2 前端层

### 老年客户端

重点解决“看得懂、点得准、撤得掉”。页面直接展示当前授权状态，提供“我的授权”“家庭协助记录”“撤销授权”和“联系银行”等入口。

授权确认页面必须展示：

- 授权给谁；
- 可以做什么；
- 每次最多支付多少；
- 累计最多支付多少；
- 授权何时失效；
- 如何撤销授权。

### 家庭协助端

只展示当前协助权限，不展示账户本人全部资产信息。主要包括“可协助事项”“发起支付”“剩余额度”“交易记录”和“权限说明”。

当协助人尝试发起超出范围的交易时，系统应当直接拒绝，而不是提供模糊的“继续尝试”按钮。

### 银行管理端

包括授权查询、交易风险、客户通知、人工核验和审计查询。

风险交易至少展示：

账户本人信息、协助人信息、授权内容、交易金额、收款方、设备和地点、命中的风险规则、历史交易情况，以及账户本人是否完成二次确认。

## 6.3 服务层

| 服务模块 | 主要职责 |
| --- | --- |
| 身份服务 | 账户本人和协助人身份确认 |
| 授权服务 | 创建、修改、暂停、恢复、撤销授权 |
| 权限服务 | 校验交易是否符合授权策略 |
| 支付服务 | 创建支付订单并跟踪支付状态 |
| 风险服务 | 对交易进行规则判断和风险评分 |
| 通知服务 | 向账户本人发送授权和交易通知 |
| 审计服务 | 记录关键操作和系统决策 |
| 客服服务 | 处理异常、申诉和争议 |

---

# 第七章 数据结构设计

以下结构用于原型系统设计，不代表工商银行真实数据库结构。

## 7.1 用户表

| 字段 | 含义 |
| --- | --- |
| user_id | 用户唯一标识 |
| role | 账户本人、协助人、银行工作人员 |
| verification_level | 身份核验等级 |
| phone_masked | 脱敏手机号 |
| account_ref | 脱敏账户标识 |
| status | 正常、冻结、注销 |
| created_at | 创建时间 |

原型系统不保存真实身份证号、银行卡号和支付密码，只使用模拟数据和脱敏字段。

## 7.2 协助关系表

| 字段 | 含义 |
| --- | --- |
| relation_id | 关系编号 |
| owner_id | 账户本人编号 |
| helper_id | 协助人编号 |
| relation_type | 子女、配偶、其他 |
| verification_status | 未确认、已确认、异常 |
| created_at | 关系建立时间 |
| status | 正常、暂停、解除 |

## 7.3 授权策略表

| 字段 | 含义 |
| --- | --- |
| authorization_id | 授权编号 |
| relation_id | 对应协助关系 |
| authorization_type | 固定缴费、小额支付、一次性支付 |
| scope_category | 交易用途 |
| merchant_scope | 收款方范围 |
| single_limit | 单笔限额 |
| daily_limit | 日累计限额 |
| monthly_limit | 月累计限额 |
| valid_from | 生效时间 |
| valid_to | 失效时间 |
| status | 授权状态 |
| version | 授权版本 |
| consent_record | 本人确认记录 |

## 7.4 支付订单表

| 字段 | 含义 |
| --- | --- |
| payment_id | 支付订单编号 |
| authorization_id | 使用的授权编号 |
| helper_id | 发起交易的协助人 |
| amount | 交易金额 |
| payee_ref | 脱敏收款方 |
| category | 交易类别 |
| device_ref | 脱敏设备标识 |
| location_level | 粗粒度地点信息 |
| policy_result | 权限校验结果 |
| risk_result | 风险评估结果 |
| payment_status | 待处理、成功、失败、拒绝 |
| created_at | 发起时间 |

## 7.5 风险事件表

| 字段 | 含义 |
| --- | --- |
| risk_event_id | 风险事件编号 |
| payment_id | 关联订单 |
| rule_code | 命中的风险规则 |
| risk_level | 低、中、高 |
| reason | 风险原因 |
| action | 放行、二次确认、人工核验、拒绝 |
| reviewer_id | 人工审核人员 |
| resolved_at | 处理时间 |

## 7.6 审计事件表

审计表采用追加式记录，普通业务人员不能直接修改或删除。

记录内容包括：操作主体、操作类型、操作对象、操作前状态、操作后状态、时间、设备、来源渠道、系统响应和人工处理意见。

---

# 第八章 原型系统接口设计

以下为原型系统的逻辑接口，不代表工商银行真实接口。

| 接口 | 调用主体 | 功能 |
| --- | --- | --- |
| POST /authorizations | 账户本人 | 创建授权草稿 |
| POST /authorizations/{id}/confirm | 账户本人 | 确认并启用授权 |
| GET /authorizations | 账户本人、协助人、银行人员 | 查询授权 |
| POST /authorizations/{id}/suspend | 账户本人、银行人员 | 暂停授权 |
| POST /authorizations/{id}/revoke | 账户本人、银行人员 | 撤销授权 |
| POST /payments/precheck | 协助人 | 发起支付预检查 |
| POST /payments | 协助人 | 创建支付订单 |
| POST /payments/{id}/confirm | 账户本人 | 处理二次确认 |
| GET /payments/{id} | 相关用户 | 查询支付状态 |
| GET /risk-events | 银行人员 | 查询风险事件 |
| GET /audit-events | 授权银行人员 | 查询审计日志 |

每一个支付请求都必须携带授权编号。系统不接受仅凭协助人身份发起的无授权支付。

---

# 第九章 安全设计

## 9.1 身份安全

账户本人和协助人使用不同身份体系，不能共享登录凭证。

账户本人确认授权时，应使用银行认可的身份核验方式。协助人只能使用自己的身份登录，不得使用账户本人的账号和密码。

## 9.2 权限安全

权限采用最小化设计。家庭协助人只能使用已经授权的交易类别和收款范围，不能访问账户本人全部交易记录，不能修改账户安全设置，也不能再次授权给其他人。

## 9.3 数据安全

原型阶段使用虚拟账户和虚拟交易，不使用真实身份证号、银行卡号、手机号和交易数据。

正式系统应对账户标识、手机号、身份证信息、设备标识、地理位置、交易金额和收款方信息进行脱敏或加密。

## 9.4 传输与存储安全

正式系统应采用加密通信，重要数据加密存储，接口使用访问令牌和权限校验，关键操作使用幂等机制和防重放机制。

原型系统可以通过模拟令牌、角色权限和事件日志展示上述逻辑，但不接入真实银行支付接口。

## 9.5 审计安全

授权变化、支付发起、交易拒绝、风险评分、人工处理和权限撤回均应记录。

审计记录必须具备时间顺序和版本信息，避免操作发生后无法追溯。

---

# 第十章 人工智能与风控技术设计

本项目不把“大模型”作为主要卖点，也不让人工智能直接决定资金是否放行。

资金交易属于高风险场景，生成式大模型不适合直接承担最终审批责任。因此项目采用“确定性规则为主、风险模型辅助”的方式。

## 10.1 硬规则

~~~text
授权状态必须为已生效；
当前协助人必须与授权对象一致；
交易用途必须属于授权类别；
收款方必须属于授权范围；
交易金额不得超过单笔限额；
累计金额不得超过日限额和月限额；
当前时间不得超过授权有效期；
交易不得属于禁止类业务。
~~~

任何一项硬规则不满足，交易不得直接通过。

## 10.2 风险评分

对于通过硬规则的交易，再根据设备、收款方、金额、地理位置、操作频率和时间等因素计算风险分值：

$$
\text{风险分值}
=
\text{设备异常权重}
+
\text{收款方异常权重}
+
\text{金额偏离权重}
+
\text{地理位置异常权重}
+
\text{操作频率异常权重}
+
\text{时间异常权重}
$$

风险分值只用于辅助判断，不直接生成无法解释的拒绝结果。

## 10.3 风险决策

| 条件 | 处理 |
| --- | --- |
| 授权有效、用途匹配、金额正常、设备稳定 | 自动通过 |
| 首次设备、首次收款方或金额明显偏高 | 账户本人二次确认 |
| 超出授权用途或存在明显异常 | 拒绝或人工核验 |
| 涉及贷款、投资、现金取现等禁止业务 | 直接拒绝普通协助权限 |

## 10.4 风险解释

系统必须说明风险原因，不能只显示“交易失败”：

- 当前交易超过本次授权的单笔金额限制。
- 当前收款方未被纳入授权范围。
- 当前操作设备与历史设备存在较大差异。
- 该交易类型不属于家庭协助权限。

---

# 第十一章 典型应用场景

## 场景一：正常固定缴费

李阿姨授权女儿每月帮助缴纳物业费，单笔限额 500 元，授权期限 12 个月，收款方限定为指定物业公司。

女儿发起支付后，系统检查授权状态、收款方、金额和期限。条件满足后，支付自动完成，李阿姨收到交易通知。

## 场景二：超出金额限制

李阿姨授权女儿进行单笔不超过 300 元的药店支付。女儿发起一笔 800 元交易，系统识别为超出单笔限额并拒绝。

## 场景三：向陌生账户转账

女儿的权限仅限生活缴费，却尝试向陌生个人账户转账。系统判断交易用途不匹配，直接拒绝，并将风险事件推送给账户本人和银行风险管理端。

## 场景四：首次使用新设备

女儿平时使用固定手机协助支付，某次更换设备后发起缴费。由于设备发生变化，但交易用途和收款方正常，系统不直接拒绝，而是要求账户本人进行二次确认。

## 场景五：撤销家庭协助权限

李阿姨在“我的授权”页面点击撤销。系统将授权状态改为“已撤销”，所有尚未执行的新交易不得继续使用该授权。

---

# 第十二章 原型开发边界

## 12.1 原型阶段实现

1. 老年客户创建固定缴费授权；
2. 家庭协助人查看受限权限；
3. 家庭协助人发起一笔模拟支付；
4. 系统完成授权规则校验；
5. 系统模拟异常交易拦截；
6. 老年客户查看交易通知；
7. 老年客户暂停或撤销授权；
8. 银行工作人员查看授权关系和风险事件。

## 12.2 原型阶段不实现

1. 真实银行账户登录；
2. 真实支付和资金清算；
3. 真实身份认证；
4. 真实银行卡绑定；
5. 真实短信验证；
6. 真实银行核心系统接入；
7. 面向公众的商业化运营。

这样的边界可以避免夸大技术成果，把评审重点放在授权机制和金融服务逻辑上。

---

# 第十三章 项目创新性

## 13.1 把授权对象从“账户”细化为“具体服务权限”

传统账户授权容易形成较大范围的操作能力。本项目将授权对象拆分为“帮助缴纳物业费”“完成小额生活支付”等具体服务，减少权限外溢。

## 13.2 把“能不能操作”细化为“可以操作什么”

项目同时限制用途、收款方、金额和期限，形成多条件组合授权。

## 13.3 把可撤回机制前置

撤回不是异常发生后的补救措施，而是授权设计中的基础功能。账户本人可以随时暂停或终止授权。

## 13.4 把家庭协助纳入银行风控体系

系统不再把家庭协助当作账户外部行为，而是通过正式授权关系，将其纳入银行可识别、可审计和可管理的服务范围。

## 13.5 技术服务于问题

项目不为了加入人工智能、区块链等名词而堆技术。技术方案只解决权限管理、风险判断和审计追溯等实际问题。

---

# 第十四章 与工商银行的匹配关系

| 工商银行能力 | 项目对应功能 |
| --- | --- |
| 个人客户身份体系 | 账户本人和协助人身份确认 |
| 手机银行服务 | 授权创建、支付发起和交易通知 |
| 营业网点服务 | 老年客户线下授权和人工辅助 |
| 支付结算体系 | 日常缴费和生活支付 |
| 反欺诈系统 | 异常设备、异常收款方和异常行为识别 |
| 客户服务体系 | 风险核验、授权撤回和争议处理 |
| 养老金融服务 | 面向老年客户的综合金融服务优化 |

项目不主张重新建设银行核心系统，而是提出一个可以嵌入既有个人金融服务体系的服务模块。

如果进入实际研究阶段，系统至少需要与客户身份系统、授权管理系统、支付系统、风险控制系统、消息中心和客户服务系统协同。

---

# 第十五章 实施计划

## 第一阶段：需求研究与问题确认

研究老年客户的日常支付需求、家庭成员的协助方式、银行网点工作人员的操作痛点，以及风险控制中可能出现的误拦截问题。

输出用户画像、场景清单、问题清单和竞品机制对比。

## 第二阶段：授权模型设计

确定授权类型、权限字段、金额限制、时间限制、收款方范围、撤回机制和风险规则。

输出权限矩阵、状态机、业务流程图和异常处理流程。

## 第三阶段：交互原型设计

完成老年客户端、家庭协助端和银行管理端的页面设计，重点演示授权、支付、拦截、通知和撤回五个环节。

## 第四阶段：技术原型开发

采用模拟用户、模拟账户和模拟交易数据，不接入真实金融系统。

原型实现角色权限隔离、授权策略判断、交易预检查、风险事件生成和操作日志记录。

## 第五阶段：情景测试

测试正常缴费、超额支付、过期授权、撤销授权、异常设备、陌生收款方和禁止类交易等场景，并根据结果修订流程、提示和规则。

---

# 第十六章 原型验收指标

以下指标是原型测试指标，不代表真实银行系统运行效果。

| 指标类别 | 目标 |
| --- | --- |
| 授权闭环 | 完成创建、确认、生效、暂停、恢复、撤销和到期 |
| 权限校验 | 所有预设的超范围交易均能够被识别 |
| 禁止交易 | 贷款、投资、取现和陌生大额转账不得通过普通协助权限 |
| 撤回机制 | 撤回后新的未执行交易不得继续使用原授权 |
| 通知机制 | 授权变化和支付结果均生成账户本人通知 |
| 审计机制 | 每次授权和交易操作均生成完整日志 |
| 风险解释 | 每次拒绝或二次确认均展示明确原因 |
| 数据安全 | 原型不使用真实个人信息和真实资金数据 |
| 操作体验 | 老年客户能够理解授权对象、用途、额度和期限 |
| 银行匹配度 | 业务流程能够对应账户、支付、风控、客服和网点场景 |

---

# 第十七章 项目风险与应对措施

## 17.1 被误解为“家属可以控制老人账户”

在项目名称、产品首页和授权确认页面中持续强调“账户本人保持控制权”，禁止使用“家属代管账户”等表述。

## 17.2 授权流程过于复杂

将授权类型限定在几个高频场景，采用固定模板；复杂权限交由银行网点或人工客服处理。

## 17.3 风险规则过于严格

将生活缴费和高风险金融交易分开处理。对正常固定缴费适当降低操作摩擦，对陌生转账和投资交易维持高强度控制。

## 17.4 老年客户不理解授权内容

使用金额、期限、用途和协助人四个固定字段进行确认，不使用难以理解的专业术语，并提供人工解释渠道。

## 17.5 家庭关系发生变化

提供即时暂停和撤销功能，授权关系不因家庭关系持续存在而永久有效。

## 17.6 发生交易争议

依靠授权记录、交易记录、风险决策记录和本人确认记录还原完整过程，并通过银行客服和争议处理机制解决。

---

# 第十八章 项目预期成果

项目最终形成：

1. 完整的《银龄e护项目计划书》；
2. 老年客户家庭协同支付业务流程；
3. 家庭协助授权权限矩阵；
4. 授权状态机和交易状态机；
5. 老年客户端交互原型；
6. 家庭协助端交互原型；
7. 银行风险管理端原型；
8. 交易权限校验规则；
9. 异常交易识别与人工核验流程；
10. 数据结构和逻辑接口设计；
11. 安全、隐私和合规边界说明；
12. 模拟场景测试记录。

---

## 结论

“银龄e护”解决的不是单纯的“老年人不会使用手机”，而是老年客户在需要家庭帮助时，如何继续保有账户控制权。

项目将家庭协助从银行卡、密码和设备共享，转变为银行系统内可定义、可限制、可追踪、可撤回的服务权限。老年客户可以决定授权给谁、可以做什么、每次支付多少、授权持续多久，并能在授权过程中查看交易、暂停权限和撤销授权。

从业务角度看，项目将养老金融服务从产品销售延伸到日常支付和客户权益保护；从技术角度看，项目把身份管理、权限管理、交易风控、消息通知和审计系统结合起来；从社会价值看，项目在家庭照护便利性和老年客户金融自主权之间建立更清晰的平衡。

本项目目前定位为面向银行场景的产品服务创新方案和交互原型，不宣称已经完成工商银行系统接入或真实业务落地。核心成果是一套边界明确、逻辑完整、技术上可实现、具备银行业务匹配度的家庭协同支付授权机制。