Bank data exception handling method, storage medium and electronic equipment

Abstract

The invention discloses a bank data exception handling method. Relates to the technical field of finance, and the method comprises the following steps: under the condition that a bank data system accords with an abnormal state, obtaining bank temporary data which is intermediate state data generated in the operation process of the bank data system; inputting first key data in the bank temporary data into the prediction model to obtain a first result output by the prediction model; inputting second key data in the bank temporary data into the sudden drop model to obtain a second result output by the sudden drop model; inputting third key data in the bank temporary data into the multiple variance model to obtain a third result output by the multiple variance model; and in combination with the first result, the second result and the third result, acquiring emergency decision data used for indicating processing of the abnormal state. Through the method and the device, the problem of relatively low abnormal processing accuracy of bank data in related technologies is solved.

Description

Technical Field

[0001] This application relates to the field of big data, and more specifically, to a method, apparatus, storage medium, and electronic device for handling anomalies in bank data. Background Technology

[0002] In scenarios involving anomaly handling in banking data, the data is characterized by high complexity and diverse dimensions. In such cases, relying solely on a single predictive model often fails to accurately generate data to guide emergency response decisions for abnormal situations, leading to low accuracy in anomaly handling within the banking system.

[0003] There is currently no effective solution to the problem of low accuracy in handling anomalies in bank data using related technologies. Summary of the Invention

[0004] The main objective of this application is to provide a method, apparatus, storage medium, and electronic device for handling anomalies in bank data, in order to solve the problem of low accuracy in handling anomalies in bank data in related technologies.

[0005] To achieve the above objectives, according to one aspect of this application, a method for handling anomalies in bank data is provided. The method includes: acquiring temporary bank data when the bank data system is in an abnormal state, wherein the temporary bank data is intermediate state data generated during the operation of the bank data system; inputting a first key data point from the temporary bank data into a prediction model to obtain a first result output by the prediction model, wherein the prediction model is based on self-learning from historical data of transaction indicators based on time series to fit a prediction result, and determining whether the temporary bank data is abnormal based on the difference between the prediction result and the first key data point; inputting a second key data point from the temporary bank data into a sudden drop model to obtain a second result output by the sudden drop model, wherein the sudden drop model is based on the characteristic characteristics of a sudden drop in transaction volume when the bank data system malfunctions to determine whether the temporary bank data is abnormal; inputting a third key data point from the temporary bank data into a multivariate variance model to obtain a third result output by the multivariate variance model, wherein the multivariate variance model is based on the mean and multivariate variance of the third key data point within a preset time range to determine whether the temporary bank data is abnormal; and combining the first result, the second result, and the third result to obtain emergency decision data for indicating how to handle the abnormal state.

[0006] To achieve the above objectives, according to another aspect of this application, an anomaly handling apparatus for bank data is provided. The apparatus includes: a first acquisition unit, configured to acquire temporary bank data when the bank data system exhibits an anomaly state, wherein the temporary bank data is intermediate state data generated during the operation of the bank data system; a first output unit, configured to input first key data from the temporary bank data into a prediction model to obtain a first result output by the prediction model, wherein the prediction model is based on self-learning from historical transaction indicator data using time series data to fit a prediction result, and based on the difference between the prediction result and the first key data, to determine whether the temporary bank data is anomaly-free; and a second output unit, configured to input second key data from the temporary bank data into a... The system employs a first-result model to obtain a second result from the aforementioned sudden drop model, where the sudden drop model is based on the characteristic characteristics of a sudden drop in transaction volume when the aforementioned bank data system experiences a failure, to determine whether the aforementioned temporary bank data is abnormal; a third output unit is used to input the third key data from the aforementioned temporary bank data into a multivariate model to obtain a third result from the multivariate model, where the multivariate model is based on the mean and multivariate of the aforementioned third key data within a preset time range to determine whether the aforementioned temporary bank data is abnormal; a second acquisition unit is used to combine the aforementioned first result, the aforementioned second result, and the aforementioned third result to acquire emergency decision data for indicating how to handle the aforementioned abnormal state.

[0007] In this embodiment, different key data are first extracted from the intermediate state data (i.e., temporary bank data) generated when the bank data system is in an abnormal state and input into different models: The prediction model performs self-learning fitting prediction on historical data of transaction indicators based on time series, and judges the anomaly by comparing the difference with the first key data. This model focuses on capturing the time trend and periodic changes of data and can detect anomalies such as abnormal fluctuations in transaction volume and abnormal deviations in transaction amount that do not conform to historical patterns; The sudden drop model judges whether there is anomaly in the temporary bank data based on the characteristics of a sudden drop in transaction volume when the bank data system fails. It focuses on identifying the sudden drop in key indicators such as transaction volume. Such anomalies are often related to sudden events such as system failures and network interruptions, which are difficult for a single prediction model to capture quickly; The multiple variance model judges whether there is anomaly based on the mean and multiple variance of the third key data within a preset time range. It can identify extreme values ​​in the data distribution and is suitable for detecting situations that deviate significantly from the normal distribution, such as abnormally large transactions and abnormally frequent small transactions.

[0008] By integrating these three models, this embodiment performs anomaly detection on temporary bank data from different angles and dimensions, comprehensively covering various types of bank data anomalies and avoiding the omission of anomalies due to the limited perspective of a single model. Simultaneously, the solution inputs different key data from the temporary bank data into different models. The first key data focuses on time-series related transaction indicators, the second key data focuses on indicators susceptible to failure, such as transaction volume, and the third key data includes indicators with statistical distribution characteristics, such as transaction amount and transaction frequency. This multi-dimensional data input method allows each model to analyze based on its most effective data features, improving the accuracy of anomaly identification.

[0009] After obtaining the output results of the three models, this embodiment performs a comprehensive decision to obtain emergency decision data for indicating the handling of abnormal states. This comprehensive decision mechanism can avoid misjudgments that may occur with a single model. For example, a sudden drop in a transaction volume may be identified as an anomaly by the sudden drop model. However, if the prediction model shows that the drop is in line with historical trends and the multivariate model does not find extreme values, the comprehensive decision may consider that this is not a real anomaly, thereby reducing the misjudgment rate. Conversely, if all three models indicate the existence of an anomaly, the comprehensive decision will more confidently confirm the abnormal state and generate corresponding emergency decision data, thereby achieving the technical effect of improving the accuracy of anomaly handling of bank data and solving the technical problem of low accuracy in anomaly handling of bank data. Attached Figure Description

[0010] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings:

[0011] Figure 1 A hardware block diagram of a computer terminal for implementing an anomaly handling method for bank data is shown.

[0012] Figure 2 This is a flowchart of a method for handling anomalies in bank data provided in an embodiment of this application;

[0013] Figure 3 This is a schematic diagram of a training device for an anomaly handling model of bank data provided in an embodiment of this application;

[0014] Figure 4 This is a structural block diagram of an electronic device according to an embodiment of this application. Detailed Implementation

[0015] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0016] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0017] First, some nouns or terms that appear in the description of the embodiments of this application shall be interpreted as follows:

[0018] It should be noted that the information collected in this application (including but not limited to user account feature information, user device information, user personal information, etc.) and data (including but not limited to data used for display, data used for analysis, etc.) are information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of related data all comply with relevant laws, regulations, and standards, necessary confidentiality measures have been taken, and they do not violate public order and good morals. Corresponding operation entry points are provided for users to choose to authorize or refuse. For example, interfaces are set up between this system and relevant users or organizations, providing users with corresponding operation entry points for them to choose to agree to or refuse automated decision results; if the user chooses to refuse, the process proceeds to the expert decision-making stage.

