Data reporting method and apparatus, storage medium, and terminal

Abstract

The embodiment of the specification discloses a data reporting method and device, a storage medium and a terminal. First, through automatic extraction and processing, multi-source heterogeneous data is integrated into unified standard data to be verified, greatly reducing manual intervention, improving integration efficiency, realizing a set of data adapting to multiple platform requirements, and reducing maintenance cost. Secondly, based on the pre-constructed knowledge graph, semantic reasoning verification is carried out, static rules are converted into dynamic knowledge, logical conflicts and implicit compliance risks are actively identified, problems can be found in time before they affect, and the verification comprehensiveness and accuracy are significantly improved. According to the requirements of the target platform, adaptive automatic reporting is realized, the whole process is automated, the reporting cycle is shortened, the system compatibility is enhanced, the reporting is ensured to be timely and reliable, and the intelligent upgrading of supervision reporting is realized.

Description

Technical Field

[0001] This specification relates to the field of computer technology, and in particular to a data reporting method, apparatus, storage medium, and terminal. Background Technology

[0002] In the process of submitting data to regulatory authorities, the traditional data extraction and integration relies on manual labor, which is costly and difficult to standardize. Furthermore, the data processing and verification stages lack intelligent tools and are mostly done manually, making them prone to errors and omissions, with vulnerabilities often only discovered after problems arise. As the types and frequency of reports increase, the large amount of repetitive submission leads to inefficiency and makes it difficult to respond promptly to regulatory needs. In addition, the lack of structured records in the data flow process makes it difficult to quickly trace the source and assess the impact of errors, omissions, or rule adjustments, leading to auditing difficulties. It is clear that the traditional reporting model has a closed architecture, low levels of automation and intelligence, and cannot meet the needs of refined regulation. Summary of the Invention

[0003] This specification provides a data reporting method, apparatus, storage medium, and terminal, which can solve the technical problems of uncontrollable data reporting quality and low reporting efficiency in related technologies.

[0004] Firstly, embodiments of this specification provide a data reporting method, the method comprising: The original regulatory data is automatically extracted from multiple heterogeneous data sources, and the data is processed according to the reporting requirements of multiple regulatory platforms to obtain the data to be verified. The original regulatory data includes structured data, semi-structured data and unstructured data. The compliance verification of the above-mentioned data to be verified is performed based on a pre-built knowledge graph. In the knowledge graph, entities extracted from multiple regulatory rules are used as nodes, and the relationships between the entities are used as edges connecting the nodes. The data to be verified that has passed the above compliance verification is processed to generate data to be reported that meets the reporting requirements of the target regulatory platform, and the data to be reported is sent to the target regulatory platform.

[0005] In one possible implementation, the above method further includes: extracting entities and relationships between entities from multiple regulatory rule files, and defining the entities in a standardized manner according to data standards to form a knowledge graph with entities as nodes and relationships as edges.

[0006] In one possible implementation, the compliance verification of the data to be verified based on the pre-built knowledge graph includes: mapping the data to be verified to the corresponding entities in the pre-built knowledge graph, performing semantic reasoning through the relationships in the knowledge graph, and identifying logical conflicts and compliance issues in the data to be verified.

[0007] In one possible implementation, the compliance verification of the data to be verified based on the pre-built knowledge graph includes: calling the configurable transaction rules pre-stored in the rule engine, combining the recognition results obtained after performing the semantic reasoning on the knowledge graph, and performing compliance verification on the data to be verified.

[0008] In one possible implementation, the above-mentioned data processing methods include at least organization, calculation, and storage.

[0009] In one possible implementation, the method further includes: automatically parsing the data calculation steps used in the data processing process, determining the source, transformation logic and dependency of the data in the current system based on the data calculation steps, and constructing a data lineage map between the original regulatory data and the data to be reported.

[0010] In one possible implementation, the method further includes: in response to data anomalies, performing data tracing based on the data lineage graph to determine the data source and data link causing the data anomalies; and / or, in response to changes in regulatory rules, determining the scope of impact of the changes in regulatory rules based on the data lineage graph.

[0011] In one possible implementation, sending the data to be reported to the target regulatory platform includes: selecting, based on the interface type supported by the target regulatory platform, sending the data to be reported to the target regulatory platform via an application programming interface, or automatically filling the data to be reported to the target regulatory platform by simulating manual operation through preset robot software.

[0012] In one possible implementation, the above method further includes: displaying multiple status indicators of the data reporting task through a display interface and visually displaying the data lineage map; storing all system operations in a log and generating an audit report based on the stored logs every preset period.

[0013] Secondly, embodiments of this specification provide a data reporting device, the device comprising: The data acquisition module is used to automatically extract raw regulatory data from multiple heterogeneous data sources and process the raw regulatory data according to the reporting requirements of multiple regulatory platforms to obtain data to be verified. The raw regulatory data includes structured data, semi-structured data and unstructured data. The compliance verification module is used to perform compliance verification on the above-mentioned data to be verified based on a pre-built knowledge graph. The knowledge graph uses entities extracted from multiple regulatory rules as nodes and the relationships between the entities as edges connecting the nodes. The intelligent reporting module is used to process the data to be verified that has passed the above compliance verification, generate data to be reported that meets the reporting requirements of the target regulatory platform, and send the data to be reported to the target regulatory platform.

[0014] Thirdly, embodiments of this specification provide a computer program product containing instructions that, when run on a computer or processor, cause the computer or processor to perform the steps of the method described above.

[0015] Fourthly, embodiments of this specification provide a computer storage medium storing a plurality of instructions adapted for loading by a processor and executing the steps of the method described above.

[0016] Fifthly, embodiments of this specification provide a terminal including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is adapted to be loaded by the processor and to execute the steps of the method described above.

[0017] The beneficial effects of the technical solutions provided in some embodiments of this specification include at least the following: This specification provides a data reporting method that automatically extracts raw regulatory data from multiple heterogeneous data sources and processes the raw regulatory data according to the reporting requirements of multiple regulatory platforms to obtain data to be verified. The raw regulatory data includes structured data, semi-structured data, and unstructured data. Compliance verification of the data to be verified is performed based on a pre-built knowledge graph, where entities extracted from multiple regulatory rules are nodes, and the relationships between entities are edges connecting the nodes. The data to be verified that passes the compliance verification is processed to generate data to be reported that meets the reporting requirements of the target regulatory platform, and then the data to be reported is sent to the target regulatory platform. First, raw regulatory data is extracted from multiple heterogeneous data sources using automated means. Based on this, the extracted raw data is processed according to the different reporting requirements of each regulatory platform to obtain data to be verified. This process transforms scattered and heterogeneous raw information into a preliminarily compliant dataset, laying a unified data foundation for subsequent verification processes. It achieves automated access and preprocessing of multi-source heterogeneous data, significantly improving data integration efficiency and accuracy. Meanwhile, by processing data on demand, the raw data can be adapted to the differentiated requirements of multiple regulatory platforms, providing standardized and structured input data for subsequent verification stages. Furthermore, by introducing a pre-built knowledge graph, during verification, the data to be verified is mapped to corresponding entities in the graph, automatically identifying compliance issues within the data. This operation transforms static regulatory rules into dynamic knowledge reasoning capabilities, enabling the system to proactively discover hidden compliance risks in the data. This graph-based verification method improves the comprehensiveness and accuracy of verification and shifts the timing of problem discovery from post-event to in-event, effectively preventing non-compliant data from entering subsequent reporting stages. Finally, according to the specific requirements of the target regulatory platform, the data to be verified that has passed compliance verification is further processed to generate data to be reported in accordance with its reporting format, and then sent to the target regulatory platform. This design achieves automated reporting, significantly shortening the reporting cycle and improving response speed. Through the knowledge graph-driven compliance verification and automated reporting process, the problems of data dispersion, low quality and efficiency, and difficulty in traceability in traditional reporting methods are systematically solved, realizing the intelligentization of regulatory reporting work. Attached Figure Description

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

