A bank digital operation performance accounting and cross-module data management and control method, server and medium

CN123032208APending Publication Date: 2026-11-03HENGFENG BANK CO LTD BEIJING BRANCH
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202611057370.8
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2026-07-16
Publication Date
2026-11-03

AI Technical Summary

Technical Problem

The execution of bank operations tasks and data accounting suffer from a lack of a unified data carrier format, making task tracking and management difficult, data aggregation and statistics inconsistent, and making it difficult to meet the unified control requirements across the entire bank.

Method used

The method adopts multi-source data standardization encapsulation and multi-layer progressive verification. By merging data through a preset data structure template and adding accounting status labels, combined with cross-validation of three modules, standardized performance data tuples are generated. Data integrity, formula logic, historical trends and compliance are verified to generate unified performance results and task execution statistical reports.

Benefits of technology

It has enabled bank-wide data consistency accounting and task tracking management, improved the accuracy and statistical efficiency of performance accounting, ensured data compliance and consistency, and met the bank's real-time accounting needs.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN123032208A_ABST
    Figure CN123032208A_ABST
Patent Text Reader

Abstract

The present application belongs to the technical field of bank data management and control, and particularly relates to a bank digital operation performance accounting and cross-module data management and control method, a server and a medium, which combines branch basic information, profit-making and payment data according to a template to generate standardized performance data tuples. The tuples are grouped and weighted according to branches to obtain a performance calculation result set. The result set is sequentially subjected to data integrity, formula logic, historical trend and compliance verification to generate task records and push notifications. Task execution statistical reports are output by comparing sign-in and submission records. Fields and verification logic are extracted from regulatory documents to convert and generate cash reports, and the performance results, task reports and cash reports are subjected to consistency comparison, and correction instructions or hierarchical early warnings are sent according to the deviation types. Through standardized packaging and verification, the accuracy and compliance of performance accounting are improved, the risk of data inconsistency is effectively reduced, and the efficiency of bank digital operation management is improved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention belongs to the field of bank data management and control technology, specifically relating to a method, server and medium for bank digital operation performance accounting and cross-module data management. Background Technology

[0002] Currently, banks are required to submit various reports regularly, such as performance reports, task execution statistics reports, and cash reports, to ensure data authenticity, business compliance, and risk controllability.

[0003] Banks' daily operations encompass various types of business tasks, and the execution requirements and time constraints of different tasks lack a unified data format. Task notifications rely on point-to-point transmission, and staff's work schedules and message receiving habits can affect the actual reception of information. After a task is issued, there is no unique code to distinguish each individual task, making it difficult to track and manage the entire cycle of a task from issuance to execution to completion.

[0004] The sign-in and submission records generated by operational tasks need to be matched and verified against the original task rules one by one, resulting in multiple sets of task completion status judgment standards across the bank. The data aggregation work carried out according to institutions, task types, and time dimensions requires sorting and arrangement throughout the process, and the output of statistical content is slow. It is also difficult to maintain consistency in statistical standards for statistical data issued by different time periods and different branches, which cannot meet the control requirements. Summary of the Invention

[0005] This invention provides a method for performance accounting and cross-module data management in digital banking operations. Through standardized encapsulation of multi-source data and multi-layered progressive verification, it improves the accuracy of performance accounting. It analyzes regulatory requirements and generates reports, and combined with cross-validation across three modules, effectively reduces the risk of data inconsistency.

[0006] The server performs the following steps: S1: According to the preset data structure template, merge the received data, add accounting status labels to the merged data, and generate standardized performance data tuples; S2: Based on the accounting dimensions, indicator weights and calculation formulas configured by the management personnel, the standardized performance data tuples are grouped by branch identifier, and the weighted score of each branch is calculated one by one according to the dimension. The results are then summarized to obtain a performance calculation result set containing the scores of each indicator of each branch. S3: Perform data integrity verification on each record field, formula logic verification by substituting the calculation results back into the original formula to verify the error range, historical data trend verification by comparing the current results with the historical results of the past four quarters using moving average and standard deviation, and compliance verification on whether the data retention period and sensitive field desensitization processing meet internal specifications; push the results of all verifications to the approval node, and form the approved performance results after hierarchical approval; S4: Based on the type of operational task received, fill the task execution requirements, check-in time window and completion deadline into the task data structure to generate task data records; S5: Obtain the sign-in records and task completion submission records of the operators within the sign-in time window, compare the sign-in time and submission time with the completion deadline in the task data record, count the number of tasks completed on time, completed after the deadline, and not completed, and summarize them by line dimension, task type dimension and time dimension, and output a task execution statistics report. S6: Extract validation logic from the predefined report entry instructions document, convert it into field correspondence and validation expressions; use the field correspondence to extract and convert the required report format; validate the converted data according to the validation expressions to generate cash report data; read performance results, task execution statistics reports and cash report data, perform consistency comparison on the data pointing to the same branch, the same time period or the same business indicator among the three, and output the comparison results.

[0007] According to another embodiment of this application, a server is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the bank digital operation performance accounting and cross-module data management method.

[0008] According to another embodiment of this application, a storage medium is also provided, on which a computer program is stored, wherein when the computer program is executed by a processor, the steps of the bank digital operation performance accounting and cross-module data management method are implemented.

[0009] As can be seen from the above technical solutions, the present invention has the following advantages: This invention uses a preset data structure template to complete the field-by-field mapping and merging of basic branch information, profit-generating indicator data, and purchase indicator data, and adds accounting status labels to each integrated data entry. The unified field system avoids the problem of field identification confusion during the integration of multi-source data, and the additional status labels provide a unified identification basis for data flow, accounting, and problem troubleshooting.

