Bank risk monitoring method and system based on ChatBI model

Abstract

The invention discloses a bank risk monitoring method and system based on a ChatBI model, and aims to solve the problems of mutual complex query and conflict between security and performance, and the method comprises the following steps: receiving a natural language query instruction, and analyzing and generating a structured data request by using the ChatBI model; generating an initial data query instruction containing a preset permission mark; before execution, a user permission strategy is obtained, an initial instruction is modified according to the user permission strategy, accurate row-level filtering and column-level desensitization rules are injected in the mode of replacing permission marks, and therefore a final data query instruction is generated; the processor executes the final instruction to obtain risk data, preposition of authority control is achieved through an instruction rewriting mechanism before execution, it is ensured that the minimum authority principle of data access is executed on the data source level, data safety is fundamentally guaranteed, and query performance is greatly improved due to the fact that redundant data transmission is avoided; and meanwhile, convenient natural language interaction experience is provided for the user.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer data processing, and particularly relates to a bank risk monitoring method and system based on a ChatBI model. BACKGROUND

[0002] With the digital transformation of financial services, the demand for risk monitoring of groups such as inclusive small and micro customers is growing. However, existing risk monitoring technologies face multiple challenges in actual application.

[0003] The human-computer interaction efficiency of existing data query systems is low. Front-line business personnel of banks usually do not have professional database query skills. They use internal risk control systems or external credit investigation platforms, which mostly require the input of accurate and standardized query conditions. When business personnel only have oral nicknames, aliases or only have vague query intentions of customers, they cannot effectively obtain data, which greatly increases the complexity and time cost of operations.

[0004] There is a technical conflict between data security and query performance. In order to protect sensitive financial data, the system must implement strict access control. A common technical implementation is "post-filtering", that is, the application server first grabs a "superset" containing unauthorized data from the database, then filters the data according to user permissions in the server memory, and finally returns the results to the user. This approach can cause a large amount of redundant data to be transmitted between the database and the application server when processing large-scale data queries, causing network input / output (I / O) bottlenecks and server memory pressure, resulting in slow system response. Conversely, if the data grabbing range is relaxed for performance, it will introduce compliance risks of data leakage.

[0005] The security defense mechanism of the existing system is passive. Most systems rely on static permission configuration and access rules, and lack effective and real-time identification and active blocking capabilities for new and hidden data security threats, such as high-frequency data dragging using legitimate permissions, resource-exhausting malicious queries, or abnormal access outside working hours. This makes the system vulnerable when facing continuously evolving attack methods.

[0006] It should be noted that the information disclosed in the above background section is only used to strengthen the understanding of the background of the present application, and therefore can include information that does not constitute prior art known to those of ordinary skill in the art. SUMMARY

[0007] In view of this, the present application provides a bank risk monitoring method and system based on ChatBI model to overcome the defects in the prior art that the bank front-line personnel do not have professional database query skills, resulting in low human-computer interaction efficiency, the existing data access control mechanism has inherent conflicts between data security and query performance, and the existing system security defense mechanism is passive, aiming to provide a bank risk monitoring scheme based on ChatBI model which can reduce the technical threshold of user query, realize safe and efficient data access, and establish an active and intelligent security defense mechanism.

[0008] The embodiment of the present application provides a bank risk monitoring method based on ChatBI model, comprising: receiving a natural language query instruction input by a computer device; performing semantic analysis on the natural language query instruction based on a preset ChatBI model to generate a structured data request containing query entities and query conditions; generating an initial data query instruction containing a preset permission marker according to the structured data request; Before executing the initial data query instruction, obtaining a permission policy associated with the user account initiating the query, and modifying the initial data query instruction according to the permission policy to generate a final data query instruction; executing the final data query instruction by a computer processor to obtain bank risk monitoring data based on ChatBI model.

[0009] In some optional embodiments, the semantic analysis further comprises: When the natural language query instruction contains colloquial or non-standardized entity expressions, use a pre-installed financial knowledge graph to perform entity linking on the entity expressions to identify the corresponding standardized entities.

[0010] In some optional embodiments, the initial data query instruction is a logical query plan, and the preset permission marker is a filter node to be instantiated in the logical query plan.

[0011] In some optional embodiments, modifying the initial data query instruction according to the permission policy comprises: Converting the row-level permission rules in the permission policy for limiting the access range of data records into one or more specific filter conditions; Using one or more specific filter conditions to replace or instantiate the preset permission marker in the initial data query instruction.

[0012] In some optional embodiments, the row-level permission rules are defined based on at least one of the role of the user account, the affiliated institution, or the geographic area information.

[0013] In some optional embodiments, the modifying the initial data query instruction according to the permission policy further comprises: identifying a data field requested to be accessed in the initial data query instruction; when the permission policy contains an access restriction rule for a specific data field, modifying an access manner of the specific data field in the initial data query instruction.

[0014] In some optional embodiments, the modifying the access manner of the specific data field in the initial data query instruction comprises: replacing a direct reading request for the specific data field with a request for applying a preset data desensitization function to the specific data field.

[0015] In some optional embodiments, the method further comprises a parallel security monitoring process, and the security monitoring process comprises: analyzing an instruction structure of the final data query instruction before the final data query instruction is executed; when it is identified that the instruction structure satisfies a preset high-risk operation mode, then aborting execution of the final data query instruction.

[0016] In some optional embodiments, the high-risk operation mode comprises a full-data scanning mode requesting to access data in an amount exceeding a preset threshold, or a multi-source data connection mode with a complexity of data correlation operation exceeding a preset threshold.

[0017] In some optional embodiments, the method further comprises a parallel user behavior analysis process, and the user behavior analysis process comprises: recording a query frequency of a user account within a preset time window; when the query frequency exceeds a preset frequency threshold, then suspending processing of subsequent query requests of the user account, and starting a secondary identity verification process.

[0018] In some optional embodiments, the executing the final data query instruction comprises: decomposing the final data query instruction into a sub-query instruction for an internal data source and an API calling request for an external data source; parallelly executing the sub-query instruction and the API calling request.

[0019] In some optional embodiments, after obtaining the bank risk monitoring data based on the ChatBI model, the method further comprises: generating a structured report containing risk attribution analysis text according to a risk index in the bank risk monitoring data based on the ChatBI model, and outputting the report on a display device.

[0020] An embodiment of the present application provides a bank risk monitoring system based on a ChatBI model, comprising: The instruction receiving and analyzing module is configured to receive a natural language query instruction input by a computer device, and perform semantic analysis on the instruction based on a preset ChatBI model to generate a structured data request. The initial instruction generating module is connected with the instruction receiving and analyzing module, and is configured to generate an initial data query instruction containing a preset permission mark according to the structured data request. The instruction rewriting module is connected with the initial instruction generating module, and is configured to obtain a permission policy associated with a user account initiating the query before executing the initial data query instruction, and modify the initial data query instruction according to the permission policy to generate a final data query instruction. The instruction executing module is connected with the instruction rewriting module, and is configured to execute the final data query instruction by a computer processor to obtain bank risk monitoring data based on the ChatBI model.