[0019] Figure 1An exemplary system architecture diagram of a data reporting method provided in the embodiments of this specification; Figure 2 A flowchart illustrating a data reporting method provided in an embodiment of this specification; Figure 3 A flowchart illustrating a data reporting method provided in an embodiment of this specification; Figure 4 A system logic architecture diagram of a data reporting method provided in the embodiments of this specification; Figure 5 A structural block diagram of a data reporting device provided in the embodiments of this specification; Figure 6 This is a schematic diagram of the structure of a terminal provided in an embodiment of this specification. Detailed Implementation

[0020] To make the features and advantages of the embodiments of this specification more apparent and understandable, the technical solutions of the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the embodiments of this specification.

[0021] In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with those in this specification. Rather, they are merely examples of apparatuses and methods consistent with some aspects of the embodiments in this specification as detailed in the appended claims. Furthermore, in the description of the embodiments in this specification, unless otherwise stated, " / " means "or," for example, A / B can mean A or B; the word "and / or" in the text is merely a description of the relationship between related objects, indicating that three relationships can exist, for example, A and / or B can represent: A alone, A and B simultaneously, and B alone. Additionally, in the description of the embodiments in this specification, "multiple" refers to two or more.

[0022] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.

[0023] In the daily operations of various enterprises, institutions, and organizations, submitting large amounts of data in diverse formats, with varying frequencies and statistical definitions to official regulatory authorities has become a routine and increasingly demanding task. As matters become more complex and regulatory requirements become more stringent, the traditional reporting model, relying on manual operations and isolated systems, is gradually revealing its shortcomings and failing to meet the high demands of modern regulatory compliance for data quality, processing efficiency, and traceability. Taking a typical financial scenario as an example, banks, securities firms, and insurance companies need to submit massive amounts of regulatory data, such as capital adequacy ratios, large risk exposures, and anti-money laundering information, to multiple official regulatory bodies, and traditional reporting models cannot solve this problem.

[0024] Traditional reporting methods have limitations in their architectural design and technical implementation. Firstly, the various transaction and production management systems within the regulated entities operate independently, with inconsistent data standards and interfaces, resulting in data silos scattered across heterogeneous data sources. This necessitates significant manual intervention in data extraction and integration, requiring the creation of ad-hoc scripts or manual import / export processes. This is not only costly but also lacks a unified metadata management mechanism, making it difficult to ensure data consistency and creating potential problems for subsequent data processing and verification. Secondly, in traditional reporting processes, data extraction, transformation, and verification heavily rely on the experience and manual operation of technical personnel. This tedious, repetitive work inevitably introduces human error, such as incorrect or missing data entries, formatting inconsistencies, or logical contradictions. Furthermore, due to the lack of intelligent verification tools, most quality issues are only discovered after report generation or even after submission, significantly increasing the difficulty of tracing and correction. Clearly, this passive, post-event error correction model cannot meet the stringent requirements of regulatory agencies for data accuracy, completeness, and timeliness.

[0025] Furthermore, with the increasing variety and frequency of regulatory statistical reports, the heavy workload of manual entry and multiple submissions leads to a slow overall response time. Especially when facing urgent statistical inquiries or regulatory rule adjustments, traditional methods require a complete overhaul of data logic and adjustments to processing scripts, severely lagging behind regulatory timeliness requirements. In addition, the lack of transparent records in the data flow from the source system to the final report, coupled with complex processing links largely linked by manual scripts, makes it difficult to quickly pinpoint the root cause and assess the scope of impact should data anomalies or regulatory requirements change. This not only complicates routine auditing and verification but also makes it difficult to provide strong evidence in the event of compliance issues.

[0026] In summary, traditional regulatory reporting technologies cannot adapt to the increasingly refined and dynamic development trend of regulation. Therefore, this specification provides a data reporting method to solve the aforementioned technical problems of uncontrollable data quality and low reporting efficiency.

[0027] Please see Figure 1 , Figure 1 This is an exemplary system architecture diagram of a data reporting method provided in the embodiments of this specification.

[0028] like Figure 1 As shown, the system architecture may include a terminal 101, a network 102, and a server 103. The network 102 serves as the medium for providing a communication link between the terminal 101 and the server 103. The network 102 may include various types of wired or wireless communication links, such as wired communication links including fiber optic cables, twisted-pair cables, or coaxial cables, and wireless communication links including Bluetooth communication links, Wireless-Fidelity (Wi-Fi) communication links, or microwave communication links, etc.

[0029] Terminal 101 can interact with server 103 via network 102 to receive messages from or send messages to server 103. Alternatively, terminal 101 can interact with server 103 via network 102 to receive messages or data sent to server 103 by other users. Terminal 101 can be hardware or software. When terminal 101 is hardware, it can be various electronic devices, including but not limited to smartphones, tablets, laptops, and desktop computers. When terminal 101 is software, it can be installed in the aforementioned electronic devices and can be implemented as multiple software programs or software modules (e.g., to provide distributed services) or as a single software program or software module; no specific limitation is made here.

[0030] In the embodiments described in this specification, the terminal 101 first automatically extracts raw regulatory data from multiple heterogeneous data sources, and processes the raw regulatory data according to the reporting requirements of multiple regulatory platforms to obtain data to be verified. The raw regulatory data includes structured data, semi-structured data, and unstructured data. For these data, the terminal 101 further performs compliance verification on the data to be verified based on a pre-built knowledge graph. In the knowledge graph, entities extracted from multiple regulatory rules are used as nodes, and the relationships between the entities are used as edges connecting the nodes. Finally, the terminal 101 processes the data to be verified that has passed the compliance verification to generate data to be reported that meets the reporting requirements of the target regulatory platform, and sends the data to be reported to the target regulatory platform.

[0031] Server 103 can be a server that provides various services. It should be noted that server 103 can be hardware or software. When server 103 is hardware, it can be implemented as a distributed server cluster consisting of multiple servers, or as a single server. When server 103 is software, it can be implemented as multiple software programs or software modules (e.g., used to provide distributed services), or as a single software program or software module; no specific limitations are made here.

[0032] Alternatively, the system architecture may not include server 103. In other words, server 103 may be an optional device in the embodiments of this specification. That is, the method provided in the embodiments of this specification can be applied to a system structure that only includes terminal 101. The embodiments of this specification do not limit this.

[0033] It should be understood that Figure 1 The number of terminals, networks, and servers shown is only illustrative; the number can be any number of terminals, networks, and servers depending on the implementation requirements.

[0034] Please see Figure 2 , Figure 2 This is a flowchart illustrating a data reporting method provided in an embodiment of this specification. The execution entity in this embodiment can be a terminal performing data reporting, a processor within the terminal performing the data reporting method, or a data reporting service within the terminal performing the data reporting method. For ease of description, the following example uses a processor within the terminal as the execution entity to illustrate the specific execution process of the data reporting method.

