CN110570321B

CN110570321B - Block chain based reinsurance business method and system

Info

Publication number: CN110570321B
Application number: CN201910870073.9A
Authority: CN
Inventors: 周征; 陈小云; 陈洁玉
Original assignee: Shanghai Insurance Exchange Co ltd
Current assignee: Shanghai Insurance Exchange Co ltd
Priority date: 2019-09-16
Filing date: 2019-09-16
Publication date: 2022-11-01
Anticipated expiration: 2039-09-16
Also published as: CN110570321A

Abstract

The present disclosure relates to a method and system for a block chain based reinsurance service involving a cedent and a cedent, generating policy details by the cedent, and sending a first message to a block chain system to add a first transaction and a second transaction in a first queue of the cedent and a second queue of the cedent in the block chain system, respectively, wherein a processing progress of the reinsurance service is represented by a processing status of the first transaction or the second transaction. Thereafter, the second queue is read from the blockchain system by the ingress. In case that the reinsurer accepts the reinsurance service, a second message is transmitted to the blockchain to delete the first transaction and the second transaction in the first queue of the exporter and the second queue of the importer in the blockchain system, respectively, and to add a third transaction and a fourth transaction in the third queue of the exporter and the fourth queue of the importer, respectively, wherein the completion state of the reinsurance service is represented by the third transaction and the fourth transaction.

Description

Block chain based reinsurance business method and system

Technical Field

The present disclosure relates to the field of blockchain, and more particularly, to a method and system for processing and encryption of block chain based reinsurance services.

Background

The reinsurance business is also called as 'insurance distribution' business, and the business relates to a distributor and a distributor, and the distributor distributes partial risks and responsibilities covered by the distributor to the distributor for insurance by signing a distribution contract on the basis of an original insurance contract. Generally, the reinsurance business mainly includes reinsurance division business, reinsurance post-adjustment business, correction business, and the like. In the conventional reinsurance service, when a distributor distributes the reinsurance service to a distributor, the distributor needs to generate an offline insurance list in a local service core system (i.e., the distributor service core system), sign a reinsurance slip file (i.e., a distribution strip), deliver the distribution strip to the distributor, and store the insurance list in the distributor service core system in a manual entry manner. However, the above conventional reinsurance business using offline transfer, manual entry, manual reconciliation, etc. has many disadvantages. Specifically, offline transfer causes low efficiency and waste of cost of the business process; omission or errors may occur in manual entry, which causes inconsistency between the input information and the output information; manual reconciliation may also reduce business efficiency. In addition, the distributor cannot inform the distributor of the claim information in time, so that the claim money cannot be allocated in time; the distributor can not timely provide the fund and can not update the operation report. More importantly, effective protection measures against private data are lacking in the conventional reinsurance business.

The reinsurance business is partially migrated to the block chain system, the original off-line operation can be converted into on-line operation, a data information island is opened, and the efficiency of the reinsurance business is greatly improved. However, blockchains as distributed ledgers are not suitable for operating complex business processes and storing large amounts of data. In addition, various types of information are mainly stored in a data form in the blockchain system, and the flow state of the service is difficult to represent and store. Meanwhile, there is currently no encryption/decryption mechanism for reinsurance services in a blockchain to ensure privacy of data.

Therefore, there is a need for an efficient and reliable method and system for processing and encryption of block chain based reinsurance services.

Disclosure of Invention

The present disclosure provides a novel method and system for block chain based reinsurance.

According to a first aspect of the present disclosure, there is provided a method for reinsurance business involving a cedent and a cedent, the method comprising, by the cedent: generating policy details based on the branch policy and the policy information, wherein the policy details correspond to the first UUID; sending a first message to the blockchain system through the blockchain transaction processing interface, wherein the first message comprises a first UUID so as to add a first transaction and a second transaction in a first queue of a distributor and a second queue of a distributor in the blockchain system respectively, and the processing progress of the reinsurance service is represented by the processing state of the first transaction or the second transaction.

Correspondingly, according to a first aspect, the present disclosure provides a first electronic device for reinsurance services, the first electronic device for a cedent. The first electronic device includes: one or more processors; and one or more memories configured to store computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to perform a respective method.

According to a second aspect of the present disclosure, there is provided a method for reinsurance services involving an egress party and an ingress party, the method comprising, by the ingress party: reading the second queue of the ingress from a blockchain system through a blockchain link point transaction processing interface, wherein the first queue of the egress and the second queue of the ingress are stored in the blockchain system, and the processing progress of the reinsurance business is represented by the processing status of the first item in the first queue of the egress and the second item in the second queue of the ingress.

Correspondingly, according to a second aspect, the present disclosure provides a second electronic device for reinsurance business, the second electronic device for a distributor. The second electronic device includes: one or more processors; and one or more memories configured to store computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to perform a respective method.

