CN110910041A

CN110910041A - Risk control method, system and device

Info

Publication number: CN110910041A
Application number: CN201911224554.9A
Authority: CN
Inventors: 汲小溪; 郑霖; 嵇方方; 陆梦倩; 王维强; 赵闻飚
Original assignee: Alipay Hangzhou Information Technology Co Ltd
Current assignee: Alipay Hangzhou Information Technology Co Ltd
Priority date: 2019-12-04
Filing date: 2019-12-04
Publication date: 2020-03-24
Also published as: WO2021109667A1

Abstract

The embodiment of the specification discloses a risk management and control method. The method may include at least one of the following. Merchant information associated with the target merchant may be obtained. At least a business type associated with the target merchant may be determined based on the merchant information. A predicted risk value for the target merchant for the business type may be determined based at least on the first model and the merchant information. And executing preset control operation corresponding to the risk estimated value on the target merchant based on the risk estimated value. The method disclosed by the embodiment of the specification can realize one-stop intelligentization of the risk management of the commercial tenant, improves the accuracy and timeliness of the risk management of the commercial tenant, and has the privacy security calculation capability.

Description

Risk control method, system and device

Technical Field

The embodiment of the specification relates to the technical field of data processing, in particular to a risk management and control method, system and device based on merchant related data.

Background

The payment platform enables the merchant to be free from the region limitation, and the business can be developed by adding the payment platform. With the development of payment platforms, the number of merchants accessing the platforms is increasing. Therefore, it is increasingly important for merchants to manage and control risks. At present, the risk management of merchants implements full link risk management and control, the service complexity is high, and the dependence on manual audit is high. Once the merchant signs a contract and the query magnitude is large, the timeliness and the accuracy of the wind control audit cannot be guaranteed by manpower.

Disclosure of Invention

One aspect of embodiments of the present specification provides a method of risk management. The method may include at least one of the following operations. Acquiring merchant information related to a target merchant; at least determining the business type related to the target merchant based on the merchant information; determining a risk pre-evaluation value of the target merchant for the business type at least based on a first model and the merchant information; and executing preset control operation corresponding to the risk estimated value on the target merchant based on the risk estimated value.

Another aspect of embodiments of the present specification provides a risk management system. The system comprises an acquisition module, a determination module and a management and control module. The acquisition module is used for acquiring merchant information related to a target merchant. The determining module is used for at least determining the business type related to the target merchant based on the merchant information; and determining a risk pre-evaluation value of the target merchant for the business type based on at least the first model and the merchant information. And the management and control module is used for executing preset management and control operation corresponding to the risk estimated value on the target merchant based on the risk estimated value.

Another aspect of embodiments of the present specification provides a risk management device. The apparatus includes a processor and a memory; the memory is to store instructions. The instructions, when executed by the processor, cause the apparatus to implement a risk management method as described above.

Drawings

The present description will be further described by way of exemplary embodiments, which will be described in detail by way of the accompanying drawings. These embodiments are not intended to be limiting, and in these embodiments like numerals are used to indicate like structures, wherein:

fig. 1 is a schematic diagram of an exemplary risk management system, shown in accordance with some embodiments of the present description;

FIG. 2 is a block diagram representation of an exemplary processing device shown in accordance with some embodiments of the present description;

FIG. 3 is an exemplary flow diagram of a risk management method shown in accordance with some embodiments of the present description;

FIG. 4 is an exemplary flow diagram illustrating obtaining relevant merchant information for a target merchant according to some embodiments of the present description;

FIG. 5 is an exemplary flow diagram illustrating the determination of a risk prediction value according to some embodiments of the present description;

FIG. 6 is a block diagram of an exemplary processing device shown in accordance with some embodiments of the present description;

FIG. 7 is a schematic diagram of an exemplary merchant knowledge-graph, shown in accordance with some embodiments of the present description.

Detailed Description

In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the drawings used in the description of the embodiments will be briefly described below. It is obvious that the drawings in the following description are only examples or embodiments of the present description, and that for a person skilled in the art, the present description can also be applied to other similar scenarios on the basis of these drawings without inventive effort. Unless otherwise apparent from the context, or otherwise indicated, like reference numbers in the figures refer to the same structure or operation.

It should be understood that "system", "device", "unit" and/or "module" as used in this specification is a method for distinguishing different components, elements, parts or assemblies at different levels. However, other words may be substituted by other expressions if they accomplish the same purpose.

As used in this specification and the appended claims, the terms "a," "an," "the," and/or "the" are not intended to be inclusive in the singular, but rather are intended to be inclusive in the plural, unless the context clearly dictates otherwise. In general, the terms "comprises" and "comprising" merely indicate that steps and elements are included which are explicitly identified, that the steps and elements do not form an exclusive list, and that a method or apparatus may include other steps or elements.

Flow charts are used in this description to illustrate operations performed by a system according to embodiments of the present description. It should be understood that the preceding or following operations are not necessarily performed in the exact order in which they are performed. Rather, the various steps may be processed in reverse order or simultaneously. Meanwhile, other operations may be added to the processes, or a certain step or several steps of operations may be removed from the processes.

The term "merchant" as used in this specification may refer to a marketing entity engaged in a transaction for goods and/or services having a physical place of business and/or an online network address. For example, a "merchant" may be a hotel that provides a food and drink service or a store that sells clothing over a network. The term "payment platform" may refer to a funding network platform set up by a third party payment authority that provides funding solutions. The "merchant" may have access to a "payment platform" through which funds transfer with other entities, such as consumers, other "merchants", "facilitators", banks (e.g., commercial banks) is accomplished. It should be understood that the application scenarios of the system and method mentioned in this specification are only examples or embodiments of this specification, and it will be obvious to those skilled in the art that the present specification can also be applied to other similar scenarios according to these drawings without inventive effort.

Fig. 1 is a schematic diagram of an exemplary risk management system, shown in accordance with some embodiments of the present description. In some embodiments, the risk management and control system 100 may be configured to determine a risk level of a merchant accessing the online payment platform, and perform different management and control operations on the merchant based on the risk level, for example, dynamically monitor the intermediate-risk merchant and perform early warning. As shown in fig. 1, the risk management system 100 may include a processing device 110, a business cluster 120, a storage device 130, and a network 140.

Processing device 110 may be used to process information and/or data associated with a merchant that is to access a payment platform to perform one or more of the functions disclosed in this specification. For example, processing device 110 may determine a type of business associated with the merchant based on the obtained merchant information. As another example, the processing device 110 may use the model to obtain an estimate of the risk that the merchant has for the type of business. For example, the processing device 110 may perform different operations for regulating the merchant according to the obtained risk estimation value. Also for example, the processing device 110 may update the models and/or algorithms used throughout the risk management flow. In some embodiments, the processing device 110 may include one or more processing engines (e.g., single core processing engines or multi-core processors). By way of example only, the processing device 110 may include one or more combinations of a central processing unit (cpu), an Application Specific Integrated Circuit (ASIC), an application specific instruction set processor (ASIP), an image processor (GPU), a physical arithmetic processing unit (PPU), a Digital Signal Processor (DSP), a Field Programmable Gate Array (FPGA), a Programmable Logic Device (PLD), a controller, a microcontroller unit, a Reduced Instruction Set Computer (RISC), a microprocessor, and the like. In some embodiments, the processing device 110 may be a server of the payment platform itself, or may be a processing device external to the payment platform. Any merchant interfacing with the payment platform may have information associated with it acquired and processed by the processing device 110.

