Account business data processing method and device, equipment, medium and program product

Abstract

The embodiment of the invention provides an account business data processing method and device, equipment, a medium and a program product, and relates to the field of artificial intelligence. The method comprises the steps of obtaining business data of multiple accounts in response to a starting instruction; in a plurality of preset risk levels, determining target risk levels corresponding to the plurality of accounts according to the business data of the plurality of accounts; for any account in the plurality of accounts, according to the target risk level corresponding to any account, configuring a management and control strategy for performing operation management and control on any account; wherein under the condition that the target risk level of any account is the risk level except the risk level with the highest risk in the plurality of risk levels, the management and control strategy configured for any account is determined according to the business requirement of any account; and receiving an operation instruction for any account, and determining whether to execute the operation instruction according to the management and control strategy configured for any account. According to the method, different accounts are subjected to hierarchical management and control, and the account use experience of the user can be improved.

Description

Technical Field

[0001] The present application relates to the field of artificial intelligence, and in particular to a method, apparatus, device, medium, and program product for processing business data of an account. Background Art

[0002] To facilitate user transactions, the service provider will open an account for the user. The account holder is usually the user of the account. The user can use the account to conduct related transactions on the platform provided by the service provider. The account's business data is generated during the account opening and transaction process.

[0003] Taking a bank account as an example, as a service provider, a bank can provide users with services such as deposits, withdrawals, and transfers. After a user opens a bank account, each transaction they perform generates transaction data. In some scenarios, for reasons of account security and other considerations, banks may control account operations based on this transaction data.

[0004] Existing methods, when managing accounts based on business data, overly restrict users' use of accounts, resulting in significant restrictions on users' business operations, reducing the efficiency of business process processing, and thus causing a decline in the user experience when using accounts. Summary of the Invention

[0005] The present application provides a method, apparatus, device, medium and program product for processing business data of an account, which is used to solve the technical problem that the processing efficiency of business processes is reduced during the account management and control process, resulting in a decreased user experience.

[0006] In a first aspect, the present application provides a method for processing business data of an account, applied to an electronic device, the method comprising:

[0007] In response to an initiation instruction for initiating business data processing, business data of a plurality of accounts is obtained, the business data including account information representing the accounts and data of account operations;

[0008] Among the preset multiple risk levels, target risk levels corresponding to the multiple accounts are determined based on the business data of the multiple accounts. The multiple risk levels are used to represent the possible degree of abnormal operation risk in the accounts;

[0009] For any of the multiple accounts, configure a control policy for operating the account based on the target risk level corresponding to the account. If the target risk level of any account is a risk level other than the highest risk level among the multiple risk levels, the control policy configured for the account is determined based on the business needs of the account.

[0010] Receive operation instructions for any account and determine whether to execute the operation instructions based on the control policy configured for any account.

[0011] In a second aspect, the present application provides an account business data processing device, applied to an electronic device, the device comprising:

[0012] an acquisition module, configured to acquire business data of a plurality of accounts in response to an initiation instruction for initiating business data processing, the business data including account information representing the accounts and data on account operations;

[0013] A determination module is used to determine target risk levels corresponding to the multiple accounts based on the business data of the multiple accounts from among multiple preset risk levels, where the multiple risk levels are used to represent the degree of possible abnormal operation risk of the accounts;

[0014] a configuration module for configuring, for any one of the multiple accounts, a control policy for performing operational control on the account based on a target risk level corresponding to the account; wherein, if the target risk level of the account is a risk level other than the highest risk level among the multiple risk levels, the control policy configured for the account is determined based on the business needs of the account;

[0015] The receiving module is used to receive operation instructions for any account and determine whether to execute the operation instructions based on the management and control policy configured for any account.

[0016] In a third aspect, the present application provides an electronic device comprising: a processor, and a memory communicatively connected to the processor; the memory stores computer-executable instructions; and the processor executes the computer-executable instructions stored in the memory to implement the method provided in the first aspect.

[0017] In a fourth aspect, the present application provides a computer-readable storage medium, in which computer-executable instructions are stored. When the computer-executable instructions are executed by a processor, they are used to implement the method provided in the first aspect.

[0018] In a fifth aspect, the present application provides a computer program product, comprising a computer program, which implements the method provided in the first aspect when executed by a processor.

[0019] The present application provides a method, apparatus, device, medium, and program product for processing business data of accounts. The method obtains business data from multiple accounts in response to a startup instruction for initiating business data processing. The business data includes account information and account operation data representing the accounts. Within multiple preset risk levels, a target risk level corresponding to each of the multiple accounts is determined based on the business data of the multiple accounts. The multiple risk levels are used to represent the likelihood of an account exhibiting abnormal operation risk. Because the behavioral intentions of each account during operation can be analyzed based on the business data, the target risk level corresponding to each account can be more accurately determined based on the behavioral intentions. This reduces the probability of misjudgment of risk and improves the accuracy of risk assessment. Furthermore, for any of the multiple accounts, a control policy for controlling operations on the account is configured based on the target risk level corresponding to the account. If the target risk level of the account is a risk level other than the highest risk level among the multiple risk levels, the control policy configured for the account is determined based on the business needs of the account. An operation instruction for the account is received, and a determination is made based on the control policy configured for the account whether to execute the operation instruction. In this way, when the target risk level of an account is a relatively low-risk level, the management and control strategy can be flexibly determined while taking into account the security of the account and fully combining the business needs of the account. The determined management and control strategy can be more adapted to the user's use needs of the account, so that the user's account permissions are not unnecessarily restricted. When receiving operation instructions to process business processes, the user can use the account to handle business more smoothly, improve the processing efficiency of the business process, and thus improve the user's usage experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0021] Figure 1 A schematic diagram of an application scenario provided in an embodiment of the present application;

[0022] Figure 2 A flowchart of a method for processing business data of an account provided in an embodiment of the present application;

[0023] Figure 3 A schematic diagram of managing and controlling non-highest risk accounts provided in an embodiment of the present application;

[0024] Figure 4 A schematic diagram of the anti-fraud system processing flow for smart account management provided in an embodiment of the present application;

[0025] Figure 5 A flowchart of account management and control provided in an embodiment of the present application;

[0026] Figure 6 A schematic diagram of the structure of a business data processing device for an account provided in an embodiment of the present application;

[0027] Figure 7 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application.

[0028] The above drawings illustrate specific embodiments of the present application, which will be described in more detail below. These drawings and the textual description are not intended to limit the scope of the present application in any way, but rather to illustrate the concepts of the present application to those skilled in the art by reference to specific embodiments. DETAILED DESCRIPTION

[0029] Exemplary embodiments will be described in detail herein, with examples illustrated in the accompanying drawings. In the following description, when referring to the drawings, identical numerals in different figures represent identical or similar elements, unless otherwise indicated. The embodiments described in the following exemplary embodiments are not intended to represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.

[0030] 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, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, storage, use, processing, transmission, provision, disclosure and application of relevant data comply with relevant laws, regulations and standards, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0031] In addition, this application involves big data analysis of user information (including but not limited to personal biometrics, identity data, consumption data, asset data, electronic terminal operation data, etc.), and the use of artificial intelligence technology for automated decision-making, and a technical solution for making decisions that have a significant impact on personal rights and interests based on the results of automated decision-making. The application provides users with corresponding operation entrances for users to choose to agree or reject the results of automated decision-making; if the user chooses to reject, the expert decision-making process will be entered.

[0032] It should be noted that the account business data processing method, device, equipment, medium and program product provided in this application can be used in the field of artificial intelligence, and can also be used in any field other than artificial intelligence. The application field of the account business data processing method, device, equipment, medium and program product in this application is not limited.

[0033] Banks provide financial services to users. For example, through bank accounts, users can conduct financial transactions such as deposits, withdrawals, and transfers. In the context of combating telecommunications fraud, banks currently play a key role in this fight. Some banks have established risk monitoring and control systems to implement blocking measures for abnormal accounts and suspicious transactions, both personal and corporate, to prevent funds from being diverted through fraudulent activities. Blocking measures can be understood as control measures or strategies used to manage account operations.

[0034] For example, the risk monitoring and control system will take appropriate blocking measures based on the fraud risk assessment of the account. For accounts with high fraud risk, more stringent blocking measures such as payment-only control, lowering account payment limits, or freezing large amounts of funds can be implemented.

[0035] Current blocking measures are typically triggered in batches by the execution system of the risk monitoring and control system, based on pre-set anti-fraud rules. Since the execution system struggles to accurately grasp the true intentions behind account transactions, its accuracy in determining an account's fraud risk is low, leading to a certain probability of misidentifying non-fraud-related accounts as fraudulent, potentially resulting in non-fraud-related accounts being accidentally affected by the blocking measures.

[0036] Taking appropriate blocking measures to control accounts can reduce the probability of fraudulent funds being transferred. However, if fraud risk is misjudged and strict blocking measures are taken against the misjudged account, the blocking measures will hinder the user's ability to use the account normally for business, which will in turn lead to a decline in the user's experience when using the account.

[0037] Furthermore, because current blocking measures are often implemented without the user's knowledge, users often only become aware of them when they use their accounts to conduct business. If an account is misidentified and strict blocking measures are implemented, and the user urgently needs to use the account without being aware of the control measures in advance, this will cause great inconvenience to the user when using the account, and may even cause losses to the user, leading to user dissatisfaction.

[0038] In related technologies, existing risk monitoring and control systems not only use batch triggering to determine fraud risk across multiple accounts, but also implement corresponding blocking measures for risky accounts in batches. Furthermore, when implementing blocking measures for all accounts with the same risk, the same blocking measures are applied.

[0039] For example, a large number of accounts are assessed for risk together. For accounts assessed as risk-free, no blocking measures are taken, and users of these accounts can use their accounts normally to conduct business without restrictions. For accounts assessed as risky, strict blocking measures such as collection-only control, lowering of account payment limits, and freezing of large amounts of funds are adopted. Users of these accounts will be subject to greater restrictions when using their accounts to conduct business. If some of these risky accounts are misjudged as risky and are mistakenly placed under control, the users of these accounts, who should have been able to use their accounts normally, are unable to do so due to the misjudgment and blocking measures, which will lead to a decline in user experience.

