银行业务AI虚构小故事合集：借故事理解业务（企业贷款、个人信用卡、反洗钱）

银行业务AI虚构小故事合集

继续用之前讲业务故事的方式来讲银行业务和表的关联，那种方式比较容易听懂。

故事：一家小工厂来借钱

第一幕：企业来了，要借钱

杭州有一家做零件的小工厂，老板叫老张。工厂想买一台新机器，需要100万。

老张去浙商银行申请贷款。银行说：你把资料给我（营业执照、流水、报表），我们先看看。

这个阶段产生的数据：客户信息表

• 表里记了一条：客户号 = C001，客户名 = 老张的工厂，行业 = 制造业，老板 = 老张

第二幕：银行批了，签合同

银行审核完，觉得老张的工厂还行，同意借他100万。双方签了一份贷款合同。

合同上写着：

• 合同金额：100万

• 期限：1年

• 利率：4%

• 还款方式：先息后本（每个月只还利息，到期还本金）

这个阶段产生的数据：贷款合同表

• 表里记了一条：合同号 = HT001，客户号 = C001，合同金额 = 100万，期限 = 1年，利率 = 4%

注意：合同签了，但钱还没到工厂账上。合同只是一个“借钱的约定”。

第三幕：钱到账了，生成借据

老张说：机器已经看好了，可以放款了。银行就把100万打到了工厂的账户。

重点来了：放款的这一刻，核心系统会生成一张借据。

借据就像是一张“电子欠条”。工厂每借一次钱，就生成一张借据。一张合同可以对应多张借据（比如分好几次提款），但这次老张一次提完了，所以一张合同对应一张借据。

这个阶段产生的数据：借据表

• 表里记了一条：借据号 = J001，合同号 = HT001，借据金额 = 100万，余额 = 100万，利率 = 4%，放款日期 = 2025-01-01，到期日 = 2026-01-01

借据表的余额字段很重要——它记录的是“还剩多少钱没还”。刚放款时，余额 = 借据金额。每还一次钱，余额就减少一点。

第四幕：每个月还利息

合同约定“先息后本”，所以老张每个月要还利息。

利息怎么算？

每月利息 = 借据金额 × 年利率 ÷ 12 = 100万 × 4% ÷ 12 = 3333.33元

每个月20号，银行自动从工厂账户扣3333.33元。

这个阶段产生的数据：还款流水表

• 每次还钱，就记一条流水：流水号 = L001，借据号 = J001，还款金额 = 3333.33，还款日期 = 2025-01-20

• 第二个月：流水号 = L002，借据号 = J001，还款金额 = 3333.33，还款日期 = 2025-02-20

注意：每次还完钱，借据表的余额不变（因为还没还本金）。

第五幕：工厂还钱了，本金减少

到了2026年1月1日，合同到期了。老张需要把100万本金还给银行。

老张凑齐了钱，银行从工厂账户扣走100万。

这个阶段产生的数据：又是一条还款流水

• 流水号 = L013，借据号 = J001，还款金额 = 100万，还款日期 = 2026-01-01

同时，借据表的余额从100万变成了0。借据状态从“正常”变成“结清”。

故事还没完：万一老张不还钱呢？

假设老张的工厂生意不好，2025年6月的利息没还上。

这时候，银行系统会怎么记录？

还款流水表里，没有6月份的还款记录。借据表里，余额还是100万，但多了一个字段会变化——五级分类。

五级分类是银行给贷款打的一个“质量分”：

• 正常：一切正常

• 关注：有点小问题，要注意

• 次级：可能还不上，有损失风险

• 可疑：大概率还不上，损失很大

• 损失：彻底凉了

老张没还利息，银行可能把他的贷款从“正常”调到“关注”或者更差。

把所有表串起来的一张图

