A payment security control method and system of a data middle platform

Abstract

The application provides a payment security control method and system of a data middle platform, determines a plurality of risk-free payment permissions and a plurality of risk payment permissions of a target customer in a data middle platform payment center; extracts an excess payment permission and a non-excess payment permission based on a quota limit value, determines a risk measure according to the non-excess payment permission; performs feature fusion on the risk measure to obtain a payment behavior feature, determines a security confidence based on a security evaluation model and the payment behavior feature; determines a payment risk cost of a large payment according to the risk payment permission combined with the risk measure; and adjusts the permission based on the payment risk cost and the security confidence. The above scheme adjusts the payment behavior of the target customer based on the payment risk cost and the security confidence, can identify the deviation mode of the payment amount of the payment permission in the user payment behavior, and makes timely permission adjustment on the current large payment behavior, thereby improving the payment security of the system.

Description

Technical Field

[0001] This application relates to the field of payment risk management technology, and more specifically, to a payment security control method and system for a data platform. Background Technology

[0002] In modern society, payment risk management plays a crucial role in the financial system. With the popularization of electronic and mobile payments and the increase in cross-border transactions, payment scenarios have become more diversified and complex, and payment risks have increased significantly. To address these risks and challenges, payment risk management has gradually developed and improved. Through the application of advanced technologies such as artificial intelligence and big data analysis, payment risk management systems can identify and respond to potential threats in real time, ensuring the security and stability of the payment process. The development of these technologies has also prompted payment risk management to shift from passive defense to proactive prevention, providing more reliable protection for financial institutions and users.

[0003] In existing payment risk management, big data analytics and machine learning play a crucial role. By analyzing user behavior patterns and historical transaction data, they predict and respond promptly to abnormal transactions. The development and improvement of payment risk management have effectively ensured the stability and security of the payment system. However, due to the large volume of funds, large-value payments often become the primary target of fraudsters, leading to an increase in potential payment risks. The payment amounts of large-value payments differ significantly from normal transaction patterns, often indicating abnormal payment activity, but they could also be legitimate high-value transactions. Misjudging legitimate high-value transactions can affect the security and reliability of the entire system and reduce the user experience. Therefore, how to accurately adjust permissions for current large-value payment behaviors to improve the system's payment security has become a challenge for the industry. Summary of the Invention

[0004] This application provides a payment security control method and system for a data platform, which can make accurate permission adjustments for current large-amount payment behaviors, thereby improving the payment security of the system.

[0005] Firstly, this application provides a payment security control method for a data platform, comprising the following steps:

[0006] Identify the multiple risk-free payment permissions and multiple risky payment permissions that the target customer can configure in the data platform payment center;

[0007] Based on the target customer's credit limit, extract multiple overpayment permissions and multiple non-overpayment permissions under the risk-free state from all risk-free payment permissions, and then determine the risk measurement of each overpayment permission in terms of payment amount based on all non-overpayment permissions;

[0008] Feature fusion is performed on all risk measures to obtain the payment behavior characteristics of the target customer when making payment operations. Based on the pre-trained security assessment model and the payment behavior characteristics, the security confidence level of the current target customer when making payment at the payment center is determined.

[0009] Determine the payment risk cost when a target customer makes a large payment based on all risk payment authority and all risk metrics.

[0010] When a target customer makes a large payment at the payment center, the payment behavior permissions of the target customer are adjusted based on the payment risk cost and the security confidence level.

[0011] In some embodiments, extracting multiple excess payment permissions and multiple non-excess payment permissions in a risk-free state from all risk-free payment permissions based on the target customer's credit limit specifically includes:

[0012] Obtain the credit limit of the target customer;

[0013] Extract the payment amount for each risk-free payment permission;

[0014] Based on the aforementioned limit and the payment amount of each risk-free payment permission, multiple excess payment permissions and multiple non-excess payment permissions are extracted from all risk-free payment permissions.

[0015] In some embodiments, determining the risk measure of each overpayment permission in terms of payment amount based on all non-overpayment permissions specifically includes:

[0016] Determine the payment limit margin for target customers when they make payment operations based on all non-overpayment permissions.

[0017] Set the security limit coefficient for payment operations in the payment center under risk-free conditions;

[0018] Get the payment amount for each overpayment permission;

[0019] The risk measure for each overpayment permission in terms of payment amount is determined based on the payment limit margin, the security limit coefficient, and the payment amount for each overpayment permission.

[0020] In some embodiments, feature fusion of all risk measures to obtain the payment behavior characteristics of the target customer when making a payment operation specifically includes:

[0021] Standardize all risk measures to obtain the normalized entropy of each risk measure;

[0022] Identify multiple entropy clusters for all canonical entropies;

[0023] Based on all entropy clustering groups, we extract the payment behavior characteristics of target customers when making payment operations.

[0024] In some embodiments, determining the security confidence level of the current target customer when making a payment at the payment center based on a pre-trained security assessment model and the payment behavior characteristics specifically includes:

[0025] Collect payment information of the current target customer in the payment center;

[0026] The payment risk coefficient of the payment information is extracted based on a pre-trained security assessment model;

[0027] The security confidence level of the current target customer when making a payment at the payment center is determined based on the payment risk coefficient and the payment behavior characteristics.

[0028] In some embodiments, adjusting the payment behavior permissions of a target customer based on the payment risk cost and the security confidence level specifically includes:

[0029] The transaction risk level of the current transaction is determined based on the stated payment risk cost and the stated security confidence level.

[0030] Based on the transaction risk level, the permissions for the target customer's transaction behavior in the payment center are adjusted.

