外匯PNL

A. 2019-02-05：金融風控系統設計 - 外匯管理風控系統

無際致力於金融科技對銀行、融擔、互聯網金融行業的基於供應鏈金融為核心的互聯網化金融風控技術的輸出。涵蓋了互聯網信貸核心的系統建設，基於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-Rece的思路可以做些改進，我也嘗試過把10幾年的數據Load到MongoDB里，然後用它自帶的Map-Rece函數做了實驗，由於畢竟單線程的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

B. 建設銀行手機銀行開通總提示預留號碼為空怎麼辦

解決方案如下：

1、戶主攜帶本人身份證、銀行卡和手機到網路進行無約束，然後開通手機銀行重新進行綁定。

2、登錄網上銀行，在我的賬戶 - 其他客服 - 手機銀行客戶端管理，解除綁定，然後再用手機登錄即可。

3、打電話給客服電話取消綁定，然後重新綁定。

建行手機銀行的預留號碼為空白原因：當建行行動電話銀行時沒有留下電話，或者系統在維護時沒有正確填寫

(2)外匯PNL擴展閱讀：

銀行預留手機號修改方法：

據悉，銀行卡預留的手機號可以在銀行網站更改，但前提是你開通了網銀或者手機銀行。人們登錄銀行的官方網站，進入個人系統的版塊，進入賬戶管理欄目，再選擇「客戶聯系資料修改」，最後點擊更改手機號碼即可，這是簡便操作的方法之一。

如果沒有網銀，那麼可以去櫃台辦理。銀行卡持有人可以攜帶自己的有效個人身份證件和持有的銀行卡去銀行櫃台辦理即可。銀行櫃台人員會要求持卡人提供之前號碼以及銀行卡的密碼，然後再填寫相關單據即可完成。

如果既沒有網銀，又不想去櫃台辦理，那麼可以撥打銀行客服電話更改。通過電話進行更改，需要提供足夠多的個人信息，銀行才會確定是持卡人本人。電話客服人員會問到的問題有很多，比如單位的地址或者是家庭的地址，手機號碼，身份證號碼等等，這些信息需要跟你在銀行填寫的個人信息一致。