Fund payment method and device, storage medium and program product

Abstract

The invention discloses a fund payment method and device, a storage medium and a program product, and relates to the technical field of data processing, and the fund payment method comprises the steps that when a payment operation is detected, the payment amount corresponding to the payment operation is acquired; when the payment amount is smaller than or equal to a preset blocking threshold value and the payment amount is larger than a preset early warning threshold value, an early warning risk event is generated, and the blocking threshold value is larger than the early warning threshold value; sending the early warning risk event to a management platform, and obtaining a first judgment result which is returned by the management platform and corresponds to the early warning risk event; and when it is determined that the event is a risk event according to the first determination result, blocking the payment operation. According to the invention, the security of fund payment is improved.

Description

Technical Field

[0001] The present application relates to the field of data processing technology, and in particular to a fund payment method, device, storage medium and program product. Background Art

[0002] With the rapid development of information technology and the deepening of enterprise digital transformation, more and more companies are migrating financial management to digital platforms. However, this transformation process also brings new challenges, especially in terms of the security and accuracy of fund payments.

[0003] At present, the payment risk control systems adopted by most enterprises mainly include early warning modules, control modules, monitoring modules and reconciliation modules. These modules prevent and control duplicate payment problems by checking the duplication of payment numbers, the consistency between bank reconciliation files and actual transaction data, etc. However, the above methods are mainly aimed at the phenomenon of duplicate payments, and cannot effectively warn and intercept abnormal payment behaviors of system operators, and the security of fund payment is low.

[0004] The above contents are only used to assist in understanding the technical solution of the present application and do not constitute an admission that the above contents are prior art. Summary of the invention

[0005] The main purpose of this application is to provide a fund payment method, device, storage medium and program product, aiming to solve the technical problem of low security of fund payment.

[0006] To achieve the above purpose, the present application proposes a fund payment method, which includes:

[0007] When a payment operation is detected, obtaining a payment amount corresponding to the payment operation;

[0008] When the payment amount is less than or equal to the preset blocking threshold, and the payment amount is greater than the preset warning threshold, a warning risk event is generated, and the blocking threshold is greater than the warning threshold;

[0009] Sending the early warning risk event to a management platform, and obtaining a first determination result corresponding to the early warning risk event returned by the management platform;

[0010] When a risk event is determined according to the first determination result, the payment operation is blocked.

[0011] In one embodiment, after the step of obtaining the payment amount corresponding to the payment operation, the method further includes:

[0012] When the payment amount is greater than the blocking threshold, a blocking risk event is generated;

[0013] The blocking risk event is sent to a payment system so that the payment system terminates the payment operation.

[0014] In one embodiment, after the step of generating a blocking risk event, the method further includes:

[0015] Sending the blocking risk event to a management platform, and obtaining a second determination result corresponding to the blocking risk event returned by the management platform;

[0016] When it is determined according to the second determination result that there is no risk event, the blocking threshold is updated.

[0017] In one embodiment, the step of updating the blocking threshold comprises:

[0018] Determine a new blocking threshold value corresponding to the amount range of the payment amount according to the cumulative payment amount to the payment recipient;

[0019] The blocking threshold associated with the amount interval is updated according to the new blocking threshold.

[0020] In one embodiment, after the step of obtaining the first determination result corresponding to the warning risk event returned by the management platform, the method further includes:

[0021] When it is determined according to the first determination result that there is no risk event, the blocking threshold and the warning threshold are updated.

[0022] In one embodiment, the step of updating the blocking threshold and the warning threshold comprises:

[0023] Determine a new blocking threshold value corresponding to the amount range of the payment amount according to the accumulated payment amount to the payment recipient;

[0024] Determine a new warning threshold corresponding to the amount range of the payment amount according to the user type of the payment recipient and the cumulative payment amount to the payment recipient;

[0025] The blocking threshold is updated according to the new blocking threshold, and the warning threshold is updated according to the new warning threshold.

[0026] In one embodiment, when the payment amount is less than or equal to a preset blocking threshold and the payment amount is greater than a preset warning threshold, before the step of generating a warning risk event, the step further includes:

[0027] Determine the user type of the payment recipient and the amount range to which the payment amount belongs;

[0028] The blocking threshold associated with the amount interval is obtained, and the warning threshold associated with the user type of the payment recipient and the amount interval is obtained.

[0029] In addition, to achieve the above objectives, the present application also proposes a fund payment device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the fund payment method as described above.

[0030] In addition, to achieve the above-mentioned purpose, the present application also proposes a computer-readable storage medium, which is a computer-readable storage medium. A computer program is stored on the storage medium, and when the computer program is executed by a processor, the steps of the fund payment method as described above are implemented.

[0031] In addition, to achieve the above-mentioned purpose, the present application also proposes a computer program product, which includes a computer program, and when the computer program is executed by a processor, the steps of the fund payment method described above are implemented.

[0032] This application proposes a fund payment method, which detects payment operations and obtains payment amounts, generates warning risk events based on payment amounts and limit thresholds, and sends the warning risk events to a management platform. When the first judgment result fed back by the management platform is determined to be a risk event, the payment operation is blocked. By detecting the risks of payment operations and timely blocking payment operations when risks exist, the security of fund payment is improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] 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.

[0034] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0035] Figure 1 A flowchart of the first embodiment of the method for payment of funds for this application;

[0036] Figure 2 A schematic diagram of a fund payment system involved in a fund payment method in an embodiment of the present application;

[0037] Figure 3 A flowchart of the second embodiment of the method for payment of funds for this application is provided;

[0038] Figure 4 A flowchart of the third embodiment of the method for payment of funds for this application is provided;

[0039] Figure 5 A flowchart of the fourth embodiment of the method for payment of funds for this application is provided;

[0040] Figure 6 A schematic diagram of threshold value update rules provided for the fourth embodiment of the fund payment method of this application;

[0041] Figure 7 A flowchart of the fifth embodiment of the method for payment of funds for this application is provided;

[0042] Figure 8 This is a schematic diagram of the device structure of the hardware operating environment involved in the fund payment method in the embodiment of the present application.

[0043] The purpose, features and advantages of this application will be further described in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0044] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of the present application and are not used to limit the present application.

[0045] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0046] The main solution of the embodiment of the present application is: by detecting the payment operation and obtaining the payment amount, a warning risk event is generated according to the payment amount and the limit threshold, and the warning risk event is sent to the management platform. When the first judgment result fed back by the management platform is determined to be a risk event, the payment operation is blocked.

[0047] At present, the payment risk control system adopted by most enterprises mainly includes early warning module, control module, monitoring module and reconciliation module. These modules prevent and control the problem of duplicate payment by checking the duplication of payment numbers, the consistency between bank reconciliation files and actual transaction data, etc. However, this technical means mainly targets the phenomenon of duplicate payment, and cannot effectively warn and intercept abnormal payment behavior of system operators, and the security of fund payment is low.

[0048] This application generates different risk events based on the payment amount and the limit threshold by presetting the limit threshold, blocks abnormal payment operations based on the risk event determination results, implements early warning and intercepts abnormal payment behaviors of system operators, and improves the security of fund payments.

[0049] It should be noted that the execution subject of this embodiment can be a computing service device with data processing, network communication and program running functions, such as a tablet computer, a personal computer, a mobile phone, etc., or an electronic device capable of realizing the above functions, a fund payment device, etc. The following takes the fund payment device as an example to illustrate this embodiment and the following embodiments.

[0050] Based on this, the present application embodiment provides a method for paying funds. Figure 1 , Figure 1 This is a flow chart of the first embodiment of the fund payment method of this application.

[0051] In this embodiment, the fund payment method includes steps S10 to S40:

[0052] Step S10, when a payment operation is detected, obtaining a payment amount corresponding to the payment operation.

