Merchant risk management method, service system and storage medium

Abstract

The embodiment of the invention provides a merchant risk management method, a service system and a storage medium. In the method, a service system determines a current stage of a target merchant in a full life cycle of the target merchant; performing risk identification on the target merchant by adopting a risk identification mode corresponding to the current stage to obtain a target risk identification result; and performing risk management on the target merchant based on the target risk identification result in the remaining time period of the current stage and / or in the next stage of the current stage, wherein the full life cycle starts from the target merchant as a potential customer of the service system until the target merchant is logout from the service system.

Description

TECHNICAL FIELD

[0001] The present specification relates to the technical field of Internet, and particularly relates to a risk management method of a merchant, a service system and a storage medium. BACKGROUND

[0002] With the rapid development and popularization of electronic commerce and mobile payment technology, consumers are increasingly inclined to use electronic payment, and the payment methods of electronic payment are also diversified. In order to support diversified payment methods, merchants usually need to rely on the collection service provided by the service system. For example, the merchant enters the service system, and the service system helps the merchant to collect and process transaction requests from different payment channels, such as credit card payment, debit card payment, electronic wallet payment, etc.

[0003] For the service system, the types of merchants registered in the service system are various, and there are also illegal merchants. Illegal merchants may carry out illegal transactions, causing damage to users and the service system. Therefore, in order to protect the security of transactions, the service system needs to manage the risk of the merchant, so as to prevent the adverse effects of illegal merchants.

[0004] The content of the background section only represents the inventor's own knowledge and does not mean that the above information has entered the public domain before the filing date of the present disclosure, nor does it mean that it can be prior art of the present disclosure. SUMMARY

[0005] The present specification provides a risk management method of a merchant, a service system and a storage medium, which can automatically and track the risk management of the merchant in the whole life cycle of the merchant, improve the timeliness of risk management, and further improve the security of transactions.

[0006] In a first aspect, the present specification provides a risk management method of a merchant, applied to a service system for managing the risk of a target merchant in the whole life cycle of the target merchant, comprising: determining a current stage of the target merchant in the whole life cycle, wherein the whole life cycle starts from the target merchant as a potential customer of the service system and ends when the target merchant is unregistered from the service system; using a risk identification method corresponding to the current stage to identify the risk of the target merchant to obtain a target risk identification result; and based on the target risk identification result, managing the risk of the target merchant in the remaining period of the current stage and / or in the next stage of the current stage.

[0007] In a second aspect, the present specification also provides a service system for performing risk management on a target merchant throughout its entire life cycle, comprising: at least one storage medium storing at least one instruction set for performing risk management on the merchant; and at least one processor communicatively connected to the at least one storage medium, wherein the at least one processor reads the at least one instruction set during operation, and according to the instructions of the at least one instruction set: determines the current stage of the target merchant in the entire life cycle, wherein the entire life cycle starts from the target merchant becoming a potential customer of the service system and ends when the target merchant is deregistered from the service system, adopts the risk identification method corresponding to the current stage, performs risk identification on the target merchant to obtain a target risk identification result, and performs risk management on the target merchant based on the target risk identification result during the remaining period of the current stage and / or the next stage of the current stage.

[0008] In a third aspect, the present specification provides a computer-readable non-transitory storage medium, wherein the computer-readable non-transitory storage medium stores at least one instruction set, and when the at least one instruction set is executed by at least one processor, the merchant risk management method as described in the first aspect is implemented.

[0009] Other features of the merchant risk management method, service system, and storage medium provided in this specification are partially listed in the following description. The inventive aspects of the merchant risk management method, service system, and storage medium provided in this specification may be fully explained by practicing or using the methods, devices, and combinations described in the following detailed examples. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] In order to more clearly illustrate the technical solutions in the embodiments of this specification, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0011] Figure 1 A schematic diagram of an application scenario of risk management for merchants provided according to an embodiment of this specification is shown;

[0012] Figure 2 shows a hardware structure diagram of a service system provided according to an embodiment of this specification;

[0013] Figure 3 A flowchart of a merchant risk management method provided according to an embodiment of this specification is shown;

[0014] Figure 4A schematic diagram showing obtaining portrait information at different stages according to an embodiment of this specification is shown;

[0015] Figure 5 A schematic diagram showing portrait information provided according to an embodiment of this specification;

[0016] Figure 6 A schematic diagram showing determination of target risk identification results at different stages according to an embodiment of this specification is shown; and

[0017] Figure 7 Another schematic diagram of determining target risk identification results at different stages according to an embodiment of this specification is shown. DETAILED DESCRIPTION

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

[0019] The terms used herein are for the purpose of describing specific example embodiments only and are not intended to be limiting. For example, as used herein, the singular forms "a," "an," and "the" may also include the plural forms unless the context clearly indicates otherwise. When used in this specification, the terms "comprise," "include," and / or "contain" are intended to refer to the presence of the associated integers, steps, operations, elements, and / or components, but do not preclude the presence of one or more other features, integers, steps, operations, elements, components, and / or groups or the addition of other features, integers, steps, operations, elements, components, and / or groups in the system / method.

[0020] These and other features of this specification, as well as the operation and function of the associated elements of the structure, and the economical assembly and manufacture of the components, can be significantly improved with consideration of the following description. Reference is made to the accompanying drawings, all of which form a part of this specification. However, it should be expressly understood that the drawings are for illustration and description purposes only and are not intended to limit the scope of this specification. It should also be understood that the drawings are not drawn to scale.

[0021] The flowcharts used in this specification illustrate operations implemented by systems according to some embodiments of the present specification. It should be clearly understood that the operations of the flowcharts may not be implemented in sequence. Rather, the operations may be implemented in reverse order or simultaneously. Furthermore, one or more additional operations may be added to the flowcharts. One or more operations may be removed from the flowcharts.

[0022] In this specification, a service system refers to a system that hosts merchants and provides services to them. The services provided by the service system to merchants may include, but are not limited to, transaction services, acquiring services, settlement services, and foreign exchange services. The service system may provide both cross-border and non-cross-border services, and this specification does not limit these services.

