Platform risk control method and system

Abstract

The invention relates to the technical field of internet technology and e-commerce risk control, in particular to a platform risk control method and system. The method comprises the following steps: verifying card password information of a card buyer, and judging whether verification succeeds or not; if not, judging whether dispute information of the card buyer and the card seller is received or not; if yes, the order is used as a dispute order, historical failure order information of the card seller is calculated, and the historical failure order information comprises the number of failure orders, the proportion of the failure orders, the number of continuous failure orders and the number of monthly failure orders; comparing the historical failure order information with a preset configuration value to obtain a first target risk control condition through matching; and performing risk control operation on a card seller based on the first target risk control condition. According to the invention, historical failure order information of two transaction parties can be comprehensively analyzed, and the risk control level is improved.

Description

Technical Field

[0001] The present application relates to the field of information technology, and in particular to a platform-based risk control method and system. Background Art

[0002] In the electronic trading industry, with the popularization and development of online payment platforms, the demand for virtual card transactions between users is growing. Such virtual card transactions cover a variety of forms such as game point cards and recharge cards, providing a convenient and efficient transaction model for buyers and sellers, and also driving the development of a series of technical means to ensure transaction security. However, in the face of various fraudulent behaviors that may occur in transactions, while ensuring the user's transaction experience, how to effectively control risks has become a key issue that needs to be solved urgently, and it directly affects the platform's reputation and user satisfaction.

[0003] In order to deal with the risks in virtual card transactions, existing risk control systems usually include verifying the card buyer's card information and judging its validity. If the verification fails, it is further determined whether it is caused by the information difference between the card buyer and the card seller, and corresponding measures are taken. However, the existing system mainly relies on simple verification methods and information comparison, and fails to fully consider the seller's past transaction records and related indicators, and has limited ability to identify and handle potential fraudulent transactions. These existing methods cannot effectively deal with frequent transaction failures, lack the function of comprehensively analyzing the historical failed order information of both parties to the transaction, resulting in poor risk control results. Summary of the invention

[0004] In order to solve the problems existing in the above-mentioned related technologies, the present application provides a platform-based risk control method and system, which can comprehensively analyze the historical failed order information of both parties to the transaction and improve the level of risk control.

[0005] In the first aspect, an embodiment of the present application discloses a platform-based risk control method, which adopts the following technical card solution: A platform-based risk control method comprises: verifying the card password information of a card buyer and determining whether the verification is successful; if not, determining whether dispute information between the card buyer and the card seller is received; if so, calculating the seller's historical failed order information as a disputed order, wherein the historical failed order information includes the number of failed orders, the proportion of failed orders, the number of consecutive failed orders, and the number of monthly failed orders; comparing the historical failed order information with a preset configuration value to match a first target risk control condition; and performing risk control operations on the seller based on the first target risk control condition.

[0006] By adopting the above technical solution, it is possible to verify the card password information of the seller and the buyer and determine the verification result. When the verification fails and dispute information is received, the historical failed order information of both parties is further calculated and compared with the preset configuration value to obtain the corresponding first target risk control condition. Based on this, corresponding risk control operations are performed on both parties to the transaction, effectively improving the risk control level during the transaction process.

[0007] Optionally, the method further includes: obtaining the account information of the card seller; based on the account information, detecting the credit limit information of the card seller; determining whether the credit limit information exceeds the consumption limit; if so, performing risk control on the card seller's operation for a preset time.

[0008] By adopting the above technical solution, the account information of the card seller is obtained, and the credit limit information of the card seller is detected based on the account information to determine whether the credit limit information exceeds the consumption limit. If so, the operation of the card seller is subject to risk control for a preset time, thereby effectively preventing the risks caused by excessive operations of the card seller and improving the security of the system.

[0009] Optionally, before verifying the card password information of the card seller and determining whether the verification is successful, it also includes: based on the account information, detecting whether the account is within the validity period of risk control: if so, prohibiting the submission of the card password.

[0010] By adopting the above technical solution, it is possible to detect whether the card seller's account is within the risk control validity period before verifying the card password information, thereby prohibiting the submission of the card password when the account is within the risk control period, effectively avoiding trading behavior of risky accounts and improving transaction security.

