Method for processing incoming payments, payment collection system and storage medium

Abstract

This specification provides an embodiment of a method for processing incoming payments, a payment collection system, and a storage medium. In the method: the payment collection system receives a target incoming payment at a first moment, performs joint risk identification on the target incoming payment and at least a portion of historical incoming payments in a buffer pool to obtain a target risk identification result, and then processes the target incoming payment based on the target risk identification result; wherein, the target risk identification result characterizes the risk probability of the target incoming payment, and the buffer pool is used to store historical incoming payments received within a historical period prior to the first moment.

Description

[0001] This application claims priority to Singapore Patent Application No. 10202500789P, filed on March 26, 2025, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This specification relates to the field of Internet technology, and in particular to a method for processing incoming payments, a payment collection system, and a storage medium. Background Technology

[0003] With the development of the globalized economy, financial transactions between individuals and businesses are becoming increasingly frequent. For payment systems, this means receiving numerous incoming payments every moment, many of which involve criminals. Payment systems need to identify the risks of each incoming payment to prevent funds corresponding to these risks (illegally transferred funds, money laundering funds, etc.) from entering the system and causing adverse effects. Therefore, accurately identifying risky incoming payments is a pressing issue that needs to be addressed.

[0004] The background information is merely information known only to the inventor and does not imply that such information had entered the public domain before the date of this application, nor does it imply that it could be considered prior art in this disclosure. Summary of the Invention

[0005] This manual provides a method for processing incoming payments, a payment system, and a storage medium that can accumulate and amplify the scattered risks of a single incoming payment, identify risk control measures that break down large transactions into smaller ones, and improve the accuracy of identifying risky incoming payments.

[0006] Firstly, this specification provides a method for processing incoming accounts, comprising: receiving a target incoming account, wherein the time of receipt of the target incoming account is a first time; performing joint risk identification on the target incoming account and at least a portion of historical incoming accounts in a buffer pool to obtain a target risk identification result, wherein the target risk identification result characterizes the risk probability of the target incoming account, and the buffer pool is used to store historical incoming accounts received within a historical period prior to the first time; and processing the target incoming account based on the target risk identification result.

[0007] Secondly, this specification also provides a payment collection system, comprising: at least one storage medium storing at least one instruction set for processing incoming payments; and at least one processor communicatively connected to the at least one storage medium, wherein the at least one processor reads the at least one instruction set during operation and, according to the instructions of the at least one instruction set, receives a target incoming payment, the time of receipt of the target incoming payment being a first time moment; performs joint risk identification on the target incoming payment and at least a portion of historical incoming payments in a buffer pool to obtain a target risk identification result, the target risk identification result representing the risk probability of the target incoming payment; the buffer pool is used to store historical incoming payments received within a historical period prior to the first time moment; and processes the target incoming payment based on the target risk identification result.

[0008] Thirdly, this specification provides a computer-readable non-transitory storage medium, wherein the computer-readable non-transitory storage medium stores at least one instruction set, which, when executed by at least one processor, implements the incoming account processing method as described in the first aspect.

[0009] Other functions of the incoming payment processing methods, payment collection system, and storage media provided in this specification will be partially listed in the following description. The inventive aspects of the incoming payment processing methods, payment collection system, and storage media provided in this specification can be fully explained by practice or by using the methods, apparatus, and combinations described in the detailed examples below. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in the embodiments of this specification, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 A schematic diagram of an application scenario for processing incoming bills, provided according to an embodiment of this specification, is shown. Figure 2 A hardware structure diagram of a payment system provided according to an embodiment of this specification is shown; Figure 3 A flowchart of an incoming bill processing method provided according to an embodiment of this specification is shown; Figure 4 A schematic diagram illustrating the determination of target risk identification results according to an embodiment of this specification is shown; Figure 5 Another schematic diagram illustrating the determination of target risk identification results provided according to an embodiment of this specification is shown; Figure 6 Another schematic diagram illustrating the determination of target risk identification results according to embodiments of this specification is shown; and Figure 7 A schematic diagram illustrating the processing of a target invoice is shown according to an embodiment of this specification. Detailed Implementation

[0012] The following description provides specific application scenarios and requirements for this specification, intended to enable those skilled in the art to make and use the contents of this specification. Various partial modifications to the disclosed embodiments will be apparent to those skilled in the art, and the general principles defined herein can be applied to other embodiments and applications without departing from the spirit and scope of this specification. Therefore, this specification is not limited to the embodiments shown, but rather to the widest scope consistent with the claims.

[0013] The terminology used herein is for the purpose of describing particular exemplary embodiments only and is not restrictive. For example, unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “the” used herein may also include the plural forms. When used in this specification, the terms “comprising,” “including,” and / or “containing” mean that the associated integers, steps, operations, elements, and / or components are present, but do not exclude the presence of one or more other features, integers, steps, operations, elements, components, and / or groups, or that other features, integers, steps, operations, elements, components, and / or groups may be added to the system / method.

[0014] Considering the following description, these and other features of this specification, as well as the operation and function of the related components of the structure, and the economy of assembly and manufacture of the parts, can be significantly improved. All of these form part of this specification with reference to the accompanying drawings. However, it should be clearly understood that the drawings are for illustrative and descriptive purposes only and are not intended to limit the scope of this specification. It should also be understood that the drawings are not drawn to scale.

[0015] The flowcharts used in this specification illustrate operations implemented according to some embodiments of this specification. It should be clearly understood that the operations in the flowcharts may not be implemented in a sequential order. Instead, the operations may be implemented in reverse order or simultaneously. Furthermore, one or more additional operations may be added to the flowcharts. One or more operations may be removed from the flowcharts.

[0016] Before describing the embodiments of this specification, the terminology used in this specification will be introduced.

[0017] Incoming payment refers to a transfer or payment from a source account to a destination account. This term is understood from the merchant's or payment system's perspective. The source account is the payer's account, and the destination account is the payee's account. For the payment system, incoming payment can refer to a message received from the payment institution (e.g., a bank, e-wallet) to which the source account belongs. Incoming payment messages may include accounting request messages or payment messages. These messages can include the source account, amount, and destination account. The payment system can process transactions based on the incoming payment message, such as adding funds corresponding to the message to the destination account. Incoming payment can originate from, for example, a transaction payment, or other sources. The following explanation primarily uses transaction payments as an example, but this specification is not limited to this.

[0018] Normally, the payment system will perform risk identification on each incoming payment.

[0019] For example, after receiving an incoming payment, the payment system obtains the information about the incoming payment and the corresponding transaction information, and determines the risk identification result of the incoming payment based on the information about the incoming payment and the transaction information. The information about the incoming payment includes the source account, amount, and destination account. Transaction information includes, but is not limited to, the transaction participants (seller and buyer), the goods traded, the transaction time, and the transaction address.

