A method and device for transferring assets in a payment platform

Abstract

Embodiments of this specification provide a method and apparatus for transferring assets in a payment platform. When a third-party payment platform detects that a first account receives a first asset transferred from a second account, the platform obtains a signature sequence corresponding to each first unit asset in the first asset, where the signature sequence includes signature information of the accounts through which the corresponding unit asset passes in sequence; obtains a first signature corresponding to the first account; and adds the first signature to the signature sequence corresponding to each first unit asset.

Description

Technical Field

[0001] This specification relates to the field of information security technology, and in particular to a method and device for transferring assets in a payment platform. Background Art

[0002] Against the backdrop of tightening payment regulations, fourth-party payment platforms have emerged. These platforms, which violate national payment and settlement regulations and rely on legitimate third-party payment platforms like Alipay and Tenpay, illegally establish payment channels through a large number of registered merchant or personal accounts. Black and gray industries use these platforms to illegally organize third-party payment platform accounts to aggregate payments and collect payments, using them to conceal the use of assets and facilitate the legalization of illicit assets (a process also known as "running points").

[0003] In order to better identify the purpose of assets entering the third-party payment platform, it is crucial to effectively identify the whereabouts of assets in the third-party payment platform. Summary of the Invention

[0004] One or more embodiments of this specification provide a method and apparatus for transferring assets in a payment platform to identify the transfer path of each asset in a third-party payment platform, thereby providing a basis for subsequent identification of the use of the assets.

[0005] According to a first aspect, a method for transferring assets in a payment platform is provided, which is applied to a third-party payment platform, and the method comprises:

[0006] Upon detecting that the first account receives the first asset transferred from the second account, obtaining a signature sequence corresponding to each first unit asset in the first asset, the signature sequence including signature information of the accounts through which the corresponding unit asset passes in sequence;

[0007] Obtaining a first signature corresponding to the first account;

[0008] The first signature is added to the signature sequence corresponding to each first unit asset.

[0009] In one possible implementation, obtaining the first signature corresponding to the first account includes:

[0010] Obtaining the first signature from a preset storage space, wherein the first signature is obtained by pre-signing a ciphertext of the first account identifier of the first account based on a current platform private key; or

[0011] The first account identification ciphertext of the first account is signed using the current platform private key to obtain the first signature.

[0012] In one possible implementation, the first account identification ciphertext is summary information obtained by performing a hash operation on the account identification of the first account.

[0013] In one embodiment, it further includes:

[0014] If it is detected that the current platform private key and its corresponding current platform public key are updated, the signature sequence corresponding to each unit asset stored on the third-party payment platform is decrypted using the current platform public key to obtain the account identification ciphertext sequence corresponding to each unit asset;

[0015] Use the updated platform private key to sign each account identification ciphertext in the account identification ciphertext sequence corresponding to each unit asset to obtain an updated signature sequence corresponding to each unit asset.

[0016] In one embodiment, it further includes:

[0017] When it is detected that the third account receives the second asset transferred from the bank card account, a corresponding new signature sequence is generated for each second unit asset in the second asset, wherein the new signature sequence includes the third signature corresponding to the third account.

[0018] In one possible implementation, each first unit asset is the smallest unit asset of the currency to which it belongs; or, each first unit asset is an asset corresponding to a different signature sequence.

[0019] In one embodiment, before detecting that the first account receives the first asset transferred from the second account, the method further includes:

[0020] receiving an asset transfer instruction to transfer assets from the second account to the first account;

[0021] Determining, from the assets held by the second account, a first asset corresponding to the asset transfer instruction based on a preset asset transfer rule, wherein the asset transfer rule is related to a signature sequence corresponding to each unit of the held assets;

[0022] The first asset is transferred from the second account to the first account.

[0023] In one possible implementation, the asset transfer rule is: preferentially selecting the unit asset with the longest corresponding signature sequence as the asset to be transferred, or preferentially selecting the unit asset with the shortest corresponding signature sequence as the asset to be transferred.

[0024] In one embodiment, it further includes:

[0025] Using the current platform public key corresponding to the current platform private key, decrypt the signature sequence corresponding to each target unit asset in the target asset range of the third-party payment platform to obtain the ciphertext sequence of each account identification corresponding to each target unit asset;

[0026] Based on the respective account identification ciphertext sequences and the pre-stored correspondence between the account identification ciphertexts and the account identifications of the respective accounts, the respective account identification sequences corresponding to the respective target unit assets are determined.

[0027] In one embodiment, the target asset range includes one of the following:

[0028] All assets stored on the third-party payment platform;

[0029] Assets that have been transferred within a predetermined timeframe;

[0030] Assets transferred to bank card accounts.

[0031] In one embodiment, it further includes:

[0032] Determine the associated statistical information of each account identifier based on the respective account identifier sequences corresponding to the respective target unit assets;

[0033] Based on the associated statistical information of each account identifier, target accounts that meet the preset risk rules are determined as risk accounts.

[0034] In one embodiment, the associated statistical information includes: the number of occurrences of each account identifier in the sequence of each account identifier, and the source account of the upstream previous account and / or the destination account of the downstream next account when the account identifier appears.

[0035] In one possible implementation, determining the target account that meets the preset risk determination rule as the risk account includes:

[0036] Determine the account identifier that appears more than a preset threshold number of times as the account identifier of the target account; and / or

[0037] Determine the account identifiers of source accounts whose number exceeds the first number as the account identifiers of the target accounts; and / or

[0038] If there are more than a second number of different accounts sharing the same account identifier as the source account, the same account identifier is determined as the account identifier of the target account.

[0039] In one embodiment, it further includes:

[0040] If there are more than a third number of different accounts that share the same account identifier as the destination account, and the destination account is a bank card account, then the more than the third number of different accounts are all determined as target accounts.

[0041] According to a second aspect, a device for transferring assets in a payment platform is provided, which is applied to a third-party payment platform, and includes:

[0042] a first obtaining module configured to, upon detecting that the first account receives the first asset transferred from the second account, obtain a signature sequence corresponding to each first unit of the first asset, the signature sequence including signature information of the accounts through which the corresponding first unit of the asset passes in sequence;

[0043] a second obtaining module, configured to obtain a first signature corresponding to the first account;

[0044] The adding module is configured to add the first signature to the signature sequence corresponding to each first unit asset.

[0045] In one possible implementation, the second obtaining module is specifically configured to obtain the first signature from a preset storage space, wherein the first signature is obtained by signing the first account identifier ciphertext of the first account in advance based on the current platform private key; or

[0046] The second obtaining module is specifically configured to use the current platform private key to sign the first account identification ciphertext of the first account to obtain the first signature.

[0047] In one possible implementation, the first account identification ciphertext is summary information obtained by performing a hash operation on the account identification of the first account.

[0048] In one embodiment, it further includes:

[0049] A first decryption module is configured to, upon detecting that the current platform private key and its corresponding current platform public key are updated, decrypt the signature sequence corresponding to each unit asset stored on the third-party payment platform using the current platform public key to obtain a ciphertext sequence of account identification corresponding to each unit asset;

[0050] The first signature module is configured to use the updated platform private key to sign each account identification ciphertext in the account identification ciphertext sequence corresponding to each unit asset, thereby obtaining an updated signature sequence corresponding to each unit asset.