[0053] It should be noted that this embodiment can be applied to a third-party management system, for example, a risk control system. Figure 2 As shown, the fund distribution system at least includes a payment system such as a distribution main system, a risk control system and a management platform. The fund distribution main system is connected to the risk control system in communication, and the risk control system is connected to the management platform in communication. Among them, the distribution main system is used to receive fund distribution requests and perform actual fund transfer operations, and interact with the risk control system during the fund transfer process; the risk control system prevents and controls risks by setting limit thresholds. When the distribution system performs payment operations, the risk control system will make limit judgments and dynamically update the limit thresholds according to the judgment results of risk events; the management platform is a system for evaluating and processing risk events generated by the risk control system. Optionally, managers evaluate risk events on the management platform and feed back the evaluation results to the risk control system.

[0054] Optionally, the payment operation is a fund transfer operation of an enterprise, a transaction operation between buyers and sellers on an online trading platform, or a daily payment operation of an individual user, but is not limited to the above operations.

[0055] Optionally, the payment information corresponding to the payment operation includes the receiving account and the payment amount. Furthermore, the payment information corresponding to the payment operation also includes the user type of the receiving account, etc.

[0056] Optionally, before step S10, the method further includes: determining the user type corresponding to the payment operation according to the employment time and / or the cumulative payment amount; and determining the blocking threshold and the warning threshold according to the user type. By analyzing the employment time and / or the cumulative payment amount, the determined blocking threshold and the warning threshold can more accurately identify the risk level of different users, thereby improving the accuracy of risk control and ensuring the security of fund payment.

[0057] As a feasible solution, before step S10, it also includes: determining the user type of the payee user, and the amount range to which the payment amount belongs; obtaining the blocking threshold associated with the amount range, and obtaining the user type of the payee user and the warning threshold associated with the amount range. Among them, different amount ranges correspond to different blocking thresholds, and different user types and the same amount range have the same blocking thresholds. Different user types or different amount ranges correspond to different warning thresholds. The warning threshold is obtained through the user type and the amount range, and the blocking threshold is obtained through the amount range, so that the determined blocking threshold and warning threshold can more accurately identify the risk levels of different users, improve the accuracy of risk control, and ensure the security of fund payment.

[0058] Step S20, when the payment amount is less than or equal to a preset blocking threshold, and the payment amount is greater than a preset warning threshold, a warning risk event is generated, and the blocking threshold is greater than the warning threshold.

[0059] It should be noted that a warning risk event is an event generated when there is a payment risk. The warning risk event is used to notify the management platform to conduct further review and take appropriate response plans.

[0060] For example, when an employee requests payment of a bonus of 8,000 yuan, the payment system executes the payment operation. After the risk control system detects the payment operation, it determines that the obtained amount of 8,000 yuan is greater than the warning threshold (assuming it is 5,000 yuan) but less than the blocking threshold (assuming it is 10,000 yuan). The risk control system generates a warning risk event and immediately sends it to the management platform.

[0061] It should be noted that the blocking threshold is used to determine whether a payment operation involves risk. Optionally, when the payment amount is greater than a preset blocking threshold, it is determined that the payment operation involves risk; when the payment amount is less than the preset blocking threshold, it is necessary to further determine whether the payment operation involves risk.

[0062] Optionally, the blocking threshold may be pre-set or determined based on the user type of the paying user. Another feasible solution is to determine the blocking threshold based on the user type of the receiving user and / or the cumulative payment amount of the receiving user. Setting the blocking threshold can effectively prevent improper behavior in large-amount payments and ensure the safety of funds.

[0063] Optionally, blocking thresholds of different gradients are set according to different factors such as payment amount, employee joining time, employee's cumulative payment amount, payment time, and transaction frequency.

[0064] It should be noted that the warning threshold is used to further determine whether there is a risk in the payment operation. Optionally, when the payment amount is less than or equal to the preset warning threshold, it is determined that there is no risk in the payment operation; when the payment amount is greater than the preset warning threshold, it is necessary to further determine whether there is a risk in the payment operation.

[0065] Optionally, the warning threshold may be pre-set or determined based on the user type of the paying user. Another feasible solution is to determine the warning threshold based on the user type of the receiving user and / or the cumulative payment amount of the receiving user. The setting of the warning threshold can further identify improper behavior in payment and ensure the safety of funds.

