An insurance intermediary channel policy data change automatic monitoring system and method

Abstract

The application belongs to the technical field of insurance intermediary, and particularly discloses an insurance intermediary channel policy data change automatic monitoring system and method, which comprises a multi-channel policy data access module, a data standardization processing module, a real-time data acquisition engine module, a policy change detection module, a distributed database module, a hierarchical early warning module, an alliance chain change log module and a front-end display module. The insurance intermediary channel policy data change automatic monitoring system and method automatically capture the unified conversion and real-time capture of the field naming and data types of different insurance companies, replace the traditional manual channel-by-channel arrangement, thereby reducing the data processing time of the policy and the monitoring delay of the policy information change, and avoiding the data errors caused by manual operation.

Description

Technical Field

[0001] This invention relates to the field of insurance intermediary technology, specifically to an automatic monitoring system and method for policy data changes in insurance intermediary channels. Background Technology

[0002] Insurance intermediary companies are organizations that connect insurance companies with policyholders, support online sales of policies from multiple insurance companies offering different products, and provide post-policy services. They need to manage policy data from multiple channels. Insurance intermediary companies are the core hub of the insurance market. With the rapid development of the insurance market, leading insurance intermediaries typically cooperate with more than 10 insurance companies and manage more than one million policies annually. After a policy takes effect, changes to core information such as policyholder information, premium amount, insurance period, and policy status are common. These changes directly affect the accuracy and timeliness of subsequent claims, policy maintenance, and other services. Therefore, it is necessary to effectively monitor changes to policy data from multiple channels.

[0003] Currently, insurance intermediary companies rely on manual monitoring of policy data changes. However, different insurance companies have different policy data interface protocols and data types, requiring manual data formatting for each channel, making direct and unified comparison impossible. Manual monitoring is inefficient, prone to missed changes and misjudgments, and the lack of unified and tamper-proof records makes traceability difficult and poses a risk of record tampering. Summary of the Invention

[0004] The purpose of this invention is to provide an automatic monitoring system and method for policy data changes in insurance intermediary channels, in order to solve the problems mentioned in the background art, which are that existing policy data changes rely on manual intervention, resulting in low efficiency, high error rate, and difficulty in tracing.

[0005] To achieve the above objectives, the present invention provides the following technical solution: an automatic monitoring system and method for policy data changes in insurance intermediary channels, comprising a multi-channel policy data access module, a data standardization processing module, a real-time data acquisition engine module, a policy change detection module, a distributed database module, a tiered early warning module, a consortium blockchain change log module, and a front-end display module. The multi-channel policy data access module is connected to the data standardization processing module, the data standardization processing module is connected to the real-time data acquisition engine module, the real-time data acquisition engine module is connected to the distributed database module and the policy change detection module, the policy change detection module is simultaneously connected to the distributed database module, the tiered early warning module, and the consortium blockchain change log module, the tiered early warning module and the consortium blockchain change log module are synchronously connected to the front-end display module, and the distributed database module is used to store standardized historical policy data. Preferably, the multi-channel policy data access module is used to connect to the API interfaces of different insurance companies to capture raw policy data in real time. The multi-channel policy data access module supports REST and SOAP protocol interface adaptation, and the raw policy data captured by the multi-channel policy data access module includes JSON and XML formats.

[0006] Using the above technical solution, the multi-channel policy data access module can automatically connect to multiple insurance companies and automatically capture original policy data.

[0007] Preferably, the data standardization processing module is used to convert the original policy data into standardized policy data in a unified format. The data standardization processing module presets a field mapping table and data cleaning rules. The field mapping table maps field names from different insurance companies to standard field names. The data cleaning rules perform data type conversion, null value filling, and outlier filtering.

[0008] By adopting the above technical solution, the data standardization processing module can achieve unified processing of the original policy data format, thereby increasing the efficiency of subsequent data processing.

