Payment service system monitoring method, device and equipment and computer storage medium

Abstract

The present application discloses a payment business system monitoring method, apparatus and equipment, and computer storage medium, relating to the field of monitoring technology. The method comprises: obtaining monitoring data of a payment business system within a set monitoring period, the monitoring data comprising monitoring data corresponding to multiple business attribute dimensions of the payment business system, wherein one attribute dimension corresponds to a monitoring indicator of the payment business system; performing anomaly analysis based on the monitoring data corresponding to each business attribute dimension to obtain an anomaly degree of the payment business system in each business attribute dimension; obtaining an anomaly degree of the payment business system and an anomaly type of the payment business system based on the anomaly degree of the payment business system in each business attribute dimension; determining an anomaly level of the payment business system based on the anomaly level of the payment business system; and performing business control of the payment business system based on the anomaly level and the anomaly type.

Description

Technical Field

[0001] The present application relates to the field of computer technology, in particular to the field of monitoring technology, and provides a payment service system monitoring method, device and equipment, and a computer storage medium. Background Art

[0002] With the development of network technology, electronic payment methods such as mobile payments are gradually replacing traditional payment methods with their greater convenience and speed. Payment service providers need to monitor and evaluate their payment systems in order to optimize their services. This allows them to promptly resolve any issues that arise, avoiding inconvenience and potential risks for users.

[0003] Therefore, for payment services, it is necessary to monitor the payment service system. Summary of the Invention

[0004] Embodiments of the present application provide a payment service system monitoring method, apparatus and device, and computer storage medium.

[0005] In one aspect, a payment service system monitoring method is provided, the method comprising:

[0006] Acquiring monitoring data of the payment service system within a set monitoring period, the monitoring data including monitoring data corresponding to multiple business attribute dimensions of the payment service system, where each attribute dimension corresponds to a monitoring indicator of the payment service system;

[0007] Performing anomaly analysis based on the monitoring data corresponding to each business attribute dimension to obtain the degree of anomaly of the payment business system in each business attribute dimension;

[0008] Obtaining the abnormality degree of the payment service system and the abnormality type of the payment service system according to the abnormality degree of the payment service system in each service attribute dimension;

[0009] determining an abnormality level of the payment service system according to the abnormality degree of the payment service system;

[0010] The payment service system is controlled according to the abnormality level and the abnormality type.

[0011] In one aspect, a payment service system monitoring device is provided, the device comprising:

[0012] a data acquisition unit, configured to acquire monitoring data of the payment service system within a set monitoring period, wherein the monitoring data includes monitoring data corresponding to multiple business attribute dimensions of the payment service system, where each attribute dimension corresponds to a monitoring indicator of the payment service system;

[0013] an abnormality analysis unit, configured to perform abnormality analysis based on the monitoring data corresponding to each business attribute dimension, to obtain the abnormality degree of the payment business system in each business attribute dimension; to obtain the abnormality degree of the payment business system and the abnormality type of the payment business system based on the abnormality degree of the payment business system in each business attribute dimension; and to determine the abnormality level of the payment business system based on the abnormality degree of the payment business system;

[0014] A service control unit is used to perform service control of the payment service system according to the abnormality level and the abnormality type.

[0015] Optionally, the service control unit is specifically configured to:

[0016] A monitoring report is generated according to the abnormality level and the abnormality type, and the monitoring report is sent to a management user associated with the payment service system, so that the management user can perform service control on the payment service system according to the monitoring report.

[0017] Optionally, the service control unit is specifically configured to:

[0018] When the abnormality level of the payment business system is higher than the set abnormality level threshold, an early warning message is sent to the management user associated with the payment business system. The early warning message carries the abnormality type indication information of the payment business system, so that the management user can adjust and control the payment business system according to the abnormality type of the payment business system.

[0019] Optionally, the abnormality analysis unit is specifically used to:

[0020] Obtaining an abnormality indicator value of any business attribute dimension according to the monitoring data corresponding to the any business attribute dimension;

[0021] The abnormality degree of the payment service system in any business attribute dimension is determined according to the abnormality index value of any business attribute dimension and the abnormality index interval threshold set for any business attribute dimension.

[0022] Optionally, the business attribute dimension includes one or more of the following dimensions:

[0023] Stability dimension, including the stability of user attribute distribution and transaction attribute distribution in the payment service system;

[0024] Account suspiciousness dimension;

[0025] Transaction suspiciousness dimension;

[0026] Unconventional business usage data dimension;

[0027] User complaint data dimension;

[0028] Limit the data dimensions of the transaction area;

[0029] Optionally, when any of the business attribute dimensions is a stability dimension, the monitoring data corresponding to any of the business attribute dimensions is user attribute data and / or transaction attribute data;

[0030] The abnormality analysis unit is specifically used to:

[0031] Obtaining attribute value distribution corresponding to each attribute within a monitoring period based on user attribute data and / or transaction attribute data;

[0032] Determine the stability of each attribute based on the attribute value distribution of each attribute during the monitoring period and the historical attribute value distribution of each attribute;

[0033] According to the stability of each attribute, the abnormality index value of the payment service system in the stability dimension is determined.

[0034] Optionally, when any one of the business attribute dimensions is an account suspicion dimension, the monitoring data corresponding to any one of the business attribute dimensions is account data of at least one account whose business volume is greater than a preset business volume threshold;

[0035] The abnormality analysis unit is specifically used to:

[0036] determining a degree of suspicion of each account based on the account data of each account in the at least one account;

[0037] determining a suspicious account among the at least one account based on the suspiciousness of each account;

[0038] The abnormality index value of the payment service system in the dimension of the account suspicion is determined according to the determined number of suspicious accounts.

[0039] Optionally, the abnormality analysis unit is further configured to:

[0040] For each suspicious account, determining a matching degree between each suspicious account and each suspicious type based on a matching degree between each suspicious account and suspicious accounts marked with a suspicious type;

[0041] Determining the suspicious type to which each suspicious account belongs based on the matching degree between each suspicious account and each suspicious type;

[0042] Generate a monitoring report based on the suspicious type of each suspicious account.

[0043] Optionally, when any of the business attribute dimensions is a transaction suspicion dimension, the monitoring data corresponding to any of the business attribute dimensions is transaction data;

[0044] The abnormality analysis unit is specifically used to:

[0045] An abnormality indicator value on a transaction suspicion dimension is determined based on transaction values ​​of suspicious transactions within the monitoring period in the transaction data.

[0046] Optionally, when any of the business attribute dimensions is an unconventional business usage dimension, the monitoring data corresponding to any of the business attribute dimensions is transaction data;

[0047] The abnormality analysis unit is specifically used to:

[0048] According to the number of target objects of non-routine business use in the transaction data during the monitoring period, an abnormal index value in the non-routine business use dimension is determined, wherein the target objects include users and transaction scenarios using payment services.

[0049] Optionally, when any one of the business attribute dimensions is a user complaint dimension, the monitoring data corresponding to any one of the business attribute dimensions is user complaint data regarding the payment service system;

[0050] The abnormality analysis unit is specifically used to:

[0051] Determine the number of complaint records of users within the monitoring period based on the complaint data, and determine the abnormal indicator value in the user complaint dimension based on the number of complaint records.

[0052] Optionally, the abnormality analysis unit is further configured to:

[0053] Extracting complaint text from the complaint data;

[0054] After segmenting the complaint text, extracting at least one keyword from the segmented terms;

[0055] Clustering is performed based on the at least one keyword to obtain at least one category and keywords included in each category;

[0056] Determining complaint events within the monitoring period based on the keywords included in each category;

[0057] Generate a complaint analysis report based on the complaint event.

[0058] In one aspect, a computer device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of any one of the above methods when executing the computer program.

