Risk data processing method, apparatus and system

Abstract

The application discloses a risk data processing method, device and system, and relates to the technical field of computers. A specific implementation manner of the method comprises the following steps: acquiring a plurality of pieces of risk data from a preset blockchain and storing the risk data locally; wherein, the risk data is written into the blockchain in advance by a plurality of data providers, any piece of risk data provided by any data provider comprises a risk subject identifier and a risk level determined by the data provider for the risk subject identifier; in response to receiving a risk query request sent by a user end, determining the risk data corresponding to a risk subject identifier carried in the risk query request in the local data, and returning a query result comprising the risk level in the determined risk data to the user end. The implementation manner can improve the availability of risk data and the risk prevention capability of enterprises.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a risk data processing method, apparatus, and system. Background Technology

[0002] Currently, internet companies typically use artificial intelligence technologies such as machine learning, deep learning, and graph computing to create risk profiles of phone numbers and IP addresses, ultimately generating risk data on these information and their risk levels. This data is then used to prevent risky behaviors during registration, login, marketing, order processing, and payment. However, because risk data cannot be shared or integrated between companies, and because the risk level calculation mechanisms and logic differ, it is difficult for enterprise users who need this risk data to select and use it effectively, which is detrimental to risk prevention and business security. Summary of the Invention

[0003] In view of this, embodiments of the present invention provide a risk data processing method, apparatus and system that can integrate and merge risk data from multiple data providers and centrally provide query services to users, while storing relevant data through blockchain for traceability, thereby effectively improving the availability of risk data and the risk prevention capabilities of enterprises.

[0004] To achieve the above objectives, according to one aspect of the present invention, a risk data processing method is provided.

[0005] The risk data processing method of this invention includes: obtaining multiple pieces of risk data from a preset blockchain and storing them locally; wherein the risk data is pre-written into the blockchain by multiple data providers, and any risk data provided by any data provider includes a risk subject identifier and a risk level determined by the data provider for the risk subject identifier; in response to receiving a risk query request sent by a user terminal, determining the risk data corresponding to the risk subject identifier carried in the risk query request in the local data, and returning the query result including the risk level in the determined risk data to the user terminal.

[0006] Optionally, the step of obtaining multiple risk data from a preset blockchain and storing them locally includes: for any risk data provided by any data provider: if it is determined that no risk data with the same risk subject identifier provided by the data provider exists locally, the risk data is stored locally; if it is determined that risk data with the same risk subject identifier exists locally, the risk data with the same risk subject identifier is replaced with the risk data.

[0007] Optionally, any risk data further includes a risk subject identifier and an applicable scenario for the risk level, and the risk query request further carries the applicable scenario; and, determining the risk data corresponding to the risk subject identifier carried in the risk query request in the local data includes: determining the risk data corresponding to the risk subject identifier and the applicable scenario carried in the risk query request in the local data.

[0008] Optionally, any risk data further includes the validity period of the risk data; and the step of determining the risk data corresponding to the risk subject identifier carried in the risk query request in the local data, and returning the query result including the risk level in the determined risk data to the user terminal includes: determining the risk data in the local data that corresponds to the risk subject identifier and applicable scenario carried in the risk query request and is in a valid state, and using the determined risk data as the target risk data; and returning the query result including the risk level in the target risk data to the user terminal.

[0009] Optionally, the risk query request further carries a false positive tolerance; and the step of returning the query result, including the risk level in the target risk data, to the user includes: when the number of target risk data is one, or when the number of target risk data is multiple and the multiple target risk data contain the same risk level, determining the risk level in the target risk data as the risk level in the query result; when the number of target risk data is multiple and the multiple target risk data contain different risk levels: if the false positive tolerance indicates high false positive tolerance, then determining the highest risk level among the different risk levels as the risk level in the query result; if the false positive tolerance indicates low false positive tolerance, then determining the lowest risk level among the different risk levels as the risk level in the query result.

[0010] Optionally, the method further includes: after returning the query results to the user terminal, determining the value data of a single query by the user terminal based on the pre-stored historical transaction records of the user terminal; determining the contribution of each data provider based on the number of data providers providing the risk level in the query results; and performing a profit-sharing operation on each data provider based on the value data and the contribution of each data provider.

[0011] Optionally, the method further includes: after returning the query result to the user terminal, receiving feedback information from the user terminal regarding the query result; determining the value data of a single query by the user terminal based on pre-stored historical transaction records of the user terminal; determining the contribution of each data provider based on the number of data providers providing risk levels in the query result and the feedback information; and performing a profit-sharing operation on each data provider based on the value data and the contribution of each data provider.

[0012] Optionally, the historical transaction records are pre-written into the blockchain, and the historical transaction records include: user identifier, transaction amount, and total number of queries; and the method further includes: after returning the query result to the user, generating a corresponding query record and writing it into the blockchain for the data provider to query; the query record includes: user identifier, risk subject identifier carried in the risk query request, the query result, the identifier of the data provider providing the risk level in the query result, and the query time; after receiving the feedback information, generating a corresponding feedback record based on the feedback information and writing it into the blockchain for the data provider to query.

[0013] Optionally, the method further includes: after determining the contribution of each data provider, generating contribution data including the identifier of the data provider providing the risk level in the query results, the contribution, and the corresponding query record identifier, and writing it into the blockchain for the data provider to query; after performing the profit-sharing operation, generating a profit-sharing record including the profit-sharing result and the corresponding contribution data identifier and writing it into the blockchain for the data provider to query.

[0014] Optionally, the blockchain is maintained by the plurality of data providers, the risk data further includes data source and risk tags characterizing risk type, the query result further includes the risk tags, and the risk subject identifier includes mobile terminal number and / or IP address; the step of obtaining multiple pieces of risk data from the preset blockchain and storing them locally includes: receiving multiple pieces of risk data pushed by the blockchain through the execution of a pre-deployed smart contract; the smart contract is used to perform the push when there is new or updated risk data in the blockchain; the method further includes: in response to receiving the risk query request, when it is determined that the target risk data does not exist in the local data, returning information of no matching result to the user terminal.

[0015] To achieve the above objectives, according to another aspect of the present invention, a risk data processing apparatus is provided.

[0016] The risk data processing apparatus of this invention may include: a data synchronization unit, configured to acquire multiple risk data entries from a preset blockchain and store them locally; wherein the risk data is pre-written into the blockchain by multiple data providers, and any risk data provided by any data provider includes a risk subject identifier and a risk level determined by the data provider for the risk subject identifier; and an external service unit, configured to: in response to receiving a risk query request sent by a user terminal, determine the risk data corresponding to the risk subject identifier carried in the risk query request in the local data, and return the query result including the risk level in the determined risk data to the user terminal.