[0019] Example 1

[0020] According to an embodiment of this application, an embodiment of a method for handling anomalies in bank data is also provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0021] The method embodiment provided in Embodiment 1 of this application can be executed on a mobile terminal, computer terminal, or similar computing device. Figure 1 A hardware block diagram of a computer terminal (or mobile device) for implementing an anomaly handling method for bank data is shown. Figure 1 As shown, the computer terminal 10 (or mobile device) may include one or more processors 102 (shown as 102a, 102b, ..., 102n in the figure) 102 (processor 102 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0022] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10 (or mobile device). As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0023] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the abnormal handling method for bank data in this embodiment. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby implementing the aforementioned abnormal handling method for bank data. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0024] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0025] The display may be, for example, a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 10 (or mobile device).

[0026] Under the aforementioned operating environment, this application provides the following: Figure 2 The method for handling anomalies in bank data is shown. Figure 2 This is a flowchart of an anomaly handling method for bank data according to Embodiment 1 of this application.

[0027] Step S201: When the bank data system is in an abnormal state, obtain temporary bank data, which is intermediate state data generated during the operation of the bank data system.

[0028] Step S202: Input the first key data in the bank's temporary data into the prediction model to obtain the first result output by the prediction model. The prediction model is based on time series to learn from historical data of transaction indicators to fit the prediction result. Based on the difference between the prediction result and the first key data, it is determined whether there is an anomaly in the bank's temporary data.

[0029] Step S203: Input the second key data in the bank's temporary data into the sudden drop model to obtain the second result output by the sudden drop model. The sudden drop model is based on the characteristic characteristics of a sudden drop in transaction volume when the bank's data system fails, and determines whether there are any anomalies in the bank's temporary data.

[0030] Step S204: Input the third key data in the bank's temporary data into the multiple variance model to obtain the third result output by the multiple variance model. The multiple variance model is based on the mean and multiple variance of the third key data within a preset time range to determine whether there are any anomalies in the bank's temporary data.

[0031] Step S205: Combine the first result, the second result, and the third result to obtain emergency decision data for indicating how to handle the abnormal state.

[0032] In an optional embodiment, temporary bank data refers to intermediate state data generated during the operation of the bank's data system. This data is not ultimately stored or used regularly, but it has significant value in detecting system anomalies.

[0033] When a bank conducts a large transfer transaction, the system generates a series of intermediate data, such as temporary records of the transfer amount and temporary changes in the account balance. These data are all temporary data until the transaction is finally completed.

[0034] In an optional embodiment, the prediction model is a model that learns from historical data of transaction indicators based on time series, can fit prediction results, and determines whether there are anomalies in the bank's temporary data by comparing the difference between the prediction results and the first key input data.

[0035] For example, a bank collects transaction amount data for the same time period every day over the past year, and uses time series analysis to learn and predict the expected transaction amount range for the current period. If the actual transaction amount for the current period (the first key data point) differs significantly from the predicted amount, the model determines that there may be an anomaly.

[0036] In an optional embodiment, the sudden drop model is a model that determines whether there are anomalies in the bank's temporary data based on the characteristics of a sudden drop in transaction volume when the bank's data system fails.

[0037] For example, a bank has recorded changes in transaction volume during past system failures and discovered that transaction volume drops sharply within a short period of time during a failure. When a sudden and significant drop in transaction volume is detected in real time (the second key data point), the sudden drop model determines that there may be an anomaly.

[0038] In an optional embodiment, the multiple variance model is a model that determines whether there are anomalies in temporary bank data based on the mean and multiple variance of a third key data within a preset time range.

[0039] For example, a bank might calculate the mean and variance of a certain business metric (such as the number of new customers per day) over the past week at the same time each day, and set a multiple variance threshold. If the difference between this business metric (the third key data point) and the mean in the current time period exceeds the multiple variance threshold, the model will determine that there may be an anomaly.

[0040] In an optional embodiment, emergency decision data, which combines the outputs of the prediction model, the plunge model, and the multivariate model, is used to indicate decision information for handling abnormal states of the bank's data system.

[0041] Assuming that the predictive model, the sudden drop model, and the multiple variance model all determine that there is an anomaly in the bank's temporary data, based on these results, the emergency decision data may indicate that the relevant business operations should be suspended immediately, technical personnel should be notified to conduct a system check, and customers should be notified to explain the situation.

[0042] It should be noted that this embodiment aims to address the problem of low accuracy in anomaly handling caused by the high complexity and multi-dimensionality of data in bank data systems. By acquiring specific data when the bank data system exhibits an anomaly state and conducting comprehensive analysis using multiple models, emergency decision-making data for instructing on handling anomalies is ultimately obtained, thereby improving the accuracy and effectiveness of anomaly handling.

[0043] Optionally, the content of this embodiment can be applied to other embodiments described above, or combined with other embodiments described above.

[0044] The embodiments provided in this application first extract different key data from the intermediate state data (i.e., temporary bank data) generated when the bank data system is in an abnormal state and input them into different models: The prediction model performs self-learning fitting prediction on historical data of transaction indicators based on time series, and judges the anomaly by comparing the difference with the first key data. This model focuses on capturing the time trend and periodic changes of data and can detect anomalies such as abnormal fluctuations in transaction volume and abnormal deviations in transaction amount that do not conform to historical patterns; The sudden drop model judges whether there is anomaly in the temporary bank data based on the characteristics of a sudden drop in transaction volume when the bank data system fails. It focuses on identifying the sudden drop in key indicators such as transaction volume. Such anomalies are often related to sudden events such as system failures and network interruptions, which are difficult for a single prediction model to capture quickly; The multiple variance model judges whether there is anomaly based on the mean and multiple variance of the third key data within a preset time range. It can identify extreme values ​​in the data distribution and is suitable for detecting situations that deviate significantly from the normal distribution, such as abnormally large transactions and abnormally frequent small transactions.

[0045] By integrating these three models, this embodiment performs anomaly detection on temporary bank data from different angles and dimensions, comprehensively covering various types of bank data anomalies and avoiding the omission of anomalies due to the limited perspective of a single model. Simultaneously, the solution inputs different key data from the temporary bank data into different models. The first key data focuses on time-series related transaction indicators, the second key data focuses on indicators susceptible to failure, such as transaction volume, and the third key data includes indicators with statistical distribution characteristics, such as transaction amount and transaction frequency. This multi-dimensional data input method allows each model to analyze based on its most effective data features, improving the accuracy of anomaly identification.

[0046] After obtaining the output results of the three models, this embodiment performs a comprehensive decision to obtain emergency decision data for indicating the handling of abnormal states. This comprehensive decision mechanism can avoid misjudgments that may occur with a single model. For example, a sudden drop in a transaction volume may be identified as an anomaly by the sudden drop model. However, if the prediction model shows that the drop is in line with historical trends and the multivariate model does not find extreme values, the comprehensive decision may consider that this is not a real anomaly, thereby reducing the misjudgment rate. Conversely, if all three models indicate the existence of an anomaly, the comprehensive decision will more confidently confirm the abnormal state and generate corresponding emergency decision data, thereby achieving the technical effect of improving the accuracy of anomaly handling of bank data.

[0047] As an optional solution, obtain temporary bank data, including at least one of the following:

[0048] Obtain transaction volume, where transaction volume refers to the number of business transactions processed by the bank's data system within a first time period. Temporary bank data includes transaction volume.

[0049] Obtain the response time, which refers to the time elapsed from when the user initiates a business request to when the bank's data system returns the processing result. Temporary bank data includes the response time.

[0050] The success rate is defined as the percentage of business transactions successfully processed by the bank's data system during the second time period, relative to the total number of business transactions.

[0051] In an optional embodiment, transaction volume refers to the number of business transactions processed by the bank's data system within a specific first time period. The first time period can be set according to actual needs, such as one hour or one day.

[0052] In an optional embodiment, response time refers to the time elapsed from when a user initiates a business request to when the bank's data system returns a processing result. It reflects the speed at which the system processes user requests.

[0053] In an optional embodiment, the success rate is defined as the percentage of business transactions successfully processed by the bank's data system within a specific second time period, relative to the total number of business transactions. This second time period can also be determined based on specific circumstances, such as a week or a month.

[0054] It should be noted that this embodiment describes the specific data types included when obtaining temporary bank data. At least three aspects can be obtained: transaction volume, response time, and success rate. All of these data fall under the category of temporary bank data.

[0055] Optionally, the content of this embodiment can be applied to other embodiments described above, or combined with other embodiments described above.

[0056] By acquiring temporary data from various sources, such as transaction volume, response time, and success rate, banks can comprehensively reflect the operational status of their data systems. This data allows banks to understand the system's business processing capabilities, performance, and stability. When abnormal changes occur in transaction volume, response time, or success rate, banks can promptly identify potential problems. For example, a sudden drop in transaction volume may indicate poor business promotion results or changes in the market environment; excessively long response times may indicate system performance bottlenecks; and a decreased success rate may suggest system malfunctions or problems with business rules. Based on this data, banks can optimize system performance and adjust business strategies accordingly. For instance, they can allocate system resources rationally based on peak and off-peak transaction times; and optimize business processes and algorithms based on the analysis of response time and success rate, thereby improving user experience and business processing efficiency.

[0057] As an optional approach, the first key data in the bank's temporary data is input into the prediction model to obtain the first result output by the prediction model, including: using transaction volume as the first key data, inputting it into the prediction model to obtain the first result;

[0058] Input the second key data from the bank's temporary data into the sudden drop model to obtain the second result output by the sudden drop model, including: inputting transaction volume as the second key data into the sudden drop model to obtain the second result;

[0059] Inputting the third key data from the bank's temporary data into the multivariate model yields the third result output by the multivariate model. This includes inputting response time and success rate as the third key data into the multivariate model to obtain the third result.

[0060] It should be noted that this embodiment further clarifies the specific key data types selected in the bank's temporary data for different model inputs. In the prediction model, transaction volume is selected as the first key data input to obtain the output result; in the sudden drop model, transaction volume is also selected as the second key data input to obtain the result; and in the multivariate model, response time and success rate are selected as the third key data input to obtain the output result.

[0061] Optionally, the content of this embodiment can be applied to other embodiments described above, or combined with other embodiments described above.

[0062] By selecting appropriate key data for different models, it is possible to more accurately capture anomalies in the operation of banking systems. For example, predictive models can use transaction volume data to detect abnormal fluctuations in transaction volume in advance, drop models can identify system failures by sudden drops in transaction volume, and multivariate models, combining response time and success rate, can comprehensively assess system performance and business processing quality, thereby improving the accuracy of anomaly detection. Quickly and accurately obtaining model output results allows for timely early warning signals, enabling banks to take swift countermeasures. For instance, when a predictive model outputs abnormal results, the bank can adjust its business strategies or prepare contingency resources in advance; when drop models and multivariate models output abnormal results, the bank can immediately investigate system failures or optimize business processes, reducing risk and losses.

[0063] As an optional approach, the bank data system is deployed across at least two campuses. After combining the first, second, and third results to obtain emergency decision-making data for instructing on handling abnormal situations, the method further includes:

[0064] Based on emergency decision-making data, adjustments were made to the deployment of bank data in at least two parks within the bank's data system.

[0065] In an optional embodiment, bank data is distributed across at least two campuses: this means that to ensure data security, availability, and business continuity, the bank stores and deploys data across two or more different physical campuses. Each campus has corresponding data processing and storage capabilities.

[0066] In an optional embodiment, emergency decision data, as mentioned above, is decision information used to indicate the handling of abnormal states in the bank's data system, obtained by comprehensively analyzing the outputs of the prediction model, the sudden drop model, and the multivariate model.

[0067] In an optional embodiment, data deployment is adjusted: based on emergency decision-making data, the distribution, storage method, access permissions, etc. of bank data in at least two parks are replanned and configured to adapt to business needs and system operation requirements under abnormal conditions.

[0068] It should be noted that the bank's data system is not concentrated in one park, but distributed across at least two parks. After combining the first result from the predictive model, the second result from the sudden drop model, and the third result from the multiple variance model to obtain emergency decision data for indicating how to handle abnormal situations, this method will further adjust the deployment of the bank's data across these at least two parks based on this emergency decision data.

[0069] Optionally, the content of this embodiment can be applied to other embodiments described above, or combined with other embodiments described above.

[0070] By adjusting data deployment based on emergency decision-making data, system resource allocation can be quickly optimized under abnormal conditions, ensuring the continued stable operation of the bank's data system, improving system availability and reliability, and reducing the risk of business interruption and data loss due to anomalies. Reasonable data deployment adjustments can ensure that banks can continue to conduct business normally under abnormal circumstances. For example, when transaction volume increases significantly, data migration and load balancing ensure that the system can process business requests in a timely manner, avoiding business backlog and thus enhancing business continuity. Dynamically adjusting data deployment based on emergency decision-making data can make full use of resources in various parks, avoiding resource waste and idleness. For example, migrating some business data to parks with relatively idle resources improves overall resource utilization efficiency and reduces operating costs.

[0071] As an alternative, at least two campuses, including Campus 1 and Campus 2, will be used to adjust the deployment of bank data in the bank's data system across these two campuses based on emergency decision-making data. This includes:

[0072] If emergency decision-making data indicates anomalies in the bank data of the first zone, while the bank data of the second zone does not show any anomalies, the bank data of the first zone will be migrated to the second zone.

[0073] If the emergency decision data indicates that both the bank data in the first and second zones are abnormal, adjustments will be made to the bank data in the first and second zones according to the degree of abnormality indicated by the emergency decision data.

[0074] In an optional embodiment, the first campus and the second campus are two different physical campuses where the bank's data system stores and processes data. They each undertake certain business data processing tasks and may have related relationships such as data backup and synchronization.

[0075] In an optional embodiment, emergency decision data refers to data information derived from a comprehensive analysis of the outputs of the aforementioned prediction model, sudden drop model, and multiple variance model, used to indicate the abnormal state and processing direction of the bank's data system.

[0076] In an optional embodiment, data migration is the process of transferring banking data from one storage location or system within a campus to another storage location or system within another campus.

[0077] In an optional embodiment, data deployment is adjusted: based on emergency decision-making data, the distribution, storage method, access permissions, etc. of bank data in the two parks are replanned and configured to optimize system performance and cope with abnormal situations.