[0059] In one aspect, a computer storage medium is provided, on which computer program instructions are stored, and when the computer program instructions are executed by a processor, the steps of any of the above methods are implemented.

[0060] In one aspect, a computer program product or computer program is provided, the computer program product or computer program comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the steps of any of the above methods.

[0061] In an embodiment of the present application, by obtaining monitoring data of the payment business system within a set monitoring period, the monitoring data includes monitoring data corresponding to multiple attribute dimensions of the payment business system, and one attribute dimension corresponds to a monitoring indicator of the payment business system. Then, the abnormality of the payment business system in each attribute dimension can be obtained respectively according to the monitoring data corresponding to each attribute dimension to obtain the abnormality of the payment business system and the abnormality type of the payment business system. According to the abnormality, the abnormality level of the payment business system can be determined, and then the business control of the payment business system can be performed according to the abnormality level and abnormality type. Therefore, by analyzing the data within the monitoring period of the payment business system, the abnormality level and abnormality type of the payment business system within the monitoring period can be known, which makes it easier for back-end personnel to perceive the current business health of the payment business system in a timely manner, and intervene in time to investigate and correct the problem when an abnormality occurs, so as to avoid serious impact on the business and reduce the probability of a poor user experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0062] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the following briefly introduces the drawings required for use in the embodiments or related technical descriptions. Obviously, the drawings described below are only embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.

[0063] Figure 1 Schematic diagram of application scenarios provided by embodiments of the present application;

[0064] Figure 2 A flow chart of a payment service system monitoring method provided in an embodiment of the present application;

[0065] Figure 3 A schematic diagram of business attribute dimensions provided in an embodiment of the present application;

[0066] Figure 4A schematic diagram of abnormal analysis of the stability dimension provided in an embodiment of the present application;

[0067] Figure 5 A schematic diagram of anomaly analysis based on the account suspicion dimension provided in an embodiment of the present application;

[0068] Figure 6 A schematic diagram of the process of abnormal analysis of transaction suspicion provided in an embodiment of the present application;

[0069] Figure 7 A schematic diagram of the clustering process provided in the embodiment of the present application;

[0070] Figures 8a to 8d A schematic diagram of the clustering process using the K-Means algorithm provided in an embodiment of the present application;

[0071] Figure 9 A schematic diagram of the process of abnormal analysis of restricted transaction area data dimensions provided in an embodiment of the present application;

[0072] Figure 10 A schematic diagram of the structure of a payment service system monitoring device provided in an embodiment of the present application;

[0073] Figure 11 A schematic diagram of the structure of a computer device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0074] In order to make the purpose, technical solutions and advantages of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application. In the absence of conflict, the embodiments in the present application and the features in the embodiments can be combined with each other in any way. In addition, although a logical order is shown in the flow chart, in some cases, the steps shown or described can be performed in an order different from that here.

[0075] To facilitate understanding of the technical solutions provided in the embodiments of the present application, some key terms used in the embodiments of the present application are explained here:

[0076] Payment business: refers to the business involving the transfer of resources between two parties to a transaction. For example, it may include common electronic payment services, such as QR code payment services, facial payment services, payment services or transfer services, etc. In addition, when financial products are bought and sold, there are actually two parties to the transaction, that is, a transaction of a financial product involves a seller and a buyer. Therefore, payment business can also include financial products of financial platforms.

[0077] Payment business system: The system that provides business support for payment business is the payment business system.

[0078] Monitoring cycle: The monitoring cycle can be set according to actual needs. For example, when the real-time monitoring of the payment business system is relatively high, the monitoring cycle can be set shorter, such as 10 minutes, 1 hour, or half a day, etc. Of course, if the real-time monitoring of the payment business system is not relatively high, the monitoring cycle can be set longer, so that the data volume basis is better and the analysis results can be more accurate. For example, it can be set to 1 day.

[0079] Business attribute dimension: This dimension is set up to monitor the payment business system. It monitors the health of the payment business system from various dimensions and summarizes the health of multiple attribute dimensions to obtain the overall health of the payment business system. This allows backend personnel to analyze the status of the payment business system and control the payment business system.

[0080] Stability dimension: Stability can include the stability of the user group and the stability of transaction attributes in the payment business system. Generally speaking, in each monitoring time period, the distribution of the entire user group of the payment business system tends to be stable. When the distribution of the user group is abnormal, it may indirectly reflect that there may be abnormalities in the payment business. Similarly, normally, transaction attributes such as the distribution of transaction time periods or transaction area distributions also tend to be stable. When the distribution of transaction time periods or transaction area distributions is abnormal, it may also indirectly reflect that there may be abnormalities in the payment business system.

[0081] Account Suspicion: In payment systems, accounts suspected of having conducted illegal transactions are considered suspicious accounts. The higher the account's suspicion, the higher the risk. The greater the number of suspicious accounts in a payment system, the higher the risk, and the lower the trustworthiness of legitimate users, which can reduce their loyalty to the payment system. Therefore, suspicious accounts in the payment system need to be monitored and subject to certain service restrictions to mitigate payment risks for legitimate accounts within the system.

[0082] Transaction Suspicion: For each transaction, we analyze the relevant data for suspicion. If the suspicion exceeds a certain threshold, we determine that the transaction is suspicious. Similarly, for a payment system, the greater the number of suspicious transactions, the higher the risk level. Therefore, it is necessary to impose certain restrictions on the use of the payment system by both parties involved in the suspicious transaction.

[0083] Unconventional Business Use: A payment service typically has a product usage policy, such as permitted users and permitted transaction scenarios. Unconventional business use refers to use of the payment service outside of the permitted scope. For example, if permitted users are set, use of the payment service by users outside of those permitted can be considered unconventional use.

[0084] For payment service providers, in order to optimize payment services, they need to monitor and evaluate payment services in the background so that any problems can be resolved promptly to avoid inconvenience and potential risks to users. Therefore, monitoring payment services is very necessary.

[0085] However, current payment monitoring methods focus solely on transaction data, such as total transaction amounts or online interception amounts. Alerts are triggered when these amounts exceed thresholds. This approach, which only considers the single characteristics of payment services, provides incomplete monitoring of payment systems, fails to truly reflect the health of payment systems, and provides limited reference for back-end analysts conducting business control.

[0086] In view of this, an embodiment of the present application provides a payment business system monitoring method, in which monitoring data of the payment business system within a set monitoring period is obtained, and the monitoring data includes monitoring data corresponding to multiple attribute dimensions of the payment business system, and one attribute dimension corresponds to a monitoring indicator of the payment business system. Then, the abnormality of the payment business system in each attribute dimension can be obtained respectively according to the monitoring data corresponding to each attribute dimension, so as to obtain the abnormality of the payment business system and the abnormality type of the payment business system. According to the abnormality, the abnormality level of the payment business system can be determined, and then the business control of the payment business system can be performed according to the abnormality level and abnormality type. Therefore, by analyzing the data within the monitoring period of the payment business system, the abnormality level and abnormality type of the payment business system within the monitoring period can be known, so as to facilitate the back-end personnel to timely perceive the current business health of the payment business system, and intervene in time to investigate and correct the problem when an abnormality occurs, so as to avoid serious impact on the business and reduce the probability of bringing a poor user experience.

[0087] After introducing the design concepts of the embodiments of the present application, the following briefly introduces the application scenarios to which the technical solutions of the embodiments of the present application can be applied. It should be noted that the application scenarios introduced below are only used to illustrate the embodiments of the present application and are not limiting. In the specific implementation process, the technical solutions provided by the embodiments of the present application can be flexibly applied according to actual needs.