[0017] To achieve the above objectives, according to another aspect of the present invention, a risk data processing system is provided.

[0018] The risk data processing system of this invention may include: multiple data providers, a blockchain maintained by the multiple data providers, and a risk identification system; the risk identification system obtains multiple risk data from a preset blockchain and stores them locally; wherein, the risk data is pre-written into the blockchain by the multiple data providers, and any risk data provided by any data provider includes a risk subject identifier and a risk level determined by the data provider for the risk subject identifier; in response to receiving a risk query request sent by a user terminal, the risk identification system determines the risk data corresponding to the risk subject identifier carried in the risk query request in the local data, and returns the query result including the risk level in the determined risk data to the user terminal.

[0019] Optionally, after returning the query results to the user terminal, the risk identification system receives feedback information from the user terminal regarding the query results. Based on pre-stored historical transaction records of the user terminal, it determines the value data of a single query by the user terminal. It then determines the contribution of each data provider based on the number of data providers offering risk levels in the query results and the feedback information. Based on the value data and the contribution of each data provider, it performs a revenue-sharing operation with each data provider. The historical transaction records are pre-written into the blockchain by the risk identification system and include: user identifier, transaction amount, and total number of queries. After returning the query results to the user terminal, the risk identification system generates corresponding query records and writes them into the blockchain for the data providers to query. The query record includes: user identifier, risk subject identifier carried in the risk query request, query result, identifier of the data provider providing the risk level in the query result, and query time; after receiving the feedback information, the risk identification system generates a corresponding feedback record based on the feedback information and writes it into the blockchain for the data provider to query; after determining the contribution of each data provider, the risk identification system generates contribution data including the identifier of the data provider providing the risk level in the query result, the contribution level, and the corresponding query record identifier and writes it into the blockchain for the data provider to query; after executing the profit sharing operation, the risk identification system generates a profit sharing record including the profit sharing result and the corresponding contribution data identifier and writes it into the blockchain for the data provider to query.

[0020] To achieve the above objectives, according to another aspect of the present invention, an electronic device is provided.

[0021] An electronic device according to the present invention includes: one or more processors; and a storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the risk data processing method provided by the present invention.

[0022] To achieve the above objectives, according to another aspect of the present invention, a computer-readable storage medium is provided.

[0023] The present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the risk data processing method provided by the present invention.

[0024] According to the technical solution of the present invention, the embodiments described above have the following advantages or beneficial effects:

[0025] After multiple data providers upload their risk data to the blockchain, the blockchain automatically synchronizes newly added or updated risk data to the risk identification system through smart contracts. The risk identification system can then provide risk data query services to users via an interface. When a user initiates a risk query request for a specific phone number or IP address, the system identifies the corresponding valid risk data from its local data, integrates this data into a query result, and returns it to the user. This achieves risk data sharing and fusion among data providers, improving the availability of risk data and enhancing the enterprise's risk prevention capabilities. The blockchain also ensures data security and traceability throughout the process. Furthermore, after providing query services, the risk identification system can reasonably determine the contribution of each data provider based on the user's historical transaction records, query records, and feedback records. Based on this contribution, the system distributes profits to the data providers, and writes these historical transaction records, query records, feedback records, contribution data, and profit-sharing records to the blockchain. This achieves efficient and fair value distribution, as well as the queryability and traceability of profit-sharing records.

[0026] The further effects of the aforementioned unconventional alternative methods will be explained below in conjunction with specific implementation methods. Attached Figure Description

[0027] The accompanying drawings are provided to better understand the invention and are not intended to unduly limit the scope of the invention. Wherein:

[0028] Figure 1 This is a schematic diagram of the main steps of the risk data processing method in an embodiment of the present invention;

[0029] Figure 2 This is a schematic diagram of the implementation architecture of the risk data processing method in this embodiment of the invention;

[0030] Figure 3 This is a schematic diagram of the components of the risk data processing device in an embodiment of the present invention;

[0031] Figure 4 This is a schematic diagram of the components of the risk data processing system in an embodiment of the present invention;

[0032] Figure 5 This is an exemplary system architecture diagram that can be applied thereto according to embodiments of the present invention;

[0033] Figure 6 This is a schematic diagram of the electronic device structure used to implement the risk data processing method in the embodiments of the present invention. Detailed Implementation

[0034] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of the present invention, including various details to aid understanding. These details should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the invention. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0035] It should be noted that, unless otherwise specified, the embodiments of the present invention and the technical features thereof can be combined with each other.

[0036] Figure 1 This is a schematic diagram of the main steps of the risk data processing method according to an embodiment of the present invention.

[0037] like Figure 1 As shown, the risk data processing method of this invention can be derived from... Figure 2 The risk identification system in the illustrated architecture executes through the following specific steps:

[0038] Step S101: Obtain multiple risk data entries from a pre-defined blockchain and store them locally.

[0039] In this embodiment of the invention, blockchain technology can be used to process risky data. Blockchain is an integrated and innovative application model that combines computer technologies such as distributed storage, peer-to-peer data transmission, consensus mechanisms, and encryption algorithms. In simple terms, blockchain is an organizational structure for information resources, logically a linked list of one or more blocks. A block stores one or more information resources such as transaction records or smart contracts. Each node in a distributed blockchain network (hereinafter referred to as a blockchain network) stores the same blockchain, and the blockchain network consists of these nodes that store the blockchain.

[0040] Based on their application scope and the accessibility of nodes, blockchains can be divided into public blockchains, private blockchains, and consortium blockchains. Public blockchains are open to everyone on the internet, such as Bitcoin and Ethereum. Private blockchains are generally used internally by organizations and are not open to others. Consortium blockchains are open to specific organizations and institutions. The following explains some of the terms used in the embodiments of this invention:

[0041] Consensus: A blockchain term. There is no single central ledger on a blockchain; the ledger is recorded collectively by the entire network. This raises the question of how to determine the legitimacy of a transaction. The process of determining the legitimacy of a transaction and whether a block recommended by a node is accepted by everyone is called consensus. Only blocks that pass consensus are recognized by the entire network.

[0042] Smart contracts are pieces of code on the blockchain that define the rights, obligations, and terms of action for the parties involved. Parties confirm smart contracts, pay for necessary digital payments, and invoke functions defined by the smart contracts by sending blockchain transactions.

[0043] See Figure 2 Multiple data providers (i.e., enterprises that generate risk data) form a blockchain network by interconnecting with each other. Each data provider acts as a node in the blockchain network and jointly maintains a blockchain. Each data provider can write its own risk data into the blockchain to achieve reliable storage and immutability of the risk data. It should be noted that the blockchain in this embodiment of the invention is preferably a consortium blockchain. The process of writing relevant data into the blockchain includes the data reaching consensus throughout the entire blockchain network and being synchronized to every node of the blockchain network. Any consensus mechanism such as PoW (Proof of Work) or PoS (Proof of Stake) can be used.

