Vehicle insurance buying information multi-party credible verification method and system based on block chain

Abstract

The invention relates to a block chain-based car insurance buying information multi-party credible verification method and system, and relates to the technical field of car insurance buying verification, and the method comprises the steps: receiving a verification request and a car owner authorization instruction; initiating a data calling instruction to a heterogeneous data source node based on the vehicle identifier; receiving an encrypted data packet returned by the heterogeneous data source node, and performing signature verification and decryption in sequence to obtain a vehicle historical data subset; performing multi-round conflict detection and credible consensus verification on the vehicle historical data subset to generate a unique credible data chain, and calculating an initial risk coefficient; and receiving current accident data, performing damage consistency comparative analysis on the current accident data based on the unique credible data link, outputting a risk coefficient update value, and generating a final credible verification report. According to the invention, the problems of risk misjudgment and claim settlement disputes caused by incomplete information and unreliable data due to the dependence of single-party declaration and manual verification in traditional vehicle insurance verification, low verification loss assessment efficiency and high cost are solved.

Description

Technical Field

[0001] This application relates to the field of auto insurance underwriting verification, and in particular to a blockchain-based method and system for multi-party trusted verification of auto insurance underwriting information. Background Technology

[0002] With the increasing demand for standardization and risk management in the auto insurance industry, the credibility, efficiency, and accuracy of information verification in the underwriting and claims processes have become key technical requirements for ensuring the sound operation of insurance companies and protecting the legitimate rights and interests of car owners.

[0003] Currently, traditional auto insurance verification methods rely on unilateral declarations and manual verification, which fail to fully integrate data from multiple parties. This not only makes it difficult to ensure the integrity and authenticity of information, but also easily leads to misjudgments of risk and claims disputes. Furthermore, it results in low efficiency in the underwriting and loss assessment process, significantly increasing the industry's operating costs. Summary of the Invention

[0004] This application provides a blockchain-based method and system for multi-party trusted verification of auto insurance application information, which improves the problems of incomplete and unreliable information, which can easily lead to misjudgment of risks and claims disputes in traditional auto insurance verification, as well as low efficiency and high cost in underwriting and loss assessment, thereby enhancing the credibility and efficiency of auto insurance verification.

[0005] The embodiments of this application disclose the following technical solutions: In a first aspect, embodiments of this application provide a blockchain-based method for multi-party trusted verification of auto insurance underwriting information, the method comprising: Receives a verification request for the target vehicle and an authorization instruction from the vehicle owner sent by the insurance application client, wherein the verification request carries a vehicle identifier; Based on the vehicle identifier, a data retrieval command is sent to multiple heterogeneous data source nodes, wherein the heterogeneous data source nodes include at least an insurance history node, a traffic monitoring node, and a vehicle status node. Receive encrypted data packets returned by the multiple heterogeneous data source nodes, and sequentially verify and decrypt them to obtain the corresponding subset of vehicle historical data; At the blockchain layer, multiple rounds of conflict detection and trusted consensus verification are performed on the subset of historical vehicle data based on consistency rules, and a unique trusted data chain for the target vehicle is generated by fusion, and an initial risk coefficient is calculated. The system receives current accident data uploaded from the claims processing end, performs damage consistency comparison analysis on the current accident data based on the unique trusted data chain, outputs risk coefficient update values, and generates a final trusted verification report.

[0006] Secondly, embodiments of this application provide a blockchain-based multi-party trusted verification system for auto insurance underwriting information, the system comprising: The insurance application request receiving module is used to receive the verification request for the target vehicle and the vehicle owner's authorization instruction sent by the insurance application terminal, wherein the verification request carries the vehicle identifier; The heterogeneous node retrieval module is used to initiate data retrieval instructions to multiple heterogeneous data source nodes based on the vehicle identifier, wherein the heterogeneous data source nodes include at least an insurance history node, a traffic monitoring node, and a vehicle status node. The data signature verification and decryption module is used to receive encrypted data packets returned by the multiple heterogeneous data source nodes, and sequentially verify and decrypt them to obtain the corresponding vehicle historical data subset. The trusted data chain generation module is used at the blockchain layer to perform multi-round conflict detection and trusted consensus verification on the subset of the vehicle's historical data based on consistency rules, merge and generate a unique trusted data chain for the target vehicle, and calculate the initial risk coefficient. The accident data verification module is used to receive the current accident data uploaded by the claims terminal, perform damage consistency comparison analysis on the current accident data based on the unique trusted data chain, output the risk coefficient update value, and generate the final trusted verification report.

[0007] One or more technical solutions provided in this application have at least the following technical effects or advantages: This application proposes a blockchain-based method and system for multi-party trusted verification of auto insurance application information. By receiving application requests and authorizations step-by-step, retrieving data from heterogeneous nodes, verifying signatures and decrypting data, performing multi-round conflict detection and consensus verification, and comparing and analyzing accident data, it achieves trusted verification and risk assessment of information throughout the entire auto insurance application process. First, it receives the target vehicle verification request and owner authorization instruction from the application client, and parses core information based on the vehicle identifier in the request. Then, it initiates differentiated data retrieval instructions to the underwriting history node, traffic supervision node, and vehicle status node, receiving encrypted data packets returned by each node and sequentially completing signature verification, decryption, and format verification to obtain a valid subset of vehicle historical data. Subsequently, at the blockchain layer, it performs multi-round conflict detection on the data subset, eliminating abnormal records through dual verification of time logic and event description, sorting mutually exclusive description nodes based on the degree of corroboration of related events, merging them to generate a unique trusted data chain, and calculating the initial risk coefficient. Finally, it receives the current accident data from the claims client, compares it with the unique trusted data chain for damage consistency, dynamically updates the risk coefficient, and generates a final trusted verification report.

[0008] The technical solution proposed in this application solves the problems of incomplete information, unreliable data, risk misjudgment, frequent claims disputes, and low underwriting efficiency caused by the reliance on unilateral declaration and manual verification in traditional auto insurance verification by leveraging the immutability of blockchain and the multi-party data collaboration mechanism. It avoids the distortion of verification results caused by a single data source and a lack of effective conflict verification, thereby improving the accuracy and efficiency of auto insurance underwriting verification. Attached Figure Description

[0009] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0010] Figure 1 A flowchart illustrating the blockchain-based multi-party trusted verification method for auto insurance underwriting information provided in this application embodiment; Figure 2 This is a schematic diagram of the structure of a blockchain-based multi-party trusted verification system for auto insurance underwriting information provided in an embodiment of this application.

[0011] The components represented by each number in the attached diagram are explained below: Insurance application request receiving module 01, heterogeneous node retrieval module 02, data verification and decryption module 03, trusted data chain generation module 04, and accident data verification module 05. Detailed Implementation

[0012] This application provides a blockchain-based method and system for multi-party trusted verification of auto insurance application information. It addresses the technical problems in existing technologies where traditional auto insurance verification relies on unilateral declarations and manual verification, resulting in incomplete information, unreliable data, and consequently, misjudgments of risks and claims disputes. Furthermore, it also addresses the low efficiency and high cost of underwriting and loss assessment.

[0013] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0014] Example 1, as shown in the appendix Figure 1 As shown, this application provides a blockchain-based method for multi-party trusted verification of auto insurance underwriting information, the method comprising the following steps: S110: Receive a verification request for the target vehicle and an authorization instruction from the vehicle owner sent by the insurance application terminal, wherein the verification request carries a vehicle identifier; In this embodiment of the application, in the business scenario of online car insurance application and efficient claims settlement, in order to ensure the legality, accuracy and security of vehicle information verification, it is necessary to establish a request reception and authorization verification system that is compatible with cross-institutional data sharing, so as to support the orderly conduct of collaborative verification of multiple data sources.

[0015] First, the insurance application side needs to have a compliant information submission function, supporting vehicle owners to initiate verification requests through online channels such as the insurance company's APP and third-party insurance service platforms. The submission interface should clearly mark the mandatory vehicle identification items and the authorization statement clause to ensure that vehicle owners are aware of the authorization scope and data usage purposes, and comply with relevant regulations on personal information protection.

[0016] Exemplarily, the authorization statement needs to clearly inform vehicle owners that after authorization, vehicle historical data will be retrieved from relevant parties such as underwriting institutions and traffic regulatory departments, and will only be used for motor insurance application review and claim verification. The data retention period is the same as the validity period of the insurance contract.

[0017] At the same time, the request receiving side needs to have security protection capabilities, support the processing of millions of concurrent requests, have security mechanisms such as SQL injection prevention and cross-site scripting attack prevention, and use the HTTPS encryption transmission protocol to ensure that request data is not stolen or tampered with during the transmission process. The response delay needs to be controlled within 500ms to avoid affecting timeliness due to slow response.

[0018] Specifically, in the request receiving process, first, the format of the vehicle identification submitted by the insurance application side needs to be verified. For example, the vehicle identification number needs to conform to the coding rule of 17 letters and numbers, and the license plate number needs to match the license plate format standard of the corresponding region. After passing the verification, the complete verification request and authorization instruction are received. If the format does not meet the requirements, an error prompt is immediately returned to guide the user to correct and resubmit.

