Agricultural insurance buying verification method and system based on land right confirmation data

Abstract

The invention relates to the technical field of insurance, in particular to an agricultural insurance buying verification method and system based on land right affirmation data, and the method comprises the steps: obtaining insurance policy information submitted by an insurance applicant, matching the insurance policy information with a land right affirmation database (including land ownership information, geographic space data and historical insurance policy information), and obtaining a land right affirmation database (including land ownership information, geographic space data and historical insurance policy information); according to a preset compliance detection rule (including land use, area and ownership consistency check, support of custom area comparison threshold, and distinguishing of large individual insuring requirements), automatic detection is carried out, a compliance detection report marked with specific reasons is generated and fed back to an insurance company, and the system comprises a data acquisition module, a data matching module, a compliance detection module and a result generation module. According to the agricultural insurance buying verification method and system based on the land right confirmation data, automation of insurance policy compliance detection is realized, the detection efficiency is improved, the labor cost is reduced, the result accuracy is ensured, and the agricultural insurance buying verification method and system can be widely applied to the field of agricultural insurance.

Description

Technical Field

[0001] This invention relates to the field of insurance technology, specifically to a method and system for verifying agricultural insurance applications based on land ownership confirmation data. Background Technology

[0002] In the agricultural insurance sector, policy compliance verification is a crucial step in ensuring the authenticity and accuracy of insurance information and effectively preventing fraud. Its results directly impact the standardization of insurance operations and the risk control capabilities of insurance companies. With the increasing prevalence and development of agricultural insurance, the volume of insurance data is growing, placing higher demands on the efficiency and accuracy of policy compliance verification. Traditional policy compliance verification primarily relies on manual review, requiring staff to verify the authenticity, completeness, and consistency of insurance information with actual circumstances. This method is not only labor-intensive and time-consuming, but also inefficient. Furthermore, the long and intensive review process is prone to errors due to human negligence, making it difficult to meet the verification needs of large-scale agricultural insurance operations.

[0003] Meanwhile, the advancement of land registration has led to the increasing availability of land registration data, which contains rich information such as land ownership, area, and location, providing a reliable reference for policy compliance verification. However, current technology lacks an effective method for fully utilizing land registration data for automated policy compliance verification. It cannot efficiently match and compare land registration data with policy information, and there is a lack of standardized compliance verification rules to systematically verify insurance information. This results in policy compliance verification still facing problems of low efficiency, insufficient accuracy, and high labor costs, making it difficult to adapt to the trend of digitalization and intelligent development in agricultural insurance.

[0004] Therefore, in view of the above situation, there is an urgent need to develop an agricultural insurance underwriting verification method and system based on land ownership confirmation data to overcome the shortcomings in current practical applications. Summary of the Invention

[0005] The purpose of this invention is to provide a method and system for verifying agricultural insurance applications based on land ownership confirmation data, so as to solve the problems mentioned in the background art.

[0006] To achieve the above objectives, the present invention provides the following technical solution: A method for verifying agricultural insurance applications based on land title confirmation data includes the following steps: (1) Obtain the policy information submitted by the policyholder, wherein the policy information includes at least the name, ID number, and insured area; (2) Match the land ownership information in the land ownership database according to the ID number, the ownership information including name, ownership area and family code; (3) Verify policy information using compliance testing rules, including: Identity consistency verification: Compare whether the name in the policy matches the name in the confirmation information; Area consistency verification: Verify the consistency between the insured area and the confirmed area according to a preset threshold; (4) Generate verification results and provide feedback.

[0007] As a further solution of the present invention: In step (2), the specific method of matching the land ownership database is: query the ownership database through the ID number in the insurance policy to obtain the corresponding name, ownership area and family code.

[0008] As a further aspect of the present invention: step (3) further includes a data integrity check, specifically including: Check if the ID number format is correct; Check for duplicate insurance records; Check if there are any blank lines or incorrectly filled items in the policy information.

[0009] As a further aspect of the present invention: the area consistency verification includes family association verification. Aggregate the insured area of ​​all policyholders under the same family based on family code; Calculate the difference between the total insured area of ​​the family and the area of ​​the family with confirmed property rights; If the difference exceeds a preset threshold, the verification is deemed unsuccessful.

[0010] As a further aspect of the present invention: the configuration of the preset threshold supports two forms: Numerical form: Directly input a numerical value as the threshold; Percentage form: Calculate the percentage difference between the insured area and the confirmed area, and compare it with the percentage threshold.

[0011] As a further solution of the present invention: In step (3), when the identity consistency verification shows that the policy name is inconsistent with the confirmed name: mark the verification as abnormal and the policy information needs to be corrected after offline verification.

[0012] As a further solution of the present invention: In step (2), if no confirmation information corresponding to the ID card number is found, mark the verification as abnormal and verify the authenticity of the land ownership of the insured offline.

[0013] As a further aspect of the present invention: the verification method for the percentage threshold is as follows: Calculate (total insured area of ​​the family - area of ​​the family with confirmed property rights) / area of ​​the family with confirmed property rights; If the calculated result is greater than the percentage threshold, the verification is deemed unsuccessful.

[0014] An agricultural insurance underwriting verification system based on land title confirmation data includes: The data acquisition module is used to receive policy information; The data matching module is used to match the land ownership database based on the ID card number; The verification module is used to execute the verification rules of the method according to any one of claims 1-8; The results generation module is used to output verification results and anomaly markers.

[0015] Compared with the prior art, the beneficial effects of the present invention are: The policy compliance detection method and system based on land ownership confirmation data provided by this invention significantly improves the efficiency of policy compliance detection through automated processing, reduces manual intervention, lowers the cost and error rate of manual review, and can quickly complete the compliance detection of large-scale policies to meet the needs of the rapid development of agricultural insurance business. Meanwhile, the method and system take land ownership confirmation data as the core reference, accurately match policy information with land ownership information, geospatial data and historical policy information, and apply preset compliance detection rules for multi-dimensional verification, ensuring the accuracy and reliability of compliance detection results and effectively preventing insurance risks caused by false information or fraud. Furthermore, the method and system support custom configuration of key parameters in compliance detection rules (such as area comparison thresholds), which can flexibly adapt to the detection needs of different regions and different types of agricultural insurance businesses. It has strong practicality and scalability, and can be widely used in the field of agricultural insurance, promoting the digital and intelligent transformation of policy compliance detection. Attached Figure Description