[0040] An analysis of the aforementioned batch control approach reveals its rationale for simplicity and ease of implementation. Since this approach only requires a single blocking measure for equal risk, it eliminates the need to analyze each account's specific circumstances and develop differentiated control measures. This streamlines the control process and makes it easy to implement. While this approach appears to be a unified, strict approach for account security, it actually sacrifices user convenience to reduce control complexity.

[0041] The above-mentioned method of uniformly taking the same blocking measures for all accounts with the same risk is a one-size-fits-all and rough control method. It ignores the usage barriers brought to users and fails to minimize the restrictions on user account use while taking into account account security.

[0042] Furthermore, since the above method adopts a unified blocking measure, it is not possible to formulate and implement management and control strategies based on the business needs of different users for their accounts, which may easily lead to unnecessary and excessive restrictions on users' account permissions, resulting in a reduced user experience.

[0043] Taking two bank accounts, A and B, as an example, assuming that the user of Account A uses Account A mainly for small deposits and fixed-term savings transactions, the business demand of this account is savings funds; the user of Account B uses Account B mainly for large-value corporate transfers and corporate collections, so the business demand of this account is corporate fund circulation.

[0044] If Account A and Account B are both judged to be risky accounts with equal risks, and unified blocking measures of only receiving but not paying are adopted, although users of Account A will feel less restricted account use when handling subsequent deposit transactions, users of Account B will feel stronger restrictions on account use when handling subsequent large-scale corporate transfers. If Account B is misjudged as risky and strict blocking measures are implemented, it is very likely that users will not be able to transfer funds normally when using Account B, resulting in obstructed business processes and reduced processing efficiency of business processes, which may cause user dissatisfaction and reduce the user experience.

[0045] The above examples are only general examples. With the diversified development of business, the business needs of different users in using accounts to handle business vary greatly. If a simple and rough one-size-fits-all management and control method is adopted, it will not be able to meet the needs of different users in using accounts to handle business. When users handle business, the processing efficiency of the business process is reduced, and it is difficult to improve the user experience of the majority of users in using accounts.

[0046] In view of this, embodiments of the present application provide a method for processing account business data, which can be applied to electronic devices. In response to a startup instruction to process account business data, business data for multiple accounts can be obtained. This business data can include account information and account operation data representing the accounts. Based on the business data, the behavioral intentions of each account when performing operations can be analyzed. Furthermore, based on the behavioral intentions, the target risk level corresponding to each account can be more accurately determined from multiple preset risk levels. This can reduce the probability of risk misjudgment and improve the accuracy of risk assessment.

[0047] Furthermore, for any of these accounts, a control strategy for operation control can be configured for it according to its corresponding target risk level. In order to improve the adaptability between the control strategy and the account, so as to minimize the restrictions on the user's use of the account while taking into account the security of the account, the method of the present application, when the target risk level of any account is a risk level other than the highest risk level among multiple risk levels, the control strategy configured for any account is determined according to the business needs of any account. In this way, when the target risk level of the account is a relatively low-risk risk level, the control strategy can be flexibly determined while taking into account the security of the account and fully combining the business needs of the account. The determined control strategy can be more adapted to the user's use needs for the account, so that the user's account authority is not unnecessarily restricted, thereby allowing the user to use the account more smoothly to handle business, thereby improving the user's experience.

[0048] Furthermore, it receives an operation instruction for any account and determines whether to execute the operation instruction based on the control policy configured for the account. In this way, it can judge the received operation instruction based on the control policy configured for any account, thereby realizing the control of the operation behavior of any account. This control takes into account both account security and user usage rights, which can reduce the situation where business process processing is blocked when users handle business, thereby improving the efficiency of business process processing and enhancing the user experience.

[0049] The specific application scenario of this application can be, for example, a scenario related to business data processing of a bank account.

[0050] Figure 1 A schematic diagram of an application scenario provided in an embodiment of the present application, such as Figure 1 As shown, banks can periodically conduct fraud risk monitoring and account management activities for bank accounts. For example, on a monthly basis, banks can analyze the likelihood of fraud risk for each account based on the business data generated by each account within that month, and then determine a target risk level for each account based on the likelihood.

[0051] For example, three risk levels can be set in advance based on the likelihood of fraud: high risk, medium risk, and low risk. High risk indicates a high likelihood of fraud; medium risk indicates a moderate likelihood of fraud; and low risk indicates a low likelihood of fraud.

[0052] The corresponding target risk level can be determined for each account through manual analysis or machine analysis algorithms. Figure 1 As shown in , after analyzing and confirming multiple bank accounts separately, the target risk level of account 1 is high risk, the target risk level of account 2 is medium risk, the target risk level of account 3 is low risk, the target risk level of account 4 is low risk, the target risk level of account 5 is low risk, and so on.

[0053] After determining the target risk level corresponding to each account, a corresponding management and control strategy is configured for each account based on the target risk level of the account. The operation of the account is controlled through the management and control strategy, so that users are less likely to be affected by fraudulent activities when conducting business through the account.

[0054] For medium-risk and low-risk accounts, control strategies can be determined based on the account's business needs. For example, a medium-risk control strategy can be configured for medium-risk account 2, a low-risk control strategy 1 can be configured for low-risk account 3, a low-risk control strategy 2 can be configured for low-risk account 4, a low-risk control strategy 3 can be configured for low-risk account 5, and so on. This allows for more tailored control strategies to be tailored to each non-high-risk account based on their business needs. When executing control strategies, unnecessary restrictions on user account usage can be reduced while maintaining account security, thereby improving the user experience.

[0055] The following specific embodiments describe in detail the technical solution of the present application and how the technical solution of the present application solves the above-mentioned technical problems. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described below in conjunction with the accompanying drawings.

[0056] Figure 2 This is a flow chart of a method for processing business data of an account provided in an embodiment of the present application. The execution subject of this method may be an electronic device with corresponding data storage and computing capabilities, such as a computer or server. Figure 2 As shown, the method includes:

[0057] S201 , in response to a start instruction for starting business data processing, obtain business data of multiple accounts, where the business data includes account information representing the accounts and data of account operations.

[0058] Taking a bank account as an example, the electronic device can be a server or other electronic device in the bank's data center. When a user uses the account to conduct business, the server can record the business data generated by the transaction. This business data can be data representing account operations or data representing account information.

[0059] Account operation data may include data generated by user operations on an account. For example, account transaction records include transaction data such as the name of the transaction object, transaction time, and transaction amount; or account login activity data such as login time, login device, and login location.

[0060] Account information data can be data generated to record basic information such as account attributes and status. For example, account attribute data may include the account holder's name, age, occupation, identity information, user risk preference, and account type (savings account or checking account, etc.); another example is account status data, such as account balance, account change records, activated account services, commonly used services, and the permissions and scope of each service.

[0061] A system capable of processing business data may be loaded into an electronic device. This system may include a computer program. This system may process business data for any one or more accounts. Upon receiving a command to initiate business data processing, the system may interpret the command and begin executing the relevant steps for business data processing.

[0062] For example, a system like this could be an anti-fraud system for intelligent account management. This system could retrieve business data for multiple accounts from server storage or other locations and begin processing this data. By organizing, analyzing, and making decisions about this business data, the system can gain a more comprehensive understanding of each account's current status and historical behavior, providing a reliable basis for determining the account's target risk level.

[0063] S202 , determining target risk levels corresponding to the multiple accounts according to the business data of the multiple accounts from among the preset multiple risk levels, wherein the multiple risk levels are respectively used to characterize the possible degree of abnormal operation risk of the accounts.

[0064] For example, N risk levels can be pre-set, where N can be any positive integer. Each risk level is used to represent the likelihood of abnormal operation risk in an account. For example, the risk levels can represent different degrees of abnormal operation risk in descending order of likelihood.

[0065] For example, three risk levels are preset, from low to high, based on the likelihood of abnormal operation risk. Low risk indicates a low likelihood of abnormal operation risk, which, for online fraud, can be interpreted as a low likelihood of the corresponding account being involved in fraud. Medium risk indicates a moderate likelihood of abnormal operation risk, which, for online fraud, can be interpreted as a moderate likelihood of the corresponding account being involved in fraud. High risk indicates a high likelihood of abnormal operation risk, which, for online fraud, can be interpreted as a high likelihood of the corresponding account being involved in fraud.

[0066] When determining target risk levels corresponding to each of the multiple accounts based on their business data, at least one method capable of determining the target risk level may be used. For example, this may be determined using a manual analysis and identification method or a machine learning algorithm.

[0067] In one implementation, for any of the multiple accounts, machine learning algorithms (such as cluster analysis or anomaly detection algorithms) are used to identify transactions that do not conform to the account's normal behavior patterns, thereby implementing abnormal transaction detection. Furthermore, based on the frequency and amount of transactions, abnormally high-frequency or large-value transactions are identified, implementing frequency and amount analysis. Based on the results of abnormal transaction detection and frequency and amount analysis, the target risk level for the account can be determined.

[0068] In another implementation, for any of the multiple accounts, the flow of funds between the account and other accounts is analyzed to identify a potential network of associated accounts. The target risk level of the account can be determined based on the target risk level of each account in the network of associated accounts.

[0069] In another implementation, a rules engine can be incorporated into the system to determine the target risk level. Specifically, predefined rules, such as blacklists and transaction limits, can be defined within the rules engine based on known patterns of fraud. By matching relevant data within the business data with the predefined rules, the target risk level of the account can be determined based on the matching results.

[0070] In one possible implementation, determining the target risk level corresponding to each of the multiple accounts based on their business data can be accomplished in the following manner:

[0071] For any account among multiple accounts, the business data of any account is input into the account grading model, and the target risk level corresponding to any account is output; wherein, the account grading model is a model obtained through training for predicting the target risk level of the account, and the account grading model includes a feature extraction layer for extracting account features from business data, a risk assessment layer for predicting risk assessment results for the extracted account features, and a grading output layer for classifying the predicted risk assessment results.