[0019] In addition, for the vehicle owner's authorization instruction, the validity needs to be confirmed through a dual mechanism of real-name authentication and willingness verification. For example, verify that the person initiating the request is the vehicle owner himself through methods such as SMS verification codes and face recognition, and at the same time verify whether the authorization instruction clearly contains key information such as the authorization object, authorization period, and data retrieval scope to ensure that there is no ambiguity or over-authorization risk in the authorization.

[0020] At the same time, it is also necessary to normalize the storage and identification of the received verification requests and authorization instructions, assign a unique request number to each request, associate metadata such as vehicle identification, the identity information of the insurance application side, and the received timestamp, and establish a request ledger.

[0021] Exemplarily, a vehicle owner initiates a household car insurance verification through the insurance company's APP, submits the license plate number "粤AXXXX", vehicle identification number "LFVXXXXXXXXX123456" and the authorization instruction, generates the request number "HQY20250520001", records the reception time as "2025-05-20 10:30:25", the identity of the insurance application side is "XX Insurance Company APP User ID: 87654321", and encrypts and stores the relevant information in a distributed database, and at the same time synchronizes it to the blockchain deposit node to complete the deposit.

[0022] The encrypted transmission and secure storage mechanisms described above ensure data security, and the standardized verification process ensures that requests are compliant and valid, laying the data foundation for subsequent data retrieval from heterogeneous data sources such as historical data nodes and traffic monitoring nodes.

[0023] S120: Based on the vehicle identifier, initiate a data retrieval command to multiple heterogeneous data source nodes, wherein the heterogeneous data source nodes include at least an insurance history node, a traffic monitoring node, and a vehicle status node; In this embodiment of the application, in order to obtain full-dimensional historical data of the target vehicle and ensure the reliability of the verification results, it is necessary to construct differentiated instructions and standardize the initiation process in combination with vehicle identification resolution information to achieve effective data retrieval and secure transmission.

[0024] First, the vehicle identification is analyzed in depth to determine the specific type of the target vehicle and its first registration time from the coded information contained in the identification. Based on this, differentiated data retrieval instructions are designed for different heterogeneous data source nodes to ensure that the instructions match the data storage range of each node.

[0025] At the same time, before sending differentiated data retrieval instructions to each node, the vehicle owner's authorization instructions must be strictly verified to confirm the validity of the authorization and whether the scope of the authorization covers all the content to be retrieved, so as to prevent the acquisition of data beyond the scope of authorization.

[0026] Furthermore, once the verification is successful, the verification result will be attached to the corresponding data retrieval instruction as a compliance basis for each node to respond to data retrieval.

[0027] After each heterogeneous data source node receives the corresponding retrieval instruction, it retrieves data records that meet the instruction requirements from the local database and performs standardized format conversion on the retrieved raw data to ensure that the data structure returned by different nodes is consistent, thus facilitating subsequent data processing.

[0028] Finally, after the data format conversion is completed, each party uses its own private key to digitally sign the data, then encrypts it to form an encrypted data packet, which is then sent back to the initiating party to comprehensively ensure the authenticity, integrity and security of the data during transmission.

[0029] Step S120 in the method provided in this application embodiment includes: The vehicle identifier is parsed to determine the vehicle type and initial registration time of the target vehicle; Based on the vehicle type and the first registration time, construct differentiated data retrieval instructions to be sent to the insurance history node, the traffic supervision node, and the vehicle status node, respectively; Among them, the data retrieval instructions sent to the underwriting history node include the full range of historical claims and insurance periods; the data retrieval instructions sent to the traffic supervision node include the full range of vehicle violation and accident records; and the data retrieval instructions sent to the vehicle status node include requests for mileage, maintenance, and key component status records in specific dimensions. Before sending the differentiated data retrieval instruction, verify the validity and scope of the vehicle owner's authorization instruction, and attach the verification result to the differentiated data retrieval instruction; Each node retrieves data records that meet the criteria from its local database according to the received instructions. After performing a standardized format conversion on the retrieval results, it signs and encrypts the data using its own private key, and then returns an encrypted data packet.

[0030] First, the vehicle identification is analyzed in depth. Specifically, the vehicle identification contains the core identity information of the target vehicle. By using the Vehicle Identification Number (VIN) parsing algorithm, key fields are extracted from the vehicle identification to determine the specific type of the target vehicle, such as passenger cars, commercial trucks, new energy vehicles, and other different categories.

[0031] At the same time, by cross-checking with the official database of the vehicle management department and by reverse-engineering the production year information in the VIN code, the first registration time of the target vehicle can be obtained to clarify the starting point of vehicle use and provide a basis for defining the time range of subsequent data retrieval.

[0032] Furthermore, after clarifying the vehicle type and initial registration time, differentiated data retrieval instructions are constructed based on the functional positioning of multiple heterogeneous data source nodes. These heterogeneous data source nodes include at least an insurance history node, a traffic monitoring node, and a vehicle status node. Each node is responsible for storing and providing different historical information about the vehicle, in order to obtain comprehensive historical data of the target vehicle.

[0033] Specifically, the core function of the underwriting history node is to provide the target vehicle's continuous historical insurance policies, claims records, damage assessment reports, and repair data. Therefore, the retrieval instructions for the underwriting history node must include the full range of historical claims and insurance periods to ensure complete coverage of all insurance and claims-related data from the vehicle's first registration to the present, without omitting any key records.

[0034] In addition, traffic monitoring nodes are responsible for providing vehicle registration, transfer, annual inspection status, and road traffic accident liability determination certificates. The corresponding retrieval instructions must cover the entire time range of vehicle violations and accident records, and comprehensively collect information such as vehicle violations and accident liability determinations during road driving.

[0035] Meanwhile, the vehicle status node is used to provide data related to the vehicle's technical status, including mileage, maintenance and key component status records in specific dimensions. The corresponding retrieval instructions must explicitly point to the above core data dimensions to ensure that the acquired data can accurately reflect the actual technical condition of the vehicle.

[0036] Before sending differentiated data retrieval instructions to each node, the validity and scope of the vehicle owner's authorization instructions must be verified to ensure that the data retrieval behavior is compliant, avoid unauthorized access to vehicle-related information, and protect the vehicle owner's information security and legitimate rights and interests.

[0037] Specifically, validity verification is confirmed through methods such as vehicle owner real-name authentication information and command signature to ensure that the authorization command was indeed initiated by the vehicle owner, preventing others from impersonating them to retrieve data. In addition, authorization scope verification needs to check the authorized object, data retrieval scope, and purpose clearly stated in the command to ensure that the data retrieval does not exceed the boundaries of the vehicle owner's authorization and complies with relevant personal information protection regulations.

[0038] Once the verification is successful, the verification results will be appended to the corresponding differentiated data retrieval instruction in a standardized format, serving as the legal and compliant basis for each node to respond to data retrieval and ensuring the legitimacy of the data retrieval behavior.

[0039] Furthermore, upon receiving the corresponding data retrieval command, each heterogeneous data source node initiates its local database retrieval process. Specifically, each node searches its dedicated database based on the specified time range, data type, and other conditions outlined in the command, selecting data records that meet the requirements.

[0040] For example, the underwriting history node retrieves all scanned copies of insurance policies, claim forms, original damage assessment reports, and repair item lists for the target vehicle within the specified timeframe based on the full historical claims and insurance period range specified in the instruction. The traffic monitoring node extracts relevant documents such as traffic violation penalty decisions, accident liability determinations, and annual inspection certificates based on the full time range of vehicle violation and accident records. The vehicle status node retrieves data such as the vehicle's cumulative mileage records, past repair records, and inspection reports for key components as required by the instruction.

[0041] After the search is completed, each node needs to perform a standardized format conversion on the search results. Because different nodes have different database storage formats, to facilitate unified data processing and analysis, the raw data in different formats needs to be converted into a preset standardized format to ensure consistency in field definitions, data types, encoding rules, etc.

[0042] For example, the claims records stored at the underwriting history node are in XML format, the violation records at the traffic monitoring node are in JSON format, and the maintenance data at the vehicle status node are in tabular format. Each node uses a format conversion tool to uniformly map core fields such as claim amount, violation type, and repair part into string identifiers, numerical parameters, and standard codes to ensure that all data is presented in a unified structure.

[0043] After the format conversion is complete, each node digitally signs the converted data using its own private key. The digital signature proves the authenticity and integrity of the data's origin, preventing tampering during transmission. Following signing, a high-strength encryption algorithm is used to encrypt the data, generating an encrypted data packet. This encryption effectively ensures data security during network transmission, preventing theft or unauthorized access.

[0044] For example, the standardized data is symmetrically encrypted using the AES-256 encryption algorithm, and the encryption key is protected by the RSA asymmetric encryption algorithm. This dual encryption mechanism ensures that even if the data is intercepted during cross-node transmission, it cannot be cracked to obtain valid information, thereby protecting the transmission security of vehicle-related sensitive data.

[0045] Finally, each node sends the generated encrypted data packet back to the data retrieval initiator via a secure communication link to ensure that the data can be transmitted quickly and stably, providing complete, secure and standardized basic data support for subsequent signature verification, decryption and data fusion processing.

[0046] S130: Receive the encrypted data packets returned by the multiple heterogeneous data source nodes, and sequentially verify and decrypt them to obtain the corresponding vehicle historical data subset; In this embodiment of the application, in order to ensure that the acquired vehicle historical data is authentic, complete and in a uniform format, the encrypted data packets need to be processed one by one according to the standard procedure to ensure the reliability and availability of the data.

