Financial data query method and device and electronic equipment

Abstract

This application provides a financial data query method, apparatus, and electronic device, relating to the fields of artificial intelligence and database information processing technology. The method receives user natural language queries, uses a financial business large language model to parse and form a query task containing data dimensions, time ranges, and computational rules, performs a risk assessment based on query intent, data sensitivity, access patterns, and user permissions, determines a tiered response method, and extracts and aggregates data from multiple heterogeneous data sources accordingly. The generated query results are then converted into an editable document and output in a preset format. This method improves the accuracy of analyzing complex financial needs, the timeliness of multi-source data processing, and the consistency of results, while enhancing the compliance of sensitive data access and the convenience of output use.

Description

Technical Field

[0001] This application relates to the fields of artificial intelligence and database information processing technology, and in particular to a financial data query method, device and electronic device. Background Technology

[0002] In the financial industry, frequent cross-system and multi-dimensional data queries and report generation are required for regulatory compliance reporting, internal operational analysis, and risk control. As business complexity increases, higher demands are placed on the real-time performance, accuracy, and flexibility of data queries.

[0003] In existing technologies, financial institutions mainly rely on two types of query solutions: one is a query system based on preset rules, where users input query conditions through a graphical interface or a fixed field selector, and the system executes the query according to predefined templates or rules. This solution only supports queries with preset fields and fixed dimensions and cannot cope with the complex needs of natural language descriptions. The other type is a natural language processing system based on a general large language model, which executes queries by converting natural language into query statements. However, the general model has limited semantic understanding of specific financial terms, which can easily lead to ambiguity. Furthermore, the query results cannot trace the data source, and compliance control also relies on static permission rules.

[0004] Therefore, how to accurately understand the complex query needs in the financial field and output traceable and editable query results while ensuring data security and compliance is a technical problem that urgently needs to be solved in the field of financial data query. Summary of the Invention

[0005] This application provides a financial data query method, apparatus, and electronic device to solve the aforementioned technical problems. This solution targets financial data query scenarios, focusing on understanding users' natural query needs, risk control during the query process, and data acquisition and result generation across heterogeneous data sources. It constructs an integrated query processing mechanism, enabling complex financial query requests to be accurately identified and processed to produce results matching business semantics, thereby improving the processing efficiency, result accuracy, and compliance adaptability of financial data queries.

[0006] Firstly, this application provides a method for querying financial data, including:

[0007] The system obtains the natural language query statement input by the user, performs semantic parsing on the natural language query statement through the financial business big language model, and generates a query instruction, which includes data dimensions, time range and calculation logic.

[0008] Based on the query command, a risk assessment is performed on the query intent, data sensitivity of the requested data, and access pattern to obtain the assessment result. Based on the assessment result and user permissions, a tiered response strategy is determined.

[0009] According to the hierarchical response strategy, corresponding source data is obtained from multiple heterogeneous data sources, and the multiple source data are aggregated to obtain query results;

[0010] The query results are converted into an editable document and output according to a preset output format.

[0011] In one possible embodiment, the step of semantically parsing the natural language query statement using a financial business big language model to generate a query instruction includes:

[0012] By using an incrementally trained financial terminology database, preliminary semantic mapping is performed on the financial terms in the natural language query statement to obtain basic parsing results;

[0013] Based on the user's historical query records and / or the current session context, ambiguous financial terms in the basic parsing results are corrected;

[0014] Based on the corrected parsing results, the data dimensions and time ranges in the natural language query are extracted to obtain the target parsing results;

[0015] Based on the financial data dictionary, the computational requirements in the natural language query statement are mapped to the corresponding computational logic, and the query instruction is generated according to the target parsing result and the computational logic.

[0016] In one possible embodiment, the risk assessment based on the query instruction, considering the query intent, data sensitivity of the requested data, and access patterns, to obtain the assessment result includes:

[0017] Based on the query instruction, identify the business scenario and purpose corresponding to the current query, and determine the risk level of the query intent;

[0018] Based on the data fields requested by the query command, a preset sensitive field library is matched to determine the sensitive fields and sensitivity levels included in the requested data;

[0019] Obtain the user's historical access records, and based on preset abnormal behavior judgment rules, perform abnormal detection on the user's access frequency, access time period and access scope to determine the risk level of the access pattern;

[0020] The user permissions are compared with the query intent, the sensitive fields, and the historical access records to obtain the permission verification result.

[0021] The evaluation result is determined based on the risk level of the query intent, the sensitivity level, the risk level of the access mode, and the permission verification result, according to preset risk rules.

[0022] In one possible embodiment, determining the tiered response strategy based on the evaluation results and user permissions includes:

[0023] The risk level of the current query is determined based on the assessment results, and the permission level is determined based on the user's permissions.

[0024] The risk level is matched with the permission level to determine the response level corresponding to the current query;

[0025] Based on the response level, the corresponding response action and data output method are matched from a preset hierarchical response strategy table; wherein, the hierarchical response strategy table defines the mapping relationship between different response levels and response actions and data output methods, and the response action includes at least one or more combinations of allowing access, data anonymization processing, and denying access.

[0026] In one possible embodiment, the step of obtaining corresponding source data from multiple heterogeneous data sources according to the hierarchical response strategy, and aggregating the multiple source data to obtain query results, includes:

[0027] When the hierarchical response strategy allows access, the target data source identifier and required data fields are determined according to the query instruction;

[0028] Call the target data access interface corresponding to the target data source identifier, and obtain the original data from the corresponding heterogeneous data source through the target data access interface;

[0029] The obtained raw data is subjected to format standardization processing and field mapping to obtain standard data with a unified format;

[0030] The query results are obtained by associating and aggregating multiple sets of standard data.

[0031] In one possible embodiment, the step of invoking the target data access interface corresponding to the target data source identifier, and obtaining the original data from the corresponding heterogeneous data source through the target data access interface, includes:

[0032] Identify the interface type of the target data access interface;

[0033] When the interface type is a relational database interface, a structured query statement is constructed, and the statement is executed through the relational database interface to obtain the original data;

[0034] When the interface type is a non-relational database interface, a corresponding non-relational data query statement is constructed, and the non-relational data query statement is executed through the non-relational database interface to obtain the original data;

[0035] When the interface type is an application programming interface (API), a hypertext transfer request is constructed, and the request is sent through the API to obtain the raw data.

[0036] In one possible embodiment, converting the query results into an editable document and outputting it according to a preset output format includes:

[0037] Based on the query results, an editable document containing traceability information about the relationship between each data item and its corresponding source data is generated.

[0038] The editable document is output according to the preset output format.

[0039] Secondly, this application provides a financial data query device, comprising:

[0040] The acquisition module is used to acquire the natural language query statement input by the user;

[0041] The processing module is used to perform semantic parsing on the natural language query statement through the financial business big language model and generate query instructions, which include data dimensions, time range and calculation logic;

[0042] The processing module is also used to perform a risk assessment on the query intent, data sensitivity of the requested data and access mode of the current query based on the query instruction, obtain the assessment result, and determine a hierarchical response strategy based on the assessment result and user permissions.

[0043] The processing module is further configured to obtain corresponding source data from multiple heterogeneous data sources according to the hierarchical response strategy, and aggregate the multiple source data to obtain query results;

[0044] The processing module is also used to convert the query results into an editable document and output it according to a preset output format.

[0045] In one possible embodiment, the processing module is further configured to perform preliminary semantic mapping on the financial terms in the natural language query statement using an incrementally trained financial terminology database to obtain basic parsing results;

[0046] The processing module is also used to correct ambiguous financial terms in the basic parsing results based on the user's historical query records and / or the current session context.

[0047] The processing module is also used to extract the data dimensions and time range in the natural language query statement based on the corrected parsing results, and obtain the target parsing result;

[0048] The processing module is further configured to map the computational requirements in the natural language query statement to corresponding computational logic based on a financial data dictionary, and generate the query instruction according to the target parsing result and the computational logic.

[0049] In one possible embodiment, the processing module is further configured to identify the business scenario and purpose corresponding to the current query based on the query instruction, and determine the risk level of the query intent;

[0050] The processing module is also used to match a preset sensitive field library with the data fields requested by the query instruction, and determine the sensitive fields and sensitivity levels included in the requested data;

[0051] The acquisition module is also used to acquire the user's historical access records;

[0052] The processing module is also used to perform anomaly detection on the user's access frequency, access time period and access range based on preset abnormal behavior judgment rules, and determine the risk level of the access mode.

[0053] The processing module is also used to perform compliance verification on the user's permissions, the query intent, the sensitive fields, and the historical access records to obtain the permission verification result;

[0054] The processing module is further configured to determine the evaluation result based on the risk level of the query intent, the sensitivity level, the risk level of the access mode, and the permission verification result, according to preset risk rules.

[0055] In one possible embodiment, the processing module is further configured to determine the risk level of the current query based on the assessment result, and determine the permission level based on user permissions;

[0056] The processing module is further configured to match the risk level with the permission level to determine the response level corresponding to the current query;

[0057] The processing module is further configured to match the corresponding response action and data output method from a preset hierarchical response strategy table according to the response level; wherein, the hierarchical response strategy table defines the mapping relationship between different response levels and response actions and data output methods, and the response action includes at least one or more combinations of allowing access, data anonymization processing, and denying access.

[0058] In one possible embodiment, the processing module is further configured to determine the target data source identifier and the required data fields for the current query based on the query instruction when the hierarchical response policy allows access;

[0059] The processing module is also used to call the target data access interface corresponding to the target data source identifier, and obtain the original data in the corresponding heterogeneous data source through the target data access interface;

[0060] The processing module is also used to perform format standardization processing and field mapping on the acquired raw data to obtain standard data with a unified format.

[0061] The processing module is also used to perform correlation and aggregation on multiple sets of standard data to obtain the query results.

[0062] In one possible embodiment, the processing module is further configured to identify the interface type of the target data access interface;

[0063] The processing module is further configured to construct a structured query statement when the interface type is a relational database interface, and execute the statement through the relational database interface to obtain the original data;

[0064] The processing module is further configured to construct a corresponding non-relational data query statement when the interface type is a non-relational database interface, and execute the non-relational data query statement through the non-relational database interface to obtain the original data;

[0065] The processing module is further configured to construct a hypertext transfer request when the interface type is an application programming interface (API), and send the request through the API to obtain the raw data.

[0066] In one possible embodiment, the processing module is further configured to generate an editable document containing traceability information about the association between each data item and the corresponding source data based on the query results;

[0067] The processing module is also used to output the editable document according to a preset output format.

[0068] Thirdly, this application provides an electronic device, including: a processor, and a memory communicatively connected to the processor;