[0010] By reading the configured accounting dimensions, indicator weights, and calculation formulas, the system automatically splits and groups data based on branch identifiers, then performs weighted calculations and summarizes the results according to predetermined rules. This invention establishes a four-layer fixed verification process: data integrity, formula logic, historical trends, and compliance, ensuring that result verification is completed according to unified standards throughout the process. The system categorizes approval levels based on the magnitude and scope of data changes, matching corresponding approval nodes to content with different risk levels. This fixed verification process ensures consistent execution standards for performance result verification across the entire bank.

[0011] This invention uses a general task data structure to carry the execution requirements, time constraints, and other information for all types of tasks. Each task is assigned a globally unique identifier, and message pushes are completed by retrieving preset notification preferences from personnel. The globally unique encoding supports full lifecycle tracking of a single task, and combined with differentiated push methods based on personnel habits, ensures that task information is consistently delivered to the executors.

[0012] The system relies on unique task identifiers to associate execution records with original task rules, determines task completion status according to fixed time standards, and then automatically summarizes data and generates reports based on branch, task type, and time dimensions. A unified time determination standard is implemented across the entire bank, and statistical reports objectively reflect the actual execution status of tasks in different regions and of different types, maintaining consistent statistical standards across the bank. Visualized rule configuration, vectorized calculations, and automatic execution verification improve processing efficiency and meet the bank's real-time data accounting needs. Attached Figure Description

[0013] To more clearly illustrate the technical solution of the present invention, the accompanying drawings used in the description will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0014] Figure 1 Flowchart for bank digital operation performance accounting and cross-module data management methods; Figure 2 Here is a flowchart of the method based on step S4; Figure 3 Here is a flowchart of the method based on step S6; Figure 4 Here is a flowchart of another embodiment of the method based on step S6; Figure 5 This is a schematic diagram of the server. Detailed Implementation

[0015] In the method for calculating digital operational performance and managing cross-module data in banks involved in this invention, some terms are explained as follows: Data structure template: A predefined field structure specification used to unify the format of data from different sources. The template specifies the field names, data types, field order, and constraints that should be included in the target data table, such as specifying "branch identifier" as a string type and "average daily deposit balance" as a numeric type. In this solution, the template serves as a mapping standard, converting heterogeneous source data into an intermediate dataset with a consistent structure.

[0016] Branch Basic Information: This is basic data from the bank's internal human resources management system, describing the static attributes of each branch. Specifically, it includes fields such as branch code, region, employee size, and organizational level. This type of information identifies the data's owner, serves as the primary key for cross-data source associations, and is also the basis for performance accounting and task control at the branch level.

[0017] Profitability metrics data: These are operational results data from the business system, reflecting the branch's performance in areas such as deposits, loans, and fee-based services. Typical indicators include average daily deposit balance, loan disbursement, and fee-based service revenue. This type of data is the main input used to calculate scores for each dimension in performance accounting, reflecting the branch's profit contribution.

[0018] Cost data, derived from the financial management system, records various expenses incurred by the branch during its operations. This includes operating costs, fixed asset depreciation, and marketing expenses. This data is used to deduct corresponding costs in performance evaluations or as a basis for cost control assessments, forming a complete profit and loss accounting foundation together with profit indicators.

[0019] Data Attachment and Accounting Status Labeling: This operation adds a lifecycle status label to each data record after standardization. The label uses a state machine model, with values ​​including "Pending Accounting," "Accounting in Progress," "Accounting Completed," and "Accounting Abnormal." The label content is stored in an extended field of the record, used to track the progress of data in the accounting process, supporting exception rollback and process control, ensuring that each piece of data is traceable and auditable.

[0020] Indicator weights and calculation formulas: In performance accounting, indicator weights refer to the numerical coefficients assigned to each accounting indicator, reflecting the importance of that indicator within its respective dimension. The sum of all indicator weights equals 1 within the same dimension. The calculation formula refers to the mathematical expression rules for converting raw indicator values ​​into performance scores, which may include arithmetic logic such as addition, subtraction, multiplication, division, conditional judgments, and function calls.

[0021] Managers can configure the weight values ​​of each indicator under each dimension through the front-end interface, such as a deposit indicator weight of 0.6 and a loan indicator weight of 0.4, and select or write the corresponding calculation formula.

[0022] Calculation formula text is an expression stored as a string, used to describe how to calculate performance scores from raw indicator values ​​or for rule validation. Calculation formula text can be Reverse Polish Notation (RPN), prefix expressions, or standard infix expressions, such as "a*0.6+b*0.4". In the rule engine, calculation formula text is parsed into a calculation logic tree or directly compiled into an executable script. Unlike natural language descriptions, calculation formula text contains operators, operands, parentheses, and function names, allowing it to be directly evaluated by the computer.

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

[0024] Please see Figure 1 The diagram shows a flowchart of a method for calculating digital operational performance and managing cross-module data in a bank, as described in a specific embodiment. The method includes: S1: According to the preset data structure template, the received branch basic information, profit indicator data and purchase indicator data are mapped and merged field by field, and an accounting status label is added to each merged data to generate a standardized performance data tuple.

[0025] In some embodiments, from a business source perspective, the branch's basic information is taken from the bank's internal human resources management system, the profit-generating indicator data is taken from the core business system, and the payment indicator data is taken from the financial management system. The original field naming rules, character encoding formats, and numerical measurement precision of the three types of data are different, and direct merging will result in problems such as field redundancy and content ambiguity.

