Work data processing method and system based on compliance verification library and risk control plan

Abstract

The invention discloses an operation data processing method and system based on a compliance verification library and a risk control plan, and belongs to the technical field of data compliance and risk control, and the method comprises the steps: obtaining an execution plan of a target operation task and risk control strategy information of the execution plan, analyzing operation data items, distributing corresponding compliance verification time windows and levels, and forming an operation data verification scheduling table; according to the verification level and the business domain, a rule set is extracted from a compliance verification library, and rules comprise predefined rules, model output rules and historical violation rules; field-level matching, logic consistency verification and cross-source linkage verification are executed in the verification time window; when the verification result meets the triggering condition, generating an abnormal event, and executing response operations such as delay, recheck or interception; and finally, writing the execution state and the verification result into an abnormal log queue for risk control strategy parameter updating or re-evaluation. According to the method, the dynamic compliance verification and strategy closed-loop optimization of the operation data are realized, and the intelligent compliance control capability of the system is improved.

Description

Technical Field

[0001] This invention relates to the field of data compliance and risk control technology, specifically to a method and system for processing operational data based on a compliance verification library and a risk control plan. Background Technology

[0002] In current compliance control and risk management scenarios, enterprises or institutions, when performing operational tasks (such as auditing, engineering, and financial operations), need to conduct phased control and manage the progress of operations according to a pre-set risk control plan. Simultaneously, they need to make real-time assessments of whether operational data violates policies, compliance rules, and laws and regulations. Existing technologies often rely on static rule matching or post-audit, failing to achieve a dynamic response mechanism linked to the risk control plan.

[0003] Specifically, in complex operational environments, such as data execution platforms in financial systems, intelligent auditing systems, or cross-departmental collaboration platforms, operational data comes from multiple systems, exhibiting heterogeneous formats and diverse content, and the verification rules are constantly being updated. For example, a fund transfer operation may involve multiple sub-operational data items, each of which needs to complete compliance verification within its planned execution window. Existing technologies have significant shortcomings in the following aspects: First, compliance rules are fragmented, lacking a centralized rule base for dynamic invocation, and risk control plans cannot drive the timing and granularity of compliance verification, leading to verification delays; second, there are logical dependencies between multiple operational data items, making it impossible to achieve linked judgments. Summary of the Invention

[0004] The purpose of this invention is to provide a method and system for processing operational data based on a compliance verification library and a risk control plan, so as to overcome the shortcomings of the prior art.

[0005] To achieve the above objectives, the present invention provides the following technical solution: a method for processing operational data based on a compliance verification library and a risk control plan, comprising: Obtain the execution plan of the target task and its corresponding risk control strategy information, wherein the risk control strategy information includes the operation time window, compliance verification level and triggering conditions corresponding to each stage; The target task contains multiple task data items, and based on the risk control strategy information, a corresponding compliance verification window and verification level are assigned to each task data item to form a task data verification scheduling table. From the compliance verification library, based on the verification level and business domain of each work data item, the corresponding set of verification rules is extracted. The compliance verification library includes predefined rules, machine learning model output rules, and historical violation rule sets. Within the compliance verification window, verification operations are performed on the job data items sequentially according to the scheduling table. The verification operations include field-level compliance matching, logical dependency consistency verification, and cross-source data linkage verification. When the verification result meets the triggering conditions, a compliance exception event is generated, and response operations including delayed execution, marking for review and forced interception are executed according to the predefined risk response logic in the risk control strategy information. The execution status of the response operation, related job data items, and their verification results are written to the exception log queue for updating policy parameters or triggering policy re-evaluation.

[0006] Preferably, the process involves parsing multiple task data items contained in the target task and, based on the risk control strategy information, assigning a corresponding compliance verification window and verification level to each task data item, including: Extract the field structure of the job data items and their associated source identifiers, and construct a metadata mapping table to identify the data type and business affiliation; Based on the stage division rules defined in the risk control strategy information, each operation data item is mapped to the corresponding operation stage, and the start and end time of its verification is determined in combination with the operation time window. Based on the risk label and historical violation frequency of each work data item, a compliance verification level is dynamically matched and assigned. Generate a job data verification schedule table that includes job data item identifiers, corresponding stage numbers, verification time windows, and verification levels.

