Intelligent SQL Statement Auditing and Risk Warning Methods for Financial Business

Abstract

This invention discloses a method for intelligent SQL statement review and risk warning in financial business, belonging to the field of intelligent review technology for financial business. It includes the following steps: Step 1, defining the core risk types and quantitative review dimensions of financial SQL; Step 2, constructing a full-dimensional perception module to collect multi-source data related to the SQL to be reviewed. The multi-source data includes at least SQL statement data, database operating environment data, financial business rule data, regulatory compliance data, and historical SQL execution log data. This invention maps the elements of the financial SQL review scenario into four categories: SQL, risk, compliance, and business. It combines a connection weight algorithm to quantify the correlation strength between these elements, constructing a virtual social network to achieve collaborative judgment across multiple risk dimensions. This covers four core risk categories: sensitive data, compliance authorization, business logic, and performance overload, avoiding the one-sidedness of traditional static rules.

Description

Technical Field

[0001] This invention relates to the field of intelligent auditing technology for financial transactions, and in particular to a method for intelligent auditing and risk warning of SQL statements used in financial transactions. Background Technology

[0002] In financial operations, SQL statements serve as the core carrier of data access and manipulation. Their execution security, compliance, and rationality directly impact the protection of sensitive customer data, the correctness of financial business logic, and the stability of the database system. The auditing and risk warning requirements for SQL statements in the financial sector significantly differ from those in ordinary IT scenarios. They not only need to cover basic issues such as syntax errors but also focus on preventing core risks such as sensitive data leakage, unauthorized access, business calculation errors, and performance overload. Simultaneously, they must strictly comply with regulatory requirements for financial data security and compliant operations.

[0003] Current mainstream methods for auditing and risk warning of financial SQL statements have significant technical limitations:

[0004] The audit logic is static: it relies heavily on preset static rules for matching, such as sensitive field keyword screening and permission whitelist verification. It cannot handle complex SQL operations that are dynamically generated, and is prone to missed or false judgments of risks. It is especially difficult to identify hidden errors at the business logic level.

[0005] One-sided risk assessment: Most methods focus only on a single risk dimension and ignore the correlation and transmission between different risks, resulting in incomplete risk assessment and failure to reflect the actual scenario of multiple risks overlapping in financial business.

[0006] Early warning lacks foresight: Traditional methods are mostly post-event audits, that is, risks are discovered through log analysis after the SQL statement is executed. It is impossible to predict potential harm before execution. If the SQL triggers performance overload or data leakage, it will cause irreversible losses such as database crashes and leakage of customer information.

[0007] Inefficient risk identification and tracing: After a risk is discovered, it is necessary to manually check the SQL statement structure, related tables and permission configuration one by one, which makes it difficult to quickly locate the core risk cause; at the same time, there is no automatic association with historical risk cases and regulatory compliance provisions, which requires auditors to consult a lot of additional information, resulting in low audit efficiency and inconsistent judgment standards due to differences in manual operation.

[0008] Insufficient adaptability and evolutionary capacity: When financial business scenarios expand, regulatory rules are updated, or database architecture is upgraded, the review rules need to be rewritten or adjusted manually, and cannot be automatically adapted to the changes, resulting in the review system becoming disconnected from business development.

[0009] The aforementioned technical deficiencies make it difficult for existing methods to meet the core requirements of the financial sector for high-precision, comprehensive, forward-looking, and traceable SQL auditing. There is an urgent need for an intelligent auditing and risk warning solution that can integrate the advantages of multiple technical fields and has dynamic collaboration and self-evolution capabilities. Summary of the Invention

[0010] To address the aforementioned technical problems, this invention provides a method for intelligent auditing and risk warning of SQL statements in financial transactions. The technical solution adopted is as follows:

[0011] The method for intelligent auditing and risk warning of SQL statements used in financial business includes the following steps:

[0012] Step 1: Define the core risk types and quantitative review dimensions for financial SQL;

[0013] Step 2: Construct a full-dimensional perception module to collect multi-source data related to the SQL to be reviewed. The multi-source data includes at least SQL statement data, database operating environment data, financial business rule data, regulatory compliance data, and historical SQL execution log data.

[0014] Step 3: Based on the multi-source data collected in Step 2, construct a digital twin corresponding to the real financial database environment;

[0015] Step 4: Map the elements of the financial SQL review scenario to individual elements in the social neurodynamics model, define the attributes of each individual element, and construct a virtual social network through a connection weight calculation algorithm;

[0016] Step 5: The improved excitation-inhibition balance model is run in the digital twin constructed in step 3 as the core of social neurodynamics calculation. The individual state of the element is iteratively updated with the individual attribute of the element as the input current until the change of the state of all individual elements is less than the preset convergence threshold. The converged SQL individual state value is extracted and the risk level is divided according to the SQL individual state value.

[0017] Step 6: Trace the interaction trajectory of individual elements within the digital twin in Step 5, locate the core risk points, generate an early warning report including risk level, core risk points, related compliance clauses, and historical similar risk cases, and complete the review and output of early warning results.

[0018] Optionally, risk types include sensitive data risk, compliance authorization risk, business logic risk, and performance overload risk;

[0019] The review dimensions include access to sensitive data, permission matching, business logic accuracy, and performance consumption, and specific thresholds for financial scenarios are set for each review dimension.

[0020] Optionally, step 7 is also included, which involves classifying and processing SQL execution requests in a real financial environment according to the risk level of the audit in step 5; at the same time, collecting the actual results after SQL execution as feedback data, and using the feedback data to correct the individual connection weights and iteration parameters of the elements in the social neural dynamics model.

[0021] Step 8: Build a global consensus and memory bank to categorize and store historical audit cases; synchronize new compliance rules with the regulatory platform every month to update the individual attributes of compliance elements; train the social neural dynamics model with feedback data from the past three months every quarter; and upgrade the digital twin architecture every year to adapt to new database types, so as to achieve continuous evolution of audit and early warning capabilities.

[0022] Optionally, the data collection methods of the full-dimensional perception module in step 2 include: deploying lightweight probes on application servers and database servers to capture SQL execution flow, connecting to the open APIs of financial business systems and database auditing tools to synchronize structured data, and automatically supplementing historical logs that were not collected in real time the previous day at midnight every day.

[0023] Optionally, step 4, which involves building a virtual social network, includes the following sub-steps:

[0024] Step 41, define the element individuals: SQL individual, risk individual, compliance individual, business individual;

[0025] Step 42, define the individual attributes of each element as follows: SQL individual attributes include syntax integrity S1, number of sensitive fields accessed S2, permission requirement level S3, estimated execution time S4, and business affiliation tag S5;

[0026] Individual risk attributes include risk trigger probability R1, risk impact level R2, and risk association strength R3;

[0027] Compliance attributes include rule matching degree C1, rule priority C2, and rule application scope C3;