[0011] Optionally, the account information includes the account level and card purchase type of the card seller; the credit limit information includes the submission limit for each time, the daily submission limit, the monthly submission limit and the number of unsold orders; wherein the credit limit information is obtained based on the account level and the card purchase type.

[0012] By adopting the above technical solution, the credit limit information is obtained based on the seller's account level and card purchase type, so that the seller's risk level can be assessed more accurately, so that when the credit limit information exceeds the consumption limit, the seller's operation can be timely controlled for a preset time, effectively preventing the risk from further expanding.

[0013] Optionally, the first target risk control condition is one of early warning, blacklisting, card cancellation conditions, and prohibition of withdrawal.

[0014] By adopting the above technical solution, the historical failed order information is compared with the preset configuration value, and the first target risk control condition can be obtained according to the comparison result. The condition can be one of warning for both parties, blacklisting the card seller, eliminating the remaining cards of the card seller, or prohibiting the card seller from withdrawing cash, thereby realizing different degrees of risk control operations for the card buyer and the card seller.

[0015] Optionally, it also includes: receiving feedback information on the failure of the buyer's order: detecting whether the feedback information contains preset keywords; if so, making responsibility judgments on the seller and the buyer based on the preset keywords, and matching the penalty conditions to execute the target penalty operation; if not, judging the corresponding failed order as an abnormal order, pending manual intervention.

[0016] By adopting the above technical solution, feedback information of failed orders from the card buyer is received, and it is detected whether the feedback information contains preset keywords. If so, the responsibility of the card seller and the card buyer is determined based on the preset keywords, and the penalty conditions are matched to execute the target penalty operation. If not, the corresponding failed order is determined as an abnormal order and is subject to manual intervention, thereby achieving effective management and responsibility determination of order failures and improving the accuracy and efficiency of the risk control system.

[0017] Optionally, the target penalty operation is one of prohibiting card cancellation operations, prohibiting cash withdrawals, canceling cards, and prohibiting card purchases.

[0018] By adopting the above technical solution, by detecting the preset keywords in the feedback information, determining the responsibilities of the buyer and seller based on the detection results and executing corresponding punishment operations, the platform's ability to control abnormal behaviors is effectively improved.

[0019] Optionally, it also includes: obtaining the responsible order information of the card buyer and the card seller, wherein the responsible order information includes the daily responsible order quantity, the monthly responsible order quantity, and the responsible order ratio; comparing the responsible order information with the preset configuration value to match the second target risk control condition; and performing risk control operations on the card buyer and the card seller based on the second target risk control condition.

[0020] By adopting the above-mentioned technical solution, the responsible order information of the card buyer and the card seller is obtained, and the responsible order information is compared with the preset configuration value to match the second target risk control condition. Based on the second target risk control condition, risk control operations are performed on the card buyer and the card seller, which can further refine risk control management and improve risk control accuracy and efficiency.

[0021] Optionally, it also includes: when the buyer or seller of the card is within the validity period of the second target risk control condition and meets the second target risk control condition, the two corresponding risk control times are compared to take the one with the longer risk control time as the final risk control condition for risk control.

[0022] By adopting the above technical solution, by comparing the risk control time of two risk control conditions, the one with the longer risk control time is selected as the final risk control condition to perform the risk control operation, thereby achieving effective management and precise execution of the risk control operation and ensuring the rationality and effectiveness of the risk control measures.

[0023] In the second aspect, another embodiment of the present application discloses a platform-based risk control system, which adopts the following technical card solution: A platform-based risk control system includes: a verification module for verifying the card password information of a card buyer and determining whether the verification is successful; a determination module for determining whether dispute information between the card buyer and the card seller is received if not; a calculation module for calculating historical failed order information of the card seller as a disputed order if so, wherein the historical failed order information includes the number of failed orders, the proportion of failed orders, the number of consecutive failed orders, and the number of monthly failed orders; a matching module for comparing the historical failed order information with a preset configuration value to match and obtain a first target risk control condition; and an execution module for executing risk control operations on the card seller based on the first target risk control condition.