[0047] First, the encrypted data packets are processed in an orderly manner according to the preset node priority in the data retrieval instruction to avoid affecting the data integration efficiency due to disordered processing order.

[0048] Specifically, for a single encrypted data packet, the registered public key of the corresponding node is first used to verify the digital signature attached to the data. The signature verification confirms that the data comes from a legitimate node and has not been tampered with during transmission, thus ensuring the authenticity of the data source and the integrity of the transmission.

[0049] After the signature verification is successful, the encrypted data packet content is decrypted using the decryption key, restoring the encrypted data to the original response data in a standardized format, in preparation for subsequent data parsing and verification.

[0050] Furthermore, the restored original response data is parsed to extract key information such as record entries, timestamps, data fields, and node identity information. At the same time, the data format is strictly verified to ensure that it conforms to the preset standardization conventions and that the data structure is standardized and uniform.

[0051] Furthermore, the original response data, after being verified, decrypted, and format-checked, will be clearly marked with the identity of its corresponding data source node. After establishing the mapping relationship between data and nodes, the data will be temporarily stored to facilitate subsequent tracing of the data source.

[0052] Finally, all returned encrypted data packets are processed sequentially according to node priority, and the valid data corresponding to each node is aggregated to form a subset of vehicle historical data corresponding to multiple heterogeneous data source nodes, providing data support for subsequent data fusion and verification at the blockchain layer.

[0053] Step S130 in the method provided in this application embodiment includes: The encrypted data packets are processed one by one according to the preset node priority of the data retrieval instruction; For a single encrypted data packet, the digital signature is verified using the registered public key of the corresponding node to confirm the authenticity of the data source and the integrity of the transmission; After the signature verification is successful, the data content is decrypted using the preset decryption key to restore the original response data in a standardized format; Parse the record entries, timestamps, data fields, and node identity information in the original response data, and verify whether the data format conforms to the standardization convention; The original response data that has passed signature verification, decryption and format validation will be marked as a subset of valid vehicle historical data from the corresponding node, and then temporarily stored after establishing a mapping relationship with the node identity. All returned encrypted data packets are traversed and processed to obtain the vehicle historical data subsets corresponding to the multiple heterogeneous data source nodes.

[0054] Specifically, the encrypted data packets are first processed according to the preset node priorities in the data retrieval instructions. The node priority setting needs to be determined based on the importance of the data to the vehicle insurance verification and the stability of the data. For example, the underwriting history node is set as the highest priority because the insurance claims data provided by this node is directly related to the core risk assessment. The traffic supervision node is the second highest priority, and the vehicle status node is the third highest priority. Processing in this order can ensure that key data is parsed first, improving the overall process efficiency.

[0055] Furthermore, for each individual encrypted data packet, a digital signature verification operation is performed. Specifically, each heterogeneous data source node submits its unique public key during registration, which is stored in the system. During processing, the corresponding node's registered public key is used to decrypt and verify the digital signature attached to the data packet. If the verification result shows that the signature matches the node's public key, it indicates that the data originates from a legitimate node and has not been tampered with during transmission, ensuring the authenticity of the data source and the integrity of the transmission.

[0056] Conversely, if signature verification fails, the data packet is marked as invalid and further processing is rejected to prevent untrusted data from entering the system.

[0057] After signature verification is successful, the encrypted data packet content is decrypted using a pre-set decryption key. The decryption key employs a management mechanism of designated personnel for safekeeping and periodic replacement to ensure key security. The decryption process must be executed within an encrypted computing environment to prevent key leakage. After decryption, the original response data is restored to a standardized format. This original response data has undergone format conversion at the data source node and possesses unified field definitions and structural specifications.

[0058] Furthermore, the restored original response data is comprehensively analyzed to extract record entries (such as insurance records, violation records, repair records, etc.), timestamps (the specific time the record was generated), data fields (such as core information such as the damaged part, claim amount, mileage, etc.), and node identity information, thereby clarifying the core content and source of the data.

[0059] At the same time, it verifies whether the data format conforms to the preset standardization conventions, including whether the number of fields is complete, whether the data types match, and whether the encoding rules are consistent. For example, it verifies whether the timestamp is in the format "YYYY-MM-DD HH:MM:SS" and whether the numeric fields meet the value range requirements, ensuring a unified data structure and avoiding the impact of format differences on subsequent data fusion.

[0060] Furthermore, the original response data, after verification, decryption, and format validation, will be clearly marked with the identity of its corresponding data source node. For example, identifiers such as "Insurance History Node - XX Institution" and "Traffic Supervision Node - XX Traffic Management Department" will be added to the data header. At the same time, a mapping relationship between data and nodes will be established, recording the unique number, name, and other information of the data source node. The data will then be temporarily stored in a distributed cache. The cached data will be stored in an encrypted manner to prevent data leakage and to support fast querying and tracing.

[0061] For example, encrypted data packets returned by a certain underwriting history node are prioritized and processed first. The signature is verified using the node's registered public key. After decryption, the original response data containing insurance records from 2020 to 2024 and two claim records is obtained. After parsing, fields such as timestamp, claim amount, and injury location of each record are extracted. The verification format conforms to the standardized agreement. Then, the data is marked as originating from "underwriting history node - Insurance Company A" and a mapping relationship is established. It is then temporarily stored in the cache.

[0062] Furthermore, after processing all returned encrypted data packets sequentially according to node priority, all valid data in the cache is traversed and summarized according to data source nodes, ultimately forming vehicle historical data subsets corresponding to the underwriting history node, traffic supervision node, and vehicle status node, respectively. The data in each subset undergoes multi-layer verification to ensure authenticity, completeness, and standardization, providing a reliable data foundation for subsequent multi-round conflict detection and trusted consensus verification at the blockchain layer.

[0063] S140: At the blockchain layer, based on the consistency rules, multiple rounds of conflict detection and trusted consensus verification are performed on the subset of the vehicle's historical data, which are then merged to generate a unique trusted data chain for the target vehicle, and an initial risk coefficient is calculated. In this embodiment of the application, in order to eliminate contradictions and redundancies in multi-source data, form a true and complete record of vehicle historical data, and accurately assess insurance risks, it is necessary to carry out data verification and risk quantification calculations in accordance with standard procedures to ensure the scientific nature and reliability of underwriting decisions.

[0064] First, the vehicle history data subsets from each node are aligned and sorted according to standardized timestamps to construct a parallel record sequence ordered by time, providing an ordered data foundation for subsequent conflict detection. Based on the time order, the first round of conflict detection is performed on the parallel record sequence, meticulously identifying and removing isolated event records and records of sudden state changes to ensure the temporal continuity and rationality of the data.

[0065] Furthermore, for records that pass the first round of conflict detection, a second round of conflict detection is conducted based on the event descriptions to identify and mark mutually exclusive descriptions, clarifying the contradictions in the data. For the marked mutually exclusive descriptions, a search is conducted in the parallel record sequence to determine whether there are related event records that can be independently verified by multiple nodes without contradictions. Based on this, the source nodes of the mutually exclusive descriptions are ranked by credibility.

[0066] Furthermore, valid records that have passed multiple rounds of conflict detection are integrated, and high-confidence versions of mutually exclusive descriptions are adopted according to their credibility. These are then fused along the timeline to generate a structured, unique, and credible data chain to ensure the authenticity and integrity of the data.

[0067] After obtaining a unique and trusted data chain, the total number of events recorded within it is counted as the cumulative event record frequency. The ratio of this frequency to the difference between the earliest timestamp and the current time in the data chain is calculated to obtain the event frequency. Furthermore, the total number of damage site identifiers appearing in all event records is extracted, and its ratio to the cumulative event record frequency is calculated as an indicator of damage severity. Simultaneously, the difference between the vehicle's initial registration time and the current time is calculated to determine the vehicle's service life.

[0068] Furthermore, based on vehicle age, event frequency, and damage severity indicators, a weighted calculation is performed to obtain an initial risk coefficient, providing a quantitative basis for risk assessment of auto insurance.

[0069] Step S140 in the method provided in this application embodiment includes: The vehicle history data subsets from each node are aligned and sorted according to standardized timestamps to generate a parallel record sequence ordered by time. The first round of conflict detection is performed on the parallel record sequence based on the time order to identify and remove isolated event records and state change records. A second round of conflict detection is performed on the records that passed the first round of conflict detection based on the event description, to identify and mark mutually exclusive descriptions; For descriptions marked as mutually exclusive, search the parallel record sequence to find whether there are related event records that can be independently verified by multiple nodes and are consistent with each other; The source nodes of the mutually exclusive descriptions are ranked by credibility based on the degree of corroboration of the associated event records; Records that have passed multiple rounds of conflict detection are integrated, and the high-confidence versions in the mutually exclusive descriptions are adopted according to the confidence level. The data are then fused along the timeline to generate a structured, unique, and trusted data chain.

[0070] The total number of events recorded from the unique trusted data chain is used as the cumulative event record frequency. The event frequency is obtained by calculating the ratio between the cumulative event record frequency and the difference between the earliest timestamp and the current time recorded in the unique trusted data chain; Extract the total number of damage site identifiers appearing in all event records from the unique trusted data chain; The ratio between the total number of identified damaged sites and the cumulative frequency of event records is calculated as an indicator of the degree of damage. The vehicle's service life is obtained by calculating the difference between the initial registration time corresponding to the vehicle identifier and the current time. The initial risk coefficient is obtained by weighted calculation based on the vehicle's service life, the frequency of the event, and the damage severity index.

