本申請涉及信息技術領域，尤其涉及一種風險信息輸出、風險信息構建方法及裝置。

背景技術：

隨著信息技術的迅速發展，很多業務都可以在網上進行，給人們的生活帶來了很多便利，同時，在網絡上進行的業務也是存在風險的。比如，某些業務可能是非法業務，或者，某些業務雖然是合法業務，但是由非法用戶冒充合法用戶進行的，等等。針對這類情況，網上的業務平臺一般會基于預定的風險控制規則和/或風險控制模型，對在該業務平臺上進行的業務進行風險控制，得出風險控制決策結果，并輸出給該業務的所屬方，并根據風險控制決策結果對該業務進行后續處理，其中，風險控制決策結果可以是：拒絕該業務或通過該業務等。

在現有技術中，在輸出風險控制決策結果時，還可以輸出相應的風險信息給業務的所屬方，該風險信息用于解釋導致該風險控制決策結果的原因，目前，各業務平臺一般都是預先對使用的風險控制規則進行簡單的翻譯，然后作為風險信息輸出給業務的所屬方。

但是，在實際應用中，業務的不同所屬方的行業經驗、風險控制能力參差不齊，相應地，業務的不同所屬方對風險信息的需求程度或深度也可能不同，而上述現有技術中輸出風險信息時并未考慮到這種差異，因此，上述現有技術中輸出的風險信息對于業務的不同所屬方的適用性較差。

技術實現要素：

本申請實施例提供一種風險信息輸出、風險信息構建方法及裝置，用以解決現有技術中輸出的風險信息對于業務的不同所屬方的適用性較差的問題。

本申請實施例提供的一種風險信息輸出方法，包括：

根據預定的、包含一個或多個風險因子的風險控制規則和/或風險控制模型，在各所述風險因子中，確定與業務的風險控制決策結果對應的風險因子，所述風險控制決策結果是根據所述風險控制規則和/或風險控制模型，以及涉及所述對應的風險因子的所述業務數據確定的；

確定與所述對應的風險因子對應的風險信息集合，所述對應的風險信息集合包含細化程度不同的多級風險信息，所述風險信息用于解釋導致所述風險控制決策結果的原因；

根據所述業務的所屬方的風險信息需求等級，在所述多級風險信息中，確定細化程度與所述業務的所屬方的風險信息需求等級匹配的至少一級風險信息；

輸出所述確定的風險信息，以便于所述業務的所屬方獲得所述確定的風險信息。

本申請實施例提供的一種風險信息輸出裝置，包括：

風險因子確定模塊，用于根據預定的、包含一個或多個風險因子的風險控制規則和/或風險控制模型，在各所述風險因子中，確定與業務的風險控制決策結果對應的風險因子，所述風險控制決策結果是根據所述風險控制規則和/或風險控制模型，以及涉及所述對應的風險因子的所述業務數據確定的；

風險信息第一確定模塊，用于確定與所述對應的風險因子對應的風險信息集合，所述對應的風險信息集合包含細化程度不同的多級風險信息，所述風險信息用于解釋導致所述風險控制決策結果的原因；

風險信息第二確定模塊，用于根據所述業務的所屬方的風險信息需求等級，在所述多級風險信息中，確定細化程度與所述業務的所屬方的風險信息需求等級匹配的至少一級風險信息；

風險信息輸出模塊，用于輸出所述確定的風險信息，以便于所述業務的所屬方獲得所述確定的風險信息。

本申請實施例提供的一種風險信息構建方法，包括：

對預定的風險控制規則和/或風險控制模型進行拆解，獲得所述風險控制規則和/或風險控制模型包含的一個或多個風險因子；

分別為獲得的各所述風險因子構建一個對應的風險信息集合，所述對應的風險信息集合包含細化程度不同的多級風險信息，所述風險信息用于解釋導致業務的風險控制決策結果的原因，所述風險控制決策結果是根據所述風險控制規則和/或風險控制模型，以及涉及所述對應的風險因子的所述業務數據確定的；

以便于在所述風險控制決策結果輸出時，根據所述業務的所屬方的風險信息需求等級，在所述多級風險信息中，確定并向所述業務的所屬方輸出細化程度與所述業務的所屬方的風險信息需求等級匹配的至少一級風險信息。

本申請實施例提供的一種風險信息構建裝置，包括：

風險因子獲得模塊，用于對預定的風險控制規則和/或風險控制模型進行拆解，獲得所述風險控制規則和/或風險控制模型包含的一個或多個風險因子；