According to a third aspect of the present disclosure, there is provided a method for reinsurance services involving a cedent and a cedent, the method comprising, by a blockchain system: receiving a first message from the cedent through a blockchain transaction processing interface, the first message including a first UUID corresponding to policy details to add a first transaction and a second transaction in a first queue of the cedent and a second queue of the cedent in the blockchain system, respectively, wherein a processing progress of the reinsurance service is represented by a processing status of the first transaction or the second transaction.

Correspondingly, according to a third aspect, the present disclosure provides a third electronic device for reinsurance business, the third electronic device for use in a blockchain system. The third electronic device includes: one or more processors; and one or more memories configured to store computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to perform a respective method.

According to a fourth aspect of the present disclosure, there is provided a system for reinsurance business, comprising a first electronic device, a second electronic device, and a third electronic device as described above.

Other features of the present disclosure and advantages thereof will become more apparent from the following detailed description of exemplary embodiments thereof, which proceeds with reference to the accompanying drawings.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments of the disclosure and together with the description, serve to explain the principles of the disclosure.

The present disclosure may be more clearly understood from the following detailed description, taken with reference to the accompanying drawings, in which:

fig. 1 shows a system architecture diagram of a block chain based reinsurance service according to an exemplary embodiment of the present disclosure.

Fig. 2A-2C illustrate a flow chart of a method of block chain based reinsurance business according to an exemplary embodiment of the present disclosure.

Fig. 3 illustrates a system interaction diagram of a block chain based reinsurance service according to an exemplary embodiment of the present disclosure.

Fig. 4 shows a schematic diagram of an encryption and decryption mechanism according to an exemplary embodiment of the present disclosure.

Fig. 5 illustrates a schematic diagram of queue states on a blockchain according to an exemplary embodiment of the present disclosure.

FIG. 6 illustrates an exemplary configuration of a computing device in which embodiments in accordance with the present disclosure may be implemented.

Detailed Description

Various exemplary embodiments of the present disclosure will be described in detail below with reference to the accompanying drawings. It should be noted that: the relative arrangement of the components and steps, the numerical expressions, and numerical values set forth in these embodiments do not limit the scope of the present disclosure unless specifically stated otherwise. In the following description, numerous details are set forth in order to better explain the present disclosure, however, it is understood that the present disclosure may be practiced without these details.

The following description of various exemplary embodiments is merely illustrative, and one of ordinary skill in the art will recognize that other variations, modifications, and alternatives are possible. In this disclosure, the terms "first," "second," and the like are used merely to distinguish between elements or steps, and the like, and are not intended to indicate temporal order, priority, or importance.

Techniques, methods, and apparatus known to those of ordinary skill in the art may not be discussed in detail herein, but are intended to be considered a part of the specification where appropriate.

It should be understood that the following embodiments of the present disclosure are primarily directed to a reinsurance breakout service by way of example, but the related systems and methods are not limited thereto, and the systems and methods described below are equally applicable, for example, to a reinsurance post-adjustment service, a wholesale service, and the like.

Fig. 1 shows a schematic diagram of a system architecture 100 for block chain based reinsurance services according to an exemplary embodiment of the present disclosure. As shown in fig. 1, the block chain based reinsurance system is mainly composed of the following parts: a service core system (or service front-end page), a front-end system, an SDK server, an intelligent contract and a block chain service layer. Further details regarding the various components of the system will be provided below.

In the exemplary embodiment shown in fig. 1, company a is the cedent of the reinsurance business and company B is the cedent. The business core system comprises a company A business core system 101 and a company B business core system 102; business front end pages include a company a business front end page 103 and a company B business front end page 104. The user can initiate reinsurance services, view and update the service status, and view policy details through the service core system or service front end page. Meanwhile, the service front-end page provides graphical interface display and interaction with a user, wherein the displayed content is plaintext information. Since blockchains are not suitable for operating complex business processes and storing large amounts of data as distributed ledgers, there are added pre-systems (including company a pre-system 105 and company B pre-system 106) in the present disclosure, and most business processes and key (including public and private key) management are handled in the pre-systems. The front-end system adopts a mature B/S (browser/server) mode and is responsible for interacting with a business core system (or a business front-end page) and a block chain system. As an example, the front-end system may encrypt the plaintext information of the service front-end page, and then link up the ciphertext data through the SDK server 107 and store it on the associated blockchain node, where the blockchain nodes may include the company a-chain node 108, the company B-chain node 109, and the regulatory agency chain node 110, and where the front-end system is not directly connected to the database. Before performing data uplink and on-chain information query operations, the intelligent contract 111 as a block chain service implementation layer needs to be invoked. The intelligent contract 111 may be regarded as a piece of program which is deployed on the blockchain and can run automatically, and one intelligent contract may be deployed on each blockchain node to implement the required flow of the reinsurance business. In addition, the system further includes a blockchain service layer 112, which is responsible for consensus services, accounting services, P2P network services, database services, and status information maintenance.

It should be understood that the system architecture herein is merely one example. Those skilled in the art may add more or delete some of the components, and may modify the function and configuration of some of the components, as desired. For example, in some embodiments, there may be one cedent and multiple cedents, where each cedent shares a different reinsurance business.