[0071] Specifically, the process begins by aggregating subsets of vehicle history data returned from underwriting history nodes, traffic monitoring nodes, and vehicle status nodes. These subsets are then globally aligned and ordered according to a pre-defined standardized timestamp format, generating a parallel record sequence with time as the sole axis. The standardized timestamp format must be uniformly "YYYY-MM-DD HH:MM:SS" to ensure comparability of the time dimension of data from different nodes. This arrangement ensures all records are sequentially arranged according to the order in which events occurred, thus constructing a data framework for conflict detection based on time sequence and event correlation.

[0072] Furthermore, based on the time sequence, the first round of conflict detection is performed on the parallel record sequence, focusing on identifying abnormal records that violate time logic and data correlation, in order to eliminate invalid, contradictory, and low-reliability data, and ensure that the retained records conform to common sense about vehicle use and data correlation rules.

[0073] The method provided in this application embodiment performs a first round of conflict detection on the parallel record sequence based on time order, identifying and removing isolated event records and state change records, including: Scan the parallel record sequence to identify all event records whose timestamps are earlier than the initial registration time, and mark them as time conflict records accordingly; The timestamps and event types of two adjacent records in the parallel record sequence are checked sequentially to identify whether there is a record whose timestamp is earlier than the timestamp of the previous record, or a record combination in which the cumulative mileage indicated by the vehicle status record shows a non-unidirectional increase. Examine the parallel record sequence to identify isolated event records that are provided by a single node and are not associated with any other event records or status records from any node in adjacent time periods before or after the time. Examine the repair records provided by the vehicle status node and the claims records provided by the insurance history node to identify combinations of records that are adjacent or overlapping in time, but whose descriptions of the vehicle damage parts do not overlap. The abnormal records in the marked time conflict records, non-unidirectional growth record combinations, isolated event records, and abnormal description records in record combinations that do not have an intersection of damage sites are removed from the parallel record sequence.

[0074] Specifically, a comprehensive scan of the parallel record sequence is first conducted to verify the logical relationship between the timestamp of each record and the vehicle's initial registration time. The initial registration time is the starting point of the vehicle's lifecycle; any event record earlier than this time is objectively impossible. For example, if a vehicle's initial registration time is May 10, 2020, and a certain accident record's timestamp is March 15, 2019, it is directly marked as a time conflict record. Such records do not require further verification and are directly included in the scope of removal.

[0075] Furthermore, the timestamps and event types of adjacent records in the parallel record sequence are checked one by one in sequence, with a focus on investigating two types of time logic anomalies. One type is the time reversal anomaly, where the timestamp of the later record is earlier than that of the earlier record. For example, if the time of the earlier record is January 20, 2023, but the time of the later related record is January 18, 2023, it violates the chronological order of events.

[0076] In addition, another type is the abnormal non-unidirectional increase of the cumulative mileage. The cumulative mileage of a vehicle will continue to increase with use. If the mileage drops in the vehicle status record, for example, the previous record shows a cumulative mileage of 60,000 kilometers, but the next record shows 58,000 kilometers, such a combination of records that does not conform to the vehicle's usage pattern needs to be accurately identified as abnormal records.

[0077] Furthermore, an investigation is conducted into the correlation of records to identify isolated event records provided by a single node. Such records lack any correlation with other event records or status records from other nodes or even the same node within a reasonable timeframe preceding and following their time, thus lacking necessary supporting evidence and having extremely low credibility. For example, a node might provide a repair record from July 2022, but if no claims records from any underwriting history node, accident records from any traffic monitoring node, or other relevant status records match it during the entire period from June to August 2022, this repair record would be determined to be an isolated event record.

[0078] Simultaneously, cross-validation is performed on repair records provided by vehicle status nodes and claim records provided by insurance history nodes. If the times of the two types of records are adjacent or overlap, it indicates that they may correspond to the same vehicle event, and in this case, the descriptions of the damaged parts in their records need to be compared. If the descriptions of the damaged parts have no overlap whatsoever—for example, the repair record shows that the transmission was repaired, but the claim record from the same period records damage to the front and rear windshields—the two are logically inconsistent and can be identified as an abnormal combination of description records, requiring the abnormal records to be marked.

[0079] Finally, all marked time conflict records, abnormal records in non-unidirectional growth record combinations, isolated event records, and abnormal description records in record combinations where the damage sites do not overlap are uniformly and completely removed from the parallel record sequence.

[0080] By conducting targeted screening and elimination through the above steps, various invalid, contradictory, and low-quality data can be effectively filtered out, ensuring that the retained records have basic temporal logical consistency, data correlation, and rationality.

[0081] Furthermore, after the abnormal records are removed in the first round of conflict detection, a second round of conflict detection based on event description is conducted to thoroughly investigate mutually exclusive contradictions in the core information of events within the same time period.

[0082] The method provided in this application embodiment performs a second round of conflict detection on records that have passed the first round of conflict detection based on event descriptions, identifying and marking mutually exclusive descriptions, including: In the parallel record sequence, record combinations with overlapping timestamps or those within the same consecutive time period are selected; For the record combination, check whether the records from different nodes simultaneously contain accident type records and maintenance type records; If accident type records and maintenance type records exist simultaneously within the same time period, then for the set of damaged parts described in the accident type records and the set of maintenance parts described in the maintenance type records, identify whether there is a record combination in which the set of damaged parts and the set of maintenance parts have no intersection at all; Examine repair type records from different nodes to identify combinations of records that are consecutive in time and target the same or adjacent vehicle parts, but whose repair conclusions are completely opposite. Groups of records where the set of damaged locations and the set of repaired locations do not intersect, and groups of records where the repair conclusions are completely opposite, are marked as mutually exclusive descriptions. Specifically, in the first round of conflict detection, parallel record sequences that pass the initial conflict detection are first filtered out based on time dimension, identifying record combinations with overlapping timestamps or those falling within the same consecutive time period. These record combinations, due to their strong temporal correlation, pose a risk of conflicting descriptions of the same vehicle event and are the core targets of the second round of conflict detection. For example, record combinations with all timestamps concentrated between March 1st and March 10th, 2023, are selected for focused investigation of inconsistencies in event descriptions within this time period.

[0083] Furthermore, for each selected set of records, first check if it contains both accident type records and repair type records. Accidents and repairs are usually causally related; the two types of records within the same time period should point to related changes in vehicle condition. If both exist simultaneously, the consistency of core information needs further verification. The focus is on comparing the set of damaged parts described in the accident type records with the set of repaired parts described in the repair type records to identify any completely overlapping situations. For example, if an accident record states that the front bumper and left headlight were damaged, while the repair records from the same period only record repairs to the right rear door and trunk lid, the sets of parts in the two types of records have no overlap, indicating mutually exclusive descriptions that need to be marked promptly.

[0084] Simultaneously, conflict resolution is conducted on repair type records from different nodes. Focusing on repair records that are consecutive in time, particular attention is paid to records addressing the same or adjacent vehicle parts, identifying combinations of records with completely contradictory repair conclusions. For example, one node's record might state "Engine block crack has been repaired, and the vehicle can be used normally," while another adjacent node's record might state "Engine block crack has not been treated, posing a safety hazard." Such descriptions of the same part with diametrically opposed conclusions violate the logic of event progression and are mutually exclusive descriptions, requiring clear identification and marking.

[0085] Through the targeted investigation steps described above, accident and repair records with no overlap in damaged areas, and repair records with completely contradictory repair conclusions, are uniformly marked as mutually exclusive descriptions. This process accurately identifies hidden logical contradictions in the data, ensuring that the final integrated vehicle data chain is consistent and reasonable in its event descriptions.

[0086] Furthermore, for descriptions marked as mutually exclusive, a comprehensive search of related event records is conducted. Specifically, throughout the entire parallel record sequence, related event records that are associated with the mutually exclusive description and can be independently verified by multiple nodes without any contradictions are systematically investigated. These related event records must be directly related to the mutually exclusive description in terms of vehicle location, time frame, or event context. For example, if the mutually exclusive description revolves around a vehicle collision accident in May 2023, relevant data such as insurance records, damage assessment records, and road surveillance records before and after that period will be retrieved to ensure that the search scope covers the complete context of the event.

[0087] Furthermore, based on the degree of corroboration of the related event records, the source nodes that provide mutually exclusive descriptions are ranked by credibility to clarify the credibility level of data from different nodes.

[0088] The method provided in this application embodiment, which ranks the source nodes of mutually exclusive descriptions based on the degree of corroboration of the associated event records, includes: The number of records in the associated event records that contain the same vehicle part identifier as the mutually exclusive description is counted as the number of direct verification records; The number of heterogeneous data source nodes that provide the associated event records is counted as an independent verification of breadth; Calculate the absolute value of the difference between the timestamps of all the associated event records and the timestamps of the mutually exclusive descriptions, and take the average of the absolute values ​​as the average time proximity. The sorting criteria are constructed based on the number of direct corroborations, the breadth of independent corroborations, and the average temporal proximity. For each source node that provides the mutually exclusive description, a comprehensive comparison is performed based on the corresponding sorting criteria. The credibility ranking is generated according to the priority order of the number of direct corroborations from most to least, the breadth of independent corroborations from largest to smallest, and the average temporal proximity from smallest to largest.