[0066] In one embodiment, the blocking threshold and the warning threshold can also be set at multiple levels based on historical payment data analysis, user behavior patterns, market changes and other factors. Personalized settings can also be customized according to the user's own needs and risk preferences to ensure that the threshold settings are scientific and reasonable, and can flexibly adapt to the ever-changing risk environment, thereby improving the security of fund payments.

[0067] Optionally, collect and analyze the user's historical payment data, where the historical payment data includes payment frequency, payment time, payment amount, etc., and determine the user's payment type based on the historical payment data. When the payment frequency for a certain user is greater than the preset frequency, and the payment amount corresponding to the current payment operation is less than or equal to the preset amount, the user's payment type is determined to be a normal payment type, and a lower warning and blocking threshold is set. When the payment frequency for a certain user is less than or equal to the preset frequency, or the payment amount corresponding to the current payment operation is greater than the preset amount, the user's payment type is determined to be a risky payment type, and a higher warning and blocking threshold is set.

[0068] Step S30: sending the early warning risk event to a management platform, and obtaining a first determination result corresponding to the early warning risk event returned by the management platform.

[0069] It should be noted that the first determination result is the management platform evaluating the received warning risk event to determine whether the warning risk event is a risk event.

[0070] Optionally, the management platform evaluates warning risk events. Management personnel can manually check payment details, including amount, time, historical payment data, etc., or use preset business rules to apply machine learning algorithms to analyze payment data and predict whether the payment operation is risky.

[0071] Optionally, the management platform may first screen the warning events according to preset business rules, including whether the payment amount is abnormally higher than the user's average payment level, whether the payment frequency is abnormally higher than the user's regular payment operations, whether the payment operation occurs outside the user's regular activity area, etc.; then, apply machine learning algorithms such as anomaly detection algorithms to identify statistically abnormal payment operations, and based on the algorithm analysis results, screen out suspected risk events, and add the screened suspected risk events to the review queue; finally, the management personnel make judgments on the suspected risk events in the review queue.

[0072] For example, if a user initiates a transaction of 5,000 yuan on an online payment platform, which is three times the average transaction amount of the user in the past three months, the risk control system generates a warning risk event to the management platform. The management platform uses an anomaly detection algorithm to find that the transaction amount is significantly different from the user's historical transactions. The behavior analysis model predicts that the risk of the transaction is high and marks the warning risk event as a suspected risk event. The manager reviews the user's transaction records for the past three months and notices that the user has never traded at the time or place where the current transaction occurred. Based on the review results, the manager determines that the warning risk event is a risk event and generates the first determination result.

[0073] In one embodiment, the first judgment result can be fed back to the risk control system by the management platform. The specific feedback methods include but are not limited to feeding back the judgment result to the risk control system through a real-time API (Application Programming Interface), updating the event status in the database of the management platform for the risk control system to query, notifying relevant personnel of the risk control system of the result by email, SMS or in-application notification, and generating a detailed assessment report and providing it to the risk control system through a system interface or automatic distribution mechanism.

[0074] Step S40: When it is determined as a risk event according to the first determination result, the payment operation is blocked.

[0075] Optionally, if the early warning risk event is determined as a risk event by the management platform, the risk control system will control the payment system to perform a blocking operation, which is used to stop the payment process of the payment system. At the same time, the risk control system can record the detailed information of the blocking operation and feedback the operation results to the management platform.

[0076] Optionally, blocking the payment operation includes revoking the operation to restore the original state, or temporarily freezing the account that initiated the payment operation to prevent further risky payments.

[0077] In one embodiment, if Figure 2As shown in the figure, after the payment is made on behalf of others, it will first enter the risk control system, which will make a limit judgment. The blocking threshold check is performed synchronously, and the subsequent warning threshold check is performed asynchronously. If the risk control system determines that the blocking threshold is exceeded, it will directly return to the main system of the payment to terminate the payment; if the blocking threshold is not exceeded, the warning threshold check will be performed. As long as the blocking threshold or the warning threshold is exceeded, a risk event will be generated and sent to the management platform. After receiving the risk event, the management platform will have a dedicated manager to make a risk event judgment and return the judgment result to the risk control system. The risk control system receives the judgment result. If the judgment result is not a risk event, it will update the corresponding blocking threshold and warning threshold.