[0051] In one embodiment, it further includes:

[0052] The generation module is configured to, upon detecting that the third account receives the second asset transferred from the bank card account, generate a corresponding new signature sequence for each second unit asset in the second asset, wherein the new signature sequence includes a third signature corresponding to the third account.

[0053] In one possible implementation, each first unit asset is the smallest unit asset of the currency to which it belongs; or, each first unit asset is an asset corresponding to a different signature sequence.

[0054] In one embodiment, it further includes:

[0055] an instruction receiving module configured to receive an asset transfer instruction for transferring assets from the second account to the first account before detecting that the first account receives the first asset transferred from the second account;

[0056] a first determining module configured to determine, from the assets corresponding to the second account, a first asset corresponding to the asset transfer instruction based on a preset asset transfer rule, wherein the asset transfer rule is related to a signature sequence corresponding to each unit asset in the held assets;

[0057] A transfer module is configured to transfer the first asset from the second account to the first account.

[0058] In one possible implementation, the asset transfer rule is: preferentially selecting the unit asset with the longest corresponding signature sequence as the asset to be transferred, or preferentially selecting the unit asset with the shortest corresponding signature sequence as the asset to be transferred.

[0059] In one embodiment, it further includes:

[0060] A second decryption module is configured to use the current platform public key corresponding to the current platform private key to decrypt the signature sequence corresponding to each target unit asset in the target asset range of the third-party payment platform, and obtain the account identification ciphertext sequence corresponding to each target unit asset;

[0061] The second determining module is configured to determine each account identification sequence corresponding to each target unit asset based on each account identification ciphertext sequence and a pre-stored correspondence between the account identification ciphertext and the account identification of each account.

[0062] In one possible implementation, the target asset range includes one of the following: all assets stored in the third-party payment platform; assets that have been transferred within a predetermined time range; and assets transferred to a bank card account.

[0063] In one embodiment, it further includes:

[0064] A third determining module is configured to determine associated statistical information of each account identifier based on each account identifier sequence corresponding to each target unit asset;

[0065] The fourth determining module is configured to determine target accounts that meet preset risk rules as risk accounts based on the associated statistical information of each account identifier.

[0066] In one embodiment, the associated statistical information includes: the number of occurrences of each account identifier in the sequence of each account identifier, and the source account of the upstream previous account and / or the destination account of the downstream next account when the account identifier appears.

[0067] In one possible implementation, the fourth determining module is specifically configured to determine the account identifier whose number of appearances exceeds a preset number threshold as the account identifier of the target account; and / or

[0068] Determine the account identifiers of source accounts whose number exceeds the first number as the account identifiers of the target accounts; and / or

[0069] If there are more than a second number of different accounts sharing the same account identifier as the source account, the same account identifier is determined as the account identifier of the target account.

[0070] In one embodiment, it further includes:

[0071] The fifth determining module is configured to determine all of the more than third number of different accounts as target accounts if there are more than a third number of different accounts sharing the same account identifier as the destination account, and the destination account is a bank card account.

[0072] According to a third aspect, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed in a computer, the computer is caused to execute the method according to the first aspect.

[0073] According to a fourth aspect, a computing device is provided, comprising a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the method described in the first aspect is implemented.

[0074] According to the method and apparatus provided in the embodiments of this specification, when a third-party payment platform detects that a first account has received a first asset transferred from a second account, it obtains a signature sequence corresponding to each first unit asset within the first asset, including the signature information of the accounts through which the corresponding unit asset has passed in sequence; obtains the first signature corresponding to the first account; and adds the first signature to each first transfer message. Thus, within the third-party payment platform, each time an asset passes through an account, the third-party payment platform adds the signature of the account that passed through it to the signature sequence corresponding to the unit asset within that asset, thereby marking the transfer path of the unit asset within the third-party payment platform and providing a basis for subsequent identification of the asset's use. BRIEF DESCRIPTION OF THE DRAWINGS

[0075] To more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required for describing the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. Those skilled in the art can also derive other drawings based on these drawings without inventive effort.

[0076] Figure 1A and Figure 1B A schematic diagram of an implementation framework of an embodiment disclosed in this specification;

[0077] Figure 2 A schematic flow chart of a method for transferring assets in a payment platform provided in an embodiment;

[0078] Figure 3 A schematic diagram showing changes in the signature sequence of a unit asset as it passes through each account in turn, as provided in the embodiment;

[0079] Figure 4 A schematic diagram of a unit asset transfer process provided in an embodiment;

[0080] Figure 5A and Figure 5B A schematic diagram of the source account of the upstream previous account and the destination account of the downstream next account when the account identifier appears in the determined association statistical information provided by the embodiment;

[0081] Figure 6 A schematic block diagram of an apparatus for transferring assets in a payment platform provided in an embodiment. DETAILED DESCRIPTION

[0082] The technical solutions of the embodiments of this specification will be described in detail below with reference to the accompanying drawings.

[0083] The embodiments of this specification disclose a method and apparatus for transferring assets in a payment platform. The following first introduces the application scenarios and technical concepts of the method for transferring assets in a payment platform, specifically as follows:

[0084] At present, in order to conceal the use of assets and facilitate the legalization of illegal assets, the black and gray industries illegally organize accounts on third-party payment platforms to collect and pay money through the "fourth-party payment" platform.

[0085] In order to curb the above illegal activities, it is necessary to effectively identify the above illegal activities. Accordingly, there is an urgent need for a method that can effectively identify the whereabouts of funds in the third-party payment platform, and then analyze the whereabouts of each fund to determine the purpose of the funds in order to identify the above illegal activities.

[0086] In view of this, the inventor proposes a method for asset transfer in a payment platform. Figure 1A FIG. 1 shows a schematic diagram of an implementation framework according to an embodiment disclosed in this specification. Figure 1A As shown, a third-party payment platform may have Account 1, Account 2, ..., and Account N. These Accounts 1, 2, and N may operate on a terminal device installed with the corresponding client software for the third-party payment platform. Accounts 1, 2, and N may be accounts logged into using this client software. In one implementation, the third-party payment platform may be any platform capable of managing assets. For example, the third-party payment platform may be the Alipay platform, and the corresponding client software for the third-party payment platform may be the Alipay application. Accounts 1, 2, and N are all Alipay accounts.

[0087] According to the technical concept of the embodiments of this specification, the third-party payment platform can monitor the assets transferred between accounts in real time, and can monitor the assets transferred from and to bank card accounts. Assume that the third-party payment platform detects that account 1 (account id is id1) receives an asset from bank card account 1. Figure 1A As shown, this asset can be identified as Asset A. Accordingly, the third-party payment platform generates a corresponding signature sequence for each unit asset in Asset A. Among them, Account 1 is the first account that Asset A enters the third-party payment platform. The signature sequence corresponding to each unit asset in Asset A includes the corresponding signature S(id1) of Account 1. The signature sequence corresponding to each unit asset in Asset A is expressed as [S(id1)].