[0089] Specifically, the number of records in the related event logs that contain the same vehicle part identifier as the mutually exclusive description is counted, which is taken as the number of direct corroborations. The number of direct corroborations reflects the correlation between the related events and the mutually exclusive descriptions on the core object. The more records there are, the more sufficient the direct evidence for the core content of the mutually exclusive descriptions is, and the higher the credibility.

[0090] For example, the mutually exclusive description revolves around the damage to the right rear wheel suspension. If there are 6 records in the associated event log that explicitly mention the right rear wheel suspension, compared to only 2 records that mention it, the former has stronger direct corroboration and the corresponding node has a higher credibility ranking.

[0091] Furthermore, the number of heterogeneous data source nodes providing related event records is counted as the breadth of independent verification. These heterogeneous data source nodes come from different business scenarios and have different information collection channels and verification mechanisms. The more nodes that provide independent verification, the more convincing the credibility of the core content of the mutually exclusive description is, indicating that it has received cross-domain and multi-channel cross-verification.

[0092] For example, the associated event records come from three heterogeneous nodes: traffic monitoring node, insurance history node, and vehicle status node. Compared to the case where the records come from only a single vehicle status node, the former has a wider range of independent verifications and the corresponding nodes have a higher sorting priority.

[0093] Furthermore, the average temporal proximity is calculated. Specifically, firstly, the absolute value of the difference between the timestamp of each related event record and the timestamp of the mutually exclusive description is calculated, and then the average of all absolute values ​​is taken. Temporal proximity reflects the correlation between related events and mutually exclusive descriptions in the time dimension. The smaller the average temporal proximity, the closer the time of occurrence of the related event and the mutually exclusive description, the stronger the timeliness of the verification of the mutually exclusive description, and the higher the corroborating value.

[0094] For example, if the average absolute value of the time difference between the associated event record and the mutual exclusion description corresponding to a certain node is 3 days, and the average time difference of another node is 15 days, then the former has better average time proximity and is more advantageous in sorting.

[0095] After obtaining three metrics—direct corroboration count, independent corroboration breadth, and average temporal proximity—a ranking criterion is constructed based on these three dimensions. For each source node providing a mutually exclusive description, a ranking tuple containing three elements is generated: (direct corroboration count, independent corroboration breadth, -average temporal proximity). The average temporal proximity is negatively assigned to ensure that nodes with lower temporal proximity have a larger third element in their corresponding tuples, thus guaranteeing that nodes are prioritized based on their average temporal proximity from smallest to largest during ranking.

[0096] Furthermore, all source nodes are sorted according to the tuple comparison rules. First, the number of direct corroborations is compared, and they are arranged in descending order. If the number of direct corroborations is equal, the breadth of independent corroborations is compared, and they are also arranged in descending order. If the first two elements are equal, the third element, the average temporal proximity, is compared, and they are arranged in descending order.

[0097] For example, if the sorted tuple for node A is (5, 3, -2), the sorted tuple for node B is (5, 2, -1), and the sorted tuple for node C is (4, 3, -1), then the sorting result is node A > node B > node C. Through the multi-dimensional and progressive comparison method described above, an objective credibility ranking is generated, providing a clear decision-making basis for subsequent selection of high-credibility descriptions and resolution of data conflicts.

[0098] After completing the credibility ranking, the data is integrated and fused by combining the valid records that have passed multiple rounds of conflict detection. Then, the high-credibility version in the mutual exclusion description is adopted, contradictory information is discarded, and all valid records are linked together along the timeline to form a structured and uniquely trusted data chain. Specifically, all records that passed the first and second rounds of conflict detection are systematically integrated. For records without mutually exclusive descriptions, their original core information is retained, including key content such as event type, occurrence time, involved locations, and handling results. For combinations of records marked as mutually exclusive, the descriptions provided by higher-ranked, more reliable nodes are prioritized based on the generated credibility ranking results, while contradictory descriptions with lower credibility are discarded. For example, if a traffic monitoring node and a third-party node describe the damage locations of the same accident as mutually exclusively, and the traffic monitoring node has a higher priority after credibility ranking, then the damage location information recorded by the traffic monitoring node is adopted.

[0099] Furthermore, all the verified valid records are re-chained according to the chronological order of standardized timestamps to construct a structured data chain that progresses along a timeline. During the fusion process, the associated metadata of each record is supplemented and improved, including data source node identifiers, credibility ratings, and supporting record indexes, to ensure the traceability of the data chain.

[0100] Simultaneously, the data chain undergoes logical consistency verification to ensure that the event development of adjacent records conforms to vehicle usage patterns. For example, a maintenance record should be followed by a corresponding normal vehicle status record to avoid logical gaps, ultimately generating a unique and reliable data chain that fully reflects all key events and status changes of the vehicle from its initial registration to the present.

[0101] After obtaining a unique and trusted data chain, an initial risk coefficient is quantitatively calculated. Specifically, the cumulative event record frequency is first counted by comprehensively scanning all records in the unique and trusted data chain and counting the total number of related events such as accidents, repairs, and violations. This indicator directly reflects the total number of historical events occurring in the vehicle.

[0102] Secondly, the event frequency is calculated by dividing the cumulative event record frequency by the difference between the earliest timestamp in the data chain and the current time. For example, if the earliest record time is June 2018 and the current time is June 2023, the time difference is 5 years, and the cumulative event record frequency is 8 times, then the event frequency is 1.6 times / year. This indicator reflects the density of vehicle events.

[0103] Next, the total number of damage location identifiers is extracted. From all event records, the mentioned vehicle damage locations are filtered out, and duplicate identifiers for the same location are removed. The total number of unique damage location identifiers is then calculated. For example, if the event records mention the front bumper, left headlight, front bumper, and right rearview mirror multiple times, after deduplication, only three unique identifiers are retained: front bumper, left headlight, and right rearview mirror. The total number of corresponding damage location identifiers is 3.

[0104] Next, the damage severity index is calculated by dividing the total number of damaged site markers by the cumulative event recording frequency. For example, if the total number of damaged site markers is 6 and the cumulative event recording frequency is 8, then the damage severity index is 0.75, reflecting the average coverage of vehicle damage per event.

[0105] In addition, determining the vehicle's service life involves retrieving the initial registration date from the vehicle identification number and calculating the difference between that date and the current date. For example, if the initial registration date was March 2019 and the current date is March 2023, then the vehicle's service life is 4 years. This indicator is an important basis for assessing vehicle aging and potential risks.

[0106] Furthermore, based on the extracted vehicle age, event frequency, and damage severity indicators, an initial risk coefficient is obtained through weighted calculation. Specifically, the weighted fusion calculation formula can be expressed as "Initial Risk Coefficient = α × Event Frequency + β × Damage Severity Indicator - γ × ln(Vehicle Age + 1)", where α, β, and γ are the positive weight coefficients corresponding to each parameter. The weight values ​​need to be comprehensively determined by combining historical claims data from the auto insurance industry, vehicle safety performance statistics, and risk assessment standards. For example, α can be set to 0.4, β to 0.5, and γ to 0.1, in order to balance the impact of each indicator on risk assessment.

[0107] In addition, the natural logarithm function is introduced to make the impact of vehicle age on risk coefficient show a reasonable decreasing trend, which is in line with the actual law that the risk increases rapidly in the early stage of vehicle use and tends to level off in the later stage.

[0108] For example, if a vehicle has an incident frequency of 0.5 times / year, a damage severity index of 0.6, and a vehicle service life of 3 years, the initial risk coefficient can be calculated by substituting the values ​​into the formula: 0.4×0.5+0.5×0.6-0.1×ln(3+1)=0.2+0.3-0.1×1.386≈0.36. This quantitative result provides a numerical basis for judging the risk level during the underwriting process.

[0109] Finally, after the initial risk coefficient is calculated, it is stored together with the unique trusted data chain on the blockchain node. The immutability of the blockchain ensures data security and traceability, so that when the claims department uploads the current accident data, it can quickly retrieve complete and authentic vehicle historical data and the initial risk coefficient, providing verifiable data support for damage consistency comparison analysis, risk coefficient updates and the generation of the final credible verification report.

[0110] S150: Receive the current accident data uploaded by the claims terminal, perform damage consistency comparison analysis on the current accident data based on the unique trusted data chain, output the risk coefficient update value, and generate the final trusted verification report.

[0111] In this embodiment of the application, in order to avoid misjudgment of risk due to inconsistency between accident data and historical records, it is necessary to conduct damage consistency comparison analysis on the current accident data based on a unique and trusted data chain, so as to output accurate risk coefficient update values ​​and form a credible verification report.

[0112] First, the current accident data is analyzed to extract the set of current injury sites and the current event type, clarifying the core information dimensions of this accident. Next, from the unique trusted data chain, all historical injury records within a preset time window that match the current event type are extracted. These records are then aggregated to obtain the historical injury site set, providing a reference basis for consistency comparison.

[0113] Furthermore, the number of injury sites in the current injury site set that did not appear in the historical injury site set is calculated as the number of newly added abnormal sites, in order to quantify the degree of difference between the current and historical injury records. Then, by calculating the ratio of the number of newly added abnormal sites to the size of the current injury site set, the injury abnormality ratio is obtained, which intuitively reflects the proportion of differences.