[0088] The solution provided in the embodiment of the present application can be applied to most scenarios where payment service system monitoring is required. Of course, it is also applicable to other business scenarios besides payment services, such as Figure 1 As shown, it is a schematic diagram of a scenario provided by an embodiment of the present application, wherein the application scenario includes a system monitoring device 101, a database 102 and a management terminal 103.

[0089] The database 102 may be a database corresponding to the payment service system, and is used to store all data generated during the operation of the payment service system. The database may be any type of database, and the embodiment of the present application does not limit the type of the database.

[0090] The system monitoring device 101 may be a computer device with certain processing capabilities, such as a personal computer (PC), a laptop, or a server. The server may be an independent physical server, or a server cluster or distributed system composed of multiple physical servers. It may also be a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms, but is not limited thereto.

[0091] In a possible implementation, the system monitoring device 101 may be a backend server of a payment service system.

[0092] The management terminal 103 may be a terminal device used by a management user of the payment service system, which may be a PC, a mobile phone, a laptop computer, a wearable device, or the like.

[0093] During the specific implementation process, the data generated by the payment business system during operation can be stored in the database 102. The system monitoring device 101 can obtain the monitoring data within the monitoring period from the database 102 within a monitoring period, and obtain the monitoring results of the payment business system through the payment business system monitoring method provided in the embodiment of the present application, that is, obtain the abnormality degree and abnormality type of the payment business system, and generate a monitoring report of the payment business system based on the monitoring results and send it to the management terminal 103. The management user can then determine whether to adjust and control the business of the payment business system based on the monitoring report. For example, when the monitoring report shows that there is an abnormality in the payment business, the abnormality can be checked and the business adjustment can be made based on the monitoring report.

[0094] The system monitoring device 101 may include one or more processors 1011, a memory 1012, and an I / O interface 1013 for interacting with other devices. Furthermore, the system monitoring device 101 may be configured with a database 1014, which may be used to store data such as monitoring data and monitoring reports involved in the solution provided in the embodiments of the present application. The memory 1012 of the system monitoring device 101 may store program instructions for the payment service system monitoring method provided in the embodiments of the present application. When these program instructions are executed by the processor 1011, they may be used to implement the steps of the payment service system monitoring method provided in the embodiments of the present application to monitor the payment service system.

[0095] The system monitoring device 101, the database 102, and the management terminal 103 can be directly or indirectly connected to each other via one or more networks 104. The network 104 can be a wired network or a wireless network, for example, a mobile cellular network or a Wireless Fidelity (WIFI) network. Of course, other possible networks are also possible, and the embodiment of the present invention does not limit this.

[0096] Of course, the method provided in the embodiment of the present application is not limited to Figure 1 The application scenarios shown can also be used in other possible application scenarios, and the embodiments of this application are not limited thereto. Figure 1 The functions that can be realized by each device in the application scenario shown will be described in the subsequent method embodiments, and will not be described in detail here. Below, a brief introduction will be given to the technology involved in the embodiments of the present application.

[0097] Artificial Intelligence (AI) refers to the theories, methods, techniques, and application systems that use digital computers or machines controlled by digital computers to simulate, extend, and expand human intelligence, to perceive the environment, acquire knowledge, and use that knowledge to achieve optimal results. In other words, AI is a comprehensive technology within computer science that seeks to understand the essence of intelligence and produce new intelligent machines that can respond in a manner similar to human intelligence. AI also studies the design principles and implementation methods of various intelligent machines, enabling them to possess the capabilities of perception, reasoning, and decision-making.

[0098] Artificial intelligence (AI) technology is a comprehensive discipline encompassing a wide range of fields, encompassing both hardware and software technologies. Foundational AI technologies generally include sensors, specialized AI chips, cloud computing, distributed storage, big data processing, operating / interaction systems, and mechatronics. AI software technologies primarily encompass computer vision, speech processing, natural language processing, and machine learning / deep learning.

[0099] Natural language processing (NLP) is a key area of ​​research in computer science and artificial intelligence. It studies the theories and methods that enable effective communication between humans and computers using natural language. Natural language processing (NLP) integrates linguistics, computer science, and mathematics. Therefore, research in this field involves natural language—the language we use in everyday life—and is closely linked to the study of linguistics. Natural language processing technologies typically include text processing, semantic understanding, machine translation, robotic question answering, and knowledge graphs.

[0100] Machine learning (ML) is a multidisciplinary field that encompasses probability theory, statistics, approximation theory, convex analysis, and algorithmic complexity theory. It specifically studies how computers can simulate or implement human learning behaviors to acquire new knowledge or skills and reorganize existing knowledge structures to continuously improve their performance. Machine learning is at the core of artificial intelligence and the fundamental way to make computers intelligent. Its applications span all areas of AI. Machine learning and deep learning typically include techniques such as artificial neural networks, belief networks, reinforcement learning, transfer learning, inductive learning, and self-learning.

[0101] With the research and advancement of artificial intelligence technology, artificial intelligence technology has been studied and applied in many fields. The solution provided in the embodiment of this application involves intelligent monitoring technology, as well as the process of analyzing complaint texts through NLP technology and classifying keywords extracted from the text through clustering algorithms or machine learning algorithms, which is specifically illustrated by the following embodiments.

[0102] See Figure 2 , is a flow chart of a payment service system monitoring method provided by an embodiment of the present application, which can be performed by Figure 1 The method is executed by the system monitoring device 101 in the system monitoring device 101, and the process of the method is described as follows.

[0103] Step 201: Acquire monitoring data of the payment service system within a set monitoring period.

[0104] In the embodiments of the present application, the monitoring of the payment service system can be performed in real time, so that the monitoring data of the payment service system can be obtained in real time for subsequent abnormality analysis. Alternatively, all monitoring data within a monitoring period can be obtained after the end of the monitoring period to perform abnormality analysis for the monitoring period. Of course, in the specific implementation, the configuration can be based on specific monitoring requirements, and the embodiments of the present application do not impose any restrictions on this.

[0105] In order to more comprehensively evaluate the health of the payment business system, monitoring data of the payment business system in multiple business attribute dimensions can be obtained, and then the payment business system can be evaluated based on the monitoring data in multiple business attribute dimensions.

[0106] Among them, multiple business attribute dimensions can be multiple dimensions where abnormalities may occur in the payment business system. Figure 3 As shown, the multiple business attribute dimensions may include one or more of the following dimensions:

[0107] (1) Stability

[0108] (2) Account Suspiciousness

[0109] (3) Transaction Suspicion

[0110] (4) Non-routine business usage data

[0111] (5) User complaint data

[0112] (6) Restricted trading area data

[0113] The abnormality of the payment business system is measured from both internal and external perspectives. For example, dimensions such as stability, account suspicion, transaction suspicion, irregular business usage data, and user complaint data are business attribute dimensions from an internal perspective, while restricted transaction area data is a business attribute dimension from an external perspective.

[0114] Of course, in specific use, other possible dimensions can also be set according to the specific business usage scenario, and the embodiments of the present application do not limit this.

[0115] Step 202: Perform anomaly analysis based on the monitoring data corresponding to each business attribute dimension to obtain the degree of anomaly of the payment business system in each business attribute dimension.

[0116] In the embodiment of the present application, a specific anomaly analysis is performed on each business attribute dimension to obtain the degree of anomaly in each business attribute dimension.

[0117] Specifically, in actual use, an abnormality analysis strategy for each business attribute dimension may be pre-set, such as an abnormality discrimination threshold, etc. The setting basis may be obtained by analyzing historical abnormalities or may be set based on experience.

[0118] Taking setting the discrimination threshold as an example, after obtaining the monitoring data, the monitoring data corresponding to any business attribute dimension can be filtered out from the obtained monitoring data, and the abnormal index value of the business attribute dimension can be obtained based on the filtered monitoring data. Then, based on the abnormal index value of any business attribute dimension and the abnormal index interval threshold set for any business attribute dimension, the abnormality degree of the payment business system in any business attribute dimension can be determined.