[0069] The memory stores computer-executed instructions;

[0070] The processor executes computer execution instructions stored in the memory to implement the financial data query method as described in the first aspect and various possible implementations of the first aspect.

[0071] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions thereon, which, when executed by a processor, are used to implement the financial data query method as described in the first aspect and various possible implementations of the first aspect.

[0072] Fifthly, this application provides a program product, including a computer program, which, when executed by a processor, implements the financial data query method described above.

[0073] The financial data query method, apparatus, and electronic device provided in this application relate to the fields of artificial intelligence and database information processing technology. This method, by acquiring the natural language query statement input by the user and generating query instructions containing data dimensions, time ranges, and computational logic based on a large financial business language model, can improve the semantic understanding ability and instruction conversion accuracy for complex financial query needs, thereby improving query processing efficiency and result accuracy. By conducting risk assessments on the query intent, the data sensitivity of the requested data, and the access pattern, and combining this with user permissions to determine a tiered response strategy, it can implement differentiated compliance control over the financial data access process, thereby enhancing the security of sensitive data access and the auditability of the query process. By acquiring and aggregating corresponding source data from multiple heterogeneous data sources according to the tiered response strategy, and simultaneously converting the query results into editable documents and outputting them according to a preset output format, it can improve cross-source data integration and result delivery capabilities, thus balancing the real-time nature and consistency of query results with subsequent editing, retention, and traceability requirements. Attached Figure Description

[0074] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0075] Figure 1 A flowchart illustrating a financial data query method provided in this application. Figure 1 ;

[0076] Figure 2 A flowchart illustrating a financial data query method provided in this application. Figure 2 ;

[0077] Figure 3 A flowchart illustrating a financial data query method provided in this application. Figure 3 ;

[0078] Figure 4 A schematic diagram of the structure of a financial data query device provided in this application;

[0079] Figure 5This is a schematic diagram of the structure of an electronic device provided in this application.

[0080] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0081] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0082] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of the relevant data all comply with relevant laws, regulations, and standards, necessary confidentiality measures have been taken, they do not violate public order and good morals, and corresponding operation portals are provided for users to choose to authorize or refuse.

[0083] Furthermore, the technical solution involved in this application, which involves big data analysis of user information (including but not limited to personal biometrics, identity data, consumption data, asset data, electronic terminal operation data, etc.) and the use of artificial intelligence technology for automated decision-making, and makes decisions that have a significant impact on personal rights based on the results of automated decision-making, provides users with corresponding operation entry points for users to choose to agree to or reject the results of automated decision-making; if the user chooses to reject, the process will proceed to the expert decision-making process.

[0084] It should be noted that the financial data query method, device, and electronic equipment provided in this application can be used in the fields of artificial intelligence and database information processing technology, or in any field other than artificial intelligence and database information processing. This application does not limit the application field of the financial data query method, device, and electronic equipment.

[0085] Financial data query and report generation technologies are widely used in regulatory reporting, operational analysis, and risk management scenarios for financial institutions such as banks and securities companies. In actual business operations, data is usually stored in multiple heterogeneous data sources, such as core trading systems, customer management systems, credit systems, and external interfaces. Staff need to initiate queries based on terminals and output the processing results as documents that are easy to circulate and review.

[0086] In existing technologies, financial institutions mainly rely on two types of query solutions: one is a query system based on preset rules, where users input query conditions through a graphical interface or fixed field selector, and the system executes the query according to predefined templates or rules. This solution only supports queries with preset fields and fixed dimensions and cannot cope with the complex needs of natural language descriptions. The other type is a natural language processing system based on a general large language model, which realizes natural language interaction to a certain extent by converting natural language queries into SQL statements (structured query statements). However, the general model has limited semantic understanding of specific financial terms (such as "provincial branch" and "non-performing loans"), which is prone to ambiguity or misinterpretation. Moreover, the query results are usually static, and users cannot trace the data source or verify the calculation logic. Compliance control also relies on static permission rules, making it difficult to achieve real-time dynamic assessment.

[0087] However, in financial scenarios, there are many complex business terms, cross-source data associations, and dynamic statistical definitions. General solutions often struggle to accurately understand the data dimensions, time ranges, and calculation logic in natural language queries, leading to inconsistencies between query commands and actual needs. Furthermore, existing solutions rely heavily on static access control when dealing with data requests of varying sensitivity levels. This makes it difficult to conduct real-time risk assessments based on query intent, data sensitivity, and access patterns, potentially resulting in insufficient control over sensitive data or the unwarranted restriction of legitimate requests.

[0088] Furthermore, differences in format, interface, and update frequency among multi-source data mean that manual correction or pre-modeling significantly lengthens the query and report generation cycle, weakening the consistency and timeliness of the results. If the output is merely a static file, it further impacts subsequent editing, review, and audit traceability, making it difficult to meet the comprehensive requirements of financial institutions for efficiency, compliance, and usability.

[0089] To address the aforementioned issues, this application provides a financial data query method, apparatus, and electronic device. After obtaining a natural language query statement input by a user, the method performs semantic parsing using a financial business big language model to generate a query instruction that includes data dimensions, time range, and calculation logic. Furthermore, it conducts a risk assessment based on the query intent, the data sensitivity of the requested data, and the access pattern, and determines a tiered response strategy in conjunction with user permissions.

[0090] This method can be deployed on dedicated business servers or local processing terminals within the intranet of banks or securities companies. It uses a financial business big language model to semantically parse the natural language query statements input by users to generate structured query instructions. The real-time compliance audit layer performs dynamic risk assessment on the query intent, data sensitivity, and access patterns and determines a hierarchical response strategy. According to the hierarchical response strategy, source data is obtained from multiple heterogeneous data sources, aggregated, and calculated to obtain the query results. The query results are converted into an editable document and the correlation and traceability information between each data item and the source data is retained before output. This realizes the fully automated processing of financial data query from natural language understanding, multi-source data aggregation, dynamic compliance control to traceable document generation.

[0091] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0092] Figure 1 A flowchart illustrating a financial data query method provided in this application embodiment. Figure 1 .like Figure 1 As shown, the financial data query method provided in this embodiment includes:

[0093] S101. Obtain the natural language query statement input by the user, perform semantic parsing on the natural language query statement through the financial business big language model, and generate query instructions.

[0094] The query command includes data dimensions, time range, and calculation logic.

[0095] Natural language queries are used to carry user-inputted query requests. Upon receiving these queries, they are used as input for financial business semantic understanding. The financial business big language model is used to semantically parse the natural language queries and transform the natural language requests into executable structured query expressions.

[0096] The query command is used to carry the structured information required for subsequent query execution. It includes at least data dimensions, time range, and calculation logic. The data dimensions are used to represent the business analysis scope that the query is concerned with, the time range is used to represent the time boundary of data retrieval, and the calculation logic is used to represent summation, counting, grouping, month-on-month comparison, year-on-year comparison, or other statistical processing rules.

[0097] One possible implementation is that users can input their query content via a terminal, and the received text can be processed as needed for subsequent semantic parsing. For example, if a user inputs "Statistics on the corporate loan balance of each branch in East China in the previous quarter, and summarized by industry," the system can identify the time range corresponding to "previous quarter," the data dimension corresponding to "each branch in East China," the query object corresponding to "corporate loan balance," and the calculation logic corresponding to "summarized by industry."

[0098] The financial business big data model is deployed in the data query system and performs semantic parsing on natural language queries to extract information relevant to the query, which is then organized into query instructions. Specifically, the structured results output by the model can include indicator name fields, data dimension fields, time fields, and calculation logic fields, which are further organized into query instructions.

[0099] After generating a query instruction, a completeness and consistency check is performed on the query instruction. If any missing or conflicting items are found, a problem to be confirmed is reported. After confirmation, a final query instruction is generated and passed to the subsequent risk assessment process.

[0100] By performing a structured transformation of natural language query statements at the financial semantic level, subsequent risk assessment and multi-source data access are all executed based on a unified query expression, thereby enabling complex business descriptions to be accurately transformed into executable query tasks.

[0101] S102. Based on the query command, perform a risk assessment on the query intent, data sensitivity of the requested data, and access mode of the current query, obtain the assessment results, and determine the hierarchical response strategy according to the assessment results and user permissions.

[0102] Once the query command is generated, it serves as the input for risk assessment. The risk assessment is not based solely on static authorization judgments based on user identity, but rather on a joint analysis of query intent, data sensitivity, and access patterns.

[0103] Query intent is used to characterize the purpose or type of the current request; data sensitivity is used to characterize the sensitivity of the requested fields and data sets; access pattern is used to characterize the dynamic characteristics of the current request in terms of time, frequency, scope, and behavioral trajectory.

[0104] The assessment results can be a combination of risk level, sensitivity level, and degree of access anomaly, or they can be policy judgment results that can be directly invoked by the system.

[0105] User permissions are used to characterize the data access level of the current user based on their job title, department, role, or authorization, while the hierarchical response strategy is used to determine how to process subsequent queries.

[0106] One possible implementation is that after receiving the generated query command, the data retrieval system analyzes the query intent, the data sensitivity of the requested data, and the access pattern to obtain the corresponding evaluation results.

[0107] After obtaining the evaluation results, a tiered response strategy is determined based on user permissions, and the subsequent query processing flow is controlled according to the determined tiered response strategy.

[0108] By incorporating the query content itself, the requested data attributes, and user behavior patterns into the control chain, the response method is matched with the current query context, thereby providing a dynamic compliance control basis for subsequent data access.

[0109] S103. Based on the hierarchical response strategy, obtain the corresponding source data from multiple heterogeneous data sources, aggregate the multiple source data, and obtain the query results.

[0110] Multiple heterogeneous data sources are used to provide the data required for the query. Heterogeneity is reflected in aspects such as storage models, interface protocols, field naming conventions, and update frequency. These heterogeneous data sources can include relational databases, non-relational databases, data warehouses, distributed search engines, and data sources corresponding to application programming interfaces (APIs).

[0111] The source data is used as the raw input for generating query results. After obtaining the corresponding source data from multiple heterogeneous data sources, it is processed and aggregated.

[0112] The query results are the final data set formed based on the query command and hierarchical response strategy, which can be represented as a structured table, array object or report dataset.

[0113] One possible implementation involves initiating a data retrieval task based on the query command and a tiered response strategy during data acquisition, retrieving source data corresponding to the current query from multiple heterogeneous data sources. Since the data formats returned by different data sources may differ, each source data can be adapted for subsequent unified aggregation.

[0114] Multi-source aggregation is performed based on the calculation logic in the query command. The aggregation process may include filtering, summarizing, grouping statistics, and sorting. For example, for the query "to summarize the corporate loan balances of branches in East China in the previous quarter and summarize them by industry category", loan balance data, customer industry classification data, and branch affiliation information are extracted from relevant data sources, and aggregation is performed according to the corresponding data dimensions to generate structured query results.