Fig. 2A-2C illustrate a flow chart of a method of block chain based reinsurance business according to an exemplary embodiment of the present disclosure. As described above, in the conventional blockchain system, various types of information are mainly stored in a data form, and it is difficult to represent and store a flow state in the reinsurance service. In this regard, the present disclosure stores corresponding queues on the blockchain nodes (including the drop side chain node and the drop side chain node, etc.), and represents the processing progress of the reinsurance service by the processing status of the transactions on these queues.

In particular, fig. 2A illustrates operations 200A performed at an egress front-end system after a request to re-insurance service (e.g., re-insurance egress service) is initiated by an egress to an ingress. At step S201A, the ceder front-end system first generates policy details based on the underwriting bar and policy information, wherein the policy details correspond to a first Universally Unique Identifier (UUID). The first UUID is a policy UUID in this exemplary embodiment. In step S202A, the head-end system of the distributor sends a first message including the policy UUID to the blockchain system through the blockchain transaction processing interface so as to add a first transaction and a second transaction in a first queue of the distributor and a second queue of the distributor, respectively, in the blockchain system, wherein the processing progress of the reinsurance service is represented by the processing status of the first transaction or the second transaction. In the present exemplary embodiment, the first queue of the exporter may be an exporter pending queue, wherein the first transaction contained therein is a exporter pending transaction, such as the exporter having sent a repudiation request to the importer and waiting for a response; the second queue of the ingress may be a ingress pending queue, wherein the second transaction contained therein is a ingress pending transaction of the ingress, such as the ingress having been requested by the egress to perform a reservative egress service and needing to give a response.

Fig. 2B illustrates operation 200B performed at the egress front-end system after adding respective backlogs to the egress pending queue and the ingress pending queue in the blockchain. In step S201B, the splitter front-end system reads the backlog in the splitter queue from the blockchain system through the blockchain link point processing interface.

Corresponding to the foregoing method flow, fig. 2C illustrates operation 200C performed at the blockchain system. In step S201C, the blockchain system receives a first message from the drop through the blockchain transaction processing interface, where the first message includes a policy UUID corresponding to the policy details, so as to add the drop to-be-processed transaction and the drop to-be-processed transaction in the drop to-be-processed queue and the drop to-be-processed queue in the blockchain system, respectively.

Fig. 3 shows a system interaction diagram 300 for block chain based reinsurance services according to an example embodiment of the present disclosure. Figure 3 is intended to illustrate and explain the reinsurance business process shown in figures 2A-2C in more detail.

Firstly, the branch party uploads the re-guaranteed slip file (namely the sub-guaranteed strip) to a Secure File Transfer Protocol (SFTP) server, acquires the corresponding sub-guaranteed strip UUID and the hash, and generates a detailed policy request by using the sub-guaranteed strip UUID, the hash and policy information so as to request for re-guaranteeing the split service. The policy details correspond to a unique policy UUID.

Next, the drop front-end system encrypts the policy details and stores the associated policy data on the blockchain. Meanwhile, the exporter front-end system calls the blockchain transaction processing interface to send a first message comprising the policy UUID to the blockchain system, so that the exporter pending queue in the blockchain system is added with the exporter pending transaction, and the exporter pending transaction is added with the exporter pending queue. The first message may include the contents of the drop to-do and the drop to-do. It should be noted that when there are a plurality of backlogs for the importer and the exporter corresponding to the same policy number, only the latest backlog in the respective backlog queues is reserved.

And then, the distributor acquires the distribution to-be-processed items through the service front-end page request, so that the distributor front-end system reads the distribution to-be-processed items from the blockchain system through the blockchain transaction processing interface, and the distributor knows that the distributor is requested to execute the reinsurance distribution service and waits for the distributor to respond. The distributor front-end system may obtain the policy UUID from the distributor backlog, obtain the encrypted policy details in the blockchain system in correspondence therewith, and then decrypt it to obtain the policy details. The policy details may then be displayed via the drop service front end page for the drop to consider and decide whether to accept the reinsurance drop service.

If the branch-in party accepts the branch-out bar (namely accepts the re-guarantee branch-out service), the confirmation can be clicked through the front-end page, then the branch-in party front-end system sends a second message comprising the insurance policy UUID to the blockchain system through the blockchain transaction processing interface, so that the branch-in to-be-processed items and the branch-out to-be-processed items are respectively deleted on the branch-in party to-be-processed queue and the branch-out party to-be-processed queue in the blockchain system, and meanwhile, the branch-in completion items and the branch-out completion items are respectively added in the branch-in party completion queue and the branch-out party completion queue in the blockchain system. The second message may include the sort completion and the contents of the sort completion. The entry completion item and the exit completion item indicate that the reinsurance exit service has been completed, so that the success of the application can be notified to the front page of the entrant, and the entrant can make a policy exit. Optionally, after the user clicks the confirmation on the front-end page of the distributor, the distributor front-end system calls the core distributor confirmation interface to acquire the assigned policy UUID, terminates the confirmation process and prompts error information if the policy UUID is not acquired correctly, and performs the above-described operations of deleting the to-be-processed items and adding the completion items if the policy UUID is acquired correctly.

