A risk control method for business process review

Abstract

The application discloses a risk control method for business process review, and belongs to the technical field of process review, and specifically comprises the following steps: acquiring all node information of a target business process, determining risk dimensions of the business process review according to compliance requirements of a field to which the business process belongs; the risk dimensions comprise node operation permission matching degree, process data transmission compliance, and inter-node business logic coherence; for each risk dimension, risk judgment rules corresponding to each risk dimension are established based on characteristic parameters; operation data generated by each node of the target business process during operation is collected in real time; the collected operation data is substituted into the risk judgment rules corresponding to each risk dimension respectively, risk dimensions and node positions corresponding to operation data that do not conform to the risk judgment rules are marked, a preset risk treatment strategy library under the risk dimensions is called, and a risk treatment suggestion corresponding to a current risk characteristic is matched from the risk treatment strategy library.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of process review, in particular to a risk control method for business process review. BACKGROUND

[0002] Enterprises usually rely on business process management platforms, office automation systems and internal control systems to conduct compliance review and risk monitoring on process execution. Common practices include: configuring approval nodes and conditional branches in the process engine, restricting personnel permissions based on role-based access control; combining log auditing, database auditing and security information and event management platform to gather operation records; matching and intercepting keywords, numerical thresholds and black and white lists in the form of rule library; cooperating with data leakage prevention systems, private line transmission and encryption storage at the data level; some institutions also try to use anomaly detection and statistical analysis to identify abnormal trajectories.

[0003] Overall, these solutions can to some extent discover unauthorized operations, illegal transmissions and abnormal flow, but they are mostly based on system function configuration or scattered security tools, lacking an integrated methodology for business process review scenarios and a traceable closed loop from clauses to rules to nodes. Specifically, the existing technology has the problems of single risk review dimension, lack of clear basis for judgment rules, inability to accurately locate risk points after operation data collection, non-targeted risk processing scheme, and the fact that review information is not stored in the system, making it impossible to trace. SUMMARY

[0004] The purpose of the present application is to provide a risk control method for business process review to solve the problems in the background art.

[0005] The purpose of the present application can be achieved by the following technical solutions:

[0006] A risk control method for business process review, comprising the following steps:

[0007] S1: Obtain all node information of the target business process, and determine the risk dimensions of the business process review according to the compliance requirements of the business process domain; the risk dimensions include node operation permission matching degree, process data transmission compliance, and node-to-node business logic coherence;

[0008] S2: For each risk dimension, extract the characteristic parameters of the business process under normal operation in that dimension, and establish risk judgment rules corresponding to each risk dimension based on the characteristic parameters;

[0009] S3: Real-time collection of operation data generated by each node of the target business process;

[0010] S4: the collected operation data are substituted into the risk judgment rules corresponding to each risk dimension respectively, whether the operation data conform to the risk judgment rules is verified one by one, and the risk dimension and node position corresponding to the operation data not conforming to the risk judgment rules are marked;

[0011] S5: according to the marked risk dimension and node position, a preset risk processing strategy library under the risk dimension is called, and a risk processing suggestion corresponding to the current risk feature is matched from the risk processing strategy library;

[0012] S6: the marked risk dimension, node position and corresponding risk processing suggestion are sent to a business process management terminal, and all information of the current business process review is stored to a business process review database.

[0013] As a further scheme of the application: in the step S1, the process of determining the risk dimension of the business process review according to the compliance requirements of the field to which the business process belongs is:

[0014] All compliance requirement files of the field to which the target business process belongs are called, the constraint clauses related to the operation of the business process in the files are parsed, and a compliance clause list is formed;

[0015] Each clause in the compliance clause list is classified by risk type, and the risk types involved by the clause are determined to be operation permission, data transmission and business logic;

[0016] The operation permission risk type corresponds to the node operation permission matching degree, the data transmission type corresponds to the process data transmission compliance, and the business logic type corresponds to the node business logic continuity;

[0017] After verifying that the risk type corresponding to each compliance clause has been matched to the risk dimension without omission, the risk dimension of the business process review is determined.

[0018] As a further scheme of the application: in the step S2, the risk judgment rule is used to define whether the operation of the business process in the dimension exists risk.

[0019] As a further scheme of the application: in the step S2, the process of extracting the feature parameters of the normal operation of the business process in each risk dimension and establishing the risk judgment rules corresponding to each risk dimension based on the feature parameters is:

[0020] For each risk dimension, the historical operation data of the business process when normally operating in the dimension are collected, and the historical operation data cover all operation links involved by the dimension;

[0021] The stable operation indicators appearing in historical operation data are extracted as characteristic parameters, the characteristic parameters of the matching degree of node operation authority include the correspondence between the operation personnel post and the operation authority, the characteristic parameters of the compliance of process data transmission include the transmission node range and the encryption mode, and the characteristic parameters of the coherence of business logic between nodes include the instruction interaction sequence and the response time range;