[0031] In some embodiments, the data platform is a centralized data platform.

[0032] Secondly, this application provides a payment security control system for a data platform, comprising:

[0033] The determination module is used to determine the multiple risk-free payment permissions and multiple risk payment permissions that a target customer can configure in the data platform payment center;

[0034] The processing module is used to extract multiple overpayment permissions and multiple non-overpayment permissions in a risk-free state from all risk-free payment permissions based on the target customer's credit limit, and then determine the risk measure of each overpayment permission in terms of payment amount based on all non-overpayment permissions;

[0035] The processing module is also used to perform feature fusion on all risk measures to obtain the payment behavior characteristics of the target customer when making payment operations, and to determine the security confidence level of the current target customer when making payment at the payment center based on the pre-trained security assessment model and the payment behavior characteristics.

[0036] The processing module is also used to determine the payment risk cost when a target customer makes a large payment based on all risk payment permissions and all risk metrics.

[0037] The execution module is used to adjust the permissions of the target customer's payment behavior based on the payment risk cost and the security confidence level when the target customer makes a large payment in the payment center.

[0038] Thirdly, this application provides a computer device, the computer device including a memory and a processor, the memory storing code, and the processor being configured to acquire the code and execute the above-described payment security control method for a data platform.

[0039] Fourthly, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the aforementioned payment security control method for a data platform.

[0040] The technical solutions provided by the embodiments disclosed in this application have the following beneficial effects:

[0041] The payment security control method and system for the data platform provided in this application firstly identifies multiple risk-free payment permissions and multiple risky payment permissions that a target customer can configure in the data platform payment center. Secondly, based on the target customer's limit, multiple overpayment permissions and multiple non-overpayment permissions under risk-free status are extracted from all risk-free payment permissions. The risk metric for each overpayment permission in terms of payment amount is determined based on all non-overpayment permissions. Further, feature fusion is performed on all risk metrics to obtain the target customer's payment behavior characteristics during payment operations. Based on a pre-trained security assessment model and the payment behavior characteristics, the security confidence level of the current target customer when making payments in the payment center is determined. Then, the payment risk cost for the target customer making large payments is determined based on all risky payment permissions and all risk metrics. Finally, when the target customer makes a large payment in the payment center, the payment permissions for the target customer's payment behavior are adjusted based on the payment risk cost and the security confidence level.

[0042] Therefore, this application can identify deviation patterns in user payment behavior regarding payment amounts with payment permissions, and make accurate permission adjustments for current large-amount payments, thereby improving the system's payment security. First, determining the target customer's risk-free and risky payment permissions provides reliable data support for the payment security control system. Second, extracting excess payment permissions and non-excess payment permissions allows analysis of the deviation between transaction amounts and normal transaction patterns under risk-free conditions, increasing the accuracy of identifying risk-free payment behavior. Furthermore, by comparing the deviation of risk-free transaction amounts with the deviation of payment amounts when completing large-amount payments under risk conditions, the payment risk cost for the target customer making large-amount payments can be determined. This invention effectively identifies the risks and uncertainties in target customer transaction behavior, thereby accurately identifying deviation patterns in payment amounts and payment behaviors. Then, it extracts the payment risk coefficient of the current transaction and uses this coefficient to determine the security confidence level of the target customer when making payments at the payment center, enabling real-time identification of risky transaction behaviors. Finally, based on the payment risk cost and security confidence level, it adjusts the payment permissions for the target customer's payment behavior, improving the system's security and reliability. In summary, the technical solution provided in this application can identify deviation patterns in payment amounts and payment behaviors of users, and accurately adjust permissions for large-amount payments, thereby improving the system's payment security. Attached Figure Description

[0043] Figure 1 This is an exemplary flowchart of a payment security control method for a data platform according to some embodiments of this application;

[0044] Figure 2 This is an exemplary flowchart illustrating the determination of payment behavior characteristics of a target customer when making a payment operation, according to some embodiments of this application;

[0045] Figure 3 This is an exemplary flowchart illustrating the cost of payment risk when a target customer makes a large payment, according to some embodiments of this application;

[0046] Figure 4 This is a schematic diagram of the structure of a payment security control system for a data platform according to some embodiments of this application;

[0047] Figure 5 This is a schematic diagram of the structure of a computer device that implements a payment security control method for a data middleware according to some embodiments of this application. Detailed Implementation

[0048] To better understand the above technical solutions, the following will provide a detailed explanation of the technical solutions in conjunction with the accompanying drawings and specific implementation methods.

[0049] refer to Figure 1 The figure is an exemplary flowchart of a payment security control method for a data platform according to some embodiments of this application. The payment security control method 100 of the data platform mainly includes the following steps:

[0050] In step 101, the target customer is identified as having multiple risk-free payment permissions and multiple risk payment permissions that can be configured in the data platform payment center.

[0051] In practice, the multiple risk-free payment permissions and multiple risky payment permissions that a target customer can be configured with in the data platform payment center are determined. Specifically, the credit rating of the target customer in the payment center is obtained from the credit scoring system of the data platform. Based on the credit rating, the payment center grants the target customer corresponding risk-free payment permissions and risky payment permissions. Thus, the multiple risk-free payment permissions and multiple risky payment permissions that a target customer can be configured with in the data platform payment center can be determined. The credit rating can be obtained by analyzing the customer's historical transaction behavior data through the credit scoring system. Customers with small fluctuations in payment amount, timely payment, and regular transaction location and time can have a higher credit rating.