[0088] Next, assume that Account 1 transfers an asset, designated Asset B, from its Asset A to Account 2 (with Account ID id2) through a third-party payment platform. Upon detecting that Account 2 has received Asset B, the third-party payment platform adds Account 2's signature, S(id2), to the signature sequence, [S(id1)], corresponding to each unit of Asset B, resulting in a signature sequence, [S(id1), S(id2)], corresponding to each unit of Asset B.

[0089] As can be seen from the above process, when an asset enters a third-party payment platform, the platform creates transfer information, represented by a signature sequence, for each unit asset within the incoming assets and attaches or associates this transfer information with each unit asset. Subsequently, each time a unit asset passes through an account, the third-party payment platform adds the signature of each account to the signature sequence corresponding to the unit asset. As will be appreciated, signatures for each account within the third-party payment platform are unique. Therefore, this attached signature sequence allows the transfer path of each unit asset within the third-party payment platform to be identified.

[0090] Based on the above concept, the third-party payment platform can track and identify asset transfers between platform accounts and between platform accounts and bank card accounts. Figure 1A As shown, Account 1, Account 2, and Account N can all receive assets transferred from a bank card (i.e., a bank card account), and can transfer assets from their accounts to a bank card account. In an example scenario, Figure 1B As shown, Account 1 receives Asset A1 transferred from Bank Card Account 1. The third-party payment platform generates a signature sequence A1 for each unit asset in Asset A1. This signature sequence A1 includes Account 1's signature, for example, "S(id1)." Account 1 then needs to transfer Asset A2 (a portion of the unit assets in Asset A1) to Bank Card Account 2. The signature sequence A2 corresponding to each unit asset in Asset A2 is the signature sequence A1, which can be expressed as [S(id1)]. It will be appreciated that in this implementation, the signature sequence corresponding to the unit assets only includes the signature corresponding to Account 1.

[0091] In one example, account 2 receives assets B1 transferred from bank card account 3. The third-party payment platform generates a signature sequence B1 for each unit asset in asset B1. The signature sequence B1 includes the signature of account 2, such as "S(id2)".

[0092] Account 2 transfers its asset B2 to bank card account 4. Assume that asset B2 consists of two parts. The first part of the assets is part of the unit assets in asset A1 transferred from account 1, and the second part is part of the unit assets in asset B1. Therefore, the signature sequence corresponding to the first part of the assets is [S(id1), S(id2)], and the signature sequence corresponding to the second part of the assets is [S(id2)].

[0093] In another example, account N receives assets U1 transferred from bank card account u. The third-party payment platform generates a signature sequence U1 for each unit asset in assets U1. The signature sequence U1 includes the signature of account N, for example, "S(idN)".

[0094] Subsequently, account N transfers its asset U2 to bank card account p. This asset U2 may include, for example: a first portion of assets originating from asset A1 and sequentially passing through accounts 1, 2, ..., N; a second portion of assets originating from asset B1 and sequentially passing through accounts 2 ... N; and a third portion of assets originating from asset U1. Therefore, the signature sequence corresponding to the unit assets in asset U2 may include the signature sequence corresponding to the first portion of assets [S(id1), S(id2), ..., S(idN-1), S(idN)]; the signature sequence corresponding to the second portion of assets [S(id2), ..., S(idN-1), S(idN)]; and the signature sequence corresponding to the third portion of assets [S(idN)].

[0095] Through the above description of the exemplary scenario, it can be intuitively understood that the signature sequence attached to each unit asset in the embodiments of this specification can clearly show the flow process of the corresponding unit asset in the third-party payment platform, thereby facilitating the third-party payment platform to track the whereabouts of funds, determine the use of funds, and identify risky behaviors.

[0096] The following describes in detail the method for transferring assets in the payment platform provided in this specification in conjunction with specific embodiments.

[0097] Figure 2 A flowchart of a method for transferring assets in a payment platform according to one embodiment of this specification is shown. The method can be implemented via a third-party payment platform, wherein the third-party payment platform can be implemented by any device, equipment, platform, device cluster, etc. having computing and processing capabilities. The method includes the following steps S210-S230:

[0098] S210: When it is detected that the first account receives the first asset transferred from the second account, a signature sequence corresponding to each first unit asset in the first asset is obtained, where the signature sequence includes signature information of the accounts through which the corresponding unit asset passes in sequence.

[0099] It is understandable that the "first" in the first account and the "second" in the second account are only used to distinguish different accounts and do not have any other limiting meaning. The first account and the second account can be any accounts of the third-party payment platform.

[0100] A third-party payment platform can monitor asset transfers between accounts in real time, including both transfers from and to bank card accounts. Upon detecting that a first account has received a first asset transferred from a second account, the third-party payment platform obtains a signature sequence corresponding to each first unit asset in the first asset. The first assets may include at least one unit asset, referred to as a first unit asset.

[0101] In one implementation, when a third-party payment platform transfers a first asset from a second account to a first account, it can simultaneously obtain the signature sequence corresponding to each unit asset (i.e., the first unit asset) in the first asset. The signature sequence includes the signature information of the accounts that the corresponding unit asset passes through in sequence. The signatures of each account in the signature sequence are arranged in the order in which the corresponding unit asset passes through each account. For example, a unit asset a passes through account 1, account 2, account 3, and account 4 in sequence, where unit asset A is transferred from a bank card account to account 1. Figure 3 As shown, correspondingly, when unit asset a arrives at account 1, its corresponding signature sequence is [S(id1)]; when unit asset a arrives at account 2, its corresponding signature sequence is [S(id1), S(id2)]; when unit asset a arrives at account 3, its corresponding signature sequence is [S(id1), S(id2), S(id3)]; when unit asset a arrives at account 4, its corresponding signature sequence can be [S(id1), S(id2), S(id3), S(id4)]. Among them, S(id1) is the current signature of account 1, S(id2) is the current signature of account 2, S(id3) is the current signature of account 3, and S(id4) is the current signature of account 4.

[0102] Correspondingly, it can be understood that the signature sequence corresponding to the first unit asset includes at least the second signature of the second account.

[0103] In this specification, the transferred first asset can be in any currently used currency, such as RMB, USD, EUR, and JPY. In one implementation, each first unit asset is the smallest unit asset in its currency. For example, if the first asset is denominated in RMB, the corresponding unit of each first unit asset in the first asset is Cen, i.e., each Cen is one unit asset.

[0104] In another implementation, each first unit of asset can also be an asset corresponding to a different signature sequence. For example, the first assets include: an asset corresponding to signature sequence 1, an asset corresponding to signature sequence 2, and an asset corresponding to signature sequence 3. Accordingly, the asset corresponding to signature sequence 1 can be referred to as a first unit of asset included in the first assets; the asset corresponding to signature sequence 2 can be referred to as a first unit of asset included in the first assets; and the asset corresponding to signature sequence 3 can also be referred to as a first unit of asset included in the first assets.

[0105] S220: Obtain a first signature corresponding to the first account. In one implementation, after obtaining the signature sequence corresponding to each first unit of the first asset, the third-party payment platform may proceed to obtain the first signature corresponding to the first account. In another implementation, obtaining the first signature may be performed before obtaining the signature sequence, or both steps may be performed simultaneously.