[0022] Each characteristic parameter is converted into a specific judgment condition, the judgment condition of the matching degree of node operation authority is that the operation personnel post must be consistent with the post in the operation authority list, the judgment condition of the compliance of process data transmission is that the transmission path is within the preset node range and adopts the specified encryption mode, and the judgment condition of the coherence of business logic between nodes is that the instruction interaction sequence conforms to the preset process and the response time is within the characteristic parameter range, thereby forming the risk judgment rules of each risk dimension;

[0023] Another part of the historical operation data in normal operation is selected and substituted into the risk judgment rules for verification, and after confirming that all the data conform to the rules, it is determined that the risk judgment rules are effective.

[0024] As a further scheme of the application, in the step S3, the operation data includes the authority information of the node operator, the transmission path information of the process data and the interaction information of the business instructions between nodes.

[0025] As a further scheme of the application, in the step S4, the process of verifying whether the operation data conforms to the risk judgment rules one by one and marking the risk dimension and the node position corresponding to the operation data not conforming to the risk judgment rules is as follows:

[0026] The collected operation data is classified according to the risk dimension, the authority information of the node operator corresponds to the matching degree of node operation authority, the transmission path information corresponds to the compliance of process data transmission, and the instruction interaction information corresponds to the coherence of business logic between nodes.

[0027] For each type of classified data, the judgment rule of the corresponding risk dimension is substituted in turn, and whether the data and the judgment condition in the rule are consistent is compared point by point, and the single-dimension comparison result is recorded.

[0028] The multi-dimension comparison results of the same node are associated and verified, and whether there is a contradiction between the dimensions is checked.

[0029] The data with inconsistent single-dimension comparison results or associated verification contradictions are extracted, and the risk dimension and the specific node position where the data are generated are determined;

[0030] The risk dimension and the node position corresponding to the extracted data are added with a special identifier, and the inconsistent judgment condition and the contradiction type are included in the identifier.

[0031] As a further scheme of the present application: in the step S5, the risk processing suggestion comprises a node permission adjustment scheme and a data transmission path optimization scheme.

[0032] As a further scheme of the present application: in the step S5, the process of retrieving a preset risk processing strategy library according to the marked risk dimension and node position, and matching the risk processing suggestion corresponding to the current risk feature from the risk processing strategy library is as follows:

[0033] The risk dimension and node position in the marked information are extracted, and the risk dimension name and node position number are combined as a strategy library query keyword to ensure that the keyword uniquely corresponds to the target query range;

[0034] According to the query keyword, a risk processing strategy library dedicated to the risk dimension is located in a preset classified storage system, and an independent storage area is divided according to the risk dimension name;

[0035] The historical risk processing records associated with the node position number are retrieved from the strategy library, and the matching items consistent with the current risk feature in the historical records are extracted as the preliminary screening basis;

[0036] The current risk feature is compared with the processing strategies in the strategy library one by one, and the processing strategy that completely matches the risk feature is selected as the risk processing suggestion in combination with the preliminary screening basis;

[0037] It is verified whether the selected risk processing suggestion is suitable for the business scenario of the current node position, and after confirmation of the adaptation, the risk processing suggestion is determined as the final output content.

[0038] As a further scheme of the present application: in the step S6, the reviewed information comprises node information, operation data, risk marking result and risk processing suggestion.

[0039] The present application has the following advantages:

[0040] The present application overcomes the limitations of the prior art by first decomposing supervision and internal system into three dimensions that can be operated, and then forming quantitative and verifiable judgment rules based on normal operation history samples and feature parameters, thereby avoiding the randomness and irretraceability caused by experience threshold. The real-time collected permission information, transmission path information and instruction interaction information are compared by dimension to realize point-by-point verification and evidence solidification; once a non-compliance item is found, the accuracy and response speed of abnormal positioning are significantly improved, the false positives and false negatives are reduced, and the investigation link and disposal time are shortened.

[0041] The application solves the pain point of non-targeted rectification in the prior art by automatically retrieving the exclusive policy library of the dimension according to the marked dimension and node, selecting a processing scheme that completely matches the current risk characteristics, and outputting an executable suggestion for a specific node. Meanwhile, all node information, operation data, risk marking results and processing suggestions are written into a business process review database, versioned, structured and encrypted, providing traceable evidence for subsequent review, audit and regulatory spot checks; the effectiveness of policy execution can also be quantitatively evaluated, which in turn benefits the continuous optimization of rules and policy libraries. BRIEF DESCRIPTION OF DRAWINGS

[0042] The application will be further described below with reference to the drawings.

[0043] Figure 1 is a flowchart of a risk control method for business process review. DETAILED DESCRIPTION

[0044] The technical solutions in the embodiments of the application will be clearly and completely described below with reference to the drawings in the embodiments of the application. Obviously, the described embodiments are only part of the embodiments of the application, rather than all the embodiments. Based on the embodiments in the application, all other embodiments obtained by those skilled in the art without creative work fall within the scope of the application.