[0115] By connecting query commands, hierarchical response strategies, and multi-data source access and aggregation processes, data scattered across multiple business systems can be processed under a unified standard, thereby generating query results that can be directly output.

[0116] S104. Convert the query results into an editable document and output them according to the preset output format.

[0117] The query results are then converted into editable documents to meet the requirements for circulation, review, and re-editing in financial scenarios. These editable documents contain the query results and allow users to modify them later.

[0118] The preset output format is used to specify the output form of editable documents.

[0119] One possible implementation involves selecting the appropriate document template based on the result type and writing the data from the query results into the corresponding locations according to the template mapping relationship. During the output process, layout adjustments are performed according to a preset output format, such as adjusting column widths, aligning numbers, converting date formats, adding currency symbols, setting percentage formats, and controlling pagination. After the document is generated, it is output to the user's terminal, either as a download link, an online preview link, or a file stream. This ensures that the query results remain editable and formatted consistently during output, facilitating subsequent review and use.

[0120] This embodiment provides a financial data query method. The method acquires a natural language query statement input by the user, performs semantic parsing of the query statement using a financial business language model, and generates a query instruction including data dimensions, time range, and calculation logic. Based on the query instruction, it performs a risk assessment on the query intent, the data sensitivity of the requested data, and the access pattern, obtaining the assessment result. Based on the assessment result and user permissions, it determines a tiered response strategy. According to the tiered response strategy, it acquires corresponding source data from multiple heterogeneous data sources, aggregates the multiple source data, and obtains the query result. The query result is converted into an editable document and output according to a preset output format. By using a financial business language model to perform structured parsing of natural language query statements, using risk assessment results and user permissions to drive tiered responses, and combining heterogeneous data source access and aggregation with editable document output, complex financial query needs can be transformed into a controlled data processing flow.

[0121] Figure 2 A flowchart illustrating a financial data query method provided in this application embodiment. Figure 2 .like Figure 2 As shown, in Figure 1 Based on the examples, the financial data query method is described in detail, including:

[0122] S201. Obtain the natural language query statement input by the user, and perform preliminary semantic mapping on the financial terms in the natural language query statement through an incrementally trained financial terminology database to obtain basic parsing results.

[0123] Among them, the financial terminology database is a pre-built and continuously maintained database that stores professional terms and their standard definitions for various business lines in the financial field, such as terms like "provincial branch", "non-performing loan ratio", and "provision coverage ratio" and their business hierarchy relationships.

[0124] Incremental training refers to the continuous introduction of new financial business terms, regulatory terms, and high-frequency words from historical query logs during the construction and optimization of the financial terminology database. This process continuously expands and updates the coverage and semantic mapping relationships of the terminology database, enabling it to adapt to the development and changes in financial business in a timely manner.

[0125] Semantic mapping refers to the process of comparing and converting financial terms identified in natural language statements with standard terms stored in a terminology database.

[0126] One possible implementation involves obtaining the user's natural language query and performing preprocessing operations such as word segmentation and part-of-speech tagging to identify candidate terms belonging to the financial business domain. Using an incrementally trained financial terminology database as a matching benchmark, the identified candidate financial terms are compared and mapped one by one with the terms stored in the database.

[0127] During the mapping process, not only are the literal expressions of terms matched, but also the hierarchical relationships and synonym relationships defined in the terminology database and the high-frequency mapping records in the historical query log are comprehensively judged. For example, "provincial branch" and "provincial first-level branch" are synonymous terms, and these two different expressions are uniformly mapped to the standardized term definitions in the terminology database.

[0128] After the above matching and mapping process, each financial term identified in the natural language statement is mapped to the corresponding standardized term expression in the terminology database. The identified terms and their mapping results are then output as the basic parsing results for further correction and parsing in subsequent steps.

[0129] If a statement contains an unknown term that is not yet included in the terminology database, the system will mark the unknown term and record its location and context information for subsequent manual review or to trigger an incremental update process of the terminology database.

[0130] Specifically, the user inputs "Please generate a table of ATM transaction amounts for the second quarter of this year based on the provincial branch level." This statement is preprocessed to identify candidate terms such as "provincial branch," "ATM device," and "transaction amount." Matching is then performed using an incrementally trained financial terminology database: the database stores the standard definition of "provincial branch" and its synonym mapping to "provincial-level branch," the standard business system name corresponding to "ATM device," and the standard data dictionary field name and its calculation definition for "transaction amount." The candidate terms are mapped to their corresponding standardized terminology expressions in the database; for example, "provincial branch" is mapped to "provincial-level institution," "ATM device" to "automatic teller machine device," and "transaction amount" to "transaction volume." This generates a basic parsing result containing the above mapping relationships, which is then used for subsequent steps to correct ambiguities and generate structured query instructions.

[0131] By using a pre-trained incremental financial terminology database to perform semantic mapping on financial terms in natural language, users' colloquial and non-standardized natural language expressions can be converted into standardized terminology expressions that the system can recognize. This effectively avoids semantic misunderstandings or parsing failures caused by differences in terminology expression methods, and improves the accuracy of understanding users' query intentions.

[0132] Meanwhile, because the terminology database adopts an incremental training mechanism, it can continuously introduce new business terms and regulatory norms that emerge in the process of financial business development, enabling the system to always have the ability to accurately identify the latest terms in the financial field, thereby enhancing the long-term applicability and ease of maintenance of the system.

[0133] S202. Based on the user's historical query records and / or the current session context, correct any ambiguous financial terms in the basic parsing results.

[0134] Among them, historical query records refer to all or part of the natural language query statements submitted by the current user in the past period of time and their corresponding parsing results. Historical query records reflect the user's query habits, common business dimension preferences, and terminology usage tendencies.

[0135] The current session context refers to the natural language query statement that the user has entered during the current continuous interaction, as well as its corresponding parsing and feedback results. For example, if the user first queries "the non-performing loan ratio of the East China branch" in the current session, and then enters "what about South China?", the word "South China" can be corrected to "South China branch" based on the context of "branch" in the previous sentence.

[0136] One possible implementation involves obtaining the basic parsing results and then identifying financial terms marked as ambiguous or potentially ambiguous. The criteria for determining ambiguity include: the term having multiple semantic definitions in the financial terminology database; the term having shown multiple different subsequent parsing paths in historical query logs; or the term having multiple reasonable business interpretations within the context of the current statement. For ambiguous terms, the user's historical query records are analyzed to statistically determine the user's usage tendencies and preferences for that term in past queries.

[0137] Simultaneously, the context information of the current session is obtained, and the relationship between the term and the preceding statements in the same session is analyzed. Based on the data dimensions, business themes, or target fields explicitly defined in the preceding queries, the semantic selection of the current term is constrained in reverse. For example, if a user previously queried "the non-performing loan ratio of the East China branch" in the same session, and now enters "what about South China?", combining the context of "branch" and "non-performing loan ratio" in the preceding query, "South China" is automatically corrected to "South China branch", and the implicit query intent is directed towards the non-performing loan ratio dimension.

[0138] It should be noted that when there is a conflict between the correction direction of historical query records and the current session context, the correction result of the current session context shall prevail, because the current session context is more in line with the user's real-time intent in this interaction.

[0139] After correction, the corrected terminology semantics are written into the basic parsing results, replacing the original ambiguous term mappings, forming the corrected target parsing results, which are then used for subsequent steps to extract dimensions and time ranges and map computational logic.

[0140] By incorporating users' historical query records and the current session context to accurately correct ambiguous financial terms, the system can effectively resolve parsing biases caused by the same term having different semantics in different business scenarios. This upgrades the system's understanding of user query intent from single-statement analysis to intelligent parsing that combines user preferences and interaction context, thereby improving the accuracy of natural language parsing and user experience.

[0141] S203. Based on the corrected parsing results, extract the data dimensions and time range from the natural language query statement to obtain the target parsing results.

[0142] In this context, data dimensions refer to the business perspective or statistical analysis angle from which users expect to group, classify, or arrange data. Examples include by institutional level (e.g., provincial branch, sub-branch), by business line (e.g., corporate banking, retail banking), and by time period (e.g., monthly, quarterly). The extraction of data dimensions determines the presentation of query results and the hierarchical structure of data aggregation.

[0143] The time range refers to the time interval between the occurrence of the event or the statistical data that the user queries, such as a calendar year quarter (such as the second quarter of this year), a relative time (such as the most recent month), or a specific date range (such as from January 1st to March 31st).

[0144] One possible approach is to obtain the corrected target parsing results and then locate the expressions related to the data dimensions. Data dimensions typically appear in natural language statements as prepositional phrases or noun phrases, such as "by provincial branch dimension," "by business line," and "by institution." Using predefined dimension identification rules, these expressions are mapped to predefined data dimension identifiers within the system. For example, "provincial branch dimension" is mapped to "institution dimension," and its aggregation level is recorded as "provincial-level branch."

[0145] If the data dimension is not explicitly specified in the statement, the default data dimension will be automatically inferred based on the business theme of the query and the types of fields involved. For example, when querying "balance of various deposits", the default is to summarize the statistics of the entire bank.

[0146] The parsing results are used to locate expressions related to time ranges. Time ranges in natural language statements typically appear as time nouns, time adverbs, or time interval phrases, such as "the second quarter of this year," "last month," "from January to March," or "the last thirty days." Using predefined time parsing rules, these natural language time expressions are converted into specific time intervals for unified storage and processing within the system. For example, "the second quarter of this year" is mapped to April 1st to June 30th of the current year, and "the last thirty days" is mapped to the thirty days prior to the current date. If the statement does not explicitly specify a time range, a default time range is determined according to default rules (such as the current calendar year, the current quarter, or the latest available data date).

[0147] The extracted data dimension identifiers and standardized time intervals are written into the corrected parsing results to form a complete target parsing result containing term mapping results, dimension identifiers, and time intervals, which is then used for subsequent steps to perform computational logic mapping and query instruction generation.

[0148] Specifically, the terminology was corrected, and the corrected parsing results now include the mapping information that "provincial branch" has been corrected to "provincial-level institution". The expression "according to the provincial branch dimension" was located in the parsing results and mapped to the system's internal "institutional dimension", with the aggregation level determined as "provincial-level branch" as the extracted data dimension. The time expression "second quarter of this year" was located, and the current year was determined to be 2024. "Second quarter of this year" was converted to the standard time range of "April 1, 2024 to June 30, 2024". The extracted "institutional dimension (provincial-level branch)" and "April 1, 2024 to June 30, 2024" were written into the parsing results, together with the existing terminology mapping results, to form the target parsing result. This target parsing result fully contains the three core types of information involved in the query: terminology definition, data dimension, and time range, providing a complete input foundation for the subsequent calculation logic mapping.