[0106] In one implementation, the first signature may have been pre-generated, and the account identifier corresponding to the first account is stored in a preset storage space. Accordingly, the S220 may include the following step 01: obtaining the first signature from the preset storage space. It is understandable that in order to protect the security of personal privacy information (including assets) of each account in the third-party payment platform, the first signature is obtained by pre-signing the ciphertext of the first account identifier of the first account based on the current platform private key. The current platform private key corresponds to the current platform public key, and the two are a pair of asymmetric keys generated based on a preset key generation algorithm.

[0107] The preset key generation algorithm may be any algorithm in the related art that can generate an asymmetric key. For example, it may be a common digital signature algorithm such as the RSA algorithm, the ElGamal algorithm, the Fiat-Shamir algorithm, the Guillou-Quisquarter algorithm, the Schnorr algorithm, the Ong-Schnorr-Shamir digital signature algorithm, the Des / DSA algorithm, the elliptic curve digital signature algorithm, and the finite automaton digital signature algorithm. It may also be a special digital signature algorithm such as a blind signature algorithm, a proxy signature algorithm, a group signature algorithm, a non-repudiation signature algorithm, a fair blind signature algorithm, a threshold signature algorithm, and a signature algorithm with a message recovery function.

[0108] In this embodiment, signatures can solve problems such as forgery, repudiation, impersonation, and tampering, improve the security of asset transfers within the third-party payment platform, and provide a basis for asset traceability.

[0109] In this implementation, upon detecting that an account's account identifier has been modified and / or the current platform private key has been updated, the third-party payment platform can subsequently update the account's signature. The account identifier can include information that uniquely identifies each account within the third-party payment platform, such as the account name, ID, and login name. The login name can include a mobile phone number or email address required to log in to the account.

[0110] In another implementation, taking into account the possibility that the account identifier of the first account may be modified, and considering that the third-party payment platform may periodically or irregularly update its platform public and private keys to ensure the security of the assets within its accounts, in view of the above two situations, the first signature can be generated in real time after the third-party payment platform detects that the first account has received the first asset transferred from the second account. Accordingly, S220 may include the following step 02: signing the ciphertext of the first account identifier of the first account using the current platform private key to obtain the first signature.

[0111] In one implementation, the first account identification ciphertext is a digest of the first account's account identification obtained by performing a hash operation. Signing the account identification ciphertext can, to a certain extent, improve the protection of the privacy of assets in each account. The embodiments of this specification do not limit the specific hashing algorithm used in the above hashing operation.

[0112] S230: Add the first signature to the signature sequence corresponding to each first-unit asset. In this step, after obtaining the signature sequence and first signature corresponding to each first-unit asset, the third-party payment platform adds the first signature to the signature sequence corresponding to each first-unit asset. For example, the first signature can be added at the end of the signature sequence corresponding to each first-unit asset. The order of the signatures in the signature sequence corresponding to each first-unit asset can reflect the order in which the first-unit assets pass through each account.

[0113] In one implementation, the order of signatures in a signature sequence can represent the order in which the corresponding unit asset passed through each account. To more accurately determine the specific time when the unit asset passed through each account, the signature sequence can also carry the timestamp information corresponding to each signature in the signature sequence. This timestamp information can indicate the time when the corresponding signature was added to the signature sequence, that is, the time when the unit asset was transferred to the corresponding account.

[0114] In this embodiment, the third-party payment platform can monitor the path transfer of assets within it. Within the third-party payment platform, every time an asset passes through an account, the third-party payment platform adds the signature of the account that passed through to the signature sequence corresponding to the unit asset within the asset, so as to mark the transfer path of the unit asset within the third-party payment platform, providing a basis for subsequent identification of the use of the asset.

[0115] In addition, the signature in the transfer information is obtained by encrypting the account identification ciphertext of the account based on the platform private key. The account identification ciphertext can avoid direct exposure of the account identification, and to a certain extent can achieve the protection of the privacy information security of the corresponding account, and greatly reduce the operational risks of analysis and operation.

[0116] In another embodiment of the present specification, the method further includes the following steps 21-22:

[0117] Step 21: If it is detected that the current platform private key and its corresponding current platform public key are updated, the signature sequence corresponding to each unit asset stored in the third-party payment platform is decrypted using the current platform public key to obtain the account identification ciphertext sequence corresponding to each unit asset.

[0118] Step 22: Use the updated platform private key to sign each account identification ciphertext in the account identification ciphertext sequence corresponding to each unit asset to obtain an updated signature sequence corresponding to each unit asset.

[0119] Through this embodiment, it is possible to avoid the situation where the platform's key is stolen and the asset information of each account in the platform is leaked. In this implementation method, the platform public and private key pairs can be updated periodically or non-periodically. Accordingly, if the third-party payment platform detects that the current platform private key and its corresponding current platform public key are updated, the current platform public key is used to decrypt each signature in the signature sequence corresponding to each unit asset stored by the third-party payment platform, and the account identification ciphertext corresponding to each signature is obtained, and then the account identification ciphertext sequence corresponding to each unit asset is obtained; the updated platform private key is used to re-sign each account identification ciphertext in the account identification ciphertext sequence corresponding to each unit asset, and the updated signature sequence corresponding to each unit asset is obtained. Furthermore, the updated signature sequence corresponding to each unit asset is stored.

[0120] Subsequently, after detecting an asset transfer between accounts on the third-party payment platform, the updated signature sequence corresponding to each unit of the transferred assets is obtained, along with the current signature of the receiving account corresponding to the asset transfer. The receiving account's current signature is added to the updated signature sequence corresponding to each unit of the asset. The receiving account's current signature is obtained by signing the receiving account's account identifier using the updated platform private key.

[0121] It is understood that the third-party payment platform itself does not generate assets. The assets within the third-party payment platform come from top-ups in bank card accounts, and any outflow of assets from the third-party payment platform also flows out to the bank card account. Accordingly, in another embodiment of this specification, the third-party payment platform may also monitor assets transferred into and out of the bank card account. The method further includes step 31: upon detecting that the third account has received a second asset transferred from the bank card account, generating a corresponding new signature sequence for each second unit of the second asset, wherein the new signature sequence includes a third signature corresponding to the third account.

[0122] The third account may be the first account, the second account or another account of the third-party payment platform.

[0123] In one scenario, if the unit asset is the smallest unit asset in its currency, upon detecting that the third account has received the second asset transferred from the bank card account, the third-party payment platform will generate a corresponding new signature sequence for each smallest unit asset in the second asset, including the third signature corresponding to the third account. In another scenario, if each unit asset corresponds to a different signature sequence, upon detecting that the third account has received the second asset transferred from the bank card account, the third-party payment platform may treat the entire second asset as a second unit asset and generate a new signature sequence for it, including the third signature corresponding to the third account. This third signature is obtained by signing the ciphertext of the third account identifier of the third account using the current platform private key. The ciphertext of the third account identifier is the digest information obtained by performing a hash operation on the account identifier of the third account.

[0124] In another embodiment of the present specification, before detecting that the first account receives the first asset transferred from the second account, the method may further include the following steps 41-43:

[0125] Step 41: Receive an asset transfer instruction to transfer assets from the second account to the first account.

[0126] Step 42: Based on the preset asset transfer rules, the first asset corresponding to the asset transfer instruction is determined from the assets corresponding to the second account. The asset transfer rules are related to the signature sequence corresponding to each unit asset in the held assets.