[0072] Exemplarily, the feature extraction layer may be a network structure layer used to extract features related to risk assessment from massive business data, and its structure may include network structure layers such as convolution layers, pooling layers and / or activation layers. The embodiment of the present application does not limit the structure of the feature extraction layer.

[0073] Account characteristics can be understood as features relevant to risk assessment. Account characteristics can also be defined as feature vectors that characterize account behavior. For example, business data such as account transaction frequency, transaction amount and fluctuation, transaction object diversity, account opening date, basic account holder information (such as age, occupation, and region), and account login behavior (such as login time and device diversity) can all characterize account behavior to a certain extent. Therefore, account characteristics can be extracted from business data.

[0074] For example, if account features are extracted from the business data of an account that frequently logs in late at night and has an abnormally large transaction amount, the corresponding relevant eigenvalues ​​in the extracted eigenvector will show a higher risk tendency.

[0075] For example, to improve the ability of account characteristics to represent risk assessments, feature selection algorithms from data mining techniques can be used to select highly representative features as account characteristics. For example, methods such as information gain or chi-square tests can be used to screen out the most influential account characteristics for risk assessment from multiple features, thereby constructing a concise and effective feature vector space, providing a more accurate basis for the subsequent determination of target risk levels.

[0076] Information gain can be used in algorithms such as decision trees. Information gain gradually selects features with strong representational power by measuring how much a feature reduces the uncertainty of the target variable. Selecting account features with strong representational power through information gain can help improve model performance and interpretability. When applying this method, you can first define the target variable and feature set. Then, calculate the entropy of the dataset to measure the uncertainty of the dataset. Then, calculate the conditional entropy of each feature in the feature set and calculate the information gain, which can be calculated as the difference between the entropy of the dataset and the conditional entropy. The higher the information gain, the more the feature reduces the uncertainty of the target variable, and the stronger the representational power. The feature with the highest information gain can be identified as the account feature.

[0077] The chi-square test can be used to test the independence of categorical variables. In feature selection, the chi-square test can help identify features that are significantly associated with the target variable. When applying it, you can first define the target variable and the feature set. Then, for each feature, a contingency table is constructed to display the frequency of each category of the feature and each category of the target variable through the contingency table. The chi-square statistic and expected frequency are calculated for each feature. Then, a significance level (which can be 0.05) is determined to determine whether the association between the feature and the target variable is significant. Based on the degrees of freedom and the significance level, the critical value is found from the chi-square distribution. By comparing the chi-square statistic with the critical value, the features that are significantly associated with the target variable are determined to be account features.

[0078] The risk assessment layer can be used to predict the extracted account features to obtain risk assessment results. Risk assessment models can be constructed based on machine learning algorithms. These algorithms may include logistic regression, support vector machines (SVMs), decision trees, and their ensembles (such as random forests and gradient boosting trees).

[0079] Taking random forests as an example, a risk assessment layer can be constructed by building multiple decision trees. Each tree can be trained based on a different feature subset and sample subset. The feature subset can be a subset of the set of all features used to build the decision tree, and the sample subset can be a subset of the set of all samples used to build the decision tree.

[0080] When assessing the risk of an account, each decision tree predicts the account's target risk level based on its own rules. Ultimately, the predictions from all decision trees are combined through voting and other methods to arrive at the account's risk assessment result. This ensemble learning approach effectively improves the model's generalization and prediction accuracy, better addressing complex account risk assessment scenarios.

[0081] The hierarchical output layer can be used to categorize the predicted risk assessment results, and its structure is not limited. The hierarchical output layer can further refine the risk assessment results obtained by the risk assessment layer into specific hierarchical outputs. Pre-set risk levels can be divided into three risk levels: high risk, medium risk, and low risk, or even more detailed levels, to facilitate the subsequent implementation of targeted management and control strategies.

[0082] For example, an account's risk assessment results can be expressed as a score. A score of 60 or below can be set as low risk, between 60 and 80 as medium risk, and 80 or above as high risk. By comparing the account's risk assessment score with the risk level range, the account's target risk level can be determined. This tiered output provides clear guidance for banks' anti-fraud efforts, ensuring that accounts of varying risk levels receive appropriate management and attention.

[0083] In this embodiment of the present application, by inputting the business data of any account into the account grading model, the target risk level corresponding to any account can be quickly output, thereby improving the efficiency of determining the target risk level for the account. Furthermore, because the account grading model includes a feature extraction layer, a risk assessment layer, and a grading output layer, it can comprehensively analyze the account's business data based on a machine learning algorithm model to predict a more accurate assessment result, reducing the probability of misjudging the risk level and improving the accuracy of determining the target risk level.

[0084] S203. For any account among the multiple accounts, configure a control strategy for performing operational control on the any account according to the target risk level corresponding to the any account; wherein, when the target risk level of any account is a risk level other than the highest risk level among the multiple risk levels, the control strategy configured for the any account is determined based on the business needs of the any account.

[0085] For example, a control strategy can be understood as a blocking measure for controlling account operations. By implementing a control strategy on an account, account behavior can be intervened and restricted to a certain extent, helping to reduce the risk or loss of the account due to abnormal operations such as fraudulent transfers.

[0086] Since the degree of abnormal operation risk corresponding to each risk level is different, the control strategy is configured according to the target risk level of the account. The control strategy can be initially configured differently based on the difference in risk levels.

[0087] For example, consider multiple risk levels, including low, medium, and high. High risk is the highest risk level, while low and medium risk are the risk levels below the highest risk level. High-risk accounts may face a greater risk of abnormal operations, so when configuring control policies for them, consider account security as the primary consideration, with the degree of restrictions on user access as a secondary consideration. Low and medium risk accounts, on the other hand, face a lower risk of abnormal operations than high risk accounts. Therefore, when configuring control policies for these accounts, consider a balanced approach, focusing on both account security and the degree of restrictions on user access.

[0088] For example, for accounts with a high risk rating, strict control policies can be implemented. These policies include restricting accounts to only receive payments, freezing large amounts of funds, limiting the scope of transactions, and prohibiting cross-border transactions. These policies can effectively prevent the transfer of fraudulent funds and improve account security.

[0089] For accounts with a target risk rating of medium, you can configure moderately strict control policies. For example, you can limit the amount of a single transaction and the total daily transaction amount, restrict trading hours (such as prohibiting large transactions late at night), and implement real-time monitoring of trading partners. These control policies can effectively mitigate risks without significantly impacting user account usage.

[0090] For accounts with a target risk rating of low, the strictness of the control policy can be further relaxed compared to accounts with medium risk. For example, only real-time monitoring of trading behavior and early warning of abnormal transactions can be performed, without excessive restrictions. These relatively relaxed control policies can reasonably control risks under normal user usage, balancing account security and user experience.

[0091] Furthermore, for low-risk and / or medium-risk accounts, to ensure that the configured control policy is more tailored to the user's needs for the account and that the user's account permissions are not unnecessarily restricted, the control policy can be determined based on the account's business needs. Business needs can refer to the user's needs when using the account for business purposes, or they can be understood as the business goals the user hopes to achieve through the account.

[0092] For example, if the user of Account A uses Account A to make small deposits and transfer fixed deposits, the business requirement for this account is savings. If the user of Account B uses Account B to make large-value corporate transfers and corporate collections, the business requirement for this account is corporate fund circulation. If the user of Account C uses Account C to purchase and redeem mutual funds, the business requirement for this account is investment and wealth management. If the user of Account D uses Account D to conduct foreign exchange transactions and remittances, the business requirement for this account is foreign exchange transactions.

[0093] If the target risk levels of Account A, Account B, Account C, and Account D are all determined to be risk levels other than the highest risk level among multiple risk levels, a management and control strategy can be determined for each account based on its respective business needs, thereby achieving differentiated management and control strategy configuration and implementation.

[0094] For example, a management and control strategy can be established for Account A based on the business needs of its savings funds, such as real-time monitoring of the amount, time, and frequency of savings. This management and control of Account A minimizes user restrictions when handling savings fund transactions and allows for timely identification of potential abnormal operations, thereby protecting account security.

[0095] Based on the business needs of account B's public fund transfers, you can determine a control strategy for account B. For example, you can restrict transactions to weekday working hours, reduce the limit for individual transfers, and keep records of transaction accounts. This allows users to conduct public transfers normally during working hours while also controlling for any abnormal operations during fund transfers, thereby protecting account security.

[0096] A management and control strategy can be determined for Account C based on the business needs of investment and financial management of Account C. For example, a maximum single investment amount and a maximum daily investment amount can be set, and a prompt message will be issued when the preset amount is exceeded. In this way, when implementing management and control over Account C, only moderate control is carried out on businesses related to investment and financial management, and no control is exercised over businesses such as savings and transfers. In this way, there is no unnecessary excessive control over Account C, and users can still use Account C normally for businesses such as savings or corporate transfers. If there is a business need for savings or corporate transfers in Account C in the future, the management and control strategy can be updated according to business needs to adapt to the management and control of Account C.

[0097] For Account D, a management and control strategy can also be determined based on its business needs. For example, specific foreign exchange exchange limits can be set, such as per-transaction and per-day, and transaction accounts for foreign exchange remittances can be recorded. This approach allows users to conduct foreign exchange transactions within the limits without affecting other transactions. This ensures account security to a certain extent while reducing restrictions on user access and improving the user experience.

[0098] In the example of accounts A, B, C, and D above, if, instead of implementing differentiated controls on each account, a uniform, strict control strategy such as payment-only control, lowering payment limits, and freezing large amounts of funds were applied, this would cause inconvenience to users of at least some of these accounts. If the accounts of users experiencing inconvenience are also accounts with an overestimated target risk level, they are likely to be dissatisfied with the control measures, resulting in negative feedback and a reduced user experience.

[0099] It can be seen that for different users with the same risk level, it is necessary to determine the management and control strategies in a targeted manner according to the business needs of each account, and differentiated and diverse management and control strategies can be more adapted to the usage needs of the general users with multiple accounts for their respective accounts.