風險信息構建模塊，用于分別為獲得的各所述風險因子構建一個對應的風險信息集合，所述對應的風險信息集合包含細化程度不同的多級風險信息，所述風險信息用于解釋導致業務的風險控制決策結果的原因，所述風險控制決策結果是根據所述風險控制規則和/或風險控制模型，以及涉及所述對應的風險因子的所述業務數據確定的；

以便于在所述風險控制決策結果輸出時，根據所述業務的所屬方的風險信息需求等級，在所述多級風險信息中，確定并向所述業務的所屬方輸出細化程度與所述業務的所屬方的風險信息需求等級匹配的至少一級風險信息。

本申請實施例通過上述至少一種技術方案，可以針對每個風險因子，構建對應于該風險因子的、細化程度不同的多級風險信息，以適應業務的不同所屬 方對于風險信息需求的不同層級的需求程度和/或深度，并且可以用不同的風險信息需求等級，表征對于風險信息需求的不同層級的需求程度和/或深度，進而，在輸出風險信息時，可以根據業務的所屬方的風險信息需求等級，在多級風險信息中，確定并輸出細化程度與業務的所屬方的風險信息需求等級匹配的至少一級風險信息，以便于業務的所屬方獲得輸出的風險信息，因此，本申請的方案輸出的風險信息對于業務的不同所屬方的適用性較好，可以部分或全部地解決上述現有技術中的問題。

附圖說明

此處所說明的附圖用來提供對本申請的進一步理解，構成本申請的一部分，本申請的示意性實施例及其說明用于解釋本申請，并不構成對本申請的不當限定。在附圖中：

圖1為本申請實施例提供的風險信息輸出方法的過程；

圖2為本申請實施例提供的在一種針對支付業務的風險控制場景下，為各風險因子構建的風險信息集合示意圖的一部分；

圖3為本申請實施例提供的在一種針對支付業務的風險控制場景下，為各風險因子構建的風險信息集合示意圖的一部分；

圖4為本申請實施例提供的風險信息構建方法的過程；

圖5為本申請實施例提供的一種針對支付業務的風險控制場景下，用于輸出風險信息的infocode分級輸出模塊的結構示意圖；

圖6為本申請實施例提供的一種針對支付業務的風險控制場景下，infocode三層框架示例圖；

圖7為本申請實施例提供的對應于圖1的風險信息輸出裝置結構示意圖；

圖8為本申請實施例提供的對應于圖4的風險信息構建裝置結構示意圖。

具體實施方式

為使本申請的目的、技術方案和優點更加清楚，下面將結合本申請具體實施例及相應的附圖對本申請技術方案進行清楚、完整地描述。顯然，所描述的實施例僅是本申請一部分實施例，而不是全部的實施例?；诒旧暾堉械膶嵤├?，本領域普通技術人員在沒有做出創造性勞動前提下所獲得的所有其他實施例，都屬于本申請保護的范圍。

在背景技術中已經提到，風險信息可以用于解釋導致對應的風險控制決策結果的原因，業務的不同所屬方對風險信息的需求程度或深度也可能不同。

具體地，以業務的所屬方是業務對應的商戶為例。對于從業時間較長、經驗豐富的商戶，他們更希望看到風險控制決策結果背后的業務呈現出的各方面的風險信號，也即，更希望看到細化程度較高(比較具體的、深入的等)的風險信息，從而有助于提高自身風險控制水平、了解當前風險趨勢；而對于行業新商戶，他們更多投入在市場拓展，沒有專業的團隊接收和處理專業的風險信息輸出，鑒于這種情況，細化程度較低(比較宏觀的、淺顯的等)的風險信息由于容易理解，因此，反而更適用于這類商戶。

而現有技術中輸出風險信息時并未考慮諸如上述差異，從而導致輸出的風險信息對業務的不同所屬方的適用性可能較差。

針對上述現有技術中的問題，本申請的方案的核心思想是：構建細化程度不同的多級(多個層級)風險信息，以適應業務的不同所屬方對風險信息不同層級的需求程度和/或深度，從而提高輸出的風險信息對業務的不同所屬方的適用性，其中，對風險信息不同層級的需求程度和/或深度可以用不同的風險信息需求等級表征，多級風險信息可以是基于歷史風險控制經驗構建的。下面對本申請的方案進行詳細說明。