[0009] Preferably, the real-time data acquisition engine module is used to receive standardized policy data. The standardized policy data is transmitted to the distributed database module for storage as historical data on the one hand, and transmitted to the policy change detection module in real time on the other hand.

[0010] By adopting the above technical solution, the real-time data acquisition engine module can realize the real-time data diversion, storage, and detection process.

[0011] Preferably, the policy change detection module compares real-time standardized data with historical data of the corresponding policy in the distributed database. The policy change detection module employs a dual-mode detection method combining threshold detection and feature matching to identify policy data changes and outputs the change results, specifically: The threshold detection section has a preset configurable threshold. When the change in the quantized field exceeds the preset threshold, it is determined to be a change. The feature matching part compares non-quantized fields based on a string similarity algorithm. When the similarity is lower than a preset threshold, it is determined to be a change. The string similarity algorithm is the Levenshtein distance algorithm.

[0012] Using the above technical solution, the policy change detection module can be used to detect changes to the policy.

[0013] Preferably, the hierarchical early warning module is used to match the change result with preset hierarchical rules and trigger an early warning at the corresponding level. The hierarchical early warning module divides the change into Level 1, Level 2, and Level 3 changes according to the degree of impact of the change. The Level 1, Level 2, and Level 3 changes correspond to different early warning methods, specifically: Level 1 changes include policy lapse, premium changes >20%, and policyholder ID number modification, which trigger a Level 1 alert and send SMS, system pop-up, and email messages to the operations manager. Level 2 changes include policyholder name modification, premium change of 5%-20%, and beneficiary information change, which trigger a Level 2 alert, and a system pop-up and email are sent to the operations specialist. Level 3 changes include changes to the policyholder's address, contact information, and minor adjustments to the insurance period (less than 30 days). These changes trigger a Level 3 alert, which is only recorded in the system log on the front-end display module and does not send an active alert.

[0014] Using the above technical solution, a tiered early warning module can be used to provide tiered early warnings based on the impact of policy changes.

[0015] Preferably, the consortium blockchain change log module is used to write the change results into the blockchain-based consortium blockchain to generate an immutable change log. The consortium blockchain change log module is built on Hyperledger Fabric, and the participating nodes include insurance intermediary nodes and cooperative insurance company nodes. The automatic on-chain storage and query of change logs are realized through smart contracts.

[0016] By adopting the above technical solution, the change log module of the consortium blockchain can realize automatic on-chain storage and query of change logs.

[0017] Preferably, the front-end display module is a user-facing interactive interface, which includes three parts: displaying a real-time change list and early warning statistical charts; querying change logs; and providing an entry point for early warning processing.

[0018] Using the above technical solution, policy change information can be queried through the front-end display module.