[0007] Preferably, the set of corresponding verification rules extracted includes: Based on the compliance level and business domain of each data item in the job data verification scheduling table, a verification rule retrieval request is generated, which includes risk level parameters and business domain codes. Retrieve a set of matching predefined rules from the compliance verification library. The predefined rules are stored according to field type and business context. Based on the data item field features and historical behavior features, supplementary verification rules are output using the trained classification model. The model is a violation behavior prediction model built based on the XGBoost algorithm. Merge predefined rules, model output rules, and rule items that match data items in the historical violation rule set to form a complete rule set and bind it to the data item.

[0008] Preferably, the rule items that match the predefined rules, model output rules, and data items in the historical violation rule set include: For each job data item, establish a rule set cache structure and initialize the rule source identifier field to distinguish the generation method of the rule; The predefined rules extracted from the compliance verification library and the model output rules are sorted according to the rule priority field, and rule deduplication and conflict detection are performed to prioritize the retention of rules with high risk level and high hit frequency. For rule items matched in the historical violation rule set, extract their violation context under the same field dimension, and compare it with the current data item field context. Only retain historical rules with similarity exceeding the threshold. The three selected rule types are merged to generate a structured rule set, which is then mapped to the unique identifier of the corresponding job data item through hash binding.

[0009] Preferably, within the compliance verification window, verification operations are performed on the job data items sequentially according to the schedule, including: Based on the verification time window and execution priority in the job data verification scheduling table, the corresponding data items and their bound rule sets are sequentially scheduled to the verification engine; For each data item, a field-level compliance matching check is performed. The matching is based on the field constraint expressions defined in the rule set, including numerical range, enumeration value limitation and regular expression format check. For data items with field dependencies, perform logical consistency checks based on the dependency chain configuration file.

[0010] Preferably, when the verification result meets the triggering conditions, a compliance exception event is generated, including: Based on the violation type and corresponding rule ID output by the verification engine, a compliance exception event object is generated, recording the violation field, violation value, trigger time, and source of associated rule; Query the risk response logic configuration in the risk control strategy information of the operation data item, and match the corresponding response method according to the violation type and risk level; If the response method is delayed execution, then update the execution time field of the job data item in the scheduling table, and re-enter the execution queue after a specified time period. If the response method is to mark for review or to force interception, the data item status will be marked as "pending review" or "intercepted" and written to the exception task queue.

[0011] Preferably, the method for updating policy parameters or triggering policy re-evaluation includes: Using the completion of the response operation as the trigger condition, extract the unique identifier, verification failure field, trigger rule ID and response method of the job data item, and construct a structured exception log entry; Write exception log entries to a distributed exception log queue. The queue supports automatic categorization and archiving by task stage and violation type. Based on the frequency of violation types, response success rate, and interception accuracy, a strategy evaluation index vector is constructed. If the deviation between the strategy evaluation indicator vector and the preset threshold exceeds the set range, the parameter update or rule re-evaluation process of the current risk control strategy will be automatically triggered.

[0012] Preferably, the execution order of each of the response operations depends on the verification result status of the previous job data item, and the data writing time of the exception log queue shall not be later than the start time of the next stage of the job data item.

[0013] This invention also provides an operational data processing system based on a compliance verification library and a risk control plan, including: The plan parsing module obtains the execution plan of the target task and its corresponding risk control strategy information, including the operation time window, compliance verification level and triggering conditions for each stage. Scheduling generation module: parses multiple job data items contained in the target job task, and assigns a corresponding compliance verification time window and verification level to each job data item according to the risk control strategy information, forming a job data verification scheduling table; Compliance rule extraction module: Extracts the corresponding set of verification rules from the compliance verification library based on the verification level and business domain of each work data item. The compliance verification library includes predefined rules, machine learning model output rules, and historical violation rule sets. Compliance verification engine module: During the compliance verification time window, the verification operation is performed on the job data items in sequence according to the schedule table. The verification operation includes field-level compliance matching, logical dependency consistency verification and cross-source data linkage verification. Risk Response Control Module: When the verification result meets the triggering conditions, a compliance exception event is generated, and response operations including delayed execution, marking for review and forced interception are executed according to the predefined risk response logic in the risk control strategy information. Policy evaluation module: Writes the execution status of response operations, related job data items and their verification results to the exception log queue, which is used to update policy parameters or trigger policy re-evaluation.

[0014] The technical effects and advantages provided by the present invention in the above technical solution are as follows: 1. This invention provides a work data processing method based on a compliance verification library and risk control plan, enabling closed-loop management of the entire work task process, from plan formulation, data item parsing, rule extraction to verification execution and response control. By introducing a work data verification scheduling table, it achieves fine-grained control over the timing and granularity of compliance verification, improving the real-time performance and accuracy of compliance verification in high-frequency work scenarios. Simultaneously, the dynamic extraction mechanism of the rule set, combined with predefined rules, model output rules, and historical violation rule sets, enables the system to adaptively identify unknown risks, solving the problems of rigid rules and insufficient coverage in existing technologies.