[0035] like Figure 2 As shown, the data reporting method may include at least: S202. Automatically extract raw regulatory data from multiple heterogeneous data sources, and process the raw regulatory data according to the reporting requirements of multiple regulatory platforms to obtain data to be verified. The raw regulatory data includes structured data, semi-structured data and unstructured data.

[0036] Optionally, after obtaining the source data to be reported, it is first necessary to uniformly access and standardize the heterogeneous data scattered across different transaction systems to form a standardized dataset that can be used for subsequent verification and reporting. Specifically, the embodiments of this specification can automatically extract raw regulatory data from multiple heterogeneous data sources through a multimodal intelligent agent, and process the raw regulatory data according to the reporting requirements of multiple regulatory platforms to obtain the data to be verified. The raw regulatory data includes structured data, semi-structured data, and unstructured data.

[0037] Specifically, for ease of understanding, let's take a typical financial scenario as an example. The original regulatory data of financial institutions is widely distributed across heterogeneous transaction platforms such as core banking systems, credit management systems, financial accounting systems, and customer relationship management systems. As can be seen, its data format is diverse. Structured data is typically stored in relational databases in the form of database tables, such as customer information tables, transaction logs, and loan contract tables. Semi-structured data is usually in the form of XML messages, JSON interface data, and system log files. Unstructured data includes text or image data such as regulatory policy documents, scanned copies of contracts, emails, and office documents. In the traditional reporting model, this data needs to be extracted and integrated manually by writing scripts or manually exporting and importing, which is not only inefficient but also prone to data errors due to inconsistent interpretations.

[0038] Furthermore, to overcome the aforementioned deficiencies, this specification introduces a multimodal intelligent agent mechanism in its embodiments. A multimodal intelligent agent refers to an automated processing unit specifically designed for different types of data, including but not limited to structured data query agents, semi-structured data parsing agents, and unstructured data understanding agents. In one feasible implementation, the structured data query agent automatically extracts the required data fields from the database tables of various transaction systems using pre-defined database connection information and SQL templates; the semi-structured data parsing agent uses an XML / JSON parser to convert message or file content into structured records according to predefined mapping rules; and the unstructured data understanding agent uses natural language processing, optical character recognition technology, image processing technology, etc., to extract key indicators and entity information from documents and images such as regulatory documents and scanned contracts. The agents coordinate tasks through a collaborative mechanism, execute data extraction operations in parallel, and aggregate the extraction results to a unified data access layer.

[0039] Furthermore, after extracting the raw data, the system processes the data according to the reporting requirements of various regulatory platforms. Understandably, different regulatory platforms often differ in their definitions, data formats, and reporting cycles for the same transaction data. For example, Bank XX may require customer information including complete document types and numbers, while Institution XX may require reports that are summarized and statistically analyzed according to specific dimensions. Therefore, the data processing employed in the embodiments of this specification encompasses a series of operations such as data cleaning, format conversion, field mapping, logical calculation, and data aggregation, aiming to transform the raw data into verification data that meets the specific requirements of each regulatory platform. For example, for the loan balance field, if the source system contains records in multiple currencies, it needs to be converted and unified according to the exchange rate required by regulations. Through the above automated extraction and processing, the originally scattered, heterogeneous, and polymorphic raw data is integrated into a unified, semantically clear, and quality-controllable dataset for verification, laying a solid data foundation for subsequent compliance verification based on knowledge graphs. Meanwhile, the introduction of multimodal intelligent agents significantly reduces reliance on human intervention, improves the efficiency and accuracy of data processing, and enables the system to flexibly respond to the differentiated needs of different regulatory platforms.

[0040] S204. Compliance verification of the data to be verified is performed based on a pre-built knowledge graph. The knowledge graph uses entities extracted from multiple regulatory rules as nodes and the relationships between entities as edges connecting the nodes.

[0041] Optionally, after obtaining the data to be verified, it is also necessary to ensure that it meets the stringent requirements of regulatory agencies regarding data accuracy, completeness, and compliance before proceeding with subsequent regulatory reporting. Traditional methods typically rely on manual checks or verification based on simple rule scripts, which struggle to detect cross-data domain, deep-seated logical conflicts, and semantic errors. Furthermore, problems are often only discovered after reporting has already caused impact, leading to high costs for tracing and correction. Therefore, to improve the quality of reported data, this embodiment of the specification performs compliance verification on the data to be verified based on a pre-built knowledge graph before reporting. In this knowledge graph, entities extracted from multiple regulatory rules serve as nodes, and the relationships between entities are the edges connecting the nodes.

[0042] Optionally, the pre-construction of the knowledge graph is a prerequisite for this step. In this embodiment, entities and relationships between entities are extracted from multiple regulatory rule files beforehand, and the entities are standardized and defined according to data standards to form a knowledge graph with entities as nodes and relationships as edges. Specifically, firstly, the system needs to extract key concepts as entities from regulatory laws, institutional documents, data standards, and transaction specifications, such as "customer," "legal entity," "loan contract," "guarantee measures," "capital adequacy ratio," and "non-performing asset ratio." These entities constitute the core of the regulatory field. Data standards include at least a regulatory data dictionary, metadata specifications, code tables, and value enumerations, such as the "Financial Basic Data Statistical Standard" and the "Regulatory Data Standardization Specification." Standardization definition refers to mapping the extracted entity names to the standard terms specified in the data standards, aligning entity attributes with the field types, lengths, and formats defined in the standards, and associating entity values ​​with standard code tables (e.g., mapping "loan five-level classification" to standard classification codes), thereby eliminating differences in naming, format, and encoding between data from different sources, and giving the nodes and relationships in the knowledge graph a unified and computable form. Simultaneously, the system identifies and extracts semantic relationships between entities. For example, "customer," "disbursement," and "loan contract" constitute a "disbursement to" relationship; "loan contract," "accrual," and "impairment provision" constitute a "computation-dependent" relationship; and "legal entity," "complies with," and "data standard" constitute a "constrained by" relationship. By structurally modeling entities and relationships, a semantic network—a regulatory knowledge graph—is ultimately formed, with entities as nodes and relationships as edges. This graph construction process involves technologies such as natural language processing, text mining, and ontology construction. This operation is automatically completed by the knowledge extraction agent and calibrated and corrected by manual review.

[0043] Furthermore, based on a pre-built knowledge graph, the system can perform relational reasoning about entities in the data to be verified within the knowledge graph, thereby completing the compliance verification of the data. For example, when verifying "single customer loan concentration," the system can automatically associate the customer's "related parties"—that is, the relationships related to the customer entity and other entities—through the graph, and calculate the total credit line for the group of customers, without having to manually write complex relational query logic. Through the embodiments in this specification, the system transforms the originally static and discrete regulatory rules into a dynamic and reasonable semantic network, enabling compliance verification to shift from conditional judgments based on hard coding to intelligent insights based on relational relationships. This allows data quality issues to be identified and located during the process, preventing non-compliant data from flowing into subsequent reporting stages, significantly reducing the risk of regulatory penalties and the cost of post-event tracing.

[0044] S206. Process the data to be verified that has passed the compliance verification to generate data to be reported that meets the reporting requirements of the target regulatory platform, and send the data to be reported to the target regulatory platform.

[0045] Optionally, after the data to be verified passes the compliance verification, it enters the final reporting execution stage. In this stage, the embodiments of this specification first process the data to be verified that has passed the compliance verification to generate data to be reported that meets the reporting requirements of the target regulatory platform, and then send the data to be reported to the target regulatory platform. This step aims to encapsulate the verified standardized data according to the specific format requirements of each regulatory platform and reliably deliver it to the target system, completing the reporting closed loop.