[0020] If the risk probability represented by the risk identification result is greater than the risk threshold, the payment system determines that the incoming payment is risky and returns the corresponding amount to the source account. Alternatively, if the risk probability represented by the risk identification result is less than or equal to the risk threshold, the payment system determines that the incoming payment is not risky and transfers the corresponding amount to the destination account. Transferring to the destination account can be understood as the payment system adding the amount corresponding to the incoming payment to the destination account, thus increasing the balance of the destination account. Subsequent references to "transfer to the destination account" will be interpreted in the same way and will not be elaborated further.

[0021] In practical applications, some criminals may deliberately split a large sum of money into multiple smaller sums to evade risk control. The risk identification methods described above for single transactions tend to classify transactions with relatively low risk probabilities as risk-free by applying a risk threshold. Therefore, when criminals split large sums of money into multiple smaller sums, the payment system struggles to identify the risk from the information in individual transactions, resulting in low accuracy in risk identification.

[0022] In view of this, this specification provides a method for processing incoming payments, a payment collection system, and a storage medium. By jointly identifying the risks of multiple incoming payments, the fragmented risks of a single incoming payment can be accumulated and amplified, thereby improving the accuracy of risk identification.

[0023] The following is combined Figure 1 This manual introduces the application scenarios for processing incoming payments.

[0024] Figure 1 A schematic diagram illustrating an application scenario for processing incoming payments according to an embodiment of this specification is shown. Figure 1 As shown, scenario 001 may include: transaction system 100, payment system 300, first wallet system 410 and second wallet system 420.

[0025] The transaction system 100 includes users 110 and merchants 120. Users 110 and merchants 120 can engage in transactions and initiate payment requests for those transactions. Payment requests can be triggered by either user 110 or merchant 120. Transactions between users 110 and merchants 120 can be offline or online; this specification does not impose any limitations on this.

[0026] Taking online transactions as an example, user 110 can execute related events through a terminal device. For instance, the terminal device may have one or more service platform clients installed, which provide user 110 with the ability to execute related events. These service platforms include, but are not limited to: web browser platforms, search platforms, chat platforms, shopping platforms, service platforms, video platforms, financial management platforms, and payment platforms.