[0045] Please refer to Figure 1 The application is a risk control method for business process review, which comprises the following steps:

[0046] S1: Obtain all node information of a target business process, and determine the risk dimensions of the business process review according to the compliance requirements of the field to which the business process belongs; the risk dimensions include node operation permission matching degree, process data transmission compliance, and inter-node business logic coherence;

[0047] S2: For each risk dimension, extract the characteristic parameters of the normal operation of the business process under the dimension, and establish risk judgment rules corresponding to each risk dimension based on the characteristic parameters;

[0048] S3: Real-time collect operation data generated during the operation of each node of the target business process;

[0049] S4: Substitute the collected operation data into the risk judgment rules corresponding to each risk dimension respectively, verify whether the operation data meet the risk judgment rules one by one, and mark the risk dimensions and node positions corresponding to the operation data that do not meet the risk judgment rules;

[0050] S5: According to the marked risk dimension and node position, the preset risk processing strategy library under the risk dimension is called, and the risk processing suggestion corresponding to the current risk feature is matched from the risk processing strategy library;

[0051] S6: The marked risk dimension, node position and corresponding risk processing suggestion are sent to the business process management terminal, and all information of the business process review is stored to the business process review database.

[0052] In a preferred embodiment of the present application, in step S1, the process of determining the risk dimension of the business process review according to the compliance requirements of the field to which the business process belongs is:

[0053] Firstly, all compliance requirement files of the field to which the target business process belongs are called and parsed. A compliance document library can be established in advance, and the sources include: industry laws and regulations, regulatory agencies' normative documents, association or alliance standards, and enterprise internal systems and operating procedures. The text parsing module in the compliance engine performs chapter-clause level segmentation on the documents, and extracts constraint information directly related to the operation of the business process, such as "who can execute, under what conditions, how to handle data when executing, how to link between nodes" and other contents are structured annotated, forming a compliance clause list containing "clause number, source, clause original text, trigger condition, applicable node or link, data element, execution constraint" and other fields. For ease of understanding, an example can be given: taking "online refund process" as an example, common clauses in regulatory documents such as "refund initiation must be reviewed by non-original approver" "credentials containing personal sensitive information shall not be sent out through non-controlled channels" "refund can be submitted only after order status is completed and risk control verification is passed" and other clauses are identified and included in the list, which will be used for risk dimension determination and mapping later.

[0054] After obtaining the list of compliance clauses, the embodiment classifies each clause in the list into a risk type, and determines that the risk involved in the clause falls into one of the three categories: operation authority, data transmission, and business logic. The classification rules are as follows: if the clause emphasizes personnel identity, job responsibility, authorization level, approval isolation, or mutual exclusion control, it is classified into the “operation authority” category; if the clause restricts the transmission path of data, cross-system or cross-border flow, encryption and desensitization, storage and retention, or access control, it is classified into the “data transmission” category; if the clause involves preconditions, state transitions, time sequences, exception rollback, branching and merging of process nodes, etc., it is classified into the “business logic” category. Continuing with the aforementioned “online refund process” as an example, the clause “refund must be reviewed by two people and authorized by the supervisor” is classified as “operation authority”; the clause “attachments containing personal sensitive information cannot be sent out through instant messaging tools, and should be transmitted through a controlled channel and encrypted” is classified as “data transmission”; and the clause “only when the order status is completed and the risk control check is passed, can the refund node be entered, otherwise it should be rolled back to the verification node” is classified as “business logic”. Through such operable classification criteria, it is ensured that each clause can be stably and consistently classified into the corresponding risk type.

[0055] After completing the risk type classification, the embodiment establishes a one-to-one correspondence between the three risk types and the three risk dimensions adopted: the operation authority risk type corresponds to the node operation authority matching degree, the data transmission risk type corresponds to the process data transmission compliance, and the business logic risk type corresponds to the inter-node business logic continuity. To make the mapping more executable, the measurement and verification criteria of each dimension are also defined: for example, “node operation authority matching degree” takes the job responsibility matrix, authorization level table, and least privilege principle as the baseline to measure whether the actual authority of the node executor is consistent with the requirements; “process data transmission compliance” takes the controlled link whitelist, encryption strength threshold, desensitization strategy, and trace requirement as the verification basis to check whether the data meets the compliance when flowing between systems or across domains; and “inter-node business logic continuity” takes the state machine model, node dependency relationship, and exception handling strategy as the reference to check whether the preconditions are met, the branches are correct, and the rollback and compensation are reachable. For example, if the “audit node A → review node B → payment node C” is the prescribed order in the refund process, the runtime track will be compared, and if “directly from A to C” occurs, it is determined that there is a potential non-compliance in the “business logic continuity” dimension.