[0024] By adopting the above technical solution, the platform-based risk control management is realized. Specifically, the card password information of the card seller is cancelled through the cancellation module and it is determined whether the cancellation is successful; if the cancellation is unsuccessful, the judgment module further determines whether the dispute information between the card buyer and the card seller is received; in the case of receiving the dispute information, the calculation module calculates the historical failed order information of the card buyer and the card seller, including the number of failed orders, the proportion of failed orders, the number of consecutive failed orders and the number of monthly failed orders; then, the matching module compares the historical failed order information with the preset configuration value to obtain the first target risk control condition; finally, the execution module performs corresponding risk control operations on the card buyer and the card seller according to the first target risk control condition. The above technical solution can effectively identify high-risk orders in transactions and take targeted measures to reduce risk control risks.

[0025] In a third aspect, another embodiment of the present application discloses an electronic device, which adopts the following technical card solution: An electronic device comprises: a memory and a processor, wherein the memory is used to store a computer program; and the processor is used to implement the steps of a platform-based risk control method as described in any one of the above items when executing the computer program.

[0026] In a fourth aspect, another embodiment of the present application discloses a computer-readable storage medium, which adopts the following technical card scheme: A computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of a platform-based risk control method as described in any one of the above items.

[0027] In summary, the present application includes at least one of the following beneficial technical effects: 1. By verifying the card seller's card secret information and judging whether the verification is successful, the failure of verification can be discovered and handled in time, thereby improving the security of transactions; 2. When the cancellation is unsuccessful, by judging whether the dispute information between the card buyer and the card seller has been received, the disputed order can be accurately managed to avoid transaction disputes; 3. Calculate the historical failed order information of the card buyer and the card seller, and compare it with the preset configuration value, which can effectively identify transaction risks and thus improve the accuracy and efficiency of the risk control system. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] Figure 1 A schematic diagram of a process flow of a platform-based risk control method disclosed in the first embodiment of the present application; Figure 2 This is another flow chart of a platform-based risk control method disclosed in the first embodiment of the present application; Figure 3 This is another flow chart of a platform-based risk control method disclosed in the first embodiment of the present application; Figure 4 It is a schematic diagram of a parameter setting interface displayed in the software platform; Figure 5 It is a schematic diagram of another parameter setting interface displayed in the software platform; Figure 6 This is a schematic diagram of the interface operated by the manual customer service displayed in the software platform; Figure 7 This is another schematic diagram of a parameter setting interface displayed in the software platform; Figure 8 A schematic diagram of the structure of a platform-based risk control system disclosed in the second embodiment; Fig. 9 This is a schematic structural diagram of an electronic device disclosed in the third embodiment.

[0029] Specific implementation card method In order to enable technicians in this field to better understand the technical card solution in this specification, the technical card solution in the embodiment of this specification will be clearly and completely described below in conjunction with the drawings in the embodiment of this specification. Obviously, the described embodiment is only a part of the embodiment of this application, not all of the embodiments.

[0030] In the description of the embodiments of the present application, words such as "for example" or "for example" are used to indicate examples, illustrations or explanations. Any embodiment or design card scheme described as "for example" or "for example" in the embodiments of the present application should not be interpreted as being more preferred or more advantageous than other embodiments or design card schemes. Specifically, the use of words such as "for example" or "for example" is intended to present related concepts in a specific card manner.

[0031] In the description of the embodiments of the present application, the meaning of the term "multiple" refers to two or more. For example, multiple systems refer to two or more systems, and multiple screen terminals refer to two or more screen terminals. In addition, the terms "first" and "second" are only used for descriptive purposes and cannot be understood as indicating or implying relative importance or implicitly indicating the indicated technical features. Thus, the features defined as "first" and "second" can explicitly or implicitly include one or more of the features. The terms "include", "comprise", "have" and their variations all mean "including but not limited to", unless otherwise specifically emphasized in other card ways.

[0032] The present application is further described in detail below in conjunction with the accompanying drawings.

[0033] [First embodiment] See also Figure 1 , the present application discloses a platform-based risk control method, comprising the following steps: S1. Verify the card secret information of the card seller and determine whether the verification is successful; The card seller, i.e. the consumer, enters the card information, i.e. the account number and password, corresponding to the card through the software platform for verification. Figure 4 As shown, the card type in this embodiment can be a commodity recharge card, a voucher, etc.

[0034] S2. If not, determine whether dispute information between the card buyer and the card seller is received; If the cancellation is unsuccessful, it means there is a problem with the card, and you may receive dispute information from both parties of the transaction, i.e. the buyer and the seller.