[0100] S204: Receive an operation instruction for any account, and determine whether to execute the operation instruction according to the control policy configured for any account.

[0101] For example, an electronic device may receive an operation instruction for any account sent via a terminal device. The terminal device may be, for example, a mobile phone, an automated teller machine, an ATM, or a computer. The operation instruction may be any type of operation instruction, such as an operation instruction for logging into an account, an operation instruction for transferring funds, an operation instruction for making a purchase, or an operation instruction for changing an account password.

[0102] After determining the account's control policy, operations can be controlled based on that policy. For example, upon receiving an operation instruction for any account, the system can parse the instruction, including the operation object and parameters, and compare the parsed content with the control policy. If the instruction complies with the control policy, it will be executed; if it does not, it will not be executed. This process ensures the security of account operations and prevents potential fraud and abnormal trading activities.

[0103] For example, a user in Account B attempts to make a corporate transfer of 10,000 yuan. The user logs into Account B via their mobile phone and enters the recipient's information and the transfer amount on the transfer page. This information is used to generate the transfer object and parameters in the transfer instruction. Furthermore, the transfer time and terminal device code are also used to generate the parameters. After receiving the instruction from Account B, the bank's server parses the instruction and compares the parsed information with the control policy for Account B. If the instruction complies with the control policy, the transfer is executed. If not, the transfer is not executed. If the transfer is not executed, the user can be provided with a prompt explaining the reason for the non-execution.

[0104] An embodiment of the present application provides a method for processing business data of accounts. The method obtains business data of multiple accounts in response to a start instruction for initiating business data processing. The business data includes account information and account operation data representing the accounts. Based on the business data of the multiple accounts, a target risk level corresponding to each of the multiple accounts is determined, among multiple preset risk levels. The multiple risk levels are used to represent the likelihood of abnormal operation risk in each account. Because the behavioral intention of each account during operation can be analyzed based on the business data, the target risk level corresponding to each account can be more accurately determined based on the behavioral intention. This reduces the probability of misjudgment of risk and improves the accuracy of risk assessment. Furthermore, for any of the multiple accounts, a control policy for controlling operations on the account is configured based on the target risk level corresponding to the account. If the target risk level of the account is a risk level other than the highest risk level among the multiple risk levels, the control policy configured for the account is determined based on the business needs of the account. An operation instruction for the account is received, and a determination is made whether to execute the operation instruction based on the control policy configured for the account. In this way, when the target risk level of an account is a relatively low-risk level, the management and control strategy can be flexibly determined while taking into account the security of the account and fully combining the business needs of the account. The determined management and control strategy can be more adapted to the user's use needs of the account, so that the user's account permissions are not unnecessarily restricted. When receiving operation instructions to process business processes, the user can use the account to handle business more smoothly, improve the processing efficiency of the business process, and thus improve the user's usage experience.

[0105] For example, for an account, the services that have been activated for the account can, to a certain extent, indicate the user's need to use the account to handle services. Therefore, the service needs of the account can be conveniently determined through the services that have been activated for the account.

[0106] In a possible implementation, the method further includes: when the target risk level of any account is a risk level other than the highest risk level among multiple risk levels, obtaining the business type of the business already opened for any account from the business data of any account; and determining the business needs of any account based on the business type of the business already opened for any account.

[0107] For example, a business can refer to matters or transactions that can be accomplished through an account. For a bank account, a business can be financial activities or transactions related to the account, such as deposits, withdrawals, transfers, consumer payments, and loans.

[0108] Business types are categories for categorizing and managing multiple businesses. A business type is a category and can include multiple businesses. For example, a business type might include a deposit business type, which includes services such as cash deposits, check deposits, and electronic transfer deposits. A business type might also include a withdrawal business type, which includes services such as over-the-counter withdrawals, self-service withdrawals, and check cashing withdrawals. Other business types include transfer business types, payment business types, loan business types, and investment and wealth management business types. Businesses and business types are related to the services provided by the account's service provider. The types of services the service provider supports users to complete through the account determine the types of services the account can handle.

[0109] Because each user has different account usage requirements, they typically only enable the services they need within their account. For example, if an account user only needs to handle deposits, they may only enable deposit-related services and not loan-related services. For example, Account A only enables cash deposits, check deposits, and electronic transfer deposits, and does not enable consumer loans or mortgages. This shows that the types of services enabled for an account generally reflect the user's account usage needs. This allows for convenient identification of the account's business needs when determining account management and control strategies based on the types of services enabled.

[0110] Business data includes data representing account information, which may include data on activated services. For example, business data may include the service names or service numbers of all activated services for an account, such as the service numbers for cash deposits, check deposits, self-service withdrawals, and check cashing withdrawals. The business data for this account indicates that the activated services for this account are deposit and withdrawal types, indicating that the user of this account has deposit and withdrawal needs. This means that the account's business needs are determined to be deposit and withdrawal.

[0111] When determining the business needs of any account based on the business type of the business already opened for any account, it can be determined based on the preset mapping relationship between the business type and the business need, or it can be determined after analyzing the business type based on a regularized analysis algorithm. This embodiment of the present application does not limit this.

[0112] In one implementation, multiple business types can be summarized based on all business categories provided by the account's service provider, and the business requirements corresponding to each business type can be summarized based on the business type. Based on the correspondence between business types and business requirements, a preset mapping relationship between business types and business requirements can be preset. For example, this preset mapping relationship can be recorded in data in a data table structure. When determining the business requirements of any account based on the business type of the services already activated for that account, the business requirements corresponding to the business type can be traversed and queried in the preset mapping relationship based on the business type of the account, thereby quickly determining the business requirements of the account.

[0113] In the embodiment of the present application, the service type of any account's activated services can be first obtained from the service data of any account, and then the service needs of any account can be determined based on the service type of any account's activated services. In this way, when processing the service data of one or more accounts, the service needs of each account can be quickly and accurately determined in batches by combining the business data of each account, which can conveniently determine the business needs and improve the efficiency and accuracy of determining business needs.

[0114] For example, in some scenarios, although an account has multiple activated services, some of these services may not necessarily be what the user needs. For example, for a certain account, some of the activated services are activated by the user themselves, while others are automatically activated by the service provider. These automatically activated services are not necessarily what the user needs. Alternatively, even if all activated services are activated by the user themselves, there may be activated services that the user does not actually need. Therefore, the services that the user has actually used are closer to the user's usage needs and can more accurately represent the user's needs for using the account.

[0115] In a possible implementation, determining the service requirements of any account based on the service type of any account that has already opened a service can be specifically implemented as follows:

[0116] Historical account operation data within a preset historical period is obtained from the business data of any account; based on the historical account operation data, the business type corresponding to the business with execution records among the business types of the opened business for any account is determined as the target business type; when at least one target business type is determined, the business needs of any account are determined based on the at least one target business type and the corresponding execution records.

[0117] Illustratively, the preset historical period can be any time period prior to the current transaction data processing time. For example, it can be within a month, a quarter, or a year prior to the current transaction processing time. Historical account operation data can be data within the transaction data that represents account operations within the preset historical period. Historical account operation data includes execution records of all operations performed on the account within the preset historical period. These execution records can reflect the actual transactions performed by the user within the preset historical period.

[0118] The target service type can be understood as the service type of the account's activated services that have corresponding execution records within a preset historical period. Services with execution records indicate that the user has previously processed the service, so using the target service type can improve the accuracy of the service requirements identified.

[0119] For all activated services of an account, historical account operation data can be used to determine the services that the user has actually used within a preset historical period among all activated services. This can eliminate the interference of unused services in determining the business needs of the account, and can further improve the accuracy of determining the business needs of the account.

[0120] When at least one target service type is determined, the service requirements of any account can be determined based on the at least one target service type and its corresponding execution records. The service requirements can be determined based solely on the target service type, ignoring activated services that do not correspond to the target service type. The method for determining service requirements can be found in the description of the above embodiments and will not be further elaborated.

[0121] In an embodiment of the present application, by determining the target business type and determining the business needs of the account based on the target business type, business types corresponding to businesses that the user has not used within a preset historical period can be excluded, thereby avoiding these business types from interfering with the determination of user usage needs. User needs can be obtained with higher accuracy, thereby improving the accuracy of determining the business needs of the account.

[0122] For example, since the main body of the account that conducts business is the user of the account, and different users have different levels of acceptance of abnormal operation risks, when determining the management and control strategy, it can also be determined in combination with the user's acceptance of abnormal operation risks, which can further improve the adaptability of the management and control strategy to the user.

[0123] In a possible implementation, the method further includes: when the target risk level of any account is a risk level other than the highest risk level among multiple risk levels, determining the risk preference of any account based on the business data of any account, the risk preference being used to characterize the user's acceptance of abnormal operation risks of the account; configuring a control strategy for operational control of any account, including: configuring a control strategy for operational control of any account based on the business needs and risk preferences of any account.

[0124] For example, the risk preference of an account can also be understood as the risk preference of the account user. The risk preference can be information representing the user's acceptance of the risk of abnormal operations.

[0125] For example, some users believe they are highly susceptible to fraudulent activity and will not fall prey to it. Such users believe that strict account blocking measures implemented by the service provider will hinder their ability to use their accounts normally. Therefore, these users prefer minimal or no restrictions on account access and are more accepting of the risk of abnormal operations. For these users, management and control strategies can prioritize protecting their account access.

[0126] For example, some users prioritize account security over access permissions. These users prefer strict blocking measures to protect their accounts when the service provider identifies a risk of abnormal account operations. Therefore, these users prioritize account security and are less accepting of the risk of abnormal account operations. For these users, management and control strategies can prioritize account security.

[0127] Business data includes data indicating account information, which may include information about the user's risk preference. Examples include the target risk preference selected by the user from among multiple pre-set risk preference levels, information provided in a risk preference questionnaire, or information related to a user's risk preference test or assessment conducted by the service provider. The risk preference of the user's account can be determined based on the risk preference data in the business data.