[0056] Finally, the matching coverage of compliance clauses and risk dimensions is comprehensively verified to ensure that "each compliance clause has been mapped to a certain risk dimension, and there is no omission or ambiguity". For this purpose, a "clause-risk dimension" table is generated, and the verification results are output by checking each clause. The three types of abnormalities, "uncategorized", "multiple classification conflicts", and "incomplete information", are marked and processed: uncategorized clauses will return to the analysis stage to supplement the elements; multiple classification conflicts are determined by priority rules (such as looking at the core constraint object of the clause subject-predicate-object first) to determine the final attribution; incomplete information is supplemented with trigger conditions or applicable nodes. Only when all clauses have a clear attribution, the risk dimension set used in this business process review is locked, and the coverage statement (including dimension definition, clause list covered, version number, and timestamp) is output. For example, in the practice of a certain e-commerce refund process, a total of 42 clauses are analyzed, including 18 "operation permissions", 12 "data transmission", and 12 "business logic", with a coverage rate of 100%. This ensures that the subsequent establishment of each dimension risk judgment rule has a solid and complete compliance basis, avoiding the review blind spot caused by the lack of dimensions.

[0057] In a preferred case of the present embodiment, in step S2, the risk judgment rule is used to determine whether there is a risk in the operation of the business process under the dimension.

[0058] In a preferred case of the present embodiment, in step S2, for each risk dimension, the process of extracting the characteristic parameters of the normal operation of the business process under the dimension and establishing the risk judgment rule corresponding to each risk dimension based on the characteristic parameters is as follows:

[0059] In the present embodiment, first, historical operation data of the business process in the normal operation state are collected for each risk dimension (node operation permission matching degree, process data transmission compliance, and node-to-node business logic continuity) to ensure that all running links involved in the dimension are covered. Data sources can include system audit logs, approval records, interface gateway call logs, message queue traces, and network device traces. To ensure representativeness, cross-period, cross-version, and cross-person samples are selected, and abnormal alarms, failure retries, and other abnormal samples are removed or labeled to avoid interference with subsequent feature extraction. For example, in the "online refund process", the permission dimension needs to collect the post and authorization records of each node "initiation-audit-review-disbursement"; the data transmission dimension needs to collect the links and message traces between the order system, the risk control system, the settlement system, and the bank channel; the business logic dimension needs to collect the node entry and exit sequence, state transition, and rollback records.

[0060] Next, the running indicators that stably appear in normal operation are mined from the historical operation data, and are identified as characteristic parameters. For the "node operation authority matching degree", the characteristic parameters at least include the corresponding relationship of "post-authority item" and the execution boundary of mutually exclusive posts; for the process data transmission compliance, the characteristic parameters include the allowed transmission node range (such as the closed loop of "order system → risk control system → settlement system → bank channel") and the specified encryption method (such as the advanced encryption standard or commercial cipher algorithm), and can include whether to use a controlled private line and a certificate validity period and other auxiliary parameters; for the inter-node business logic continuity, the characteristic parameters include the fixed sequence of instruction interaction, the acceptable branch condition and the typical response time range (which can be statistically calculated according to the percentile, such as the 95th percentile). For example, if the average response time of the "review" node is stable between 300-500 milliseconds in a large number of normal samples, and the sequence is always "audit → review → disbursement", it can be fixed as the characteristic of this dimension.

[0061] After obtaining the characteristic parameters, they are converted into explicit and executable judgment conditions, and then the risk judgment rules of each risk dimension are formed. Specifically, the judgment condition of the authority dimension is set as: the actual execution post of the node must be consistent with the authorized post in the authority list, and meet the minimum authority and mutual exclusion control requirements; the judgment condition of the data transmission dimension is set as: the actual transmission path must completely fall within the preset node range, the link needs to be a controlled channel, and the specified encryption method needs to be used to encrypt or desensitize the key data; the judgment condition of the business logic dimension is set as: the instruction interaction sequence must be consistent with the preset process Figure 1 , the trigger preconditions are complete, and the response time of each key node is within the range given by the characteristic parameters. Continuing the example of the refund, if "audit" is directly followed by "disbursement", or "risk check" is not completed before entering "review", it is determined by the rule as not meeting the "business logic continuity"; if the "disbursement" node is executed by a temporary account without authorization, it is determined as not meeting the operation authority matching degree; if the transaction message is sent outside the regular instant messaging tool and is not encrypted, it is determined as not meeting the data transmission compliance.

[0062] Finally, to verify the effectiveness of the rules, a set of mutually independent sample sets is selected from the normal operation history data and substituted into the above risk judgment rules for verification. If the verification result shows that all samples meet the corresponding conditions, it is determined that the rule can accurately depict normal behavior, and the rule is determined to be effective accordingly; if a small number of samples do not pass, it is necessary to backtrack to check whether the sample contains version switching or peak period characteristics, or to reasonably converge and fine-tune the threshold and range of the characteristic parameters. Taking the refund process as an example, ten thousand normal records are extracted from the past six months as a verification set, and if the pass rate reaches one hundred percent, the current rule set is frozen and labeled with version number and timestamp as the basis for subsequent real-time review; if it is found that the "holiday peak" causes the response time of individual nodes to float but still falls within the acceptable range of business, the upper time limit of the corresponding node is relaxed accordingly, while the hard conditions such as process order and authorization consistency are maintained unchanged to avoid false positives and false negatives.

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