[0052] It should be noted that in this application, risk-free payment authority refers to the authority corresponding to payment behaviors that are considered risk-free (or safe and low-risk) in the transaction activities conducted by the customer in the payment center, while risky payment authority refers to the authority corresponding to payment behaviors that are considered high-risk in the transaction conducted by the customer in the payment center. By determining risk-free payment authority and risky payment authority, the legality and security of payments can be enhanced.

[0053] It should also be noted that the data platform in this application is a platform for centralized management and processing of data. The main functions of the data platform include data integration, management, analysis and service. The data platform is usually used to support enterprise decision-making and improve data utilization efficiency. The main service target of the data platform is the payment center. By analyzing historical payment data, the data platform can identify abnormal transaction patterns and transaction amounts and provide risk feedback on potential risks in current transaction behavior, thereby controlling payment security.

[0054] In step 102, based on the target customer's credit limit, multiple overpayment permissions and multiple non-overpayment permissions under the risk-free state are extracted from all risk-free payment permissions, and the risk measure of each overpayment permission in terms of payment amount is determined based on all non-overpayment permissions.

[0055] In some embodiments, extracting multiple excess payment permissions and multiple non-excess payment permissions under the risk-free state from all risk-free payment permissions based on the target customer's credit limit can be done in the following manner:

[0056] Obtain the credit limit of the target customer;

[0057] Extract the payment amount for each risk-free payment permission;

[0058] Based on the aforementioned limit and the payment amount of each risk-free payment permission, multiple excess payment permissions and multiple non-excess payment permissions are extracted from all risk-free payment permissions.

[0059] In specific implementation, the credit limit of the target customer is obtained by querying the amount of each transaction completed by the target customer in the payment center through a database query statement, and taking the median of all the amounts as the credit limit of the target customer. In addition, in other embodiments, other methods can be used to obtain the credit limit of the target customer, such as accessing the data platform management system, contacting the payment center customer service team, etc., which are not limited here.

[0060] It should be noted that, in this embodiment, the limit value represents a security assessment threshold for the payment center to monitor the payment amount of a target customer. When the single transaction payment amount of a target customer exceeds the limit value, the single transaction is determined to be a large payment, and a security assessment of the payment behavior of the single transaction is required. When the single transaction payment amount of a target customer is less than the limit value, the single transaction is determined to be a small transaction, and a security assessment of the payment behavior of the single transaction is not required. By determining the limit value, it is beneficial to control the risk of payment behavior, thereby ensuring the security of customers' payment operations at the payment center.

[0061] In practice, Python log analysis tools can be used to extract the payment amount for each risk-free payment permission from the data log files of the payment center. In addition, other methods can be used to extract the payment amount for each risk-free payment permission in other embodiments, such as data analysis platforms like Tableau and Power BI, which are not limited here.

[0062] In specific implementation, based on the credit limit and the payment amount of each risk-free payment permission, multiple excess payment permissions and multiple non-excess payment permissions are extracted from all risk-free payment permissions. That is, the payment amount of each risk-free payment permission is compared with the credit limit, all payment amounts less than or equal to the credit limit are extracted, and the risk-free payment permissions corresponding to each extracted payment amount are taken as non-excess payment permissions, thus obtaining multiple non-excess payment permissions. All payment amounts greater than the credit limit are extracted, and the risk-free payment permissions corresponding to each extracted payment amount are taken as excess payment permissions, thus obtaining multiple excess payment permissions.

[0063] It should be noted that in this application, the overpayment permission refers to the security transaction permission for the target customer's payment behavior that exceeds the preset limit during the payment process, while the non-overpayment permission refers to the security transaction permission for the target customer's payment behavior that does not exceed the preset limit during the payment process. By extracting the overpayment permission and the non-overpayment permission, more stringent permission management of payment behavior can be carried out to ensure the security and compliance of the payment system.

[0064] In some embodiments, the risk measure for each overpayment authority in terms of payment amount can be determined based on all non-overpayment authorities in the following manner:

[0065] Determine the payment limit margin for target customers when they make payment operations based on all non-overpayment permissions.

[0066] Set the security limit coefficient for payment operations in the payment center under risk-free conditions;

[0067] Get the payment amount for each overpayment permission;

[0068] The risk measure for each overpayment permission in terms of payment amount is determined based on the payment limit margin, the security limit coefficient, and the payment amount for each overpayment permission.

[0069] In some embodiments, determining the payment limit margin for a target customer when making a payment operation based on all non-overpayment permissions can be achieved in the following manner:

[0070] Determine the reference payment amount for target customers when they make payment transactions;

[0071] The amount of compensation for each non-overpayment permission is extracted based on the reference payment amount;

[0072] The payment limit margin for target customers is determined by all the credit limit compensation amounts.

[0073] In specific implementation, the percentile calculation method can be used to determine the reference payment amount when the target customer makes a payment operation. Specifically, the payment amounts of all non-excess payment permissions are extracted, and all payment amounts are sorted in ascending order to obtain a payment amount sequence. The payment amount located in the first 90% of the payment amount sequence is used as the reference payment amount when the target customer makes a payment operation. In addition, in other embodiments, other methods can be used to determine the reference payment amount, which are not limited here.

[0074] It should be noted that the method for extracting payment amounts for all non-overpayment permissions in this embodiment is as described above. The percentile calculation method is an existing calculation method based on statistical distribution, and neither of them will be elaborated here.

[0075] Additionally, it should be noted that in this embodiment, the reference payment amount represents the maximum transaction amount for most transactions made by the target customer at the payment center. By determining the reference payment amount, the common transaction amounts for the target customer at the payment center can be determined, thereby providing security guidance for the actual payment amount.