[0021] In some optional embodiments, the instruction rewriting module is specifically configured to: add a corresponding filter condition in the initial data query instruction according to a row-level permission rule in the permission policy for limiting the access range of data records; modify a direct access request for a specific data field in the initial data query instruction into a request for applying a preset data desensitization operation according to an access restriction rule for the specific data field in the permission policy.

[0022] In some optional embodiments, the system further comprises: The security monitoring module is connected with the instruction rewriting module and the instruction executing module, and is configured to analyze the instruction structure of the final data query instruction before the final data query instruction is executed, and when it is identified that the instruction structure satisfies a preset high-risk operation mode, the execution of the final data query instruction is aborted.

[0023] In some optional embodiments, the instruction executing module is specifically configured to: divide the final data query instruction into a sub-query instruction for an internal data source and an API call request for an external data source; execute the sub-query instruction and the API call request in parallel, and fuse the returned data results.

[0024] It should be understood that the above general description and the following detailed description are only exemplary and explanatory, and cannot limit the present application.

[0025] The bank risk monitoring method and system based on the ChatBI model have the following beneficial effects: The application converts complex queries into simple interactions through natural language understanding, improves business efficiency; the pre-execution instruction rewriting mechanism ensures the principle of least privilege, reduces the risk of data leakage from the root, and improves the query performance under large data; parallel security monitoring and user behavior analysis build a multi-level intelligent defense system, actively identify and intercept malicious operations; seamlessly integrate internal and external data sources and generate reports containing attribution analysis, enhance the timeliness, comprehensiveness and accuracy of risk decision-making. The method improves the query efficiency and reduces the operation and maintenance cost under the premise of ensuring data security compliance, and provides a more efficient, safe and intelligent solution for bank risk monitoring based on ChatBI model. BRIEF DESCRIPTION OF DRAWINGS

[0026] Other features, objects, and advantages of the application will become more apparent from the following detailed description of non-limiting embodiments with reference to the drawings.

[0027] Figure 1 is a flowchart of a bank risk monitoring method based on a ChatBI model according to an embodiment of the application; Figure 2 is a structural schematic diagram of a bank risk monitoring system based on a ChatBI model according to an embodiment of the application. DETAILED DESCRIPTION

[0028] Example implementations will now be described more fully with reference to the accompanying drawings. Example implementations may, however, be implemented in many different forms and should not be construed as limited to the implementations set forth herein; rather, these implementations are provided so that this disclosure will be thorough and complete, and will fully convey the inventive aspects to those skilled in the art. Features, structures, or characteristics described in connection with one implementation can be combined in any suitable manner with features, structures or characteristics of other implementations.

[0029] In addition, the drawings are only schematic and are non-limiting. Like references signs denote like parts throughout the drawings and textual description, whereupon repeated description of like parts will be omitted. Some of the blocks in the drawings are functional entities that do not necessarily have to correspond to physically or logically independent entities. These functional entities can be implemented in software, or in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0030] The flowcharts shown in the drawings are only illustrative and do not necessarily include all the steps. For example, some steps can be further decomposed, and some steps can be combined or partially combined, so the actual execution order can be changed according to the actual situation.

[0031] The technical scheme relates to how to efficiently and safely convert a natural language query of a user into a machine executable instruction, and finally realize effective monitoring of bank risk data. Natural language processing technology enables a computer to understand and analyze human language, thereby converting an unstructured query into a structured data request, and reducing the use threshold of the user. Data query optimization technology is committed to improving the efficiency of data retrieval, and through a preset permission marking and instruction rewriting mechanism, the permission policy of the user is dynamically injected into the query instruction before query execution, thereby avoiding performance loss and security risks caused by a traditional post-filtering mode. Parallel computing technology can fully utilize the computing capacity of a multi-core processor and a distributed system, decompose a complex query task into multiple subtasks, and execute the subtasks in parallel, thereby shortening the response time. These technologies work together to realize the purpose of improving user experience and system performance under the premise of ensuring data security.

[0032] As shown in Figure 1 The embodiment of the application provides a bank risk monitoring method based on a ChatBI model, which comprises the following steps: S100, receiving a natural language query instruction input by a computer device. This step is the starting point of the bank risk monitoring method based on the ChatBI model. The user can express the query requirement in the form of natural language through the computer device, including but not limited to a PC, a mobile terminal and the like, so as to break the wall of professional SQL knowledge required by a traditional database query. The natural language query instruction refers to a query request input by the user in the form of daily colloquial language, rather than an unstructured query statement such as SQL, for example, "who is the legal representative of Beijing Huaxing Industry?". The receiving mode of the instruction greatly reduces the use threshold of the user, so that a bank front-line business personnel without a professional technical background can also conveniently obtain the required data.

[0033] S200, based on the preset ChatBI model, the natural language query instruction is semantically analyzed to generate a structured data request containing query entities and query conditions. This step realizes natural language understanding and machine executable instruction conversion. ChatBI model refers to a language model that is trained and optimized for a specific field, specifically, a language model for the financial industry. Compared with general language models, it can more accurately understand and analyze professional terms and business logic in the financial field. The model processes the input natural language query instruction through deep learning algorithms, such as word segmentation, part-of-speech tagging, named entity recognition, and dependency syntax analysis, extracts key query entities such as enterprise names, legal representatives, and query conditions such as regions and time ranges, and converts them into computer-understandable structured data requests, such as JSON format data structures. The structured data request contains clear query intent and query parameters, laying the foundation for subsequent data query and processing. To improve the accuracy of the model's understanding of financial domain terminology, ChatBI model can select pre-trained models such as BERT and GPT, and fine-tune them using financial research reports, credit contracts and other professional corpus. Specifically, financial ChatBI models such as ChatBl model can be used, and the present embodiment does not make specific limitations, and other models that can achieve the same or similar functions can be used as ChatBI models of the present invention.

[0034] S300, according to the structured data request, an initial data query instruction containing a preset permission marker is generated. This step is to convert the results of semantic analysis into executable query instructions and reserve interfaces for subsequent dynamic permission control. The generated initial data query instruction is not a complete executable instruction, but a preset permission marker is embedded in the key position such as the filter condition part. This marker can be understood as a placeholder, which does not affect the grammatical correctness of the instruction, but provides an accurate anchor point for subsequent permission injection. For example, the initial data query instruction may be a SQL statement, and the WHERE clause in the statement contains a "@@PERMISSION_PLACEHOLDER@@" marker, indicating that the corresponding filter condition needs to be added according to the user's permission. Using the initial data query instruction containing the preset permission marker, the logical query plan can be used to decouple the permission control logic and the query logic, providing flexibility for subsequent dynamic permission management.

[0035] S400. Before executing the initial data query instruction, the system obtains the permission policy associated with the user account initiating the query and modifies the initial data query instruction according to the permission policy to generate the final data query instruction. This step implements dynamic, fine-grained data access control. First, the system needs to obtain the permission policy associated with the user account initiating the query. The permission policy defines which data a user can access and what operations they can perform. The permission policy can be configured based on multiple dimensions such as user role, affiliated organization, and data sensitivity level, and is stored in a centralized permission management system. Then, the initial data query instruction is modified according to the permission policy. This modification is performed before the instruction is executed, also known as pre-access control. According to the permission policy, the system injects the corresponding filtering conditions or data anonymization operations into the initial data query instruction to generate a final data query instruction. This final data query instruction has internalized the user's permission logic, ensuring that only data that the user is authorized to access is returned at the data source level.