[0027] In some embodiments, the terminal device displays a transaction interface provided by merchant 120 to user 110. User 110 initiates a payment operation on the transaction interface and specifies that the payment will be completed through the source account (user 110's payment account) in the first wallet system 410. After user 110 initiates the payment operation, merchant 120 generates a payment request for the transaction and sends it to the collection system 300. The collection system 300 provides collection services to merchant 120. Specifically, the collection system 300 can receive and process the payment request initiated by user 110 and forward the payment request to the corresponding wallet system based on the payment method / payment channel specified by the payment request 110. For example, the collection system 300 can provide a front-end payment port (such as a payment page that displays one or more optional payment methods / payment channels to the user) to the merchant. User 110 can select a payment method in the front-end payment port. Suppose user 110 selects payment method A for payment. After receiving the payment request, the collection system 300 can forward the payment request to the first wallet system 410 corresponding to payment method A. After receiving the payment request, the first wallet system 410 can identify the source account of user 110 and perform accounting processing on the source account (such as reducing the balance of the source account). After accounting processing, it sends a payment confirmation to the receiving system 300. Upon receiving the payment confirmation, the receiving system 300 receives an incoming payment, which originates from the source account to the merchant 120's account (hereinafter referred to as the destination account, which may be an account applied for or registered by merchant 120 in the second wallet system 420). The receiving system 300 can process the incoming payment accordingly. For example, the receiving system 300 can transfer the amount corresponding to the incoming payment to the merchant 120's destination account, or if the receiving system 300 determines that the incoming payment is risky, it can return the amount corresponding to the incoming payment to the source account. Alternatively, the receiving system 300 can perform other processing on the incoming payment, as described in method P100 below, which will not be elaborated here.

[0028] It is understood that the first wallet system 410 can be a wallet system within the receiving system 300, or a wallet system cooperating with the receiving system 300. The second wallet system 420 can be a wallet system within the receiving system 300, or a wallet system cooperating with the receiving system 300. The first wallet system 410 and the second wallet system 420 can be the same wallet system or different wallet systems. This specification does not impose any limitations on the above. Furthermore, the wallet systems (first wallet system 410, second wallet system 420) described in this specification generally refer to systems used for storing and managing user assets. A wallet system can provide users with asset services such as payment, transfer, top-up, and withdrawal. A wallet system can be an electronic wallet or digital wallet, or it can be a banking system corresponding to the issuing bank.

[0029] It can also be understood that the payments received by the payment system 300 can be received in real time as the transaction is completed, or periodically. For example, after a transaction is completed, the payment system 300 can receive the payments in real time; or, after a preset period, the payment system 300 can receive payments for multiple transactions generated within that period all at once. This manual does not impose any restrictions on this.

[0030] In some embodiments, the payment system 300 can execute the payment processing method described herein. The payment system 300 may store data and instructions for implementing the payment processing method, and may execute or be used to execute said data and instructions. In some embodiments, the payment system 300 may include hardware devices with data processing capabilities and the necessary programs required to drive the hardware devices.

[0031] For example, the payment system 300 receives the target payment at the first moment, performs joint risk identification on the target payment and at least a portion of historical payments in the buffer pool to obtain the target risk identification result, and processes the target payment based on the target risk identification result. Here, the target risk identification result represents the risk probability of the target payment, and the buffer pool is used to store historical payments received within the historical period prior to the first moment. Details are described in detail in method P100 and will not be repeated here.

[0032] It should be noted that the payment system 300 can correspond to a single device or a cluster of devices; this specification does not impose any restrictions on this. When the payment system 300 corresponds to a single device (e.g., the server of the payment system), the incoming payment processing method can be executed entirely on that device. When the payment system 300 corresponds to a cluster of devices, the incoming payment processing method can be executed on multiple devices corresponding to the cluster, or the incoming payment processing method may have other execution methods; this specification does not impose any restrictions on this.

[0033] Figure 2 A hardware structure diagram of a payment system 300 provided according to an embodiment of this specification is shown.

[0034] like Figure 2 As shown, the payment system 300 may include at least one storage medium 330 and at least one processor 320. In some embodiments, the payment system 300 may also include a communication port 350 and an internal communication bus 310. Furthermore, the payment system 300 may also include I / O components 360.

[0035] The internal communication bus 310 can connect to different system components. For example, the internal communication bus 310 can connect to storage medium 330, processor 320, communication port 350, and I / O component 360.

[0036] I / O component 360 supports input / output between the payment system 300 and other components.

[0037] Communication port 350 is used for data communication between the payment system 300 and external sources. For example, communication port 350 can be used for data communication between the payment system 300 and a network. Communication port 350 can be a wired communication port or a wireless communication port.

[0038] In some embodiments, the network can be any type of wired or wireless network, or a combination thereof. For example, the network may include a cable network, a wired network, a fiber optic network, a telecommunications network, an intranet, the Internet, a local area network (LAN), a wide area network (WAN), a wireless local area network (WLAN), a metropolitan area network (MAN), a public switched telephone network (PSTN), a Bluetooth network™, a ZigBee™ short-range wireless network, a near field communication (NFC) network, or a similar network.

[0039] In some embodiments, the network may include one or more network access points. For example, the network may include wired or wireless network access points, such as base stations or internet switching points. Through these access points, one or more components of various devices corresponding to the payment system 300 can connect to the network to exchange data or information.

[0040] Storage medium 330 may include a data storage device. The data storage device may be a non-transitory storage medium or a temporary storage medium. For example, the data storage device may include one or more of a disk 332, a read-only storage medium (ROM) 334, or a random access storage medium (RAM) 336. Storage medium 330 also includes at least one instruction set stored in the data storage device. The instruction set may include computer program code, which may include programs, routines, objects, components, data structures, procedures, modules, etc., that execute the account processing methods provided in this specification.

[0041] Processor 320 can be communicatively connected to storage medium 330. Processor 320 is used to execute at least one of the above-described instruction sets. When the payment system 300 is running, processor 320 reads the at least one instruction set and executes the incoming payment processing method provided in this specification according to the instructions of the at least one instruction set.

[0042] Processor 320 may be in the form of one or more processors. In some embodiments, processor 320 may include one or more hardware processors, such as microcontrollers, microprocessors, reduced instruction set computers (RISC), application-specific integrated circuits (ASICs), application-specific instruction set processors (ASIPs), central processing units (CPUs), graphics processing units (GPUs), physical processing units (PPUs), microcontroller units, digital signal processors (DSPs), field-programmable gate arrays (FPGAs), advanced RISC machines (ARMs), programmable logic devices (PLDs), any circuit or processor capable of performing one or more functions, or any combination thereof.

[0043] For illustrative purposes only, only one processor 320 is shown in the accompanying drawings of the payment system 300. However, it should be noted that the payment system 300 may also include multiple processors. Therefore, the operational and / or method steps disclosed herein may be executed by a single processor as described herein, or they may be executed jointly by multiple processors. For example, if processor 320 of the payment system 300 in this specification executes steps A and B, it should be understood that steps A and B may also be executed jointly or separately by two different processors 320 (e.g., a first processor executes step A, a second processor executes step B, or the first and second processors jointly execute steps A and B).

[0044] Figure 3 A flowchart of an incoming payment processing method P100 according to an embodiment of this specification is shown. As previously described, the payment system 300 can execute the incoming payment processing method P100. Specifically, the processor 320 in the payment system 300 can read an instruction set stored in its local storage medium and then execute the incoming payment processing method P100 according to the instructions in the instruction set.

[0045] like Figure 3 As shown, the incoming payment processing method P100 may include the following steps.

[0046] S110: Receive the incoming payment from the target, and the moment the incoming payment is received is the first moment.

[0047] The target payment can be one or more payments. The payment system 300 can execute method P100 on each payment simultaneously or sequentially. The following text uses the target payment as a single payment to describe the processing process of the payment system 300 for the target payment. The processing process for other payments is similar and will not be repeated.

[0048] For example, a target payment is a payment made by a user using a primary source account to the counterparty (e.g., a merchant) for a target transaction. After successful payment by the user, combined with... Figure 1The payment system can receive incoming payments. Incoming payments include a primary source account, the amount, and a primary destination account. The primary source account is the account from which the user makes the payment; the amount is the payment amount; and the primary destination account is the receiving account of the counterparty.

[0049] S120: Perform joint risk identification on the target incoming call and at least a portion of the historical incoming calls in the buffer pool to obtain the target risk identification result. The target risk identification result characterizes the risk probability of the target incoming call. The buffer pool is used to store historical incoming calls received within the historical time period prior to the first moment.

[0050] Joint risk identification can be understood as risk identification for multiple incoming payments. Target risk identification result can be understood as the result obtained by the payment system 300 during the risk identification process for a target incoming payment, after considering the joint risk identification of the target incoming payment and historical incoming payments. It should be noted that the target risk identification result can also be obtained by referring to other risk identification results based on the result obtained from joint risk identification; this specification does not impose any restrictions on this.

[0051] The risk probability of a target payment is used to describe the likelihood that a target payment is a risky payment, or to describe the severity of the risk associated with the target payment. From the perspective of the target payment, the buffer pool stores historical payments received by the payment system 300 within the historical time period prior to the first moment. However, from the perspective of the buffer pool, it can store payments received by the payment system 300 at any given moment.

[0052] The payment system 300 can obtain the target risk identification results in a variety of ways. Two of these methods are illustrated below.

[0053] Method 1 like Figure 4 As shown, the payment system 300 performs joint risk identification on the target incoming payment and at least a portion of the historical incoming payments selected from the buffer pool to obtain the joint risk identification result P. C Joint risk identification results P C That is, the target risk identification result.

[0054] For example, each time the payment system 300 receives a new payment, it adds the new payment to a buffer pool and stores the corresponding amount in a transition account of the payment system 300. When the new payment is added to the buffer pool, it triggers a joint risk identification of the new payment and historical payments. A transition account is an account used by the payment system 300 to temporarily hold funds. These funds will be transferred to the destination account or returned to the source account in the short term. The payment system 300 may have one transition account, or each destination account may correspond to one transition account. The following description uses one transition account per destination account as an example, but this specification is not limited to this.

[0055] For example, in chronological order, if the payment system 300 receives payment 1 at time #1, and payment 1 is a payment from source account S1 to destination account D1, then the payment system 300 will temporarily store the amount corresponding to payment 1 in the transition account corresponding to destination account D1. If the payment system 300 receives payment 2 at time #2, and payment 2 is a payment from source account S2 to destination account D2, then the payment system 300 will temporarily store the amount corresponding to payment 2 in the transition account corresponding to destination account D2.

[0056] For example, when the payment system 300 receives a new payment, it may not put it into the buffer pool immediately, but instead trigger a joint risk identification of the new payment and the historical payments in the buffer pool.

[0057] The following section uses the target inflow as an example to introduce the joint risk identification process. The joint risk identification of other inflows is similar and will not be repeated here.

[0058] In some embodiments, such as Figure 5 As shown, the payment system 300 determines N1 sets of historical payment receipts from the buffer pool, each set containing at least one historical payment receipt. These N1 sets of historical payment receipts are correlated with the target payment receipt across different risk dimensions, where N1 is an integer greater than or equal to 1.

[0059] In this embodiment, the risk dimension can also be understood as the correlation dimension. The payment system 300 can aggregate historical payments with similarities from multiple risk dimensions into a historical payment set, so that the subsequent payment system 300 can accumulate and amplify the fragmented risks of the target payment from multiple risk dimensions, thereby improving the accuracy of identifying the target payment.

[0060] For example, the payment system 300 determines N1 risk dimensions corresponding to the target payment based on the information of the target payment. The information of the target payment includes at least one of the following: a first source account and a first destination account. The payment system 300 can determine three risk dimensions based on the information of the target payment: the destination account dimension, the source account dimension, and the destination account and source account dimension. Then, for each risk dimension, it selects historical payments associated with the target payment in the buffer pool to form a historical payment set.

[0061] For example, the payment system 300 selects historical incoming payments from the buffer pool for the same destination account as the target incoming payment to form a historical incoming payment set G1 for the destination account dimension; selects historical incoming payments from the buffer pool for the same source account as the target incoming payment to form a historical incoming payment set G2 for the source account dimension; and selects historical incoming payments from the buffer pool for the same source account and the same destination account as the target incoming payment to form a historical incoming payment set G3 for both the destination account and the source account dimension.

[0062] In some embodiments, such as Figure 5 As shown, after the payment system 300 determines N1 sets of historical incoming payments, it performs joint risk identification on the target incoming payment and the N1 sets of historical incoming payments to obtain N1 intermediate risk identification results.

[0063] For example, such as Figure 5 As shown, for each set of historical inflows, the payment system 300 determines the inflow characteristics based on the target inflow and the set of historical inflows, and inputs the inflow characteristics into the joint risk identification model corresponding to the target risk dimension. The joint risk identification model then performs joint risk identification on the target inflow and the set of historical inflows to obtain the intermediate risk identification result corresponding to the target risk dimension. The target risk dimension is the risk dimension corresponding to the set of historical inflows, meaning that the target inflow and the historical inflows in the set are correlated in terms of the target risk dimension.

[0064] In this example, the payment system 300 can determine some characteristics of incoming payments from the relevant information of a single incoming payment, or from the related information of multiple incoming payments. Therefore, the risk profile of the target incoming payment is more accurate and comprehensive, providing a basis for accurately identifying the target incoming payment.

[0065] Taking historical payment collection set G1 as an example, this article introduces the process by which the payment system 300 performs joint risk identification on the target payment collection set G1 and the historical payment collection set G1 to obtain the intermediate risk identification result #1. The joint risk identification process for the target payment collection set and other historical payment collection sets is similar and will not be repeated here.

[0066] The historical inflow set G1 includes historical inflow 1 and historical inflow 2. The destination accounts corresponding to historical inflow 1 and historical inflow 2 are both primary destination accounts. That is, the historical inflows in the historical inflow set G1 are related to the target inflows in terms of destination accounts.

[0067] For example, the invoice feature F1 corresponding to the target invoice and the historical invoice set G1 is obtained based on at least one of the following: Transaction information for the target inflow, historical inflow 1, and historical inflow 2, respectively; External information obtained from external data sources based on the target incoming payment, historical incoming payment 1, and historical incoming payment 2, where the external data source is a data source outside the payment system 300; and Based on the target incoming payment, historical incoming payment 1, and historical incoming payment 2, the internal information obtained by searching the internal data source is the data source inside the payment system 300.

[0068] In this example, the features of incoming payments are obtained through multiple means, which avoids the problem of bias in the characterization of target incoming payments and related historical incoming payments caused by a single method of obtaining features. It also avoids the information limitation problem of obtaining features of incoming payments from only the relevant information of a single incoming payment. This makes the features of incoming payments provide a relatively comprehensive characterization of target incoming payments and related historical incoming payments, thereby improving the accuracy of identifying target incoming payments and related historical incoming payments.

[0069] The above information is illustrated below using the target account as an example. The information corresponding to the relevant historical accounts (historical account 1 and historical account 2) is similar and will not be repeated here.

[0070] Specifically, the transaction information corresponding to the target transaction includes, but is not limited to: transaction participants (such as the payer and the payee), transaction goods, transaction time, and transaction address.

[0071] Internal information obtained from internal data sources based on the target payment includes, but is not limited to: the reporting information of the first source account and / or the first destination account in the payment system, the historical risk control information of the first source account and / or the first destination account, and a list of risky payment accounts.

[0072] External information obtained from external data sources based on the target payment includes, but is not limited to: information about the payment institution (e.g., a bank) corresponding to the first source account, regional information (country or region) corresponding to the first destination account, and business registration information corresponding to the first destination account (if the first destination account is a corporate account). Alternatively, information that the payment system 300 cannot retrieve from internal data sources can be supplemented by external data sources. It is understood that the external data sources can be one or more, and this specification does not impose any restrictions on this.

[0073] See also Figure 5 After receiving the incoming payment feature F1, the payment system 300 inputs the incoming payment feature F1 into the joint risk identification model U1 corresponding to the destination account dimension to obtain the intermediate risk identification result #1. The joint risk identification model corresponding to the destination account dimension can be one or more; this specification does not impose any restrictions on this.

[0074] For example, when there is only one joint risk identification model corresponding to the target account dimension, the intermediate risk identification result #1 is determined based on the output of this single joint risk identification model. When there are multiple joint risk identification models corresponding to the target account dimension, the intermediate risk identification result #1 is determined based on the outputs of multiple joint risk identification models and the weights corresponding to each of the multiple joint risk identification models.

[0075] It is understandable that for different sets of historical accounts receivable, the target risk dimensions are different, and the joint risk identification models corresponding to the target risk dimensions, as well as the number of joint risk identification models, can also be different. This manual does not provide examples for each one.

[0076] See also Figure 5 After the payment system 300 determines N1 intermediate risk identification results in the manner described above, it can determine the joint risk identification result P based on the N1 intermediate risk identification results. C Joint risk identification results P C That is, the target risk identification result.

[0077] For example, the payment system 300 can determine P based on N1 intermediate risk identification results and the weights corresponding to each of the N1 intermediate risk identification results. C .

[0078] Method 2 like Figure 6 As shown, the payment system 300 performs joint risk identification on the target incoming payment and at least a portion of the historical incoming payments selected from the buffer pool to obtain the joint risk identification result P. C And obtain the independent risk identification result P corresponding to the target inflow. D The independent risk identification result is obtained by independently identifying the risks of the target inbound payments. The 300 payment system is based on P... C and P D The target risk identification results are obtained.

[0079] It should be noted that P DRisk identification can be based on a single independent risk identification of the target inflow, or it can be based on multiple independent risk identifications of the target inflow. In the case of multiple identifications, these independent risk identifications can be discontinuous. For example, an independent risk identification can be performed once before joint risk identification of the target inflow, and then again after joint risk identification. This specification does not impose any restrictions on this. In a scheme involving multiple independent risk identifications, the independent risk identification model used in the later independent risk identification process can be an optimized model, resulting in more accurate output.

[0080] In Method 2, the buffer pool can be understood as a feature set up by the payment system 300 to delay the processing of each individually identified risky inflow, used to store a portion of the risky inflows after independent risk identification. Thus, the payment system 300 can identify the associated risks between multiple risky inflows based on the buffer pool, accumulating and amplifying the scattered risks of these inflows, preventing the corresponding amounts from entering the destination account.

[0081] In other words, the 300 payment system does not perform joint risk identification on all incoming payments indiscriminately. Instead, it only performs joint risk identification on payments that have been identified as having a certain level of risk after independent risk identification. This allows the 300 payment system to quickly process payments that have not been identified as having any risk after independent risk identification, as well as payments with excessive risk, thereby improving the efficiency of payment processing and enhancing the user experience for the payee.

[0082] For example, the payment system 300 receives a target payment and performs independent risk identification on it. This might involve the payment system 300 obtaining information about the target payment and the transaction information of the corresponding target transaction. The target payment information includes, but is not limited to, the first source account, the amount, and the first destination account. The transaction information includes, but is not limited to, the transaction participants (e.g., the payer and the payee), the traded goods, the transaction time, and the transaction address. The payment system 300 can determine the independent risk identification result of the target payment based on the target payment information and the transaction information.

[0083] For example, the payment system 300 can input the target incoming payment information and the transaction information into an independent risk identification model to obtain the independent risk identification result. The independent risk identification model can be pre-trained to identify the risk of a single incoming payment. The payment system 300 can determine the independent risk probability of the target incoming payment based on the independent risk identification result. The independent risk identification result may include the independent risk probability of the target incoming payment; or, the independent risk identification result may also include one or more risk tags corresponding to the target incoming payment, and the risk probability corresponding to each risk tag; or, the independent risk identification result may include the independent risk probability, one or more risk tags corresponding to the target incoming payment, and the risk probability corresponding to each risk tag.

[0084] The risk labels include, but are not limited to: fraud risk, money laundering risk, compliance risk, restricted sales risk, fraud risk, receiving account risk, payment account risk, card and account theft risk, default risk, and transaction authenticity risk.

[0085] It is understandable that the payment system 300 can determine the independent risk probability of the target payment based on the risk probability corresponding to each risk label and their respective weights.

[0086] It is understandable that after receiving each payment, the 300 payment system can temporarily store the corresponding amount in its public account and perform independent risk identification for each payment to obtain an independent risk identification result. The public account can be understood as an internal account of the 300 payment system used to handle financial matters, and is not open to external individual or corporate users.

[0087] The following example uses a target payment to illustrate how the payment system handles target payments after independent risk identification.

[0088] In some embodiments, after receiving a target payment, the payment system 300 performs independent risk identification on the target payment to obtain an independent risk identification result, and processes the amount corresponding to the target payment based on the risk level represented by the independent risk identification result.

[0089] For example, such as Figure 7 As shown, the payment system 300 determines whether the target inflow is risky based on the risk level represented by the independent risk identification result. If no risk is identified, the payment system 300 can transfer the amount corresponding to the target inflow from the public account to the primary destination account; if risk is identified, the payment system 300 determines whether the risk level represented by the independent risk identification result is a preset level. If it is a preset level, the payment system 300 can deposit the target inflow into a buffer pool and transfer the amount corresponding to the target inflow from the public account to the transition account corresponding to the primary destination account; if it is not a preset level, the payment system 300 returns the amount corresponding to the target inflow from the public account to the primary source account. Alternatively, the payment system 300 may also have... Figure 7 Other similar judgment sequences are not listed in this instruction manual.

[0090] Specifically, if the independent risk probability corresponding to the target payment is less than threshold T1, the payment system 300 determines that the target payment is risk-free; or, if the independent risk probability corresponding to the target payment is greater than threshold T2, the payment system 300 determines that the target payment is not of the preset level, which can also be understood as the target payment having too high a risk, or the target payment being a high-risk payment; or, if the independent risk probability corresponding to the target payment is greater than or equal to threshold T1 and less than or equal to threshold T2, the payment system 300 determines that the target payment is of the preset level, which can be understood as a medium-to-low risk level. Here, threshold T2 is greater than threshold T1.

[0091] In some embodiments, when the risk level represented by the independent risk identification result of the target invoice is a preset level, or when the payment system 300 determines that the target invoice should be stored in the buffer pool based on the independent risk identification result, it may trigger joint risk identification of the target invoice and at least some historical invoices in the buffer pool to obtain the target risk identification result.

[0092] In this embodiment, the payment system 300 will only perform subsequent joint risk identification on payments whose risk level, as indicated by the independent risk identification results, is at a preset level. This ensures targeted joint risk identification and avoids the waste of computing resources and poor user experience caused by indiscriminate joint risk identification.

[0093] For example, the payment system 300 determines N2 risk dimensions corresponding to the target payment based on the information of the target payment, where N2 is an integer greater than or equal to 1. The information of the target payment includes at least one of the following: a risk label for the target payment, a first source account corresponding to the target payment, and a first destination account corresponding to the target payment. The risk label is obtained by independently identifying the risk of the target payment. Furthermore, for each risk dimension, the payment system 300 selects historical payments associated with the target payment in that risk dimension from a buffer pool to form a historical payment set.

[0094] In this example, compared to method 1, the target payment information includes risk tags, allowing the payment system 300 to mine the historical payment set associated with the target payment from more risk dimensions. Subsequently, it can comprehensively and accurately identify the associated risks between the target payment and the historical payment set from more risk dimensions.

[0095] In some embodiments, after the payment system 300 determines N2 sets of historical incoming payments, it performs joint risk identification on the target incoming payment and the N2 sets of historical incoming payments to obtain N2 intermediate risk identification results.

[0096] It should be noted that the specific details of how the payment system 300 determines the N2 sets of historical payments can be found in the description of Method 1, and will not be repeated here. The difference is that the target payment information in Method 2 also includes risk tags. In other words, when determining the historical payment sets, the payment system 300, in addition to considering the risk dimensions listed in Method 1, also needs to consider the risk dimensions corresponding to the risk tags.

[0097] For example, if the risk tags corresponding to the target inflow include money laundering and fraud risks, then in addition to determining the historical inflow set as in Method 1, the payment system 300 also needs to select one or more historical inflows corresponding to money laundering risks from the buffer pool to form a historical inflow set; and select one or more historical inflows corresponding to fraud risks from the buffer pool to form a historical inflow set. The specific process of forming the historical inflow set is described in Method 1 and will not be repeated here.

[0098] After determining N2 sets of historical payment receipts, the payment system performs joint risk identification on the target payment receipt and each historical payment receipt to obtain P. C The specific methods can be found in the description of Method 1, and will not be repeated here. The difference lies in the joint risk identification model used for jointly identifying the historical inflow set corresponding to the risk label and the target inflow.

[0099] For example, when performing joint risk identification on a set of historical and target inflows for a corresponding fraud risk dimension, the joint risk identification model used can be a model for identifying fraud risks associated with multiple inflows, and so on. Furthermore, the inflow characteristics input into the joint risk identification model can also differ. For instance, in Method 2, for each set of historical and target inflows, the inflow characteristics input into the corresponding joint risk identification model can be obtained not only based on the transaction information, external information, and internal information shown in Method 1, but also based on the process information and result information generated during the independent risk identification process for the target and historical inflows.

[0100] At this point, the payment system 300 has obtained the target risk identification result corresponding to the target payment through method 1 or method 2.

[0101] S130: Process incoming payments for the target based on the target risk identification results.

[0102] In some embodiments, if the risk probability represented by the target risk identification result is greater than or equal to a first preset threshold, the payment system 300 returns the amount corresponding to the target incoming payment from the transition account corresponding to the first destination account back to the first source account. If the risk probability represented by the target risk identification result is less than or equal to a second preset threshold, the payment system 300 transfers the amount corresponding to the target incoming payment from the transition account corresponding to the first destination account to the first destination account, where the first preset threshold is greater than the second preset threshold. Alternatively, if the risk probability represented by the target risk identification result is less than the first preset threshold and greater than the second preset threshold, the payment system 300 keeps the amount corresponding to the target incoming payment in the transition account corresponding to the first destination account and keeps the target incoming payment in a buffer pool.

[0103] The first preset threshold can be the same as or different from the threshold T2; the second preset threshold can be the same as or different from the threshold T1, and this specification does not impose any restrictions on this.

[0104] In this embodiment, the payment system 300 can process the amount corresponding to the target payment to different degrees based on the risk level of the target payment, rather than simply returning or transferring it to the target account, which is more flexible.

[0105] For transactions where the target payment is kept in the buffer pool, the subsequent payment system 300 can continue to perform joint risk identification on the target payment and other new payments until the amount corresponding to the target payment can be transferred to the primary destination account or returned to the primary source account. Of course, there is a limit to the time a target payment can remain in the buffer pool. The following describes how the payment system 300 handles target payments when the retention period in the buffer pool is greater than or equal to a preset period.

[0106] In some embodiments, method P100 further includes: If the retention period of the target payment in the buffer pool is greater than or equal to the preset period, the payment system 300 obtains the transaction proof information corresponding to the target payment, performs supplementary risk identification on the target payment based on the transaction proof information, obtains the supplementary risk identification result, and processes the target payment based on the supplementary risk identification result.

[0107] For example, if the retention period of the target payment in the buffer pool is greater than or equal to a preset period, the payment system 300 may require both parties to the transaction corresponding to the target payment to upload or submit transaction supporting documents. Transaction supporting documents include, but are not limited to, relevant documents that can prove the authenticity or legality of the transaction corresponding to the target payment. The payment system 300 can extract transaction supporting information from the transaction supporting documents and perform supplementary risk identification on the target payment based on the transaction supporting information to obtain a supplementary risk identification result. If the supplementary risk identification result indicates risk, the payment system 300 will return the amount corresponding to the target payment from the transitional account corresponding to the primary destination account to the primary source account; or if the supplementary risk identification result indicates no risk, the payment system 300 will transfer the amount corresponding to the target payment from the transitional account corresponding to the primary destination account to the primary destination account.

[0108] In this example, there is a time limit for risk identification for each incoming payment, so that the corresponding amount will not be unable to be transferred to the destination account or returned to the source account indefinitely, thus affecting the recipient's payment experience.

[0109] In some embodiments, the intermediate risk identification result determined by the payment system 300 can also characterize the risk probability of some historical payments. When the payment system 300 determines only one set of historical payments, and the target risk identification result corresponding to the target payment is obtained based on the intermediate risk identification result corresponding to that set of historical payments, the target risk identification result can also characterize the risk probability of historical payments in that set of historical payments.

[0110] For example, the target risk identification result also represents the risk probability of the first historical inflow. The first historical inflow is a transfer from the second source account to the second destination account, and the amount corresponding to the first historical inflow is temporarily stored in the transition account corresponding to the second destination account. The payment system 300 can directly process the first historical inflow based on the target risk identification result (e.g., if the first historical inflow does not have a cumulative risk identification result); or, if the first historical inflow has a cumulative risk identification result, the payment system 300 can update the cumulative risk identification result of the first historical inflow based on the target risk identification result, and process the first historical inflow based on the updated cumulative risk identification result.

[0111] The cumulative risk identification result can be obtained based on any of the following: one or more independent risk identification results of the first historical inflow; one or more joint risk identification results of the first historical inflow and other inflows (inflows other than the target inflow); one or more independent risk identification results of the first historical inflow; and one or more joint risk identification results of the first historical inflow and other inflows. The cumulative risk identification result can be a cumulative risk probability or the risk probabilities corresponding to multiple risk identification results, and this specification does not limit this. The updated cumulative risk identification result is, for example, the final risk probability of the first historical inflow obtained by the payment system 300 based on the cumulative risk identification result and the target risk identification result.

[0112] The method by which the 300 payment system directly processes first historical payments based on the target risk identification results is similar to the method for handling target payments described above, and will not be repeated here. The following describes how the 300 payment system processes first historical payments based on the updated cumulative risk identification results.

[0113] For example, if the risk probability represented by the updated cumulative risk identification result is greater than or equal to the first preset threshold, the payment system 300 will return the amount corresponding to the first historical payment from the transition account corresponding to the second destination account to the second source account; if the risk probability represented by the updated cumulative risk identification result is less than or equal to the second preset threshold, the payment system 300 will transfer the amount corresponding to the first historical payment from the transition account corresponding to the second destination account to the second destination account; or if the risk probability represented by the updated cumulative risk identification result is less than the first preset threshold and greater than the second preset threshold, the payment system 300 will leave the amount corresponding to the first historical payment in the transition account corresponding to the second destination account and continue to leave the first historical payment in the buffer pool.

[0114] When the retention period of the first historical payment in the buffer pool is greater than or equal to the preset period, the processing of the first historical payment by the payment system 300 is as described above and will not be repeated here.

[0115] In the example above, while processing the target payment, the payment system 300 can also process other historical payments that are jointly risk-identified with the target payment, thereby improving the efficiency of payment processing.

[0116] In summary, the inflow processing methods, payment collection system, and storage media provided in this manual can help identify the associated risks between multiple inflows by jointly identifying risks from multiple inflows. This process accumulates and amplifies the scattered risks of individual inflows, improving the accuracy of identifying risky inflows. This is especially important for small business payment accounts, which typically have the following characteristics: small amounts, numerous transactions, diverse sources, and varied payers, making inflows relatively scattered. Some risky inflows with similar characteristics can easily be mixed in. The solution provided in this manual can identify these risky inflows with the aforementioned characteristics hidden within normal inflows. Furthermore, the solution provided in this manual can prevent criminals from escaping the payment collection system's risk control by breaking down large inflows into smaller ones, thus avoiding adverse effects on the system. In addition, the solution provided in this manual can collect more features during the joint risk identification of multiple inflows, thereby aggregating potential risk features that are not easily detected from the perspective of individual inflows, making the risk features more obvious and thus more accurately identifying risky inflows.

[0117] It should be noted that in the above description of method P100, the incoming payment is exemplified by a payment originating from a transaction. Therefore, the specific description uses some terms that are involved in transactions, such as transaction information. If the incoming payment originates from other sources, the relevant terms used in method P100 can be adjusted accordingly, and they will not be listed here.

[0118] This specification, in another aspect, provides a computer-readable non-transitory storage medium storing at least one set of executable instructions for processing incoming payments. When the executable instructions are executed by a processor, they instruct the processor to perform the steps of method P100 described herein. In some possible embodiments, various aspects of this specification may also be implemented as a program product comprising program code. When the program product is run on a payment system 300, the program code causes the payment system 300 to perform the steps of method P100 described herein. The program product for implementing the above method may employ a portable compact disc read-only memory (CD-ROM) containing program code and may run on the payment system 300. However, the program product of this specification is not limited thereto. In this specification, the readable storage medium may be any tangible medium containing or storing a program that may be used by or in conjunction with an instruction execution system. The program product may employ any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. The readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. The computer-readable storage medium may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable storage medium may also be any readable medium other than a readable storage medium that can send, propagate, or transmit programs for use by or in connection with an instruction execution system, apparatus, or device. Program code contained on a readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof. Program code for performing the operations described herein can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the payment system 300, partially on the payment system 300, as a standalone software package, partially on the payment system 300 and partially on a remote computing device, or entirely on a remote computing device.

[0119] The term "and / or" in the embodiments of this specification describes the relationship between associated objects, indicating that three relationships can exist. For example, A and / or B can represent three cases: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following associated objects have an "or" relationship.

[0120] The terms “first”, “second”, etc., used in this specification are used to distinguish similar or related objects or entities, and do not necessarily imply a specific order or sequence.

[0121] Unless otherwise stated, the term "multiple" in this specification shall be understood as two or more.

[0122] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0123] In summary, after reading this detailed disclosure, those skilled in the art will understand that the foregoing detailed disclosure is presented by way of example only and is not restrictive. Although not explicitly stated herein, those skilled in the art will understand that this specification requires various reasonable changes, improvements, and modifications to the embodiments. These changes, improvements, and modifications are intended to be made by this specification and are within the spirit and scope of the exemplary embodiments described herein.

