下面將參照圖式更詳細地描述本發明的示例性實施例。雖然圖式中顯示了本發明的示例性實施例，然而應當理解，可以以各種形式實現本發明而不應被這裡闡述的實施例所限制。相反，提供這些實施例是為了能夠更透徹地理解本發明，並且能夠將本發明的範圍完整的傳達給本領域的技術人員。
本說明書中涉及的名詞解析如下：
策略：是多個規則條件組合後形成的一個有業務意義的結論判斷。其中“規則”是配置變數的取值，產生一個成功或者失敗或者校驗的結果；
事件：是描述用戶具體業務行為的風控最基本單元，如登錄、註冊、轉帳等有業務意義的即時請求均可稱之為“事件”。智能風控決策系統透過事件與週邊系統(例如業務系統)交互。
模擬觸發：是指透過即時“事件”請求，業務系統向風控系統諮詢風險，風控系統觸發對應策略並返回給業務系統決策結果的模擬行為。主要為能夠正確上線策略提供自檢排查，保證新配置策略符合預期及業務指標的穩定性。
本說明書揭示了一種處理系統，該處理系統可廣泛應用於各行各業，以處理各種類型的業務，比如金融業務、銷售業務等等。
金融業務例如存取款業務、信貸業務、證券業務、保險業務等等。
銷售業務例如汽車銷售、電子銷售、電氣銷售等等。
進一步地，本說明書還具有“業務場景”的概念。以金融業務為例，業務場景包括但不限於是：儲蓄業務場景(儲蓄卡業務)、信貸業務場景(信用卡業務)、保險業務場景(保險業務)等等。
參看圖1，本實施例的處理系統包含兩個部分：業務系統01、智能風控決策系統02。
業務系統01用於接收事件集，並將事件集傳輸給本說明書的智能風控決策系統02進行處理。在接收事件的過程中，可從各類資料埠接收事件，或者接收使用者操作在業務系統01中產生事件。
其中，業務系統01配置有各類資料埠，用於和第三方業務平台實現資料對接。一個資料介面對接一類業務平台。第三方業務平台包括但不限於是手機業務平台、商城業務平台、PC業務平台等等。這些業務平台過來的各類業務請求在本說明書中統稱為事件。事件包括但不限於是：登錄、註冊、交易(轉帳)、修改密碼、貸款、報案(舉報異常事件，例如舉報異常交易)、申請等等。例如某某用戶在XX時間在XX業務場景下發起了XX交易；再例如，某某用戶在XX時間在XX業務場景下發起XX申請。
各事件有各自的業務場景，參看圖2，是第三方業務平台、事件和業務場景的映射關係的示意圖。
智能風控決策系統02，用於識別策略對事件集進行風險識別，獲得事件集的風險行為；其中，事件集中的每個事件具有各自的業務場景；識別策略中包含對事件集中的每個事件進行處理的子策略，子策略根據該事件的業務場景確定；根據事件集的風險行為產生應對決策；應對決策中包含每個事件的個性化應對決策；對風險行為和應對決策進行監控分析，獲得事件集的分析結果；根據事件集的分析結果調整識別策略和應對決策。
智能風控決策系統02，用於將每個事件的個性化應對決策回饋給業務系統01；
業務系統01，用於根據每個事件的個性化應對決策產生每個事件的執行決策進行執行。
下面介紹業務系統01的具體實施過程。其中，參看圖1，業務系統01包括：
事件接收模組11，用於接收事件集。由於業務系統01無法對事件集進行處理，故需將事件集傳輸給智能風控決策系統02，由風控決策系統對事件集進行風險識別、產生應對決策等操作，指導業務系統01根據事件集的應對決策進行處理。而智能風控決策系統02的具體實施過程會在下述實施例中詳細介紹，故在此不再進行贅述。
事件填充模組12，用於從智能風控決策系統02中獲取事件集的應對決策；其中，應對決策中包含每個事件的個性化應對決策。並根據每個事件的個性化應對決策產生每個事件的執行決策。
事件分發模組13，用於將事件集的應對決策分發到決策返回模組。
決策返回模組14，用於根據每個事件的個性化應對決策配置各自的執行決策進行執行。各事件配置執行決策的過程和其他事件無關。舉例來說，某事件的個性化應對決策為拒絕決策。則會根據該個性化決策配置比如修改密碼失敗，您的操作環境有風險等執行決策進行執行。
以上是業務系統01和智能風控決策系統02在整體上的交互過程。透過業務系統01在前端為事件集提供操作回應，透過智能風控決策系統02在後端對事件集進行風險識別並產生應對決策，以及根據分析結果對識別策略和應對決策進行調整，來保證風險防控的效果。
基於相同的發明構思，本說明書的另一個實施例提供了一種智能風控決策方法，該方法應用於智能風控決策系統02。
通常來說，事件傳輸過來後，調用對應的子策略進行配置後，會產生個性化應對決策：通過、拒絕、待定等等決策。
傳統的防控策略邏輯在系統開發時就已經固化在智能風控決策系統02中，不會因為外界條件的變化而變更，策略調整的靈活性極低。比如貸款時需要金額超過某閾值才通過，這是很固定的，靈活性極低。如果獲知上述策略邏輯就很容易規避，比如提高流水金額超過該閾值，就可以成功申貸。即便是發現這個漏洞，如果要更改，需要代碼人員修改更換代碼並且發佈了該系統的升級版本後才能生效，風險防控能力極低。而本說明書中的智能風控決策系統02支援在運行過程中根據實際情況適應性調整策略邏輯。具體來說，調用識別策略對事件集進行風險識別，獲得事件集的風險行為，並根據事件集的風險行為產生應對決策。在對事件集進行識別和決策後，可對事件集的風險行為和應對決策進行監控分析，獲得事件集的分析結果，並支援根據事件集的分析結果調整識別策略和應對決策，以根據實際情況對策略(決策)進行靈活變更，能夠快速回應風險情勢，進而減少誤判，提高風險識別的準確率。
進一步地，本說明書的方法能夠對事件集進行批次處理，並且針對每個事件會產生其個性化應對決策，能夠使“批次”和“個性化服務”成為本系統的一大優勢。例如，用戶A和用戶B同時申請相同額度的貸款，而對兩者進行風險識別時，會調用兩者的繳稅記錄，若使用者B繳稅不連續或者繳稅額度低，則給用戶B貸款的利率更高，額度更低。若用戶A的繳稅連續並且額度高，則給用戶A的貸款利率更低且額度更高，故而針對兩個用戶申請相同額度的貸款事件，產生的應對決策不同。
參看圖3，該方法是智能風控決策系統02在運行過程中執行的步驟，具體包括如下步驟：
步驟11，調用識別策略對事件集進行風險識別，獲得事件集的風險行為。
其中，事件集由業務系統01傳輸，並且事件集中的每個事件具有各自的業務場景。
識別策略中包含對事件集中的每個事件進行處理的子策略，子策略根據該事件的業務場景確定。
參看圖4，是事件、業務場景、子策略的映射關係圖。其中，各業務場景下具有各自的子策略(和應對決策)。
而在調用識別策略對事件集進行風險識別的過程中，針對事件集中的每個事件，根據每個事件各自的業務場景，確定出每個事件的子策略。進而調用每個事件的子策略對該事件進行風險識別，獲得該事件的風險行為。此處所指“該事件”實際指的是事件本身。例如，針對事件1，確定出事件1的子策略，進而調用事件1的子策略對該事件1本身進行風險識別。
步驟12，根據事件集的風險行為產生應對決策。
其中，應對決策中包含每個事件的個性化應對決策。各事件的個性化應對決策可相同或不同。
在具體的實施過程中，在調用每個事件的子策略對該事件進行風險識別，獲得該事件的風險行為後，會針對該事件的風險行為產生該事件的個性化應對決策。
而個性化應對決策包括：通過、拒絕、待定等等決策。若某個事件為待定決策，則表示需要對該事件進一步進行驗證。驗證方式包括但不限於是人臉、指紋、簡訊、語音等等方式進行驗證。
以上是對事件集進行風險識別和產生應對決策的實施過程。針對事件集中的每個事件，都需要執行上述過程。
具體來說，在調用子策略對各事件進行風險識別後，得到的風險行為可能為無風險或有風險。如果事件的風險行為是無風險，則產生通過決策，傳輸給業務系統01，以便對該事件快速放行。如果事件的風險行為是有風險，則產生拒絕決策或者待定決策傳輸給業務系統01。
另外，會將事件集的相關資料(事件本身資料、風險行為、決策等等)沉澱下來保存，以便後續分析。
由此可見，本說明書的方法借助於系統，透過風險識別和應對決策等步驟，能夠對事件集進行批次處理，並產生各事件的個性化應對決策。無需人工審核，審核時間跨度以分、秒來計算，為使用者帶來更好的服務體驗。
當然，後續會針對這一系列操作進行分析，具體請看下面的步驟。
步驟13，對事件集的風險行為和應對決策進行監控分析，獲得事件集的分析結果。
監控分析主要是為了即時監控智能風控決策系統02的運行環境。在對獲得事件集進行分析、決策等操作後，需要監控該事件集引起的通過率、拒絕率、校驗率、事件來源等等，作為後續分析的基礎資料。
例如，分析結果為某地區的申請量上升、管道增多(例如事件來源為支付寶，事件來源為微信、某個管道量特別多等等)。這些都是對開展業務很有幫助，能夠作為後續開展業務的基礎資料。另外，還可以根據分析結果調整後續的識別策略，例如，假設識別策略中沒有對微信管道加以風險識別的子策略，則可以在識別策略中加入微信管道識別的子策略。
步驟14，根據事件集的分析結果調整識別策略和應對決策。
在具體的調整過程中，在監控到事件集中有預設個事件的個性化應對決策為通過決策，則無需調整。
若監控到事件集中有預設個事件的個性化應對決策為拒絕決策和/或待定決策，故而在調整的過程中，會根據分析結果產生預設個事件的優化子策略和預設個事件的優化決策。利用預設個事件的優化子策略對預設個事件的原識別策略進行優化，並利用預設個事件的優化決策對預設個事件的原應對決策進行優化。
以上是本實施例的智能決策方法的主要實施原理。另外，本說明書還揭示了資料中心，也稱為統一的風險變數池。本實施例將內部各系統資料(線上＋離線)進行有效融合，形成資料中心。資料中心融合了多維度、多特徵的資料，為智能風控決策引擎提供資料支援，以對事件進行更為精准化的評估，比如融合傳統的金融業務場景中申請、審批、貸後等一系列環節建立在不同的業務系統01中的資料。
以銀行系統為例，傳統銀行也嘗試考慮簡單的決策引擎，嘗試將相關流程線上化，進行線上即時審批或者即時決策，但受限於風控決策引擎的局限性，往往僅支持簡單的名單類過濾。而對於風控中非常重要的即時累積變數(如“設備上過去7天登陸的用戶數“等累積類變數)、第三方資料(人行徵信)融入、離線資料如何線上引用等關鍵問題都很難透過可配置方式引用甚至都不支援，傳統銀行風控所使用的資料非常有限，難以將不同部門、不同場景、不同種類的資料來源統一管理並應用起來。為了解決這一問題，本說明書將線上資料域與離線資料統一起來，建立資料中心。資料中心將不同性質的資料有機融合在一塊，支援不同來源的資料的靈活擴展，對不同場景的業務共用風險資料，一方面降低資料使用成本，另一方面最大化資料價值。
進一步地，為了支援線上資料域、離線資料域的融合，本說明書採用了資料服務的方式進行引用，將離線資料域中的資料融入到線上資料域中。另外，資料服務還可以接入第三方資料融入到線上資料域中，以實現離線資料域和第三方資料的引用。
具體來說，資料中心包含線上資料域和離線資料域。線上資料域為智能風控決策引擎提供線上資料支援。離線資料域為智能風控決策引擎提供歷史資料支援。
具體的，線上資料域，包括以下幾個方面的資料：
線上累積資料，記錄事件集的所有相關資料，包括：事件名，當前系統登錄使用者數，事件所屬設備的設備欄位，事件的操作時間等等。
線上名單資料，記錄當前所有事件的名單。
維表資料，包括手機解析維表、IP位址解析維表、身分證解析維表，供風險識別模組調用。其中，IP位址解析維表為第三方資料，透過資料服務接入到維表資料中。
事件資料：記錄當前所有事件。
離線資料域，包括以下幾個方面的資料：
歷史事件表，記錄歷史事件的所有相關資料。例如，某子策略為“調用某帳戶過去60天的轉帳金額進行判定”，則從歷史時間表中清洗出該帳戶過去59天的轉帳金額，加上當天線上的轉帳金額即可獲得總共為60天的轉帳金額。
名單表，包括黑名單和白名單；其中，黑名單中記錄歷史事件中異常事件的相關資料，異常事件指的是應對決策為拒絕、待定等決策的事件。例如，異常手機號、異常銀行卡號、異常WIFI等等存入黑名單。若有事件所屬手機號、銀行卡號、所用WIFI等匹配到黑名單，則直接產生“拒絕”的應對決策。白名單中記錄歷史事件中正常事件的相關資料，正常事件指的是應對決策為通過決策的事件。
決策表，記錄有歷史事件的應對決策；其中，歷史事件的應對決策包括：通過、拒絕、待定等等。
案件表，記錄歷史舉報事件；
可信表，記錄歷史事件中正常事件的相關資料配對關係。可信表類似白名單，例如，用戶過去三個月在某個設備上登錄過，就把登錄帳號和設備進行綁定配對，如果用戶異地登錄，就會認為異常。
以上是線上資料域和離線資料域中的相關資料。
由於離線資料域中儲存的是歷史資料，故需要和線上資料域中的線上資料進行相互融合。此時，智能風控決策系統02中還包括資料服務模組，用於將離線資料域和線上資料域進行融合，以供風險識別模組調用。
除此之外，資料服務模組還用於接入第三方資料到線上資料域中，供風險識別模組調用。
資料中心是本說明書中的資料基礎，將各系統資料(線上＋離線)進行有效融合，提供多維度、多特徵的資料，為智能風控決策系統02提供豐富的槍支彈藥。
下面具體介紹各步驟的實施過程。
在進行風險識別的過程中，首先會涉及到子策略的配置。
通常來說，針對每個事件，都需要先配置該事件的子策略，然後在根據子策略對該事件進行風險識別。
假設業務系統01傳輸一筆交易(交易事件)到智能風控決策系統02中，智能風控決策系統02中針對該交易事件有一系列子策略對其進行識別，以獲得該交易的風險。舉例來說，30天內金額超過30萬就為風險交易。假設交易事件為查看帳戶30天內交易金額，該交易事件傳輸到智能風控決策系統02後，調用上述子策略對其進行識別，比如超過30萬，直接產生拒絕的個性化應對策略。
而子策略的配置需要使用累積變數。累積變數是指透過策略計算中的“流計算”產生的特徵變數，主要透過累積管理與變數產生兩個步驟產生累積特徵。一個完整的累積變數包含累積主體、累積內容、累積函數以及累積視窗四個部分，例如“帳戶30天內交易金額”這個累積變數，主體是帳戶，累積內容是金額，累積函數是SUM，累積視窗是30天。
在配置每個事件的子策略的過程中，也需要接入線上資料域、離線資料域、第三方資料庫等一種多種資料來源，來配置子策略。
具體來說，包括以下一種或者幾種方式組合：
第一種方式：根據每個事件各自的業務場景，從線上資料域中確定出該事件的配置變數取值；根據該事件的配置變數取值，配置該事件的子策略。
第二種方式：根據每個事件各自的業務場景，從在離線據域中確定出該事件的配置變數取值；根據該事件的配置變數取值，配置該事件的子策略。
第三種方式：根據每個事件各自的業務場景，從在第三方資料中確定出該事件的配置變數取值；根據該事件的配置變數取值，配置該事件的子策略。例如個稅策略，只有在某地稅局交稅才能發放貸款，此時需要從地稅局請求發送稅務資料。配置的策略為：用戶過去是否連續12個月交稅，交稅是否連續性，達到的比例額度等等。因此，從第三方資料中也可以配置策略的維度進行風險防控。
以上三種方式可以任意組合或單獨使用。
而在利用子策略對事件進行風險識別的過程中，會涉及到模型調用，即：根據每個事件的子策略，確定每個事件的子模型，並調用每個事件的對其本身事件(該事件)進行風險識別，獲得每個事件的風險行為。
作為一種可選的實施例，子策略包含N層識別子策略，每層識別子策略具有先後調用關係；N≥1且為正整數。故，調用每個事件的子策略中的N層識別子策略依次對該事件進行風險識別，獲得該事件的風險行為。
針對單一事件來說，由於其子策略包含N層識別子策略，每層識別子策略具有先後調用關係。故每層子策略都會對該事件進行風險識別，並產生一風險行為。該風險行為是“有風險”、“無風險”等等行為。例如，當識別為“通過”、“匹配”、“滿足”等等結果，表示無風險。若識別為“拒絕”、“不匹配”、“不滿足”等等結果，表示有風險行為。而針對每層子策略的風險行為會產生對應的個性化應對決策。具體的，若當層子策略為的風險行為表示無風險，則產生一個“通過”的個性化應對決策，並轉化到下一層子策略進行識別。若當層子策略為的風險行為表示有風險，則產生一個“拒絕”的個性化應對決策，並停止後續子策略的識別操作。若為最後一層子策略，則根據“有風險”、“無風險”等等行為產生對應的個性化應對決策。
舉例來說，有關某用戶人臉識別的識別策略，包含“人臉和身分證照片是否匹配”，“信貸申請失敗的次數是否達到閾值”兩層識別子策略。在對人臉進行識別時，先調用第1層識別子策略“人臉和身分證照片是否匹配”進行識別。若不匹配，則產生“拒絕”的個性化應對決策。若匹配，則獲取該用戶信貸申請失敗的次數，調用第二層識別子策略“信貸申請失敗的次數是否達到閾值”進行判斷。若判斷達到閾值，則產生“拒絕”的個性化應對決策。若判斷未達到閾值，則產生“通過”的個性化應對決策。
作為一種可選的實施例，在根據所述事件集的風險行為產生應對決策之後，若所述事件集中有事件的個性化應對決策為待定決策，分析該事件的歷史應對決策；根據該事件的歷史應對決策和該事件待定決策產生該事件的驗證方式，該事件的驗證方式和該事件的歷史決策中的驗證方式不同。
舉例來說，登錄事件的歷史應對決策為“簡訊驗證”，也就是說已經對其進行了簡訊驗證。若對登錄事件的帳號、密碼進行識別，則會結合歷史應對決策“簡訊驗證”。如此，避免產生相同的驗證方式進行重複執行引起使用者的反感情緒且避免浪費決策資源。假設產生的個性化應對決策為“待定”決策，就不能再次使用“簡訊驗證”方式。
而在監控的具體實施過程中，監控的目的是為了即時監控智能風控決策系統02的運行環境。在對獲得事件集進行分析、決策等操作後，需要監控該事件集引起的通過率、拒絕率、校驗率、事件來源等等，作為後續分析的基礎資料。其實時監控智能風控決策系統02的運行環境的目的是為了監控各子策略的風險後，對子策略和個性化決策進行補漏，否則不知道哪條子策略風險高影響了系統。
監控能夠獲知子策略的風險命中率，分析能夠獲知子策略的風險命中率的具體原因，例如是子策略配錯了導致的命中率高，還是這段時間確實有這樣的風險。如果是子策略配錯了，則透過監控分析得知分析結果後，根據分析結果能夠修改子策略。這些都是在運行過程中操作，無需返回技術開發重新研發版本。
具體來說，由於決策為拒絕、通過或待定等等個性化決策。在監控到事件集中有預設個事件的個性化應對決策為通過決策，則分析該預設個事件的風險進行規律分析，獲得預設個事件的分析結果，然後根據預設個事件的分析結果，調整預設個事件中每個事件的子策略和個性化應對決策。
若監控到事件集中有預設個事件的個性化應對決策為拒絕決策和/或待定決策，表示這預設個事件為異常事件，故必須分析出其具體的風險行為，並要反補到之前的子策略和個性化應對決策中，提高系統的防控能力和防控準確率。這樣做的原因是，在對拒絕事件或者對事件進行待定處理後，都需要進行分析，以便查漏補缺，避免識別策略的漏洞造成後續嚴重影響。例如，發現某地區申請貸款數目超載，如果不更新識別策略控制貸款數目，若後續貸款人員還不上貸款，則會造成虧空。
故，對預設個事件的風險行為進行分析，獲得預設個事件的分析結果。該分析結果為引起預設個事件的風險行為的具體原因。
進一步地，在調整時，會根據預設個事件的分析結果，調整預設個事件中每個事件的子策略和個性化應對決策，配置後即可生效。
具體來說，若預設個事件的個性化應對決策為拒絕決策和/或待定決策，對應的事件會進行沉澱，以便於對預設個事件的風險行為進行分析，避免到海量資料中撈異常事件。而將分析結果反補到防控上，用以調整預設個事件中每個事件的子策略和個性化應對決策，形成一個閉環，能夠根據分析結果靈活調整前述策略和決策，用以快速彌補前述策略和決策的不足，以提高防控的準確率。
舉例來說，若對50個事件分析時，發現產生拒絕決策的步驟在人臉識別那層子策略，分析出來的原因可能是：惡意攻擊，或者操作人群年齡比較大不懂操作。在識別決策後進行分析，反過來做優化，針對性對策略進行調整。例如分析發現某個時間段某個地區的人臉識別最多，則在原有策子策略的基礎上將“高危時間”和“地區”的策略加上。後續如果是這個時間並且申請人都來自某個地區，那就直接拒絕掉，將分析結果反補到之前的風險防控上，形成一個閉環，以提高防控的準確率。
作為一種可選的實施例，本說明書支持新業務場景的靈活擴展。
在具體的實施過程中，構建新業務場景。根據所述新業務場景的配置需求從當前所有業務場景中確定目標業務場景。目標業務場景是為新業務場景提供識別策略、應對決策進行配置的場景。目標業務場景中具有目標識別策略和目標應對決策，用以對新業務場景進行配置。調用目標識別策略和目標應對決策對新業務場景進行配置。例如，信用卡中心中的目標識別策略和目標應對決策交易中心想借用，又必須保證不能夠影響信用卡中心的使用，故可以構建新業務場景，借用信用卡中心中的目標識別策略和目標應對決策對其進行配置。在使用時，由於事件已經具有場景劃分，故即便是兩個場景的識別策略相同，也可能產生不同的風險行為，並且各場景的識別策略互不影響。
透過上述描述，本說明書中的智能風控決策方法支援修改策略邏輯，具備即時風險感知監控、即時配置即時生效、場景可靈活擴展等巨大優勢。其一方面具備更高的自由度，能夠靈活更改識別策略和決策(而非傳統的方式，運營同學提供策略邏輯，讓開發同學將該邏輯寫死在後台，不管是後續修改還是管理都極其不方便)。另一方面，在提高審核速度和防控準確率的同時，由於識別策略和決策可即時更改，也降低了系統被攻陷的機率(傳統寫死策略邏輯的方式，很容易被黑、灰產多次嘗試後繞行並突破)。此外，本說明書中的方法能夠實現在所有場景下配置的所有策略的監控(量級、拒絕率等)，以全面監控風險情勢，並能根據異動情況靈活回應並快速優化策略。
作為一種可選的實施例，本說明書還支援策略配置和自檢。目前很多傳統風控，往往是識別策略直接上線(無法支援策略自檢)，在發現異常後，再進行事後補救，如此極大機率會導致運營悲劇(如打擾率激增或者拒絕率暴增等)。
而為了使操作風險等得到有效控制，在上線新識別策略時，需要模擬觸發事件和自動比對的策略自檢功能，保證新識別策略上線的過程中結果符合預期，讓靈活的系統運營起來更加穩健，透過模擬行為做到事前規避操作風險，而非上線後發現異常而進行事後補救，能夠避免因操作風險導致的運營悲劇(例如打擾率激增或者拒絕率暴增等)。
具體來說，產生新識別策略，其中，新識別策略具有預期資料。預期資料用作新識別策略的檢驗標準。
配置模擬事件對新識別策略進行檢測，根據檢測得到的檢測報告對新識別策略執行對應操作。
在具體的實施過程中，配置模擬事件；執行模擬事件，調用新識別策略對模擬事件進行處理，獲得結果資料；判斷結果資料是否滿足預期資料，產生檢測報告；若檢測報告表示結果資料滿足預期資料，則將新識別策略配置到對應業務場景中。
舉個例子，假設我們需要上線一條策略A為“轉帳用戶的註冊時長小於30天且轉帳金額大於5000”，且命中時出校驗(比如出簡訊)。那麼，具體地：
1, 事件配置：註冊事件配置、轉帳事件配置；變數配置：變數var1“註冊時間距當前時間的天數”和變數var2“轉帳金額”的配置；策略配置：策略A配置(試運行但未上線)。
2, 模擬觸發：為了驗證策略A是否符合預期，我們需要設計並構造資料(如表1)模擬正常用戶的行為，對策略A進行觸發，並沉澱對應的結果資料。
3, 自動比對：基於上述第2步，我們將策略A和所有變數(var1與var2)的預期結果和結果資料進行自動比對(如表2)，並產出對應的檢測報告。
4, 策略上線：基於上述第3步，當檢測報告內容符合預期的前提下，按照流程“試運行-＞灰度(調整)-＞正式運行”進行策略上線；否則，排查異常並定位後回到第1步或者第2步。 用例 編號 用例 說明 發送 次數 實驗設計屬性
事件 發生時間 事件 編碼 交易 名稱 核心 客戶號 金額 ( 元 )
TR079P 註冊(前置) 1 systime-15d REGISTER 註冊 userid1
TR079 轉帳用戶的註冊時長小於3天且轉帳金額大於5000 1 systime TRANSFER 轉帳 userid1 6000
表1: 策略自檢－資料構造&模擬觸發
其中，事件發生時間：Systime表示發送觸發事件時，系統當前的時間戳。同理Systime-15d表示15天前的時間戳；比如：Systime所取的系統時間戳為‘2018-12-31 10:24:20’，那麼Systime-15d對應的時間戳是‘2018-12-16 10:24:20’。 用例
編號 事件 策略 策略
預期值 策略
實際值 變數 預期值 實際值 變數 預期值 實際值
TR079 轉帳 策略A 校驗 校驗 var1 15 15 var2 6000 6000
表2: 策略自檢－自動比對
以上，基於“模擬觸發”和“自動比對”的策略自檢模組，讓靈活的系統運營起來更加穩健。透過模擬行為做到事前規避操作風險，而非上線後發現異常而進行事後補救。
作為一種可選的實施例，若事件集中具有舉報事件，對舉報事件及其個性化應對決策進行審理，獲得審理結果；對審理結果進行監控分析，獲得舉報事件的分析結果。進一步地，會根據舉報事件的分析結果調整舉報事件對應的子策略和個性化應對決策。
以上是智能風控決策方法的具體實施過程，基於與前述實施例中同樣的發明構思，本說明書實施例還提供一種業務處理方法，該方法應用於業務處理系統，該方法的實施過程如下：
業務系統01接收事件集，將事件集傳輸給上述一個或者多個實施例揭示的智能風控決策系統02；
智能風控決策系統02調用識別策略對事件集進行風險識別，獲得事件集的風險行為；其中，事件集中的每個事件具有各自的業務場景；識別策略中包含對事件集中的每個事件進行處理的子策略，子策略根據該事件的業務場景確定；根據事件集的風險行為產生應對決策；應對決策中包含每個事件的個性化應對決策；對風險行為和應對決策進行監控分析，獲得事件集的分析結果；根據事件集的分析結果調整識別策略和應對決策。
具體的處理方式在上述一個或者多個實施例中已經介紹，故而此處不再贅述。
智能風控決策系統02將每個事件的個性化應對決策回饋給業務系統01；
業務系統01根據每個事件的個性化應對決策產生每個事件的執行決策進行執行。
業務系統01的具體執行過程在上述一個或者多個實施例中已經介紹，故而此處不再贅述。
基於與前述實施例中同樣的發明構思，參看圖1，本說明書實施例還提供一種智能風控決策系統02，該系統的具體實施過程在上述方法實施例中一致，故對具體示例和解釋不再贅述，包括：
風險識別模組21，用於調用識別策略對事件集進行風險識別，獲得事件集的風險行為。
其中，事件集由業務系統01傳輸，並且事件集中的每個事件具有各自的業務場景；識別策略中包含對事件集中的每個事件進行處理的子策略，子策略根據該事件的業務場景確定。
風險決策模組22，用於根據事件集的風險行為產生應對決策。
應對決策中包含每個事件的個性化應對決策；
監控分析模組23，用於對事件集的風險行為和應對決策進行監控分析，獲得事件集的分析結果；
策略調整模組24，用於根據事件集的分析結果調整識別策略和應對決策。
作為一種可選的實施例，風險識別模組21，具體用於：
針對事件集中的每個事件，根據每個事件各自的業務場景，確定出每個事件的子策略；
調用每個事件的子策略對該事件進行風險識別，獲得該事件的風險行為。
作為一種可選的實施例，風險識別模組21，具體用於處理以下一個或者多個步驟的組合：
根據每個事件各自的業務場景，從線上資料域中確定出該事件的配置變數取值；根據該事件的配置變數取值，配置該事件的子策略；
根據每個事件各自的業務場景，從在離線資料域中確定出該事件的配置變數取值；根據該事件的配置變數取值，配置該事件的子策略；
根據每個事件各自的業務場景，從在第三方資料中確定出該事件的配置變數取值；根據該事件的配置變數取值，配置該事件的子策略。
另外，本說明書還揭示了資料中心，也稱為統一的風險變數池。而資料中心在上述實施例已經詳細介紹，故而此處本說明書不再贅述。
進一步地，為了支援線上資料域、離線資料域的融合，本系統還包括:資料服務模組，用於將離線資料域中的資料融入到線上資料域中，或者將第三方資料融入到線上資料域中，以實現離線資料域和第三方資料的引用。
作為一種可選的實施例，風險決策模組22，具體還用於：
若所述事件集中有事件的個性化應對決策為待定決策，分析該事件的歷史應對決策；
根據該事件的歷史應對決策和該事件待定決策產生該事件的驗證方式，該事件的驗證方式和該事件的歷史決策中的驗證方式不同。
作為一種可選的實施例，監控分析模組23，具體用於若監控到事件集中有預設個事件的個性化應對決策為拒絕決策和/或待定決策，對預設個事件的風險行為進行分析，獲得預設個事件的分析結果；
策略調整模組24，具體用於根據預設個事件的分析結果，調整預設個事件中每個事件的子策略和個性化應對決策。
作為一種可選的實施例，系統還包括場景配置模組，用於：
構建新業務場景；
根據所述新業務場景的配置需求從當前所有業務場景中確定目標業務場景，目標業務場景中具有目標識別策略和目標應對決策；
調用目標識別策略和目標應對決策對新業務場景進行配置。
作為一種可選的實施例，系統還包括：
策略產生模組，用於產生新識別策略，其中，新識別策略具有預期資料；
策略檢測模組，用於配置模擬事件對新識別策略進行檢測，根據檢測得到的檢測報告對新識別策略執行對應操作。
作為一種可選的實施例，策略檢測模組，包括：
事件配置模組，用於配置模擬事件；
模擬觸發模組，用於執行模擬事件，調用新識別策略對模擬事件進行處理，獲得結果資料；
對比模組，用於判斷結果資料是否滿足預期資料，產生檢測報告；
策略上線模組，用於若檢測報告表示結果資料滿足預期資料，則將新識別策略配置到對應業務場景中。
作為一種可選的實施例，系統還包括：
審理模組，用於若事件集中具有舉報事件，對舉報事件及其個性化應對決策進行審理，獲得審理結果；
監控分析模組23，用於對審理結果進行監控分析，獲得舉報事件的分析結果。
基於與前述實施例中同樣的發明構思，本說明書實施例還提供一種電腦可讀儲存媒體，其上儲存有電腦程式，該程式被處理器執行時實現前文任一方法的步驟。
基於與前述實施例中同樣的發明構思，本說明書的實施例還提供一種電腦設備，如圖5所示，包括記憶體504、處理器502及儲存在記憶體504上並可在處理器502上運行的電腦程式，處理器502執行程式時實現前文任一方法的步驟。
其中，在圖5中，匯流排架構(用匯流排500來代表)，匯流排500可以包括任意數量的互聯的匯流排和橋，匯流排500將包括由處理器502代表的一個或多個處理器和記憶體504代表的記憶體的各種電路連結在一起。匯流排500還可以將諸如週邊設備、穩壓器和功率管理電路等之類的各種其他電路連結在一起，這些都是本領域所公知的，因此，本文不再對其進行進一步描述。匯流排介面506在匯流排500和接收器501和發送器503之間提供介面。接收器501和發送器503可以是同一個元件，即收發機，提供用於在傳輸媒體上與各種其他終端設備通訊的單元。處理器502負責管理匯流排500和通常的處理，而記憶體504可以被用於儲存處理器502在執行操作時所使用的資料。
透過本說明書的一個或者多個實施例，本說明書具有以下有益效果或者優點：
本說明書揭示了智能風控決策方法及系統、業務處理方法及系統，調用識別策略對事件集進行風險識別，獲得事件集的風險行為，並根據事件集的風險行為產生應對決策。在對事件集進行識別和決策後，可對事件集的風險行為和應對決策進行監控分析，獲得事件集的分析結果，並支援根據事件集的分析結果調整識別策略和應對決策，以根據實際情況對策略(決策)進行靈活變更，能夠快速回應風險情勢，進而減少誤判，提高風險識別的準確率。
在此提供的演算法和顯示不與任何特定電腦、虛擬系統或者其它設備固有相關。各種通用系統也可以與基於在此的示教一起使用。根據上面的描述，構造這類系統所要求的結構是顯而易見的。此外，本說明書也不針對任何特定程式設計語言。應當明白，可以利用各種程式設計語言實現在此描述的本說明書的內容，並且上面對特定語言所做的描述是為了披露本說明書的最佳實施方式。
在此處所提供的說明書中，說明了大量具體細節。然而，能夠理解，本說明書的實施例可以在沒有這些具體細節的情況下實踐。在一些實例中，並未詳細示出公知的方法、結構和技術，以便不模糊對本說明書的理解。
類似地，應當理解，為了精簡本發明並幫助理解各個發明方面中的一個或多個，在上面對本說明書的示例性實施例的描述中，本說明書的各個特徵有時被一起分組到單一實施例、圖、或者對其的描述中。然而，並不應將該公開的方法解釋成反映如下示意圖：即所要求保護的本說明書要求比在每個請求項中所明確記載的特徵更多的特徵。更確切地說，如下面的申請專利範圍所反映的那樣，發明方面在於少於前面公開的單一實施例的所有特徵。因此，遵循具體實施方式的申請專利範圍由此明確地併入該具體實施方式，其中每個請求項本身都作為本說明書的單獨實施例。
本領域那些技術人員可以理解，可以對實施例中的設備中的模組進行自我調整性地改變並且把它們設置在與該實施例不同的一個或多個設備中。可以把實施例中的模組或單元或元件組合成一個模組或單元或元件，以及此外可以把它們分成多個子模組或子單元或子元件。除了這樣的特徵和/或過程或者單元中的至少一些是相互排斥之外，可以採用任何組合對本說明書(包括伴隨的申請專利範圍、摘要和圖式)中公開的所有特徵以及如此公開的任何方法或者設備的所有過程或單元進行組合。除非另外明確陳述，本說明書(包括伴隨的申請專利範圍、摘要和圖式)中公開的每一特徵可以由提供相同、等同或相似目的的替代特徵來代替。
此外，本領域的技術人員能夠理解，儘管在此的一些實施例包括其它實施例中所包括的某些特徵而不是其它特徵，但是不同實施例的特徵的組合意味著處於本說明書的範圍之內並且形成不同的實施例。例如，在下面的申請專利範圍中，所要求保護的實施例的任意一者都可以以任意的組合方式來使用。
本說明書的各個部件實施例可以以硬體實現，或者以在一個或者多個處理器上運行的軟體模組實現，或者以它們的組合實現。本領域的技術人員應當理解，可以在實踐中使用微處理器或者數位訊號處理器(DSP)來實現根據本說明書實施例的閘道、代理伺服器、系統中的一些或者全部部件的一些或者全部功能。本說明書還可以實現為用於執行這裡所描述的方法的一部分或者全部的設備或者裝置程式(例如，電腦程式和電腦程式產品)。這樣的實現本說明書的程式可以儲存在電腦可讀媒體上，或者可以具有一個或者多個信號的形式。這樣的信號可以從網際網路網站上下載得到，或者在載體信號上提供，或者以任何其他形式提供。
應該注意的是上述實施例對本說明書進行說明而不是對本說明書進行限制，並且本領域技術人員在不脫離所附申請專利範圍的範圍的情況下可設計出替換實施例。在權利要求中，不應將位於括弧之間的任何參考符號構造成對申請專利範圍的限制。單詞“包含”不排除存在未列在申請專利範圍中的元件或步驟。位於元件之前的單詞“一”或“一個”不排除存在多個這樣的元件。本說明書可以借助於包括有若干不同元件的硬體以及借助於適當程式設計的電腦來實現。在列舉了若干裝置的單元請求項中，這些裝置中的若干個可以是透過同一個硬體項來具體體現。單詞第一、第二、以及第三等的使用不表示任何順序。可將這些單詞解釋為名稱。Hereinafter, exemplary embodiments of the present invention will be described in more detail with reference to the drawings. Although the exemplary embodiments of the present invention are shown in the drawings, it should be understood that the present invention can be implemented in various forms and should not be limited by the embodiments set forth herein. On the contrary, these embodiments are provided to enable a more thorough understanding of the present invention and to fully convey the scope of the present invention to those skilled in the art. The nouns involved in this specification are analyzed as follows: Strategy: A conclusion judgment with business significance formed after the combination of multiple rules and conditions. The "rule" is the value of the configuration variable, which produces a success or failure or verification result; Event: is the most basic unit of risk control that describes the specific business behavior of the user, such as login, registration, transfer and other instant requests with business significance All can be called "events". The intelligent risk control decision-making system interacts with peripheral systems (such as business systems) through events. Simulation trigger: refers to the simulated behavior in which the business system consults the risk control system through real-time "event" request, and the risk control system triggers the corresponding strategy and returns the decision result to the business system. It mainly provides self-inspection and troubleshooting for the correct launch of the strategy to ensure that the new configuration strategy meets expectations and the stability of business indicators. This specification discloses a processing system that can be widely used in various industries to process various types of business, such as financial business, sales business, and so on. Financial business such as deposit and withdrawal business, credit business, securities business, insurance business and so on. Sales business such as car sales, electronics sales, electrical sales, etc. Furthermore, this specification also has the concept of "business scenario". Taking financial business as an example, business scenarios include but are not limited to: savings business scenarios (debit card business), credit business scenarios (credit card business), insurance business scenarios (insurance business), and so on. Referring to Fig. 1, the processing system of this embodiment includes two parts: a business system 01 and an intelligent risk control decision-making system 02. The business system 01 is used to receive the event set and transmit the event set to the intelligent risk control decision-making system 02 of this specification for processing. In the process of receiving events, events can be received from various data ports, or events can be generated in the business system 01 by receiving user operations. Among them, the business system 01 is equipped with various data ports for data connection with third-party business platforms. One data interface faces one type of business platform. Third-party service platforms include, but are not limited to, mobile phone service platforms, shopping mall service platforms, PC service platforms, etc. The various business requests from these business platforms are collectively referred to as events in this manual. Events include but are not limited to: login, registration, transaction (transfer), password modification, loan, report (reporting abnormal events, such as reporting abnormal transactions), applications, etc. For example, a certain user initiates an XX transaction in the XX business scenario at XX time; for another example, a certain user initiates an XX application in the XX business scenario at XX time. Each event has its own business scenario. Refer to Figure 2, which is a schematic diagram of the mapping relationship between third-party business platforms, events, and business scenarios. The intelligent risk control decision-making system 02 is used to identify the risk of the event set by the identification strategy to obtain the risk behavior of the event set; among them, each event in the event set has its own business scenario; the identification strategy includes each event in the event set The sub-strategy for processing, which is determined according to the business scenario of the event; generates a response decision based on the risk behavior of the event set; the response decision includes a personalized response decision for each event; monitors and analyzes the risk behavior and response decision to obtain The analysis result of the event set; adjust the identification strategy and response decision according to the analysis result of the event set. The intelligent risk control decision-making system 02 is used to feed back the personalized response decision of each event to the business system 01; the business system 01 is used to execute the execution decision of each event according to the personalized response decision of each event. The following describes the specific implementation process of business system 01. Among them, referring to Fig. 1, the business system 01 includes: an event receiving module 11 for receiving event sets. Since the business system 01 cannot process the event set, the event set needs to be transmitted to the intelligent risk control decision-making system 02. The risk control decision-making system will perform risk identification on the event set, generate response decisions and other operations, and guide the business system 01 according to the event set The response decision-making process. The specific implementation process of the intelligent risk control decision-making system 02 will be described in detail in the following embodiments, so it will not be repeated here. The event filling module 12 is used to obtain the response decision of the event set from the intelligent risk control decision-making system 02; wherein, the response decision includes a personalized response decision for each event. And according to the individualized response decision of each event, the execution decision of each event is generated. The event distribution module 13 is used to distribute the response decision of the event set to the decision return module. The decision return module 14 is used to execute the respective execution decisions of the decision configuration according to the individualized response of each event. The process of each event configuration execution decision has nothing to do with other events. For example, the personalized response decision for an event is a rejection decision. It will be executed according to the personalized decision configuration such as the failure to modify the password and the risk of your operating environment. The above is the overall interaction process between the business system 01 and the intelligent risk control decision-making system 02. Provide operational responses to the event set at the front end through the business system 01, identify the risk of the event set at the back end through the intelligent risk control decision system 02 and generate response decisions, and adjust the identification strategies and response decisions based on the analysis results to ensure risks The effect of prevention and control. Based on the same inventive concept, another embodiment of this specification provides an intelligent risk control decision-making method, which is applied to the intelligent risk control decision-making system 02. Generally speaking, after the event is transmitted, after calling the corresponding sub-strategy for configuration, personalized response decisions will be generated: decisions such as pass, reject, pending and so on. The traditional prevention and control strategy logic has been solidified in the intelligent risk control decision-making system 02 when the system is developed, and will not be changed due to changes in external conditions, and the flexibility of strategy adjustment is extremely low. For example, a loan needs to exceed a certain threshold before it is passed, which is very fixed and extremely low in flexibility. If the above strategy logic is known, it is easy to circumvent it. For example, if the turnover amount exceeds the threshold, the loan can be successfully applied. Even if this vulnerability is discovered, if you want to change it, you need the code staff to modify and replace the code and release the upgraded version of the system before it can take effect. The risk prevention and control capabilities are extremely low. The intelligent risk control decision-making system 02 in this manual supports adaptive adjustment of strategy logic according to actual conditions during operation. Specifically, the identification strategy is called to identify the risk of the event set, obtain the risk behavior of the event set, and generate response decisions based on the risk behavior of the event set. After the event set is identified and decided, the risk behavior and response decision of the event set can be monitored and analyzed, the analysis result of the event set can be obtained, and the identification strategy and response decision can be adjusted according to the analysis result of the event set to be based on the actual situation. Flexible changes to strategies (decisions) can quickly respond to risk situations, thereby reducing misjudgments and improving the accuracy of risk identification. Further, the method of this specification can perform batch processing on event sets, and will generate individualized response decisions for each event, enabling "batch" and "personalized service" to become a major advantage of the system. For example, user A and user B apply for the same amount of loans at the same time, and when risk identification is performed on the two, the tax payment records of both will be called. If user B's tax payment is not continuous or the tax payment amount is low, user B will be given The interest rate of the loan is higher and the amount is lower. If the tax payment of user A is continuous and the amount is high, the loan interest rate for user A is lower and the amount is higher. Therefore, for two users applying for the same amount of loan event, the corresponding response decisions are different. Referring to Figure 3, this method is a step executed by the intelligent risk control decision-making system 02 during the operation process, which specifically includes the following steps: Step 11, call the identification strategy to identify the risk of the event set, and obtain the risk behavior of the event set. Among them, the event set is transmitted by the business system 01, and each event in the event set has its own business scenario. The identification strategy includes a sub-strategy for processing each event in the event set, and the sub-strategy is determined according to the business scenario of the event. Refer to Figure 4, which is a mapping relationship diagram of events, business scenarios, and sub-strategies. Among them, each business scenario has its own sub-strategies (and coping decisions). In the process of invoking the identification strategy to identify the risk of the event set, for each event in the event set, the sub-strategy of each event is determined according to the respective business scenario of each event. Then call the sub-strategy of each event to identify the risk of the event, and obtain the risk behavior of the event. The "event" referred to here actually refers to the event itself. For example, for event 1, the sub-strategy of event 1 is determined, and then the sub-strategy of event 1 is invoked to identify the risk of the event 1 itself. Step 12: Generate a response decision based on the risk behavior of the event set. Among them, the response decision includes a personalized response decision for each event. The individualized response decisions for each event can be the same or different. In the specific implementation process, the sub-strategy of each event is called to identify the risk of the event, and after obtaining the risk behavior of the event, a personalized response decision for the event will be generated for the risk behavior of the event. The individualized response decisions include: pass, reject, pending and other decisions. If an event is a pending decision, it means that the event needs to be further verified. Verification methods include, but are not limited to, face, fingerprint, text message, voice, etc. for verification. The above is the implementation process of risk identification and response decision-making for the event set. For each event in the event set, the above process needs to be performed. Specifically, after calling the sub-strategies to identify the risks of each event, the resulting risk behavior may be risk-free or risky. If the risk behavior of the event is risk-free, a passing decision is generated and transmitted to the business system 01 so that the event can be quickly released. If the risk behavior of the event is risky, a rejection decision or a pending decision is transmitted to the business system 01. In addition, the relevant data of the event set (data on the event itself, risk behavior, decision-making, etc.) will be deposited and stored for subsequent analysis. It can be seen that, with the help of the system, the method in this specification can process the event set in batches through steps such as risk identification and response decision-making, and generate personalized response decisions for each event. No manual review is required, and the review time span is calculated in minutes and seconds, which brings users a better service experience. Of course, this series of operations will be analyzed later. For details, please see the following steps. Step 13, Monitor and analyze the risk behavior and response decision of the event set, and obtain the analysis result of the event set. Monitoring analysis is mainly for real-time monitoring of the operating environment of the intelligent risk control decision-making system 02. After performing operations such as analysis and decision-making on the acquired event set, it is necessary to monitor the pass rate, rejection rate, verification rate, event source, etc. caused by the event set as the basic data for subsequent analysis. For example, the analysis result is that the number of applications in a certain area has increased and the number of channels has increased (for example, the source of the event is Alipay, the source of the event is WeChat, a certain channel has a particularly large volume, etc.). These are very helpful for business development and can be used as basic materials for subsequent business development. In addition, subsequent identification strategies can also be adjusted according to the analysis results. For example, if there is no sub-strategy for risk identification of WeChat pipelines in the identification strategy, the sub-strategies for WeChat pipeline identification can be added to the identification strategy. Step 14. Adjust the identification strategy and response decision according to the analysis result of the event set. In the specific adjustment process, the personalized response decision for a preset event in the monitored event set is a pass decision, and there is no need to adjust. If it is detected that the personalized response decision for a preset event in the event set is a rejection decision and/or a pending decision, during the adjustment process, an optimization sub-strategy for preset events and a preset event will be generated according to the analysis results. Optimize decision making. The optimization sub-strategy of the preset events is used to optimize the original recognition strategy of the preset events, and the optimization decision of the preset events is used to optimize the original response decision of the preset events. The above is the main implementation principle of the intelligent decision method of this embodiment. In addition, this manual also discloses the data center, also known as the unified risk variable pool. In this embodiment, various internal system data (online + offline) are effectively integrated to form a data center. The data center integrates multi-dimensional and multi-featured data to provide data support for the intelligent risk control decision-making engine to make more accurate assessments of events, such as integrating applications, approvals, and post-loans in traditional financial business scenarios. Links are based on data in different business systems 01. Taking the banking system as an example, traditional banks also try to consider simple decision-making engines, and try to make relevant processes online to conduct online real-time approval or real-time decision-making. However, due to the limitations of risk control decision-making engines, they often only support simple list types. filter. And for the very important real-time cumulative variables in risk control (such as "the number of users logged in on the device in the past 7 days" and other cumulative variables), the integration of third-party data (PBC credit information), and how to quote offline data online are all critical issues. It is difficult to quote or even support through configurable methods. The data used by traditional bank risk control is very limited, and it is difficult to manage and apply different departments, different scenarios, and different types of data sources in a unified manner. In order to solve this problem, this manual unifies the online data field and offline data to establish a data center. The data center organically integrates data of different natures, supports the flexible expansion of data from different sources, and shares risk data for businesses in different scenarios, reducing data usage costs on the one hand, and maximizing data value on the other. Furthermore, in order to support the integration of online data domains and offline data domains, this manual adopts the method of data service for quoting, and integrates the data in the offline data domain into the online data domain. In addition, the data service can also access third-party data and integrate it into the online data domain, so as to realize the quotation of offline data domain and third-party data. Specifically, the data center includes online data domains and offline data domains. The online data domain provides online data support for the intelligent risk control decision-making engine. The offline data field provides historical data support for the intelligent risk control decision-making engine. Specifically, the online data field includes the following data: Online cumulative data, records all relevant data of the event set, including: event name, number of users currently logged in the system, device field of the device to which the event belongs, and operation of the event Time and so on. Online list data, record the list of all current events. The dimension table data, including the mobile phone analysis dimension table, the IP address analysis dimension table, and the ID card analysis dimension table, are used by the risk identification module. Among them, the IP address resolution dimension table is third-party data, which is accessed to the dimension table data through the data service. Event data: record all current events. The offline data field includes the following data: Historical event table, which records all relevant data of historical events. For example, if a certain sub-strategy is "call the transfer amount of an account in the past 60 days for determination", the transfer amount of the account in the past 59 days will be washed out from the historical timetable, and the transfer amount on the same day will be added to get a total of 60 Day’s transfer amount. The list table includes blacklists and whitelists; among them, the blacklist records relevant information about abnormal events in historical events, and abnormal events refer to events in which the response decision is a rejection or pending decision. For example, abnormal mobile phone numbers, abnormal bank card numbers, abnormal WIFI, etc. are stored in the blacklist. If the mobile phone number, bank card number, WIFI used, etc. of the event are matched to the blacklist, the response decision of "rejection" will be directly generated. The whitelist records the relevant information of the normal events in the historical events, and the normal events refer to the events in which the response decision is a decision-making pass. The decision table records the response decisions of historical events; among them, the response decisions of historical events include: pass, reject, pending and so on. The case table, which records historical reported events; the credible table, which records the pairing relationship of relevant data of normal events in historical events. The trusted table is similar to a white list. For example, if a user has logged in on a device in the past three months, the login account and the device will be bound and paired. If the user logs in remotely, it will be considered abnormal. The above is the relevant data in the online data domain and the offline data domain. Since historical data is stored in the offline data domain, it needs to be integrated with the online data in the online data domain. At this time, the intelligent risk control decision-making system 02 also includes a data service module, which is used to integrate the offline data domain and the online data domain for the risk identification module to call. In addition, the data service module is also used to access third-party data into the online data domain for the risk identification module to call. The data center is the basis of the data in this manual, which effectively integrates the data of various systems (online + offline), provides multi-dimensional and multi-featured data, and provides a wealth of guns and ammunition for the intelligent risk control decision-making system 02. The following describes the implementation process of each step in detail. In the process of risk identification, the configuration of sub-strategies is first involved. Generally speaking, for each event, you need to configure the event's sub-strategy first, and then perform risk identification for the event based on the sub-strategy. Assuming that the business system 01 transmits a transaction (transaction event) to the intelligent risk control decision-making system 02, the intelligent risk control decision-making system 02 has a series of sub-strategies to identify the transaction event in order to obtain the risk of the transaction. For example, if the amount exceeds 300,000 within 30 days, it is a risky transaction. Suppose the transaction event is the transaction amount within 30 days of checking the account. After the transaction event is transmitted to the intelligent risk control decision-making system 02, the above sub-strategy is called to identify it. For example, if it exceeds 300,000, a personalized response strategy of rejection will be directly generated. The configuration of sub-strategies requires the use of cumulative variables. Cumulative variables refer to the characteristic variables generated through the "flow calculation" in strategy calculations. Cumulative characteristics are mainly generated through the two steps of cumulative management and variable generation. A complete accumulation variable includes four parts: accumulation subject, accumulation content, accumulation function, and accumulation window. For example, the accumulation variable "account transaction amount within 30 days", the subject is the account, the accumulation content is the amount, the accumulation function is SUM, and the accumulation window It's 30 days. In the process of configuring the sub-strategies for each event, it is also necessary to access a variety of data sources such as online data domains, offline data domains, and third-party databases to configure the sub-policies. Specifically, it includes one or a combination of the following methods: The first method: According to the respective business scenarios of each event, determine the value of the configuration variable of the event from the online data field; take the value of the configuration variable of the event , Configure the sub-strategy of the event. The second method: Determine the value of the configuration variable of the event in the offline data field according to the respective business scenario of each event; configure the sub-policy of the event according to the value of the configuration variable of the event. The third method: According to the respective business scenarios of each event, determine the value of the configuration variable of the event from the third-party data; configure the sub-strategy of the event according to the value of the configuration variable of the event. For example, in a tax strategy, a loan can only be issued by paying taxes at a certain local tax bureau. At this time, you need to request tax information from the local tax bureau. The configured strategy is: whether the user has paid taxes for 12 consecutive months in the past, whether the tax payment is continuous, the proportion of the amount reached, and so on. Therefore, the dimensions of the strategy can also be configured from the third-party data for risk prevention and control. The above three methods can be used in any combination or alone. In the process of using sub-strategies to identify the risks of events, model calls are involved, that is: according to the sub-strategies of each event, determine the sub-model of each event, and call each event's own event (the Event) conduct risk identification and obtain the risk behavior of each event. As an optional embodiment, the sub-strategy includes N-layer recognition sub-strategies, and each layer of recognition sub-strategies has a sequential calling relationship; N≥1 and a positive integer. Therefore, the N-level recognition sub-strategy in the sub-strategies of each event is called to identify the risk of the event in turn to obtain the risk behavior of the event. For a single event, since its sub-strategies include N-layer recognition sub-strategies, each layer of recognition sub-strategies has a sequential calling relationship. Therefore, each sub-strategy will carry out risk identification of the event and generate a risky behavior. The risk behavior is "risky", "no risk" and other behaviors. For example, when the results are identified as "passed", "matched", "satisfied", etc., it means that there is no risk. If it is identified as "rejection", "unmatched", "not satisfied", etc., it indicates risky behavior. The risk behavior for each sub-strategy will produce corresponding personalized response decisions. Specifically, if the risky behavior of the current sub-strategy indicates that there is no risk, a "passed" personalized response decision will be generated and transferred to the next sub-strategy for identification. If the risk behavior of the current sub-strategy indicates that there is a risk, a personalized response decision of "rejection" is generated, and the subsequent sub-strategy identification operation is stopped. If it is the last sub-strategy, it will generate corresponding personalized response decisions based on "risky", "riskless" and other behaviors. For example, the recognition strategy for a user's face recognition includes two recognition sub-strategies: "whether the face and the photo of the ID card match" and "whether the number of failed credit applications reaches the threshold". When recognizing the face, first call the first-level recognition sub-strategy "Does the face and the photo of the ID card match" for recognition. If there is no match, a personalized response decision of "rejection" will be produced. If it matches, the number of failed credit applications for the user is obtained, and the second-level recognition sub-strategy "whether the number of failed credit applications reaches the threshold" is called for judgment. If the judgment reaches the threshold, a personalized response decision of "rejection" is generated. If it is judged that the threshold is not reached, a personalized response decision of "passed" is produced. As an optional embodiment, after generating a response decision based on the risk behavior of the event set, if a personalized response decision of an event in the event set is a pending decision, analyze the historical response decision of the event; The historical response decision and the pending decision of the event produce the verification method of the event, and the verification method of the event is different from the verification method in the historical decision of the event. For example, the historical response decision for a login event is "SMS verification", which means that it has been verified by SMS. If the account and password of the login event are identified, it will be combined with historical response to the decision-making "message verification". In this way, the repeated execution of the same verification method is avoided to cause the user's disgust and the waste of decision-making resources is avoided. Assuming that the resulting personalized response decision is a "pending" decision, the "message verification" method cannot be used again. In the specific implementation process of monitoring, the purpose of monitoring is to instantly monitor the operating environment of the intelligent risk control decision-making system 02. After performing operations such as analysis and decision-making on the acquired event set, it is necessary to monitor the pass rate, rejection rate, verification rate, event source, etc. caused by the event set as the basic data for subsequent analysis. The purpose of real-time monitoring of the operating environment of the intelligent risk control decision-making system 02 is to monitor the risks of each sub-strategy, and to make up for the omissions of the sub-strategies and personalized decisions, otherwise it is not known which sub-strategy has a high risk that affects the system. The monitoring can learn the risk hit rate of the sub-strategy, and analyze the specific reasons for the risk hit rate of the sub-strategy, such as the high hit rate caused by the mismatch of the sub-strategy, or whether there is such a risk during this period. If the sub-strategy is mismatched, the sub-strategy can be modified according to the analysis result after the analysis result is obtained through monitoring and analysis. These are all operated during the running process, and there is no need to return to the technical development and re-development version. Specifically, because the decision is a personalized decision such as rejection, approval, or pending. In the monitored event set, the personalized response decision of a preset event is a pass decision, then analyze the risk of the preset event for regular analysis, obtain the analysis result of the preset event, and then according to the analysis result of the preset event , Adjust the sub-strategies of each event in the preset events and individualized response decisions. If the personalized response decision of a preset event in the monitored event set is a rejection decision and/or a pending decision, it means that the preset event is an abnormal event, so the specific risk behavior must be analyzed and the previous one must be denied. In the sub-strategy and individualized response decision-making, improve the prevention and control capability and accuracy of the system. The reason for this is that after the rejection event or the pending handling of the event, an analysis is needed to check for omissions and avoid the vulnerabilities of the identification strategy that will cause serious follow-up impacts. For example, it is discovered that the number of loans applied for in a certain area is overloaded. If the identification strategy is not updated to control the number of loans, if the subsequent loan personnel cannot repay the loan, it will cause a deficit. Therefore, the risk behavior of the preset event is analyzed, and the analysis result of the preset event is obtained. The analysis result is the specific cause of the risk behavior that caused the preset event. Further, during the adjustment, the sub-strategies and personalized response decisions of each event in the preset events will be adjusted according to the analysis results of the preset events, and the configuration can take effect. Specifically, if the personalized response decision of a preset event is a rejection decision and/or a pending decision, the corresponding event will be precipitated to facilitate the analysis of the risk behavior of the preset event and avoid finding anomalies in massive data event. The analysis results are denied to prevention and control to adjust the sub-strategies and personalized response decisions of each event in the preset events, forming a closed loop, which can flexibly adjust the aforementioned strategies and decisions according to the analysis results to quickly compensate The aforementioned deficiencies in strategies and decision-making can improve the accuracy of prevention and control. For example, when analyzing 50 incidents, it is found that the step that produces the rejection decision is the face recognition sub-strategy. The analysis may be due to malicious attacks, or the operating population is older and does not understand the operation. After the decision is identified, the analysis is performed, and the optimization is performed in turn, and the strategy is adjusted in a targeted manner. For example, when the analysis finds that a certain area has the most face recognition in a certain period of time, the strategy of "high risk time" and "region" will be added on the basis of the original strategy. If it is this time and the applicants are all from a certain area, they will be rejected directly, and the analysis results will be added to the previous risk prevention and control to form a closed loop to improve the accuracy of prevention and control. As an optional embodiment, this specification supports flexible expansion of new business scenarios. In the specific implementation process, construct new business scenarios. The target business scenario is determined from all current business scenarios according to the configuration requirements of the new business scenario. The target business scenario is a scenario that provides identification strategies for new business scenarios and configures decision-making responses. The target business scenario has target recognition strategies and target response decisions to configure new business scenarios. Invoke the target recognition strategy and target response decision to configure the new business scenario. For example, the target recognition strategy and target response decision in the credit card center want to borrow, but it must ensure that it cannot affect the use of the credit card center. Therefore, new business scenarios can be constructed to borrow the target recognition strategy and target response decision in the credit card center. Configure it. In use, since the event has scene division, even if the identification strategies of two scenes are the same, different risk behaviors may occur, and the identification strategies of each scene do not affect each other. Through the above description, the intelligent risk control decision-making method in this manual supports the modification of strategy logic, and has great advantages such as real-time risk perception monitoring, real-time configuration and immediate effect, and flexible expansion of scenarios. On the one hand, it has a higher degree of freedom and can flexibly change the recognition strategy and decision-making (instead of the traditional way, the operating students provide the strategy logic, allowing the development students to write the logic in the background, regardless of subsequent modification or management. Convenience). On the other hand, while improving the review speed and prevention and control accuracy rate, since the identification strategy and decision can be changed in real time, it also reduces the probability of the system being compromised (the traditional way of writing the strategy logic to death is easy to be hacked and grayed out. Go around and break after this attempt). In addition, the method in this manual can realize the monitoring (magnitude, rejection rate, etc.) of all strategies configured in all scenarios to comprehensively monitor the risk situation, and can respond flexibly and quickly optimize strategies according to changes. As an optional embodiment, this specification also supports policy configuration and self-checking. At present, in many traditional risk control, the identification strategy is usually launched directly (the strategy self-check cannot be supported), and after the abnormality is found, the post-remediation is performed. Such a high probability will lead to operational tragedies (such as a surge in interruption rates or a surge in rejection rates). In order to effectively control operational risks, when a new identification strategy is launched, it is necessary to simulate the trigger event and the automatic comparison strategy self-check function to ensure that the results of the new identification strategy are in line with expectations during the launch of the new identification strategy, and make the flexible system more operational. Robustness, avoiding operational risks in advance through simulated behaviors, rather than remediating afterwards after discovering anomalies after going online, can avoid operational tragedies (such as a surge in interruption rates or a surge in rejection rates) caused by operational risks. Specifically, a new identification strategy is generated, where the new identification strategy has expected data. The expected data is used as a test standard for the new identification strategy. Configure simulated events to detect the new identification strategy, and perform corresponding operations on the new identification strategy based on the detection report obtained from the detection. In the specific implementation process, configure the simulated event; execute the simulated event, call the new recognition strategy to process the simulated event, and obtain the result data; determine whether the result data meets the expected data, and generate a test report; if the test report indicates that the result data meets the expected data , Configure the new recognition strategy to the corresponding business scenario. For example, suppose we need to launch a strategy A that is "the registration time of the transfer user is less than 30 days and the transfer amount is greater than 5000", and verification is issued when it hits (such as sending a text message). Then, specifically: 1. Event configuration: registration event configuration, transfer event configuration; variable configuration: variable var1 "number of days from the current time of registration" and variable var2 "transfer amount"configuration; strategy configuration: strategy A configuration (try Running but not online). 2, Simulation trigger: In order to verify whether strategy A meets expectations, we need to design and construct data (as shown in Table 1) to simulate the behavior of normal users, trigger strategy A, and deposit the corresponding result data. 3. Automatic comparison: Based on the second step above, we will automatically compare the expected results and result data of strategy A and all variables (var1 and var2) (see Table 2), and produce the corresponding test report. 4. Strategy online: Based on the above step 3, when the content of the inspection report meets expectations, follow the process "trial operation -> grayscale (adjustment) -> formal operation" to implement the strategy online; otherwise, check the abnormality and return to the location. Go to step 1 or 2. Use case number Use case description Send times Experimental design attributes
Incident time Event code Transaction name Core customer number Amount ( yuan )
TR079P Registration (pre-) 1 systime-15d REGISTER registered userid1
TR079 The registration time of the transfer user is less than 3 days and the transfer amount is greater than 5000 1 systime TRANSFER Transfer userid1 6000
Table 1: Strategy self-check-data structure & simulation trigger Among them, the event occurrence time: Systime represents the current timestamp of the system when the trigger event is sent. Similarly, Systime-15d means the timestamp 15 days ago; for example: the system timestamp taken by Systime is '2018-12-31 10:24:20', then the corresponding timestamp of Systime-15d is '2018-12- 16 10:24:20'. Use case number event Strategy Strategy Expected Value Strategy actual value variable Expected value Actual value variable Expected value Actual value
TR079 Transfer Strategy A check check var1 15 15 var2 6000 6000
Table 2: Strategy self-check-automatic comparison Above, the strategy self-check module based on "analog trigger" and "automatic comparison" makes the flexible system operation more stable. By simulating behaviors, we can avoid operational risks beforehand, instead of remediating after we discover abnormalities after going online. As an optional embodiment, if there are reported incidents in the event collection, the reported incident and its personalized response decision are reviewed to obtain the trial result; the trial result is monitored and analyzed to obtain the analysis result of the reported incident. Further, the sub-strategies and personalized response decisions corresponding to the reported incident will be adjusted according to the analysis result of the reported incident. The above is the specific implementation process of the intelligent risk control decision-making method. Based on the same inventive concept as the previous embodiment, the embodiment of this specification also provides a business processing method, which is applied to a business processing system. The implementation process of the method is as follows: Business The system 01 receives the event set, and transmits the event set to the intelligent risk control decision-making system 02 disclosed in one or more of the above embodiments; The intelligent risk control decision-making system 02 calls the identification strategy to identify the risk of the event set, and obtains the risk behavior of the event set; Among them, each event in the event set has its own business scenario; the identification strategy includes a sub-strategy for processing each event in the event set, and the sub-strategy is determined according to the business scenario of the event; the response decision is generated according to the risk behavior of the event set ; Response decisions include individualized response decisions for each event; monitor and analyze risk behaviors and response decisions to obtain the analysis results of the event set; adjust identification strategies and response decisions based on the analysis results of the event set. The specific processing method has been introduced in one or more of the above embodiments, so it will not be repeated here. The intelligent risk control decision-making system 02 feeds back the personalized response decision of each event to the business system 01; the business system 01 generates the execution decision of each event according to the personalized response decision of each event. The specific execution process of the business system 01 has been introduced in one or more of the above embodiments, so it will not be repeated here. Based on the same inventive concept as in the foregoing embodiment, referring to Fig. 1, the embodiment of this specification also provides an intelligent risk control decision-making system 02. The specific implementation process of the system is the same as in the foregoing method embodiment, so specific examples and explanations are not given. To repeat it again, it includes: The risk identification module 21 is used to call the identification strategy to identify the risk of the event set, and obtain the risk behavior of the event set. Among them, the event set is transmitted by the business system 01, and each event in the event set has its own business scenario; the recognition strategy includes a sub-strategy for processing each event in the event set, and the sub-strategy is determined according to the business scenario of the event. The risk decision module 22 is used to generate response decisions based on the risk behavior of the event set. The response decision includes a personalized response decision for each event; the monitoring analysis module 23 is used to monitor and analyze the risk behavior and response decision of the event set to obtain the analysis result of the event set; the strategy adjustment module 24 is used to monitor and analyze the risk behavior and response decision of the event set; The analysis results of the event set adjust the identification strategy and response decision. As an optional embodiment, the risk identification module 21 is specifically used to: For each event in the event set, determine the sub-strategy of each event according to the respective business scenario of each event; call the sub-strategy of each event The strategy identifies the risk of the event and obtains the risk behavior of the event. As an optional embodiment, the risk identification module 21 is specifically configured to process one or a combination of the following steps: According to the respective business scenarios of each event, determine the value of the configuration variable of the event from the online data field ; According to the value of the configuration variable of the event, configure the sub-strategy of the event; According to the respective business scenario of each event, determine the value of the configuration variable of the event from the offline data field; take the value of the configuration variable of the event , Configure the sub-strategy of the event; determine the value of the configuration variable of the event from the third-party data according to the respective business scenario of each event; configure the sub-strategy of the event according to the value of the configuration variable of the event. In addition, this manual also discloses the data center, also known as the unified risk variable pool. The data center has already been described in detail in the above embodiment, so the description will not be repeated here. Further, in order to support the integration of online data domains and offline data domains, this system also includes: a data service module, used to integrate data from offline data domains into online data domains, or to integrate third-party data into online data In order to realize the reference of offline data domain and third-party data. As an optional embodiment, the risk decision module 22 is specifically used to: if the personalized response decision of an event in the event set is a pending decision, analyze the historical response decision of the event; and analyze the historical response decision of the event; Unlike the verification method for the event pending decision to generate the event, the verification method for the event is different from the verification method in the historical decision of the event. As an optional embodiment, the monitoring analysis module 23 is specifically configured to perform the risk behavior of a preset event if the personalized response decision of a preset event is a rejection decision and/or a pending decision in the monitored event set Analyze to obtain the analysis result of the preset events; the strategy adjustment module 24 is specifically used to adjust the sub-strategies and personalized response decisions of each event in the preset events according to the analysis results of the preset events. As an optional embodiment, the system further includes a scenario configuration module for: constructing a new business scenario; determining a target business scenario from all current business scenarios according to the configuration requirements of the new business scenario, and the target business scenario has a target Identify strategies and target response decisions; call target recognition strategies and target response decisions to configure new business scenarios. As an optional embodiment, the system further includes: a strategy generation module, used to generate a new recognition strategy, wherein the new recognition strategy has expected data; a strategy detection module, used to configure a simulated event to detect the new recognition strategy, Perform corresponding operations on the new identification strategy based on the detection report obtained from the detection. As an optional embodiment, the strategy detection module includes: an event configuration module, used to configure simulation events; a simulation trigger module, used to execute simulation events, call a new recognition strategy to process the simulation events, and obtain result data The comparison module is used to determine whether the result data meets the expected data and generate a test report; the strategy online module is used to configure the new identification strategy into the corresponding business scenario if the test report indicates that the result data meets the expected data. As an optional embodiment, the system further includes: a trial module, which is used to review the reported event and its personalized response decision if there is a reported event in the event set, and obtain the trial result; a monitoring analysis module 23, used to The trial results are monitored and analyzed, and the analysis results of the reported incidents are obtained. Based on the same inventive concept as the foregoing embodiment, the embodiment of the present specification also provides a computer-readable storage medium on which a computer program is stored, and when the program is executed by a processor, the steps of any of the foregoing methods are implemented. Based on the same inventive concept as the previous embodiment, the embodiment of this specification also provides a computer device, as shown in FIG. 5, including a memory 504, a processor 502, and stored on the memory 504 and can be stored on the processor 502 The running computer program, when the processor 502 executes the program, implements the steps of any of the foregoing methods. Among them, in FIG. 5, the bus bar architecture (represented by bus bar 500), the bus bar 500 may include any number of interconnected bus bars and bridges, and the bus bar 500 will include one or more processes represented by the processor 502 The memory and various circuits of the memory represented by the memory 504 are connected together. The bus bar 500 can also connect various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are all known in the art, and therefore, no further descriptions thereof are provided herein. The bus interface 506 provides an interface between the bus 500 and the receiver 501 and transmitter 503. The receiver 501 and the transmitter 503 may be the same component, that is, a transceiver, which provides a unit for communicating with various other terminal devices on the transmission medium. The processor 502 is responsible for managing the bus 500 and general processing, and the memory 504 can be used to store data used by the processor 502 when performing operations. Through one or more embodiments of this specification, this specification has the following beneficial effects or advantages: This specification discloses intelligent risk control decision-making methods and systems, business processing methods and systems, calling identification strategies to identify event sets for risk identification, and obtaining events Set risk behaviors, and generate response decisions based on the risk behaviors of the event set. After the event set is identified and decided, the risk behavior and response decision of the event set can be monitored and analyzed, the analysis result of the event set can be obtained, and the identification strategy and response decision can be adjusted according to the analysis result of the event set to be based on the actual situation. Flexible changes to strategies (decisions) can quickly respond to risk situations, thereby reducing misjudgments and improving the accuracy of risk identification. The algorithms and displays provided here are not inherently related to any particular computer, virtual system or other equipment. Various general-purpose systems can also be used with the teaching based on this. From the above description, the structure required to construct this type of system is obvious. In addition, this manual is not aimed at any specific programming language. It should be understood that various programming languages can be used to implement the content of this specification described here, and the above descriptions in specific languages are for the purpose of disclosing the best implementation of this specification. In the instructions provided here, a lot of specific details are explained. However, it can be understood that the embodiments of this specification can be practiced without these specific details. In some instances, well-known methods, structures, and technologies are not shown in detail, so as not to obscure the understanding of this specification. Similarly, it should be understood that in order to simplify the present invention and help understand one or more of the various inventive aspects, in the above description of the exemplary embodiments of this specification, the various features of this specification are sometimes grouped together into a single embodiment. , Figure, or its description. However, the disclosed method should not be interpreted as reflecting the following schematic diagram: that is, the claimed specification requires more features than the features clearly recorded in each claim. More precisely, as reflected in the scope of the patent application below, the invention lies in less than all the features of the single embodiment disclosed above. Therefore, the scope of the patent application following the specific embodiment is thus clearly incorporated into the specific embodiment, in which each claim itself serves as a separate embodiment of this specification. Those skilled in the art can understand that it is possible to self-adjustably change the modules in the device in the embodiment and set them in one or more devices different from the embodiment. The modules or units or elements in the embodiments can be combined into one module or unit or element, and in addition, they can be divided into multiple sub-modules or sub-units or sub-elements. Except that at least some of such features and/or processes or units are mutually exclusive, any combination can be used to compare all features disclosed in this specification (including the accompanying patent scope, abstract, and drawings) and any method disclosed in this manner. Or all the processes or units of the equipment are combined. Unless expressly stated otherwise, each feature disclosed in this specification (including the accompanying patent scope, abstract and drawings) can be replaced by an alternative feature providing the same, equivalent or similar purpose. In addition, those skilled in the art can understand that although some embodiments herein include certain features included in other embodiments but not other features, the combination of features of different embodiments means that they are within the scope of this specification. And form different embodiments. For example, in the scope of the following patent applications, any one of the claimed embodiments can be used in any combination. The various component embodiments in this specification can be implemented by hardware, or by software modules running on one or more processors, or by a combination of them. Those skilled in the art should understand that a microprocessor or a digital signal processor (DSP) can be used in practice to implement some or all of the gateway, proxy server, and some or all components of the system according to the embodiments of this specification. Features. This specification can also be implemented as a device or device program (for example, a computer program and a computer program product) for executing part or all of the methods described herein. Such a program for implementing this specification may be stored on a computer-readable medium, or may have the form of one or more signals. Such signals can be downloaded from Internet sites, or provided on carrier signals, or provided in any other form. It should be noted that the above-mentioned embodiments illustrate this specification rather than limit it, and those skilled in the art can design alternative embodiments without departing from the scope of the appended patent application. In the claims, any reference signs located between parentheses should not be constructed to limit the scope of the patent application. The word "comprising" does not exclude the presence of elements or steps that are not listed in the scope of the patent application. The word "a" or "an" preceding an element does not exclude the presence of multiple such elements. This description can be realized by means of hardware including several different components and by means of a computer with appropriate programming. Among the unit request items that list several devices, several of these devices can be embodied through the same hardware item. The use of the words first, second, and third, etc. do not indicate any order. These words can be interpreted as names.