[0023] As mentioned above, the service system needs to manage merchant risk. This risk management can occur at multiple stages. For example, during customer acquisition, the service system may seek partnerships with merchants with high qualifications and low risks. Another example is that for merchants registered with the service system, the service system can set certain permissions based on their risk level.

[0024] Currently, most service systems rely heavily on manual labor for merchant risk management. There is no mature system for merchant tracking risk management, and the efficiency and effectiveness of risk management are unsatisfactory.

[0025] In view of this, this specification provides a merchant risk management method, service system and storage medium, in order to perform automated and traceable risk management throughout the merchant's life cycle, improve the timeliness of risk management, and thereby enhance the security of transactions.

[0026] The following combination Figure 1 This section introduces the application scenarios of merchant risk management provided in this manual.

[0027] Figure 1 FIG2 shows a schematic diagram of an application scenario of risk management for merchants according to an embodiment of this specification. Figure 1 As shown, scenario 001 may include a service system 100 and merchants 200. The service system 100 may collaborate with one or more merchants 200 to provide services to merchants 200. For example, the service system 100 may provide merchants 200 with one or more services including transaction services, acquiring services, settlement services, and foreign exchange services. The service system 100 may also identify and manage risks for merchants 200 throughout their lifecycle.

[0028] The service system 100 may include multiple subsystems. In some embodiments, Figure 1 As shown, the service system 100 includes an information storage subsystem 10, a risk identification subsystem 20, and a risk management subsystem 30. It should be noted that the subsystems in the service system 100 can also be divided in other ways. Figure 1 This is an example of a subsystem division method, and the present specification is not limited thereto.

[0029] The information storage subsystem 10 can store relevant information about the merchant 200 (e.g., portrait information). The merchant 200 can be a merchant that has already cooperated with the service system 100, for example, the merchant 200 has already registered in the service system. The merchant 200 can also be a merchant that has not yet cooperated with the service system 100, for example, the merchant 200 is a merchant with high qualifications that the service system 100 has identified from among many merchants and wants to expand it into a cooperative merchant, hereinafter referred to as a potential customer.

[0030] It is understandable that the information storage subsystem 10 may be inside the risk identification subsystem 20 or may be a subsystem independent of the risk identification subsystem 20 , and this specification does not impose any limitation on this.

[0031] The risk identification subsystem 20 can perform risk identification on the merchant 200 to obtain the risk identification result of the merchant 200. During the risk identification process, the risk identification subsystem 20 can obtain the portrait information of the merchant 200 from the information storage subsystem 10. The portrait information can characterize the merchant characteristics of the merchant 200 during the period from the first stage of the entire life cycle to the moment of risk identification. The merchant characteristics include but are not limited to KYB (Know Your Business) information and KYC (Know Your Customer) information. After the risk identification subsystem 20 obtains the risk identification result, it can transmit it to the risk management subsystem 30, or visualize the risk identification result. In some embodiments, after the risk identification subsystem 20 obtains the risk identification result, it can also store it in the information storage subsystem 10.

[0032] The risk management subsystem 30 can perform risk management on the merchant 200 based on the risk identification results corresponding to the merchant 200. The risk management subsystem 30 can correspond to one or more management modules. Each management module can be responsible for risk management in different directions or at different stages of the merchant.

[0033] For example, management module 1 is used to manage the risks of potential customers. For example, based on the risk identification results for merchant 200, management module 1 can determine whether to identify it as a high-quality merchant for key expansion. Management module 2 is used to manage the risks of established merchants. For example, management module 2 can set the transaction limit for merchant 200 based on the risk identification results for established merchants.

[0034] It is understood that after the risk identification subsystem 20 obtains the risk identification results for the merchant 200, the risk management subsystem 30 can perform the aforementioned risk management operations on the merchant 200 in real time. Alternatively, after the risk identification subsystem 20 obtains the risk identification results for the merchant 200, it can store them in the information storage subsystem 10. When the risk management subsystem 30 needs to perform risk management on the merchant 200 (for example, when the merchant 200 enters a new stage), the risk identification results corresponding to the merchant 200 can be read from the information storage subsystem 10, thereby performing the aforementioned risk management operations on the merchant 200.

[0035] In some embodiments, the service system 100 may store data and instructions for implementing the merchant's risk management method, and may execute or be used to execute the data and instructions. In some embodiments, the service system 100 may include a hardware device with data information processing capabilities and the necessary programs required to drive the hardware device to operate.

[0036] Exemplarily, service system 100 determines the current stage of merchant 200's lifecycle; employs a risk identification method corresponding to the current stage to perform risk identification on merchant 200, obtaining a target risk identification result; and performs risk management on merchant 200 based on the target risk identification result during the remainder of the current stage and / or the next stage after the current stage. The lifecycle begins when merchant 200 becomes a potential customer of service system 100 and ends when merchant 200 deregisters from service system 100. The specific implementation of each subsystem in service system 100 is described in the relevant description of method P300 below and will not be repeated here.

[0037] It should be noted that the service system 100 may correspond to a single device or a device cluster, and this specification does not impose any restrictions on this. When the service system 100 corresponds to a single device, the merchant's risk management method may be executed entirely on that device. When the service system 100 corresponds to a device cluster, the merchant's risk management method may be executed in coordination across multiple devices corresponding to the device cluster, or the merchant's risk management method may be executed in other ways, and this specification does not impose any restrictions on this.

[0038] Figure 2 A hardware structure diagram of a service system 100 provided according to an embodiment of this specification is shown.

[0039] like Figure 2 As shown, the service system 100 may include at least one storage medium 130 and at least one processor 120. In some embodiments, the service system 100 may further include a communication port 150 and an internal communication bus 110. In addition, the service system 100 may further include an I / O component 160.

[0040] The internal communication bus 110 can connect various system components. For example, the internal communication bus 110 can connect the storage medium 130 , the processor 120 , the communication port 150 , and the I / O component 160 .

[0041] The I / O component 160 supports input / output between the service system 100 and other components.

[0042] The communication port 150 is used for data communication between the service system 100 and the outside world. For example, the communication port 150 can be used for data communication between the service system 100 and a network. The communication port 150 can be a wired communication port or a wireless communication port.

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