[0046] Specifically, different regulatory platforms have varying requirements for data reporting formats, commonly including Excel reports, XML messages, JSON data structures, and fixed-length text files, often accompanied by specific file naming rules, encryption and signature requirements, and reporting deadlines. Therefore, in the embodiments of this specification, the data to be verified is first formatted according to the technical specifications of the target regulatory platform. For example, for platforms requiring Excel reports, the system calls a report generation agent to fill the data item by item into the specified cells according to a predefined template style, and generates a complete workbook file containing elements such as titles, headers, and footers; for platforms requiring XML messages, the system serializes the data according to the structure defined by the XSD schema, generating a standard XML document containing root elements, child elements, and attributes; for platforms requiring direct API connections, the system encapsulates the data into a JSON-formatted request body and attaches the necessary authentication token and signature information.

[0047] Furthermore, for the processed data that meets the reporting requirements of the target regulatory platform, the system sends the data to the platform. To ensure the reliable execution of reporting tasks, a reporting task scheduler is configured. The scheduler manages the execution cycle, dependencies, and concurrency control of all reporting tasks. For example, for tasks reporting at fixed times each day, the scheduler triggers the corresponding process at that time. For tasks with sequential dependencies (such as reporting the basic data table first and then the derived indicator table), the scheduler ensures that the preceding task is successfully completed before starting the subsequent task. For a large number of reporting tasks, the scheduler controls the concurrency based on the target platform's capacity to avoid interface rate limiting or blocking due to request overload, making the system more robust and scalable. Through the embodiments in this specification, the system transforms rigorously verified data into a final product that meets regulatory requirements and ensures its accurate and timely delivery to the target platform, thereby automating the end-to-end reporting process, significantly shortening the reporting cycle, reducing manual intervention, and improving reporting success rate and traceability.

[0048] This specification provides a data reporting method that automatically extracts raw regulatory data from multiple heterogeneous data sources and processes the raw regulatory data according to the reporting requirements of multiple regulatory platforms to obtain data to be verified. The raw regulatory data includes structured data, semi-structured data, and unstructured data. Compliance verification of the data to be verified is performed based on a pre-built knowledge graph. The knowledge graph uses entities extracted from multiple regulatory rules as nodes, and the edges connecting the nodes are the relationships between the entities. The data to be verified that passes the compliance verification is processed to generate data to be reported that meets the reporting requirements of the target regulatory platform, and then the data to be reported is sent to the target regulatory platform. First, raw regulatory data is extracted from multiple heterogeneous data sources using automated means. Based on this, the extracted raw data is processed according to the different reporting requirements of each regulatory platform to obtain data to be verified. This process transforms scattered and heterogeneous raw information into a preliminarily compliant dataset, laying a unified data foundation for subsequent verification processes. It achieves automated access and preprocessing of multi-source heterogeneous data, significantly improving data integration efficiency and accuracy. Meanwhile, by processing data on demand, the raw data can be adapted to the differentiated requirements of multiple regulatory platforms, providing standardized and structured input data for subsequent verification stages. Furthermore, by introducing a pre-built knowledge graph, during verification, the data to be verified is mapped to corresponding entities in the graph, automatically identifying compliance issues within the data. This operation transforms static regulatory rules into dynamic knowledge reasoning capabilities, enabling the system to proactively discover hidden compliance risks in the data. This graph-based verification method improves the comprehensiveness and accuracy of verification and shifts the timing of problem discovery from post-event to in-event, effectively preventing non-compliant data from entering subsequent reporting stages. Finally, according to the specific requirements of the target regulatory platform, the data to be verified that has passed compliance verification is further processed to generate data to be reported in accordance with its reporting format, and then sent to the target regulatory platform. This design achieves automated reporting, significantly shortening the reporting cycle and improving response speed. Through the knowledge graph-driven compliance verification and automated reporting process, the problems of data dispersion, low quality and efficiency, and difficulty in traceability in traditional reporting methods are systematically solved, realizing the intelligentization of regulatory reporting work.

[0049] Please see Figure 3 , Figure 3 This is a flowchart illustrating a data reporting method provided in an embodiment of this specification.

[0050] like Figure 3 As shown, the data reporting method may include at least: S302. Automatically extract raw regulatory data from multiple heterogeneous data sources, and process the raw regulatory data according to the reporting requirements of multiple regulatory platforms to obtain data to be verified. The data processing methods include at least organization, calculation and storage.

[0051] Optionally, please refer to Figure 4 , Figure 4 This is a system logic architecture diagram of a data reporting method provided in an embodiment of this specification. Figure 4 As shown in the embodiments of this specification, the system first automatically extracts raw regulatory data from various heterogeneous transaction systems through a multimodal intelligent agent in the data acquisition and processing layer. These data sources cover core banking systems, credit management systems, financial accounting systems, etc., and the data formats include structured database tables, semi-structured interface messages, unstructured documents, etc. The extraction process is executed in parallel to ensure the comprehensiveness and timeliness of data acquisition. Next, the system performs systematic data processing on the raw data according to the differentiated reporting requirements of multiple regulatory platforms.

[0052] Specifically, the processing methods include at least three dimensions: organization, computation, and storage. For data organization, the system can classify and integrate data according to the subject areas of regulatory reports. For example, customer information, transaction records, and risk indicators can be organized into corresponding data marts for easy retrieval when needed. For data computation, the system transforms and derives raw data through predefined transaction logic. For example, it can calculate the aging of loans based on the loan disbursement date and the current date, or convert multi-currency amounts into RMB based on exchange rate tables. For data storage, the system persists the processed data to the target storage medium in a standardized structure, forming a dataset to be verified for subsequent verification and reporting. These operations provide a unified and reliable data foundation for the entire reporting process.

[0053] S304. Automatically analyze the data calculation steps used in the data processing process, determine the source, transformation logic and dependency of the data in the current system based on the data calculation steps, and construct a data lineage map between the original regulatory data and the data to be reported.

[0054] Alternatively, please continue reading Figure 4 During data processing and storage, the raw data undergoes a series of complex transformations (such as SQL queries, script calculations, and function calls) before finally forming the data to be verified. Traditionally, these transformation logics are scattered across various scripts and programs, lacking unified recording and management, making it difficult to trace data issues. To overcome this deficiency, this specification's embodiments introduce an automatic data lineage analysis engine to deeply analyze the computational steps used in the data processing process.

[0055] Specifically, the system captures all operations involving data reading, transformation, and writing through a combination of static code analysis and runtime interception. For example, for ETL scripts, the engine identifies the source table and fields of the data by parsing the SELECT source table, JOIN relationships, WHERE filtering conditions, and GROUP BY aggregation fields in the SQL statement; for stored procedures, the engine extracts the dependency chain between intermediate temporary tables and the final output table by parsing their control flow and data flow; for custom calculation functions, the engine obtains the correspondence between input parameters and output results through bytecode instrumentation or logging. All these parsing results are uniformly stored in a metadata knowledge base, forming a directed acyclic graph with data objects as nodes and transformation operations as edges, i.e., a data lineage graph. This data lineage graph can completely record the entire process of transformation from raw regulatory data to data to be verified, including the source system of each data item, the processing steps it has undergone, the code logic it depends on, and the intermediate temporary data produced. In a preferred embodiment, the data lineage map is also presented in a visual form, and supports backtracking data versions by timeline, providing precise technical support for subsequent source tracing analysis and impact assessment.