客户信息表 贷款合同表 ┌─────────────┐ ┌─────────────┐ │客户号：C001 │◄────────────│合同号：HT001│ │客户名：工厂 │ 1个客户 │客户号：C001 │ │老板：老张 │ 可以签 │合同金额：100万│ └─────────────┘ 多份合同 └──────┬──────┘ │ │ 1份合同 │ 可以对应 │ 多张借据 ▼ 借据表 ┌─────────────────────────┐ │借据号：J001 │ │合同号：HT001 │ │借据金额：100万 │ │余额：100万 → 0万 │ │五级分类：正常 → 结清 │ └───────────┬─────────────┘ │ │ 1张借据 │ 可以对应 │ 多次还款 ▼ 还款流水表 ┌─────────────────────────┐ │流水号：L001 │ │借据号：J001 │ │还款金额：3333.33 │ │还款日期：2025-01-20 │ ├─────────────────────────┤ │流水号：L002 │ │借据号：J001 │ │还款金额：3333.33 │ │还款日期：2025-02-20 │ ├─────────────────────────┤ │... │ ├─────────────────────────┤ │流水号：L013 │ │借据号：J001 │ │还款金额：100万 │ │还款日期：2026-01-01 │ └─────────────────────────┘

你现在能回答的面试问题

问：请讲一下银行贷款的数据流转。

客户签了贷款合同，合同存到合同表。放款时生成借据，每张借据记录一笔放款的金额和余额。客户每次还款，还款流水表记一条记录，同时借据表的余额减少。如果客户逾期，借据表的五级分类会变成关注或更差。监管报送要的就是借据表的余额和五级分类。

故事：老张办了一张信用卡

第一幕：老张想办信用卡

老张的工厂需要经常买零件，有时候手头紧，想有一张信用卡可以临时周转。

他去银行填了申请表，银行查了他的征信、收入，觉得没问题，批了一张信用卡。

这个阶段产生的数据：信用卡账户表

• 表里记了一条：卡号 = 8888-1111-2222-3333，客户号 = C001（就是老张的工厂），信用额度 = 10万，账单日 = 每月5号，还款日 = 每月25号，账户状态 = 正常

注意：信用卡和贷款不一样。

---

贷款是一次性借一笔钱，还完就结束；

---

信用卡是给一个额度，可以反复借、反复还，像一个大水桶，你舀水（刷）、灌水（还），桶里的水（可用额度）变来变去。

第二幕：老张去消费

老张去供应商那里买了5万元的零件，拿出信用卡一刷。

这时候发生了什么？

• 商户的POS机把交易信息传给银行

• 银行验证：额度够不够？卡片状态正常吗？

• 通过后，交易成功，银行的系统记了一笔

这个阶段产生的数据：信用卡交易流水表

• 表里记了一条：流水号 = T001，卡号 = 8888-...，交易金额 = 5万，交易时间 = 2025-05-10，商户名称 = XX零件厂

同时，信用卡账户表的已用额度从0变成5万，可用额度从10万变成5万。

可用额度 = 信用额度 - 已用额度 10万 - 0 = 10万 → 刷5万后 → 10万 - 5万 = 5万

第三幕：账单日到了，银行算账

每个月5号是老张的账单日。到了6月5号，银行把老张5月份刷的所有交易汇总起来，生成了账单。

账单上写着：

• 本期应还总额：5万（上次刷的）

• 最低还款额：5000（通常是本期的10%）

• 到期还款日：6月25号

这个阶段产生的数据：信用卡账单表（有的系统叫账户月结表）

• 表里记了一条：卡号 = 8888-...，账单周期 = 2025-05，应还总额 = 5万，最低还款额 = 5000，还款到期日 = 2025-06-25

这里的最低还款额是银行给客户的“缓冲”：如果暂时还不上全部，至少还这个数，不算逾期，但剩余部分要收利息。

第四幕：老张还钱

老张手里资金有点紧张，6月25号只还了5000（最低还款额）。

还款这个阶段产生的数据：信用卡还款流水表

• 表里记了一条：流水号 = R001，卡号 = 8888-...，还款金额 = 5000，还款日期 = 2025-06-25

更新账户：已用额度从5万变成4.5万，可用额度从5万变成5.5万。

注意：老张只还了5000，剩下的4.5万没还，银行会从6月25号之后开始每天算利息（通常是万分之五）。这笔利息会在下个月的账单里出现。

第五幕：老张想分期

老张觉得一下子还4.5万压力大，打电话给银行申请账单分期：把这4.5万分3个月还，每个月还1.5万加一点手续费。

银行同意了。

这个阶段产生的数据：信用卡分期表

• 表里记了一条：分期号 = F001，卡号 = 8888-...，分期类型 = 账单分期，分期金额 = 4.5万，期数 = 3，每期应还 = 1.5万，手续费率 = 0.7%/期