The business segment 120 may include individuals, e.g., businesses, merchants, individuals, etc., that have data traffic with the processing device 110. In some embodiments, the business segment 120 may include a bank 120-1, an facilitator 120-2, a merchant 120-3, and so forth. In some embodiments, business cluster 120 may include different levels of individuals, which may be interconnected, depending on the mode of connection of the individuals to the platform. For example, a business group may include direct individuals and indirect individuals. The direct connection individual can mean that the individual has a protocol relationship with the platform and directly receives platform management. The inter-connected individuals can mean that the individuals do not have a protocol relationship with the platform, but have a protocol relationship with a third party and receive platform management through the third party. The third party may include a direct connection individual, or an organization that cooperates with the platform. In some embodiments, a business cluster may be based on a computer device sending data and/or co-modeling with a processing device over a network to a processing device or a storage device, the sent data and modeling may be encrypted. In some embodiments, the transmitted data may include business data, attribute data, credit data, etc. of the individual. The business data of an individual may include the individual's turnover, gross interest rate, cost, business trends, and the like. The attribute data may include the name, address, ID, hours of operation, business license, cell phone number, identification number, etc. of the individual. The credit data may include credit investigation records, loan amounts, loan frequency, rates of equity, etc. for the individual. In some embodiments, the service group 120 may also include a terminal 120-4, and the terminal 120-4 may be used by a user (also referred to as a consumer). The terminal 120-4 may include, but is not limited to, a mobile device, a computer (e.g., a tablet, a laptop, a desktop kiosk), etc., or any combination thereof. Exemplary mobile devices may include, but are not limited to, smart phones, Personal Digital Assistants (PDAs), cash registers, handheld game consoles, smart glasses, smart watches, wearable devices, virtual display devices, display enhancement devices, and the like, or any combination thereof. Through the terminal 120-4, the user may create associations with other individuals in the service group 120. For example, a user's payment at a merchant 120-3 may result in transaction data associated with the merchant 120-3. In some embodiments, the terminal may send the transaction data to the processing device 110 or the storage device 130 over a network.

Storage device 130 may store data and/or instructions. In some embodiments, the storage device 130 may store the collected data. The data may include raw data related to the service group 120. Such as business data, attribute data, credit data, etc. of the individual. In some embodiments, the data may also include other data that has been processed. Such as knowledge-graph data, etc. In some embodiments, storage device 130 may store data and/or instructions for execution or use by processing device 110, which processing device 110 may execute or use to implement the example methods of this specification. In some embodiments, the storage device 130 may be connected to a network 140 to enable communication with one or more components (e.g., processing devices 110, business groups 120, etc.) in the risk management system 100. One or more components of risk management system 100 may access data or instructions stored in storage 130 via network 140. In some embodiments, the storage device 130 may be directly connected or in communication with one or more components of the risk management system 100 (e.g., the processing devices 110, the business group 120, etc.). In some embodiments, the storage device 130 may be part of the processing device 110. In some embodiments, storage 130 may include mass storage, removable storage, volatile read-write memory, read-only memory (ROM), and the like, or any combination thereof. Exemplary mass storage may include magnetic disks, optical disks, solid state disks, and the like. Exemplary removable memory may include flash drives, floppy disks, optical disks, memory cards, compact disks, magnetic tape, and the like. Exemplary volatile read-only memory can include Random Access Memory (RAM). Exemplary RAM may include Dynamic RAM (DRAM), double-data-rate synchronous dynamic RAM (DDR SDRAM), Static RAM (SRAM), thyristor RAM (T-RAM), zero-capacitance RAM (Z-RAM), and the like. Exemplary ROMs may include Mask ROM (MROM), Programmable ROM (PROM), erasable programmable ROM (PEROM), Electrically Erasable Programmable ROM (EEPROM), compact disk ROM (CD-ROM), digital versatile disk ROM, and the like. In some embodiments, storage device 130 may be implemented on a cloud platform. By way of example only, the cloud platform may include a private cloud, a public cloud, a hybrid cloud, a community cloud, a distributed cloud, an internal cloud, a multi-tiered cloud, and the like, or any combination thereof. For example, some algorithms or data in this specification may be stored on a certain cloud platform, and are periodically updated, and the processing device 110 accesses these algorithms or data through a network, so as to implement uniform and interactive algorithms or data of the whole platform. In particular, some historical data may be uniformly stored on one cloud platform of the platform so that a plurality of processing devices 110 or business groups 120 can access or update the historical data, and therefore real-time performance and cross-platform use of the data are guaranteed. For example, the service group 120 may publish offline network payment transaction data to a certain cloud platform at any time, and the system may perform regional recommendation operations according to data of a plurality of service groups 120.

In some embodiments, network 140 may facilitate the exchange of information and/or data. In some embodiments, one or more components of risk management system 100 (e.g., processing devices 110, business clusters 120, storage devices 130, etc.) may transmit information to other components of risk management system 100 via network 140. For example, processing device 110 may retrieve information and/or data associated with a region from storage device 130 via network 140. In some embodiments, the network 140 may be any form of wired or wireless network, or any combination thereof. By way of example only, network 140 may be a wireline 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 Wide Area Network (WAN), a Public Switched Telephone Network (PSTN), a Bluetooth network, a ZigBee network, a Near Field Communication (NFC) network, a global system for mobile communications (GSM) network, a Code Division Multiple Access (CDMA) network, a Time Division Multiple Access (TDMA) network, a General Packet Radio Service (GPRS) network, an enhanced data rates for GSM evolution (EDGE) network, a Wideband Code Division Multiple Access (WCDMA) network, a High Speed Downlink Packet Access (HSDPA) network, a Long Term Evolution (LTE) network, a User Datagram Protocol (UDP) network, a Transmission control protocol/Internet protocol (TCP/IP) network, a Short Message Service (SMS) network, a wireless application protocol (SMS) network, a wireless access point-to-point network, one or more combinations of ultra-wideband (UWB) networks, mobile communication (1G, 2G, 3G, 4G, 5G) networks, Wi-Fi, Li-Fi, narrowband Internet of things (NB-IoT), infrared communication, and the like. In some embodiments, network 140 may include one or more network access points. For example, the network 140 may include wired or wireless network access points such as base stations and/or Internet switching points 140-1, 140-2, …. Through which one or more components of risk management system 100 may connect to network 140 to exchange information and/or data.

Fig. 2 is a block diagram of an exemplary processing device shown in accordance with some embodiments of the present description. Processing device 110 may include any components used to implement the systems described in embodiments herein. For example, the processing device 110 may be implemented in hardware, software programs, firmware, or a combination thereof. For convenience, only one processing device is depicted in the figures, but the computing functions described in the embodiments herein with respect to the risk management system 100 may be implemented in a distributed manner by a set of similar platforms to distribute the processing load of the system.