[0016] Figure 1 This is a flowchart of the insurance policy compliance detection method based on land ownership data in an embodiment of the present invention.

[0017] Figure 2 This is a structural block diagram of the insurance policy compliance detection system based on land ownership confirmation data in an embodiment of the present invention. Detailed Implementation

[0018] 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.

[0019] The specific implementation of the present invention will be described in detail below with reference to specific embodiments.

[0020] Please see Figure 1 and Figure 2 This invention provides a method and system for verifying agricultural insurance applications based on land ownership confirmation data, which improves compliance detection efficiency, reduces labor costs, and ensures the accuracy of compliance detection results. The specific details are as follows: I. Agricultural insurance underwriting verification method based on land title confirmation data; The agricultural insurance application verification method based on land ownership confirmation data provided by this invention is applicable to the automated compliance detection of farmers' insurance policies in the agricultural insurance field. By integrating land ownership confirmation data with preset detection rules, it achieves efficient and accurate compliance judgment. The method specifically includes the following steps: (1) Data acquisition; The policyholder submits policy information through the insurance company's terminal (such as an agricultural insurance integrated service platform), and the system receives this information through a data acquisition module. The policy information includes at least: the farmer's name, ID number, farmer's address (such as administrative village), insured area (mu), and crop type (such as wheat).

[0021] Policy information is uploaded in electronic file format (e.g., Excel), and its content must meet preset format requirements, such as including fields like serial number, farmer's name, ID number, farmer's address, and insured area. After receiving the information, the data acquisition module first performs a preliminary validation of the file format to ensure that the file can be parsed correctly.

[0022] Phase 1: File Receiving and Preliminary Verification The goal at this stage is to quickly identify obviously unusable files and prevent invalid data from entering subsequent complex processing flows.

[0023] Receiving and Persisting: Action: The system receives electronic files (such as Excel files) uploaded by users through API interfaces (such as HTTP / S file upload).

[0024] Logic: Files are not directly processed in memory. Instead, they are temporarily saved to a designated directory on the server, and a unique file ID is generated for later tracking. This is to prevent large files from consuming too much memory and to ensure traceability in case of processing failures.

[0025] Preliminary verification: Verification items: File type verification: Checks if the file extension (e.g., .xlsx, .xls) meets the requirements. A further security check involves reading the file's magic number to ensure the internal file format matches the extension, preventing file spoofing.

[0026] File size check: Checks if the file size is within a preset reasonable range (e.g., 1KB~50MB). Too small a file may be empty, while too large a file may affect system performance.

[0027] Exception handling: If any verification fails, the subsequent process will be terminated immediately.

[0028] Return a clear error code and prompt message to the policyholder's terminal, for example: ERROR_FILE_TYPE: "Only Excel files in .xlsx or .xls format are supported. Please check and upload again."

[0029] ERROR_FILE_SIZE: "File size exceeds the limit. Please ensure the file is less than 50MB."

[0030] Record error logs, including file ID, user information, reason for failure, and timestamp.

[0031] Phase Two: File Parsing and Structure Verification The goal of this stage is to successfully read the file content into memory and verify whether its structure conforms to the preset template.

[0032] File parsing: Logic: Use the corresponding file parsing library (e.g., alibaba-easyexcel for Excel) to try to open the file and read the first worksheet.

[0033] Algorithm: The parsing process needs to be performed in a try-catch block to catch parsing exceptions.

[0034] Structural verification: Header validation: Logic: Read the first row of the worksheet and compare it with a predefined list of required fields. Required fields typically include: serial number, farmer's name, ID number, farmer's address, insured area, and crop type.

[0035] Algorithm: Does not rely on strict column order, but checks for exact or compatibility matches of column names (e.g., ignoring spaces). Sets or hash tables can be used to quickly determine if all preset fields exist in the file header.

[0036] Data existence check: Confirm that there are valid data rows (non-empty rows) starting from the second row.

[0037] Exception handling: ERROR_FILE_PARSE: "File cannot be read, may be corrupted. Please check file integrity and re-upload." (When a parsing exception is captured).

[0038] ERROR_FILE_HEADER: "The file header format is incorrect and the necessary field [ID number] is missing. Please download the latest template and fill it in."

[0039] Record detailed debugging information, such as the specific stack trace of the exception.

[0040] Phase 3: Data Content Verification This is the most crucial step: validating each row of data according to business rules. Validation methods typically fall into two categories: Strong validation: Must pass, otherwise the data is considered invalid.

[0041] Weak validation: A warning is generated, the data can be accepted, but further manual review is required.

[0042] Line-by-line reading and verification: Logic: Starting from the second row, read each row in a loop, map the value of each cell to the corresponding field, and perform the following validations: Detailed validation rules are shown in the table below: Phase 4: Results Summary and Feedback Processing result generation: Logic: After traversing all rows, the system generates a detailed processing report.

[0043] content: total_rows: Total number of rows.

[0044] successful_rows: The number of valid rows that passed all validations.

[0045] failed_rows: Number of invalid rows.

[0046] details: A list detailing the processing status (success / failure) and the reason for failure for each row of data.

[0047] Data delivery and feedback: Successful data processing: Convert all valid data from memory into internal system objects (such as InsurancePolicy objects) and store them in batches into the "Pending Confirmation Policies" temporary table in the database.

[0048] Feedback from users: If all steps are successful: Return "File upload successful" to the terminal.

[0049] If a failure occurs: Return "File upload failed, and the reason for the failure" to the terminal.

[0050] (2) Matching of land ownership confirmation data; The data matching module calls the land ownership database and matches the received policy information with the data in the database to verify the basic validity of the information.

