Internal control process management methods, devices, storage media and terminals

Abstract

This specification discloses an internal control process management method, device, storage medium, and terminal. First, it utilizes natural language processing and other technologies to parse regulatory documents into a structured knowledge graph, transforming textual elements into computable entities and relationships, thus solving the underlying problem of machine-readable regulations. Second, based on the knowledge graph, an executable logical rule set is generated through a rule engine, and a dynamic mapping is established between this set and multiple service processes, achieving decoupling between rules and processes and improving the system's agility in responding to changes. Finally, when a target service process is executed, the corresponding rules and knowledge graph are dynamically invoked based on the mapping relationship to identify compliance risks, achieving timely in-process control and related risk analysis. This solution achieves dynamic collaboration and risk management of regulations, rules, and processes through knowledge-driven approaches.

Description

Technical Field

[0001] The embodiments in this specification relate to the field of computer technology, and in particular to an internal control process management method, apparatus, storage medium, and terminal. Background Technology

[0002] In the management of operational workflows, core challenges commonly exist, including a disconnect between policy documents and execution processes, lagging control, data silos, and system rigidity. Policies rely on manual interpretation and execution, which is prone to bias; supervision is primarily based on post-event audits, failing to achieve real-time intervention; data is scattered across various systems, lacking the ability to perform correlation analysis; and traditional technical solutions struggle to respond nimbly to changes. Particularly in certain scenarios, the tight coupling of rules and processes in traditional workflow systems leads to high change costs; independent monitoring platforms cannot effectively prevent abnormal events from occurring in real time; and fragmented control modules result in inconsistent standards and difficulties in collaboration. The inability to achieve dynamic alignment between policies and processes, real-time risk perception, and system self-optimization fundamentally hinders the improvement of organizational compliance and risk control capabilities. Summary of the Invention

[0003] This specification provides an internal control process management method, device, storage medium, and terminal, which can solve the technical problem of the inability of systems and service processes to coordinate in related technologies.

[0004] Firstly, embodiments of this specification provide an internal control process management method, which includes: The input specification document is structured and parsed to generate a knowledge graph corresponding to the specification document. The knowledge graph uses the document elements in the specification document as entities and the relationships between entities as edges. Based on the knowledge graph mentioned above, a set of logical rules containing at least one executable logical rule is generated, and a dynamic mapping relationship between the set of logical rules and multiple service processes is established. When a target service process is detected to be in execution, the target executable logic rules corresponding to the target service process are invoked according to the above dynamic mapping relationship, and the above knowledge graph is invoked to identify compliance risks of the target service process.

[0005] In one possible implementation, the above-mentioned structured parsing of the input specification document to generate a knowledge graph corresponding to the specification document includes: performing natural language processing on the specification document to identify and extract entity elements and relation elements in the specification document; associating the extracted entity elements with at least one actual service data to construct a knowledge graph that integrates the specification document and the actual service.

[0006] In one possible implementation, the above-mentioned generation of a set of logical rules containing at least one executable logical rule based on the knowledge graph includes: generating at least one executable logical rule based on the knowledge graph, performing service association reasoning on each executable logical rule, so as to construct a composite rule chain of executable logical rules belonging to the same service scenario.

[0007] In one possible implementation, establishing the dynamic mapping relationship between the above-mentioned set of logical rules and multiple service processes includes: embedding each executable logical rule in the above-mentioned set of logical rules into each execution node of the corresponding service process in the form of service calls.

[0008] In one possible implementation, the above-mentioned compliance risk identification of the target service process includes: based on the target executable logic rules and the knowledge graph, performing graph computation analysis on the entities appearing in the target service process to identify the associated risk transmission paths and abnormal behavior patterns related to the target service process.

[0009] In one possible implementation, the method further includes: if a compliance risk is identified, determining the risk node where the compliance risk is located based on the knowledge graph, and automatically triggering the risk control operation corresponding to the risk node according to a preset handling strategy.

[0010] In one possible implementation, the above method further includes: continuously collecting process data on compliance risk identification and handling; generating an internal control assessment report based on the process data and analyzing it; and adaptively adjusting the entity relationships in the knowledge graph or the rules in the logical rule set according to the analysis conclusions.

[0011] In one possible implementation, the method further includes: adaptively adjusting the entity relationships in the knowledge graph or the rules in the logical rule set based on historical risk identification results and service environment feedback information.

[0012] Secondly, embodiments of this specification provide an internal control process management device, which includes: The knowledge graph construction module is used to perform structured parsing on the input standard documents and generate the knowledge graph corresponding to the standard documents. The knowledge graph uses the document elements in the standard documents as entities and the relationships between entities as edges. The control logic generation module is used to generate a set of logic rules containing at least one executable logic rule based on the knowledge graph mentioned above, and to establish a dynamic mapping relationship between the set of logic rules and multiple service processes. The process risk awareness module is used to identify compliance risks of a target service process when a target service process is detected to be in operation, based on the aforementioned dynamic mapping relationship, by invoking the target executable logic rules corresponding to the target service process and the aforementioned knowledge graph.

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

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

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

[0016] The beneficial effects of the technical solutions provided in some embodiments of this specification include at least the following: This specification provides an internal control process management method that performs structured parsing of input standard documents to generate a knowledge graph corresponding to the standard documents. The knowledge graph uses document elements in the standard documents as entities and the relationships between entities as edges. Based on the knowledge graph, a set of logical rules containing at least one executable logical rule is generated, and a dynamic mapping relationship is established between the set of logical rules and multiple service processes. When a target service process is detected being executed, the target executable logical rule corresponding to the target service process is called according to the dynamic mapping relationship, and the knowledge graph is also called to identify compliance risks in the target service process. Firstly, by introducing technologies such as natural language processing, key concepts, subjects, conditions, behaviors, and other elements in the text are automatically identified and abstracted into entities. The logical, causal, and hierarchical relationships between entities are abstracted into edges, thereby constructing a structured knowledge graph network. This transformation process maps human-readable institutional norms into machine-operable knowledge models, laying a data foundation for subsequent automated processing. Based on the completed knowledge graph, a set of logical rules containing at least one executable logical rule is generated. A dynamic mapping relationship is established between this set of logical rules and multiple service processes. This operation transforms static knowledge into dynamic control logic, ensuring that this logic can flexibly apply to specific service processes. This decouples rules from processes, improving system flexibility and maintainability while guaranteeing consistency of internal control standards. Ultimately, when a specific service flow instance runs, the system can automatically trigger the set of rules related to that process node through the pre-established dynamic mapping relationship, and make a comprehensive judgment based on the rich contextual information provided by the knowledge graph. This real-time internal control risk prevention enables timely compliance checks and risk warnings when service operations occur, effectively preventing violations and achieving real-time, automated, and intelligent risk control, significantly improving the depth and breadth of system risk perception. Attached Figure Description

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

