Bank branch transaction risk monitoring method, device and equipment and storage medium

Abstract

The embodiment of the invention relates to the technical field of information, and provides a bank branch transaction risk monitoring method and device, equipment and a storage medium, and the method comprises the steps: obtaining transaction data of each application system and each branch; constructing a regional access view of each application system according to the transaction data, wherein the regional access views are used for displaying accessed conditions of each application system in different branches; constructing a branch transaction general monitoring view according to the regional access view of each application system, wherein the branch transaction general monitoring view is used for displaying a transaction relationship between each branch and each application system; and performing risk monitoring on each branch transaction according to the transaction data and a pre-configured branch transaction risk alarm rule, and displaying alarm information on the branch transaction general monitoring view according to a risk monitoring result. Through the embodiment of the invention, the branch application system can be comprehensively monitored, the branch risk transaction can be identified in time, and the identification accuracy of the branch risk transaction is improved.

Description

Technical Field

[0001] The embodiments of this specification relate to the field of information technology, and in particular to a method, apparatus, device, and storage medium for monitoring transaction risks in a bank branch. Background Art

[0002] Risk management is paramount in banks' operations and operational decision-making. Currently, commercial banks generally adopt a head office and branch structure, consisting of approximately five tiers: head office, first-tier branches, second-tier branches, first-tier branches, and second-tier branches. Branches are primarily responsible for the overall business coordination and administrative management of all branches, playing a crucial role and function. Preventing and controlling financial risks within branches is an essential component of building a comprehensive risk management system. Branch operations are complex and diverse, and branch personnel must utilize numerous diverse application systems to meet business needs. From an application operations and maintenance perspective, monitoring the usage of various systems within a branch provides a direct reflection of its operational status and is an effective means of mitigating branch transaction risks. However, current application system monitoring primarily focuses on the system itself. This makes it difficult to provide timely insights into branch operational status in the event of a complete network outage, a regional natural disaster, or a failure in the branch's overall operational system.

[0003] In existing technologies, transaction monitoring for branches mainly focuses on internal operations within the branch, with the monitoring content limited to a single system used within the branch. This lacks control over the branch's overall transaction processing. Furthermore, the only criterion for judging branch transaction risk is the branch's transaction volume. From the perspective of branch transactions, the performance and capacity assessment of the application system should also be affected by multiple factors, such as transaction time, transaction success rate, and transaction response rate. A single judgment metric is unable to handle complex transaction scenarios, resulting in low accuracy in monitoring branch risk transactions. Furthermore, the standards for branch risk transaction warnings require manual evaluation and lack dynamic adjustment. Established warning indicators are difficult to meet the specialized needs of branches and are also difficult to respond to emergencies, resulting in insufficient risk identification and untimely warnings. Therefore, there is an urgent need for a bank branch transaction risk monitoring method that can comprehensively monitor branch application systems, promptly identify branch risk transactions, and improve the accuracy of identifying branch risk transactions. Summary of the Invention

[0004] In response to the above-mentioned problems in the prior art, the purpose of the embodiments of this specification is to provide a bank branch transaction risk monitoring method, device, equipment and storage medium to solve the problems of untimely branch transaction risk identification and incomplete branch application system monitoring in the prior art.

[0005] In order to solve the above technical problems, the specific technical solutions of the embodiments of this specification are as follows:

[0006] In one aspect, an embodiment of this specification provides a method for monitoring transaction risk in a bank branch, the method comprising:

[0007] Obtain transaction data from each application system and each branch;

[0008] Constructing a regional access view for each application system based on the transaction data, wherein the regional access view is used to display the access status of each application system in different branches;

[0009] Building a branch transaction total monitoring view based on the regional access view of each application system, wherein the branch transaction total monitoring view is used to display the transaction relationship between each branch and each application system;

[0010] Risk monitoring is performed on each branch transaction based on the transaction data and pre-configured branch transaction risk warning rules, and warning information is displayed on the branch transaction overall monitoring view based on the risk monitoring results.

[0011] Furthermore, constructing a regional access view for each application system based on the transaction data includes:

[0012] Acquiring all transaction data of each application system from the transaction data;

[0013] Constructing an entry flow for each application system based on all transaction data of each application system, wherein the entry flow includes a first destination node and a plurality of first source nodes, wherein the first source node is the IP address of the service terminal initiating the access, and the first destination node is the entry IP address of the accessed application system;

[0014] Determining the region information corresponding to each business terminal IP address based on a pre-built IP address library, wherein the IP address library stores a mapping relationship between the business terminal IP address and the region and branch to which it belongs;

[0015] A regional access view for each application system is constructed according to the entry flow of each application system and the regional information corresponding to each service terminal IP address.

[0016] Furthermore, the step of constructing a branch transaction total monitoring view based on the regional access view of each application system includes:

[0017] Integrate all first destination nodes in the regional access view of each application system into one node, and use the node as the bank-wide application system node;

[0018] Aggregate the regional access views with the same regional information to obtain the transaction views of each branch;

[0019] Build the transaction flow of each branch by using the transaction view of each branch as the second source node, the bank-wide application system node as the second destination node, and the transaction access relationship between the second source node and the second destination node as the edge;

[0020] A total branch transaction monitoring view is constructed based on the transaction flows of each branch.

[0021] Furthermore, the application system entry IP address is determined by:

[0022] Determine the application system entry IP address based on the network area where the application system server is located; or

[0023] Determine the application system entry IP address based on the application system server node type; or

[0024] Determine the application system entry IP address based on the application system deployment type.

[0025] Furthermore, the risk monitoring of each branch's transactions based on the transaction data and pre-configured branch transaction risk warning rules includes:

[0026] Calculating the transaction index value corresponding to each branch based on the transaction data of each application system and each branch;

[0027] Determining each transaction indicator threshold according to the pre-configured transaction risk warning rules for each branch;

[0028] Determine whether each branch has abnormal transaction indicators based on the transaction indicator threshold and the transaction indicator value corresponding to each branch;

[0029] If there is an abnormal trading indicator, determining whether the frequency of occurrence of the abnormal trading indicator within the first specified time period exceeds a preset number of times;

[0030] If so, the branch transactions corresponding to the abnormal transaction indicators exceeding the preset number of occurrence frequencies within the first specified time period are determined to have transaction risks.

[0031] Furthermore, the method further comprises:

[0032] If there are no abnormal transaction indicators, then obtain the historical transaction data of each branch within the second specified time period;

[0033] Calculate the historical transaction index value of each branch based on the historical transaction data;

[0034] Calculate the difference between each branch's transaction index value and historical transaction index value;

[0035] Determining whether there is a transaction indicator value whose difference exceeds a preset difference threshold;

[0036] If so, the branch transaction corresponding to the transaction indicator value whose difference exceeds the preset difference threshold is determined to have transaction risk.

[0037] On the other hand, an embodiment of this specification provides a bank branch transaction risk monitoring device, the device comprising:

[0038] The acquisition module is used to obtain transaction data from each application system and each branch;

[0039] A first construction module is configured to construct a regional access view for each application system based on the transaction data, wherein the regional access view is configured to display the access status of each application system in different branches;

[0040] A second building module is used to build a branch transaction total monitoring view based on the regional access view of each application system, and the branch transaction total monitoring view is used to display the transaction relationship between each branch and each application system;

[0041] The monitoring module is used to monitor the risk of each branch transaction based on the transaction data and pre-configured branch transaction risk warning rules, and display warning information on the branch transaction overall monitoring view based on the risk monitoring results.

[0042] On the other hand, an embodiment of this specification further provides a computer device, including a memory, a processor, and a computer program stored in the memory, wherein when the computer program is run by the processor, the computer program executes instructions of any one of the above methods.

[0043] On the other hand, an embodiment of the present specification further provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor of a computer device, executes instructions of any one of the above methods.

[0044] On the other hand, the embodiments of this specification further provide a computer program product, which, when executed by a processor of a computer device, executes instructions of any one of the above methods.

[0045] By adopting the above technical solution, the bank branch transaction risk monitoring method provided in the embodiment of this specification can cover a wide range of transaction scenarios and data sources by obtaining transaction data from each application system and each branch, thereby ensuring the comprehensiveness and accuracy of risk monitoring. By constructing a regional access view for each application system, it can intuitively display the access status of each application system in different branches, helping bank branches to identify regional risk characteristics. By constructing a branch transaction total monitoring view to display the transaction relationship between each branch and each application system, each branch can more clearly understand the overall situation of transaction activities, making it easier to discover abnormal transaction patterns and potential risk points. By pre-configuring the transaction risk alarm rules for each branch, each branch can flexibly adjust the risk monitoring thresholds and conditions according to its own business characteristics and risk tolerance, thereby improving the pertinence and effectiveness of risk monitoring. Displaying alarm information on the branch transaction total monitoring view based on the risk monitoring results can quickly draw the branch's attention to transaction risks, enable timely implementation of corresponding risk response measures, and reduce risk losses.

[0046] The above description is only an overview of the technical solutions of some embodiments of this specification. In order to more clearly understand the technical means of some embodiments of this specification, they can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the embodiments of this specification more obvious and easy to understand, the following specifically cites preferred embodiments and provides detailed descriptions in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] In order to more clearly illustrate the embodiments of this specification or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0048] Figure 1 A schematic diagram showing the steps of a bank branch transaction risk monitoring method in some embodiments of this specification is shown;

[0049] Figure 2 A schematic diagram of a process for constructing a regional access view for each application system in some embodiments of this specification is shown;

