為了使本領域技術人員更好地理解本說明書實施例中的技術方案，下面將結合本說明書實施例中的圖式，對本說明書實施例中的技術方案進行詳細地描述，顯然，所描述的實施例僅僅是本說明書的一部分實施例，而不是全部的實施例。基於本說明書中的實施例，本領域普通技術人員所獲得的所有其他實施例，都應當屬保護的範圍。
針對現有技術的問題，本說明書實施例提供一種保險交易處理方法，參見圖1所示，該方法可以包括以下步驟：
S101，根據目標保險交易的險種，確定與所述險種對應的保單產生策略，所述保單產生策略包括：所述險種產生保單時採用的保單維度；
用戶購買保險時，將首先需要與保險機構達成交易，然後簽訂保險合同，形成對應的保單，在保險場景中，同一用戶(投保人)可以與同一保險機構達成多筆交易。
以材質險為例，材質險是由賣家付費投保，買家享受獲賠權益的保險，賣家一旦選擇加入該險種，即為店鋪內每一筆承保範圍內的商品訂單投保，例如，賣家為店鋪內的若干種商品投保了材質險，則每產生一筆相關商品的訂單，賣家便與保險機構達成1筆材質險交易。
傳統的保險管理方案中，針對每筆保險交易創建1個保單，且每個保單具有獨立的投保、繳費、理賠流程。但是，網際網路保險一般具有碎片化、保費額度低、交易頻次高等區別於傳統保險的特點。
仍以材質險為例，賣家每日可能會產生幾十筆甚至上百筆商品訂單，對應的將與保險公司達成上百筆材質險交易，按照傳統的保險管理方案，將創建上百個保單，並單獨進行投保、繳費、理賠等流程，導致管理效率低。
本說明書實施例提供的方案中，針對不同的險種設置不同的保單維度，在達成1筆保險交易時，根據該保險交易的險種，從對應的保單維度產生保單，從而根據若干筆保險交易產生1個保單，提高保單的管理效率。
例如，保單維度可以是用戶維度。可以理解的是，用戶可以指自然人，也可以指企業、機構等，此外，可以指投保人，也可以指被保險人、受益人等，本說明書不做限定。以訂單險為例，該險種的保單維度可以是賣家維度，即同一賣家的各筆訂單險交易，均對應產生1個訂單險保單，從而根據1個保單統一地管理該賣家的多筆訂單險交易的繳費、理賠等流程。
又例如，保單維度可以是時間維度。以運費險為例，某電商平臺為在該平臺購物的買家均投保運費險，即每產生1筆購物訂單，便達成1筆運費險交易，而平臺每日可能產生上萬筆購物訂單，因此可以以時間維度，每日達成的運費險交易對應產生1個保單，從而根據1個保單統一地管理各買家的多筆運費險交易的繳費、理賠等流程。
再例如，保單維度還可以是參保項目維度，如某平臺聯合保險機構發起的互助保險項目，可以有多人、分多日參與，即每產生1個參加該項目的用戶，即達成1筆互助險交易，因此可以以項目維度，1個互助保險項目中的若干筆互助險交易對應產生1個保單，從而根據1個保單統一地管理各用戶的多筆互助險交易的繳費、理賠等流程。
S102，根據所述保單產生策略，檢查所述保單維度下是否已存在所述險種的保單；
如上面所述，同一維度下的若干筆保險交易，將對應產生1個保單，因此，首先需要檢查該維度下是否已產生保單。
仍以訂單險為例，當某賣家產生1筆買賣訂單時，即對應達成1筆訂單險交易，並確定訂單險的保單產生策略中，保單維度是賣家維度，則可以檢查該賣家是否已存在訂單險保單。
S103，在不存在保單的情況下，在所述保單維度下產生所述險種的保單，並根據所述目標保險交易的交易資訊產生所述保單的管理規則；
所述管理規則用於對保單對應的各保險交易進行管理，在本說明書的一種具體實施方式中，所述保單產生策略中還可以包括：所述險種所產生保單對應的各保險交易的管理維度。
在一個例子中，在所述保單維度下產生所述險種的保單，並根據所述目標保險交易的交易資訊產生所述保單的管理規則時，可以首先在所述保單維度下產生所述險種的保單，並根據所述保單產生策略，確定所述目標保險交易的管理維度。然後根據所確定的管理維度，創建所產生保單對應的管理組，該管理組中包括所述目標保險交易，根據所述目標保險交易的交易資訊，產生所述管理組的管理組規則，所產生保單的管理規則中包括所述管理組規則。
本說明書實施例中不限定管理維度的具體內容，本領域技術人員可以根據實際需求，靈活地設置保單維度與管理維度。
仍以訂單險為例，訂單險的保單維度可以設置為用戶維度，管理維度可以設置為時間維度，具體地，可以將每日的各筆訂單險交易歸入同一個管理組，而該賣家的各管理組下的各訂單險交易，對應產生1個保單。
保單的管理規則中包括各管理組的管理規則，同一個管理組中的各筆訂單險交易，透過該組的管理組規則管理，如繳費的時間、日期等。此外，管理規則中還可以包括其他規則，用於進一步管理各訂單險交易，如管理該賣家的訂單險保單的保期是否到期、是否續期等。
S104，在已存在保單的情況下，根據所述目標保險交易的交易資訊更新所述保單的管理規則，以透過所述保單對所述目標保險交易進行管理；
本說明書的一種具體實施方式中，在根據所述目標保險交易的交易資訊更新所述保單的管理規則，以透過所述保單對所述目標保險交易進行管理時，可以首先根據所述保單產生策略，確定所述目標保險交易的管理維度，並檢查所述保單在所確定的管理維度下，是否存在對應的管理組。
在存在管理組的情況下，將所述目標保險交易加入該管理組，並根據所述目標保險交易的交易資訊更新該管理組的管理組規則；
例如，管理組規則中可以包括該管理組下的各筆保險交易的繳費金額、繳費日期等，更新管理組規則時，可以將目標保險交易的交易標識、繳費金額等資訊，添加到管理組規則中，以便在需要繳費時產生繳費提醒、或自動為該筆保險交易繳費等。
在不存在管理組的情況下，在所述管理維度下創建所述保單對應的管理組，並根據所述目標保險交易的交易資訊，產生該管理組的管理組規則。
本說明書的另一種具體實施方式中，管理規則中可以包括以下幾種子規則中的一種或多種：繳費子規則，所述繳費子規則用於：確定所管理的保險交易的繳費時間與繳費金額；保期子規則，所述保期子規則用於：確定所管理的保險交易的是否到期、及/或是否續期；公示子規則，所述公示子規則用於：向公示所管理的保險交易的管理資訊，所述管理資訊包括：繳費資訊、理賠資訊保期資訊、及/或用戶信用資訊。
可以理解的是，如果管理規則中還包括管理組規則，則管理組規則中也可以分別包括上述的一種或多種子規則。
例如，險種A的保單產生策略中不包括管理維度，即該保單下的各筆保險交易不需要分管理組，且該保單的管理規則中可以包括繳費子規則、保期子規則、公示子規則中的一種或多種。
而險種B的保單產生策略中包括管理維度，即該保單下的各筆保險交易根據管理維度分為若干管理組，分別根據管理組的管理組規則進行管理，則各管理組規則中也可以包括繳費子規則、保期子規則、公示子規則中的一種或多種；或者管理規則中可以直接包括繳費子規則、保期子規則、公示子規則中的一種或多種；當然，也可以管理規則中包括公示子規則，而管理組規則中包括繳費子規則與保期子規則；等等，本說明書實施例對此不做限定。
下面結合幾個更為具體的實例，對本說明書提供的保險交易處理方法進行說明。
(1)假設目標保險交易A的險種為訂單險，確定與訂單險對應的保單產生策略中，產生保單時採用的保單維度為賣家維度。此外，保單產生策略中，所產生保單對應的各保險交易的管理維度為日期維度。
並且，管理組規則中包括繳費子規則，具體規則為投保後的N日內繳納保費，管理規則中包括各管理組規則、以及保期子規則，保期子規則的具體規則為賣家的保單期限為1年。
由此，達成1筆訂單險交易後，首先檢查該賣家是否已存在訂單險的保單，在不存在保單的情況下，產生該賣家的訂單險保單，並產生當日(T日)的管理組，根據這筆訂單險交易的交易時間T日及需繳納的保費X1
元，產生該管理組的繳費子規則，具體為T+N日繳納X1
元保費。
如果當日又達成1筆訂單險交易，則檢查賣家維度下是否已存在訂單險的保單的結果將為存在保單，且經檢查存在對應的管理組，則將該筆訂單險交易加入該管理組，並根據這筆訂單險交易的交易時間T日及需繳納的保費X2
元，更新該管理組的管理組規則中的繳費子規則，更新後為T+N日繳納X1
+X2
元保費。
可見，如圖2所示，可以將同日達成的訂單險交易，加入同一管理組，根據訂單險交易總量對繳費日期、金額等進行統一管理，並且為同一賣家的訂單險交易產生1個保單，從而對保期等進行統一管理，在未影響原有保障內容的情況下，提高保期短、保險交易量大的訂單險的管理效率。
(2)投資人在融資平臺投入資金後，借款人可以透過平臺借用投資人的資金，並在預定借款期滿後償還本金與一定利息，為了保障投資人在期滿後可以足額收回預先承諾的本金與利息，可以為投資人的每筆被借款投保投資險。
假設目標保險交易B的險種為投資險，確定與訂單險對應的保單產生策略中，產生保單時採用的保單維度為投資人維度。並且，管理規則中包括繳費子規則以及保期子規則，具體地，繳費子規則根據投保的每筆被借款，規定了繳費的日期、及被借款相應比例的保費金額，保期子規則的根據投保的每筆被借款的還款日，規定了相應的保期，並且根據投資人的設定，規定了在該筆資金再次被借時是否自動續保。
由此，發生1筆借款並達成1筆投資險交易後，首先檢查該投資人下是否已存在投資險的保單，在不存在保單的情況下，產生該投資人的投資險保單，並產生該保單管理規則中的繳費子規則及保期子規則。
當該筆借款按照預定的本息被歸還後，投資險也將終止保障，而當該投資人的資金再次借出時，又將達成1筆投資險交易，經檢查投資人維度下是否已存在訂單險的保單的結果將為存在保單，則直接根據本次達成的投資險交易中，對應借款的金額及還款日期，更新繳費子規則與保期子規則。
可見，同一投資人的各筆投資險交易，可以統一地由該投資人的1個保單管理，在借款情況發生變更時，僅需要根據借款的金額、還款日等交易資訊，更新保單的管理規則，從而在未影響原有保障內容的情況下，提高保期與保費靈活的投資險的管理效率。
相應於上述方法實施例，本說明書實施例還提供一種保險交易處理裝置，參見圖3所示，該裝置可以包括：
策略確定模組110，用於根據目標保險交易的險種，確定與所述險種對應的保單產生策略，所述保單產生策略包括：所述險種產生保單時採用的保單維度；
保單檢查模組120，用於根據所述保單產生策略，檢查所述保單維度下是否已存在所述險種的保單；
保單產生模組130，用於在不存在保單的情況下，在所述保單維度下產生所述險種的保單，並根據所述目標保險交易的交易資訊產生所述保單的管理規則；
規則更新模組140，用於在已存在保單的情況下，根據所述目標保險交易的交易資訊更新所述保單的管理規則，以透過所述保單對所述目標保險交易進行管理；
其中，所述管理規則用於對保單對應的各保險交易進行管理。
在本說明書提供的一種具體實施方式中，所述保單產生策略，還可以包括：
所述險種所產生保單對應的各保險交易的管理維度。
在本說明書提供的一種具體實施方式中，參見圖4所示，所述保單產生模組130，可以包括：
保單產生單元131，用於在所述保單維度下產生所述險種的保單；
維度確定單元132，用於根據所述保單產生策略，確定所述目標保險交易的管理維度；
管理組創建單元133，用於根據所確定的管理維度，創建所產生保單對應的管理組，該管理組中包括所述目標保險交易；
規則產生單元134，用於根據所述目標保險交易的交易資訊，產生所述管理組的管理組規則，所產生保單的管理規則中包括所述管理組規則。
在本說明書提供的一種具體實施方式中，參見圖5所示，所述規則更新模組140，包括：
維度確定單元141，用於根據所述保單產生策略，確定所述目標保險交易的管理維度；
管理組檢查單元142，用於檢查所述保單在所確定的管理維度下，是否存在對應的管理組；
規則更新單元143，用於在存在管理組的情況下，將所述目標保險交易加入該管理組，並根據所述目標保險交易的交易資訊更新該管理組的管理組規則；
規則產生單元144，用於在不存在管理組的情況下，在所述管理維度下創建所述保單對應的管理組，並根據所述目標保險交易的交易資訊，產生該管理組的管理組規則；
其中，所述保單的管理規則中包括所述管理組規則。
在本說明書提供的一種具體實施方式中，所述管理規則，可以包括：
繳費子規則，所述繳費子規則用於：確定所管理的保險交易的繳費時間與繳費金額；及/或，
保期子規則，所述保期子規則用於：確定所管理的保險交易的是否到期、及/或是否續期；及/或，
公示子規則，所述公示子規則用於：向公示所管理的保險交易的管理資訊，所述管理資訊包括：繳費資訊、理賠資訊保期資訊、及/或用戶信用資訊。
上述裝置中各個模組的功能和作用的實現過程具體詳見上述方法中對應步驟的實現過程，在此不再贅述。
本說明書實施例還提供一種電腦設備，其至少包括儲存器、處理器及儲存在儲存器上並可在處理器上運行的電腦程式，其中，處理器執行所述程式時實現前述的保險交易處理方法。該方法至少包括：
一種保險交易處理方法，該方法包括：
根據目標保險交易的險種，確定與所述險種對應的保單產生策略，所述保單產生策略包括：所述險種產生保單時採用的保單維度；
根據所述保單產生策略，檢查所述保單維度下是否已存在所述險種的保單；
在不存在保單的情況下，在所述保單維度下產生所述險種的保單，並根據所述目標保險交易的交易資訊產生所述保單的管理規則；
在已存在保單的情況下，根據所述目標保險交易的交易資訊更新所述保單的管理規則，以透過所述保單對所述目標保險交易進行管理；
其中，所述管理規則用於對保單對應的各保險交易進行管理。
圖6示出了本說明書實施例所提供的一種更為具體的計算設備硬體結構示意圖，該設備可以包括：處理器1010、儲存器1020、輸入/輸出介面1030、通訊介面1040和匯流排1050。其中處理器1010、儲存器1020、輸入/輸出介面1030和通訊介面1040透過匯流排1050實現彼此之間在設備內部的通訊連接。
處理器1010可以採用通用的CPU(Central Processing Unit，中央處理器)、微處理器、應用專用積體電路(Application Specific Integrated Circuit，ASIC)、或者一個或多個積體電路等方式實現，用於執行相關程式，以實現本說明書實施例所提供的技術方案。
儲存器1020可以採用ROM(Read Only Memory，唯讀記憶體)、RAM(Random Access Memory，隨機存取記憶體)、靜態儲存設備，動態儲存設備等形式實現。儲存器1020可以儲存操作系統和其他應用程式，在透過軟體或者韌體來實現本說明書實施例所提供的技術方案時，相關的程式代碼保存在儲存器1020中，並由處理器1010來呼叫執行。
輸入/輸出介面1030用於連接輸入/輸出模組，以實現資訊輸入及輸出。輸入輸出/模組可以作為組件配置在設備中(圖中未示出)，也可以外接於設備以提供相應功能。其中輸入設備可以包括鍵盤、滑鼠、觸控螢幕、麥克風、各類傳感器等，輸出設備可以包括顯示器、揚聲器、振動器、指示燈等。
通訊介面1040用於連接通訊模組(圖中未示出)，以實現本設備與其他設備的通訊交互。其中通訊模組可以透過有線方式(例如USB、網路線等)實現通訊，也可以透過無線方式(例如行動網路、WIFI、藍牙等)實現通訊。
匯流排1050包括一通路，在設備的各個組件(例如處理器1010、儲存器1020、輸入/輸出介面1030和通訊介面1040)之間傳輸資訊。
需要說明的是，儘管上述設備僅示出了處理器1010、儲存器1020、輸入/輸出介面1030、通訊介面1040以及匯流排1050，但是在具體實施過程中，該設備還可以包括實現正常運行所必需的其他組件。此外，本領域的技術人員可以理解的是，上述設備中也可以僅包含實現本說明書實施例方案所必需的組件，而不必包含圖中所示的全部組件。
本說明書實施例還提供一種電腦可讀儲存媒體，其上儲存有電腦程式，該程式被處理器執行時實現前述的保險交易處理方法。該方法至少包括：
一種保險交易處理方法，該方法包括：
根據目標保險交易的險種，確定與所述險種對應的保單產生策略，所述保單產生策略包括：所述險種產生保單時採用的保單維度；
根據所述保單產生策略，檢查所述保單維度下是否已存在所述險種的保單；
在不存在保單的情況下，在所述保單維度下產生所述險種的保單，並根據所述目標保險交易的交易資訊產生所述保單的管理規則；
在已存在保單的情況下，根據所述目標保險交易的交易資訊更新所述保單的管理規則，以透過所述保單對所述目標保險交易進行管理；
其中，所述管理規則用於對保單對應的各保險交易進行管理。
電腦可讀媒體包括永久性和非永久性、可移除和非可移除媒體可以由任何方法或技術來實現資訊儲存。資訊可以是電腦可讀指令、資料結構、程式的模組或其他資料。電腦的儲存媒體的例子包括，但不限於相變記憶體(PRAM)、靜態隨機存取記憶體(SRAM)、動態隨機存取記憶體(DRAM)、其他類型的隨機存取記憶體(RAM)、唯讀記憶體(ROM)、電可抹除可程式化唯讀記憶體(EEPROM)
、快閃記憶體或其他記憶體技術、唯讀光碟唯讀儲存器(CD-ROM)、數位多功能光碟(DVD)或其他光學儲存、卡式磁帶，磁帶磁磁碟儲存或其他磁性儲存設備或任何其他非傳輸媒體，可用於儲存可以被計算設備存取的資訊。按照本文中的界定，電腦可讀媒體不包括暫存電腦可讀媒體(transitory media)，如調變的資料信號和載波。
透過以上的實施方式的描述可知，本領域的技術人員可以清楚地瞭解到本說明書實施例可借助軟體加必需的通用硬體平臺的方式來實現。基於這樣的理解，本說明書實施例的技術方案本質上或者說對現有技術做出貢獻的部分可以以軟體產品的形式體現出來，該電腦軟體產品可以儲存在儲存媒體中，如ROM/RAM、磁碟、光碟等，包括若干指令用以使得一台電腦設備(可以是個人電腦，伺服器，或者網路設備等)執行本說明書實施例各個實施例或者實施例的某些部分所述的方法。
上述實施例闡明的系統、裝置、模組或單元，具體可以由電腦晶片或實體實現，或者由具有某種功能的產品來實現。一種典型的實現設備為電腦，電腦的具體形式可以是個人電腦、膝上型電腦、行動電話、相機電話、智慧電話、個人數位助理、媒體播放器、導航設備、電子郵件收發設備、遊戲控制台、平板電腦、可穿戴設備或者這些設備中的任意幾種設備的組合。
本說明書中的各個實施例均採用遞進的方式描述，各個實施例之間相同相似的部分互相參見即可，每個實施例重點說明的都是與其他實施例的不同之處。尤其，對於裝置實施例而言，由於其基本相似於方法實施例，所以描述得比較簡單，相關之處參見方法實施例的部分說明即可。以上所描述的裝置實施例僅僅是示意性的，其中所述作為分離部件說明的模組可以是或者也可以不是實體上分開的，在實施本說明書實施例方案時可以把各模組的功能在同一個或多個軟體及/或硬體中實現。也可以根據實際的需要選擇其中的部分或者全部模組來實現本實施例方案的目的。本領域普通技術人員在不付出進步性勞動的情況下，即可以理解並實施。
以上所述僅是本說明書實施例的具體實施方式，應當指出，對於本技術領域的普通技術人員來說，在不脫離本說明書實施例原理的前提下，還可以做出若干改進和潤飾，這些改進和潤飾也應視為本說明書實施例的保護範圍。In order to enable those skilled in the art to better understand the technical solutions in the embodiments of this specification, the technical solutions in the embodiments of this specification will be described in detail below in conjunction with the drawings in the embodiments of this specification. Obviously, the described implementation The examples are only a part of the embodiments of this specification, not all the embodiments. Based on the embodiments in this specification, all other embodiments obtained by those of ordinary skill in the art should fall within the scope of protection. In view of the problems of the prior art, the embodiments of this specification provide an insurance transaction processing method. As shown in FIG. 1, the method may include the following steps: S101, according to the insurance type of the target insurance transaction, determine the policy generation strategy corresponding to the insurance type, The policy generation strategy includes: the policy dimensions used when the insurance policy is generated by the insurance type; when a user purchases insurance, he will first need to conclude a transaction with an insurance institution, and then sign an insurance contract to form a corresponding insurance policy. In an insurance scenario, the same user ( The policyholder) can enter into multiple transactions with the same insurance institution. Take material insurance as an example. The material insurance is paid for by the seller, and the buyer enjoys the insurance of the indemnified rights. Once the seller chooses to join this insurance type, he will insure every order of goods within the insurance coverage in the store. Some of the commodities insured are insured for material insurance, and every time an order for a related product is generated, the seller concludes a material insurance transaction with the insurance agency. In the traditional insurance management scheme, one insurance policy is created for each insurance transaction, and each insurance policy has an independent insurance, payment, and claims process. However, Internet insurance generally has the characteristics of fragmentation, low premiums, and high transaction frequency, which are different from traditional insurance. Still taking material insurance as an example, sellers may generate dozens or even hundreds of commodity orders every day, corresponding to hundreds of material insurance transactions with insurance companies. According to the traditional insurance management plan, hundreds of insurance policies will be created. , And separate insurance, payment, claims and other processes, resulting in low management efficiency. In the solution provided in the embodiment of this specification, different insurance policy dimensions are set for different insurance types. When an insurance transaction is concluded, an insurance policy is generated from the corresponding insurance policy dimension according to the insurance transaction type, and the insurance policy is generated based on several insurance transactions. A policy to improve the management efficiency of the policy. For example, the policy dimension may be the user dimension. It is understandable that users can refer to natural persons, enterprises, institutions, etc. In addition, they can refer to applicants, insured persons, beneficiaries, etc., and this manual does not limit it. Taking order insurance as an example, the policy dimension of this insurance type can be the seller dimension, that is, each order insurance transaction of the same seller generates one order insurance policy, so that the seller’s multiple order insurance policies are managed uniformly according to one policy. Transaction payment, claim settlement and other procedures. For another example, the insurance policy dimension may be the time dimension. Take freight insurance as an example. An e-commerce platform insures freight insurance for all buyers who shop on the platform. That is, every time a shopping order is generated, a freight insurance transaction is reached, and the platform may generate tens of thousands of shopping orders every day Therefore, one insurance policy can be generated corresponding to the daily freight insurance transaction in the time dimension, so as to uniformly manage the payment, claim settlement and other processes of multiple freight insurance transactions for each buyer based on one insurance policy. For another example, the dimension of the insurance policy can also be the dimension of the insured project. For example, a mutual insurance project initiated by a certain platform and an insurance institution can involve multiple people and multiple days. That is, for every user participating in the project, 1 transaction Mutual insurance transactions, therefore, one insurance policy can be generated corresponding to several mutual insurance transactions in one mutual insurance project in the project dimension, so as to uniformly manage the payment, claim settlement and other processes of multiple mutual insurance transactions of each user according to one insurance policy . S102. According to the policy generation strategy, check whether an insurance policy of the insurance type already exists in the insurance policy dimension; as described above, a number of insurance transactions in the same dimension will generate one insurance policy. Therefore, it is necessary to check first Whether an insurance policy has been generated in this dimension. Still taking order insurance as an example, when a seller generates 1 purchase order, it corresponds to 1 order insurance transaction, and confirms that in the policy generation strategy of order insurance, the policy dimension is the seller dimension, you can check whether the seller already exists Order insurance policy. S103: In the case that there is no insurance policy, generate an insurance policy of the insurance type under the policy dimension, and generate a management rule of the insurance policy according to transaction information of the target insurance transaction; the management rule is used to correspond to the insurance policy In a specific implementation of this specification, the policy generation strategy may also include: the management dimension of each insurance transaction corresponding to the insurance policy generated by the insurance type. In an example, when the insurance policy of the insurance type is generated under the policy dimension, and the management rules of the insurance policy are generated according to the transaction information of the target insurance transaction, the insurance policy of the insurance type may be generated first under the insurance policy dimension. And determine the management dimension of the target insurance transaction according to the policy generation strategy. Then, according to the determined management dimension, a management group corresponding to the generated insurance policy is created, the management group includes the target insurance transaction, and the management group rules of the management group are generated according to the transaction information of the target insurance transaction. The management rules of the insurance policy include the management group rules. The specific content of the management dimension is not limited in the embodiments of this specification, and those skilled in the art can flexibly set the policy dimension and the management dimension according to actual needs. Still taking order insurance as an example, the policy dimension of order insurance can be set to the user dimension, and the management dimension can be set to the time dimension. Specifically, each daily order insurance transaction can be grouped into the same management group, and the seller’s Each order insurance transaction under each management group generates one insurance policy correspondingly. The policy management rules include the management rules of each management group, and each order insurance transaction in the same management group is managed through the management group rules of the group, such as the time and date of payment. In addition, the management rules may also include other rules for further management of each order insurance transaction, such as managing whether the insurance period of the seller's order insurance policy expires and whether it is renewed, etc. S104: In the case of an existing insurance policy, update the management rules of the insurance policy according to the transaction information of the target insurance transaction, so as to manage the target insurance transaction through the insurance policy; in a specific implementation of this specification, When updating the management rules of the insurance policy according to the transaction information of the target insurance transaction to manage the target insurance transaction through the insurance policy, the management of the target insurance transaction may be determined first according to the policy generation strategy And check whether the insurance policy has a corresponding management group under the determined management dimension. In the case of a management group, the target insurance transaction is added to the management group, and the management group rules of the management group are updated according to the transaction information of the target insurance transaction; for example, the management group rules may include those under the management group When you update the management group rules, you can add the transaction identification and payment amount of the target insurance transaction to the management group rules to generate a payment reminder when you need to pay, or Automatic payment for the insurance transaction, etc. In the case that there is no management group, the management group corresponding to the insurance policy is created in the management dimension, and the management group rules of the management group are generated according to the transaction information of the target insurance transaction. In another specific implementation of this specification, the management rules may include one or more of the following sub-rules: payment sub-rules, the payment sub-rules are used to: determine the payment time and payment amount of the managed insurance transaction ; The insurance period sub-rule, the insurance period sub-rule is used to determine whether the managed insurance transaction expires and/or whether it is renewed; the publicity sub-rule, the publicity sub-rule is used to: publicize the managed insurance transaction The management information of insurance transactions, the management information includes: payment information, claims information, insurance period information, and/or user credit information. It is understandable that if the management rules also include management group rules, the management group rules may also include one or more of the aforementioned sub-rules. For example, the policy generation strategy of insurance type A does not include the management dimension, that is, each insurance transaction under the policy does not need to be divided into management groups, and the management rules of the policy can include payment sub-rules, insurance period sub-rules, and publicity sub-rules One or more of. The policy generation strategy of insurance category B includes the management dimension, that is, each insurance transaction under the policy is divided into management groups according to the management dimension, and managed according to the management group rules of the management group, then each management group rule can also include One or more of payment sub-rules, warranty sub-rules, and publicity sub-rules; or management rules can directly include one or more of payment sub-rules, warranty sub-rules, and publicity sub-rules; of course, it can also be in management rules Including the publicity sub-rule, and the management group rules include the payment sub-rule and the warranty sub-rule; etc., this specification does not limit this. The following describes the insurance transaction processing methods provided in this manual with a few more specific examples. (1) Assuming that the insurance type of the target insurance transaction A is order insurance, in determining the policy generation strategy corresponding to the order insurance, the insurance policy dimension used when generating the insurance policy is the seller dimension. In addition, in the policy generation strategy, the management dimension of each insurance transaction corresponding to the generated policy is the date dimension. In addition, the management group rules include the payment sub-rule. The specific rules are to pay premiums within N days after the insurance is insured. The management rules include the management group rules and the warranty sub-rules. The specific rules of the warranty sub-rules are that the seller’s policy period is 1 year. Therefore, after completing an order insurance transaction, first check whether the seller already has an order insurance policy. If there is no insurance policy, generate the seller’s order insurance policy and generate the management group on the same day (T day). According to the transaction time T day of this order insurance transaction and the premium X 1 yuan to be paid, the payment sub-rule of the management group is generated, specifically, X 1 yuan premium is paid on T+N day. If another order insurance transaction is reached on the same day, the result of checking whether there is an order insurance policy under the seller dimension will be an existing insurance policy, and after checking that there is a corresponding management group, the order insurance transaction will be added to the management group. And according to the transaction time T day of this order insurance transaction and the premium X 2 yuan to be paid, update the payment sub-rule in the management group rules of the management group, and pay X 1 +X 2 yuan premium on T+N day after the update . It can be seen that, as shown in Figure 2, the order insurance transactions concluded on the same day can be added to the same management group, and the payment date and amount can be uniformly managed according to the total amount of order insurance transactions, and an insurance policy can be generated for the order insurance transaction of the same seller , So as to carry out unified management of the insurance period, etc., without affecting the original insurance content, improve the management efficiency of order insurance with short insurance period and large insurance transaction volume. (2) After the investor invests funds in the financing platform, the borrower can borrow the investor’s funds through the platform, and repay the principal and a certain amount of interest after the scheduled loan period expires, in order to ensure that the investor can fully recover the advance The promised principal and interest can be used to insure investment insurance for each loan of the investor. Assuming that the insurance type of the target insurance transaction B is investment insurance, in determining the policy generation strategy corresponding to the order insurance, the policy dimension used when generating the insurance policy is the investor dimension. Moreover, the management rules include the payment sub-rule and the insurance period sub-rule. Specifically, the payment sub-rule specifies the date of payment and the corresponding premium amount of the loaned amount based on each loan insured. The basis of the insurance period sub-rule The repayment date of each insured loan stipulates the corresponding insurance period, and according to the investor's setting, stipulates whether the insurance is automatically renewed when the funds are borrowed again. Therefore, after a loan is made and an investment insurance transaction is reached, first check whether there is an investment insurance policy under the investor. If there is no insurance policy, the investor’s investment insurance policy is generated and the investment insurance policy is generated. The payment sub-rules and the insurance period sub-rules in the policy management rules. When the loan is returned according to the predetermined principal and interest, the investment insurance will also terminate the protection, and when the investor’s funds are lent again, another investment insurance transaction will be concluded. After checking whether there is an order in the investor dimension The result of the insurance policy will be the existence of an insurance policy, and then the payment sub-rule and the insurance period sub-rule will be updated directly based on the amount of the loan and the date of repayment in the investment insurance transaction concluded this time. It can be seen that each investment insurance transaction of the same investor can be managed uniformly by one insurance policy of the investor. When the borrowing situation changes, it is only necessary to update the management of the insurance policy according to the transaction information such as the amount of the borrowed money and the repayment date. Rules, so as to improve the management efficiency of investment insurance with flexible insurance periods and premiums without affecting the original protection content. Corresponding to the foregoing method embodiment, the embodiment of this specification also provides an insurance transaction processing device. As shown in FIG. 3, the device may include: a strategy determination module 110 for determining the insurance transaction according to the target insurance transaction The corresponding policy generation strategy, the policy generation strategy includes: the insurance policy dimension used when the insurance policy is generated by the type of insurance; the insurance policy checking module 120 is configured to check whether the insurance policy dimension already exists in the insurance policy according to the policy generation strategy Insurance policy of the type of insurance; The policy generation module 130 is used to generate the insurance policy of the type of insurance in the dimension of the insurance policy when there is no insurance policy, and generate the management rules of the insurance policy according to the transaction information of the target insurance transaction The rule update module 140 is used to update the management rules of the policy according to the transaction information of the target insurance transaction in the case of an existing policy, so as to manage the target insurance transaction through the policy; The management rules are used to manage each insurance transaction corresponding to the insurance policy. In a specific implementation manner provided in this specification, the policy generation strategy may further include: the management dimensions of each insurance transaction corresponding to the insurance policy generated by the insurance type. In a specific implementation manner provided in this specification, referring to FIG. 4, the insurance policy generation module 130 may include: an insurance policy generation unit 131, configured to generate an insurance policy of the type of insurance under the insurance policy dimension; The unit 132 is configured to determine the management dimension of the target insurance transaction according to the policy generation strategy; the management group creation unit 133 is configured to create a management group corresponding to the generated insurance policy according to the determined management dimension, in the management group Including the target insurance transaction; a rule generating unit 134, configured to generate a management group rule of the management group according to the transaction information of the target insurance transaction, and the management rule of the generated insurance policy includes the management group rule. In a specific implementation manner provided in this specification, referring to FIG. 5, the rule update module 140 includes: a dimension determination unit 141, configured to determine the management dimension of the target insurance transaction according to the policy generation strategy The management group checking unit 142 is used to check whether the insurance policy has a corresponding management group in the determined management dimension; the rule updating unit 143 is used to add the target insurance transaction to the target insurance transaction if there is a management group The management group, and update the management group rules of the management group according to the transaction information of the target insurance transaction; the rule generation unit 144 is used to create the corresponding insurance policy in the management dimension when there is no management group And generate the management group rules of the management group according to the transaction information of the target insurance transaction; wherein, the management rules of the insurance policy include the management group rules. In a specific implementation manner provided in this specification, the management rules may include: payment sub-rules, which are used to: determine the payment time and payment amount of the managed insurance transaction; and/or, the warranty period Sub-rules, the warranty sub-rules are used to: determine whether the managed insurance transaction expires and/or whether to renew; and/or, the publicity sub-rules are used to: publicize the managed insurance transactions The management information of insurance transactions, the management information includes: payment information, claims information, insurance period information, and/or user credit information. For the implementation process of the functions and roles of each module in the above-mentioned device, refer to the implementation process of the corresponding steps in the above-mentioned method for details, which will not be repeated here. The embodiment of the specification also provides a computer device, which at least includes a storage, a processor, and a computer program stored in the storage and capable of running on the processor, wherein the processor executes the aforementioned insurance transaction processing method. The method includes at least: an insurance transaction processing method, the method comprising: determining an insurance policy generation strategy corresponding to the insurance type according to the insurance type of the target insurance transaction, the insurance policy generation strategy including: the insurance policy dimension used when the insurance type generates the insurance policy ; According to the policy generation strategy, check whether an insurance policy of the insurance type already exists in the policy dimension; if there is no insurance policy, generate an insurance policy of the insurance type under the policy dimension, and according to the target insurance The transaction information of the transaction generates the management rules of the insurance policy; in the case of an existing insurance policy, the management rules of the insurance policy are updated according to the transaction information of the target insurance transaction, so as to manage the target insurance transaction through the insurance policy ; Wherein, the management rules are used to manage each insurance transaction corresponding to the insurance policy. 6 shows a more specific hardware structure diagram of a computing device provided by an embodiment of this specification. The device may include: a processor 1010, a storage 1020, an input/output interface 1030, a communication interface 1040, and a bus 1050 . The processor 1010, the storage 1020, the input/output interface 1030 and the communication interface 1040 realize the communication connection between each other in the device through the bus 1050. The processor 1010 may be implemented by a general CPU (Central Processing Unit, central processing unit), a microprocessor, an application specific integrated circuit (Application Specific Integrated Circuit, ASIC), or one or more integrated circuits, etc., for Execute related programs to realize the technical solutions provided in the embodiments of this specification. The storage 1020 can be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage device, dynamic storage device, etc. The storage 1020 can store the operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the related program codes are stored in the storage 1020 and called for execution by the processor 1010 . The input/output interface 1030 is used for connecting input/output modules to realize information input and output. The input/output/module can be configured in the device as a component (not shown in the figure), or can be connected to the device to provide corresponding functions. The input devices may include keyboards, mice, touch screens, microphones, various sensors, etc., and output devices may include displays, speakers, vibrators, indicator lights, and so on. The communication interface 1040 is used to connect a communication module (not shown in the figure) to realize the communication interaction between the device and other devices. The communication module can realize communication through wired means (such as USB, network cable, etc.), or through wireless means (such as mobile network, WIFI, Bluetooth, etc.). The bus 1050 includes a path for transmitting information between various components of the device (such as the processor 1010, the storage 1020, the input/output interface 1030, and the communication interface 1040). It should be noted that although the above device only shows the processor 1010, the storage 1020, the input/output interface 1030, the communication interface 1040, and the bus 1050, in the specific implementation process, the device may also include a place for normal operation. Other required components. In addition, those skilled in the art can understand that the above-mentioned device may also include only the components necessary to implement the solutions of the embodiments of the present specification, rather than all the components shown in the figures. The embodiment of the specification also provides a computer-readable storage medium on which a computer program is stored, and the program is executed by a processor to implement the aforementioned insurance transaction processing method. The method includes at least: an insurance transaction processing method, the method comprising: determining an insurance policy generation strategy corresponding to the insurance type according to the insurance type of the target insurance transaction, the insurance policy generation strategy including: the insurance policy dimension used when the insurance type generates the insurance policy ; According to the policy generation strategy, check whether an insurance policy of the insurance type already exists in the policy dimension; if there is no insurance policy, generate an insurance policy of the insurance type under the policy dimension, and according to the target insurance The transaction information of the transaction generates the management rules of the insurance policy; in the case of an existing insurance policy, the management rules of the insurance policy are updated according to the transaction information of the target insurance transaction, so as to manage the target insurance transaction through the insurance policy ; Wherein, the management rules are used to manage each insurance transaction corresponding to the insurance policy. Computer-readable media includes permanent and non-permanent, removable and non-removable media, and information storage can be realized by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), and other types of random access memory (RAM) , Read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, CD-ROM, digital multi-function Optical discs (DVD) or other optical storage, cassette tapes, magnetic tape storage or other magnetic storage devices or any other non-transmission media can be used to store information that can be accessed by computing devices. According to the definition in this article, computer-readable media does not include transitory media, such as modulated data signals and carrier waves. From the description of the above embodiments, those skilled in the art can clearly understand that the embodiments of this specification can be implemented by means of software plus a necessary general hardware platform. Based on this understanding, the technical solutions of the embodiments of this specification can be embodied in the form of software products, which can be stored in storage media, such as ROM/RAM, magnetic A disc, an optical disc, etc., include a number of instructions to make a computer device (which can be a personal computer, a server, or a network device, etc.) execute the methods described in the various embodiments or some parts of the embodiments of this specification. The systems, devices, modules or units explained in the above embodiments may be implemented by computer chips or entities, or implemented by products with certain functions. A typical implementation device is a computer. The specific form of the computer can be a personal computer, a laptop, a mobile phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email receiving and sending device, and a game console , Tablets, wearable devices, or a combination of any of these devices. The various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, as for the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and for related parts, please refer to the partial description of the method embodiment. The device embodiments described above are only illustrative, and the modules described as separate components may or may not be physically separated. When implementing the embodiments of this specification, the functions of the modules can be Implemented in the same one or more software and/or hardware. It is also possible to select some or all of the modules according to actual needs to achieve the objectives of the solutions of the embodiments. Those of ordinary skill in the art can understand and implement it without making progressive work. The above are only specific implementations of the embodiments of this specification. It should be pointed out that for those of ordinary skill in the art, without departing from the principle of the embodiments of this specification, several improvements and modifications can be made. These Improvements and modifications should also be regarded as the protection scope of the embodiments of this specification.