[0044] The blockchain can also synchronize new or updated risk data to the risk identification system by executing pre-deployed smart contracts. The risk identification system can then provide risk data query services based on the latest risk data stored locally, thereby achieving the integration of risk data from multiple platforms and the convenience of risk query while ensuring data security.

[0045] In practical applications, any risk data may include a risk subject identifier and a risk level determined by the data provider for that risk subject identifier. The risk subject identifier, as the subject of risk assessment, may include a mobile terminal number and IP address, or other data with a similar function. The risk level can be represented by numbers or text, for example, zero points indicates no risk, 1 point indicates extremely low risk, 2 points indicates low risk, 3 points indicates medium risk, 4 points indicates medium-high risk, and 5 points indicates high risk. Generally, the higher the risk level, the more severe the risk. Optionally, the risk data may further include the risk subject identifier and the applicable scenario of the risk level. The applicable scenario is business-related and may be registration, login, marketing, orders, payments, etc. The risk data may also include the validity period of the risk data, which can be in the form of a date or remaining time. This validity period can be used to determine whether any risk data is currently valid. In some embodiments, risk data may further include data sources and risk labels characterizing risk types. For example, data sources may be proprietary and external, representing sources within and outside the data provider, respectively. Risk labels may be for mobile terminal numbers (e.g., abnormal registration, abnormal login, abnormal payment, malicious after-sales service) and for IP addresses (e.g., ordinary proxy IPs, instant-dial proxy IPs, real-person cheating, device spoofing). All of the above risk data is pre-determined by the data provider according to its own calculation rules and written into the blockchain.

[0046] In this step, the risk identification system automatically retrieves multiple risk data entries from the aforementioned blockchain and stores them locally. In practical applications, after the blockchain stores newly added or updated risk data (updating refers to adding risk data with the same risk subject identifier), a pre-deployed smart contract is executed to push this risk data to the risk identification system, thereby achieving synchronization of risk data between the blockchain and the risk identification system. For the risk identification system, for any risk data (hereinafter referred to as first data) provided by any data provider: if it is determined that no risk data (hereinafter referred to as associated data of first data) provided by the same data provider and having the same risk subject identifier exists locally, the first data is stored locally; if it is determined that associated data of first data exists locally, the associated data is replaced with the first data. That is to say, since the data stored in the blockchain cannot be deleted or modified, the blockchain will store various versions of risk data for the same data provider and the same risk subject identifier from historical periods, but the risk identification system can store only the latest version of risk data for the same data provider and the same risk subject identifier. In practical applications, the applicable scenario can be further considered during the data synchronization process. That is, the risk identification system can store only one latest version of risk data with the same data provider, the same risk subject identifier, and the same applicable scenario.

[0047] Step S102: In response to receiving a risk query request sent by the user, determine the risk data corresponding to the risk subject identifier carried in the risk query request in the local data, and return the query results including the risk level in the determined risk data to the user.

[0048] In this step, the risk identification system can provide risk query services to user terminals based on locally stored risk data. These user terminals can be enterprise users or individual users. In practical applications, the user terminal sends a risk query request to the risk identification system targeting a specific risk entity. The risk query request can also carry the user-specified applicable scenario and the false alarm tolerance provided by the user. The false alarm tolerance can indicate high false alarm tolerance (i.e., the risk identification system can have a certain false alarm rate, which can be quantified by comparing with a preset false alarm rate threshold) or low false alarm tolerance (i.e., the false alarm rate of the risk identification system needs to be less than the false alarm rate threshold). The false alarm tolerance can have two options: "high false alarm tolerance" and "low false alarm tolerance," or it can be expressed as the highest acceptable false alarm rate.

[0049] Upon receiving the risk query request, the risk identification system can locally query risk data corresponding to the risk subject identifier in the risk query request, and generate query results based on this risk data, returning them to the user. If the risk query request includes an applicable scenario, the risk identification system can locally query risk data corresponding to both the risk subject identifier and the applicable scenario in the risk query request, and generate query results based on this risk data, returning them to the user. As a preferred approach, upon receiving a risk query request, the risk identification system identifies valid risk data in its local data that corresponds to the risk subject identifier and applicable scenario carried in the risk query request. This identified risk data is then used as the target risk data, and query results including the risk level of the target risk data are returned to the user. In specific applications, the query results may include risk tags in addition to the risk level. It is understood that if the risk identification system determines that no target risk data exists in its local data, it will return a no-match message to the user.

[0050] Preferably, the risk level in the query results is determined in the following ways: If there is only one target risk data record, or multiple target risk data records containing the same risk level, the risk level in the target risk data is determined as the risk level in the query results (referred to as the first integration strategy); if there are multiple target risk data records containing different risk levels: if the false positive tolerance in the risk query request indicates high false positive tolerance, the highest risk level among the different risk levels is determined as the risk level in the query results (referred to as the second integration strategy); if the false positive tolerance in the risk query request indicates low false positive tolerance, the lowest risk level among the different risk levels is determined as the risk level in the query results (referred to as the third integration strategy).

[0051] The principle behind the above strategies is as follows: For the second integration strategy, since users have a high tolerance for false positives, the potential adverse impact of information security and risk subject identification on business can be prioritized, while reducing or ignoring the potentially high false positive probability of high-risk levels. Therefore, the highest risk level among multiple risk levels is returned to the user. For the third integration strategy, since users do not allow a high false positive rate, and the false positive probability corresponding to high-risk levels is generally higher than that of low-risk levels, the lowest risk level among multiple risk levels is returned to the user.

[0052] Risk tags in the query results can be composed of risk tags contained in the target risk data corresponding to the risk level in the query results. Query results can then be generated based on the risk level and risk tags and returned to the user. Alternatively, query results can be generated based solely on the risk level. This allows for the sharing and integration of risk data from various data providers, improving the availability of risk data and the enterprise's risk prevention capabilities, while ensuring data security and traceability throughout the process through blockchain.

[0053] Subsequently, revenue sharing can be allocated among the relevant data providers for this query. Since users typically obtain risk query services from the risk identification system by purchasing resource packages, each query from the user's end corresponds to a value. Because the risk query service relies on risk data from various data providers, the risk identification system needs to implement a fair and reasonable revenue sharing scheme to distribute the value of each query to the relevant data providers, while ensuring the maintenance of relevant data records during the revenue sharing process so that data providers can query and verify at any time. In this embodiment of the invention, the following two revenue sharing strategies can be used:

[0054] The first profit-sharing strategy only considers the query process. Specifically, after returning the query results to the user, the risk identification system first determines the value of a single query based on pre-stored historical transaction records of the user. For example, historical transaction records can be records of user purchases of resource packages, which may include the user identifier (which could be the PIN code of the purchased resource package), transaction amount, and total number of queries. They may also include data such as resource package rules, quantity, purchase time, and expiration time. These historical transaction records are written to the blockchain by the risk identification system after generation, so that data providers can query them. In the above steps, the value of a single query can be obtained by dividing the transaction amount in the historical transaction records by the total number of queries.

[0055] Subsequently, the contribution of each data provider is determined based on the number of data providers offering risk levels in the query results. The contribution level characterizes the importance and weight of each data provider in the query process, and the sum of the contributions of all data providers can be 1 or a preset number between 1 and 0. For example, if there is only one data provider contributing to the query results, its contribution level can be calculated as 1 (without considering the profit sharing with the risk identification system itself; this is the primary example below). If the profit sharing with the risk identification system itself is considered, the contribution level of the data provider can be calculated as 0.9 (0.1 being the contribution of the risk identification system). If there are two data providers contributing to the query results, their respective contributions can be calculated as 0.5.

[0056] Finally, the risk identification system can perform revenue sharing operations on each data provider based on the value of a single query and the contribution of each data provider. The revenue shared by each data provider can be the product of the value of the single query and its contribution. In practical applications, the risk identification system can interact directly with data providers to perform revenue sharing, or it can interact with data providers through a statistical data gateway to perform revenue sharing.

[0057] The second profit-sharing strategy considers not only the query process but also user feedback on the query results. Specifically, after returning the query results to the user, the risk identification system can receive feedback information from the user regarding the query results. This feedback information can be positive (not a false alarm) or negative (a false alarm). It can be understood that the user receives corresponding feedback after performing an action based on the risk level in the query results, and then generates the above feedback information to send to the risk identification system. In the profit-sharing process, the risk identification system first determines the value data of a single query by the user based on pre-stored historical transaction records of the user. Then, it determines the contribution of each data provider based on the number of data providers providing the risk level in the query results and the above feedback information. Specifically, if the feedback information is positive, the contribution of the data provider is calculated according to the method in the first profit-sharing strategy; if the feedback information is negative, for the aforementioned first and third integration strategies, the contribution of the data provider is still calculated according to the method in the first profit-sharing strategy; if the feedback information is negative, for the aforementioned second integration strategy, the contribution of each data provider is reduced according to preset rules. Finally, the risk identification system performs a revenue-sharing operation with each data provider based on the value of the data and their contribution.

[0058] The principle behind the above contribution adjustments is that the first and third integration strategies are already conservative. If false alarms still occur, it indicates that other reasons have led to data errors, and therefore, it is not advisable to reduce the data provider's contribution and revenue share. For the second integration strategy, if revenue share is not reduced for the corresponding data provider after receiving false alarm feedback, it may incentivize the data provider to increase their risk level for profit. Therefore, an appropriate reduction in contribution can prevent this motivation. For example, if a query process executing the second integration strategy receives a false alarm from the user after a period of time, and this query process involves two data providers, the contribution can be reduced by 10% from the normal contribution of 0.5, resulting in a final contribution of 0.45 for each data provider.

[0059] Specifically, after returning the query results to the user, the risk identification system can generate corresponding query records and write them to the blockchain for data providers to query. These query records include: user identifier, risk subject identifier carried in the risk query request, query results, the identifier of the data provider providing the risk level in the query results, and the query time. Upon receiving the above feedback information, the risk identification system can generate corresponding feedback records based on the feedback information and write them to the blockchain for data providers to query. In practical applications, the above query records and feedback records can be associated with data such as user identifiers, and they can also be associated with the aforementioned historical transaction records. The risk identification system can also perform the above contribution calculation and value sharing based on the historical transaction records, query records, and feedback records corresponding to any given query.

[0060] Furthermore, after determining the contribution of each data provider, the risk identification system can generate contribution data, including the identifier of the data provider providing the risk level in the query results, their contribution level, and the corresponding query record identifier, and write this data to the blockchain for data providers to query. After executing the profit-sharing operation, the risk identification system can generate a profit-sharing record, including the profit-sharing result and the corresponding contribution data identifier, and write this record to the blockchain for data providers to query. This contribution data and profit-sharing record can be correlated with a specific query, historical transaction records, query records, and feedback records, thus comprehensively reflecting the relevant information and profit-sharing basis of a query process. Therefore, efficient and fair value sharing, as well as the secure storage, queryability, and traceability of relevant records during risk queries and profit sharing, can be achieved.

[0061] In the technical solution of this invention, after multiple data providers upload their risk data to the blockchain, the blockchain automatically synchronizes the newly added or updated risk data to the risk identification system through the execution of smart contracts. Subsequently, the risk identification system can provide risk data query services to users through an interface. When a user initiates a risk query request for a specific mobile phone number or IP address to the risk identification system, the system determines the corresponding valid risk data from its local data, integrates this risk data into query results, and returns them to the user. This achieves risk data sharing and fusion among data providers, improves the availability of risk data and the enterprise's risk prevention capabilities, and ensures data security and traceability throughout the process through the blockchain. Furthermore, after providing the query service, the risk identification system can reasonably determine the contribution of each data provider based on the user's historical transaction records, query records, and feedback records. Based on this contribution, it then distributes profits to the data providers and writes the historical transaction records, query records, feedback records, contribution data, and profit-sharing records to the blockchain, thereby achieving efficient and fair value distribution and ensuring the queryability and traceability of profit-sharing records.

[0062] It should be noted that, for the sake of ease of description, the foregoing method embodiments are described as a series of actions. However, those skilled in the art should understand that the present invention is not limited to the described order of actions, and some steps may actually be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential for implementing the present invention.

[0063] To facilitate better implementation of the above-described solutions of the embodiments of the present invention, related apparatus for implementing the above-described solutions is also provided below.

[0064] Please see Figure 3 As shown, the risk data processing device 300 provided in this embodiment of the invention may include: a data synchronization unit 301 and an external service unit 302.

[0065] The data synchronization unit 301 can be used to obtain multiple risk data from a preset blockchain and store them locally; wherein the risk data is pre-written into the blockchain by multiple data providers, and any risk data provided by any data provider includes a risk subject identifier and a risk level determined by the data provider for the risk subject identifier; the external service unit 302 can be used to: in response to receiving a risk query request sent by a user terminal, determine the risk data corresponding to the risk subject identifier carried in the risk query request in the local data, and return the query result including the risk level in the determined risk data to the user terminal.

[0066] In this embodiment of the invention, the data synchronization unit 301 can be further configured to: for any risk data provided by any data provider: when it is determined that there is no risk data provided by the data provider that has the same risk subject identifier as the risk data locally, store the risk data locally; when it is determined that there is risk data with the same risk subject identifier as the risk data locally, replace the risk data with the risk data that has the same risk subject identifier with the risk data.