[0078] It should be noted that, for situations where a bank's data system is deployed across at least two zones (specifically, Zone 1 and Zone 2), the specific methods for adjusting the deployment of bank data between zones based on emergency decision-making data are explained. When emergency decision-making data indicates anomalies in Zone 1 while data in Zone 2 is normal, the data from Zone 1 is migrated to Zone 2; if anomalies are present in both zones, the data deployment in both zones is adjusted according to the degree of anomaly indicated by the emergency decision-making data.

[0079] Optionally, the content of this embodiment can be applied to other embodiments described above, or combined with other embodiments described above.

[0080] By adjusting data deployment across different zones based on emergency decision-making data, data can be promptly migrated to normal zones when anomalies occur in a single zone, or resources can be rationally allocated and adjusted according to the severity of anomalies when anomalies occur in multiple zones. This improves the fault tolerance of the bank's data system and reduces business interruptions caused by zone failures. Implementing security measures during data migration prevents data leakage and damage, ensuring the security of bank data. Furthermore, adjusting data deployment based on the severity of anomalies avoids concentrating data in zones with high anomaly rates, reducing data security risks. Adjusting data deployment based on the anomaly level indicated by emergency decision-making data allows for the rational allocation of system resources and improves data processing efficiency. For example, migrating data to zones with relatively idle resources or optimizing zones with lower anomaly rates can improve the performance of the entire bank's data system.

[0081] As an optional approach, by combining the first, second, and third results, emergency decision-making data for instructing on handling abnormal situations can be obtained, including:

[0082] By combining the first, second, and third results, determine the type and degree of abnormality of the abnormal state;

[0083] Obtain emergency decision-making data based on the type and severity of the anomaly.

[0084] In an optional embodiment, the anomaly type refers to different types of anomalies that occur in the bank's data system, such as abnormal data volume (e.g., a sudden increase or decrease in transaction volume), abnormal data quality (e.g., an excessively high data error rate), or abnormal system performance (e.g., excessively long response time or a decrease in success rate).

[0085] In an optional embodiment, the degree of anomaly is used to measure the severity of the abnormal state, and can usually be quantitatively assessed by setting certain indicators and thresholds. For example, the degree of anomaly can be divided into different levels such as mild, moderate, and severe, or the severity of the anomaly can be represented by specific numerical values.

[0086] In an optional embodiment, emergency decision data refers to specific data and information derived from analysis and judgment based on the type and severity of the anomaly, used to guide the handling of abnormal states. This data may include data migration plans, system resource adjustment strategies, and adjustments to business processing priorities.

[0087] It should be noted that this embodiment describes the specific steps for obtaining emergency decision-making data in the anomaly handling process of a bank data system. First, the first result output by the predictive model, the second result output by the sudden drop model, and the third result output by the multi-variance model are comprehensively considered. By analyzing these results, the type and severity of the current anomaly faced by the bank data system are determined. Then, based on the determined anomaly type and severity, corresponding emergency decision-making data is further obtained. This data will provide specific guidance for subsequent handling of the anomaly.

[0088] Optionally, the content of this embodiment can be applied to other embodiments described above, or combined with other embodiments described above.

[0089] By combining the results of multiple models to determine the type and severity of anomalies, and obtaining emergency decision-making data accordingly, it is possible to formulate more accurate handling plans for specific anomalies, avoiding blind handling and improving the precision of anomaly handling. Once the anomaly type and severity are clearly identified, corresponding handling measures can be quickly obtained from pre-set emergency decision-making data, reducing decision-making time and thus shortening emergency response time, reducing the impact of anomalies on banking operations. Emergency decision-making data obtained based on the anomaly type and severity allows for the rational allocation of the bank's human, material, and financial resources, ensuring that resources are invested where they are most needed, improving resource utilization efficiency, and reducing operating costs.

[0090] As an optional solution, after obtaining the bank's temporary data, the method also includes: displaying the bank's temporary data on the first front-end interface of the bank's data system;

[0091] After combining the first, second, and third results to obtain emergency decision data for indicating how to handle abnormal situations, the method further includes displaying the emergency decision data on a second front-end interface of the bank's data system.

[0092] In an optional embodiment, temporary bank data refers to data that is temporarily generated or acquired during the operation of the bank's data system for specific analysis or display purposes. This data may be time-sensitive and is not core business data that is stored for a long period of time.

[0093] In an optional embodiment, the first front-end interface is a user interaction interface in the bank data system specifically used to display temporary bank data. It typically has intuitive charts, tables, and other formats to facilitate users' quick understanding of the content and trends of the temporary data.

[0094] In an optional embodiment, emergency decision data refers to specific data and information derived from the analysis of the abnormal state of the bank's data system (combining the first, second, and third results), used to guide the handling of the abnormal state, which may include countermeasures, resource allocation plans, etc.

[0095] In an optional embodiment, the second front-end interface is a user interface in the bank's data system used to display emergency decision-making data. Its design aims to enable relevant personnel to clearly see the specific content of emergency decisions so that they can take timely action.

[0096] It should be noted that in the processing flow of the bank's data system, upon acquiring temporary bank data, further action is taken. First, this temporary data is displayed on the primary front-end interface of the bank's data system for easy viewing by relevant personnel. Second, after combining the first, second, and third results from the predictive model, the plunge model, and the multivariate variance model to obtain emergency decision-making data for handling abnormal situations, this emergency decision-making data is also displayed on the secondary front-end interface of the bank's data system, enabling relevant personnel to make appropriate decisions and take corresponding actions based on this data.

[0097] Optionally, the content of this embodiment can be applied to other embodiments described above, or combined with other embodiments described above.

[0098] By displaying temporary and emergency decision-making data on the front-end interface, relevant personnel can promptly understand the operational status and anomaly handling of the bank's data system, improving information transparency and reducing problems caused by information asymmetry. The intuitive data presentation provides decision-making support, helping personnel quickly understand the meaning behind the data and the underlying issues, thus enabling more accurate decision-making and action. For example, business personnel can adjust business strategies based on temporary data, and technical personnel can quickly resolve system anomalies based on emergency decision-making data.

[0099] As an optional approach, in the process of combining the first, second, and third results to obtain emergency decision data for indicating how to handle abnormal situations, the method further includes:

[0100] Push production change information of the bank's data system within the third time period, and the real-time production environment operation information currently implemented by the bank's data system;

[0101] By combining generated change information and production environment operation information, the correlation between abnormal states and changes in the production environment can be determined.

[0102] In an optional embodiment, the third time period is a pre-defined time range for collecting production change information of the bank's data system. This time period can be flexibly set according to actual needs and business characteristics, such as the most recent day, week, or month.

[0103] In an optional embodiment, production change information refers to records of changes made to the system architecture, software version, configuration parameters, business processes, etc., in the production environment of the bank's data system. These changes may affect the system's operating status.

[0104] In an optional embodiment, production environment operation information refers to the operation information currently being executed in real time in the bank's data system production environment, such as database read and write operations, server start and stop operations, application update operations, etc.

[0105] In an optional embodiment, the correlation refers to a certain connection or causal relationship between the abnormal state and the change in the production environment. By analyzing this relationship, it can be determined whether the change in the production environment is the cause of the abnormal state.

[0106] It should be noted that in the process of obtaining emergency decision-making data for handling abnormal situations based on the first result of the prediction model, the second result of the sudden drop model, and the third result of the multivariate model, two additional steps are performed. First, the bank's data system pushes production change information and currently implemented production environment operation information within the third time period. Then, this production change information and production environment operation information are combined with the previously obtained model results to analyze and determine whether there is a correlation between the abnormal situation and the changes in the production environment, so as to more accurately identify the cause of the anomaly and provide a basis for subsequent effective emergency decisions.

