第三方支付作為一個具有獨立性質(zhì)的機構(gòu)，常常需要解決很多風(fēng)險問題，從某種程度來說第三方支付存在的價值不在于消滅不確定性，而是在于對于風(fēng)險的控制的認(rèn)識的基礎(chǔ)上，對風(fēng)險進(jìn)行控制和管理，對交易的監(jiān)督，提前發(fā)現(xiàn)交易的風(fēng)險性，從而提高預(yù)防能力，降低交易產(chǎn)生的風(fēng)險。

第三方支付風(fēng)控系統(tǒng)實現(xiàn)的幾種方案

1)、數(shù)據(jù)庫方案：將風(fēng)險規(guī)則、交易數(shù)據(jù)等都采用關(guān)系數(shù)據(jù)庫存放。正如 支付系統(tǒng)風(fēng)控系統(tǒng)建設(shè)思考 所提到的方案，交易庫和風(fēng)險庫一般分別部署在不同的服務(wù)器上，在事件觸發(fā)上可以采用數(shù)據(jù)庫觸發(fā)器、消息隊列事件等方案。此種方案技術(shù)實現(xiàn)相對簡單，但在進(jìn)行海量交易數(shù)據(jù)查詢以及大量風(fēng)險規(guī)則處理時候，數(shù)據(jù)庫系統(tǒng)查詢性能及擴展性成為一個較大的瓶頸。很難滿足風(fēng)險事件實時分析的要求。

2)、內(nèi)存數(shù)據(jù)庫方案：由于對海量交易數(shù)據(jù)的查詢、分析極其消耗數(shù)據(jù)庫資源，可以采用內(nèi)存數(shù)據(jù)庫方案來替代關(guān)系數(shù)據(jù)庫，保證風(fēng)險事件實時處理的性能。 但目前開源的內(nèi)存數(shù)據(jù)中VoltDB、H2、MonetDB、FastDB、Berkeley DB、SQLite等在大規(guī)模的業(yè)務(wù)場合應(yīng)用的成熟度尚待考察，而Oracle TimesTen、MCObject eXtremeDB、Altibase價格太高。

3)、分布式緩存方案：采用Memcached等NOSQL的分布式緩存來緩存交易數(shù)據(jù)、風(fēng)險規(guī)則等，但由于NOSQL解決方案并不擅長數(shù)據(jù)間的關(guān)系邏輯處理，需要在程序中大量維護業(yè)務(wù)處理邏輯，遠(yuǎn)不如關(guān)系數(shù)據(jù)庫或內(nèi)存數(shù)據(jù)庫方案方便。

第三方支付作為買賣雙方的支付橋梁，在整個交易過程中起到中樞的作用，從上面的方案可以看出，通過規(guī)則引擎的部署方案，可以完成風(fēng)險規(guī)則的管理和維護，可以有效地避免了大多數(shù)的風(fēng)險，以及第三方支付在規(guī)則維護和處理規(guī)則之間的繁瑣的關(guān)系。