[0044] In some embodiments, the network may include one or more network access points. For example, the network may include a wired or wireless network access point, such as a base station or an Internet exchange point. Through the access point, one or more components of each device corresponding to the service system 100 can connect to the network to exchange data or information.

[0045] The storage medium 130 may include a data storage device. The data storage device may be a non-transitory storage medium or a temporary storage medium. For example, the data storage device may include one or more of a disk 132, a read-only storage medium (ROM) 134, or a random access storage medium (RAM) 136. The storage medium 130 also includes at least one instruction set stored in the data storage device. The instruction set may include computer program code, which may include programs, routines, objects, components, data structures, processes, modules, etc. that implement the merchant risk management method provided in this specification.

[0046] The processor 120 can be in communication with the storage medium 130. The processor 120 is configured to execute the at least one instruction set. When the service system 100 is running, the processor 120 reads the at least one instruction set and, in accordance with the instructions of the at least one instruction set, executes the merchant risk management method provided herein.

[0047] The processor 120 may be in the form of one or more processors. In some embodiments, the processor 120 may include one or more hardware processors, such as a microcontroller, a microprocessor, a reduced instruction set computer (RISC), an application-specific integrated circuit (ASIC), an application-specific instruction set processor (ASIP), a central processing unit (CPU), a graphics processing unit (GPU), a physical processing unit (PPU), a microcontroller unit, a digital signal processor (DSP), a field programmable gate array (FPGA), an advanced RISC machine (ARM), a programmable logic device (PLD), any circuit or processor capable of performing one or more functions, etc., or any combination thereof.

[0048] For illustrative purposes only, only one processor 120 is shown in the service system 100 in the accompanying drawings. However, it should be noted that the service system 100 in this specification may also include multiple processors. Therefore, the operations and / or method steps disclosed in this specification may be performed by one processor as described in this specification, or may be performed jointly by multiple processors. For example, if the processor 120 of the service system 100 in this specification performs step A and step B, it should be understood that step A and step B may also be performed jointly or separately by two different processors 120 (for example, the first processor performs step A, the second processor performs step B, or the first and second processors perform steps A and B together).

[0049] Figure 3 A flowchart illustrating a merchant risk management method P300 provided according to an embodiment of this specification is shown. As previously described, the service system 100 can execute the merchant risk management method P300 to manage the risk of a target merchant throughout its lifecycle. Specifically, the processor 120 in the service system 100 can read an instruction set stored in its local storage medium and then execute the merchant risk management method P300 according to the instructions set.

[0050] like Figure 3 As shown, the merchant's risk management method P300 includes the following steps.

[0051] S310: Determine the current stage of the target merchant in its full life cycle, wherein the full life cycle starts from the target merchant becoming a potential customer of the service system 100 and ends when the target merchant deregisters from the service system 100.

[0052] The target merchant can be a merchant already established in the service system 100 or a potential customer of the service system 100. There can be one or more target merchants. This specification uses one merchant as an example to describe the process of the service system 100 executing P300. The process executed by the service system 100 for other merchants is similar and will not be repeated here. It is understood that when there are multiple target merchants, the stages of each merchant may be different. The service system 100 can execute P300 for multiple target merchants simultaneously or sequentially, and this specification does not limit this.

[0053] In some embodiments, the full lifecycle includes at least two phases: a potential customer phase, a registered phase, and a transaction phase. The potential customer phase corresponds to the period during which the target merchant is a potential customer of the service system 100; the registered phase corresponds to the period during which the target merchant registers with the service system 100; and the transaction phase corresponds to the period during which the target merchant conducts transactions with the service system 100.

[0054] Specifically, the potential customer stage can be understood as the stage before the target merchant submits an application for settlement / registration to the service system. The settlement stage can be understood as the stage from the target merchant submitting an application for settlement / registration to the service system 100 to the target merchant's first transaction on the service system 100. The transaction stage can be understood as the stage after the target merchant conducts its first transaction on the service system 100.

[0055] In this embodiment, the entire life cycle is divided into several key stages, so that risks of target merchants can be identified at key stages, so that reasonable risk management methods can be adopted for target merchants at key stages, thereby timely controlling the risk scope and avoiding expansion.

[0056] For example, if the target merchant is currently in the potential customer stage, it means that the target merchant is currently a potential customer of the service system 100, that is, the target merchant has not yet registered in the service system 100. If the target merchant is currently in the registered stage, it means that the target merchant has registered in the service system but has not yet conducted any transactions. If the target merchant is currently in the transaction stage, it means that the target merchant has already participated in transactions.

[0057] It will be understood that the above division of the entire life cycle is only an example. The service system 100 can make other divisions of the entire life cycle based on all the stages that a merchant can go through in the service system. For example, the service system 100 can further divide the transaction stage into: an active transaction stage, a silent transaction stage, and a restricted transaction stage. The active transaction stage corresponds to the stage when the number of transactions of the target merchant within X days is greater than or equal to a first preset threshold. The silent transaction stage corresponds to the stage when the number of transactions of the target merchant within X days is less than or equal to a second preset threshold, and the first preset threshold is greater than or equal to the second preset threshold. The restricted transaction stage corresponds to the stage when the target merchant's transaction rights are restricted by the service system. The restricted transaction rights may include but are not limited to: limiting the transaction amount, limiting the number of transactions, limiting the amount of foreign exchange settlement, etc. For another example, the service system 100 can also divide other stages after the transaction stage, including but not limited to: cancellation / clearance stage, etc., but this specification is not limited to this.

[0058] It should be noted that when the service system 10 divides the entire life cycle into stages, it may be based on the stages that merchants can sequentially experience within the service system 100. That is, each stage has a sequential order, and adjacent stages do not overlap. However, this specification is not limited to this. For example, different stages may overlap. The following will specifically explain the lack of overlapping periods.

[0059] In some embodiments, the service system 100 can determine the current stage of a target merchant in its life cycle based on the target merchant's registration status and / or transaction status in the service system 100. In this way, the service system 100 can accurately determine the current stage of a target merchant based on the target merchant's actual operations in the service system 100, thereby enabling the selection of appropriate risk identification and risk management methods.