[0119] For example, for the stability dimension, a stability anomaly threshold can be set. When the abnormal index value obtained based on the monitoring data exceeds the abnormal threshold, it is determined that there is an abnormality in the stability dimension. In actual implementation, the corresponding abnormality degree can be set according to the degree of deviation between the abnormal index value and the abnormal threshold, and the abnormality degree in the stability dimension can be obtained. The abnormality degree can indicate the degree of abnormality of the payment business system in the stability dimension.

[0120] The process of determining the abnormality of each dimension will be introduced in detail in the subsequent introduction, so we will not introduce it in detail here.

[0121] Step 203: Obtain the abnormality degree of the payment service system and the abnormality type of the payment service system according to the abnormality degree of the payment service system in each service attribute dimension.

[0122] After performing an anomaly analysis on each business attribute dimension, the anomaly degree on each business attribute dimension can be obtained, and then the anomaly degree of the payment business system can be obtained based on the anomaly degree on each business attribute dimension.

[0123] For example, when an anomaly exists in a business attribute dimension, the anomaly score for that business attribute dimension can be 1. If there is no anomaly or it is approximately believed that there is no anomaly in each business attribute dimension, the anomaly score for that business attribute dimension can be 0. The anomaly scores for each business attribute dimension can then be added together to obtain the total anomaly score for the payment service system. Since different business attribute dimensions may have different levels of importance, or the impact of anomalies in each business attribute dimension on the payment service system may differ, weights can be set for each business attribute dimension. When calculating the total anomaly score, the weights of each business attribute dimension can be used to calculate the score, thereby improving the accuracy of the anomaly score for the payment service system.

[0124] Specifically, for business attribute dimensions with abnormalities, further analysis can be performed to obtain the abnormality types of each business attribute dimension, so that the abnormality type data can be included in the monitoring report to facilitate backend management users to locate the abnormalities.

[0125] Step 204: Determine the abnormality level of the payment service system according to the abnormality degree of the payment service system.

[0126] Specifically, corresponding abnormality levels can be set for different abnormality degrees, and one abnormality level can correspond to an abnormality degree interval. In this way, after the abnormality degree of the payment business system is obtained based on the above process, the abnormality level of the payment business system within the currently calculated monitoring period can be determined based on the correspondence between the abnormality degree and the abnormality level.

[0127] For example, if there is an anomaly in a business attribute dimension, the anomaly score of the business attribute dimension can be 1. If there is no anomaly or it is approximately considered that there is no anomaly in each business attribute dimension, the anomaly score of the business attribute dimension can be 0. The corresponding relationship between the anomaly degree and the anomaly level can be shown in Table 1.

[0128] Abnormality range Abnormal Level Risk Level [0，1] Low Low risk [2，3] middle Medium risk [4，6] Higher Higher risk [7，+∞] high High risk

[0129] Table 1

[0130] Among them, the risk level can measure the risk to users and the risk to payment service providers.

[0131] When the abnormality score is in [0, 1], the corresponding abnormality level is low, and the corresponding risk level of the payment business system is low risk; when the abnormality score is in [2, 3], the corresponding abnormality level is medium, and the corresponding risk level of the payment business system is medium risk; when the abnormality score is in [4, 6], the corresponding abnormality level is high, and the corresponding risk level of the payment business system is high risk; when the abnormality score is in [7, +∞], the corresponding abnormality level is high, and the corresponding risk level of the payment business system is high risk.

[0132] Step 205: Perform business control of the payment business system according to the abnormality level and abnormality type.

[0133] In the embodiment of the present application, after the abnormality level and abnormality type of the payment service system are determined, service control of the payment service system can be performed according to the abnormality level and abnormality type.

[0134] Specifically, the business control measures corresponding to each abnormality level and abnormality type can be pre-set based on the abnormality level, abnormality type, and corresponding business control measures obtained through historical data analysis. After the abnormality analysis is completed, the corresponding business measures can be determined and implemented based on the abnormality level and abnormality type obtained through the analysis. For example, if the abnormality level is high risk and the abnormality type includes too many suspicious accounts within the monitoring period, transactions involving suspicious accounts can be restricted, or the transaction limit in the current payment service system can be dynamically adjusted. Alternatively, if the abnormality type is too many user complaints against a particular merchant, transactions with that merchant can be restricted.

[0135] Specifically, monitoring reports can be generated based on anomaly levels and types, and sent to administrative users associated with the payment system, enabling them to control the payment system based on the reports. For situations where automatic adjustments and controls aren't possible, backend administrators can analyze and locate anomalies based on the monitoring reports, allowing them to adjust and control the payment system accordingly.

[0136] Alternatively, in order to deal with some high-risk situations, when the abnormality level of the payment business system is higher than the set abnormality level threshold, an early warning message can be sent to the management user associated with the payment business system. The early warning message carries the abnormality type indication information of the payment business system, so that the management user can adjust and control the payment business system in time according to the abnormality type of the payment business system.

[0137] The following describes the anomaly analysis process for specific business attribute dimensions.

[0138] (1) Abnormal analysis of stability dimension

[0139] Among them, the data involved in the stability dimension are mainly user attribute data and transaction attribute data in the payment business system. They are subdivided according to different user attributes or transaction attributes, and the attribute value distribution of each attribute within the monitoring period is calculated separately. Based on the attribute value distribution of each attribute within the monitoring period and the historical attribute value distribution of each attribute, the stability of each attribute is determined. Then, based on the stability of each attribute, the abnormal indicator value of the payment business system in the stability dimension is determined.

[0140] For example, Figure 4 The figure shows a schematic diagram of abnormal analysis in the stability dimension.

[0141] Among them, according to the segmentation of user attributes and transaction attributes, multiple attributes are obtained, such as Figure 4 Classification based on user attributes may include the proportion of real-name / non-real-name users, the proportion of each type of ID, the proportion of operators bound to mobile phone numbers, the proportion of new and old users, and the proportion of user data in each age group. Classification based on transaction attributes may include the proportion of day and night transactions, the proportion of each transaction time period, the proportion of domestic and foreign transactions, the proportion of users stratified by transaction amount, and the proportion of users in each payment scenario.

[0142] The Population Stability Index (PSI) measures the deviation between expected and actual values. It primarily observes whether the proportion of people in different groups varies significantly across different samples, effectively measuring the degree of change in the distribution of each attribute. The PSI value for each of the aforementioned attributes can be calculated. A large PSI value indicates significant variation in the distribution of that attribute, potentially indicating an anomaly. However, changes in a single attribute may not reflect the stability of the entire system. Therefore, a comprehensive PSI analysis of each attribute can be used to determine stability. This can be achieved by setting a threshold. If a large number of attributes have PSI values ​​greater than the threshold, indicating an anomaly in the payment system, the stability dimension of the payment system can be considered abnormal, and the anomaly score for the stability dimension can be set to 1. If a small number of attributes have PSI values ​​greater than the threshold, the stability dimension of the payment system can be considered normal, and the anomaly score for the stability dimension can be set to 0.

[0143] Generally, a PSI less than 0.1 indicates high stability, while a PSI greater than 0.25 indicates system instability and requires attention and updates. For example, you can set the indicator threshold to 0.25 and the quantity threshold to 2. If two or more attributes have a PSI value greater than or equal to 0.25, then a score of 1 is awarded, otherwise a score of 0 is awarded.

[0144] Of course, in addition to the above method, you can also set the corresponding abnormality value according to the quantity. For example, when the number of attributes greater than the set threshold accounts for 10%, the abnormality of the stability dimension is 10%; when the number of attributes greater than the set threshold accounts for 80%, the abnormality of the stability dimension is 80%, and so on.