[0149] By selectively extracting data dimensions and time ranges from the corrected parsing results, the implicit or explicit dimensional information and time constraints in the user's natural language expression are made explicit into structured parameters that the system can recognize. This elevates the parsing results from "accurate understanding of terminology semantics" to "complete extraction of query elements," solving the problem that missing dimensions or ambiguous time expressions in natural language queries lead to query results that do not meet user expectations.

[0150] S204. Based on the financial data dictionary, the computational requirements in the natural language query statement are mapped to the corresponding computational logic, and query instructions are generated according to the target parsing results and computational logic.

[0151] The financial data dictionary is a pre-built metadata management library used to store the standard names, business meanings, data types, value ranges, calculation rules, and relationships between fields in financial business data. For example, the data dictionary defines the "transaction amount" field as originating from the "transaction amount" field in the transaction details table, "net interest income" as equal to "interest income" minus "interest expense", and "non-performing loan ratio" as equal to "non-performing loan balance" divided by "total loan amount" and then multiplied by 100%.

[0152] One possible approach is to locate the user's computational needs from the target parsing results. These needs typically appear in natural language statements as verb phrases or noun phrases. For example, "distribution table" indicates a need for grouping and summarizing by dimension, "total amount" indicates a need for summation, and "average" indicates a need for calculating the arithmetic mean. Based on the identified computational need type, the corresponding computational rules are matched in the financial data dictionary. For instance, "distribution table" matches the computational rule of "grouping and summarizing by specified dimension," and "year-on-year growth rate" matches the computational rule of "the difference between the current period's value and the value of the same period last year divided by the value of the same period last year multiplied by 100%."

[0153] After matching the calculation rules, the system further maps the business fields (e.g., "transaction amount") in the natural language statement to their corresponding physical fields and data tables or data sources in the data dictionary, based on the field mapping relationships defined in the data dictionary. For example, "transaction amount" is mapped to the "occurrence amount field in the transaction details table". Simultaneously, based on the field calculation rules defined in the data dictionary, the user's calculation requirements are further refined into specific calculation expressions. For instance, the calculation requirement for the "transaction amount distribution table" is refined into the calculation logic of "grouping by institution dimension and summing the occurrence amount field in the transaction details table".

[0154] The data dimension identifiers, standardized time intervals, and mapping calculation logic in the target parsing results are integrated to generate a complete query command.

[0155] Specifically, the target parsing result generated in step S203 is obtained, which already includes the data dimension "Institution Dimension (Provincial-level Branch)," the time range "April 1, 2024 to June 30, 2024," and the term mapping result "Transaction Amount has been mapped to Transaction Transaction Amount." The calculation requirement statement "Distribution Table" is located from the target parsing result and identified as a "dimension-based grouping and aggregation" calculation type. The physical field corresponding to "Transaction Amount" and its calculation rules are matched in the financial data dictionary. The data dictionary defines "Transaction Amount" as originating from the "Transaction Amount" field in the "Transaction Details Table," and defines the calculation rule for "dimension-based aggregation" as "using the institution identifier as the grouping field and summing the transaction amount field." The above information is integrated to generate a complete query instruction containing the data source identifier "Transaction Details Table," the target field "Transaction Amount," the grouping field "Institution Identifier," the time filter condition "Transaction Dates are between April 1, 2024 and June 30, 2024," and the aggregation method "Sum." This query instruction is output in a structured format to subsequent steps for data acquisition.

[0156] By using a financial data dictionary, vague and colloquial computational needs in users' natural language are accurately mapped into executable, structured computational logic that includes specific field sources and computational rules. This avoids query result deviations caused by inconsistencies between business field names and physical field names, or unclear computational definitions, and ensures consistency of query results at both the business semantics and physical implementation levels.

[0157] By adopting the above implementation method, the process of identifying and disambiguating financial terms can be kept consistent with user habits and the current context. The data dimensions, time range and calculation logic in the query instructions can be clearly expressed synchronously, thereby improving the accuracy of query parsing and the consistency of instruction generation.

[0158] S205. Based on the query command, identify the business scenario and purpose corresponding to the current query, and determine the risk level of the query intent.

[0159] Understandably, a business scenario refers to the specific business context in which a user initiates a query. Different business scenarios correspond to different data access scopes, data uses, and compliance requirements. Common financial business scenarios include regulatory compliance reporting, internal operational analysis, customer information inquiries, risk control monitoring, and audit lead verification. The query purpose further refines the user's specific intent within the current business scenario, such as "generating regulatory reports," "compiling quarterly operational indicators," "querying specific customer account information," and "monitoring trends in non-performing loans."

[0160] The risk level of a query intent is a qualitative risk assessment result assigned to the current query by the system based on a comprehensive judgment of the business scenario and the purpose of the query. It is used to guide subsequent data sensitivity assessment and access pattern analysis. The risk level usually includes multiple levels such as high risk, medium risk, and low risk.

[0161] One possible approach is to extract key information from the query command as a basis for identifying the business scenario. This key information includes the type of the target data source indicated by the query command, the business attributes of the requested data fields, the business level corresponding to the data dimension, and the characteristics of the time range. For example, if the query command points to a customer information table and the requested fields include sensitive personal information such as customer name, ID number, and contact number, the system determines that the current query scenario is a "customer information query" scenario. If the query command points to a transaction details table and the requested fields are summary statistical fields such as transaction amount and number of transactions, the system determines that the current query scenario is a "business analysis" scenario.

[0162] After determining the business scenario, further analysis of the data dimensions, aggregation methods, and calculation logic in the query command is used to identify the user's specific query purpose within the current business scenario. For example, in the "customer information query" scenario, if the query command includes statistical operations summarizing by organization, the query purpose is determined to be "customer information statistics"; if the query command includes precise filtering conditions for specific customer identifiers, the query purpose is determined to be "specific customer information retrieval." In the "business analysis" scenario, if the query command includes year-on-year or month-on-month analysis over a time dimension, the query purpose is determined to be "trend analysis"; if the query command only includes simple summary statistical operations, the query purpose is determined to be "routine business indicator statistics."

[0163] Based on the identified business scenario and query purpose, and in conjunction with a predefined business scenario risk mapping table, the risk level of the current query intent is determined. This mapping table pre-stores risk classification rules for different business scenarios and their corresponding query purposes. For example, in the "customer information query" scenario, the purpose of "specific customer information retrieval" is defined as a high-risk level; in the "business analysis" scenario, "routine business indicator statistics" is defined as a low-risk level; and in the "risk control monitoring" scenario, it is defined as a medium-risk level.

[0164] If the combination of business scenario and query purpose involved in the query command does not have a clear correspondence in the mapping table, it will be set to medium risk level by default according to the preset security policy, and further corrected through sensitive field assessment and access pattern analysis in subsequent steps.

[0165] Specifically, by analyzing the data source identifier "Transaction Details" and fields such as "Transaction Amount" and "Institution Identifier" in the query command, it was determined that the target of the query was transaction summary data, which did not involve sensitive personal information fields such as customer names or ID card numbers. Therefore, the current query scenario was identified as an "internal business analysis" scenario. Further analysis of the calculation logic in the query command revealed it to be "summarizing transaction amounts by institution dimension," without involving complex operations such as year-on-year, month-on-month, or regression analysis. This indicated the query purpose was "routine business indicator statistics." Combining the "internal business analysis" scenario with the "routine business indicator statistics" purpose and matching it with a predefined business scenario risk mapping table, this combination was defined as low-risk by the mapping table. Therefore, the risk level of the current query intent was determined to be "low risk."

[0166] By automatically identifying business scenarios and query purposes based on query commands and determining the risk level of query intent, the starting point for risk assessment is shifted from post-event manual review to the initial stage of query execution. This allows for preliminary risk prediction of query intent before data acquisition. By matching business scenarios and query purposes with predefined risk mapping rules, differentiated risk control strategies can be implemented for different types of queries, avoiding a one-size-fits-all approach of applying the same level of review intensity to all queries. This ensures data security in high-risk scenarios while also maintaining response efficiency for low-risk routine queries.

[0167] S206. Based on the data fields requested by the query command, match the preset sensitive field library to determine the sensitive fields and sensitivity levels included in the requested data.

[0168] The pre-built sensitive field library is a pre-constructed database of field-level data protection rules used to define the sensitive attributes of each business field in financial data and their corresponding protection levels. The field attribute information stored in the sensitive field library includes, but is not limited to: the business system to which the field belongs, the data type of the field, whether the field belongs to personal financial information, whether it constitutes a trade secret, and whether it is subject to data security regulations of regulatory agencies. Sensitivity levels are data protection priorities assigned to fields based on their sensitive attributes. These levels guide the intensity of de-identification processing or the granularity of access control in subsequent tiered response strategies. Sensitivity levels typically include multiple levels such as high sensitivity, medium sensitivity, and low sensitivity.

[0169] One possible implementation involves parsing the target field list within the generated query command. This target field list records all data fields requested by the current query. Each field in the target field list is then compared and matched against a pre-defined sensitive field database to determine if it belongs to a sensitive field as defined in the database. If a field has a corresponding record in the database, it is marked as a sensitive field, and the pre-stored sensitivity level in the database is retrieved. If a field does not have a corresponding record in the database, it is marked as a non-sensitive field.

[0170] During the matching process, not only are the physical names of fields matched, but also fuzzy matching is performed based on the business aliases and synonym mappings of the fields in the data dictionary to avoid missed matches due to differences in field naming. For example, if a sensitive field defined in the sensitive field library is "customer ID card number," and the field requested by the query command is named "ID card number," then "ID card number" is matched to "customer ID card number" through the synonym mappings stored in the data dictionary, thus correctly identifying the sensitive attribute of the field. After matching all requested fields, the matching results are summarized, and the highest sensitivity level of the overall data requested in this query is determined according to the principle of taking the highest sensitivity level. The field names of the matched sensitive fields and their corresponding sensitivity levels are then output as the results.

[0171] Specifically, the query command was parsed to include the "Transaction Amount" and "Institution Identifier" fields from the "Transaction Details Table," but did not contain any fields involving customer personal information or account information. The "Transaction Amount" and "Institution Identifier" were compared one by one with a pre-defined sensitive field database. The sensitive field database pre-determined "Customer Name," "ID Card Number," "Mobile Number," "Bank Account Number," and "Transaction Password" as highly sensitive fields, while "Institution Name" and "Institution Identifier" were non-sensitive fields. "Transaction Amount" was marked as low-sensitive or non-sensitive according to different business scenarios. Since "Transaction Amount" is a summary statistical field and does not carry any customer-level detailed information, it was defined as a low-sensitive field in the sensitive field database, and "Institution Identifier" was defined as a non-sensitive field. Therefore, the matching result of this query was: a match was found for the low-sensitive field "Transaction Amount," and the overall sensitivity level was determined to be low-sensitive.