[0128] For example, when configuring a control policy for operating and controlling any account based on the business needs and risk appetite of any account, the control items targeted by the control policy can be determined based on the business needs, and the control degree of the control items can be determined based on the risk appetite. For example, the businesses that require control can be determined based on business needs, and the degree or amount of control for each business that requires control can be determined based on the risk appetite.

[0129] In an embodiment of the present application, by determining the risk preference of an account, the risk preference of the account can be taken into consideration when configuring the management and control strategy. The degree of control over account operations can then be configured based on the risk preference of the account, and a management and control strategy that better matches the user's usage needs can be determined. This improves the adaptability of the management and control strategy and can take into account both the security of the account and the convenience of the user in using the account.

[0130] For example, under normal circumstances, an account will go through certain business operation processes or business operation steps when handling business; or, when handling business, different businesses correspond to different operation parameters. For example, when handling a transfer business through mobile banking, you need to log in to the account and enter the transfer page of the transfer business. On the transfer page, you need to fill in the account number of the transfer-out account and the account number of the transfer-in account, and you also need to fill in the transfer amount. After filling in, you need to enter the transfer password and click OK to complete the handling of this transfer business. Among them, logging in to the account, filling in the content, and entering the password can all be understood as business operation processes, and the account number and transfer amount can both be understood as operation parameters. When configuring the management and control strategy, you can generate a configuration file by setting the business operation process and / or the business operation threshold that constrains the operation parameters, and then configure the management and control strategy for the account through the configuration file.

[0131] In one possible implementation, when configuring a control policy for operating and controlling any account based on the business needs and risk preferences of any account, this can be specifically implemented as follows:

[0132] Determine at least one target business that requires operational control based on the business needs of any account; set a business operation threshold for at least one target business based on the risk preference of any account, and the business operation threshold is used to judge the operating parameters in the operation instruction for any account to determine whether to execute the operation instruction; and / or set a business operation process for at least one target business, and the business operation process is used to guide the handling of the corresponding business; generate a configuration file based on the business operation threshold and / or business operation process of at least one target business, and associate the configuration file with any account to conduct operational control over it.

[0133] For example, target services can be any service that requires operational control based on business needs, such as cash deposits, check deposits, check cashing withdrawals, or online transfers. When determining target services based on an account's business needs, the target services may include some or all of the services offered by the service provider that are relevant to meeting the business needs. Alternatively, the target services may include all of the account's already enabled services that are relevant to meeting the business needs.

[0134] When one or more target services are determined, a service operation threshold and / or service operation process for each target service may be set.

[0135] Taking the transfer business as an example, the business operation thresholds for transfers can include the upper limit for a single mobile banking transfer, the upper limit for a single mobile banking transfer per day, the upper limit for a single ATM transfer, and the upper limit for a single ATM transfer per day. For example, when setting the business operation thresholds for transfers, you could set the upper limit for a single mobile banking transfer to 10,000 yuan and the upper limit for a single mobile banking transfer to 20,000 yuan.

[0136] The business operation process of a transfer service may include user identity authentication during the transfer operation and transfer security verification during the transfer operation. For example, when setting up the business operation process of a transfer service, the user identity authentication during the transfer operation may be set to require biometric authentication, such as at least one of facial recognition, fingerprint recognition, or iris recognition; and the transfer security verification during the transfer operation may be set to require the input of a preset transfer password and a text message verification code from a reserved mobile phone number.

[0137] Exemplarily, the business operation process may also be a process for opening a low-level account online. Figure 3 A schematic diagram of managing non-highest-risk accounts provided in an embodiment of the present application assumes that the account is a Class A bank account. Since the authority level of a Class A account is higher than that of a Class B account, the business of a Class A account is less restricted, and a wide range of business types and high credit limits can be handled.

[0138] If the target risk level of a type of account is determined to be a risk level other than the highest risk level among multiple risk levels, such as Figure 3 As shown, the business operation process can be configured as follows: automatic control of Class 1 accounts; notification of account users; online opening of Class 2 accounts based on user instructions; partial transfer of funds from Class 1 accounts to Class 2 accounts; and transaction restrictions for Class 2 accounts. These business operation processes can be used to configure and execute control policies for Class 1 accounts. By setting up these business operation processes, transaction restrictions can be imposed on Class 1 accounts with higher permissions, preventing unauthorized transfers of funds within the accounts.

[0139] Optionally, upon user application or when the control policy is adjusted, the control policy can be adjusted to: release the Class 1 account and transfer funds from the Class 2 account back to the Class 1 account. This allows the user to resume using the Class 1 account to conduct business, avoiding prolonged restrictions on user access rights and improving the user experience.

[0140] When setting business operation thresholds and / or business operation processes for each target business, a corresponding configuration file can be generated. This configuration file can be used to store configuration information such as the business operation thresholds and / or business operation processes. The configuration file can be read by the system or application to dynamically execute the stored configuration information such as the business operation thresholds and / or business operation processes. The configuration file can be in a format such as XML, JSON, or YAML.

[0141] After the configuration file is generated, it can be stored in the storage space and associated with the corresponding account. In the subsequent management and control process, if an operation instruction of the corresponding account is received, the configuration file can be read and executed to judge the operation instruction of the account, thereby realizing the management and control of the operation of the account.

[0142] In an embodiment of the present application, by determining the target business, the control items targeted by the control strategy can be determined, and the control strategy can be configured in a targeted manner. Based on each target business, the business operation threshold and / or business operation process suitable for the user can be set according to the risk preference and the user's acceptance of abnormal operation risks, so that the control items can be set with an appropriate degree of control. Based on this, if there are multiple different users, each user's account can be managed in a differentiated and targeted manner, and each user's needs for account security and account usage rights can be taken into account, thereby improving the user experience of each user in the control process.

[0143] For example, after a configuration file is generated and associated with an account, the content of the configuration file can be read to effectively perform management and control of operations on the account.

[0144] In one possible implementation, determining whether to execute an operation instruction based on a management and control policy configured for any account includes: reading a configuration file, and when the configuration file includes a business operation threshold of at least one target business, obtaining operation parameters for at least one target business in the operation instruction, and comparing the operation parameters with the business operation threshold, and determining to execute the operation instruction when the operation parameters meet the business operation threshold; and / or, when the configuration file includes a business operation process of at least one target business, executing the business operation process, and determining to execute the operation instruction when the business operation process is successfully executed.

[0145] For example, the system for processing business data loaded in the electronic device can generate a configuration file or read the configuration file. After reading the configuration file, the account can be managed and controlled according to the specific content of the read configuration file.

[0146] After reading the configuration file, if it is parsed that the configuration file includes at least one service operation threshold of a target service, the operation parameters in the operation instruction may be compared and judged according to the service operation threshold.

[0147] For example, the configuration file sets a business operation threshold for the transfer service, one of the target services. Specifically, the business operation threshold is set to 10,000 yuan for a single transfer and 20,000 yuan for a single mobile banking transfer. The business operation threshold is read and the operation parameters for the transfer service in the received operation instruction are parsed.

[0148] Assuming the operation parameter is 30,000 yuan for this transfer, a comparison shows that this transfer of 30,000 yuan is greater than the upper limit of 10,000 yuan for a single transfer, which does not meet the business operation threshold. Therefore, the operation instruction is determined not to be executed and the transfer is rejected. Assuming the operation parameter is 10,000 yuan for this transfer, a comparison shows that this transfer of 10,000 yuan does not exceed the upper limit of 10,000 yuan for a single transfer, which meets the business operation threshold. Therefore, the operation instruction is determined to be executed and the transfer is approved.

[0149] After reading the configuration file, if it is parsed that the configuration file includes at least one business operation process of a target business, the user can be guided to handle the business according to the business operation process.

[0150] For example, the configuration file includes a business operation process for a transfer service, one of the target services. This process specifically requires facial recognition verification after an account submits a transfer request. Upon receiving an operation instruction for that account, if the instruction indicates submitting a transfer request, the facial recognition verification process is executed based on the configuration file. If the facial recognition verification passes successfully, the business operation process has been successfully executed, and the instruction can be determined to have been executed, and the transfer request can be approved. If the facial recognition verification fails, the business operation process has not been successfully executed, and the instruction can be determined not to have been executed, and the transfer request can be rejected.

[0151] In an embodiment of the present application, by reading the configuration file and comparing the business operation threshold in the configuration file with the operation parameters in the operation instruction, or by executing whether the business operation process in the configuration file is successfully executed, it is possible to quickly and accurately determine whether the operation instruction complies with the management and control strategy, thereby improving the efficiency of executing the management and control strategy.

[0152] For example, a user's account usage needs may change over time. For example, a user may have previously used an account for savings, but over time may want to use it for transfers, loans, or foreign exchange transactions. If the management and control policy cannot adapt to the changing business needs of the account, its compatibility with the user's usage needs may decrease, and it may not be able to effectively balance account security with the user's account usage needs.

[0153] In a possible implementation, the method further includes: obtaining, for any account among the multiple accounts, user feedback data, business data and / or management and control policy execution data of any account within a preset time period; and after the preset time period, updating the management and control policy of any account based on the user feedback data, business data and / or management and control policy execution data of any account.

[0154] Exemplarily, user feedback data can be any type of data provided by any user, such as text, images, and / or voice data provided by users through channels such as mobile banking, telephone banking, or ATMs. User feedback data can be used to indicate user opinions, suggestions, or evaluations. Management and control policy execution data can be data recording the execution of management and control policies, such as the time, number of executions, and results of management and control policy executions on accounts.

[0155] The preset time period may be a time period of any preset length, for example, a time period from the start of a preset date to the end of a preset date, or a preset week, month, or quarter.

[0156] Updating the control policy of any account based on the user feedback data, business data and / or control policy execution data of any account can be understood as determining whether the current control policy is applicable to the user of the account, that is, whether it meets the user's requirements for account security and account usage permissions, by analyzing the user feedback data, business data and / or control policy execution data, and then updating and adjusting the control policy of the account based on the analysis results.

