银行业务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-3333Q查老张最近3个月的消费总额SELECT SUM(交易金额) FROM 信用卡交易流水表 WHERE 卡号 8888-... AND 交易时间 DATE_SUB(CURDATE(), INTERVAL 3 MONTH)Q查所有逾期超过30天的信用卡账户SELECT 卡号, 客户号, 已用额度, 逾期天数 FROM 信用卡账户表 WHERE 逾期天数 30信用卡 vs 贷款异同对比维度贷款信用卡额度形式合同金额一次性或分批提款信用额度循环使用交易方式放款到账户刷卡消费还款方式按计划还本息按账单还可选最低还款利息计算从放款日开始计息消费有免息期逾期/取现才计息账户状态借据余额到0后结清只要不注销一直有效核心表借据表、还款流水表信用卡账户表、交易流水表、还款流水表面试时你可以这样说信用卡和贷款逻辑类似但信用卡是循环额度。客户有一个信用额度每刷一笔交易流水表记一笔已用额度增加可用额度减少。每月账单日生成账单客户在还款日前还钱。如果还最低还款额剩余部分要收利息。申请分期的话分期表会记录分了多少期、每期还多少。举一个洗钱的案例故事这个故事改编自一起真实的特大洗钱案——海南“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。有些是正规企业的灰色资金想避税有些是网络赌博平台的赌资有些是非法集资的赃款。每一个源头背后都是一起上游犯罪——洗钱不是终点它是犯罪链条上的“最后一公里”。第七幕这个故事给你的启示作为大数据开发人员你从银行反洗钱的角度可以关注以下几类数据特征你会接触到的几类“洗钱信号”反洗钱信号数据特征对应你日常看到的字段快进快出资金到账后几分钟/几小时内就转走基本不过夜交易流水表的交易时间字段对比转入时间和转出时间公转私频繁公司账户频繁向个人账户转账金额分散交易流水表的账号类型对公/对私账户休眠后突然激活开户后长期无交易突然有大额进出账户表的开户日期和最近交易日期时间差很大多层嵌套转账A→B→C→D经过多个中间账户才到最终目的地交易流水表做“链路追踪”关联上下游账号交易规模与身份不符无固定职业的人账户月流水几百万客户信息表的职业字段 交易流水表聚合同一IP操作多个账户一个IP地址同时登录控制多个公司账户网银登录日志的IP地址账号维度聚合计数银行反洗钱系统的基础流程【反洗钱数据流转】 交易发生 → 交易流水表新增记录 ↓ 【批量跑批】每日夜间ETL任务扫描当日所有交易 ↓ 【规则引擎】匹配异常特征 ├── 触发金额阈值如单笔≥5万→ 进入大额交易清单 └── 触发行为规则如快进快出、公转私→ 标记“可疑” ↓ 【生成报送数据】 ├── 大额交易报告 → 反洗钱监测中心 └── 可疑交易报告 → 反洗钱监测中心 ↓【监管核查】—— 如果银行漏报了被查出就是千万级罚单如果你在银行做反洗钱相关的数据开发你可能会参与这些工作数据清洗确保交易流水表准确、完整时间字段无误规则开发配合反洗钱业务人员把“快进快出”“公转私”等规则用SQL落地成定时任务模型优化针对新出现的洗钱手段比如用虚拟货币收佣金的跑分洗钱-10不断迭代监测模型监管报送加工按监管要求生成可疑交易报告和大额交易报告的数据接口文件为什么银行非常重视反洗钱2025年一家大型银行因为反洗钱违规被央行罚款6807万元13名总行核心部门责任人被追责-4另一家银行因未按规定履行客户身份识别义务、未按规定报送可疑交易报告等9项违规被罚没约2527万元-1。你的ETL任务出bug导致数据漏报可能直接影响银行是否被罚。洗钱的故事讲完了。反过来看你作为银行大数据开发人员的工作就是在这个链条的每一个节点上——用数据、用规则、用ETL——去发现那些不该发生的事。数据就是你的显微镜和追踪器。