- Updated `RiskListAccess` and `ThresholdWriteAccess` to enforce access control in the risk repository and threshold repository, ensuring only authorized roles can perform sensitive operations. - Introduced new methods in `RiskRepository` for counting pending alerts and listing alerts with access checks, improving data security and compliance. - Enhanced the `chat.py` and `deps.py` files to integrate compliance roles into the risk management matrix, allowing for more granular access control. - Updated documentation to reflect the new testing baseline of 825 passed tests, indicating improved stability and functionality across the application. This update significantly strengthens the risk management capabilities, ensuring robust access control and compliance with organizational policies.
60 lines
3.2 KiB
Markdown
60 lines
3.2 KiB
Markdown
# 服务对象大环境(现状 / As-Is)
|
||
|
||
> 来源:`docs/需求拆解/业务场景优先级清单.md`、`docs/需求拆解/用户故事/`
|
||
> **Core 说明:** 生产环境应以真实 Core 为 L0 权威;**本项目无真实 Core**,开发用 `jinrong_core` 模拟库(见 `docs/项目框架设计/Core模拟底座/`)。
|
||
|
||
------
|
||
|
||
## 1. 服务对象与角色(现在)
|
||
|
||
| 角色 | 谁 | 在环境里干什么 |
|
||
| --- | --- | --- |
|
||
| C 端客户 | 公募投资者 | 看持仓、查产品、交易;正式 C1~C5 在测评系统 |
|
||
| 理财代理人 | 一线理财经理 | 服务名下客户、多系统查持仓、讲解规则、跟进 |
|
||
| 内部员工 | 分析、运营、合规 | 问数、报表、抽检会话、协同风控 |
|
||
| 风控 / 合规官 | 风控专员 | 监测大额/适当性/AML;人工审核,不自动冻户 |
|
||
|
||
**L0 权威来源(本项目):** MySQL `jinrong_core` 模拟库 — 客户、C1~C5、持仓、流水、产品、代理人-客户归属。Agent 代码经 `CoreReadOnlyRepository` **只读 SELECT**,不提供 HTTP Core API。
|
||
|
||
------
|
||
|
||
## 2. 对方现在怎么办事
|
||
|
||
- **客户**:App/柜台看持仓;亏损无 Agent 式阈值提醒。
|
||
- **代理人**:多后台手工汇总;话术自写,合规靠事后检查。
|
||
- **内部分析**:SQL 或 IT 导表。
|
||
- **风控**:事后/T+1 发现异常;适当性靠交易前规则;AML 批处理或人工。
|
||
|
||
Agent **尚未上线**;后端已在 **`merger` 分支**集成(AL-09 + 客服 Wave3 + 问数 S3/D-06/N-03/N-07 + 风控 TEST-RISK-001 修复 + 平台 API v0.1 + `/api/ready`):**`python -m pytest` → 825 passed 1 skipped**(集成需本机 MySQL/Redis);无生产 Core/托管接入。代理人/分析 **chat 骨架**仍为主,问数/客服/风控已有独立业务链路。
|
||
|
||
------
|
||
|
||
## 3. 主路径(现状 → 模拟后)
|
||
|
||
1. 开户/测评 → Core(模拟:`core_customer` + `core_customer_risk`)写 L0
|
||
2. 交易 → Core 流水(模拟:`core_trade`);交易前适当性 R-02 **已实现**(模拟网关 `app/gateway/` + `service/suitability.py`,唯一阻断点)
|
||
3. 同步 → `sync_advisor_rel.py` 写入 agent 库 `customer_advisor_rel`;`sync_neo4j.py` 灌关系图
|
||
4. 代理人服务 → 查 Core RO + 口头沟通(L2 画像表待业务实现)
|
||
5. 风控 → 规则/人工台账;合规事后抽检
|
||
|
||
------
|
||
|
||
## 4. 环境里的关键对象
|
||
|
||
| 名称 | 含义 | 本项目存储 |
|
||
| --- | --- | --- |
|
||
| L0 正式档案 | customer_id、C1~C5、年龄、职业、advisor | `jinrong_core.core_*` |
|
||
| 持仓/流水 | 产品、份额、盈亏 | `core_holding` / `core_trade` |
|
||
| 代理人-客户归属 | 服务关系 | Core 种子 → 同步 `jinrong_agent.customer_advisor_rel` |
|
||
| Agent 会话/画像/审计 | 平台业务数据 | `jinrong_agent`(11 共用表 + agent 专用表) |
|
||
|
||
------
|
||
|
||
## 5. 痛点与约束
|
||
|
||
```text
|
||
痛点:客户看不清持仓与规则;代理人多系统慢、话术易违规;问数靠 SQL;风控感知滞后
|
||
不能动:正式 C1~C5 仅测评/人工变更;事实账以 Core 为准(模拟库亦只读);监管要求审计与适当性
|
||
模拟边界:不模拟 TA/清算/报盘;种子数据静态净值可接受;Neo4j 由同步脚本维护
|
||
```
|