[0018] Figure 1 An exemplary system architecture diagram of an internal control process management method provided in the embodiments of this specification; Figure 2 A flowchart illustrating an internal control process management method provided in an embodiment of this specification; Figure 3 A flowchart illustrating an internal control process management method provided in another embodiment of this specification; Figure 4 A flowchart illustrating an internal control process management method provided in yet another embodiment of this specification; Figure 5 A structural block diagram of an internal control process management device provided in the embodiments of this specification; Figure 6 This is a schematic diagram of the structure of a terminal provided in an embodiment of this specification. Detailed Implementation

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

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

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

[0022] In large organizations, especially those heavily reliant on institutionalized and process-oriented operations, ensuring a high degree of consistency between internal management systems and daily service execution processes is a core foundation for guaranteeing operational compliance, controlling risks, and improving efficiency. Currently, several challenges exist in this area. First, systems often exist statically in document form, relying on manual interpretation and operation by employees. This leads to inconsistent understanding, arbitrary execution, and key control points being bypassed or distorted in service processes, creating significant blind spots and operational risks. Second, control methods are severely outdated. Traditional supervision methods primarily rely on periodic audits, spot checks, and manual reports, meaning that by the time problems are discovered, service impacts have already occurred. Furthermore, checks based on limited samples cannot achieve full coverage, resulting in low efficiency and accuracy in control. In addition, data and systems are often difficult to coordinate. Data, events, and permission information related to system implementation are scattered across numerous independent service systems, lacking a unified data view and correlation analysis capabilities. This makes it difficult for management to gain a penetrating understanding of cross-departmental and cross-process compliance status and associated risks, leading to biased risk assessments and ineffective coordination of control measures. Furthermore, the contradiction between external compliance pressures and internal agility requirements is becoming increasingly acute. Regulatory requirements are becoming stricter and more dynamic, while traditional rigid process systems cannot respond quickly to policy updates, resulting in high compliance costs and slow response times.

[0023] Taking the typical scenario of online banking operations as an example, the above problems are particularly specific and severe. Core service processes of banks, such as credit approval, transactions, and account opening, are all subject to strict internal and external institutional constraints. However, traditional technological solutions have significant limitations in supporting the automation and intelligence of the linkage between institutional and control processes. For example, process automation systems based on traditional workflow engines often hard-code rules into the process links, resulting in cumbersome process reengineering and system development accompanying institutional changes, making it impossible to respond nimbly to changes in regulatory policies. Management models primarily based on post-event audits and manual checks struggle to handle massive, high-frequency transaction data, leading to severe delays in risk detection and difficulties in closing the loop on rectification and tracking. Independently built risk monitoring platforms generally focus on post-event data analysis, separated from real-time service processing processes, failing to achieve real-time intervention and creating gaps between early warning and handling. Furthermore, the scattered control modules built within each service line result in inconsistent control standards, data incompatibility, and redundant construction. Therefore, this specification provides an internal control process management method to solve the aforementioned technical problems of the inability to coordinate institutional and service processes.

[0024] Please see Figure 1 , Figure 1 This is an exemplary system architecture diagram of an internal control process management method provided in the embodiments of this specification.

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

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

[0027] In the embodiments of this specification, terminal 101 first performs structured parsing on the input specification document to generate a knowledge graph corresponding to the specification document. The knowledge graph uses document elements in the specification document as entities and the relationships between entities as edges. Then, terminal 101 generates a set of logical rules containing at least one executable logical rule based on the knowledge graph and establishes a dynamic mapping relationship between the set of logical rules and multiple service processes. When a target service process is detected being executed, terminal 101 calls the target executable logical rule corresponding to the target service process and calls the knowledge graph according to the dynamic mapping relationship to identify compliance risks of the target service process.

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

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

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

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

[0032] like Figure 2 As shown, internal control process management methods can include at least: S202. Perform structured parsing on the input standard document to generate a knowledge graph corresponding to the standard document. The knowledge graph uses document elements in the standard document as entities and the relationships between entities as edges.

[0033] Optionally, in existing internal control management practices, requirements regarding capital adequacy ratios, liquidity management, related-party transactions, information disclosure, data security, and consumer rights protection, as well as internal system regulations such as service operation procedures, risk limits, and authorization management methods, are typically in the form of unstructured natural language text (such as PDF and Word documents). In this form, the semantic information is not explicitly and structurally expressed, making it difficult for computer systems to directly understand, query, or use for automated reasoning. To address this deficiency, the embodiments in this specification consider structuring and parsing the text rules and constructing a knowledge graph, thereby transforming unstructured information into a structured knowledge model operable by the computer system, facilitating subsequent automated application of regulations by the computer.