[0015] 2. This invention constructs a policy feedback closed loop through a response control module and an anomaly log mechanism, enabling quantitative evaluation of policy execution effectiveness and automatically triggering parameter updates or rule re-evaluation based on the evaluation results, effectively enhancing the sustainable optimization capability of risk control strategies. This method is particularly suitable for scenarios involving multi-system collaboration, complex business logic, and compliance risk sensitivity, improving the system's intelligent compliance governance capabilities while ensuring data processing efficiency. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this invention. For those skilled in the art, other drawings can be obtained based on these drawings.

[0017] Figure 1 This is a flowchart of the method of the present invention.

[0018] Figure 2 This is a flowchart of the system modules of the present invention. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, 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, 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.

[0020] Example 1, please refer to Figure 1 As shown in this embodiment, the operational data processing method based on the compliance verification library and risk control plan includes: Obtain the execution plan of the target task and its corresponding risk control strategy information, wherein the risk control strategy information includes the operation time window, compliance verification level and triggering conditions corresponding to each stage; The target task contains multiple task data items, and based on the risk control strategy information, a corresponding compliance verification window and verification level are assigned to each task data item to form a task data verification scheduling table. From the compliance verification library, based on the verification level and business domain of each work data item, the corresponding set of verification rules is extracted. The compliance verification library includes predefined rules, machine learning model output rules, and historical violation rule sets. Within the compliance verification window, verification operations are performed on the job data items sequentially according to the scheduling table. The verification operations include field-level compliance matching, logical dependency consistency verification, and cross-source data linkage verification. When the verification result meets the triggering conditions, a compliance exception event is generated, and response operations including delayed execution, marking for review and forced interception are executed according to the predefined risk response logic in the risk control strategy information. The execution status of the response operation, related job data items, and their verification results are written to the exception log queue for updating policy parameters or triggering policy re-evaluation.

[0021] In this embodiment of the invention, it is first necessary to obtain the corresponding execution plan and associated risk control strategy information for the target task, so as to serve as the basis for subsequent task data processing and compliance verification.

[0022] Specifically, target tasks are typically generated by a scheduling platform, business management system, or risk control management platform. The execution plan includes, but is not limited to, the task's phase divisions, the start and end times of each phase, the responsible unit, and the task requirements. The execution plan is defined as structured data to facilitate system parsing and task decomposition.

[0023] Corresponding to the execution plan is a set of pre-set risk control strategies for different stages of the task. This risk control strategy information includes: The corresponding task time window for each stage: used to limit the time interval during which task data must be input and validated; The corresponding compliance verification level reflects the current level of compliance risk sensitivity. The higher the level, the stricter the required verification rules. A set of triggering conditions, including changes in the status of job data, characteristics of field values, and differences in the source system, serve as the basis for determining when to initiate a compliance verification task.

[0024] For example, in a financial audit scenario, the execution plan for a large fund transfer task is defined in three stages: initial preparation, approval process, and fund execution. The system assigns different time windows and compliance levels to these three stages, with the approval stage set as "high-risk" and having multiple compliance trigger conditions such as field inconsistencies and approval delays.

[0025] Upon receiving the target task identifier, the system first retrieves the corresponding execution plan through the task management interface or risk control strategy management module, and parses the structural information of each stage. Simultaneously, it calls the risk control rule database or strategy service to extract the risk control strategy information matching each stage of the task, parses it, and binds it to the scheduling task.

[0026] In a preferred embodiment of the present invention, after obtaining the execution plan of the target task and its corresponding risk control strategy information, the system further parses the multiple task data items contained in the task and assigns corresponding compliance verification parameters to each data item based on the risk control strategy information, including verification time window and compliance level, to construct a task data verification scheduling table for subsequent scheduling control. Specifically, this includes the following steps: First, the data packet for the target job task is received from the task management platform or job data access module. Each job data item includes multiple fields, such as field name, field type, value type, and business tag.

[0027] The source system identifier carried in each data item is parsed, and the business scenario to which the data item belongs is determined according to the system's preset system-business domain mapping rules. For example, if the source system identifier is "SYSTEM_A", then its business belongs to the "financial accounting domain".

[0028] Subsequently, a metadata mapping table is constructed, with a table structure including data item identifiers, field structure descriptions, source systems, business domains, and other information. This mapping table is used for subsequent matching calculations with risk control strategies.