[0028] Individual business attributes include business sensitivity B1 and historical risk coefficient B2;

[0029] Step 43, establish association rules between individuals: SQL individuals and risk individuals trigger directed association based on attribute matching and historical case matching; SQL individuals and compliance individuals trigger directed association based on rule engine matching; SQL individuals and business individuals trigger undirected association based on business metadata matching; risk individuals and compliance individuals trigger directed association based on the correspondence of regulatory documents.

[0030] Step 44, Calculate connection weights: First, calculate the basic weights of each associated combination using the basic weight formula, and then adjust them by introducing the business priority correction term Corr1 and the historical risk coefficient correction term Corr2.

[0031] Step 45: A directed weighted graph is used to construct the topology, which is stored in a dual structure of adjacency matrix and adjacency list. The network timeliness is maintained by daily recalculation of attributes and weights and timed updates and event-driven updates.

[0032] Optionally, in step 44, the basic weights of the SQL individual and the risk individual association combination. The calculation formula is:

[0033] ;

[0034] The basic weight of the association between SQL individuals and compliant individuals The calculation formula is:

[0035] ;

[0036] The basic weight of the association between SQL entities and business entities The calculation formula is:

[0037] ;

[0038] The basic weight of the combination of risky individuals and compliant individuals The calculation formula is:

[0039] ;

[0040] in It is the strength of the risk association. , and These are the attributes corresponding to individual SQL statements; It is the rule matching degree. It refers to rule priority; S.S5 is the business affiliation label; It's about business acumen; This refers to the scope of application of the rules;

[0041] The formulas for calculating the business priority adjustment terms Corr1 and Corr2 are:

[0042] P represents business priority;

[0043] ; Historical risk coefficient for individual business units;

[0044] The final weighting formula is:

[0045] ;

[0046] in It is the final weight of the association combination between the i-th element and the j-th element. It is the basic weight of the association combination between the i-th element individual and the j-th element individual.

[0047] Optionally, in step 5, the core iterative formula of the excitation-inhibition balance model is:

[0048] ;

[0049] in Let be the state value of the i-th element at time t. Let be the connection weight between the i-th element individual and the j-th excitation source element individual. Let J be the output intensity of the j-th excitation source element individual. Let be the connection weight between the i-th serious individual and the k-th suppressive source element individual. The output intensity of the k-th individual suppressing source element. This is the iteration step size.

[0050] Optionally, in step 5, the specific method for classifying risk levels based on individual SQL status values ​​includes the following steps:

[0051] Determine the basic interval for the SQL individual state values: based on the converged state values ​​of the SQL individuals. Using these as core indicators, a basic risk level classification range is established;

[0052] when When the risk is low, it means that the probability of the SQL statement triggering core financial risks is less than 30%, and it meets more than 90% of the compliance rules and business logic requirements.

[0053] when When the risk level is determined to be medium, it means that the probability of the SQL statement triggering the core financial risk is ≥30% and <80%, or there are 1-2 non-veto-type compliance rules that are not met.

[0054] when When an SQL statement is deemed high-risk, it indicates that the probability of it triggering core financial risks is ≥80%, or that it violates at least one veto-type compliance rule, and therefore it must be directly blocked.

[0055] Optionally, in step 6, the method for tracing the individual interaction trajectories of elements within the digital twin is:

[0056] First, collect and store interaction logs: During the excitation-inhibition balance model iteration in step 5, collect the interaction logs of all individual elements in the digital twin simultaneously. The logs must include the following core elements: interaction subject information, interaction process data, related iteration information, time axis dimension, and weight intensity dimension.

[0057] Re-visualize and reconstruct the interaction trajectory: Based on the collected interaction logs, the trajectory is reconstructed through a time-series weighted two-dimensional visualization model.

[0058] Optionally, in step 6, the quantitative positioning of core risk points includes screening of high-impact risk individuals: extracting risk individuals that directly interact with the SQL individual from the high-impact interaction links, with the screening criteria being: interaction weight and the increase in the SQL individual's status value after the interaction, to obtain a set of candidate risk individuals;

[0059] For the set of candidate risk individuals, the risk contribution ratio algorithm is used to quantify the degree of influence of each risk individual on the final state value of the SQL individual;

[0060] The core risk point is determined as follows: if the risk contribution of a certain individual is greater than or equal to 50%, then the risk type corresponding to that individual is the unique core risk point.

[0061] If the risk contribution of all risk individuals is less than 50%, but the sum of the risk contribution of two or more risk individuals is greater than or equal to 70%, then the risk type corresponding to these risk individuals is a joint core risk point, and the primary and secondary relationships are marked in descending order of risk contribution percentage; the triggering factors of the core risk point are recorded simultaneously.

[0062] In summary, the present invention has at least one of the following beneficial technical effects:

[0063] This invention provides an intelligent SQL statement review and risk warning method for financial business. By mapping the elements of financial SQL review scenarios into four categories of elements—SQL, risk, compliance, and business—and combining a connection weight algorithm to quantify the correlation strength between these elements, a virtual social network is constructed to achieve collaborative judgment across multiple risk dimensions. This covers four core risk categories: sensitive data, compliance authorization, business logic, and performance overload, avoiding the one-sidedness of traditional static rules and meeting the multi-dimensional review needs of financial business.

[0064] By replicating the real financial database environment using digital twins, SQL execution risks are iteratively simulated in the virtual environment through an improved excitation-inhibition balance model. Individual SQL state values ​​can be calculated and risk levels can be classified in advance without actual execution, shifting from post-event remediation to pre-event prevention, effectively avoiding losses such as database failures and data leaks that may be caused by SQL execution.

[0065] By collecting all individual element interaction logs and visually reconstructing interaction trajectories, combined with a risk contribution ratio algorithm, we can accurately locate single or combined core risk points and triggering factors, replacing traditional manual investigation. At the same time, we can automatically associate compliance clauses with similar historical cases, reduce manual operations by auditors, unify judgment standards, and significantly improve the efficiency of risk tracing and compliance verification.

[0066] By correcting model parameters and individual element connection weights through feedback data, regularly synchronizing regulatory rules, training social neural dynamics models, and upgrading the digital twin architecture, it can automatically adapt to new financial business scenarios, database types, and regulatory requirements, maintain high audit accuracy in the long term, and ensure that the audit system evolves in sync with the development of financial business.

[0067] The solution classifies risk levels based on specific thresholds for financial scenarios, identifies core risk points in relation to regulatory compliance clauses, stores and reuses historical cases to meet regulatory requirements for risk tracing, and ensures that SQL auditing and risk warnings comply with financial industry regulatory standards throughout the process, thereby reducing the risk of compliance penalties. Attached Figure Description

[0068] Figure 1 This is a flowchart illustrating the intelligent SQL statement review and risk warning method for financial business according to the present invention. Detailed Implementation