[0060] For example, if the service system 100 determines that the target merchant is not a registered merchant with the service system 100 based on the target merchant's registration status with the service system 100, the target merchant's current stage can be determined to be a potential customer. For example, if the risk identification subsystem 20 cannot find the target merchant's registration information in the information storage subsystem 10, the target merchant can be determined to be not a registered merchant with the service system 100.

[0061] If the service system 100 determines that the target merchant is a registered merchant of the service system 100 based on the target merchant's registration status and transaction status in the service system 100, and that the target merchant has no transaction records in the service system 100, then the target merchant is determined to be in the settled stage. For example, if the risk identification subsystem 20 can search the information storage subsystem 10 for the target merchant's registration information but cannot find any transaction records, then the target merchant can be determined to be in the settled stage.

[0062] If the service system 100 determines that the target merchant has a transaction record in the service system 100 based on the target merchant's transaction status in the service system 100, the target merchant is currently in the transaction stage. For example, if the risk identification subsystem 20 can search for at least one transaction record in the information storage subsystem 10, it can be determined that the target merchant is currently in the transaction stage.

[0063] S320: Using the risk identification method corresponding to the current stage, risk identification is performed on the target merchant to obtain a target risk identification result.

[0064] When the target merchant is at different stages, the service system 100 can use different risk identification methods to identify the target merchant, so as to avoid a single risk identification method that cannot accurately identify risky merchants at each stage.

[0065] For example, when the current stage of the target merchant is the potential customer stage, the risk identification subsystem 20 can use the first risk identification method corresponding to the potential customer stage to identify the risk of the target merchant; when the current stage of the target merchant is the settlement stage, the risk identification subsystem 20 can use the second risk identification method corresponding to the settlement stage to identify the risk of the target merchant; when the current stage of the target merchant is the transaction stage, the risk identification subsystem 20 can use the third risk identification method corresponding to the transaction stage to identify the risk of the target merchant.

[0066] In some embodiments, the service system 100 obtains the portrait information of the target merchant. The portrait information represents the merchant characteristics of the target merchant within the target period. The target period is the period from the first stage to the current stage of the target merchant's life cycle. Then, the service system 100 adopts the risk identification method corresponding to the current stage, and performs risk identification on the target merchant based on the portrait information to obtain a target risk identification result. In this embodiment, the portrait information used by the service system 100 in the process of risk identification represents the merchant characteristics within the cumulative period, and the merchant is portrayed more comprehensively, which is conducive to improving the accuracy of risk identification.

[0067] When a target merchant is in a new stage, the service system 100 can generate and store profile information for the target merchant. For example, when the target merchant is in the potential customer stage (the first stage of the entire life cycle), the service system 100 can generate profile information 1 for the target merchant. Profile information 1 represents the merchant characteristics of the target merchant in the potential customer stage. For another example, when the target merchant is in the settlement stage (the second stage of the entire life cycle), the service system 100 can generate profile information 2 for the target merchant. Profile information 2 can be understood as an updated profile information 1, which can represent more merchant characteristics than profile information 1, representing the merchant characteristics of the target merchant during the period from the potential customer stage to the settlement stage. For another example, when the target merchant is in the transaction stage (the third stage of the entire life cycle), the service system 100 can generate profile information 3 for the target merchant. Profile information 3 can be understood as an updated profile information 2, which can represent more merchant characteristics than profile information 2 (for example, profile information 3 can include more transaction characteristics), representing the merchant characteristics of the target merchant during the period from the potential customer stage to the transaction stage.

[0068] For example, at each stage, after the service system 100 generates the target merchant's profile information for the current stage, it can store the profile information in the information storage subsystem 10. Furthermore, the profile information stored in the information storage subsystem 10 can be regularly updated during the current stage. For example, if the target merchant is currently in the potential customer stage, the service system 100 can update the target merchant's profile information in the information storage subsystem 10 every Y days, thereby ensuring that the profile information stored in the information storage subsystem 10 is updated in a timely manner, providing an accurate basis for subsequent risk identification.

[0069] The following describes how the service system 100 obtains the portrait information of the target merchant.

[0070] Exemplarily, the service system 100 searches at least one data source based on keywords of the target merchant to obtain search results related to the target merchant, and then extracts features from the search results from multiple dimensions to obtain the portrait information. In this example, the service system 100 can search from multiple different data sources to obtain real-time, rich search results, providing a more comprehensive perspective for accurately portraying the target merchant.

[0071] For example, the at least one data source includes at least one of the following: a data source within the service system, an open internet website, an official internet website, and a data source provided by a partner of the service system. The open internet website, official internet website, and data sources provided by a partner of the service system can be understood as data sources external to the service system. Open internet websites include, but are not limited to, search websites and transaction websites. Search websites include, for example, open search engines, and transaction websites include, for example, e-commerce websites. Official internet websites include, but are not limited to, business websites. A partner of the service system can be understood as a data provider that provides data. Data providers can obtain information related to merchants through various channels.

[0072] This allows for a wider variety of data sources, allowing search results to include a wide range of information about merchants. Furthermore, official data sources provide authoritative and reliable search results, which can be used to verify search results from other data sources, improving the authenticity and accuracy of merchant portraits.

[0073] It is understandable that when the target merchant is in different stages, the data sources and the number of data sources searched by the service system 100 may be different.

[0074] for example, Figure 4 As shown, the target merchant's full lifecycle is primarily illustrated by the potential customer stage, the onboarding stage, and the transaction stage. During the potential customer stage, service system 100 can search data source #1 (e.g., a search engine) and data source #2 (e.g., a transaction engine) to obtain search result #1 related to the target merchant. For example, service system 100 uses one or more of the target merchant's name, foreign name, code, or serial number as keywords to search data source #1 and data source #2, respectively, and generates search result #1 based on the search results obtained from each of data source #1 and data source #2. Data source #1 and data source #2 can each correspond to one or more data sources, and this specification does not impose any restrictions on this.