[0035] S3. If yes, then it is regarded as a disputed order, and the historical failed order information of the card buyer and the card seller is calculated; When receiving dispute information from both parties, the system will mark the corresponding order as a disputed order and obtain historical failed order information for the historical orders of both parties. Here, the historical failed order information includes the number of failed orders, the proportion of failed orders, the number of consecutive failed orders, and the number of monthly failed orders.

[0036] S4. Compare the historical failed order information with the preset configuration value to match and obtain the first target risk control condition; Among them, the preset configuration value corresponds to each parameter of the acquired historical failed order information and is set with a preset value. When the historical failed order information meets the preset value, the risk control condition set by the preset value is executed, and the corresponding risk control condition is also preset. The first target risk control condition can be one of a warning for both parties, blacklisting the card seller, selling the remaining cards of the card seller, and prohibiting the card seller from withdrawing cash, and is not limited to this. The warning for both parties is to warn both the buyer and the seller, blacklist the card seller to prohibit subsequent transactions, sell the remaining cards of the card seller, and cancel the remaining cards under the name of the card seller's account, and prohibit the card seller from withdrawing cash, that is, prohibit the card seller from withdrawing the balance in the account.

[0037] For example, see Figure 5 , which is the setting interface of the preset configuration value. The corresponding configurable parameters are: When the number of failed orders within 24 hours is 5, the corresponding risk control conditions include prohibition of submission (24 hours), delayed withdrawal (24 hours) and failure of remaining card return (cancellation of remaining cards). You can set one of them as a risk control condition to enable; If the number of consecutive failed orders is 5, the corresponding risk control conditions include prohibition of submission (24 hours), delayed withdrawal (24 hours) and failure of remaining card return. You can set one of them as the risk control condition to enable; If the failure rate within 24 hours is 21 / 5, the corresponding risk control conditions include prohibition of submission (24 hours), delayed withdrawal (168 hours) and failure of remaining card refund; for this explanation, "21" is the failure rate within 24 hours calculated from the 21st order, that is, this risk control will be calculated only when the total number of orders is greater than 20; "5" means that when the failure rate reaches 5%, this risk control will be triggered; The percentage of total failed orders in a month (X / Y), the corresponding risk control conditions are submission prohibition (24 hours), delayed withdrawal (24 hours) and remaining card refund failure, where X and Y are integer values; If the face value does not match the quantity within 24 hours (1), the corresponding risk control conditions include prohibition of submission (24 hours), delayed withdrawal (24 hours) and failure of remaining card return.

[0038] For further information, see Figure 2 , this embodiment also includes: S5. Obtain the account information of the card seller; Among them, the account information includes the account level of the card seller and the card purchase type. The account levels correspond to non-real-name, basic real-name, advanced real-name and enterprise real-name.

[0039] S6. Detect the credit limit information of the card seller based on the account information; There are different credit limit information for different levels of accounts and different card purchase types, so that credit limit information can be obtained based on account level and card purchase type. Credit limit information may include, but is not limited to, each submission limit, daily submission limit, monthly submission limit, and the number of unsold orders. Figure 4 The corresponding credit limit information is pre-set by the operator who sells the card.

[0040] S7, determining whether the credit limit information exceeds the consumption limit; Among them, the consumption limit is set corresponding to each parameter in the quota information, for example, the submission limit each time is 500, the daily submission limit is 3000, the monthly submission limit must be less than 10000 and the slow-moving order limit is 100.

[0041] See also Figure 4 When setting various values ​​in advance, you can check the corresponding risk control conditions. For example, when the number of unsaleable orders is 100, the corresponding risk control conditions prohibit submission.

[0042] In addition, in this embodiment, it also involves setting the number of historical abnormal orders to, for example, 3. The corresponding risk control conditions include suspension of cancellation, prohibition of submission, and prohibition of withdrawal. The corresponding transaction process includes obtaining the number of historical abnormal orders and executing corresponding risk control operations.

[0043] S8. If yes, then risk control is performed on the card seller’s operation for a preset period of time.

[0044] Among them, the preset time is, for example, 24 hours, 48 ​​hours, etc., and the card seller limits operations during this time, thereby effectively preventing the risks caused by excessive operations of the card seller and improving the security of the system.