[0124] Furthermore, certain terms in this specification have been used to describe embodiments of this specification. For example, "an embodiment," "an embodiment," and / or "some embodiments" mean that a particular feature, structure, or characteristic described in connection with that embodiment may be included in at least one embodiment of this specification. Therefore, it is to be emphasized and understood that two or more references to "an embodiment" or "an embodiment" or "alternative embodiment" in various parts of this specification do not necessarily refer to the same embodiment. Moreover, specific features, structures, or characteristics may be suitably combined in one or more embodiments of this specification.

[0125] It should be understood that in the foregoing description of the embodiments in this specification, various features are combined in a single embodiment, drawing, or description for the purpose of simplifying the description and aiding in the understanding of a feature. However, this does not mean that the combination of these features is necessary, and those skilled in the art may readily identify some of the devices as separate embodiments when reading this specification. That is, the embodiments in this specification can also be understood as an integration of multiple secondary embodiments. It is also valid when each secondary embodiment contains fewer than all the features of a single foregoing disclosed embodiment.

[0126] Every patent, patent application, publication of a patent application, and other material such as articles, books, specifications, publications, documents, articles, etc., cited herein, except for those inconsistent with or conflicting with this document, or those having a restrictive effect on the widest scope of the claims, may be incorporated herein by reference for all purposes now or hereafter associated with this document. Furthermore, in the event of any inconsistency or conflict between the description, definition, and / or use of relevant terms in any material and the description, definition, and / or use of relevant terms in this document, the terms in this document shall prevail.