然后，分期系统会生成一个分期还款计划：未来3个月，每个月固定日期扣1.5万+手续费。

第六幕：如果老张不还钱

假设老张忘了还款，到了7月25号，最低还款额也没还。

这时候，系统会把这笔账标记为逾期。信用卡账户表的账户状态可能从“正常”变成“逾期1期”、“逾期2期”……

和贷款一样，逾期时间长了，也会影响征信，甚至冻结卡片。

现在我们把两张表串起来：贷款 vs 信用卡

贷款业务： 合同表（借多少钱） → 借据表（每次放款） → 还款流水表（每次还钱） 特点：一次性使用，还完就结束 信用卡业务： 信用卡账户表（额度） → 交易流水表（每笔消费） → 还款流水表（每次还款） 特点：循环使用，额度可恢复

刚入行你需要记住的信用卡核心字段

你会遇到的SQL问题举例

Q：查老张的信用卡还剩多少额度

SELECT (信用额度 - 已用额度) AS 可用额度 FROM 信用卡账户表 WHERE 卡号 = '8888-1111-2222-3333'

Q：查老张最近3个月的消费总额

SELECT SUM(交易金额) FROM 信用卡交易流水表 WHERE 卡号 = '8888-...' AND 交易时间 >= DATE_SUB(CURDATE(), INTERVAL 3 MONTH)

Q：查所有逾期超过30天的信用卡账户

SELECT 卡号, 客户号, 已用额度, 逾期天数 FROM 信用卡账户表 WHERE 逾期天数 > 30

信用卡 vs 贷款：异同对比

面试时你可以这样说

信用卡和贷款逻辑类似，但信用卡是循环额度。客户有一个信用额度，每刷一笔，交易流水表记一笔，已用额度增加，可用额度减少。每月账单日生成账单，客户在还款日前还钱。如果还最低还款额，剩余部分要收利息。申请分期的话，分期表会记录分了多少期、每期还多少。

举一个洗钱的案例故事

这个故事改编自一起真实的特大洗钱案——海南“1·29”地下钱庄案，涉案金额727亿元，资金来自全国29个省份的2337家上游公司，涉及4473个个人和公司账户-9。

故事：刘总的地下钱庄

第一幕：刘总的想法

刘总，42岁，没什么学历，但脑子活络。他之前在深圳做地下钱庄，赚了钱，也攒了一套路子。

2008年，他觉得深圳监管太严，决定把“生意”搬到海南去。

他的生意模式很简单：有人有钱想转出去，有人有外汇想换进来，他在中间当“资金搬运工”，抽走千分之零点四到千分之三点五的手续费-9。

但问题是：银行每天都在监控大额资金流动。你怎么让钱在眼皮子底下流动而不被发现？

刘总的方案，层层嵌套，就像剥洋葱。

第二幕：注册空壳公司

刘总先花几万块，在网上买了20张身份证。这些身份证的主人都不知道自己被“代表”了。

拿着这些身份证，他在三亚和海口找了代办公司，注册了20家公司。每家公司的注册资金都是100万——假的，代办公司垫资过一下，验完资就撤走了。

这20家公司，没有员工、没有办公室、没有任何经营活动。它们唯一的用途，就是用来开户和转账-9。

银行系统里，这些公司看起来是正常的法人实体——有营业执照、有公章、有对公账户、开了网银。但实际上，它们全是“空壳”。

你作为大数据开发，如果拉一张表，统计“成立时间不满3个月且没有水电费缴纳记录的企业”，这些空壳公司就会暴露在第一层筛子里。

第三幕：资金进进出出

刘总在深圳有一家正经的投资公司做“前台”。客户打电话来：“刘总，我这有500万，想转到境外。”

刘总说：没问题。

客户把钱打到刘总在深圳投资公司的账户。然后，刘总通过网银，把资金分批转到海南那20家空壳公司的对公账户里-9。

在银行流水里，资金是怎么走的？

它看起来像是一笔正常的业务往来——客户A公司 -> 深圳投资公司 -> 海南某贸易公司 -> 客户指定的B账户。

但其实中间什么业务都没发生。钱只是在空壳公司的账户之间“旅行”了一圈，最后到了客户想让它去的地方，完成了洗钱-9。

