Risk control method for business process review

Abstract

The invention discloses a risk control method for business process review, which belongs to the technical field of process review, and specifically comprises the following steps: acquiring all node information of a target business process, and determining a risk dimension of the business process review according to compliance requirements of a field to which the business process belongs; the risk dimension comprises a node operation authority matching degree, flow data transmission compliance and inter-node business logic coherence; for each risk dimension, establishing a risk judgment rule corresponding to each risk dimension based on the feature parameters; collecting operation data generated when each node of the target business process runs in real time; respectively substituting the collected operation data into a risk judgment rule corresponding to each risk dimension, marking the risk dimension and the node position corresponding to the operation data which does not conform to the risk judgment rule, and calling a preset risk processing strategy library under the risk dimension, and matching a risk processing suggestion corresponding to the current risk feature from a risk processing strategy library.

Description

Technical Field

[0001] This invention relates to the field of process review technology, and more specifically to a risk control method for business process review. Background Technology

[0002] Enterprises typically rely on business process management platforms, office automation systems, and internal control systems to conduct compliance reviews and risk monitoring of process execution. Common practices include: configuring approval nodes and conditional branches in the process engine; constraining personnel permissions through role-based access control; aggregating operational records with log auditing, database auditing, and security information and event management platforms; using rule bases to match and block based on keywords, numerical thresholds, and blacklists / whitelists; and employing data leakage prevention systems, dedicated transmission lines, and encrypted storage technologies at the data level. Some organizations also attempt to use anomaly detection and statistical analysis to identify abnormal patterns.

[0003] Overall, these solutions can detect unauthorized operations, unauthorized transmissions, and abnormal processes to some extent. However, they mostly rely on system function configurations or scattered security tools, lacking an integrated methodology for business process review scenarios and a traceable closed loop from clauses to rules, and from rules to nodes. Specifically, existing technologies in business process review suffer from problems such as a single risk review dimension, a lack of clear basis for judgment rules, inability to accurately locate risk points after operational data collection, lack of targeted risk handling solutions, and the inability to trace review information due to its lack of system storage. Summary of the Invention

[0004] The purpose of this invention is to provide a risk control method for business process review, thereby solving the problems in the background art; The objective of this invention can be achieved through the following technical solutions: A risk control method for business process review includes the following steps: S1: Obtain all node information of the target business process, and determine the risk dimensions for review of the business process based on the compliance requirements of the domain to which the business process belongs; the risk dimensions include the matching degree of node operation permissions, compliance of process data transmission, and the consistency of business logic between nodes; S2: For each risk dimension, extract the characteristic parameters of the normal operation of the business process under that dimension, and establish risk judgment rules for each risk dimension based on the characteristic parameters. S3: Real-time collection of operational data generated at each node of the target business process during runtime; S4: Substitute the collected operational data into the risk judgment rules corresponding to each risk dimension, verify whether the operational data conforms to the risk judgment rules one by one, and mark the risk dimensions and node positions corresponding to the operational data that does not conform to the risk judgment rules. S5: Based on the marked risk dimension and node position, retrieve the preset risk handling strategy library under that risk dimension, and match the risk handling suggestions corresponding to the current risk characteristics from the risk handling strategy library; S6: Send the marked risk dimensions, node locations, and corresponding risk handling suggestions to the business process management terminal, and store all information from this business process review in the business process review database.

[0005] As a further aspect of the present invention: in step S1, the process of determining the risk dimension of the business process review based on the compliance requirements of the domain to which the business process belongs is as follows: Retrieve all compliance requirement documents for the target business process's domain, analyze the constraint clauses in the documents related to the operation of the business process, and form a list of compliance clauses; Each clause in the compliance clause list is categorized by risk type, and the risks involved in the clauses are identified into three categories: operational permissions, data transmission, and business logic. The risk types are categorized by the matching degree of operation permissions to the nodes, the compliance of data transmission to the process data transmission, and the consistency of business logic between nodes. After verifying that the risk type corresponding to each compliance clause has been matched with the risk dimension without any omissions, the risk dimension for the review of this business process is determined.

[0006] As a further aspect of the present invention: in step S2, the risk judgment rule is used to determine whether there is a risk in the business process operation under this dimension.

[0007] As a further aspect of the present invention: In step S2, the process of extracting feature parameters of normal business process operation under each risk dimension, and establishing risk judgment rules corresponding to each risk dimension based on the feature parameters, is as follows: For each risk dimension, collect historical operational data when the business process under that dimension is running normally. The historical operational data covers all operational steps involved in that dimension. Stable operational indicators are extracted from historical operational data as feature parameters. Feature parameters for node operation permission matching include the correspondence between operator positions and operation permissions. Feature parameters for compliance of process data transmission include the range of transmission nodes and encryption method. Feature parameters for the continuity of business logic between nodes include the order of instruction interaction and the response time range. Each feature parameter is transformed into a specific judgment condition. The judgment condition for the matching degree of node operation permission is that the operator's position must be consistent with the position in the operation permission list. The judgment condition for the compliance of process data transmission is that the transmission path is within the preset node range and a specified encryption method is used. The judgment condition for the continuity of business logic between nodes is that the order of instruction interaction conforms to the preset process and the response time is within the range of feature parameters, thus forming risk judgment rules for each risk dimension. Select another portion of historical operational data that is running normally, substitute it into the risk assessment rule for verification, and confirm that all data comply with the rule, then determine that the risk assessment rule is valid.