[0026] The pre-defined data structure template predefines a unified field system, using the row identifier as the primary key for cross-data source association, and combining it with standard fields such as indicator categories and timestamps to form a unified specification.

[0027] After receiving three types of raw data, the system performs field-by-field matching according to the preset mapping relationship in the template, associates and binds fields with different names but the same semantics, and synchronizes and unifies numerical precision and data format. Additional fields in the raw data that exceed the template range will be stored and retained separately and will not be directly discarded.

[0028] After the field mapping is completed, the three types of heterogeneous data are integrated into an intermediate dataset with a unified format. The system traverses each record in the dataset and adds annotations related to the accounting status. The annotations are divided into four states: pending accounting, accounting in progress, accounting completed, and accounting abnormal. Data quality evaluation information and original data source traceability information are bound together. After the annotations are completed, standardized performance data tuples are finally formed and stored in the designated storage area.

[0029] S2: Based on the accounting dimensions, indicator weights, and calculation formulas configured by the management personnel, the standardized performance data tuples are grouped by branch identifier, and the weighted score of each branch is calculated one by one according to the dimension. The results are then summarized to obtain a performance calculation result set containing the scores of each indicator of each branch.

[0030] In some embodiments, after managers complete the division of accounting dimensions, the allocation of weights for each dimension's indicators, and the setting of business calculation formulas on the front-end operation interface, the system will convert this manually configured content into its own recognizable calculation rules. The system retrieves the standardized performance data tuples generated in step S1, uses the branch identifier built into the tuple as the grouping basis, and aggregates all data records belonging to the same branch into independent units, achieving partitioning and isolation of all branch data. The system processes the data units of each branch one by one according to the accounting dimensions, reads the original values ​​of the corresponding indicators in sequence, performs single-dimensional weighted calculations in combination with the configured indicator weights, and then applies the preset calculation formula to integrate the calculation results of each dimension, calculating the individual indicator score and the branch's comprehensive weighted score in sequence. The individual indicator scores, dimension scores, and comprehensive scores generated by all branches will be collected and organized according to a unified structure, fully retaining the associated content such as branch identifiers, corresponding indicators, and calculated scores, and finally converging to form a complete performance calculation result set.

[0031] It should be further explained that in S2, the specific steps for calculating the weighted score of each row by dimension include the following: S21: Traverse the list of accounting dimensions configured by the management personnel, filter out the indicator value records belonging to the current dimension from the standardized performance data tuples, and collect them according to the row identifier.

[0032] S22: Read the weight value corresponding to each indicator in the current dimension, multiply the collected data records of each sub-row by the corresponding indicator weight, and then sum them up to generate the weighted score of each sub-row in the current dimension; switch to the next dimension and repeat the process until all dimensions are processed to obtain the set of weighted scores of each sub-row in all dimensions.

[0033] It should be noted that each item in the dimension list includes a dimension name such as "Deposit Dimension", "Loan Dimension", "Intermediate Business Dimension" and a list of indicator field names contained under that dimension.

[0034] The system reads the dimension list and retrieves one dimension at a time in the order they are stored. For the current retrieved dimension, the system accesses the already generated standardized performance data tuple. The standardized performance data tuple is stored in the form of a data table, with each row corresponding to a single original performance record, containing fields such as row identifier, indicator name, indicator value, and calculation status.

[0035] Further, the system performs a filtering operation: it iterates through each row of the data table, checking whether the "Indicator Name" field of that row belongs to the list of indicator field names included in the current dimension. If it does, the row is kept; otherwise, it is skipped. All the filtered rows constitute a temporary dataset for the current dimension. The system groups this temporary dataset according to the "Row ID" field, that is, multiple records with the same row ID are grouped into the same grouping container. Each grouping container stores all indicator value records of that row under the current dimension. After grouping, the system obtains a mapping structure: the key is the row ID, and the value is several indicator value records belonging to the current dimension under that row.

[0036] Further, the system reads the weight value corresponding to each indicator field name in the current dimension. The weight value is a decimal fraction, and the sum of all indicator weights equals 1. The system obtains the generated grouping mapping structure and iterates through each row. For the currently traversed row group, the system obtains all indicator value records within that group and reads the indicator value field of each record one by one. The system multiplies this value by the corresponding weight value of the indicator to obtain a product. The system adds the product of all indicators in the current row to a temporary variable. After traversing all records in the current row group, the value stored in the temporary variable is the weighted score of that row in the current dimension. The system associates and stores this weighted score with the identifier of that row.

[0037] For example, the data is written to a temporary dictionary with "row identifier" as the key and "dimension score" as the value. After calculating one row, the temporary variable is cleared, and the next row is processed. When all rows have been processed, the system writes the scores of all rows for the current dimension into a column of the performance calculation result set. Subsequently, the system switches to the next dimension in the calculation dimension list and repeats steps S21 and S22 until all dimensions have been processed. Ultimately, each row in the performance calculation result set corresponds to one row, and each column corresponds to the weighted score of one dimension.

[0038] S3: Perform data integrity verification on each record field, formula logic verification by substituting the calculation results back into the original formula to verify the error range, historical data trend verification by comparing the current results with the historical results of the past four quarters using moving average and standard deviation, and compliance verification on whether the data retention period and sensitive field desensitization processing meet internal specifications; push the results of all verifications to the approval node, and form the approved performance results after hierarchical approval.