[0029] Based on the time window definitions (including stage number, start time, and end time) of each stage in the aforementioned execution plan, the system maps data items to the corresponding job stages according to the business domain and job type to which the data items belong.

[0030] For example, if a data item comes from the "approval process" and its fields are "Approver ID" and "Approval Time", the system will map the data item to stage 2 based on the start and end time of the "approval stage" defined in the execution plan, such as "stage 2: 09:00-11:00", and set its verification time window to 09:00 to 11:00.

[0031] In addition, the system supports setting a "verification reservation time". If the verification is started 5 minutes in advance, the system will adjust the verification time window to 08:55 to 11:00.

[0032] The system integrates a compliance level configuration engine, which assesses compliance levels based on the following two types of information: Risk Tag: Predefined according to business rules, such as "funds field" and "cross-border transaction field" are high-risk tags; Historical Violation Frequency: The system counts the number of violations of this field in the past N (e.g., 30) days, denoted as F. If F is greater than the preset threshold T (e.g., T = 3 times), then it is regarded as a high-frequency violation field. The compliance level is divided into three levels: L1 (low), L2 (medium), L3 (high), and the assignment rules are as follows: If the field has a high-risk label and F ≥ T, the level is set to L3; if the field has any risk label and F < T, the level is set to L2; if there is no risk label and F = 0, the level is set to L1. The level information will be bound to the field identifier to form a field-level mapping relationship, which is used to drive the extraction of subsequent verification rules.

[0033] Structurally record the field-level information (data item identifier, belonging stage, verification time window, compliance level) obtained in the above steps to generate a job data verification scheduling table. An example of its table structure is as follows: Table 1 Job Data Verification Scheduling Table

[0034] Cache Table 1 in the task scheduling module as the core parameter set for triggering the job data verification task. When the scheduling system detects that the current system time enters a certain verification time window and the data item has not been verified yet, it will immediately start the corresponding compliance verification process according to the content of the scheduling table.

[0035] In a preferred embodiment of the present invention, based on the compliance level and the belonging business domain of each job data item, extract the corresponding verification rule set from the compliance verification library to construct a complete rule combination applicable to this data item. The compliance verification library is a multi-source heterogeneous structure, including three types of rule resources: predefined rule set, model output rule set, and historical violation rule set.

[0036] The process of rule extraction and fusion includes the following steps: First, read the assigned compliance level and business domain information in the job data verification scheduling table, and construct a standardized rule retrieval request for each job data item. This request includes: a risk level parameter, whose value corresponds to the compliance level, such as "L1 (low)", "L2 (medium)", "L3 (high)"; a business domain code, which identifies the business belonging of the data item according to the metadata mapping table, such as "FIN" representing the financial domain and "HRM" representing the human resource management domain; optionally includes additional parameters such as field type and data sensitivity label for further refined matching. This retrieval request is encapsulated into a structured request body and transmitted to the compliance verification library interface service module.

[0037] The predefined rules in the compliance verification library are organized with the field dimension as the index, and the structure contains the following fields: rule ID, applicable business domain, field type, rule expression, applicable level.

[0038] Upon receiving a rule retrieval request, the following filtering logic is executed: Matching business domain fields with the business domain code in the request; filtering rules with an applicable risk level less than or equal to the requested risk level (e.g., L2 data items can use both L1 and L2 rules); optionally, further limiting the rule scope by field type to improve matching accuracy. The filtering results constitute the first set of rules for the current data item.

[0039] A classification model is introduced to enhance the rule recognition mechanism, which is used to discover supplementary rules in the rule base that are not explicitly defined but exhibit compliance risk characteristics in historical data.

[0040] The model is built based on the XGBoost algorithm. Its training process includes: input features: including the historical value distribution of the field, the co-occurrence frequency of the field and risk events, and the frequency of field changes; label definition: constructing supervised learning labels with whether a violation event is triggered in the past as the target variable; training set construction: extracting more than 10,000 positive and negative sample pairs from the labeled violation dataset; model output: predicting the input field and outputting a probability score. If the score is greater than a set threshold of 0.65, it indicates that the field has a potential violation tendency. The model output will generate a set of suggested rules, such as "If field X has a value of type B and a risk level of L3, cross-business submissions should be prohibited," as the second set of rules.