[0076] In specific implementation, the limit compensation amount for each non-overpayment permission is extracted based on the reference payment amount. That is, the payment amount of each non-overpayment permission is subtracted from the reference payment amount, and the absolute value of the difference is taken as the limit compensation amount for the non-overpayment permission, thereby obtaining the limit compensation amount for each non-overpayment permission. In addition, in other embodiments, other methods can be used to determine the limit compensation amount, which is not limited here.

[0077] It should be noted that in this embodiment, the amount of credit compensation represents the degree of constraint on the actual amount paid by the target customer when making a payment operation. The larger the amount of credit compensation, the more relaxed the constraint on the actual amount paid by the target customer when making a payment operation; the smaller the amount of credit compensation, the more tight the constraint on the actual amount paid by the target customer when making a payment operation.

[0078] In specific implementation, the payment limit margin when the target customer makes a payment operation is determined by all the limit compensation amounts. That is, the average of all limit compensation amounts is used as the payment limit margin when the target customer makes a payment operation. In addition, in other embodiments, other methods can be used to determine the payment limit margin, which are not limited here.

[0079] It should be noted that in this embodiment, the payment limit margin represents a certain amount of money that the target customer is accustomed to providing when making a payment. By determining the payment limit margin, it is possible to accommodate additional transaction needs and deal with occasional overpayment situations, thereby improving the customer's payment flexibility and continuity, and thus ensuring the ability to monitor risks during the payment process.

[0080] In practice, a security limit coefficient for payment operations in a risk-free state is set. That is, the security limit coefficient for payment operations in a risk-free state is preset by using all historical payment data of the payment center and combining expert experience. The value of the security limit coefficient can be set according to actual application needs, and is not limited here.

[0081] It should be noted that in this embodiment, the safety limit coefficient is a parameter used to monitor and adjust the payment limit margin. By determining the safety limit coefficient, the rationality of transaction operations can be improved, thereby effectively controlling payment risks.

[0082] In some embodiments, the risk measure of each overpayment permission in terms of payment amount, based on the payment limit margin, the security limit coefficient, and the payment amount of each overpayment permission, can be determined in the following manner:

[0083] Obtain multiple overpayment permissions from all risk-free payment permissions, and extract the payment amount for each overpayment permission;

[0084] For each overpayment permission, the security overpayment entropy corresponding to the overpayment permission is determined based on the payment limit margin, the security limit coefficient, and the payment amount of the overpayment permission, thereby obtaining the security overpayment entropy corresponding to each overpayment permission;

[0085] The distribution statistics of all security excess entropy are performed to determine the risk measure of each excess payment authority in terms of payment amount.

[0086] It should be noted that the method for withdrawing the payment amount for each overpayment limit is as described above, and will not be repeated here.

[0087] In specific implementation, the security excess entropy corresponding to the excess payment permission is determined based on the payment limit margin, the security limit coefficient, and the payment amount of the excess payment permission. That is, the product of the security limit coefficient and the payment limit margin is used as the adjustment base, the difference between the payment amount of each excess payment permission and the payment limit margin is calculated, and the ratio of each difference result to the adjustment base is used as the security excess entropy of each excess payment permission.

[0088] It should be noted that in this embodiment, the security excess entropy represents an indicator that measures the degree of abnormality of excess transactions in payment behavior relative to normal transaction patterns. Determining the security excess entropy can help assess the potential risks of each excess payment permission. The adjustment base is a normative parameter used for mathematical calculation. Determining the adjustment parameter can make the range of calculation results more reasonable, which will not be elaborated here.

[0089] In specific implementation, the distribution statistics of all security excess entropy are performed to determine the risk measure of each excess payment permission in terms of payment amount. That is, the difference between each security excess entropy and the mean of all security excess entropies is calculated, and the standard deviation of each difference result and all security excess entropies is used as the risk measure of each excess payment permission. In addition, in other embodiments, other methods can be used to determine the risk measure, which are not limited here.

[0090] It should be noted that in this application, the risk metric represents the position of each excess payment authority within all excess payment authorities and the degree of transaction abnormality. The larger the risk metric, the greater the deviation of the excess payment authority from the normal transaction pattern, and the higher the degree of risk. Conversely, the smaller the risk metric, the smaller the deviation of the excess payment authority from the normal transaction pattern, and the lower the degree of risk. By determining the risk metric, the payment center can identify abnormal high-risk transactions and thus take corresponding risk control measures.

[0091] In step 103, feature fusion is performed on all risk metrics to obtain the payment behavior characteristics of the target customer when making payment operations. Based on the pre-trained security assessment model and the payment behavior characteristics, the security confidence level of the current target customer when making payment at the payment center is determined.

[0092] In some embodiments, reference Figure 2 As shown in the figure, this is an exemplary flowchart illustrating the determination of payment behavior characteristics of a target customer during a payment operation, according to some embodiments of this application. In this embodiment, feature fusion of all risk measures is performed to obtain the payment behavior characteristics of the target customer during a payment operation, which can be achieved through the following steps:

[0093] First, in step 1031, all risk measures are standardized to obtain the normalized entropy of each risk measure;

[0094] Then, in step 1032, multiple entropy clusters of all canonical entropies are determined;

[0095] Finally, in step 1033, payment behavior features of the target customer when making payment operations are extracted based on all entropy clustering groups.

[0096] In specific implementation, all risk measures are standardized to obtain the normalized entropy of each risk measure. That is, each risk measure is subtracted from the mean of all risk measures, and the difference is used as the normalized entropy of the risk measure. In addition, in other embodiments, other methods can be used to determine the normalized entropy, which is not limited here. The normalized entropy can ensure the consistency of data scale, thereby simplifying the calculation operation of the payment center and improving the accuracy of risk control.