[0039] In some embodiments, data integrity verification includes the following specific methods: S311: Read the list of required fields in the preset data structure template, read each record in the performance calculation result set one by one, and check whether the record contains each field in the list.

[0040] S312: For a record that is missing any required field, write the line break identifier and the name of the missing field to the exception record table, and mark the record as failing the integrity check; for a record that has all required fields, mark it as passing the integrity check.

[0041] It should be noted that a preset data structure template is loaded from the configuration file. This template defines an array of required field names, with elements including field names such as "Row Identifier," "Indicator Score," "Accounting Status," and "Timestamp." The data table containing the performance calculation results set is opened, and data is read row by row. For each row, the required field array is iterated through, checking each row's field set to see if a field with the same name as a given element exists. The checking method is: obtain the list of field names for the current row, call the list lookup method, and match for string equality. If a required field is found not to be in the current row's field list, the check for that row is immediately stopped, the missing field name is recorded, and the process jumps to the next row.

[0042] Furthermore, the system defines two output containers: one for storing records that pass integrity verification, and the other for storing abnormal records. For records that are determined in S311 to have all required fields present, the system copies the entire record to the pass container and appends an "Integrity Verification Status" field with the value "Pass" to the end of the record. For records with missing fields, the system creates a new abnormal record containing three fields: the line break identifier of the abnormal record, a list of missing field names, and a unique identifier of the original record.

[0043] Furthermore, the abnormal record is written to an abnormal record table, which is stored independently in the verification database. After processing all rows, records that fail verification are discarded, and only records that pass verification are passed to the next verification stage.

[0044] In some embodiments, formula logic verification includes the following specific methods: S321: Read the scores of each indicator for each record from the performance calculation results set, read the original profit-generating indicator value and purchase indicator value corresponding to the record from the standardized performance data tuple, and read the calculation formula text applicable to the record from the rule configuration library.

[0045] S322: Substitute the original indicator values ​​into the calculation formula text to recalculate the score. Compare the recalculated score with the original score in the performance calculation result set and calculate the absolute value of the difference between the two. If the absolute value is greater than the preset floating-point error threshold, mark the record as failing the formula logic verification; otherwise, mark it as passing.

[0046] It should be noted that the system reads the "branch identifier" and various "indicator scores" fields from the current record in the performance calculation results set. Using the "branch identifier" and the current indicator name as the join key, it accesses the standardized performance data tuple table to extract the original profit-generating indicator values ​​corresponding to that branch, such as the average daily deposit balance and marketing expenses. Then, using the current indicator name as the query key, it accesses the calculation formula table in the rule configuration library. Each row of this table stores an indicator name and its corresponding calculation formula text. The calculation formula text is stored using Reverse Polish Notation or prefix expressions, such as "Average Daily Deposit Balance 0.6 * Marketing Expenses 0.4 * +". The system temporarily stores the two extracted original values ​​and one calculation formula text in a memory structure.

[0047] Furthermore, the calculation formula text extracted from S321 is fed into an expression calculator, which has a built-in stack. The calculator reads each element of the expression from left to right, pushing a numerical value onto the top of the stack, popping the top two values ​​from the stack when an operator is encountered, performing the corresponding arithmetic operation, and pushing the result back onto the stack. After reading the entire expression, the only remaining value on the top of the stack is the score to be recalculated.

[0048] Furthermore, the system reads the original score of the record from the performance calculation results set and calculates the absolute value of the re-score minus the original score. The system reads the floating-point error threshold from the configuration and compares the absolute value with the threshold: if the absolute value is less than or equal to the threshold, the "Formula Logic Verification Status" field is appended to the record and assigned the value "Pass"; if it is greater than the threshold, it is assigned the value "Fail", and the absolute value of the difference is written to the exception details field.

[0049] In some embodiments, historical data trend verification includes the following specific methods: S331: Using the current branch identifier and the current indicator name as the query key, retrieve the branch's scores for the same indicator for the past four quarters from the historical performance database, and extract these four score values ​​to form a historical sequence.

[0050] S332: Calculate the mean and standard deviation of the historical series. Set the normal fluctuation range as the mean plus or minus twice the standard deviation. Compare the score of the current quarter with the normal fluctuation range. If the current score exceeds the normal fluctuation range, mark it as a failure of historical data trend verification; otherwise, mark it as a success.

[0051] It should be noted that the query conditions are as follows: the row identifier equals the current value, the indicator name equals the current value, and the quarter identifier belongs to the most recent four quarters. The system executes this query and returns a list containing a maximum of four score values. If fewer than four values ​​are returned, only the actual data points returned are used, and the number of data points is recorded in the log.

[0052] Furthermore, the system receives the returned list of historical scores, assuming the list contains N values ​​(N≤4). The system calculates the average of the list. Iterates through the list, summing each value to obtain the total, and divides the total by N to obtain the average. Calculate the standard deviation. Iterates through the list again, for each value, calculates the difference between that value and the average, squares the difference, sums all squared differences, divides the sum by N to obtain the variance, and then takes the square root of the variance to obtain the standard deviation.

[0053] The normal fluctuation range is defined as follows: the lower limit of normal fluctuation is the average value minus two standard deviations, and the upper limit of normal fluctuation is the average value plus two standard deviations. The system reads the current quarterly score from the current record in the performance calculation result set, compares the current score with the upper and lower fluctuation limits, and marks the "historical trend verification status" as passed if the current score is between the lower and upper limits; otherwise, it is marked as failed if the score is below the lower limit or above the upper limit.