[0019] Preferably, the steps of the method are as follows: Step 1: Multi-channel policy data access; The multi-channel policy data access module connects to the data sources of various partner insurance companies through a pre-developed API interface; The API interface automatically retrieves raw policy data at a preset frequency. The raw policy data formats include JSON and XML, and the data content includes policy number, policyholder information, premium amount, and policy status. If the API interface fails to capture data due to network disconnection, the multi-channel policy data access module will trigger a retry mechanism with a maximum number of retries of ≤3 and a retry interval of 10 seconds. If the retry fails, an alarm email will be sent to the technical maintenance personnel. Step 2: Data Standardization Processing; The data standardization processing module receives raw data output from the multi-channel policy data access module. The data standardization processing module receives the raw data output by the access module and calls the preset "field mapping table" and "data cleaning rules"; The field mapping table performs field name conversion, data type conversion, and outlier filtering. Output standardized policy data in a unified JSON format; Step 3: Real-time data storage and transmission; The real-time data acquisition engine module receives the standardized output data and processes it in two paths: The data is transmitted to a distributed database module and indexed and stored according to "policy number + collection time" as historical data for subsequent comparisons. Another path transmits data in real time to the policy change detection module, triggering the change detection process; The distributed database module supports fast querying by "policy number" with a response time of less than 1 second, meeting the real-time comparison requirements of the policy change detection module; Step 4: Policy Change Detection; The policy change detection module receives real-time standardized data and reads the latest historical data of the policy from the distributed database module using the "policy number"; Perform dual-mode detection on real-time data, including threshold detection and feature matching, specifically: Threshold detection: Calculates the quantitative field difference between real-time data and historical data; Feature matching: Compare non-quantized fields using the Levenshtein distance algorithm; If the dual-mode detection detects a change, it outputs a structured change result, which includes at least the policy number, the changed field, the values ​​before and after the change, the change time, the change type, and the detection method. Step 5: Triggering of tiered early warnings; The tiered early warning module receives the change results and matches the tiered rules according to the "change type"; Call the corresponding alert interface: Based on the change results, match the preset grading rules in the grading early warning module to trigger the corresponding level of early warning; Step 6: Store change logs on the blockchain; The consortium blockchain change log module receives the change results, automatically adds "operator", records any manual intervention, and records "system automatic detection" if there is no manual intervention, generating a complete log record; The consortium blockchain smart contract is invoked to write log records to the blockchain, including the distributed storage of intermediary company and insurance company nodes, to ensure that the records cannot be tampered with. Once the blockchain upload is complete, a "Blockchain upload successful" flag is returned and associated with the change result; Step 7, Results Display and Query; The front-end display module obtains warning information from the hierarchical warning module and change logs from the consortium blockchain change log module, and displays them in a dashboard format, specifically: Real-time Change List: Sorted in descending order of change time, displaying policy number, changed fields, alert level, and processing status; Early warning statistics pie chart: showing the percentage of Level 1, Level 2, and Level 3 early warnings; Log query box: Allows users to enter the policy number to query all historical change logs of the policy. The historical change logs are read from the consortium blockchain to ensure authenticity. Users can mark the status of the alert processing on the front end, and click "Processed" to update the status record of the alert module.

[0020] By adopting the above technical solution and following the above steps, it is possible to monitor and provide early warnings for policy changes.

[0021] Compared with the prior art, the beneficial effects of the present invention are: the automatic monitoring system and method for policy data changes in insurance intermediary channels: 1. This invention sets up a multi-channel policy data access module to connect with different insurance companies, automatically captures and unifies the field naming and data type of different insurance companies, and captures them in real time, replacing the traditional manual channel-by-channel sorting, thereby reducing the data processing time of policies and the monitoring delay of policy information changes, while avoiding data errors caused by manual operation; 2. This invention employs a dual-mode change detection method combining threshold detection and feature matching. The system uses quantitative thresholds to identify changes in values ​​such as premiums and terms. At the same time, it uses string similarity algorithms to compare subtle differences in non-quantifiable fields such as ID numbers and names, reducing the missed detection rate and false positive rate of policy changes. In addition, each change record is automatically written to the consortium blockchain. By leveraging the immutability and distributed storage characteristics of blockchain, the system prevents policy data from being tampered with, thereby improving data credibility. Attached Figure Description

[0022] Figure 1 This is a schematic diagram of the system module connection structure of the present invention; Figure 2 This is a schematic diagram of the process flow of the method of the present invention. Detailed Implementation

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

[0024] Please see Figures 1-2 The present invention provides a technical solution: an automatic monitoring system and method for policy data changes in insurance intermediary channels.