[0056] S306. In response to data anomalies, perform data tracing based on data lineage graphs to determine the data source and data link that caused the data anomalies; and / or, in response to changes in regulatory rules, determine the scope of impact of the changes in regulatory rules based on data lineage graphs.

[0057] Optionally, after constructing the data lineage graph, it can be further applied to two key operation and compliance scenarios: data anomaly tracing and analysis of the impact of regulatory rule changes. When the system detects quality issues in the data to be verified, such as a regulatory indicator value exceeding a reasonable range or a report failing verification, operations personnel can select the abnormal data item through the unified monitoring interface to trigger the source tracing analysis function. The system immediately uses the pre-built lineage graph to traverse all upstream dependencies from the abnormal data node, locating the root cause of the problem layer by layer. For example, if the "non-performing loan ratio" indicator is abnormal, the system can trace back to intermediate indicators such as "substandard loan balance" and "doubtful loan balance" on which its calculation depends, and further trace back to the "five-level loan classification" field in the original data source. If a data item is found to be incorrectly labeled, the system can accurately pinpoint the record location of that data item in the source system and its corresponding processing logic. The entire tracing process can generally be completed within minutes, which greatly shortens the troubleshooting time and avoids the inefficiency and omissions of manually searching through scripts layer by layer.

[0058] Furthermore, when regulatory agencies issue new data reporting rules or adjust existing indicator definitions, the system needs to quickly assess the impact of the changes on the existing reporting system. At this point, operations personnel can conduct positive impact analysis based on the lineage graph. Specifically, starting with the affected original data field or processing rule, the system can traverse all downstream data nodes and report indicators forward along the dependency edges in the graph to generate a complete sub-graph of the impact scope. This sub-graph can be arranged using a tree structure. For example, if regulations require changing the calculation of "customer age" from "nominal age" to "actual age," the system can automatically list all reports that directly or indirectly depend on the age field (such as "personal credit statistics table," "risk-weighted asset calculation table," etc.), as well as processing scripts and intermediate tables involving age calculation. Based on these analysis results regarding the scope of impact, a more precise transformation plan can be formulated, requiring only modifications to the affected logic modules without a full-scale investigation, significantly improving rule response efficiency and the level of refinement in change management. Through the design of this data lineage map, the embodiments in this specification automatically construct and dynamically apply data lineage throughout the entire lifecycle of regulatory reporting, enabling rapid location of data issues and accurate assessment of the impact of changes, and significantly improving the system's observability, maintainability, and compliance response capabilities.

[0059] S308. Map the data to be verified to the corresponding entities in the pre-built knowledge graph, and perform semantic reasoning through the relationships in the knowledge graph to identify logical conflicts and compliance issues in the data to be verified.

[0060] Optionally, after obtaining the data to be verified after preliminary processing, it is also necessary to accurately identify the complex compliance issues hidden within and spanning multiple data domains. In order to fundamentally improve the intelligence level and efficiency of verification, the embodiments of this specification introduce a knowledge graph-driven semantic reasoning mechanism.

[0061] For details, please continue reading Figure 4At the knowledge graph and rule engine layer, the system first maps each field in the data to be verified to the corresponding entity nodes in the pre-built knowledge graph. For example, the "borrower name" field in the data record maps to the "customer" entity, "loan contract number" maps to the "contract" entity, and "guarantor information" maps to the "guarantor" entity. This mapping process relies on predefined metadata mapping rules, which have been set according to data standards and regulatory requirements during the system initialization and knowledge graph pre-construction phases. After completing the entity mapping, the system uses the pre-stored semantic relationships in the knowledge graph to perform deep reasoning calculations to identify logical conflicts and compliance issues in the data. The knowledge graph not only records explicit relationships but also defines derived relationships with the assistance of the rule engine. The reasoning engine, based on a graph traversal algorithm, performs multi-hop queries along specific relationship paths starting from the target entity to discover implicit logical connections in the data. For example, when verifying the regulatory indicator of "loan concentration per single customer," the system not only checks whether the total loan amount of a single customer exceeds a certain percentage of net capital, but also automatically identifies related companies of the customer through relationships such as "related parties" and "actual controllers" in the knowledge graph. It also aggregates the total credit lines of group customers to determine whether there is any violation of concealing concentration through related parties. This process does not require manual writing of complex relational query SQL; instead, it is automatically completed by the inference engine based on the graph structure, thus shifting the timing of problem detection from post-event to real-time, significantly improving data quality assurance capabilities.

[0062] S310: Call the configurable transaction rules stored in the rule engine, and combine them with the recognition results obtained after semantic reasoning of the knowledge graph to perform compliance verification on the data to be verified.

[0063] Furthermore, as described in the above embodiments, when knowledge graphs and rule engines work together, more comprehensive compliance verification can be achieved. The rule engine pre-stores a large number of configurable, rigid format rules and logical rules, which originate from regulatory laws, data standards, and transaction specifications, and are transformed into executable decision logic after structured processing. In one feasible implementation, the verification agent, during runtime, can first call the rule engine to perform basic format and logic checks, and then combine the semantic reasoning results from the knowledge graph to conduct in-depth compliance analysis, thereby achieving multi-dimensional and comprehensive verification of the data to be verified. This dual-engine collaborative mechanism ensures both the efficiency of rule execution and fully leverages the advantages of knowledge graphs in complex relational reasoning.

[0064] Specifically, formatting rules in a rule engine are used to check basic data specifications, such as "contract number cannot be empty" and "amount fields must be positive and retain two decimal places." These rules are typically implemented using regular expressions or simple comparison conditions, offering high execution efficiency and suitability for rapid screening of large-scale data. Logical rules, on the other hand, involve more complex constraints, such as "loans classified as 'loss' must have 100% impairment provisions made" and "related party transaction prices must comply with the fairness principle." The execution of these rules often requires consideration of contextual data and semantics, which the rule engine achieves through conditional judgments, computational functions, and table lookup mappings.

[0065] During the specific verification process, the system can adopt a layered collaborative strategy based on the rule engine. First, the rule engine performs efficient format and basic logic verification, quickly filtering out obviously non-compliant data items and generating a preliminary verification report. Then, the system uses the recognition results obtained through semantic reasoning as supplementary input, cross-validating and comprehensively evaluating them with the rule engine's execution results. For example, when the rule engine determines that the guarantee ratio for a loan meets the requirements, but semantic reasoning discovers an implicit relationship between the guarantor and the borrower that might lead to the guarantee's failure, the system will combine the results of both and issue a warning prompt that "manual review is required." This dual-engine collaborative mechanism leverages both the rule engine's high efficiency in handling deterministic rules and the knowledge graph's deep insight capabilities in complex relationship reasoning, achieving comprehensive verification of regulatory data from syntax to semantics, and from single points to relationships. After verification, the system generates a structured verification report, detailing the rules triggered by each data item, potential problems discovered through reasoning, and the comprehensive judgment result, providing clear guidance for subsequent manual review and problem rectification.

[0066] S312. Process the data to be verified that has passed the compliance verification to generate data to be reported that meets the reporting requirements of the target regulatory platform. Depending on the interface type supported by the target regulatory platform, choose to send the data to be reported to the target regulatory platform through the application programming interface, or automatically fill in the data to be reported to the target regulatory platform through preset robot software to simulate manual operation.