[0034] Specifically, structured parsing refers to using Natural Language Processing (NLP) technology to perform deep semantic analysis on regulatory documents. This operation aims to automatically identify and extract key elements from the text, recognizing key concepts, subjects, objects, conditions, behaviors, and results, such as customer type, risk level, approval authority, data domain, technical architecture standards, and market access qualifications. These elements are abstracted as entities. Correspondingly, the system also identifies various semantic relationships between these entities, such as logical relationships, causal relationships, hierarchical relationships, restrictive relationships, and dependency relationships. These relationships are abstracted as edges connecting entities. From the entities and edges, a knowledge graph corresponding to the regulatory document can be constructed. This knowledge graph can structurally represent the complex logic, hierarchy, and constraints in the regulatory clauses, providing a unified data structure foundation for machines to understand the connotation of the regulations. This transforms the originally rigid textual regulations into a flexible, digital knowledge system, laying a reliable foundation for the automated application, consistency checks, and correlation analysis of regulations.

[0035] S204. Generate a set of logical rules based on the knowledge graph, which contains at least one executable logical rule, and establish a dynamic mapping relationship between the set of logical rules and multiple service processes.

[0036] Alternatively, in existing technologies, service rules are either hard-coded directly into the source code of the service process, resulting in a high degree of coupling between rules and processes; or traditional workflow engines are used, but their rules are usually statically configured as an attribute of process nodes, and changes still require modification of the process definition. In both modes, there is a tight coupling between control logic and process logic, meaning that when the system (i.e., the source of control logic) changes, the code or configuration of multiple service processes must be traced and modified. This process is cumbersome, time-consuming, error-prone, and makes it difficult to guarantee global consistency, severely restricting the responsiveness of the internal control system. Therefore, this specification's embodiments introduce an independent, configurable rule engine as an intermediate layer to receive structured information from the knowledge graph and automatically generate executable logical rules based on predefined syntax (such as the Drools rule language) or through machine learning reasoning. For example, based on the relationship between "a certain type of transaction" and "a certain risk level" in the graph, a rule is automatically generated: "If a transaction belongs to type X and involves risk level Y, then trigger control activity Z." These rules are centrally managed, forming a set of logical rules.

[0037] Furthermore, the system establishes a dynamic mapping relationship between the logical rule set and multiple service processes. For example, for a product design or cooperation plan involving multiple parties, the system can automatically traverse the knowledge graph, identify all relevant compliance risk requirements, approval processes, and technical specifications, and generate a complete set of compliance and risk control rule chains. This mapping relationship can be declarative and stored in a configuration library or metadata, rather than hard-coded. By obtaining regulatory requirements from the knowledge graph through the rule engine and dynamically compiling or interpreting them into executable code, while maintaining the association mapping relationship between rules and process nodes, when a service process is deployed or modified, there is no need to concern oneself with the specific rule content; only the node type needs to be declared, and the corresponding rules will be dynamically bound and invoked at runtime. This rule-driven process mechanism implemented by this architecture allows regulatory changes to be automatically or semi-automatically adjusted by updating the knowledge graph and rule set, achieving dynamic consistency between rules and internal control strategies, and greatly improving the system's maintainability, flexibility, and responsiveness to changes.

[0038] S206. When a target service process is detected to be in operation, the target executable logic rules corresponding to the target service process are invoked according to the dynamic mapping relationship, and the knowledge graph is invoked to identify compliance risks of the target service process.

[0039] Optionally, in order to detect anomalies and intervene and apply control activities in a timely manner while the service process is in progress, the system detects the running status of the target service process through event listening or API hooks, and calls two key resources in real time based on the aforementioned dynamic mapping relationship: one is the target executable logic rule corresponding to the process node, and the other is a knowledge graph containing rich related information, and then performs a comprehensive judgment process that combines rule reasoning and graph context.

[0040] In practice, when a service process instance reaches a certain node, the system first loads all rules mapped to that node. Then, the engine queries the knowledge graph for all entities and their relationships related to the service instance, inputting this real-time context as factual data into the rule engine for reasoning. Compliance risk identification is thus deepened in at least two dimensions: first, rule-based deterministic compliance verification; and second, knowledge graph-based correlation risk mining and abnormal behavior pattern detection. The context-aware composite event handling mechanism allows the system to evaluate individual service events within the knowledge graph network. Simultaneously, the rule engine utilizes the correlation paths provided by the graph to perform cross-entity and cross-process reasoning, identifying hidden risks that are difficult to detect from an isolated perspective (such as closed-loop fund flows and excessive centralized credit from related parties). This shift from passive post-event response to proactive in-event perception and intervention not only enables earlier and more accurate risk identification, providing intelligent decision support for operators, but also allows for automated handling (such as automatic interception or transfer to manual intervention) under explicit rule authorization, thereby substantially reducing risk threats and improving the effectiveness and stability of the internal control system.

[0041] This specification provides an internal control process management method. It involves structured parsing of input standard documents to generate a knowledge graph corresponding to the standard documents. The knowledge graph uses document elements in the standard documents as entities and the relationships between entities as edges. Based on the knowledge graph, a set of logical rules containing at least one executable logical rule is generated, and a dynamic mapping relationship is established between the logical rule set and multiple service processes. When a target service process is detected being executed, the target executable logical rule corresponding to the target service process is invoked according to the dynamic mapping relationship, and the knowledge graph is also invoked to identify compliance risks in the target service process. Firstly, by introducing technologies such as natural language processing, key concepts, subjects, conditions, and behaviors in the text are automatically identified and abstracted into entities. The logical, causal, and hierarchical relationships between entities are abstracted into edges, thereby constructing a structured knowledge graph network. This transformation process maps human-readable regulations into a machine-operable knowledge model, laying the data foundation for subsequent automated processing. Based on the completed knowledge graph, a set of logical rules containing at least one executable logical rule is generated. A dynamic mapping relationship is established between this set of logical rules and multiple service processes. This operation transforms static knowledge into dynamic control logic, ensuring that this logic can flexibly apply to specific service processes. This decouples rules from processes, improving system flexibility and maintainability while guaranteeing consistency of internal control standards. Ultimately, when a specific service flow instance runs, the system can automatically trigger the set of rules related to that process node through the pre-established dynamic mapping relationship, and make a comprehensive judgment based on the rich contextual information provided by the knowledge graph. This real-time internal control risk prevention enables timely compliance checks and risk warnings when service operations occur, effectively preventing violations and achieving real-time, automated, and intelligent risk control, significantly improving the depth and breadth of system risk perception.