[0075] After obtaining search result #1, service system 100 can extract features from multiple dimensions of search result #1 to obtain portrait information #1. The multiple dimensions include but are not limited to: subject dimension, transaction dimension, and qualification dimension. Figure 5As shown, in the subject dimension, the service system 100 can extract the following features: features related to industrial and commercial foundations (such as industrial and commercial materials, shareholder information, legal person, abnormal business records, annual report information, etc.), features related to intellectual property (such as patent information, trademark information, etc.), features related to operations (such as offline stores, social security payments, merchant websites, recruitment information, bidding information, etc.), features related to taxation (such as tax level, etc.). In the transaction dimension, the service system 100 can extract the following features: features related to the amount of funds (such as the amount of payees, frequency of collection, amount of foreign exchange settlement, etc.), features related to the source of funds (personal accounts, related accounts, notes on accounts, payer profiles, etc.), features related to transaction orders (transaction mode, delivery cycle, transaction area, commodity category, etc.), features related to logistics (logistics methods, cross-border information, export methods, etc.), etc. In the qualification dimension, the service system 100 can extract the following features: features related to negative qualifications (such as negative public opinion, abnormal addresses, blacklists, gray lists, etc.), features related to positive qualifications (such as merchant store ratings, major customers, whitelists, etc.), and features related to quota qualifications (such as foreign exchange settlement quota, quota usage, return order status, etc.).

[0076] Combine Figure 5 As shown, in the potential customer stage, the service system 100 extracts features from the search result #1 from the subject dimension, transaction dimension and qualification dimension, and can obtain multiple features ( Figure 5 The feature set #1 consisting of the features in the box not filled with grayscale in the figure can be used as the portrait information #1 of the target merchant.

[0077] Continue to see Figure 4 During the onboarding phase, service system 100 can search data source #1 (e.g., a search engine), data source #2 (e.g., a trading website), and data source #3 (e.g., a data source within service system 100 and / or a business website) to obtain search result #2 related to the target merchant. The search process is not further described. Data source #3 can correspond to one or more data sources, and this specification does not impose any restrictions on this.

[0078] In the settlement phase, the service system 100 extracts features from the search result #2 from the subject dimension, transaction dimension, and qualification dimension, and obtains multiple features ( Figure 5 Feature set #2, consisting of features (including features in the light gray box in the figure), can be used as target merchant profile information #2. Alternatively, service system 100 extracts features from search result #2 based on the subject dimension, transaction dimension, and qualification dimension to obtain feature set #2. Feature set #2 is then combined with the features in feature set #1 to obtain profile information #2.

[0079] Continuing to refer to Figure 4 In the transaction stage, the service system 100 can search for search results #3 related to the target merchant from a data source #1 (such as a search website), a data source #2 (such as a transaction website), and a data source #3 (such as a data source inside the service system 100 and / or a business website) respectively.

[0080] In the transaction stage, the service system 100 extracts features from the search results #3 from the subject dimension, the transaction dimension, and the qualification dimension, and can obtain a feature set #3 composed of a plurality of features (the features in the box filled with dark gray in the middle). Figure 5 The feature set #3 can be used as the portrait information #3 of the target merchant. Alternatively, after the service system 100 extracts features from the search results #3 from the subject dimension, the transaction dimension, and the qualification dimension, the service system 100 can obtain the feature set #3, and obtain the portrait information #3 by merging and processing the features in the feature set #3 and the feature set #2.

[0081] In the above example, in the process of extracting features from search results in each stage, the plurality of dimensions are the same, but the present specification is not limited thereto. For example, different dimensions can be used for feature extraction in different stages.

[0082] It should be noted that the above division of the plurality of dimensions and the features extracted from each dimension are only examples, and the present specification is not limited thereto. For example, the plurality of dimensions can be divided into more fine-grained dimensions according to the features shown in the middle. Figure 5

[0083] In the process of searching for data sources in the external system of the service system 100, the service system 100 can obtain search results by using a crawler, or can obtain search results by establishing a data access interface with external data sources, and the present specification is not limited thereto.

[0084] In addition to the above example of obtaining portrait information, the service system 100 can also use a large model in the process of obtaining portrait information.

[0085] For example, the service system 100 guides the large model to process the search results to obtain the merchant information of the target merchant by using target guide information, the target guide information represents a merchant information mining method for the target merchant, and the large model is trained to mine merchant information in the search results based on the guide information; and the features of the merchant information are extracted from a plurality of dimensions to obtain the portrait information. In this example, since the search results obtained from a plurality of data sources are relatively extensive and chaotic, the large model can standardize the search results, realize efficient and accurate data analysis and mining, and improve the efficiency and quality of processing search results to obtain portrait information.​

[0086] For example, in the potential customer stage, the service system 100 obtains the target guidance information #1 corresponding to the potential customer stage. The target guidance information #1 may include the multiple dimensions or multiple features exemplified above, or the target guidance information #1 may include questions asked around the multiple dimensions or around the multiple features exemplified above. The target guidance information #1 may also include format information requiring the large model to output content. It can be understood that the target guidance information #1 can be in a variety of forms, the purpose of which is to extract the portrait information #1 from the search result #1. Further, the service system 100 inputs the target guidance information #1 and the search result #1 into the large model, and the large model can output the portrait information #1 exemplified above.

[0087] During the settlement stage and the transaction stage, the service system 100 uses a large model to obtain portrait information #2 or portrait information #3 in a similar manner and will not be repeated here.

[0088] After the service system 100 obtains the portrait information, there are multiple ways to obtain the target risk identification results of the target merchant based on the portrait information. Two of them are given below as examples, and this specification is not limited to them.

[0089] Method 1

[0090] In some embodiments, the service system 100 obtains a risk identification model corresponding to the current stage and inputs the profile information obtained at the current stage into the risk identification model to obtain the target risk identification result. Different stages of the lifecycle correspond to different risk identification models. In this embodiment, a pre-trained risk identification model suitable for the current stage can be used for risk identification, thereby improving risk identification efficiency.

[0091] Based on expert risk control experience, service system 100 can pre-train risk identification models corresponding to different stages. After training, service system 100 can obtain risk identification model #1 for use during the prospecting phase, risk identification model #2 for use during the onboarding phase, and risk identification model #3 for use during the transaction phase. These risk identification models can be scorecard models, but this specification is not limited thereto.