[0054] In some embodiments, compliance verification includes the following specific methods: S341: Read the generation timestamp of each record in the performance calculation result set, read the data retention period threshold from the compliance configuration table, calculate the difference between the current system time and the generation timestamp, and if the difference exceeds the retention period threshold, mark it as a retention period failure.

[0055] S342: Scan each record in the performance calculation result set, and search whether the record contains sensitive fields. If it contains sensitive fields, check whether the field values ​​have been de-identified. Records that have not been de-identified are marked as de-identification failed. Records that have passed both retention period and de-identification are marked as compliance verification passed.

[0056] It should be noted that the list of sensitive fields is stored in a configuration format, supporting addition, deletion, and modification. The desensitization rules are stored as descriptive strings; during checks, the rule strings are parsed to obtain the number of characters to retain and the replacement characters. The traversal order is fields first, then records; the complexity is the number of records multiplied by the average number of fields. The two checks are performed independently, and a logical AND operation is performed at the end.

[0057] S4: Based on the received operational task type, fill the task execution requirements, check-in time window and completion deadline into the task data structure, generate a task data record containing a globally unique identifier, and send the task notification to the terminal of the designated operational personnel according to the preset personnel list and notification preferences.

[0058] In some embodiments, upon receiving a newly issued operational task, the system identifies the task's category. Different task categories correspond to different execution standards, check-in rules, and time constraints. The system calls a preset general task data structure and fills in the core parameters corresponding to this task, such as execution requirements, check-in time window, and task completion deadline, into the structure. At the same time, a globally unique identifier is assigned to each task. This code can distinguish each independent task across the entire system, preventing duplicate identifiers during high-concurrency task issuance.

[0059] S5: Obtain the check-in records and task completion submission records of the operators within the check-in time window, compare the check-in time and submission time with the completion deadline in the task data record, count the number of tasks completed on time, completed after the deadline, and not completed, and summarize them by line dimension, task type dimension, and time dimension to output a task execution statistics report.

[0060] In some embodiments, the system obtains the sign-in records of operators within the sign-in time window and the records submitted after the task is completed. The sign-in time and submission time are compared with the completion deadline in the task data record. The system counts the number of tasks completed on time, completed after the deadline, and not completed. The system then summarizes the results by line dimension, task type dimension, and time dimension, and outputs a task execution statistics report.

[0061] Furthermore, the system periodically collects operation data generated by each terminal device, extracts the sign-in record and task completion submission record corresponding to each task, and extracts the actual sign-in time, actual submission time, and unique task identifier.

[0062] Furthermore, based on the unique task identifier, the system retrieves the task data records generated in the S4 stage, and reads the preset check-in time window and task completion deadline. The actual check-in time is compared with the check-in time window to determine if the check-in occurred within the specified range. Then, the actual submission time is compared with the task completion deadline to classify all tasks into three states: completed on time, completed after the deadline, and incomplete. After determining the status of all tasks, the system initiates multi-dimensional data aggregation. Using the branch as the first aggregation dimension, it statistically analyzes the overall task completion status of all personnel in each branch. Using task type as the second aggregation dimension, it distinguishes the execution status of tasks in different business categories. Using natural days, weeks, and months as time dimensions, it analyzes the total number of tasks and the distribution of status within different time periods. After the multi-dimensional statistical data is integrated, the system completes the content layout according to a fixed report format, generating a task execution statistical report containing statistical values, status percentages, and detailed information.

[0063] S6: Extract the names, numbers, and intra- and inter-table validation logic of each data field from the predefined report filling instructions document, and convert them into field correspondences and validation expressions; use the field correspondences to extract raw data from multiple business systems within the bank and convert them into the form required by the report; validate the converted data according to the validation expressions to generate cash report data that conforms to the regulatory format; read the approved performance results, the task execution statistics report, and the cash report data through a standardized data interface, and perform a consistency comparison on the data pointing to the same branch, the same time period, or the same business indicator among the three; If a discrepancy is found during the comparison, a data correction instruction will be sent to the corresponding business module or a tiered early warning notification will be sent to the management personnel, depending on the type of discrepancy.

[0064] This embodiment transforms textual regulatory requirements into standardized computational expressions to complete report verification, reducing the workload of manual report checking. Fixed field correspondences ensure stable retrieval of target data from multiple business systems. Cross-module data consistency comparisons can promptly detect data anomalies between different business segments, ensuring the consistency of operational data across the entire bank.

[0065] In some specific embodiments, such as Figure 2 As shown, based on step S4, a task data record containing a globally unique identifier is generated. The following will provide a possible embodiment and describe its specific implementation in a non-limiting manner.

[0066] S41: Read the received operational task type code, call the task data structure template, fill in the task type code, task name, distribution scope, execution requirement description, creation timestamp and creator fields in the template, and generate a basic field set; S42: Query the extended field configuration table corresponding to the task type code, dynamically append the check-in time window, completion deadline and task execution requirements fields to the basic field set, and write them into the data structure of the task data record; S43: Read the current system timestamp, call the random sequence generator to generate a random sequence, concatenate the timestamp and the random sequence to generate a globally unique identifier, write the globally unique identifier into the primary key field of the task data record, and store it in the task management database.

[0067] In some embodiments, a task data structure template is pre-installed in the system configuration library. The template defines the field names, data types, length limits, and whether the basic fields are required. Based on the template field list, the task type code, task name, distribution scope, execution requirement description, creation timestamp, and creator fields are populated sequentially.