[0041] To further enhance rule adaptability, fuzzy matching is performed on the fields corresponding to data items within the historical violation rule set: field dimensions and contextual information (such as previous and subsequent field values, source system, time tags, etc.) are extracted; a contextual similarity algorithm based on cosine similarity is used for comparison, with a similarity threshold of 0.85, and only rules exceeding this threshold are retained; the matching results constitute a third type of rule set. Subsequently, the system performs the following fusion operation on the three types of rule sets: a rule set cache structure is initialized for each job data item, with fields including rule ID, rule source (predefined / model / historical), priority, and scope of application; rule priority sorting is performed, with the priority set as follows: L3>L2>L1, and the source priority is "historical rules>model rules>predefined rules"; rule deduplication and conflict resolution are performed, and if duplicate rules exist for the same field, those with high hit frequency and high risk level are retained; The final result is a set of structured rules, which are hashed and bound to the unique identifier of the key-value pair structure and the job data item, and then written to the local rule cache queue.

[0042] In a preferred embodiment of the present invention, when the system time enters the compliance verification time window defined by the job data verification schedule table, the system performs compliance verification operations on each job data item to be verified according to the task sorting information in the schedule table. This verification process includes not only field-level static rule judgment but also logical consistency judgment and multi-source data consistency verification. The specific steps are as follows: Based on the fields "Verification Start Time", "Verification Priority" and "Data Item ID" in the job data verification scheduling table, scheduling is performed according to the following logic: The current system time is greater than or equal to the "verification start time"; The data item status is marked as "pending verification"; Within the same time window, data items with higher priority are scheduled first, with priority levels set as P1>P2>P3, and the scheduling strategy is P1 first, then P2, and then P3.

[0043] After scheduling is completed, the system pushes the data item and its bound complete set of rules (including rule ID, verification logic, and applicable fields) to the compliance verification engine module.

[0044] The compliance verification engine first performs field-level compliance matching for each data item, including but not limited to the following verification methods: Numeric range validation: For numeric fields, the minimum and maximum value boundaries in the rules are read to determine if the current value falls within those ranges. For example, if the rule sets "the range of the amount field is 1000 to 100000", a current value of 950 would be considered non-compliant. Enumeration value restriction: For string fields, restrict their value range, such as "the approval status field is only allowed to be: pending review, approved, rejected", and if the value is "processing", a violation will be triggered; Format validation: Regular expressions are used to validate the field format. Fields such as ID number, date format, and account number format must conform to the preset expression pattern.

[0045] The verification process matches the rule fields by field name and calls the corresponding verification function for verification. If the verification fails, the exception record is written to the compliance exception log.

[0046] For cases involving cross-field and cross-data-item logical relationships, the system invokes the dependency chain configuration file to perform logical consistency checks. This configuration file defines the constraint logic relationships between data items, such as: causal relationship: if the "Approval Time" field exists, then "Approver ID" cannot be empty; quota constraint: if the "Transaction Type" is "Internal Transfer," then the "Amount" field cannot exceed 50,000 yuan; time order constraint: the "Submission Time" field must be earlier than the "Approval Time" field. The implementation is as follows: Assemble the job context based on the associated data item identifiers in the scheduling table; read the field logical relationship diagram in the dependency chain definition; compare and verify the corresponding field values; if the logical relationship is not satisfied, it is determined to be a violation. This step ensures that the data semantically conforms to business compliance expectations, avoiding misjudgments or omissions caused by isolated rule execution.

[0047] If a job data item contains cross-system fields, meaning that some fields of the data item are not defined in the local system or their values ​​depend on external systems, the system calls the data linkage module to perform cross-source consistency verification. The steps are as follows: Construct a cross-system query request based on the "source system identifier" and "primary key field" defined in the scheduling table; send a data request to the corresponding external system interface (such as ERP system, CRM platform, etc.) to obtain the target field value; according to the verification rules of the corresponding field in the job data item, use the primary key to compare the current data with the remote field or perform logical calculations. For example, if the field "customer level" is "A" in this system and "B" is returned from the remote end, a cross-source inconsistency alarm will be triggered.

[0048] To improve the efficiency of the linkage, the system adopts a field-level caching strategy, which caches frequently used remote field values ​​for a short period of time. The cache validity period can be set to 5 minutes to reduce the frequency of interface calls.