[0127] Finally, it should be understood that the embodiments disclosed herein are illustrative of the principles of the embodiments described in this specification. Other modified embodiments are also within the scope of this specification. Therefore, the embodiments disclosed in this specification are merely examples and not limitations. Those skilled in the art can implement the applications described in this specification using alternative configurations based on the embodiments in this specification. Therefore, the embodiments in this specification are not limited to the embodiments precisely described in the applications.

Claims

1. A method for processing incoming payments, applied to a payment collection system, comprising: Receive the target incoming payment, wherein the time of receiving the target incoming payment is the first moment; The target incoming call is jointly risk-identified with at least a portion of historical incoming calls in the buffer pool to obtain a target risk identification result. The target risk identification result characterizes the risk probability of the target incoming call. The buffer pool is used to store historical incoming calls received in the historical period before the first moment. as well as The incoming payment to the target is processed based on the target risk identification results.

2. The method of claim 1, wherein, The step of jointly identifying the target inbound transaction with at least a portion of historical inbound transactions in the buffer pool to obtain the target risk identification result includes: N sets of historical inflows are determined from the buffer pool. Each set of historical inflows includes at least one historical inflow. The N sets of historical inflows are correlated with the target inflow in different risk dimensions. N is an integer greater than or equal to 1. The target incoming payment and the N sets of historical incoming payments are jointly risk-identified to obtain N intermediate risk identification results; and Based on the N intermediate risk identification results, the target risk identification result is determined.