[0097] In a specific implementation, multiple entropy clustering groups of all normalized entropies can be determined by the K-means clustering algorithm. The K-means clustering algorithm is a calculation method for data processing, which will not be elaborated here. In addition, in other embodiments, other clustering algorithms can be used to determine multiple entropy clustering groups, such as hierarchical clustering, density clustering, etc., which are not limited here.

[0098] It should be noted that in this embodiment, the entropy cluster group represents a collection of different clusters formed by cluster analysis of the normative entropy. There are multiple normative entropies with similar characteristics in an entropy cluster group. By determining the entropy cluster group, different patterns and structures of normative entropy can be reflected, thereby providing support for payment decisions and risk analysis.

[0099] In specific implementation, the payment behavior features of the target customer when making a payment operation are extracted based on all entropy clusters. That is, for each entropy cluster, the cluster features corresponding to the entropy cluster are determined by all the normal entropies in the entropy cluster, and then the cluster features corresponding to each entropy cluster are obtained. All cluster features are vector transformed to obtain the payment behavior features of the target customer when making a payment operation. The cluster features represent the mean of all normal entropies in the entropy cluster.

[0100] Specifically, the NumPy component in Python can be used to perform vector transformation on all clustered features, which will not be elaborated here. In addition, in other embodiments, other methods can be used to perform vector transformation on all clustered features and then extract payment behavior features, which are not limited here.

[0101] It should be noted that, in this embodiment, the payment behavior feature is a characteristic correlation indicator used to describe the actual payment amount of the target customer when completing various payment behaviors. By determining the payment behavior feature, the payment behavior pattern of the target customer in terms of transaction amount can be effectively understood, thereby providing data support for payment risk assessment and personalized services.

[0102] In some embodiments, determining the security confidence level of a current target customer when making a payment at a payment center based on a pre-trained security assessment model and the payment behavior characteristics can be achieved in the following manner:

[0103] Collect payment information of the current target customer in the payment center;

[0104] The payment risk coefficient of the payment information is extracted based on a pre-trained security assessment model;

[0105] The security confidence level of the current target customer when making a payment at the payment center is determined based on the payment risk coefficient and the payment behavior characteristics.

[0106] In practice, the payment information of the current target customer in the payment center can be collected through the application programming interface (API) provided by the payment center. In addition, in other embodiments, other methods can be used to collect payment information, such as event-driven mechanisms, database queries, or message queues, etc., which are not limited here.

[0107] It should be noted that the payment information in this application refers to various transaction-related detailed data of the target customer when conducting transaction operations at the payment center, including but not limited to the payment initiation time and payment initiation location. By collecting payment information, the current payment behavior of the target customer can be effectively reflected, which is conducive to the payment center to conduct security monitoring, analysis and management of the target customer's current transaction activities.

[0108] In some embodiments, the payment risk coefficient of the payment information can be extracted based on a pre-trained security assessment model in the following manner:

[0109] Initialize a pre-trained security assessment model;

[0110] The transaction data of the payment information is extracted as input parameters of the security assessment model. The security assessment model is then called to perform a security assessment on the transaction data, and the assessment result is used as the payment risk coefficient.

[0111] It should be noted that the security assessment model in this application refers to a machine learning or deep learning model that has been trained using a large amount of historical transaction data, such as a random forest model. In addition, other security assessment models may be used in other embodiments, which are not limited here.

[0112] It should also be noted that the payment risk coefficient in this application represents an indicator used to quantify the degree of risk in a specific payment process. Determining the payment risk coefficient helps payment centers identify and manage potential transaction risks, thereby improving the security of the payment process.

[0113] In specific implementation, the security confidence level of the current target customer when making a payment at the payment center is determined based on the payment risk coefficient and the payment behavior characteristics. That is, the mean of all clustered features in the payment behavior characteristics is weighted and summed with the payment risk coefficient, and the sum is taken as the security confidence level of the current target customer at the payment center. The specific weights can be set according to actual application needs. For example, in this application, the weights of the mean of all clustered features in the payment behavior characteristics and the payment risk coefficient are set to 0.55 and 0.45, respectively. This is not limited here. In addition, in other embodiments, other methods can be used to determine the security confidence level. This is not limited here.

[0114] It should be noted that, in this application, the security confidence level represents an indicator for measuring and assessing the degree of risk that may be involved in the current target customer's payment operation. The higher the security confidence level, the lower the degree of risk that may be involved in the current target customer's payment operation; the lower the security confidence level, the higher the degree of risk that may be involved in the current target customer's payment operation. By determining the security confidence level, the risk of each payment by the payment center can be assessed in real time, thereby identifying potential risky behaviors immediately when a payment occurs, and thus protecting the customer's funds.

[0115] In step 104, the payment risk cost when the target customer makes a large payment is determined based on all risk payment permissions and all risk metrics.

[0116] In some embodiments, reference Figure 3 As shown, this diagram is an exemplary flowchart illustrating the determination of payment risk costs when a target customer makes a large payment, according to some embodiments of this application. In this embodiment, determining the payment risk costs when a target customer makes a large payment based on all risk payment permissions and all risk metrics can be achieved through the following steps:

[0117] First, in step 1041, the deviation adjustment amount of the payment center's payment operation under risk conditions is determined;

[0118] Then, in step 1042, the payment bias value of the target customer when completing all large payments is determined based on the deviation adjustment amount;

[0119] Then, in step 1043, the amount anomaly index of each risk payment authority is determined by the payment bias value;

[0120] Finally, in step 1044, the payment risk cost when the target customer makes a large payment is determined based on all the abnormal amount indices and all the risk measures.