[0127] Step 43: Transfer the first asset from the second account to the first account.

[0128] Among them, the above-mentioned asset transfer rules can be set according to needs. In one implementation, the above-mentioned asset transfer rules can be: give priority to selecting the unit asset with the longest corresponding signature sequence as the asset to be transferred, or give priority to selecting the unit asset with the shortest corresponding signature sequence as the asset to be transferred. Giving priority to selecting the unit asset with the longest corresponding signature sequence as the asset to be transferred can, to a certain extent, provide a basis for subsequent analysis and determination of the purpose of each unit asset based on the transfer path of each unit asset (that is, the account identification sequence corresponding to the unit asset), and then determine the account at risk. Accounts at risk may include but are not limited to: accounts applied for by black and gray industries for the purpose of concealing assets and other accounts used for illegal activities.

[0129] In this implementation, the third-party payment platform can perform an asset transfer after receiving an asset transfer instruction instructing the transfer. Accordingly, before detecting that the first account has received the first asset transferred from the second account, the third-party payment platform first receives an asset transfer instruction to transfer assets from the second account to the first account, wherein the asset transfer instruction may include a specific number of assets to be transferred. Then, based on a preset asset transfer rule, the third-party payment platform determines the first asset corresponding to the asset transfer instruction from the assets corresponding to the second account, i.e., determines the specific number of first assets, and transfers the first assets from the second account to the first account.

[0130] like Figure 4 As shown in the figure, assuming that the minimum unit corresponding to a unit asset is cents, and the specific number of assets to be transferred in the asset transfer instruction is 3 cents, among the 5 cents held by the second account, the signature sequence corresponding to 2 cents (i.e., unit assets 1 and 2) is [S(a), S(b), S(c), S(d), S(e)], the signature sequence corresponding to 1 cent (i.e., unit asset 3) is [S(c), S(d), S(e)], the signature sequence corresponding to 1 cent (unit asset 4) is [S(e)], and the signature sequence corresponding to 1 cent (unit asset 5) is [S(f), S(e)], where S(e) represents the signature of the second account. The third-party payment platform first determines the first asset corresponding to the asset transfer instruction, i.e., 3 cents, from the assets held by the second account based on the preset asset transfer rules.

[0131] If the asset transfer rule is to give priority to the unit asset with the longest corresponding signature sequence as the asset to be transferred, such as Figure 4As shown, the third-party payment platform identifies unit assets 1, 2, and 3 as first assets and transfers them to the first account. Subsequently, after detecting that the first account has received unit assets 1, 2, and 3, the third-party payment platform adds the first account's first signature S(x) to the signature sequences corresponding to unit assets 1, 2, and 3, respectively. That is, the signature sequences corresponding to unit assets 1 and 2 are updated to [S(a), S(b), S(c), S(d), S(e), S(x)]; the signature sequence corresponding to unit asset 3 is updated to [S(c), S(d), S(e), S(x)].

[0132] For example, let's assume that the second account holds two assets, Asset A and Asset B, which correspond to different signature sequences. Asset A and Asset B are both denominated in RMB, with Asset A valued at 100 yuan and Asset B valued at 90 yuan. The second account needs to transfer 150 yuan to the first account. Accordingly, the third-party payment platform determines 150 yuan as the first asset from the 100 yuan in Asset A and the 90 yuan in Asset B.

[0133] Among them, if the asset transfer rule is: give priority to selecting the unit asset with the longest corresponding signature sequence as the asset to be transferred, and the signature sequence corresponding to Unit Asset A of 100 yuan is longer than the signature sequence corresponding to Unit Asset B of 90 yuan. The third-party payment platform determines the 100 yuan of Unit Asset A and 50 yuan of the 90 yuan of Unit Asset B as the first asset and transfers the first asset to the first account. Accordingly, the first account obtains the first asset, including Unit Asset A of 100 yuan and 50 yuan of the 90 yuan of Unit Asset B. Among them, 50 yuan of the 90 yuan of Unit Asset B is treated as a separate unit asset, such as Unit Asset C. The third-party payment platform adds the first signature to the signature sequences corresponding to Unit Asset A of 100 yuan and Unit Asset C respectively (which are equivalent to the signature sequence corresponding to Unit Asset B). In one case, the remaining 40 yuan of the 90 yuan of Unit Asset B held by the second account is used as the new Unit Asset B, and its corresponding signature sequence remains unchanged.

[0134] In another embodiment of the present specification, the method may further include the following steps 51-52:

[0135] Step 51: using the current platform public key corresponding to the current platform private key, decrypt the signature sequence corresponding to each target unit asset in the target asset range of the third-party payment platform to obtain the ciphertext sequence of each account identification corresponding to each target unit asset.

[0136] Step 52: Based on each account identification ciphertext sequence and the pre-stored correspondence between the account identification ciphertext and the account identification of each account, determine each account identification sequence corresponding to each target unit asset.

[0137] In this implementation, when there's a need to obtain the transfer path of certain assets, the target asset range can be determined first. Then, using the current platform public key corresponding to the current platform private key, each signature in the signature sequence corresponding to each target unit asset within the target asset range on the third-party payment platform can be decrypted to obtain the corresponding account identification ciphertext sequence for each target unit asset. The account identification ciphertext sequence corresponding to the target unit asset is a sequence consisting of the current account identification ciphertexts of each account that the target unit asset passes through in sequence.

[0138] After obtaining the account identification ciphertext sequence corresponding to each target unit asset, the correspondence between the account identification ciphertext and the account identifier of each account is obtained from the preset storage space as a first correspondence. For example, if the account identification ciphertext is the result of a hash operation of the account identifier, the first correspondence may be the correspondence between the account identifier and its hash value. For the account identification ciphertext sequence corresponding to each target unit asset, the account identifier corresponding to each account identification ciphertext is determined based on the first correspondence, thereby obtaining the account identification sequence corresponding to each target unit asset, which can also be referred to as the transfer path corresponding to each target unit asset.

[0139] In one case, the target asset range includes one of the following: all assets stored in a third-party payment platform; assets that have been transferred within a predetermined time range; and assets transferred to a bank card account.

[0140] Among them, all assets stored in the third-party payment platform can refer to all assets flowing into the third-party payment platform (including: all assets currently existing in the third-party payment platform and all assets that have been transferred to bank card accounts); it can also refer to all assets currently existing in the third-party payment platform.

[0141] The assets that have been transferred within the aforementioned predetermined time range may refer to the assets monitored by the third-party payment platform as flowing into or out of the third-party payment platform within a predetermined time range, as well as the assets transferred between accounts on the third-party payment platform within the predetermined time range. For example, an acquisition cycle for acquiring the transfer path of assets may be pre-set. Whenever an acquisition cycle arrives, the assets monitored by the third-party payment platform as flowing into or out of the third-party payment platform during the period between the previous acquisition cycle and the current acquisition cycle, as well as the assets transferred between accounts on the third-party payment platform during the period, are identified as assets within the target asset range. The period between the previous acquisition cycle and the current acquisition cycle is the predetermined time range.