[0042] Please see Figure 3 , Figure 3 This is a flowchart illustrating an internal control process management method provided in another embodiment of this specification.

[0043] like Figure 3 As shown, internal control process management methods can include at least: S302. Perform natural language processing on the standard document to identify and extract entity elements and relational elements in the standard document.

[0044] Optionally, when constructing the knowledge graph, this embodiment of the specification uses natural language processing to identify and extract entity elements and relational elements from the specification document. Entity elements refer to key objects or concepts that objectively exist in the text, possess independent meaning and are distinguishable, such as organizational structures, personnel roles, service products, monetary thresholds, time periods, and technical terms. Relational elements describe the specific semantic relationships between entities, such as subordinate, constraint, causal, temporal, equivalent, and referential relationships. By extracting these elements, the system can capture the structured knowledge framework inherent in the regulatory text.

[0045] In one specific implementation, the document text is first preprocessed (e.g., encoding conversion, paragraph segmentation). Then, a Named Entity Recognition (NER) model, combined with a domain dictionary and contextual features, accurately locates and classifies all entities in the text. For example, in regulatory text, the NER model needs to accurately distinguish whether "customer" refers to a "corporate customer" or a "natural person customer," and whether "transaction" refers to a "securities transaction" or a "credit transaction." Next, a Relation Extraction (RE) model or a rule / dependency parsing-based method is used to identify the semantic relationships between entity pairs. For example, analyzing the syntactic tree and semantic roles determines that "Risk Management Committee" and "Approval" have an "Execution" relationship, while "Single Transaction Amount" and "5 million yuan" have a "Comparison (Greater than)" relationship. In another feasible implementation, a fine-tuning method based on pre-trained language models (such as BERT, GPT series) can be used to simultaneously optimize the extraction of entities and relationships in an end-to-end or pipeline manner. This process transforms unstructured natural language descriptions into standardized triples such as (entity, relation, entity) or (entity, attribute, value), providing raw materials for constructing formal knowledge graphs. It enables deep semantic understanding and automated knowledge extraction of institutional documents, laying the foundation for the subsequent construction of computable and reasonable knowledge models.

[0046] S304. Associate the extracted entity elements with at least one actual service data to construct a knowledge graph that integrates specification documents and actual services.

[0047] Optionally, after extracting the elements from the regulatory text, if a knowledge graph is constructed solely based on the text itself, the resulting knowledge system may be static and isolated, disconnected from the dynamic data and complex entity networks in actual application scenarios. This would directly lead to inferences and decisions based on it being detached from reality, and control rules failing to be accurately applied to specific service objects and scenarios. This is because regulatory clauses are general and abstract, while service data is concrete and instantiated. Therefore, in the embodiments of this specification, to ensure that the knowledge system possesses the necessary contextual information to drive real-time service judgments, the extracted entity elements are also associated with at least one piece of actual service data to construct a knowledge graph that integrates regulatory documents and actual services.

[0048] In this context, actual service data refers to data generated from real service systems (such as core banking systems, credit systems, risk control systems, compliance systems, and data warehouses) that reflects the actual service status and processes. The essence of correlation operations is to establish a mapping and link between abstract institutional concepts and concrete service instances. For example, the abstract category of "high-risk customers" in the system is associated with a list of specific customer IDs in the risk control system whose risk scores are below a certain threshold; the concept of "related-party transactions" is associated with actual equity control chain data in the enterprise relationship graph, ultimately forming a unified and comprehensive service knowledge network.

[0049] In practice, the system typically relies on entity linking and data fusion technologies. First, it addresses alignment issues at the schema level by semantically mapping entity categories extracted from policy texts (e.g., "approval agency") to tables / fields in the actual service database (e.g., "employee table.department"). Second, it performs entity linking at the instance level, using string similarity, rules, or machine learning models to determine if "Client Company A" mentioned in the text corresponds to "Client Number C1001 'XX Technology Co., Ltd.'" in the service database. Building on this, the system further integrates data from multiple heterogeneous data sources, using knowledge fusion technology to handle issues such as homonyms, heteronyms, and data conflicts, and supplementing with rich potential relationships not explicitly stated in the text. The resulting fused knowledge graph is a unified, multi-source integrated semantic network. By constructing this knowledge graph, subsequent risk control rules can directly apply to service instances, enabling compliance checks to be based on real service relationships and historical behavior patterns, significantly improving the accuracy, relevance, and real-time nature of risk identification.

[0050] S306. Generate at least one executable logic rule based on the knowledge graph, and perform service association reasoning on each executable logic rule to construct a composite rule chain of executable logic rules belonging to the same service scenario.

[0051] Optionally, in existing technologies, the traditional method of transforming internal control systems into executable rules mainly relies on manual writing and static configuration. In this model, the rule generation and management process is detached from the knowledge ontology of the system and the dynamic relational network of service entities, resulting in a lack of organic semantic connections and reasoning capabilities between rules. To address these issues, at least one executable logical rule can be generated based on a knowledge graph, and service-related reasoning can be performed on each executable logical rule to construct a composite rule chain from executable logical rules belonging to the same service scenario. Here, executable logical rules refer to atomic judgment logic that can be directly interpreted and executed by the rule engine, typically existing in the form of "condition-action" pairs. Service-related reasoning refers to using the semantic network of entities and relationships in the knowledge graph to analyze and identify the logical order, dependency, or combination relationships between multiple atomic rules serving the same service goal or process. The composite rule chain is a rule execution sequence capable of handling complex logic, formed by the orderly arrangement and combination of these atomic rules based on the reasoning results.