[0069] The present invention will be further described in detail below with reference to the accompanying drawings.

[0070] This invention discloses a method for intelligent auditing and risk warning of SQL statements used in financial business.

[0071] Reference Figure 1 Example 1, a method for intelligent auditing and risk warning of SQL statements for financial business, includes the following steps:

[0072] Step 1: Define the core risk types and quantitative review dimensions for financial SQL;

[0073] Step 2: Construct a full-dimensional perception module to collect multi-source data related to the SQL to be reviewed. The multi-source data includes at least SQL statement data, database operating environment data, financial business rule data, regulatory compliance data, and historical SQL execution log data.

[0074] Step 3: Based on the multi-source data collected in Step 2, construct a digital twin corresponding to the real financial database environment;

[0075] Step 4: Map the elements of the financial SQL review scenario to individual elements in the social neurodynamics model, define the attributes of each individual element, and construct a virtual social network through a connection weight calculation algorithm;

[0076] Step 5: The improved excitation-inhibition balance model is run in the digital twin constructed in step 3 as the core of social neurodynamics calculation. The individual state of the element is iteratively updated with the individual attribute of the element as the input current until the change of the state of all individual elements is less than the preset convergence threshold. The converged SQL individual state value is extracted and the risk level is divided according to the SQL individual state value.

[0077] Step 6: Trace the interaction trajectory of individual elements within the digital twin in Step 5, locate the core risk points, generate an early warning report including risk level, core risk points, related compliance clauses, and historical similar risk cases, and complete the review and output of early warning results.

[0078] Example 2: Risk types include sensitive data risk, compliance authorization risk, business logic risk, and performance overload risk;

[0079] The review dimensions include access to sensitive data, permission matching, business logic accuracy, and performance consumption, and specific thresholds for financial scenarios are set for each review dimension.

[0080] Example 3 also includes step 7, which involves classifying SQL execution requests in a real financial environment according to the risk level of the audit in step 5; at the same time, collecting the actual results after SQL execution as feedback data, and using the feedback data to correct the individual connection weights and iteration parameters of the elements in the social neural dynamics model.

[0081] Step 8: Build a global consensus and memory bank to categorize and store historical audit cases; synchronize new compliance rules with the regulatory platform every month to update the individual attributes of compliance elements; train the social neural dynamics model with feedback data from the past three months every quarter; and upgrade the digital twin architecture every year to adapt to new database types, so as to achieve continuous evolution of audit and early warning capabilities.

[0082] Example 4, the data collection method of the full-dimensional perception module in step 2 includes: deploying lightweight probes on application servers and database servers to capture SQL execution flow, connecting to the open API of financial business systems and database auditing tools to synchronize structured data, and automatically supplementing historical logs that were not collected in real time the previous day at midnight every day.

[0083] By adopting the above technical solution, the audit benchmark is first clarified, defining four core risks: sensitive data, compliance authorization, business logic, and performance overload, as well as quantitative audit dimensions such as the degree of access to sensitive data and the degree of permission matching, and setting specific thresholds for financial scenarios. Then, through the full-dimensional perception module, multi-source data such as SQL statements, database environment, business rules, regulatory compliance, and historical execution logs are collected by means of capturing SQL execution flow with probes, synchronizing business and audit data with APIs, and log completion, providing a foundation for subsequent analysis.

[0084] Based on the collected data, a digital twin consistent with the real financial database is constructed to reproduce the real operating environment. Then, the elements of the review scenario are mapped to four categories of elements: SQL, risk, compliance, and business. Individual attributes are defined, and a virtual social network is constructed according to association rules and weight calculation algorithms to quantify the influence strength between individuals.

[0085] Within the digital twin, an improved excitation-inhibition balance model is run to iteratively update the individual's state, using the individual's attributes as input. Once the state change is less than the convergence threshold, the SQL individual state value is extracted and classified into low, medium, and high risk levels according to a preset range. Then, the individual's interaction trajectory is traced to locate the core risk points and generate an early warning report containing the risk level, core risk points, related compliance clauses, and historical cases, thus completing the review and early warning output.

[0086] In addition, real SQL execution requests are processed in a graded manner according to risk level, and real results are collected as feedback data to correct model parameters and individual weights; at the same time, a memory bank is built to store historical cases, and regulatory rules are regularly synchronized to update compliance attributes, train models, and upgrade the twin architecture to achieve continuous evolution of audit and early warning capabilities.

[0087] Example 5, step 4 of constructing a virtual social network includes the following sub-steps:

[0088] Step 41, define the element individuals: SQL individual, risk individual, compliance individual, business individual;

[0089] Step 42, define the individual attributes of each element as follows: SQL individual attributes include syntax integrity S1, number of sensitive fields accessed S2, permission requirement level S3, estimated execution time S4, and business affiliation tag S5;

[0090] Individual risk attributes include risk trigger probability R1, risk impact level R2, and risk association strength R3;

[0091] Compliance attributes include rule matching degree C1, rule priority C2, and rule application scope C3;

[0092] Individual business attributes include business sensitivity B1 and historical risk coefficient B2;

[0093] Step 43, establish association rules between individuals: SQL individuals and risk individuals trigger directed association based on attribute matching and historical case matching; SQL individuals and compliance individuals trigger directed association based on rule engine matching; SQL individuals and business individuals trigger undirected association based on business metadata matching; risk individuals and compliance individuals trigger directed association based on the correspondence of regulatory documents.

[0094] Step 44, Calculate connection weights: First, calculate the basic weights of each associated combination using the basic weight formula, and then adjust them by introducing the business priority correction term Corr1 and the historical risk coefficient correction term Corr2.

[0095] Step 45: A directed weighted graph is used to construct the topology, which is stored in a dual structure of adjacency matrix and adjacency list. The network timeliness is maintained by daily recalculation of attributes and weights and timed updates and event-driven updates.

[0096] By adopting the above technical solution, the core of constructing a virtual social network is to transform the dispersed participating elements in the financial SQL review scenario into quantifiable and interactive network nodes and relationships, forming a structured system that reflects the intensity of influence between various elements, and providing an accurate interactive model for subsequent risk simulation. The specific principle is as follows:

[0097] First, the basic network nodes are defined by defining four types of elements: SQL individuals, risk individuals, compliance individuals, and business individuals, covering the core participants in the entire SQL review process.

[0098] Next, each node is assigned computable attribute characteristics. By defining attributes such as the syntactic integrity and the number of sensitive fields accessed for SQL individuals, the structure and requirements of the SQL itself are quantified; by defining attributes such as the trigger probability and impact level for risk individuals, the likelihood and severity of risk occurrence are quantified; by defining attributes such as the rule matching degree and priority for compliance individuals, the constraint strength and scope of application of rules are quantified; and by defining attributes such as the sensitivity and historical risk coefficient for business individuals, the risk tolerance and historical experience of business scenarios are quantified. These attributes provide data basis for subsequent calculations of the correlation and interaction strength between nodes.