[0142] In one implementation, the account identifiers in the account identifier sequence corresponding to each unit asset may only include the account identifier of the third-party payment platform account. That is, transfers between accounts on the third-party payment platform and bank card accounts are not added to the account identifier sequence corresponding to the unit asset, but are stored separately.

[0143] In another implementation, the account identifiers in the account identifier sequence corresponding to each unit asset may include both the account identifier of the third-party payment platform account and the related bank card account. Among them, the related bank card account may include: the bank card account that serves as the asset transfer-out account when the third-party payment platform transfers out the asset. In one case, when the unit asset is transferred from the bank card account to the third-party payment platform (such as the mth account), when generating a signature sequence including the signature of the mth account for the unit asset, the signature of the corresponding bank card account (obtained by signing the ciphertext of the account identifier of the bank card account based on the current platform private key) may also be added to the signature sequence, that is, in this case, the above-mentioned related bank card account may also include the bank card account that transfers the asset to the third-party payment platform. The account identifier ciphertext of the bank card account may be the summary information obtained by performing a hash operation on the account identifier of the bank card account, and the account identifier of the bank card account may be all or part of the sequence value in the bank card account.

[0144] In another embodiment of the present specification, the method may further include the following steps 53-54:

[0145] Step 53: Based on the account identification sequences corresponding to the target unit assets, the associated statistical information of each account identification is determined.

[0146] Step 54: Based on the associated statistical information of each account identifier, target accounts that meet the preset risk rules are determined as risk accounts.

[0147] In this embodiment, after determining the respective account identification sequences corresponding to the respective target unit assets, the third-party payment platform can analyze and determine each account based on the above-mentioned respective account identification sequences to determine whether the account is a risk account, that is, whether it is an account applied for by the black and gray industries for the purpose of concealing assets or other accounts used for illegal activities. Specifically, the third-party payment platform determines the associated statistical information of each account identification based on the respective account identification sequences corresponding to the respective target unit assets. In one implementation, the above-mentioned associated statistical information may include: the number of occurrences of each account identification in each account identification sequence (that is, all account identification sequences), and when each account identification appears in each account identification sequence, it is the source account of its upstream previous account, and / or the destination account of its downstream subsequent account. Furthermore, based on the associated statistical information of each account identification, the target account that meets the preset risk rules is determined as a risk account.

[0148] It is understood that the associated statistical information may also include other content, such as the number of source accounts corresponding to the account identifier and the number of destination accounts corresponding to the account identifier. The above is merely an example of the content included in the associated statistical information and is not intended to be limiting. The specific content included in the associated statistical information can be set as needed.

[0149] For example, if Figure 5A As shown, assume that the target unit assets include: target unit asset 1, target unit asset 2, and target unit asset 3. Among them, the transfer path corresponding to target unit asset 1 is: account a -> account b -> account c -> account d (for simplicity, a, b, c, d represent accounts and their account identifiers; the above transfer path can also be expressed as a -> b -> c -> d).

[0150] The transfer path corresponding to target unit asset 2 is: account a->account c->account b->account e->account t (this transfer path can also be expressed as a->c->b->e->t).

[0151] The transfer path corresponding to the target unit asset 3 is: account d->account e->account f (this transfer path can also be expressed as d->e->f).

[0152] Among them, based on the above-mentioned target unit assets, in the associated statistical information of each account identifier determined, the number of occurrences of each account identifier in the transfer path obtained by statistics is as follows: the number of occurrences of accounts (i.e., account identifiers) a, b, c, d and e is 2 (all appear in two transfer paths); the number of occurrences of accounts f and t is 1 (all appear in one transfer path).

[0153] When each account identifier appears, the source account of the previous upstream account and the destination account of the next downstream account are shown as follows: Figure 5B As shown, they are:

[0154] The source account corresponding to account a is: None; the corresponding destination accounts are: account b and account c.

[0155] The source accounts corresponding to account b are: account a and account c; the corresponding destination accounts are: account c and account e.

[0156] The source accounts corresponding to account c are: account b and account a; the corresponding destination accounts are: account d and account b.

[0157] The source account corresponding to account d is account c; the corresponding destination account is account e.

[0158] The source accounts corresponding to account e are account b and account d; the corresponding destination accounts are account f and account t.

[0159] The source account corresponding to account f is: account e; the corresponding destination account is: none.

[0160] The source account corresponding to account t is: account e; the corresponding destination account is: none.

[0161] Among them, when a certain account identifier appears, the source account of its upstream previous account is: None, which can be understood as: First, when the account identifier in the account identifier sequence only includes the account identifier of the third-party payment platform account, the source account of the account identifier is a bank card account (correspondingly, the source account of account a is a bank card account); Second, when the account identifier in the account identifier sequence includes both the account identifier of the third-party payment platform account and the relevant bank card account, the account identifier is a bank card account identifier (correspondingly, account a is a bank card account identifier).

[0162] Correspondingly, when a certain account identifier appears, the destination account of its downstream subsequent account is: None, which can be understood as follows: First, when the account identifier in the account identifier sequence only includes the account identifier of the third-party payment platform account, it indicates that the destination account is a bank card account, or the corresponding target unit asset exists in the account and has not been transferred (correspondingly, the destination account corresponding to account f and account t may be a bank card account, or the target unit asset 2 may exist in account t and has not been transferred, and the target unit asset 3 may exist in account f and has not been transferred); Second, when the account identifier in the account identifier sequence includes both the account identifier of the third-party payment platform account and the relevant bank card account identifier, it indicates that the corresponding account may be a bank card account, or the corresponding target unit asset may exist in the account and has not been transferred (correspondingly, account f and account t may be bank card accounts, or the target unit asset 2 may exist in account t and has not been transferred, and the target unit asset 3 may exist in account f and has not been transferred).

[0163] In one implementation, the preset risk rules are associated with the content included in the associated statistical information, that is, the preset risk rules are set based on the content included in the associated statistical information. Accordingly, based on the content included in the associated statistical information, step 54 may include the following steps 541, 542, and / or 543, wherein step 541 is configured to: determine the account identifier whose number of appearances exceeds a preset threshold as the account identifier of the target account. In one scenario, considering that when black and gray industries use third-party payment platforms to launder money, their registered accounts may experience large-scale asset transfers, in view of this, in this step, when the associated statistical information includes the number of appearances of each account identifier in the above-mentioned sequence of all account identifiers, the account identifier whose number of appearances exceeds the preset threshold is determined as the account identifier of the target account, and then the target account is determined as a risky account.

[0164] Wherein, step 542 is configured to: determine the account identifiers of the source accounts whose number exceeds a first number as the account identifiers of the target accounts. The first number is set according to actual conditions.

[0165] In one case, considering that when black and gray industries use third-party payment platforms to launder money, they may break up assets and transfer them into multiple accounts separately, and then use these multiple accounts to falsify the use of the assets (fake them into assets corresponding to different transfer paths, i.e., account identification sequences). Subsequently, the broken up assets are transferred into the same account from different transfer paths to fake the merchant's receipt of payments, so as to avoid the problem of a certain account transferring too many assets at one time and attracting regulatory attention. In view of the above situation, in this implementation method, the number of source accounts corresponding to each account identifier can be determined based on the statistics of the source accounts of the previous upstream account when each account identifier included in the above-mentioned associated statistical information appears, and the account identifier whose number of source accounts exceeds the first number is determined as the account identifier of the target account, and then the determined target account is determined as a risk account.