圖1為本申請實施例提供的風險信息輸出方法的過程，該過程的執行主體可以是服務器或終端，更具體地，執行主體可以是服務器或終端上用于輸出風險信息的功能模塊?？勺鳛樗龇掌鞯脑O備包括但不限于：個人計算機、大中型計算機、計算機集群等；可作為所述終端的設備包括但不限于：手機、平 板電腦、智能手表、車載移動臺、個人計算機等。執行主體并不構成對本申請的限定，為了便于描述，本申請實施例均以執行主體是服務器為例進行說明。

圖1中的過程可以包括以下步驟：

s101：根據預定的、包含一個或多個風險因子的風險控制規則和/或風險控制模型，在各所述風險因子中，確定與業務的風險控制決策結果對應的風險因子，所述風險控制決策結果是根據所述風險控制規則和/或風險控制模型，以及涉及所述對應的風險因子的所述業務數據確定的。

在本申請實施例中，所述業務可以指“一筆業務”，針對每筆業務都可以分別執行一次圖1中的過程。

在本申請實施例中，可以基于風險控制規則和/或風險控制模型，對業務進行風險控制，獲得風險控制決策結果，其中，風險控制規則一般是由風險控制模型執行的，風險控制模型本身也可以包含有風險控制規則。在實際應用中，可以將風險控制規則、風險控制模型作為一個整體看待，并可以將這個整體稱為：風險策略體系。

隨著網絡業務的日益復雜化，在對業務進行風險控制時，單一的風險行為刻畫已難以精準地防控風險，因此，目前的風險控制規則在某些簡單場景下雖然也可以是單一的行為特征，但在更多的場景下是多種行為特征的組合。對業務進行風險控制的過程，即是對該業務的各行為特征(可通過該業務的相關數據提取)與風險控制規則的各行為特征，分別對應匹配的過程，進而可以根據匹配結果進行決策，以確定風險控制決策結果。

進一步地，每種行為特征可以分別用一個風險因子進行概括。在這種情況下，風險控制規則可以包含有一個或多個風險因子，相應地，可以將風險控制規則拆解為一個或多個風險因子。類似地，風險控制模型也可以包含有一個或多個風險因子。

在本申請實施例中，涉及所述對應的風險因子的所述業務數據可以指：屬于該業務的、反映該風險因子對應的行為特征的數據。風險控制決策結果可以 對應于一個或多個風險因子，其中，若業務的風險控制決策結果是由屬于該業務的、反映某個或某幾個風險因子對應的行為特征導致的，則可以稱：該風險控制決策結果對應于所述某個或某幾個風險因子。

業務的風險決策結果具體可以包括：拒絕該業務、或通過該業務、或對該業務進行人工審核，等等。

s102：確定與所述對應的風險因子對應的風險信息集合，所述對應的風險信息集合包含細化程度不同的多級風險信息，所述風險信息用于解釋導致所述風險控制決策結果的原因。

由于不同的風險因子分別對應不同的行為特征，因此，對于對應于不同風險因子的風險決策結果，用于解釋導致風險決策結果的風險信息相應地也可以不同。

如上所述，可以據此預先建立風險因子與風險信息之間的對應關系。具體的，在本申請實施例中，可以預先分別為每個風險因子構建一個對應的風險信息集合。風險信息集合中可以包含細化程度不同的多級風險信息，該風險信息集合對應的風險因子也即：該風險信息集合包含的多級風險信息對應的風險因子。

需要說明的是，本申請中所述的風險信息集合中包含多級風險信息，具體含義可以是：該多級風險信息已經構建完畢，并存放與該風險信息集合中；或者，該多級風險信息雖然尚未構建完畢，但是，用于構建該多級風險信息的素材已經在風險信息集合中準備就緒，當要輸出該多級風險信息時，可以根據這些素材實時地構建出該多級風險信息，再輸出。

在本申請實施例中，多級風險信息具體可以是多個層級的風險信息，所述多個層級的風險信息可以是逐層進行細化的。例如，頂層的風險信息是宏觀的、籠統的，次層的風險信息是對頂層的風險信息進一步的細化(具體地解釋，和/或擴充部分新內容等)，以此類推，除了頂層的風險信息以外，以下每層的風險信息都可以是對上一層風險信息進一步的細化。

當然，所述多個層級的風險信息也可以不具有“逐層細化”的關聯關系。例如，可以是相對獨立地構建各個層級的風險信息的，在這種情況下，并不一定要基于上一層風險信息構建本層的風險信息。

