我一直覺得“financial-services”這個(gè)提法在行業(yè)里有點(diǎn)被用濫了——一說金融服務(wù)好像就是銀行柜員、保險(xiǎn)推銷、理財(cái)銷售這三件套。但真正在這個(gè)賽道里摸爬滾打過的人都知道金融服務(wù)是一個(gè)包羅萬象的復(fù)雜生態(tài)從支付清算到財(cái)富管理從風(fēng)控建模到合規(guī)審計(jì)每一層都有自己的門道。這篇文章不打算寫那種“金融行業(yè)入門指南”式的綜述而是想把我在金融科技FinTech一線做項(xiàng)目、做產(chǎn)品、踩坑填坑的真實(shí)經(jīng)驗(yàn)整理出來。內(nèi)容覆蓋服務(wù)設(shè)計(jì)、系統(tǒng)架構(gòu)、風(fēng)控策略、監(jiān)管合規(guī)四個(gè)核心板塊既適合剛?cè)胄邢虢⑷忠曇暗男氯艘策m合已經(jīng)在做具體業(yè)務(wù)、想回頭看看整體邏輯的從業(yè)者。我會把每一個(gè)關(guān)鍵決策背后的“為什么”講透比如為什么支付系統(tǒng)要這么設(shè)計(jì)、為什么風(fēng)控模型要這樣調(diào)參、為什么合規(guī)不是法務(wù)部門一個(gè)部門的事——這些東西教科書里不會講只有真刀真槍做過項(xiàng)目才會有體感。1. 金融服務(wù)到底在解決什么問題1.1 拆掉“金融服務(wù)”的行業(yè)濾鏡很多人對金融服務(wù)的第一印象是“離錢近、門檻高、規(guī)則多”。這話對了一半。金融服務(wù)的本質(zhì)其實(shí)是在解決三個(gè)最基本的問題信任缺失、信息不對稱、風(fēng)險(xiǎn)錯(cuò)配。你愿意把錢存進(jìn)銀行而不是藏在床底下不是因?yàn)榇驳撞话踩且驗(yàn)殂y行給了你一個(gè)“本金可兌付”的信任承諾。你借錢給一個(gè)陌生人做生意最大的顧慮不是他有沒有商業(yè)頭腦而是他會不會還錢——這就是信息不對稱。而風(fēng)控要做的事就是在這個(gè)不對稱的信息場里把“他會不會還錢”這件事從玄學(xué)變成概率學(xué)。所以做金融服務(wù)的人做的不是“錢生錢”的魔術(shù)而是用制度、技術(shù)和數(shù)據(jù)去壓縮不確定性。想明白這一點(diǎn)很多產(chǎn)品設(shè)計(jì)、系統(tǒng)架構(gòu)上的決策就會變得清晰起來一切為降低不確定性服務(wù)的功能都值得投入資源一切讓不確定性增加的流程都應(yīng)該被砍掉或者加一道閘。1.2 金融服務(wù)的技術(shù)棧演變從IOE到分布式國內(nèi)金融系統(tǒng)的技術(shù)棧演進(jìn)本身就是一部濃縮的行業(yè)史。早年的大型機(jī)集中式數(shù)據(jù)庫典型的IOE架構(gòu)IBM小型機(jī)、Oracle數(shù)據(jù)庫、EMC存儲統(tǒng)治了金融核心系統(tǒng)將近二十年。這套架構(gòu)的優(yōu)勢是穩(wěn)定、可靠單機(jī)性能強(qiáng)悍維護(hù)起來也有成熟的標(biāo)準(zhǔn)流程。但它的劣勢同樣明顯貴、擴(kuò)展性差、被廠商綁定。我記得剛?cè)胄袝r(shí)帶我的老前輩說過一句話“銀行系統(tǒng)的第一原則不是快是穩(wěn)。一臺機(jī)器掛了整個(gè)分行網(wǎng)點(diǎn)都取不了錢這個(gè)責(zé)任誰扛得住”這句話解釋了為什么金融行業(yè)對新技術(shù)總是慢半拍——不是守舊是真的經(jīng)不起折騰。但這幾年趨勢已經(jīng)變了。隨著移動(dòng)支付、消費(fèi)信貸、線上理財(cái)這些業(yè)務(wù)的爆發(fā)集中式架構(gòu)的瓶頸越來越明顯。雙十一這種量級的峰值流量IOE架構(gòu)幾乎不可能扛住。于是行業(yè)開始大規(guī)模轉(zhuǎn)向分布式架構(gòu)用一堆普通的x86服務(wù)器替代昂貴的小型機(jī)用分布式數(shù)據(jù)庫替代Oracle用消息隊(duì)列做異步解耦用微服務(wù)拆散巨石應(yīng)用。這個(gè)轉(zhuǎn)型過程我完整經(jīng)歷過感受最深的一點(diǎn)是分布式架構(gòu)解決的不僅是性能問題更是組織問題。集中式架構(gòu)下所有業(yè)務(wù)邏輯都耦合在一個(gè)系統(tǒng)里改一個(gè)理財(cái)產(chǎn)品需求要牽動(dòng)十幾個(gè)團(tuán)隊(duì)的排期。拆成微服務(wù)之后每個(gè)團(tuán)隊(duì)可以獨(dú)立迭代自己負(fù)責(zé)的服務(wù)效率提升是幾何級的。但分布式也帶來了新麻煩數(shù)據(jù)一致性、分布式事務(wù)、鏈路追蹤、服務(wù)治理。原來在一臺機(jī)器里能靠數(shù)據(jù)庫事務(wù)搞定的事拆到幾十個(gè)服務(wù)里之后就得靠TCC、SAGA、消息補(bǔ)償這些“反人類”的方案去實(shí)現(xiàn)。這個(gè)代價(jià)很多團(tuán)隊(duì)在拆之前是沒想清楚的。2. 核心業(yè)務(wù)域拆解支付、信貸、財(cái)富管理2.1 支付系統(tǒng)金融服務(wù)的“水電煤”如果說金融服務(wù)是一棟大廈支付系統(tǒng)就是大廈的水電煤管道——平時(shí)沒人注意一旦出問題就是大事。支付系統(tǒng)的核心不是“把錢從A轉(zhuǎn)到B”這么簡單而是一套嚴(yán)謹(jǐn)?shù)臓顟B(tài)機(jī)在背后運(yùn)轉(zhuǎn)。一筆支付從用戶點(diǎn)擊“確認(rèn)支付”到最終結(jié)算完成中間會經(jīng)歷交易創(chuàng)建、支付請求、渠道受理、銀行/第三方扣款、回調(diào)通知、對賬、結(jié)算。每一步都有對應(yīng)的狀態(tài)待支付、支付中、成功、失敗、退款中、已退款?？雌饋砗芎唵蔚嬲龔?fù)雜的場景是部分成功——比如用戶的錢已經(jīng)被銀行扣了但回調(diào)通知因?yàn)榫W(wǎng)絡(luò)超時(shí)丟了你這邊顯示支付失敗用戶的錢卻少了。這個(gè)場景怎么解靠的是支付對賬和最終一致性。每天晚上系統(tǒng)自動(dòng)拉取銀行側(cè)的清算文件和自己數(shù)據(jù)庫里的交易記錄做逐筆比對。發(fā)現(xiàn)不一致的單子再走差錯(cuò)處理流程。做了三年支付項(xiàng)目之后我對“對賬”這件事的敬畏心是拉滿的它不性感不炫酷但沒了它支付系統(tǒng)再穩(wěn)也是空中樓臺。2.2 信貸風(fēng)控從人工經(jīng)驗(yàn)到模型驅(qū)動(dòng)的進(jìn)化信貸業(yè)務(wù)是整個(gè)金融服務(wù)體系里利潤最厚、風(fēng)險(xiǎn)也最高的板塊。早年做信貸審批靠的是信貸員跑線下、查征信、看流水、問鄰里一套流程下來少則一周多則一個(gè)月。這套模式的問題不是不準(zhǔn)而是太慢、太貴、太依賴個(gè)人經(jīng)驗(yàn)。現(xiàn)在的消費(fèi)金融和中小微貸款業(yè)務(wù)基本已經(jīng)轉(zhuǎn)向自動(dòng)化審批 人工兜底的模式。核心是構(gòu)建一套風(fēng)險(xiǎn)評分體系反欺詐模型識別團(tuán)伙欺詐、身份冒用、設(shè)備指紋異常信用評估模型依據(jù)征信、電商消費(fèi)、社交行為等數(shù)據(jù)預(yù)測違約概率額度定價(jià)模型根據(jù)風(fēng)險(xiǎn)等級動(dòng)態(tài)匹配額度與利率模型用什么算法傳統(tǒng)邏輯回歸和決策樹XGBoost、LightGBM依然占據(jù)主流地位。原因很簡單金融行業(yè)對模型的可解釋性要求極高——監(jiān)管問你“為什么拒絕這個(gè)客戶”你不能答“因?yàn)樯疃葘W(xué)習(xí)模型說不行”。這也是為什么很多互聯(lián)網(wǎng)公司引以為傲的深度學(xué)習(xí)模型到了金融場景反而落不了地。2.3 財(cái)富管理從賣產(chǎn)品到做配置財(cái)富管理這個(gè)板塊在金融行業(yè)里的地位過去十年發(fā)生了根本性變化。早年的理財(cái)銷售邏輯是“產(chǎn)品銷售導(dǎo)向”行員有銷售指標(biāo)哪個(gè)產(chǎn)品提成高就推哪個(gè)客戶只是被當(dāng)成銷售渠道的終端。這種模式有天然的缺陷——不管客戶的風(fēng)險(xiǎn)承受能力如何都推激進(jìn)型產(chǎn)品一旦市場波動(dòng)客戶虧損信任關(guān)系就徹底崩塌?，F(xiàn)在行業(yè)普遍在往買方投顧轉(zhuǎn)型。核心是先把客戶的風(fēng)險(xiǎn)偏好測清楚KYC再基于資產(chǎn)配置模型去做組合建議。說白了不是幫客戶買“最好的”產(chǎn)品而是幫客戶買到“最適合他的風(fēng)險(xiǎn)收益結(jié)構(gòu)”。這個(gè)理念的轉(zhuǎn)變對系統(tǒng)建設(shè)提出了很高要求需要客戶畫像系統(tǒng)、資產(chǎn)配置模型、組合再平衡引擎、投后跟蹤報(bào)表——一套完整的數(shù)字化基建才能支撐起來。3. 風(fēng)控基建從策略到模型的系統(tǒng)工程3.1 風(fēng)控不是一堆規(guī)則的堆砌很多業(yè)務(wù)方對風(fēng)控的理解是“越多規(guī)則越安全”——命中任何一條風(fēng)控規(guī)則就拒絕交易。這種思路在業(yè)務(wù)量小的階段沒什么問題但一旦業(yè)務(wù)規(guī)模上來規(guī)則之間的沖突和誤殺率就會失控。我見過一個(gè)真實(shí)案例某平臺為了防套現(xiàn)加了一條“同一設(shè)備一天內(nèi)綁定超過3張信用卡則觸發(fā)人工審核”的規(guī)則。結(jié)果上線之后正常代購用戶大量中招客訴率暴漲。原因很簡單——代購用戶本來就要頻繁更換支付卡這條規(guī)則把正常行為誤判成了風(fēng)險(xiǎn)行為。好的風(fēng)控體系應(yīng)該是一個(gè)分層遞進(jìn)的漏斗第一層實(shí)時(shí)反欺詐攔截處理高置信度風(fēng)險(xiǎn)事件盜刷、薅羊毛第二層風(fēng)險(xiǎn)評分和動(dòng)態(tài)決策將中低風(fēng)險(xiǎn)訂單轉(zhuǎn)入人工復(fù)核第三層離線規(guī)則和模型調(diào)優(yōu)基于歷史數(shù)據(jù)持續(xù)優(yōu)化策略這套體系的關(guān)鍵不是“更嚴(yán)”而是“更準(zhǔn)”。每新增一條規(guī)則都要同步評估它的攔截率和誤殺率——攔截率再高如果誤殺了一堆正?？蛻裟且彩翘澋?。3.2 樣本、特征與模型風(fēng)控工程師的日常風(fēng)控模型的落地過程說穿了就四步樣本準(zhǔn)備、特征工程、模型訓(xùn)練、效果評估。樣本準(zhǔn)備是第一步也是最花時(shí)間的。在信貸場景里好樣本按時(shí)還款和壞樣本逾期90天以上的定義要清晰而且要處理好樣本的時(shí)間切片——你用2018年的數(shù)據(jù)訓(xùn)練模型去預(yù)測2023年的客戶行為中間經(jīng)濟(jì)環(huán)境、客群結(jié)構(gòu)早就變了模型效果必然會衰減。這就是金融模型特有的樣本時(shí)效性問題。特征工程的核心是從數(shù)據(jù)里挖出有區(qū)分度的變量。常用的有用信比客戶用了多少授信額度、近六個(gè)月查詢次數(shù)申了多少次貸款、夜貓子指數(shù)凌晨交易占比這類指標(biāo)常用于反欺詐場景。特征的區(qū)分度可以用IV值Information Value來量化行業(yè)慣例是IV值在0.1到0.3之間的特征是“中等預(yù)測力”小于0.1的基本可以放棄。模型訓(xùn)練完成之后的復(fù)盤同樣重要。KS值Kolmogorov-Smirnov檢驗(yàn)和AUC是風(fēng)控模型最常用的兩個(gè)評估指標(biāo)但實(shí)操里我建議多關(guān)注一個(gè)東西策略回放。拿過去一段時(shí)間的真實(shí)交易數(shù)據(jù)把新模型跑一遍看看如果當(dāng)時(shí)就上線這個(gè)模型哪些交易結(jié)果會不一樣?；胤抛鐾曛竽銜l(fā)現(xiàn)模型在離線評估里看著很亮眼一放到真實(shí)線上場景就各種水土不服——這就是理論和實(shí)操的溫差。4. 合規(guī)與安全做金融服務(wù)的“高壓線”4.1 數(shù)據(jù)合規(guī)不是法務(wù)一個(gè)人的事這幾年金融行業(yè)對數(shù)據(jù)合規(guī)的要求越來越嚴(yán)尤其是個(gè)人隱私保護(hù)相關(guān)的法規(guī)落地之后整個(gè)行業(yè)都在補(bǔ)課。但很多公司把數(shù)據(jù)合規(guī)當(dāng)成法務(wù)部門的事業(yè)務(wù)和技術(shù)部門就看個(gè)熱鬧這是大錯(cuò)特錯(cuò)的。數(shù)據(jù)合規(guī)必須貫穿到系統(tǒng)的每一個(gè)設(shè)計(jì)決策里數(shù)據(jù)采集環(huán)節(jié)不能偷雞。拿到了超出業(yè)務(wù)場景必要范圍的數(shù)據(jù)就是違規(guī)。很多App被通報(bào)下架問題都出在“超范圍采集個(gè)人信息”上。數(shù)據(jù)傳輸環(huán)節(jié)加密是標(biāo)配。不管是客戶端到服務(wù)端還是服務(wù)到服務(wù)之間數(shù)據(jù)都要加密傳輸。密鑰管理要單獨(dú)一套體系不能寫死在代碼里。數(shù)據(jù)存儲環(huán)節(jié)敏感字段必須脫敏加密。手機(jī)號、身份證號不能明文存庫。哪怕數(shù)據(jù)庫被拖走了拿到的也是密文。我在實(shí)際項(xiàng)目中踩過一個(gè)坑某業(yè)務(wù)方為了開發(fā)調(diào)試方便要求數(shù)據(jù)庫里的手機(jī)號明文返回給前端。開發(fā)圖省事就同意了結(jié)果被安全團(tuán)隊(duì)掃描出來要求整改。來回折騰了兩周才搞定。這個(gè)教訓(xùn)的核心是數(shù)據(jù)合規(guī)如果不在架構(gòu)設(shè)計(jì)階段就考慮進(jìn)去后面再補(bǔ)就是災(zāi)難級的成本。4.2 技術(shù)安全從滲透測試到安全運(yùn)營金融系統(tǒng)是黑客眼中的“高價(jià)值目標(biāo)”所以安全建設(shè)標(biāo)準(zhǔn)也比一般行業(yè)高得多。常規(guī)的安全工作包括滲透測試定期請外部團(tuán)隊(duì)模擬攻擊、安全開發(fā)SDL把安全檢測嵌入到開發(fā)流程、安全監(jiān)控SIEM/SOC運(yùn)營、應(yīng)急響應(yīng)出事了怎么快速止血。這里我想特別糾正一個(gè)誤解很多團(tuán)隊(duì)以為上了Web應(yīng)用防火墻WAF就高枕無憂了。實(shí)際上WAF只能攔已知的、特征明顯的攻擊。對于業(yè)務(wù)邏輯漏洞比如越權(quán)訪問、支付金額篡改這種只要改個(gè)參數(shù)就能出的問題WAF一點(diǎn)忙都幫不上。安全的核心還是靠“開發(fā)自己寫安全代碼 安全團(tuán)隊(duì)做審查兜底”這條雙保險(xiǎn)路線。5. 金融服務(wù)的未來趨勢與個(gè)人建議5.1 銀行核心系統(tǒng)國產(chǎn)化替代的進(jìn)程前面提到的IOE架構(gòu)現(xiàn)在整個(gè)行業(yè)都在做國產(chǎn)化替代。這個(gè)替代不是簡單的“換一個(gè)數(shù)據(jù)庫軟件”那么簡單背后牽扯的是整個(gè)生態(tài)鏈的遷移操作系統(tǒng)、中間件、數(shù)據(jù)庫、芯片每一層都要適配。我在實(shí)際項(xiàng)目里最深的感覺是一套核心系統(tǒng)跑得好好的本來沒必要?jiǎng)拥咭缶褪亲畲笮枨笏灾荒苡仓^皮上。這條賽道的技術(shù)難度在于分布式數(shù)據(jù)庫的強(qiáng)一致性方案還不成熟尤其是金融核心場景里“轉(zhuǎn)賬1分錢都不能錯(cuò)”這種強(qiáng)要求對分布式事務(wù)處理能力提出了極高要求。不過換個(gè)角度看這也是技術(shù)產(chǎn)品團(tuán)隊(duì)的機(jī)會——誰能在兼容性和性能上把這套基建做穩(wěn)誰就能吃到未來五年最大的技術(shù)紅利。5.2 當(dāng)下最值得做的三件事如果你在金融服務(wù)業(yè)做技術(shù)或產(chǎn)品我個(gè)人建議把精力放在這三塊數(shù)據(jù)治理搞清楚你有哪些數(shù)據(jù)、數(shù)據(jù)質(zhì)量如何、模型風(fēng)控從規(guī)則體系升級到模型驅(qū)動(dòng)、開放生態(tài)通過API把金融服務(wù)嵌入到更多場景里。數(shù)據(jù)治理看起來不“炫技”但它是一切模型和AI應(yīng)用的基礎(chǔ)。你連客戶到底在系統(tǒng)里有多少個(gè)重復(fù)ID都查不清楚還談什么千人千面的精細(xì)化運(yùn)營模型風(fēng)控是利潤與風(fēng)險(xiǎn)的平衡器做得好壞直接影響業(yè)務(wù)能不能賺到錢。開放生態(tài)則是未來的增長點(diǎn)金融服務(wù)的邊界會被場景需求切割得越來越細(xì)誰先卡住場景誰就有話語權(quán)。5.3 最后分享一個(gè)實(shí)操中的坑和心得文章末尾分享一個(gè)我這幾年做過最有價(jià)值的決定給每一個(gè)金融業(yè)務(wù)系統(tǒng)都加了“全鏈路追蹤”能力。一開始很多同事不理解覺得這玩意兒又不能直接產(chǎn)生業(yè)務(wù)價(jià)值純粹增加開發(fā)工作量。但到線上出問題的時(shí)候這套東西的價(jià)值就體現(xiàn)出來了——用戶報(bào)障說“支付成功了錢沒到賬”你沿著traceID一查發(fā)現(xiàn)卡在渠道服務(wù)對賬失敗的環(huán)節(jié)幾分鐘就能定位到根因。沒有全鏈路追蹤之前這種問題排查至少半天起步還得拉上好幾個(gè)團(tuán)隊(duì)的負(fù)責(zé)人一起開會復(fù)盤。能上系統(tǒng)的都盡量做可觀測不要為了眼前的一點(diǎn)點(diǎn)開發(fā)效率犧牲運(yùn)維期的時(shí)間和精力。這個(gè)原則從我做了第一代支付系統(tǒng)沿用至今適用于金融服務(wù)也適用于任何復(fù)雜業(yè)務(wù)系統(tǒng)。做金融這行穩(wěn)比快重要看得清比藏得住重要。