[0045] In this embodiment, based on the risk control of step S8, the following steps are performed before step S1: S9. Based on the account information, check whether the account is within the validity period of risk control; The validity period refers to the preset time in step S8.

[0046] S10. If yes, the submission of the card code is prohibited.

[0047] In this way, through steps S9 and 10, it is possible to detect whether the seller's account is within the risk control validity period before verifying the card password information, thereby prohibiting the submission of the card password when the account is within the risk control period, effectively avoiding trading behavior of risky accounts and improving transaction security.

[0048] For further information, see Figure 3 , in this embodiment, further comprising: S11, receiving feedback information of the card buyer's order failure; Among them, the feedback information is the text feedback information provided by the card buyer on the system based on the failed order.

[0049] S12, detecting whether the feedback information contains preset keywords; Among them, preset keywords include, for example, discrepancy in face value, failure in verification, etc.

[0050] S13. If yes, based on the preset keywords, the responsibility of the card seller and the card buyer is determined, and the target penalty operation is executed according to the penalty conditions; Among them, the responsibility determination can be divided into no responsibility, the responsibility of the card seller (user), and the responsibility of the card buyer (merchant). For example, if the keyword is face value discrepancy, the pre-set responsibility determination is the responsibility of the card seller. The target penalty operation for the responsible party is one of prohibiting card verification operations, prohibiting cash withdrawals, canceling cards, and prohibiting card purchases, but is not limited to these.

[0051] S14. If not, the corresponding failed order is determined as an abnormal order and is subject to manual intervention.

[0052] If no keywords are detected, the order will be marked as abnormal and will need to wait for manual customer service to intervene, thereby achieving effective management of order failures and more accurate determination of responsibilities, and improving the accuracy of the risk control system. For the specific manual operation interface, please refer to Figure 6 , the manual customer service will check and fill in the form based on the actual situation.

[0053] Furthermore, in this embodiment, it also includes: S15, obtaining the responsible order information of the card buyer and the card seller; Among them, the responsible order information can be understood as the orders in the historical orders that have problems and are judged responsible. The responsible order information includes the number of responsible orders per day, the number of responsible orders per month, and the proportion of responsible orders.

[0054] S16. Compare the responsible order information with the preset configuration value to match and obtain the second target risk control condition; Among them, the preset configuration values ​​correspond to the thresholds of the number of responsible orders, the number of responsible orders per month, and the proportion of responsible orders.

[0055] For example, see Figure 7 , which is another setting interface for preset configuration values. The corresponding configurable parameters are: When the number of abnormal orders reaches x, the corresponding risk control condition is to suspend trading for y hours, where x and y are integer values; When the number of responsible orders of the merchant (card buyer) reaches 2, the corresponding risk control condition is to suspend transactions for 168 hours; If the number of orders for which the merchant is responsible reaches 5 within 30 days, the corresponding risk control condition is to suspend transactions for 336 hours.

[0056] In addition, in this embodiment, it also includes risk control for processing timeouts. For example, when the number of orders being processed reaches 10% within a 10-minute timeout, trading is suspended for 24 hours.

[0057] S17. Perform risk control operations on the card buyer and the card seller based on the second target risk control condition.

[0058] The second target risk control condition may be the same as the first target risk control condition, and may be one of warning to both parties, blacklisting the card seller, selling the remaining cards of the card seller, and prohibiting the card seller from withdrawing cash, but is not limited thereto. For details, please refer to the above.

[0059] It is worth mentioning that, in this embodiment, it also includes: S18. When the card buyer or the card seller is within the validity period of the second target risk control condition and meets the second target risk control condition, the two risk control times are compared to take the longer risk control time as the final risk control condition for risk control.

[0060] For example, corresponding to the above S4, and see Figure 3 , when the second target risk control condition triggered for the first time is that the number of failed orders within 24 hours is 5, the corresponding risk control condition is to delay withdrawal for 24 hours. When the second target risk control condition triggered for the second time is that the number of consecutive failed orders is 5, the corresponding risk control condition is to delay withdrawal for 168 hours. Then, 24 hours and 168 hours are compared, and the delay of withdrawal for 168 hours is used as the final risk control condition for risk control. On the contrary, if the first corresponding risk control condition is to delay withdrawal for 168 hours, and the second corresponding risk control condition is to delay withdrawal for 24 hours, the delay of withdrawal for 168 hours is still used as the final risk control condition for risk control.