[0145] Specifically, the specific calculation formula of PSI is as follows:

[0146]

[0147] in, represents the actual value of attribute i obtained based on the attribute data within the monitoring period, It represents the expected value of attribute i, which can be set based on historical data or experience.

[0148] Taking the attribute of the proportion of user data in each age group as an example, the user age data of No. 1 is selected here, and the distribution of the number of accounts in different age ranges is counted as the expected value. The user age data of No. 15 is selected as the actual value, as shown in Table 2.

[0149]

[0150] Table 2

[0151] Among them, based on the actual number of users in each age range, the proportion of the actual number of users in this age range to the total number of users can be calculated, and based on the expected number of users in each age range, the proportion of the expected number of users in this age range to the total number of users can be calculated. Then, based on the proportion of actual users and the proportion of expected users, the PSI of each age range can be calculated. The combination of the PSI of each age range is the PSI of the proportion of user data in each age group.

[0152] Based on Table 2, we can see that the PSI value of the proportion of user data in each age group is 0.23, which is lower than the set indicator threshold of 0.25, which means that the age of users using this payment service is stable.

[0153] (2) Abnormal analysis of account suspiciousness

[0154] In the embodiment of the present application, the suspiciousness of an account can also be referred to as the maliciousness of the account. When there are too many transactions with suspicious accounts in the payment business system, the health of the system is obviously not high. Therefore, it is necessary to conduct a suspicious analysis of the accounts in the payment business system to find out the suspicious accounts and then determine the abnormality of the payment business system.

[0155] When the business attribute dimension is the account suspicion dimension, the monitoring data corresponding to this business attribute dimension is the account data of at least one account whose business volume exceeds a preset business volume threshold. The business volume can be measured by the amount of receipts, number of transactions, or transfer amount. Furthermore, the suspicion level of each account in the at least one account can be determined based on the account data of each account. The suspicious accounts in the at least one account can then be determined based on the suspicion level of each account. Finally, the abnormality indicator value for the payment service system in the account suspicion dimension can be determined based on the number of determined suspicious accounts.

[0156] In the embodiment of the present application, a blacklist database can be established in advance based on the identified suspicious accounts, and then the blacklist database can be used to determine whether the account is a suspicious account. The blacklist database can be established and updated through the following process.

[0157] A. Suspicious Account Identification Model Analysis

[0158] A trained suspicious account identification model can be used to identify the suspiciousness of accounts and add accounts with a suspicion level exceeding a certain threshold to a blacklist. The suspicious account identification model can be built into sub-models based on different types to accurately identify suspicious accounts. For example, sub-models can be included for gambling, fraud, foreign exchange, and pyramid schemes.

[0159] B. Manual review

[0160] In daily work, accounts will be identified as suspicious accounts through manual review, and these accounts can also be added to the blacklist library.

[0161] C. Online interception data analysis

[0162] In actual use, the payment business system backend will also judge the security of the transaction. When it is determined that the current transaction is unsafe, it will intercept the transaction. When an account's transactions are intercepted multiple times, it is obvious that this account is at risk. Therefore, accounts that have been intercepted more than a certain number of times can be added to the blacklist library.

[0163] D. Controlled accounts

[0164] In actual use, there may be some accounts that have been manually frozen or restricted from entering the account. These accounts can be called controlled accounts, and controlled accounts can also be added to the blacklist.

[0165] In the embodiment of the present application, in a monitoring cycle, the number of accounts involved in transactions is large. In order to reduce the workload of abnormal analysis, accounts with greater risk impact on the payment service system can be selected for suspicious analysis. Figure 5As shown, it is a schematic diagram of abnormal analysis of the account suspicion dimension, wherein multiple accounts ranked high in terms of the amount of receipts can be selected, for example, 200 accounts, and the account data of these 200 accounts can be obtained from the monitoring data. The account data of each account is matched with the account in the blacklist library. The degree of matching between each account and the blacklist account can be used as the suspicion of the account, and then it can be determined whether each account is a suspicious account based on the suspicion, and the proportion of suspicious accounts can be counted, and then the abnormality of the account suspicion dimension can be determined based on whether the proportion of suspicious accounts is high.

[0166] For example, the degree of abnormality can be determined based on whether the number of suspicious accounts exceeds a threshold. The threshold can be set to 50%, for example. When the proportion of suspicious accounts is greater than 50%, the payment business system is considered abnormal, and the abnormality score in the account suspicion dimension is 1 point, otherwise it is 0 point.

[0167] Of course, you can also set the corresponding abnormality value according to the proportion of suspicious accounts. For example, when the suspicious account ratio is 10%, the abnormality of the account suspiciousness dimension is 10%; when the suspicious account ratio is 80%, the abnormality of the account suspiciousness dimension is 80%, etc.

[0168] In an embodiment of the present application, suspicious accounts in the blacklist library can also be marked with suspicious types, and then for each suspicious account determined within the monitoring period, the matching degree between the suspicious account and the suspicious accounts marked with suspicious types can be determined, so that the suspicious type to which the suspicious account belongs can be determined, and then a monitoring report can be generated based on the suspicious type to which each suspicious account belongs, that is, the suspicious type of each suspicious account can be given in the monitoring report, and the proportion of various suspicious types can also be counted to give the overall risk details, which is convenient for the back-end management user to subsequently deal with the model in a targeted manner.

[0169] (3) Abnormal analysis of transaction suspicion

[0170] When the business attribute dimension is a transaction suspicion dimension, the monitoring data corresponding to the business attribute dimension may be transaction data. Specifically, the abnormal indicator value on the transaction suspicion dimension may be determined based on the transaction value in the transaction data whose suspicion is greater than a preset suspicion threshold during the monitoring period.

[0171] like Figure 6 The figure below is a flow chart of anomaly analysis based on the transaction suspicion dimension. A pre-set threshold for suspicious transactions can be used to determine whether the total intercepted amount during the monitoring period is greater than or equal to the threshold. If the total intercepted amount is less than the threshold, the anomaly score for the transaction suspicion dimension is 0; if the total intercepted amount is greater than or equal to the threshold, the anomaly score for the transaction suspicion dimension is 1.

[0172] Similarly, transaction values ​​can also be divided into numerical ranges. Different numerical ranges correspond to respective abnormalities. Then, based on the numerical range in which the total intercepted amount during the monitoring period lies, the abnormality degree in the transaction suspicion dimension can be determined as the abnormal indicator value in the transaction suspicion dimension.

[0173] (4) Abnormal analysis of data dimensions used in non-routine business

[0174] When the business attribute dimension is an unconventional business usage dimension, the monitoring data corresponding to the business attribute dimension may be transaction data, and the transaction data specifically includes data related to product strategies such as transaction accounts and transaction locations.

[0175] Specifically, the abnormal indicator value in the dimension of unconventional business use can be determined based on the number of target objects of unconventional business use in transaction data during the monitoring period. The target objects include users who use payment services and transaction scenarios.

[0176] In the embodiment of the present application, for a payment service, it is usually necessary to limit the users and transaction scenarios that are allowed to use it. Anything beyond the allowed scope of use is considered regular business use. Therefore, it can be measured from two aspects: the allowed users and the limited transaction scenarios. Finally, the abnormality scores of these two aspects are summarized as the abnormality of the unconventional business use data dimension.

[0177] A. Allow users to use

[0178] When conducting payment transactions, payment services will judge the identity of users and determine which users can use the service and which cannot. For example, only Chinese users are allowed to use the service, while foreign users are not allowed to use the service. If, during the monitoring period, the transaction data shows that there are users who use the product in violation of regulations, the abnormality score of the irregular business usage data dimension will be increased by 1 point, otherwise it will not be increased.