[0050] Figure 3 A schematic diagram of the process of constructing a branch transaction overall monitoring view in some embodiments of this specification is shown;

[0051] Figure 4 A schematic diagram showing the process of risk monitoring of transactions at each branch in some embodiments of this specification is shown;

[0052] Figure 5A schematic diagram showing a process of providing early warnings for transactions at each branch in some embodiments of this specification is shown;

[0053] Figure 6 A schematic diagram showing a regional access view of a certain application system in some embodiments of this specification;

[0054] Figure 7 A schematic diagram showing a branch transaction overall monitoring view in some embodiments of this specification;

[0055] Figure 8 A schematic diagram of the structure of a bank branch transaction risk monitoring device in some embodiments of this specification is shown;

[0056] Figure 9 A schematic structural diagram of a computer device in this specification is shown.

[0057] Description of the accompanying symbols:

[0058] 801. Get module;

[0059] 802, first building block;

[0060] 803, second building block;

[0061] 804, monitoring module;

[0062] 902. Computer equipment;

[0063] 904, processor;

[0064] 906. Memory;

[0065] 908, driving mechanism;

[0066] 910, input / output module;

[0067] 912. Input devices;

[0068] 914. Output device;

[0069] 916. Presentation equipment;

[0070] 918. Graphical User Interface;

[0071] 920, network interface;

[0072] 922, communication link;

[0073] 924. Communication bus. DETAILED DESCRIPTION

[0074] The following will be combined with the drawings in the embodiments of this specification to clearly and completely describe the technical solutions in the embodiments of this specification. Obviously, the embodiments described are only part of the embodiments of this specification, not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by ordinary technicians in this field without making any creative efforts are within the scope of protection of this specification.

[0075] It should be noted that the terms "first," "second," and the like in this specification, the claims, and the accompanying drawings are used to distinguish similar objects and are not necessarily used to describe a particular order or precedence. It should be understood that the terms used in this manner are interchangeable where appropriate, so that the embodiments of this specification described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having," and any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, apparatus, product, or device comprising a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units that are not explicitly listed or that are inherent to such processes, methods, products, or devices.

[0076] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, storage, and display, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. The acquisition, storage, use, and processing of data in the technical solutions described in the embodiments of this application comply with relevant regulations.

[0077] In order to solve the above problems, the present invention provides a method for monitoring transaction risks of bank branches. Figure 1 This is a step diagram of a bank branch transaction risk monitoring method provided in the embodiment of this specification. This specification provides method operation steps as described in the embodiment or flowchart, but may include more or fewer operation steps based on conventional or non-creative labor. The order of steps listed in the embodiment is only one way of executing the steps among many steps, and does not represent the only execution order. When the actual system or device product is executed, it can be executed in the order or in parallel according to the method shown in the embodiment or the accompanying drawings. Specifically, Figure 1 As shown, the method may include:

[0078] S101: Acquire transaction data between each application system and each branch.

[0079] In this embodiment, branches primarily include first-tier and second-tier branches. During business operations, branch personnel utilize a wide range of application systems with diverse functions to meet their business needs. These systems include core business systems, electronic banking systems, payment systems, and customer relationship management systems. Each time a business personnel accesses an application system, corresponding transaction data or access data is generated. This transaction data includes transaction time, transaction amount, transaction type, and information about both parties. In this embodiment, transaction data can be collected from various application systems and branches in real time or periodically using methods such as APIs, database connections, or file transfers, thereby ensuring data integrity, accuracy, and timeliness.

[0080] S102: Constructing a regional access view for each application system based on the transaction data, wherein the regional access view is used to display the access status of each application system in different branches.

[0081] In this embodiment, the regional access view of the application system is a specific view display method. It is based on the transaction data of the application system and divides the source IP (i.e., the IP address of the business terminal) according to the region of the first-level branch and the second-level branch, so as to intuitively display the access situation of each application system in different regions, including which users in which regions have accessed the system, how much access there is, whether there are abnormal accesses, etc. The regional access view of the application system has important application value for banks or financial institutions. It can help business personnel better understand the usage of each application system, discover potential access bottlenecks or security risks, and take corresponding measures to optimize and improve them. At the same time, the regional access view can also provide strong data support for business decisions, helping banks or financial institutions to better meet the needs of customers in different regions.

[0082] S103: Constructing a branch transaction total monitoring view according to the regional access view of each application system, wherein the branch transaction total monitoring view is used to display the transaction relationship between each branch and each application system.