[0078] In the technical solution of this embodiment, by detecting the payment operation and obtaining the payment amount, a warning risk event is generated according to the payment amount and the limit threshold, and the warning risk event is sent to the management platform. When it is determined as a risk event according to the first judgment result fed back by the management platform, the payment operation is blocked. By detecting the risk of the payment operation and blocking the payment operation in time when there is a risk, the security of fund payment is improved.

[0079] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar contents as those in the above embodiment can refer to the above introduction, and will not be repeated later. Figure 3 After step S10, the fund payment method further includes:

[0080] Step S50, when the payment amount is greater than the blocking threshold, generating a blocking risk event;

[0081] Step S60: sending the blocking risk event to the payment system so that the payment system terminates the payment operation.

[0082] It should be noted that blocking risk events are events generated when there is a large payment risk, and warning risk events are used to block payment operations.

[0083] Optionally, the risk control system automatically detects the payment amount of each payment operation, and compares the detected payment amount with a preset blocking threshold. If the payment amount is greater than the blocking threshold, it means that there is a greater payment risk in the payment operation. At this time, a blocking risk event is generated, and relevant detailed information can be recorded, such as transaction account, payment amount, payment time, user information, etc.

[0084] Optionally, the risk control system will select a suitable transmission channel for the blocking risk event, such as an SSL (Secure Sockets Layer) encrypted channel, and pass it to a payment system, such as a payment system, through an API. After receiving the blocking risk event, the payment system will terminate the payment operation, or cancel the payment operation, and return confirmation information to the risk control system.

[0085] Optionally, after step S10, it also includes: when the payment amount is greater than the blocking threshold, generating a blocking risk event; sending the blocking risk event to the management platform, and obtaining a second judgment result corresponding to the blocking risk event returned by the management platform; when it is determined to be a risk event according to the second judgment result, blocking support operations; when it is determined not to be a risk event according to the second judgment result, it indicates that the blocking threshold is set incorrectly, and the blocking threshold is updated.

[0086] Optionally, the risk control system detects that the payment amount is greater than the blocking threshold, generates a blocking risk event and sends the event to the management platform, requesting further evaluation. The managers of the management platform evaluate the blocking risk event. If the payment operation is determined to be a risk event, the management platform will feed back the judgment result to the risk control system in real time. After receiving the judgment result, the risk control system immediately controls the payment system to block the payment operation.

[0087] In the technical solution of this embodiment, by comparing the payment amount with the blocking threshold, when the payment amount is greater than the blocking threshold, the payment operation is blocked in time to prevent erroneous payment of funds and improve the security of fund payment.

[0088] Based on the first or second embodiment of the present application, in the third embodiment of the present application, the same or similar contents as those in the above embodiment can be referred to the above introduction, and will not be repeated in the following. Figure 4 After step S50, the fund payment method further includes:

[0089] Step S70, sending the blocking risk event to a management platform, and obtaining a second determination result corresponding to the blocking risk event returned by the management platform;

[0090] Step S80: When it is determined according to the second determination result that there is no risk event, updating the blocking threshold.

[0091] It should be noted that the second determination result is the management platform's evaluation of the blocking risk event to determine whether the blocking risk event is a risk event. The second determination result can be fed back to the risk control system by the management platform in the same way as the first determination result, and will not be described in detail here.

[0092] Optionally, the risk control system generates a blocking risk event, records the payment details, and sends it to the management platform. The machine learning algorithm of the management platform conducts a preliminary analysis to assess whether there are abnormal patterns or risk characteristics in the blocking risk event, which is then further reviewed by management personnel, including verifying the user's payment history, checking the legitimacy and authorization of the payment request, and assessing the reputation and risk level of the user's account. After review and analysis, it is confirmed that the blocking risk event is a normal payment, but it is recommended to pay in batches to reduce risks. The management platform generates a second judgment result and feeds it back to the risk control system through the system interface. At the same time, the risk control system notifies the user that the payment request has been accepted and will be paid in batches.