If the distributor does not accept the distribution bar (i.e. refusing to guarantee the distribution service), the front-end page can be used for clicking to refuse, then the distributor front-end system requests to delete the distribution to-be-processed items on the distributor to-be-processed queue in the block chain system, and the items on the distributor to-be-processed queue are updated to the distribution refused items. The cedent front-end system can then read the cedent rejected entry from the blockchain system and can choose to regenerate and issue the cedent bar. Optionally, the ceder may view the reasons for rejection, and thus, the cedent may be re-generated and issued with a pertinence.

Fig. 4 shows a schematic diagram 400 of an encryption and decryption mechanism according to an example embodiment of the present disclosure. Although public and private key pairs of asymmetric encryption (RSA) are typically required to construct inter-node trust in blockchain systems, for reinsurance services, it is desirable to use different encryption/decryption schemes for different types of data to ensure that only transaction-related parties can view the related content, but transaction-unrelated parties cannot view the related content. The details of the encryption/decryption of the reinsurance slip file (i.e., the underwriting bar), the details of the policy, and the pending transactions will be described in detail below. Similar to fig. 1, the distributor in the present exemplary embodiment is company a, and the distributor is company B.

Encryption/decryption of a security stripe

The shareholder is part of the policy content and is a relatively independent content, and the shareholder is usually required to be stored in a ciphertext form on the SFTP server.

The uploading interface of the security stripe comprises two fields of a distributor and an distributor, the two fields correspond to a public and private key pair generated by adopting an RSA encryption algorithm, the public and private key pair is a special public and private key pair known by both the distributor (namely company A) and the distributor (namely company B), and comprises a special public key (hereinafter, abbreviated as AB public key) and a special private key (hereinafter, abbreviated as AB private key) known by both companies A and B. It should be noted that the generation of the public and private key pair based on the RSA encryption algorithm above is merely an example, and those skilled in the art may employ a public and private key pair generated by other encryption algorithms known in the art or discovered in the future.

The cedent front-end system may encrypt the shareholder strip using the AB public key, obtain the encrypted shareholder strip and upload it to and store it in the SFTP server. The upload interface may return the shareholder strip UUID and a hash (such as generated using the MD5 algorithm) as part of the policy details, which are described in more detail below.

Accordingly, the front-end system of the distributor can acquire the encrypted sub-security strip from the SFTP server, specifically, the encrypted sub-security strip can be downloaded through a policy detail page, and then the AB private key is used for decrypting the sub-security strip, so as to obtain a complete original re-secure clip file.

Encryption of policy details

The cedent front-end system may obtain policy information from the business core system (or business front-end page) including, but not limited to, a policy number, applicant, insurance carrier, principal, ceder information, etc. The policy information together with the aforementioned shareholder strip UUID and hash constitute policy details, which must include the sharer information. Only storing the UUID and hash of the shareholder stripe can avoid the data on the data chain from being too large.

The distributor front-end system encrypts the policy details using the AB public key, encrypts key elements of the policy details (where the key elements belong to policy information including a policy number, a risk, a master term, distributor information, etc.) using the AB private key, and generates a policy UUID through a hash algorithm. Policy data may be posted as a record to the blockchain ledger by invoking the smart contract, with policy UUID as a key (key) and encrypted policy details as a value (value).

Encryption/decryption of backlog

After the policy data uplink is stored, the following two business processes will occur:

(a) The method comprises the steps that a to-be-processed item is added to a to-be-processed item separating queue of a block chain, in the to-be-processed item separating queue, a key is a to-be-processed item separating UUID, the value is corresponding to-be-processed item content, and the content comprises information such as a policy UUID and the like encrypted by a public key (hereinafter referred to as an A public key) known only by a separating party. The issuer may then decrypt the policy UUID using its own private key to correspond to the policy details.

(b) The method comprises the steps that a to-be-processed item is added to a to-be-processed item queue of a distributor of a block chain, in the to-be-processed item queue, a key is a to-be-processed item UUID, the value is corresponding to-be-processed item content, and the content comprises information such as a policy UUID and the like encrypted by a public key (hereinafter referred to as a B public key) known only by the distributor. The distributor may then decrypt the policy UUID using its own private key to correspond to the policy details.

After the request for the reinsurance outgoing service is sent, the branch party needs to wait for the response of the branch party, and the branch party can manually confirm or reject the reinsurance outgoing service, which involves the following two service flows:

(c) And the distributor refreshes the pages to be processed, so that the distributor front-end system reads the distribution backlog from the block chain system. Specifically, the distributor front-end system obtains a distribution pending queue according to the chain node ID and the queue type, and decrypts the pending item using a private key known only to the distributor (hereinafter, referred to as a B private key) and obtains a distribution pending item content including the policy UUID. From the policy UUID, encrypted policy details can be obtained from records of the blockchain ledger using key-value pairs;