[0049] In a preferred embodiment of the present invention, after the compliance verification engine completes the verification of the operational data items, if a rule violation is detected and the set triggering conditions are met, the system will automatically generate a corresponding compliance anomaly event and execute corresponding control measures according to the predefined risk response logic in the risk control strategy information associated with the data item. This processing flow includes the following four steps: During the compliance verification process, once the rule matching result is "failed," a violation determination is triggered. The system will create a structured compliance exception event object containing the following key fields: Violation Field Identifier: the name of the field where the violation occurred; Violation Value: the current value of the field; Violation Rule ID: the rule number that triggered the violation; Rule Source: identifies the rule type, with values ​​of "predefined," "model output," or "historical rule"; Violation Timestamp: records the precise time (accurate to milliseconds) when the violation occurred; Data Item ID and Job Task ID: used to track exceptions at the task level. The exception event object is stored in a structured format in the compliance exception event log queue and simultaneously pushed to the risk response module as the basis for response triggering.

[0050] Read the "task stage number" and "belonging risk control strategy number" recorded in the scheduling table for the task data item, and query the risk response logic configuration corresponding to the stage from the risk control strategy library based on the strategy number.

[0051] The risk response logic is defined in the form of rules, including: a violation type mapping table: mapping rule IDs or rule categories (such as monetary rules, approval rules) to standard violation types; a risk level matching table: matching executable response operations based on the compliance level (L1, L2, L3) of the operational data item and the violation type; and response method parameters: defining the execution parameters required for different response operations, such as delay duration and status code marking. For example, if a rule triggers "amount exceeding limit" and its risk level is L3, the risk control strategy can be configured as "forced interception"; if it is an L1 violation, it can be configured as "mark for review".

[0052] If the response logic matching result is "delayed execution", the system will dynamically adjust the execution time field of the current job data item in the scheduling table. The execution method is as follows: Read the "Delay Duration" parameter from the policy configuration, in minutes; obtain the current system time and calculate the new execution start time = current time + delay duration; update the "Verification Start Time" field of the data item in the job data verification scheduling table; set the status field to "Delayed to be executed" and write it to the job delay log for subsequent auditing.

[0053] For example, if the current violation occurs at 10:00 and the delay time is configured to be 15 minutes, then the updated execution start time will be 10:15.

[0054] If the response logic is "Mark for review" or "Force interception", the system will immediately change the task status of the data item and perform the following operations: Mark for review: Update the status of the data item to "pending review" and write the exception event object and data item ID into the "Exception Task Review Queue" for processing by the manual review module or intelligent audit system; Forced Interception: Update the status to "Intercepted" to prevent the data item from entering the subsequent execution process, and record the interception operation log, including the operator (system), interception time, interception basis, etc.

[0055] In a preferred embodiment of the present invention, to achieve dynamic monitoring and feedback updates of the risk control strategy response effect, after completing the response operation on the operation data item, the system uniformly writes its execution status, verification result, and related field information into an exception log queue, which is then used by the subsequent strategy evaluation module for strategy parameter updates or rule re-evaluation triggering. The specific implementation steps are as follows: After each response operation (such as delayed execution, marked for review, or forced interception) is completed, the following information fields are immediately collected, using the operation completion event as the trigger point, to construct standardized exception log entries: The log entries include: a unique identifier for each data item (DataItemID) to correspond one-to-one with the scheduling table and historical data; a field name (FieldName) for verifying the failure and its corresponding value (InvalidValue); a trigger rule ID (RuleID) and its source type (predefined, model output, historical rule); a response type (ActionType) such as Delay, Flag, Block; a response result status (ActionResult) including success, failure, and skipped; and a trigger timestamp and task stage number for time-dimensional analysis during policy evaluation. These log entries use a structured data format (such as JSON or Protocol Buffers) for easy transmission and parsing between heterogeneous systems.

[0056] Once the exception log entries are completed, they will be sent to the exception log queue service module. This module is built on a distributed message queue system (such as Kafka or RocketMQ) and features high availability and multi-dimensional tag archiving capabilities. Specific implementation methods include: Log entries are categorized and indexed based on the "Task Stage Number" and "Violation Type" fields, and automatically distributed to the corresponding sub-queues or topics. The queues support daily partitioning and rolling backup mechanisms to ensure the integrity of data storage required for long-term analysis. Each log entry is appended with a unique log ID and write timestamp for easy retrieval and tracking. The queue also supports integration with risk control visualization platforms for real-time compliance event monitoring.

[0057] The strategy evaluation module periodically reads the exception log queue, extracts log data, and calculates the following strategy evaluation metrics: Violation type frequency statistics: the number of times a certain type of rule is triggered within a specified time window; Response success rate: the proportion of successfully executed response operations; Interception accuracy rate: the proportion of mandatory interception operations that truly prevent high-risk behaviors, which can be confirmed through subsequent review and annotation; Average response latency time: the average time taken from triggering to completing a response operation. These metrics are combined into a strategy evaluation metric vector, represented as: [Vf, Asr, Ba, Aad], where Vf represents violation frequency, Asr represents response success rate, Ba represents interception accuracy rate, and Aad represents average latency time.