[0051] The land ownership confirmation database contains three core types of data: Land ownership information includes: farmer's name, ID number, family code, contractor code, confirmed area, and confirmed address; Geospatial data includes spatial information such as the geographical location and extent of land parcels contracted by farmers; Historical insurance policy information: including the farmer's and family members' past insurance purchase records and claims records, etc.

[0052] The matching process uses "ID number" as the core search keyword, and the specific operation is as follows: The data matching module queries the corresponding ownership information in the land ownership confirmation database based on the ID number in the insurance policy, and obtains data such as the farmer's confirmed name, family code, confirmed area and confirmed address; If a matching result is found, further verify the consistency between the "farmer's name" and "farmer's address" in the policy and the confirmed data; If no matching result is found (i.e. no corresponding land ownership information), the system marks it as "requires offline verification" and prompts the insurance company to confirm whether the farmer has any special circumstances such as land transfer or land reclamation. If the ID numbers are the same but the names are different, the system will mark it as "information mismatch" and prompt that the correct name in the policy needs to be verified offline.

[0053] Land title confirmation database structure: 1. Ownership Core Table This table stores the core ownership information related to land contracting relationships.

[0054] 2. Land Parcel Details This table stores the geographic location and details of each specific piece of land.

[0055] 3. Policy History This table stores insurance records for fraud prevention and renewal verification.

[0056] II. Core Matching Process and Query Optimization Logic The matching process is a multi-step decision-making process involving complex business rules.

[0057] Step 1: Perform a precise search based on the ID number. SQL logic: SQL SELECT farmer_name, family_code, total_verified_area, verified_address FROM ownership_core WHERE farmer_idcard = ? -- Pass in the ID number from the insurance policy AND is_active = 1; Query optimization: Indexing strategy: A composite index (farmer_idcard, is_active) must be created on the farmer_idcard and is_active fields. This will make the query an efficient index lookup and avoid a full table scan.

[0058] Connection pooling: Using a database connection pool avoids creating a new database connection for each match, significantly improving performance.

[0059] Step 2: Matching Result Judgment and Multipath Processing Based on the query results, the system proceeds to different processing branches: 1. No match found (NO_MATCH) Scenario: There is no record of ownership verification for this ID number in the database.

[0060] Cause analysis and handling logic: Land transfer: Farmers transfer their land to others and no longer own any land in their own names.

[0061] Newly reclaimed land: Newly reclaimed land has not yet been included in the land ownership confirmation system.

[0062] Information entry error: The ID number in the policy was entered incorrectly.

[0063] Processing mechanism: System flag: The policy status is marked as FLAG_NEED_VERIFICATION, with the reason code NO_VERIFIED_LAND.

[0064] Workflow Trigger: Generate an "Offline Verification" task and assign it to the corresponding insurance surveyor. Task information includes the farmer's contact information, insured address, etc.

[0065] Feedback to the user: "Your information has been submitted. As we need to further verify the land situation, we will arrange for someone to contact you."

[0066] 2. Inconsistent information (INFO_MISMATCH) Scenario: The ID number is successfully matched, but the "farmer's name" in the insurance policy is not completely consistent with the farmer_name in the property rights database.

[0067] Consensus Algorithm: Exact match: Direct string comparison. (policy.name.equals(database.name)) Processing mechanism: System flags: Status flag is FLAG_NEED_VERIFICATION, reason code is NAME_MISMATCH.

[0068] Processing procedure: Offline verification is still required to confirm whether it is a name change, an entry error, or fraudulent insurance application.

[0069] 3. Address mismatch (ADDRESS_MISMATCH) Scenario: The ID card and name match, but the "farmer's address" (administrative village) in the insurance policy does not match the verified_address in the property rights database.

[0070] Matching logic: The policy address is parsed into an administrative division code and compared with the code in the database. If they do not belong to the same administrative village, the addresses are marked as inconsistent.

[0071] Processing mechanism: Risk Level: This situation carries a high risk and may involve insurance coverage on land without confirmed ownership.

[0072] System flag: Flagged as FLAG_NEED_VERIFICATION, reason code is ADDRESS_MISMATCH.

[0073] Strong reminder: Surveyors need to focus on verifying whether there are any issues such as cross-village contracting or incorrect address entry.

[0074] (3) Application of compliance testing rules; The compliance detection module loads a pre-set compliance detection rule library and performs multi-dimensional compliance detection based on the matched land ownership data and insurance policy information, including data integrity checks and core compliance checks.

[0075] ① Data integrity check; ID card number correctness check: Verify whether the ID card number format conforms to national standards (such as 18 digits, including date of birth and check code, etc.). If the format is abnormal, it will be marked as "failed". Duplicate insurance detection: By comparing historical policy information, check whether there are duplicate insurance records for the same ID number in the same crop and the same time period. If so, mark it as "duplicate insurance". Format compliance check: Check for blank lines, missing fields (such as missing insured area) and incorrect data format (such as insured area being entered as a non-numeric field) in the policy information. If any of these are found, mark them as "incorrectly filled".

[0076] ② Core compliance checks; Ownership consistency check: Name and ID number consistency: Check whether the name on the policy matches the name associated with the corresponding ID number in the land ownership confirmation database. If they do not match, mark it as "ownership information mismatch". Address consistency: Verify whether the farmer's address in the insurance policy is consistent with the confirmed address (such as administrative village, community village committee). If the difference is large, it is necessary to further verify the land plot correlation by combining geospatial data.

[0077] Area consistency check: Individual dimension check: Calculate the difference between the insured area and the actual area of ​​a single farmer. If the difference exceeds the preset threshold, it is marked as "individual area exceeds the threshold". Family-level check: Query the corresponding "family code" by ID number, sum the insured area of ​​all members under the same family code to get the "total insured area of ​​the family"; compare the sum with the total area of ​​the family's property rights (i.e. the sum of the property rights areas of all members under the same family code), and if the difference exceeds the preset threshold, it is marked as "family area exceeds the threshold".