[0099] Then, establish the association logic between nodes, and set association rules based on the actual role of each element in the audit scenario: the association between SQL and risk needs to be combined with the current attribute matching degree and historical case verification to ensure the accuracy of risk association; the association between SQL and compliance needs to be strictly matched through the rule engine to ensure the seriousness of compliance constraints; the association between SQL and business needs to be determined based on business metadata to ensure the accuracy of scenario adaptation; the association between risk and compliance needs to refer to regulatory documents to clarify the corresponding relationship to ensure the correspondence between risk and constraint; at the same time, the direction of influence is reflected through directed association (such as the one-way influence of risk on SQL) and the two-way adaptation is reflected through undirected association (such as the mutual matching of SQL and business), so that the association relationship conforms to the actual business logic.

[0100] Next, the interaction strength between nodes is quantified. First, the initial strength of each association combination is calculated using the basic weight formula to reflect the inherent influence at the attribute level. Then, a business priority correction term is introduced to enhance the sensitivity of associations in core business scenarios. A historical risk coefficient correction term is introduced to strengthen the association strength in high-frequency risk scenarios. Through dual correction, the weights can reflect both inherent attributes and adapt to business priorities and historical experience, ensuring that the quantitative results of interaction strength are in line with the actual needs of financial business.

[0101] Finally, the network topology is constructed to ensure timeliness. A directed weighted graph is used to represent the directional and strength relationships between nodes. Adjacency matrices enable fast weight lookups, and adjacency lists enable efficient interactive traversal, balancing query and computation efficiency. At the same time, attributes and weights are recalculated daily to ensure that the network updates with daily data changes. Event-driven updates (such as adding rules or business changes) ensure that the network can quickly respond to sudden adjustments, maintaining the timeliness of the network structure and attributes, and providing a dynamic and accurate interactive model for risk simulation within the digital twin.

[0102] Example 6, step 44: the basic weight of the SQL individual and the risk individual association combination. The calculation formula is:

[0103] ;

[0104] The basic weight of the association between SQL individuals and compliant individuals The calculation formula is:

[0105] ;

[0106] The basic weight of the association between SQL entities and business entities The calculation formula is:

[0107] ;

[0108] The basic weight of the combination of risky individuals and compliant individuals The calculation formula is:

[0109] ;

[0110] in It is the strength of the risk association. , and These are the attributes corresponding to individual SQL statements; It is the rule matching degree. It refers to rule priority; S.S5 is the business affiliation label; It's about business acumen; This refers to the scope of application of the rules;

[0111] The formulas for calculating the business priority adjustment terms Corr1 and Corr2 are:

[0112] P represents business priority;

[0113] ; Historical risk coefficient for individual business units;

[0114] The final weighting formula is:

[0115] ;

[0116] in It is the final weight of the association combination between the i-th element and the j-th element. It is the basic weight of the association combination between the i-th element individual and the j-th element individual.

[0117] By adopting the above technical solution, the design of the basic weight formula revolves around the core correlation logic between individual attributes and related scenarios. Through mathematical operations between attributes, qualitative correlations are transformed into quantitative weight values, ensuring that the basic strength of each correlation combination conforms to the actual review logic.

[0118] The fundamental weights of SQL instances and risk instances are based on the risk association strength (Rj.R3) as the core coefficient, multiplied by the weighted sum of the attributes directly related to risk triggering within the SQL instance (sensitive field access count S.S2, permission requirement level S.S3, estimated execution time S.S4). The logic behind this design is that the strength of the association between risk and SQL depends not only on the basic correlation between the risk and the SQL, but also on the performance of the SQL in risk-sensitive dimensions such as sensitive data access, permission requirements, and performance consumption.

[0119] The basic weights for SQL and compliance individuals are calculated by directly multiplying the rule matching degree (Ck.C1) and rule priority (Ck.C2) of the compliance individual. The logic is that the strength of the association between compliance and SQL depends primarily on the degree to which the SQL meets the compliance rules and the enforcement level of those compliance rules.

[0120] The basic weights for SQL entities and business entities are calculated by multiplying the business affiliation label (S.S5) of the SQL entity by the business sensitivity (Bm.B1) of the business entity. The logic is that the strength of the association between SQL and business is first determined by whether the SQL belongs to the business scenario (S.S5=1 if the association is established, =0 if the association is not established), and then adjusted by the risk sensitivity of the business scenario.

[0121] The basic weights for risk-prone and compliant entities are directly based on the applicable rules for compliant entities (Ck.C3). The logic is that the relationship between risk and compliance is essentially about the coverage of risk by compliance rules.

[0122] The purpose of the correction items (Corr1, Corr2) is to adapt the basic weights to the priority differences and historical risk experience of financial businesses, and to avoid the weights being limited to individual attributes while ignoring the actual needs of the business scenario.

[0123] Business priority adjustment item (Corr1): Calculated using the formula (1 + 0.2 × P) (where P is the business priority). The logic is: there are clear priority differences in financial businesses.

[0124] Historical risk coefficient correction term (Corr2): Calculated using the formula (1 + 0.3 × Bm.B2) (where Bm.B2 is the historical risk coefficient for the individual business). The logic is: historical risk experience is an important basis for risk control.

[0125] The final weighting formula, calculated by multiplying the base weight by Corr1 and Corr2, integrates the inherent correlation strength determined by individual attributes with the requirements of two scenarios: business priority and historical risk experience. The core logic of this design is that the final correlation strength must simultaneously satisfy both individual attribute matching and business scenario adaptation.

[0126] In Example 7, step 5, the core iterative formula of the excitation-inhibition balance model is:

[0127] ;

[0128] in Let be the state value of the i-th element at time t. Let be the connection weight between the i-th element individual and the j-th excitation source element individual. Let J be the output intensity of the j-th excitation source element individual. Let be the connection weight between the i-th serious individual and the k-th suppressive source element individual. The output intensity of the k-th individual suppressing source element. This is the iteration step size.

[0129] By adopting the above technical solution, the core of this model is to simulate the dynamic interaction logic of individual elements in a financial SQL review scenario: through the dynamic balance of excitation sources (risk individuals) driving the state upward and inhibition sources (compliance individuals) constraining the state downward, the real-time state of individual elements is iteratively calculated, and finally converges to obtain a state value that reflects the true risk level of the SQL, providing a dynamic quantitative basis for risk level determination. The specific principle is as follows:

[0130] The formula uses the current state value of the i-th element. Starting from point A, calculate the state value at the next time step. The core logic is that the state of an individual element is not fixed, but changes continuously with its interaction with other individuals. The excitatory effect of a risky individual will improve its state, while the inhibitory effect of a compliant individual will decrease its state. Through successive iterations, this dynamic interaction process is simulated until the state tends to stabilize (converge), ensuring that the final state value can truly reflect the actual situation of the individual under multiple interactions.