[0058] Determine if the current strategy's performance deviates from expectations. The model sets a set of reference threshold vectors, such as: Vf threshold = 50 (unit: times / day); Asr threshold = 90%; Ba threshold = 85%; Aad threshold = 3 minutes. When the difference between the actual metric and the threshold in any dimension exceeds the tolerance range (e.g., ±10%), it is considered a strategy deviation. Once a deviation is confirmed, the system automatically triggers one of the following operations: Strategy parameter updates: such as adjusting the response method corresponding to the risk control level (e.g., upgrading the original mark review to mandatory interception); Rule reassessment process initiated: The system notifies the rule maintenance module to reassess the applicability or threshold settings of rules with high frequency of abnormal triggers; Strategy manual review suggestion: Push the assessment report to risk control personnel for decision support.

[0059] Example 2, please refer to Figure 2 As shown in this embodiment, the operational data processing system based on the compliance verification library and risk control plan includes: The plan parsing module obtains the execution plan of the target task and its corresponding risk control strategy information, including the operation time window, compliance verification level and triggering conditions for each stage. Scheduling generation module: parses multiple job data items contained in the target job task, and assigns a corresponding compliance verification time window and verification level to each job data item according to the risk control strategy information, forming a job data verification scheduling table; Compliance rule extraction module: Extracts the corresponding set of verification rules from the compliance verification library based on the verification level and business domain of each work data item. The compliance verification library includes predefined rules, machine learning model output rules, and historical violation rule sets. Compliance verification engine module: During the compliance verification time window, the verification operation is performed on the job data items in sequence according to the schedule table. The verification operation includes field-level compliance matching, logical dependency consistency verification and cross-source data linkage verification. Risk Response Control Module: When the verification result meets the triggering conditions, a compliance exception event is generated, and response operations including delayed execution, marking for review and forced interception are executed according to the predefined risk response logic in the risk control strategy information. Policy evaluation module: Writes the execution status of response operations, related job data items and their verification results to the exception log queue, which is used to update policy parameters or trigger policy re-evaluation.

[0060] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A method for processing operational data based on a compliance verification database and a risk control plan, characterized in that, include: Obtain the execution plan of the target task and its corresponding risk control strategy information, wherein the risk control strategy information includes the operation time window, compliance verification level and triggering conditions corresponding to each stage; The target task contains multiple task data items, and based on the risk control strategy information, a corresponding compliance verification window and verification level are assigned to each task data item to form a task data verification scheduling table. From the compliance verification library, based on the verification level and business domain of each work data item, the corresponding set of verification rules is extracted. The compliance verification library includes predefined rules, machine learning model output rules, and historical violation rule sets. Within the compliance verification window, verification operations are performed on the job data items sequentially according to the scheduling table. The verification operations include field-level compliance matching, logical dependency consistency verification, and cross-source data linkage verification. When the verification result meets the triggering conditions, a compliance exception event is generated, and response operations including delayed execution, marking for review and forced interception are executed according to the predefined risk response logic in the risk control strategy information. The execution status of the response operation, related job data items, and their verification results are written to the exception log queue for updating policy parameters or triggering policy re-evaluation.

2. The operational data processing method based on the compliance verification library and risk control plan according to claim 1, characterized in that: The process involves parsing multiple task data items contained in the target task and, based on the risk control strategy information, assigning a corresponding compliance verification window and verification level to each task data item, including: Extract the field structure of the job data items and their associated source identifiers, and construct a metadata mapping table to identify the data type and business affiliation; Based on the stage division rules defined in the risk control strategy information, each operation data item is mapped to the corresponding operation stage, and the start and end time of its verification is determined in combination with the operation time window. Based on the risk label and historical violation frequency of each work data item, a compliance verification level is dynamically matched and assigned. Generate a job data verification schedule table that includes job data item identifiers, corresponding stage numbers, verification time windows, and verification levels.

3. The operational data processing method based on the compliance verification library and risk control plan according to claim 2, characterized in that: The extracted set of corresponding verification rules includes: Based on the compliance level and business domain of each data item in the job data verification scheduling table, a verification rule retrieval request is generated, which includes risk level parameters and business domain codes. Retrieve a set of matching predefined rules from the compliance verification library. The predefined rules are stored according to field type and business context. Based on the data item field features and historical behavior features, supplementary verification rules are output using the trained classification model. The model is a violation behavior prediction model built based on the XGBoost algorithm. Merge predefined rules, model output rules, and rule items that match data items in the historical violation rule set to form a complete rule set and bind it to the data item.