[0068] Furthermore, the extended field configuration table pre-defines the mapping relationship between different task type codes and the extended field list. Each record in the table contains the task type code, extended field name, extended field data type, and extended field default value.

[0069] Furthermore, a random sequence generator is invoked to generate a random sequence consisting of uppercase and lowercase letters and numbers, with a fixed length of eight characters. The timestamp is converted to a string format and concatenated with the random sequence, separated by a fixed delimiter, to generate a globally unique identifier. The system reads the current maximum primary key value from the task management database, compares the globally unique identifier with the existing primary key value, and checks for conflicts. If a conflict occurs, the random sequence generator is invoked again, replacing part of the random sequence, and the comparison is repeated until no conflict occurs. The conflict-free globally unique identifier is written to the primary key field of the task data record. The database write interface is called to store the task data record into the task management database, where a composite index is created for the task identifier field and the executor field. The composite index supports fast retrieval of pending tasks by executor, reducing the overhead of full table scans.

[0070] In some specific embodiments, such as Figure 3 As shown, based on S6, extracting the names, numbers, and intra- and inter-table validation logic of each data field from the predefined report entry instructions document, and converting them into field correspondences and validation expressions specifically includes the following steps: S61: Locate the table area in the report filling instructions document, read the cell content row by row, parse the field name, field number and the field's position coordinates in the report from each cell, and generate a field mapping table.

[0071] S62: Scan natural language paragraphs in the document, identify statements containing relational words such as "equal to", "sum of", and "greater than", extract the field numbers in the statements, combine them into a validation expression according to the relational word type, and store it in the validation rule base.

[0072] It should be noted that for each sentence, the system scans whether it contains a predefined list of relational terms. The list of relational terms is divided into three categories: equivalence relational terms are "equal to," "is," "should be," and "must be." Summation relational terms are "sum," "total," and "add to." Comparison relational terms are "greater than," "less than," and "cannot be negative."

[0073] If a sentence matches a relational term, the system further extracts field numbers from the sentence. The extraction method is as follows: a regular expression is used to match all field number patterns appearing in the document. The extracted field numbers are then arranged into a list of numbers in the order they appear in the sentence. For equality relational terms, an expression of the form "field A = field B" is constructed, where field A and field B are the first two numbers in the list; for summation relational terms, an expression of the form "field A = field B + field C + …" is constructed.

[0074] In this system, field A is the number on the left side of the equals sign, and the remaining numbers are connected on the right side using plus signs. For comparison terms, the system constructs forms such as "field A > 0" or "field A >= field B". The system stores each validation expression, along with its rule number, applicable report tab, and list of involved fields, in the validation rule base. Each rule in the rule base contains: rule ID, page signature name, expression string, and expression type.

[0075] In some specific embodiments, such as Figure 4 As shown in S6, the process of extracting raw data from multiple internal business systems of the bank using the field correspondence and converting it into the required format for reports, and then validating the converted data according to the validation expression to generate cash report data that conforms to the regulatory format, specifically includes the following steps: S611: Traverse each record in the field mapping table, read the corresponding data source connection information and extraction statement according to the field number, connect to the bank's internal business system, execute the extraction statement to obtain the raw value, convert the value according to the unit, precision and format required by the report, and write it into the report data buffer.

[0076] S612: Read each validation expression in the validation rule base, parse the field number in the expression, retrieve the value of the corresponding field from the report data buffer, perform calculations according to the operators in the expression, compare the results on both sides, if all expressions are satisfied, fill the data in the buffer into the report template according to the position coordinates in the field mapping table, and output the report file; if any expression is not satisfied, mark the field involved in the expression as an error field and generate an error list.

[0077] It should be noted that each row in the field mapping table generated by S61 contains four fields: field number, field name, tab, and row / column coordinates. Furthermore, an additional data source registry is configured, recording the data source information corresponding to each field number. The system iterates through each row of the field mapping table, and for the current field number, queries the data source registry to obtain the corresponding connection information.

[0078] Furthermore, the system establishes a database connection to the target business system. If the system type is Oracle, a JDBC driver is used; if it is MySQL, the corresponding connector is used.

[0079] Further, the system loads the validation rule base generated by S62. The system iterates through the rule base, extracting the expression string for each rule. The expression string uses prefix or infix expressions, such as "=R01R02" meaning R01 equals R02, and "+R03R04R05" meaning R03 equals R04 plus R05. The system parses the expression string and extracts the list of field numbers involved in the calculation.

[0080] Furthermore, for each field number, the system retrieves the corresponding value from the report data buffer generated by S611 using that number as the key. If the number does not exist in the buffer, the rule is marked as "cannot be verified" and skipped, and the missing field number is added to the error list.

[0081] Furthermore, for equivalence relationships, the absolute value of the difference between the values ​​on the left and right sides is calculated. If the difference is less than the preset floating-point error threshold, the pass is achieved; otherwise, the pass is failed.

[0082] Furthermore, for summation relationships, the sum of all values ​​on the right is calculated and compared with the values ​​on the left, using the difference threshold in the same way.

[0083] Furthermore, for comparison relationships, the two values ​​are directly compared. If all rules are met, the system reads the position coordinates from the field mapping table and fills the values ​​in the buffer into the report template field by field, ensuring that the format always meets the requirements.