[0052] In its implementation, the system first utilizes the template or script capabilities of a pre-built rule engine, taking triples (entity-relationship-entity) or more complex subgraph patterns from the knowledge graph as input. Through predefined mapping rules or machine learning-based methods, it automatically generates corresponding logical rules in the form of conditional statements (IF-THEN), sequence execution, and complex event handling. Secondly, using the rule engine or other dedicated reasoning components, it traverses and reasons based on the knowledge graph's topology to identify all relevant institutional entities and constraints. Then, the system dynamically combines these scattered atomic rules corresponding to the constraints into a complete and ordered rule execution chain according to the temporal logic and dependencies of the service flow. Finally, by continuously analyzing historical logs of rule execution and external feedback, and leveraging the association analysis capabilities of the knowledge graph, the system identifies blind spots and contradictions in existing rule sets, proposes optimization suggestions, and even automatically performs iterative adjustments. This operation significantly improves the efficiency and accuracy of rule construction, reduces the bias and delay caused by human intervention, and enables the dynamic assembly of rules in a contextualized and systematic manner through reasoning on the knowledge graph. This allows the system to automatically respond to complex and cross-domain service scenarios. Furthermore, by introducing a feedback learning mechanism, it further realizes the continuous self-optimization and evolution of the rule system, enabling the internal control system to proactively adapt to service innovation and regulatory changes.

[0053] S308. Embed and integrate each executable logical rule in the logical rule set into each execution node of the corresponding service process in the form of service calls.

[0054] Optionally, existing technologies generally employ a hard-coded or tightly configured integration model when applying risk control rules to service processes. Specifically, this manifests as either directly writing the rule logic within the service process's application code or configuring the rules as a fixed attribute of a process node in a Service Process Management (BPM) tool. Due to the deep coupling between service logic (process) and control logic (rules), any changes to the system face cumbersome processes and long cycles. Therefore, in the embodiments of this specification, each executable logic rule in the logic rule set is embedded and integrated into the corresponding execution nodes of the service process via service calls to achieve decoupling. In this model, each or each set of executable logic rules is encapsulated as an independent, standardized decision service. This service provides risk assessment or compliance judgment functions to the outside world through a predefined application programming interface (API), and its internal implementation details (such as the specific rules used) are transparent to the caller. The execution nodes of the service process obtain the necessary control judgments by calling these standardized decision service APIs, rather than carrying specific rule logic within the nodes themselves. This integration approach first enhances the system's flexibility and maintainability. When policy changes necessitate rule updates, only the rule logic needs direct modification, and the corresponding decision-making service needs to be republished or updated. All service processes integrated with this service will automatically acquire the updated decision-making capabilities upon subsequent calls, without requiring any modifications to the processes themselves. Secondly, it improves the system's reusability and standardization. The same risk control decision-making service can be reused by multiple different service processes, ensuring consistency in risk control standards across the entire bank. Furthermore, it enhances the system's observability and manageability. Since all risk decisions are made through standard service interfaces, the system can centrally monitor the performance, call frequency, and decision result distribution of all decision-making services, providing a unified and clear data foundation for subsequent risk assessment, auditing, and other processes.

[0055] S310. When a target service process is detected to be in progress, the target executable logic rules corresponding to the target service process and the knowledge graph are invoked according to the dynamic mapping relationship. Based on the target executable logic rules and the knowledge graph, graph calculation analysis is performed on the entities appearing in the target service process to identify the associated risk transmission paths and abnormal behavior patterns related to the target service process.

[0056] Optionally, during the execution of the target service process, preset logical rules are invoked based on dynamic mapping relationships, and the knowledge graph is simultaneously invoked to perform graph computation analysis on the entities appearing in the process, in order to identify associated risk transmission paths and abnormal behavior patterns. Graph computation analysis uses the entity relationship network constructed by the knowledge graph as the computational object, employing a series of analytical operations using graph theory algorithms. Associated risk transmission paths refer to the possible chains along which risk factors (such as credit defaults, liquidity shortages, and operational errors) spread from a certain node to other related nodes along the relationship edges between entities in the knowledge graph. Abnormal behavior patterns refer to abnormal connections, clusters, or flows that deviate from historical normal graph patterns or preset compliance subgraph patterns exhibited in the graph structure.

[0057] In terms of specific implementation, firstly, at the level of associated risk identification, when the process involves a core entity (such as legal entity A applying for a loan), the system takes this entity as the starting point and performs multi-hop traversal and expansion along various relational edges in the knowledge graph. Using algorithms such as label propagation or Louvain's algorithm, it identifies other entities with deep relationships with this entity. This operation can reconstruct discrete service data points into a globally interconnected network and proactively mine the inherent risk topology through graph algorithms. Secondly, at the level of abnormal behavior pattern detection, the core is to dynamically update the knowledge graph with real-time generated service data and perform anomaly detection based on graph features. The system not only maintains a static knowledge graph but also constructs a dynamic behavior graph. When real-time transaction data flows in and updates the graph, the system identifies abnormal behavior patterns suspected of violating regulations by calculating the deviation between the current graph structure features and historical normal patterns in the embedding space, or by detecting the existence of suddenly appearing abnormally dense connections. This achieves a leap from simple rule-based judgment to intelligent identification based on graph pattern learning. Finally, at the level of impact path analysis, the core lies in risk propagation simulation and critical path finding. Once an entity is identified as a risk point (e.g., due to default), the system can use shortest path algorithms or random walk models to simulate the transmission process of risk along relational paths, quickly locate the most likely affected related entities, and assess the overall risk exposure. This provides a precise basis for subsequent risk isolation and mitigation measures. This risk assessment based on logical rules and knowledge graphs enables the identification and early warning of complex, hidden, and highly contagious related risks, significantly improving the comprehensiveness and foresight of risk discovery. Furthermore, by quantifying risk transmission paths, it provides strong technical support for shifting risk management from passive response to proactive defense and precise intervention, thereby fundamentally enhancing the system's ability to cope with risks.