[0064] In a preferred case of the embodiment, in the step S4, the process of verifying whether the operation data meets the risk judgment rule one by one and marking the risk dimension and node position corresponding to the operation data that does not meet the risk judgment rule is as follows:

[0065] In the embodiment, first, the collected operation data during the operation period is automatically classified and stored according to the risk dimension. The specific method is as follows: the permission information of the node operator (such as post, authorized level, mutually exclusive responsibility, and valid period) is classified into the node operation permission matching degree dimension; the transmission path information of the process data (such as starting node, target node, intermediate system passed, whether the transmission channel is controlled, whether it is encrypted or desensitized) is classified into the process data transmission compliance dimension; and the interaction information of the business instructions between nodes (such as calling sequence, pre-condition satisfaction, branch selection, rollback and compensation, and response time of each link) is classified into the node-to-node business logic coherence dimension. For ease of understanding, taking the "online refund process" as an example: data such as "whether the review personnel has the corresponding post authorization" is classified into the permission dimension; the link trajectory of "order system→risk control system→settlement system→bank channel" and whether a controlled private line is used and whether a specified encryption algorithm is used are classified into the data transmission dimension; and the instruction calling sequence of "audit→review→payment" and the response time of each link are classified into the business logic dimension. Such classification can ensure that "similar things are compared with similar things" during subsequent verification, avoiding confusion between dimensions.

[0066] Subsequently, for each type of classified data, the corresponding risk dimension judgment rule is substituted in turn, and the specific judgment conditions are compared point by point to see if they are met, and the single-dimension comparison results are recorded one by one. To achieve this, the rule engine generates a detailed entry of "judgment condition - conform / non-conform - evidence" for each piece of data. For example, in the authority dimension, the rule requires that "the review node must be executed by a person with a review post and pass the annual qualification review." When it is found that the review of a certain refund is completed by a "temporary account" and the account is not in the authorized list, "non-conform" is output, and the evidence is fixed as "post inconsistency + no annual review record"; in the data transmission dimension, if the rule requires "sensitive fields must be encrypted and transmitted in the controlled channel", and the log shows that the message is sent out by a non-standard tool and transmitted in plaintext, then "non-conform" is output, and "transmission path out of bounds + not encrypted" is recorded; in the business logic dimension, if the rule requires "after the audit is completed and the risk control check is passed, it can enter the review", and the track shows "audit → disbursement", skipping the review, then "non-conform" is output, and "sequence disruption" is recorded. The above comparison results are stored as single-dimension conclusions, forming a clear and traceable review detail.

[0067] Next, the multi-dimension comparison results of the same node are associated and checked to identify possible data contradictions between dimensions. The association check takes "process instance number + node identification + timestamp" as the primary key, and pairs the authority, data transmission and business logic three types of results to check if there are any mutually contradictory situations. For example: if the business logic dimension records "the review node has been normally executed", but the authority dimension shows "the review node has no legal executor", it is determined that there is a "dimension contradiction - logic completion, authority not established"; for example, the data transmission dimension shows that "the message must be sent through the risk control system", but the business logic dimension has no "risk control check" link in the sequence, which is also a contradiction; for example, the authority dimension shows that two mutually exclusive posts are operating at the same time in the same node, while the business logic dimension only allows single serial processing, which also constitutes a contradiction. Therefore, a consistency rule library is set, such as "if the logic dimension determines that the node has been executed, the corresponding node must have a legal authorized subject" and "if the data transmission path contains a mandatory node, the logic sequence must have a corresponding link", to unify the judgment standard and avoid false positives and omissions.

[0068] After the association check is completed, two types of data are extracted: one is the data with single-dimension comparison results of "inconsistency", and the other is the data with "association contradiction" between dimensions although each dimension is compliant. For each extracted data, the risk dimension to which it belongs and the specific location of the node generating the data are determined, including key information such as process name, node name (or number), node belonging system, timestamp, operator (if involving permission dimension) or transmission link (if involving data transmission dimension). For example: for the record of "audit → disbursement" jump, mark "business logic coherence dimension - settlement system - disbursement node - sequence break"; for the record of "temporary account performing review", mark "node operation permission matching degree dimension - approval system - review node - post and authorization list inconsistency"; for the record of "message bypassing the risk control system", mark "process data transmission compliance dimension - integrated bus - pre and post link of risk control - transmission path boundary crossing". This step ensures that the problem point is located to "which dimension and which node", facilitating subsequent strategy selection and rectification closed loop.