[0131] in the formula This represents the total excitation contribution of all individual excitation source elements to the i-th individual, and its design logic aligns with the actual pattern of risk escalation in financial scenarios:

[0132] This reflects the degree of connection between the two; if the connection weight between the SQL individual and a certain risk individual is higher, it indicates that the risk has a stronger impact on the SQL, and the transmission efficiency of its excitatory effect is also higher.

[0133] This reflects the risk-management ability of the individual; for example, individuals with a high probability of risk triggering and a high level of impact. A larger value has a stronger exciting and driving effect on individual SQL statements.

[0134] Summation operation Σ: Since an SQL individual may be affected by multiple risk individuals at the same time (such as simultaneous access to sensitive data or insufficient permissions), the excitation effects of all risk individuals need to be summed to obtain the total excitation contribution, ensuring that the impact of multiple risk superpositions is not missed.

[0135] in the formula This represents the total inhibitory contribution of all individual source elements (i.e., compliant individuals) to the i-th individual. Its design logic corresponds to the constraint law of compliance reducing risk in financial scenarios:

[0136] This reflects the strength of the constraint imposed by the compliant individual on the i-th individual. If the connection weight between the SQL individual and a certain compliant individual is higher, it indicates that the compliant rule imposes a stricter constraint on the SQL, and the transmission efficiency of the inhibition effect is higher.

[0137] This reflects the self-restraint of a compliant individual; for example, compliant individuals with high rule compliance and high priority. A larger value results in a stronger inhibitory and constraining effect on individual SQL statements.

[0138] Summation operation Σ: SQL entities may be subject to multiple compliance rules simultaneously. The inhibitory effects of all compliant entities need to be summed to obtain the total inhibitory contribution, ensuring a comprehensive reflection of the impact of multiple compliance constraints.

[0139] in the formula It is the net change between the total excitation contribution and the total inhibition contribution. Its meaning is: if the net change is positive, it means that the driving force of risk exceeds the constraint of compliance, and the state of the i-th individual will rise (such as the SQL risk level increases); if it is negative, it means that the compliance constraint is dominant, and the state will fall (such as the SQL risk level decreases); if it is close to zero, the state tends to be stable.

[0140] The iteration step size Δt controls the magnitude of state changes in each iteration: too large a Δt leads to drastic state fluctuations, making it difficult to converge to a stable value; too small a Δt results in too many iterations and low efficiency. In financial SQL auditing scenarios, Δt is typically set to around 0.1, ensuring smooth and controllable state changes in each iteration while achieving convergence within a reasonable number of iterations (e.g., within 100), thus balancing stability and auditing efficiency.

[0141] In actual financial SQL auditing, the core focus is on the SQL individual: in each iteration, the state value S_SQL(t) of the SQL individual will be dynamically adjusted under the excitation effect of risk individuals and the inhibition effect of compliance individuals until the state change of all individuals (including risk, compliance, and business individuals) is less than the convergence threshold. At this time, the final state value S_SQL of the SQL individual can accurately quantify its risk level, providing an objective and dynamic quantitative basis for subsequent risk level classification based on state value, avoiding the one-sidedness of traditional static rule judgment.

[0142] Example 8, step 5, the specific method for classifying risk levels based on SQL individual status values ​​includes the following steps:

[0143] Determine the basic interval for the SQL individual state values: based on the converged state values ​​of the SQL individuals. Using these as core indicators, a basic risk level classification range is established;

[0144] when When the risk is low, it means that the probability of the SQL statement triggering core financial risks is less than 30%, and it meets more than 90% of the compliance rules and business logic requirements.

[0145] when When the risk level is determined to be medium, it means that the probability of the SQL statement triggering the core financial risk is ≥30% and <80%, or there are 1-2 non-veto-type compliance rules that are not met.

[0146] when When an SQL statement is deemed high-risk, it indicates that the probability of it triggering core financial risks is ≥80%, or that it violates at least one veto-type compliance rule, and therefore it must be directly blocked.

[0147] By adopting the above technical solution, the core of this method is to establish a direct correspondence between the converged SQL individual state value and the actual financial risk level and compliance satisfaction. By transforming the 0-1 quantitative range of the state value into a gradient risk level range, the objective and quantifiable judgment of the risk level can be achieved.

[0148] The convergence state value of an SQL individual is the final result of the excitation-inhibition balance model iteration in step 5. Its value range of 0-1 essentially reflects the dynamic balance between the excitation effect of risk and the inhibition effect of compliance: the lower the state value, the stronger the compliance inhibition and the weaker the excitation effect of risk, resulting in a lower risk level for the SQL; conversely, the higher the state value, the stronger the excitation effect of risk and the weaker the inhibition effect of compliance, resulting in a higher risk level for the SQL. Based on this physical meaning, the state value is divided into three gradient intervals, each directly corresponding to a specific risk probability and compliance satisfaction, ensuring that the division logic is consistent with the state value generation logic.

[0149] When the SQL individual status value is in the range of 0-0.3, it indicates that the compliance inhibition effect is significantly stronger than the risk excitation effect, specifically corresponding to two core characteristics:

[0150] From a risk probability perspective: a low state value directly reflects that the probability of SQL triggering core financial risks is less than 30%. This is because the state value is the result of the sum of the output intensity (risk trigger probability, impact level) of risk individuals and the connection weights. A low state value means that the total excitation contribution of risk individuals to SQL is much less than the total inhibition contribution of compliant individuals. The possibility of risk occurring is greatly suppressed, hence the risk probability is at a low level.

[0151] In terms of compliance satisfaction: This range corresponds to meeting more than 90% of compliance rules and business logic requirements. Since compliant individuals are the core source of the inhibitory effect, a compliance rule satisfaction rate of more than 90% means that the output strength (rule matching degree, priority) of most compliant individuals is at a high level, and their inhibitory effect on SQL is fully exerted, thereby lowering the SQL individual status value, forming a positive correlation of high compliance satisfaction → low status value → low risk.

[0152] When the SQL individual status value is in the range of 0.3-0.8, it indicates that the risk-excitement effect and the compliance-inhibition effect are in a relatively balanced state, and no single effect has an absolute advantage, corresponding to two core characteristics:

[0153] From a risk probability perspective: the probability of the middle value of the state value triggering core financial risks by SQL is ≥30% and <80%. At this point, the excitation contribution of risky individuals and the inhibition contribution of compliant individuals are not much different. The risk is neither completely suppressed nor out of control, and is in an intermediate state that requires attention but is not urgent.

