Insurance supervision report data processing method and device, storage medium and processor
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- CHINA CONSTRUCTION BANK
- Filing Date
- 2023-09-22
- Publication Date
- 2026-07-03
AI Technical Summary
The different organizational levels and custodian banks of different insurance companies lead to the need for manual adjustment of summary rules, resulting in a large workload for development and maintenance and a long response cycle.
Configure reporting nodes according to the organizational structure of the reporting party, configure synthesis rules according to the report type, collect source data from the custodian bank system, perform verification and synthesis, and automatically generate regulatory reports.
It enables flexible adaptation to different insurance company reporting levels, automates report generation, improves reporting efficiency, and reduces manual development and maintenance costs and response time.
Smart Images

Figure CN117194531B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of big data technology, specifically to a method for processing insurance regulatory reporting data, a device for processing insurance regulatory reporting data, a processor, a machine-readable storage medium, and a computer program product. Background Technology
[0002] The insurance industry is a special industry that manages risks and is an important component of the social and economic compensation system. It bears a great responsibility for the stability of the social economy and the well-being of the people. Strict state supervision of the insurance industry is necessary to effectively protect the interests of industries and the public related to insurance activities.
[0003] Insurance companies are required to submit reports to regulatory agencies on a regular basis, as per regulatory requirements. Since insurance funds are held in custodian banks, which are responsible for fund transfers and accounting, insurance companies often obtain asset data for different custodian products from these banks and manually integrate and summarize this data to ultimately create a report that complies with regulatory requirements.
[0004] Because different insurance companies have different organizational levels (some have subsidiaries), different types of insurance products, and different custodian banks, the aggregation rules need to be manually adjusted according to the specific level when aggregating the data. The aggregation rules of the conventional reporting system often need to be customized according to the reporting level of each company, which results in a large workload for development and maintenance. Summary of the Invention
[0005] The purpose of this application is to provide a method, apparatus, storage medium, and processor for processing insurance regulatory reporting data. The method configures the reporting hierarchy nodes according to the reporting party's organizational structure, configures report synthesis rules according to the report type, and acquires, verifies, and summarizes the reported report data level by level. This achieves adaptation to the reporting hierarchy management of different insurance companies, automatically synthesizes reports according to preset rules, and improves reporting efficiency.
[0006] To achieve the above objectives, the first aspect of this application provides a method for processing insurance regulatory reporting data, the method comprising:
[0007] Configure reporting nodes according to the organizational structure and asset status of the reporting party;
[0008] Configure report synthesis rules according to report type;
[0009] Collect source data from different custodian bank systems based on the current target report type;
[0010] The source data is validated based on the current target report type to obtain the data to be submitted;
[0011] Based on the report synthesis rules corresponding to the current target report type and the reporting node, the data to be reported is synthesized and processed into the target reporting report.
[0012] Based on the aforementioned technical means, the reporting hierarchy nodes can be configured according to the organizational structure of the reporting party, which can flexibly adapt to different reporting level requirements. The report synthesis rules can be configured according to the report type, and the reported report data can be automatically acquired, verified, and summarized level by level. This achieves adaptation to the reporting level management of different insurance companies, and automatically synthesizes reports according to preset rules, thereby improving reporting efficiency.
[0013] In this embodiment of the application, source data is collected from different custodian bank systems according to the current target report type, including:
[0014] Retrieve the required reporting fields from the target report template based on the current target report type;
[0015] Based on the required reporting fields, source data is collected from different custodian bank systems and stored in the local original database table.
[0016] Based on the above technical means, the required reporting fields are determined from the target report template, and then the source data is collected according to the required reporting fields. This can accurately obtain the required source data from different custodian bank systems, reduce the amount of source data, and improve processing efficiency.
[0017] In this embodiment of the application, source data is collected from different custodian bank systems according to the required reporting fields, including:
[0018] Determine the target data fields corresponding to the required reporting fields in different custodian bank systems based on the preset field mapping relationship;
[0019] Collect source data from the current custodian bank system based on the target data fields in the current custodian bank system.
[0020] Based on the aforementioned technical means, the data that needs to be collected in the non-custodial bank system can be accurately determined according to the preset field mapping relationship, effectively realizing the interoperability between data and required reporting fields in different custodial bank systems and reducing subsequent data synthesis errors.
[0021] In this embodiment of the application, the source data is validated according to the current target report type to obtain the data to be reported, including:
[0022] Based on the current asset status in the custodian bank system, perform non-empty verification on the source data collected in the current custodian bank system;
[0023] If the non-empty verification is successful, check whether the data types of different table fields in the current target report are consistent with the data types of the corresponding table fields in the source data. If they are consistent, the data type verification is successful, and the current source data is used as the data to be submitted.
[0024] Based on the above technical means, source data with verification anomalies can be eliminated, thereby improving the accuracy of the reporting reports synthesized from the data to be reported.
[0025] In this embodiment of the application, based on the asset status in the current custodian bank system, a non-empty verification is performed on the source data collected in the current custodian bank system, including:
[0026] Get the current asset status in the custodian bank's system;
[0027] If the current custodian bank system contains assets but the source data collected in the current custodian bank system is empty, or if the current custodian bank system does not contain assets but the source data collected in the current custodian bank system is not empty, then the non-empty verification fails; otherwise, the non-empty verification passes.
[0028] Based on the above technical means, it is possible to verify whether the source data matches the custodian bank's asset situation, thereby reducing source data anomalies.
[0029] In this embodiment of the application, the method for processing the insurance regulatory reporting data further includes:
[0030] Import the data to be reported into the database table to be reported, and import the data that fails the non-empty check and the data that fails the data type check into the database table that fails the check.
[0031] Based on the aforementioned technical means, using different database tables to store the data to be submitted and the data that failed verification can facilitate review during the subsequent review process of the target report.
[0032] In this embodiment of the application, the data to be reported is synthesized and processed into a target reporting report according to the report synthesis rules corresponding to the current target report type and the reporting node, including:
[0033] Determine the target data field in the data to be reported based on the preset field mapping relationship;
[0034] Based on the report synthesis rules corresponding to the current target report type, the target data fields in the data to be reported are synthesized and processed sequentially from the last node upwards according to the reporting node to obtain the target reporting report.
[0035] Based on the above technical means, the required reporting fields in different source data are processed and synthesized to obtain the target reporting report.
[0036] In this embodiment of the application, the method for processing the insurance regulatory reporting data further includes:
[0037] Once the target report has been verified, it will be sent to the regulatory authority.
[0038] Based on the aforementioned technical means, target reporting reports can be automatically sent to regulatory agencies, thereby achieving data reporting.
[0039] In this embodiment of the application, the method for processing the insurance regulatory reporting data further includes:
[0040] Configure the data acquisition time for the corresponding report type based on the report type and regulatory requirements;
[0041] Source data is collected from different custodian bank systems based on the current target report type and the corresponding data acquisition time.
[0042] Based on the aforementioned technical means, source data can be automatically collected at regular intervals according to regulatory needs, processed into target reporting reports, and data reporting can be completed.
[0043] A second aspect of this application provides an apparatus for processing insurance regulatory reporting data, the apparatus comprising:
[0044] The reporting node configuration unit is used to configure reporting nodes according to the organizational structure and asset status of the reporting party.
[0045] The report synthesis rule configuration unit is used to configure report synthesis rules according to the report type.
[0046] The report data acquisition unit is used to collect source data from different custodian bank systems according to the current target report type.
[0047] The report data verification unit is used to verify the source data according to the current target report type to obtain the data to be submitted.
[0048] The report synthesis and processing unit is used to synthesize and process the data to be reported into the target report based on the report synthesis rules corresponding to the current target report type and the reporting node.
[0049] Based on the aforementioned technical means, the reporting node configuration unit configures the reporting level nodes according to the organizational structure of the reporting party, which can flexibly adapt to different reporting level requirements. The reporting synthesis rule configuration unit configures the report synthesis rules according to the report type. The device realizes automatic acquisition, verification, and hierarchical summarization of the reported report data, realizes the adaptation to the reporting level management of different insurance companies, and automatically synthesizes reports according to preset rules, thereby improving reporting efficiency.
[0050] In this embodiment of the application, the report data acquisition unit includes:
[0051] The reporting field acquisition module is used to obtain the required reporting fields from the target report template according to the current target report type;
[0052] The data acquisition module is used to collect source data from different custodian bank systems and store it in the local raw database table according to the required reporting fields.
[0053] Based on the above technical means, the required reporting fields are determined from the target report template, and then the source data is collected according to the required reporting fields. This can accurately obtain the required source data from different custodian bank systems, reduce the amount of source data, and improve processing efficiency.
[0054] In this embodiment of the application, the report data verification unit includes:
[0055] The non-empty verification module is used to perform non-empty verification on the source data collected in the current custodian bank system based on the asset status in the current custodian bank system.
[0056] The data type validation module is used to verify whether the data types of different table fields in the current target report are consistent with the data types of the corresponding table fields in the source data.
[0057] Based on the aforementioned technical means, the data that needs to be collected in the non-custodial bank system can be accurately determined according to the preset field mapping relationship, effectively realizing the interoperability between data and required reporting fields in different custodial bank systems and reducing subsequent data synthesis errors.
[0058] In this embodiment of the application, the report synthesis and processing unit includes:
[0059] The target data field determination module is used to determine the target data field in the data to be reported, which corresponds to the required reporting field, based on a preset field mapping relationship.
[0060] The synthesis and processing module is used to synthesize and process the target data fields in the data to be reported according to the report synthesis rules corresponding to the current target report type, starting from the last node and working upwards, to obtain the target report.
[0061] Based on the above technical means, the required reporting fields in different source data are processed and synthesized to obtain the target reporting report.
[0062] In this embodiment of the application, the processing device for insurance regulatory reporting data further includes:
[0063] The data storage unit is used to store the collected source data, the data to be reported, and the verification failure data.
[0064] Based on the above technical means, the data storage unit uses different database tables to store the data to be submitted and the data that failed to be verified, which can facilitate the review during the subsequent review of the target report.
[0065] In this embodiment of the application, the processing device for insurance regulatory reporting data further includes:
[0066] The report sending unit is used to send the target report, which has been verified to be correct, to the regulatory agency.
[0067] Based on the aforementioned technical means, target reporting reports can be automatically sent to regulatory agencies, thereby achieving data reporting.
[0068] In this embodiment of the application, the processing device for insurance regulatory reporting data further includes:
[0069] The time configuration unit is used to configure the data acquisition time for the corresponding report type according to the report type and regulatory requirements.
[0070] The report data acquisition unit is also used to collect source data from different custodian bank systems according to the current target report type and the corresponding data acquisition time.
[0071] Based on the aforementioned technical means, source data can be automatically collected at regular intervals according to regulatory needs, processed into target reporting reports, and data reporting can be completed.
[0072] A third aspect of this application provides a processor configured to perform the aforementioned method for processing insurance regulatory reporting data.
[0073] The fourth aspect of this application provides a machine-readable storage medium storing instructions that, when executed by a processor, configure the processor to perform the processing method for insurance regulatory reporting data.
[0074] The fifth aspect of this application is a computer program product, including a computer program that, when executed by a processor, implements the aforementioned method for processing insurance regulatory reporting data.
[0075] The above technical solution can flexibly adapt to different reporting levels, automatically acquire and verify reporting data, and process the data by summarizing it upwards according to the reporting level to obtain a complete regulatory report, which is then pushed to the regulatory agency to complete the regulatory reporting. It achieves adaptation to the reporting level management of different insurance companies, automatically synthesizes reports according to preset rules, and improves reporting efficiency.
[0076] When the reporting node level changes later, the reporting node only needs to be reset to complete the reporting, which greatly reduces the cost of manual development and maintenance and shortens the reporting response time.
[0077] Other features and advantages of the embodiments of this application will be described in detail in the following detailed description section. Attached Figure Description
[0078] The accompanying drawings are provided to further illustrate the embodiments of this application and form part of the specification. They are used together with the following detailed description to explain the embodiments of this application, but do not constitute a limitation on the embodiments of this application. In the drawings:
[0079] Figure 1 This illustration schematically shows an application environment diagram of the insurance regulatory reporting data processing method according to an embodiment of this application;
[0080] Figure 2 The illustration shows a flowchart of a method for processing insurance regulatory reporting data according to an embodiment of this application;
[0081] Figure 3 This schematic diagram illustrates a structural block diagram of a processing apparatus for insurance regulatory reporting data according to an embodiment of this application;
[0082] Figure 4 The diagram illustrates the internal structure of a computer device according to an embodiment of this application.
[0083] Explanation of reference numerals in the attached figures
[0084] A01 - Processor, A02 - Network Interface, A03 - Internal Memory, A04 - Non-volatile Storage Medium, B01 - Operating System, B02 - Computer Program. Detailed Implementation
[0085] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are only for illustration and explanation of the embodiments of this application and are not intended to limit the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.
[0086] It should be noted that if the embodiments of this application involve directional indicators (such as up, down, left, right, front, back, etc.), the directional indicators are only used to explain the relative positional relationship and movement of the components in a certain specific posture (as shown in the figure). If the specific posture changes, the directional indicators will also change accordingly.
[0087] Furthermore, if the embodiments of this application involve descriptions such as "first" or "second," these descriptions are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, features defined with "first" or "second" may explicitly or implicitly include at least one of those features. Additionally, the technical solutions of various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. If the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed in this application.
[0088] The data processing method for insurance regulatory reporting provided in this application can be applied to, for example... Figure 1 The application environment is shown. The reporting system 101 communicates with different custodian bank systems (103, 104) and the regulatory agency system 102 via a network. The custodian bank systems store the reporting system's fund transfer and accounting data with the corresponding banks. When processing reports, the reporting system retrieves data from the custodian bank systems, ultimately processing it into the target report and sending it to the regulatory agency system. The reporting system, custodian bank systems, and regulatory agency systems are deployed on servers, which can be either standalone servers or a server cluster.
[0089] Figure 2 This illustration schematically shows a flowchart of a method for processing insurance regulatory reporting data according to an embodiment of this application. Figure 2 As shown, in one embodiment of this application, a method for processing insurance regulatory reporting data is provided. This embodiment mainly applies this method to the above-mentioned... Figure 1 Taking the reporting system in the example, the steps include:
[0090] S1: Configure reporting nodes based on the reporting party's organizational structure and asset situation.
[0091] Different insurance companies have different organizational levels (some have subsidiaries), different types of insurance products, and different custodian banks for their insurance products. Therefore, when summarizing, it is necessary to manually adjust the summarization rules according to the specific levels.
[0092] For example, for a group insurance company A, compiling a regulatory report generally requires the following steps: First, obtain the product data from different custodian banks according to the custodian product dimension and summarize it according to the product. Then, summarize all the products under the company according to the asset category. Next, summarize all the asset categories under the company according to the subsidiaries. Finally, summarize all the assets of all subsidiaries to form the final reporting report. That is, Company A needs to configure four reporting nodes: product dimension, asset category, subsidiary, and all assets.
[0093] For a small-scale insurance company B, which has no subsidiaries and a small number of insurance products, compiling a regulatory report only requires: obtaining the asset data of the product from different custodian banks according to the custodian product dimension, and summarizing it according to the product to obtain the final report. That is, company B only needs to configure one reporting node, namely the product dimension.
[0094] In one embodiment of this application, the reporting party determines the number of reporting nodes to be configured based on its own organizational structure and asset situation, combined with relevant regulatory reporting requirements, and then configures them through an interactive interface.
[0095] In other embodiments, the reporting party can provide its own organizational structure and asset information. The system sets up an automatic identification process according to the relevant regulatory reporting requirements, automatically identifies the required reporting nodes, and then performs automatic configuration.
[0096] In other embodiments, the reporting party can provide its own organizational structure and asset information, as well as relevant regulatory reporting requirements. By identifying the relevant regulations, key data for setting up nodes can be obtained, and then the required reporting nodes can be automatically divided based on the key data, followed by automatic configuration.
[0097] The configured reporting nodes are stored in a database table and can be reused repeatedly if the reporting node does not need to be adjusted, without having to be set up for each reporting.
[0098] S2: Configure report synthesis rules according to report type. In this embodiment, report synthesis rules refer to the synthesis rules for different reports defined by regulatory reporting regulations. For example, the Insurance Institution Investment Business Monitoring Report (Report No. 303) is in Excel format, and the summary rule is to calculate SUM for cells containing data fields; another example is the Sell-Repurchase Position Data Report (Report No. 415), which is in TXT format, and the summary rule is simple merging. In this embodiment, the report synthesis rules are adjusted according to changes in regulatory reporting regulations, and the configured report synthesis rules are stored in a database table for repeated use.
[0099] S3: Collect source data from different custodian bank systems based on the current target report type. Different report types require different data; therefore, the source data collection process needs to collect source data from different custodian bank systems based on the current target report type.
[0100] In this embodiment of the application, source data is collected from different custodian bank systems according to the current target report type, including:
[0101] The required fields are retrieved from the target report template based on the current target report type. Each report type has a standard template; the required fields are determined by performing cell content recognition or semantic recognition on the standard template.
[0102] Source data is collected from different custodian bank systems and stored in a local raw database table according to the required reporting fields. Since different custodian bank systems are different, the data record format or the fields used may vary. Therefore, in this embodiment, collecting source data from different custodian bank systems according to the required reporting fields includes:
[0103] The target data fields corresponding to the required reporting fields in different custodian bank systems are determined based on the preset field mapping relationship. The preset field mapping relationship associates the required reporting fields with the corresponding fields in different custodian bank systems according to the data record format or field settings used in different custodian bank systems. Therefore, by traversing the preset field mapping relationship, the target data fields corresponding to different custodian bank systems can be determined.
[0104] Collect source data from the current custodian bank system based on the target data fields in the current custodian bank system.
[0105] Based on the aforementioned technical means, the data that needs to be collected in the non-custodial bank system can be accurately determined according to the preset field mapping relationship, effectively realizing the interoperability between data and required reporting fields in different custodial bank systems and reducing subsequent data synthesis errors.
[0106] Based on the above technical means, the required reporting fields are determined from the target report template, and then the source data is collected according to the required reporting fields. This can accurately obtain the required source data from different custodian bank systems, reduce the amount of source data, and improve processing efficiency.
[0107] S4: Validate the source data according to the current target report type to obtain the data to be submitted, specifically including:
[0108] First, based on the current asset status in the custodian bank's system, a non-empty check is performed on the source data collected from the current custodian bank's system. In this embodiment, the non-empty check specifically includes:
[0109] Obtain the current asset status in the custodian bank's system. The asset status mainly includes whether the asset of this type exists in the current custodian bank's system.
[0110] If the current custodian bank system contains assets but the source data collected in the current custodian bank system is empty, or if the current custodian bank system does not contain assets but the source data collected in the current custodian bank system is not empty, then the non-empty verification fails; otherwise, the non-empty verification passes.
[0111] Based on the above technical means, it is possible to verify whether the source data matches the custodian bank's asset situation, thereby reducing source data anomalies.
[0112] If the non-empty verification is successful, check whether the data types of different table fields in the current target report are consistent with the data types of the corresponding table fields in the source data. If they are consistent, the data type verification is successful, and the current source data is used as the data to be submitted.
[0113] Based on the above technical means, source data with verification anomalies can be eliminated, thereby improving the accuracy of the reporting reports synthesized from the data to be reported.
[0114] S5: Based on the report synthesis rules corresponding to the current target report type and the reporting node, synthesize and process the data to be reported into the target report.
[0115] In this embodiment of the application, the data to be reported is synthesized and processed into a target reporting report according to the report synthesis rules corresponding to the current target report type and the reporting node, including:
[0116] Determine the target data field in the data to be reported based on the preset field mapping relationship;
[0117] Based on the report synthesis rules corresponding to the current target report type, the target data fields in the data to be reported are synthesized and processed sequentially from the last node upwards according to the reporting node to obtain the target reporting report.
[0118] For example, if a 303 regulatory report is to be submitted and the submitter has only one node, then it is only necessary to sum the asset data of each insurance product scattered across different custodian banks in the same column. If the submitter has three nodes, then first, the asset data of each insurance product scattered across different custodian banks at the product node are summed in the same column. After the product node is completed, the data of different insurance products under the same asset category are progressively processed and synthesized. After the asset category node is completed, the system progressively synthesizes and summarizes all asset category product data under different branches and subsidiaries. Finally, the asset data of all branches and subsidiaries are synthesized and summarized to obtain the final 303 regulatory report that the insurance group can directly submit.
[0119] Based on the above technical means, the required reporting fields in different source data are processed and synthesized to obtain the target reporting report.
[0120] The method of this application configures the reporting hierarchy nodes according to the organizational structure of the reporting party, which can flexibly adapt to different reporting level requirements. It configures report synthesis rules according to the report type, automatically acquires, verifies, and summarizes the reported report data level by level, realizes the adaptation to the reporting level management of different insurance companies, and automatically synthesizes reports according to preset rules, thereby improving reporting efficiency.
[0121] In other embodiments of this application, the method for processing the insurance regulatory reporting data further includes:
[0122] Import the data to be reported into the database table to be reported, and import the data that fails the non-empty check and the data that fails the data type check into the database table that fails the check.
[0123] Based on the aforementioned technical means, using different database tables to store the data to be submitted and the data that failed verification can facilitate review during the subsequent review process of the target report.
[0124] In other embodiments of this application, the method for processing the insurance regulatory reporting data further includes:
[0125] The verified target reporting forms are then sent to the regulatory authorities. Before being formally sent, the target reporting forms undergo manual review. This review serves two purposes: firstly, to re-verify their accuracy; and secondly, to correct any data that fails verification. During the review process, data stored in the database table of failed verifications can shorten the manual review time.
[0126] In the actual report submission process, after the target report is sent to the regulatory agency, the regulatory agency system will return a message. The method in this application can confirm the completion of the final submission based on the returned message.
[0127] Based on the aforementioned technical means, target reporting reports can be automatically sent to regulatory agencies, thereby achieving data reporting.
[0128] In other embodiments of this application, the method for processing the insurance regulatory reporting data further includes:
[0129] Configure the data acquisition time for the corresponding report type based on the report type and regulatory requirements;
[0130] Source data is collected from different custodian bank systems based on the current target report type and the corresponding data acquisition time.
[0131] Based on the aforementioned technical means, source data can be automatically collected at regular intervals according to regulatory needs, processed into target reporting reports, and data reporting can be completed.
[0132] In other embodiments, a reporting deadline can be set to remind or ensure that the corresponding reports are submitted within the specified time.
[0133] Figure 2 This is a flowchart illustrating a method for processing insurance regulatory reporting data in one embodiment. It should be understood that, although... Figure 2The steps in the flowchart are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order in which these steps are executed, and they can be performed in other orders. Figure 2 At least some of the steps in the process may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.
[0134] The following examples illustrate this application.
[0135] An insurance group plans to submit Report No. 303, "Insurance Institution Investment Business Monitoring Report." Based on its organizational structure, it has set up a four-tiered reporting system, from bottom to top: insurance products, asset categories, subsidiaries, and all assets. The report is scheduled to be submitted on the 3rd of each month, and the report aggregation rule is set to SUM summation of data in the same column. Then, at the end of each month, the system automatically identifies and retrieves data on insurance product assets held in custody by different custodian banks based on Report No. 303, storing the retrieved data in a local original database table. For example, it records the cost and book balance of financial assets such as bank deposits, government bonds, and open-ended funds held by Insurance Product 1 in custodian banks A, B, and C. The system then automatically validates the asset data in the original database table. Data that meets the validation rules is imported from the original database table into the database table to be submitted; data that does not meet the validation rules is imported into the database table for failed validation.
[0136] The system then automatically processes and synthesizes the data reported by each end node sequentially upwards. For example, following the previous node settings, it first synthesizes the asset data of each insurance product scattered across different custodian banks at the end node. After completing the synthesis of the product node, the system automatically processes and synthesizes the data of different insurance products under the same asset category in a progressive manner. After completing the synthesis of the asset category node, the system progressively synthesizes and summarizes the asset category product data of all branches and subsidiaries. Finally, it synthesizes and summarizes the asset data of all branches and subsidiaries to obtain the final 303 regulatory report that the insurance group can directly submit. After manual review and verification, the system automatically sends the synthesized report to the regulatory agency, and the final submission is successfully confirmed based on the returned message.
[0137] This application primarily addresses the issue that when different insurance companies submit regulatory reports, the rules for processing and summarizing report data level by level are uncertain due to the different institutional levels, product types, and custodian banks associated with each company. This uncertainty necessitates customized system modifications for different types of insurance companies, resulting in high maintenance costs and slow response times.
[0138] The regulatory reporting technical solution proposed in this application can utilize the autonomous configuration of the reporting node setting unit and the reporting synthesis rule setting unit. Subsequently, the system will automatically complete the entire regulatory reporting process from data acquisition, data verification, data storage, data aggregation to data reporting, which significantly reduces the cost of customized system development and operation and maintenance, greatly shortens the reporting response time, and improves business processing efficiency.
[0139] The second aspect of this application provides a processing device for insurance regulatory reporting data, such as... Figure 3 As shown, the processing device for the insurance regulatory reporting data includes:
[0140] The reporting node configuration unit is used to configure reporting nodes according to the organizational structure and asset status of the reporting party.
[0141] The report synthesis rule configuration unit is used to configure report synthesis rules according to the report type.
[0142] The report data acquisition unit is used to collect source data from different custodian bank systems according to the current target report type.
[0143] The report data verification unit is used to verify the source data according to the current target report type to obtain the data to be submitted.
[0144] The report synthesis and processing unit is used to synthesize and process the data to be reported into the target report based on the report synthesis rules corresponding to the current target report type and the reporting node.
[0145] Based on the aforementioned technical means, the reporting node configuration unit configures the reporting level nodes according to the organizational structure of the reporting party, which can flexibly adapt to different reporting level requirements. The reporting synthesis rule configuration unit configures the report synthesis rules according to the report type. The device realizes automatic acquisition, verification, and hierarchical summarization of the reported report data, realizes the adaptation to the reporting level management of different insurance companies, and automatically synthesizes reports according to preset rules, thereby improving reporting efficiency.
[0146] In this embodiment of the application, the report data acquisition unit includes:
[0147] The reporting field acquisition module is used to obtain the required reporting fields from the target report template according to the current target report type;
[0148] The data acquisition module is used to collect source data from different custodian bank systems and store it in the local raw database table according to the required reporting fields.
[0149] In this embodiment, the data acquisition module first determines the target data field corresponding to the required reporting field in different custodian bank systems based on the required reporting field provided by the reporting field acquisition module from the preset field mapping relationship; then, it acquires the source data in the current custodian bank system based on the target data field in the current custodian bank system.
[0150] Based on the above technical means, the required reporting fields are determined from the target report template, and then the source data is collected according to the required reporting fields. This can accurately obtain the required source data from different custodian bank systems, reduce the amount of source data, and improve processing efficiency.
[0151] In this embodiment of the application, the report data verification unit includes:
[0152] The non-empty verification module is used to perform non-empty verification on the source data collected in the current custodian bank system based on the asset status in the current custodian bank system.
[0153] The data type validation module is used to verify whether the data types of different table fields in the current target report are consistent with the data types of the corresponding table fields in the source data.
[0154] In this embodiment of the application, the non-empty verification module first obtains the asset status in the current custodian bank system; then it makes a judgment: if there are assets in the current custodian bank system but the source data collected in the current custodian bank system is empty, or if there are no assets in the current custodian bank system but the source data collected in the current custodian bank system is not empty, then the non-empty verification fails; otherwise, the non-empty verification passes.
[0155] Based on the aforementioned technical means, the data that needs to be collected in the non-custodial bank system can be accurately determined according to the preset field mapping relationship, effectively realizing the interoperability between data and required reporting fields in different custodial bank systems and reducing subsequent data synthesis errors.
[0156] In this embodiment of the application, the report synthesis and processing unit includes:
[0157] The target data field determination module is used to determine the target data field in the data to be reported, which corresponds to the required reporting field, based on a preset field mapping relationship.
[0158] The synthesis and processing module is used to synthesize and process the target data fields in the data to be reported according to the report synthesis rules corresponding to the current target report type, starting from the last node and working upwards, to obtain the target report.
[0159] Based on the above technical means, the required reporting fields in different source data are processed and synthesized to obtain the target reporting report.
[0160] In this embodiment of the application, the processing device for insurance regulatory reporting data further includes:
[0161] The data storage unit is used to store the collected source data, the data to be reported, and the verification failure data.
[0162] Based on the above technical means, the data storage unit uses different database tables to store the data to be submitted and the data that failed to be verified, which can facilitate the review during the subsequent review of the target report.
[0163] In this embodiment of the application, the processing device for insurance regulatory reporting data further includes:
[0164] The report sending unit is used to send the target report, which has been verified to be correct, to the regulatory agency.
[0165] Based on the aforementioned technical means, target reporting reports can be automatically sent to regulatory agencies, thereby achieving data reporting.
[0166] In this embodiment of the application, the processing device for insurance regulatory reporting data further includes:
[0167] The time configuration unit is used to configure the data acquisition time for the corresponding report type according to the report type and regulatory requirements.
[0168] The report data acquisition unit is also used to collect source data from different custodian bank systems according to the current target report type and the corresponding data acquisition time.
[0169] Based on the aforementioned technical means, source data can be automatically collected at regular intervals according to regulatory needs, processed into target reporting reports, and data reporting can be completed.
[0170] The processing device for insurance regulatory reporting data includes a processor and a memory. The aforementioned reporting node configuration unit, reporting synthesis rule configuration unit, report data acquisition unit, report data verification unit, report synthesis and processing unit, and report sending unit are all stored in the memory as program units. The processor executes the aforementioned program modules stored in the memory to implement the corresponding functions.
[0171] The processor contains a kernel, which retrieves the corresponding program units from memory. One or more kernels can be configured, and the processing methods for insurance regulatory reporting data can be implemented by adjusting kernel parameters.
[0172] The memory may include non-permanent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.
[0173] A third aspect of this application provides a processor configured to perform the aforementioned method for processing insurance regulatory reporting data.
[0174] The fourth aspect of this application provides a machine-readable storage medium storing instructions that, when executed by a processor, configure the processor to perform the aforementioned method for processing insurance regulatory reporting data.
[0175] The fifth aspect of this application is a computer program product, including a computer program that, when executed by a processor, implements the aforementioned method for processing insurance regulatory reporting data.
[0176] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 4 As shown. The computer device includes a processor A01, a network interface A02, memory (not shown), and a database (not shown) connected via a system bus. The processor A01 provides computing and control capabilities. The memory includes internal memory A03 and a non-volatile storage medium A04. The non-volatile storage medium A04 stores an operating system B01, a computer program B02, and a database (not shown). The internal memory A03 provides an environment for the operation of the operating system B01 and the computer program B02 stored in the non-volatile storage medium A04. The database is used to categorize and store source data, data to be reported, and verification failure data. The network interface A02 is used to communicate with external terminals via a network connection. When the computer program B02 is executed by the processor A01, it implements a method for processing insurance regulatory reporting data.
[0177] Those skilled in the art will understand that Figure 4 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.
[0178] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0179] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.
[0180] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.
[0181] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.
[0182] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.
[0183] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.
[0184] Computer-readable media include both permanent and non-permanent, removable and non-removable media, which can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.
[0185] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.
[0186] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.
Claims
1. A method for processing insurance regulatory filing data, characterized in that, The processing method for the insurance regulatory reporting data includes: Configure reporting nodes according to the organizational structure and asset status of the reporting party; Configure report synthesis rules according to report type; Data is collected from different custodian bank systems based on the current target report type, including: Retrieve the required reporting fields from the target report template based on the current target report type; Data source data is collected from different custodian bank systems and stored in the local original database table according to the required reporting fields; Source data is collected from different custodian bank systems based on the required reporting fields, including: Determine the target data fields corresponding to the required reporting fields in different custodian bank systems based on the preset field mapping relationship; Collect source data from the current custodian bank's system based on the target data fields in the current custodian bank's system; The source data is validated based on the current target report type to obtain the data to be submitted; Based on the report synthesis rules corresponding to the current target report type and the reporting node, the data to be reported is synthesized and processed into the target reporting report, including: Determine the target data field in the data to be reported based on the preset field mapping relationship; Based on the report synthesis rules corresponding to the current target report type, the target data fields in the data to be reported are synthesized and processed sequentially from the last node upwards according to the reporting node to obtain the target reporting report.
2. The method of claim 1, wherein, The source data is validated based on the current target report type to obtain the data to be submitted, including: Based on the current asset status in the custodian bank system, perform non-empty verification on the source data collected in the current custodian bank system; If the non-empty verification is successful, check whether the data types of different table fields in the current target report are consistent with the data types of the corresponding table fields in the source data. If they are consistent, the data type verification is successful, and the current source data is used as the data to be submitted.
3. The method of claim 2, wherein, Based on the current asset status in the custodian bank's system, perform non-empty verification on the source data collected from the current custodian bank's system, including: Get the current asset status in the custodian bank's system; If the current custodian bank system contains assets but the source data collected in the current custodian bank system is empty, or if the current custodian bank system does not contain assets but the source data collected in the current custodian bank system is not empty, then the non-empty verification fails; otherwise, the non-empty verification passes.
4. The method of claim 2, wherein the insurance regulatory reporting data is processed by, The method for processing insurance regulatory reporting data also includes: Import the data to be reported into the database table to be reported, and import the data that fails the non-empty check and the data that fails the data type check into the database table that fails the check.
5. The method of claim 1, wherein, The method for processing insurance regulatory reporting data also includes: Once the target report has been verified, it will be sent to the regulatory authority.
6. The method of claim 1, wherein, The method for processing insurance regulatory reporting data also includes: Configure the data acquisition time for the corresponding report type based on the report type and regulatory requirements; Source data is collected from different custodian bank systems based on the current target report type and the corresponding data acquisition time.
7. A data processing device for insurance regulatory reporting, characterized in that, The processing device for the insurance regulatory reporting data includes: The reporting node configuration unit is used to configure reporting nodes according to the organizational structure and asset status of the reporting party. The report synthesis rule configuration unit is used to configure report synthesis rules according to the report type. The report data acquisition unit is used to collect source data from different custodian bank systems according to the current target report type. The report data verification unit is used to verify the source data according to the current target report type to obtain the data to be submitted. The report synthesis and processing unit is used to synthesize and process the data to be reported into the target report based on the report synthesis rules corresponding to the current target report type and the reporting node. The report data acquisition unit includes: The reporting field acquisition module is used to obtain the required reporting fields from the target report template according to the current target report type; The data acquisition module is used to collect source data from different custodian bank systems and store it in the local raw database table according to the required reporting fields; Source data is collected from different custodian bank systems based on the required reporting fields, including: Determine the target data fields corresponding to the required reporting fields in different custodian bank systems based on the preset field mapping relationship; Collect source data from the current custodian bank's system based on the target data fields in the current custodian bank's system; The report synthesis and processing unit includes: The target data field determination module is used to determine the target data field in the data to be reported, which corresponds to the required reporting field, based on a preset field mapping relationship. The synthesis and processing module is used to synthesize and process the target data fields in the data to be reported according to the report synthesis rules corresponding to the current target report type, starting from the last node and working upwards, to obtain the target report.
8. The processing device for insurance regulatory reporting data according to claim 7, characterized in that, The report data verification unit includes: The non-empty verification module is used to perform non-empty verification on the source data collected in the current custodian bank system based on the asset status in the current custodian bank system. The data type validation module is used to verify whether the data types of different table fields in the current target report are consistent with the data types of the corresponding table fields in the source data.
9. The data processing device for insurance regulatory reporting according to claim 7, characterized in that, The processing device for insurance regulatory reporting data also includes: The data storage unit is used to store the collected source data, the data to be reported, and the verification failure data.
10. The processing device for insurance regulatory reporting data according to claim 7, characterized in that, The processing device for insurance regulatory reporting data also includes: The report sending unit is used to send the target report, which has been verified to be correct, to the regulatory agency.
11. The processing device for insurance regulatory reporting data according to claim 7, characterized in that, The processing device for insurance regulatory reporting data also includes: The time configuration unit is used to configure the data acquisition time for the corresponding report type according to the report type and regulatory requirements. The report data acquisition unit is also used to collect source data from different custodian bank systems according to the current target report type and the corresponding data acquisition time.
12. A processor, characterized in that, The method is configured to perform the processing method for insurance regulatory reporting data as described in any one of claims 1 to 6.
13. A machine-readable storage medium storing instructions thereon, characterized in that, When executed by a processor, this instruction causes the processor to be configured to perform the processing method for insurance regulatory reporting data as described in any one of claims 1 to 6.
14. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method for processing insurance regulatory reporting data as described in any one of claims 1 to 6.