[0121] In some embodiments, the deviation adjustment amount of the payment center's payment operation under risk conditions can be determined in the following manner:

[0122] The number of permissions to obtain risk payment authorization;

[0123] Set the first and second adjustment constants;

[0124] The deviation adjustment amount of the payment operation of the payment center under risk status is determined based on the number of permissions, the first adjustment constant, and the second adjustment constant.

[0125] It should be noted that the first adjustment constant and the second adjustment constant in this embodiment are two calculation constants preset based on historical experience. Their values ​​can be selected according to actual application needs, and no limitation is made here.

[0126] In specific implementation, the deviation adjustment amount of the payment operation of the payment center under risk status is determined based on the number of permissions, the first adjustment constant, and the second adjustment constant. That is: first, the number of permissions is subtracted from the first adjustment constant and the second adjustment constant respectively, and the two differences are used as the first coefficient and the second coefficient respectively. Then, the ratio of the number of permissions to the product of the first coefficient and the second coefficient is calculated, and the ratio is used as the deviation adjustment amount of the payment operation of the payment center under risk status. In addition, in other embodiments, other methods can be used to determine the deviation adjustment amount, which are not limited here.

[0127] It should be noted that in this embodiment, the deviation adjustment amount represents the adjustment range used to adjust the normality of payment operations. By determining the deviation adjustment amount, the risk control strategy of the payment center can be dynamically adjusted. In addition, in this embodiment, the first coefficient and the second coefficient are intermediate variables in the calculation process, which will not be elaborated here.

[0128] In some embodiments, the payment bias value of the target customer when completing all large payments can be determined based on the deviation adjustment amount in the following manner:

[0129] Obtain the payment amount for each risk payment permission;

[0130] The risk amount is determined based on all payment amounts;

[0131] The payment bias value of the target customer when completing all large payments is determined based on the risk amount metric and the deviation adjustment amount.

[0132] In specific implementation, the risk amount measure is determined based on all payment amounts. That is, the payment amount of each risk payment authority is subtracted from the mean of the payment amounts of all risk payment authorities. The square of each difference result is then compared with the cube of the standard deviation of all payment amounts. All the ratio results are summed up, and the summed result is used as the risk amount measure. In addition, in other embodiments, other methods can be used to determine the risk amount measure, which are not limited here.

[0133] It should be noted that, in this embodiment, the risk amount metric represents an indicator that measures the degree of deviation of the payment amount from the overall risk payment behavior under a risk state. By determining the risk amount metric, abnormal behavior and potential risks in the payment process can be effectively identified and managed, thereby ensuring the security and reliability of transactions.

[0134] In specific implementation, the payment bias value of the target customer when completing all large payments is determined based on the risk amount measurement and the deviation adjustment amount. That is, the product of the risk amount measurement and the deviation adjustment amount is used as the payment bias value of the target customer when completing all large payments. In addition, in other embodiments, other methods can be used to determine the payment bias value, which are not limited here.

[0135] It should be noted that, in this embodiment, the payment skewness value is an indicator used to measure the degree of asymmetry in the distribution of payment amounts. By determining the payment skewness value, it is helpful to understand the overall distribution of target customer payment behavior, thereby improving the management reliability of the payment center.

[0136] In specific implementation, the amount anomaly index of each risk payment permission is determined by the payment skewness value. That is, for each risk payment permission, the difference between the payment amount of the risk payment permission and the payment skewness value is used to obtain the amount anomaly index of the risk payment permission, and thus the amount anomaly index of each risk payment permission is obtained. In addition, in other embodiments, other methods can be used to determine the amount anomaly index, which is not limited here.

[0137] It should be noted that, in this application, the amount anomaly index represents the degree of deviation of the risk payment authority from the normal payment behavior in terms of payment amount when processing large-amount payments. If the amount anomaly index is positive, it means that the corresponding risk payment authority has a larger deviation from the normal payment behavior in terms of payment amount when processing large-amount payments, and has a higher risk level. If the amount anomaly index is negative, it means that the corresponding risk payment authority has a smaller deviation from the normal payment behavior in terms of payment amount when processing large-amount payments, and has a lower risk level.

[0138] In practice, the payment risk cost for a target customer making a large payment is determined based on all abnormal amount indices and all risk measures. Specifically, the mean of all abnormal amount indices and the mean of all risk measures are weighted and summed, and the sum is used as the payment risk cost for the target customer making a large payment. The specific weights can be set according to actual application needs. For example, in this application, the weights of the mean of all abnormal amount indices and the mean of all risk measures are set to 0.65 and 0.35, respectively. This is not a limitation. In addition, in other embodiments, other methods can be used to determine the payment risk cost, which is not a limitation here.

[0139] It should be noted that, in this application, the payment risk cost refers to the degree of additional risk that a target customer needs to bear when making large payments at a payment center. The higher the payment risk cost, the greater the degree of additional risk that a target customer may need to bear when making large payments at a payment center; the lower the payment risk cost, the less the degree of additional risk that a target customer may need to bear when making large payments at a payment center. By determining the payment risk cost, the risk and uncertainty of the target customer's transaction behavior can be more accurately reflected, thereby providing the payment center with a more precise risk control strategy.

[0140] In step 105, when a target customer makes a large payment at the payment center, the payment behavior permissions of the target customer are adjusted based on the payment risk cost and the security confidence level.

[0141] In some embodiments, adjusting the payment behavior of a target customer based on the payment risk cost and the security confidence level can be done in the following ways:

[0142] The transaction risk level of the current transaction is determined based on the stated payment risk cost and the stated security confidence level.