[0008] As a further aspect of the present invention: in step S3, the operation data includes the permission information of the node operator, the transmission path information of the process data, and the interaction information of business instructions between nodes.

[0009] As a further aspect of the present invention: in step S4, the process of verifying whether each piece of operational data conforms to the risk assessment rules, and marking the risk dimension and node position corresponding to operational data that does not conform to the risk assessment rules, is as follows: The collected operational data is categorized by risk dimension. The node operator's permission information corresponds to the node operation permission matching degree, the transmission path information corresponds to the compliance of process data transmission, and the instruction interaction information corresponds to the business logic coherence between nodes. For each category of data, substitute the corresponding risk dimension judgment rules into the data one by one, compare the data with the judgment conditions in the rules, and record the single-dimensional comparison results. Perform correlation verification on the multi-dimensional comparison results of the same node to check for data inconsistencies between dimensions; Extract data whose single-dimensional comparison results are inconsistent or have contradictory correlation verification, and clarify the risk dimension to which it belongs and the specific location of the node that generated the data. Add unique identifiers to the risk dimensions and node locations corresponding to the extracted data. The identifiers contain the judgment conditions for discrepancies and the types of contradictions.

[0010] As a further aspect of the present invention: in step S5, the risk handling suggestions include a node permission adjustment scheme and a data transmission path optimization scheme.

[0011] As a further aspect of the present invention: In step S5, the process of retrieving a preset risk handling strategy library under the marked risk dimension and node position, and matching risk handling suggestions corresponding to the current risk characteristics from the risk handling strategy library, is as follows: Extract the risk dimensions and node positions from the tagging information, and combine the risk dimension names and node position numbers into strategy library query keywords to ensure that the keywords uniquely correspond to the target query range. Based on the query keywords, locate the risk management strategy library specific to this risk dimension in the preset classification storage system, and divide it into independent storage areas according to the risk dimension name; Retrieve historical risk handling records associated with node location numbers from the strategy library, and extract matching items from the historical records that are consistent with the current risk characteristics as a preliminary screening basis; The current risk characteristics are compared one by one with the processing strategies in the strategy library. Based on the preliminary screening criteria, the processing strategy that perfectly matches the risk characteristics is selected as the risk processing recommendation. Verify whether the selected risk handling suggestion is suitable for the business scenario of the current node. If it is confirmed to be suitable, determine that the risk handling suggestion is the final output.

[0012] As a further aspect of the present invention: in step S6, all the information reviewed includes node information, operation data, risk marking results, and risk handling suggestions.

[0013] The beneficial effects of this invention are: This invention constructs a closed loop encompassing compliance clauses, risk dimensions, characteristic parameters, judgment rules, and operational data. First, it breaks down regulatory and internal systems into three operable dimensions, overcoming the limitations of existing technologies that rely on a single perspective. Then, it uses historical samples of normal operation to precipitate characteristic parameters, forming quantifiable and verifiable judgment rules to avoid the arbitrariness and lack of traceability inherent in experience-based thresholds. Real-time collected permission information, transmission path information, and instruction interaction information are compared dimension by dimension, achieving point-by-point verification and evidence consolidation. Once non-compliance is detected, it significantly improves the accuracy and speed of anomaly location, reduces false alarms and missed alarms, and shortens the investigation process and processing time.

[0014] This invention automatically retrieves a dedicated strategy library for each labeled dimension and node, selects a processing solution that perfectly matches the current risk characteristics, and outputs actionable suggestions for specific nodes, thus solving the pain point of existing technologies that lack targeted rectification. Simultaneously, all node information, operational data, risk labeling results, and processing suggestions are uniformly written into the business process review database, achieving versioning, structured, and encrypted storage, providing traceable evidence for subsequent review, auditing, and regulatory spot checks; the effectiveness of strategy execution can also be quantitatively evaluated, feeding back into the continuous optimization of rules and strategy libraries. Attached Figure Description

[0015] The invention will now be further described with reference to the accompanying drawings.

[0016] Figure 1 This is a flowchart illustrating a risk control method for business process review according to the present invention. Detailed Implementation