[0114] The risk sensitivity coefficient is determined based on the initial risk coefficient. The higher the initial risk coefficient, the larger the risk sensitivity coefficient, enabling risk adjustments to be adapted to different initial risk levels. The damage anomaly ratio is multiplied by the risk sensitivity coefficient to obtain the risk adjustment amount, achieving a correlation between the degree of difference and the risk level.

[0115] Finally, the initial risk coefficient is added to the risk adjustment amount to obtain the updated risk coefficient value, completing the dynamic optimization of the risk assessment. Finally, by combining the updated risk coefficient value, the damage anomaly ratio, and the entire comparative analysis process record, a final credible verification report is generated, providing a comprehensive and reliable basis for claims decisions.

[0116] Step S150 in the method provided in this application embodiment includes: Analyze the current accident data to extract the set of injured parts and the event type for the current period; From the unique trusted data chain, extract all historical damage records that are recorded within a preset time window and have the same type as the current event, and summarize them to obtain a set of historical damage locations; Calculate the number of parts in the current set of injury sites that have not appeared in the historical set of injury sites, and use this as the number of newly added abnormal parts. The ratio of the number of newly added abnormal sites to the size of the current set of damaged sites is calculated as the damage-abnormality ratio. A risk sensitivity coefficient is determined based on the initial risk coefficient, wherein the higher the initial risk coefficient, the greater the risk sensitivity coefficient. Multiply the damage anomaly ratio by the risk sensitivity coefficient to obtain the risk adjustment amount; The initial risk coefficient is added to the risk adjustment amount to obtain the updated risk coefficient value; Based on the updated risk coefficient value, the damage anomaly ratio, and the process record of the comparative analysis, a final credible verification report is generated.

[0117] Specifically, the system first receives the current accident data uploaded by the claims department and performs comprehensive analysis and processing on the data. This current accident data includes information such as the time and location of the incident, damage description, and nature of the incident. During the analysis process, it is necessary to accurately extract the set of damaged parts and the type of incident for the current period.

[0118] The current damage section must clearly identify the specific parts of the vehicle involved in the accident, such as the front bumper, left headlight, and right door. The current event type must be defined according to a unified classification standard, such as collision, scratch, or mechanical failure, to ensure consistency with historical records.

[0119] Furthermore, from the unique trusted data chain, all historical damage records that are the same type as the current event recorded within a preset time window are extracted and summarized to form a set of historical damage locations.

[0120] The setting of the preset time window needs to be determined based on vehicle usage patterns and the characteristics of the event type. For example, for collision-related events, the preset time window can be set to the past 3 years, which covers the vehicle's recent damage history while avoiding a decrease in reference value due to excessive time. In addition, for mechanical failure-related events, the preset time window can be set to the past 5 years, which aligns with the normal service life cycle of vehicle parts.

[0121] At the same time, when compiling historical damage records, it is necessary to conduct a comprehensive search of all historical records of the same event type to ensure that nothing is missed, and then extract the damage location information to form a complete set of historical damage locations.

[0122] Furthermore, the number of newly added abnormal parts is calculated by counting parts in the current damage set that have not appeared in the historical damage set. These parts are the first damages to appear in this accident and are a key indicator for judging the reasonableness of the current accident data. For example, if the historical damage set includes the front bumper, left headlight, and hood, and the current damage set includes the front bumper, right rear door, and trunk lid, then the number of newly added abnormal parts is 2.

[0123] Furthermore, the damage anomaly ratio is calculated based on the number of newly added abnormal sites and the size of the current set of damaged sites. Specifically, the calculation formula can be expressed as "Damage Anomaly Ratio = Number of Newly Added Abnormal Sites / Size of Current Set of Damaged Sites". The damage anomaly ratio directly reflects the degree of difference between current accident damage and historical damage. A higher ratio indicates a stronger anomaly in the current accident, requiring closer investigation; a lower ratio indicates a closer alignment between the current accident damage and historical damage patterns. For example, if the size of the current set of damaged sites is 3 and the number of newly added abnormal sites is 2, then the damage anomaly ratio is 2 / 3 ≈ 0.67.

[0124] Furthermore, a risk sensitivity coefficient is determined based on the initial risk coefficient. Specifically, the risk sensitivity coefficient can be calculated as "Risk Sensitivity Coefficient = k × Initial Risk Coefficient", where k is a pre-set proportional coefficient based on the risk benchmark weight corresponding to the vehicle type, with a value ranging from 0.1 to 0.5. Different vehicle types have different risk benchmark weights. For example, the k value can be set to 0.5 for commercial vehicles, 0.3 for passenger cars, and 0.4 for trucks, to match the actual risk levels of different vehicle types. A higher initial risk coefficient indicates a greater basic risk for the vehicle, and a correspondingly higher risk sensitivity coefficient, making risk adjustments more reflective of the cumulative risk effect of the vehicle.

[0125] For example, if the initial risk coefficient of a passenger car is 0.4 and the k value is set to 0.3, then the risk sensitivity coefficient = 0.3 × 0.4 = 0.12; if the initial risk coefficient of another commercial vehicle is 0.6 and the k value is set to 0.5, then the risk sensitivity coefficient = 0.5 × 0.6 = 0.3.

[0126] Furthermore, the risk adjustment is obtained by multiplying the damage anomaly ratio by the risk sensitivity coefficient. This risk adjustment quantifies the impact of the current accident anomaly on the overall vehicle risk. A higher damage anomaly ratio and a larger risk sensitivity coefficient result in a larger risk adjustment, meaning the accident has a more significant impact on the vehicle's risk level. For example, if the damage anomaly ratio is 0.67 and the risk sensitivity coefficient is 0.12, then the risk adjustment = 0.67 × 0.12 ≈ 0.08; if the damage anomaly ratio is 0.8 and the risk sensitivity coefficient is 0.3, then the risk adjustment = 0.8 × 0.3 = 0.24.

[0127] Furthermore, the initial risk coefficient is added to the risk adjustment amount to obtain the updated risk coefficient value, thereby achieving dynamic optimization of vehicle risk assessment. The updated risk coefficient value retains the vehicle's historical risk level while incorporating the impact of current accident-related anomalies, making the risk assessment results more closely reflect the vehicle's current actual risk status.

[0128] For example, if the initial risk coefficient is 0.4 and the risk adjustment is 0.08, then the updated risk coefficient value = 0.4 + 0.08 = 0.48; if the initial risk coefficient is 0.6 and the risk adjustment is 0.24, then the updated risk coefficient value = 0.6 + 0.24 = 0.84.

[0129] Furthermore, based on the updated risk coefficient values, the damage anomaly ratio, and the process records of the comparative analysis, a final credible verification report is generated. This final credible verification report must comprehensively present the core information of this comparative analysis, including the analysis results of the current incident data, the extraction range of the historical damage site set, a detailed list of newly added abnormal sites, the calculation process of the damage anomaly ratio and risk sensitivity coefficient, and the derivation logic of the risk adjustment amount and the updated risk coefficient values.

[0130] Simultaneously, clear claims assessment recommendations must be provided based on the updated risk coefficient value. For example, if the updated risk coefficient value is below 0.5, normal payment is recommended; if it is between 0.5 and 0.8, further investigation of the incident details is recommended; and if it is above 0.8, initiating an anti-fraud investigation process is recommended. The resulting credible verification report has a clear structure and detailed data, providing claims review personnel with comprehensive and reliable decision-making references to ensure the fairness and efficiency of the claims process.

[0131] The embodiments of this application, through the specific implementation methods described above, achieve the following technical effects: This application proposes a blockchain-based multi-party trusted verification method for auto insurance underwriting information. First, it receives the target vehicle verification request and the vehicle owner's authorization instruction from the underwriting client. The vehicle identifier is format-verified, and the authorization validity is confirmed through real-name authentication and intent verification, ensuring request compliance and legal data use. Next, the vehicle identifier is parsed to determine the vehicle type and initial registration time. Differential data retrieval instructions are initiated to the underwriting history node, traffic monitoring node, and vehicle status node. After authorization verification, standardized encrypted data returned by each node is obtained. Subsequently, encrypted data packets are sequentially verified, decrypted, and format-verified according to node priority, and valid data is filtered to form a subset of vehicle history data. Then, at the blockchain layer, the data is aligned and sorted by timestamp. Abnormal records are eliminated through two rounds of conflict detection, and mutually exclusive descriptions are marked. Nodes are sorted based on the degree of corroboration of related events, and a unique trusted data chain is generated and an initial risk coefficient is calculated. Finally, the current accident data from the claims client is received and compared with the unique trusted data chain for damage consistency. The risk coefficient is dynamically updated, and a final trusted verification report is generated.

[0132] The method provided in this application, through the technical solution of "request reception and authorization verification - heterogeneous node data retrieval - data verification, signature decryption and screening - multi-round verification and risk quantification at the blockchain layer - accident data comparison and report generation", solves the problems of incomplete information, unreliable data, risk misjudgment, frequent claims disputes and low underwriting efficiency caused by the reliance on unilateral declaration and manual verification in traditional auto insurance verification. It provides technical support for insurance companies' risk management and protection of car owners' rights.