[0067] In specific applications, any risk data may further include a risk subject identifier and a risk level, and the risk query request may further carry the applicable scenario; and the external service unit 302 may be further used to: determine the risk data corresponding to the risk subject identifier and applicable scenario carried in the risk query request in local data.

[0068] In practical applications, any risk data may further include the validity period of the risk data; and the external service unit 302 may be further used to: determine the risk data that is valid and corresponds to the risk subject identifier and applicable scenario carried in the risk query request in the local data, and use the determined risk data as the target risk data; and return the query results including the risk level in the target risk data to the user terminal.

[0069] As a preferred embodiment, the risk query request further carries a false positive tolerance; and the external service unit 302 can be further configured to: determine the risk level in the target risk data as the risk level in the query result when the number of target risk data is one, or when the number of target risk data is multiple and the multiple target risk data contain the same risk level; when the number of target risk data is multiple and the multiple target risk data contain different risk levels: if the false positive tolerance indicates high false positive tolerance, then the highest risk level among the different risk levels is determined as the risk level in the query result; if the false positive tolerance indicates low false positive tolerance, then the lowest risk level among the different risk levels is determined as the risk level in the query result.

[0070] Preferably, the device 300 may further include a profit-sharing unit, configured to: after returning the query result to the user terminal, determine the value data of a single query by the user terminal based on pre-stored historical transaction records of the user terminal; determine the contribution of each data provider based on the number of data providers providing risk levels in the query result; and perform profit-sharing operations on each data provider based on the value data and the contribution of each data provider.

[0071] In one embodiment, the profit-sharing unit is further configured to: after returning the query result to the user terminal, receive feedback information from the user terminal regarding the query result; determine the value data of a single query by the user terminal based on pre-stored historical transaction records of the user terminal; determine the contribution of each data provider based on the number of data providers providing risk levels in the query result and the feedback information; and perform profit-sharing operations on each data provider based on the value data and the contribution of each data provider.

[0072] In an optional technical solution, the historical transaction records are pre-written into the blockchain, and the historical transaction records include: user identifier, transaction amount, and total number of queries; and the device 300 may further include an on-chain unit, used for: after returning the query result to the user terminal, generating a corresponding query record and writing it into the blockchain for the data provider to query; the query record includes: user identifier, risk subject identifier carried in the risk query request, the query result, the identifier of the data provider providing the risk level in the query result, and the query time; after receiving the feedback information, generating a corresponding feedback record based on the feedback information and writing it into the blockchain for the data provider to query.

[0073] In practical scenarios, the on-chain unit can be further used to: after determining the contribution of each data provider, generate contribution data including the identifier of the data provider providing the risk level in the query results, the contribution, and the corresponding query record identifier, and write it into the blockchain for the data provider to query; after performing the profit-sharing operation, generate a profit-sharing record including the profit-sharing result and the corresponding contribution data identifier and write it into the blockchain for the data provider to query.

[0074] Furthermore, in this embodiment of the invention, the blockchain is maintained by the plurality of data providers, the risk data further includes a data source and a risk label representing the risk type, the query result further includes the risk label, and the risk subject identifier includes a mobile terminal number and / or IP address; the data synchronization unit 301 can be further used to: receive multiple pieces of risk data pushed by the blockchain through the execution of a pre-deployed smart contract; the smart contract is used to execute the push when there is new or updated risk data in the blockchain; the external service unit 302 can be further used to: in response to receiving the risk query request, when it is determined that the target risk data does not exist in the local data, return information of no matching result to the user terminal.

[0075] According to the technical solution of this invention, after multiple data providers upload their risk data to the blockchain, the blockchain automatically synchronizes the newly added or updated risk data to the risk identification system through the execution of smart contracts. Subsequently, the risk identification system can provide risk data query services to users through an interface. When a user initiates a risk query request for a specific mobile phone number or IP address to the risk identification system, the system determines the corresponding valid risk data from its local data, integrates this risk data into query results, and returns them to the user. This achieves risk data sharing and fusion among data providers, improves the availability of risk data and the enterprise's risk prevention capabilities, and ensures data security and traceability throughout the process through the blockchain. Furthermore, after providing the query service, the risk identification system can reasonably determine the contribution of each data provider based on the user's historical transaction records, query records, and feedback records. Based on the contribution, it then distributes profits to the data providers and writes the historical transaction records, query records, feedback records, contribution data, and profit-sharing records to the blockchain, thereby achieving efficient and fair value distribution and ensuring the queryability and traceability of profit-sharing records.

[0076] Figure 4 This is a schematic diagram of the components of the risk data processing system in an embodiment of the present invention. See also... Figure 4 The risk data processing system of this invention may include: multiple data providers, a blockchain maintained by the multiple data providers, and a risk identification system. The risk identification system retrieves multiple pieces of risk data from a preset blockchain and stores them locally. The risk data is pre-written into the blockchain by the multiple data providers, and any risk data provided by any data provider includes a risk subject identifier and a risk level determined by the data provider for the risk subject identifier. In response to receiving a risk query request from a user, the risk identification system determines the risk data corresponding to the risk subject identifier carried in the risk query request from the local data and returns the query result, including the risk level in the determined risk data, to the user. Since some specific execution steps and related functions have already been described above, they will not be described in detail here.

[0077] Figure 4 The data gateway in the system is used to preprocess the raw risk data before data providers upload it to the blockchain, thereby obtaining risk data in a standardized format. After the risk identification system obtains the contribution of each data provider, it can interact with the data providers through the data gateway to distribute value.

[0078] In this embodiment of the invention, after returning the query result to the user terminal, the risk identification system receives feedback information from the user terminal regarding the query result. Based on pre-stored historical transaction records of the user terminal, the system determines the value data of a single query by the user terminal. It then determines the contribution of each data provider based on the number of data providers offering risk levels in the query result and the feedback information. Finally, it performs a revenue-sharing operation with each data provider based on the value data and their contribution. The historical transaction records are pre-written into the blockchain by the risk identification system and include: user identifier, transaction amount, and total number of queries.

[0079] As a preferred embodiment, after returning the query results to the user, the risk identification system generates corresponding query records and writes them into the blockchain for the data provider to query; the query record includes: user identifier, risk subject identifier carried in the risk query request, the query results, the identifier of the data provider providing the risk level in the query results, and the query time.

[0080] Preferably, after receiving the feedback information, the risk identification system generates a corresponding feedback record based on the feedback information and writes it into the blockchain for the data provider to query.

[0081] In practical applications, after determining the contribution of each data provider, the risk identification system generates contribution data including the identifier of the data provider that provides the risk level in the query results, the contribution level, and the corresponding query record identifier, and writes it into the blockchain for the data provider to query.