[0078] The area comparison threshold supports two custom configuration methods: Numerical format: Directly input a specific value (e.g., 5 mu). If the difference between the insured area and the confirmed area exceeds this value, it will be considered as failing. Percentage format: Enter a percentage (e.g., 10%). If the ratio of (insured area - confirmed area) / confirmed area exceeds this percentage, it is considered a failure. For example, if the confirmed area is 5 mu and the insured area is 5.6 mu, the difference is 12% (0.6 / 5). If the threshold is set to 10%, it will be considered a failure.

[0079] Large / Retail Investor Qualification Check: Large-scale farmers are defined as business entities with an insured area of ​​50 mu or more, and must meet the requirement of "one policy per farmer"; Individual farmers are defined as farmers with an insured area of ​​less than 50 mu (approximately 3.3 hectares). They usually purchase insurance through the village committee and support "one policy for multiple farmers". The system verifies whether farmers meet the "large-scale farmer / small-scale farmer" type they declared based on the insured area and the number of policies. If they do not meet the criteria, the system marks them as "unqualified".

[0080] (4) Generation of compliance testing results; The results generation module generates a detailed compliance testing report based on the output of the compliance testing module. The report content must include at least: Basic policy information: policy number, coverage period, crop type, and total insured area, etc. Summary of test results: Number of policies that passed / failed, names and ID numbers of farmers who failed; Detailed explanation of reasons for failure: For each policy or farmer that failed, the specific reason is noted (such as "family area exceeds the threshold by 8.51 mu", "abnormal ID card format" and "name does not match the property rights information").

[0081] For example, in a certain insurance policy, farmers Lan Lei and Lan Jingyin are members of the same family (with the same family code). The total insured area of ​​the family is 12 mu, while the total confirmed area of ​​the family is 3.49 mu. The difference between the two is 8.51 mu. If the preset threshold is 5 mu, the report will mark "Family area exceeds the threshold of 8.51 mu, not passed".

[0082] (5) Results feedback; The results generation module feeds back the compliance test report to the insurance company's terminal (such as the work dashboard of the agricultural insurance integrated service platform). The insurance company can view the report details, download the list of those who failed, and conduct manual review or offline verification of the failed items through the terminal. Finally, the insurance company decides whether to underwrite based on the report results.

[0083] I. Module Initialization and Rule Loading Before the detection begins, the system needs to load a configurable rule base. This is achieved through a rule engine and a configuration center.

[0084] 1. Rule base data structure Rules are defined as configurable objects and stored in a database or configuration file.

[0085] 2. Rule Loading Algorithm Logic: When the system starts, it loads all rules with is_active = true from the database, sorts them by priority, and caches them in memory.

[0086] Code logic: Java First, the component calls the data persistence layer interface to query all active rule definitions from the rule configuration repository. These rule definitions include at least a unique rule identifier, a rule execution priority parameter, and a rule judgment logic expression.

[0087] The component then sorts the retrieved rule set, arranging them in ascending order according to the rule execution priority parameter to ensure that high-priority rules are executed first.

[0088] Finally, the component converts the sorted rule set into an in-memory key-value mapping structure, where the rule's unique identifier serves as the key and the corresponding rule configuration object serves as the value. This mapping structure provides data support for the rapid retrieval and execution of rules during subsequent compliance checks.

[0089] Through the above initialization process, the system completes the preloading and preprocessing of compliance detection rules during the service startup phase, laying the foundation for the automatic and orderly execution of multi-dimensional compliance detection after receiving policy data.

[0090] This technical approach, through preloading and sorting mechanisms, ensures the controllability and efficiency of the compliance testing process, enabling the system to execute complex multi-rule verifications according to predetermined business logic.

[0091] II. Data Integrity Check Algorithm 1. ID number accuracy check Algorithm: This is a combination of a deterministic finite automaton (DFA) and a checksum calculation.

[0092] Step 1: Regular expression matching regex ^\d{17}[\dXx]$ / / Matches 18 characters, the first 17 are digits, and the last character is either a digit or an X. Step 2: Validation of Date of Birth Extract the birth date (yyyyMMdd) from the 7th to 14th digits of the ID number.