[0172] By automatically matching the requested fields in the query command with the preset sensitive field library, it is possible to accurately identify whether the requested data contains sensitive fields and their sensitivity level before the query is executed. This provides a data-level basis for the formulation of subsequent hierarchical response strategies, avoiding the mistaken release or over-sensitization of sensitive data due to human oversight or differences in the understanding of field aliases.

[0173] S207. Obtain the user's historical access records, and based on the preset abnormal behavior judgment rules, perform abnormal detection on the user's access frequency, access time period and access scope to determine the risk level of the access mode.

[0174] The access time period refers to the time point or time period when a user submits a query request, such as working hours, non-working hours, or late-night hours.

[0175] Access scope refers to the breadth of data coverage requested in a single query, including the number of data tables involved, the sensitivity of the requested fields, and the number of data records returned.

[0176] The preset abnormal behavior judgment rules are a set of pre-configured judgment logic used to identify whether user access behavior deviates from the normal pattern.

[0177] The risk level of access patterns is a qualitative assessment of the data leakage risk of the current access behavior based on the degree of deviation between the user's real-time access behavior and historical behavior patterns. The risk level usually includes multiple levels such as high risk, medium risk, and low risk.

[0178] One possible implementation involves obtaining the current user's identity identifier and retrieving all historical access records of that user from the audit logs over a past period (e.g., the past thirty calendar days). Statistical analysis is then performed on these historical access records to extract the user's behavioral baseline across three dimensions: access frequency, access time period, and access scope. Regarding access frequency, the average daily number of queries and the fluctuation range of daily queries over the past period are statistically analyzed as a baseline to determine whether the current query is an anomaly due to high frequency. Regarding access time period, the time distribution pattern of the user's historical queries is analyzed, such as whether they are mainly concentrated during normal working hours on weekdays, as a baseline to determine whether the current query is an anomaly due to abnormal time periods. Regarding access scope, the distribution of data table types involved in the user's historical queries, the distribution of field sensitivity, and the average number of records returned are statistically analyzed as a baseline to determine whether the current query is an anomaly due to data range anomalies.

[0179] After completing baseline statistics, anomaly detection is performed on the current query based on preset abnormal behavior judgment rules. In the access frequency dimension, the current user's real-time query frequency is compared with the user's historical average query frequency. For example, it's checked whether the current user's query count in the past hour is significantly higher than a certain multiple of the user's historical daily average query count. In the access time dimension, it's determined whether the current query's submission time falls within the user's historical active access time range. For example, if the user typically only submits queries during normal working hours, but the current query was submitted in the early morning. In the access scope dimension, it's determined whether the data table type, field sensitivity, or number of returned records requested by the current query significantly deviates from the user's historical access scope. For example, if the user typically only accesses summary statistics, but the current query requests detailed customer data.

[0180] The anomaly detection results from the three dimensions mentioned above are quantified into anomaly scores, and then comprehensively calculated according to preset weighting rules to obtain a risk assessment score for the access pattern. In the preset weighting rules, anomalies in access frequency, access time, and access scope each correspond to different weight coefficients. For example, the risk weight for anomalies in access scope is higher than that for anomalies in access frequency, because anomalies in access scope usually indicate a higher risk of data leakage. The risk level of this access pattern is determined based on the score range in which the final calculated risk assessment score falls.

[0181] By establishing personalized behavioral baselines through accessing users' historical browsing records and performing anomaly detection across three dimensions—access frequency, access time, and access scope—this approach can identify abnormal user behavior that deviates from their usual patterns. This effectively prevents data breaches caused by account theft, malicious queries by internal personnel, or automated attacks. Compared to solutions that apply uniform thresholds to all users for anomaly detection, personalized judgment based on individual user historical behavioral baselines avoids misjudging users with different query habits due to a one-size-fits-all static threshold. This reduces the probability of legitimate queries being falsely blocked and improves the accuracy of anomaly detection.

[0182] S208. Perform compliance verification on user permissions, query intent, sensitive fields, and historical access records to obtain the permission verification result.

[0183] User permissions refer to a set of data access licenses pre-configured based on a user's job role, business line, and data access authorization scope. Different user permission levels determine the range of data they can access, the types of data operations they can perform, and the precision of the data they can obtain in the system.

[0184] The permission verification result is the final determination of whether the current query is allowed to continue execution after comprehensively assessing the risks of query intent, data sensitivity, user behavior risks, and user static permissions.

[0185] Compliance verification is the intersection of multi-dimensional information in the entire assessment process. It comprehensively compares the risk level of query intent, data sensitivity level, access mode risk level, and user's inherent permission level assessed in the previous steps to confirm whether there are any conflicts or overreaches between the dimensions, thereby arriving at the final conclusion as to whether the current query is compliant.

[0186] One possible implementation involves retrieving the user's granted data access permissions from the access control module based on the user's role. This includes the list of data tables and fields the user can access, the types of data operations allowed, and the level of precision of data that can be retrieved. For example, a user working as a statistical analyst at a branch might have permissions limited to accessing only the branch's summary statistics, without access to detailed data or the ability to query data across branches.

[0187] The system compares the user's permission level with the determined query intent risk level to determine if the current query intent matches the user's permissions. If the user's permission is for a branch statistics position, but the query intent is identified as "generation of bank-wide regulatory reports," then there is a mismatch between intent and permissions. The system then compares the user's permission level with the determined data sensitivity level to determine if the user has permission to access the requested sensitive fields.

[0188] If a user's permissions explicitly state that they are not authorized to access fields containing customer personal information, but the current query requests data fields containing the customer's ID number, a conflict arises between permissions and sensitive fields. Simultaneously, cross-validation is performed between the user's permission level and the determined access pattern risk level to determine whether the abnormal signals under the current access pattern exceed the acceptable range of the user's permissions. For example, even if a user has high-level permissions, but their access pattern shows frequent abnormal access outside of working hours, combining these two factors will improve the overall compliance verification score.

[0189] The results of the multi-dimensional comparisons are summarized, and the final permission verification result is generated according to preset rules. The permission verification result is in the form of a judgment result of passing or failing the verification. When sensitive fields are involved, the corresponding data output method indication also needs to be output (such as allowing viewing of plaintext, allowing viewing of only de-identified results, completely denying access, etc.), so that the subsequent hierarchical response strategy steps can determine the specific data output method based on the indication.

[0190] If the query intent, sensitive fields, and access mode do not conflict with the user's permissions, the permission verification result of "verification passed" will be output. If any dimension is mismatched or conflicted, the permission verification result of different levels such as "verification failed, it is recommended to de-identify" or "verification failed, it is recommended to deny access" will be generated according to the severity of the mismatch.

[0191] By cross-validating user static permissions with query intent risk, data sensitivity, and access behavior risk from multiple dimensions, access control is upgraded from traditional single-dimensional static judgment to dynamic comprehensive judgment that combines query context and user behavior characteristics. Compared with traditional solutions that rely solely on preset role permissions for data access control, the comprehensive judgment by introducing multi-dimensional information such as query intent, data sensitivity, and access patterns can effectively identify hidden unauthorized behaviors where users are within the scope of static permissions but have abnormal query intent. This compensates for the lack of dynamic risk perception in static access control and improves the granularity and effectiveness of compliance control.

[0192] S209. Based on the risk level of the query intent, the sensitivity level, the risk level of the access mode, and the permission verification results, determine the assessment result according to the preset risk rules.

[0193] One possible implementation involves obtaining the query intent risk level determined in step S205, the data sensitivity level determined in step S206, the access pattern risk level determined in step S207, and the permission verification result determined in step S208, and using the output of the four dimensions as input parameters for preset risk rules.

[0194] A comprehensive evaluation is conducted according to the judgment logic of the preset risk rules. The preset risk rules define multiple risk level judgment conditions. The input parameters of the four dimensions are compared with each judgment condition one by one to determine the final evaluation result. For example, the preset risk rules stipulate that if any dimension is judged as high-risk and the permission verification result is failed, the comprehensive evaluation result is directly determined to be high-risk; if the permission verification result is "recommend denial," the evaluation result is directly determined to be high-risk regardless of other dimensions; if the query intent risk level, data sensitivity level, and access pattern risk level are all low-risk and the permission verification result is passed, the comprehensive evaluation result is determined to be low-risk; if multiple dimensions are medium-risk and the permission verification result is "recommend desensitization," the comprehensive evaluation result is determined to be medium-risk; if a single dimension is medium-risk while other dimensions are low-risk and the permission verification result is passed, the comprehensive evaluation result is determined to be low-risk or medium-risk, determined according to the weights of each dimension defined in the preset risk rules.

[0195] When the permission verification result includes an execution instruction such as "recommend de-identification" or "recommend rejection," this instruction will be used as a weighting factor or a veto item in the pre-defined risk rule judgment logic for comprehensive evaluation. The execution instruction in the permission verification result takes precedence over individual risk levels in the judgment to ensure the strictness of compliance control. For example, when the permission verification result is "recommend rejection," even if the risk levels of the other three dimensions are all low risk, the evaluation result will still be determined as high risk to ensure that queries with permission conflicts are promptly blocked.

[0196] After completing the comprehensive judgment according to the above judgment logic, the final evaluation result is output. The evaluation result includes the comprehensive risk level and the corresponding execution tendency (such as allow, de-identify or reject), which can be directly called when determining the graded response strategy.

[0197] The query command provides the structured context required for risk analysis. Identification of business scenarios and purposes is used to define the boundaries of the query's use. Sensitive field matching is used to identify whether the request involves sensitive data. Historical access record analysis is used to discover abnormal access patterns. Permission verification is used to confirm the compliance of the current user's access. Preset risk rules then summarize all the results into a single assessment conclusion and output it to the subsequent response module for invocation.

[0198] By adopting the above implementation method, query semantics, data sensitivity, access behavior and permission status can be jointly evaluated, so that the evaluation results can more accurately reflect the overall risk status of the current query and provide a unified basis for subsequent graded response, thereby improving the compliance control capability and risk identification consistency in financial data query scenarios.

[0199] S210. Determine the risk level of the current query based on the assessment results, and determine the permission level based on user permissions.