(d) And the dispatcher refreshes the page to be processed, so that the dispatcher front-end system reads the dispatcher backlog from the block chain system. Specifically, the cedent front-end system obtains a cedent to-be-processed queue according to the chain node ID and the queue type, and decrypts the to-be-processed item using a private key known only to the cedent (hereinafter, referred to as a private key) and obtains a content of the cedent to-be-processed item, the content including the policy UUID. The policy UUID corresponds to the policy that has been separated, which may have two states: pending and rejected. The ceder can only view pending policies and can regenerate policies for rejected policies and cede.

It should be appreciated that similar encryption/decryption schemes may be employed for other transactions on other queues. As an example, after adding an entry completion item to the entry completion queue of the block chain, in the item, the key is an entry completion item UUID, and the value is the corresponding completion item content, which includes information such as a policy UUID encrypted using the public key B. Similarly, after adding a sort-out completion item in the sort-out completion queue, in the item, the key is the sort-out completion item UUID, and the value is the corresponding completion item content, which includes information such as the policy UUID encrypted using the public key a.

Decryption of policy details

In flow (c) in the above description regarding encryption/decryption of backlog, the policy UUID may be obtained by dividing decryption into backlogs, and encrypted policy details may be obtained from the data chain system according to the policy UUID based on the key-value pair. Since the policy details are encrypted using the AB public key, the distributor front-end system can decrypt and obtain the policy details using the AB private key.

The encryption/decryption method is mainly completed by the front-end system, and as mentioned above, the front-end system manages the public and private key pairs. Taking the present exemplary embodiment as an example, when company a is a distributor and company B is a distributor, key information that needs to be kept in addition to File Transfer Protocol (FTP) server account information in the company a head-end system and the company B head-end system is shown in table 1.

A public key

A private key

B public key

B private key

AB public key

AB private key

Company A (Branch out square)

√

Company B (Fang income)

√

TABLE 1 Key information that company A and company B need to keep

Taking the front-end system of company a as an example, the relevant information for encryption/decryption that needs to be kept includes: the system comprises a public key A, a private key A, a public key B, a public key AB, a private key AB, FTP server account information and the like. It should be noted that in the case where company B is the distributor and company a is the distributor, the private public key and private key, both of which are known, are the BA public key and BA private key, respectively, rather than the AB public key and AB private key. Therefore, when company a initiates a reinsurance and separation service to company B, the AB public key and the AB private key need to be kept by both the two company front systems; when company B initiates a reservior distribution service to company a, both company front-end systems need to maintain the BA public key and the BA private key.

Fig. 5 illustrates an example diagram of queue states on a blockchain in accordance with this disclosure. As shown in fig. 5, the present disclosure is primarily directed to four queues: a drop pending queue 501, a drop pending queue 502, a drop completion queue 503, and a drop completion queue 504 (shown in the first row of the table in figure 5).

The first column of the table in fig. 5 shows four states in the reinsurance business. First, the egress side requests the ingress side to perform the reservior egress 505 service, and then the egress side to-be-processed item is added to the egress side to-be-processed queue 501 and the ingress side to-be-processed item is added to the ingress side to-be-processed queue 502. Alternatively, when the dispatcher needs to perform the reinsurance modification 506, the operations on the two queues are the same as the reinsurance dispatching operation, and only the content information of the to-be-processed item may be changed. After the branch-in party reads the branch-in to-be-processed items of the reinsurance branch-out or the reinsurance modification, the reinsurance service can be selected to be accepted or rejected. If rejected (507), the drop to-be-processed transaction on the drop to-be-processed queue 502 is deleted, and the drop to-be-processed transaction on the drop to-be-processed queue 501 is updated to a drop rejected state. If accepted (508), the outstanding transactions on the ceder pending queue 501 and the ceder pending queue 502 are deleted, while a cedent completion transaction is added to the ceder completion queue 503 and a cedent completion transaction is added to the ceder completion queue 504.

Similarly, for other reinsurance services, the state flow of the various queues is similar to the example described above. By way of example, the state flows on the various queues described above are equally applicable to reinsurance post adjustment, reinsurance post adjustment modification, and the transferor rejecting and accepting the reinsurance post adjustment.

The present disclosure provides a method and system for block chain based reinsurance services. By converting the traditional reinsurance business from offline to online operation, the business efficiency can be greatly improved. In particular, the present disclosure adds a front-end system, avoiding directly operating complex business processes and storing large amounts of data in a blockchain system. The method and the device can effectively represent and store the service flow state by adding, updating and deleting items in four queues on the block chain. The information to be processed by the intelligent contract is relatively concise, the uplink speed of data is improved, and the operation experience of a terminal user is improved. In addition, different encryption/decryption mechanisms are adopted for the branch insurance policy, the insurance policy details, the transaction contents on the queue and the like, so that only transaction related parties can know the transaction contents, and transaction unrelated parties cannot know the transaction contents, and data isolation of different services in the reinsurance service is realized.