[0107] Optionally, the content of this embodiment can be applied to other embodiments described above, or combined with other embodiments described above.

[0108] By combining production change information and operational information about the production environment to determine the correlation between abnormal states and changes in the production environment, a more comprehensive analysis of the causes of anomalies can be conducted. This avoids relying solely on model results while ignoring the impact of actual changes in the production environment, thereby improving the accuracy of anomaly diagnosis. Clarifying the correlation between abnormal states and changes in the production environment allows for faster identification of the root cause of problems, enabling targeted emergency decisions, reducing decision-making time, accelerating anomaly handling, and minimizing the impact of anomalies on banking operations. Furthermore, analyzing the correlation between abnormal states and changes in the production environment can identify problems and deficiencies in production environment management, allowing for timely improvements and optimizations, enhancing the stability and reliability of the production environment, and reducing the occurrence of anomalies.

[0109] As an optional solution, for ease of understanding, the above-mentioned methods for handling bank data anomalies are applied to specific application scenarios. With the continuous and rapid development of new business models and formats in the financial industry, and the widespread adoption of new technologies such as cloud platforms, distributed systems, and microservices in the financial sector, the overall architecture of bank information systems is becoming increasingly diverse and flexible. Currently, increasingly stringent financial regulatory requirements and fierce market competition place higher demands on the ability of bank information systems to provide continuous and stable services, especially in the event of large-scale failures, where the ability to quickly restore services becomes a key consideration.

[0110] In the event of a major information system failure, effective emergency decision-making is crucial for the rapid restoration of services. However, given the large scale, complex structure, and flexible architecture of banking information systems, emergency decision-making has long faced the following challenges: First, the information required for emergency decision-making lacks centralized data management, resulting in fragmented and inconveniently accessible information; second, the emergency process lacks observability, making it difficult for decision-makers to grasp the emergency dynamics in real time, leading to increased emergency decision-making costs; third, the inability to accurately grasp the business impact during an emergency leaves emergency resource allocation and reporting in a reactive state; and fourth, the lack of clarity in emergency response measures introduces uncertainty into emergency handling.

[0111] This embodiment addresses the aforementioned issues by utilizing streaming data analytics technology. Through multi-model anomaly detection of transaction data, a rule engine is constructed, integrating various operational and process management information from the bank's information system. This enables the automatic delivery of key elements such as business impact assessment, operational guidance, and emergency measure recommendations in emergency scenarios, thereby effectively improving the efficiency of the bank's information system in making emergency decisions to address complex problems.

[0112] In an optional embodiment, emergency decision-making after an information system failure requires comprehensive reference to various types of information. The first step of this method is to achieve unified aggregation of various types of data, using data collection technologies such as Filebeat, RESTful API, Avro, Kafka, Logstash, and Flume to complete the centralized access of various types of data.

[0113] In the data processing and computation phase, technologies such as MapReduce, Flink, and Spark are used to perform streaming and batch processing of data. For data storage, technologies such as Elasticsearch, Hadoop, and MySQL are used to store various temporary data and the final output results. Simultaneously, Vue.js technology is used to centrally display all processed information on a single screen.

[0114] Business impact assessment provides a basis for decision-making regarding resource allocation and external reporting during emergencies. This method performs real-time calculations on three core indicators of the bank's information system—transaction volume, response time, and success rate. To accurately and promptly detect various business anomalies, multiple models, including predictive models, drop models, and multi-variance models, are selected for multi-dimensional detection.

[0115] The prediction model learns from historical data of trading indicators based on time series, fits reasonable prediction values ​​and upper and lower limits, and judges whether there are anomalies based on the difference between the current value and the prediction value.

[0116] The sudden drop model is based on the characteristics of a sudden drop in transaction volume when a production system fails. If the volume remains below the drop point for several minutes starting from a certain time point, and the drop level continuously exceeds a threshold and continues to exceed the drop threshold for a certain period of time, it determines whether there is an anomaly in the business.

[0117] The mean and multiple variance of the same indicator are calculated based on the statistical multiple variance model over the past 30 days (distinguishing between weekdays and holidays). If the current value exceeds N times the standard deviation, it is determined whether there is an anomaly in the business.

[0118] Currently, most critical information systems in banks have deployed multi-campus high-availability architectures. In the event of a system failure, emergency measures such as campus switchover are primarily implemented to ensure rapid production recovery. Therefore, this approach recommends campus switchover as the primary emergency measure, using streaming calculations of transaction volume across each campus to determine if any anomalies exist. If only a single campus experiences an alarm for a particular scenario, then it checks if another campus also has alarms. If the transaction volume in the other campus is normal, it is recommended to switch the entire application to that campus.

[0119] Analysis of bank system failures revealed that most failures were related to changes in the production environment. Therefore, this embodiment pushes production change information from the past 48 hours, along with current real-time production environment operation information, to help quickly pinpoint whether the current failure was caused by changes in the production environment.

[0120] Filebeat is a lightweight log data transmission tool that can collect and forward log file data to specified targets (such as Elasticsearch, Logstash, etc.). It is commonly used in log collection scenarios and features low resource consumption and simple configuration.

[0121] A RESTful API (Representational State Transfer Application Programming Interface) is an API interface designed based on the REST (Representational State Transfer) architectural style. It uses the HTTP protocol for communication and operates on resources through different HTTP methods (such as GET, POST, PUT, DELETE, etc.). It has advantages such as simplicity and strong scalability, and is widely used for data exchange between various systems.

[0122] Avro is a data serialization system developed by the Apache Software Foundation. It provides rich data type definitions and efficient serialization and deserialization mechanisms, supports multiple programming languages, and is commonly used for data storage and transmission in big data processing scenarios.

[0123] Kafka (Apache Kafka) is a high-throughput distributed publish-subscribe messaging system developed by the Apache Software Foundation. It can handle massive amounts of message data and features high reliability, high scalability, and low latency. It is commonly used in scenarios such as real-time data stream processing, log collection, and system decoupling.

[0124] Logstash is an open-source data collection engine that can dynamically collect, transform, and transmit data. It can integrate with various data sources (such as log files, databases, message queues, etc.) to perform operations such as filtering and transforming data, and then send the processed data to specified targets (such as Elasticsearch, file systems, etc.).

[0125] Flume (Apache Flume) is a distributed, reliable, and available system for efficiently collecting, aggregating, and moving large amounts of log data. It features high fault tolerance and scalability, enabling it to collect data from multiple data sources and transfer it to centralized data storage systems (such as HDFS and HBase).

[0126] MapReduce is a programming model for parallel computation of large-scale datasets (greater than 1TB). It breaks down computational tasks into two phases: Map and Reduce, which are executed in parallel on multiple computing nodes using a distributed computing framework (such as Hadoop), thereby improving data processing efficiency.

[0127] FLINK (Apache Flink, Flink) is an open-source distributed computing engine for stream and batch processing, developed by the Apache Software Foundation. It provides low-latency, high-throughput stream processing capabilities while also supporting batch operations. It features state management and fault tolerance mechanisms, making it suitable for scenarios such as real-time data analysis and complex event processing.

[0128] Spark (Apache Spark) is a fast and versatile cluster computing system developed by the Apache Software Foundation. It provides in-memory computing capabilities, significantly improving data processing speed, supports multiple programming languages, and offers a rich set of data processing APIs, making it suitable for various data processing scenarios such as batch processing, stream processing, and machine learning.