[0025] The multi-channel policy data access module is connected to the data standardization processing module, which in turn is connected to the real-time data acquisition engine module. The real-time data acquisition engine module is connected to a distributed database module and a policy change detection module. The policy change detection module is simultaneously connected to the distributed database module, the tiered early warning module, and the consortium blockchain change log module. The tiered early warning module and the consortium blockchain change log module are synchronously connected to the front-end display module. The distributed database module stores standardized historical policy data. The multi-channel policy data access module interfaces with different insurance companies' APIs to capture raw policy data in real time. This module supports REST and SOAP protocol interface adaptation. The raw policy data captured by the multi-channel policy data access module includes JSON and XML formats. The data standardization processing module converts the raw policy data into standardized policy data in a unified format. This module has a pre-defined field mapping table and data cleaning rules. The field mapping table maps field names from different insurance companies to standard field names, and the data cleaning rules perform data type conversion and emptying / removal. Value imputation and outlier filtering: The real-time data acquisition engine module receives standardized policy data. This standardized policy data is transmitted to a distributed database module for storage as historical data, and simultaneously transmitted in real-time to a policy change detection module. The policy change detection module compares the real-time standardized data with the historical data of the corresponding policies in the distributed database. The module employs a dual-mode detection method combining threshold detection and feature matching to identify policy data changes and outputs the results. Specifically: the threshold detection part presets a configurable threshold; when the change in a quantified field exceeds the preset threshold, it is considered a change. The feature matching part compares non-quantified fields based on a string similarity algorithm; when the similarity is below a preset threshold, it is considered a change. The string similarity algorithm is the Levenshtein distance algorithm. The tiered early warning module matches the change results with preset tiered rules to trigger corresponding level warnings. The tiered early warning module classifies changes into Level 1, Level 2, and Level 3 changes based on their impact, with each level corresponding to a different warning method. Level 1 changes include policy lapse, premium changes >20%, and policyholder ID number modification, which trigger a Level 1 alert and send SMS, system pop-up, and email messages to the operations manager. Level 2 changes include policyholder name modification, premium change of 5%-20%, and beneficiary information change, which trigger a Level 2 alert, and a system pop-up and email are sent to the operations specialist. Level 3 changes include policyholder address modification, contact information modification, and minor adjustments to the insurance period (less than 30 days), triggering a Level 3 alert. This is only recorded in the system logs displayed on the front-end module and no proactive alert is sent. The consortium blockchain change log module is used to write the change results into the blockchain-based consortium blockchain, generating an immutable change log. The consortium blockchain change log module is built on Hyperledger Fabric, with participating nodes including insurance intermediary nodes and partner insurance company nodes. Automatic on-chain storage and querying of change logs are achieved through smart contracts. The front-end module is a user-facing interactive interface consisting of three parts: displaying a real-time change list and alert statistics charts; and providing an entry point for change log queries and alert processing. like Figure 1 As shown, before the system is officially launched, or when adding or modifying insurance company interfaces, the API interface of the multi-channel policy data access module is pre-debugged. Technical personnel conduct connectivity tests on the API of each insurance company to verify whether data can be captured; field integrity tests to verify whether all core fields are included; and stress tests to verify whether the interface can support a call frequency of 100 times / minute. Through debugging, the interface is ensured to be stable to avoid data collection failure due to interface problems after launch. The debugging process is only triggered when the interface changes. Before the system went live, 100,000 historical change data from the past 6 months were used to train the threshold and feature matching model to determine the initial thresholds, such as premium changes ±5% and similarity thresholds such as 95%. Quarterly calibration was performed. After the system went live, the model was retrained every quarter using new change data from the past 3 months to adjust the thresholds. If a high false negative rate was found, the premium change threshold was lowered from 5% to 3%. The model accuracy was optimized through regular model training. When deploying the system or adding new cooperative insurance company nodes, technical personnel create intermediary company nodes and individual insurance company nodes in the Hyperledger Fabric consortium blockchain, configure node permissions (e.g., insurance company nodes can only query the change logs of their own insurance policies and cannot modify them), initialize smart contracts, and thus build the consortium blockchain infrastructure. The distributed database backup process involves performing a full backup of historical policy data in the distributed database module during off-peak business periods, such as 2:00 AM daily, and storing it on a remote server to prevent data loss.