[0179] B. Limited transaction scenarios

[0180] Limited transaction scenarios, such as those that must be reported to regulators

[0181] Before certain financial products go online, the product's usage scenarios and transaction locations will be reported to the regulator. For example, they are only allowed to be used domestically and no overseas transactions are allowed, otherwise there will be compliance risks. Therefore, the limited transaction scenarios can be, for example, transaction scenarios reported to the regulator. Then, if unreported transaction scenarios are found in the transaction data during the monitoring period, the anomaly score of the unconventional business usage data dimension will be increased by 1 point, otherwise it will not be increased.

[0182] Similarly, the numerical intervals can be divided according to the number of target objects, and different numerical intervals correspond to their own abnormality levels. Then, based on the numerical intervals in which the number of target objects within the monitoring period is located, the abnormality level in the dimension of unconventional business usage data can be determined as the abnormality indicator value in the dimension of unconventional business usage data.

[0183] (5) Abnormal analysis of user complaint data dimensions

[0184] If the business attribute dimension is a user complaint dimension, the monitoring data corresponding to this business attribute dimension can be user complaint data regarding the payment service system. Based on this complaint data, the number of user complaint records within the monitoring period can be determined, and the abnormality indicator value for the user complaint dimension can be determined based on the number of complaint records.

[0185] A complaint record threshold can be pre-set to determine whether the number of complaint records within a monitoring period is greater than or equal to the complaint record threshold. If it is less than the complaint record threshold, the abnormality score for the transaction suspicion dimension is 0. If it is greater than or equal to the complaint record threshold, the abnormality score for the user complaint dimension is 1. For example, when a gang fraud case occurs, many users may be involved, and the corresponding number of complaints will also explode. Therefore, complaint records can be monitored. If the number of complaint records within the monitoring period exceeds the set maximum threshold, the abnormality score is 1, otherwise it is 0.

[0186] Currently, the complaint record values ​​can also be divided into numerical intervals. Different numerical intervals correspond to their own abnormality levels. Then, based on the numerical intervals in which the complaint records within the monitoring period are located, the abnormality level in the user complaint dimension can be determined as the abnormality indicator value in the user complaint dimension.

[0187] In order to understand the reasons for user complaints, that is, to determine which events the complaints are about, so that subsequent backend management users can make corresponding business adjustments and control, and improve the efficiency of analysts, text analysis can also be performed on the user's complaint text to determine the specific events that the complaints are about.

[0188] Specifically, after obtaining the complaint data from the monitoring data, the complaint text in the complaint data can be extracted, and the complaint text can be segmented and stop words can be removed to obtain multiple terms, and at least one keyword can be extracted from the obtained terms. Among them, the processing process can be performed using a word segmentation tool, such as Jieba word segmentation. Jieba word segmentation is a Python Chinese word segmentation component that can perform word segmentation, part-of-speech tagging, and keyword extraction on Chinese text. Of course, other possible word segmentation tools can also be used, and the embodiments of the present application are not limited to this.

[0189] Then, after the keywords are converted into word vectors, a clustering algorithm is used to cluster the keywords, and then the keywords and word frequencies in each category are output respectively. The clustering algorithm can be, for example, an unsupervised algorithm such as the K-means algorithm. Of course, other possible algorithms can also be used, which can be unsupervised algorithms or supervised algorithms. This embodiment of the application does not limit this.

[0190] Taking the K-Means algorithm as an example, the number of categories K can be set based on experience, and then cluster classification is performed according to this K value. Figure 7 The figure shows a flow chart of classification.

[0191] Step 701: Select k keywords from multiple keywords as the initial cluster centers m i (i=1, 2,…, k).

[0192] Step 702: Calculate the distances between the remaining keywords in the keyword set and the centers of the k clusters, and divide the keywords into the cluster with the smallest distance.

[0193] The distance can be, for example, the Euclidean distance between the vectors of keywords. The smaller the distance, the more similar they are. For example, for two n-dimensional objects, keyword i and keyword j, where i = (x i1 , x i2 ,…,x in ) and j=(x j1 , x j2 ,…,x jn ), the Euclidean distance d(i,j) between keyword i and keyword j is calculated as follows:

[0194]

[0195] Step 703: Determine whether the loop termination condition is met.

[0196] The loop termination condition may be, for example, that the square error criterion function of the current clustering result converges, that is, the cluster center no longer changes. The square error criterion function is defined as follows:

[0197]

[0198] Where p refers to the keyword, m i It is cluster C i The principle of this criterion function is to make the generated clusters as independent as possible and the members within the cluster as similar as possible.

[0199] Step 704: If the result of step 703 is no, calculate a new cluster center based on the keywords included in the divided clusters. For example, the average value of each cluster can be calculated as the new cluster center, and jump to step 702.

[0200] If the result of step 703 is yes, clustering ends.

[0201] like Figures 8a to 8d , is a schematic diagram of the process of using the K-Means algorithm to find three clusters in the data set. Figure 8a is the initial cluster center selected, where the plus sign represents the cluster center, and objects of the same shape belong to the same cluster. For example, a triangle represents one cluster, and a square and a circle represent two other clusters. Figure 8b to Figure 8d These correspond to the clustering results after the 1st to 3rd cycle iterations. It can be seen that through multiple iterations, multiple objects with similar distances are gradually divided into the same class.

[0202] After clustering, the complaint events within the monitoring period and the keyword information of the corresponding time can be determined based on at least one category obtained by clustering, and then a monitoring report can be generated based on the complaint events so that the backend management personnel can handle them in a targeted manner.

[0203] Among them, there may be some complaints about historical events. For example, at least one event is determined to include an event that occurred in the monitoring cycle before the current monitoring cycle. Since these events have been mentioned in the previous monitoring report, adjustments may have been made to the events. Therefore, in order to reduce the analysis workload of the subsequent management user, these historical events and related keyword information can also be filtered out, and newly appeared events and related keyword information can be output. Of course, it should be noted that the historical events here refer to events within a set time period before the current monitoring cycle, such as the last week or the last 3 days, etc. Of course, the length of the time period can be set according to actual conditions.

[0204] (6) Abnormal analysis of data dimensions in restricted transaction areas

[0205] In the embodiment of the present application, the restricted trading areas are some areas with higher risks.

[0206] When the number of transactions or the transaction amount in the restricted transaction area is large, the risk of the payment business system may increase, such as Figure 9 As shown, it is a flowchart of anomaly analysis of the restricted transaction area data dimension. Transaction records in the restricted transaction area can be obtained from the monitoring data, and then the number of transactions or transaction amount in the restricted transaction area can be monitored based on the transaction records. When the number of transactions or transaction amount in the restricted transaction area exceeds the set threshold, the anomaly score is 1 point, otherwise it is 0 point.

[0207] Among them, when the number of transactions or transaction amount in the restricted transaction area exceeds the set threshold, the abnormality score of the restricted transaction area data dimension increases by 1 point.

[0208] Of course, the number of transactions or the transaction amount can also be divided into numerical intervals. Different numerical intervals correspond to respective abnormalities. Then, the abnormality in the restricted transaction area data dimension can be determined according to the numerical interval in which the number of transactions or the transaction amount in the monitoring period is located, and used as the abnormal indicator value in the restricted transaction area data dimension.

[0209] To sum up, the payment business system of the embodiment of the present application can monitor payment business risks in a timely manner, evaluate the health of the payment business system, provide risk assessment results, clarify business risk details, and facilitate analysts to perceive and intervene in a timely manner to avoid serious impact on the business.

[0210] See Figure 10 Based on the same inventive concept, the embodiment of the present application further provides a payment service system monitoring device 100, which includes:

[0211] The data acquisition unit 1001 is configured to acquire monitoring data of the payment service system within a set monitoring period. The monitoring data includes monitoring data corresponding to multiple business attribute dimensions of the payment service system, where each attribute dimension corresponds to a monitoring indicator of the payment service system.

[0212] The abnormality analysis unit 1002 is configured to perform abnormality analysis based on the monitoring data corresponding to each business attribute dimension to obtain the abnormality degree of the payment business system in each business attribute dimension; obtain the abnormality degree and abnormality type of the payment business system based on the abnormality degree of the payment business system in each business attribute dimension; and determine the abnormality level of the payment business system based on the abnormality degree of the payment business system.

[0213] The service control unit 1003 is used to perform service control of the payment service system according to the abnormality level and abnormality type.

[0214] Optionally, the service control unit 1003 is specifically configured to:

[0215] A monitoring report is generated based on the abnormality level and abnormality type, and the monitoring report is sent to the management user associated with the payment service system, so that the management user can control the payment service system based on the monitoring report.

[0216] Optionally, the service control unit 1003 is specifically configured to:

[0217] When the abnormality level of the payment business system is higher than the set abnormality level threshold, an early warning message is sent to the management user associated with the payment business system. The early warning message carries the abnormality type indication information of the payment business system, so that the management user can adjust and control the payment business system according to the abnormality type of the payment business system.

[0218] Optionally, the abnormality analysis unit 1002 is specifically configured to:

[0219] According to the monitoring data corresponding to any business attribute dimension, obtain the abnormal index value of any business attribute dimension;

[0220] The abnormality degree of the payment business system in any business attribute dimension is determined based on the abnormality indicator value of any business attribute dimension and the abnormality indicator interval threshold set for any business attribute dimension.

[0221] Optionally, the business attribute dimension includes one or more of the following dimensions:

[0222] Stability dimension: Stability includes the stability of user attribute distribution and transaction attribute distribution in the payment business system;

[0223] Account suspiciousness dimension;

[0224] Transaction suspiciousness dimension;

[0225] Unconventional business usage data dimension;

[0226] User complaint data dimension;

[0227] Limit the data dimensions of the transaction area;

[0228] Optionally, when any business attribute dimension is a stability dimension, the monitoring data corresponding to any business attribute dimension is user attribute data and / or transaction attribute data;

[0229] The abnormality analysis unit 1002 is specifically configured to:

[0230] Obtaining attribute value distribution corresponding to each attribute within a monitoring period based on user attribute data and / or transaction attribute data;

[0231] Determine the stability of each attribute based on the attribute value distribution of each attribute during the monitoring period and the historical attribute value distribution of each attribute;

[0232] Based on the stability of each attribute, determine the abnormal indicator value of the payment business system in the stability dimension.

[0233] Optionally, when any business attribute dimension is an account suspicion dimension, the monitoring data corresponding to any business attribute dimension is account data of at least one account whose business volume is greater than a preset business volume threshold;

[0234] The abnormality analysis unit 1002 is specifically configured to:

[0235] determining a degree of suspicion of each account based on the account data of each account in the at least one account;

[0236] determining a suspicious account among at least one account based on the suspiciousness of each account;

[0237] Determine the abnormal indicator value of the payment business system in the account suspiciousness dimension based on the determined number of suspicious accounts.

[0238] Optionally, the abnormality analysis unit 1002 is further configured to:

[0239] For each suspicious account, determine the matching degree between each suspicious account and each suspicious type based on the matching degree between each suspicious account and the suspicious accounts marked as suspicious types;

[0240] Determine the suspicious type to which each suspicious account belongs based on the degree of matching between each suspicious account and each suspicious type;

[0241] Generate a monitoring report based on the suspicious type of each suspicious account.

[0242] Optionally, when any business attribute dimension is a transaction suspiciousness dimension, the monitoring data corresponding to any business attribute dimension is transaction data;

[0243] The abnormality analysis unit 1002 is specifically configured to:

[0244] Based on the transaction values ​​of suspicious transactions in the transaction data during the monitoring period, the abnormal indicator value on the transaction suspicion dimension is determined.

[0245] Optionally, when any business attribute dimension is a non-routine business usage dimension, the monitoring data corresponding to any business attribute dimension is transaction data;

[0246] The abnormality analysis unit 1002 is specifically configured to:

[0247] Based on the number of target objects of non-routine business use in transaction data during the monitoring period, the abnormal indicator value in the non-routine business use dimension is determined, where the target objects include users and transaction scenarios using payment services.

[0248] Optionally, when any business attribute dimension is a user complaint dimension, the monitoring data corresponding to any business attribute dimension is user complaint data regarding the payment business system;

[0249] The abnormality analysis unit 1002 is specifically configured to:

[0250] Determine the number of user complaint records during the monitoring period based on the complaint data, and determine the abnormal indicator value in the user complaint dimension based on the number of complaint records.

[0251] Optionally, the abnormality analysis unit 1002 is further configured to:

[0252] Extract complaint text from complaint data;

[0253] After segmenting the complaint text, extract at least one keyword from the segmented terms;

[0254] Clustering is performed based on at least one keyword to obtain at least one category and keywords included in each category;

[0255] Determine the complaint incidents during the monitoring period based on the keywords included in each category;

[0256] Generate complaint analysis reports based on complaint events.

[0257] The device can be used to perform Figures 2 to 9 The method shown in the embodiment shown, therefore, for the functions that can be realized by each functional module of the device, please refer to Figures 2 to 9 The description of the illustrated embodiment is omitted for brevity.

[0258] The above-mentioned device can be a physical device for realizing payment business system monitoring, or it can be realized by software, that is, the above-mentioned payment business system monitoring device can be a computer program (including program code) running in a computer device. For example, the payment business system monitoring device is an application software, which can be used to execute the corresponding steps in the payment business system monitoring method provided in the embodiment of the present application. Figure 10 A payment service system monitoring device stored in a memory is shown, which can be software in the form of a program and a plug-in, and includes a series of modules, including a data acquisition unit 1001, an anomaly analysis unit 1002 and a business control unit 1003; wherein the acquisition unit 1001, the anomaly analysis unit 1002 and the business control unit 1003 are used to implement the payment service system monitoring method provided in an embodiment of the present invention.

[0259] See Figure 11 Based on the same technical concept, an embodiment of the present application also provides a computer device 110, which may include a memory 1101 and a processor 1102.

[0260] The memory 1101 is used to store computer programs executed by the processor 1102. The memory 1101 may mainly include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function, etc.; the data storage area may store data created according to the use of the computer device, etc. The processor 1102 may be a central processing unit (CPU), or a digital processing unit, etc. The specific connection medium between the above-mentioned memory 1101 and the processor 1102 is not limited in the embodiment of the present application. The embodiment of the present application is Figure 11 In the embodiment, the memory 1101 and the processor 1102 are connected via a bus 1103. The bus 1103 is connected to the processor 1102 via a bus 1103. Figure 11 The bus 1103 can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 11 Only one thick line is used in the diagram, but this does not mean that there is only one bus or one type of bus.

[0261] Memory 1101 may be a volatile memory, such as random-access memory (RAM); or a non-volatile memory, such as read-only memory, flash memory, a hard disk drive (HDD), or a solid-state drive (SSD); or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but is not limited thereto. Memory 1101 may be a combination of the aforementioned memories.

[0262] The processor 1102 is configured to execute the following when calling the computer program stored in the memory 1101: Figures 2 to 9 The method executed by the device in the embodiment shown.

[0263] In some possible implementations, various aspects of the method provided in the present application may also be implemented in the form of a program product, which includes program code. When the program product is run on a computer device, the program code is used to enable the computer device to perform the steps of the method according to various exemplary embodiments of the present application described above in this specification. For example, the computer device may perform the following steps: Figures 2 to 9 The method executed by the device in the embodiment shown.