[0082] In a specific application, after the profit-sharing operation is performed, the risk identification system generates a profit-sharing record including the profit-sharing result and the corresponding contribution data identifier and writes it into the blockchain for the data provider to query.

[0083] In one embodiment, for any risk data obtained from any data provider: when the risk identification system determines that there is no risk data with the same risk subject identifier provided by the data provider that is available locally, the risk identification system stores the risk data locally; when the risk identification system determines that there is risk data with the same risk subject identifier available locally, the risk identification system replaces the risk data with the same risk subject identifier with the risk data.

[0084] In one optional implementation, any risk data further includes a risk subject identifier and an applicable scenario for the risk level, and the risk query request further carries the applicable scenario; and, after receiving the risk query request, the risk identification system determines the risk data corresponding to the risk subject identifier and applicable scenario carried in the risk query request in its local data.

[0085] In one optional technical solution, any risk data further includes the validity period of the risk data; and after receiving the risk query request, the risk identification system determines in its local data the risk subject identifier and applicable scenario carried in the risk query request, and the risk data that is in a valid state, and uses the determined risk data as the target risk data; the risk identification system returns the query results, including the risk level in the target risk data, to the user terminal.

[0086] Specifically, the risk query request further carries a false positive tolerance; and, when the number of target risk data is one, or when the number of target risk data is multiple and the multiple target risk data contain the same risk level, the risk identification system determines the risk level in the target risk data as the risk level in the query result; when the number of target risk data is multiple and the multiple target risk data contain different risk levels: if the false positive tolerance indicates high false positive tolerance, the risk identification system determines the highest risk level among the different risk levels as the risk level in the query result; if the false positive tolerance indicates low false positive tolerance, the risk identification system determines the lowest risk level among the different risk levels as the risk level in the query result.

[0087] In a specific scenario, after returning the query results to the user terminal, the risk identification system determines the value data of a single query by the user terminal based on the pre-stored historical transaction records of the user terminal, determines the contribution of each data provider based on the number of data providers providing the risk level in the query results, and performs a profit-sharing operation to each data provider based on the value data and the contribution of each data provider.

[0088] Furthermore, in this embodiment of the invention, the blockchain is maintained by the plurality of data providers, the risk data further includes a data source and a risk label representing the risk type, the query result further includes the risk label, and the risk subject identifier includes a mobile terminal number and / or IP address; the risk identification system receives multiple pieces of risk data pushed by the blockchain through the execution of a pre-deployed smart contract; the smart contract is used to push the data when there is new or updated risk data in the blockchain; in response to receiving the risk query request, when the risk identification system determines that the target risk data does not exist in the local data, it returns information of no matching result to the user terminal.

[0089] The following describes a specific embodiment of the present invention.

[0090] The rapid development of the internet industry has provided opportunities for black market activities to reap huge profits. IP addresses and mobile phone numbers are highly correlated with risky behavior in the registration, login, marketing, order, and payment processes. Currently, companies (i.e., data providers) generally conduct real-time and offline risk detection and identification based on their own platform's end-to-end business data, combining artificial intelligence algorithms such as machine learning, deep learning, and graph computing to create risk profiles of IP addresses and mobile phone numbers used in their business, thereby obtaining risk data.

[0091] Currently, the risk data from various data providers is not integrated or centralized, making it difficult for users to select accurate risk data for risk protection, which poses a serious challenge to business risk control operations.

[0092] In this embodiment, data providers are first invited to join the consortium blockchain. Each data provider preprocesses the risk data through a data gateway and uploads the preprocessed data to the blockchain via smart contracts. The blockchain system synchronizes the risk data to the risk identification system and updates it in real time. The risk identification system provides services externally through an OpenAPI (Open Application Programming Interface) and uploads user resource package purchase records (i.e., historical transaction records), query records, and feedback records to the blockchain via smart contracts. Based on these records, the contribution of each risk identification system is calculated, and value sharing is based on the contribution. Finally, the contribution data and profit sharing records are uploaded to the blockchain via smart contracts to ensure the fairness, impartiality, and traceability of data contributions and profit sharing among all parties. The specific execution steps are as follows:

[0093] Step 1: Risk Data Preprocessing

[0094] The alliance manages data providers and assigns them specific roles and permissions. Data providers preprocess existing risk data through a data gateway, converting it into a standardized format that includes dimensions such as risk subject identification, risk level, risk label, data source, applicable scenario, and validity period. The processed data is then automatically uploaded to the blockchain via smart contracts.

[0095] Step Two: Risk Data Synchronization and Update

[0096] The consortium blockchain system manages on-chain data in real time through smart contract management and blockchain management, and synchronizes the latest risk data to the risk identification system for external users to access.

[0097] Step 3: Accessing Risk Intelligence Data

[0098] Fee Management: The risk identification system provides services through an OpenAPI, allowing users to access these services by purchasing resource packages. Historical transaction records are uploaded to the blockchain via smart contracts.

[0099] Authentication Management: Users access the API interface through Access Key ID and Access Key Secret authentication methods.

[0100] Rate limiting management: Rate limiting is implemented through token distribution to prevent users from abusing the interface.

[0101] Risk Inquiry: The user submits encrypted data (generated by MD5 or other agreed-upon methods) of mobile phone number or IP address, risk control scenario, and false alarm tolerance to the risk identification system via API interface. The risk identification system returns the risk level and risk label.

[0102] For the same mobile phone number or IP address, the risk level and applicable scenarios provided by different data providers may be inconsistent. Under the condition that the validity period and applicable scenarios are met, the risk identification system flexibly outputs parameters according to the user's false alarm tolerance: when the false alarm tolerance is high, the risk identification system outputs the highest risk level; when the false alarm tolerance is low, the risk identification system outputs the lowest risk level.

[0103] Step 4: Contribution Calculation

[0104] For a single query, if the data providers have the same risk level, their respective contributions are calculated on average. If the data providers have different risk levels, but the user selects a low false positive tolerance and outputs the lowest risk level, their respective contributions are also calculated on average. If the data providers have different risk levels, and the user selects a high false positive tolerance and outputs the highest risk level, and receives false positive feedback, their respective contributions are reduced by 10% based on the average calculation. Finally, the contribution data is uploaded to the blockchain via a smart contract.

[0105] Step 5: Profit Sharing from Business Risk Intelligence

[0106] The risk identification system calculates the cost of a single query using a user's resource package purchase records (phone number or IP address) and distributes profits based on contribution. The profit-sharing records are then recorded on the blockchain via a smart contract.