[0157] For example, within a preset period of time (e.g., one month) after the current business data processing, user feedback data is collected, such as the certification materials uploaded online by the controlled account holder, and the account's business data and the control policy execution data within the preset period of time are obtained. By analyzing the account's business data and the control policy execution data within the preset period of time, it is determined whether the account has undergone any abnormal operations, as well as the time and number of abnormal operations. Combined with the user feedback data, it is determined whether the user's account permissions are subject to unnecessary restrictions.

[0158] If analysis determines that the current control policy, while ensuring account security, overly restricts user access, the policy can be adjusted appropriately to reduce restrictions on user access. If analysis determines that the current control policy cannot ensure account security, the policy can be adjusted appropriately to update to a control policy that ensures account security and prevents abnormal account operations.

[0159] In an embodiment of the present application, by obtaining user feedback data, business data and / or management policy execution data of any account within a preset time period, and after the preset time period, based on the user feedback data, business data and / or management policy execution data of any account, the management policy of any account is updated. In this way, the management policy can be adjusted in a timely manner according to the obtained data, so that the management policy can be adjusted in a timely manner according to the user feedback, the user's business handling and / or the execution of the management policy, so that the management policy can be kept adaptable to the account user in a timely manner, thereby improving the security and convenience of the user's use of the account.

[0160] For example, for multiple accounts, the control indicators corresponding to the multiple accounts can reflect whether the control strategies of the multiple accounts are adapted. Therefore, by updating the control strategies of some or all of the multiple accounts according to the control indicators, the control strategies of the accounts can be adjusted in a timely manner.

[0161] In a possible implementation, the method further includes: determining control indicators corresponding to the multiple accounts based on user feedback data, business data and / or control policy execution data of the multiple accounts, the control indicators including the false alarm rate, user complaint rate and / or risk interception rate of the multiple accounts; and updating the control policies of at least some of the multiple accounts based on the control indicators corresponding to the multiple accounts.

[0162] For example, a regular evaluation mechanism for control strategies can be established for multiple accounts to continuously monitor and evaluate the implementation of control strategies. By collecting user feedback data, business data, and / or control strategy execution data from multiple accounts, control indicators such as the false positive rate, user complaint rate, and / or risk interception rate for these accounts can be determined based on the acquired data, allowing timely identification of whether the control strategies are being implemented effectively.

[0163] The false positive rate refers to the percentage of accounts with no abnormal activity that are mistakenly identified as risky during the control process. A high false positive rate can prevent users of legitimate accounts from conveniently using their accounts and may also lead to user dissatisfaction with the service provider. Therefore, during the control process, it is necessary to minimize the false positive rate to ensure that legitimate accounts can conduct business smoothly.

[0164] The user complaint rate refers to the proportion of user complaints resulting from dissatisfaction with account control policies. This rate reflects the impact of control policies on user experience. An increase in the false positive rate or user complaint rate indicates that the current control policies for each account are causing significant user distress and require adjustments and updates to optimize the configuration.

[0165] The risk interception rate refers to the percentage of potential risks or abnormal operations that are successfully identified and intercepted during the control process. A high risk interception rate indicates that the current control strategy is effective in preventing abnormal operations and is a key indicator for account management.

[0166] For example, the risk interception rate can be used in combination with the false alarm rate to comprehensively evaluate whether the current control strategy needs to be updated. When it is determined that an update is needed, the direction of the update is to further determine whether to reduce the control strictness or increase the control strictness.

[0167] In an embodiment of the present application, the control indicators corresponding to the multiple accounts are determined through user feedback data, business data and / or control policy execution data of multiple accounts, and the control policies of at least some of the multiple accounts are updated based on the control indicators. The control policies can be adjusted objectively and timely so that the updated control policies can be more suitable for users of each account, which can effectively prevent risks and provide a good user experience.

[0168] For example, an account grading model can be used to determine the target risk level of an account. The account grading model can be trained. To train an account grading model with high prediction accuracy, training can be performed through methods such as data preprocessing and tuning model hyperparameters.

[0169] In one possible implementation, the account grading model is obtained by training in the following manner: performing a preprocessing operation on the business data of multiple sample accounts to obtain preprocessed business data of the multiple sample accounts, where the preprocessing operation includes at least one of the following: removing noise data, filling missing data, or data standardization; inputting the preprocessed business data of at least one sample account among the multiple sample accounts into the initial account grading model to obtain the target risk level corresponding to at least one sample account; and tuning the hyperparameters of the initial account grading model according to the target risk level of at least one sample account to obtain the account grading model.

[0170] For example, multiple sample accounts can be used as a sample set for training an account classification model. These sample accounts can be real or virtual accounts, and each sample account includes corresponding business data. Business data from a large number of accounts is collected, including both normal transaction data and data from confirmed fraudulent accounts. This business data is then cleaned and preprocessed, such as removing noise, filling in missing values, and / or performing data standardization, to ensure data quality and consistency.

[0171] For example, transaction amount data in business data can be converted into a unified monetary unit and normalized to be between 0 and 1 to facilitate better learning and processing by the model.

[0172] The initial account grading model can be understood as the model of the machine learning algorithm in the initial state before training, which may include network structures such as the initial feature extraction layer, the initial risk assessment layer, and the initial grading output layer.

[0173] During training, the initial machine learning algorithm model is trained using preprocessed business data. Cross-validation methods such as k-fold cross-validation can be used. For example, when using k-fold cross-validation for training, the preprocessed business data of multiple sample accounts is divided into k subsets. Training is performed on k-1 subsets each time, and the remaining subset is used to verify the model's performance. This is repeated k times, and the average value is taken as the final performance indicator of the model.

[0174] For example, assuming k is 10, assume that the sample accounts are 1,000. Preprocess the business data of these 1,000 sample accounts to obtain preprocessed business data. The 1,000 sample accounts are randomly divided into 10 sets. Each set can be considered a subset of the larger set of 1,000 sample accounts, and each subset contains 100 sample accounts. When training the initial account classification model, nine of the 10 subsets can be used as training sets, and the remaining subset as a test set. The initial account classification model is trained using these nine subsets, and the performance of the trained model is verified using the test set after training. This completes one training cycle. Similarly, each of the ten subsets can be used as a test set, allowing for a total of ten training cycles. This allows for a model with superior performance to be obtained through multiple training cycles.

[0175] During training, we adjust the model's hyperparameters, such as the depth of the decision tree and the number of trees in the random forest, based on the target risk level of the sample accounts obtained in each round of training. Through multiple rounds of training, we continuously optimize the model's performance until we identify the optimal hyperparameter combination, enabling the model to achieve good prediction results on both the training and validation sets.

[0176] In an embodiment of the present application, by preprocessing the business data of multiple sample accounts, the reliability of the business data can be improved, thereby enhancing the effectiveness of training. The preprocessed business data of at least one sample account is input into an initial account grading model to obtain the target risk level corresponding to each sample account. The hyperparameters of the initial account grading model can then be tuned based on the target risk level. Through one or more rounds of training, the hyperparameters can be repeatedly tuned, resulting in an account grading model that can accurately predict the target risk level, resulting in a highly accurate account grading model.

[0177] For example, the performance indicators of a model can reflect the processing capability or performance of the model. Therefore, the performance indicators of the model can be determined through test data, and then the model can be tuned according to the performance indicators to improve the processing capability or performance of the model.

[0178] In one possible implementation, after obtaining the account grading model, the method further includes: inputting business data of multiple test accounts into the account grading model to obtain target risk levels corresponding to each of the multiple test accounts; determining performance indicators of the account grading model based on the target risk levels of the multiple test accounts and the true value labels of the risk levels of the multiple test accounts, the performance indicators including at least one of the following: accuracy, recall, or the harmonic mean of accuracy and recall; and tuning the hyperparameters of the account grading model based on the performance indicators of the account grading model to optimize the account grading model.

[0179] For example, a test account can be understood as an account used to test the performance of an account grading model. This test account can be a real account or a virtual account, for example, a test account can be obtained from multiple sample accounts. The performance indicators of the account grading model can be understood as indicators that can characterize the performance of the account grading model, such as precision, recall, or the harmonic mean of precision and recall.

[0180] Precision represents the proportion of target risk levels correctly predicted by the model to the total number of predictions. This can be understood as the accuracy of the model's predictions, reflecting the accuracy of the model's predictions. Recall represents the proportion of accounts that are actually high-risk (or at other risk levels) correctly predicted by the model, reflecting the model's responsiveness. The harmonic mean of precision and recall, also known as the F1 value, comprehensively represents the model's accuracy and recall capabilities.

[0181] The true risk level label of the test account can be the actual target risk level of the test account. By comparing and calculating the true risk level label of the test account with the target risk level output by the account grading model, the performance index of the account grading model can be obtained.

[0182] If the account grading model's performance indicators determine that the model is deficient in a particular performance aspect, the model can be tuned specifically based on the deficient performance. For example, if the account grading model has a low recall rate for high-risk accounts, further analysis can be conducted to determine whether the cause is incomplete feature selection or an unreasonable model structure. The model structure and / or hyperparameters can then be optimized and adjusted accordingly. Alternatively, the model can be retrained after optimization and adjustment until satisfactory performance indicators are achieved, resulting in an account grading model with even better performance.

[0183] In the embodiments of the present application, the performance indicators of the account grading model can be determined by combining multiple test accounts and their true risk level labels with the target risk levels corresponding to the test accounts output by the account grading model. This allows analysis of the performance indicators to determine whether the account grading model has deficiencies in various aspects of its performance. Based on the results of the performance analysis, the hyperparameters of the account grading model can then be adjusted to optimize the account grading model and improve its performance.

[0184] Currently, controlled accounts often require the account holder to go to the service provider’s outlets for due diligence and verification before the control can be released. This process often takes up a lot of the account holder’s time.

[0185] For example, the electronic device used to execute the business data processing method for an account in an embodiment of the present application may be provided with an anti-fraud system for intelligent account management. This system can implement intelligent hierarchical management of accounts, effectively and intelligently managing high-risk suspicious accounts while meeting the normal fund usage needs of low-risk account holders. The system can automatically classify accounts and, through a configurable approach, customize and configure management and control strategies for accounts with different target risk levels. In addition, online resolution and control can be performed based on information such as supporting documentation provided by the account user.