[0264] In one possible implementation, the executable instructions of the program product may be deployed to be executed on one computing device, or on multiple computing devices located at one location, or on multiple computing devices distributed at multiple locations and interconnected by a communication network. Multiple computing devices distributed at multiple locations and interconnected by a communication network may constitute a blockchain system.

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

[0266] Although the preferred embodiments of the present application have been described, those skilled in the art may make additional changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the present application.

[0267] Obviously, those skilled in the art may make various changes and modifications to this application without departing from the spirit and scope of this application. Thus, if these modifications and variations of this application fall within the scope of the claims of this application and their equivalents, this application is intended to include these modifications and variations.

Claims

1. A payment service system monitoring method, characterized in that: The method comprises: Acquiring monitoring data of a payment service system within a set monitoring period, the monitoring data including monitoring data corresponding to multiple business attribute dimensions of the payment service system, where each attribute dimension corresponds to a monitoring indicator of the payment service system; the payment service system is used to provide business support for payment services; the multiple business attribute dimensions are attribute dimensions related to the payment services; and the multiple business attribute dimensions are multiple dimensions of potential anomalies in the payment service system; Performing anomaly analysis based on the monitoring data corresponding to each business attribute dimension to obtain the degree of anomaly of the payment business system in each business attribute dimension; Obtaining the abnormality degree of the payment service system and the abnormality type of the payment service system according to the abnormality degree of the payment service system in each service attribute dimension; determining an abnormality level of the payment service system according to the abnormality degree of the payment service system; The payment service system is controlled according to the abnormality level and the abnormality type.

2. The method according to claim 1, wherein Performing business control of the payment business system according to the abnormality level and the abnormality type includes: A monitoring report is generated according to the abnormality level and the abnormality type, and the monitoring report is sent to a management user associated with the payment service system, so that the management user can perform service control on the payment service system according to the monitoring report.

3. The method according to claim 1, wherein Performing business control of the payment business system according to the abnormality level and the abnormality type includes: When the abnormality level of the payment business system is higher than the set abnormality level threshold, an early warning message is sent to the management user associated with the payment business system. The early warning message carries the abnormality type indication information of the payment business system, so that the management user can adjust and control the payment business system according to the abnormality type of the payment business system.

4. The method according to claim 1, wherein For any business attribute dimension, anomaly analysis is performed based on the monitoring data corresponding to each business attribute dimension to obtain the anomaly degree of the payment business system in each business attribute dimension, including: Obtaining an abnormality indicator value of any business attribute dimension according to the monitoring data corresponding to the any business attribute dimension; The abnormality degree of the payment service system in any business attribute dimension is determined according to the abnormality index value of any business attribute dimension and the abnormality index interval threshold set for any business attribute dimension.

5. The method according to claim 1, wherein The business attribute dimension includes one or more of the following dimensions: Stability dimension, including the stability of user attribute distribution and transaction attribute distribution in the payment service system; Account suspiciousness dimension; Transaction suspiciousness dimension; Unconventional business usage data dimension; User complaint data dimension; Limit the transaction area data dimension.

6. The method according to claim 4, wherein When any of the business attribute dimensions is a stability dimension, the monitoring data corresponding to any of the business attribute dimensions is user attribute data and / or transaction attribute data; Then, according to the monitoring data corresponding to any business attribute dimension, an abnormality index value of any business attribute dimension is obtained, including: Obtaining attribute value distribution corresponding to each attribute within a monitoring period based on user attribute data and / or transaction attribute data; Determine the stability of each attribute based on the attribute value distribution of each attribute during the monitoring period and the historical attribute value distribution of each attribute; According to the stability of each attribute, the abnormality index value of the payment service system in the stability dimension is determined.

7. The method according to claim 4, wherein When any one of the business attribute dimensions is an account suspicion dimension, the monitoring data corresponding to the any one of the business attribute dimensions is account data of at least one account whose business volume is greater than a preset business volume threshold; Then, according to the monitoring data corresponding to any business attribute dimension, an abnormality index value of any business attribute dimension is obtained, including: determining a degree of suspicion of each account based on the account data of each account in the at least one account; determining a suspicious account among the at least one account based on the suspiciousness of each account; The abnormality index value of the payment service system in the dimension of the account suspicion is determined according to the determined number of suspicious accounts.

8. The method according to claim 7, wherein After determining a suspicious account among the at least one account based on the suspiciousness of each account, the method further includes: For each suspicious account, determining a matching degree between each suspicious account and each suspicious type based on a matching degree between each suspicious account and suspicious accounts marked with a suspicious type; Determining the suspicious type to which each suspicious account belongs based on the matching degree between each suspicious account and each suspicious type; Generate a monitoring report based on the suspicious type of each suspicious account.

9. The method according to claim 4, wherein When any of the business attribute dimensions is a transaction suspicion dimension, the monitoring data corresponding to the any of the business attribute dimensions is transaction data; Then, according to the monitoring data corresponding to any business attribute dimension, an abnormality index value of any business attribute dimension is obtained, including: An abnormality indicator value on a transaction suspicion dimension is determined based on transaction values ​​of suspicious transactions within the monitoring period in the transaction data.

10. The method according to claim 4, wherein When any of the business attribute dimensions is a non-routine business usage dimension, the monitoring data corresponding to the any of the business attribute dimensions is transaction data; Then, according to the monitoring data corresponding to any business attribute dimension, an abnormality index value of any business attribute dimension is obtained, including: According to the number of target objects of non-routine business use in the transaction data during the monitoring period, an abnormal index value in the non-routine business use dimension is determined, wherein the target objects include users and transaction scenarios using payment services.

11. The method according to claim 4, wherein When any of the business attribute dimensions is a user complaint dimension, the monitoring data corresponding to any of the business attribute dimensions is user complaint data regarding the payment service system; Then, according to the monitoring data corresponding to any business attribute dimension, an abnormality index value of any business attribute dimension is obtained, including: Determine the number of complaint records of users within the monitoring period based on the complaint data, and determine the abnormal indicator value in the user complaint dimension based on the number of complaint records.

12. The method according to claim 11, wherein The method further comprises: Extracting complaint text from the complaint data; After segmenting the complaint text, extracting at least one keyword from the segmented terms; Clustering is performed based on the at least one keyword to obtain at least one category and keywords included in each category; Determining complaint events within the monitoring period based on the keywords included in each category; Generate a complaint analysis report based on the complaint event.

13. A payment service system monitoring device, characterized in that: The device comprises: a data acquisition unit, configured to acquire monitoring data of the payment service system within a set monitoring period, the monitoring data including monitoring data corresponding to multiple business attribute dimensions of the payment service system, each attribute dimension corresponding to a monitoring indicator of the payment service system; the payment service system is configured to provide business support for the payment service, the multiple business attribute dimensions are attribute dimensions related to the payment service, and the multiple business attribute dimensions are multiple dimensions of potential anomalies in the payment service system; an abnormality analysis unit, configured to perform abnormality analysis based on the monitoring data corresponding to each business attribute dimension, to obtain the abnormality degree of the payment business system in each business attribute dimension; to obtain the abnormality degree of the payment business system and the abnormality type of the payment business system based on the abnormality degree of the payment business system in each business attribute dimension; and to determine the abnormality level of the payment business system based on the abnormality degree of the payment business system; A service control unit is used to perform service control of the payment service system according to the abnormality level and the abnormality type.

14. 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 steps of the method according to any one of claims 1 to 12 are implemented.

15. A computer storage medium having computer program instructions stored thereon, characterized in that: When the computer program instructions are executed by a processor, the steps of the method according to any one of claims 1 to 12 are implemented.

Images