[0107] In the technical solution of this invention, a consortium blockchain technology is used to integrate, share, and unify risk data from multiple parties, and then provide services externally through an API. By putting risk data, users' historical transaction records, query records, feedback records, contribution data, and profit-sharing records on the blockchain, the data management costs of each data provider can be reduced while ensuring data security and traceability. Furthermore, the risk identification system, through reasonable contribution calculation and profit-sharing methods, ensures the fairness, impartiality, and traceability of data contributions and value sharing among all parties, achieving efficient transfer of risk data value while protecting the data ownership of all parties.

[0108] Figure 5 An exemplary system architecture 500 is shown that can be applied to the risk data processing method or risk data processing apparatus of the present invention.

[0109] like Figure 5 As shown, system architecture 500 may include terminal devices 501, 502, and 503, network 504, and server 505 (this architecture is merely an example; the components included in a specific architecture may be adjusted according to the specific application). Network 504 serves as the medium for providing a communication link between terminal devices 501, 502, and 503 and server 505. Network 504 may include various connection types, such as wired or wireless communication links or fiber optic cables.

[0110] Users can use terminal devices 501, 502, and 503 to interact with server 505 via network 504 to receive or send messages, etc. Various client applications, such as risk identification applications, can be installed on terminal devices 501, 502, and 503 (for example only).

[0111] Terminal devices 501, 502, and 503 can be various electronic devices with displays that support web browsing, including but not limited to smartphones, tablets, laptops, and desktop computers.

[0112] Server 505 can be a server that provides various services, such as a risk identification server (for example only) that supports risk identification applications operated by users using terminal devices 501, 502, and 503. The risk identification server can process received risk query requests and feed back the processing results (such as query results including risk levels - for example only) to terminal devices 501, 502, and 503.

[0113] It should be noted that the risk data processing method provided in the embodiments of the present invention is generally executed by server 505, and correspondingly, the risk data processing device is generally set in server 505.

[0114] It should be understood that Figure 5 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0115] The present invention also provides an electronic device. The electronic device according to an embodiment of the present invention includes: one or more processors; and a storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the risk data processing method provided by the present invention.

[0116] The following is for reference. Figure 6 It shows a schematic diagram of the structure of a computer system 600 suitable for implementing an electronic device according to embodiments of the present invention. Figure 6 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of the present invention.

[0117] like Figure 6 As shown, the computer system 600 includes a central processing unit (CPU) 601, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 602 or programs loaded from storage section 608 into random access memory (RAM) 603. The RAM 603 also stores various programs and data required for the operation of the computer system 600. The CPU 601, ROM 602, and RAM 603 are interconnected via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0118] The following components are connected to I / O interface 605: an input section 606 including a keyboard, mouse, etc.; an output section 607 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a LAN card, modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to I / O interface 605 as needed. A removable medium 611, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on drive 610 as needed so that computer programs read from it can be installed into storage section 608 as needed.

[0119] In particular, according to the embodiments disclosed in this invention, the processes described in the above main step diagrams can be implemented as computer software programs. For example, embodiments of this invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the main step diagrams. In the above embodiments, the computer program can be downloaded and installed from a network via communication section 609, and / or installed from removable medium 611. When the computer program is executed by central processing unit 601, it performs the functions defined in the system of this invention.

[0120] It should be noted that the computer-readable medium shown in this invention can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can 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 a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, 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 device, magnetic storage device, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this invention, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium may be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0121] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0122] The units described in the embodiments of the present invention can be implemented in software or hardware. The described units can also be housed in a processor; for example, a processor may be described as including a data synchronization unit and an external service unit. The names of these units do not necessarily limit the specific unit; for example, a data synchronization unit may also be described as "a unit that provides risk data to the external service unit."

[0123] In another aspect, the present invention also provides a computer-readable medium, which may be included in the device described in the above embodiments; or it may exist independently and not assembled into the device. The computer-readable medium carries one or more programs, which, when executed by the device, cause the device to perform the following steps: obtaining multiple pieces of risk data from a preset blockchain and storing them locally; wherein the risk data is pre-written into the blockchain by multiple data providers, and any risk data provided by any data provider includes a risk subject identifier and a risk level determined by the data provider for the risk subject identifier; in response to receiving a risk query request sent by a user terminal, determining the risk data corresponding to the risk subject identifier carried in the risk query request in the local data, and returning a query result including the risk level in the determined risk data to the user terminal.

[0124] In the technical solution of this invention, after multiple data providers upload their risk data to the blockchain, the blockchain automatically synchronizes the newly added or updated risk data to the risk identification system through the execution of smart contracts. Subsequently, the risk identification system can provide risk data query services to users through an interface. When a user initiates a risk query request for a specific mobile phone number or IP address to the risk identification system, the system determines the corresponding valid risk data from its local data, integrates this risk data into query results, and returns them to the user. This achieves risk data sharing and fusion among data providers, improves the availability of risk data and the enterprise's risk prevention capabilities, and ensures data security and traceability throughout the process through the blockchain. Furthermore, after providing the query service, the risk identification system can reasonably determine the contribution of each data provider based on the user's historical transaction records, query records, and feedback records. Based on this contribution, it then distributes profits to the data providers and writes the historical transaction records, query records, feedback records, contribution data, and profit-sharing records to the blockchain, thereby achieving efficient and fair value distribution and ensuring the queryability and traceability of profit-sharing records.

[0125] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can occur depending on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A risk data processing method, characterized in that, include: Multiple risk data entries are retrieved from a pre-defined blockchain and stored locally. These risk data entries are pre-written into the blockchain by multiple data providers. Each risk data entry provided by any data provider includes a risk subject identifier, a risk level determined by the data provider for the risk subject identifier, the data source, and a risk label representing the risk type. The blockchain is maintained by the multiple data providers, and the risk subject identifier includes a mobile terminal number and / or IP address. In response to receiving a risk query request from a user, the system determines the risk data corresponding to the risk subject identifier carried in the risk query request in the local data, uses the determined risk data as the target risk data, and returns a query result including the risk level in the target risk data to the user; the query result further includes the risk tag; in response to receiving the risk query request, if it is determined that the target risk data does not exist in the local data, the system returns a no-matching-result message to the user. The step of obtaining multiple risk data from a preset blockchain and storing them locally includes: receiving multiple risk data pushed by the blockchain through the execution of a pre-deployed smart contract; the smart contract is used to push the data when there is new or updated risk data in the blockchain.

2. The method according to claim 1, characterized in that, The step of retrieving multiple risk data entries from a pre-defined blockchain and storing them locally includes: For any risk data obtained from any data provider: if it is determined that no risk data with the same risk subject identifier as the risk data provided by the data provider exists locally, then store the risk data locally. When it is determined that there is risk data with the same risk subject identifier as the risk data in the local system, the risk data with the same risk subject identifier as the risk data shall be replaced with the risk data with the risk data.