[0083] The branch transaction monitoring view aggregates and integrates transaction data from all branches of the bank, creating a comprehensive overview of each branch's transactions. This view typically includes key transaction metrics such as business hours, transaction volume, transaction success rate, and transaction response rate, and can be displayed in various formats, including heat maps, line charts, and data tables. The branch transaction monitoring view displays transaction data for each branch, helping business personnel promptly identify transaction anomalies or potential risks. By analyzing the transaction data in this view, business personnel can understand transaction trends, transaction characteristics, and customer behavior across branches, providing a basis for business decision-making. Metrics such as transaction success rate and transaction response rate in this view can be used to evaluate each branch's business performance and service quality, providing a basis for performance appraisals. When unusual fluctuations in transaction data in this view occur, business personnel can promptly implement risk warning measures to prevent potential risks.

[0084] S104: performing risk monitoring on each branch transaction according to the transaction data and pre-configured risk warning rules for each branch transaction, and displaying warning information on the overall branch transaction monitoring view according to the risk monitoring results.

[0085] In this embodiment, the configuration of alarm rules is based on branch transaction data, and different alarm rules are configured for each branch's business hours, business scale, special needs, etc. Special needs generally configure separate alarms for a certain type of transaction in a certain branch, a transaction in a certain system, or even a certain transaction. Alarm indicators include transaction volume, transaction success rate, transaction response rate, transaction acceptance rate, transaction response time (which can be divided into average response time, maximum response time, and minimum response time), etc. Transaction risk is identified based on alarm indicators. When the indicators do not meet the set threshold, it is considered that there is a branch transaction risk and an alarm is triggered.

[0086] By adopting the above technical solution, the bank branch transaction risk monitoring method provided in the embodiment of this specification can cover a wide range of transaction scenarios and data sources by obtaining transaction data from each application system and each branch, thereby ensuring the comprehensiveness and accuracy of risk monitoring. By constructing a regional access view for each application system, it can intuitively display the access status of each application system in different branches, helping bank branches to identify regional risk characteristics. By constructing a branch transaction total monitoring view to display the transaction relationship between each branch and each application system, each branch can more clearly understand the overall situation of transaction activities, making it easier to discover abnormal transaction patterns and potential risk points. By pre-configuring the transaction risk alarm rules for each branch, each branch can flexibly adjust the risk monitoring thresholds and conditions according to its own business characteristics and risk tolerance, thereby improving the pertinence and effectiveness of risk monitoring. Displaying alarm information on the branch transaction total monitoring view based on the risk monitoring results can quickly draw the branch's attention to transaction risks, enable timely implementation of corresponding risk response measures, and reduce risk losses.

[0087] In this embodiment, in the process of constructing the regional access view of each application system, it is first necessary to aggregate all transaction inflows of the application system into one stream, which is called the entry stream. The source IP of the entry stream represents the IP address of the business terminal that initiates the access, and the destination IP represents the entry IP address of the application system being accessed. Next, by combing the entry streams of all application systems in the bank, the transaction data of each application system in different regions can be obtained. These data include but are not limited to transaction volume, transaction frequency, transaction period, etc. Finally, according to the regional information of the source IP (i.e., the division of first-level branches and second-level branches), the transaction data is classified and aggregated to form a regional access view for each application system.

[0088] Preferably, in the embodiments of this specification, reference is made to Figure 2 , said constructing a regional access view for each application system based on said transaction data includes:

[0089] S201: Acquire all transaction data of each application system from the transaction data.

[0090] In this embodiment, data is filtered based on the unique identifier of the application system (such as system name, system number, etc.), thereby obtaining all transaction data of each application system. The filtered transaction data is pre-processed to ensure data integrity and consistency.

[0091] S202: Construct an entry flow for each application system based on all transaction data of each application system, wherein the entry flow includes a first destination node and several first source nodes, wherein the first source node is the IP address of the service terminal initiating the access, and the first destination node is the entry IP address of the accessed application system.

[0092] In this embodiment, the ingress flow refers to the traffic generated when business personnel access the application system entrance. It should include the traffic generated by all business personnel authorized to use the application system at all entrances to the application system. An ingress flow should have a clear source address and destination address, where the source address is specifically the IP address of the business personnel's operating terminal, and the destination address is the application system entrance IP address. To ensure the accuracy and comprehensiveness of traffic data, the following strategy is used in actual processes to determine the application system entrance IP address and prevent the loss of ingress traffic:

[0093] (1) Based on the IP address of the application system entrance in the network area where the application system server is located, it can be roughly divided into production area entrance, office area entrance, Internet area entrance, and external area entrance;

[0094] (2) Determine the application system entry IP address based on the application system server node type, which can be roughly divided into virtual machine entry node, full stack cloud entry node, container cloud entry node, and trusted machine entry node;

[0095] (3) Determine the entry IP address of the application system based on the application system deployment type, which can be roughly divided into single-stack operation, dual-stack operation and multi-stack operation.