[0036] The S500 uses a computer processor to execute final data query instructions to retrieve bank risk monitoring data based on the ChatBI model. These instructions are sent to a database or other data source and executed by the computer processor to obtain the final risk monitoring data. Because the final data query instructions already include user permission restrictions, the data source only returns a subset of data that meets the permissions, thus avoiding redundant data transmission and processing, improving query efficiency and data security. The execution of the final data query instructions by the computer processor can utilize distributed computing frameworks such as Spark and Hadoop to accelerate the data processing.

[0037] The method provided in this invention lowers the technical threshold for user queries through natural language understanding, achieves fine-grained data access control through preset permission tags and dynamic instruction rewriting, and balances ease of use, security and query performance. This allows business personnel without professional skills to quickly and accurately obtain risk monitoring data, thereby improving the efficiency and accuracy of risk decision-making and effectively preventing data leakage risks.

[0038] In some embodiments, semantic parsing further includes: When a natural language query command contains colloquial or non-standard entity representations, a pre-built financial knowledge graph is used to link the entity representations to identify their corresponding standardized entities.

[0039] Embodiments of the present application aim to solve the problem that the system cannot accurately identify the user's intention due to colloquial or non-standard entity expression when the user uses natural language to query. To solve this problem, the present application uses a pre-set financial knowledge graph to perform entity linking on the entity expression in the natural language query instruction, that is, to identify non-standard or ambiguous entity references and map them to standardized entity representations in the knowledge graph.

[0040] Specifically, the financial knowledge graph is a structured knowledge base that stores a large number of entities in the financial field such as companies, products, and persons and their mutual relationships. The construction of this knowledge graph can be achieved in various ways, for example: extracting entities and relationships from publicly available business registration information, financial research reports, news information, etc.; or manually constructed and maintained by domain experts. Each entity in the knowledge graph has a unique identifier and a standardized name, and may also contain various attribute information of the entity such as aliases, abbreviations, and English names. When the system receives a query instruction containing a non-standard entity expression, for example, the user inputs "check the latest risks of Huaxing", the ChatBI model can identify "Huaxing" as a query entity of the company name type, but "Huaxing" may only be the abbreviation or alias of "Beijing Huaxing Co., Ltd.". At this time, the entity linking module will query the financial knowledge graph to try to link "Huaxing" to the known company entities in the knowledge graph. The process of entity linking can use various algorithms, for example: string similarity-based matching algorithm, vector embedding-based similarity calculation method, or machine learning-based classification model. Considering the rigor of the financial field, the present application preferably uses a matching algorithm based on string similarity combined with expert rules, for example, when there are multiple company names containing the "Huaxing" field in the knowledge graph, such as "Beijing Huaxing Co., Ltd.", "Shanghai Huaxing Trade Company", etc., the system can prioritize linking to "Beijing Huaxing Co., Ltd." by combining the user's current geographic location, for example, the user is located in Beijing. If there are multiple matching entities and cannot be disambiguated by other information, the system can prompt the user to select a specific company name to ensure the accuracy of the query.

[0041] Through entity linking, the system can convert non-standard entity expressions into standardized entity representations, thereby avoiding the problem of inaccurate query results due to entity ambiguity. For example, after linking "Huaxing" to "Beijing Huaxing Co., Ltd." through entity linking, the system can obtain the company's unified social credit code, legal representative, etc. according to the entity attribute information stored in the knowledge graph, and use these information as query conditions to retrieve related data from the database. In addition, the knowledge graph can also be used to expand the query range, for example, when the user queries "Huaxing's associated enterprises", the system can query other company entities that have investment or control relationships with "Beijing Huaxing Co., Ltd." in the knowledge graph, and include these companies in the query range.

[0042] The above technical solutions can effectively improve the accuracy and coverage of natural language queries and improve user experience. For example, the user only needs to input the company abbreviation to complete the query, without the need to remember and input the complete company name, greatly simplifying the operation process. At the same time, through the extension query capability of the knowledge graph, potential risk associations can be discovered to improve the comprehensiveness of risk monitoring.

[0043] In some embodiments, the initial data query instruction is a logical query plan, and the preset permission mark is a filter node to be instantiated in the logical query plan. The specific form of the initial data query instruction and the embodiment of the permission control strategy in the instruction adopt the abstract data structure of the logical query plan, making the generation and conversion process of the instruction more flexible, easy to maintain and extend, and able to adapt to the differences of different types of data sources. The preset permission mark, i.e. the filter node to be instantiated, is the key to realize dynamic permission control. It is implanted into the logical query plan at the initial stage of instruction generation, providing an accurate anchor point for subsequent permission strategy injection, ensuring that the permission control logic can be seamlessly integrated into the data query process.

[0044] The logical query plan can be implemented in various ways. For example, it can be an abstract syntax tree (AST), where each node represents a relational algebra operation such as selection, projection, join, etc. The filter node can be represented as a special selection (Selection) operation with an initially empty or placeholder filter condition. Alternatively, the logical query plan can also adopt a more compact intermediate representation form, such as serialized JSON or XML format. For example, the filter node can be represented as a special field in a JSON object: `{"type": "filter", "condition": "@@PERMISSION_PLACEHOLDER@@"}`.

[0045] The filter node to be instantiated can also have various implementation methods. It can be a standard placeholder string such as `@@PERMISSION_PLACEHOLDER@@`, or a pre-defined class or object containing an attribute for storing the actual filter condition. For example, in Java, a `PermissionFilterNode` class can be defined, containing a `condition` attribute with an initial value of `null`.

[0046] The embodiments of the present application change the permission control from the traditional post-filtering mode to the pre-injection mode. By converting the user's permission policy into specific filtering conditions before the instruction execution, and seamlessly injecting it into the initial data query instruction, it is ensured that the data source will only access and return the minimum data subset that meets the permission when executing the query. This mechanism not only avoids the transmission and processing of redundant data, greatly improves the query performance, but also fundamentally eliminates the risk of over-authorized data leakage.

[0047] The technical solutions of logical query plan and instantiable filtering node can improve the security and efficiency of the bank risk monitoring system based on ChatBI model. Since the permission control is embedded in the initial stage of data query, the risk of sensitive data leakage can be maximally avoided, unnecessary data transmission can be reduced, query response speed can be improved, and resource consumption of the system can be effectively reduced.

[0048] In some embodiments, modifying the initial data query instruction according to the permission policy comprises: Converting the row-level permission rule in the permission policy for limiting the access range of data records into one or more specific filtering conditions; Using the one or more specific filtering conditions to replace or instantiate the preset permission mark in the initial data query instruction.

[0049] The embodiments achieve fine-grained control of data access. The row-level permission rule in the permission policy for limiting the access range of data records defines which data rows the user can access. In the bank risk monitoring scenario based on ChatBI model, the row-level permission rule is usually associated with factors such as the user's role, the affiliated institution or the geographical location. For example, a customer manager can only access the information of the customers he is responsible for, and a branch employee can only access the data in his region. In order to achieve these restrictions, the embodiments of the present application convert the row-level permission rule into specific filtering conditions, such as the WHERE clause in the SQL statement, to limit the scope of data query. The present application uses these specific filtering conditions to replace or instantiate the preset permission mark in the initial data query instruction, thereby embedding the permission control logic into the query instruction.