[0067] Optionally, after the data to be verified passes the above dual verification, it enters the final reporting and execution stage. The core task of this step is to encapsulate the verified data according to the specific format requirements of each target regulatory platform and reliably deliver it to the target system. However, different regulatory platforms have significantly different requirements for the format of data reporting. For example, some institutions require the submission of message files conforming to a specific XML Schema definition and accompanied by a digital signature; some enterprises require the generation of Excel format report files and uploading them according to specified naming rules; and some platforms that do not have open API interfaces may only provide a web page for manual reporting. Please continue reading Figure 4 In the intelligent reporting and application layer, to address this diversity, the embodiments in this specification first format the verified data according to the technical specifications of the target monitoring platform. The system has a built-in report generation agent that can optimize for one or more output formats. For example, the XML generation agent serializes data into a standard XML document based on an XSD template and automatically calculates the checksum and signature value; the Excel generation agent fills data into specified cells according to a predefined report template and sets cell formatting, formulas, data validation, and other attributes; the JSON generation agent encapsulates the data into a key-value pair JSON object and adds necessary metadata fields.

[0068] Furthermore, after generating the data to be reported, the system needs to select an appropriate sending method based on the interface openness of the target monitoring platform. If the target platform provides a standardized application programming interface (API), the data is transmitted directly through the API reporting service. This method typically uses the HTTP / HTTPS protocol. The system uses the encapsulated data as the request body to initiate a POST or PUT request and processes the response results, including receiving success receipts, parsing error messages, and recording reporting logs. The direct API connection method has the advantages of high transmission efficiency, traceable status, and easy automation integration.

[0069] However, in actual regulatory reporting scenarios, many regulatory platforms still do not have open API interfaces, only supporting users to manually fill in forms or upload files via web pages. To address this, this specification introduces Robotic Process Automation (RPA) technology to overcome the automation bottleneck in such scenarios. The RPA reporting robot cluster consists of multiple software robots, each capable of simulating human operation, automatically completing a series of operations such as opening a browser, logging into the regulatory platform, navigating to the reporting page, filling in form fields, uploading attachments, clicking the submit button, and downloading the receipt file. The robot's behavioral logic is pre-programmed through a visual process designer and can be configured with exception handling and retry mechanisms. For example, when submitting monthly statistical reports to a local financial regulatory bureau, the RPA robot can start daily at a set time, open a specified URL, log in with a username and password, click the "Data Reporting" menu, select the corresponding report file to upload, wait for the system to complete processing, and save a screenshot of the successful submission page as proof. Throughout the process, the robot maintains state synchronization with the backend system, ensuring that the reporting results are traceable and auditable. Through the collaborative adaptation of API and RPA, full-coverage automated reporting to various regulatory platforms has been achieved, ensuring accurate and timely data delivery, significantly shortening the reporting cycle, reducing manual intervention, and improving the success rate and traceability of reporting.

[0070] S314. Display multiple status indicators of the data reporting task through the display interface, and visualize the data lineage graph; store all system operations in the log, and generate an audit report based on the stored log every preset period.

[0071] Alternatively, please continue reading Figure 4 In the visualization monitoring and management layer, to achieve observability, controllability, and auditability of the entire regulatory reporting process, this specification also constructs a unified visualization monitoring and management layer, providing managers with an intuitive and comprehensive view of system operation. The system displays multiple key status indicators of data reporting tasks in real time through a unified monitoring screen. For example, these indicators include, but are not limited to: the current progress of each reporting task (e.g., "Pending," "Processing," "Completed," "Failed"), success rate (number of successful tasks / total number of tasks), average processing time, data quality score (calculated based on the pass rate of verification rules), and a list of abnormal tasks. The monitoring interface uses graphical presentation methods, such as a line chart to show the trend of success rate over time, a bar chart to compare the reporting volume of various regulatory platforms, and a pie chart to show the distribution of failure reasons. Managers can clearly grasp the overall system operation status at a glance and promptly identify anomalies and bottlenecks.

[0072] Optionally, the data lineage graph can be integrated into the monitoring interface in a visual format. The lineage graph displays the complete flow path from the original data source to the final reported report in the form of a directed acyclic graph. Each node in the graph represents a data entity (such as a source table, intermediate table, or report indicator), and each directed edge represents a data transformation operation (such as an SQL query or script calculation). Users can drill down into any node to view its detailed metadata information, including field definitions, data sources, transformation logic, dependent upstream nodes, and affected downstream nodes. When data anomalies occur, users can directly click on the abnormal data item in the lineage graph to trigger a source tracing analysis process. The system automatically highlights the complete path from that node to the root data source and marks the possible fault points identified. When regulatory rules change, users can also select the affected data field to trigger impact analysis. The system automatically lists all downstream reports and processing scripts that directly or indirectly depend on that field. This visual analysis method greatly reduces the complexity of data problem investigation and change impact assessment.

[0073] In a preferred embodiment, a complete audit log mechanism is also constructed. The system records all key operations, including the start time, operator (or system module), input / output summary, and execution result of data extraction, processing, verification, and reporting. The logs are stored in a structured format in a highly reliable database, and a reasonable lifecycle management strategy is set. Every preset period (e.g., monthly), the system automatically generates a standard-format audit report based on the stored logs. The report content includes a summary of reporting tasks for the period, statistics of abnormal events, operation behavior records, and data quality trend analysis, meeting the compliance requirements of internal and external audits for traceability and verifiability of the reporting process. Furthermore, the audit report can be exported as a PDF or Excel file for the compliance department to archive for future reference. Through the visual monitoring and audit mechanism, the observability and auditability of the entire regulatory reporting system are improved, enabling managers to grasp the system status in real time, quickly locate the root cause of problems, accurately assess the impact of changes, and provide complete and reliable operation records for compliance audits, comprehensively improving the system's operation and maintenance capabilities and compliance management level.

[0074] This specification provides a data reporting method that systematically addresses the core pain points of traditional regulatory reporting, such as data fragmentation, difficulty in quality control, low efficiency, and difficulty in traceability, through end-to-end automation and intelligent technologies. First, a multimodal intelligent agent automatically extracts heterogeneous data and processes it according to multi-platform requirements, significantly improving data preparation efficiency and consistency, laying a reliable foundation for subsequent steps. Next, through automatic data lineage analysis and graph construction, the entire data flow path from source to report is fully recorded, achieving end-to-end traceability. When data is abnormal, the root cause can be quickly traced back; when regulatory rules change, the scope of impact can be accurately assessed, greatly shortening troubleshooting and rule response time and reducing operational costs. During compliance verification, a dual mechanism of knowledge graph semantic reasoning and rule engine is introduced, transforming static regulatory rules into a dynamic, reasonable semantic network. This enables the discovery of deep logical conflicts and cross-domain compliance risks, shifting the timing of problem discovery from post-event to in-event, significantly improving data quality and compliance, and effectively mitigating regulatory penalty risks. The reporting and execution process employs a flexible adaptation mechanism combining direct API connection and RPA robot collaboration, enabling automated data entry and submission regardless of whether the target platform has an open interface. Furthermore, a visual monitoring dashboard displays task status and lineage graphs in real time, supplemented by complete audit logs and periodic report generation, giving the system a high degree of observability and auditability. This makes operations and maintenance management more intuitive, decision-making more accurate, and fully meets internal and external compliance audit requirements.