[0133] Example 2, as shown in the appendix Figure 2As shown, based on the inventive concept of the blockchain-based multi-party trusted verification method for auto insurance underwriting information provided in Embodiment 1, this application also provides a blockchain-based multi-party trusted verification system for auto insurance underwriting information, specifically including: The insurance application request receiving module 01 is used to receive the verification request for the target vehicle and the vehicle owner's authorization instruction sent by the insurance application terminal, wherein the verification request carries the vehicle identifier; The heterogeneous node retrieval module 02 is used to initiate data retrieval instructions to multiple heterogeneous data source nodes based on the vehicle identifier, wherein the heterogeneous data source nodes include at least an insurance history node, a traffic supervision node, and a vehicle status node. The data signature verification and decryption module 03 is used to receive encrypted data packets returned by the multiple heterogeneous data source nodes, and sequentially verify and decrypt the signatures to obtain the corresponding vehicle historical data subset. The trusted data chain generation module 04 is used at the blockchain layer to perform multi-round conflict detection and trusted consensus verification on the subset of the vehicle's historical data based on consistency rules, merge and generate a unique trusted data chain for the target vehicle, and calculate the initial risk coefficient. The accident data verification module 05 is used to receive the current accident data uploaded by the claims terminal, perform damage consistency comparison analysis on the current accident data based on the unique trusted data chain, output the risk coefficient update value, and generate the final trusted verification report.

[0134] In one embodiment, the heterogeneous node retrieval module 02 is further configured to: The vehicle identifier is parsed to determine the vehicle type and initial registration time of the target vehicle. Based on the vehicle type and initial registration time, differentiated data retrieval instructions are constructed and sent to the insurance history node, the traffic monitoring node, and the vehicle status node, respectively. The data retrieval instruction sent to the insurance history node includes the full range of historical claims and insurance periods; the data retrieval instruction sent to the traffic monitoring node includes the full range of vehicle violation and accident records; and the data retrieval instruction sent to the vehicle status node includes requests for mileage, maintenance, and key component status records in specific dimensions. Before sending the differentiated data retrieval instructions, the validity and scope of the owner's authorization instruction are verified, and the verification result is appended to the differentiated data retrieval instructions. Each node, based on the received instructions, retrieves data records that meet the conditions in its local database, performs standardized format conversion on the retrieval results, signs and encrypts them using its own private key, and generates an encrypted data packet for return.

[0135] In one embodiment, the data verification and decryption module 03 is also used for: According to the preset node priority of the data retrieval instruction, the encrypted data packets are processed one by one; for a single encrypted data packet, the digital signature is verified using the registered public key of the corresponding node to confirm the authenticity of the data source and the integrity of the transmission; after the signature verification is passed, the data content is decrypted using a preset decryption key to restore the original response data in a standardized format; the record entries, timestamps, data fields and node identity information in the original response data are parsed to verify whether the data format conforms to the standardized convention; the original response data that has passed the signature verification, decryption and format verification is marked as a valid vehicle historical data subset from the corresponding node, and a mapping relationship is established with the node identity before it is temporarily stored; all returned encrypted data packets are traversed and processed to obtain the vehicle historical data subsets corresponding to the multiple heterogeneous data source nodes respectively.

[0136] In one embodiment, the trusted data link generation module 04 is further configured to: A subset of vehicle history data from each node is aligned and sorted according to standardized timestamps to generate a parallel record sequence ordered by time. A first round of conflict detection is performed on the parallel record sequence based on the time order, identifying and removing isolated event records and records of state abrupt changes. A second round of conflict detection is performed on the records that pass the first round of conflict detection based on event descriptions, identifying and marking mutually exclusive descriptions. For descriptions marked as mutually exclusive, the parallel record sequence is searched for related event records that can be independently verified by multiple nodes without contradiction. The source nodes of the mutually exclusive descriptions are ranked by credibility based on the degree of corroboration of the related event records. Records that pass multiple rounds of conflict detection are integrated, and the higher-credibility versions of the mutually exclusive descriptions are adopted according to the credibility ranking, fused along the timeline to generate a structured, unique, and credible data chain. From the unique trusted data chain, the total number of recorded events is counted as the cumulative event record frequency; the ratio between the cumulative event record frequency and the difference between the earliest timestamp and the current time recorded in the unique trusted data chain is calculated to obtain the event frequency; from the unique trusted data chain, the total number of damage site identifiers appearing in all event records is extracted; the ratio between the total number of damage site identifiers and the cumulative event record frequency is calculated as a damage severity index; the difference between the first registration time corresponding to the vehicle identifier and the current time is calculated to obtain the vehicle's service life; based on the vehicle's service life, the event frequency, and the damage severity index, the initial risk coefficient is obtained through weighted calculation.

[0137] Furthermore, the trusted data link generation module 04 also includes: Scan the parallel record sequence to identify all event records with timestamps earlier than the initial registration time, and mark them as time conflict records. Sequentially examine the timestamps and event types of adjacent records in the parallel record sequence to identify whether there are records where the timestamp of the later record is earlier than the timestamp of the earlier record, or records where the cumulative mileage indicated by the vehicle status record shows a non-unidirectional increase. Examine the parallel record sequence to identify isolated event records provided by a single node and associated with no other event records or status records from any node within adjacent time periods. Examine the maintenance records provided by the vehicle status node and the claims records provided by the insurance history node to identify record combinations that are temporally adjacent or overlapping, but whose descriptions of vehicle damage parts do not overlap. Remove the marked time conflict records, abnormal records in non-unidirectional increase record combinations, isolated event records, and abnormal description records in record combinations with no overlap in damage parts from the parallel record sequence.

[0138] Furthermore, the trusted data link generation module 04 also includes: In the parallel record sequence, record combinations with overlapping timestamps or within the same continuous time period are selected. For each record combination, it is checked whether records from different nodes simultaneously contain both accident type records and repair type records. If both accident type records and repair type records exist within the same time period, it is then identified whether there are record combinations where the sets of damaged parts described in the accident type records and the sets of repair parts described in the repair type records have no overlap. Repair type records from different nodes are checked to identify record combinations that are temporally continuous and target the same or adjacent vehicle parts, but whose repair treatment conclusions are completely opposite. Record combinations where the sets of damaged parts and repair parts have no overlap, and record combinations where the repair treatment conclusions are completely opposite, are marked as having mutually exclusive descriptions.

[0139] Furthermore, the trusted data link generation module 04 also includes: The following steps are taken: First, count the number of records in the associated event records that contain the same vehicle part identifier as the mutually exclusive description, as the direct corroboration count. Second, count the number of heterogeneous data source nodes providing the associated event records, as the independent corroboration breadth. Third, calculate the absolute value of the difference between the timestamps of all associated event records and the timestamps of the mutually exclusive descriptions, and take the average of these absolute values ​​as the average temporal proximity. Fourth, construct a sorting criterion based on the direct corroboration count, the independent corroboration breadth, and the average temporal proximity. Fifth, for each source node providing the mutually exclusive description, perform a comprehensive comparison based on the corresponding sorting criterion, and generate the credibility ranking according to the priority order of direct corroboration count from most to least, independent corroboration breadth from largest to smallest, and average temporal proximity from smallest to largest.

[0140] In one embodiment, the accident data verification module 05 is also used for: The process involves analyzing the current incident data to extract the current set of injury locations and the current event type; extracting all historical injury records with the same event type within a preset time window from the unique trusted data chain, and summarizing them to obtain the historical injury location set; calculating the number of locations in the current injury location set that have not appeared in the historical injury location set, as the number of newly added abnormal locations; calculating the ratio of the number of newly added abnormal locations to the size of the current injury location set, as the injury anomaly ratio; determining a risk sensitivity coefficient based on the initial risk coefficient, wherein the higher the initial risk coefficient, the larger the risk sensitivity coefficient; multiplying the injury anomaly ratio by the risk sensitivity coefficient to obtain a risk adjustment amount; adding the initial risk coefficient to the risk adjustment amount to obtain the risk coefficient update value; and generating a final credible verification report based on the risk coefficient update value, the injury anomaly ratio, and the process record of the comparative analysis.

Claims

1. A blockchain-based method for multi-party trusted verification of auto insurance underwriting information, characterized in that, The method includes: Receives a verification request for the target vehicle and an authorization instruction from the vehicle owner sent by the insurance application client, wherein the verification request carries a vehicle identifier; Based on the vehicle identifier, a data retrieval command is sent to multiple heterogeneous data source nodes, wherein the heterogeneous data source nodes include at least an insurance history node, a traffic monitoring node, and a vehicle status node. Receive encrypted data packets returned by the multiple heterogeneous data source nodes, and sequentially verify and decrypt them to obtain the corresponding subset of vehicle historical data; At the blockchain layer, multiple rounds of conflict detection and trusted consensus verification are performed on the subset of historical vehicle data based on consistency rules, and a unique trusted data chain for the target vehicle is generated by fusion, and an initial risk coefficient is calculated. The system receives current accident data uploaded from the claims processing end, performs damage consistency comparison analysis on the current accident data based on the unique trusted data chain, outputs risk coefficient update values, and generates a final trusted verification report.