[0058] This specification provides an internal control process management method in its embodiments. First, natural language processing is used to transform textual regulations into a computable entity relationship network, which is then further associated with actual service data. This provides a precise and dynamic contextual knowledge foundation for subsequent automated control. Second, rules are automatically generated based on a knowledge graph, and service association reasoning is performed to construct a composite rule chain, achieving intelligent decoupling and dynamic assembly of rules and processes. Third, rules are embedded into process nodes through service invocation, allowing rule changes to be performed independently of service processes, significantly reducing maintenance costs and ensuring unified control standards. Finally, during process execution, rules and the knowledge graph are simultaneously invoked for graph computation analysis. This not only enables rule-based point-based compliance checks but also identifies complex risk transmission paths and hidden abnormal behavior patterns that are difficult to detect using traditional methods, thereby constructing an intelligent internal control system with deep insight and continuous evolution capabilities.

[0059] Please see Figure 4 , Figure 4 This is a flowchart illustrating an internal control process management method provided in yet another embodiment of this specification.

[0060] like Figure 4 As shown, internal control process management methods may also include at least: S402. Perform structured parsing on the input standard document to generate a knowledge graph corresponding to the standard document. The knowledge graph uses document elements in the standard document as entities and the relationships between entities as edges.

[0061] S404. Generate a set of logical rules based on the knowledge graph, which contains at least one executable logical rule, and establish a dynamic mapping relationship between the set of logical rules and multiple service processes.

[0062] S406. When a target service process is detected to be in operation, the target executable logic rules corresponding to the target service process are invoked according to the dynamic mapping relationship, and the knowledge graph is invoked to identify compliance risks of the target service process.

[0063] For details regarding steps S402-S406, please refer to the detailed descriptions in steps S202-S206, which will not be repeated here.

[0064] S408. If a compliance risk is identified, the risk node where the compliance risk is located is determined based on the knowledge graph, and the risk control operation corresponding to the risk node is automatically triggered according to the preset handling strategy.

[0065] Optionally, traditional systems or manual processes, after identifying a risk, typically require generating a work order, sending an email, or initiating a separate approval process to drive the handling, leading to response delays, execution interruptions, and difficulty in ensuring the targeted nature of the handling actions. To address the issues of delayed and disconnected risk handling, the embodiments in this specification will determine the risk node where the compliance risk is located based on a knowledge graph, and automatically trigger the risk control operation corresponding to the risk node according to a preset handling strategy. Here, a risk node refers to two things: first, the specific execution steps in the service process instance where the risk occurs; and second, the key entities or relationships in the knowledge graph that are directly related to the risk. The preset handling strategy is a series of predefined, standardized response procedures bound to different risk types and severity levels, which can also be stored as rules in the system. Risk control operations refer to specific actions that can be automatically executed, such as rejecting a transaction, locking an account, suspending the process, triggering a specific approval chain, or sending a mandatory prompt.

[0066] Furthermore, when the system identifies compliance risks, it immediately utilizes knowledge graphs for root cause analysis and impact assessment. By tracing back the rules and graph paths that triggered the risk, the system can accurately pinpoint the risk process nodes and key responsible entities (such as borrowers, guarantors, and approval roles) that led to the risk. This process transforms risk management from a lagging process relying on manual decision-making into an instant response system driven by data and strategies, significantly reducing the risk exposure window. Through automated execution, it ensures the timeliness, accuracy, and consistency of the handling actions, achieving proactive defense.

[0067] S410. Continuously collect process data on compliance risk identification and handling; generate internal control assessment reports based on process data and analyze them; and adaptively adjust the entity relationships in the knowledge graph or the rules in the logical rule set according to the analysis conclusions.

[0068] Optionally, another prominent deficiency of existing internal control management systems lies in their static and fragmented nature. Data from risk identification, handling, auditing, and rectification are often scattered across different systems or reports, making correlation analysis difficult. Optimization of the internal control system typically relies on periodic audits or assessments, which are retrospective, sampling checks that cannot achieve continuous iteration based on full, real-time process data. This results in the design and improvement of internal control rules and processes lagging significantly behind actual service needs, failing to dynamically adapt to new risks or service changes. Therefore, this specification's embodiments overcome this deficiency by continuously collecting process data on compliance risk identification and handling; generating and analyzing internal control assessment reports based on this process data; and adaptively adjusting the entity relationships in the knowledge graph or the rules in the logical rule set according to the analysis conclusions. The process data encompasses the entire chain of multi-dimensional data, from risk event triggering, contextual information, rule execution results, handling operation records to final handling effect verification. Adaptive adjustment refers to the system's ability to automatically or semi-automatically correct, supplement, or optimize core knowledge assets (knowledge graph) and judgment logic (rule set) using data analysis conclusions.

[0069] In its implementation, a reinforcement learning loop was constructed, encompassing monitoring, analysis, and feedback. The system continuously acquires massive amounts of process data through data tracking and log collection, storing it on an analysis platform. Subsequently, the data analysis module (potentially integrating BI tools and machine learning models) performs multi-dimensional data mining: for example, analyzing the high-frequency false alarm rate of a certain type of rule, identifying new risk patterns not covered by existing rules (such as discovering new variants of suspicious transactions through cluster analysis), evaluating the actual effectiveness of different handling strategies, or discovering potential contradictions between policy provisions through correlation analysis. These analytical conclusions are then structured and fed back to the system. For high-frequency false alarm rules, the system can suggest adjusting their thresholds or confidence levels. This process of transforming operational data into system knowledge enables the internal control system to continuously learn and dynamically optimize from practical experience, achieving continuous improvement and dynamic adaptability, thereby systematically enhancing the long-term effectiveness, accuracy, and intelligence of the internal control system.

[0070] S412. Based on the historical risk identification results and service environment feedback information, adaptively adjust the entity relationships or rules in the logical rule set in the knowledge graph.

[0071] Optionally, by introducing an open learning and adaptation mechanism—that is, by adaptively adjusting the entity relationships or rules in the logical rule set of the knowledge graph based on historical risk identification results and service environment feedback information—the system's dynamic optimization capabilities can be further enhanced. Historical risk identification results represent the system's long-term accumulated identification paradigms, while service environment feedback information can include the latest rule texts, case studies, industry risk research reports, and other internal and external information. Based on this process, the system can transform this internal and external feedback into optimizations of its own knowledge structure.