In some embodiments, processing device 110 may include a processor 210, a memory 220, an input/output component 230, and a communication port 240. In some embodiments, the processor (e.g., CPU)210 may execute program instructions in the form of one or more processors. In some embodiments, the memory 220 includes different forms of program memory and data storage, such as a hard disk, Read Only Memory (ROM), Random Access Memory (RAM), etc., for storing a variety of data files for processing and/or transmission by a computer. In some embodiments, the input/output component 230 may be used to support input/output between the processing device 110 and other components. In some embodiments, the communication port 240 may be connected to a network for enabling data communication. An exemplary processing device may include program instructions stored in Read Only Memory (ROM), Random Access Memory (RAM), and/or other types of non-transitory storage media that are executed by processor 210. The methods and/or processes of the embodiments of the present specification may be implemented as program instructions. The processing device 110 may also receive the programs and data disclosed in this specification through network communication.

For ease of understanding, only one processor is exemplarily depicted in fig. 2. However, it should be noted that the processing device 110 in the embodiment of the present specification may include a plurality of processors, and thus, the operations and/or methods described in the embodiment of the present specification, which are implemented by one processor, may also be implemented by a plurality of processors, collectively or independently. For example, if in this specification the processors of processing device 110 perform steps 1 and 2, it should be understood that steps 1 and 2 may also be performed by two different processors of processing device 110, either collectively or independently (e.g., a first processor performing step 1, a second processor performing step 2, or a first and second processor performing steps 1 and 2 collectively).

Fig. 3 is an exemplary flow diagram of a risk management method according to some embodiments of the present description. In some embodiments, one or more steps of method 300 may be implemented in system 100 shown in FIG. 1. For example, one or more steps of method 300 may be stored as instructions in storage device 130 and/or memory 220 and invoked and/or executed by processing device 110 and/or processor 210.

At step 310, merchant information associated with the target merchant is obtained. Step 310 may be performed by an acquisition module 610.

In some embodiments, the target merchant may be a merchant that is to access and/or has access to a payment platform. For example, a particular restaurant may wish to access a payment platform for the purpose of quick and easy collection of food fees (e.g., a consumer may pay directly by scanning a code to avoid cumbersome cash collection and change). For another example, a clothing store that joins an online consumer platform may wish to broaden the payment method and route through the payment platform to attract more online consumers (e.g., increase the number of quick payment methods implemented through the payment platform).

In some embodiments, the target merchant needs to submit verification information for the payment platform to determine whether to allow the payment platform to access when preparing to access the payment platform. The verification information may include, for example, merchant owner identity information, place of business, license number, bank account number, and the like. It will also be appreciated that when the target merchant is ready to access the payment platform, a large number (e.g., in billions) of merchants are already accessed and present in the payment platform. There may be associated information between these large numbers of merchants and the target merchant. For example, the target merchant is a provider of an accessed merchant, and the accessed merchant performs fund clearing with the target merchant through a payment platform and pays funds to a bank account of the target merchant. Therefore, the merchant information related to the target merchant may include the verification information submitted by the target merchant, and may also include association information with other merchants in the payment platform. In some embodiments, the obtaining module 610 may obtain the merchant information described above by communicating with the business segment 120 and/or the storage device 130. For example, the acquisition module 510 may communicate directly with the merchant 120-3 to acquire the verification information submitted by the target merchant. As another example, the obtaining module 510 may access to read data stored on the storage device 130 to obtain association information between the target merchant and other merchants in the payment platform. For the specific description of the merchant information and obtaining the merchant information, reference may be made to the description of other parts in this specification, for example, fig. 4, which is not described herein again.

Step 320, at least determining the business type related to the target merchant based on the merchant information. Step 320 may be performed by determination module 620 (or traffic type determination unit 622).

In some embodiments, the business type associated with the target merchant may be an industry engaged in by the merchant. For example, the business types may include dining (e.g., dinners, snacks, milky tea, coffee, etc.), entertainment (e.g., bars, KTVs, game arcades, movie theaters, etc.), department goods (e.g., clothing, shoes, jewelry, etc.), service businesses (e.g., intermediaries, travel agencies, designs, investments, counseling, courier, etc.), and so forth. In some embodiments, the merchant information may also include at least one modality data of the target merchant. The modal data may represent the morphology of the target merchant in different forms including images, text, addresses, transactions, and the like. For example, the image may show the actual size of a store owned by the target merchant, as well as the specific business activity engaged in the store. The text may directly literally obtain specific information such as location, sold goods, etc. of the target merchant. The address may indicate a specific location of the target merchant, while the transaction may determine other entities that have funded with the target merchant, thereby indicating an approximate extent of the business of the target merchant.

As described above, the modal data may reflect to some extent the type of business associated with the target merchant. In some embodiments, the determining module 620 (or the business type determining unit 622) may fuse the at least one modal data using the second model to obtain the business type associated with the target merchant. The second model may be a single model, and may be capable of extracting, for each of the inputted plurality of modal data, a feature related to the service type related to the target merchant, and fusing and outputting a final result, for example, the second model may be a feature mapping table. The feature mapping table records the mapping relation between each feature or combination of features and the service type, and the service type related to the target merchant can be directly obtained based on the feature mapping table. The second model may also be a combination of two or more models. For example, the second model may include a semantic extraction model such as HMM or CFR, etc. and an image recognition model CNN. The characteristic information related to the business type can be obtained by identifying and extracting the input characters and/or images, and the business type related to the target merchant is finally obtained.

In some embodiments, for each modal data, the determining module 620 (or the service type determining unit 622) may respectively obtain the feature data corresponding to the modal data based on the extraction model corresponding to the modal data. For example, the extraction models corresponding to images and characters are different, and the pertinence is better. The effect is better than using a single second model for feature calculation or extraction. The extraction model may be selected from machine learning models, e.g., regression models (linear or logistic regression), naive bayes, decision trees, SVMs, KNNs, neural networks, and the like. After obtaining the feature data corresponding to each modal data, the determining module 620 (or the service type determining unit 622) may fuse the feature data corresponding to the at least one modal data to obtain the service type related to the target merchant. One or more decision fusion algorithms and/or models may be used to fuse the feature data, e.g., statistics, probability analysis, template matching, bayesian inference, neural networks, DS (Dempster-Shafer) evidence theory, etc. The feature data obtained using the extraction model may be used as input to a decision fusion algorithm and/or model to obtain an output of the business type associated with the target merchant.

In some embodiments, the determining module 620 (or the business type determining unit 622) may first determine a representation of each of the at least one modal data, and fuse the at least one representation based on a fusion model to obtain the business type related to the target merchant. The representation may refer to XXX. For example XXX. The fusion model can include a multi-layer neural network, e.g., AlexNet, VGG Net, GoogleNet, ResNet, ResNeXt, CNN, R-CNN, FCN, RNN, YOLO, SqueezeNet, SegNet, GAN, and the like. By using the multilayer neural network, the representation of each mode can be fused layer by layer, so that the data extraction and processing are more accurate. After obtaining the respective representations of the respective modality data, the determining module 620 (or the service type determining unit 622) may input the representations into the fusion model to obtain a joint representation of the respective modality data. The joint representation may refer to XXX. Finally, the determining module 620 (or the business type determining unit 622) may obtain the business type related to the target merchant based on the joint representation.