[0026] The steps of the method are as follows: Step 1: Multi-channel policy data access; The multi-channel policy data access module connects to the data sources of various partner insurance companies through a pre-developed API interface; The API interface automatically retrieves raw policy data at a preset frequency. The raw policy data formats include JSON and XML, and the data content includes policy number, policyholder information, premium amount, and policy status. If the API interface fails to capture data due to network disconnection, the multi-channel policy data access module will trigger a retry mechanism with a maximum number of retries of ≤3 and a retry interval of 10 seconds. If the retry fails, an alarm email will be sent to the technical maintenance personnel. Step 2: Data Standardization Processing; The data standardization processing module receives raw data output from the multi-channel policy data access module. The data standardization processing module receives the raw data output by the access module and calls the preset "field mapping table" and "data cleaning rules"; The field mapping table performs field name conversion, data type conversion, and outlier filtering. Output standardized policy data in a unified JSON format; Step 3: Real-time data storage and transmission; The real-time data acquisition engine module receives the standardized output data and processes it in two paths: The data is transmitted to a distributed database module and indexed and stored according to "policy number + collection time" as historical data for subsequent comparisons. Another path transmits data in real time to the policy change detection module, triggering the change detection process; The distributed database module supports fast querying by "policy number" with a response time of less than 1 second, meeting the real-time comparison requirements of the policy change detection module; Step 4: Policy Change Detection; The policy change detection module receives real-time standardized data and reads the latest historical data of the policy from the distributed database module using the "policy number"; Perform dual-mode detection on real-time data, including threshold detection and feature matching, specifically: Threshold detection: Calculates the quantitative field difference between real-time data and historical data; Feature matching: Compare non-quantized fields using the Levenshtein distance algorithm; If the dual-mode detection detects a change, it outputs a structured change result, which includes at least the policy number, the changed field, the values ​​before and after the change, the change time, the change type, and the detection method. Step 5: Triggering of tiered early warnings; The tiered early warning module receives the change results and matches the tiered rules according to the "change type"; Call the corresponding alert interface: Based on the change results, match the preset grading rules in the grading early warning module to trigger the corresponding level of early warning; Step 6: Store change logs on the blockchain; The consortium blockchain change log module receives the change results, automatically adds "operator", records any manual intervention, and records "system automatic detection" if there is no manual intervention, generating a complete log record; The consortium blockchain smart contract is invoked to write log records to the blockchain, including the distributed storage of intermediary company and insurance company nodes, to ensure that the records cannot be tampered with. Once the blockchain upload is complete, a "Blockchain upload successful" flag is returned and associated with the change result; Step 7, Results Display and Query; The front-end display module obtains warning information from the hierarchical warning module and change logs from the consortium blockchain change log module, and displays them in a dashboard format, specifically: Real-time Change List: Sorted in descending order of change time, displaying policy number, changed fields, alert level, and processing status; Early warning statistics pie chart: showing the percentage of Level 1, Level 2, and Level 3 early warnings; Log query box: Allows users to enter the policy number to query all historical change logs of the policy. The historical change logs are read from the consortium blockchain to ensure authenticity. Users can mark the status of the alert processing on the front end, and click "Processed" to update the status record of the alert module; Example: Background: An insurance intermediary company, hereinafter referred to as "Intermediary X", has a partner insurance company A. Partner insurance company A provides a REST API interface with a "premium" string field, such as "5000 yuan" and "insuredId" being the policyholder's ID number. At 10:00 AM on May 20, 2024, insurance company A pushes policy data for policy number "P20240520001". The historical data of this policy from April 20 is stored in a distributed database module. like Figure 2 As shown, the specific data processing flow is as follows: Step 1: Multi-channel data access; Intermediary X's "Multi-channel policy data access module" retrieves raw data through Insurance Company A's REST API interface. The raw data is in JSON format. { "policyNo":"P20240520001", "insuredName":"Zhang San", "insuredId":"110101199001011235", "premium":"5000 yuan", "policyStatus":"Valid", "term":"365 days"} The interface call was successful without any errors. The multi-channel policy data access module will transmit the raw data to the "data standardization processing module". Step 2: Data standardization processing. The standardization module calls the "Bao Si A - Standard Fields" mapping table: "policyNo" → "policy number", "insuredName" → "insured person's name", "insuredId" → "ID card number", "premium" → "premium amount", "policyStatus" → "policy status", "term" → "insurance period (days)"; Perform data cleaning: "premium":"5000 yuan" → Delete the character "yuan" and convert it to the numeric type 5000; "term":"365 days" → Delete the character "day" and convert it to the numeric type 365; Output standardized data: { Policy Number: "P20240520001", "Insured's Name": "Zhang San" ID number: "110101199001011235" Premium Amount: 5000 Policy Status: "Valid" "Insurance period (days)": 365 Data collection time: 2024-05-20 10:00:00 }; Step 3: Real-time data storage and transmission. The "real-time data acquisition engine module" divides the standardized data into two paths: The data is transmitted to the "distributed database module" and stored as "Policy Number = P20240520001 + Collection Time = 2024-05-20 10:00:00". Another path transmits data in real time to the "Policy Change Detection Module"; Step 4: Policy Change Detection. The policy change detection module reads historical data from the distributed database on April 20th using "Policy Number = P20240520001". json { Policy Number: "P20240520001", "Insured's Name": "Zhang San" ID number: "110101199001011234" Premium Amount: 4800 Policy Status: "Valid" "Insurance period (days)": 365 "Collection Time":"2024-04-20 10:00:00"}; Perform dual-mode detection: Threshold detection: Premium amount difference = 5000 - 4800 = 200 yuan, difference rate = 200 / 4800 ≈ 4.17% < 5% (preset threshold), not judged as a change; Feature matching: The Levenshtein distance between the ID number "110101199001011235" and the historical "110101199001011234" is 1, with only the last character different. The similarity is (18-1) / 18≈94.4%<95%. Based on the preset similarity threshold, it is determined to be a change. Output the change results: json { Policy Number: "P20240520001", "Change field":"ID number", Previous value: "110101199001011234" "Changed value":"110101199001011235", "Change Time":"2024-05-20 10:00:00", "Change Type": "Insured Information Change" "Detection method":"Feature matching"}; Step 5: Tiered early warning triggered. The tiered early warning module matches the tiered rules: "Modification of policyholder's ID number" belongs to the second-level change category and is automatically triggered. Send an alert email to Operations Specialist Wang Wu's corporate email address (wangwu@mediatorx.com), including details of the change; A warning pop-up appeared in Wang Wu's system account, displaying "[Level 2 Warning] Policy P20240520001 ID number changed, please handle it in time", with a "Mark for processing" button attached; Step 6: Store the change log on the blockchain. The consortium blockchain change log module receives the policy change results, adds "operator = system automatic detection", and generates log records. The smart contract is invoked to write the logs to the consortium blockchain, and the intermediary node X and the insurance company node A store them synchronously. After successful on-chain processing, the system returns "On-chain ID: LC20240520100001", which is associated with the change result. Step 7: Result Display and Query. The "Real-time Change List" on the front-end dashboard displays the change record, with the warning level marked in yellow (Level 2) and the processing status as "Unprocessed". After logging into the system, Wang Wu saw a pop-up warning, clicked "Mark for Handling," and updated the status to "Handled." If further tracing is required, users can enter the policy number "P20240520001" in the "Log Query Area" to find the change log (including the on-chain ID and on-chain time), which is marked "unalterable". At this point, the automatic change task is completed.