[0200] One possible implementation involves reading the comprehensive risk qualitative conclusion and its corresponding execution tendency from the assessment results, such as "low risk, access allowed," "medium risk, output after anonymization," or "high risk, access denied." Following a preset risk level mapping rule, the comprehensive risk qualitative conclusion in the assessment results is converted into the standard risk level adopted by the tiered response strategy module. If the assessment results explicitly indicate a risk level, that risk level is directly extracted as the risk level for the current query. If the assessment results only contain qualitative descriptions or scores, they are converted into the corresponding standard risk levels according to a preset mapping table; for example, "Comprehensive assessment result is low risk, access allowed" is directly mapped to "low risk level," and "Comprehensive assessment result is medium risk, output after anonymization" is mapped to "medium risk level."

[0201] Obtain the current user's permission information and extract the user's permission level from the retrieved user permission records. Based on the user's permission scope description in step S208, the user permission level is quantified into the standard permission level adopted by the hierarchical response strategy according to a preset permission level division rule. For example, the user permission scope is divided into multiple permission levels, where ordinary query users have permission level one, only able to access publicly available aggregated statistical data; business analysts have permission level two, able to access anonymized restricted data within their permission scope; and department heads or compliance personnel have permission level three, able to access raw data within their permission scope.

[0202] After determining the risk level and permission level, both are output as input parameters for step S211. The risk level represents the degree of risk of the current query itself, and the permission level represents the data access capabilities of the user initiating the query. Together, they constitute the two core dimensions for determining the response level.

[0203] By converting the assessment results and user permissions into standard risk levels and standard permission levels used in the tiered response strategy, the complex and multi-dimensional assessment results are quantified into two standardized parameters that can be matched within the same framework. This provides a unified input basis for subsequent response level matching and reduces the complexity of subsequent matching logic.

[0204] S211. Match the risk level with the permission level to determine the response level corresponding to the current query.

[0205] S212. Based on the response level, match the corresponding response action and data output method from the preset hierarchical response strategy table.

[0206] The hierarchical response strategy table defines the mapping relationship between different response levels, response actions, and data output methods. Response actions include at least one or more combinations of allowing access, data anonymization, and denying access.

[0207] The response level is a comprehensive response priority determined based on the matching result of the current query's risk level and the user's permission level.

[0208] The hierarchical response strategy table is a pre-configured strategy mapping table used to store the correspondence between different response levels and specific response actions and data output methods.

[0209] Response action refers to the type of operation the system performs on the current query request based on the response level, including one or more combinations of allowing access, data anonymization, and denying access. Data output method refers to the specific form of data returned to the user when access is allowed or after data anonymization.

[0210] One possible implementation uses risk level and permission level as two input dimensions for the matching logic. For example, matching is performed according to a predefined risk-permission matching rule table, which predefines the response levels corresponding to different combinations of risk levels and permission levels. The core principle of the matching rules is: the higher the risk level, the higher the response level; under the same risk level, the lower the permission level, the higher the response level. During the matching process, the combination of risk level and permission level is located to the corresponding response level entry in the matching rule table. If there is no exact match in the matching rule table, the response level is determined according to the security principle of "choosing the highest," that is, selecting the highest among all possible candidate response levels to ensure that there are no security vulnerabilities caused by missing matches.

[0211] Once the response level is determined, it is used as an index to search and match within a pre-defined tiered response policy table. The tiered response policy table pre-configures corresponding response actions and data output methods for each response level. For example, a lower response level corresponds to "allow access and output source data," a medium response level corresponds to "data anonymization and output anonymized data," and a higher response level corresponds to "deny access and output a reason for denial." The mapping relationship between response levels, response actions, and data output methods in the policy table follows a progressive principle from low to high: at lower response levels, the system tends to provide more lenient access permissions and more complete data output; at higher response levels, the system tends to impose stricter control measures.

[0212] After matching the response level against the policy table, the corresponding response action and data output method are read. If no exact entry corresponds to the response level in the hierarchical response policy table, the policy with the next higher response level in the policy table is selected as the default policy according to the principle of security priority. The matched response action (allow access, data anonymization, or deny access) and data output method are output as execution instructions to subsequent data acquisition and aggregation steps.

[0213] Specifically, upon receiving the assessment results, the risk level is first determined based on the corresponding risk threshold range in the assessment results. Then, the permission level is looked up based on the user's permission information, and the two are input into a preset matching rule to complete the combination mapping. This matching rule can be implemented using a lookup table or a level matrix approach, where different combinations of risk levels and permission levels correspond to different response levels.

[0214] When the response level is low and the permission level meets the allow conditions, the tiered response strategy table returns a data output method that allows access and outputs data as is. When the response level is in the middle range and the request contains sensitive fields, the tiered response strategy table returns a data output method that includes data anonymization and the anonymized data. When the response level exceeds the preset limit or the permission level is insufficient, the tiered response strategy table returns a data output method that denies access and does not output the target data. Based on this, a final response result is generated, and this result is used to control subsequent data acquisition, aggregation, and return formats.

[0215] By adopting the above-mentioned hierarchical response strategy, risk assessment, access control, and output control can be unified into the same mapping mechanism, thereby enabling query requests under different security states to receive corresponding processing strengths and ensuring that the output results are consistent with access control.

[0216] S213. Based on the hierarchical response strategy, obtain the corresponding source data from multiple heterogeneous data sources, aggregate the multiple source data, and obtain the query results.

[0217] Step S213 is similar to step S103 above, and will not be repeated here.

[0218] S214. Convert the query results into an editable document and output them according to the preset output format.

[0219] Step S214 is similar to step S104 above, and will not be repeated here.

[0220] This embodiment provides a financial data query method. This method utilizes an incrementally trained financial terminology database to perform terminology mapping and ambiguity correction on natural language queries. Combined with a data dictionary, it generates structured query instructions containing data dimensions, time ranges, and computational logic to accurately analyze complex query needs in the financial field. Furthermore, it assesses the risk levels of query intent, data sensitivity, and access patterns from multiple dimensions and cross-validates them with user permissions. Based on the validation results, a tiered response strategy is determined. Then, according to the tiered response strategy, source data is obtained from heterogeneous data sources and aggregated into query results. Finally, the results are converted into an editable document while retaining the correlation and traceability information between each data item and the source data before output. This achieves fully automated processing of the entire financial data query process—including pre-screening, dynamic tiering, and data traceability—enhancing the accuracy, flexibility, and verifiability of financial data queries while ensuring data security and compliance.

[0221] Figure 3 A flowchart illustrating a financial data query method provided in this application embodiment. Figure 3 .like Figure 3 As shown, in Figure 1 Based on the examples, a possible implementation method for obtaining corresponding source data from multiple heterogeneous data sources according to a hierarchical response strategy, and aggregating the multiple source data to obtain query results is described in detail, including:

[0222] S301. When the hierarchical response strategy is set to allow access, determine the target data source identifier and the required data fields for the current query based on the query instruction.

[0223] The target data source identifier is a unique identification mark assigned by the system to each accessed data source, used to accurately locate one or more data sources that need to be accessed in this query among multiple heterogeneous data sources.

[0224] Data fields refer to the specific data columns or data attributes requested by the user in the query, such as "transaction amount", "customer name", "account balance", etc. Data fields exist in the form of business semantics in the query command, and their corresponding physical storage fields need to be specified before data acquisition.

[0225] One possible implementation is to determine whether the response action is "Allow access" after obtaining it. If the response action is "Allow access", the data acquisition process begins; if the response action is "Deny access" or "Data anonymization processing but requires further judgment", the corresponding processing is performed according to the corresponding strategy.

[0226] After confirming that the tiered response policy allows access, the query instruction is obtained. The data source mapping portion of the query instruction is parsed to extract all target data source identifiers involved in this query. Since financial data is usually distributed across multiple heterogeneous systems (e.g., transaction data is stored in a transaction database, and institutional information is stored in an institutional management system), a single query instruction may point to multiple different data sources. One or more data source identifiers recorded in the query instruction are extracted one by one to form a list of data sources to be accessed.

[0227] Parse the data field mapping portion of the query command to extract the list of data fields required for this query. This field list exists in the query command as standardized physical fields processed in steps S201 to S204, such as physical field names like "Transaction Amount," "Institution Identifier," and "Transaction Date," rather than business terms like "Transaction Amount" or "Branch" from the user's original input. Associate the extracted data field list with the target data source identifier to clarify the data source to which each data field belongs, providing a basis for accurately selecting the corresponding field when retrieving data from different data sources later. If a data field in the query command cannot be associated with any of the extracted target data sources, it is marked as an anomaly and an error log is recorded.

[0228] By parsing the target data source identifier and data fields in the query command, the structured query command is further refined into specific parameters that can be directly executed in subsequent data acquisition operations. This enables seamless integration between the output of the preceding semantic parsing stage and the subsequent data acquisition stage, avoiding query failures caused by incorrect data source location or field selection during the data acquisition stage. By pre-establishing the association between data fields and data sources, the accurate source of each field can be clearly identified when acquiring data from multiple heterogeneous data sources, effectively reducing the risk of field confusion or source errors during cross-source data integration.

[0229] S302. Identify the interface type of the target data access interface.

[0230] The target data access interface refers to a specific access channel or driver used to connect to and access a heterogeneous data source. Different data sources require different types of access interfaces for connection and data exchange due to differences in their underlying architecture, data model, and communication protocols.

[0231] Interface type refers to the category to which a data access interface belongs, primarily categorized based on the data source's storage model and access protocol. Types include relational database interfaces, non-relational database interfaces, and application programming interfaces (APIs). A relational database interface is an access channel that supports the Structured Query Language (SCL) standard and is used to access data storage systems that follow a relational model (such as database systems that organize data in tabular form and support SCL). A non-relational database interface is an access channel used to access non-relational data storage systems (such as database systems that organize data using document, key-value pair, or graph structures). An application programming interface (API) is an access channel that uses network communication protocols such as Hypertext Transfer Protocol (HTTP) to access standardized data service interfaces provided by the data server.

[0232] One possible implementation involves pre-maintaining a mapping table between data source identifiers and interface types within the system. This mapping table is configured and recorded when each data source connects to the system, recording the access protocol types, driver library information, and connection parameters supported by each data source. For each target data source identifier in the list, its corresponding data access interface type is identified. That is, using the target data source identifier as a query index, the system searches this mapping table to obtain the pre-configured interface type information for that data source.

[0233] If a target data source does not have a corresponding interface type record in the mapping table, it will be automatically identified based on the protocol characteristics or driver library information in the connection parameters of the data source. For example, it may determine whether it is a relational or non-relational database based on the protocol prefix in the database connection string, or determine whether it is an application programming interface type based on the service description information. If automatic identification also fails to determine the interface type, the data source will be marked as an unknown type and an error log will be recorded. At the same time, a notification of data source configuration error will be sent to the management terminal.

