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

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

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

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

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

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