[0075] Please see Figure 5 , Figure 5 This is a structural block diagram of a data reporting device provided in an embodiment of this specification. Figure 5 As shown, the data reporting device 500 includes: The data acquisition module 510 is used to automatically extract raw regulatory data from multiple heterogeneous data sources and process the raw regulatory data according to the reporting requirements of multiple regulatory platforms to obtain data to be verified. The raw regulatory data includes structured data, semi-structured data and unstructured data. The compliance verification module 520 is used to perform compliance verification on the data to be verified based on a pre-built knowledge graph. The knowledge graph uses entities extracted from multiple regulatory rules as nodes and the relationships between entities as edges connecting the nodes. The intelligent reporting module 530 is used to process the data to be verified that has passed the compliance verification, generate data to be reported that meets the reporting requirements of the target regulatory platform, and send the data to be reported to the target regulatory platform.

[0076] Optionally, the data reporting device 500 further includes a knowledge graph construction module, which is used to extract entities and relationships between entities from multiple regulatory rule files, and to standardize the definition of entities according to data standards to form a knowledge graph with entities as nodes and relationships as edges.

[0077] Optionally, the compliance verification module 520 is also used to map the data to be verified to the corresponding entities in the pre-built knowledge graph, and to perform semantic reasoning through the relationships in the knowledge graph to identify logical conflicts and compliance issues in the data to be verified.

[0078] Optionally, the compliance verification module 520 is also used to call the configurable transaction rules pre-stored in the rule engine, and combine them with the recognition results obtained after semantic reasoning of the knowledge graph to perform compliance verification on the data to be verified.

[0079] Optionally, the data processing methods include at least organization, computation, and storage.

[0080] Optionally, the data reporting device 500 further includes a data lineage construction module, which is used to automatically parse the data calculation steps used in the data processing process, determine the source, transformation logic and dependency relationship of the data in the current system based on the data calculation steps, and construct a data lineage map between the original regulatory data and the data to be reported.

[0081] Optionally, the data reporting device 500 further includes: a data lineage tracing module, used to trace the source of data based on the data lineage graph in response to data anomalies, so as to determine the data source and data link that caused the data anomalies; and / or, in response to changes in regulatory rules, to determine the scope of impact of the changes in regulatory rules based on the data lineage graph.

[0082] Optionally, the intelligent reporting module 530 is also used to select, based on the interface type supported by the target regulatory platform, to send the data to be reported to the target regulatory platform via an application programming interface, or to automatically fill in the data to be reported to the target regulatory platform by simulating manual operation through preset robot software.

[0083] Optionally, the data reporting device 500 also includes: a visualization monitoring module, used to display multiple status indicators of the data reporting task through a display interface and to visualize the data lineage map; to store all system operations in a log and to generate an audit report based on the stored logs every preset period.

[0084] In this embodiment of the specification, a data reporting device is provided, wherein a data acquisition module is used to automatically extract raw regulatory data from multiple heterogeneous data sources and process the raw regulatory data according to the reporting requirements of multiple regulatory platforms to obtain data to be verified. The raw regulatory data includes structured data, semi-structured data, and unstructured data. A compliance verification module is used to perform compliance verification on the data to be verified based on a pre-built knowledge graph. The knowledge graph uses entities extracted from multiple regulatory rules as nodes and the relationships between entities as edges connecting the nodes. An intelligent reporting module is used to process the data to be verified that has passed the compliance verification, generate data to be reported that meets the reporting requirements of the target regulatory platform, and send the data to be reported to the target regulatory platform. First, raw regulatory data is extracted from multiple heterogeneous data sources using automated methods. Based on this, and according to the different reporting requirements of various regulatory platforms, the extracted raw data undergoes targeted data processing to obtain data to be verified. This process transforms fragmented and heterogeneous raw information into a preliminarily compliant dataset, laying a unified data foundation for subsequent verification processes. It achieves automated access and preprocessing of multi-source heterogeneous data, significantly improving data integration efficiency and accuracy. Simultaneously, through on-demand processing, the raw data can be adapted to the differentiated requirements of multiple regulatory platforms, providing standardized and structured input data for subsequent verification stages. Furthermore, by introducing a pre-built knowledge graph, the data to be verified is mapped to corresponding entities in the graph during verification, automatically identifying compliance issues within the data. This operation transforms static regulatory rules into dynamic knowledge reasoning capabilities, enabling the system to proactively discover hidden compliance risks in the data. This graph-based verification method improves the comprehensiveness and accuracy of verification and shifts the timing of problem discovery from post-event to in-event, effectively preventing non-compliant data from entering subsequent reporting stages. Finally, based on the specific requirements of the target regulatory platform, the data to be verified that has passed compliance checks is further processed to generate data to be reported in accordance with its reporting format. This data is then sent to the target regulatory platform. This design achieves automated reporting, significantly shortening the reporting cycle and improving response speed. Through a knowledge graph-driven compliance check and automated reporting process, the problems of data dispersion, low quality and efficiency, and difficulty in traceability in traditional reporting methods are systematically solved, realizing the intelligentization of regulatory reporting work.

[0085] This specification provides a computer program product containing instructions that, when run on a computer or processor, cause the computer or processor to perform the steps of any of the methods described above.

[0086] This specification also provides a computer storage medium that can store multiple instructions adapted for loading by a processor and executing the steps of any of the methods described in the above embodiments.

[0087] Please see Figure 6 , Figure 6 This is a schematic diagram of the structure of a terminal provided in an embodiment of this specification. Figure 6 As shown, terminal 101 may include: at least one terminal processor 601, at least one network interface 604, user interface 603, memory 605, and at least one communication bus 602.

[0088] The communication bus 602 is used to enable communication between these components.

[0089] The user interface 603 may include a display screen and a camera. Optionally, the user interface 603 may also include a standard wired interface and a wireless interface.

[0090] The network interface 604 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0091] The terminal processor 601 may include one or more processing cores. The terminal processor 601 connects to various parts within the terminal 101 using various interfaces and lines, and performs various functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in the memory 605, and by calling data stored in the memory 605. Optionally, the terminal processor 601 may be implemented using at least one hardware form selected from Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), and Programmable Logic Array (PLA). The terminal processor 601 may integrate one or a combination of several of the following: a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), and a modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content required for display on the screen; and the modem handles wireless communication. It is understood that the modem may also be implemented as a separate chip without being integrated into the terminal processor 601.

[0092] The memory 605 may include random access memory (RAM) or read-only memory (ROM). Optionally, the memory 605 may include a non-transitory computer-readable storage medium. The memory 605 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 605 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the above-described method embodiments, etc.; the data storage area may store data involved in the above-described method embodiments, etc. Optionally, the memory 605 may also be at least one storage device located remotely from the aforementioned terminal processor 601. Figure 6 As shown, the memory 605, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and a data reporting program.

[0093] exist Figure 6 In the terminal 101 shown, the user interface 603 is mainly used to provide an input interface for the user and to obtain the user's input data; while the terminal processor 601 can be used to call the data reporting program stored in the memory 605 and specifically perform the following operations: The system automatically extracts raw regulatory data from multiple heterogeneous data sources and processes the raw regulatory data according to the reporting requirements of multiple regulatory platforms to obtain data to be verified. The raw regulatory data includes structured data, semi-structured data, and unstructured data. Compliance verification of the data to be verified is performed based on a pre-built knowledge graph. The knowledge graph uses entities extracted from multiple regulatory rules as nodes and the relationships between the entities as edges connecting the nodes. The data to be verified that has passed the compliance check is processed to generate data to be reported that meets the reporting requirements of the target regulatory platform, and then the data to be reported is sent to the target regulatory platform.