[0050] Specifically, the above-mentioned replacement or instantiation of the preset permission marker can be implemented in various ways. For example, when the row-level permission rule defines that the user can only access the data of a specific organization, the preset permission marker can be replaced with a filter condition similar to "organization_id = 'user's organization ID'". For another example, when the row-level permission rule defines that the user can only access the data of the customers he is responsible for, the preset permission marker can be replaced with a filter condition similar to "manager_id = 'user ID'". It should be noted that the manager_id and organization_id here are only exemplary descriptions, and in actual application scenarios, other fields can also be used for limitation, such as the industry to which the customer belongs, the credit rating of the customer, and the like.

[0051] In addition to the role of the user account, the organization to which the user belongs, or the geographic region information, the above-mentioned row-level permission rule can also be defined based on the attributes of the data itself. For example, it can be defined that only personnel of a certain level can access data with a high level of sensitivity, which can be achieved by judging a preset sensitivity level field in the data record.

[0052] Through this step, the present application can ensure that each user can only access the data he is authorized to access, thereby avoiding the risk of unauthorized access and data leakage. At the same time, since the filter condition is injected before the query execution, the permission control can be realized at the data source level, avoiding the performance loss of a large amount of data filtering on the application server side. This technical solution not only improves the data security, but also improves the query efficiency, so that the system can maintain good response speed under large data volume.

[0053] In some embodiments, the row-level permission rule refers to an access control strategy that limits the range of accessible data according to specific attributes of the user account, such as role, organization to which the user belongs, or geographic region. This rule is crucial in a risk monitoring system, as it ensures that users can only access data related to their responsibilities or jurisdiction, thereby preventing unauthorized access and data leakage and meeting the compliance requirements of the financial industry.

[0054] In the present application, the row-level permission rule is used to solve the contradiction between data security and query performance in the prior art. By converting the row-level permission rule into a specific filter condition and injecting it into the initial data query instruction during the instruction rewriting phase, the system can accurately control the user's permissions at the data source level, avoiding the transmission and processing of a large amount of redundant data in the traditional post-filtering method, thereby improving the query performance while ensuring data security.

[0055] Specifically, the row-level permission rule can be implemented based on the following technical solutions: Role-Based Access Control (RBAC): Assign permissions to users based on their roles in the organization, such as customer manager, credit approver, risk analyst. For example, a customer manager role may be restricted to access only the data of the customers they are responsible for, while a credit approver can access all pending credit application data. Roles can be implemented through predefined role-permission tables or through dynamic role-permission assignment systems. For example, create role and permission tables in the database, associate user IDs with role tables, and associate role tables with permission tables to achieve user-permission correspondence.

[0056] Institution-based access control: Limit the range of data that users can access based on their institution, such as branch, department. For example, employees of the Beijing branch can only access customer data within the jurisdiction of the Beijing branch, and employees of the Shanghai branch can only access customer data within the jurisdiction of the Shanghai branch. Institutions can be implemented through predefined institution codes or through dynamic organizational structure information. For example, establish an organizational structure management system within the enterprise, query the user's institution, and then inject the institution code as a query condition into the SQL statement.

[0057] Geographical area-based access control: Limit the range of data that users can access based on their geographical location, such as country, province, city. For example, only allow domestic users to access domestic customer data, and prohibit foreign users from accessing. Geographical location can be determined by IP address or address information filled in by the user during registration. For example, locate the user's geographical location through the IP address, and then inject the geographical location information as a query condition into the SQL statement.

[0058] In practical applications, these rules can be used alone or in combination to achieve more refined permission control. For example, you can set up a customer manager in the Beijing branch to only access customer data in the Beijing area they are responsible for. These rules can be stored in the permission center and dynamically applied to data query instructions based on user account attributes. The permission center can use a centralized permission management system or a distributed permission management system. Permission rules can use predefined rule engines or custom scripting languages to implement.

[0059] In addition, the definition and application of line-level permission rules do not necessarily rely on specific fields in the database table structure. For example, you can associate multiple underlying data tables through virtual data views (Views), and dynamically filter data based on user roles or institution information. This way you can avoid modifying existing database table structures, thereby reducing system maintenance costs.

[0060] By using the above technical means, the present application can achieve the following technical effects: Fine-grained permission control: Based on various attributes such as user account roles, affiliated institutions, or geographic regions, fine-grained control of data access can be achieved, ensuring that users can only access data related to their job responsibilities, effectively preventing unauthorized access and data leakage.

[0061] Improved data security: By implementing permission control at the data source level, the risk of sensitive data leakage during network transmission and server-side processing is avoided, significantly improving the overall security of the system.

[0062] Compliance satisfaction: It meets the regulatory requirements of the financial industry for data security and privacy protection, providing a safe and compliant data access solution for banks.

[0063] In some embodiments, modifying the initial data query instruction according to the permission policy further includes: Identifying the data fields requested to access in the initial data query instruction; When the permission policy contains access restriction rules for specific data fields, modify the access method of the specific data fields in the initial data query instruction.

[0064] Embodiments of the present application aim to solve the problem that different users may have different access permissions to different fields of the same data table. By analyzing the initial data query instruction, the specific fields requested to access by the user are determined and compared with the pre-set permission policy, fine-grained access control can be implemented at the field level. For example, a user may be allowed to view the name and address of a customer, but prohibited from viewing the customer's phone number. This technical solution dynamically associates field access permissions with query instructions, achieving a balance between data security and flexible access.

[0065] Modifying the access method for a specific data field in the initial data query instruction can involve various implementation methods. For example, user access to the field can be directly denied, and the field's value can be set to null in the returned result. Alternatively, data anonymization techniques can be used to partially or completely mask the field's value; for example, using asterisks (*) to mask some digits of a phone number. Another option is to use data transformation techniques to convert the field's value to another form; for example, hashing a customer's ID number before returning it. Furthermore, access restriction rules can be defined based on multiple dimensions, such as user role, user department, and data sensitivity level. For example, for highly sensitive data fields like account balances, only users with specific roles can access them, and additional security verification is required. Regular users can only access the anonymized data. In practice, the database's built-in access control functions can be used; for example, MySQL's GRANT and REVOKE statements can be used to control user access permissions to specific fields. Alternatively, a custom permission management module can be used to intercept SQL statements and dynamically modify the query plan, thereby achieving fine-grained control over field access. For example, AOP (Aspect-Oriented Programming) technology can be used to dynamically weave permission control logic before the SQL statement is executed. Alternatively, a database proxy middleware can be used to intercept SQL statements and modify them according to the permission policy.

[0066] By implementing the above embodiments, unauthorized access to sensitive data can be effectively prevented, ensuring data security and compliance. Furthermore, since access control is performed at the field level, it can maximize the fulfillment of users' reasonable data needs and avoid impacting business efficiency due to excessive access restrictions.

[0067] In some embodiments, modifying the access method for a specific data field in the initial data query instruction includes: The direct read request for that specific data field will be replaced with a request to apply a preset data anonymization function to that specific data field.