[0093] In the technical solution of this embodiment, by sending the blocking risk event to the management platform for evaluation and updating the blocking threshold according to the second judgment result of the blocking risk event, the accuracy of fund payment risk judgment is further improved, and the security of fund payment is improved.

[0094] Based on any one of the first to third embodiments, the present application proposes a fourth embodiment of a fund payment method. The same or similar contents as those in the above embodiments can be referred to the above introduction and will not be described in detail later. Figure 5 , step S80 further includes:

[0095] Step S81, determining a new blocking threshold corresponding to the amount range of the payment amount according to the accumulated payment amount to the payment recipient;

[0096] Step S82: updating the blocking threshold associated with the amount interval according to the new blocking threshold.

[0097] Optionally, the accumulated payment amount is the total payment amount made by the same paying user to the receiving user corresponding to the payment operation within a preset time period. The accumulated payment amount belongs to different amount intervals, and the corresponding new blocking threshold is also different.

[0098] Optionally, a new blocking threshold is determined according to the user type of the payment recipient and the payment amount of the payment operation. Different user types and payment amounts correspond to different blocking thresholds. Optionally, when the user type is a trusted user and the payment amount is less than or equal to a preset amount threshold, the blocking threshold is a first threshold. When the user type is an untrustworthy user or the payment amount is greater than the preset amount threshold, the blocking threshold is a second threshold, wherein the second threshold is less than the first threshold.

[0099] For example, refer to Figure 6 Assuming that the amount of money paid on behalf of a person is between 00,000 and 10,000, triggering a blocking risk event, and the event is judged as a non-risk event, then the new blocking threshold for the person will be updated to 1 million, and the same applies to other amounts paid on behalf of others.

[0100] Optionally, the payment amount in the historical payment data is used for statistical analysis, such as the mean, median, standard deviation, etc., to determine the new blocking threshold. Exemplarily, the new blocking threshold is set to the mean value of the payment amount plus a preset multiple of the standard deviation. If the historical data shows that the average value of monthly salary payment is 5,000 yuan and the standard deviation is 1,000 yuan, the new blocking threshold can be set to the mean value plus 3 times the standard deviation, that is, 8,000 yuan. Statistical analysis based on actual payment data provides an objective decision-making basis, making the setting of the blocking threshold more scientific and reasonable, in order to cope with different payment modes and periodic changes, and improve the security of fund payment.

[0101] In the technical solution of this embodiment, by updating the blocking threshold for the cumulative payment amount of the receiving user, it is possible to reduce false alarms caused by improper threshold settings, improve the accuracy of fund payment risk judgment, and improve the security of fund payment.

[0102] Based on any one of the first to fourth embodiments, the present application proposes a fifth embodiment of a fund payment method. The same or similar contents as those in the above embodiments can be referred to the above introduction and will not be described in detail later. Figure 7 After step S30, the fund payment method further includes:

[0103] Step S90: When it is determined that there is no risk event according to the first determination result, the blocking threshold and the warning threshold are updated.

[0104] It should be noted that when the first determination result is determined not to be a risk event, it means that the current payment operation is risk-free, and in order to avoid the next false alarm, the blocking threshold and the warning threshold are updated. Optionally, the blocking threshold is updated according to a preset first value, and the warning threshold is updated according to a preset second value, and the preset first value is greater than the preset second value.

[0105] In a feasible implementation scheme, a new blocking threshold corresponding to the amount range of the payment amount is determined based on the cumulative payment amount to the payee user; a new warning threshold corresponding to the amount range of the payment amount is determined based on the user type of the payee user and the cumulative payment amount to the payee user; the blocking threshold is updated according to the new blocking threshold, and the warning threshold is updated according to the new warning threshold.

[0106] Optionally, the user type of the payment recipient includes the user's years of service, such as a new employee account or an old employee account. The user type includes transaction frequency, such as an active transaction account or an inactive transaction account. The user type includes historical reputation, such as a user with good historical reputation or a user with poor historical reputation.

[0107] By distinguishing user types and setting new warning thresholds, the thresholds can be adjusted in a timely manner according to the user's transaction behavior, reducing interference with normal transactions, avoiding frequent false alarms caused by too low thresholds, and improving the security of fund payments.