在本申請實施例中，對多級風險信息層級的劃分可以是根據歷史風險控制經驗，和/或業務的所屬方的需求等進行的。不同業務可以有不同的劃分方式，本申請對多級風險信息層級的具體劃分方式并不做限定。

s103：根據所述業務的所屬方的風險信息需求等級，在所述多級風險信息中，確定細化程度與所述業務的所屬方的風險信息需求等級匹配的至少一級風險信息。

在本申請實施例中，業務的所屬方的風險信息需求等級可以用于表征：該業務的所屬方的風險信息需求程度和/或深度。

在實際應用中，業務的所屬方的風險信息需求等級可以由服務器根據歷史數據推定，也可以由該業務的所屬方指定等。前一種方式可以減少業務的所屬方的操作，便利性較高；后一種方式由于是直接采用的所屬方自身的意見，因此準確性較高。本申請對所述風險信息需求的等級具體數量和等級具體劃分方式并不做限定。

在本申請實施例中，業務的不同所屬方的風險信息需求等級可能不同，相應地，可以分別向所述不同所屬方輸出對應層級的風險信息，以分別適應不同所屬方的需求。

進一步地，對于多級風險信息，每個風險信息需求等級可以唯一匹配該多級風險信息中的其中一級風險信息，也可以同時匹配該多級風險信息中的其中兩級甚至更多級風險信息。

s104：輸出所述確定的風險信息，以便于所述業務的所屬方獲得所述確定的風險信息。

在本申請實施例中，可以將確定的風險信息直接輸出給業務的所屬方；也可以將該風險信息輸出給其他設備或功能模塊，再由其他設備或功能模塊將該 風險信息發送給業務的所屬方；還可以先保存該風險信息，被動地等待業務的所屬方查詢后，再輸出該風險信息；等等。

在本申請實施例中，風險控制決策結果、以及為該風險控制決策結果確定的風險信息可以由同一個設備輸出，也可以分別由不同設備輸出，本申請對此并不做限定。進一步地，本申請對該風險控制決策結果和該風險信息的輸出時刻與輸出先后順序也不做限定，一般地，可以在輸出該風險控制決策結果時，一并輸出該風險信息，如此可以便于業務的所屬方及時知曉導致該風險控制決策結果的原因。

通過上述方法，可以針對每個風險因子，構建對應于該風險因子的、細化程度不同的多級風險信息，以適應業務的不同所屬方對于風險信息需求的不同層級的需求程度和/或深度，并且可以用不同的風險信息需求等級，表征對于風險信息需求的不同層級的需求程度和/或深度，進而，在輸出風險信息時，可以根據業務的所屬方的風險信息需求等級，在多級風險信息中，確定并輸出細化程度與業務的所屬方的風險信息需求等級匹配的至少一級風險信息，以便于業務的所屬方獲得輸出的風險信息，因此，本申請的方案輸出的風險信息對于業務的不同所屬方的適用性較好，可以部分或全部地解決上述現有技術中的問題。

基于上述方法，本申請實施例還提供了上述方法的一些具體實施方案，以及擴展方案，下面進行說明。

在本申請實施例中，如前所述，風險控制規則和/或風險控制模型包含的每個風險因子可以分別與預定的一個風險信息集合建立有對應關系。在這種情況下，對于步驟s102，確定與所述對應的風險因子對應的風險信息集合，具體可以包括：根據所述對應關系，在預定的各所述風險信息集合中，確定與所述對應的風險因子對應的風險信息集合。

當然，也可以不預先構建風險信息集合，而是在要使用時再實時地構建。在這種情況下，對于步驟s102，確定與所述對應的風險因子對應的風險信息 集合，具體可以包括：根據所述對應的風險因子，構建與所述對應的風險因子對應的風險信息集合。

在本申請實施例中，在執行步驟s103的過程中，用到了業務的所屬方的風險信息需求等級信息，為了便于實施本申請的方案，下面提供兩種獲得該風險信息需求等級信息的方式，作為示例：

第一種方式，可以預先由業務的所屬方指定自己的風險信息需求等級，或者，由服務器指定業務的所屬方的風險信息需求等級；然后將指定的風險信息需求等級信息寫入預定配置文件中。則在執行步驟s103前，可以從該預定配置文件中讀取到該風險需求等級信息。第一種方式可以減少業務的所屬方的操作，便利性較高。

第二種方式，可以在要執行步驟s103時，再實時地由服務器推定業務的所屬方的風險信息需求等級。具體地，服務器可以根據獲取的所述業務的所屬方的風險控制水平信息和/或風險控制需求信息，推定所述業務的所屬方的風險信息需求等級。第二種方式由于參考了業務的所屬方的相關信息，因此，準確性較高。