[0069] Finally, a dedicated identifier is generated for the above extracted data in its risk dimension and node location, and the "inconsistent judgment condition" and "contradiction type" are embedded in the identifier for visual display and subsequent tracking. The dedicated identifier includes but is not limited to: unique identifier, risk dimension, process instance number, node location, triggered judgment condition number and text description, contradiction type (such as "permission-logic conflict" and "logic-transmission conflict"), evidence summary (such as actual post, actual link, actual sequence and response time outside the threshold), severity level (such as prompt, general, and serious), and discovery time. Following the example of the withdrawal display, an identifier can be presented as: "identifier R-20240920-0001; dimension: business logic coherence; node: disbursement; inconsistent condition: disbursement must be completed after review; contradiction type: none; evidence: trajectory shows disbursement directly after review, missing review node; severity level: serious." For example: "identifier R-20240920-0002; dimension: node operation permission matching degree; node: review; inconsistent condition: performer must be a review post and pass annual qualification review; contradiction type: conflict with logic dimension (logic shows that the node has been completed); evidence: performer is a temporary account, not in the authorized list; severity level: general." Through such standardized identifiers, the management terminal can quickly filter and sort by dimension, node, and severity level, supporting real-time early warning.

[0070] In a preferred case of the embodiment, in the step S5, the risk processing suggestion includes a node permission adjustment scheme and a data transmission path optimization scheme.

[0071] In a preferred case of the embodiment, in step S5, the process of retrieving the preset risk handling strategy library under the risk dimension and matching the risk handling suggestion corresponding to the current risk feature from the risk handling strategy library according to the marked risk dimension and node position is as follows:

[0072] In the embodiment, first, the risk dimension name and node position number are extracted from the marked information output in step S4, and the two are combined to generate a query keyword for strategy retrieval. To ensure the uniqueness of the retrieval range, the splicing mode of "business process name + version number + node position number + risk dimension name" is adopted when generating the keyword, and the characters are uniformly standardized to avoid confusion caused by the same process or parallel version. For example, in the "online refund process (version five)", if the marking result is "node operation permission matching degree - review node (number 03)", the generated query keyword is "online refund process - version five - node 03 - permission". If it is detected that the keyword still has potential homonymy (such as the same combination appearing across business domains), "business domain identifier and institution code" is automatically appended, and finally it is ensured that one keyword can only point to one specific query space, so that the subsequent search does not produce ambiguity.

[0073] Based on the above query keyword, the exclusive risk handling strategy library corresponding to the risk dimension is quickly located in the preset classified storage system. The classified storage system is physically and logically divided according to the risk dimension, and is provided with "permission dimension strategy area", "data transmission dimension strategy area" and "business logic dimension strategy area". Each strategy area contains general strategy templates, refined applicable conditions, implementation steps, rollback plans and effectiveness evaluation indicators and other information structures; and field-based retrieval indexes such as "node position number, system name, trigger condition, severity level, historical success rate" are set to ensure accurate and efficient retrieval within the same dimension. Continuing the foregoing example, the query keyword points to the "refund process - version five - node 03" subdirectory of the "permission dimension strategy area", so that subsequent matching can be limited in the subdirectory and its associated index, avoiding confusing permission problems with data transmission or business logic problems.

[0074] After locating the target policy library, the historical risk handling records associated with the "node position number" will be called as the preliminary screening basis. The historical records contain risk events and their handling closed-loop information that occurred in the same node, the same or similar business context in the past, such as problem characteristic summary, adopted handling scheme, implementation timing, required approval level, supporting monitoring points, handling duration and result evaluation (e.g. false positive rate, recurrence rate, compliance review pass rate, etc.). Compare these historical records with the current risk characteristics, and preferentially extract records with "consistent problem causes, similar trigger conditions, and compatible system versions" as candidates. For example, if the current problem is "temporary account over-privilege operation in review node", find multiple successful disposal cases related to "temporary account not in authorized list", "mutually exclusive posts online at the same time", and "missing annual qualification review" in the historical records, then mark the corresponding policy entries as priority candidates for narrowing the subsequent precise matching range and improving the availability of recommendations.

[0075] Subsequently, enter the precise matching stage: compare the "current risk characteristic set" with the handling strategies in the policy library one by one, and implement priority matching combined with the candidate set from the previous step. The comparison elements include at least: trigger scenario (e.g. whether it is peak period), preconditions (such as whether risk control verification has been completed), problem causes (such as missing permission configuration or transmission path boundary crossing), impact range (which subsystems and personnel are involved), control constraints (whether implementation needs to be non-stop), and target effectiveness (reducing recurrence rate, meeting specific requirements of regulatory clauses). Adopt the way of checking each item one by one, only when the four key elements of "trigger scenario, cause, constraint, and effectiveness target" are all consistent, the strategy is determined as "completely consistent". Continue with the above-mentioned permission problem as an example, if a policy entry clearly states "revoke the execution privilege of temporary accounts in review nodes; backfill authorization according to post and job level; enable two-person review and set time window restrictions; add mutual exclusion verification for approval to enter review nodes", and this entry has been verified effective in the same version process, then it is selected as the preferred solution for risk handling. The same applies to the scenario of data transmission and business logic: if the problem is "message bypassing the risk control system and not encrypted", then preferentially match the combination scheme of "forcing routing through the risk control system, enabling controlled channels, adopting the specified encryption method, and issuing interception and rerouting strategies at the integration bus"; if the problem is "flow sequence broken and skipping review", then match the policy entry of "adding a mandatory verification node in the process orchestration engine, setting rollback and compensation mechanisms, automatically blocking and alerting abnormal jumps".