Step 330, determining a risk pre-estimated value of the target merchant for the business type based on at least the first model and the merchant information. Step 330 may be performed by the determination module 620 (or the risk prediction value determination unit 624).

In some embodiments, the risk pre-evaluation value may be used to indicate the risk level that may exist when the target merchant develops the type of business associated with the target merchant. The risk prediction value can be expressed using a numerical value, with the higher the numerical value, the higher the risk. The risk prediction value may also be represented by a range of values, or a hierarchy. Each level corresponds to a risk size level (e.g., high risk, medium risk, low risk). The first model (or referred to as a global model) may be a model for predicting risk prediction values that may exist when a new merchant enters the industries to perform business, based on relevant merchant information of merchants in the industries and risk values or risk levels faced by the merchants in actual situations. The first model may be a machine learning model, for example. Regression models (linear or logistic regression), naive bayes, decision trees, SVMs, KNNs, neural networks, and the like. Alternatively, the first model may be one of neural networks, such as AlexNet, VGG Net, GoogleNet, ResNet, ResNeXt, R-CNN, YOLO, SqueezeNet, SegNet, GAN, and the like. In some embodiments, the determination module 620 (or the risk estimate determination unit 624) may determine the risk estimate directly based on the first model. For example, when it is determined that the business type related to the target merchant is related to the industry where the merchant corresponding to the merchant information used for training the first model is located, the determining module 620 (or the risk pre-evaluation value determining unit 624) may directly input the merchant information of the target merchant into the first model to obtain the corresponding risk pre-evaluation value. In some embodiments, the determining module 620 (or risk prediction value determining unit 624) may first obtain an adaptation model based on the first model, and determine a risk prediction value existing for the business type by the target merchant based on the adaptation model. For example, when the business type related to the target merchant is an industry that does not relate to any merchant corresponding to the merchant information used for training the universe model. For a detailed description of the risk estimation value, reference may be made to other parts of the present specification, for example, fig. 5, which are not described herein again.

In some embodiments, the first model and/or the adapted model may be updated. The update operation may be performed by the update module 640. After the risk estimated value of the target merchant is determined, the updating module 640 may use the risk estimated value of the target merchant and the merchant information as a new training sample, and continue to train the first model by using the training sample, so that the adaptability of the first model is wider.

And step 340, executing a preset control operation corresponding to the risk estimated value on the target merchant based on the risk estimated value. Step 340 may be performed by administration module 630.

In some embodiments, the governing module 630 may determine whether the predicted risk value satisfies a predetermined condition. The preset condition may be that the risk prediction value is within a preset threshold. The preset threshold range may be a preset parameter of the processing device 110, or may be adjusted according to different situations (e.g., for different target merchants). Which may be a range of values representing an intermediate risk level. In some embodiments, when the risk pre-estimated value corresponding to the target merchant is smaller than the minimum endpoint value of the preset threshold range, or the risk pre-estimated value belongs to a low risk class, the management and control module 530 may consider that the target merchant belongs to a trusted merchant, and may allow the target merchant to access the platform. In some embodiments, when the risk pre-estimated value corresponding to the target merchant is greater than the maximum endpoint value of the preset threshold range, or the risk pre-estimated value belongs to a high risk level, the management and control module 630 may consider the target merchant to be at a high level. In such a case, the governing module 630 may transfer the target merchant to a manual platform for risk attribution and governing decisions. In some embodiments, when the risk estimation value meets the preset condition, that is, when the risk corresponding to the target merchant is considered to be at a medium level, the management and control module 630 may reacquire merchant information related to the target merchant at preset time intervals and update the risk estimation value of the target merchant. The preset time interval may be a default value for the processing device 110, e.g. one day, one week, one month. The adjustment can be performed at any time in a quarter, a year, and the like, and the specification is not particularly limited. The obtained merchant information may include verification information that is re-submitted by the target merchant, and also includes new association information that is generated by the target merchant and is associated with other accessed merchants after the preset time interval. Thereafter, the management and control module 630 may directly input the merchant information of the target merchant obtained again into the first model or the adaptation model to determine the risk pre-evaluation value of the target merchant again. Or the management and control module 630 may re-determine the industry type of the target merchant based on the re-acquired merchant information of the target merchant, re-determine an adaptation model based on the industry type, and determine a risk pre-estimation value based on the re-determined adaptation model. It is to be understood that the above-described preset regulating operation is an iterative process. When the risk prediction value of the target merchant determined again at a certain time is not within the preset threshold range, the preset control operation may be stopped. At this time, enough merchant information is obtained to determine whether the target merchant belongs to a low risk level or a high risk level, and corresponding management and control measures are taken.

In some embodiments, the data used in the flow 300 (e.g., merchant information, etc.) and/or the model used (e.g., first model, adaptation model, second model, extraction model, fusion model, etc.) may be encrypted. Since in the flow 300 the data and portions of the model are provided by the merchant itself and/or partners of the payment platform (e.g., banks), a large amount of user information is involved, requiring encryption in order to protect user privacy and security. The encryption may be performed by the encryption module 650. In some embodiments, the encryption may be with the acquired data and/or model in a trusted execution environment, and/or with a model used for training with a distributed machine learning algorithm. The trusted execution environment may be a secure area running in a separate environment, where the confidentiality and integrity of the data and model loaded in the trusted execution environment may be protected. Distributed machine learning may take the form of shared memory (or virtual memory) based multi-threaded and/or multi-host parallel operations. For example only, the trusted execution environment may be determined based on SGX (software Guard extensions). SGX may protect code or data that is not intended to be disclosed or modified. SGX implements a trusted execution environment by using a bounding box (i.e., a protected execution area in memory). As another example, the model may be trained with a federal learning algorithm. The Federal learning algorithm is a distributed machine learning method, each party participating in the method can build a model together on the premise of not disclosing original data, the fact that the own data of each party cannot be sent out locally is achieved, interactive operation is conducted through an encryption mechanism, and under the condition that data privacy regulations are not violated, the model of each party is optimized by means of the middle results of model training of other parties.

It should be noted that the above description of the process 300 is for illustration and description only and is not intended to limit the scope of the present disclosure. Various modifications and changes to flow 300 will be apparent to those skilled in the art in light of this description. However, such modifications and variations are intended to be within the scope of the present description.

Fig. 4 is an exemplary flow diagram illustrating obtaining relevant merchant information for a target merchant according to some embodiments of the present description. In some embodiments, one or more steps of method 400 may be implemented in system 100 shown in FIG. 1. For example, one or more steps of method 400 may be stored as instructions in storage device 130 and/or memory 220 and invoked and/or executed by processing device 110 and/or processor 210. In some embodiments, the method 400 may be performed by the acquisition module 610.