[0061] In this way, for repeatedly triggered events, the most severe control measures are taken to effectively manage both parties to the transaction, while ensuring the rationality and effectiveness of risk control measures.

[0062] In addition, it is worth mentioning that if the same order of the seller has triggered a certain risk control, the order will be excluded in the subsequent risk calculation. For example, if the number of failed orders in 24 hours is 5, the seller has 5 failed orders that reach the threshold and trigger this risk control and execute it. Later, when counting the number of failed orders in the account, these 5 orders will no longer be counted in the range. In this way, repeated risk control can be avoided for the seller.

[0063] To sum up, the first embodiment of the present invention discloses a platform-based risk control method, which can promptly discover and handle the failure of verification by verifying the card password information of the card seller and judging whether the verification is successful, thereby improving the security of the transaction; when the verification is unsuccessful, by judging whether the dispute information between the card buyer and the card seller is received, the disputed orders can be accurately managed to avoid the occurrence of transaction disputes; the historical failed order information of the card buyer and the card seller is calculated and compared with the preset configuration value, which can effectively identify transaction risks, thereby improving the accuracy and efficiency of the risk control system.

[0064] [Second embodiment] In the second embodiment of the present application, a platform-based risk control system is disclosed. Figure 8 The system includes: a verification module 210, a judgment module 220, a calculation module 230, a matching module 240 and an execution module 250.

[0065] Among them, the verification module 210 is used to verify the card password information of the card seller and determine whether the verification is successful; the judgment module 220 is used to determine whether the dispute information between the card buyer and the card seller is received if not; the calculation module 230 is used to calculate the historical failed order information of the card buyer and the card seller as a disputed order if so, wherein the historical failed order information includes the number of failed orders, the proportion of failed orders, the number of consecutive failed orders and the number of monthly failed orders; the matching module 240 is used to compare the historical failed order information with the preset configuration value to match the first target risk control condition; the execution module 250 is used to perform risk control operations on the card buyer and the card seller based on the first target risk control condition.

[0066] It should be noted that the platform-based risk control method implemented by the platform-based risk control system disclosed in the second embodiment of the present application is the same as the first embodiment, so it will not be described in detail here. Optionally, each module in this embodiment and the above-mentioned other operations or functions are respectively for implementing the methods in the above-mentioned embodiments.

[0067] [Third embodiment] In the third embodiment of the present application, an electronic device is disclosed. Fig. 9, the device includes: a memory 310 and a processor 320, the memory 310 is used to store computer programs; the processor 320 is used to implement the steps of a platform-based risk control method described in the first embodiment when executing the computer program, which can be specifically referred to above, so it will not be described in detail here. The technical effect of a platform-based risk control system device provided by this embodiment in actual application is the same as the technical effect of a platform-based risk control method in the first embodiment.

[0068] [Fourth embodiment] In the fourth embodiment of the present application, a computer-readable storage medium is disclosed. The computer-readable storage medium is, for example, a non-volatile memory, such as: magnetic media (such as hard disks, floppy disks, and tapes), optical media (such as CDROM disks and DVDs), magneto-optical media (such as optical disks), and hardware devices specially constructed to store and execute computer-executable instructions (such as read-only memory (ROM), random access memory (RAM), flash memory, etc.). A computer program is stored on the computer-readable storage medium. The computer-readable storage medium can be executed by one or more processors or processing devices to implement a platform-based risk control method in the aforementioned embodiment.

[0069] In addition, it can be understood that the aforementioned embodiments are only exemplary descriptions of the present invention. Under the premise that the technical features do not conflict, the structures do not contradict, and the purpose of the present invention is not violated, the technical card solutions of the various embodiments can be arbitrarily combined and used in combination.

[0070] In the several embodiments provided by the present invention, it should be understood that the disclosed methods, systems and devices can be implemented through other card modes. For example, the modules included in the system described above are only schematic, and the division of modules is only a logical function division. There may be other division card modes in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0071] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, i.e., they may be located in one card area, or they may be distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the card solution of this embodiment.

