2019-02-05：金融風控系統設計 - 外匯管理風控系統
胖子釣魚
https://www.jianshu.com/p/e0609b5ba0d4
2019.02.05 14:06:01
字數 3,227閱讀 1,576
無際致力於金融科技對銀行、融擔、互聯網金融行業的基於供應鏈金融爲核心的互聯網化金融風控技術的輸出。涵蓋了互聯網信貸核心的系統建設，基於Spark[Spark ML, Spark Streaming(Flink 替換中)，Spark Graphx]技術體系的信貸風控系統建設，以及長期爲合作伙伴提供有效的低風險資產的流量業務。在經歷了從銀行到互聯網金融公司到科技輸出行金融科技公司的歷程後，筆者希望能夠將對行業及系統設計的理解做以分享。
本文共分爲三部分（外資銀行的外匯交易系統風險建設，互聯網金融個人風控系統建設，供應鏈金融中小企業風控系統建設）
外資銀行的風險系統建設
該部分更多介紹一下外匯交易系統風險控制的業務層面，技術上的確無創新之處，加上大量使用三方廠商的系統，在此感謝IBM MQ、Webmethod跟Oracle爲該行提供大量的便利，在這家銀行裏，我們看不到Tomcat, Jetty, 看不到Spring Cloud，Dubbo，ZooKeeper，沒有人理會微服務，大家連Yarn跟Hadoop啥關係都不知道。從技術角度到也單純，能買的就不做。特別是竟然拿着ITIL去指導DevOps，搞個Jenkins就叫做CI， CD了（我都沒見到過一個正經能跑的自動化Test Case），系統跑批幾乎都是各種存儲過程（不得不說，銀行的確交易信息多流水大，加上以前對數據平臺的構建不完善，國內銀行很多也是如此，這些批處理無非就是業務型的處理統計、補賬、代收付、息費計算、清結算等等的工作，圍繞着銀行的核心業務：存貸款、資金資產管理、理財及卡業務、中間業務來完成不論日終還是日間），這裏的JVM調優靠的是買硬件（似乎印證了筆者17年前工作的一家公司的老總說過，別看咱軟件做的不行，咱有錢，硬件補…賊豪）另外，最不習慣的就是在用SVN，不知道Git爲何物，再小的小工具，也不會去嘗試JHipster。筆者曾做過一個基於Nodejs的小工具，被別的組的人嘲笑半天，說js還能做生產環境的工具…但是做Quants的人在用Haskell包個計算引擎，也做了一些DSL的實踐，有機會把我瞭解到的再跟大家分享。在這裏的三年半時間，讓我學會了扯皮，更加體會到不做不錯的道理。
2012年底有機會進入一家非常有名的外資銀行從事系統建設工作，當時主要的工作是完成Murex2000到Murex3.1的升級項目，該項目很大，大到項目的需求及前期討論花了1年多的時間，最終產物除了各級海外高層領導的審批之外，建立了TOM文檔。（TOM: Target Of Model）也就是這個項目最終要達成的目的，對現有業務的影響，對現有系統的改造。說實話，這個項目也讓我見識了爲啥外資行的系統如此龐大，如此複雜，當然除了必須符合KYC，GAAC，Anti-Laundry 及銀行的監管特性外，以互聯網化視角看到的很多系統都冗餘的不行，加上極大的人員浪費（一個項目2Program Manager，4-5個Project Manager，一大堆BA，當然還有一幫沒啥用的Technical BA - 沒人知道爲啥弄這麼個職位，他們的確不是架構師，最多懂一些系統的配置和流程的改動及垂直領域業務；真正幹活的幾本都是國人；的確不懂爲啥，動不動就弄一大幫人跑到新加坡出差，上線都跑到倫敦去上 - 這個倒是有點道理，畢竟很多Trader在英國）。整個系統建設初步估算4-5年，當然包含了系統遷移，數據遷移，各種UAT， UVT， Rollout等。回到項目本身，Murex可以說是外匯交易管理系統Vendor中的絕對老大，公司名氣大，系統大，訂單金額大，Consultant的架子大。做過資金、外匯交易管理的人都知道Summit/Murex/Calypso 三家公司，說實話，如果從技術角度選個合適的中臺，我會選Calypso（可能因爲對Java框架情有獨鍾）；如果選大而全的，不論從支持的產品角度（能想到的Option的，Vanilla的，衍生品，押品，Fx的各種），還是從功能角度：能MSL（Murex Script Language），各種Pre-Trade，Post-Trade的Setup，定價，Curve & PnL，又能出策略，算各種VaR，又能錄交易看Cash， PV， NPV還能跟後臺操作不管Paper Confirmation， Electronic Confirmation（Swift）還是各種結算，審計， 財務，對賬等等我只會選Murex，雖然貴。
由於當時更多的接觸的是基於外匯系統的風險系統建設工作，簡單說說外匯交易系統的風險管理，筆者接觸過的銀行有一點是一樣的，就都是風險厭惡型實體，基本上對風險容忍度都不高。從風險的角度，銀行無非關注：
a). Liquidity Risk【可能因爲筆者參與很多ALM的項目建設，對銀行的表跟流動性關注頗多，才把流動性風險放在首位】就這麼一句話，靠控制存量，調節流量，儘量保持負債的穩定性和資產的高流動性來應對Liquidity Risk。筆者曾經在某Top 10互金P2P公司任職技術管理，順便提一句，P2P在完全取消資金池及錯配後，流動性成爲是否能活下去的關鍵，當然如果你在資本市場上有極強的融資能力另議，但融資如果融來的是運營資金，那就只能再找通道洗成兌付資金嘍。
關於錯配所謂的藉端放長，因爲你的負債大量的都是短期的定期存款或者活期存款，但你的資產，很多是來自於中長期的貸款，的債券投資等等，這些都是表內業務，而且還有大量的表外業務，比如說擔保、承諾、銀行承兌匯票、理財產品，這都會對流動性產生影響。外匯交易也是一樣，根源是到底有沒有錢。
b). Credit Risk：交易對手風險或履約風險，指交易對方不履行到期債務的風險。由於結算方式的不同，場內衍生交易和場外衍生交易各自所涉的信用風險也有所不同。
c). Operation Risk：操作型風險，這個最好理解，爲啥Murex提供了OSP
d). Market Risk：沒有比這個鏈接講的更好的了 市場風險 ，匯率風險，利率風險，大宗商品等等都涵蓋了。說到Market Risk，我們說一下VaR （Value At Risk）我真不知道咋翻譯，這裏面在系統設計時的確考慮大量運算，Historical 方法，蒙特卡洛法等等，都是需要對PnL， PPL等進行大量的計算才能完成的，說實話，Map-Reduce的思路可以做些改進，我也嘗試過把10幾年的數據Load到MongoDB裏，然後用它自帶的Map-Reduce函數做了實驗，由於畢竟單線程的JS函數，效率提升很小。
而針對外匯的交易風險，來源幾本就三方面：
1）經濟主體自身持有外匯頭寸，發生不同貨幣間進行兌換或折算產生的
2）匯率的不確定因素
3）並因匯率變動而給經濟主體帶來的經濟損失的可能性【仔細想想，就是因爲貨幣和時間兩個維度的因素導致了風險的存在】而變數在於，各個國家匯率制度不同（金本位或固定匯率下，波動小；浮動匯率下加上波動率上下限不一，容易大起大落）、貨幣政策（基本起決定性作用，匯率的波動在購買力和利率平價理論下，匯率由兩國的通脹率和利率決定的）、會計制度（科目劃分、會計方法選擇、會計覈算差異，什麼貨幣/非貨幣法什麼流動/非流動法，還有時間度量法啥的）說到會計制度突然想起來下圖，呵呵一下。當然還有國際收支，國家政局狀況等。
考慮的風險因素基本上的就這些，作爲整體的外匯交易系統的設計，主要的就是算，比如上面提到的VaR的計算，算成一個如下圖的結果
整體系統的架構設計，不難在功能，銀行裏面懂業務的專家有的是，特別是這種外資銀行，設計系統的時候最複雜的外部的業務對接，這也是爲什麼文章開端也提到很多互聯網化的技術並沒有用，除了風險的角度外，的確系統的外部對接是個問題，當然，爲了更好的讓系統能和外部業務系統對接，當時也有一個專門做協議轉化的項目，雙方大量使用XML定義好自己的格式用於交換數據，特別是跟MxML的轉換工作。這也是開篇感謝IBM的原因。最後，給個整體的功能圖，方便大家理解外匯交易系統到底啥樣，
從業務功能上講，無非前中後臺，之所以說Murex是外匯交易管理平臺，也是因爲他們不做直接的交易系統，一般來說交易系統都是外採或自己開發的，畢竟沒這麼複雜。特別是如果外匯實盤交易，針對的產品大都是Fx Spot， Fx Forward， Fx Swap（不算衍生品的話），虛盤交易無非加入保證金的管理。實際上的
前臺管理功能無非：交易錄入、實時行情、頭寸、損益、交易前分析、策略試算、情景分析、模擬、客戶管理、外部遠程交易管理等；
中臺：信用管理，市場限額（敞口、止損位控制、VaR、期限限額、合規管控）、各種計算（VaR，資本充足狀況、壓力測試、Back Testing）；
後臺：工作流配置，各種日常任務管控，報表，報文管理，抵押品，會計管理（交易頭寸估值、外匯頭寸的計算、報表、必須支持多實體，多幣種，全資產多套會計體系的計算）。
系統所有功能都來自對業務的支持，十幾年前我的導師，Des Greer 就跟我說過，銀行的系統多，各司其職，看上去複雜，複雜在Data Model和系統所屬的業務線上，本身並不複雜，設計工業化軟件還是高內聚低耦合以最小的成本完成最基礎的功能，不要按照自己的想法增加功能。當然也許說的不全對，但有一定道理。大年初一，囉哩囉嗦寫了這麼多，讀的人希望不太晦澀。下面的兩個部分，爭取少些業務內容，多寫一些跟技術相關的東東，畢竟我是個程序員。
祝大家新春快樂 - Leon 2019-2-5