[0076] Finally, the selected risk handling suggestions are verified for business scenario adaptability, and after confirmation, they are used as the final output. The adaptability verification is carried out around three aspects: first, technical feasibility check, checking whether the target node system has the required function switches, configuration items and interfaces for implementation, and whether the implementation will affect the parallel process; second, business continuity assessment, assessing the impact of executing the strategy at different times, and if necessary, selecting to take effect at low peak times or using a gray method to enable in batches; third, compliance consistency review, checking the strategy content against the compliance clause list to confirm that it is consistent with regulatory requirements, especially focusing on the minimum authority principle, controlled transmission link and mandatory business link hard requirements. Taking "revoking the temporary account permission and enabling double review" as an example, the authorization matrix adjustment and approval mutual exclusion verification will be performed in the pre-production environment first, and then a small range of people in the real environment will be used for gray release, with supporting online monitoring alarm points and rollback plans during the period; if the verification shows that the strategy does not cause processing time abnormality at the current "review node (No. 03)", nor causes downstream payment delay, and is passed by the compliance review, the strategy will be confirmed as the final output content, and will be pushed to the business process management terminal together with the implementation steps, impact assessment and rollback plan. Through the above steps, the risk handling suggestions are precisely matched with the problem characteristics, and are ensured to be executable, traceable and auditable in the current node position of the business scenario.

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

[0078] In a preferred case of the embodiment, in the step S6, the specific process is:

[0079] In this embodiment, after completing the policy matching, the "risk dimension, node position, corresponding risk processing suggestion" is immediately packaged in a structured data format, pushed to the business process management terminal through the internal message bus, and the persistent storage to the "business process review database" is completed synchronously. To ensure that the management personnel can quickly locate and dispose, the pushed data includes: process name and version, process instance identification, node position number and node name, risk dimension (such as node operation permission matching degree, process data transmission compliance, node-to-node business logic coherence), non-compliance judgment condition, recommended processing scheme (including implementation steps, impact assessment and rollback plan), severity level and timestamp. The terminal displays it in the form of an alarm panel after receiving it, and provides one-key jump to the corresponding process arrangement and permission configuration interface. At the same time, all the information of this review is written into the review database, including but not limited to: node information (system to which it belongs, node number, upstream and downstream relationship), operation data (collection time, executor or account, transmission link and encryption method, instruction interaction sequence and response time), risk marking result (single-dimension comparison conclusion, inter-dimension association verification conclusion, evidence abstract), risk processing suggestion (strategy number, applicable condition, expected effectiveness, historical success rate), review batch and version number, etc.; sensitive data is desensitized and encrypted before being stored in the database to ensure auditability and compliance. Taking the "online refund process" as an example, if this review finds that "review → disbursement" is skipped, it will push the item "business logic coherence—disbursement node—non-compliant condition: must complete review before disbursement—processing suggestion: add forced verification and set automatic rollback in process arrangement engine" to the management terminal; At the same time, a complete record is generated in the database, including the node track of this instance, actual response time distribution, evidence screenshot abstract of unauthorized or skipping, recommended strategy and its rollback scheme. Through the above mechanism, management personnel can view and implement rectification on the terminal in real time, and all subsequent disposal actions and results will also be written back to the same review record, forming a "discovery—suggestion—execution—verification" closed loop, providing reliable data basis for future review, audit and continuous optimization.

[0080] The above describes one embodiment of the present application in detail, but the above description is only a preferred embodiment of the present application and cannot be considered as limiting the scope of the present application. Any equivalent changes and improvements made within the scope of the present application should still belong to the patent coverage of the present application.

Claims