[0072] Specifically, the system can periodically crawl or receive new regulations issued by institutions, analyze them using NLP technology, compare them with existing knowledge graphs, automatically suggest entities and relationships that need to be added, modified, or abolished, and drive the generation or adjustment of corresponding compliance rules. For example, by analyzing historical risk case databases, graph neural networks can learn the common patterns of risk event diffusion in the graph, thereby setting early warning rules or strengthening related relationships in advance on similar graph structures. Its technical essence lies in placing the system in an ecosystem that continuously interacts with the service environment, using feedback information for incremental learning and knowledge evolution. This mechanism enhances the adaptability and risk predictability of the internal control system. Based on this, the system can proactively learn external knowledge and historical experience, anticipate and adapt to potential future risks and compliance requirements, thus making the entire internal control system more robust and timely.

[0073] This specification provides an internal control process management method. First, the solution significantly improves the timeliness and effectiveness of control through the automation and precision of risk handling. This allows the system to instantly locate the root cause of a risk based on a knowledge graph after risk identification and automatically trigger precise control operations according to preset strategies, greatly shortening the risk exposure window and ensuring the immediacy, accuracy, and consistency of handling actions. Second, the solution establishes a data-driven self-optimization mechanism for the internal control system. By continuously collecting and deeply analyzing data from the entire process chain, it not only supports the generation of accurate internal control assessment reports but also directly feeds the analysis conclusions back to the knowledge graph and rule base, driving them to adaptively adjust. This allows the system to continuously learn from actual operation, achieving a closed-loop improvement and dynamic refinement of internal control quality. Finally, by further incorporating historical experience and external environmental feedback, the system drives the evolution of the knowledge graph and rules. This enables the system not only to solve current problems but also to learn from external knowledge, thereby anticipating and adapting to future compliance requirements and risk patterns, thus building a resilient and strategically valuable intelligent internal control system.

[0074] Please see Figure 5 , Figure 5 This is a structural block diagram of an internal control process management device provided as an embodiment of this specification. Figure 5As shown, the internal control process management device 500 includes: The knowledge graph construction module 510 is used to perform structured parsing on the input standard documents and generate a knowledge graph corresponding to the standard documents. The knowledge graph uses document elements in the standard documents as entities and the relationships between entities as edges. The control logic generation module 520 is used to generate a set of logic rules containing at least one executable logic rule based on the knowledge graph, and to establish a dynamic mapping relationship between the set of logic rules and multiple service processes. The process risk perception module 530 is used to identify compliance risks of the target service process when a target service process is detected to be executing, by calling the target executable logic rules corresponding to the target service process and calling the knowledge graph according to the dynamic mapping relationship.

[0075] Optionally, the knowledge graph construction module 510 is also used to perform natural language processing on the specification document, identify and extract entity elements and relation elements in the specification document; and associate the extracted entity elements with at least one actual service data to construct a knowledge graph that integrates the specification document and the actual service.

[0076] Optionally, the control logic generation module 520 is also used to generate at least one executable logic rule based on the knowledge graph, and to perform service association reasoning on each executable logic rule, so as to construct a composite rule chain of executable logic rules belonging to the same service scenario.

[0077] Optionally, the control logic generation module 520 is also used to embed each executable logic rule in the logic rule set into each execution node of the corresponding service process in the form of service calls.

[0078] Optionally, the process risk perception module 530 is also used to perform graph computation analysis on entities appearing in the target service process based on the target executable logic rules and knowledge graph, so as to identify the associated risk transmission path and abnormal behavior pattern related to the target service process.

[0079] Optionally, the internal control process management device 500 also includes an automated handling module, which, if a compliance risk is identified, determines the risk node where the compliance risk is located based on a knowledge graph and automatically triggers the risk control operation corresponding to the risk node according to a preset handling strategy.

[0080] Optionally, the internal control process management device 500 also includes: an assessment and adjustment module, used to continuously collect process data on compliance risk identification and handling; generate an internal control assessment report based on the process data and perform analysis; and adaptively adjust the entity relationships in the knowledge graph or the rules in the logical rule set according to the analysis conclusions.

[0081] Optionally, the internal control process management device 500 also includes a feedback adjustment module, which is used to adaptively adjust the entity relationships in the knowledge graph or the rules in the logical rule set based on the historical risk identification results and service environment feedback information.

[0082] In this embodiment, an internal control process management device is provided, comprising: a knowledge graph construction module for structured parsing of input normative documents to generate a knowledge graph corresponding to the normative documents, wherein the knowledge graph uses document elements in the normative documents as entities and the relationships between entities as edges; a control logic generation module for generating a set of logic rules containing at least one executable logic rule based on the knowledge graph, and establishing a dynamic mapping relationship between the set of logic rules and multiple service processes; and a process risk perception module for identifying compliance risks of the target service process when a target service process is detected being executed, by invoking the target executable logic rule corresponding to the target service process and the knowledge graph according to the dynamic mapping relationship. Firstly, by introducing technologies such as natural language processing, key concepts, subjects, conditions, behaviors, and other elements in the text are automatically identified and abstracted into entities, and the logical, causal, and hierarchical relationships between entities are abstracted into edges, thereby constructing a structured knowledge graph network. This transformation process maps human-readable institutional norms into machine-operable knowledge models, laying the data foundation for subsequent automated processing. Based on the completed knowledge graph, a set of logical rules containing at least one executable logical rule is generated. A dynamic mapping relationship is established between this set of logical rules and multiple service processes. This operation transforms static knowledge into dynamic control logic, ensuring that this logic can flexibly apply to specific service processes. This decouples rules from processes, improving system flexibility and maintainability while guaranteeing consistency of internal control standards. Ultimately, when a specific service flow instance runs, the system can automatically trigger the set of rules related to that process node through the pre-established dynamic mapping relationship, and make a comprehensive judgment based on the rich contextual information provided by the knowledge graph. This real-time internal control risk prevention enables timely compliance checks and risk warnings when service operations occur, effectively preventing violations and achieving real-time, automated, and intelligent risk control, significantly improving the depth and breadth of system risk perception.

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

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

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

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

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

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

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

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