[0096] The embodiments of this specification do not impose any restrictions on source addresses. It is assumed that as long as traffic accessing the application system is collected, the IP address can be used as the source address of the ingress flow. In the process of constructing the ingress flow, the initiator (business terminal) and recipient (application system portal) of the transaction record are first identified from the transaction data. The IP address of the application system portal being accessed is then used as the first destination node, and the IP addresses of several business terminals that initiated the access are used as the first source nodes. The transaction relationships between the business terminals and the application systems are used as edges to construct the ingress flow for each application system.

[0097] S203: Determine the region information corresponding to each service terminal IP address according to a pre-built IP address database, wherein the IP address database stores a mapping relationship between the service terminal IP address and the region and branch to which it belongs.

[0098] S204: Constructing a regional access view for each application system according to the entry flow of each application system and the regional information corresponding to each service terminal IP address.

[0099] In this embodiment, each business terminal's IP address is matched against a record in the IP address database to identify the corresponding region and branch information. Determining the region information identifies the branch from which the source IP address originates. Generally speaking, within the banking system, branches are directly categorized by region. For example, if an IP address originates from location XX, we consider the access to the branch in location XX. Of course, a given region may contain multiple first-tier branches. For example, location XX includes the first, second, and third branches, each of which is also categorized by IP address. Therefore, the granularity of regional categorization is individual first-tier branches and some key second-tier branches. Because the number of second-tier branches and their subordinate branches is too large to capture key insights from the visual representation, their transaction monitoring has been incorporated into the first-tier branches, though it is no longer displayed separately. When transactions at a second-tier branch or subordinate branch are abnormal, they often generate alerts related to transaction success rates and other factors. In this case, starting from the first-tier branch view, specific second-tier branches or sub-branches can be identified based on IP network segments, allowing for rapid, hierarchical location locating. Therefore, the remaining second-tier branches and subordinate sub-branches are not further categorized. At the same time, attention should be paid to the IP division of overseas branches and specific directly affiliated institutions. These are also important sources of business and are also regarded as first-level branches in the embodiments of this specification.

[0100] Integrate the entry flow of each application system and the regional information corresponding to each business terminal IP address to form entry flow data containing regional information. Then use data visualization tools to build a regional access view of each application system based on the integrated entry flow data, such as Figure 6 As shown. The regional access view should be able to intuitively display the access status of each application system in different regions and branches. In other embodiments, the constructed regional access view can be optimized, such as adjusting the color, line thickness, node size, etc., to improve the readability and aesthetics of the regional access view.

[0101] In this embodiment, when constructing a comprehensive branch transaction monitoring view, systems with the same regional access are first aggregated to obtain a branch's overall transaction monitoring chain, namely the branch transaction flow. The source IP address of the branch transaction flow is the business terminal of a single branch, and the destination IP address is all application systems in the entire bank. Next, the transaction flows of each branch are integrated to form a comprehensive branch transaction monitoring data set. This data set includes key indicators such as transaction time, transaction volume, transaction success rate, and transaction response rate for each branch. Finally, the integrated data is displayed using visualization technology to form a branch transaction monitoring view. This view can take the form of heat maps, line charts, data tables, and other formats, so that staff can intuitively understand the transaction status of each branch.

[0102] Preferably, in the embodiments of this specification, reference is made to Figure 3 The step of constructing a branch transaction monitoring view based on the regional access view of each application system includes:

[0103] S301: Integrate all first destination nodes in the regional access view of each application system into one node, and use the node as the bank-wide application system node.

[0104] Specifically, in the regional access view, all first destination nodes representing application system entrances are identified and merged to form a unified node, the bank-wide application system node, which represents the collection of all bank application systems. This merged bank-wide application system node replaces the original multiple first destination nodes, while retaining the connection between the first source node (the service terminal IP address) and the bank-wide application system node.

[0105] S302: Summarize the regional access views with the same regional information to obtain transaction views of each branch.

[0106] Specifically, regional access views are first classified based on region information, grouping those with the same region information into one category. Each category of regional access views is then aggregated, merging transaction records with the same primary source node (the IP address of a business terminal, specifically different business terminals within a branch) and the same region information. For each category of region information, a branch transaction view is generated, which displays the access status of all business terminals within that branch to the bank's entire application system.

[0107] S303: Build the transaction flow of each branch by taking the transaction view of each branch as the second source node, the bank-wide application system node as the second destination node, and the transaction access relationship between the second source node and the second destination node as the edge.

[0108] S304: Constructing a branch transaction overall monitoring view based on the transaction flows of each branch.