需要說明的是，本申請對風險控制水平信息和/或風險控制需求信息的獲取方式并不做限定，可以是由服務器在與業務的所屬方的歷史交互過程中采集的，也可以是由服務器側的管理人員通過與業務的所屬方進行的溝通獲知，并輸入服務器的，等等。

在本申請實施例中，對于步驟s104，前面已經給出了若干實施方式。在實際應用中，比較常見的一種實施方式如下：

輸出所述確定的風險信息，具體可以包括：在所述風險控制決策結果輸出給所述業務的所屬方時，向所述業務的所屬方輸出所述確定的風險信息。這種實施方式的優點是：業務的所屬方可以在看到風險控制決策結果時，相對同步地看到對應的風險信息，業務的所屬方的體驗較好，便于根據該風險信息，有方向性地對業務進行后續處理，比如，去除風險后重新提交業務等。

“多級風險信息”、“風險信息需求等級”均是本申請的方案的重點之一，為了便于理解，在此分別對它們進一步地說明。

在本申請實施例中，所述業務的所屬方的風險信息需求等級是預定的多個風險信息需求等級之一，用于表征所述業務的所屬方的風險信息需求程度和/或深度。所述多個風險信息需求等級可以與所述多級風險信息一一對應并匹配，且表征風險信息需求程度和/或深度越高的風險信息需求等級，在所述多級風險信息中匹配的那一級風險信息的細化程度可以越高。

以所述業務是支付業務，該支付業務的所屬方是該支付業務對應的商戶為例。其中，所述支付業務可以主要基于第三方支付平臺進行，也可以主要基于銀行提供的支付平臺進行。

可以將支付業務場景下的所有商戶劃分為三類，風險信息需求程度和/或深度相對低的一類稱為：“弱管控商戶”；風險信息需求程度和/或深度相對適中的一類稱為：“一般管控商戶”；風險信息需求程度和/或深度相對高的一類稱為：“強管控商戶”。

相應地，多級風險信息具體可以是三個層級的風險信息，在輸出風險信息時，若業務的所屬方是弱管控商戶，則可以輸出細化程度最低的那個層級的風險信息，若該所屬方是一般管控商戶，則可以輸出細化程度適中的那個層級的風險信息，若該所屬方是強管控商戶，則可以輸出細化程度最高的那個層級的風險信息。

在本申請實施例中，多級風險信息可以是根據所述風險控制規則和/或風險控制模型，以及相關的歷史風險控制經驗數據構建，以及以易于所述業務的所屬方理解的描述方式進行描述的。

歷史風險控制經驗可以包括服務器在針對歷史業務的風險控制過程中總結出的經驗，以及業務的所屬方提供的現成可用的經驗等。例如，服務器可以根據業務的所屬方已提供的信息，推定該所屬方或與該所屬方相似的其他所屬方所需求的風險信息，以及什么樣的風險信息是易于該所屬方或與該所屬方相 似的其他所屬方理解的；業務的所屬方也可以主動告知服務器自己需要怎樣的風險信息，以及自己容易理解的風險信息描述方式等；這些數據都可以作為歷史風險控制經驗數據。

所述風險信息可以是程序代碼形式的信息，也可以是自然語言形式的信息。現有技術中對風險控制規則進行簡單翻譯就作為風險信息，而本申請的方案可以根據歷史風險控制經驗，以通俗易懂的語言描述風險信息，以易于業務的所屬方理解，因此，基于本申請的方案輸出的風險信息適用性更好。

本申請實施例提供了在一種針對支付業務的風險控制場景下，為各風險因子構建的風險信息集合示意圖，如圖2、圖3組合所示。其中，圖2和圖3分別為該風險信息集合示意圖的一部分，圖2中“盜卡風險”的各子節點是在圖3中示出的。

在該場景下，將風險信息稱為“風險信息提示編碼(infocode)”，將為各風險因子構建的風險信息集合合稱為“infocode體系”。需要說明的是，這兩個名稱僅是一種示例，并不構成對本申請的限定，在其他的場景，也可以用其他的名稱命名。

在圖2、圖3中是以一個樹形結構表示該infocode體系的，“風險信息提示編碼體系”節點是該樹形結構的根節點。在該樹形結構的第二層一共有4個分支，每一個分支下分別是一個infocode集合，這些infocode集合分別為：“盜卡風險”節點內容及其所有子節點內容構成的集合、“盜賬戶風險”節點內容及其所有子節點內容構成的集合、“可信體系”節點內容及其所有子節點內容構成的集合、“銀行系統拒絕”節點內容及其所有子節點內容構成的集合。