Fig. 6 illustrates an exemplary configuration of a computing device 600 in which embodiments in accordance with the disclosure may be implemented. Computing device 600 is an example of a hardware device to which the above-described aspects of the disclosure may be applied. Computing device 600 may be any machine configured to perform processing and/or computing. Computing device 600 may be, but is not limited to, a workstation, a server, a desktop computer, a laptop computer, a tablet computer, a Personal Data Assistant (PDA), a smart phone, an in-vehicle computer, or a combination thereof.

As shown in fig. 6, computing device 600 may include one or more elements connected to or in communication with bus 602, possibly via one or more interfaces. The bus 602 may include, but is not limited to, an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, a Peripheral Component Interconnect (PCI) bus, and the like. Computing device 600 may include, for example, one or more processors 604, one or more input devices 606, and one or more output devices 608. The one or more processors 604 may be any kind of processor and may include, but are not limited to, one or more general purpose processors or special purpose processors (such as special purpose processing chips). Input device 606 may be any type of input device capable of inputting information to a computing device and may include, but is not limited to, a mouse, a keyboard, a touch screen, a microphone, and/or a remote controller. Output device 608 may be any type of device capable of presenting information and may include, but is not limited to, a display, speakers, a video/audio output terminal, a vibrator, and/or a printer.

The computing device 600 may also include or be connected to a non-transitory storage device 614, which non-transitory storage device 614 may be any non-transitory and may implement a storage of data, and may include, but is not limited to, a disk drive, an optical storage device, solid state memory, a floppy disk, a flexible disk, a hard disk, a magnetic tape, or any other magnetic medium, a compact disk, or any other optical medium, cache memory, and/or any other memory chip or module, and/or any other medium from which a computer can read data, instructions, and/or code. The computing device 600 may also include Random Access Memory (RAM) 610 and Read Only Memory (ROM) 612. The ROM 612 may store programs, utilities or processes to be executed in a nonvolatile manner. The RAM 610 may provide volatile data storage and stores instructions related to the operation of the computing device 600. Computing device 600 may also include a network/bus interface 616 that couples to a data link 618. The network/bus interface 616 may be any kind of device or system capable of enabling communication with external devices and/or networks and may include, but is not limited to, modems, network cards, infrared communication devices, wireless communication devices, and/or chipsets (such as bluetooth (TM) devices, 1302.11 devices, wiFi devices, wiMax devices, cellular communication facilities, etc.).

Various aspects, embodiments, implementations or features of the foregoing embodiments may be used alone or in any combination. Various aspects of the foregoing embodiments may be implemented by software, hardware, or a combination of hardware and software.

For example, the foregoing embodiments may be embodied as computer readable code on a computer readable medium. The computer readable medium is any data storage device that can store data which can thereafter be read by a computer system. Examples of a computer readable medium include read-only memory, random-access memory, CD-ROMs, DVDs, magnetic tape, hard drives, solid state drives, and optical data storage devices. The computer readable medium can also be distributed over network coupled computer systems so that the computer readable code is stored and executed in a distributed fashion.

For example, the foregoing embodiments may take the form of hardware circuitry. Hardware circuitry may include any combination of combinational logic circuitry, clocked storage devices (such as floppy disks, flip-flops, latches, etc.), finite state machines, memories such as static random access memories or embedded dynamic random access memories, custom designed circuits, programmable logic arrays, etc.

While some specific embodiments of the present disclosure have been shown in detail by way of example, it should be understood by those skilled in the art that the foregoing examples are intended to be illustrative only and are not limiting upon the scope of the present disclosure. It should be appreciated that some of the steps of the foregoing methods need not be performed in the order illustrated, but rather they may be performed simultaneously, in a different order, or in an overlapping manner. In addition, one skilled in the art may add some steps or omit some steps as desired. Some of the components in the foregoing systems need not be arranged as shown, and those skilled in the art may add or omit some components as desired. It will be appreciated by those skilled in the art that the above-described embodiments may be modified without departing from the scope and spirit of the disclosure. The scope of the present disclosure is defined by the appended claims.

In addition, embodiments of the present invention may also include the following examples:

1. a method for reinsurance services involving a cedent party and a cedent party, the method comprising, by the cedent party:

generating policy details based on the branch policy and the policy information, wherein the policy details correspond to the first UUID;

sending a first message to the blockchain system through the blockchain transaction processing interface, the first message including a first UUID to add a first transaction and a second transaction in a first queue of a drop and a second queue of a drop in the blockchain system, respectively,

wherein the progress of the processing of the reinsurance service is represented by the processing status of the first transaction or the second transaction.

2. The method of 1, wherein the cedent and cedent have private first public and private keys, generating policy details comprising:

encrypting the sub-protection strip by using a first public key to generate a second UUID and a hash of the sub-protection strip; and

and generating the insurance policy details based on the second UUID and the hash of the branch insurance strip and the insurance policy information.

3. The method of claim 2, further comprising, by the cedent:

encrypting the policy details using the first public key; and

key elements of the policy details are encrypted using the first private key and the first UUID is generated by a hash algorithm.

4. The method of 3, further comprising, by the cedent:

encrypting the shareholder strip using a first public key and storing the encrypted shareholder strip in a secure server; and/or

Posting the policy details as a record into a blockchain ledger, wherein the first UUID serves as a key for the record and the encrypted policy details serve as a value for the record.

5. The method of 1, wherein the first message includes a first UUID encrypted using the second public key of the drop and a first UUID encrypted using the third public key of the drop, and

the first event includes a first UUID encrypted using a second public key of the cedent, and the second event includes a first UUID encrypted using a third public key of the cedent.

6. The method of 5, further comprising, by the cedent:

reading a first queue of the cedent to determine a status of the reinsurance service, wherein the status comprises one of pending for the cedent or having been processed by the cedent.

7. A method for reinsurance services involving an egress party and an ingress party, the method comprising, by the ingress party:

reading the second queue of the ingress from the blockchain system through a blockchain nexus transaction processing interface,

wherein the first queue of the cedent and the second queue of the cedent are stored in the blockchain system, and the processing progress of the reinsurance service is represented by the processing status of the first transaction in the first queue of the cedent and the second transaction in the second queue of the cedent.

8. The method of 7, further comprising, by the affiliate:

and decrypting the second item in the second queue by using a third private key of the distributor to obtain a first UUID corresponding to the policy details.

9. The method of 8, further comprising, by the affiliate:

obtaining an encrypted underwriting strip from a secure server; and/or

Obtaining a record keyed by the first UUID from a blockchain ledger, the value of the record being encrypted policy details.

10. The method of 9, further comprising, by the ingress:

decrypting the encrypted policy details using a first private key specific to the importer and the exporter to obtain the policy details.

11. The method of claim 9, further comprising, by the affiliate:

the encrypted shard is decrypted using a first private key specific to the importer and the exporter to obtain the shard.

12. The method of 11, further comprising, by the ingress:

in the event that the SCD bar is accepted, sending a second message to the blockchain system through a blockchain transaction processing interface, the second message including a first UUID, to delete the first transaction and the second transaction in a first queue of the egress and a second queue of the ingress in the blockchain system, respectively, and to add a third transaction and a fourth transaction in a third queue of the egress and a fourth queue of the ingress, respectively,

wherein the completion status of the reinsurance service is indicated by the third and fourth items.

13. The method of 12, wherein the second message includes a first UUID encrypted using the second public key of the cedent and a first UUID encrypted using the third public key of the cedent, and

the third transaction includes the first UUID encrypted using the second public key of the cedent, and the fourth transaction includes the first UUID encrypted using the third public key of the cedent.

14. A method for reinsurance services involving a cedent and a cedent, the method comprising, by a blockchain system:

receiving a first message from the cedent over a blockchain transaction processing interface, the first message including a first UUID corresponding to policy details to add a first transaction and a second transaction in a first queue of the cedent and a second queue of the cedent in the blockchain system, respectively,

15. The method of claim 14, further comprising, by the blockchain system:

receiving a second message from the ingress through the blockchain transaction processing interface, the second message including the first UUID, to delete the first transaction and the second transaction in a first queue of the egress and a second queue of the ingress in the blockchain system, respectively, and to add a third transaction and a fourth transaction in a third queue of the egress and a fourth queue of the ingress, respectively,

wherein the completion status of the reinsurance service is indicated by the third and fourth transactions.

16. A first electronic device for reinsurance services, comprising:

one or more processors; and

one or more memories configured to store computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to perform the method of any of claims 1-6.

17. A second electronic device for reinsurance services, comprising:

one or more processors; and

one or more memories configured to store computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to perform the method of any one of claims 7-13.

18. A third electronic device for reinsurance services, comprising:

one or more processors; and

one or more memories configured to store computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to perform the method of any one of claims 14-15.

19. A system for reinsurance business comprising a first electronic device as set forth in claim 16, a second electronic device as set forth in claim 17, and a third electronic device as set forth in claim 18.

Claims

1. A method for reinsurance drop traffic involving a drop party and a drop party, the method comprising, by the drop party:

encrypting a sub-protection strip by using a first public key special for the distributor and the distributor to generate a sub-protection strip UUID and a hash of the sub-protection strip;

storing the encrypted shareholder in the secure server;

generating policy details based on the sub-policy UUID, the hash and policy information, wherein the policy details correspond to the policy UUID; and

sending a first message to the blockchain system through the blockchain transaction processing interface, the first message including a policy UUID to add a first transaction and a second transaction to a first queue of a cedent and a second queue of a cedent in the blockchain system, respectively, wherein the first transaction includes the policy UUID encrypted using a second public key of the cedent and the second transaction includes the policy UUID encrypted using a third public key of the cedent,

wherein the progress of the processing of the reinsurance breakout service is represented by the processing status of the first transaction in the first queue or the second transaction in the second queue, an