[0154] In terms of compliance satisfaction: This range corresponds to 1-2 non-veto-level compliance rules that are not met. Non-veto-level compliance rules have lower priority, and their non-compliance only leads to a decrease in local suppression contribution, without causing an overall collapse of the suppression effect. Therefore, the status value only rises to the middle range, rather than directly surging. If a veto-level compliance rule is not met, its high priority will cause a sharp drop in suppression contribution, and the status value will directly exceed 0.8. Therefore, the medium-risk range explicitly excludes veto-level violations.

[0155] When the SQL individual status value is in the range of 0.8-1, it indicates that the risk-excitement effect is much stronger than the compliance-inhibition effect, or that the compliance-inhibition effect is ineffective due to the breach of key rules, corresponding to two core characteristics:

[0156] From a risk probability perspective: a high value in the state indicates that the probability of SQL triggering core financial risks is ≥80%. At this point, the excitatory contribution of risky individuals is absolutely dominant, and the inhibitory contribution of compliant individuals is difficult to offset, indicating that the risk level of SQL has reached an extremely high level of harm.

[0157] In terms of compliance satisfaction: This range corresponds to a violation of at least one veto-type compliance rule. Veto-type compliance rules are the bottom line requirements for financial compliance, and their priority is extremely high. Once violated, the inhibitory output strength of the compliance entity will plummet to 0, resulting in a significant reduction in the overall inhibitory contribution. The risk-excitement effect will instantly take absolute advantage, and the status value will soar directly to above 0.8. Such violations are extremely harmful and therefore must be directly intercepted to prevent actual risks from occurring.

[0158] The entire risk level classification method achieves quantified and standardized risk level determination through a three-layered correlation of state value quantification range, risk probability gradient, and compliance rule severity. This avoids the bias of risk judgment that relies solely on subjective experience, and through the special adaptation of veto-type compliance rules, it meets the core requirement of zero tolerance for bottom-line risks in the financial sector. It ensures that the judgment result of each risk level can directly guide the subsequent graded processing of SQL execution, forming a closed loop from state value calculation to risk prevention and control actions.

[0159] Example 9, in step 6, the method for tracing the interaction trajectory of individual elements within a digital twin is:

[0160] First, collect and store interaction logs: During the excitation-inhibition balance model iteration in step 5, collect the interaction logs of all individual elements in the digital twin simultaneously. The logs must include the following core elements: interaction subject information, interaction process data, related iteration information, time axis dimension, and weight intensity dimension.

[0161] Re-visualize and reconstruct the interaction trajectory: Based on the collected interaction logs, the trajectory is reconstructed through a time-series weighted two-dimensional visualization model.

[0162] In Example 10, step 6, the core risk point quantification and positioning includes high-impact risk individual screening: extracting risk individuals that directly interact with the SQL individual from the high-impact interaction link, with the screening criteria being: interaction weight and the increase in the SQL individual's status value after the interaction, to obtain a set of candidate risk individuals;

[0163] For the set of candidate risk individuals, the risk contribution ratio algorithm is used to quantify the degree of influence of each risk individual on the final state value of the SQL individual;

[0164] The core risk point is determined as follows: if the risk contribution of a certain individual is greater than or equal to 50%, then the risk type corresponding to that individual is the unique core risk point.

[0165] If the risk contribution of all risk individuals is less than 50%, but the sum of the risk contribution of two or more risk individuals is greater than or equal to 70%, then the risk type corresponding to these risk individuals is a joint core risk point, and the primary and secondary relationships are marked in descending order of risk contribution percentage; the triggering factors of the core risk point are recorded simultaneously.

[0166] By adopting the above technical solution, firstly, during the iterative process of the excitation-inhibition balance model, the interaction logs of all individual elements are collected synchronously. By recording the interaction subject (the individual participating in the interaction), process data (interaction weights, state changes), iteration information (round number, convergence progress), timeline (interaction sequence), and weight strength (influence magnitude), it is ensured that no interaction process is missed, and complete data is retained for subsequent traceability. Then, based on the collected logs, a visualization model is constructed using two dimensions: time sequence (showing state changes by iteration round) and weight (marking key interactions by influence strength). This transforms the abstract interaction data into an intuitive trajectory chart, clearly presenting the interaction influence process of each individual on the SQL individual, which facilitates the rapid identification of key interaction links.

[0167] The core of this solution is to accurately pinpoint the core risk points that dominate SQL risks by screening key risk sources, quantifying the degree of impact, and clarifying judgment rules, thus avoiding vague or subjective risk identification. First, from the high-impact interaction links identified through visualization, risk individuals that directly interact with the SQL entity are extracted. A set of candidate risk individuals is obtained based on the interaction weight (ensuring close correlation) and the significant increase in the SQL state after the interaction (ensuring effective impact), excluding irrelevant or weakly influential risk individuals. Next, a risk contribution ratio algorithm is used to quantify the total impact of each candidate risk individual on the final SQL state value, transforming qualitative impact into quantitative percentage data. Finally, core risk points are determined based on contribution ratio: risk individuals with a contribution ratio ≥ 50% are considered unique core risk points; multiple risk individuals with a combined contribution ratio ≥ 70% are considered joint core risk points, marked with primary and secondary indicators, and their triggering causes are recorded to ensure accurate and quantifiable identification of core risk points and to clearly identify the root cause of the risk.

[0168] The following specific embodiments illustrate the implementation principle of the present invention:

[0169] Step 1: Define the risk and audit dimensions:

[0170] The core risk types are defined as risk trigger probability (R1), compliance authorization risk (R2), business logic risk (R3), and performance overload risk (R4); the audit dimensions are set as sensitive data access degree (threshold ≤ 0.3), permission matching degree (threshold ≥ 0.9), business logic correctness rate (threshold ≥ 0.95), and performance consumption degree (threshold ≤ 0.5), all of which are suitable for retail bank account query scenarios.

[0171] Step 2: Full-Dimensional Sensing and Data Acquisition

[0172] The full-dimensional sensing module collects multi-source data in the following ways:

[0173] SQL statement data: The collected SQL statement is SELECT customer_id, id_card, balance FROM customer_account WHERE account_no='6226001234567890' AND query_date BETWEEN'2024-01-01' AND'2024-01-30'. The syntax is complete and involves two sensitive fields (id_card and balance).

[0174] Database operating environment data: The current database CPU utilization is 35%, the number of connections is 80, and the query account permission is that of a regular counter staff member, who is only allowed to query customer accounts under their jurisdiction;

[0175] Financial business rules data: Account balance queries must desensitize the id_card field, and the query results must include information about the branch to which the account belongs;

[0176] Regulatory compliance data: The Personal Financial Information Protection Law stipulates that sensitive customer information must be anonymized when accessed; internal compliance rules prohibit counter staff from accessing customer accounts across jurisdictions.

[0177] Historical SQL execution log data: The average execution time of similar SQL queries in the past 3 months was 0.8 seconds. There were 2 instances where sensitive data risk warnings were triggered due to failure to anonymize the data.