3. The method of claim 2, wherein, The process of determining N sets of historical inflows from the buffer pool includes: Based on the information of the target inflow, N risk dimensions corresponding to the target inflow are determined, wherein the information of the target inflow includes at least one of the following: a risk label for the target inflow, a first source account corresponding to the target inflow, a first destination account corresponding to the target inflow, and the risk label is obtained by independently identifying the risk of the target inflow; and For each risk dimension, historical invoices associated with the target invoice in that risk dimension are selected from the buffer pool to form a set of historical invoices.

4. The method of claim 2, wherein, The step of jointly identifying the target inbound call and the N sets of historical inbound calls to obtain N intermediate risk identification results includes: For each set of historical inflows, The characteristics of incoming accounts are determined based on the target incoming account and the historical incoming account set; and The incoming account features are input into the joint risk identification model corresponding to the target risk dimension. The joint risk identification model is used to perform joint risk identification on the target incoming account and the historical incoming account set to obtain the intermediate risk identification result. The target risk dimension is the risk dimension corresponding to the historical incoming account set.

5. The method according to claim 4, wherein, The incoming payment characteristics are obtained based on at least one of the following: The transaction information corresponding to the target incoming account and the historical incoming accounts in the historical incoming account set; External information obtained from external data sources based on the target incoming payment and the historical incoming payment set, wherein the external data source is a data source outside the payment system; as well as Internal information obtained by searching the internal data source based on the target incoming payment and the historical incoming payment set, wherein the internal data source is the data source within the payment collection system.