[0068] This invention, while ensuring data security, meets users' needs for querying sensitive data. In the financial sector, customers' personal information such as ID numbers, contact numbers, and bank accounts is highly sensitive data; directly exposing this information would pose significant compliance risks and security vulnerabilities. The technical principle of this invention lies in pre-setting permission policies to restrict different users or user roles from accessing these sensitive fields and dynamically modifying query instructions, thereby achieving data anonymization.

[0069] Specifically, if the permission policy indicates that the user's access level to a certain data field, such as "customer contact phone", is "desensitization", the instruction rewriting module will replace the direct read request for this field in the original query instruction with a request to call a preset data desensitization function. For example, the original SQL statement may be `SELECT customer_name, customer_contact_phone FROM customer_table WHERE...`, after modification, it will become `SELECT customer_name, MASK_PHONE(customer_contact_phone) FROM customer_table WHERE...`. Here `MASK_PHONE()` is a preset data desensitization function, which can use multiple desensitization algorithms, such as: Partial masking: replace the middle several digits of the phone number with asterisks, for example `138*1234`.

[0070] Complete replacement: replace the phone number with a virtual number or a placeholder, for example `13800000000` or `XXXXXXXXXXX`.

[0071] Encryption processing: use encryption algorithms to encrypt the phone number, only users with specific keys can decrypt it. For example, symmetric encryption algorithms such as AES, DES, or asymmetric encryption algorithms such as RSA can be used.

[0072] In addition, the data desensitization function can also use different desensitization strategies according to different security levels. For example, for ordinary employees, only partially masked phone numbers are displayed; for managers with higher permissions, complete phone numbers or decrypted phone numbers can be displayed. The use of which desensitization function and which specific desensitization strategy can be flexibly configured according to specific business needs and security requirements. These desensitization functions can be stored in the database, or encapsulated in the application code, or even implemented by calling external APIs.

[0073] In this way, sensitive data can be protected at the data source level, avoiding the risk of data leakage during transmission and processing. At the same time, since the desensitization operation is completed on the database server side rather than the application server side, the pressure on the application server can be effectively reduced, and the performance of the system can be improved. Using instruction rewriting to implement data desensitization can avoid any intrusive modifications to the existing database system, reducing implementation costs and risks.

[0074] By implementing this embodiment, first, compliance access to sensitive data is ensured, avoiding the risk of data leakage and meeting the strict data security requirements of the financial industry. Second, by desensitizing at the data source level, data transmission volume and server-side processing pressure are reduced, improving query performance. Finally, by flexibly configuring the desensitization strategy, data access requirements of different users and different scenarios can be met, improving the usability and flexibility of the system.

[0075] In some embodiments, the security monitoring process includes: analyzing the instruction structure of the final data query instruction before it is executed; When the instruction structure is identified as meeting the pre-set high-risk operation mode, the execution of the final data query instruction is aborted.

[0076] The security monitoring process of this embodiment aims to actively defend against potential security risks. This process analyzes the structure of the final data query instruction before execution and compares it with the pre-set high-risk operation mode, thereby achieving early warning and blocking of malicious queries. This parallel security monitoring mechanism does not passively wait for security incidents to occur before responding, but actively intervenes in the "pre-stage" of query execution, thereby eliminating security risks at the source.

[0077] Specifically, instruction structure analysis can be achieved using various technical means. For example, a SQL parser such as Apache Calcite can be used to parse SQL statements into an abstract syntax tree (AST), and then traverse the AST to identify key structures. The key structures to be identified can include but are not limited to: whether the SELECT statement contains a wildcard (*), whether the index column is missing in the WHERE clause, whether the number of JOIN operations is too large, and whether there are ORDER BY or GROUP BY operations, etc.

[0078] The high-risk operation mode can be a pre-defined rule set or an abnormal pattern learned from historical query logs through machine learning algorithms. For example, a common high-risk mode is full table scan, i.e. the query statement does not use any index, causing the database to scan the entire table to find matching data. Another high-risk mode is Cartesian product JOIN, i.e. there is no association condition between two tables, causing the result set to grow exponentially, severely consuming database resources. In addition, some high-risk modes based on user behavior can also be defined, such as frequent access to sensitive data in a short period of time, or launching a large number of queries during non-working hours, etc.

[0079] If the instruction structure analysis identifies that the query instruction conforms to the preset high-risk operation mode, the system will immediately suspend the execution of the instruction. The suspension operation can be implemented in various ways. For example, a KILLQUERY command can be sent to the database to forcibly terminate the query process. An error prompt can also be returned to the user, informing him that the query request is rejected and suggesting that he modify the query conditions to reduce the risk. In addition, the query instruction can also be recorded in the security log for subsequent analysis and auditing.

[0080] As an alternative embodiment, in addition to suspending the execution of the instruction, some other security measures can also be taken. For example, the query result can be limited to return only part of the data, or the sensitive data can be desensitized. The user's query behavior can also be monitored, and if it is found to be abnormal, the account can be locked or secondary identity verification can be required.

[0081] Through the above technical means, the embodiment can effectively defend against various potential security risks, such as SQL injection attacks, denial of service attacks, and data leakage. Compared with traditional passive security defense mechanisms, the embodiment can more actively identify and block malicious queries, thereby ensuring the security and stability of the bank risk monitoring system based on the ChatBI model. By performing security monitoring in parallel, real-time early warning and blocking of risks can be achieved without affecting normal business queries, thereby improving the overall security and availability of the system.

[0082] In some embodiments, the high-risk operation mode includes a full-data scan mode that requests access to data volume exceeding a preset threshold, or a multi-source data connection mode that has a complexity of data association operation exceeding a preset threshold. The embodiment of the present application aims to actively identify and prevent potential high-risk database operations by analyzing the structural characteristics of the query instruction, thereby improving the overall security of the system. The "high-risk operation mode" here refers to those operation types that can significantly affect the performance of the database server or can cause data leakage.

[0083] The full data scan mode refers to a query instruction lacking effective filter conditions such as a WHERE clause, causing the database system to read and process the entire data table. This mode of operation consumes a large amount of I / O resources and CPU resources, affecting the query performance of other users, and in high-concurrency scenarios, can cause the database service to crash. The preset threshold can be dynamically adjusted according to the hardware configuration of the database server, network bandwidth, and historical load data, for example, it can be set to 10% of the table data volume or a specific number of data records, and those skilled in the art can select according to the actual situation. Alternatively, the lack of effective filter conditions can be specifically manifested as the absence of a WHERE clause in the SQL statement, or the filter conditions in the WHERE clause do not use indexes, causing the database engine to be unable to quickly locate the target data. In order to avoid full table scanning, the system can require all queries to include filter conditions based on index fields. As an alternative implementation, if the user does indeed need to perform full table scanning, the system can perform degradation processing, such as reducing the query priority, limiting the available CPU resources, or assigning it to an offline analysis cluster for execution.