Wherein in a case where the SCD is accepted by the ingress, the first transaction in the first queue and the second transaction in the second queue are deleted, respectively, and a third transaction and a fourth transaction are added in a third queue of the egress and a fourth queue of the ingress, respectively, wherein a completion status of the reinsurance egress service is indicated by the third transaction and the fourth transaction.

2. The method of claim 1, wherein the cedent and cedent have the first public key and first private key in common.

3. The method of claim 2, further comprising, by the cedent:

encrypting the policy details using the first public key; and

the key elements of the policy details are encrypted using the first private key and the policy UUID is generated by a hashing algorithm.

4. The method of claim 3, further comprising, by the cedent:

and recording the policy details as a record into a block chain ledger, wherein the policy UUID is used as a key of the record, and the encrypted policy details are used as the value of the record.

5. The method of claim 1, wherein the first message comprises the policy UUID encrypted using a second public key of the cedent and the policy UUID encrypted using a third public key of the cedent.

6. The method of claim 5, further comprising, by the cedent:

reading the first queue of the cedent to determine a status of the reinsurance cedent service, wherein the status comprises one of pending, rejected, or processed by the cedent.

7. A method for reinsurance into a service involving an egress party and an ingress party, the method comprising, by the ingress party:

reading a second queue of the ingress from a blockchain system through a blockchain endpoint transaction processing interface, wherein the first queue of the egress and the second queue of the ingress are stored in the blockchain system, and the processing progress of the reinsurance ingress service is represented by a processing status of a first transaction in the first queue of the egress and a second transaction in the second queue of the ingress, wherein the first transaction comprises an insurance policy UUID encrypted by a second public key of the egress and the second transaction comprises an insurance policy UUID encrypted by a third public key of the ingress;

decrypting the second item in the second queue by using a third private key of the distributor to obtain a policy UUID;

decrypting encrypted policy details corresponding to the policy UUID using a first private key dedicated to the importer and the exporter to obtain the policy details, the policy details generated based on a shareholder strip UUID and a hash and policy information;

obtaining an encrypted sub-security bar corresponding to the sub-security bar UUID from a security server;

decrypting the encrypted shareholder strip using the first private key to obtain the shareholder strip; and

and in the case of accepting the insured strip, sending a second message to the blockchain system through a blockchain transaction processing interface, the second message comprising an insured UUID, so as to delete the first and second transactions in the first queue of the exporter and the second queue of the importer in the blockchain system, respectively, and add a third and fourth transactions in the third queue of the exporter and the fourth queue of the importer, respectively, wherein the completion state of the reinsurance into service is indicated by the third and fourth transactions.

8. The method of claim 7, further comprising, by the ingress:

obtaining a record keyed by the policy UUID from a blockchain ledger, the value of the record being encrypted policy details.

9. The method of claim 7, wherein the second message includes a policy UUID encrypted using the second public key of the cedent and a policy UUID encrypted using the third public key of the cedent, and

the third transaction includes a policy UUID encrypted using the second public key of the cedent, and the fourth transaction includes a policy UUID encrypted using the third public key of the cedent.

10. A method for reinsurance drop traffic involving a drop party and a drop party, the method comprising, by a blockchain system:

receiving a first message from the distributor through a blockchain transaction processing interface, the first message including a policy UUID corresponding to policy details;

adding a first transaction and a second transaction in a first queue of a distributor and a second queue of a distributor in the blockchain system, respectively, wherein the first transaction comprises a policy UUID encrypted by using a second public key of the distributor, and the second transaction comprises a policy UUID encrypted by using a third public key of the distributor;

receiving a second message from the affiliate via the blockchain transaction processing interface, the second message including the policy UUID;

deleting the first transaction and the second transaction in a first queue of the ingress and a first queue of the egress in the block chain system, respectively, and adding a third transaction and a fourth transaction in a third queue of the ingress and a fourth queue of the egress, respectively,

wherein the policy UUID corresponds to policy details generated by the issuer based on a sub-policy UUID and a hash and policy information, the sub-policy UUID is generated by the issuer encrypting a sub-policy using a first public key dedicated to the issuer and the issuer, and the encrypted sub-policy is stored in a secure server, and

wherein a processing progress of the reinsurance drop service is represented by a processing status of the first transaction in the first queue or the second transaction in the second queue, and a completion status of the reinsurance drop service is represented by the third transaction and the fourth transaction.

11. A first electronic device for reinsurance drop traffic, comprising:

one or more processors; and

one or more memories configured to store computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to perform the method of any one of claims 1-6.

12. A second electronic device for reinsurance into a business, comprising:

one or more processors; and

one or more memories configured to store computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to perform the method of any one of claims 7-9.

13. A third electronic device for reinsurance drop traffic, comprising:

one or more processors; and

one or more memories configured to store computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to perform the method of claim 10.

14. A system for reinsurance drop services comprising a first electronic device as claimed in claim 11, a second electronic device as claimed in claim 12 and a third electronic device as claimed in claim 13.