[0084] In some specific embodiments, in S6, the process of reading the approved performance results, the task execution statistical report, and the cash report data through a standardized data interface, and performing a consistency comparison on the data pointing to the same branch, the same time period, or the same business indicator among the three, specifically includes the following steps: S621: Read the average daily deposit balance of a specified branch and a specified quarter from the performance results data table, and read the cash balance of the same branch and the same quarter from the cash statement data. Calculate the absolute value of the difference between the two values. If the absolute value of the difference is less than a preset threshold, mark the two values ​​as consistent; otherwise, mark them as inconsistent.

[0085] S622: Read the on-time completion rate of a specified branch in a specified quarter from the task execution statistics report, read the operation management performance score of the same branch in the same quarter from the performance results data table, calculate the direction of change between the completion rate and the score, and mark it as consistent trend if both rise or fall at the same time, otherwise mark it as inconsistent trend.

[0086] S623: Summarize all records marked with inconsistencies, group them by line identifier and quarter, and generate a consistency verification report. The report includes inconsistent field pairs, actual values, differences, and the identifiers of the business modules involved.

[0087] As can be seen, comparing the direction of change rather than the absolute value avoids the impact of differences in performance score bases between different branches. For example, comparing the direction of change is more comparable between branches with consistently low scores and those with consistently high scores. Grouping and summarizing allows each branch to obtain an independent report quarterly, facilitating distribution to the corresponding branch managers. The summary view provides a snapshot of the overall consistency, allowing users to quickly identify branches with prominent problems or widespread systemic issues.

[0088] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0089] like Figure 5 As shown, this application also provides a server, including a display module 103, a memory 102, a processor 101, a communication module 104, and a computer program stored in the memory and executable on the processor 101. When the processor 101 executes the program, it implements the steps of a bank digital operation performance accounting and cross-module data management method.

[0090] In embodiments of the present invention, a server includes, but is not limited to, laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. A server can also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the embodiments described and / or claimed herein.

[0091] In this embodiment, processor 101 may be implemented using at least one of an application-specific integrated circuit, a programmable logic device, a field-programmable gate array, a processor, a controller, a microcontroller, a microprocessor, or an electronic unit designed to perform the functions described herein. In some cases, such an implementation may be implemented within a controller. For software implementation, implementations such as processes or functions may be implemented with separate software modules that allow the performance of at least one function or operation. Software code may be implemented by a software application (or program) written in any suitable programming language, and the software code may be stored in memory and executed by the controller.

[0092] The display module 103 is used to display information input by the user or information provided to the user. The display module 103 may include a display panel, which may be configured in the form of a liquid crystal display, an organic light-emitting diode, or the like.

[0093] The memory 102 can be used to store software programs and various data. The memory 102 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0094] The communication module 104 transmits radio signals to and / or receives radio signals from at least one of a base station, an external terminal, and a server. Such radio signals may include voice call signals, video call signals, or various types of data sent and / or received according to text and / or multimedia messages.

[0095] The present invention also provides a storage medium storing a computer program thereon, wherein the computer program, when executed by a processor, implements the steps of the bank digital operation performance accounting and cross-module data management method.

[0096] The storage medium may be any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example,, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0097] The storage medium stores a program product capable of implementing the methods described above in this specification. In some possible implementations, various aspects of this disclosure may also be implemented as a program product comprising program code that, when run on a terminal device, causes the terminal device to perform the steps described in the "Exemplary Methods" section of this specification according to various exemplary embodiments of this disclosure.

[0098] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for performance accounting and cross-module data management in digital bank operations, characterized in that, The server performs the following steps: S1: According to the preset data structure template, merge the received data, add accounting status labels to the merged data, and generate standardized performance data tuples; S2: Based on the accounting dimensions, indicator weights and calculation formulas configured by the management personnel, the standardized performance data tuples are grouped by branch identifier, and the weighted score of each branch is calculated one by one according to the dimension. The results are then summarized to obtain a performance calculation result set containing the scores of each indicator of each branch. S3: Perform data integrity verification on each record field, formula logic verification by substituting the calculation result back into the original formula to verify the error range, historical data trend verification by comparing the current result with the historical results of the past four quarters using moving average and standard deviation, and compliance verification on whether the data retention period and sensitive field desensitization processing meet the internal specifications. The results of all verifications will be pushed to the approval node, and after hierarchical approval, the performance results will be confirmed. S4: Based on the type of operational task received, fill the task execution requirements, check-in time window and completion deadline into the task data structure to generate task data records; S5: Obtain the sign-in records and task completion submission records of the operators within the sign-in time window, compare the sign-in time and submission time with the completion deadline in the task data record, count the number of tasks completed on time, completed after the deadline, and not completed, and summarize them by line dimension, task type dimension and time dimension, and output a task execution statistics report. S6: Extract validation logic from the predefined report entry instructions document, convert it into field correspondence and validation expressions; use the field correspondence to extract and convert the required report format; validate the converted data according to the validation expressions to generate cash report data; read performance results, task execution statistics reports and cash report data, perform consistency comparison on the data pointing to the same branch, the same time period or the same business indicator among the three, and output the comparison results.

2. The method for bank digital operation performance accounting and cross-module data management according to claim 1, characterized in that, In S2, the weighted score for each row is calculated according to each dimension, which includes the following steps: Iterate through the list of accounting dimensions configured by the management personnel, filter out the indicator value records belonging to the current dimension from the standardized performance data tuples, and group them according to the row identifier; Read the weight value corresponding to each indicator in the current dimension, multiply the collected data records of each sub-row by the corresponding indicator weight, and then sum them up to generate the weighted score of each sub-row in the current dimension; switch to the next dimension and repeat the process until all dimensions are processed to obtain the set of weighted scores of each sub-row in all dimensions.