[0094] In some embodiments, the terminal processor 601 further performs the following steps: extracting entities and relationships between entities from multiple regulatory rule files, and defining entities in a standardized manner according to data standards to form a knowledge graph with entities as nodes and relationships as edges.

[0095] In some embodiments, when the terminal processor 601 performs compliance verification on the data to be verified based on a pre-built knowledge graph, it specifically performs the following steps: mapping the data to be verified to the corresponding entity in the pre-built knowledge graph, performing semantic reasoning through the relationships in the knowledge graph, and identifying logical conflicts and compliance issues in the data to be verified.

[0096] In some embodiments, when the terminal processor 601 performs compliance verification on the data to be verified based on a pre-built knowledge graph, it specifically performs the following steps: calling the configurable transaction rules pre-stored in the rule engine, and combining the recognition results obtained after semantic reasoning on the knowledge graph to perform compliance verification on the data to be verified.

[0097] In some embodiments, data processing methods include at least organizing, computing, and storing.

[0098] In some embodiments, the terminal processor 601 further performs the following steps: automatically parses the data calculation steps used in the data processing process, determines the source, transformation logic and dependency of the data in the current system based on the data calculation steps, and constructs a data lineage map between the original regulatory data and the data to be reported.

[0099] In some embodiments, the terminal processor 601 further performs the following steps: in response to data anomalies, performing data tracing based on a data lineage graph to determine the data source and data link causing the data anomalies; and / or, in response to changes in regulatory rules, determining the scope of impact of the changes in regulatory rules based on a data lineage graph.

[0100] In some embodiments, when the terminal processor 601 sends the data to be reported to the target regulatory platform, it specifically performs the following steps: depending on the interface type supported by the target regulatory platform, it selects to send the data to be reported to the target regulatory platform through an application programming interface, or to automatically fill in the data to be reported to the target regulatory platform by simulating manual operation through preset robot software.

[0101] In some embodiments, the terminal processor 601 further performs the following steps: displaying multiple status indicators of the data reporting task through a display interface and visually displaying the data lineage graph; storing all system operations in a log and generating an audit report based on the stored logs every preset period.

[0102] In the several embodiments provided in this specification, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or modules may be electrical, mechanical, or other forms.

[0103] The modules described as separate components may or may not be physically separate. Similarly, the components shown as modules may or may not be physical modules; they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0104] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When these computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this specification are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in or transmitted through a computer-readable storage medium. The computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The aforementioned available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., Digital Versatile Discs (DVDs)), or semiconductor media (e.g., Solid State Disks (SSDs)).

[0105] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments in this specification are not limited to the described order of actions, because according to the embodiments in this specification, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in this specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the embodiments in this specification.

[0106] Furthermore, it should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.), and signals involved in the embodiments of this specification are all authorized by the user or fully authorized by all parties, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. For example, the documents and data involved in this specification were obtained under full authorization.

[0107] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0108] The above is a description of a data reporting method, apparatus, storage medium, and terminal provided in the embodiments of this specification. For those skilled in the art, based on the ideas of the embodiments of this specification, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation on the embodiments of this specification.

Claims

1. A data reporting method, the method comprising: The system automatically extracts raw regulatory data from multiple heterogeneous data sources using multimodal intelligent agents, and processes the raw regulatory data according to the reporting requirements of multiple regulatory platforms to obtain data to be verified. The raw regulatory data includes structured data, semi-structured data, and unstructured data. The multimodal intelligent agents include a first type of intelligent agent for structured data, a second type of intelligent agent for semi-structured data, and a third type of intelligent agent for unstructured data. The agents perform data extraction operations in parallel through a collaborative mechanism. The compliance verification of the data to be verified is performed based on a pre-built knowledge graph, in which entities extracted from multiple regulatory rules are used as nodes, and the relationships between the entities are used as edges connecting the nodes. The data to be verified that has passed the compliance verification is processed to generate data to be reported that meets the reporting requirements of the target regulatory platform, and the data to be reported is sent to the target regulatory platform. The compliance verification of the data to be verified based on the pre-built knowledge graph includes: mapping the data to be verified to the corresponding entities in the pre-built knowledge graph, performing semantic reasoning through the relationships in the knowledge graph, and identifying logical conflicts and compliance issues in the data to be verified.

2. The method according to claim 1, further comprising: Entities and relationships between entities are extracted from multiple regulatory rule documents, and the entities are standardized and defined according to data standards to form a knowledge graph with entities as nodes and relationships as edges.

3. The method according to claim 1, wherein the compliance verification of the data to be verified based on the pre-constructed knowledge graph includes: The configurable transaction rules pre-stored in the rule engine are invoked, and the recognition results obtained after semantic reasoning on the knowledge graph are combined to perform compliance verification on the data to be verified.

4. The method according to claim 1, wherein the data processing includes at least organization, calculation, and storage.

5. The method according to claim 1, further comprising: The system automatically analyzes the data calculation steps used in the data processing process, determines the source, transformation logic and dependency of the data in the current system based on the data calculation steps, and constructs a data lineage map between the original regulatory data and the data to be reported.

6. The method according to claim 5, further comprising: In response to data anomalies, data tracing is performed based on the data lineage map to determine the data source and data link that caused the data anomalies; And / or, in response to a change in regulatory rules, determine the scope of impact of the change in regulatory rules based on the data lineage graph.

7. The method according to claim 1, wherein sending the data to be reported to the target monitoring platform comprises: Depending on the interface type supported by the target monitoring platform, the data to be reported can be sent to the target monitoring platform via an application programming interface (API), or the data to be reported can be automatically filled into the target monitoring platform by a preset robot software that simulates manual operation.

8. The method according to claim 5, further comprising: The system displays multiple status indicators of the data reporting task through a display interface and visualizes the data lineage map. All system operations are stored in logs, and audit reports are generated based on the stored logs at preset intervals.

9. A data reporting device, the device comprising: The data acquisition module is used to automatically extract raw regulatory data from multiple heterogeneous data sources through multimodal intelligent agents, and process the raw regulatory data according to the reporting requirements of multiple regulatory platforms to obtain data to be verified. The raw regulatory data includes structured data, semi-structured data, and unstructured data. The multimodal intelligent agents include a first type of intelligent agent for structured data, a second type of intelligent agent for semi-structured data, and a third type of intelligent agent for unstructured data. The intelligent agents perform data extraction operations in parallel through a collaborative mechanism. The compliance verification module is used to perform compliance verification on the data to be verified based on a pre-built knowledge graph, wherein the knowledge graph uses entities extracted from multiple regulatory rules as nodes and the relationships between the entities as edges connecting the nodes. The intelligent reporting module is used to process the data to be verified that has passed the compliance verification, generate data to be reported that meets the reporting requirements of the target regulatory platform, and send the data to be reported to the target regulatory platform. The compliance verification module is also used to map the data to be verified to the corresponding entities in the pre-built knowledge graph, and to perform semantic reasoning through the relationships in the knowledge graph to identify logical conflicts and compliance issues in the data to be verified.

10. A computer program product comprising instructions that, when run on a computer or processor, causes the computer or processor to perform the steps of the method as claimed in any one of claims 1 to 8.

11. A computer storage medium storing a plurality of instructions adapted for loading by a processor and performing the steps of the method as claimed in any one of claims 1 to 8.

12. A terminal comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the method as claimed in any one of claims 1 to 8.

Images