[0129] Elasticsearch is a search engine based on the Lucene library, featuring distributed, highly available, and real-time search capabilities. It can quickly store, search, and analyze large amounts of data, and is commonly used in scenarios such as log analysis, full-text search, and data visualization.

[0130] Hadoop (Apache Hadoop) is an open-source distributed computing framework developed by the Apache Software Foundation. It includes components such as the HDFS distributed file system and the MapReduce distributed computing model. It is capable of handling large-scale datasets and features high fault tolerance and scalability, making it widely used in big data storage and processing.

[0131] MySQL (MySQL) is a relational database management system (RDBMS) developed by the Swedish company MySQL AB, now owned by Oracle. It features high performance, high reliability, and ease of use, supports multiple operating systems, and is widely used in various web applications, enterprise applications, and other scenarios.

[0132] Meanwhile, Vue (Vue.js, Vue) technology is used to centrally display all processed information on a single screen. Vue.js is a progressive JavaScript framework for building user interfaces. It adopts a bottom-up incremental development design, is easy to learn and use, and can efficiently achieve data binding and component-based development. It is often used to build single-page applications (SPAs).

[0133] Optionally, the content of this embodiment can be applied to other embodiments described above, or combined with other embodiments described above.

[0134] Through the embodiments of this application, comprehensive information during emergencies is integrated to simplify emergency decision-making during information system failures, thereby helping bank data centers achieve more efficient and high-quality emergency response.

[0135] The centralized information display function effectively solves the problem of multiple and scattered information sources during emergency decision-making, ensuring that decision-makers can quickly obtain comprehensive and accurate information. Simultaneously, by automatically pushing business impact assessment results after a failure, emergency resource allocation becomes more targeted, enabling the rational allocation of resources based on the actual business impact. Furthermore, real-time display of operational information enhances the observability of the emergency process, allowing decision-makers to monitor the progress of emergency response in real time. The automatic push function for emergency measures significantly improves emergency response efficiency, enabling banks to quickly take effective measures after a failure occurs, minimizing the impact of the failure on business operations.

[0136] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0137] Example 2

[0138] This application also provides an anomaly handling device for bank data. It should be noted that this bank data anomaly handling device can be used to execute the bank data anomaly handling method provided in this application. The following describes the bank data anomaly handling device provided in this application.

[0139] According to embodiments of this application, an apparatus for implementing the above-described method for handling anomalies in bank data is also provided, such as... Figure 3 As shown, the device includes:

[0140] The first acquisition unit 301 is used to acquire temporary bank data when the bank data system is in an abnormal state. The temporary bank data is intermediate state data generated during the operation of the bank data system.

[0141] The first output unit 302 is used to input the first key data in the bank's temporary data into the prediction model to obtain the first result output by the prediction model. The prediction model is based on time series to learn from historical data of transaction indicators to fit the prediction result. Based on the difference between the prediction result and the first key data, it is determined whether there is an anomaly in the bank's temporary data.

[0142] The second output unit 303 is used to input the second key data in the bank's temporary data into the sudden drop model to obtain the second result output by the sudden drop model. The sudden drop model is based on the characteristic characteristics of a sudden drop in transaction volume when the bank's data system fails, and determines whether there is an anomaly in the bank's temporary data.

[0143] The third output unit 304 is used to input the third key data in the bank's temporary data into the multiple variance model to obtain the third result output by the multiple variance model. The multiple variance model is based on the mean and multiple variance of the third key data within a preset time range to determine whether there is an anomaly in the bank's temporary data.

[0144] The second acquisition unit 305 is used to combine the first result, the second result, and the third result to acquire emergency decision data for indicating how to handle abnormal situations.

[0145] For specific implementation examples, please refer to the examples shown in the above-mentioned bank data anomaly handling method, which will not be repeated here.

[0146] The embodiments provided in this application first extract different key data from the intermediate state data (i.e., temporary bank data) generated when the bank data system is in an abnormal state and input them into different models: The prediction model performs self-learning fitting prediction on historical data of transaction indicators based on time series, and judges the anomaly by comparing the difference with the first key data. This model focuses on capturing the time trend and periodic changes of data and can detect anomalies such as abnormal fluctuations in transaction volume and abnormal deviations in transaction amount that do not conform to historical patterns; The sudden drop model judges whether there is anomaly in the temporary bank data based on the characteristics of a sudden drop in transaction volume when the bank data system fails. It focuses on identifying the sudden drop in key indicators such as transaction volume. Such anomalies are often related to sudden events such as system failures and network interruptions, which are difficult for a single prediction model to capture quickly; The multiple variance model judges whether there is anomaly based on the mean and multiple variance of the third key data within a preset time range. It can identify extreme values ​​in the data distribution and is suitable for detecting situations that deviate significantly from the normal distribution, such as abnormally large transactions and abnormally frequent small transactions.

[0147] By integrating these three models, this embodiment performs anomaly detection on temporary bank data from different angles and dimensions, comprehensively covering various types of bank data anomalies and avoiding the omission of anomalies due to the limited perspective of a single model. Simultaneously, the solution inputs different key data from the temporary bank data into different models. The first key data focuses on time-series related transaction indicators, the second key data focuses on indicators susceptible to failure, such as transaction volume, and the third key data includes indicators with statistical distribution characteristics, such as transaction amount and transaction frequency. This multi-dimensional data input method allows each model to analyze based on its most effective data features, improving the accuracy of anomaly identification.

[0148] After obtaining the output results of the three models, this embodiment performs a comprehensive decision to obtain emergency decision data for indicating the handling of abnormal states. This comprehensive decision mechanism can avoid misjudgments that may occur with a single model. For example, a sudden drop in a transaction volume may be identified as an anomaly by the sudden drop model. However, if the prediction model shows that the drop is in line with historical trends and the multivariate model does not find extreme values, the comprehensive decision may consider that this is not a real anomaly, thereby reducing the misjudgment rate. Conversely, if all three models indicate the existence of an anomaly, the comprehensive decision will more confidently confirm the abnormal state and generate corresponding emergency decision data, thereby achieving the technical effect of improving the accuracy of anomaly handling of bank data.

[0149] As an optional solution, the first acquisition unit 301 includes at least one of the following:

[0150] The first acquisition module is used to acquire transaction volume, where transaction volume refers to the number of business transactions processed by the bank's data system within a first time period. Temporary bank data includes transaction volume.

[0151] The second acquisition module is used to acquire the response time, where the response time refers to the time elapsed from when the user initiates a business request to when the bank's data system returns the processing result. Temporary bank data includes the response time.

[0152] The third acquisition module is used to obtain the success rate, which refers to the proportion of business transactions successfully processed by the bank's data system to the total number of business transactions during the second time period.

[0153] For specific implementation examples, please refer to the examples shown in the above-mentioned bank data anomaly handling method, which will not be repeated here.

[0154] As an optional solution, the first output unit 302 includes: a first output module, used to input the transaction volume as the first key data into the prediction model to obtain a first result;

[0155] The second output unit 303 includes: a second output module, used to input the transaction volume as the second key data into the sudden drop model to obtain a second result;

[0156] The third output unit 304 includes: a third output module, which is used to input response time and success rate as the third key data into the multivariate model to obtain the third result.

[0157] For specific implementation examples, please refer to the examples shown in the above-mentioned bank data anomaly handling method, which will not be repeated here.