[0109] Specifically, the transaction view of each branch is defined as the second source node, and the bank-wide application system node is defined as the second destination node. Based on the transaction access relationship in the transaction view of each branch, the edges between the second source node and the second destination node are constructed. These edges represent the transaction access paths of the business terminals in the branch to the bank-wide application system. The second source node, the second destination node and the edges between them are combined to form the transaction flow of each branch. The transaction flow intuitively shows the transaction access status between the branch and the bank-wide application system. The transaction flow data of all branches are integrated to form a data set containing the transaction access status of all branches. Finally, a data visualization tool is used to generate a total monitoring view of branch transactions based on this data level. In summary, if Figure 7 As shown, the overall branch transaction monitoring view consists of three components: a single bank-wide system node, a view node for all first-tier branches, and the transaction flow for each branch. The transaction flow no longer distinguishes between specific transaction types, such as channel, office, core accounting, and online transactions. Instead, all accesses are referred to as transactions. This means that from a branch perspective, the focus shifts from specific transaction types to regional transaction risks, which are closely aligned with actual needs. For example, branches may report transaction risks such as multiple system unavailability, overall branch network outages, and regional natural disasters.

[0110] Preferably, in the embodiments of this specification, reference is made to Figure 4 , said risk monitoring of each branch's transactions based on the transaction data and pre-configured branch transaction risk warning rules includes:

[0111] S401: Calculating the transaction index value corresponding to each branch based on the transaction data between each application system and each branch;

[0112] S402: Determine each transaction indicator threshold according to the pre-configured transaction risk warning rules for each branch;

[0113] S403: Determine whether each branch has abnormal transaction indicators based on the transaction indicator threshold and the transaction indicator value corresponding to each branch;

[0114] S404: If there is an abnormal trading indicator, determining whether the frequency of occurrence of the abnormal trading indicator within the first specified time period exceeds a preset number of times;

[0115] S405: If yes, the branch transactions corresponding to the abnormal transaction indicators exceeding the preset number of occurrence frequencies within the first specified time period are determined to have transaction risks.

[0116] It can be understood that, in this embodiment, the configuration of the alarm rules is based on the branch access transaction flow, and alarms with different rules are configured for each branch's business hours, business scale, special needs, etc. Special needs generally configure separate alarms for a certain type of transaction, a certain system's transaction, or even a certain transaction of a certain branch. Alarm indicators include transaction volume, transaction success rate, transaction response rate, transaction acceptance rate, and transaction response time (which can be divided into average response time, maximum response time, and minimum response time). The identification of transaction risks is based on alarm indicators. When the indicators do not meet the set threshold, it is considered that there is a branch transaction risk and an alarm is triggered. Furthermore, the triggering condition of the alarm is mainly frequency alarm, that is, the number of times the transaction indicator is abnormal within a certain period of time. For example, if the transaction success rate is lower than 98% four times within one minute, an alarm is triggered. At the same time, the manifestation of the alarm is an important tool for risk identification. The embodiment of this specification uses the following three methods to display alarm information on the total monitoring view of the branch transaction:

[0117] (1) In the view, the color of the alarm node changes to red to distinguish it from ordinary type nodes. In the branch view, it corresponds to a specific branch;

[0118] (2) In terms of voice, the alarm will trigger a voice broadcast, which will include the branch name, abnormal transaction indicators and the duration of the abnormality;

[0119] (3) In the system, the alarm will trigger an event ticket, which will be automatically distributed to the on-duty personnel at the first time. The content description of the event ticket includes the branch name, the name of the destination application system, and the details of each transaction indicator. The event ticket can be linked with the branch transaction monitoring view, jumping to the view abnormal node and transaction flow, so that the on-duty personnel can quickly analyze the abnormal situation through the view. At the same time, according to the analysis of the transaction message, specific fields can be customized and added to the diagram, such as transaction code, return code, source IP, etc. The display of transaction status includes various forms such as heat map, curve map, data table, etc.

[0120] In this embodiment, the transaction volume is predicted by learning from its own historical transaction volume data to form a transaction volume baseline indicator alarm to identify the transaction risk of a branch's transaction volume increasing or decreasing sharply. Figure 5 , the method further comprises:

[0121] S406: If there is no abnormal transaction indicator, obtain historical transaction data of each branch within the second specified time period;

[0122] S407: Calculating historical transaction index values ​​of each branch based on the historical transaction data;

[0123] S408: Calculate the difference between the transaction index value of each branch and the historical transaction index value;

[0124] S409: Determine whether there is a transaction indicator value whose difference exceeds a preset difference threshold;

[0125] S410: If yes, the branch transaction corresponding to the transaction indicator value whose difference exceeds the preset difference threshold is determined to have transaction risk.

[0126] This specification can be understood as providing early warnings for transaction risks. These warnings primarily rely on baseline alerts. The baseline is based on historical branch data, comparing alert indicators with historical data. Significant discrepancies between these indicators indicate transaction risk and trigger an alert. This alert is often used based on transaction volume metrics. For example, if a branch's transaction volume significantly increases or decreases compared to one or several days prior, even if indicators like transaction success rate meet requirements, the branch may still harbor transaction risks, which should be identified in advance.

