為了更好的理解上述技術方案，下面通過圖式以及具體實施例對本說明書實施例的技術方案做詳細的說明，應當理解本說明書實施例以及實施例中的具體特徵是對本說明書實施例技術方案的詳細的說明，而不是對本說明書技術方案的限定，在不衝突的情況下，本說明書實施例以及實施例中的技術特徵可以相互組合。
參見圖1，為本說明書實施例風險識別應用場景示意圖。終端100位於用戶側，與網路側的伺服器200通信。終端100中的交易處理用戶端101可以是基於互聯網實現業務的APP或網站，為用戶提供交易的介面並將交易資料提供給網路側進行處理；伺服器200中的風險識別系統201用於對交易處理用戶端101中涉及的有風險交易進行識別。
以服務商提供雲端計算、雲端儲存和雲端安全等雲端服務商品為例，現有的付費模式包括後付費模式，即在用戶側下訂單至伺服器後，先提供訂單請求中的雲端服務商品至用戶側使用，再由服務商統一在固定時間(例如，每月的固定扣款日)進行批量扣款。然而，在用戶出現資金問題或存在低信用用戶時，服務商在固定時間的扣費容易出現存款餘額不足導致的扣款失敗，從而出現壞帳，給服務商帶來經濟損失。
本說明書實施例，為不同的用戶側定制出符合其自身行為特徵的購買權限，從而能根據當前購買權限更準確的識別出該用戶側的訂單請求是否存在風險，即減小了服務商的經濟損失，也避免了購買權限設置不合適導致的對高信用等級客戶的頻繁打擾。
第一方面，本說明書實施例提供一種風險識別方法，用於根據用戶側的用戶資訊，確定其信用等級和其對應的當前購買權限，從而根據當前購買權限識別用戶側發送的訂單請求是否存在風險。
請參考圖2，上述方法包括S201-S203。
S201：獲取表徵用戶側的行為特徵的用戶資訊，並基於用戶資訊確定用戶側的信用等級。
在本申請實施例中，該用戶資訊，包括：用戶側的註冊資訊、歷史付費資訊或設備狀態資訊中的任一種或多種資訊。具體來講，可以是用戶註冊區域資訊、註冊行業資訊、關聯帳戶活躍資訊、設備資訊、環境資訊、歷史預付費繳費資訊、歷史後付費繳費資訊和產品使用資訊中的一種或多種資訊。
其中，用戶註冊區域資訊是用戶註冊的地理區域，例如：成都、武漢或華南等；註冊行業資訊是用戶註冊的業務所屬領域的資訊，例如：教育、醫療或政務等；關聯帳戶活躍資訊是用戶側關聯的帳戶的登錄時長、頻率或使用年限等資訊；設備資訊是用戶側設備的型號、類型或設備數量等資訊；環境資訊是用戶側設備的網路連接環境或安裝系統環境等資訊；歷史預付費繳費資訊是用戶側以前預先繳費再使用服務商品的金額、次數等資訊；歷史後付費繳費資訊是用戶側以前先使用服務商品再付費的金額、次數、延遲付款等資訊；產品使用資訊是用戶側購買和使用過的服務商品種類、數量和使用時長等資訊。
上述用戶資訊的獲取可以是由用戶側安裝的APP或開啟的網站根據預設的上報規則，觸發用戶側發送給伺服器的；也可以是由伺服器發送收集請求至用戶側獲取的；還可以是伺服器從交易日誌中整理獲取的，在此不作限制。
而基於用戶資訊確定用戶側的信用等級的方法也可以有多種，下面列舉兩種為例：
第一種，以用戶資訊作為預設模型的輸入資料，通過預設模型計算確定用戶側的信用等級。
具體來講，採用預設模型來計算各個用戶側的信用等級不僅能通過快速的模型計算提高確定信用等級的速度，還能通過採用越來越豐富的用戶資訊作為該預設模型的訓練資料來提高模型的計算精確度，使確定出的信用等級更符合各用戶側的行為特徵。
在具體實施過程中，可以是，以用戶資訊作為預設模型的輸入資料，通過預設模型的計算直接輸出信用等級資料；也可以是，以用戶資訊作為預設模型的輸入資料，通過預設模型先計算輸出用戶側的信用分數，再根據信用分數和預存的信用分數與信用等級的對應關係，確定用戶側的信用等級，在此不作限制。
預設模型可以是基於隨機森林演算法的模型，也可以是基於其他的有監督或無監督演算法的模型，例如：梯度提升樹演算法，神經網路演算法，聚類演算法，基於高斯分佈的異常檢測演算法，等等，在此不作限制。
下面以採用隨機森林演算法生成預設模型，該預設模型輸出信用分數為例進行說明。
隨機森林是包含多個決策樹的森林演算法，並且其輸出的分值是由個別樹輸出的分值的眾數而定。即是用隨機的方式建立一個森林，森林裡面包括很多的決策樹，隨機森林的每棵決策樹之間是沒有關聯的。當有一個新的輸入樣本進入的時候，就由森林中的每一棵決策樹分別進行計算，確定該樣本的分值，然後看看哪個分值被選擇最多，就作為這個樣本的預測分值。
例如，在本說明書實施例中，先收集近兩年的用戶資料，包括各用戶側的用戶資訊，及各用戶側的扣費情況資料，再由工作人員對用戶資料進行整理，並按照扣費情況進行預打分，生成n條訓練樣本，其中，每條訓練樣本包括一用戶側的用戶資訊及其對應的預打分分值。將n條訓練樣本輸入隨機森林演算法生成預設模型進行打分，將計算出的預測分值與訓練樣本的預打分分值進行比對，再根據比對結果修正預設模型，從而完成對預設模型的訓練。在預設模型的預打分分值與預打分分值的差值小於預設範圍時，認為該預設模型符合預期，可以部署上線來確定用戶信用等級。
而根據預設模型計算輸出的用戶側的信用分數，來確定用戶側的信用等級的方法，可以是預先設置信用分數範圍與信用等級的映射表格，通過查詢映射表格來確認信用等級；也可以是預先設置信用分數與信用等級的計算規則，通過計算規則來確認信用等級(例如，以信用分數的十位數字作為其信用等級)，在此不作限制。
第二種，設置信用等級與用戶資訊的映射表格，通過查表確定信用等級。
即預先設置信用等級與用戶資訊的映射表格，該映射表格中列舉有不同的用戶資訊組合及其對應的信用等級，獲取用戶資訊後，只需要到表格中查找到該用戶資訊對應的信用等級即可。
當然，在具體實施過程中，根據用戶資訊確認信用等級的方式不限於上述兩種，在此不作限制，也不再一一列舉。
S202：根據信用等級和預存的信用等級與購買權限的對應關係，確定用戶側的當前購買權限。
具體來講，可以預先設置信用等級與購買權限的映射表，通過查詢該映射表來確定用戶側的信用等級對應的購買權限，作為該用戶側本次下訂單的當前購買權限。
在本申請實施例中，用戶側的當前購買權限，包括：該用戶側允許購買的產品種類、產品數量或延後付款額度中的任一種或多種。其中，延後付款額度是指用戶能先使用商品，後進行支付的商品費用總額度。具體來講，當購買的服務商品為雲端服務商品時，該產品數量可以是指實例數額度，即指提供服務的設備數量或資源大小。
舉例來說，以服務商品為雲端服務商品為例，購買權限可以是：該用戶側本次只能購買雲端計算服務和雲端儲存服務；該用戶側只有獲得4台實例數；該用戶側的延後付款額度為2萬。
以服務商品為網購平臺服務商品為例，購買權限可以是：該用戶側本次只能購買將商鋪連結推送顯示在主頁的服務；該用戶側的延後付款額度為1萬。
S203：根據當前購買權限，識別用戶側發送的訂單請求是否存在風險。
通過判斷訂單請求中攜帶的購買資訊是否滿足當前購買權限的規定即可以識別是否存在風險。如果購買請求超出當前購買權限的範圍，則認為存在風險；如果購買請求在當前購買權限的範圍內，則認為不存在風險。
舉例來講，用戶側發送的訂單請求中攜帶有本次購買的產品種類和產品數量，根據產品種類和產品數量能夠確定該次購買所需的總費用。分別判斷訂單請求中購買的產品種類、產品數量和總費用是否符合當前購買權限規定的產品種類、產品數量和延後付款額度。如果均符合則認為不存在風險，如果有不符合則認為存在風險。
例如，用戶側發送的訂單請求攜帶的購買資訊為，購買雲端安全服務，3台實例數。而確定出該用戶側的當前購買權限為只能購買雲端計算服務和雲端儲存服務；該用戶側只有獲得4台實例數；該用戶側的延後付款額度為2萬。由於雲端安全服務不在該用戶側的當前購買權限內，則認為存在風險。
還需要說明的是，本實施提供的風險識別方法可以有多種實施流程方案，下面列舉兩種為例：
第一種，由訂單請求觸發獲取用戶資訊。
在伺服器接收到用戶側發送的訂單請求後，觸發回應該訂單請求，執行步驟S201~S203。即伺服器是在接收到用戶側的訂單請求後才觸發獲取用戶資訊進行風險識別。
第二種，定期獲取用戶資訊進行用戶等級確定，由訂單請求觸發風險識別。
按預設的第一週期(每天，每2天或每10小時等)執行步驟S201~S202，並儲存各用戶側確定出的當前購買權限，在伺服器接收到用戶側發送的訂單請求後，觸發回應該訂單請求，執行步驟S203。即伺服器會定期(每天、每10小時或每週)收集各用戶側的用戶資訊來確定個用戶側的當前購買權限並儲存，在接收到用戶側的訂單請求後才觸發根據當前購買權限進行風險識別。
當然，在具體實施過程中，不限於上述兩種實施流程方案，也可以定期執行步驟S201，在接收到用戶側的訂單請求後才觸發執行步驟S202~S203，在此不作限制。
在通過步驟S203識別出訂單請求是否存在風險後，就可以根據識別結果設置不同的風險處理方法，來保證服務商的經濟利益。
在一種實現方式中，在識別出訂單請求是否存在風險後，如果不存在風險，則向所述用戶側提供訂單請求對應的服務商品；如果存在風險，則攔截該訂單請求。為了避免攔截該訂單請求後導致用戶側不能再下單購買服務商品，可以設置伺服器向用戶側回饋攔截資訊，該攔截資訊包括：攔截的理由說明，提示用戶提升信用等級的方法(例如，指導用戶提交相應資料證明或指導用戶綁定新的付款帳戶等)。
在另一種實現方式中，在識別出訂單請求是否存在風險後，如果不存在風險，則向所述用戶側提供訂單請求對應的服務商品；如果存在風險，則先扣除部分預付款項，再向所述用戶側提供訂單請求對應的服務商品。
進一步，考慮到在用戶側的訂單請求通過後，其使用服務商品的過程中，隨著使用時間的增加，會產生更多的費用消耗，為了減少用戶側在使用服務商品過程中的費用消耗給服務商帶來的經濟損失風險，本實施例還設置在向用戶側提供訂單請求對應的服務商品之後，還會按預設的第二週期(一小時、半小時或一天等)獲取用戶側使用服務商品的使用資訊，並根據使用資訊生成帳單資料，再根據生成的帳單資料，識別用戶側是否存在存款不足風險。
在一種實現方式中，識別用戶側是否存在存款不足風險的過程為：將新生成的帳單資料和該用戶側的其他行為特徵資料作為新的用戶資訊，再採用步驟S201~S202的方法確定出當前購買權限，通過判斷用戶當前使用的服務商品是否符合新計算出的當前購買權限，來識別是否存在存款不足風險。
在另一種實現方式中，識別用戶側是否存在存款不足風險的過程為：將新生成的帳單資料與該用戶側之前確定出當前購買權限中的延後付款額度進行比對，來識別是否存在存款不足風險。可以是新生成的帳單資料的金額大於等於延後付款額度，則認為存在存款不足風險，也可以是新生成的帳單資料的金額距延後付款額度的差額小於預設差額，則認為存在存款不足風險。
進一步，在識別出用戶側存在存款不足風險之後，可以設置從用戶側對應的帳戶中扣除該用戶側已消費但尚未扣款的費用，以減少壞帳風險。如果扣除不成功，則禁止用戶側繼續使用服務商品，減少損失。還可以對扣除不成功的用戶側發送審查資訊，以提醒用戶側上傳審核資料來申請繼續使用商品。
可見，通過本發明實施例提供的風險識別方法，根據用戶側的用戶資訊來確定用戶的信用等級進而確認其當前購買權限，為不同的用戶側定制出符合其自身行為特徵的購買權限，從而能根據當前購買權限更準確的識別出該用戶側的訂單請求是否存在風險，即減小了服務商的經濟損失，也避免了購買權限設置不合適導致的對高信用等級客戶的頻繁打擾。
以一個具體應用場景說明，例如，在購買雲端服務商品的場景，用戶側向伺服器發送訂單請求後，由伺服器的線上信用模型以用戶側的用戶資訊為輸入，對用戶側進行打分。並根據打分確認其是否存在存款不足(Non Fufficient Fund, NSF)風險，如果存在則攔截訂單，如果不存在則用戶下單成功。在用戶下單成功後，每小時產生一次該用戶側的帳單，結合該帳單再採用線上信用模型進行打分，根據打分結果確認是否存在NSF風險。如果不存在風險則不作處理，如果存在風險則觸發扣款。如果扣款成功則不作處理，如果扣款不成功則採取對帳戶持有人的強化審查來瞭解資金來源的合法性(Know Your Customer, KYC)或禁止使用商品等措施。
第二方面，基於同一發明構思，本說明書實施例提供一種風險識別裝置， 參見圖3，所述風險識別裝置，包括：
等級確定單元301，用於獲取表徵用戶側的行為特徵的用戶資訊，並基於所述用戶資訊確定所述用戶側的信用等級；
權限確定單元302，用於根據所述信用等級和預存的信用等級與購買權限的對應關係，確定所述用戶側的當前購買權限；
識別單元303，用於根據所述當前購買權限，識別所述用戶側發送的訂單請求是否存在風險。
在一種可選的方式中，所述用戶資訊，包括：所述用戶側的註冊資訊、歷史付費資訊或設備狀態資訊中的任一種或多種組合。
在一種可選的方式中，所述等級確定單元301還用於：以所述用戶資訊作為預設模型的輸入資料，通過所述預設模型計算確定所述用戶側的信用等級。
在一種可選的方式中，所述等級確定單元301還用於：以所述用戶資訊作為預設模型的輸入資料，通過所述預設模型計算輸出所述用戶側的信用分數；根據所述信用分數和預存的信用分數與信用等級的對應關係，確定所述用戶側的信用等級。
在一種可選的方式中，所述權限確定單元302還用於：確定所述用戶側允許購買的產品種類、產品數量或延後付款額度中的任一種或多種組合。
在一種可選的方式中，所述的裝置還包括：
處理單元304，用於如果所述訂單請求不存在風險，則向所述用戶側提供所述訂單請求對應的服務商品；如果所述訂單請求存在風險，則攔截所述訂單請求。
在一種可選的方式中，所述處理單元304還用於：按預設的第二週期獲取所述用戶側使用所述服務商品的使用資訊，並根據所述使用資訊生成帳單資料；根據所述帳單資料，識別所述用戶側是否存在存款不足風險。
在一種可選的方式中，所述處理單元304還用於：如果所述訂單請求存在存款不足風險，則從所述用戶側對應的帳戶中扣除所述用戶側已消費但尚未扣款的費用。
在一種可選的方式中，所述處理單元304還用於：如果扣除不成功，則禁止所述用戶側使用所述服務商品。
在一種可選的方式中，所述等級確定單元301還用於：在接收所述用戶側發送的所述訂單請求時，回應所述訂單請求，從而獲取表徵用戶側的行為特徵的用戶資訊。
在一種可選的方式中，所述等級確定單元301還用於：按預設的第一週期，獲取表徵用戶側的行為特徵的用戶資訊。
在一種可選的方式中，所述權限確定單元302還用於：接收所述用戶側發送的所述訂單請求；回應所述訂單請求，根據所述當前購買權限，識別所述用戶側發送的訂單請求是否存在風險。
第三方面，基於與前述實施例中風險識別方法同樣的發明構思，本發明還提供一種伺服器，如圖4所示，包括記憶體404、處理器402及儲存在記憶體404上並可在處理器402上運行的電腦程式，所述處理器402執行所述程式時實現前文所述風險識別方法的任一方法的步驟。
其中，在圖4中，匯流排架構(用匯流排400來代表)，匯流排400可以包括任意數量的互聯的匯流排和橋，匯流排400將包括由處理器402代表的一個或多個處理器和記憶體404代表的記憶體的各種電路連結在一起。匯流排400還可以將諸如週邊設備、穩壓器和功率管理電路等之類的各種其他電路連結在一起，這些都是本領域所公知的，因此，本文不再對其進行進一步描述。匯流排界面406在匯流排400和接收器401和發送器403之間提供介面。接收器401和發送器403可以是同一個元件，即收發機，提供用於在傳輸媒體上與各種其他裝置通信的單元。處理器402負責管理匯流排400和通常的處理，而記憶體404可以被用於儲存處理器402在執行操作時所使用的資料。
第四方面，基於與前述實施例中風險識別方法的發明構思，本發明還提供一種電腦可讀儲存媒體，其上儲存有電腦程式，該程式被處理器執行時實現前文所述風險識別方法的任一方法的步驟。
本說明書是參照根據本說明書實施例的方法、設備(系統)、和電腦程式產品的流程圖和/或方框圖來描述的。應理解可由電腦程式指令實現流程圖和/或方框圖中的每一流程和/或方框、以及流程圖和/或方框圖中的流程和/或方框的結合。可提供這些電腦程式指令到通用電腦、專用電腦、嵌入式處理機或其他可程式設計資料處理設備的處理器以產生一個機器，使得通過電腦或其他可程式設計資料處理設備的處理器執行的指令產生用於實現在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能的設備。
這些電腦程式指令也可儲存在能引導電腦或其他可程式設計資料處理設備以特定方式工作的電腦可讀記憶體中，使得儲存在該電腦可讀記憶體中的指令產生包括指令設備的製造品，該指令設備實現在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能。
這些電腦程式指令也可裝載到電腦或其他可程式設計資料處理設備上，使得在電腦或其他可程式設計設備上執行一系列操作步驟以產生電腦實現的處理，從而在電腦或其他可程式設計設備上執行的指令提供用於實現在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能的步驟。
儘管已描述了本說明書的較佳實施例，但本領域內的技術人員一旦得知了基本創造性概念，則可對這些實施例作出另外的變更和修改。所以，所附申請專利範圍意欲解釋為包括較佳實施例以及落入本說明書範圍的所有變更和修改。
顯然，本領域的技術人員可以對本說明書進行各種改動和變型而不脫離本說明書的精神和範圍。這樣，倘若本說明書的這些修改和變型屬於本說明書申請專利範圍及其等同技術的範圍之內，則本說明書也意圖包含這些改動和變型在內。In order to better understand the above technical solutions, the following describes the technical solutions of the embodiments of the present specification in detail through the drawings and specific embodiments. It should be understood that the embodiments of the present specification and the specific features in the embodiments are the technical solutions of the embodiments of the present specification The detailed description, rather than the limitation on the technical solutions of this specification, the embodiments of this specification and the technical features in the embodiments can be combined with each other without conflict.
Refer to FIG. 1, which is a schematic diagram of an application scenario of risk identification according to an embodiment of the present specification. The terminal 100 is located on the user side and communicates with the server 200 on the network side. The transaction processing client 101 in the terminal 100 may be an APP or website that implements business based on the Internet, provides users with an interface for transactions and provides transaction data to the network side for processing; the risk identification system 201 in the server 200 is used for transactions Identify the risky transactions involved in the client 101.
Taking the service provider providing cloud computing products such as cloud computing, cloud storage, and cloud security as an example, the existing payment model includes a post-paid model, that is, after placing an order on the user side to the server, the cloud service product in the order request is first provided to the user For side use, the service provider will uniformly charge in batches at a fixed time (for example, a fixed deduction day every month). However, when users have capital problems or there are low-credit users, the service provider's fee deduction at a fixed time is prone to failure due to insufficient deposit balance, resulting in bad debts and economic losses to the service provider.
In this embodiment of the present specification, purchase rights that match their own behavior characteristics are customized for different user sides, so that it is possible to more accurately identify whether there is a risk in the order request of the user side according to the current purchase rights, which reduces the economics of the service provider. The loss also avoids frequent interruptions to customers with high credit ratings caused by improper purchase authorization settings.
In the first aspect, the embodiments of the present specification provide a risk identification method for determining the credit level and corresponding current purchase authority according to user information on the user side, so as to identify whether the order request sent by the user side is risky according to the current purchase authority .
Please refer to FIG. 2, the above method includes S201-S203.
S201: Obtain user information characterizing the behavior characteristics of the user side, and determine the credit level of the user side based on the user information.
In the embodiment of the present application, the user information includes: any one or more types of information on user-side registration information, historical payment information, or device status information. Specifically, it can be one or more of the user registration area information, registered industry information, linked account active information, equipment information, environmental information, historical prepaid billing information, historical postpaid billing information, and product usage information.
Among them, the user registration area information is the geographical area where the user is registered, such as: Chengdu, Wuhan, or South China, etc.; the registered industry information is information about the domain of the user's registered business, such as: education, medical care, or government affairs; and the related account active information is the user Information such as the login duration, frequency, or years of use of the account associated with the user side; device information is information such as the model, type, or number of devices of the user side device; environmental information is information such as the network connection environment or installation system environment of the user side device; Historical prepaid billing information is the amount and frequency of service goods previously paid by the user beforehand; historical postpaid billing information is the amount, number of times and delayed payment of the service goods previously paid by the user side; product usage information It is information such as the type, quantity and duration of service goods purchased and used by the user.
The above user information can be obtained by the APP installed on the user side or the website opened according to the preset reporting rules, triggering the user side to send to the server; or the server can send a collection request to the user side to obtain; also It can be collected by the server from the transaction log, without limitation.
There are also many ways to determine the credit rating of the user side based on user information. The following two are listed as examples:
In the first type, user information is used as input data of a preset model, and the credit rating of the user side is determined through calculation of the preset model.
Specifically, using the preset model to calculate the credit rating of each user side can not only improve the speed of determining the credit rating through rapid model calculation, but also by using more and more rich user information as the training data of the preset model. Improve the calculation accuracy of the model, so that the determined credit level is more in line with the behavior characteristics of each user side.
In the specific implementation process, the user information can be used as the input data of the preset model, and the credit rating data can be directly output through the calculation of the preset model; or the user information can be used as the input data of the preset model, through the preset The model first calculates and outputs the user's credit score, and then determines the user's credit rating based on the correspondence between the credit score and the pre-stored credit score and credit rating, without limitation.
The preset model can be a model based on a random forest algorithm, or a model based on other supervised or unsupervised algorithms, for example: gradient lifting tree algorithm, neural network algorithm, clustering algorithm, based on Gaussian distribution The anomaly detection algorithm, etc., are not limited here.
The following uses a random forest algorithm to generate a preset model, and the preset model outputs a credit score as an example for description.
Random forest is a forest algorithm that contains multiple decision trees, and the score of its output is determined by the mode of the scores output by individual trees. That is to build a forest in a random way, the forest includes many decision trees, and there is no association between each decision tree in the random forest. When a new input sample enters, each decision tree in the forest is calculated separately to determine the score of the sample, and then see which score is selected most, it is used as the predicted score of this sample .
For example, in the embodiment of this specification, the user data of the past two years is collected first, including user information on each user side, and the deduction information on each user side, and then the user data is collated by the staff, and the deductions are made according to In case of pre-scoring, n training samples are generated, where each training sample includes user information on a user side and its corresponding pre-scoring score. Enter n training samples into the random forest algorithm to generate a preset model for scoring, compare the calculated predicted score with the pre-scoring score of the training sample, and then modify the preset model according to the comparison result to complete the Set the training of the model. When the difference between the pre-scoring score of the preset model and the pre-scoring score is less than the preset range, the preset model is considered to be in line with expectations, and it can be deployed online to determine the user's credit rating.
The method of determining the credit rating of the user side by calculating and outputting the credit score of the user side according to the preset model may be to preset a mapping table of the credit score range and credit level, and confirm the credit level by querying the mapping table; or The calculation rules for credit scores and credit ratings are set in advance, and the credit ratings are confirmed by the calculation rules (for example, the ten-digit number of the credit score is used as its credit rating), which is not limited here.
The second is to set up a mapping table of credit rating and user information, and determine the credit rating by looking up the table.
That is, a mapping table of credit levels and user information is pre-set. The mapping table lists different combinations of user information and their corresponding credit levels. After obtaining user information, you only need to find the credit level corresponding to the user information in the table. can.
Of course, in the specific implementation process, the method of confirming the credit level based on user information is not limited to the above two, and is not limited here, nor will it be listed one by one.
S202: Determine the current purchase right of the user side according to the correspondence between the credit level and the pre-stored credit level and the purchase right.
Specifically, a mapping table of credit levels and purchase rights may be set in advance, and the purchase rights corresponding to the credit levels of the user side may be determined by querying the mapping table as the current purchase rights of the order placed by the user side.
In the embodiment of the present application, the current purchase authority on the user side includes any one or more of the types of products, the number of products, or the amount of deferred payment that the user side is allowed to purchase. Among them, the deferred payment quota refers to the total amount of commodity fees that the user can use the commodity first and then pay. Specifically, when the purchased service product is a cloud service product, the quantity of the product may refer to the instance amount, that is, the number of devices providing services or the size of resources.
For example, taking the service product as a cloud service product as an example, the purchase authority may be: the user side can only purchase cloud computing services and cloud storage services this time; the user side only obtains 4 instances; the user side extension The post-payment limit is 20,000.
Taking the service product as an online shopping platform service product as an example, the purchase authority may be: the user side can only purchase the service that displays the link of the store on the home page this time; the deferred payment limit of the user side is 10,000.
S203: According to the current purchase authority, identify whether there is a risk in the order request sent by the user side.
By judging whether the purchase information carried in the order request meets the requirements of the current purchase authority, it can identify whether there is a risk. If the purchase request exceeds the scope of the current purchase authority, it is considered that there is risk; if the purchase request is within the scope of the current purchase authority, it is considered that there is no risk.
For example, the order request sent by the user side carries the product category and product quantity of the purchase, and the total cost required for the purchase can be determined according to the product category and product quantity. Determine whether the product type, product quantity and total cost purchased in the order request conform to the product type, product quantity and deferred payment limit stipulated by the current purchase authority. If they all meet, it is considered that there is no risk, and if there is any non-compliance, then there is risk.
For example, the purchase information carried in the order request sent by the user side is to purchase a cloud security service and 3 instances. It is determined that the current purchase authority of the user side can only purchase cloud computing services and cloud storage services; the user side only obtains 4 instances; the deferred payment limit of the user side is 20,000. Since the cloud security service is not within the current purchase authority of the user side, it is considered to be a risk.
It should also be noted that the risk identification method provided in this implementation may have multiple implementation process schemes, and the following two examples are listed as examples:
The first type is triggered by the order request to obtain user information.
After receiving the order request sent by the user side, the server triggers the response to the order request, and executes steps S201 to S203. That is, the server triggers the acquisition of user information for risk identification after receiving the order request from the user.
The second method is to periodically obtain user information to determine the user level, and the risk identification is triggered by the order request.
Perform steps S201~S202 according to the preset first cycle (every day, every 2 days or every 10 hours, etc.), and store the current purchase rights determined by each user side. After the server receives the order request sent by the user side, In response to the order request, step S203 is executed. That is, the server will periodically (daily, every 10 hours, or weekly) collect user information on each user side to determine the current purchase authority of each user side and store it. After receiving the order request from the user side, the server will trigger the process according to the current purchase authority. Risk Identification.
Of course, in the specific implementation process, it is not limited to the above two implementation flow schemes, and step S201 may be periodically executed. Steps S202~S203 are triggered after receiving an order request from the user side, which is not limited herein.
After identifying whether there is a risk in the order request through step S203, different risk processing methods can be set according to the identification result to ensure the economic benefits of the service provider.
In one implementation, after identifying whether there is risk in the order request, if there is no risk, the service product corresponding to the order request is provided to the user side; if there is risk, the order request is intercepted. In order to avoid intercepting the order request and causing the user to no longer place an order to purchase service products, the server can be set to feed back interception information to the user. The interception information includes: explanation of the reason for the interception, and a method to prompt the user to improve the credit rating (for example, guidance The user submits the corresponding data certificate or instructs the user to bind a new payment account, etc.).
In another implementation, after identifying whether there is a risk in the order request, if there is no risk, the service product corresponding to the order request is provided to the user side; if there is a risk, some prepayments are deducted first, and then the The user side provides the service goods corresponding to the order request.
Further, considering that after the order request on the user side is passed, during the use of the service product, as the use time increases, more cost consumption will be generated. In order to reduce the cost consumption of the user side in the process of using the service product, The risk of economic loss brought by the service provider. In this embodiment, after the service goods corresponding to the order request are provided to the user side, the user side use will also be obtained according to the preset second cycle (one hour, half hour or one day, etc.) Service product usage information, and generate billing data based on the usage information, and then identify whether there is a risk of insufficient deposit on the user side based on the generated billing data.
In one implementation, the process of identifying whether there is a risk of insufficient deposits on the user side is: using the newly generated billing data and other behavioral characteristic data on the user side as new user information, and then using steps S201-S202 to determine The current purchase authority determines whether there is a risk of insufficient deposits by judging whether the service goods currently used by the user comply with the newly calculated current purchase authority.
In another implementation, the process of identifying whether there is a risk of insufficient deposit on the user side is: comparing the newly generated billing data with the deferred payment amount in the current purchase authority previously determined by the user side to identify whether there is Risk of insufficient deposits. It may be that the amount of the newly generated billing data is greater than or equal to the deferred payment amount, it is considered that there is a risk of insufficient deposit, or the difference between the amount of the newly generated billing information and the deferred payment amount is less than the preset difference, it is considered to exist Risk of insufficient deposits.
Further, after recognizing that there is a risk of insufficient deposits on the user side, it may be set to deduct the expenses that have been consumed by the user side but have not been deducted from the corresponding account on the user side to reduce the risk of bad debts. If the deduction is unsuccessful, the user side is prohibited from continuing to use the service goods to reduce losses. It is also possible to send review information to the user side where the deduction is unsuccessful to remind the user side to upload review data to apply for continued use of the product.
It can be seen that through the risk identification method provided by the embodiment of the present invention, the user's credit level is determined according to the user information on the user side to confirm his current purchase authority, and the purchase authority that matches his own behavior characteristics is customized for different user sides, so that According to the current purchase authority, it can more accurately identify whether there is a risk in the order request on the user side, that is, the economic loss of the service provider is reduced, and frequent interruptions to customers with high credit ratings caused by inappropriate purchase authority settings are avoided.
Take a specific application scenario description, for example, in the scenario of purchasing cloud service products, after the user side sends an order request to the server, the server's online credit model uses the user side user information as input to score the user side. And according to the score to confirm whether there is a risk of insufficient deposit (Non Fufficient Fund, NSF), if there is, then intercept the order, if not, the user orders successfully. After the user places an order successfully, a bill on the user's side is generated every hour, and the online credit model is used for scoring based on the bill, and whether there is NSF risk is confirmed according to the scoring result. If there is no risk, it will not be processed, if there is risk, it will trigger the deduction. If the deduction is successful, it will not be processed. If the deduction is unsuccessful, an enhanced review of the account holder will be taken to understand the legality of the source of funds (Know Your Customer, KYC) or the use of commodities is prohibited.
In a second aspect, based on the same inventive concept, an embodiment of the present specification provides a risk identification device. Referring to FIG. 3, the risk identification device includes:
The level determining unit 301 is used to obtain user information characterizing the behavior characteristics of the user side, and determine the credit level of the user side based on the user information;
The authority determining unit 302 is configured to determine the current purchasing authority of the user side according to the correspondence between the credit rating and the pre-stored credit rating and the purchasing authority;
The identification unit 303 is configured to identify whether there is a risk in the order request sent by the user side according to the current purchase authority.
In an optional manner, the user information includes any one or more combinations of registration information, historical payment information, or device status information on the user side.
In an optional manner, the rating determination unit 301 is further configured to: use the user information as input data of a preset model, and calculate and determine the credit rating of the user side through the preset model.
In an optional manner, the level determining unit 301 is further configured to: use the user information as input data of a preset model, calculate and output the credit score of the user side through the preset model; The correspondence relationship between the credit score and the pre-stored credit score and the credit rating determines the credit rating on the user side.
In an optional manner, the authority determination unit 302 is further configured to: determine any one or more combinations of the types of products, the number of products, or the amount of deferred payment that the user side is allowed to purchase.
In an optional manner, the device further includes:
The processing unit 304 is configured to provide service products corresponding to the order request to the user side if the order request is not at risk; and intercept the order request if the order request is at risk.
In an optional manner, the processing unit 304 is further configured to: obtain usage information of the user-side using the service goods according to a preset second cycle, and generate billing data according to the usage information; The billing material identifies whether there is a risk of insufficient deposit on the user side.
In an optional manner, the processing unit 304 is further configured to: if the order request has a risk of insufficient deposit, deduct the expenses that have been consumed by the user side but not yet deducted from the account corresponding to the user side .
In an optional manner, the processing unit 304 is further configured to: if the deduction is unsuccessful, prohibit the user side from using the service goods.
In an optional manner, the level determining unit 301 is further configured to: when receiving the order request sent by the user side, respond to the order request, thereby obtaining user information characterizing the behavior characteristics of the user side.
In an optional manner, the level determining unit 301 is further configured to: according to a preset first cycle, acquire user information characterizing the behavior characteristics of the user side.
In an optional manner, the authority determining unit 302 is further configured to: receive the order request sent by the user side; respond to the order request, and identify the user side sent according to the current purchase authority Is there any risk in the order request?
In the third aspect, based on the same inventive concept as the risk identification method in the foregoing embodiment, the present invention also provides a server, as shown in FIG. 4, which includes a memory 404, a processor 402, and is stored on the memory 404 and can be A computer program running on the processor 402, when the processor 402 executes the program, the steps of any method of the risk identification method described above are implemented.
Among them, in FIG. 4, the busbar architecture (represented by the busbar 400 ), the busbar 400 may include any number of interconnected busbars and bridges, and the busbar 400 will include one or more processes represented by the processor 402 The various circuits of the memory represented by the memory and the memory 404 are connected together. The bus bar 400 can also connect various other circuits such as peripheral devices, voltage regulators, and power management circuits, etc., which are well known in the art, and therefore, they will not be further described herein. The bus interface 406 provides an interface between the bus 400 and the receiver 401 and the transmitter 403. The receiver 401 and the transmitter 403 may be the same element, that is, a transceiver, providing a unit for communicating with various other devices on a transmission medium. The processor 402 is responsible for managing the bus 400 and general processing, and the memory 404 can be used to store data used by the processor 402 in performing operations.
According to a fourth aspect, based on the inventive concept of the risk identification method in the foregoing embodiment, the present invention also provides a computer-readable storage medium on which a computer program is stored, which when executed by a processor implements the risk identification method described above The steps of any method.
This specification is described with reference to the flowcharts and/or block diagrams of the method, device (system), and computer program product according to the embodiments of this specification. It should be understood that each flow and/or block in the flowchart and/or block diagram and a combination of the flow and/or block in the flowchart and/or block diagram may be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device to produce a machine that allows instructions executed by the processor of the computer or other programmable data processing device A device for generating the functions specified in one block or multiple blocks of the flowchart one flow or multiple flows and/or block diagrams.
These computer program instructions can also be stored in a computer readable memory that can guide a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce a manufactured product including the instruction device The instruction device implements the functions specified in one block or multiple blocks in one flow or multiple flows in the flowchart and/or one block in the block diagram.
These computer program instructions can also be loaded onto a computer or other programmable data processing device, so that a series of operating steps can be performed on the computer or other programmable device to generate computer-implemented processing, and thus on the computer or other programmable device The instructions executed above provide steps for implementing the functions specified in one flow or flow of the flowchart and/or one block or flow of the block diagram.
Although the preferred embodiments of the present specification have been described, those skilled in the art can make additional changes and modifications to these embodiments once they learn the basic inventive concept. Therefore, the scope of the attached patent application is intended to be interpreted as including the preferred embodiments and all changes and modifications falling within the scope of this specification.
Obviously, those skilled in the art can make various modifications and variations to this description without departing from the spirit and scope of this description. In this way, if these modifications and variations of this specification fall within the scope of the patent application of this specification and the scope of its equivalent technology, this specification is also intended to include these modifications and variations.