[0017] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0018] Please see Figure 1 As shown, the present invention is a risk control method for business process review, comprising the following steps: S1: Obtain all node information of the target business process, and determine the risk dimensions for review of the business process based on the compliance requirements of the domain to which the business process belongs; the risk dimensions include the matching degree of node operation permissions, compliance of process data transmission, and the consistency of business logic between nodes; S2: For each risk dimension, extract the characteristic parameters of the normal operation of the business process under that dimension, and establish risk judgment rules for each risk dimension based on the characteristic parameters. S3: Real-time collection of operational data generated at each node of the target business process during runtime; S4: Substitute the collected operational data into the risk judgment rules corresponding to each risk dimension, verify whether the operational data conforms to the risk judgment rules one by one, and mark the risk dimensions and node positions corresponding to the operational data that does not conform to the risk judgment rules. S5: Based on the marked risk dimension and node position, retrieve the preset risk handling strategy library under that risk dimension, and match the risk handling suggestions corresponding to the current risk characteristics from the risk handling strategy library; S6: Send the marked risk dimensions, node locations, and corresponding risk handling suggestions to the business process management terminal, and store all information from this business process review in the business process review database.

[0019] In a preferred embodiment of the present invention, step S1, wherein determining the risk dimension of the business process review based on the compliance requirements of the domain to which the business process belongs, is as follows: First, all compliance requirement documents for the target business process's domain are retrieved and parsed. A compliance document library can be pre-established, with sources including industry laws and regulations, normative documents issued by regulatory agencies, association or alliance standards, and internal company rules and operating procedures. The text parsing module in the compliance engine segments the documents at the chapter-clause level and extracts constraint information directly related to the business process's operation. For example, it structures and annotates content such as "who can execute, under what conditions, how data is processed during execution, and how nodes are connected," forming a list of compliance clauses containing fields such as "clause number, source, original clause text, triggering conditions, applicable nodes or links, data elements, and execution constraints." For ease of understanding, an example can be given: taking the "online refund process" as an example, common clauses in regulatory documents such as "refund initiation must be reviewed by someone other than the original approver," "credentials containing sensitive personal information must not be sent out through uncontrolled channels," and "refunds can only be submitted after the order status is completed and risk control verification has passed" are all identified and included in the list, which will be used for the determination and mapping of risk dimensions later.

[0020] After obtaining the list of compliance clauses, this embodiment categorizes each clause in the list by risk type, clarifying that the risks involved in the clauses fall into one of three categories: operational authority, data transmission, and business logic. The categorization rules are as follows: If a clause emphasizes personnel identity, job responsibilities, authorization level, approval isolation or mutual exclusion control, it is categorized into the "operational authority" category; if a clause restricts data transmission paths, cross-system or cross-border flow, encryption and desensitization, storage and retention or access control, it is categorized into the "data transmission" category; if a clause involves preconditions for process nodes, state transitions, time sequence, exception rollback, branching and merging, etc., it is categorized into the "business logic" category. Continuing with the aforementioned "online refund process" as an example, the clause "refunds must be reviewed by two people and authorized by the supervisor" is categorized into "operational authority"; the clause "attachments containing sensitive personal information must not be sent out through instant messaging tools, but should be transmitted through controlled channels and encrypted" is categorized into "data transmission"; the clause "only when the order status is completed and the risk control verification passes can it enter the refund node, otherwise it should be rolled back to the verification node" is categorized into "business logic". Such operational classification criteria ensure that each clause can be consistently and stably categorized into its corresponding risk type.

[0021] After classifying the risk types, this embodiment establishes a one-to-one correspondence between the three risk types and the three risk dimensions adopted: the operation permission risk type corresponds to the node operation permission matching degree, the data transmission risk type corresponds to the process data transmission compliance, and the business logic risk type corresponds to the business logic coherence between nodes. To make the mapping more executable, the measurement and verification criteria for each dimension are defined: for example, "node operation permission matching degree" uses the job responsibility matrix, authorization hierarchy table, and the principle of least privilege as the baseline to measure whether the actual permissions of an executor at a node are consistent with the requirements; "process data transmission compliance" uses the controlled link whitelist, encryption strength threshold, de-identification strategy, and traceability requirements as the verification basis to check whether the data meets the compliance requirements when flowing between systems or across domains; "business logic coherence between nodes" uses the state machine model, node dependency relationship, and exception handling strategy as references to verify whether the preconditions are met, whether the branches are correct, and whether rollback and compensation are achievable. For example, if the refund process follows the prescribed order of "approval node A → review node B → disbursement node C", the runtime trajectory will be compared. If there is a "direct jump from A to C", it will be judged as a potential non-compliance in the "business logic coherence" dimension.