[0234] After identifying the interface types for multiple target data sources, the identifiers of each data source are associated with their corresponding interface types to form a list of interface types. This list is then used in subsequent steps to call the corresponding access methods to obtain the raw data according to different types.

[0235] S303. When the interface type is a relational database interface, construct a structured query statement and execute the statement through the relational database interface to obtain the original data.

[0236] Understandably, when the interface type of a target data source is a relational database interface, the parameters of the corresponding structured query command for that data source are obtained, including the target data table name, the names of the fields to be queried, data filtering conditions, and data grouping methods. Following the syntax of the Structured Query Language (SCL), these parameters are organized into a complete query statement. During the statement construction process, data filtering conditions are set in the query statement based on the time range parameter in the query command; data grouping methods are set based on the data dimension parameters; and aggregation calculation methods are set based on the calculation logic parameters. After the query statement is completed, it is sent to the database for execution through the relational database interface corresponding to the data source, and the raw data result set returned by the database is received.

[0237] After retrieving raw data from the relational database, the data types and formats of each field in the raw data are uniformly converted to the standard format used by the system's internal processing according to preset format standardization rules. This includes, but is not limited to, uniform format conversion of date fields, uniform precision of numeric fields, and standardized handling of null values. For cases involving multi-table joins, the join query function of the relational database interface is used to complete cross-table data joins and extractions in a single database access, avoiding the performance overhead caused by multiple database accesses.

[0238] If an exception occurs during the execution of a query statement, such as a database connection failure, a query statement syntax error, or a database response timeout, the exception information is recorded and a retry mechanism is triggered. The query is re-executed according to the preset number of retries and the interval time. If the retry still fails, a data source exception alarm is sent to the management terminal.

[0239] S304. When the interface type is a non-relational database interface, construct the corresponding non-relational data query statement and execute the non-relational data query statement through the non-relational database interface to obtain the original data.

[0240] Understandably, when the interface type of a target data source is a non-relational database interface, it is necessary to determine the specific type of that non-relational database. Different types of non-relational databases have different data models and access methods, therefore, corresponding query syntaxes need to be used for data extraction.

[0241] Depending on the specific type of the NoSQL database, select the appropriate query statement construction method. For example, with a document-oriented database, construct the query statement according to the database's query syntax specifications, based on parameters such as field names, data filtering conditions, and data grouping methods in the query command. The time range parameter is converted into data filtering conditions, and the data dimension parameter is converted into the basis for data grouping or sorting. With a key-value database, construct the corresponding key query operation based on the primary key or key range in the query command. With a graph database, construct the corresponding path query statement based on the node and edge association conditions in the query command. After completing the query statement construction, send the query statement to the database for execution through the corresponding NoSQL database interface and receive the raw data result set returned by the database.

[0242] After retrieving raw data from a NoSQL database, the data types and formats of each field in the raw data are uniformly converted to the standard format used by the system's internal processing according to preset format standardization rules. This includes, but is not limited to, flattening nested fields in the document structure, uniformly converting date fields to a standard format, and unifying the precision of numeric fields. For different data structures returned by different types of NoSQL databases, corresponding parsing and conversion logic is used to uniformly convert them into a standard data format that can be processed uniformly in subsequent steps.

[0243] If a database connection failure, query syntax error, database response timeout, or abnormal data format occurs during the execution of a query statement, the exception information is recorded and a retry mechanism is triggered. The query is re-executed according to the preset number of retries and intervals. If the retry still fails, a data source exception alarm is sent to the management terminal.

[0244] S305. When the interface type is an application programming interface, construct a hypertext transfer request and send the request through the application programming interface to obtain the raw data.

[0245] Understandably, when the interface type of a target data source is an Application Programming Interface (API), the system retrieves the corresponding API access information from the system configuration based on the target data source identifier. This information includes the API request path, request method, authentication method, and request parameter format specifications. Based on the query command, the data dimension parameters, time range parameters, and data field parameters in the query command are converted into the respective parameter items in the request message according to the parameter format and naming conventions required by the API.

[0246] Based on the authentication method required by the Application Programming Interface (API), add the corresponding authentication information to the request. For example, for APIs using application key authentication, encode the application identifier and application key according to the API requirements and add them to the request; for APIs using token authentication, add an access token field to the request. After completing the request message construction, send the request to the server address corresponding to the API via the network communication component and wait for the server to return a response. Upon successful server response, parse the data content returned by the server from the response message.

[0247] After obtaining the raw data from the application programming interface (API), the data content parsed from the response message is converted into a standard format used by the system's internal processing according to preset format standardization rules. If the response message returned by the server contains pagination information (i.e., the data is returned in multiple pages, each containing a portion of the data), requests for subsequent pages are automatically constructed based on the pagination information, and all data is retrieved page by page until all data has been retrieved.

[0248] If an abnormal situation occurs during the request execution process, such as network connection failure, server return of error status code, or response timeout, the abnormal information is recorded and a retry mechanism is triggered. The request is resent according to the preset number of retries and interval. If the retry still fails, a data source abnormality alarm is sent to the management terminal.

[0249] S306. Perform correlation and aggregation on multiple standard data sets to obtain the query results.

[0250] Understandably, this involves obtaining multiple standard datasets from various heterogeneous data sources, standardizing their format, and then using the computational logic and data dimension definitions in the query instructions. Specifically, based on the data dimensions defined in the query instructions, the association keys between the multiple standard datasets are determined. Association keys are fields used to match related records in different datasets. For example, the institution identifier in transaction data and the institution identifier in institution information have the same business meaning and can serve as the association key between the two datasets.

[0251] After determining the association key, perform association operations on multiple standard datasets according to the data dimensions defined in the query command. The goal of the association operation is to merge data records belonging to the same business dimension from different data sources into a single complete record. For example, match the institution identifier in the transaction summary data with the institution identifier in the institution information data, and merge the successfully matched transaction summary records with the corresponding institution name information, so that each transaction summary record includes the complete institution name.

[0252] The aggregated data is processed according to the calculation logic defined in the query command. This involves grouping the data according to the data dimensions defined in the query command and applying statistical operations such as summation, counting, and averaging to each data item within each group. For example, when the query command requests a summary of transaction amounts by institution, the aggregated data is grouped by institution identifier, and the transaction amount field within each group is summed to obtain the summary value of transaction amounts for each institution. After the aggregation calculation is completed, the aggregation results are arranged according to the output field order and organization method defined in the query command to form the final query result dataset, which is then used for document conversion and output in subsequent steps.

[0253] When the target data source identifier points to a financial transaction database, it is identified as a relational database interface and a structured query statement is generated; when the target data source identifier points to log storage or cache storage, the corresponding query expression is constructed according to the non-relational database interface; when the target data source identifier points to an external credit reporting service or a third-party data service, the request is constructed according to the application programming interface to complete the access.

[0254] By pre-identifying the interface types of each target data source, and adopting corresponding data acquisition methods for relational database interfaces, non-relational database interfaces, and application programming interfaces, unified access and differentiated adaptation to various heterogeneous data sources in the financial industry have been achieved.

[0255] Relational database interfaces, by constructing and executing structured queries, can efficiently retrieve data using the database's own query optimizer and indexing mechanisms, making them suitable for highly structured data organized in tabular form. Non-relational database interfaces, by constructing corresponding queries for specific database types such as document-oriented, key-value, or graph databases, can flexibly adapt to the access needs of semi-structured or unstructured data storage. Application programming interfaces (APIs), by constructing hypertext transfer requests and sending them to the server, can access various external data systems that provide data capabilities as network services. These three acquisition methods cover the mainstream data storage and service models in the financial industry, enabling the system to simultaneously access multiple data sources such as transaction databases, customer information management systems, and external data services.

[0256] S307. Based on the query results, generate an editable document containing traceability information about the relationship between each data item and its corresponding source data.

[0257] S308. Output an editable document according to the preset output format.

[0258] Editable documents refer to electronic files that users can directly modify, adjust the format, or add annotations to in document reading software.

[0259] Linkage and traceability information refers to a collection of information recording the source of each data item in the query results, including which data source the data item originated from, the name of the original data table or collection corresponding to the data item, the calculation logic on which the data item was based, and the timestamp when the data item was generated. This information allows users to trace the original source of any data item when browsing documents.

[0260] The preset output format refers to the document format type specified by the user when initiating a query or the system default configuration.

[0261] One possible implementation involves obtaining the query result dataset, retrieving the user-specified output format information from the query command, and if the user does not specify an output format, then outputting according to the system's preset default document format (e.g., a table document format). Based on the determined document format, a blank document object of the corresponding format is created, such as a table document object or a text document object, as the base carrier for subsequent data population.

[0262] Write the data from the query results dataset into a document according to the document format organization rules. For tabular document format, create a table structure in the document, write the field names from the query results into the table header row, write each data record into the data row in sequence, and set the corresponding cell format according to the data type of the field, including the numeric format for numeric fields, the date format for date fields, and the alignment of text fields, etc.

[0263] Generate corresponding association and traceability information for each data item. Specifically, identify the data source identifier when obtaining the original data to determine the source data source name of the current data item; determine the original data table, collection, or interface service name corresponding to the current data item based on the query statement or request parameters; determine the calculation rule description based on the calculation logic; and record the timestamp of the current document's generation. After summarizing the above information, bind it to the corresponding data item.

[0264] Embed traceability information into the document. Specifically, create a separate traceability information lookup table outside the main table, labeling the source of each data row or cell; or store traceability information within cells as comments or notes; or store the complete mapping relationship between data items and traceability information in a structured format within the document's metadata area. Regardless of the embedding method, ensure that users can access the associated traceability information for any data item through the document viewing function, and that the binding relationship between traceability information and data items remains valid throughout the document's editing and saving process. After document generation, output the document in a defined format for users to download or view online.

[0265] Through the above processing, the query results not only retain editable attributes when output, but also simultaneously preserve the source chain of each data item, enabling the document to be traced back to the original data during review, revision, and auditing. Because the output process follows a preset format, the document's layout, field order, and display style match the requirements of financial statements or business record keeping, thus ensuring better flow and consistency of the query results.

[0266] This embodiment provides a financial data query method. When the hierarchical response policy allows access, the method determines the target data source identifier and required data fields based on the query instruction. It then identifies the interface type of the target data access interface and uses corresponding data acquisition methods to obtain raw data from multiple heterogeneous data sources according to three types of interfaces: relational database interface, non-relational database interface, and application programming interface. This avoids data acquisition failures or format incompatibility caused by differences in interface protocols. After obtaining the raw data from each data source, the method performs correlation and aggregation on multiple standard data to obtain query results. An editable document containing traceability information between each data item and its corresponding source data is then generated and output according to a preset output format. This achieves fully automated processing from differentiated adaptation and acquisition of multi-source heterogeneous data, unified aggregation, to the generation of traceable documents. This ensures data acquisition compatibility and accuracy while guaranteeing that each data item in the query results can be traced back to the original data source, improving data credibility and audit efficiency.