At step 410, initial merchant information associated with the target merchant is obtained.

In some embodiments, the initial merchant information may include verification information submitted by the target merchant at an access payment platform, and may include attribute data, credit data, business data, and the like of the target merchant. The attribute data may include a merchant name, a merchant registration address, a business license, a merchant owner contact, a merchant owner identification number, an ID (e.g., an identification number specified by the payment platform for the target merchant when registering an account of the payment platform), a bank account, etc. The credit data may include credit investigation records, loan amounts, loan frequency, rates of equity, credit scores, and the like. The business data may include business hours, amount of orders, amount of deals, gross interest rate, cost, trends in deals, etc. In some embodiments, the initial merchant information may include at least an identification for providing at least a distinguishing attribute of the target merchant. The distinguishing attributes may refer to attributes that distinguish the target merchant from other merchants. Such as a store name. To uniquely indicate the target merchant, the identification may be the ID. In some embodiments, merchant 120-3 (e.g., the target merchant) may transmit the initial merchant information directly to the acquisition module 610 through network 140.

Step 420, determining the category of the target merchant based on the identification.

In some embodiments, the categories of target merchants may include new merchants and existing merchants. The new merchant may refer to a merchant whose matched merchant information is not included in the platform database. The existing merchant may refer to a merchant whose matched merchant information is already contained in the platform database. In some embodiments, the obtaining module 610 may determine the target merchant as a new merchant or an existing merchant based on the identification using a merchant knowledge-graph. The merchant knowledge-graph may refer to a knowledge base consisting of a series of merchant entities and relationships between merchant entities. The entities in the merchant knowledge graph may include merchant subjects (e.g., direct merchants, indirect merchants, applet merchants, etc.), payment platform accounts (e.g., buyer accounts, payee accounts, etc.), various media (e.g., identification numbers, business license numbers, cell phone numbers, wifi devices, etc.), recommenders, and the like. The relationship in the merchant knowledge graph may include a recommendation relationship, a consumption relationship, a transfer relationship, a media usage relationship, and the like. Referring to fig. 7, fig. 7 is a schematic diagram of an exemplary merchant knowledge-graph, shown in accordance with some embodiments of the present description. As shown in fig. 6, in the exemplary merchant knowledge-graph, circles may represent entities (also referred to as nodes), and lines between circles may represent relationships (also referred to as edges). In some embodiments, two entities being directly connected may indicate that the two entities have a direct relationship, and two entities being connected by at least two edges may indicate that the two entities have an indirect relationship. For example, entity 1 has a direct relationship with entity 3 and entity 2 has an indirect relationship with entity 8. In some embodiments, each entity may be connected with one or more entities. In the merchant knowledge-graph, each entity is associated through various relationships. Thus, the entity can be expressed in a variety of forms. And, through the merchant knowledge-graph, the relationship between entities can be passed. In some embodiments, the obtaining module 610 may search for an entity related to the target merchant through the identification of the target merchant based on the merchant knowledge-graph, and may determine whether the target merchant is a new merchant or an existing merchant through the search.

Step 430, designating the initial merchant information as the merchant information related to the target merchant.

In some embodiments, when the target merchant is determined to be a new merchant, the acquisition module 610 may directly designate the initial merchant information as the merchant information related to the target merchant.

Step 440, obtaining entity information related to the target merchant from the merchant knowledge graph based on the identifier, and designating the entity information and the initial merchant information as the merchant information related to the target merchant.

In some embodiments, when it is determined that the target merchant is an existing merchant, the obtaining module 610 may obtain entity information of other entities having a connection relationship with an entity corresponding to the target merchant according to the merchant knowledge graph. The entity information may include, for example, attribute data, credit data, business data, etc. submitted by the entity when accessing the payment platform, business data generated after accessing the payment platform, and the relationship between the entity and the target merchant. Thereafter, the obtaining module 610 may designate the entity information and the initial merchant information as the merchant information related to the target merchant.

In some embodiments, the merchant knowledge-graph may be updated. The updating of the merchant knowledge-graph may be performed by an update module 640. For example, for a new merchant, the updating module 640 may add an entity to the knowledge graph, determine a relationship between the new merchant and other entities based on the information of the new merchant, and establish a connection between the new merchant and the associated entity. For another example, for an existing merchant, the updating module 640 may determine, according to the merchant information, a change in a relationship between the existing merchant and another entity, add a newly established relationship, and remove an invalidated relationship.

It should be noted that the above description related to the flow 400 is only for illustration and description, and does not limit the applicable scope of the present specification. Various modifications and changes to flow 300 will be apparent to those skilled in the art in light of this description. However, such modifications and variations are intended to be within the scope of the present description.

FIG. 5 is an exemplary flow diagram illustrating the determination of a risk prediction value according to some embodiments of the present description. In some embodiments, one or more steps of method 500 may be implemented in system 100 shown in FIG. 1. For example, one or more steps of method 500 may be stored as instructions in storage device 130 and/or memory 220 and invoked and/or executed by processing device 110 and/or processor 210. In some embodiments, the method 500 may be performed by the determination module 620 (or the risk prediction value determination unit 624).

Step 510, determining whether the first model is adapted to the traffic type.

In some embodiments, the adapting may be understood as that the business where the merchant corresponding to the merchant information used for training the first model is located includes the business type related to the target merchant. For example, assuming that the training samples for training the first model are taken from the catering industry, the department industry and the entertainment industry, if the business type related to the target merchant is selling clothes, shoes and caps, the business type related to the target merchant can be considered to belong to the industry where the merchant corresponding to the merchant information for training the first model is located (the clothes, shoes and caps are sold and belong to the department industry). If the business type related to the target merchant is legal consultation, the business type related to the target merchant is not considered to belong to the industry where the merchant corresponding to the merchant information for training the first model is located (the legal consultation belongs to the service industry). For example, the first may be considered to be a fit, while the second may be considered to be a non-fit. In some embodiments, if the first model is adapted to the traffic type, process 500 may proceed to step 520. Otherwise, flow 500 may proceed to step 530.

Step 520, determining a risk prediction value of the target merchant for the service type based on the global model.

In some embodiments, the determination module 620 (or risk estimate determination unit 624) may input merchant information related to the target merchant directly to the first model to obtain the risk estimate. The first model is adapted to the business type of the target merchant, namely, merchant information of the industry where the target merchant is located is adopted in the first model training, which shows that the first model can be well adapted to risk estimation and judgment of the industry where the target merchant is located. The determination module 620 (or the risk prediction value determination unit 624) may determine the risk prediction value based directly on the first model.

Step 430, obtaining an adaptation model adapted to the service type based on the first model.

In some embodiments, when the first model is not adapted to the traffic type, the determining module 620 (or risk prediction value determining unit 624) may obtain the adapted model according to the first model based on a transfer learning algorithm. The migration learning algorithm may apply knowledge or patterns learned in a certain domain to a different but related domain. Therefore, in the field of merchant risk control, the transfer learning algorithm may use the first model trained based on the existing business type as a source domain, use the new business type scene as a target domain, and the knowledge transfer process is the process of obtaining the adapted model. In some embodiments, the migration learning algorithm may include a plurality of migration learning models such as feature migration, sample migration, and scene migration, and an optimal migration adaptation scheme may be selected according to different scene conditions, so as to reduce the time cost and computational resource consumption of the migration learning.