[0022] Finally, this embodiment comprehensively verifies the matching coverage of compliance clauses and risk dimensions to ensure that "each compliance clause has been mapped to a specific risk dimension without omissions or ambiguities." To this end, a "clause-risk dimension" comparison table is generated, and each clause is checked and the verification results are output. Three types of anomalies—"uncategorized," "multiple classification conflicts," and "incomplete information"—are marked and processed: uncategorized clauses will return to the parsing stage to supplement elements; multiple classification conflicts will have their final attribution determined by priority rules (e.g., first looking at the core constraint objects of the clause's subject, verb, and object); and incomplete information will have triggering conditions or applicable nodes added. Only when all clauses have a clear attribution is the set of risk dimensions used in this business process review locked, and a coverage description (including dimension definitions, a list of covered clauses, version numbers, and timestamps) output. For example, in the practice of a refund process in a certain e-commerce field, a total of 42 clauses were verified, including 18 "operation permissions," 12 "data transmission," and 12 "business logic," achieving 100% coverage. This move ensures that the risk assessment rules established subsequently across all dimensions have a solid and complete compliance basis, avoiding blind spots in the review process due to missing dimensions.

[0023] In a preferred embodiment, in step S2, the risk assessment rule is used to determine whether there is a risk in the business process operation under this dimension.

[0024] In a preferred embodiment, step S2, which involves extracting feature parameters for the normal operation of the business process under each risk dimension and establishing risk judgment rules corresponding to each risk dimension based on the feature parameters, is as follows: In this embodiment, historical operational data of the business process under normal operating conditions is first collected for each risk dimension (node ​​operation permission matching degree, process data transmission compliance, and business logic coherence between nodes) to ensure coverage of all operational stages involved in that dimension. Data sources may include system audit logs, approval records, interface gateway call logs, message queue traces, and network device traces. To ensure representativeness, samples from different time periods, versions, and personnel are selected, and abnormal samples such as abnormal alarms and failed retries are removed or labeled to avoid interfering with subsequent feature extraction. For example, in the "online refund process," the permission dimension requires collecting the job positions and authorization records of each node from "initiation—review—verification—disbursement"; the data transmission dimension requires collecting the links and message traces between the order system, risk control system, settlement system, and bank channels; and the business logic dimension requires collecting the node entry and exit order, state transition, and rollback records.

[0025] Next, operational indicators that consistently appear during normal operation are extracted from the aforementioned historical operational data and identified as feature parameters. For "node operation permission matching degree," the feature parameters should at least include the correspondence between "positions—permission entries" and the execution boundaries of mutually exclusive positions. For compliance of process data transmission, the feature parameters include the allowed range of transmission nodes (e.g., a closed loop of "order system → risk control system → settlement system → bank channel") and the prescribed encryption methods (e.g., advanced encryption standards or commercial cryptographic algorithms), and may include auxiliary parameters such as whether a controlled dedicated line is used and the certificate validity period. For the continuity of business logic between nodes, the feature parameters include the fixed order of instruction interaction, acceptable branching conditions, and the typical response time range (which can be statistically analyzed by percentile, such as the 95th percentile). For example, if the average response time of the "review" node is consistently between 300 and 500 milliseconds in a large number of normal samples, and the order is always "approval → review → disbursement," then this can be solidified as a feature of this dimension.

[0026] After obtaining the characteristic parameters, they are transformed into explicit and executable judgment conditions, thereby forming risk judgment rules for each risk dimension. Specifically, the judgment conditions for the permission dimension are set as follows: the actual execution position of the node must be consistent with the authorized position in the permission list, and the requirements of minimum permission and mutual exclusion control must be met; the judgment conditions for the data transmission dimension are set as follows: the actual transmission path must fall entirely within the preset node range, the link must be a controlled channel, and key data must be encrypted or desensitized using a specified encryption method; the judgment conditions for the business logic dimension are set as follows: the order of instruction interaction must conform to the preset process. Figure 1The prerequisites for triggering the transaction are met, and the response times of each key node are within the range given by the feature parameters. Continuing with the refund example, if the system detects that "approval" directly leads to "disbursement," or that "risk control verification" is not completed before "review," both are judged by the rules as not conforming to "business logic coherence." If the "disbursement" node is executed by an unauthorized temporary account, it is judged as not conforming to the matching degree of operation permissions. If the transaction message is sent out via unconventional instant messaging tools without encryption, it is judged as not conforming to data transmission compliance.

[0027] Finally, to verify the effectiveness of the rules, another set of independent samples is selected from the historical data of normal operation and substituted into the above risk judgment rules for verification. If the verification results show that all samples meet the corresponding conditions, the rule is determined to accurately characterize normal behavior, and the rule is thus determined to be effective. If a small number of samples fail, it is necessary to backtrack and check whether the samples contain version switching or peak period characteristics, or to reasonably converge and fine-tune the threshold and range of the feature parameters. Taking the refund process as an example, 10,000 normal records are extracted from the past six months as the verification set. If the pass rate reaches 100%, the current rule set is frozen and labeled with the version number and timestamp as the basis for subsequent real-time review. If it is found that the response time of individual nodes is increased due to "holiday peaks" but is still within the acceptable range of business, the time upper bound of the node is relaxed accordingly, while keeping the hard conditions such as process order and authorization consistency unchanged to avoid false alarms and false negatives.

[0028] In a preferred embodiment, in step S3, the operation data includes the permission information of the node operator, the transmission path information of the process data, and the interaction information of business instructions between nodes.

[0029] In a preferred embodiment, step S4, which involves verifying whether each operation data conforms to the risk assessment rules and marking the risk dimension and node position corresponding to operation data that does not conform to the risk assessment rules, is as follows: In this embodiment, the collected operational data is first automatically categorized and stored according to risk dimensions. Specifically, the following steps are taken: The permission information of node operators (such as job title, authorization level, mutually exclusive responsibilities, and validity period) is categorized into the node operation permission matching dimension; the transmission path information of process data (such as starting node, target node, intermediate systems passed through, whether the transmission channel is controlled, and whether it is encrypted or anonymized) is categorized into the process data transmission compliance dimension; and the interaction information of business instructions between nodes (such as call order, precondition fulfillment, branch selection, rollback and compensation, and response time of each stage) is categorized into the business logic coherence dimension. For ease of understanding, taking the "online refund process" as an example: data such as "whether the reviewer has the corresponding job authorization" is categorized into the permission dimension; the link trajectory of "order system → risk control system → settlement system → bank channel" and whether a controlled dedicated line is used, and whether a specified encryption algorithm is adopted, are categorized into the data transmission dimension; and the instruction call order of "approval → review → disbursement" and the response time of each stage are categorized into the business logic dimension. This classification ensures that "same category is compared with same category" during subsequent verification, avoiding confusion between indicators across dimensions.

[0030] Subsequently, for each category of categorized data, the corresponding risk dimension's judgment rules are sequentially applied, and the specific judgment conditions are compared point by point to see if they are met. The single-dimensional comparison results are recorded for each data item. In implementation, the rule engine generates detailed entries for each data item: "Judgment Condition—Compliant / Non-compliant—Evidence." For example, in the permission dimension, the rule requires that "review nodes must be performed by personnel with review positions who have passed the annual qualification review." If it is found that the review of a refund was completed by a "temporary account" and that account is not on the authorization list, then "Non-compliant" is output, and the evidence is fixed as "inconsistent position + no annual review record." In the data transmission dimension, if the rule requires that "sensitive fields must be transmitted encrypted in a controlled channel," but the log shows that the message was sent out via unconventional tools and transmitted in plaintext, then "Non-compliant" is output, and "transmission path out of bounds + unencrypted" is recorded. In the business logic dimension, if the rule requires that "review can only proceed after the audit is completed and the risk control verification is passed," but the trajectory shows "audit → disbursement," skipping the review, then "Non-compliant" is output, and "sequence break" is recorded. All the above comparison results are recorded as single-dimensional conclusions in the database, forming a clear and traceable review detail.

[0031] Next, the multi-dimensional comparison results of the same node are correlated and verified to identify potential data contradictions between dimensions. Correlation verification uses "process instance number + node identifier + timestamp" as the primary key to pair the three types of results: permissions, data transmission, and business logic, checking for any conflicting situations. For example, if the business logic dimension records "the review node has been executed normally," but the permissions dimension shows "the review node has no legitimate executor," it is determined to be a "dimensional contradiction—logic is completed, permissions are invalid." Similarly, if the data transmission dimension shows "the message must pass through the risk control system," but the business logic dimension's sequence does not include a "risk control verification" step, this is also a contradiction. Furthermore, if the permissions dimension shows two mutually exclusive positions operating on the same node simultaneously, but the business logic dimension only allows single-person sequential processing, this also constitutes a contradiction. To address this, a consistency rule base is established, such as "if the logic dimension determines that a node has been executed, then the corresponding node must have a legitimate authorized entity" and "if the data transmission path includes a necessary node, then the corresponding step must appear in the logical sequence," to unify the judgment criteria and avoid false positives and false negatives.

[0032] After the correlation verification is completed, two types of datasets are extracted: one is data with a "discrepancy" result in a single dimension comparison, and the other is data that, although compliant in each dimension individually, has a "correlation contradiction" between dimensions. For each extracted data, its risk dimension and the specific location of the node that generated the data must be clearly identified, including key information such as process name, node name (or number), system to which the node belongs, timestamp, operator (if involving permission dimension) or transmission link (if involving data transmission dimension). For example, for records with a "review → disbursement" jump step, the system is marked "Business logic coherence dimension—settlement system—disbursement node—sequence break"; for records with "temporary account execution review", the system is marked "Node operation permission matching degree dimension—approval system—review node—position and authorization list inconsistency"; for records with "message bypassing the risk control system", the system is marked "Process data transmission compliance dimension—integrated bus—risk control before and after link—transmission path out of bounds". This step ensures that the problem point is located to "which specific dimension and which node", which facilitates subsequent strategy selection and rectification loop closure.

[0033] Finally, unique identifiers are generated for the extracted data at their risk dimensions and node locations, and "disagreement judgment conditions" and "contradiction types" are embedded in the identifiers for visualization and subsequent tracking. The unique identifiers include, but are not limited to: a unique identifier, risk dimension, process instance number, node location, triggered judgment condition number and text description, contradiction type (e.g., "permission-logic conflict," "logic-transmission conflict"), evidence summary (e.g., actual position, actual link, actual sequence, and response time outside the threshold), severity level (e.g., warning, general, severe), and discovery time. Using the refund example, an identifier can be presented as: "Identifier R-20240920-0001; Dimension: Business logic coherence; Node: Disbursement; Non-compliance condition: Review must be completed before disbursement; Conflict type: None; Evidence: Tracking shows disbursement directly after review, lacking a review node; Severity level: Severe." Another example is: "Identifier R-20240920-0002; Dimension: Node operation permission matching degree; Node: Review; Non-compliance condition: The executor must be in a review position and pass the annual qualification review; Conflict type: Conflict with the logical dimension (logic shows the node has been completed); Evidence: The executor is a temporary account, not on the authorization list; Severity level: Moderate." Through this standardized identifier, the management terminal can quickly filter and sort by dimension, node, and severity level, supporting real-time alerts.

[0034] In a preferred embodiment, step S5 includes a risk handling suggestion that includes a node permission adjustment scheme and a data transmission path optimization scheme.

[0035] In a preferred embodiment, step S5, which involves retrieving a preset risk management strategy library based on the marked risk dimension and node position, and matching risk management suggestions corresponding to the current risk characteristics from the risk management strategy library, is as follows: In this embodiment, the risk dimension name and node location number are first extracted from the tagging information output in step S4, and then combined to generate query keywords for strategy retrieval. To ensure the uniqueness of the retrieval scope, the keywords are generated using a concatenation method of "business process name + version number + node location number + risk dimension name," and the characters are uniformly standardized to avoid confusion caused by processes with the same name or parallel versions. For example, in "Online Refund Process (Version 5)," if the tagging result is "Node Operation Permission Matching Degree - Review Node (Number 03)," the generated query keyword is "Online Refund Process - Version 5 - Node 03 - Permission." If potential name duplication is detected (such as the same combination appearing across business domains), "business domain identifier and affiliated organization code" are automatically appended, ultimately ensuring that a keyword can only point to a specific query space, thereby preventing ambiguity in subsequent searches.

[0036] Based on the aforementioned query keywords, the system quickly locates the corresponding dedicated risk handling strategy library for each risk dimension within the pre-defined categorized storage system. The categorized storage system is physically and logically divided according to risk dimensions, with separate "Permission Dimension Strategy Area," "Data Transmission Dimension Strategy Area," and "Business Logic Dimension Strategy Area." Each strategy area contains a general strategy template, detailed applicable conditions, implementation steps, rollback contingency plans, and effectiveness evaluation indicators. It also features field-based search indexes, such as "node location number, system name, trigger condition, severity level, and historical success rate," ensuring accurate and efficient retrieval within the same dimension. Continuing with the previous example, query keywords pointing to the "Refund Process - Version 5 - Node 03" subdirectory within the "Permission Dimension Strategy Area" will limit subsequent matching to this subdirectory and its associated indexes, avoiding confusion between permission issues and data transmission or business logic issues.

[0037] After locating the target strategy library, historical risk handling records associated with the "node location number" are retrieved as a preliminary screening basis. Historical records contain information on risk events that occurred in the same node and within the same or similar business context, along with their closed-loop handling details. This includes summaries of problem characteristics, the handling solutions adopted, implementation timing, required approval levels, supporting monitoring points, handling duration, and result evaluation (e.g., false alarm rate, recurrence rate, compliance review approval status). These historical records are compared with current risk characteristics, prioritizing records with "consistent problem causes, similar triggering conditions, and system version compatibility" as candidates. For example, if the current problem is "unauthorized operation by a temporary account at the review node," and multiple successful handling cases related to "temporary accounts not on the authorization list," "mutually exclusive positions online simultaneously," and "missing annual qualification review" are found in the historical records, the strategy entries corresponding to these cases are marked as priority candidates to narrow down the subsequent precise matching range and improve the usability of recommendations.

[0038] Next, the precise matching phase begins: the "current risk feature set" is compared one by one with the processing strategies in the strategy library, and priority matching is implemented based on the candidate set from the previous step. The comparison elements include at least: triggering scenario (e.g., peak period), preconditions (e.g., whether risk control verification has been completed), cause of the problem (e.g., missing permission configuration or out-of-bounds transmission path), scope of impact (which subsystems and personnel are involved), control constraints (whether it needs to be implemented without downtime), and target effectiveness (reducing recurrence rate, meeting specific requirements of regulatory clauses). A step-by-step verification method is used; only when all four key elements—"triggering scenario, cause, constraints, and target effectiveness"—are consistent is the strategy determined to be a "perfect fit." Continuing with the permission issue example, if a strategy entry explicitly states "revoke the execution permission of temporary accounts at the review node; refill authorization by position and level; enable dual-person review and set time window limits; add mutual exclusion verification for approvals entering the review node," and this entry has been verified as effective in the same version of the workflow, then it is selected as the preferred solution for risk handling recommendations. The same applies to scenarios involving data transmission and business logic: If the problem is "the message bypasses the risk control system and is not encrypted", then the combination of "forced routing through the risk control system, enabling the controlled channel, adopting the specified encryption method, and issuing interception and rerouting policies at the integrated bus" will be matched first; if the problem is "the process sequence is broken and skips the review", then the policy item of "adding a forced verification node in the process orchestration engine, setting a rollback and compensation mechanism, and automatically blocking and alarming abnormal jumps" will be matched.

[0039] Finally, the selected risk handling recommendations are validated for their adaptability to the business scenario. Once confirmed to be correct, they are used as the final output. The adaptability validation revolves around three aspects: First, technical feasibility verification, checking whether the system where the target node is located has the necessary function switches, configuration items, and interfaces for implementation, and whether the implementation will affect parallel processes; second, business continuity assessment, evaluating the impact of implementing the strategy at different times, and, if necessary, choosing to implement it during off-peak hours or using a phased rollout approach; third, compliance consistency review, confirming that the strategy content is consistent with regulatory requirements by comparing it with the compliance clause list, paying particular attention to hard requirements such as the principle of least privilege, controlled transmission links, and essential business processes. Taking "revoke temporary account permissions and enable dual-person review" as an example, the process first involves rehearsing authorization matrix adjustments and approval mutual exclusion verification in a pre-production environment, followed by a phased rollout to a small group of people in a real environment. During this process, monitoring and alarm points and rollback contingency plans are implemented. If verification shows that the strategy does not cause abnormal processing time or downstream payment delays at the current "review node (number 03)," and it passes compliance review, then the strategy is confirmed as the final output and pushed to the business process management terminal along with the implementation steps, impact assessment, and rollback plan. Through these steps, the risk handling recommendations accurately match the problem characteristics and ensure that they are executable, traceable, and auditable in the current business scenario.

[0040] In a preferred embodiment, in step S6, the review information includes node information, operation data, risk marking results, and risk handling suggestions.

[0041] In a preferred embodiment, step S6 specifically involves the following process: In this embodiment, after strategy matching is completed, the "risk dimension, node location, and corresponding risk handling suggestions" are immediately encapsulated in a structured data format and pushed to the business process management terminal via the internal message bus. Simultaneously, the data is persistently stored in the "business process review database." To ensure that managers can quickly locate and handle the situation, the pushed data includes: process name and version, process instance identifier, node location number and node name, risk dimension (such as node operation permission matching degree, process data transmission compliance, and business logic coherence between nodes), non-compliance judgment conditions, suggested handling solutions (including implementation steps, impact assessment, and rollback contingency plans), severity level, and timestamp. Upon receiving the data, the terminal displays it in the form of an alarm panel and provides one-click access to the corresponding process orchestration and permission configuration interface. Simultaneously, all information from this review will be written into the review database, including but not limited to: node information (system, node number, upstream and downstream relationships), operation data (collection time, executor or account, transmission link and encryption method, instruction interaction sequence and response time), risk marking results (single-dimensional comparison conclusion, inter-dimensional correlation verification conclusion, evidence summary), risk handling suggestions (strategy number, applicable conditions, expected results, historical success rate), review batch and version number, etc. Sensitive data will be de-identified and encrypted before being stored in the database to ensure auditability and compliance. Taking the "online refund process" as an example, if the review finds a "review → disbursement" skip step, an entry will be pushed to the management terminal: "Business logic coherence - disbursement node - non-compliance: review must be completed before disbursement - handling suggestion: add mandatory verification and set automatic rollback in the process orchestration engine". At the same time, a complete record will be generated in the database, including the node trajectory of the instance, the actual response time distribution, the evidence screenshot summary of unauthorized or skipped steps, the suggested strategy and its rollback plan. Through the above mechanism, managers can view and implement rectification in real time on the terminal. All subsequent actions and results will also be written back to the same review record, forming a closed loop of "discovery - suggestion - implementation - verification", providing reliable data basis for future review, auditing and continuous optimization.

[0042] The foregoing has provided a detailed description of one embodiment of the present invention, but this description is merely a preferred embodiment and should not be construed as limiting the scope of the invention. All equivalent variations and modifications made within the scope of the claims of this invention should still fall within the patent coverage of this invention.

Claims

1. A risk control method for business process review, characterized in that, Includes the following steps: S1: Obtain all node information of the target business process, and determine the risk dimensions for review of the business process based on the compliance requirements of the domain to which the business process belongs; the risk dimensions include the matching degree of node operation permissions, compliance of process data transmission, and the consistency of business logic between nodes; S2: For each risk dimension, extract the characteristic parameters of the normal operation of the business process under that dimension, and establish risk judgment rules for each risk dimension based on the characteristic parameters. S3: Real-time collection of operational data generated at each node of the target business process during runtime; S4: Substitute the collected operational data into the risk judgment rules corresponding to each risk dimension, verify whether the operational data conforms to the risk judgment rules one by one, and mark the risk dimensions and node positions corresponding to the operational data that does not conform to the risk judgment rules. S5: Based on the marked risk dimension and node position, retrieve the preset risk handling strategy library under that risk dimension, and match the risk handling suggestions corresponding to the current risk characteristics from the risk handling strategy library; S6: Send the marked risk dimensions, node locations, and corresponding risk handling suggestions to the business process management terminal, and store all information from this business process review in the business process review database.

2. The risk control method for business process review according to claim 1, characterized in that, In step S1, the process of determining the risk dimensions of the business process review based on the compliance requirements of the domain to which the business process belongs is as follows: Retrieve all compliance requirement documents for the target business process's domain, analyze the constraint clauses in the documents related to the operation of the business process, and form a list of compliance clauses; Each clause in the compliance clause list is categorized by risk type, and the risks involved in the clauses are identified into three categories: operational permissions, data transmission, and business logic. The risk types are categorized by the matching degree of operation permissions to the nodes, the compliance of data transmission to the process data transmission, and the consistency of business logic between nodes. After verifying that the risk type corresponding to each compliance clause has been matched with the risk dimension without any omissions, the risk dimension for the review of this business process is determined.

3. The risk control method for business process review according to claim 1, characterized in that, In step S2, the risk assessment rule is used to determine whether there is a risk in the business process operation under this dimension.

4. The risk control method for business process review according to claim 3, characterized in that, In step S2, the process of extracting feature parameters for the normal operation of the business process under each risk dimension, and establishing risk judgment rules corresponding to each risk dimension based on the feature parameters, is as follows: For each risk dimension, collect historical operational data when the business process under that dimension is running normally. The historical operational data covers all operational steps involved in that dimension. Stable operational indicators are extracted from historical operational data as feature parameters. Feature parameters for node operation permission matching include the correspondence between operator positions and operation permissions. Feature parameters for compliance of process data transmission include the range of transmission nodes and encryption method. Feature parameters for the continuity of business logic between nodes include the order of instruction interaction and the response time range. Each feature parameter is transformed into a specific judgment condition. The judgment condition for the matching degree of node operation permission is that the operator's position must be consistent with the position in the operation permission list. The judgment condition for the compliance of process data transmission is that the transmission path is within the preset node range and a specified encryption method is used. The judgment condition for the continuity of business logic between nodes is that the order of instruction interaction conforms to the preset process and the response time is within the range of feature parameters, thus forming risk judgment rules for each risk dimension. Select another portion of historical operational data that is running normally, substitute it into the risk assessment rule for verification, and confirm that all data comply with the rule, then determine that the risk assessment rule is valid.

5. A risk control method for business process review according to claim 1, characterized in that, In step S3, the operation data includes the permission information of the node operators, the transmission path information of the process data, and the interaction information of business instructions between nodes.

6. The risk control method for business process review according to claim 1, characterized in that, In step S4, the process of verifying whether each piece of operational data conforms to the risk assessment rules and marking the risk dimension and node position corresponding to operational data that does not conform to the risk assessment rules is as follows: The collected operational data is categorized by risk dimension. The node operator's permission information corresponds to the node operation permission matching degree, the transmission path information corresponds to the compliance of process data transmission, and the instruction interaction information corresponds to the business logic coherence between nodes. For each category of data, substitute the corresponding risk dimension judgment rules into the data one by one, compare the data with the judgment conditions in the rules, and record the single-dimensional comparison results. Perform correlation verification on the multi-dimensional comparison results of the same node to check for data inconsistencies between dimensions; Extract data whose single-dimensional comparison results are inconsistent or have contradictory correlation verification, and determine the risk dimension to which it belongs and the specific location of the node that generated the data. Add unique identifiers to the risk dimensions and node locations corresponding to the extracted data. The identifiers contain the judgment conditions for discrepancies and the types of contradictions.

7. A risk control method for business process review according to claim 1, characterized in that, In step S5, the risk handling suggestions include node permission adjustment schemes and data transmission path optimization schemes.

8. A risk control method for business process review according to claim 1, characterized in that, In step S5, the process of retrieving a preset risk management strategy library based on the marked risk dimension and node position, and matching risk management suggestions corresponding to the current risk characteristics from the risk management strategy library, is as follows: Extract the risk dimensions and node positions from the tagging information, and combine the risk dimension names and node position numbers into strategy library query keywords to ensure that the keywords uniquely correspond to the target query range. Based on the query keywords, locate the risk management strategy library specific to this risk dimension in the preset classification storage system, and divide it into independent storage areas according to the risk dimension name; Retrieve historical risk handling records associated with node location numbers from the strategy library, and extract matching items from the historical records that are consistent with the current risk characteristics as a preliminary screening basis; The current risk characteristics are compared one by one with the processing strategies in the strategy library. Based on the preliminary screening criteria, the processing strategy that perfectly matches the risk characteristics is selected as the risk processing recommendation. Verify whether the selected risk handling suggestion is suitable for the business scenario of the current node. If it is confirmed to be suitable, determine that the risk handling suggestion is the final output.

9. A risk control method for business process review according to claim 1, characterized in that, In step S6, all the information reviewed includes node information, operation data, risk marking results, and risk handling suggestions.

Images