[0108] In a feasible implementation scheme, a new warning threshold is determined according to the user type of the payment user, the payment amount of the payment operation, and the cumulative payment amount to the payment user. Optionally, the amount interval to which the payment amount of the payment operation belongs is determined, and when the user type is a trusted user and the payment amount is less than or equal to a preset amount threshold, the blocking threshold associated with the amount interval to which the payment amount belongs is determined to be a first threshold, and when the user type is an untrustworthy user, or the payment amount is greater than the preset amount threshold, the blocking threshold associated with the amount interval to which the payment amount belongs is determined to be a second threshold, wherein the second threshold is less than the first threshold.

[0109] For example, Figure 6 Different warning thresholds are set for new and old employees according to different payment amount ranges. The warning threshold for old employees is higher than that for new employees, and the blocking thresholds for old and new employees are the same. Figure 6 The threshold update rules shown provide clear guidance for the risk control system on how to set new blocking thresholds and new warning thresholds according to different situations. Assuming that a person's agency payment amount is between 10,000 and 50,000, triggering a blocking or warning risk event, and the event is judged as a non-risk event, the new blocking threshold for the person will be updated to 1 million accordingly. If the person is a new employee, the new warning threshold will be updated to 100,000. If the person is an old employee, the new warning threshold will be updated to 250,000. The same applies to other agency payment amounts.

[0110] In the technical solution of this embodiment, if it is determined that it is not a risk event according to the first judgment result, the blocking threshold and the warning threshold are updated, which can reduce false alarms and missed alarms caused by improper threshold settings and improve the security of fund payment.

[0111] It should be noted that the above examples are only used to understand the present application and do not constitute a limitation on the payment method of the present application. More simple transformations based on this technical concept are all within the scope of protection of the present application.

[0112] The present application provides a fund payment device, such as a main system for issuing funds, and the fund payment device includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the fund payment method in the above-mentioned embodiment one.

[0113] Reference below Figure 8, which shows a schematic diagram of the structure of a fund payment device suitable for implementing the embodiment of the present application. The fund payment device in the embodiment of the present application may include but is not limited to mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 8 The fund payment device shown is merely an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0114] like Figure 8 As shown, the fund payment device may include a processing device 1001 (e.g., a central processing unit, a graphics processor, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM: Read Only Memory) 1002 or a program loaded from a storage device 1003 to a random access memory (RAM: Random Access Memory) 1004. In RAM1004, various programs and data required for the operation of the fund payment device are also stored. The processing device 1001, ROM1002, and RAM1004 are connected to each other through a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Generally, the following systems can be connected to the I / O interface 1006: an input device 1007 including, for example, a touch screen, a touch pad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; an output device 1008 including, for example, a liquid crystal display (LCD: Liquid Crystal Display), a speaker, a vibrator, etc.; a storage device 1003 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 1009. The communication device 1009 can allow the fund payment device to communicate wirelessly or wired with other devices to exchange data. Although the figure shows a fund payment device with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems can be implemented or provided alternatively.

[0115] In particular, according to the embodiments disclosed in the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication device, or installed from a storage device 1003, or installed from a ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are executed.

[0116] The fund payment device provided by the present application adopts the fund payment method in the above embodiment, which can solve the technical problem of low security of fund payment. Compared with the prior art, the beneficial effects of the fund payment device provided by the present application are the same as the beneficial effects of the fund payment method provided by the above embodiment, and other technical features in the fund payment device are the same as the features disclosed in the method of the previous embodiment, which will not be repeated here.

[0117] It should be understood that the various parts disclosed in this application can be implemented by hardware, software, firmware or a combination thereof. In the description of the above embodiments, specific features, structures, materials or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0118] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

[0119] The present application provides a computer-readable storage medium having computer-readable program instructions (ie, computer programs) stored thereon, and the computer-readable program instructions are used to execute the fund payment method in the above-mentioned embodiment.

[0120] The computer-readable storage medium provided in the present application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, systems or devices, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, system or device. The program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination of the above.