[0093] Use a date library (such as Java's LocalDate) to verify whether it is a valid calendar date.

[0094] Step 3: Verification Code Algorithm: Using GB 11643-1999 standard.

[0095] logic: Multiply the first 17 digits by the weighting coefficients: [7, 9, 10, 5, 8, 4, 2, 1, 6, 3, 7, 9, 10, 5, 8, 4, 2].

[0096] Sum the 17 products.

[0097] Divide the sum by 11 and get the remainder.

[0098] Map the remainders to the checksums: ['1', '0', 'X', '9', '8', '7', '6', '5', '4', '3', '2'].

[0099] The calculated verification code is compared with the last digit of the ID card; if they match, the verification is successful.

[0100] 2. Duplicate Insurance Detection Algorithm: Efficient query based on set membership detection.

[0101] SQL logic: First, a database query is constructed. This query performs an exact match query on the historical policy data table based on three key fields: farmer's ID number, insured crop type, and policy year. The query logic is to count the number of records that simultaneously meet the following three conditions: The farmer's ID number is completely consistent with the ID number used in the current insurance application; The types of crops covered by the insurance are exactly the same as those in the current insurance application. The policy year is exactly the same as the current application year; To improve query efficiency, the system has established a multi-field composite index structure at the database level. This index uses the aforementioned three query fields (farmer's ID number, insured crop type, and policy year) as the composite key. Through this index structure, the database system can directly locate records that meet all query conditions without performing a full table scan.

[0102] 3. Format conformity check Algorithm: Most of the work has been completed in the data parsing stage, and secondary verification can be performed here.

[0103] Blank lines / missing fields: Checks whether the required fields of the parsed data object are null or empty strings.

[0104] Data format error: Use type checking and regular expressions.

[0105] Insured area: instanceof Number or isnumeric(), and check if it is greater than 0.

[0106] Farmer's name: regular ^[\u4e00-\u9fa5]{2,20}$ (2-20 Chinese characters).

[0107] III. Core Compliance Check Algorithm 1. Ownership consistency check Premise: This check has been initially completed in the "Data Matching Module" and the final decision is made here.

[0108] Name Consistency Algorithm: Exact match: Direct string equality comparison. `policyName.equals(verifiedName)` Fuzzy matching (fault tolerance): Java / / Using the Jaro-Winkler similarity algorithm from the Apache Commons Lang3 library double similarity = StringUtils.getJaroWinklerDistance(policyName,verifiedName); if (similarity >= config.getNameSimilarityThreshold()) { / / The threshold is usually set to 0.9 return "PASS"; } else { return "FAIL_NAME_MISMATCH"; } Address consistency algorithm: Logic: Based on administrative division code comparison, not strings.

[0109] step: The "farmer's address" in the insurance policy is parsed into the standard administrative village / community code using an address parser (such as a reverse address matching algorithm based on a trie tree).

[0110] Compare this code with the admin_code in the ownership confirmation data.

[0111] Geospatial verification (advanced): If the address codes are inconsistent but adjacent, GIS services can be called to determine the spatial relationship between the insured land parcel and the land parcel with confirmed ownership (such as intersection, inclusion, distance). If it is within a reasonable range, it can be marked as a warning rather than an error.

[0112] 2. Area Consistency Check This is the most complex part, involving multi-dimensional aggregation calculations.

[0113] Personal dimension inspection algorithm: Java This verification method is implemented through the following steps: First, the system extracts the sum of all insured area values ​​from the currently processed policy object, and at the same time obtains the corresponding confirmed area value from the matched land ownership data object.

[0114] Next, the system calls the threshold check function, passing the aforementioned two area values ​​and the preset compliance rules as input parameters. This threshold check function executes the following judgment logic based on the rule configuration: If the rule is configured as an absolute value threshold mode, the arithmetic difference between the insured area and the confirmed area is calculated, and this difference is compared with the fixed area threshold set in the rule.

[0115] If the rule is configured as a percentage threshold mode, the difference between the insured area and the confirmed area is calculated first, then the difference is divided by the confirmed area to obtain the percentage value, and finally the percentage value is compared with the percentage threshold set in the rule.

[0116] Ultimately, the verification process generates a standardized compliance test result object, which contains the following information: A status indicator indicating whether the verification has passed; The specific difference or percentage; The corresponding prompts and suggested solutions; Family dimension inspection algorithm: Step 1: Family Information Aggregation SQL -- Obtain the total registered area of ​​the household First, an inner-layer query is executed, retrieving the corresponding family code from the core land ownership data table based on the ID number of the currently insured farmer. This family code is a unique symbol identifying the farmer's family unit within the system.

[0117] Next, the outer query is executed, using the family code returned by the inner query as a condition to filter out all records that match the family code in the core land ownership data table.

[0118] Finally, the area field of the confirmed ownership in the outer query result set is summed to obtain the total confirmed ownership area of ​​the farmer's family.

[0119] Step 2: Threshold Determination Java / / Unified threshold checking function First, calculate the numerical difference between the insured area and the confirmed area. This difference reflects the degree of deviation between the insured area and the confirmed area.

[0120] Next, the preset threshold rule configuration is obtained, which includes two key parameters: threshold type and threshold value. The threshold type is divided into two modes: absolute value mode and percentage mode.

[0121] If the threshold type is absolute value mode, the aforementioned difference is directly compared with the fixed area threshold set in the rule. When the difference is greater than the fixed threshold, a conclusion of verification failure is generated, and the specific area value exceeding the threshold is clearly marked in the result information.

[0122] If the threshold type is percentage mode, the following calculation is performed: First, calculate the ratio of the difference to the confirmed area, then convert the ratio into a percentage form. Next, compare this percentage value with the percentage threshold set in the rule. When the calculated percentage is greater than the set threshold, a verification failure conclusion is generated, and the percentage value exceeding the threshold is precisely indicated in the result information, retaining two decimal places.

[0123] If neither of the above two threshold comparisons triggers a failure condition, then a conclusion of verification success is generated.

[0124] 3. Qualification check of large / small investors Algorithm: Based on conditional logic and counting.

[0125] logic: Java First, determine the type of business entity declared by the policyholder. If the declared type is "large enterprise," then perform the following dual-condition verification: Verify whether the insured area of ​​a single farmer exceeds the legal threshold of the number of acres configured by the system; Second, it verifies whether the number of farmers included in the current policy is 1. This measure aims to prevent the impersonation of large-scale farmers by packaging and merging multiple small farmers.

[0126] If either of the above two conditions is not met, the qualification will be deemed non-compliant and the verification will fail.

[0127] IV. Detection Execution Engine and Result Generation 1. Execution Process The detection engine iterates through all active rules according to priority and performs checks on each policy data.

[0128] This verification method is implemented through the following steps: First, create an initial compliance inspection report object, which is associated with the policy data currently pending verification and is used to record all subsequent verification results.

[0129] Next, the system iterates through all active compliance verification rules in a predetermined order. For each rule, the system calls the rule execution engine, takes the policy data and the matching land title confirmation data as input parameters, executes the verification logic corresponding to that rule, and generates the verification result for that single rule.

[0130] Then, add the verification result of this single rule to the compliance detection report as a detailed entry in the report.

[0131] During the rule execution process, the system supports a configurable short-circuit return mechanism: when a certain rule is marked as a critical rule and its verification result fails, the system will abort the execution of subsequent rules and directly jump out of the loop. This mechanism ensures that critical compliance issues can be immediately identified and quickly responded to, improving the system processing efficiency.

[0132] After completing all rule traversals or triggering a short-circuit return, the system calls the report summary generation function to calculate and generate a summary conclusion based on all the executed rule verification results, including information such as the overall verification status, the statistics of the number of passed / failed rules, etc.

[0133] Finally, the system returns this complete compliance detection report containing the detailed verification results and the overall summary conclusion.

[0134] 2. Result Generation and Feedback Data Structure: json { "policyId": "P202405200001", "overallStatus": "FAIL", "summary": { "totalChecks": 8, "passed": 5, "failed": 3 }, "details": { "ruleId": "RULE_FAMILY_AREA", "ruleName": "Family Total Area Consistency Check", "status": "FAIL", "message": "The total insured area of the family (12.0 mu) exceeds the confirmed right area (3.49 mu) by 8.51 mu, exceeding the absolute value threshold (5.0 mu).", "failedSubjects": {"name": "Lan Lei", "idcard": "..."}, {"name": "Lan Jingyin", "idcard": "..."} , "suggestion": "Please verify whether the family has a land transfer contract or has acquired new arable land." }, { "ruleId": "RULE_ID_CARD_FORMAT", "ruleName": "ID card format verification", "status": "PASS", "message": "" } / / ... other rule results ] } Feedback mechanism: Real-time API response: The above JSON report will be returned to the front-end work dashboard in real time.

[0135] Batch file download: Provides a "Download Failed List" function, which generates a CSV or Excel file for easy offline processing.

[0136] Workflow Integration: For policies marked as "Not Passed", an "Artificial Review" task is automatically created in the insurance company's workflow system and assigned to the appropriate personnel.

[0137] II. Agricultural insurance underwriting verification system based on land ownership confirmation data; The present invention also provides a system for implementing the above method, the system comprising the following modules: Data acquisition module: Used to receive policy information (such as Excel format files) submitted by policyholders and to perform preliminary verification of the file format; Data matching module: Used to call the land ownership database, match the corresponding ownership information, geospatial data and historical insurance policy information with ID number as the keyword, and return the matching results (including information matching, information inconsistency and no matching information, etc.). Compliance Detection Module: Loads the compliance detection rule library and performs data integrity checks (ID card format, duplicate insurance and format specifications, etc.) and core compliance checks (ownership consistency, area consistency and large / small customer qualifications, etc.) based on the matching results. Results generation module: Generates a test report containing detailed reasons based on the compliance test results, and feeds the report back to the insurance company's terminal.

[0138] I. Data Transfer and Technical Interfaces Between Modules 1. Compliance testing module → Result generation module (inter-service call) This is the most core internal data interaction, usually adopting an asynchronous message-driven mode to achieve decoupling and high-concurrency processing.

[0139] Trigger method: After the compliance detection module completes the preliminary verification and data matching, it pushes an event to the message queue.

[0140] Technology selection: RabbitMQ Message format (JSON Schema): json / / Topic / Exchange: `compliance.check.trigger` { "eventId": "EVT_20240520120000001", / / Unique event ID "eventType": "COMPLIANCE_CHECK_REQUESTED", "timestamp": "2024-05-20T12:00:00.000Z", "payload": { "batchId": "BATCH_20240520001", / / Batch ID, used to associate multiple insurance policies uploaded in the same file "policyId": "POL_2024052000001", / / Unique insurance policy ID "insuredInfo": { "farmerName": "Lan Lei", "idCard": "410725199001011234", "insuredArea": 12.0, "cropType": "Wheat", "farmerType": "Individual farmer" / / Large farmer / Individual farmer }, "matchedLandData": { "verifiedName": "Lan Lei", "familyCode": "FAM_41072500102", "totalVerifiedArea": 3.49, "verifiedAddress": "XX Village, XX County, Xinxiang City, Henan Province", "familyMembers": {"name": "Lan Lei", "idCard": "410725199001011234", "verifiedArea": 2.0}, {"name": "Lan Jingyin", "idCard": "410725196501011235", "verifiedArea": 1.49} }, "checkTriggeredBy": "system", "checkPriority": "normal" } } 2. Internal Processing of Result Generation Module Input: Consume the above MQ message.

[0141] Processing Logic: Parse the message: Extract the policyId and all relevant data.

[0142] Load rules: Load all activated compliance rules from the rule engine or configuration center.

[0143] Execute detection: Traverse the rules by priority, calculate and judge the received data (algorithm see previous reply).

[0144] Generate report: Summarize the judgment results of each rule to form structured report data.

[0145] Persistent storage: Save the full text of the report (especially the HTML / PDF version containing a large number of details) to object storage, and store the index information and summary of the report in the business database.

[0146] 3. Result Generation Module → Database / Storage (Data Persistence) Technical Selection: Report summary / index: MySQL / PostgreSQL.

[0147] Full text of report (large file): AWS S3 / Alibaba Cloud OSS / Tencent Cloud COS.

[0148] II. Interface with Insurance Company Terminal (API Design) The front end interacts with the back end through a set of well-defined RESTful APIs to obtain the detection status and results.

[0149] ​1. Real-time status query interface Purpose: After a file is uploaded, the front-end polls or obtains the overall progress of batch processing via WebSocket.

[0150] Endpoint: GET / api / v1 / compliance / check / batches / {batchId} / status Response example: json { "code": 200, "message": "success", "data": { "batchId": "BATCH_20240520001", "totalPolicies": 150, "processedPolicies": 150, "status": "COMPLETED", / / Possible values: PROCESSING, COMPLETED, FAILED "summary": { "passed": 120, "failed": 30, "warnings": 10 } } } 2. Test Report Acquisition Interface Purpose: Click on a specific batch or policy on the work dashboard to view detailed reports.

[0151] Endpoint: GET / api / v1 / compliance / reports?batchId={batchId}&policyId={policyId} Response example: json { "code": 200, "message": "success", "data": { "batchId": "BATCH_20240520001", "policyId": "POL_2024052000001", "overallStatus": "FAIL", "checkTime": "2024-05-20T12:05:30.000Z", "reportUrl": "https: / / oss.example.com / reports / POL_2024052000001.pdf", / / Link to the downloadable detailed report "details": [ { "ruleName": "Family Total Area Consistency Check", "status": "FAIL", "message": "The total insured area of ​​the family (12.0 mu) exceeds the confirmed area (3.49 mu) by 8.51 mu, which exceeds the absolute value threshold (5.0 mu).", "failedSubjects": [ {"name": "Zhang San", "idcard": "410725199001011234"}, {"name": "Li Si", "idcard": "410725196501011235"} ], "suggestion": "Please verify whether the family has a land transfer contract or has acquired new arable land." } / / ... other rule results ] } } 3. Failed to download the list via the API. Purpose: To provide the function of downloading the list of farmers who failed the test in batches, so as to facilitate offline contact and verification.

[0152] Endpoint: GET / api / v1 / compliance / reports / {batchId} / download / failed-list Response: Returns a CSV file stream with the following structure: csv Policy number, farmer's name, ID number, reason for failure, suggested steps POL_2024052000001, Zhang San, 410725199001011234, "Family area exceeds threshold by 8.51 mu", "Offline verification of land transfer status" POL_2024052000001, Li Si, 410725196501011234,"Family area exceeds threshold by 8.51 mu","Verify land transfer status offline" POL_2024052000002, Wang Wu, 410725198502021234,"ID card format error", "Please have farmers verify and correct their ID card information" IV. Security and Encryption Transmission Scheme To ensure the security of sensitive data (such as ID card numbers), end-to-end encryption must be implemented.

[0153] HTTPS / TLS 1.3 transport encryption Requirements: All API interfaces (frontend ↔ backend, backend ↔ backend) must use the HTTPS protocol and disable the insecure TLS version.

[0154] Encrypted storage and transmission of sensitive information Algorithm: Use AES-256-GCM or the national cryptographic algorithm SM4 to encrypt sensitive fields.

[0155] accomplish: Front-end: Before submitting the policy documents, use the public key (RSA or SM2) provided by the back-end to encrypt fields such as the ID number.

[0156] Backend: Upon receiving encrypted data, decrypt it using the private key. When transmitting messages between internal systems (such as MQ messages), the idCard field is encrypted again using AES. When storing data in the database, it should be in ciphertext.

[0157] Key Management: Use KMS (Key Management Service) or HashiCorp Vault to uniformly manage encryption keys, enabling key rotation and secure storage.

[0158] API Authentication and Authorization Mechanism: JWT (JSON Web Token) or OAuth 2.0.

[0159] Process: After logging in, the insurance company user obtains a time-limited JWT. When calling any subsequent APIs, the HTTP Header Authorization: Bearer is used to... <token>The Token is carried by the user. The backend gateway is responsible for verifying the legality of the Token.

[0160] Through the agricultural insurance application verification method and system based on land right data, the application of the present application realizes the automatic processing of the agricultural insurance policy compliance detection, not only reduces the workload of manual auditing, but also ensures the accuracy of the detection result through the deep application of the land right data, effectively prevents the insurance fraud risk, and is suitable for the large-scale compliance detection needs of various agricultural insurance scenes.

[0161] (I) Technical scheme overview The core of the present application is to construct a multi-level automatic verification pipeline, through four core steps of data acquisition and verification -> data matching -> compliance detection -> result generation and feedback, to deeply cross-verify the policy information and the land right database, and to apply a configurable compliance rule library for multi-dimensional risk identification.

[0162] (II) Specific technical means In order to achieve the above purpose, the present application adopts the following specific technical means: 1. Data acquisition and structured analysis module Technical means: The system receives the electronic policy file uploaded by the applicant (such as Excel format) through the defined RESTful API interface.

[0163] Use a specific file parsing library (such as Apache POI for Java, OpenPyXL for Python) to parse the file and extract its content into a structured data object in memory (such as Java Bean or Python Dictionary).

[0164] Implement a step-by-step verification algorithm: First step: file-level verification. Verify the file type by checking the file extension and magic number (Magic Number); verify the file size legality by comparing it with the preset threshold.

[0165] Second step: structure-level verification. Read the parsed data table header and compare it with the preset required field set (including "farmer's name", "ID number", "farmer's address", "insured area", "crop type") to ensure the structure integrity.

[0166] Third step: data-level verification. For each row of data, use regular expressions, data type conversion and range checking algorithms to verify the ID number format, name characters, insured area as a positive number, etc.

[0167] 2. Data matching and association module Technical means: Establish and connect to a structured land right confirmation relationship database, which at least contains: Ownership main table: Take farmer_idcard (farmer ID card number) as the primary key or unique index, associate farmer_name (confirmation name), family_code (family code), total_verified_area (total verified area), verified_address (verified address) and other fields.

[0168] Land block detail table: Associated with the ownership main table through farmer_idcard, store land block information containing geo_polygon (geospatial polygon) field.

[0169] History insurance table: Store past insurance records, key fields include farmer_idcard, insured_crop (insured crop), insured_area (insured area), claim_status (claim status).

[0170] Execute precise and fuzzy matching algorithms: Take the ID number in the insurance policy as the key, execute SQL query in the ownership main table to get the right confirmation information. To achieve high-performance query, a database index is established on the farmer_idcard field.

[0171] For name matching, use string similarity algorithms (such as Jaro-Winkler algorithm) to calculate the similarity score between the insurance policy name and the right confirmation name. If the score is lower than the preset threshold (such as 0.9), it is marked as inconsistent.

[0172] For address matching, convert both the insurance policy address and the right confirmation address into national standard administrative division codes for comparison to ensure consistency.

[0173] 3. Compliance detection rule engine module Technical means: Build a configurable rule library, rules are stored in the form of data objects, including rule ID, name, threshold type (absolute value / percentage), threshold value, whether activated and other attributes.

[0174] The rule engine loads and iterates through these rules according to priority, and performs the following core detection algorithms for each insurance policy: Area consistency check: Individual area check: Calculate insured_area - individual_verified_area.

[0175] Household Area Check: Aggregate the total insured area and the total certified area of the household through the family_code, then calculate the difference.

[0176] Compare the difference with the threshold configured in the rules: if it is an absolute value threshold, compare directly; if it is a percentage threshold, calculate (difference / certified area) * 100% and then compare.

[0177] Big / Small Household Qualification Check: Use conditional judgment logic: if declared as "big", check if the insured area > 50 and the number of households in the policy == 1; if declared as "small", check if the insured area of each household in the policy < 50.

[0178] Duplicate Insurance Check: Construct a SQL query to search for valid policy records with the same ID card number, the same crop, and the same year in the historical policy table.

[0179] 4. Result Generation and Feedback Module Technical Means: Structured Report Generation Algorithm: Aggregate the detection results of each rule (pass / fail, detailed information, failed subject list) into a JSON structured report data object.

[0180] Asynchronous Processing Mechanism: The compliance detection module publishes detection events to this module through a message middleware (such as RabbitMQ), and this module acts as a consumer to process asynchronously, achieving system decoupling.

[0181] Dual Storage Strategy: Store the report summary (such as policy number, overall status) in a relational database (such as MySQL); store the generated detailed report file (PDF / HTML format) in an object storage service (such as AWS S3 or Aliyun OSS), and return an accessible URL.

[0182] Front-end Data Interface: Provide RESTful API based on HTTP protocol for insurance company terminal calls. Key interfaces include: GET / api / v1 / compliance / reports?policyId={policyId}: Return detailed detection results in JSON format.

[0183] GET / api / v1 / compliance / reports / {batchId} / download / failed-list: Return a CSV format failed list file stream.

[0184] By implementing the above technical means, the present application achieves the following remarkable effects: Automation and high efficiency: No manual intervention is required in the whole process, realizing batch and automated processing of insurance verification, and the processing efficiency is improved by more than 90%.

[0185] Accuracy and risk control ability: Through deep matching with authoritative land right data and complex rule calculation, risks such as area falsification, ownership inconsistency and repeated insurance can be accurately identified, effectively preventing fraud.

[0186] Flexibility and scalability: Based on the design of a configurable rule base, business rules can be flexibly adjusted and extended without modifying the core code, which can quickly adapt to policy changes and new risks.

[0187] System stability and security: The use of asynchronous messages, database indexing, object storage and other technologies ensures the stability and data security of the system in high-concurrency scenarios.

[0188] Based on the data structure, algorithm logic, module division and technology selection described in the present application, a general programming language (such as Java, Python) and mature middleware (such as MySQL, PgSQL, RabbitMQ, Redis, S3) can be used in a conventional cloud computing or server environment to repeatedly implement the agricultural insurance automatic verification system described in the present application. The specific threshold of the rule base (such as the number of mu or percentage of area over-limit) can be configured and adjusted by the implementation unit according to the local specific policy, and these adjustments belong to the conventional operation within the technical solution framework of the present application.

[0189] It should be noted that in the present application, although the present application is described in terms of embodiments, each embodiment does not contain only one independent technical solution, and the description manner of the specification is only for the sake of clarity. The skilled person should consider the specification as a whole, and the technical solutions in each embodiment can be appropriately combined to form other embodiments that the skilled person can understand.< / token>

Claims

1. A method for verifying agricultural insurance applications based on land ownership confirmation data, characterized in that, Includes the following steps: (1) Obtain the policy information submitted by the policyholder, wherein the policy information includes at least the name, ID number, and insured area; (2) Match the land ownership information in the land ownership database according to the ID number, the ownership information including name, ownership area and family code; (3) Verify policy information using compliance testing rules, including: Identity consistency verification: Compare whether the name in the policy matches the name in the confirmation information; Area consistency verification: Verify the consistency between the insured area and the confirmed area according to a preset threshold; (4) Generate verification results and provide feedback.

2. The agricultural insurance underwriting verification method and system based on land ownership confirmation data according to claim 1, characterized in that, In step (2), the specific method of matching the land ownership database is as follows: query the ownership database through the ID number in the insurance policy to obtain the corresponding name, ownership area and family code.

3. The agricultural insurance underwriting verification method and system based on land ownership confirmation data according to claim 1, characterized in that, Step (3) also includes data integrity checks, specifically including: Check if the ID number format is correct; Check for duplicate insurance records; Check if there are any blank lines or incorrectly filled items in the policy information.

4. The agricultural insurance underwriting verification method and system based on land ownership confirmation data according to claim 1, characterized in that, The area consistency verification includes family association verification: Aggregate the insured area of ​​all policyholders under the same family based on family code; Calculate the difference between the total insured area of ​​the family and the area of ​​the family with confirmed property rights; If the difference exceeds a preset threshold, the verification is deemed unsuccessful.

5. The agricultural insurance underwriting verification method and system based on land ownership confirmation data according to claim 4, characterized in that, The preset threshold configuration supports two forms: Numerical form: Directly input a numerical value as the threshold; Percentage form: Calculate the percentage difference between the insured area and the confirmed area, and compare it with the percentage threshold.

6. The agricultural insurance underwriting verification method and system based on land ownership confirmation data according to claim 1, characterized in that, In step (3), when the identity consistency verification shows that the policy name is inconsistent with the confirmed name: mark the verification as abnormal and the policy information needs to be corrected after offline verification.

7. The agricultural insurance underwriting verification method and system based on land ownership confirmation data according to claim 1, characterized in that, In step (2), if no confirmation information corresponding to the ID number is found, mark the verification as abnormal and verify the authenticity of the insured's land ownership offline.

8. The agricultural insurance underwriting verification method and system based on land ownership confirmation data according to claim 5, characterized in that, The verification method for the percentage threshold is as follows: Calculate (total insured area of ​​the family - area of ​​the family with confirmed property rights) / area of ​​the family with confirmed property rights; If the calculated result is greater than the percentage threshold, the verification is deemed unsuccessful.

9. An agricultural insurance underwriting verification system based on land ownership confirmation data, characterized in that, include: The data acquisition module is used to receive policy information; The data matching module is used to match the land ownership database based on the ID card number; The verification module is used to execute the verification rules of the method according to any one of claims 1-8; The results generation module is used to output verification results and anomaly markers.

Images