Step 440, determining a risk prediction value existing by the target merchant for the service type based on the adaptation model.

In some embodiments, the determination module 620 (or risk estimate determination unit 624) may input merchant information related to the target merchant to the adaptation model to obtain the risk estimate. In some embodiments, the adapted model and the first model may be the same class model. For example, the adapted model may also be a machine learning model, e.g. a machine learning model. Regression models (linear or logistic regression), naive Bayes, decision trees, SVM, KNN, neural networks (e.g., AlexNet, VGGNet, GoogleNet, ResNet, ResNeXt, R-CNN, YOLO, SqueezeNet, SegNet, GAN, etc.), and the like. After obtaining the adaptation model, the determining module 620 (or risk prediction value determining unit 624) may input merchant information related to the target merchant into the adaptation model to determine a risk prediction value existing for the new business type.

It should be noted that the above description related to the flow 500 is only for illustration and description, and does not limit the applicable scope of the present specification. Various modifications and changes to flow 500 may occur to those skilled in the art, given the benefit of this description. However, such modifications and variations are intended to be within the scope of the present description.

Fig. 6 is a block diagram of an exemplary processing device 110 shown in accordance with some embodiments of the present description. Processing device 110 may obtain merchant information related to a target merchant and determine a risk prediction value for the target merchant. As shown in fig. 6, the processing device 110 may include an acquisition module 610, a determination module 620, a policing module 630, an update module 640, and an encryption module 650.

The acquisition module 610 may acquire data.

In some embodiments, the acquisition module 610 may acquire merchant information related to a target merchant. The merchant may be a merchant that is to access and/or has access to a payment platform. The merchant information may include verification information submitted by the target merchant when accessing the payment platform (e.g., attribute data, credit data, business data, etc. of the target merchant), and may also include entity information of other entities that have a connection relationship with the entity corresponding to the target merchant and obtained based on the merchant knowledge graph (e.g., attribute data, credit data, business data, etc. submitted by the entity when accessing the payment platform, business data generated after accessing the payment platform, and a relationship between the entity and the target merchant, etc.).

The determination module 620 may determine one or more results based on the acquired data.

In some embodiments, the determining module 620 may further include a traffic type determining unit 622, and a risk prediction value determining unit 624. The business type determining unit 622 may determine at least a business type related to the target merchant based on the merchant information. The business type associated with the target merchant may be an industry engaged in by the merchant. The service type determining unit 622 may use the second model to fuse at least one modal data included in the merchant information to obtain a service type related to the target merchant. The service type determining unit 622 may further obtain feature data corresponding to the modal data based on the extraction model corresponding to the modal data, and obtain the service type related to the target merchant by fusing the feature data corresponding to the at least one modal data. The service type determining unit 622 may further first determine a representation of each of the at least one modal data, and fuse the at least one representation based on a fusion model to obtain the service type related to the target merchant.

Risk prediction value determination unit 624 may determine a risk prediction value existing for the business type by the target merchant based on at least the first model and the merchant information. The risk pre-estimated value can be used to indicate the risk level that the target merchant may have when developing the business type associated with the target merchant. The risk prediction value can be expressed using a numerical value, with the higher the numerical value, the higher the risk. The risk prediction value may also be represented by a range of values, or a hierarchy. Each level corresponds to a risk size level (e.g., high risk, medium risk, low risk). The risk pre-estimation value determining unit 624 may determine the risk pre-estimation value directly based on the first model, or may first obtain an adaptation model based on the first model, and determine the risk pre-estimation value existing by the target merchant for the service type based on the adaptation model.

The policing module 630 may perform a policing operation.

In some embodiments, the management and control module 630 may perform a preset management and control operation corresponding to the risk pre-estimated value on the target merchant based on the risk pre-estimated value. The governing module 630 may determine whether the predicted risk value satisfies a predetermined condition. The preset condition may be that the risk prediction value is within a preset threshold. The preset threshold range may be a preset parameter of the processing device 110, or may be adjusted according to different situations (e.g., for different target merchants). Which may be a range of values representing an intermediate risk level. When the risk pre-estimated value corresponding to the target merchant is smaller than the minimum endpoint value of the preset threshold range, or the risk pre-estimated value belongs to a low risk level, the management and control module 530 may consider that the target merchant belongs to a trusted merchant, and may allow the target merchant to access the platform. When the risk pre-estimated value corresponding to the target merchant is greater than the maximum endpoint value of the preset threshold range, or the risk pre-estimated value belongs to a high risk level, the management and control module 630 may consider that the target merchant is at a high level. In such a case, the governing module 630 may transfer the target merchant to a manual platform for risk attribution and governing decisions. When the risk estimated value meets the preset condition, that is, when the risk corresponding to the target merchant is considered to be at a medium level, the management and control module 630 may obtain merchant information related to the target merchant again at preset time intervals and update the risk estimated value of the target merchant. When the risk prediction value of the target merchant determined again at a certain time is not within the preset threshold range, the preset control operation may be stopped.

The update module 640 may update the data and/or the model.

In some embodiments, the update module 640 may update the merchant knowledge-graph. For the newly added merchant, the updating module 640 may add an entity in the knowledge graph, determine a relationship between the newly added merchant and other entities based on the information of the newly added merchant, and establish a connection between the newly added merchant and the associated entity. For an existing merchant, the update module 640 may determine, according to the merchant information, a change in the relationship between the existing merchant and other entities, add a newly established relationship, and remove an invalidated relationship.

In some embodiments, the update module 640 may update the first model and/or the adaptation model. After the risk estimated value of the target merchant is determined, the updating module 640 may use the risk estimated value of the target merchant and the merchant information as a new training sample, and continue to train the first model by using the training sample, so that the adaptability of the first model is wider.

The encryption module 650 may encrypt the data and/or the model.

In some embodiments, the encryption module 650 may encrypt data (e.g., merchant information, etc.) and/or models (e.g., first model, adaptation model, second model, extraction model, fusion model, etc.) referred to in this description. Encryption may be using the acquired data and/or model in a trusted execution environment and/or using a model trained using a distributed machine learning algorithm. For example only, the trusted execution environment may be determined based on SGX (software Guard extensions). SGX may protect code or data that is not intended to be disclosed or modified. SGX implements a trusted execution environment by using a bounding box (i.e., a protected execution area in memory). As another example, the model may be trained with a federal learning algorithm. The Federal learning algorithm is a distributed machine learning method, each party participating in the method can build a model together on the premise of not disclosing original data, the fact that the own data of each party cannot be sent out locally is achieved, interactive operation is conducted through an encryption mechanism, and under the condition that data privacy regulations are not violated, the model of each party is optimized by means of the middle results of model training of other parties.

For the specific description of the above modules, reference may be made to the flow chart part in the present specification, which is not described in detail herein.