每個infocode集合分別對應于一個風險因子(風險因子省略未示出)，每個infocode集合包含多級infocode，從樹形結構的第二層開始往下，每一層分別是多級infocode中的其中一級infocode，越往下的infocode的細化程度越高。

以“盜卡風險”節點所屬的infocode集合為例，在圖3中可以看見，該infocode集合包含有三級infocode。第一級infocode包括“盜卡風險”節點內 容；第二級infocode包括“高風險賬戶”、“信息沖突”、“高風險環境”、“風險網絡”、“高危事件屬性”、“異常行為路徑”、“速率”這7個節點內容。

可以看到，第二級infocode是對第一級infocode的進一步細化；類似地，第三級infocode是對第二級infocode的進一步細化，比如，第二級infocode中的“高風險賬戶”節點內容被細化為第三級infocode中的“新賬戶”、“休眠賬戶”、“情報完成度”、“賬戶登錄時存在批量行為”這4個節點內容，第二級infocode中的“信息沖突”節點內容被細化為第三級infocode中的“交易信息存在沖突”、“信用卡驗證信息沖突”這2個節點內容，等等。

從圖2、圖3可以看出，細化程度越高的infocode可以越具體地解釋導致風險控制決策結果的原因。

需要說明的是，圖2、圖3中的節點內容可能并未完全示出，而且圖2、圖3僅是對多級infocode的示例而已，并不構成對本申請的限定。

上面對本申請實施例提供的風險信息輸出方法進行了詳細說明，基于同樣的思路，本申請實施例還提供了一種風險信息構建方法。

圖4為該風險信息構建方法的過程，該過程的執行主體可以與圖1中的過程的執行主體相同，在此不贅述。

圖4中的過程可以包括以下步驟：

s401：對預定的風險控制規則和/或風險控制模型進行拆解，獲得所述風險控制規則和/或風險控制模型包含的一個或多個風險因子。

s402：分別為獲得的各所述風險因子構建一個對應的風險信息集合，所述對應的風險信息集合包含細化程度不同的多級風險信息，所述風險信息用于解釋導致業務的風險控制決策結果的原因，所述風險控制決策結果是根據所述風險控制規則和/或風險控制模型，以及涉及所述對應的風險因子的所述業務數據確定的；

以便于在所述風險控制決策結果輸出時，根據所述業務的所屬方的風險信息需求等級，在所述多級風險信息中，確定并向所述業務的所屬方輸出細化程 度與所述業務的所屬方的風險信息需求等級匹配的至少一級風險信息。

通過圖4中的方法，輸出的風險信息對于業務的不同所屬方的適用性較好，可以部分或全部地解決上述現有技術中的問題。

基于同樣的思路，本申請實施例還提供一種針對支付業務的風險控制場景下，用于輸出風險信息的infocode分級輸出模塊的結構示意圖，如圖5所示。

圖5中的模塊主要可以分為三個部分：

第一部分，infocode框架，用于根據支付業務平臺的歷史風險控制經驗數據，構建infocode三層框架。多級風險信息即是基于該infocode三層框架構建的。

第二部分，infocode映射。這里的“映射”主要風險控制規則和/或風險控制模塊包含的各風險因子(即：風險因子1、風險因子2、…、風險因子x)與各風險信息集合(即：infocodea、infocodeb、…、infocodex)之間的對應關系映射。

其中，每個風險信息集合都包含有對應的多級風險信息，比如，infocodea包含了codea1、codea2、codea3這三級逐級細化的風險信息。

第三部分，infocode輸出。用于將多級風險信息分級輸出給風險信息需求等級匹配的業務的所屬方。

其中，風險信息需求等級一共有三個級別，即為：弱管控商戶的級別、一般管控商戶的級別、強管控商戶的級別。其中，弱管控商戶可以是無風險控制能力或不關注風險控制的小商戶或新商戶，一般管控商戶可以是有一定風險控制能力，但無專業風險控制團隊的中小型商戶，強管控商戶可以是有較強風險控制能力、已組建專業風險控制團隊的大中型商戶。

在實際應用中，服務器可以實時地分析每筆支付業務，在結合風險控制規則和風險控制模型給出“拒絕該業務”或“通過該業務”等風險控制決策結果時，也可以將對應級別的infocode輸出給該業務的所屬方。