[0178] Step 3: Digital Twin Construction

[0179] A digital twin, built on a 1:1 scale with the bank's core database, was constructed based on the collected data.

[0180] Structural twin: replicates the customer_account table structure, including fields such as customer_id, id_card, balance, account_no, branch_code, etc., with index configuration consistent with the real database;

[0181] State twin: Synchronize the anonymized customer data, with the id_card field anonymized to 622******1234, and the balance field retains the original value to ensure calculation consistency. The current database CPU and connection count status are synchronized to the twin.

[0182] Rule twinning: Transform "id_card needs to be desensitized" and "counter post jurisdiction limit query" into virtual constraints;

[0183] Historical Twin: Stores execution logs and risk records of SQL queries for similar accounts over the past 12 months.

[0184] Step 4: Building a Virtual Social Network

[0185] Element individual definitions: SQL individual (SQL query pending review), risk individuals R1-R4, compliance individuals C1 (regulatory anonymization rules) and C2 (internal permission rules), and business individual B1 (retail bank account query scenario).

[0186] Individual attribute assignments: SQL individual S1=1 (syntactic complete), S2=0.6 (involves 2 sensitive fields, total 3 sensitive fields), S3=0.6 (requires normal query privileges), S4=0.4 (estimated execution time 0.4 seconds, tolerable execution time 1 second), S5=1 (belongs to B1); R1's R1=0.3 (historical trigger probability 30%), R2=0.8 (high impact level), R3=0.7 (high association strength with SQL); C1's C1=0 (not desensitized, low rule matching degree), C2=1 (desensitization rule is high priority), C3=1 (applicable to all account query scenarios); B1's B1=0.3 (low business sensitivity), B2=0.2 (low historical risk coefficient);

[0187] Association rule triggers: SQL and R1 are associated because S2=0.6>0.3 and there are similar risk cases in the past; SQL and C1 are associated because the anonymization rules are not met; SQL and B1 are associated undirected because they belong to the retail banking scenario; R1 and C1 are associated because the anonymization rules in the regulatory documents are corresponding.

[0188] Connection weight calculation: SQL and R1 have a base weight of 0.4, which is adjusted by the business priority adjustment item (P=1, Corr1=1.2) and the historical risk coefficient adjustment item (B2=0.2, Corr2=1.06) to a final weight of 0.42; SQL and C1 have a base weight of 0.5, which is adjusted to a final weight of 0.53.

[0189] Topology and Updates: A directed weighted graph is used to construct the topology. The adjacency matrix records SQL with a weight of 0.42 and R1 with a weight of 0.53. The weights are recalculated every day at midnight. If a new de-identification rule is added, an event-driven update is triggered.

[0190] Step 5: Iteration of the excitation-inhibition balance model and risk level classification:

[0191] Running an improved excitation-inhibition balance model within a digital twin:

[0192] Iterative process: Using the SQL individual attributes as input current, R1 as the excitation source with an output intensity of 0.7, and C1 as the inhibition source with an output intensity of 0.5, after 15 iterations, the change in the state of all individuals is less than 0.01, and the process converges to a steady state.

[0193] Risk level classification: After convergence, the individual SQL status value is 0.65, which is in the range of 0.3-0.8, and is judged as medium risk. The probability of triggering the core financial risk is 55%. There is one non-veto compliance rule that is not met (not anonymized).

[0194] Step 6: Interactive trajectory tracking and early warning report generation:

[0195] Interaction trajectory tracing: Interaction logs were collected, recording that the interaction weight between SQL and R1 in the 8th iteration was 0.42, causing the SQL state value to rise from 0.5 to 0.58; the interaction weight between SQL and C1 in the 12th iteration was 0.53, causing the SQL state value to drop from 0.68 to 0.65; the visualization timeline showed that the SQL state value gradually increased to 0.65 with each iteration, and the heatmap marked SQL and R1 as high-impact interaction links;

[0196] Core risk point identification: Candidate risk individuals R1 and R2 were selected. R1 contributed 45% and R2 contributed 27%, with the sum of the two being 72%, which were determined to be the joint core risk points. The primary and secondary relationship is R1 (sensitive data risk) and R2 (compliance authorization risk). The triggering factor is that the SQL involved unmasked sensitive fields and the queried account did not verify the customer's jurisdiction.

[0197] Early warning report generation: The report includes a medium risk level, joint core risk points, related compliance clauses (Article 15 of the Personal Financial Information Protection Law and Article 8 of the Internal Access Control Regulations), and similar historical cases (an early warning and handling result of a counter SQL query that was not anonymized 3 months ago). The review and early warning output are completed.

[0198] Step 7: Hierarchical processing and model correction

[0199] Tiered processing: Medium-risk SQL queries are pushed to the bank's data security experts for review. The experts determined that the id_card de-identification function needs to be added and that jurisdictional attribution verification conditions need to be added.

[0200] Feedback and Correction: Collect expert review opinions and the corrected SQL execution results (risk-free) as feedback data, correct the connection weight between SQL and C1 to 0.7, and adjust the E / I model iteration step size to 0.08.

[0201] Step 8: The system continues to evolve.

[0202] Storage memory: The cases reviewed this time (including SQL statements, weight data, and warning reports) are categorized and stored in the global consensus and storage memory;

[0203] Regular updates: In the current month, synchronize newly added customer information protection rules with the regulatory authorities and update the C1 attribute; in the next quarter, use feedback data from the past 3 months to train the E / I model; at the end of the year, upgrade the digital twin architecture to adapt to the newly added distributed database.

[0204] The above are all preferred embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Therefore, all equivalent changes made in accordance with the structure, shape and principle of the present invention should be covered within the scope of protection of the present invention.

Claims

1. A method for intelligent auditing and risk warning of SQL statements used in financial business, characterized in that, Includes the following steps: Step 1: Define the core risk types and quantitative review dimensions for financial SQL; Step 2: Construct a full-dimensional perception module to collect multi-source data related to the SQL to be reviewed. The multi-source data includes at least SQL statement data, database operating environment data, financial business rule data, regulatory compliance data, and historical SQL execution log data. Step 3: Based on the multi-source data collected in Step 2, construct a digital twin corresponding to the real financial database environment; Step 4: Map the elements of the financial SQL review scenario to individual elements in the social neurodynamics model, define the attributes of each individual element, and construct a virtual social network through a connection weight calculation algorithm; Step 5: The improved excitation-inhibition balance model is run in the digital twin constructed in step 3 as the core of social neurodynamics calculation. The individual state of the element is iteratively updated with the individual attribute of the element as the input current until the change of the state of all individual elements is less than the preset convergence threshold. The converged SQL individual state value is extracted and the risk level is divided according to the SQL individual state value. Step 6: Trace the interaction trajectory of individual elements within the digital twin in Step 5, locate the core risk points, generate an early warning report including risk level, core risk points, related compliance clauses, and historical similar risk cases, and complete the review and output of early warning results.