[0267] Figure 4 This is a schematic diagram of the structure of a financial data query device provided in this application. Figure 4 As shown, this application provides a financial data query device, the financial data query device 400 including:

[0268] The acquisition module 401 is used to acquire the natural language query statement input by the user;

[0269] Processing module 402 is used to perform semantic parsing on natural language query statements through a financial business big language model and generate query instructions, which include data dimensions, time range and calculation logic.

[0270] The processing module 402 is also used to perform risk assessment on the query intent of the current query, the data sensitivity of the requested data and the access mode based on the query command, obtain the assessment result, and determine the hierarchical response strategy based on the assessment result and user permissions.

[0271] The processing module 402 is also used to obtain corresponding source data from multiple heterogeneous data sources according to the hierarchical response strategy, and to aggregate the multiple source data to obtain query results;

[0272] The processing module 402 is also used to convert the query results into an editable document and output it according to a preset output format.

[0273] In one possible embodiment, the processing module 402 is further configured to perform preliminary semantic mapping on financial terms in natural language query statements using an incrementally trained financial terminology database to obtain basic parsing results.

[0274] The processing module 402 is also used to correct ambiguous financial terms in the basic parsing results based on the user's historical query records and / or the current session context;

[0275] Processing module 402 is also used to extract the data dimensions and time range in the natural language query statement based on the corrected parsing results, and obtain the target parsing results;

[0276] The processing module 402 is also used to map the computational requirements in the natural language query statement to the corresponding computational logic based on the financial data dictionary, and to generate query instructions based on the target parsing results and the computational logic.

[0277] In one possible embodiment, the processing module 402 is further configured to identify the business scenario and purpose corresponding to the current query based on the query instruction, and determine the risk level of the query intent;

[0278] The processing module 402 is also used to match the data fields requested by the query instruction with a preset sensitive field library to determine the sensitive fields and sensitivity levels included in the requested data;

[0279] The acquisition module 401 is also used to acquire the user's historical access records;

[0280] The processing module 402 is also used to perform anomaly detection on the user's access frequency, access time period and access scope based on preset abnormal behavior judgment rules, and determine the risk level of the access mode.

[0281] Processing module 402 is also used to perform compliance verification on user permissions, query intent, sensitive fields and historical access records to obtain permission verification results;

[0282] The processing module 402 is also used to determine the assessment result based on the risk level of the query intent, the sensitivity level, the risk level of the access mode, and the permission verification result, according to preset risk rules.

[0283] In one possible embodiment, the processing module 402 is further configured to determine the risk level of the current query based on the assessment results, and determine the permission level based on the user's permissions;

[0284] The processing module 402 is also used to match the risk level with the permission level to determine the response level corresponding to the current query;

[0285] The processing module 402 is also used to match the corresponding response action and data output method from a preset hierarchical response strategy table according to the response level; wherein, the hierarchical response strategy table defines the mapping relationship between different response levels and response actions and data output methods, and the response action includes at least one or more combinations of allowing access, data desensitization processing, and denying access.

[0286] In one possible embodiment, the processing module 402 is further configured to determine the target data source identifier and the required data fields according to the query instruction when the hierarchical response policy is set to allow access;

[0287] The processing module 402 is also used to call the target data access interface corresponding to the target data source identifier, and obtain the original data in the corresponding heterogeneous data source through the target data access interface;

[0288] The processing module 402 is also used to perform format standardization processing and field mapping on the acquired raw data to obtain standard data in a unified format;

[0289] The processing module 402 is also used to perform correlation and aggregation on multiple standard data to obtain query results.

[0290] In one possible embodiment, the processing module 402 is further configured to identify the interface type of the target data access interface;

[0291] The processing module 402 is also used to construct a structured query statement and execute the statement through the relational database interface to obtain the original data when the interface type is a relational database interface;

[0292] The processing module 402 is also used to construct a corresponding non-relational data query statement when the interface type is a non-relational database interface, and execute the non-relational data query statement through the non-relational database interface to obtain the original data;

[0293] The processing module 402 is also used to construct a hypertext transfer request when the interface type is an application programming interface, and send the request through the application programming interface to obtain the raw data.

[0294] In one possible embodiment, the processing module 402 is further configured to generate an editable document containing traceability information on the association between each data item and the corresponding source data based on the query results;

[0295] The processing module 402 is also used to output an editable document according to a preset output format.

[0296] The financial data query device provided in this application embodiment is similar in principle and technical effect to the implementation of each part of the aforementioned financial data query method, and will not be described again here.

[0297] Figure 5 This is a schematic diagram of the structure of an electronic device provided in this application. Figure 5 As shown, the electronic device 500 includes: a receiver 501, a transmitter 502, a processor 503, and a memory 504.

[0298] Receiver 501 is used to receive instructions and data;

[0299] Transmitter 502 is used to send commands and data;

[0300] Memory 504 is used to store instructions executed by the computer;

[0301] The processor 503 is used to execute computer execution instructions stored in the memory 504 to implement the various steps of the financial data query processing method in the above embodiments. For details, please refer to the relevant descriptions in the foregoing embodiments of the financial data query method.

[0302] Optionally, the memory 504 can be either standalone or integrated with the processor 503.

[0303] When the memory 504 is set up independently, the electronic device also includes a bus for connecting the memory 504 and the processor 503.

[0304] The implementation principle and technical effects of the electronic device provided in this embodiment can be found in the foregoing embodiments, and will not be repeated here.

[0305] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the method of any of the foregoing embodiments.

[0306] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the method of any of the foregoing embodiments.

[0307] 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 this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0308] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart 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 performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0309] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0310] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

[0311] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0312] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0313] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for querying financial data, characterized in that, include: The system obtains the natural language query statement input by the user, performs semantic parsing on the natural language query statement through the financial business big language model, and generates a query instruction, which includes data dimensions, time range and calculation logic. Based on the query command, a risk assessment is performed on the query intent, data sensitivity of the requested data, and access pattern to obtain the assessment result. Based on the assessment result and user permissions, a tiered response strategy is determined. According to the hierarchical response strategy, corresponding source data is obtained from multiple heterogeneous data sources, and the multiple source data are aggregated to obtain query results; The query results are converted into an editable document and output according to a preset output format.

2. The method according to claim 1, characterized in that, The step of semantically parsing the natural language query statement using a financial business big language model to generate query instructions includes: By using an incrementally trained financial terminology database, preliminary semantic mapping is performed on the financial terms in the natural language query statement to obtain basic parsing results; Based on the user's historical query records and / or the current session context, ambiguous financial terms in the basic parsing results are corrected; Based on the corrected parsing results, the data dimensions and time ranges in the natural language query are extracted to obtain the target parsing results; Based on the financial data dictionary, the computational requirements in the natural language query statement are mapped to the corresponding computational logic, and the query instruction is generated according to the target parsing result and the computational logic.

3. The method according to claim 1, characterized in that, The process involves performing a risk assessment based on the query instruction, considering the query intent, data sensitivity of the requested data, and access patterns, to obtain the assessment results, including: Based on the query instruction, identify the business scenario and purpose corresponding to the current query, and determine the risk level of the query intent; Based on the data fields requested by the query command, a preset sensitive field library is matched to determine the sensitive fields and sensitivity levels included in the requested data; Obtain the user's historical access records, and based on preset abnormal behavior judgment rules, perform abnormal detection on the user's access frequency, access time period and access scope to determine the risk level of the access pattern; The user permissions are compared with the query intent, the sensitive fields, and the historical access records to obtain the permission verification result. The evaluation result is determined based on the risk level of the query intent, the sensitivity level, the risk level of the access mode, and the permission verification result, according to preset risk rules.

4. The method according to claim 1, characterized in that, The step of determining a tiered response strategy based on the evaluation results and user permissions includes: The risk level of the current query is determined based on the assessment results, and the permission level is determined based on the user's permissions. The risk level is matched with the permission level to determine the response level corresponding to the current query; Based on the response level, the corresponding response action and data output method are matched from a preset hierarchical response strategy table; wherein, the hierarchical response strategy table defines the mapping relationship between different response levels and response actions and data output methods, and the response action includes at least one or more combinations of allowing access, data anonymization processing, and denying access.

5. The method according to claim 4, characterized in that, The step of obtaining corresponding source data from multiple heterogeneous data sources according to the hierarchical response strategy, and aggregating the multiple source data to obtain query results includes: When the hierarchical response strategy allows access, the target data source identifier and required data fields are determined according to the query instruction; Call the target data access interface corresponding to the target data source identifier, and obtain the original data from the corresponding heterogeneous data source through the target data access interface; The obtained raw data is subjected to format standardization processing and field mapping to obtain standard data with a unified format; The query results are obtained by associating and aggregating multiple sets of standard data.

6. The method according to claim 5, characterized in that, The step of calling the target data access interface corresponding to the target data source identifier, and obtaining the original data from the corresponding heterogeneous data source through the target data access interface, includes: Identify the interface type of the target data access interface; When the interface type is a relational database interface, a structured query statement is constructed, and the statement is executed through the relational database interface to obtain the original data; When the interface type is a non-relational database interface, a corresponding non-relational data query statement is constructed, and the non-relational data query statement is executed through the non-relational database interface to obtain the original data; When the interface type is an application programming interface (API), a hypertext transfer request is constructed, and the request is sent through the API to obtain the raw data.

7. The method according to claim 1, characterized in that, The step of converting the query results into an editable document and outputting it according to a preset output format includes: Based on the query results, an editable document containing traceability information about the relationship between each data item and its corresponding source data is generated. The editable document is output according to the preset output format.

8. A financial data query device, characterized in that, The device includes: The acquisition module is used to acquire the natural language query statement input by the user; The processing module is used to perform semantic parsing on the natural language query statement through the financial business big language model and generate query instructions, which include data dimensions, time range and calculation logic; The processing module is also used to perform a risk assessment on the query intent, data sensitivity of the requested data and access mode of the current query based on the query instruction, obtain the assessment result, and determine a hierarchical response strategy based on the assessment result and user permissions. The processing module is further configured to obtain corresponding source data from multiple heterogeneous data sources according to the hierarchical response strategy, and aggregate the multiple source data to obtain query results; The processing module is also used to convert the query results into an editable document and output it according to a preset output format.

9. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1 to 7.

11. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method of any one of claims 1 to 7.

Images