[0027] Working Principle: The system accesses policy data from multiple channels by calling the API interfaces of various insurance companies to capture raw policy data. The captured data enters the data standardization processing module, which maps field names from different insurance companies to standard field names and converts data types, outputting standardized policy data in a unified format. This standardized data is received by the real-time data acquisition engine module. One stream of data is stored in a distributed database as historical data, while the other stream is pushed to the policy change detection module in real time. The policy change detection module performs threshold detection on quantifiable fields such as premium and term, and uses the Levenshtein distance algorithm for similarity matching on non-quantifiable fields such as ID number and name. After a change is detected, a structured result containing the policy number, changed field, previous and current values, time, and type is output. The hierarchical early warning module matches preset rules based on the change type and triggers corresponding early warnings. At the same time, the consortium blockchain change log module automatically supplements the change results with operator information and generates an immutable log. The front-end display module displays the change list and early warning statistics in real time and supports querying on-chain historical logs by policy number. Users can mark the status of early warning processing, completing the closed-loop monitoring of the entire process.

[0028] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention.

Claims

1. An automatic monitoring system for policy data changes in insurance intermediary channels, comprising a multi-channel policy data access module, a data standardization processing module, a real-time data acquisition engine module, a policy change detection module, a distributed database module, a tiered early warning module, a consortium blockchain change log module, and a front-end display module, characterized in that: The multi-channel policy data access module is connected to the data standardization processing module, which is connected to the real-time data acquisition engine module. The real-time data acquisition engine module is connected to a distributed database module and a policy change detection module. The policy change detection module is simultaneously connected to the distributed database module, the hierarchical early warning module, and the consortium blockchain change log module. The hierarchical early warning module and the consortium blockchain change log module are synchronously connected to the front-end display module. The distributed database module is used to store standardized historical policy data.