[0084] The multi-source data connection mode refers to a query instruction containing JOIN operations between multiple data tables, and the association conditions of the JOIN operations are complex and have large data volumes, causing the database system to need to perform a large amount of intermediate result calculation and data transmission. This mode of operation also consumes a large amount of system resources and can cause performance problems. The "preset threshold" can be measured by the number of JOIN tables, the complexity of the JOIN conditions, and the size of the intermediate result set, for example, it can be set to more than 3 JOIN tables, JOIN conditions containing multiple non-index fields, or an intermediate result set size exceeding 1 GB. Alternatively, the high complexity of the data association operation can be manifested as the use of functions or expressions in the JOIN conditions, causing the database engine to be unable to perform effective optimization. To solve this problem, the system can use the following strategies: limiting the JOIN operation, such as limiting the number of JOIN tables or prohibiting the use of functions or expressions in the JOIN conditions; rewriting the query, such as decomposing complex JOIN operations into multiple simple queries or using materialized views to precompute JOIN results; using a distributed query engine to distribute JOIN operations to multiple nodes for parallel execution.

[0085] Through the identification and blocking of the above risk modes, the consumption of database resources by invalid queries can be reduced while ensuring compliance, thereby improving the overall stability and response speed of the system. In addition, this mechanism can effectively prevent malicious attackers from using high-complexity queries to bring down the database service, thereby improving the security of the system.

[0086] In some embodiments, the method further comprises a parallel user behavior analysis process, which includes: recording the query frequency of the user account within a preset time window; when the query frequency exceeds a preset frequency threshold, suspending the subsequent query request processing of the user account and starting a secondary identity verification process.

[0087] The embodiments of the present application aim to actively identify and respond to potential malicious or abnormal query behavior, improving the overall security of the system. This process monitors the query behavior of the user account in real time to determine whether it conforms to the preset normal behavior pattern, thereby timely discovering and preventing abnormal behavior and preventing data leakage or abuse of system resources. Suspending the subsequent query request processing of the user account is not a mandatory step and can be selected for execution according to the actual application scenario and security requirements. Starting the secondary identity verification process is also not a mandatory step and can be selected for execution according to the actual situation.

[0088] Through the above-mentioned user behavior analysis process, the present application can effectively identify and respond to abnormal query behavior, prevent data leakage and abuse of system resources, and improve the overall security of the system. For example, if an account initiates a large number of queries in a short period of time, it may indicate that the account is engaged in malicious data crawling activities, and the system can timely suspend the query permission of the account to avoid a large amount of sensitive data being illegally obtained.

[0089] In some embodiments, executing the final data query instruction includes: decomposing the final data query instruction into a sub-query instruction for an internal data source and an API call request for an external data source; parallelly executing the sub-query instruction and the API call request.

[0090] The embodiments of the present application aim to improve data acquisition efficiency and coverage. A complex query task is decomposed into multiple parallelly executable sub-tasks for data acquisition from internal and external data sources, and finally integrated into a comprehensive risk monitoring result. The internal data source here usually refers to customer information, transaction records, risk ratings, etc. stored in the bank's own database; the external data source refers to third-party data obtained through API interface, such as credit reporting, public opinion information, and business information, etc.

[0091] This solution takes advantage of computer parallel processing, significantly shortens the data acquisition time by concurrently executing internal queries and external API calls, and can integrate multi-party data to provide more comprehensive and timely information support for risk monitoring.

[0092] By means of instruction decomposition and parallel execution, the scheme can make full use of computing resources, significantly improve data acquisition efficiency, and integrate internal and external multi-party data to provide more comprehensive and timely information support for risk monitoring. Compared with the serial execution mode, the query efficiency is improved by more than 30%, and more types of data sources can be accessed, improving the coverage of risk monitoring.

[0093] In some embodiments, after obtaining the bank risk monitoring data based on the ChatBI model, the method further comprises: According to the risk indicators in the bank risk monitoring data based on the ChatBI model, a structured report containing risk attribution analysis text is automatically generated and output on a display device.

[0094] The embodiments of the present application aim to solve how to present complex risk monitoring data to users in a more intuitive and understandable way to assist users in rapid and accurate risk assessment and decision-making. The technical principle is to organically integrate data information and knowledge information through pre-set report templates and rule engines, thereby improving information transmission efficiency and user experience.

[0095] Through the embodiments of the present application, complex risk monitoring data can be converted into information that is easy to understand and use, assisting users in risk assessment, decision-making and management. For example, customer managers can discover potential risk customers in a timely manner according to the risk report and take appropriate risk control measures; credit approval personnel can assess the credit status of enterprises according to the risk report and make reasonable credit decisions.

[0096] The technical means of automatically generating a structured report containing risk attribution analysis text can significantly improve the transmission efficiency of risk information and user experience. Compared with the traditional pure data display method, this technical solution can help users quickly understand the risk situation and potential impact, so as to make more intelligent decisions. Through the automatic report generation process, the workload of manual analysis and report writing can be reduced, and the work efficiency can be improved. Through customizable report templates, the needs of different users can be met, and personalized risk information services can be provided.

[0097] As shown in Figure 2 The embodiments of the present application provide a bank risk monitoring system based on a ChatBI model, which decomposes the bank risk monitoring process based on the ChatBI model into several independent and cooperatively working components through modular design, aiming to solve the problems of low human-computer interaction efficiency, difficult balance between data security and query performance, and passive security defense mechanism in the prior art.

[0098] Instruction receiving and parsing module M100: In the technical field, instruction receiving refers to receiving user input instructions, and parsing refers to converting received instructions into a form that machines can understand. In the present application, the module is responsible for receiving user input query instructions in natural language form, and using a preset ChatBI model, such as a large language model based on BERT, GPT, etc. Transformer architecture, and using financial domain corpus for fine-tuning to perform deep semantic parsing of the instruction. Semantic parsing includes steps such as word segmentation, part-of-speech tagging, named entity recognition, and dependency syntax analysis, aiming to identify the user's query intent and extract key query entities such as enterprise names, legal person names, and query conditions such as financial indicator constraints and regional restrictions, and finally generate a standardized, machine-readable structured data request such as a JSON object or XML document. ChatBI model can be a pre-trained general language model, or a specialized model fine-tuned for the financial domain, such as using financial research reports, credit documents, etc. corpus for training. The module is the first step to achieve convenient and natural human-computer interaction, which eliminates the interaction barriers between business personnel and data systems, allowing users without professional database query skills to easily obtain the required information.

[0099] Initial instruction generation module M200: In the technical field, initial instruction generation refers to generating instructions that can be processed by subsequent modules based on structured data requests. In the present application, the module receives the structured data request generated by the instruction receiving and parsing module M100, and generates an initial data query instruction according to the preset mapping rules, such as mapping business entities to the physical storage structure of the data source, such as mapping "enterprise name" to the `name` field of the database table `t_company`. The instruction is not in its final form, but embeds one or more pre-set "permission markers" or "placeholders" for subsequent permission instantiation in its logical structure. Permission markers can be comments in SQL statements such as ` / *PERMISSION_PLACEHOLDER* / `, special character sequences such as `@@PERMISSION_NODE@@`, or specific tags in XML / JSON documents. These markers do not affect the syntactic correctness of the instruction itself, but provide precise "anchor points" for subsequent dynamic modification. For example, the initial data query instruction can be a SQL query statement, where the `WHERE` clause contains a placeholder for subsequent injection of permission filtering conditions. Alternatively, the initial data query instruction can be an abstract syntax tree (AST) containing a special node representing permission control logic. The module provides a foundation for subsequent dynamic permission injection by reserving permission markers in the initial instruction.