4. The operational data processing method based on the compliance verification library and risk control plan according to claim 3, characterized in that: The merged predefined rules, model output rules, and rule items matched with data items in the historical violation rule set include: For each job data item, establish a rule set cache structure and initialize the rule source identifier field to distinguish the generation method of the rule; The predefined rules extracted from the compliance verification library and the model output rules are sorted according to the rule priority field, and rule deduplication and conflict detection are performed to prioritize the retention of rules with high risk level and high hit frequency. For rule items matched in the historical violation rule set, extract their violation context under the same field dimension, and compare it with the current data item field context. Only retain historical rules with similarity exceeding the threshold. The three selected rule types are merged to generate a structured rule set, which is then mapped to the unique identifier of the corresponding job data item using a hash binding method.

5. The operational data processing method based on the compliance verification library and risk control plan according to claim 4, characterized in that: Within the compliance verification window, perform verification operations on the job data items sequentially according to the schedule, including: Based on the verification time window and execution priority in the job data verification scheduling table, the corresponding data items and their bound rule sets are sequentially scheduled to the verification engine; For each data item, a field-level compliance matching check is performed. The matching is based on the field constraint expressions defined in the rule set, including numerical range, enumeration value limitation and regular expression format check. For data items with field dependencies, perform logical consistency checks based on the dependency chain configuration file.

6. The operational data processing method based on the compliance verification library and risk control plan according to claim 5, characterized in that: When the verification result meets the triggering conditions, a compliance exception event is generated, including: Based on the violation type and corresponding rule ID output by the verification engine, a compliance exception event object is generated, recording the violation field, violation value, trigger time, and source of associated rule; Query the risk response logic configuration in the risk control strategy information of the operation data item, and match the corresponding response method according to the violation type and risk level; If the response method is delayed execution, then update the execution time field of the job data item in the scheduling table, and re-enter the execution queue after a specified time period. If the response method is to mark for review or to force interception, the data item status will be marked as "pending review" or "intercepted" and written to the exception task queue.

7. The operational data processing method based on the compliance verification library and risk control plan according to claim 6, characterized in that: Used to update policy parameters or trigger policy re-evaluation, including: Using the completion of the response operation as the trigger condition, extract the unique identifier, verification failure field, trigger rule ID and response method of the job data item, and construct a structured exception log entry; Write exception log entries to a distributed exception log queue. The queue supports automatic categorization and archiving by task stage and violation type. Based on the frequency of violation types, response success rate, and interception accuracy, a strategy evaluation index vector is constructed. If the deviation between the strategy evaluation indicator vector and the preset threshold exceeds the set range, the parameter update or rule re-evaluation process of the current risk control strategy will be automatically triggered.

8. The operational data processing method based on the compliance verification library and risk control plan according to claim 1, characterized in that: The execution order of each response operation depends on the verification result status of the previous job data item, and the data writing time of the exception log queue must not be later than the start time of the next stage job of the job data item.

9. A work data processing system based on a compliance verification library and a risk control plan, used to implement the work data processing method based on a compliance verification library and a risk control plan as described in any one of claims 1-8, characterized in that, include: The plan parsing module obtains the execution plan of the target task and its corresponding risk control strategy information, including the operation time window, compliance verification level and triggering conditions for each stage. Scheduling generation module: parses multiple job data items contained in the target job task, and assigns a corresponding compliance verification time window and verification level to each job data item according to the risk control strategy information, forming a job data verification scheduling table; Compliance rule extraction module: Extracts the corresponding set of verification rules from the compliance verification library based on the verification level and business domain of each work data item. The compliance verification library includes predefined rules, machine learning model output rules, and historical violation rule sets. Compliance verification engine module: During the compliance verification time window, the verification operation is performed on the job data items in sequence according to the schedule table. The verification operation includes field-level compliance matching, logical dependency consistency verification and cross-source data linkage verification. Risk Response Control Module: When the verification result meets the triggering conditions, a compliance exception event is generated, and response operations including delayed execution, marking for review and forced interception are executed according to the predefined risk response logic in the risk control strategy information. Policy evaluation module: Writes the execution status of response operations, related job data items and their verification results to the exception log queue, which is used to update policy parameters or trigger policy re-evaluation.

Images