2. The automatic monitoring system for policy data changes in insurance intermediary channels according to claim 1, characterized in that: The multi-channel policy data access module is used to connect to the API interfaces of different insurance companies and capture raw policy data in real time. The multi-channel policy data access module supports REST and SOAP protocol interface adaptation, and the raw policy data captured by the multi-channel policy data access module includes JSON and XML formats.

3. The automatic monitoring system for policy data changes in insurance intermediary channels according to claim 1, characterized in that: The data standardization processing module is used to convert the original policy data into standardized policy data in a unified format. The data standardization processing module presets a field mapping table and data cleaning rules. The field mapping table maps field names from different insurance companies to standard field names. The data cleaning rules perform data type conversion, null value filling, and outlier filtering.

4. The automatic monitoring system for policy data changes in insurance intermediary channels according to claim 1, characterized in that: The real-time data acquisition engine module is used to receive standardized policy data. The standardized policy data is transmitted to the distributed database module for storage as historical data on the one hand, and transmitted to the policy change detection module in real time on the other hand.

5. The automatic monitoring system for policy data changes in insurance intermediary channels according to claim 1, characterized in that: The policy change detection module compares real-time standardized data with historical data of the corresponding policies in the distributed database. The module employs a dual-mode detection method combining threshold detection and feature matching to identify policy data changes and outputs the change results, specifically: The threshold detection section has a preset configurable threshold. When the change in the quantized field exceeds the preset threshold, it is determined to be a change. The feature matching part compares non-quantized fields based on a string similarity algorithm. When the similarity is lower than a preset threshold, it is determined to be a change. The string similarity algorithm is the Levenshtein distance algorithm.

6. The automatic monitoring system for policy data changes in insurance intermediary channels according to claim 1, characterized in that: The hierarchical early warning module is used to match the change result with preset hierarchical rules and trigger an early warning at the corresponding level. The module classifies changes into Level 1, Level 2, and Level 3 changes based on their impact, with each level corresponding to a different early warning method: Level 1 changes include policy lapse, premium changes >20%, and policyholder ID number modification, which trigger a Level 1 alert and send SMS, system pop-up, and email messages to the operations manager. Level 2 changes include policyholder name modification, premium change of 5%-20%, and beneficiary information change, which trigger a Level 2 alert, and a system pop-up and email are sent to the operations specialist. Level 3 changes include changes to the policyholder's address, contact information, and minor adjustments to the insurance period (less than 30 days). These changes trigger a Level 3 alert, which is only recorded in the system log on the front-end display module and does not send an active alert.