進一步地，本申請實施例還提供了一種針對支付業務的風險控制場景下， infocode三層框架示例圖，如圖6所示。

在圖6中，采用的風險控制規則稱為“新賬戶沖突換多卡”，其可以拆解為“新賬戶”、“沖突”、“換多卡”這3個風險因子。

每個風險因子分別對應于一個infocode集合，風險因子可以從更為細化的維度進行刻畫，進而可以構建出三級infocode，三級infocode即構成一個infocode集合。例如，“沖突”存在盜卡和盜賬戶風險(可作為第一級infocode)，進一步地，盜卡風險可以分為卡bin沖突、設備沖突等類型(可作為第二級infocode)，更進一步地，卡bin沖突可以分為發卡國與ip國沖突、發卡國與收貨國沖突等(可作為第三級infocode)。

基于圖5、圖6中的方案，可以有效增強支付業務平臺與商戶的良性互動，提升支付風險控制體驗。

需要說明的是，在以上各例中均是以“一共有三級的多級風險信息”作為“多級風險信息”的示例的，在實際應用中，多級風險信息也可以共有兩級，或者共有三級以上，等等。另外，本申請的方案可以針對全部風險因子實施，也可以只針對部分風險因子實施。

以上為本申請實施例提供的風險信息輸出方法、風險信息構建方法，基于同樣的思路，本申請實施例還提供相應的風險信息輸出裝置、風險信息構建裝置，如圖7、圖8所示。

圖7為本申請實施例提供的對應于圖1的風險信息輸出裝置結構示意圖，具體包括：

風險因子確定模塊701，用于根據預定的、包含一個或多個風險因子的風險控制規則和/或風險控制模型，在各所述風險因子中，確定與業務的風險控制決策結果對應的風險因子，所述風險控制決策結果是根據所述風險控制規則和/或風險控制模型，以及涉及所述對應的風險因子的所述業務數據確定的；

風險信息第一確定模塊702，用于確定與所述對應的風險因子對應的風險信息集合，所述對應的風險信息集合包含細化程度不同的多級風險信息，所述 風險信息用于解釋導致所述風險控制決策結果的原因；

風險信息第二確定模塊703，用于根據所述業務的所屬方的風險信息需求等級，在所述多級風險信息中，確定細化程度與所述業務的所屬方的風險信息需求等級匹配的至少一級風險信息；

風險信息輸出模塊704，用于輸出所述確定的風險信息，以便于所述業務的所屬方獲得所述確定的風險信息。

可選地，所述風險控制規則和/或風險控制模型包含的每個風險因子分別與預定的一個風險信息集合建立有對應關系；

風險信息第一確定模塊702具體用于：根據所述對應關系，在預定的各所述風險信息集合中，確定與所述對應的風險因子對應的風險信息集合。

可選地，所述裝置還包括：

風險信息需求等級確定模塊705，用于在風險信息第二確定模塊703確定細化程度與所述業務的所屬方的風險信息需求等級匹配的至少一級風險信息前，確定預定配置文件中指定的所述業務的所屬方的風險信息需求等級；或者，根據獲取的所述業務的所屬方的風險控制水平信息和/或風險控制需求信息，推定所述業務的所屬方的風險信息需求等級。

可選地，風險信息輸出模塊704具體用于：在所述風險控制決策結果輸出給所述業務的所屬方時，向所述業務的所屬方輸出所述確定的風險信息。

可選地，所述業務的所屬方的風險信息需求等級是預定的多個風險信息需求等級之一，用于表征所述業務的所屬方的風險信息需求程度和/或深度；

所述多個風險信息需求等級與所述多級風險信息一一對應并匹配，且表征風險信息需求程度和/或深度越高的風險信息需求等級，在所述多級風險信息中匹配的那一級風險信息的細化程度越高。

可選地，所述多級風險信息是根據所述風險控制規則和/或風險控制模型，以及相關的歷史風險控制經驗數據構建，以及以易于所述業務的所屬方理解的描述方式進行描述的。

可選地，所述業務的風險控制決策結果包括：拒絕所述業務、或通過所述業務、或需對所述業務進行人工審核。

可選地，所述業務包括支付業務，所述業務的所屬方包括所述支付業務對應的商戶。

圖7中的裝置具體可以位于服務器或終端上。

圖8為本申請實施例提供的對應于圖4的風險信息構建裝置結構示意圖，具體包括：