3. The method according to claim 1, characterized in that, Any risk data further includes the risk subject identifier and the applicable scenario of the risk level, and the risk query request further carries the applicable scenario; And, determining the risk data corresponding to the risk subject identifier carried in the risk query request in the local data includes: Determine the risk subject identifier and the risk data corresponding to the applicable scenario carried in the risk query request from the local data.

4. The method according to claim 3, characterized in that, Any risk data further includes the validity period of the risk data; and, the step of determining the risk data corresponding to the risk subject identifier carried in the risk query request in the local data, and returning the query result including the risk level in the determined risk data to the user terminal, includes: In the local data, identify the risk subject identifier and applicable scenario carried in the risk query request, and determine the risk data that is in a valid state, and use the determined risk data as the target risk data; The query results, including the risk level in the target risk data, will be returned to the user terminal.

5. The method according to claim 4, characterized in that, The risk query request further carries a false positive tolerance; and the step of returning the query results, including the risk level in the target risk data, to the user includes: If the number of target risk data is one, or if the number of target risk data is multiple and the multiple target risk data contain the same risk level, the risk level in the target risk data will be determined as the risk level in the query result. When there are multiple target risk data entries and these multiple target risk data entries contain different risk levels: if the false alarm tolerance indicates high false alarm tolerance, then the highest risk level among the different risk levels is determined as the risk level in the query result; if the false alarm tolerance indicates low false alarm tolerance, then the lowest risk level among the different risk levels is determined as the risk level in the query result.

6. The method according to claim 5, characterized in that, The method further includes: After returning the query results to the user terminal, the value data of a single query by the user terminal is determined based on the pre-stored historical transaction records of the user terminal. The contribution of each data provider is determined based on the number of data providers offering risk levels in the query results; Based on the value data and the contribution of each data provider, a revenue-sharing operation is performed on each data provider.

7. The method according to claim 5, characterized in that, The method further includes: After returning the query results to the user terminal, receive feedback information from the user terminal regarding the query results; The value data of a single query by the user terminal is determined based on the pre-stored historical transaction records of the user terminal; The contribution of each data provider is determined based on the number of data providers offering risk levels in the query results and the feedback information. Based on the value data and the contribution of each data provider, a revenue-sharing operation is performed on each data provider.

8. The method according to claim 7, characterized in that, The historical transaction records are pre-written into the blockchain, and the historical transaction records include: user identifier, transaction amount, and total number of queries; and the method further includes: After returning the query results to the user, a corresponding query record is generated and written to the blockchain for the data provider to query; the query record includes: user identifier, risk subject identifier carried in the risk query request, query results, identifier of the data provider providing the risk level in the query results, and query time; After receiving the feedback information, a corresponding feedback record is generated based on the feedback information and written into the blockchain for the data provider to query.

9. The method according to claim 8, characterized in that, The method further includes: After determining the contribution of each data provider, contribution data including the identifier of the data provider that provides the risk level in the query results, the contribution level, and the corresponding query record identifier is generated and written into the blockchain for the data provider to query. After the profit-sharing operation is performed, a profit-sharing record including the profit-sharing result and the corresponding contribution data identifier is generated and written into the blockchain for the data provider to query.

10. A risk data processing device, characterized in that, include: A data synchronization unit is used to retrieve multiple risk data entries from a pre-set blockchain and store them locally. The risk data is pre-written into the blockchain by multiple data providers. Any risk data provided by any data provider includes a risk subject identifier, a risk level determined by the data provider for the risk subject identifier, the data source, and a risk label representing the risk type. The blockchain is maintained by the multiple data providers, and the risk subject identifier includes a mobile terminal number and / or IP address. The external service unit is configured to: respond to receiving a risk query request sent by a user terminal, determine the risk data corresponding to the risk subject identifier carried in the risk query request in local data, use the determined risk data as the target risk data, and return a query result including the risk level in the target risk data to the user terminal; the query result further includes the risk tag; and respond to receiving the risk query request, if it is determined that the target risk data does not exist in the local data, return a no-matching-result message to the user terminal. The step of obtaining multiple risk data from a preset blockchain and storing them locally includes: receiving multiple risk data pushed by the blockchain through the execution of a pre-deployed smart contract; the smart contract is used to push the data when there is new or updated risk data in the blockchain.

11. A risk data processing system, characterized in that, include: Multiple data providers, blockchains maintained by the multiple data providers, and a risk identification system; The risk identification system retrieves multiple risk data entries from a pre-set blockchain and stores them locally. These risk data entries are pre-written into the blockchain by the multiple data providers. Each risk data entry provided by any data provider includes a risk subject identifier, a risk level determined by the data provider for the risk subject identifier, the data source, and a risk label representing the risk type. The blockchain is maintained by the multiple data providers, and the risk subject identifier includes a mobile terminal number and / or IP address. In response to receiving a risk query request from a user, the risk identification system determines the risk data corresponding to the risk subject identifier carried in the risk query request in local data, uses the determined risk data as the target risk data, and returns a query result including the risk level in the target risk data to the user; the query result further includes the risk tag; in response to receiving the risk query request, if it is determined that the target risk data does not exist in the local data, it returns a no-matching-result message to the user. The step of obtaining multiple risk data from a preset blockchain and storing them locally includes: receiving multiple risk data pushed by the blockchain through the execution of a pre-deployed smart contract; the smart contract is used to push the data when there is new or updated risk data in the blockchain.

12. The risk data processing system according to claim 11, characterized in that, After returning the query results to the user terminal, the risk identification system receives feedback information from the user terminal regarding the query results. Based on pre-stored historical transaction records of the user terminal, it determines the value data of a single query. It then determines the contribution of each data provider based on the number of data providers offering risk levels in the query results and the feedback information. Finally, it performs a revenue-sharing operation with each data provider based on the value data and their contribution. The historical transaction records are pre-written into the blockchain by the risk identification system and include: user identifier, transaction amount, and total number of queries. After returning the query results to the user, the risk identification system generates corresponding query records and writes them into the blockchain for the data provider to query. The query record includes: user identifier, risk subject identifier carried in the risk query request, query results, identifier of the data provider that provides the risk level in the query results, and query time. After receiving the feedback information, the risk identification system generates corresponding feedback records based on the feedback information and writes them into the blockchain for the data provider to query. After determining the contribution of each data provider, the risk identification system generates contribution data including the identifier of the data provider that provides the risk level in the query results, the contribution level, and the corresponding query record identifier, and writes it into the blockchain for the data provider to query. After the profit-sharing operation is performed, the risk identification system generates a profit-sharing record including the profit-sharing result and the corresponding contribution data identifier and writes it into the blockchain for the data provider to query.

13. An electronic device, characterized in that, include: One or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1-9.

14. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1-9.

Images