[0100] Instruction rewriting module M300: In the technical field, instruction rewriting refers to modifying existing instructions according to specific rules. In the present application, this module is responsible for dynamically injecting the user's permission policy into the query instruction itself before sending the initial data query instruction to the data source for execution. This module first obtains the user account that initiates the query and its multi-dimensional permission policy configured in the permission center, such as role permissions, agency / region permissions, data sensitivity level permissions, etc. The permission policy can be stored in a centralized permission management system such as LDAP, Active Directory, or a database. Then, the module parses the permission policy and converts it into specific, executable data filtering conditions or data processing operations. For example, replace a data range marker with a specific `manager_id = 'user123'` condition, or modify an access request for a sensitive field to a request to call a desensitization function. Finally, the module locates the permission markers in the initial data query instruction and replaces or instantiates these markers with the specific filtering conditions or processing operations generated in the previous step. For example, replace a ` / *PERMISSION_PLACEHOLDER* / ` with `AND t_company.manager_id = 'user123'`, or modify a `SELECT customer_contact_phone` to `SELECT MASK_PHONE(customer_contact_phone)`. Instruction rewriting can be implemented through various technologies, such as regular expression-based text replacement, structured modification based on abstract syntax tree (AST), and code generation based on template engine. Through the above rewriting process, the module generates a final data query instruction that has internalized the user's permission logic as part of its own structure.

[0101] Instruction execution module M400: In the technical field, instruction execution refers to performing corresponding operations according to the logic of the instruction. In the present application, this module is responsible for executing the final data query instruction processed by the instruction rewriting module M300. Since all permission restrictions have been reflected at the instruction level, the data source such as a database will only access and return the smallest data subset that absolutely complies with permissions when executing, thereby avoiding the transmission and processing of redundant data from the root. This module can also call external APIs in parallel and fuse multi-party data to ultimately obtain comprehensive bank risk monitoring data based on the ChatBI model. Instruction execution module can be implemented through various technologies, such as direct execution of SQL queries, calling stored procedures, and executing MapReduce tasks. In order to improve query performance, this module can also use query optimization techniques such as index optimization, query rewriting, and parallel execution.

[0102] The bank risk monitoring system based on the ChatBI model provided by the embodiment of the application realizes the extreme ease of use of the query, greatly improves the business efficiency, innovatively solves the fundamental contradiction between safety and performance, constructs a multi-level and active intelligent security defense system, and improves the data support quality of risk decision-making.

[0103] In some embodiments, the instruction rewriting module M300 is specifically configured to: add a corresponding filter condition in the initial data query instruction according to a row-level permission rule in the permission policy for limiting the data record access range; and modify a direct access request for a specific data field in the initial data query instruction into a request for applying a preset data desensitization operation according to an access restriction rule for the specific data field in the permission policy.

[0104] The embodiment of the application aims to further improve the security and flexibility of data access by refining the implementation of the permission control policy. The module can not only limit the accessible data range of the user according to the role, institution and other information of the user, but also perform desensitization processing on sensitive data fields, thereby preventing the leakage of sensitive information on the premise of ensuring the availability of data. Among them, the row-level permission rule is implemented by adding a filter condition to ensure that the user can only access the data records within the permission range; and the column-level permission rule is implemented by modifying the data access mode, for example, replacing the operation of directly reading the sensitive field with the operation of calling the desensitization function to protect the sensitive data.

[0105] The instruction rewriting module M300 is configured to dynamically modify the initial data query instruction according to the permission policy, specifically in two aspects: Row-level permission control: The instruction rewriting module M300 will add corresponding filtering conditions to the initial data query instruction according to the row-level permission rules in the permission policy that are used to limit the access scope of data records. These filtering conditions can be defined based on multiple dimensions such as the role of the user account, the affiliated organization, and the geographical location. For example, for the account manager role, filtering conditions can be added so that they can only access the customer data they are responsible for; for users of a specific organization, filtering conditions can be added so that they can only access the data of that organization; for users in a specific geographical location, filtering conditions can be added so that they can only access the data in that geographical location. These filtering conditions usually appear as the `WHERE` clause in the SQL statement, such as `WHERE manager_id = 'user123'`, which is used to limit the query results to only include data records that meet the permissions. This filtering condition does not have to be an equal value comparison, and can also be in various forms such as range comparison, fuzzy matching, etc., such as `WHERE create_time BETWEEN '2023-01-01' AND '2023-12-31'`, or `WHERE company_name LIKE '%Huaxing%'`. In addition, the filtering conditions can be added by directly appending them to the `WHERE` clause of the SQL statement, or by modifying the filtering node in the logical query plan. This module also supports the overlay of multiple row-level permission rules. For example, if a user belongs to both the account manager role and a specific organization, then the role permissions and organization permissions need to be applied simultaneously to ensure that the user can only access data records that meet both permissions.

[0106] Column-level permission control: The instruction rewriting module M300 will also modify the direct access request for a specific data field in the initial data query instruction to a request for applying a preset data desensitization operation according to the access restriction rules for specific data fields in the permission policy. For example, for sensitive fields such as ID numbers and phone numbers, their direct reading operations can be replaced with operations that call desensitization functions, such as `MASK_ID(id_number)` or `MASK_PHONE(phone_number)`. These desensitization functions can adopt various desensitization algorithms, such as masking some characters, replacing characters, encryption, etc. In addition, the calling method of the desensitization function can be to directly replace the field name in the SQL statement, or to modify the projection node in the logical query plan. Column-level permission control is not limited to desensitization operations, and can also include operations such as data conversion and data aggregation, such as converting a date field to a year field, or aggregating the values of multiple fields into the value of one field.

[0107] By implementing the above row-level and column-level permission control strategies, the instruction rewriting module M300 can effectively protect sensitive data, prevent data leakage, and meet compliance requirements. Compared with the traditional post-filtering method, the present scheme realizes permission control at the data source level, avoiding the transmission of unauthorized data to the application server, thereby improving the security and performance of the system. At the same time, the present scheme also has high flexibility, and can dynamically adjust the permission control strategy according to different user roles, institutions and data fields, to adapt to the changing business requirements.

[0108] In some embodiments, the system further comprises: A security monitoring module connected with the instruction rewriting module M300 and the instruction execution module, configured to analyze the instruction structure of the final data query instruction before it is executed, and when it is identified that the instruction structure meets the pre-set high-risk operation mode, the execution of the final data query instruction is aborted.

[0109] In the embodiments of the present application, the security monitoring module serves as a proactive defense mechanism, which analyzes the instruction structure and evaluates its potential risks before execution, thereby effectively preventing malicious or erroneous queries from causing damage to the system and improving the overall security of the system. The module is connected with the instruction rewriting module M300 and the instruction execution module, ensuring that security monitoring can be performed at each stage of instruction execution. When it is identified that the instruction structure meets the pre-set high-risk operation mode, the execution of the final data query instruction is aborted, thereby minimizing potential risks.