[0158] As an optional solution, the bank data system is deployed across at least two campuses, and the equipment also includes:

[0159] The deployment unit is used to adjust the deployment of bank data in at least two campuses based on emergency decision data obtained by combining the first result, the second result, and the third result to indicate the handling of abnormal states.

[0160] For specific implementation examples, please refer to the examples shown in the above-mentioned bank data anomaly handling method, which will not be repeated here.

[0161] As an optional solution, at least two campuses are included, comprising a first campus and a second campus, and the deployment unit includes:

[0162] The first deployment module is used to migrate bank data from the first park to the second park when emergency decision data indicates that there is an anomaly in the bank data of the first park, but there is no anomaly in the bank data of the second park.

[0163] The second deployment module is used to adjust the deployment of bank data in both the first and second parks according to the degree of anomaly indicated by the emergency decision data when both the first and second parks' bank data show abnormalities.

[0164] For specific implementation examples, please refer to the examples shown in the above-mentioned bank data anomaly handling method, which will not be repeated here.

[0165] As an optional solution, the second acquisition unit 305 includes:

[0166] The determination module is used to combine the first result, the second result, and the third result to determine the type and degree of abnormality of the abnormal state.

[0167] The acquisition module is used to obtain emergency decision-making data based on the type and severity of the anomaly.

[0168] For specific implementation examples, please refer to the examples shown in the above-mentioned bank data anomaly handling method, which will not be repeated here.

[0169] As an optional solution, the device also includes: a first display unit, used to display the temporary bank data on the first front-end interface of the bank data system after the temporary bank data is acquired;

[0170] The device also includes a second display unit, which displays the emergency decision data on the second front-end interface of the bank data system after combining the first result, the second result, and the third result to obtain emergency decision data for indicating the handling of abnormal states.

[0171] For specific implementation examples, please refer to the examples shown in the above-mentioned bank data anomaly handling method, which will not be repeated here.

[0172] As an optional solution, the device also includes:

[0173] The push unit is used to push production change information of the bank data system in the third time period and production environment operation information currently implemented by the bank data system in real time during the process of combining the first result, the second result and the third result to obtain emergency decision data for indicating the handling of abnormal states.

[0174] The determining unit is used to determine the correlation between the abnormal state and changes in the production environment by combining the first result, the second result, and the third result to obtain emergency decision data for indicating the handling of abnormal states, and by combining the generated change information and production environment operation information.

[0175] For specific implementation examples, please refer to the examples shown in the above-mentioned bank data anomaly handling method, which will not be repeated here.

[0176] It should be noted that the first acquisition unit 301, the first output unit 302, the second output unit 303, the third output unit 304, and the second acquisition unit 305 mentioned above correspond to steps S201 to S205 in Embodiment 1. The instances and application scenarios implemented by each module and the corresponding steps are the same, but are not limited to the content disclosed in Embodiment 1. It should be noted that the above modules or units can be hardware or software components stored in memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, ..., 102n). The above modules can also be part of a device and can run in the computer terminal 10 provided in Embodiment 1.

[0177] Example 3

[0178] Embodiments of this application may provide an electronic device. Figure 4 This is a structural block diagram of an electronic device according to an embodiment of this application. Figure 4 As shown, the electronic device may include: one or more ( Figure 4 (Only one is shown) Processor 402, memory 404, memory controller, and peripheral interface, wherein the peripheral interface is connected to the radio frequency module, audio module and display.

[0179] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the methods and apparatus in the embodiments of this application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby implementing the above-described methods. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0180] The processor can access information and applications stored in memory via a transfer device to perform the following steps:

[0181] When a bank's data system exhibits abnormal conditions, temporary bank data is acquired. This temporary data refers to intermediate state data generated during the operation of the bank's data system. The first key data from this temporary data is input into a prediction model, yielding a first output. This prediction model uses time-series data to learn from historical transaction indicators and fits the predicted result. The difference between the predicted result and the first key data is used to determine if the temporary data is abnormal. The second key data from this temporary data is input into a sudden drop model, yielding a second output. This sudden drop model is based on the characteristics of sudden drops in transaction volume during a bank data system failure, determining if the temporary data is abnormal. The third key data from this temporary data is input into a multivariate variance model, yielding a third output. This multivariate variance model is based on the mean and multiple variance of the third key data within a preset time range, determining if the temporary data is abnormal. Combining the first, second, and third results, emergency decision-making data for indicating how to handle the abnormal state is obtained.

[0182] Obtaining temporary bank data includes at least one of the following: obtaining transaction volume, where transaction volume refers to the number of business transactions processed by the bank's data system within a first time period, and temporary bank data includes transaction volume; obtaining response time, where response time refers to the time elapsed from when a user initiates a business request to when the bank's data system returns a processing result, and temporary bank data includes response time; obtaining success rate, where success rate refers to the proportion of business transactions successfully processed by the bank's data system to the total number of business transactions within a second time period.

[0183] The first key data from the bank's temporary data is input into the prediction model to obtain the first result output by the prediction model, including: using transaction volume as the first key data and inputting it into the prediction model to obtain the first result; the second key data from the bank's temporary data is input into the plunge model to obtain the second result output by the plunge model, including: using transaction volume as the second key data and inputting it into the plunge model to obtain the second result; the third key data from the bank's temporary data is input into the multivariate model to obtain the third result output by the multivariate model, including: using response time and success rate as the third key data and inputting them into the multivariate model to obtain the third result.

[0184] The bank data system is deployed in at least two parks. After combining the first result, the second result, and the third result to obtain emergency decision data for indicating the handling of abnormal states, the method also includes: adjusting the deployment of the bank data system in at least two parks based on the emergency decision data.

[0185] At least two parks, including a first park and a second park, will be involved. Based on emergency decision-making data, adjustments will be made to the deployment of bank data in the bank data system across the at least two parks. This includes: migrating the bank data from the first park to the second park if the emergency decision-making data indicates anomalies in the bank data of the first park but not in the bank data of the second park; and adjusting the deployment of the bank data in both the first and second parks according to the degree of anomalies indicated by the emergency decision-making data.

[0186] By combining the first, second, and third results, emergency decision-making data for indicating how to handle abnormal states is obtained, including: determining the type and degree of abnormality of the abnormal state by combining the first, second, and third results; and obtaining emergency decision-making data based on the type and degree of abnormality.

[0187] After obtaining temporary bank data, the method further includes: displaying the temporary bank data on a first front-end interface of the bank data system; and after combining the first result, the second result, and the third result to obtain emergency decision data for indicating the handling of abnormal states, the method further includes: displaying the emergency decision data on a second front-end interface of the bank data system.

[0188] In the process of combining the first, second, and third results to obtain emergency decision data for indicating the handling of abnormal states, the method also includes: pushing production change information of the bank data system in the third time period and the production environment operation information currently implemented by the bank data system in real time; and combining the generated change information and the production environment operation information to determine the correlation between the abnormal state and the changes in the production environment.