[0143] Based on the transaction risk level, the permissions for the target customer's transaction behavior in the payment center are adjusted.

[0144] In some embodiments, the transaction risk level of the current transaction behavior can be determined based on the payment risk cost and the security confidence level in the following manner:

[0145] Obtain the preset payment risk cost and preset risk security confidence level;

[0146] The payment risk cost is compared with the preset payment risk cost. If the payment risk cost is greater than the preset payment risk cost, the payment risk cost is determined to be a loss cost. If the payment risk cost is less than or equal to the preset payment risk cost, the payment risk cost is determined to be a lossless cost.

[0147] The security confidence level is compared with a preset risk security confidence level. If the security confidence level is greater than the preset risk security confidence level, the security confidence level is determined to be a risk-free confidence value. If the security confidence level is less than or equal to the preset risk security confidence level, the security confidence level is determined to be a risk confidence value.

[0148] When the payment risk cost is determined to be a lossless cost and the security confidence level is determined to be a risk-free confidence value, the transaction risk level of the current transaction behavior is determined to be a low-risk level.

[0149] When the payment risk cost is determined to be a lossless cost and the security confidence level is determined to be a risk confidence value, or when the payment risk cost is determined to be a lossy cost and the security confidence level is determined to be a risk-free confidence value, the transaction risk level of the current transaction behavior is determined to be a medium risk level.

[0150] When the payment risk cost is determined to be a lossy cost and the security confidence level is determined to be a risk confidence value, the transaction risk level of the current transaction behavior is determined to be a high-risk level.

[0151] It should be noted that the preset payment risk cost and preset risk security confidence level in this embodiment are monitoring thresholds preset by the payment center to control payment security. The specific values ​​can be set according to actual application needs, which will not be elaborated here.

[0152] In practice, if the payment risk cost is greater than the preset payment risk cost, it means that the target customer is likely to suffer a loss when making a large payment at the payment center, and the payment risk cost is determined to be a lossy cost; if the payment risk cost is less than or equal to the preset payment risk cost, it means that the target customer is unlikely to suffer a loss when making a large payment at the payment center, and the payment risk cost is determined to be a lossless cost.

[0153] In specific implementation, if the security confidence level is greater than the preset risk security confidence level, it means that the current target customer's payment operation may involve low risk, and the security confidence level is determined as a risk-free confidence value; if the security confidence level is less than or equal to the preset risk security confidence level, it means that the current target customer's payment operation may involve high risk, and the security confidence level is determined as a risk confidence value.

[0154] In some embodiments, adjusting the permissions of a target customer's transaction behavior in the payment center based on the transaction risk level can be done in the following ways:

[0155] If the current transaction risk level is low, no security permission adjustments will be made, and the transaction will continue.

[0156] If the current transaction risk level is medium risk, the target customer needs to undergo additional security permission verification. The transaction will continue after the permission verification is successful.

[0157] If the current transaction risk level is high, the detailed transaction information will be collected and uploaded to the payment center. The payment center will then issue a warning to the target customer, preventing the target customer from approving any payment permissions, and the transaction will be interrupted.

[0158] It should be noted that the additional security permission verification performed by the target customer in this embodiment refers to the payment permission authentication method provided by the payment center to manage the customer's payment security, including but not limited to SMS verification code verification, dynamic password verification, biometric identification verification, etc. In addition, in other embodiments, the additional security permission verification may also include other authentication methods, which are not limited here.

[0159] Furthermore, in another aspect of this application, in some embodiments, this application provides a payment security control system for a data platform, with reference to... Figure 4 The figure is a schematic diagram of the structure of a payment security control system for a data platform according to some embodiments of this application. The payment security control system 200 of the data platform includes: a determination module 201, a processing module 202, and an execution module 203, which are described below:

[0160] The determination module 201 in this application is mainly used to determine the multiple risk-free payment permissions and multiple risk payment permissions that the target customer can configure in the data platform payment center;

[0161] Processing module 202 in this application is mainly used to extract multiple overpayment permissions and multiple non-overpayment permissions in the risk-free state from all risk-free payment permissions based on the target customer's credit limit, and to determine the risk measurement of each overpayment permission in terms of payment amount based on all non-overpayment permissions;

[0162] The processing module 202 is also used to perform feature fusion on all risk measures to obtain the payment behavior characteristics of the target user when making a payment operation, and to determine the security confidence level of the current target customer when making a payment at the payment center based on the pre-trained security assessment model and the payment behavior characteristics.

[0163] In addition, the processing module 202 is also used to determine the payment risk cost when a target customer makes a large payment based on all risk payment permissions and all risk metrics.

[0164] The execution module 203 in this application is mainly used to adjust the permissions of the target customer's payment behavior based on the payment risk cost and the security confidence level when the target customer makes a large payment in the payment center.

[0165] In addition, this application also provides a computer device, the computer device including a memory and a processor, the memory storing code, and the processor being configured to acquire the code and execute the above-described payment security control method for the data platform.

[0166] In some embodiments, reference Figure 5The figure is a schematic diagram of the structure of a computer device implementing a payment security control method for a data middle platform according to some embodiments of this application. The payment security control method for the data middle platform in the above embodiments can... Figure 5 The computer device shown is used to implement this, and the computer device 300 includes at least one processor 301, a communication bus 302, a memory 303, and at least one communication interface 304.

[0167] The processor 301 may be a general-purpose central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more payment security control methods for controlling the execution of the data platform in this application.

[0168] The communication bus 302 can be used to transmit information between the aforementioned components.