風險因子獲得模塊801，用于對預定的風險控制規則和/或風險控制模型進行拆解，獲得所述風險控制規則和/或風險控制模型包含的一個或多個風險因子；

風險信息構建模塊802，用于分別為獲得的各所述風險因子構建一個對應的風險信息集合，所述對應的風險信息集合包含細化程度不同的多級風險信息，所述風險信息用于解釋導致業務的風險控制決策結果的原因，所述風險控制決策結果是根據所述風險控制規則和/或風險控制模型，以及涉及所述對應的風險因子的所述業務數據確定的；

以便于在所述風險控制決策結果輸出時，根據所述業務的所屬方的風險信息需求等級，在所述多級風險信息中，確定并向所述業務的所屬方輸出細化程度與所述業務的所屬方的風險信息需求等級匹配的至少一級風險信息。

圖8中的裝置具體可以位于服務器或終端上。

需要說明的是，本申請提供的裝置是與本申請提供的方法一一對應的，因此，所述裝置也具有與所述方法類似的有益技術效果，由于上面已經對所述方法的有益技術效果進行了詳細說明，因此，這里不再贅述所述裝置的有益技術效果。

本領域內的技術人員應明白，本發明的實施例可提供為方法、系統、或計算機程序產品。因此，本發明可采用完全硬件實施例、完全軟件實施例、或結合軟件和硬件方面的實施例的形式。而且，本發明可采用在一個或多個其中包 含有計算機可用程序代碼的計算機可用存儲介質(包括但不限于磁盤存儲器、cd-rom、光學存儲器等)上實施的計算機程序產品的形式。

本發明是參照根據本發明實施例的方法、設備(系統)、和計算機程序產品的流程圖和/或方框圖來描述的。應理解可由計算機程序指令實現流程圖和/或方框圖中的每一流程和/或方框、以及流程圖和/或方框圖中的流程和/或方框的結合。可提供這些計算機程序指令到通用計算機、專用計算機、嵌入式處理機或其他可編程數據處理設備的處理器以產生一個機器，使得通過計算機或其他可編程數據處理設備的處理器執行的指令產生用于實現在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能的裝置。

這些計算機程序指令也可存儲在能引導計算機或其他可編程數據處理設備以特定方式工作的計算機可讀存儲器中，使得存儲在該計算機可讀存儲器中的指令產生包括指令裝置的制造品，該指令裝置實現在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能。

這些計算機程序指令也可裝載到計算機或其他可編程數據處理設備上，使得在計算機或其他可編程設備上執行一系列操作步驟以產生計算機實現的處理，從而在計算機或其他可編程設備上執行的指令提供用于實現在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能的步驟。

在一個典型的配置中，計算設備包括一個或多個處理器(cpu)、輸入/輸出接口、網絡接口和內存。

內存可能包括計算機可讀介質中的非永久性存儲器，隨機存取存儲器(ram)和/或非易失性內存等形式，如只讀存儲器(rom)或閃存(flashram)。內存是計算機可讀介質的示例。

計算機可讀介質包括永久性和非永久性、可移動和非可移動媒體可以由任何方法或技術來實現信息存儲。信息可以是計算機可讀指令、數據結構、程序的模塊或其他數據。計算機的存儲介質的例子包括，但不限于相變內存(pram)、靜態隨機存取存儲器(sram)、動態隨機存取存儲器(dram)、其 他類型的隨機存取存儲器(ram)、只讀存儲器(rom)、電可擦除可編程只讀存儲器(eeprom)、快閃記憶體或其他內存技術、只讀光盤只讀存儲器(cd-rom)、數字多功能光盤(dvd)或其他光學存儲、磁盒式磁帶，磁帶磁磁盤存儲或其他磁性存儲設備或任何其他非傳輸介質，可用于存儲可以被計算設備訪問的信息。按照本文中的界定，計算機可讀介質不包括暫存電腦可讀媒體(transitorymedia)，如調制的數據信號和載波。

還需要說明的是，術語“包括”、“包含”或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、商品或者設備不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種過程、方法、商品或者設備所固有的要素。在沒有更多限制的情況下，由語句“包括一個……”限定的要素，并不排除在包括所述要素的過程、方法、商品或者設備中還存在另外的相同要素。

以上所述僅為本申請的實施例而已，并不用于限制本申請。對于本領域技術人員來說，本申請可以有各種更改和變化。凡在本申請的精神和原理之內所作的任何修改、等同替換、改進等，均應包含在本申請的權利要求范圍之內。