[0189] The embodiments provided in this application first extract different key data from the intermediate state data (i.e., temporary bank data) generated when the bank data system is in an abnormal state and input them into different models: The prediction model performs self-learning fitting prediction on historical data of transaction indicators based on time series, and judges the anomaly by comparing the difference with the first key data. This model focuses on capturing the time trend and periodic changes of data and can detect anomalies such as abnormal fluctuations in transaction volume and abnormal deviations in transaction amount that do not conform to historical patterns; The sudden drop model judges whether there is anomaly in the temporary bank data based on the characteristics of a sudden drop in transaction volume when the bank data system fails. It focuses on identifying the sudden drop in key indicators such as transaction volume. Such anomalies are often related to sudden events such as system failures and network interruptions, which are difficult for a single prediction model to capture quickly; The multiple variance model judges whether there is anomaly based on the mean and multiple variance of the third key data within a preset time range. It can identify extreme values ​​in the data distribution and is suitable for detecting situations that deviate significantly from the normal distribution, such as abnormally large transactions and abnormally frequent small transactions.

[0190] By integrating these three models, this embodiment performs anomaly detection on temporary bank data from different angles and dimensions, comprehensively covering various types of bank data anomalies and avoiding the omission of anomalies due to the limited perspective of a single model. Simultaneously, the solution inputs different key data from the temporary bank data into different models. The first key data focuses on time-series related transaction indicators, the second key data focuses on indicators susceptible to failure, such as transaction volume, and the third key data includes indicators with statistical distribution characteristics, such as transaction amount and transaction frequency. This multi-dimensional data input method allows each model to analyze based on its most effective data features, improving the accuracy of anomaly identification.

[0191] After obtaining the outputs of the three models, this embodiment performs a comprehensive decision-making process to obtain emergency decision data for indicating how to handle abnormal states. This comprehensive decision-making mechanism can avoid misjudgments that may occur with a single model. For example, a sudden drop in transaction volume may be identified as an anomaly by the sudden drop model, but if the predictive model shows that the drop is consistent with historical trends and the multivariate model does not find extreme values, the comprehensive decision-making process may consider it not a true anomaly, thus reducing the misjudgment rate. Conversely, if all three models indicate the presence of an anomaly, the comprehensive decision-making process will more confidently confirm the abnormal state and generate corresponding emergency decision data, thereby achieving the technical effect of improving the accuracy of anomaly handling in bank data. Those skilled in the art will understand that... Figure 4 The structure shown is for illustrative purposes only. Electronic devices can also be smartphones (such as Android phones, iOS phones, etc.), tablets, PDAs, mobile internet devices (MIDs), PADs, and other terminal devices. Figure 4This does not limit the structure of the aforementioned electronic device. For example, electronic devices may also include components that are more... Figure 4 The more or fewer components shown (such as network interfaces, display devices, etc.), or having the same Figure 4 The different configurations shown.

[0192] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0193] Example 4

[0194] Embodiments of this application also provide a storage medium. Optionally, in this embodiment, the storage medium can be used to store the program code executed by the training method for the bank data anomaly handling method or the bank data anomaly handling model provided in Embodiment 1.

[0195] Optionally, in this embodiment, the storage medium may be located in any computer terminal in a group of computer terminals in a computer network, or in any mobile terminal in a group of mobile terminals.

[0196] This application also provides a computer program product, which, when executed on a data processing device, is suitable for performing the steps of a method for handling anomalies in bank data or a training method for an anomaly handling model of bank data.

[0197] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

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

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

[0200] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0201] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0202] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0203] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method of processing bank data anomalies, characterized by, The method comprises: acquiring bank temporary data in the case of abnormal state of the bank data system, wherein the bank temporary data is intermediate state data generated in the running process of the bank data system; inputting first key data in the bank temporary data into a prediction model to obtain a first result output by the prediction model, wherein the prediction model is based on self-learning of time series on transaction index historical data, is used for fitting a prediction result, and judges whether the bank temporary data is abnormal based on the difference between the prediction result and the first key data; inputting second key data in the bank temporary data into a sudden drop model to obtain a second result output by the sudden drop model, wherein the sudden drop model is based on the characteristic representation of transaction volume sudden drop when the bank data system fails, and judges whether the bank temporary data is abnormal; inputting third key data in the bank temporary data into a multiple variance model to obtain a third result output by the multiple variance model, wherein the multiple variance model is based on the mean value and multiple variance of the third key data within a preset time range, and judges whether the bank temporary data is abnormal; combining the first result, the second result, and the third result to acquire emergency decision data for indicating processing of the abnormal state.

2. The method of claim 1, wherein, The acquisition of the bank temporary data comprises at least one of the following: acquiring transaction volume, wherein the transaction volume refers to the number of business transactions processed by the bank data system within a first time period, and the bank temporary data comprises the transaction volume; acquiring response time, wherein the response time refers to the time elapsed from the initiation of a business request by a user to the return of a processing result by the bank data system, and the bank temporary data comprises the response time; acquiring success rate, wherein the success rate refers to the proportion of the number of business transactions successfully processed by the bank data system within a second time period to the total number of business transactions.

3. The method of claim 2, wherein: the inputting of the first key data in the bank temporary data into the prediction model to obtain the first result output by the prediction model comprises inputting the transaction volume as the first key data into the prediction model to obtain the first result; the inputting of the second key data in the bank temporary data into the sudden drop model to obtain the second result output by the sudden drop model comprises inputting the transaction volume as the second key data into the sudden drop model to obtain the second result; the inputting of the third key data in the bank temporary data into the multiple variance model to obtain the third result output by the multiple variance model comprises inputting the response time and the success rate as the third key data into the multiple variance model to obtain the third result.

4. The method of claim 1, wherein, The bank data system has a bank data layout in at least two parks, and after the combination of the first result, the second result, and the third result to acquire the emergency decision data for indicating processing of the abnormal state, the method further comprises: Adjust the deployment of the bank data of the bank data system in the at least two parks based on the emergency decision data.

5. The method of claim 4, wherein, The at least two parks include a first park and a second park, and the adjusting the deployment of the bank data of the bank data system in the at least two parks based on the emergency decision data includes: In a case where the emergency decision data indicates that the bank data of the first park is abnormal and the bank data of the second park is not abnormal, migrating the bank data of the first park to the second park; In a case where the emergency decision data indicates that the bank data of the first park and the bank data of the second park are both abnormal, adjusting the deployment of the bank data of the first park and the second park according to the abnormality degree of the data of the first park and the second park indicated by the emergency decision data.

6. The method according to any one of claims 1 to 5, characterized in that, The obtaining the emergency decision data for indicating the processing of the abnormal state based on the first result, the second result, and the third result includes: determining an abnormal type and an abnormal degree to which the abnormal state belongs based on the first result, the second result, and the third result; obtaining the emergency decision data according to the abnormal type and the abnormal degree.

7. The method of any one of claims 1-5, wherein, after the obtaining the bank temporary data, the method further includes: displaying the bank temporary data on a first front-end interface of the bank data system; after the obtaining the emergency decision data for indicating the processing of the abnormal state based on the first result, the second result, and the third result, the method further includes: displaying the emergency decision data on a second front-end interface of the bank data system.

8. The method according to any one of claims 1 to 5, characterized in that, In the process of the obtaining the emergency decision data for indicating the processing of the abnormal state based on the first result, the second result, and the third result, the method further includes: pushing production change information of the bank data system in a third time period and production environment operation information currently implemented by the bank data system in real time; determining an association between the abnormal state and a change in the production environment based on the production change information and the production environment operation information.

9. A computer-readable storage medium, characterized in that, The computer readable storage medium includes a stored executable program, wherein the executable program controls the device where the computer readable storage medium is located to execute the method of any one of claims 1-8 when the executable program is running.

10. An electronic device, comprising: includes: a memory storing an executable program; a processor configured to execute the program, wherein the program performs the method of any one of claims 1-8 when the program is executed.

Images