[0072] In addition, each functional unit / module in each embodiment of the present invention may be integrated into one processing unit / module, or each unit / module may exist physically separately, or two or more units / modules may be integrated into one unit / module. The above-mentioned integrated unit / module may be implemented in the form of hardware or in the form of hardware plus software functional units / modules.

[0073] The above-mentioned integrated unit / module implemented in the form of a software functional unit / module can be stored in a computer-readable storage medium. The above-mentioned software functional unit is stored in a storage medium, including a number of instructions for enabling one or more processors of a computer device (which can be a personal computer, a server, or a network device, etc.) to perform some steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (Read-Only Memory, referred to as ROM), random access memory (Random Access Memory, referred to as RAM), disk or optical disk and other media that can store program codes.

[0074] Finally, it should be noted that the above embodiments are only used to illustrate the technical card scheme of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical card schemes described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical card schemes from the spirit and scope of the technical card schemes of the embodiments of the present invention.

Claims

1. A platform-based risk control method, characterized in that: include: Verify the card information of the seller and determine whether the verification is successful; If not, determine whether dispute information between the card buyer and the card seller is received; If yes, it is regarded as a disputed order, and the historical failed order information of the card buyer and the card seller is calculated, wherein the historical failed order information includes the number of failed orders, the proportion of failed orders, the number of consecutive failed orders, and the number of monthly failed orders; Compare the historical failed order information with the preset configuration value to match and obtain the first target risk control condition; Based on the first target risk control condition, risk control operations are performed on the card buyer and the card seller.

2. The method according to claim 1, characterized in that Also includes: Get the account information of the card seller; Based on the account information, detecting the credit limit information of the card seller; Determining whether the amount information exceeds the consumption limit; If so, the card seller’s operation will be subject to risk control for a preset period of time.

3. The method according to claim 2, characterized in that Before verifying the card seller's card secret information and determining whether the verification is successful, the process further includes: Based on the account information, check whether the account is within the validity period of risk control: If so, the submission of the card code is prohibited.

4. The method according to claim 2, characterized in that: The account information includes the card seller's account level and card purchase type; The quota information includes the submission limit for each time, the daily submission limit, the monthly submission limit and the number of unsaleable orders; The credit limit information is obtained based on the account level and the card purchase type.

5. The method according to claim 1, characterized in that The first target risk control condition is one of the following: warning both parties, blacklisting the card seller, selling the remaining cards of the card seller, and prohibiting the card seller from withdrawing cash.

6. The method according to claim 1, characterized in that Also includes: Receive feedback on failed card purchase orders: Detecting whether the feedback information contains preset keywords; If yes, based on the preset keywords, the seller and the buyer are judged responsible, and the penalty conditions are matched to execute the target penalty operation; If not, the corresponding failed order will be judged as an abnormal order and will be processed by manual intervention.

7. The method according to claim 6, characterized in that The target penalty operation is one of prohibiting card cancellation operations, prohibiting cash withdrawals, canceling cards, and prohibiting card purchases.

8. The method according to claim 1, characterized in that Also includes: Obtaining the responsible order information of the card buyer and the card seller, wherein the responsible order information includes the daily responsible order quantity, the monthly responsible order quantity, and the responsible order ratio; Comparing the responsible order information with the preset configuration value to match and obtain a second target risk control condition; Based on the second target risk control condition, risk control operations are performed on the card buyer and the card seller.

9. The method according to claim 8, characterized in that Also includes: When the buyer or seller of the card is within the validity period of the second target risk control condition and meets the second target risk control condition, the two corresponding risk control times are compared to take the longer risk control time as the final risk control condition for risk control.

10. A platform-based risk control system, characterized in that: include: The cancellation module is used to cancel the card seller's card password information and determine whether the cancellation is successful; A judgment module, for judging whether the dispute information between the card buyer and the card seller is received if no; a calculation module, configured to calculate historical failed order information of the card buyer and the card seller as disputed orders, wherein the historical failed order information includes the number of failed orders, the proportion of failed orders, the number of consecutive failed orders, and the number of monthly failed orders; A matching module, used to compare the historical failed order information with a preset configuration value to match and obtain a first target risk control condition; An execution module is used to perform risk control operations on the card buyer and the card seller based on the first target risk control condition.

Images