3. The method for bank digital operation performance accounting and cross-module data management according to claim 1, characterized in that, In S3, data integrity verification includes the following specific methods: Read the list of required fields in the preset data structure template, read each record in the performance calculation result set one by one, and check whether the record contains every field in the list; For records that are missing any required field, write the line break identifier and the name of the missing field to the exception record table, and mark the record as failing the integrity check; for records that have all required fields, mark them as passing the integrity check. Formula logic verification includes the following specific methods: Read the scores of each indicator for each record from the performance calculation results set, read the original profit-generating indicator value and purchase indicator value corresponding to the record from the standardized performance data tuple, and read the calculation formula text applicable to the record from the rule configuration library; Substitute the original indicator values ​​into the calculation formula text to recalculate the score. Compare the recalculated score with the original score in the performance calculation result set, and calculate the absolute value of the difference between the two. If the absolute value is greater than the preset floating-point error threshold, mark the record as failing the formula logic verification; otherwise, mark it as passing.

4. The method for bank digital operation performance accounting and cross-module data management according to claim 1, characterized in that, In S3, historical data trend verification includes the following specific methods: Using the current branch identifier and the current indicator name as the query key, retrieve the branch's scores for the same indicator over the past four quarters from the historical performance database, and extract these four score values ​​to form a historical sequence. Calculate the mean and standard deviation of the historical series, set the normal fluctuation range as the mean plus or minus two standard deviations, compare the score of the current quarter with the normal fluctuation range, if the current score exceeds the normal fluctuation range, mark it as a failure of historical data trend verification, otherwise mark it as a success; Compliance verification includes the following specific methods: Read the generation timestamp of each record in the performance calculation result set, read the data retention period threshold from the compliance configuration table, calculate the difference between the current system time and the generation timestamp, and if the difference exceeds the retention period threshold, mark it as a retention period failure. Scan each record in the performance calculation result set and search for sensitive fields. If a sensitive field is found, check whether the field value has been anonymized. Records that have not been anonymized are marked as failing the anonymization process. Records that pass both the retention period and anonymization are marked as passing the compliance verification.

5. The method for bank digital operation performance accounting and cross-module data management according to claim 1, characterized in that, S4 specifically includes the following steps: Read the received operational task type code, call the task data structure template, and fill in the task type code, task name, distribution scope, execution requirement description, creation timestamp and creator fields in the template to generate a basic field set; Query the extended field configuration table corresponding to the task type code, dynamically append the check-in time window, completion deadline and task execution requirements fields to the basic field set, and write them into the data structure of the task data record; Read the current system timestamp, call the random sequence generator to generate a random sequence, concatenate the timestamp and the random sequence to generate a globally unique identifier, write the globally unique identifier into the primary key field of the task data record, and store it in the task management database.

6. The method for bank digital operation performance accounting and cross-module data management according to claim 1, characterized in that, In S6, the conversion to field correspondence and validation expressions specifically includes the following steps: Locate the table area in the report filling instructions document, read the cell content row by row, and parse the field name, field number, and field position coordinates in the report from each cell to generate a field mapping table; Scan natural language paragraphs in the document, identify statements containing terms such as equal to, sum of, and greater than, extract the field numbers from the statements, combine them into validation expressions according to the type of relation, and store them in the validation rule base.

7. The method for bank digital operation performance accounting and cross-module data management according to claim 1, characterized in that, In step S6, raw data is extracted from multiple internal business systems of the bank using the field correspondence and converted into the format required for the report. The converted data is then validated according to the validation expression to generate cash report data that conforms to the regulatory format. This process specifically includes the following steps: Iterate through each record in the field mapping table, read the corresponding data source connection information and extraction statement according to the field number, connect to the bank's internal business system, execute the extraction statement to obtain the raw value, convert the value according to the unit, precision and format required by the report, and write it into the report data buffer. Read each validation expression in the validation rule base, parse the field number in the expression, retrieve the value of the corresponding field from the report data buffer, perform calculations according to the operators in the expression, compare the results on both sides, and if all expressions are satisfied, fill the data in the buffer into the report template according to the position coordinates in the field mapping table and output the report file. If any expression is not satisfied, the field involved in the expression is marked as an error field, and an error list is generated.

8. The method for bank digital operation performance accounting and cross-module data management according to claim 1, characterized in that, In S6, the approved performance results, task execution statistics report, and cash report data are read through a standardized data interface. A consistency comparison is performed on the data from these three sources that point to the same branch, the same time period, or the same business indicator. This includes the following steps: Read the average daily deposit balance of a specified branch and a specified quarter from the performance results data table, and read the cash balance of the same branch and the same quarter from the cash statement data. Calculate the absolute value of the difference between the two values. If the absolute value of the difference is less than a preset threshold, mark the two values ​​as consistent; otherwise, mark them as inconsistent. Read the on-time completion rate of tasks for a specified branch in a specified quarter from the task execution statistics report, and read the operation management performance score of the same branch in the same quarter from the performance results data table. Calculate the direction of change between the completion rate and the score. If both rise or fall at the same time, mark them as having the same trend; otherwise, mark them as having different trends. Summarize all records marked with inconsistencies, group them by line number and quarter, and generate a consistency verification report. The report includes inconsistent field pairs, actual values, differences, and the identifiers of the business modules involved.

9. A server, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the bank digital operation performance accounting and cross-module data management method as described in any one of claims 1 to 8.

10. A storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the bank digital operation performance accounting and cross-module data management method as described in any one of claims 1 to 8.