1. A risk control method for business process review, characterized by, The method comprises the following steps: S1: obtaining all node information of a target business process, determining risk dimensions of the business process review according to compliance requirements of the field to which the business process belongs; the risk dimensions include node operation permission matching degree, process data transmission compliance, and inter-node business logic coherence; S2: for each risk dimension, extracting feature parameters of the business process under normal operation in the dimension, and establishing risk judgment rules corresponding to each risk dimension based on the feature parameters; the risk judgment rules are used to determine whether the operation of the business process in the dimension is risky; the specific process is as follows: For each risk dimension, collect historical operation data of the business process under normal operation in the dimension, which covers all running links involved in the dimension; Extract stable running indicators from the historical operation data as feature parameters; the feature parameters of the node operation permission matching degree include the correspondence between the operator post and the operation permission; the feature parameters of the process data transmission compliance include the transmission node range and the encryption method; and the feature parameters of the inter-node business logic coherence include the instruction interaction sequence and the response time range; Convert each feature parameter into a specific judgment condition; the judgment condition of the node operation permission matching degree is that the operator post must be consistent with the post in the operation permission list; the judgment condition of the process data transmission compliance is that the transmission path is within the preset node range and uses the specified encryption method; and the judgment condition of the inter-node business logic coherence is that the instruction interaction sequence conforms to the preset process and the response time is within the feature parameter range, thereby forming the risk judgment rules of each risk dimension; Select another part of the historical operation data under normal operation, substitute it into the risk judgment rules for verification, and determine that the risk judgment rules are effective after confirming that all the data meet the rules; S3: real-time collection of operation data generated when each node of the target business process runs; S4: substituting the collected operation data into the risk judgment rules corresponding to each risk dimension respectively, verifying whether the operation data meet the risk judgment rules one by one, and marking the risk dimensions and node positions corresponding to the operation data that do not meet the risk judgment rules; S5: according to the marked risk dimensions and node positions, calling the preset risk treatment strategy library in the risk dimension, and matching the risk treatment suggestions corresponding to the current risk characteristics from the risk treatment strategy library; S6: sending the marked risk dimensions, node positions, and corresponding risk treatment suggestions to the business process management terminal, and storing all information of the business process review to the business process review database.

2. The risk control method for business process review according to claim 1, wherein, In the step S1, the process of determining the risk dimensions of the business process review according to the compliance requirements of the field to which the business process belongs is as follows: Call all compliance requirement files of the field to which the target business process belongs, parse the constraint clauses related to the business process operation in the files, and form a compliance clause list; Classify each clause in the compliance clause list into a risk type, and determine that the risk types involved in the clause are operation permission, data transmission, and business logic; The operation permission class risk type corresponding node operation permission matching degree, the data transmission class corresponding process data transmission compliance, and the business logic class corresponding node-to-node business logic coherence; After verifying that each compliance clause corresponding risk type has been matched to the risk dimension without omission, the risk dimension of the business process review is determined.

3. The risk control method for business process review according to claim 1, wherein, In the 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 the node-to-node business instructions.

4. The risk control method for business process review according to claim 1, wherein, In the step S4, the process of verifying whether the operation data conforms to the risk judgment rule one by one and marking the risk dimension and node position corresponding to the operation data that does not conform to the risk judgment rule is: Classify the collected operation data according to the risk dimension, the permission information of the node operator corresponds to the node operation permission matching degree, the transmission path information corresponds to the process data transmission compliance, and the instruction interaction information corresponds to the node-to-node business logic coherence; For each type of classified data, the judgment rule corresponding to the risk dimension is substituted in turn, and whether the data and the judgment condition in the rule are consistent is compared point by point, and the single-dimension comparison result is recorded; The multi-dimension comparison results of the same node are associated and verified to check whether there is a data contradiction between dimensions; Extract the data with inconsistent single-dimension comparison results or associated verification contradictions to determine the risk dimension to which the data belongs and the specific node position where the data is generated; Add exclusive identification to the risk dimension and node position corresponding to the extracted data, and the identification includes the inconsistent judgment condition and the contradiction type.

5. The risk control method for business process review according to claim 1, wherein, In the step S5, the risk handling suggestion includes a node permission adjustment scheme and a data transmission path optimization scheme.

6. The risk control method for business process review according to claim 1, wherein, In the step S5, the process of retrieving the risk handling strategy library preset under the risk dimension according to the marked risk dimension and node position, and matching the risk handling suggestion corresponding to the current risk characteristics from the risk handling strategy library is: Extract the risk dimension and node position in the marked information, combine the risk dimension name and node position number into a strategy library query keyword to ensure that the keyword uniquely corresponds to the target query range; According to the query keyword, locate the risk handling strategy library exclusive to the risk dimension in the preset classified storage system, and divide the independent storage area according to the risk dimension name; Retrieve the historical risk handling records associated with the node position number from the strategy library, extract the matching items in the historical records that are consistent with the current risk characteristics as the preliminary screening basis; Compare the current risk characteristics with the handling strategies in the strategy library one by one, combine the preliminary screening basis, and select the handling strategy that completely matches the risk characteristics as the risk handling suggestion; Verify whether the selected risk handling suggestion is suitable for the business scenario of the current node position, and confirm the adaptation to determine that the risk handling suggestion is the final output content.

7. The risk control method for business process review according to claim 1, wherein, In the step S6, the reviewed information includes node information, operation data, risk marking results, and risk handling suggestions.

Images