[0186] Figure 4 A schematic diagram of the anti-fraud system processing flow for smart account management provided in the embodiment of the present application is shown in FIG. Figure 4 As shown, the account's business data is input into the anti-fraud system for intelligent account management. The account's target risk level can be determined using the account grading model in the anti-fraud system. A determination is then made as to whether the account's target risk level is the highest risk level. If the account's target risk level is the highest risk level, a management and control strategy corresponding to the highest risk level can be configured and implemented. If the account's target risk level is not the highest risk level, such as medium or low risk, a management and control strategy corresponding to medium or low risk can be configured and implemented.

[0187] After implementing a control strategy, the decision to remove the account control can be made based on the execution of the control strategy. If so, the account control can be removed or the control strategy can be adjusted based on the proof of removal uploaded online by the user. If not, the control strategy can be adjusted as appropriate and continued to be implemented.

[0188] Figure 5 A flowchart of account management and control provided in the embodiment of this application is shown in FIG. Figure 5 As shown, the method includes:

[0189] Step 1: Model Analysis and Account Level Processing (AccLevelModel). The account's business data is input into the account level model for model analysis, and the account is then leveled using the model. This account level model can be any of the above-described embodiments, and it supports custom risk levels.

[0190] Step 2: Configure the RiskStrategy. Customizable control strategies are supported, such as direct control of high-risk accounts and restrictions on transfer amounts, transaction amounts, and merchant purchases for medium-risk or low-risk accounts.

[0191] Step 3, Account Control (AccControl), can also be understood as the implementation of control strategies. Implement account control in conjunction with control strategies. For example, only accepting discrepancies, lowering account payment limits, freezing large amounts of funds, etc.

[0192] Step 4: Account Uncontrol Analysis, which can also be understood as a decision on the uncontrol strategy. This step is based on the uncontrol evidence uploaded online by the customer to determine whether the account can be uncontrolled.

[0193] Step 5: Account Uncontrol (AccUncontrol): Remove restrictions from the account control policy.

[0194] Through the embodiments of the present application, a unified platform can be provided. Specifically, the system implements unified management of account grading models and control policy configurations, supporting the effects of unified maintenance, rapid reuse, and flexible adjustment of models and policies. In addition, through the embodiments of the present application, an integrated service can be provided. Specifically, through the system, the integrated full-process processing of risk account identification, grading, control, and control can be achieved, which can improve the efficiency of anti-fraud work. Furthermore, through the embodiments of the present application, precise management can be provided. Specifically, through the system, hierarchical and precise management of risk accounts can be achieved, avoiding the accidental control of a large number of non-fraud-related accounts, and supporting online control, solving the pain point of low-risk customers not having to go to the outlets for control, which can improve the user experience.

[0195] An embodiment of the present application also provides a business data processing device for an account, which is applied to an electronic device. Figure 6 A schematic diagram of the structure of the business data processing device for an account provided in an embodiment of the present application, such as Figure 6 As shown, the device includes:

[0196] An acquisition module 601 is configured to acquire business data of multiple accounts in response to a start instruction for starting business data processing, where the business data includes account information representing the accounts and data on account operations;

[0197] Determination module 602, configured to determine target risk levels corresponding to each of the multiple accounts based on the business data of the multiple accounts from among multiple preset risk levels, wherein the multiple risk levels are respectively used to represent the degree of the possibility of abnormal operation risk in the accounts;

[0198] Configuration module 603, configured to configure, for any one of the multiple accounts, a control policy for performing operational control on the account based on a target risk level corresponding to the account; wherein, if the target risk level of the account is a risk level other than the highest risk level among the multiple risk levels, the control policy configured for the account is determined based on the business needs of the account;

[0199] The receiving module 604 is configured to receive an operation instruction for any account and determine whether to execute the operation instruction according to the control policy configured for any account.

[0200] In one possible implementation, the configuration module 603 is also used to: when the target risk level of any account is a risk level other than the highest risk level among multiple risk levels, obtain the business type of the business already opened for any account from the business data of any account; and determine the business needs of any account based on the business type of the business already opened for any account.

[0201] In one possible implementation, the configuration module 603 is specifically used to: obtain historical account operation data within a preset historical period from the business data of any account; based on the historical account operation data, determine the business type corresponding to the business with execution records among the business types of the opened business for any account as the target business type; when at least one target business type is determined, determine the business needs of any account based on the at least one target business type and the corresponding execution records.

[0202] In one possible implementation, the configuration module 603 is also used to: when the target risk level of any account is a risk level other than the highest risk level among multiple risk levels, determine the risk preference of any account based on the business data of any account, and the risk preference is used to characterize the user's acceptance of abnormal operation risks of the account; the configuration module 603 is specifically used to: configure a control strategy for operational control of any account based on the business needs and risk preferences of any account.

[0203] In one possible implementation, the configuration module 603 is specifically used to: determine at least one target business that requires operational control based on the business needs of any account; set a business operation threshold for at least one target business based on the risk preference of any account, and the business operation threshold is used to judge the operating parameters in the operation instruction for any account to determine whether to execute the operation instruction; and / or set a business operation process for at least one target business, and the business operation process is used to guide the handling of the corresponding business; generate a configuration file based on the business operation threshold and / or business operation process of at least one target business, and associate the configuration file with any account to perform operational control on it.

[0204] In one possible implementation, the receiving module 604 is specifically used to: read the configuration file, and when the configuration file includes a business operation threshold of at least one target business, obtain the operation parameters for at least one target business in the operation instruction, compare the operation parameters with the business operation threshold, and determine to execute the operation instruction when the operation parameters meet the business operation threshold; and / or, when the configuration file includes a business operation process of at least one target business, execute the business operation process, and determine to execute the operation instruction when the business operation process is successfully executed.

[0205] In one possible implementation, the configuration module 603 is further used to: obtain user feedback data, business data and / or management policy execution data of any account among multiple accounts within a preset time period; after the preset time period, update the management policy of any account based on the user feedback data, business data and / or management policy execution data of any account.

[0206] In one possible implementation, the configuration module 603 is further used to: determine the control indicators corresponding to multiple accounts based on user feedback data, business data and / or control policy execution data of multiple accounts, where the control indicators include the false alarm rate, user complaint rate and / or risk interception rate of multiple accounts; and update the control policies of at least some of the multiple accounts based on the control indicators corresponding to the multiple accounts.

[0207] In one possible implementation, the determination module 602 is specifically used to: for any account among multiple accounts, input the business data of any account into an account grading model, and output the target risk level corresponding to any account; wherein the account grading model is a model obtained through training for predicting the target risk level of the account, and the account grading model includes a feature extraction layer for extracting account features from business data, a risk assessment layer for predicting risk assessment results for the extracted account features, and a grading output layer for classifying the predicted risk assessment results.

[0208] In one possible implementation, the account grading model is obtained by training in the following manner: performing a preprocessing operation on the business data of multiple sample accounts to obtain preprocessed business data of the multiple sample accounts, where the preprocessing operation includes at least one of the following: removing noise data, filling missing data, or data standardization; inputting the preprocessed business data of at least one sample account among the multiple sample accounts into the initial account grading model to obtain the target risk level corresponding to at least one sample account; and tuning the hyperparameters of the initial account grading model according to the target risk level of at least one sample account to obtain the account grading model.

[0209] In one possible implementation, after obtaining the account grading model, the method further includes: inputting business data of multiple test accounts into the account grading model to obtain target risk levels corresponding to each of the multiple test accounts; determining performance indicators of the account grading model based on the target risk levels of the multiple test accounts and the true value labels of the risk levels of the multiple test accounts, the performance indicators including at least one of the following: accuracy, recall, or the harmonic mean of accuracy and recall; and tuning the hyperparameters of the account grading model based on the performance indicators of the account grading model to optimize the account grading model.

[0210] The account business data processing device provided in the embodiment of the present application can be used to execute the technical solution of the account business data processing method in any of the above embodiments of the present application. Its implementation principle and technical effects are similar, and will not be repeated here in this embodiment.

[0211] It should be understood that the above-described device embodiments are merely illustrative, and the device of the present application may also be implemented in other ways. For example, the division of units / modules in the above-described embodiments is merely a logical functional division, and actual implementations may employ other division methods. For example, multiple units, modules, or components may be combined or integrated into another system, or some features may be omitted or not implemented.

[0212] In addition, unless otherwise specified, the functional units / modules in the various embodiments of the present application may be integrated into a single unit / module, each unit / module may exist physically separately, or two or more units / modules may be integrated together. The aforementioned integrated units / modules may be implemented in the form of hardware or software program modules.

[0213] If the integrated unit / module is implemented in the form of hardware, the hardware can be a digital circuit, an analog circuit, etc. The physical implementation of the hardware structure includes but is not limited to transistors, memristors, etc. If the integrated unit / module is implemented in the form of a software program module and sold or used as an independent product, it can be stored in a computer-readable memory. Based on this understanding, the technical solution of the present application, 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, which is stored in a memory and includes a number of instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods of each embodiment of the present application.

[0214] Figure 7 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application is shown in FIG. Figure 7 As shown, the electronic device of this embodiment may include: at least one processor 701; and a memory 702 communicatively connected to the at least one processor; wherein the memory 702 stores instructions that can be executed by the at least one processor 701, and the instructions are executed by the at least one processor 701 so that the electronic device executes a method as in any of the above embodiments.

[0215] Optionally, the memory 702 may be independent or integrated with the processor 701 .

[0216] The implementation principle and technical effects of the electronic device provided in this embodiment can be found in the aforementioned embodiments and will not be described in detail here.

[0217] An embodiment of the present application further provides a computer-readable storage medium, wherein the computer-readable storage medium stores computer-executable instructions. When a processor executes the computer-executable instructions, the method described in any of the above embodiments is implemented.

[0218] An embodiment of the present application further provides a computer program product, including a computer program, which implements the method described in any of the aforementioned embodiments when executed by a processor.