[0092] For example, Figure 6As shown, if the risk identification subsystem 20 determines that the target merchant is currently in the potential customer stage, profile information #1 can be input into risk identification model #1, thereby obtaining target risk identification result #1 output by risk identification model #1. If the risk identification subsystem 20 determines that the target merchant is currently in the settlement stage, profile information #2 can be input into risk identification model #2, thereby obtaining target risk identification result #2 output by risk identification model #2. If the risk identification subsystem 20 determines that the target merchant is currently in the transaction stage, profile information #3 can be input into risk identification model #3, thereby obtaining target risk identification result #3 output by risk identification model #3.

[0093] Method 2

[0094] In some embodiments, the service system 100 obtains historical risk identification results corresponding to the target merchant in the historical stage before the current stage, inputs the historical risk identification results and the portrait information obtained in the current stage into the risk identification model corresponding to the current stage, and obtains the target risk identification results.

[0095] Based on expert risk control experience, service system 100 can pre-train risk identification models corresponding to different stages. After training, service system 100 can obtain Risk Identification Model #1 for use during the prospecting phase, Risk Identification Model #2a for use during the onboarding phase, and Risk Identification Model #3a for use during the transaction phase. These risk identification models can be scorecard models, but this specification is not limited to this. Compared to the risk identification models exemplified in Method 1, Risk Identification Model #2a and Risk Identification Model #3a can be fed with historical risk identification results.

[0096] For example, Figure 7As shown, if the risk identification subsystem 20 determines that the current stage of the target merchant is the potential customer stage, the portrait information #1 can be input into the risk identification model #1, thereby obtaining the target risk identification result #1 output by the risk identification model #1. If the risk identification subsystem 20 determines that the current stage of the target merchant is the settlement stage, the portrait information #2 and the target risk identification result #1 (an example of the historical risk identification result) can be input into the risk identification model #2a, thereby obtaining the target risk identification result #2a output by the risk identification model #2a. If the risk identification subsystem 20 determines that the current stage of the target merchant is the transaction stage, the portrait information #3 and the target risk identification result #2a (an example of the historical risk identification result) can be input into the risk identification model #3a, thereby obtaining the target risk identification result #3a output by the risk identification model #3a. After obtaining the target risk identification results at the current stage, the risk identification subsystem 20 can store the target risk identification results in the information storage subsystem 10 (after obtaining the target risk identification results, the information storage subsystem 10 can add them to the target merchant's profile information). Furthermore, after obtaining new target risk identification results at the next stage, the historical risk identification results in the information storage subsystem 10 can be updated with the new target risk identification results. After obtaining target risk identification results at different stages, the risk identification subsystem 20 can also send the target risk identification results to the risk management subsystem 30.

[0097] It is understandable that the target risk identification results involved in Method 1 and Method 2 can represent the risk level or risk probability of the target merchant, etc., and this specification does not limit this.

[0098] It is also understood that within each stage, S110 and S120 may be periodically repeated multiple times. For example, in the potential customer stage, the risk identification subsystem 20 in the service system 100 may execute S110 and S120 once every Z days. The other stages are similar and will not be described in detail.

[0099] S330: During the remaining period of the current phase and / or the next phase of the current phase, risk management is performed on the target merchant based on the target risk identification result.

[0100] For example, the risk management subsystem 30 corresponds to a management module 1 for managing the risk of a potential customer. The management module 1 can determine whether to label the target merchant as a high-quality merchant based on the risk level represented by the target risk identification result of the target merchant in the potential customer stage. For example, if the risk level represented by the target risk identification result of the target merchant in the potential customer stage is high risk, the target merchant is determined to be a poor-quality merchant, and the management module 1 does not need to expand the target merchant. For another example, if the risk level represented by the target risk identification result of the target merchant in the potential customer stage is no risk, the target merchant is determined to be a high-quality merchant, and the management module 1 can inform the staff to expand the target merchant to develop it into a registered merchant of the service system 100.

[0101] For example, the risk management subsystem 30 corresponds to a management module 2 for managing the risk of a registered merchant. The management module 2 can set the permission of the target merchant in the current stage based on the risk level represented by the target risk identification result of the target merchant in the registered stage, or can also set the permission of the target merchant in the next stage. The permission includes but is not limited to: enjoying registered benefits, transaction limit, settlement limit, etc.

[0102] For example, if the risk level represented by the target risk identification result of the target merchant in the registered stage is high risk, the management module 2 can set the target merchant to a silent state, and the target merchant cannot perform transactions in the service system 100 in the future.

[0103] For example, if the risk level represented by the target risk identification result of the target merchant in the registered stage is medium risk, the management module 2 can limit the permission of the target merchant. For example, the management module 2 does not issue registered benefits to the target merchant. Or the management module 2 can also set the transaction limit or settlement limit of the target merchant to a low limit. Subsequently, when the target merchant performs the first K (an integer greater than or equal to 1) transactions in the transaction stage, the management module 2 determines whether to intercept the transactions based on the transaction limit.

[0104] For example, if the risk level represented by the target risk identification result of the target merchant in the registered stage is no risk, the target merchant is not limited in permission. The management module 2 can issue registered benefits to the target merchant in the registered stage. When the target merchant performs the first K (an integer greater than or equal to 1) transactions in the transaction stage, the management module 2 does not perform additional risk control on the target merchant.

[0105] For example, the risk management subsystem 30 corresponds to a management module 3 for updating the permission of a registered merchant. The management module 3 can update the permission of the target merchant in the transaction stage based on the risk level represented by the target risk identification result of the target merchant in the transaction stage.

[0106] For example, if the target merchant's risk level represented by the target risk identification result during the transaction phase is high risk, the management module 3 may perform a withdrawal operation on the target merchant.

[0107] For example, if the target merchant's target risk identification result in the transaction stage indicates a medium risk level, and the target merchant's historical risk identification result in the settlement stage indicates a low risk level, the management module 3 may update the target merchant's transaction limit from a high limit to a low limit.

[0108] For example, if the target merchant's target risk identification result in the transaction stage indicates a risk level of no risk, and the target merchant's historical risk identification result in the settlement stage indicates a risk level of medium risk, the management module 3 may update the target merchant's transaction limit from a low limit to no limit.