6. The method according to claim 2, wherein, The process of determining the target risk identification result based on the N intermediate risk identification results includes: Obtain the independent risk identification result corresponding to the target inflow, wherein the independent risk identification result is obtained by performing independent risk identification on the target inflow; A joint risk identification result is determined based on the N intermediate risk identification results; and Based on the joint risk identification results and the independent risk identification results, the target risk identification result is determined.

7. The method according to claim 1, wherein, After receiving the target payment, the method further includes: Independent risk identification is performed on the target inflow to obtain an independent risk identification result. If the risk level represented by the independent risk identification result is a preset level, the amount corresponding to the target inflow is temporarily stored in the transit account of the payment system. The joint risk identification of the target inbound account and at least a portion of the historical inbound accounts in the buffer pool includes: If the risk level represented by the independent risk identification result is the preset level, the target inbound account and at least a portion of the historical inbound accounts in the buffer pool will be jointly identified for risk identification.

8. The method according to claim 7, wherein, The target incoming payment is a transfer from a first source account to a first destination account. The processing of the target incoming payment based on the target risk identification result includes: If the risk probability represented by the target risk identification result is greater than or equal to the first preset threshold, then the amount corresponding to the target incoming payment will be returned from the transition account to the first source account. If the risk probability represented by the target risk identification result is less than or equal to the second preset threshold, then the amount corresponding to the target incoming payment will be transferred from the transit account to the first destination account, where the first preset threshold is greater than the second preset threshold; or If the risk probability represented by the target risk identification result is less than the first preset threshold and greater than the second preset threshold, then the amount corresponding to the target inflow will be left in the transition account and the target inflow will be left in the buffer pool.

