很多時候會碰到新業務上線之後，發現由於程式bug導致一些髒資料，但是這些髒資料並不會立即告訴你我這邊出問題了，你趕緊修復或者回滾。往往是等若干小時之後，陸續有使用者反饋，資料或應用出現問題了，然後通知客滿，客滿再反饋給開發同學。

      在做對賬的時候要考慮這兩點：第一是每一次資金入賬都要符合預期，要能夠準確識別出來哪些是異常入賬並進行攔截，進入人工稽核。另外還需要增加一種事後對賬，確保上下游系統的資料是完全一致的。要做到筆筆清。目前還缺少入賬實時對賬這塊的風控。

引入對賬之後的流程變更 

流程圖：

簡單理解：在做入賬操作之前先做一次對賬處理。看下資料是否合理的。

實時對賬業務架構

引入一個對賬中心，這個對賬中心要做的事情就是結算系統的資料與業務資料進行對賬。判斷當前這筆結算是否有風險。

結算系統根據對賬中心的返回結果，決策後續流程。如果對賬異常，那麼進行凍結，否則，進行結算入賬。

批量對賬業務架構

說明：

1. 對賬中心把每一個對賬需求都看做一個對賬任務，每一個對賬任務採用資料收集器+對賬處理器的方式進行對賬處理。
2. 批量對賬的觸發方式採用dts定期觸發，可以在dts中配置對賬的時間範圍。
3. 對賬任務被觸發後，呼叫資料收集器拉取業務系統和結算系統流水資料。資料收集器採用併發方式拉取對賬資料，以減少資料查詢時間。資料查詢完成後，交由對賬任務處理器進行對賬處理。
4. 對賬任務處理器採取雙向對賬的方式進行對賬，即先以業務系統流水為基準進行對賬，然後，再以結算系統流水為基準進行對賬。另外，為了防止對賬時間範圍臨界處的流水可能拉取不到的問題，在拉取批量對賬資料時，向前向後多拉取了10s 範圍的資料，我們稱為臨界區資料。例如，在進行t+1日對賬時，我們拉取的時間範圍就是[t-1 23:59:50, t+1 00:00:10]。但是,對賬的基準資料仍然是[t 00:00:00, t 23:59:59]，只不過查詢資料時會覆蓋到臨界區資料。
5. 對賬任務每次執行都會生成一個批次號，並記錄對賬狀態。如果對賬失敗，則要把對賬失敗的記錄也插入DB，便於後續排查。

風控系統

風控系統比較常見的一個架構圖：

簡單列舉幾個末端結算相關的風控規則：

1、提現金額到達一個指定的閥值的時候報警或進入人工稽核平臺

2、結算金額範圍校驗

3、異常資料監控

兩個引擎

風控規則引擎用來執行風控實時規則，為上游提供實時的風控風險識別能力的輸出。

風控離線模型引擎用來執行離線演算法模型，產出的結果為風控規則引擎提供決策依據。從資料倉庫中獲取所需要的指標，產出的結果也會沉澱到資料倉庫中。

後續末端結算域的風控系統設計上也是可以參考下這塊的設計。包括風控實時規則，離線的可以基於離線資料進行運算風控模型。進一步來講，可以將刷單風控、等這些功能也做進來。

抽象風控監控模型