[0110] Specifically, the high-risk operation mode can include but is not limited to: Full table scan: refers to a query operation that needs to access the entire table in the database without proper indexes or filter conditions. Such operation will consume a large amount of database I / O resources and affect system performance. For example, if a SQL query statement lacks an effective WHERE clause, resulting in a full table scan on a large customer information table such as the `customer_info` table, it is determined as a high-risk operation mode. To deal with the risk of full table scan, the security monitoring module can be set to abort execution, or suggest the user to add more precise filter conditions, such as specifying the query time range, customer type, etc.

[0111] Multi-table join query: refers to a query operation that needs to access multiple tables simultaneously and associate their data. If the number of associated tables is too large or the association conditions are unreasonable, it will cause a sharp decline in query performance, and even cause the database to crash. For example, if a SQL query statement involves JOIN operations on more than three tables, and no suitable indexes are used, it is determined as a high-risk operation mode. As an alternative, the system can suggest the user to optimize the query statement, use fewer tables for association, or use pre-computed materialized views to speed up the query.

[0112] High-frequency recursive query: Some data with complex hierarchical relationships, such as organizational structure trees and fund flow, may require recursive queries to obtain complete data. However, too deep recursive queries can easily consume database resources and cause system death. The security monitoring module can limit the maximum depth of recursive queries, for example, limit to no more than 5 layers.

[0113] Statement containing fuzzy query: LIKE operation or regular expression matching usually reduces query efficiency, especially in high concurrency environment. The use of fuzzy matching can be limited, for example, only allow fuzzy matching for specific fields such as customer name, and limit the character length of fuzzy matching.

[0114] Cross-database or cross-data center query: This kind of query needs to consume a lot of network resources and may introduce additional security risks. For cross-database queries, the types of databases allowed to access and the amount of data can be limited; for cross-data center queries, access permissions should be strictly controlled and encrypted transmission should be performed.

[0115] The criteria for determining these high-risk operation modes can be adjusted according to actual application scenarios, such as adjusting the data volume threshold for full table scan and the upper limit of the number of tables for multi-table join query. In addition, the security monitoring module can also work with other security modules such as intrusion detection systems and firewalls to jointly build a multi-level security defense system.

[0116] By adopting the security monitoring module, the potential risks caused by malicious or erroneous query operations on the bank risk monitoring system based on ChatBI model can be effectively reduced, ensuring the security of the system while maintaining its stable operation. At the same time, by limiting unnecessary resource consumption, the overall performance of the system is improved.

[0117] In some embodiments, the instruction execution module is specifically configured to: decompose the final data query instruction into sub-query instructions for internal data sources and API call requests for external data sources; execute the sub-query instructions and API call requests in parallel, and fuse the returned data results.

[0118] In the embodiments of the present application, the instruction execution module is the key component for data query and integration. It decomposes the final data query instruction after permission control into multiple sub-tasks, coordinates the query operations of internal and external data sources, and finally fuses the results to provide comprehensive risk monitoring data. Decomposing instructions embodies the idea of "divide and conquer", which can break down complex query tasks into parallel executable sub-tasks to improve efficiency. Fusing data aims to break down information silos and integrate internal and external data to provide a more comprehensive perspective for risk assessment.

[0119] Internal data sources, such as relational databases like MySQL, Oracle, PostgreSQL, NoSQL databases like MongoDB, Cassandra, or big data platforms like Hadoop, Spark, are used to store customer information, transaction records, risk assessment results, and other data within the bank. External data sources, such as third-party credit investigation agencies, industry associations, and government open data platforms, provide enterprise business information, credit ratings, public opinion information, and other data through API interfaces. API call requests can be implemented using RESTful API, GraphQL API, or SOAP API technologies.

[0120] Through instruction decomposition, parallel execution, and data fusion, the instruction execution module can fully utilize computing resources, shorten query response time, and provide comprehensive risk monitoring data, thereby improving the efficiency and accuracy of risk decision-making.

[0121] The above is a further detailed description of the present application in combination with specific preferred embodiments, and cannot be considered as limiting the specific implementation of the present application to these descriptions. For ordinary skilled persons in the technical field to which the present application belongs, without departing from the concept of the present application, a number of simple deductions or substitutions can be made, which should be considered as falling within the protection scope of the present application.

Claims

1. A bank risk monitoring method based on a ChatBI model, characterized in that, The method comprises: receiving a natural language query instruction input by a computer device; performing semantic analysis on the natural language query instruction based on a preset ChatBI model to generate a structured data request containing query entities and query conditions; generating an initial data query instruction containing a preset permission marker according to the structured data request; before executing the initial data query instruction, obtaining a permission policy associated with a user account initiating the query, and modifying the initial data query instruction according to the permission policy to generate a final data query instruction; executing the final data query instruction by a computer processor to obtain bank risk monitoring data based on the ChatBI model.

2. The method of claim 1, wherein, The semantic analysis further comprises: when the natural language query instruction contains colloquial or non-standardized entity expressions, performing entity linking on the entity expressions using a preset financial knowledge graph to identify corresponding standardized entities.

3. The method according to claim 1 or 2, characterized in that, The initial data query instruction is a logical query plan, and the preset permission marker is a filter node to be instantiated in the logical query plan.

4. The method of claim 1, wherein, The modification of the initial data query instruction according to the permission policy comprises: converting row-level permission rules in the permission policy for limiting data record access range into one or more specific filter conditions; using the one or more specific filter conditions to replace or instantiate the preset permission marker in the initial data query instruction.

5. The method of claim 4, wherein, The row-level permission rules are defined based on at least one of the role of the user account, the institution to which the user account belongs, or the geographic region information of the user account.

6. The method of claim 1, wherein, The modification of the initial data query instruction according to the permission policy further comprises: identifying data fields requested to be accessed in the initial data query instruction; when the permission policy contains access restriction rules for specific data fields, modifying the access mode of the specific data fields in the initial data query instruction.

7. The method of claim 6, wherein, The modification of the access mode of the specific data fields in the initial data query instruction comprises: replacing a direct read request for the specific data fields with a request to apply a preset data desensitization function to the specific data fields.

8. The method of claim 1, wherein, The method further comprises a parallel security monitoring process, which comprises: analyzing the instruction structure of the final data query instruction before it is executed; when it is identified that the instruction structure satisfies a preset high-risk operation mode, the execution of the final data query instruction is aborted.

9. The method of claim 8, wherein, The high-risk operation mode includes a full-data scanning mode requesting access to data exceeding a preset threshold, or a multi-source data connection mode with a complexity exceeding a preset threshold. 10.A bank risk monitoring system based on a ChatBI model, characterized in that, The method comprises: an instruction receiving and analyzing module configured to receive a natural language query instruction input by a computer device, and perform semantic analysis on the instruction based on a preset ChatBI model to generate a structured data request; an initial instruction generating module connected with the instruction receiving and analyzing module and configured to generate an initial data query instruction containing a preset permission marker according to the structured data request; The instruction rewriting module is connected with the initial instruction generation module and is configured to, before execution of the initial data query instruction, acquire a permission policy associated with a user account initiating a query, and modify the initial data query instruction according to the permission policy to generate a final data query instruction. The instruction execution module is connected with the instruction rewriting module and is configured to execute the final data query instruction by a computer processor to acquire bank risk monitoring data based on a ChatBI model.

Images