[0109] In some embodiments, method P300 further includes: in response to a risk display request from the target merchant, displaying the target risk identification results and profile information for the target merchant at the current stage. In this embodiment, the target risk identification results and profile information for the target merchant can be transparently transmitted in real time to the subsystem within service system 100 requiring risk management, thereby improving the response speed and risk control capabilities of the subsystem requiring risk management.

[0110] Exemplarily, after the risk identification subsystem 20 obtains the portrait information of the target merchant at the current stage, it can visually display the portrait information; or, after the risk identification subsystem 20 obtains the portrait information of the target merchant at the current stage, it stores it in the information storage subsystem 10. The information storage subsystem 10 can visually display the portrait information in real time, or it can visually display the portrait information after receiving a risk display request. After the risk identification subsystem 20 obtains the target risk identification result of the target merchant at the current stage, it can visually display the target risk identification result; or, after the risk identification subsystem 20 obtains the target risk identification result of the target merchant at the current stage, it stores it in the information storage subsystem 10. The information storage subsystem 10 can visually display the target risk identification result in real time, or it can visually display the target risk identification result after receiving a risk display request. Information transmission interfaces can be established between the information storage subsystem 10, the risk identification subsystem 20 and the risk management subsystem 30, respectively, for transparently transmitting the target risk identification result and portrait information.

[0111] It should be noted that, in the above example, the portrait information is obtained by the risk identification subsystem 20 , but this specification is not limited thereto, that is, the portrait information can also be obtained by other subsystems in the service system 100 .

[0112] To sum up, the merchant risk management method, the service system and the storage medium provided by the present application can realize automatic and tracking risk identification and risk management for the target merchant in the whole life cycle of the merchant, provide continuous risk identification and tracking management, improve the accuracy and efficiency of risk identification in each stage of the whole life cycle of the merchant, and make accurate risk management strategies for the merchant in each stage in time, improve the level and efficiency of automatic risk management of the service system for the merchant, reduce the cost of manual management, improve the security of transactions, and drive the healthy development of the service industry. Moreover, the scheme provided by the present application can perform risk pre-identification on the merchant in the potential customer stage, expand the risk management of the merchant to before registration, so that the merchant can be converted based on the risk identification result, and the quality of customer acquisition can be improved.

[0113] Another aspect of this specification provides a computer-readable non-transitory storage medium storing at least one set of executable instructions for performing merchant risk management. When the executable instructions are executed by a processor, the executable instructions direct the processor to implement the steps of method P300 described in this specification. In some possible implementations, various aspects of this specification may also be implemented in the form of a program product comprising program code. When the program product is executed on a service system 100, the program code is used to cause the service system 100 to perform the steps of method P300 described in this specification. The program product for implementing the above method may include the program code in a portable compact disc read-only memory (CD-ROM) and may be run on the service system 100. However, the program product of this specification is not limited to this. In this specification, a readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system. The program product may utilize any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. The readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or any combination thereof. More specific examples of computer-readable storage media include: an electrical connection having one or more conductors, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. The computer-readable storage medium may include a data signal propagated in baseband or as part of a carrier wave, which carries readable program code. Such a propagated data signal may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the foregoing. The computer-readable storage medium may also be any readable medium other than a readable storage medium that can transmit, propagate, or transfer a program for use by or in conjunction with an instruction execution system, apparatus, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical cable, RF, etc., or any suitable combination of the foregoing. Program code for performing the operations described herein may be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java, C++, and conventional procedural programming languages ​​such as C or similar programming languages. The program code may execute entirely on the server system 100, partially on the server system 100, as a stand-alone software package, partially on the server system 100 and partially on a remote computing device, or entirely on the remote computing device.

[0114] In the embodiments of this specification, the term "and / or" describes the relationship between associated objects, indicating that three possible relationships exist. For example, "A and / or B" can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone. The character " / " generally indicates that the associated objects are in an "or" relationship.

[0115] The terms "first", "second" and the like in this specification are used to distinguish similar or similar objects or entities, and are not necessarily meant to limit a specific order or sequence.

[0116] Unless otherwise stated, the term “plurality” mentioned in this specification should be understood to mean two or more.

[0117] The foregoing description of this specification describes specific embodiments. 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 an order different from that described in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the particular order or sequential order shown to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0118] In summary, after reading this detailed disclosure, those skilled in the art will appreciate that the foregoing detailed disclosure may be presented by way of example only and may not be limiting. Although not expressly stated herein, those skilled in the art will understand that this specification encompasses various reasonable changes, improvements, and modifications to the embodiments. Such changes, improvements, and modifications are intended to be suggested by this specification and are within the spirit and scope of the exemplary embodiments of this specification.

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

[0120] It should be understood that in the foregoing descriptions of the embodiments of this specification, to facilitate understanding of a feature and to simplify this specification, various features are combined in a single embodiment, figure, or description thereof. However, this does not necessarily mean that these features are combined. When reading this specification, a person skilled in the art may label some of the devices as separate embodiments. In other words, the embodiments of this specification can also be understood as the integration of multiple sub-embodiments. This also applies when each sub-embodiment contains fewer than all the features of a single previously disclosed embodiment.

[0121] Each patent, patent application, patent application publication, and other materials, such as articles, books, specifications, publications, documents, articles, and the like, cited herein, except to the extent that it is inconsistent or conflicting with this document or that it has a limiting effect on the broadest scope of the claims, is hereby incorporated by reference for all purposes now or hereafter connected with this document. In addition, in the event of any inconsistency or conflict between the description, definition, and / or use of a term in any material and the description, definition, and / or use of a term in this document, the term in this document shall control.

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

Claims

1. A merchant risk management method, applied to a service system, wherein the service system performs risk management on a target merchant throughout its entire life cycle, the method comprising: Determining a current stage of the target merchant in the full life cycle, wherein the full life cycle begins when the target merchant becomes a potential customer of the service system and ends when the target merchant deregisters from the service system; Using the risk identification method corresponding to the current stage, performing risk identification on the target merchant to obtain a target risk identification result; and During the remaining period of the current stage and / or in the next stage of the current stage, risk management is performed on the target merchant based on the target risk identification result.