7. The automatic monitoring system for policy data changes in insurance intermediary channels according to claim 1, characterized in that: The consortium blockchain change log module is used to write the change results into the blockchain-based consortium blockchain, generating an immutable change log. The consortium blockchain change log module is built on Hyperledger Fabric, and the participating nodes include insurance intermediary nodes and cooperative insurance company nodes. The automatic on-chain storage and query of change logs are realized through smart contracts.

8. The automatic monitoring system for policy data changes in insurance intermediary channels according to claim 1, characterized in that: The front-end display module is a user-facing interactive interface, which includes three parts: displaying a real-time change list and early warning statistical charts. Entry point for change log query and early warning processing.

9. A method for automatically monitoring policy data changes through insurance intermediaries, characterized in that: Using the automatic monitoring system for policy data changes in insurance intermediary channels as described in any one of claims 1 to 8, the steps of the method are as follows: Step 1: Multi-channel policy data access; The multi-channel policy data access module connects to the data sources of various partner insurance companies through a pre-developed API interface; The API interface automatically retrieves raw policy data at a preset frequency. The raw policy data formats include JSON and XML, and the data content includes policy number, policyholder information, premium amount, and policy status. If the API interface fails to capture data due to network disconnection, the multi-channel policy data access module will trigger a retry mechanism with a maximum number of retries of ≤3 and a retry interval of 10 seconds. If the retry fails, an alarm email will be sent to the technical maintenance personnel. Step 2: Data Standardization Processing; The data standardization processing module receives raw data output from the multi-channel policy data access module. The data standardization processing module receives the raw data output by the access module and calls the preset "field mapping table" and "data cleaning rules"; The field mapping table performs field name conversion, data type conversion, and outlier filtering. Output standardized policy data in a unified JSON format; Step 3: Real-time data storage and transmission; The real-time data acquisition engine module receives the standardized output data and processes it in two paths: The data is transmitted to a distributed database module and indexed and stored according to "policy number + collection time" as historical data for subsequent comparisons. Another path transmits data in real time to the policy change detection module, triggering the change detection process; The distributed database module supports fast querying by "policy number" with a response time of less than 1 second, meeting the real-time comparison requirements of the policy change detection module; Step 4: Policy Change Detection; The policy change detection module receives real-time standardized data and reads the latest historical data of the policy from the distributed database module using the "policy number"; Perform dual-mode detection on real-time data, including threshold detection and feature matching, specifically: Threshold detection: Calculates the quantitative field difference between real-time data and historical data; Feature matching: Compare non-quantized fields using the Levenshtein distance algorithm; If the dual-mode detection detects a change, it outputs a structured change result, which includes at least the policy number, the changed field, the values ​​before and after the change, the change time, the change type, and the detection method. Step 5: Trigger tiered early warning; The tiered early warning module receives the change results and matches them with tiered rules based on the "change type". Call the corresponding alert interface: Based on the change results, match the preset grading rules in the grading early warning module to trigger the corresponding level of early warning; Step 6: Store change logs on the blockchain; The consortium blockchain change log module receives the change results, automatically adds "operators," records any manual intervention, and automatically detects "system activity" without manual intervention, generating a complete log record; The consortium blockchain smart contract is invoked to write log records to the blockchain, including the distributed storage of intermediary company and insurance company nodes, to ensure that the records cannot be tampered with. Once the blockchain upload is complete, a "Blockchain upload successful" flag is returned and associated with the change result; Step 7, Results Display and Query; The front-end display module obtains warning information from the hierarchical warning module and change logs from the consortium blockchain change log module, and displays them in a dashboard format, specifically: Real-time Change List: Sorted in descending order of change time, displaying policy number, changed fields, alert level, and processing status; Early warning statistics pie chart: showing the percentage of Level 1, Level 2, and Level 3 early warnings; Log query box: Allows users to enter the policy number to query all historical change logs of the policy. The historical change logs are read from the consortium blockchain to ensure authenticity. Users can mark the status of the alert processing on the front end, and click "Processed" to update the status record of the alert module.

Images