[0219] The above-mentioned integrated module implemented in the form of a software functional module can be stored in a computer-readable storage medium. The above-mentioned software functional module is stored in a storage medium and includes a number of instructions for causing a computer device (which can be a personal computer, server, or network device, etc.) or a processor to perform some steps of the method described in each embodiment of the present application.

[0220] It should be understood that the above-mentioned processor can be a processing unit (Central Processing Unit, CPU), or other general-purpose processors, digital signal processors (Digital Signal Processor, DSP), application-specific integrated circuits (Application Specific Integrated Circuit, ASIC), etc. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc. The steps of the method disclosed in the application can be directly embodied as being executed by a hardware processor, or can be executed by a combination of hardware and software modules in the processor. The memory may include random access memory (Random Access Memory, RAM), and may also include non-volatile memory (NVM), such as at least one disk storage, and can also be various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a disk or an optical disk.

[0221] The storage medium may be implemented by any type of volatile or non-volatile memory device, or a combination thereof, such as static random-access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The storage medium may be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0222] An exemplary storage medium is coupled to a processor, such that the processor can read information from the storage medium and write information to the storage medium. Of course, the storage medium can also be an integral part of the processor. The processor and storage medium can be located in an application-specific integrated circuit. Of course, the processor and storage medium can also exist as discrete components in an electronic device or a host control device.

[0223] It should be noted that, in this document, the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or apparatus comprising a series of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, article, or apparatus. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or apparatus comprising the element.

[0224] The serial numbers of the embodiments of the present application are for description only and do not represent the advantages and disadvantages of the embodiments. Through the description of the above implementation modes, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus a necessary general hardware platform. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present application is essentially or the part that contributes to the prior art can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, a magnetic disk, an optical disk), including a number of instructions to enable a terminal device (which can be a mobile phone, a computer, a server or a network device, etc.) to execute the methods described in each embodiment of the present application.

[0225] The above are only preferred embodiments of the present application and do not limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made using the contents of the present application specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present application.

[0226] It should be noted that for the aforementioned method embodiments, for the sake of simplicity, they are all expressed as a series of action combinations, but those skilled in the art should be aware that this application is not limited by the order of the actions described, because according to this application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in this specification are all optional embodiments, and the actions and modules involved are not necessarily required by this application.

[0227] It should be further noted that, although the various steps in the flowchart are shown in sequence as indicated by the arrows, these steps are not necessarily performed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and these steps may be performed in other orders. Moreover, at least a portion of the steps in the flowchart may include multiple sub-steps or multiple stages, and these sub-steps or stages are not necessarily performed at the same time, but may be performed at different times. The execution order of these sub-steps or stages is not necessarily to be performed in sequence, but may be performed in turn or alternately with other steps or at least a portion of the sub-steps or stages of other steps.

[0228] In the above embodiments, the description of each embodiment has its own emphasis. For parts not described in detail in a particular embodiment, please refer to the relevant description of other embodiments. The technical features of the above embodiments can be combined in any way. To keep the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0229] Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the present application that follow the general principles of the present application and include common knowledge or customary techniques in the art not disclosed herein. The description and examples are to be considered as exemplary only, and the true scope and spirit of the present application are indicated by the following claims.

[0230] It should be understood that the present application is not limited to the exact structure described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present application is limited only by the appended claims.

Claims

1. A method for processing business data of an account, characterized in that: Applied to electronic equipment, the method includes: In response to an initiation instruction for initiating business data processing, business data of a plurality of accounts is acquired, the business data including account information representing the accounts and data of account operations; Determining target risk levels for each of the multiple accounts based on the business data of the multiple accounts, from among multiple preset risk levels, wherein the multiple risk levels are respectively used to represent the degree of possible abnormal operation risk of the accounts; For any one of the multiple accounts, configuring a control policy for performing operation control on the any one of the multiple accounts based on the target risk level corresponding to the any one of the accounts; wherein, if the target risk level of the any one of the multiple risk levels is a risk level other than the highest risk level among the multiple risk levels, the control policy configured for the any one of the accounts is determined based on the business needs of the any one of the accounts; Receive an operation instruction for any of the accounts, and determine whether to execute the operation instruction based on the management and control policy configured for any of the accounts.

2. The method according to claim 1, characterized in that The method further comprises: When the target risk level of any one of the accounts is a risk level other than the highest risk level among the multiple risk levels, obtaining a service type of a service activated for the any one of the accounts from the service data of the any one of the accounts; The business needs of any one of the accounts are determined according to the business types of the services already opened for the any one of the accounts.

3. The method according to claim 2, characterized in that The determining the service requirement of any account according to the service type of the service opened for any account includes: Obtaining historical account operation data within a preset historical period from the business data of any of the accounts; According to the historical account operation data, a business type corresponding to a business with an execution record among the business types of the services activated for any of the accounts is determined as a target business type; When at least one target business type is determined, the business demand of any one of the accounts is determined according to the at least one target business type and the corresponding execution record.

4. The method according to claim 1, wherein The method further comprises: If the target risk level of any of the accounts is a risk level other than the highest risk level among the multiple risk levels, determining the risk preference of the account based on the business data of the account, the risk preference being used to represent the user's acceptance of the risk of abnormal operations; The configuration of a control policy for performing operation control on any of the accounts includes: Configure a control strategy for operating and controlling any of the accounts based on the business needs and risk preferences of the accounts.

5. The method according to claim 4, characterized in that The control strategy for performing operational control on any of the accounts according to the business needs and risk preferences of the accounts includes: Determining at least one target business that requires operational control based on the business needs of any of the accounts; setting a business operation threshold for the at least one target business based on the risk preference of the any one account, the business operation threshold being used to judge operation parameters in an operation instruction for the any one account to determine whether to execute the operation instruction; and / or setting a business operation process for the at least one target business, the business operation process being used to guide the processing of the corresponding business; A configuration file is generated according to the business operation threshold and / or business operation process of the at least one target business, and the configuration file is associated with any one of the accounts to perform operation control on the account.

6. The method according to claim 5, characterized in that The determining whether to execute the operation instruction according to the control policy configured for any one of the accounts includes: Read the configuration file, and if the configuration file includes the business operation threshold of the at least one target business, obtain the operation parameters for the at least one target business in the operation instruction, compare the operation parameters with the business operation threshold, and determine to execute the operation instruction if the operation parameters meet the business operation threshold; and / or, if the configuration file includes the business operation process of the at least one target business, execute the business operation process, and determine to execute the operation instruction if the business operation process is successfully executed.

7. The method according to any one of claims 1 to 6, characterized in that The method further comprises: For any one of the multiple accounts, obtaining user feedback data, business data, and / or management and control policy execution data of the any one of the accounts within a preset time period; After the preset time period, the control policy of any one of the accounts is updated based on the user feedback data, business data and / or control policy execution data of any one of the accounts.

8. The method according to claim 7, characterized in that The method further comprises: Determining control indicators corresponding to the multiple accounts based on user feedback data, business data, and / or control policy execution data of the multiple accounts, the control indicators including a false alarm rate, a user complaint rate, and / or a risk interception rate of the multiple accounts; The control strategies of at least some of the multiple accounts are updated according to the control indicators corresponding to the multiple accounts.

9. The method according to any one of claims 1 to 6, characterized in that Determining target risk levels corresponding to each of the multiple accounts based on the business data of the multiple accounts includes: For any account among the multiple accounts, inputting the business data of the any account into the account grading model, and outputting a target risk level corresponding to the any account; Among them, the account grading model is a model obtained through training for predicting the target risk level of an account. The account grading model includes a feature extraction layer for extracting account features from the business data, a risk assessment layer for predicting risk assessment results for the extracted account features, and a grading output layer for classifying the predicted risk assessment results.

10. The method according to claim 9, characterized in that The account classification model is obtained through training in the following way: Performing a preprocessing operation on the business data of the plurality of sample accounts to obtain preprocessed business data of the plurality of sample accounts, wherein the preprocessing operation includes at least one of the following: removing noise data, filling missing data, or data standardization; Inputting the pre-processed business data of at least one sample account among the plurality of sample accounts into an initial account grading model to obtain a target risk level corresponding to each of the at least one sample account; The hyperparameters of the initial account grading model are tuned according to the target risk level of the at least one sample account to obtain the account grading model.

11. The method according to claim 10, characterized in that After obtaining the account grading model, the method further includes: Inputting business data of multiple test accounts into the account grading model to obtain target risk levels corresponding to each of the multiple test accounts; Determining a performance indicator of the account grading model based on the target risk levels of the multiple test accounts and the risk level truth labels of the multiple test accounts, the performance indicator comprising at least one of the following: precision, recall, or a harmonic mean of the precision and recall; The hyperparameters of the account grading model are tuned according to the performance indicators of the account grading model to optimize the account grading model.

12. A business data processing device for an account, characterized in that: Applied to electronic equipment, the device comprises: an acquisition module, configured to acquire business data of a plurality of accounts in response to an initiation instruction for initiating business data processing, wherein the business data includes account information representing the accounts and data of account operations; a determination module, configured to determine, from a plurality of preset risk levels, a target risk level corresponding to each of the plurality of accounts based on the business data of the plurality of accounts, wherein the plurality of risk levels are respectively used to represent the degree of possibility of abnormal operation risk in the account; a configuration module configured to configure, for any one of the multiple accounts, a control policy for performing operation control on the any one of the multiple accounts based on a target risk level corresponding to the any one of the accounts; wherein, if the target risk level of the any one of the multiple risk levels is a risk level other than the highest risk level among the multiple risk levels, the control policy configured for the any one of the accounts is determined based on the business needs of the any one of the accounts; The receiving module is used to receive an operation instruction for any of the accounts and determine whether to execute the operation instruction according to the management and control policy configured for any of the accounts.

13. An electronic device, characterized in that: include: a processor, and a memory communicatively connected to the processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory to implement the method according to any one of claims 1 to 11.

14. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer-executable instructions, which are used to implement the method according to any one of claims 1 to 11 when executed by a processor.

15. A computer program product, characterized in that The invention comprises a computer program, which implements the method according to any one of claims 1 to 11 when being executed by a processor.

Images