[0166] Wherein, step 543 is set as follows: if there are more than a second number of different accounts sharing the same account identifier as the source account, then the same account identifier is determined as the account identifier of the target account. The second number is set according to actual conditions.

[0167] Taking into account that when black and gray industries use third-party payment platforms to launder money, they may break up assets and transfer them into multiple accounts separately, and then use these multiple accounts to falsify the use of the assets (falsify them into assets corresponding to different transfer paths, i.e., account identification sequences) to achieve their goals. In view of the above situation, in this implementation method, it is possible to first determine whether there are more than a second number of different accounts sharing the same account identifier as the source account based on the statistics of the source account of each account identifier included in the above-mentioned associated statistical information when it appears as its upstream previous account. If there are more than a second number of different accounts sharing the same account identifier as the source account, then the same account identifier is determined as the account identifier of the target account to determine the risk account. For example, the accounts corresponding to account identifiers 1-100 (100 accounts) share the same account identifier A as the source account, and the second number is set to 99. Accordingly, the account identifier A can be determined as the account identifier of the target account, that is, the account corresponding to account identifier A is determined to be a risk account.

[0168] In another implementation, step 54 may further include step 544: if more than a third number of different accounts share the same account identifier as the destination account, and the destination account is a bank card account, all of the accounts exceeding the third number are determined as target accounts. The third number is set based on actual circumstances.

[0169] Considering that when black and gray industries use third-party payment platforms to launder money, they may break up assets and transfer them into multiple accounts separately, and then use these multiple accounts to forge the use of the assets (forged into assets corresponding to different transfer paths, i.e., account identification sequences), that is, transfer the broken up assets to multiple different accounts registered in advance, and subsequently, transfer the assets out of the third-party payment platform through the multiple different accounts registered in advance. In view of the above situation, when the account identifiers in the generated transfer path, i.e., the account identifiers in the account identifier sequence, include both the account identifiers of the third-party payment platform account and the related bank card account, it is possible to first determine whether there are more than a third number of different accounts sharing the same account identifier as the destination account based on the statistics of the account identifiers included in the above-mentioned associated statistical information when they appear as the destination account of the downstream subsequent account; when it is determined that there are more than a third number of different accounts sharing the same account identifier as the destination account, determine whether the destination account is a bank card account; if it is still determined that the destination account is a bank card account, all the different accounts exceeding the third number are determined as target accounts, i.e., risk accounts.

[0170] Subsequently, in one implementation, the destination account of the bank card account may also be determined as a risk account.

[0171] In this embodiment, by marking the transfer path of assets entering the third-party payment platform, the use of assets can be monitored, which to a certain extent provides a basis for identifying illegal activities of black and gray industries.

[0172] The foregoing description describes specific embodiments of the present disclosure, and other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in a different order than that described in the embodiments and still achieve the desired results. In addition, the processes depicted in the accompanying drawings do not necessarily need to be performed in the specific order shown or in a sequential order to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0173] Corresponding to the above method embodiment, the embodiment of this specification provides an apparatus 300 for transferring assets in a payment platform, which is applied to a third-party payment platform. The schematic block diagram thereof is shown as follows: Figure 6 Shown, including:

[0174] A first obtaining module 610 is configured to, upon detecting that a first account receives a first asset transferred from a second account, obtain a signature sequence corresponding to each first unit of the first asset, the signature sequence including signature information of the accounts through which the corresponding first unit of the asset passes in sequence;

[0175] A second obtaining module 620 is configured to obtain a first signature corresponding to the first account;

[0176] The adding module 630 is configured to add the first signature to the signature sequence corresponding to each first unit asset.

[0177] In one embodiment, the second obtaining module 620 is specifically configured to obtain the first signature from a preset storage space, wherein the first signature is obtained by signing the first account identifier ciphertext of the first account based on the current platform private key in advance; or

[0178] The second obtaining module 620 is specifically configured to use the current platform private key to sign the first account identification ciphertext of the first account to obtain the first signature.

[0179] In one possible implementation, the first account identification ciphertext is summary information obtained by performing a hash operation on the account identification of the first account.

[0180] In one embodiment, it further includes:

[0181] A first decryption module (not shown in the figure) is configured to, upon detecting that the current platform private key and its corresponding current platform public key are updated, use the current platform public key to decrypt the signature sequence corresponding to each unit asset stored on the third-party payment platform to obtain the account identification ciphertext sequence corresponding to each unit asset;

[0182] The first signature module (not shown in the figure) is configured to use the updated platform private key to sign each account identification ciphertext in the account identification ciphertext sequence corresponding to each unit asset, and obtain an updated signature sequence corresponding to each unit asset.

[0183] In one embodiment, it further includes:

[0184] A generation module (not shown in the figure) is configured to generate a corresponding new signature sequence for each second unit asset in the second asset when detecting that the third account receives the second asset transferred from the bank card account, wherein the new signature sequence includes the third signature corresponding to the third account.

[0185] In one possible implementation, each first unit asset is the smallest unit asset of the currency to which it belongs; or, each first unit asset is an asset corresponding to a different signature sequence.

[0186] In one embodiment, it further includes:

[0187] an instruction receiving module (not shown in the figure), configured to receive an asset transfer instruction for transferring assets from the second account to the first account before detecting that the first account receives the first asset transferred from the second account;

[0188] a first determining module (not shown) configured to determine, from the assets held by the second account, the first asset corresponding to the asset transfer instruction based on a preset asset transfer rule, wherein the asset transfer rule is related to a signature sequence corresponding to each unit asset in the held assets;

[0189] A transfer module (not shown in the figure) is configured to transfer the first asset from the second account to the first account.

[0190] In one possible implementation, the asset transfer rule is: preferentially selecting the unit asset with the longest corresponding signature sequence as the asset to be transferred, or preferentially selecting the unit asset with the shortest corresponding signature sequence as the asset to be transferred.

[0191] In one embodiment, it further includes:

[0192] A second decryption module (not shown in the figure) is configured to use the current platform public key corresponding to the current platform private key to decrypt the signature sequence corresponding to each target unit asset in the target asset range of the third-party payment platform, and obtain the account identification ciphertext sequence corresponding to each target unit asset;

[0193] The second determination module (not shown) is configured to determine the account identification sequences corresponding to the target unit assets based on the account identification ciphertext sequences and the pre-stored correspondence between the account identification ciphertexts and account identifications of the accounts.

[0194] In one possible implementation, the target asset range includes one of the following: all assets stored in the third-party payment platform; assets that have been transferred within a predetermined time range; and assets transferred to a bank card account.

[0195] In one embodiment, it further includes:

[0196] A third determining module (not shown in the figure) is configured to determine associated statistical information of each account identifier based on each account identifier sequence corresponding to each target unit asset;

[0197] The fourth determining module (not shown in the figure) is configured to determine target accounts that meet preset risk rules as risk accounts based on the associated statistical information of each account identifier.

