❶ 供應鏈金融風控系統流程是怎樣的
供應鏈金融風控系統流程是怎樣的呢？依據我們供應鏈金融風控系統的開發經驗，下面來為大家進行介紹。
前期准備
拿到足夠多的數據做支撐
做足夠靈活的分析平台去分析數據
產出風險事件進行阻攔風險
量化風險攔截的價值和不斷分析案例進行策略優化
風控技術評估研究
日誌選擇：以增量日誌方式記錄存儲，hadoop或spark做分析，集群同步到客戶端機器上，做同步策略，不同緯度的數據做統計加工計算。
實時監控：監控在每一個環節的交易量和高風險操作，做閥值報警，以默認的規則做處理。
dns防範：防止http對dns的攔截，手動紀錄中斷被攔截掉的交易流，轉向存儲中心系統做處理給予用戶提示。
報警提醒：在發生重大災難的同時需要有一套完善的體系提醒風控人員近入作戰，以簡訊或電話的形式發起通知給用戶。
數據災難：數據的歷史紀錄應該有完整的備庫紀錄，這種操作不是必須的但是必要的，防止管理員因為誤操作導致的數據災難不容小視，啟東應急方案進行恢復。
日誌選擇：需要在原有基礎上做集群數據分析後，統一有一個入口的分析平台做匯總，對不同維度的計算規則做排重，這里我們可以使用elk的方式把數據清洗完成後，做相關的分析調研，實時讀庫的方式不可取，增量資料庫只保留歷史的數據，可以對時間做相關的約定，查詢的平台統一做相關的調控。
方案的選擇和實施
針對現在的數據規則，需要對現有的各方數據做分析指標，做數據倉庫，從不同的數據中計算對應的需要風控形成各種渠道的報表數據。如何通過查詢海量的歷史數據來支撐規則的運算，從分析的角度來看，又是一個IO密集型的應用；利用OLTP（online transaction processing ）和OLAP（online analytical processing）做相關的維度計算，主要針對用戶、功能、數據片、存儲空間、DB設計來做維度計算和方案的優化調整。
大到用hadoop做數據集群演算法分析，也可以用spark、storm來做。
簡而言之就是分布式框架，那麼什麼是分布式框架？
分布式計算框架實現了什麼？簡而言之，基於分布式計算框架的應用，就是一個分布式的應用；那麼分布式的應用解決了什麼問題？簡而言之，就是將請求處理的業務邏輯和所需資源合理地分布到N台伺服器上，這里就不在過多介紹。
基於C/S模式的原理，從client到server端的應用，採集需要的數據。Server之間通訊是有開銷的，只不過這個開銷是MS級的。系統在定位也是基於百萬級的應用。
以分層的概念，針對每部的風控模塊，需要在特定的時間做調整。緩存的應用：如果是歷史級別的數據，可以採用redis、cache來做，防止減少對於I/O的讀寫操作，減少存儲壓力的開銷。基於款時間的維度對應的風控系統計算，需要我們在處理的同時考慮數據的節點，分批次處理。對於變化多端的數據，建議利用高可用性能存儲設計，基於DB設計即可，數據結構要基於範式(NF)設計，不可有冗餘免得頻繁返工。
數據分離的優先選擇
資料庫讀寫分離機制：在初期，風控系統一般都極為簡單，此時侯一般通過資料庫主從復制/讀寫分離/Sharding（或slave進行）等機制來保證交易系統的資料庫和風控系統數據的同步及讀寫分離。風控系統對所需要的客戶/賬戶數據、交易數據一般都只進行讀操作。
緩存/內存資料庫機制：不管是交易系統還是風控系統，高效的緩存系統是提升性能的大殺器，一般會把頻繁使用的數據存放到Redis等緩存系統中。例如對風控系統，包括諸如風控規則、風控案例庫、中間結果集、黑白名單、預處理結果等數據；對交易系統而言，包括諸如交易參數、計費模板、清結算規則、分潤規則、銀行路由策略等。對一些高頻交易中，基於性能考慮，會採用內存資料庫（一般會結合SSD硬碟）。
RPC/SOA架構：要降低交易系統和風控系統的耦合度，在初期系統服務較少的情況下，一般直接採用RabbitMQ/ActiveMQ之類的消息中間件或RPC方式來實現系統間服務的調用。如果系統服務較多，存在服務治理問題，會採用Dubbo之類的SOA中間件來實現系統服務調用，這個期間我們需要支持用非同步消息完成rabbitMQ的消息的push/pull處理機制來處理違規數據和異常數據提取。