2. The method according to claim 1, wherein The full life cycle includes at least two of the following stages: The potential customer stage corresponds to the period during which the target merchant serves as a potential customer of the service system; The settlement phase corresponds to the period during which the target merchant registers in the service system; The transaction phase corresponds to the period during which the target merchant conducts transactions in the service system.

3. The method according to claim 1, wherein The risk identification method corresponding to the current stage is used to perform risk identification on the target merchant to obtain a target risk identification result, including: Obtaining portrait information of the target merchant, the portrait information representing merchant characteristics of the target merchant within a target period, the target period being the period from the first stage of the full life cycle to the current stage; and The target risk identification result is obtained by adopting the risk identification method corresponding to the current stage and performing risk identification on the target merchant based on the portrait information.

4. The method according to claim 3, wherein: The portrait information is obtained based on the following methods: Searching from at least one data source based on the keywords of the target merchant to obtain search results related to the target merchant; and Feature extraction is performed on the search results from multiple dimensions to obtain the portrait information.

5. The method according to claim 4, wherein The feature extraction of the search results from multiple dimensions to obtain the portrait information includes: Processing the search results by guiding the large model through target guidance information to obtain merchant information of the target merchant, wherein the target guidance information represents a merchant information mining method for the target merchant, and the large model is trained to mine merchant information in the search results based on the guidance information; and Feature extraction is performed on the merchant information from multiple dimensions to obtain the portrait information.

6. The method according to claim 4, wherein: The at least one data source includes at least one of the following: The data source within the service system; Internet open website; Official internet websites; and The data source is provided by the partner of the service system.

7. The method according to claim 3, wherein: The adopting the risk identification method corresponding to the current stage to perform risk identification on the target merchant based on the portrait information to obtain the target risk identification result includes: Obtaining a risk identification model corresponding to the current stage, wherein different stages in the entire life cycle correspond to different risk identification models; and The portrait information is input into the risk identification model corresponding to the current stage to obtain the target risk identification result.

8. The method according to claim 7, wherein: Inputting the portrait information into the risk identification model corresponding to the current stage to obtain the target risk identification result includes: Obtaining historical risk identification results corresponding to the target merchant's historical stages before the current stage; and The historical risk identification results and the portrait information are input into the risk identification model corresponding to the current stage to obtain the target risk identification results.

9. The method according to claim 1, wherein Determining the current stage of the target merchant in the entire life cycle includes: Based on the registration status and / or transaction status of the target merchant in the service system, the current stage of the target merchant in the full life cycle is determined.

10. The method according to claim 9, wherein: Determining the current stage of the target merchant in the full life cycle based on the registration status and / or transaction status of the target merchant in the service system includes any of the following: If the target merchant is not a registered merchant in the service system, it is determined that the target merchant is in the potential customer stage; If the target merchant is a registered merchant in the service system and there is no transaction record of the target merchant in the service system, it is determined that the target merchant is in the settlement stage; or If the target merchant has a transaction record in the service system, it is determined that the target merchant is in the transaction stage.

11. The method according to claim 3, wherein: The method further comprises: In response to the risk display request of the target merchant, the target risk identification result and the portrait information are displayed.

12. A service system for performing risk management on a target merchant throughout its life cycle, comprising: at least one storage medium storing at least one instruction set for performing risk management for merchants; as well as At least one processor is communicatively connected to the at least one storage medium, wherein the at least one processor reads the at least one instruction set when running and, according to instructions of the at least one instruction set: Determining the current stage of the target merchant in the full life cycle, wherein the full life cycle starts from the target merchant becoming a potential customer of the service system and ends when the target merchant deregisters from the service system, Using the risk identification method corresponding to the current stage, the target merchant is identified for risk to obtain a target risk identification result, and During the remaining period of the current stage and / or in the next stage of the current stage, risk management is performed on the target merchant based on the target risk identification result.

13. The service system according to claim 12, wherein: The full life cycle includes at least two of the following stages: The potential customer stage corresponds to the period during which the target merchant serves as a potential customer of the service system; The settlement phase corresponds to the period during which the target merchant registers in the service system; The transaction phase corresponds to the period during which the target merchant conducts transactions in the service system.

14. The service system according to claim 12, wherein: In order to obtain the target risk identification result, the at least one processor: Obtaining portrait information of the target merchant, wherein the portrait information represents merchant characteristics of the target merchant within a target period, wherein the target period is a period from the first stage of the full life cycle to the current stage; as well as The target risk identification result is obtained by adopting the risk identification method corresponding to the current stage and performing risk identification on the target merchant based on the portrait information.

15. The service system according to claim 14, wherein: The portrait information is obtained based on the following methods: Searching from at least one data source based on the keywords of the target merchant to obtain search results related to the target merchant; and Feature extraction is performed on the search results from multiple dimensions to obtain the portrait information.

16. The service system according to claim 15, wherein: In order to obtain the portrait information, the at least one processor: The target guidance information guides the large model to process the search results to obtain the merchant information of the target merchant, wherein the target guidance information represents the merchant information mining method for the target merchant, and the large model is trained to mine the merchant information in the search results based on the guidance information; as well as Feature extraction is performed on the merchant information from multiple dimensions to obtain the portrait information.

17. The service system according to claim 15, wherein: The at least one data source includes at least one of the following: The data source within the service system; Internet open website; Official internet websites; and The data source is provided by the partner of the service system.

18. The service system according to claim 14, wherein: In order to obtain the target risk identification result, the at least one processor: Obtaining a risk identification model corresponding to the current stage, wherein different stages in the entire life cycle correspond to different risk identification models; and The portrait information is input into the risk identification model corresponding to the current stage to obtain the target risk identification result.

19. The service system according to claim 18, wherein: In order to obtain the target risk identification result, the at least one processor: Obtain historical risk identification results corresponding to the target merchant's historical stages before the current stage; as well as The historical risk identification results and the portrait information are input into the risk identification model corresponding to the current stage to obtain the target risk identification results.

20. A computer-readable non-transitory storage medium, wherein: The computer-readable non-transitory storage medium stores at least one instruction set, and when the at least one instruction set is executed by at least one processor, the method according to any one of claims 1 to 11 is implemented.

Images