[0127] Based on the above-mentioned method for monitoring transaction risks of bank branches, the embodiments of this specification also provide a corresponding device for monitoring transaction risks of bank branches. The device may include a system (including a distributed system), software (application), modules, components, servers, clients, etc. using the method described in the embodiments of this specification and combined with the necessary implementation hardware. Based on the same innovative concept, the devices in one or more embodiments provided in the embodiments of this specification are as described in the following embodiments. Since the implementation scheme and method for solving the problem of the device are similar, the implementation of the specific device in the embodiments of this specification can refer to the implementation of the aforementioned method, and the repetitions will not be repeated. As used below, the term "unit" or "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, the implementation of hardware, or a combination of software and hardware, is also possible and conceived.

[0128] Specifically, Figure 8This is a module structure diagram of an embodiment of a bank branch transaction risk monitoring device provided in this specification, referring to Figure 8 As shown, the embodiment of this specification provides a bank branch transaction risk monitoring device comprising:

[0129] Acquisition module 801, used to obtain transaction data between each application system and each branch;

[0130] A first constructing module 802 is configured to construct a regional access view for each application system based on the transaction data, wherein the regional access view is used to display the access status of each application system in different branches;

[0131] A second building module 803 is configured to build a branch transaction total monitoring view based on the regional access view of each application system, wherein the branch transaction total monitoring view is used to display the transaction relationship between each branch and each application system;

[0132] The monitoring module 804 is configured to monitor the risk of each branch transaction based on the transaction data and pre-configured risk warning rules for each branch transaction, and display warning information on the overall branch transaction monitoring view based on the risk monitoring results.

[0133] The beneficial effects achieved by the device provided in the embodiments of this specification are consistent with the beneficial effects achieved by the above-mentioned method and will not be repeated here.

[0134] Reference Figure 9 As shown, based on the above-described bank branch transaction risk monitoring method, one embodiment of this specification further provides a computer device 902, wherein the above-described method is executed on the computer device 902. The computer device 902 may include one or more processors 904, such as one or more central processing units (CPUs), each of which may implement one or more hardware threads. The computer device 902 may also include any memory 906 for storing any type of information, such as code, settings, data, etc. For example, without limitation, the memory 906 may include any one or more combinations of the following: any type of RAM, any type of ROM, a flash memory device, a hard disk, an optical disk, etc. More generally, any memory may use any technology to store information. Furthermore, any memory may provide volatile or non-volatile retention of information. Furthermore, any memory may represent a fixed or removable component of the computer device 902. In one embodiment, when the processor 904 executes associated instructions stored in any memory or combination of memories, the computer device 902 may perform any operation of the associated instructions. The computer device 902 also includes one or more drive mechanisms 908 for interacting with any storage, such as a hard disk drive mechanism, an optical disk drive mechanism, and the like.

[0135] The computer device 902 may also include an input / output module 910 (I / O) for receiving various inputs (via input devices 912) and for providing various outputs (via output devices 914). A specific output mechanism may include a presentation device 916 and an associated graphical user interface (GUI) 918. In other embodiments, the input / output module 910 (I / O), input devices 912, and output devices 914 may not be included, and the computer device 902 may simply be a computer device in a network. The computer device 902 may also include one or more network interfaces 920 for exchanging data with other devices via one or more communication links 922. One or more communication buses 924 couple the components described above together.

[0136] The communication link 922 may be implemented in any manner, for example, via a local area network, a wide area network (e.g., the Internet), a point-to-point connection, etc., or any combination thereof. The communication link 922 may include any combination of hardwired links, wireless links, routers, gateway functions, name servers, etc., governed by any protocol or combination of protocols.

[0137] Corresponding to Figures 1 to 5 In addition to the method shown, an embodiment of this specification also provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the above method are executed.

[0138] The embodiment of this specification also provides a computer-readable instruction, wherein when the processor executes the instruction, the program therein causes the processor to execute the following Figures 1 to 5 The method shown.

[0139] The embodiment of this specification also provides a computer program product, including at least one instruction or at least one program, which is loaded and executed by a processor to implement the following Figures 1 to 5 The method shown.

[0140] It should be understood that in the various embodiments of this specification, the size of the serial numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this specification.

[0141] It should also be understood that in the embodiments of this specification, the term "and / or" is merely a description of the relationship between associated objects, indicating that three possible relationships exist. For example, "A and / or B" can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone. Furthermore, the character " / " in this specification generally indicates that the associated objects are in an "or" relationship.

[0142] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed in this specification can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the composition and steps of each example according to function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this specification.

[0143] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0144] In the several embodiments provided in this specification, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, or can be an electrical, mechanical or other form of connection.

[0145] The units described as separate components may or may not be physically separate, and 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 may be selected according to actual needs to achieve the purpose of the embodiments of this specification.

