在金融科技圈待久了你会发现一个反直觉的现象预算年年涨外围系统越买越多但一线的客户经理和柜台人员却觉得系统越来越难用IT部门的排期永远排不完。我过去几年参与过好几家金融机构的数字化升级项目从股份制银行到保险公司再到持牌消金名字不方便提但踩过的坑、趟过的路都是相通的。这篇就围绕 financial-services 这个方向把我做金融服务数字化项目的完整思路和实操细节摊开讲适合金融机构的IT、业务、风控条线朋友也适合做金融科技外包、创业团队的同学参考。我说的金融服务数字化不是指上一个App、开几个小程序、搞一套SCRM就完事。真正的难点在于怎么在不动摇账务核心的前提下把客户旅程、业务规则、风控合规、数据能力全部串成一条现代化的链路。这套东西想清楚比选什么技术栈重要得多。1. 金融服务数字化这道题难的不是新技术是老系统留下的债务先聊一个很多非金融行业的朋友不理解的现象银行、保险、证券这些机构的核心系统很多还是十几二十年前甚至更早的技术栈有的还跑在大型机上。你可能会问为什么不直接换成现在流行的微服务架构答案很简单核心账务系统是金融行业的命根子它承载着存款、贷款、支付、清算这些绝对不能错账、绝对不能丢数据的业务替换成本极高、风险极大。我参与的项目里有一家银行光客户信息就散落在四套系统里核心系统一套客户号信用卡系统一套客户号零售信贷系统一套客户号理财代销系统又有一套。同一个客户在不同系统里性别、手机号都能对不上。这种数据孤岛系统烟囱的格局就是金融服务数字化最大的阻力。还有一个隐藏的瓶颈是批处理。传统金融系统有很强的日终批处理基因白天跑联机交易晚上跑批量任务——结息、对账、批量扣款、报表加工都堆在凌晨跑。我见过最夸张的案例跑批要跑到早上六点半比柜面开门时间还晚IT值班人员每天跟打仗一样。后来做优化把跑批任务按客户号哈希分片、并行调度硬生生把跑批时间压缩到凌晨三点半才给白天的实时业务留出足够的系统余量。所以我的第一个建议是做金融服务数字化先别急着推倒重来而是要先做系统盘点和依赖梳理。把每个系统的归属、接口协议、数据流向、批处理任务画成一张全景图。这一步通常要花掉项目前期三分之一的时间但绝对值回票价。你看清楚家底之后才会发现很多数字化需求其实是被老系统的接口效率卡住的而不是业务本身有多复杂。老系统的接口协议也相当分裂核心系统对外提供的是CICS事务接口或者XML格式的WebService信用卡系统是专有的Socket报文外围的新系统则是标准的RESTful API。这个阶段最适合做的就是接口网关消息总线的过渡架构——对外统一暴露标准化接口内部用异步消息把老系统的响应时间稀释掉。说白了就像一栋不断加盖的老楼你要做的是加几部数据电梯和统一的消防通道而不是把楼拆了重盖。2. 从客户旅程下手才能真正让业务感受到数字化很多金融机构做数字化上来就定指标App要装多少、MAU要涨多少。但真正让业务方觉得系统好用了是从客户旅程的重构开始的。我把一个最典型的例子讲透线上贷款申请。改造前一条贷款申请要走这样的流程客户到网点填纸质申请书客户经理手工录入信贷系统。客户经理去征信系统查征信人工判断是否符合准入。提交审批审批人线下看材料逐级签批快则两三天慢则一周。审批通过后通知客户到网点签纸质合同再提交放款岗放款。整个过程7到10天客户体验差客户经理也被文书工作淹没。我们当时的目标很简单把全流程压缩到分钟级客户在手机银行上就能完成申请到放款。这个目标拆到系统层面其实是一串组件的编排身份认证人脸识别活体检测身份证OCR银行卡四要素姓名、身份证、卡号、手机号校验。征信授权与查询线上授权征信查询对接人行征信接口、百行征信、第三方大数据源。规则准入把过去的准入政策年龄、地区、职业、征信逾期次数、负债率等配置进规则引擎自动预审批。电子签约CA数字证书、时间戳、电子合同存证确保法律效力。自动放款放款系统对接账务核心实时记账、实时出账。触达通知短信、App Push、微信服务号模板消息关键节点自动通知。客户体验上压缩成一个动作申请背后却是十几个系统的协同。这里有个工程重点同步调用和异步解耦必须分清楚。像身份认证、征信查询、实时审批这些步骤必须同步等待结果而像征信授权记录归档、合同存证上链、通知发送这类不阻塞主流程的一律扔到消息队列里异步处理。我们当时踩过的一个教训是一开始把合同生成做成了同步调用结果电子签章服务在高峰期响应慢把整个申请链路拖到十几秒客户以为卡死了疯狂重试反而加重了系统压力。后来改成提交申请即受理、合同后台异步生成存证、签约环节再实时拉取问题立刻缓解。做旅程重构还需要在每个步骤上做技术埋点人脸上传耗时、OCR识别耗时、征信接口耗时、审批规则执行耗时、放款接口耗时全部落到日志平台。为什么强调这个因为金融系统的链路长任何一个环节变慢都没人说得清只有把每个环节的耗时和成功率可视化才能知道瓶颈在哪。我们当时上线后第一周靠这些指标抓出了两个第三方数据源接口的慢查询直接推动供应商做了优化。3. 中台不是概念是账户、产品、风控三类服务实实在在的微服务化聊完客户旅程再往深一层走。金融服务数字化的技术底座基本绕不开中台这两个字。但我不太想把它讲成玄学落到实处就是把原来一个个大而全的单体系统按业务能力拆成可以独立部署、独立扩展、独立运维的微服务。在金融场景里最值得优先拆的是三类账户类账户查询、余额变动、交易流水、冻结解冻。产品类产品定义、定价、额度、期限、还款计划。风控类准入规则、额度计算、反欺诈、名单筛查。拿信贷领域举例我们把原来一个综合授信系统拆成了四个独立中心额度中心、定价中心、合同中心、放款中心。为什么这么拆因为它们的变更频率完全不同。利率定价可能一个月调好几次合同模板一个季度才动一次放款逻辑更是半年都不一定碰。混在一个单体里任何一次小改动都要整个系统回归测试发版窗口掐得很死。拆开以后改定价中心根本不影响放款中心上线频率从一个月一次提升到一周两三次对业务响应速度快得多。拆服务有个必须强调的点幂等设计。金融服务最怕重复扣款、重复放款。放款中心对外提供的接口要求调用方必须传业务流水号数据库里用业务流水号唯一索引做约束同一个流水号重复调用第二次直接返回第一次的结果而不是再执行一次。这个设计看似简单但没有它任何网络超时重试都可能制造资金安全事故。我们当时还做过测试把放款接口在超时场景下重放了50次账务余额始终只变动一次才敢放心交给业务使用。还有一个选型问题是分布式事务。金融系统对数据一致性要求极高但不是所有场景都要强一致。我的经验是账务核心的余额变动必须强一致这部分留在核心不动外围服务通过接口调用本质上还是依赖核心的强一致保证而像进件信息同步、审批状态流转这类场景用本地消息表或者MQ最终一致性就够了。最怕的是不分场景一律上分布式事务框架性能开销大不说排起错来能把人逼疯。中台落地的节奏也很重要。不可能一次性把所有系统都微服务化我们当时的方法是先用二到三个月做接口收敛把老系统散乱的接口收拢到网关统一认证、统一限流再挑一两个高频业务场景做服务拆分试点跑稳之后再逐步扩大。这个节奏既控制风险也让团队有时间建立微服务治理的配套能力。4. 风控合规要长在业务流程里而不是挂在外面当摆设金融服务和其他互联网产品最大的差别就是头顶上始终悬着风控合规这把剑。KYC了解你的客户、反洗钱、适当性管理、监管数据报送哪一样没做好都可能演变成真金白银的罚单和声誉损失。我见过很多团队的做法是先上线业务风控规则之后再补。这在金融行业是绝对行不通的。合规必须从一开始就参与流程设计风控能力必须作为一个基础服务嵌入到业务链路里。在系统层面我们一般把风控拆成三个层次事前准入客户申请进件时实时调用风控引擎跑准入规则、评分卡、黑名单筛查直接决定批不批。事中监控交易发生时通过实时计算引擎比如FlinkKafka做异常行为识别。比如短时间内连续小额试探、深夜大额转账、收款账户在历史交易中从未出现过这些特征都会触发反欺诈拦截。事后分析跑批扫描存量交易识别可疑交易模式生成反洗钱可疑交易报告同时保留完整的审计日志。规则引擎在金融风控里地位非常高。我们用的是开源Drools加自研规则管理界面业务人员和风控人员可以自己在界面上配置规则不需要每次改规则都走IT排期。但这里有个关键点规则的变更要有版本管理和审批流。我们一开始图省事允许风控同学直接改线上规则结果有一次规则条件写错把一个正常的客群全拒了半小时后才发现损失了一大批业务进件。从那以后所有规则变更必须走测试环境验证→灰度环境生效→全量发布的流程改动记录可追溯。合规留痕这块也容易被低估。现在金融监管都要求业务全链路可追溯我们当时做了一个贯穿所有服务的traceId链路追踪从App点击到最终放款每一步的请求参数、返回结果、处理人、时间戳全部落库。再配合电子合同存证证书、时间戳、哈希上链一旦产生纠纷这些就是完整的证据链。还有一件事我想单独提醒适当性管理。做财富管理、保险销售这类金融服务必须做客户风险承受能力评估产品风险等级要跟客户风险等级匹配。这个逻辑听起来简单但落地时牵扯到产品端、销售端、客户端的多方校验。经常出现的情况是客户风险测评过期了系统还让他继续买高风险产品。设计上要把风险测评有效期写进交易前置校验过期就拦截引导客户重新测评。这既是合规要求也是客户保护。5. 数据架构和安全既要打通又不能乱打通金融服务数字化的另一个重头戏是数据。业务方天天喊数据打通但数据架构师心里要有一杆秤什么数据能打通、什么数据只能脱敏后使用、什么数据连碰都不能碰边界必须非常明确。先聊打通的部分。主数据管理是基础客户、账户、产品、渠道、员工这几类主数据必须有一个权威来源。我们当时的做法是建集中式客户信息中心各系统通过接口或数据同步订阅客户主数据逐步收敛原来散落在各系统的客户号。这个过程很痛苦因为涉及老系统改造和历史数据清洗但它是后续所有数据应用的地基。往上层走是数据平台的建设。传统金融的数仓链路是ODS→数仓→数据集市→BI报表链条长、时效低T1是常态。为了支持实时风控和实时经营分析我们在原有数仓旁边搭了一条实时数据管道用Debezium做数据库变更捕获接入Kafka再同步到OLAP引擎。现在很多业务场景比如实时大额交易监控、实时客户流失预警都跑在这条实时管道上。数据安全是金融数据的生命线。有几点是必须做到的传输加密所有敏感数据接口走TLS禁止明文传输。存储加密客户敏感字段在数据库里AES加密存储密钥单独管理、定期轮换。脱敏展示手机号、身份证号、银行卡号在应用层动态脱敏不是把所有环境的数据都改掉而是根据访问者角色实时决定能看到什么。柜员查客户信息只显示中间四位风控专员经过授权才能看完整字段。字段级权限不同角色对同一张表的同一字段权限不同这个要通过统一数据访问层控制而不是每个应用自己实现一套。近两年隐私计算在金融行业越来越受关注联邦学习、多方安全计算、可信执行环境这些技术解决的是数据可用不可见的问题。典型的场景是多家金融机构联合做反欺诈模型各家不出库自己的客户数据但通过联邦学习训练出一个共享的风控模型既保护各家数据隐私又提升了整体的风险识别能力。我们当时试点过一个小范围的反欺诈联邦学习项目效果确实比单家数据训练的模型好不少但工程复杂度确实高对算法团队的要求也高不是所有机构都适合马上上。6. 复盘时刻五个让我印象深刻的坑讲完大框架最后盘点几个我实际踩过或者亲眼见过的坑。这些坑看起来都不大但每一个都足够让项目延期、让团队焦头烂额。第一个坑是缓存和账务不一致。我们曾为了让余额查询不拖垮账务核心把账户余额放到了Redis缓存里结果转账完成后缓存更新失败客户看到余额没变又发起了一笔转账最后账实不符。处理这种问题我的原则很干脆余额这种强一致数据要么不缓存要么缓存只做展示、不做交易校验交易强校验永远走数据库。你省下来的那点数据库压力远不够填一次资金差错事故的坑。第二个坑是大批量任务跟实时交易抢资源。有一段时间系统每到整点就卡顿排查半天发现是某个数据同步任务每小时整点启动把数据库IO打满了。金融系统最怕这种定时任务扎堆和批量任务无资源限制。治本办法是资源隔离加错峰调度批量任务和实时交易分别部署或者限制批量任务的并发度和IO优先级。第三个坑是外包系统的黑盒改造。金融行业有大量系统是第三方厂商建设的合同期内还好合同期外厂商配合意愿低接口文档和实际行为经常对不上。我们对接过一个贷款核心系统文档里写返回码0000表示成功实际联调时发现还有0001表示部分成功差点搞出资金事故。这类问题只能靠制度规避对外包系统的接口要做契约测试关键接口要有运维SLA合同里明确出问题时的响应时效别等踩雷了再谈。第四个坑是测试环境数据脱敏不到位。测试和联调需要真实结构的数据但直接用生产数据拷贝到测试环境手机号、身份证全是真实的一旦测试环境防护薄弱泄露出去合规上就是大问题。我们后来建了一套自动脱敏工具链生产数据在导出到测试环境时自动完成变换姓名打码、身份证号改为不存在的合法格式、手机号随机化才把这类风险收敛住。第五个坑是管理层对敏捷开发的误解。有些领导以为敏捷就是可以天天变需求、不用写文档、不用做设计评审结果导致迭代计划完全失控。金融系统变更是要承担风险的再怎么敏捷需求变更要过变更评审代码要过代码评审重要文档可以精简但不能消失。我们当时的做法是迭代节奏可以快但变更管控的红线一步不退。我做了这么多年金融服务相关项目最大的体会是金融数字化成不成功不取决于你用了多新的技术而是取决于业务、技术、风控、合规这几条线能不能拧成一股绳。系统拆了可以再建流程错了可以再造但信任一旦因为一次事故崩塌要花十倍的时间才能补回来。希望这篇复盘能帮同行少走几步弯路也欢迎有类似经历的朋友多交流。