[0121] The computer-readable storage medium may be included in the funds payment device; or may exist independently without being assembled into the funds payment device.

[0122] The computer-readable storage medium carries one or more programs, and when the one or more programs are executed by the fund payment device, the fund payment device can write computer program codes for performing the operations of the present application in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as an independent software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computer (for example, through the Internet using an Internet service provider).

[0123] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present application. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0124] The modules involved in the embodiments described in this application may be implemented by software or hardware, wherein the name of the module does not constitute a limitation on the unit itself in some cases.

[0125] The readable storage medium provided in this application is a computer-readable storage medium, which stores computer-readable program instructions (i.e., computer programs) for executing the above-mentioned fund payment method, and can solve the technical problem of low security of fund payment. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as the beneficial effects of the fund payment method provided in the above-mentioned embodiment, and will not be repeated here.

[0126] The present application also provides a computer program product, including a computer program, which implements the steps of the above-mentioned fund payment method when executed by a processor.

[0127] The computer program product provided by this application can solve the technical problem of low security of fund payment. Compared with the prior art, the beneficial effects of the computer program product provided by this application are the same as the beneficial effects of the fund payment method provided by the above embodiment, which will not be repeated here.

[0128] The above descriptions are only some embodiments of the present application, and are not intended to limit the patent scope of the present application. All equivalent structural changes made using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect applications in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A fund payment method, characterized in that: The method includes: When a payment operation is detected, obtaining a payment amount corresponding to the payment operation; When the payment amount is less than or equal to the preset blocking threshold, and the payment amount is greater than the preset warning threshold, a warning risk event is generated, and the blocking threshold is greater than the warning threshold; Sending the early warning risk event to a management platform, and obtaining a first determination result corresponding to the early warning risk event returned by the management platform; When a risk event is determined according to the first determination result, the payment operation is blocked.

2. The method according to claim 1, characterized in that After the step of obtaining the payment amount corresponding to the payment operation, the method further includes: When the payment amount is greater than the blocking threshold, a blocking risk event is generated; The blocking risk event is sent to a payment system so that the payment system terminates the payment operation.

3. The method according to claim 2, characterized in that After the step of generating a blocking risk event, the method further includes: Sending the blocking risk event to a management platform, and obtaining a second determination result corresponding to the blocking risk event returned by the management platform; When it is determined according to the second determination result that there is no risk event, the blocking threshold is updated.

4. The method according to claim 3, characterized in that The step of updating the blocking threshold comprises: Determine a new blocking threshold value corresponding to the amount range of the payment amount according to the cumulative payment amount to the payment recipient; The blocking threshold associated with the amount interval is updated according to the new blocking threshold.

5. The method according to claim 1, characterized in that After the step of obtaining the first determination result corresponding to the early warning risk event returned by the management platform, the method further includes: When it is determined according to the first determination result that there is no risk event, the blocking threshold and the warning threshold are updated.

6. The method according to claim 5, characterized in that The step of updating the blocking threshold and the warning threshold comprises: Determine a new blocking threshold value corresponding to the amount range of the payment amount according to the accumulated payment amount to the payment recipient; Determine a new warning threshold corresponding to the amount range of the payment amount according to the user type of the payment recipient and the cumulative payment amount to the payment recipient; The blocking threshold is updated according to the new blocking threshold, and the warning threshold is updated according to the new warning threshold.

7. The method according to claim 1, characterized in that When the payment amount is less than or equal to the preset blocking threshold, and the payment amount is greater than the preset warning threshold, before the step of generating a warning risk event, the method further includes: Determine the user type of the payment recipient and the amount range to which the payment amount belongs; The blocking threshold associated with the amount interval is obtained, and the warning threshold associated with the user type of the payment recipient and the amount interval is obtained.

8. A fund payment device, characterized in that: The device comprises: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the fund payment method according to any one of claims 1 to 7.

9. A storage medium, characterized in that: The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, the steps of the fund payment method according to any one of claims 1 to 7 are implemented.

10. A computer program product, characterized in that The computer program product comprises a computer program, and when the computer program is executed by a processor, the steps of the fund payment method according to any one of claims 1 to 7 are implemented.

Images