[0146] In addition, the functional units in the various embodiments of this specification may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0147] If the integrated unit is implemented in the form of 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 specification is essentially 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, and the computer software product is stored in a storage medium, including a number of instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the method described in each embodiment of this specification. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0148] Specific embodiments are used in this specification to illustrate the principles and implementation methods of this specification. The description of the above embodiments is only used to help understand the methods and core ideas of this specification. At the same time, for those skilled in the art, based on the ideas of this specification, there will be changes in the specific implementation methods and application scope. In summary, the contents of this specification should not be understood as limiting this specification.

Claims

1. A bank branch transaction risk monitoring method, characterized in that: The method comprises: Obtain transaction data from each application system and each branch; Constructing a regional access view for each application system based on the transaction data, wherein the regional access view is used to display the access status of each application system in different branches; Building a branch transaction total monitoring view based on the regional access view of each application system, wherein the branch transaction total monitoring view is used to display the transaction relationship between each branch and each application system; Risk monitoring is performed on each branch transaction based on the transaction data and pre-configured branch transaction risk warning rules, and warning information is displayed on the branch transaction overall monitoring view based on the risk monitoring results.

2. The method according to claim 1, characterized in that The constructing of a regional access view for each application system based on the transaction data includes: Acquiring all transaction data of each application system from the transaction data; Constructing an entry flow for each application system based on all transaction data of each application system, wherein the entry flow includes a first destination node and a plurality of first source nodes, wherein the first source node is the IP address of the service terminal initiating the access, and the first destination node is the entry IP address of the accessed application system; Determining the region information corresponding to each business terminal IP address based on a pre-built IP address library, wherein the IP address library stores a mapping relationship between the business terminal IP address and the region and branch to which it belongs; A regional access view for each application system is constructed according to the entry flow of each application system and the regional information corresponding to each service terminal IP address.

3. The method according to claim 2, characterized in that The step of constructing a branch transaction total monitoring view based on the regional access view of each application system includes: Integrate all first destination nodes in the regional access view of each application system into one node, and use the node as the bank-wide application system node; Aggregate the regional access views with the same regional information to obtain the transaction views of each branch; Build the transaction flow of each branch by using the transaction view of each branch as the second source node, the bank-wide application system node as the second destination node, and the transaction access relationship between the second source node and the second destination node as the edge; A total branch transaction monitoring view is constructed based on the transaction flows of each branch.

4. The method according to claim 2, characterized in that The application system entry IP address is determined in the following way: Determine the application system entry IP address based on the network area where the application system server is located; or Determine the application system entry IP address based on the application system server node type; or Determine the application system entry IP address based on the application system deployment type.

5. The method according to claim 1, wherein The risk monitoring of each branch's transactions based on the transaction data and pre-configured branch transaction risk warning rules includes: Calculating the transaction index value corresponding to each branch based on the transaction data of each application system and each branch; Determining each transaction indicator threshold according to the pre-configured transaction risk warning rules for each branch; Determine whether each branch has abnormal transaction indicators based on the transaction indicator threshold and the transaction indicator value corresponding to each branch; If there is an abnormal trading indicator, determining whether the frequency of occurrence of the abnormal trading indicator within the first specified time period exceeds a preset number of times; If so, the branch transactions corresponding to the abnormal transaction indicators exceeding the preset number of occurrence frequencies within the first specified time period are determined to have transaction risks.

6. The method according to claim 5, characterized in that The method further comprises: If there are no abnormal transaction indicators, then obtain the historical transaction data of each branch within the second specified time period; Calculate the historical transaction index value of each branch based on the historical transaction data; Calculate the difference between each branch's transaction index value and historical transaction index value; Determining whether there is a transaction indicator value whose difference exceeds a preset difference threshold; If so, the branch transaction corresponding to the transaction indicator value whose difference exceeds the preset difference threshold is determined to have transaction risk.

7. A bank branch transaction risk monitoring device, characterized in that: The device comprises: The acquisition module is used to obtain transaction data from each application system and each branch; A first construction module is configured to construct a regional access view for each application system based on the transaction data, wherein the regional access view is configured to display the access status of each application system in different branches; A second building module is used to build a branch transaction total monitoring view based on the regional access view of each application system, and the branch transaction total monitoring view is used to display the transaction relationship between each branch and each application system; The monitoring module is used to monitor the risk of each branch transaction based on the transaction data and pre-configured branch transaction risk warning rules, and display warning information on the branch transaction overall monitoring view based on the risk monitoring results.

8. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the method according to any one of claims 1 to 6 is implemented.

9. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method according to any one of claims 1 to 6 is implemented.

10. A computer program product, characterized in that The method comprises at least one instruction or at least one program, wherein the at least one instruction or the at least one program is loaded and executed by a processor to implement the method according to any one of claims 1 to 6.

Images