It should be understood that the system and its modules shown in FIG. 6 may be implemented in a variety of ways. For example, in some embodiments, the system and its modules may be implemented in hardware, software, or a combination of software and hardware. Wherein the hardware portion may be implemented using dedicated logic; the software portions may be stored in a memory for execution by a suitable instruction execution system, such as a microprocessor or specially designed hardware. Those skilled in the art will appreciate that the methods and systems described above may be implemented using computer executable instructions and/or embodied in processor control code, such code being provided, for example, on a carrier medium such as a diskette, CD-or DVD-ROM, a programmable memory such as read-only memory (firmware), or a data carrier such as an optical or electronic signal carrier. The system and its modules in this specification may be implemented not only by hardware circuits such as very large scale integrated circuits or gate arrays, semiconductors such as logic chips, transistors, or programmable hardware devices such as field programmable gate arrays, programmable logic devices, etc., but also by software executed by various types of processors, for example, or by a combination of the above hardware circuits and software (e.g., firmware).

It should be noted that the above description of the processing device 110 and its modules is merely for convenience of description and should not limit the present disclosure to the scope of the illustrated embodiments. It will be appreciated by those skilled in the art that, given the teachings of the present system, any combination of modules or sub-system configurations may be used to connect to other modules without departing from such teachings. For example, in some embodiments, the obtaining module, the determining module, the managing module, the updating module and the encrypting module disclosed in fig. 6 may be different modules in one system, or may be a module that implements the functions of two or more modules described above. For another example, each module in the processing device 110 may share one storage module, and each module may have its own storage module. Such variations are within the scope of the present disclosure.

As shown in fig. 7, in the merchant knowledge-graph, circles may represent entities (also referred to as nodes), and lines between circles may represent relationships (also referred to as edges). In some embodiments, the edges have their corresponding weights, which may reflect the strength of the association between two entities. In some embodiments, the entities in the merchant knowledge graph may include merchant principals (e.g., direct merchants, indirect merchants, applet merchants, etc.), payment instrument accounts (e.g., buyer accounts, payee accounts, etc.), various media (e.g., identification numbers, business license numbers, cell phone numbers, wifi devices, etc.), recommenders, and the like. The relationships in the merchant knowledge graph may include recommendation relationships, consumption relationships, transfer relationships, media usage relationships, and the like.

In some embodiments, the merchant knowledge-graph may be constructed based on the obtained merchant information by techniques including entity identification, entity classification, relationship extraction, entity linking, and the like. In some embodiments, two entities being directly connected may indicate that the two entities have a direct relationship, and two entities being connected by at least two edges may indicate that the two entities have an indirect relationship. For example, entity 1 has a direct relationship with entity 3 and entity 2 has an indirect relationship with entity 8. In some embodiments, each entity may be connected with one or more entities. In the merchant knowledge-graph, each entity is associated through various relationships. Thus, the entity can be expressed in a variety of forms. And, through the merchant knowledge-graph, the relationship between entities can be passed.

The beneficial effects that may be brought by the embodiments of the present description include, but are not limited to: (1) the method and the device realize one-stop intellectualization of the risk management of the commercial tenant, replace manpower, support complex and large-batch calculation on line, and greatly improve the accuracy and the timeliness of the risk management of the commercial tenant. (2) Federal learning is introduced and applied to privacy security calculation of merchant data, and the user information privacy security is improved. It is to be noted that different embodiments may produce different advantages, and in different embodiments, any one or combination of the above advantages may be produced, or any other advantages may be obtained.

Having thus described the basic concept, it will be apparent to those skilled in the art that the foregoing detailed disclosure is to be regarded as illustrative only and not as limiting the present specification. Various modifications, improvements and adaptations to the present description may occur to those skilled in the art, although not explicitly described herein. Such modifications, improvements and adaptations are proposed in the present specification and thus fall within the spirit and scope of the exemplary embodiments of the present specification.

Also, the description uses specific words to describe embodiments of the description. Reference throughout this specification to "one embodiment," "an embodiment," and/or "some embodiments" means that a particular feature, structure, or characteristic described in connection with at least one embodiment of the specification is included. Therefore, it is emphasized and should be appreciated that two or more references to "an embodiment" or "one embodiment" or "an alternative embodiment" in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, some features, structures, or characteristics of one or more embodiments of the specification may be combined as appropriate.

Moreover, those skilled in the art will appreciate that aspects of the present description may be illustrated and described in terms of several patentable species or situations, including any new and useful combination of processes, machines, manufacture, or materials, or any new and useful improvement thereof. Accordingly, aspects of this description may be performed entirely by hardware, entirely by software (including firmware, resident software, micro-code, etc.), or by a combination of hardware and software. The above hardware or software may be referred to as "data block," module, "" engine, "" unit, "" component, "or" system. Furthermore, aspects of the present description may be represented as a computer product, including computer readable program code, embodied in one or more computer readable media.

The computer storage medium may comprise a propagated data signal with the computer program code embodied therewith, for example, on baseband or as part of a carrier wave. The propagated signal may take any of a variety of forms, including electromagnetic, optical, etc., or any suitable combination. A computer storage medium may be any computer-readable medium that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code located on a computer storage medium may be propagated over any suitable medium, including radio, cable, fiber optic cable, RF, or the like, or any combination of the preceding.

Computer program code required for the operation of various portions of this specification may be written in any one or more programming languages, including an object oriented programming language such as Java, Scala, Smalltalk, Eiffel, JADE, Emerald, C + +, C #, VB.NET, Python, and the like, a conventional programming language such as C, VisualBasic, Fortran2003, Perl, COBOL2002, PHP, ABAP, a dynamic programming language such as Python, Ruby, and Groovy, or other programming languages, and the like. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or processing device. In the latter scenario, the remote computer may be connected to the user's computer through any network format, such as a Local Area Network (LAN) or a Wide Area Network (WAN), or the connection may be made to an external computer (for example, through the Internet), or in a cloud computing environment, or as a service, such as a software as a service (SaaS).

Additionally, the order in which the elements and sequences of the process are recited in the specification, the use of alphanumeric characters, or other designations, is not intended to limit the order in which the processes and methods of the specification occur, unless otherwise specified in the claims. While various presently contemplated embodiments of the invention have been discussed in the foregoing disclosure by way of example, it is to be understood that such detail is solely for that purpose and that the appended claims are not limited to the disclosed embodiments, but, on the contrary, are intended to cover all modifications and equivalent arrangements that are within the spirit and scope of the embodiments herein. For example, although the system components described above may be implemented by hardware devices, they may also be implemented by software-only solutions, such as installing the described system on an existing processing device or mobile device.

Similarly, it should be noted that in the preceding description of embodiments of the present specification, various features are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure aiding in the understanding of one or more of the embodiments. This method of disclosure, however, is not intended to imply that more features than are expressly recited in a claim. Indeed, the embodiments may be characterized as having less than all of the features of a single embodiment disclosed above.