作为数据开发，如果银行的反洗钱系统里有“资金归集”监测规则——多个上游账户频繁向同一个下游账户转入资金，且下游账户无实质经营——这些空壳公司的资金归集模式就会被识别出来。

第四幕：银行的反洗钱系统为什么会发现？

2009年1月，中国人民银行的反洗钱系统发出了一个信号-9。

信号触发的依据是几个“可疑特征”：

• 日交易量巨大：这20个账户，每天都有几十上百万的资金进出

• 交易频率异常：比正常做生意的公司频繁得多

• 近一个月交易总量大：短期内资金流量爆炸性增长

• 资金快进快出：钱进来，几乎不停留，马上转走——真正的生意不会有这种资金周转

系统把这些账户标记为“可疑”，自动生成了报告，推送给监管。警方介入后，从近10万条银行交易数据里，筛出了100多个可疑账户，经过逐一跟踪追查，最终锁定这20个公司账户-9。

第五幕：一层一层剥下去

那么，这20个账户是谁开的？开户人是谁？

警方查到，其中有7个账户的开户人是一个叫“曹斌”的湖南人。但查下去发现，这张身份证是假的——户口信息是曹斌的，照片却是谢冬伟的。因为银行规定必须本人到柜台开通网银、领取U盾，犯罪分子就伪造了一张身份证，用了曹斌的户口信息和谢冬伟的照片-9。

真正的“张总”就是刘越本人。这条链条就这样被公安机关揪了出来。

警方继续顺着资金流往下追：

从这20个空壳公司账户出发，追查每一笔资金去向——最终指向4473个账户，分布在29个省份。这些账户里，有个人账户，也有公司账户。不少是企业老板为了转移灰色资金，主动找刘总“帮忙”的-9。

作为数据开发，如果系统建立了“账户资金链路追踪”，从源头账户出发，追踪到一级流出账户、二级流出账户，直到资金“落地”——这些多层级、分散到大量账户的资金流转路径，在正常业务中是极不常见的，而洗钱资金链路正是这种特征。

第六幕：钱的真正来源

故事没有结束。顺着这些账户继续追，警方发现上游资金来自2337家公司-9。

有些是正规企业的灰色资金，想避税；

有些是网络赌博平台的赌资；

有些是非法集资的赃款。

每一个源头背后，都是一起上游犯罪——洗钱不是终点，它是犯罪链条上的“最后一公里”。

第七幕：这个故事给你的启示

作为大数据开发人员，你从银行反洗钱的角度可以关注以下几类数据特征：

你会接触到的几类“洗钱信号”

银行反洗钱系统的基础流程

【反洗钱数据流转】 交易发生 → 交易流水表新增记录 ↓ 【批量跑批】每日夜间ETL任务扫描当日所有交易 ↓ 【规则引擎】匹配异常特征 ├── 触发金额阈值（如单笔≥5万）→ 进入大额交易清单 └── 触发行为规则（如快进快出、公转私）→ 标记“可疑” ↓ 【生成报送数据】 ├── 大额交易报告 → 反洗钱监测中心 └── 可疑交易报告 → 反洗钱监测中心 ↓【监管核查】—— 如果银行漏报了，被查出就是千万级罚单

如果你在银行做反洗钱相关的数据开发

你可能会参与这些工作：

• 数据清洗：确保交易流水表准确、完整，时间字段无误

• 规则开发：配合反洗钱业务人员，把“快进快出”“公转私”等规则用SQL落地成定时任务

• 模型优化：针对新出现的洗钱手段（比如用虚拟货币收佣金的跑分洗钱-10），不断迭代监测模型

• 监管报送加工：按监管要求，生成可疑交易报告和大额交易报告的数据接口文件

为什么银行非常重视反洗钱？

2025年，一家大型银行因为反洗钱违规，被央行罚款6807万元，13名总行核心部门责任人被追责-4；另一家银行因未按规定履行客户身份识别义务、未按规定报送可疑交易报告等9项违规，被罚没约2527万元-1。

你的ETL任务出bug导致数据漏报，可能直接影响银行是否被罚。

洗钱的故事讲完了。反过来看，你作为银行大数据开发人员的工作，就是在这个链条的每一个节点上——用数据、用规则、用ETL——去发现那些不该发生的事。数据就是你的显微镜和追踪器。