2. The blockchain-based multi-party trusted verification method for auto insurance underwriting information as described in claim 1, characterized in that, Based on the vehicle identifier, data retrieval commands are sent to multiple heterogeneous data source nodes, including: The vehicle identifier is parsed to determine the vehicle type and initial registration time of the target vehicle; Based on the vehicle type and the first registration time, construct differentiated data retrieval instructions to be sent to the insurance history node, the traffic supervision node, and the vehicle status node, respectively; Among them, the data retrieval instructions sent to the underwriting history node include the full range of historical claims and insurance periods; the data retrieval instructions sent to the traffic supervision node include the full range of vehicle violation and accident records; and the data retrieval instructions sent to the vehicle status node include requests for mileage, maintenance, and key component status records in specific dimensions. Before sending the differentiated data retrieval instruction, verify the validity and scope of the vehicle owner's authorization instruction, and attach the verification result to the differentiated data retrieval instruction; Each node retrieves data records that meet the criteria from its local database according to the received instructions. After performing a standardized format conversion on the retrieval results, it signs and encrypts the data using its own private key, and then returns an encrypted data packet.

3. The blockchain-based multi-party trusted verification method for auto insurance underwriting information according to claim 1, characterized in that, The system receives encrypted data packets returned by the multiple heterogeneous data source nodes, performs signature verification and decryption sequentially, and obtains the corresponding subset of vehicle historical data, including: The encrypted data packets are processed one by one according to the preset node priority of the data retrieval instruction; For a single encrypted data packet, the digital signature is verified using the registered public key of the corresponding node to confirm the authenticity of the data source and the integrity of the transmission; After the signature verification is successful, the data content is decrypted using the preset decryption key to restore the original response data in a standardized format; Parse the record entries, timestamps, data fields, and node identity information in the original response data, and verify whether the data format conforms to the standardization convention; The original response data that has passed signature verification, decryption and format validation will be marked as a subset of valid vehicle historical data from the corresponding node, and then temporarily stored after establishing a mapping relationship with the node identity. All returned encrypted data packets are traversed and processed to obtain the vehicle historical data subsets corresponding to the multiple heterogeneous data source nodes.

4. The blockchain-based multi-party trusted verification method for auto insurance underwriting information according to claim 1, characterized in that, At the blockchain layer, based on consistency rules, multiple rounds of conflict detection and trusted consensus verification are performed on the subset of historical vehicle data, and the resulting data is fused to generate a unique trusted data chain for the target vehicle, including: The vehicle history data subsets from each node are aligned and sorted according to standardized timestamps to generate a parallel record sequence ordered by time. The first round of conflict detection is performed on the parallel record sequence based on the time order to identify and remove isolated event records and state change records. A second round of conflict detection is performed on the records that passed the first round of conflict detection based on the event description, to identify and mark mutually exclusive descriptions; For descriptions marked as mutually exclusive, search the parallel record sequence to find whether there are related event records that can be independently verified by multiple nodes and are consistent with each other; The source nodes of the mutually exclusive descriptions are ranked by credibility based on the degree of corroboration of the associated event records; Records that have passed multiple rounds of conflict detection are integrated, and the high-confidence versions in the mutually exclusive descriptions are adopted according to the confidence level. The data are then fused along the timeline to generate a structured, unique, and trusted data chain.

5. The blockchain-based multi-party trusted verification method for auto insurance underwriting information according to claim 4, characterized in that, The first round of conflict detection is performed on the parallel record sequence based on time order to identify and remove isolated event records and records of state abrupt changes, including: Scan the parallel record sequence to identify all event records whose timestamps are earlier than the initial registration time, and mark them as time conflict records accordingly; The timestamps and event types of two adjacent records in the parallel record sequence are checked sequentially to identify whether there is a record whose timestamp is earlier than the timestamp of the previous record, or a record combination in which the cumulative mileage indicated by the vehicle status record shows a non-unidirectional increase. Examine the parallel record sequence to identify isolated event records that are provided by a single node and are not associated with any other event records or status records from any node in adjacent time periods before or after the time. Examine the repair records provided by the vehicle status node and the claims records provided by the insurance history node to identify combinations of records that are adjacent or overlapping in time, but whose descriptions of the vehicle damage parts do not overlap. The abnormal records in the marked time conflict records, non-unidirectional growth record combinations, isolated event records, and abnormal description records in record combinations that do not have an intersection of damage sites are removed from the parallel record sequence.

6. The blockchain-based multi-party trusted verification method for auto insurance underwriting information according to claim 4, characterized in that, A second round of conflict detection is performed on the records that passed the first round of conflict detection based on the event description, identifying and marking mutually exclusive descriptions, including: In the parallel record sequence, record combinations with overlapping timestamps or those within the same consecutive time period are selected; For the record combination, check whether the records from different nodes simultaneously contain accident type records and maintenance type records; If accident type records and maintenance type records exist simultaneously within the same time period, then for the set of damaged parts described in the accident type records and the set of maintenance parts described in the maintenance type records, identify whether there is a record combination in which the set of damaged parts and the set of maintenance parts have no intersection at all; Examine repair type records from different nodes to identify combinations of records that are consecutive in time and target the same or adjacent vehicle parts, but whose repair conclusions are completely opposite. Records that do not intersect with the set of damaged parts and the set of repaired parts, as well as records with completely opposite repair conclusions, are marked as mutually exclusive descriptions.

7. The blockchain-based multi-party trusted verification method for auto insurance underwriting information according to claim 4, characterized in that, The credibility of the source nodes of the mutually exclusive descriptions is ranked based on the degree of corroboration of the associated event records, including: The number of records in the associated event records that contain the same vehicle part identifier as the mutually exclusive description is counted as the number of direct verification records; The number of heterogeneous data source nodes that provide the associated event records is counted as an independent verification of breadth; Calculate the absolute value of the difference between the timestamps of all the associated event records and the timestamps of the mutually exclusive descriptions, and take the average of the absolute values ​​as the average time proximity. The sorting criteria are constructed based on the number of direct corroborations, the breadth of independent corroborations, and the average temporal proximity. For each source node that provides the mutually exclusive description, a comprehensive comparison is performed based on the corresponding sorting criteria. The credibility ranking is generated according to the priority order of the number of direct corroborations from most to least, the breadth of independent corroborations from largest to smallest, and the average temporal proximity from smallest to largest.

8. The blockchain-based multi-party trusted verification method for auto insurance underwriting information according to claim 1, characterized in that, Calculate the initial risk coefficient, including: The total number of events recorded from the unique trusted data chain is used as the cumulative event record frequency. The event frequency is obtained by calculating the ratio between the cumulative event record frequency and the difference between the earliest timestamp and the current time recorded in the unique trusted data chain; Extract the total number of damage site identifiers appearing in all event records from the unique trusted data chain; The ratio between the total number of identified damaged sites and the cumulative frequency of event records is calculated as an indicator of the degree of damage. The vehicle's service life is obtained by calculating the difference between the initial registration time corresponding to the vehicle identifier and the current time. The initial risk coefficient is obtained by weighted calculation based on the vehicle's service life, the frequency of the event, and the damage severity index.

9. The blockchain-based multi-party trusted verification method for auto insurance underwriting information according to claim 1, characterized in that, The system receives current accident data uploaded from the claims processing end, performs damage consistency comparison analysis on the current accident data based on the unique trusted data chain, outputs updated risk coefficient values, and generates a final trusted verification report, including: Analyze the current accident data to extract the set of injured parts and the event type for the current period; From the unique trusted data chain, extract all historical damage records that are recorded within a preset time window and have the same type as the current event, and summarize them to obtain a set of historical damage locations; Calculate the number of parts in the current set of injury sites that have not appeared in the historical set of injury sites, and use this as the number of newly added abnormal parts. The ratio of the number of newly added abnormal sites to the size of the current set of damaged sites is calculated as the damage-abnormality ratio. A risk sensitivity coefficient is determined based on the initial risk coefficient, wherein the higher the initial risk coefficient, the greater the risk sensitivity coefficient. Multiply the damage anomaly ratio by the risk sensitivity coefficient to obtain the risk adjustment amount; The initial risk coefficient is added to the risk adjustment amount to obtain the updated risk coefficient value; Based on the updated risk coefficient value, the damage anomaly ratio, and the process record of the comparative analysis, a final credible verification report is generated.

10. A blockchain-based multi-party trusted verification system for auto insurance underwriting information, characterized in that: The system is used to execute the blockchain-based multi-party trusted verification method for auto insurance underwriting information as described in any one of claims 1-9, and the system includes: The insurance application request receiving module is used to receive the verification request for the target vehicle and the vehicle owner's authorization instruction sent by the insurance application terminal, wherein the verification request carries the vehicle identifier; The heterogeneous node retrieval module is used to initiate data retrieval instructions to multiple heterogeneous data source nodes based on the vehicle identifier, wherein the heterogeneous data source nodes include at least an insurance history node, a traffic monitoring node, and a vehicle status node. The data signature verification and decryption module is used to receive encrypted data packets returned by the multiple heterogeneous data source nodes, and sequentially verify and decrypt them to obtain the corresponding vehicle historical data subset. The trusted data chain generation module is used at the blockchain layer to perform multi-round conflict detection and trusted consensus verification on the subset of the vehicle's historical data based on consistency rules, merge and generate a unique trusted data chain for the target vehicle, and calculate the initial risk coefficient. The accident data verification module is used to receive the current accident data uploaded by the claims terminal, perform damage consistency comparison analysis on the current accident data based on the unique trusted data chain, output the risk coefficient update value, and generate the final trusted verification report.

Images