[0091] exist Figure 6 In the terminal 600 shown, the user interface 603 is mainly used to provide an input interface for the user and to obtain the user's input data; while the terminal processor 601 can be used to call the internal control process management program stored in the memory 605 and specifically perform the following operations: The input standard document is structured and parsed to generate a knowledge graph corresponding to the standard document. The knowledge graph uses document elements in the standard document as entities and the relationships between entities as edges. Generate a set of logical rules based on the knowledge graph, each containing at least one executable logical rule, and establish a dynamic mapping relationship between the set of logical rules and multiple service processes; When a target service process is detected to be in execution, the target executable logic rules corresponding to the target service process are invoked according to the dynamic mapping relationship, and the knowledge graph is invoked to identify compliance risks of the target service process.

[0092] In some embodiments, when the terminal processor 601 performs structured parsing of the input specification document to generate a knowledge graph corresponding to the specification document, it specifically performs the following steps: performs natural language processing on the specification document to identify and extract entity elements and relation elements in the specification document; and associates the extracted entity elements with at least one actual service data to construct a knowledge graph that integrates the specification document and the actual service.

[0093] In some embodiments, when the terminal processor 601 executes the following steps when generating a set of logical rules containing at least one executable logical rule based on a knowledge graph: generating at least one executable logical rule based on the knowledge graph, and performing service association reasoning on each executable logical rule to construct a composite rule chain of executable logical rules belonging to the same service scenario.

[0094] In some embodiments, when the terminal processor 601 performs the dynamic mapping relationship between the set of logical rules and multiple service processes, it specifically performs the following steps: embedding each executable logical rule in the set of logical rules into each execution node of the corresponding service process in the form of a service call.

[0095] In some embodiments, when the terminal processor 601 performs compliance risk identification on the target service process, it specifically performs the following steps: based on the target executable logic rules and knowledge graph, it performs graph computation analysis on the entities appearing in the target service process to identify the associated risk transmission paths and abnormal behavior patterns related to the target service process.

[0096] In some embodiments, the terminal processor 601 further performs the following steps: if a compliance risk is identified, the risk node where the compliance risk is located is determined based on the knowledge graph, and the risk control operation corresponding to the risk node is automatically triggered according to the preset handling strategy.

[0097] In some embodiments, the terminal processor 601 further performs the following steps: continuously collecting process data on compliance risk identification and handling; generating an internal control assessment report based on the process data and analyzing it; and adaptively adjusting the entity relationships in the knowledge graph or the rules in the logical rule set according to the analysis conclusions.

[0098] In some embodiments, the terminal processor 601 further performs the following steps: adaptively adjusting the entity relationships in the knowledge graph or the rules in the logical rule set based on the historical risk identification results and service environment feedback information.

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

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

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

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

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

[0104] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

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

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

Claims

1. An internal control process management method, the method comprising: The input standard document is subjected to structured parsing to generate a knowledge graph corresponding to the standard document. The knowledge graph uses document elements in the standard document as entities and the relationships between entities as edges. Based on the knowledge graph, a set of logical rules containing at least one executable logical rule is generated, and a dynamic mapping relationship is established between the set of logical rules and multiple service processes. When a target service process is detected to be in execution, the target executable logic rules corresponding to the target service process are invoked according to the dynamic mapping relationship, and the knowledge graph is invoked to identify compliance risks of the target service process.

2. The method according to claim 1, wherein the step of performing structured parsing on the input normative document to generate a knowledge graph corresponding to the normative document includes: Natural language processing is performed on the specification document to identify and extract entity elements and relation elements from the specification document; The extracted entity elements are associated with at least one actual service data to construct a knowledge graph that integrates the specification document and the actual service.

3. The method according to claim 1 or 2, wherein generating a set of logical rules containing at least one executable logical rule based on the knowledge graph includes: At least one executable logic rule is generated based on the knowledge graph, and service association reasoning is performed on each executable logic rule to construct a composite rule chain of executable logic rules belonging to the same service scenario.

4. The method according to claim 1, wherein establishing the dynamic mapping relationship between the logical rule set and multiple service processes includes: Each executable logical rule in the set of logical rules is embedded into each execution node of the corresponding service process in the form of a service call.

5. The method according to claim 1, wherein the compliance risk identification of the target service process includes: Based on the target executable logic rules and the knowledge graph, graph computation analysis is performed on the entities appearing in the target service process to identify the associated risk transmission paths and abnormal behavior patterns related to the target service process.

6. The method according to claim 1, further comprising: If a compliance risk is identified, the risk node where the compliance risk is located is determined based on the knowledge graph, and the risk control operation corresponding to the risk node is automatically triggered according to the preset handling strategy.

7. The method according to claim 1, further comprising: Continuously collect process data on compliance risk identification and handling; An internal control assessment report is generated and analyzed based on the process data. The entity relationships in the knowledge graph or the rules in the logical rule set are adaptively adjusted according to the analysis conclusions.

8. The method according to claim 1, further comprising: Based on historical risk identification results and service environment feedback information, the entity relationships in the knowledge graph or the rules in the logical rule set are adaptively adjusted.

9. An internal control process management device, the device comprising: The knowledge graph construction module is used to perform structured parsing on the input standard document and generate a knowledge graph corresponding to the standard document. The knowledge graph uses document elements in the standard document as entities and the relationships between entities as edges. The control logic generation module is used to generate a set of logic rules containing at least one executable logic rule based on the knowledge graph, and to establish a dynamic mapping relationship between the set of logic rules and multiple service processes. The process risk perception module is used to identify compliance risks of a target service process when a target service process is detected to be executing, by invoking the target executable logic rules corresponding to the target service process and the knowledge graph according to the dynamic mapping relationship.

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

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

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

Images