9. The method according to claim 8, wherein, The method further includes: If the retention period of the target inflow in the buffer pool is greater than or equal to a preset period, then the transaction proof information corresponding to the target inflow is obtained; and Based on the transaction proof information, supplementary risk identification is performed on the target inbound account to obtain supplementary risk identification results, and the target inbound account is processed based on the supplementary risk identification results.

10. The method according to claim 1, wherein, The at least some of the incoming accounts include first historical incoming accounts, and the method further includes: Based on the target risk identification result, the cumulative risk identification result of the first historical inflow is updated, and the first historical inflow is processed based on the updated cumulative risk identification result.

11. The method according to claim 10, wherein, The first historical inflow is a transfer from the second source account to the second destination account, and the amount corresponding to the first historical inflow is temporarily stored in the transit account of the payment system. The first historical inflow is processed based on the updated cumulative risk identification results, including: If the risk probability represented by the updated cumulative risk identification result is greater than or equal to the first preset threshold, then the amount corresponding to the first historical inflow will be returned from the transition account to the second source account. If the risk probability represented by the updated cumulative risk identification result is less than or equal to the second preset threshold, then the amount corresponding to the first historical inflow will be transferred from the transition account to the second destination account, where the first preset threshold is greater than the second preset threshold; or If the risk probability represented by the updated cumulative risk identification result is less than the first preset threshold and greater than the second preset threshold, then the amount corresponding to the first historical inflow will be left in the transition account, and the first historical inflow will be left in the buffer pool.

12. A payment collection system, comprising: At least one storage medium storing at least one instruction set for processing incoming payments; as well as At least one processor is communicatively connected to the at least one storage medium, wherein the at least one processor reads the at least one instruction set during operation and, according to the instructions of the at least one instruction set: Receive the target payment, where the time of receiving the target payment is the first moment. The target incoming call is jointly risk-identified with at least a portion of historical incoming calls in the buffer pool to obtain a target risk identification result. The target risk identification result characterizes the risk probability of the target incoming call. The buffer pool is used to store historical incoming calls received within a historical period prior to the first time point. The incoming payment to the target is processed based on the target risk identification results.

13. The payment system according to claim 12, wherein, In order to obtain the target risk identification results, the at least one processor: N sets of historical inflows are determined from the buffer pool. Each set of historical inflows includes at least one historical inflow. The N sets of historical inflows are correlated with the target inflow in different risk dimensions. N is an integer greater than or equal to 1. The target inflow and the N sets of historical inflows are combined for risk identification to obtain N intermediate risk identification results; as well as Based on the N intermediate risk identification results, the target risk identification result is determined.

14. The payment system according to claim 13, wherein, To determine N sets of historical invoices, the at least one processor: Based on the information of the target inflow, N risk dimensions corresponding to the target inflow are determined, wherein the information of the target inflow includes at least one of the following: a risk label for the target inflow, a first source account corresponding to the target inflow, a first destination account corresponding to the target inflow, and the risk label is obtained by independently identifying the risk of the target inflow; and For each risk dimension, historical invoices associated with the target invoice in that risk dimension are selected from the buffer pool to form a set of historical invoices.

15. The payment system according to claim 13, wherein, To obtain N intermediate risk identification results, the at least one processor: For each set of historical inflows, The characteristics of incoming accounts are determined based on the target incoming account and the historical incoming account set; and The incoming account features are input into the joint risk identification model corresponding to the target risk dimension. The joint risk identification model is used to perform joint risk identification on the target incoming account and the historical incoming account set to obtain the intermediate risk identification result. The target risk dimension is the risk dimension corresponding to the historical incoming account set.

16. The payment system according to claim 15, wherein, The incoming payment characteristics are obtained based on at least one of the following: The transaction information corresponding to the target incoming account and the historical incoming accounts in the historical incoming account set; External information obtained from external data sources based on the target incoming payment and the historical incoming payment set, wherein the external data source is a data source outside the payment system; as well as Internal information obtained by searching the internal data source based on the target incoming payment and the historical incoming payment set, wherein the internal data source is the data source within the payment collection system.

17. The payment system according to claim 13, wherein, To determine the target risk identification result, the at least one processor: Obtain the independent risk identification result corresponding to the target inflow, wherein the independent risk identification result is obtained by performing independent risk identification on the target inflow; The joint risk identification result is determined based on the N intermediate risk identification results; as well as Based on the joint risk identification results and the independent risk identification results, the target risk identification result is determined.

18. The payment system according to claim 12, wherein, The at least one processor also: Independent risk identification is performed on the target inflow to obtain an independent risk identification result. If the risk level represented by the independent risk identification result is a preset level, the amount corresponding to the target inflow is temporarily stored in the transit account of the payment system. If the risk level represented by the independent risk identification result is the preset level, the target inbound account and at least a portion of the historical inbound accounts in the buffer pool will be jointly identified for risk identification.

19. The payment system according to claim 18, wherein, The target incoming payment is a transfer from a first source account to a first destination account. To process the target incoming payment, the at least one processor includes: If the risk probability represented by the target risk identification result is greater than or equal to the first preset threshold, then the amount corresponding to the target incoming payment will be returned from the transition account to the first source account. If the risk probability represented by the target risk identification result is less than or equal to the second preset threshold, then the amount corresponding to the target incoming payment will be transferred from the transit account to the first target account, where the first preset threshold is greater than the second preset threshold. or If the risk probability represented by the target risk identification result is less than the first preset threshold and greater than the second preset threshold, then the amount corresponding to the target inflow will be left in the transition account and the target inflow will be left in the buffer pool.

20. A computer-readable non-transitory storage medium, wherein, The computer-readable non-transitory storage medium stores at least one set of instructions, which, when executed by at least one processor, implement the method as described in any one of claims 1-11.

Images