Numerals describing the number of components, attributes, etc. are used in some embodiments, it being understood that such numerals used in the description of the embodiments are modified in some instances by the use of the modifier "about", "approximately" or "substantially". Unless otherwise indicated, "about", "approximately" or "substantially" indicates that the number allows a variation of ± 20%. Accordingly, in some embodiments, the numerical parameters used in the specification and claims are approximations that may vary depending upon the desired properties of the individual embodiments. In some embodiments, the numerical parameter should take into account the specified significant digits and employ a general digit preserving approach. Notwithstanding that the numerical ranges and parameters setting forth the broad scope of the range are approximations, in the specific examples, such numerical values are set forth as precisely as possible within the scope of the application.

For each patent, patent application publication, and other material, such as articles, books, specifications, publications, documents, etc., cited in this specification, the entire contents of each are hereby incorporated by reference into this specification. Except where the application history document does not conform to or conflict with the contents of the present specification, it is to be understood that the application history document, as used herein in the present specification or appended claims, is intended to define the broadest scope of the present specification (whether presently or later in the specification) rather than the broadest scope of the present specification. It is to be understood that the descriptions, definitions and/or uses of terms in the accompanying materials of this specification shall control if they are inconsistent or contrary to the descriptions and/or uses of terms in this specification.

Finally, it should be understood that the embodiments described herein are merely illustrative of the principles of the embodiments of the present disclosure. Other variations are also possible within the scope of the present description. Thus, by way of example, and not limitation, alternative configurations of the embodiments of the specification can be considered consistent with the teachings of the specification. Accordingly, the embodiments of the present description are not limited to only those embodiments explicitly described and depicted herein.

Claims

1. A risk management and control method, characterized in that the method comprises:

acquiring merchant information related to a target merchant;

at least determining the business type related to the target merchant based on the merchant information;

determining a risk pre-evaluation value of the target merchant for the business type at least based on a first model and the merchant information; and

and executing preset control operation corresponding to the risk estimated value on the target merchant based on the risk estimated value.

2. The method of claim 1, wherein obtaining merchant information associated with a target merchant comprises:

acquiring initial merchant information related to the target merchant, wherein the initial merchant information at least comprises an identifier, and the identifier is at least used for providing a distinguishing attribute of the target merchant;

determining the target merchant to be an existing merchant or a new merchant based on the identification by using a merchant knowledge map;

if the target merchant is a new merchant, designating the initial merchant information as the merchant information related to the target merchant; and

and if the target merchant is an existing merchant, acquiring entity information related to the target merchant from the merchant knowledge graph based on the identification, and designating the entity information and the initial merchant information as the merchant information related to the target merchant.

3. The method of claim 2, further comprising:

and updating the merchant knowledge map based on the merchant information.

4. The method of claim 1, wherein the merchant information includes at least one modal data of the target merchant; the determining at least the business type related to the target merchant based on the merchant information includes:

and fusing the at least one modal data by using a second model to obtain the service type related to the target merchant.

5. The method of claim 1, wherein the merchant information includes at least one modal data of the target merchant; the determining at least the business type related to the target merchant based on the merchant information includes:

for each of the modal data, the data is,

acquiring feature data corresponding to the modal data based on a corresponding extraction model, wherein the extraction model is a deep learning model; and fusing the characteristic data corresponding to the at least one modal data to obtain the service type related to the target merchant.

6. The method of claim 1, wherein the merchant information includes at least one modal data of the target merchant; the determining at least the business type related to the target merchant based on the merchant information includes:

determining a respective representation of the at least one modality data;

and acquiring the business type related to the target merchant based on the at least one representation of the fusion model, wherein the fusion model comprises a multilayer neural network.

7. The method of claim 1, wherein determining the expected risk value for the business type for the target merchant based on at least the first model and the merchant information comprises:

determining whether the first model is adapted to the traffic type;

and if the first model is adapted to the business type, determining a risk pre-evaluation value of the target merchant for the business type based on the first model and the merchant information.

8. The method of claim 7, further comprising:

and if the first model is not adapted to the service type, acquiring an adaptation model adapted to the service type based on a transfer learning method and the first model, and determining a risk pre-evaluation value of the target merchant for the service type based on the adaptation model and the merchant information.

9. The method of claim 8, further comprising:

updating the first model and/or the adaptation model based on the merchant information related to the target merchant and the risk pre-evaluation value corresponding to the target merchant.

10. The method according to claim 1, wherein the performing, on the basis of the risk pre-evaluation value, a preset management and control operation corresponding to the risk pre-evaluation value on the target merchant includes:

determining whether the risk pre-evaluation value meets a preset condition;

and if the risk estimated value meets the preset condition, acquiring merchant information related to the target merchant again at preset time intervals and updating the risk estimated value of the target merchant.

11. The method of claim 1, further comprising:

the data and/or the model obtained and/or used are encrypted.

12. The method of claim 11, wherein the encrypting comprises:

using the acquired data and/or model in a trusted execution environment; and/or

The machine learning model used is trained using a distributed machine learning algorithm.

13. A risk management and control system is characterized by comprising an acquisition module, a determination module and a management and control module;

the acquisition module is used for acquiring merchant information related to a target merchant;

the determining module is used for at least determining the business type related to the target merchant based on the merchant information; and

the risk pre-evaluation value of the target merchant for the business type is determined at least based on a first model and the merchant information;

and the management and control module is used for executing preset management and control operation corresponding to the risk estimated value on the target merchant based on the risk estimated value.

14. The system of claim 13, wherein to obtain merchant information associated with the target merchant, the obtaining module is configured to:

15. The system of claim 14, further comprising an update module;

the updating module is used for updating the merchant knowledge graph based on the merchant information.

16. The system of claim 13, wherein the merchant information includes at least one modal data for the target merchant; to determine the type of business associated with the target merchant, the determination module is configured to:

17. The system of claim 13, wherein the merchant information includes at least one modal data for the target merchant; to determine the type of business associated with the target merchant, the determination module is configured to:

for each of the modal data, the data is,

18. The system of claim 13, wherein the merchant information includes at least one modal data for the target merchant; to determine the type of business associated with the target merchant, the determination module is configured to:

determining a respective representation of the at least one modality data;

19. The system of claim 13, wherein to determine the expected value of risk for the business type for the target merchant, the determination module is configured to:

determining whether the first model is adapted to the traffic type;

20. The system of claim 19, wherein to determine the expected value of risk for the business type for the target merchant, the determination module is further configured to:

21. The system of claim 20, further comprising an update module;

the updating module is configured to update the first model and/or the adaptation model based on the merchant information related to the target merchant and the risk prediction value corresponding to the target merchant.

22. The system of claim 13, wherein to perform a preset governing operation corresponding to the risk prediction value for the target merchant, the governing module is configured to:

determining whether the risk pre-evaluation value meets a preset condition;

23. The system of claim 13, further comprising an encryption module,

the encryption module is used for encrypting the obtained and/or used data and/or model.

24. The system of claim 23, wherein, for encryption, the encryption module is configured to:

using the acquired data and/or model in a trusted execution environment; and/or

25. A risk management and control apparatus, comprising a processor and a memory; the memory is configured to store instructions that, when executed by the processor, cause the apparatus to implement the method of any of claims 1-12.