[0198] In one embodiment, the associated statistical information includes: the number of occurrences of each account identifier in the sequence of each account identifier, and the source account of the upstream previous account and / or the destination account of the downstream next account when the account identifier appears.

[0199] In one possible implementation, the fourth determining module is specifically configured to determine the account identifier whose number of appearances exceeds a preset number threshold as the account identifier of the target account; and / or

[0200] Determine the account identifiers of source accounts whose number exceeds the first number as the account identifiers of the target accounts; and / or

[0201] If there are more than a second number of different accounts sharing the same account identifier as the source account, the same account identifier is determined as the account identifier of the target account.

[0202] In one embodiment, it further includes:

[0203] The fifth determination module (not shown in the figure) is configured to determine all of the more than third number of different accounts as target accounts if there are more than a third number of different accounts sharing the same account identifier as the destination account, and the destination account is a bank card account.

[0204] The above-mentioned device embodiments correspond to the method embodiments. For detailed descriptions, please refer to the description of the method embodiments, which will not be repeated here. The device embodiments are obtained based on the corresponding method embodiments and have the same technical effects as the corresponding method embodiments. For detailed descriptions, please refer to the corresponding method embodiments.

[0205] The embodiments of this specification also provide a computer-readable storage medium having a computer program stored thereon. When the computer program is executed in a computer, the computer is caused to execute the method for transferring assets in the payment platform provided in this specification.

[0206] An embodiment of this specification also provides a computing device, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the method for transferring assets in the payment platform provided in this specification is implemented.

[0207] The various embodiments in this specification are described in a progressive manner. Similar portions between the various embodiments can be referenced to each other, and each embodiment focuses on the differences between the other embodiments. In particular, the storage medium and computing device embodiments are described briefly because they are generally similar to the method embodiments. For relevant portions, refer to the description of the method embodiments.

[0208] Those skilled in the art will appreciate that, in one or more of the above examples, the functions described in the embodiments of the present invention may be implemented using hardware, software, firmware, or any combination thereof. When implemented using software, these functions may be stored in a computer-readable medium or transmitted as one or more instructions or codes on a computer-readable medium.

[0209] The specific implementation methods described above further illustrate the purpose, technical solutions, and beneficial effects of the embodiments of the present invention. It should be understood that the above description is only a specific implementation method of the embodiments of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent replacements, improvements, etc. made on the basis of the technical solutions of the present invention shall be included in the scope of protection of the present invention.

Claims

1. A method for transferring assets in a payment platform, applied to a third-party payment platform, comprising: Upon detecting that a first account receives a first asset transferred from a second account, obtaining a signature sequence corresponding to each of at least one first unit asset included in the first asset, the signature sequence including signature information of the accounts through which the corresponding unit asset passes in sequence; each first unit asset is the smallest unit asset of the currency to which it belongs; Alternatively, each first unit asset is an asset corresponding to a different signature sequence; Obtaining a first signature corresponding to the first account; The first signature is added to the signature sequence corresponding to each first unit asset.

2. The method according to claim 1, wherein obtaining the first signature corresponding to the first account comprises: Obtaining the first signature from a preset storage space, wherein the first signature is obtained by pre-signing a ciphertext of the first account identifier of the first account based on a current platform private key; or The first account identification ciphertext of the first account is signed using the current platform private key to obtain the first signature.

3. The method according to claim 2, wherein: The first account identification ciphertext is summary information obtained by performing a hash operation on the account identification of the first account.

4. The method according to claim 2, further comprising: If it is detected that the current platform private key and its corresponding current platform public key are updated, the signature sequence corresponding to each unit asset stored on the third-party payment platform is decrypted using the current platform public key to obtain the account identification ciphertext sequence corresponding to each unit asset; Use the updated platform private key to sign each account identification ciphertext in the account identification ciphertext sequence corresponding to each unit asset to obtain an updated signature sequence corresponding to each unit asset.

5. The method according to claim 1, further comprising: When it is detected that the third account receives the second asset transferred from the bank card account, a corresponding new signature sequence is generated for each second unit asset in the second asset, wherein the new signature sequence includes the third signature corresponding to the third account.

6. The method according to any one of claims 1 to 5, wherein: Before detecting that the first account receives the first asset transferred from the second account, the method further includes: receiving an asset transfer instruction to transfer assets from the second account to the first account; Determining, from the assets held by the second account, a first asset corresponding to the asset transfer instruction based on a preset asset transfer rule, wherein the asset transfer rule is related to a signature sequence corresponding to each unit of the held assets; The first asset is transferred from the second account to the first account.

7. The method according to claim 6, wherein: The asset transfer rule is: give priority to selecting the unit asset with the longest corresponding signature sequence as the asset to be transferred, or give priority to selecting the unit asset with the shortest corresponding signature sequence as the asset to be transferred.

8. The method according to claim 2, further comprising: Using the current platform public key corresponding to the current platform private key, decrypt the signature sequence corresponding to each target unit asset in the target asset range of the third-party payment platform to obtain the ciphertext sequence of each account identification corresponding to each target unit asset; Based on the respective account identification ciphertext sequences and the pre-stored correspondence between the account identification ciphertexts and the account identifications of the respective accounts, the respective account identification sequences corresponding to the respective target unit assets are determined.

9. The method according to claim 8, wherein The target assets include any of the following: All assets stored on the third-party payment platform; Assets that have been transferred within a predetermined timeframe; Assets transferred to bank card accounts.

10. The method according to claim 8, further comprising: Determine the associated statistical information of each account identifier based on the respective account identifier sequences corresponding to the respective target unit assets; Based on the associated statistical information of each account identifier, target accounts that meet the preset risk rules are determined as risk accounts.

11. The method according to claim 10, wherein: The association statistics information includes: the number of occurrences of each account identifier in the sequence of each account identifier, and the source account of the previous upstream account and / or the destination account of the next downstream account when the account identifier appears.

12. The method according to claim 11, wherein The step of determining a target account that meets a preset risk determination rule as a risk account includes: Determine the account identifier that appears more than a preset threshold number of times as the account identifier of the target account; and / or Determine the account identifiers of source accounts whose number exceeds the first number as the account identifiers of the target accounts; and / or If there are more than a second number of different accounts sharing the same account identifier as the source account, the same account identifier is determined as the account identifier of the target account.

13. The method according to claim 11, further comprising: If there are more than a third number of different accounts that share the same account identifier as the destination account, and the destination account is a bank card account, then the more than the third number of different accounts are all determined as target accounts.

14. A device for transferring assets in a payment platform, applied to a third-party payment platform, comprising: A first obtaining module is configured to, upon detecting that a first account receives a first asset transferred from a second account, obtain a signature sequence corresponding to each of at least one first unit asset included in the first asset, wherein the signature sequence includes signature information of accounts through which the corresponding first unit asset passes in sequence; each first unit asset is the smallest unit asset of the currency to which it belongs; Alternatively, each first unit asset is an asset corresponding to a different signature sequence; a second obtaining module, configured to obtain a first signature corresponding to the first account; The adding module is configured to add the first signature to the signature sequence corresponding to each first unit asset.

15. A computing device comprising a memory and a processor, wherein: The memory stores executable code, and when the processor executes the executable code, the method according to any one of claims 1 to 13 is implemented.

Images