2. The method for intelligent auditing and risk warning of SQL statements for financial business according to claim 1, characterized in that, Risk types include sensitive data risk, compliance and authorization risk, business logic risk, and performance overload risk; The review dimensions include access to sensitive data, permission matching, business logic accuracy, and performance consumption, and specific thresholds for financial scenarios are set for each review dimension.

3. The method for intelligent auditing and risk warning of SQL statements for financial business according to claim 2, characterized in that, It also includes step 7, which classifies and processes SQL execution requests in the real financial environment according to the risk level of the audit in step 5; at the same time, it collects the real results after SQL execution as feedback data and uses the feedback data to correct the individual connection weights and iteration parameters of the elements in the social neural dynamics model. Step 8: Build a global consensus and memory bank to categorize and store historical audit cases; synchronize new compliance rules with the regulatory platform every month to update the individual attributes of compliance elements; train the social neural dynamics model with feedback data from the past three months every quarter; and upgrade the digital twin architecture every year to adapt to new database types, so as to achieve continuous evolution of audit and early warning capabilities.

4. The method for intelligent auditing and risk warning of SQL statements for financial business according to claim 3, characterized in that, The data collection methods of the full-dimensional perception module in step 2 include: deploying lightweight probes on application servers and database servers to capture SQL execution flow, connecting to the open APIs of financial business systems and database auditing tools to synchronize structured data, and automatically supplementing historical logs that were not collected in real time the previous day at midnight every day.

5. The method for intelligent auditing and risk warning of SQL statements for financial business according to claim 4, characterized in that: Step 4, building a virtual social network, includes the following sub-steps: Step 41, define the element individuals: SQL individual, risk individual, compliance individual, business individual; Step 42, define the individual attributes of each element as follows: SQL individual attributes include syntax integrity S1, number of sensitive fields accessed S2, permission requirement level S3, estimated execution time S4, and business affiliation tag S5; Individual risk attributes include risk trigger probability R1, risk impact level R2, and risk association strength R3; Compliance attributes include rule matching degree C1, rule priority C2, and rule application scope C3; Individual business attributes include business sensitivity B1 and historical risk coefficient B2; Step 43, establish association rules between individuals: SQL individuals and risk individuals trigger directed association based on attribute matching and historical case matching; SQL individuals and compliance individuals trigger directed association based on rule engine matching; SQL individuals and business individuals trigger undirected association based on business metadata matching; risk individuals and compliance individuals trigger directed association based on the correspondence of regulatory documents. Step 44, Calculate connection weights: First, calculate the basic weights of each associated combination using the basic weight formula, and then adjust them by introducing the business priority correction term Corr1 and the historical risk coefficient correction term Corr2. Step 45: A directed weighted graph is used to construct the topology, which is stored in a dual structure of adjacency matrix and adjacency list. The network timeliness is maintained by daily recalculation of attributes and weights and timed updates and event-driven updates.

6. The method for intelligent auditing and risk warning of SQL statements for financial business according to claim 5, characterized in that: In step 44, the basic weights of the SQL individual and the risk individual association combination. The calculation formula is: ； The basic weight of the association between SQL individuals and compliant individuals The calculation formula is: ； The basic weight of the association between SQL entities and business entities The calculation formula is: ； The basic weight of the combination of risky individuals and compliant individuals The calculation formula is: ； in It is the strength of the risk association. , and These are the attributes corresponding to individual SQL statements; It is the rule matching degree. It's about rule priority; S.S5 is a business attribution label; It's about business acumen; This refers to the scope of application of the rules; The formulas for calculating the business priority adjustment terms Corr1 and Corr2 are: P represents business priority; ; Historical risk coefficient for individual business units; The final weighting formula is: ； in It is the final weight of the association combination between the i-th element and the j-th element. It is the basic weight of the association combination between the i-th element individual and the j-th element individual.

7. The method for intelligent auditing and risk warning of SQL statements for financial business according to claim 6, characterized in that: In step 5, the core iterative formula of the excitation-inhibition balance model is: ； in Let be the state value of the i-th element at time t. Let be the connection weight between the i-th element individual and the j-th excitation source element individual. Let J be the output intensity of the j-th excitation source element individual. Let be the connection weight between the i-th serious individual and the k-th suppressive source element individual. The output intensity of the k-th individual suppressing source element. This is the iteration step size.

8. The method for intelligent auditing and risk warning of SQL statements for financial business according to claim 7, characterized in that: Step 5, the specific method for classifying risk levels based on individual SQL status values ​​includes the following steps: Determine the basic interval for the SQL individual state values: based on the converged state values ​​of the SQL individuals. Using these as core indicators, a basic risk level classification range is established; when When the risk level is low, it means that the probability of the SQL statement triggering core financial risks is less than 30%, and it meets more than 90% of the compliance rules and business logic requirements. when When the risk level is determined to be medium, it means that the probability of the SQL statement triggering the core financial risk is ≥30% and <80%, or there are 1-2 non-veto-type compliance rules that are not met. when When an SQL statement is deemed high-risk, it indicates that the probability of it triggering core financial risks is ≥80%, or that it violates at least one veto-type compliance rule, and therefore it must be directly blocked.

9. The method for intelligent auditing and risk warning of SQL statements for financial business according to claim 8, characterized in that: In step 6, the method for tracing the interaction trajectory of individual elements within the digital twin is as follows: First, collect and store interaction logs: During the excitation-inhibition balance model iteration in step 5, collect the interaction logs of all individual elements in the digital twin simultaneously. The logs must include the following core elements: interaction subject information, interaction process data, related iteration information, time axis dimension, and weight intensity dimension. Re-visualize and reconstruct the interaction trajectory: Based on the collected interaction logs, the trajectory is reconstructed through a time-series weighted two-dimensional visualization model.

10. The method for intelligent auditing and risk warning of SQL statements for financial business according to claim 9, characterized in that: In step 6, the quantitative positioning of core risk points includes the screening of high-impact risk individuals: extracting risk individuals that directly interact with the SQL individual from the high-impact interaction links. The screening criteria are: interaction weight and the increase in the SQL individual's status value after the interaction, to obtain a set of candidate risk individuals. For the set of candidate risk individuals, the risk contribution ratio algorithm is used to quantify the degree of influence of each risk individual on the final state value of the SQL individual; The core risk point is determined as follows: if the risk contribution of a certain individual is greater than or equal to 50%, then the risk type corresponding to that individual is the unique core risk point. If the risk contribution of all risk individuals is less than 50%, but the sum of the risk contribution of two or more risk individuals is greater than or equal to 70%, then the risk type corresponding to these risk individuals is the joint core risk point, and the primary and secondary relationships are marked in descending order of risk contribution percentage. Simultaneously record the triggering factors of core risk points.

Images