[0169] The memory 303 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or it may be an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital versatile optical discs, Blu-ray discs, etc.), a magnetic disk or other magnetic storage device, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but is not limited thereto. The memory 303 may exist independently and be connected to the processor 301 via a communication bus 302. The memory 303 may also be integrated with the processor 301.

[0170] The memory 303 stores program code for executing the scheme of this application, and its execution is controlled by the processor 301. The processor 301 executes the program code stored in the memory 303. The program code may include one or more software modules. In the above embodiments, the determination of the payment security control method of the data platform can be implemented by the processor 301 and one or more software modules in the program code in the memory 303.

[0171] Communication interface 304 uses any transceiver-like device for communicating with other devices or communication networks, such as Ethernet, radio access network (RAN), wireless local area networks (WLAN), etc.

[0172] In a specific implementation, as one example, a computer device may include multiple processors, each of which may be a single-core (single-CPU) processor or a multi-core (multi-CPU) processor. Here, a processor may refer to one or more devices, circuits, and / or processing cores for processing data (e.g., computer program instructions).

[0173] The aforementioned computer device can be a general-purpose computer device or a special-purpose computer device. In specific implementations, the computer device can be a desktop computer, a portable computer, a network server, a handheld digital assistant (PDA), a mobile phone, a tablet computer, a wireless terminal device, a communication device, or an embedded device. This application does not limit the type of computer device.

[0174] In addition, this application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the payment security control method of the data platform described above.

[0175] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0176] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A payment security control method for a data middleware platform, characterized in that, Includes the following steps: Identify the multiple risk-free payment permissions and multiple risky payment permissions that the target customer can configure in the data platform payment center; Based on the target customer's credit limit, extract multiple overpayment permissions and multiple non-overpayment permissions under the risk-free state from all risk-free payment permissions, and then determine the risk measurement of each overpayment permission in terms of payment amount based on all non-overpayment permissions; Feature fusion is performed on all risk measures to obtain the payment behavior characteristics of the target customer when making payment operations. Based on the pre-trained security assessment model and the payment behavior characteristics, the security confidence level of the current target customer when making payment at the payment center is determined. Determine the payment risk cost when a target customer makes a large payment based on all risk payment authority and all risk metrics. When a target customer makes a large payment at the payment center, the payment behavior permissions of the target customer are adjusted based on the payment risk cost and the security confidence level.

2. The method as described in claim 1, characterized in that, Based on the target customer's credit limit, extract multiple excess payment permissions and multiple non-excess payment permissions from all risk-free payment permissions, specifically including: Obtain the credit limit of the target customer; Extract the payment amount for each risk-free payment permission; Based on the aforementioned limit and the payment amount of each risk-free payment permission, multiple excess payment permissions and multiple non-excess payment permissions are extracted from all risk-free payment permissions.

3. The method as described in claim 1, characterized in that, The risk measure for each overpayment authority in terms of payment amount is determined based on all non-overpayment authorities, specifically including: Determine the payment limit margin for target customers when they make payment operations based on all non-overpayment permissions. Set the security limit coefficient for payment operations in the payment center under risk-free conditions; Get the payment amount for each overpayment permission; The risk measure for each overpayment permission in terms of payment amount is determined based on the payment limit margin, the security limit coefficient, and the payment amount for each overpayment permission.

4. The method as described in claim 1, characterized in that, By fusing features from all risk metrics, the specific payment behavior characteristics of the target customer during payment transactions are obtained, including: Standardize all risk measures to obtain the normalized entropy of each risk measure; Identify multiple entropy clusters for all canonical entropies; Based on all entropy clustering groups, we extract the payment behavior characteristics of target customers when making payment operations.

5. The method as described in claim 1, characterized in that, Determining the security confidence level of the current target customer when making a payment at the payment center based on the pre-trained security assessment model and the payment behavior characteristics specifically includes: Collect payment information of the current target customer in the payment center; The payment risk coefficient of the payment information is extracted based on a pre-trained security assessment model; The security confidence level of the current target customer when making a payment at the payment center is determined based on the payment risk coefficient and the payment behavior characteristics.

6. The method as described in claim 1, characterized in that, Adjusting payment permissions for target customers based on the aforementioned payment risk cost and the aforementioned security confidence level specifically includes: The transaction risk level of the current transaction is determined based on the stated payment risk cost and the stated security confidence level. Based on the transaction risk level, the permissions for the target customer's transaction behavior in the payment center are adjusted.

7. The method as described in claim 1, characterized in that, The data platform is a centralized data platform.

8. A payment security control system for a data platform, characterized in that, include: The determination module is used to determine the multiple risk-free payment permissions and multiple risk payment permissions that a target customer can configure in the data platform payment center; The processing module is used to extract multiple overpayment permissions and multiple non-overpayment permissions in a risk-free state from all risk-free payment permissions based on the target customer's credit limit, and then determine the risk measurement of each overpayment permission in terms of payment amount based on all non-overpayment permissions; The processing module is also used to perform feature fusion on all risk measures to obtain the payment behavior characteristics of the target customer when making payment operations, and to determine the security confidence level of the current target customer when making payment at the payment center based on the pre-trained security assessment model and the payment behavior characteristics. The processing module is also used to determine the payment risk cost when a target customer makes a large payment based on all risk payment permissions and all risk metrics. The execution module is used to adjust the permissions of the target customer's payment behavior based on the payment risk cost and the security confidence level when the target customer makes a large payment in the payment center.

9. A computer device, characterized in that, The computer device includes a memory and a processor, the memory storing code, and the processor being configured to retrieve the code and execute the payment security control method of the data platform as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the payment security control method of the data platform as described in any one of claims 1 to 7.

Images