Risk control model management method and device, electronic equipment and storage medium

Abstract

The present disclosure provides a risk control model management method and device, electronic equipment and storage medium. The method comprises: receiving a risk control sub-model sent by a terminal device, wherein the risk control sub-model comprises a sub-model identifier; determining a sub-model version number of the risk control sub-model according to the sub-model identifier; and storing the risk control sub-model with the sub-model version number. The method realizes automatic management of the risk control sub-model version and the risk control model version, and facilitates comparison, rollback and tracing between different versions of decision models.

Description

TECHNICAL FIELD

[0001] Embodiments of the present disclosure relate to the technical field of data processing, and in particular, to a risk control model management method and device, electronic equipment and storage medium. BACKGROUND

[0002] In recent years, with the popularization and application of the Internet, the channels and events of financial fraud have increased dramatically. In order to avoid the economic losses and adverse social impacts of the gray and black industries such as fraud on credit business, risk prevention and control (hereinafter referred to as: risk control) has become an indispensable important part of credit business. With the increase of cooperation channels and application scenarios, the business volume is growing, and the risk control mode is gradually changing from manual approval to automatic approval. In the early stage, the automatic risk control approval is realized by hard coding. Each time the decision strategy logic is iterated, the system developer needs to modify the code logic and execute a lengthy application release process. In order to adapt to the needs of flexible changes in decision strategy logic, a visual decision model management system relying on strategy flow is born with the purpose of low code. Business personnel can configure, package and release decision rules through an interface-based strategy editor, and simple deployment operations greatly improve the iteration efficiency of decision models.

[0003] The current popular visual decision model management systems mainly include Blaze Advisor released by FICO, a credit giant in the United States, Drools maintained by the Red Hat core team, SMARTS released by Sparking Logic, the open source project Urule and Radar released by the Apache community, etc. Most of the above systems manage decision models in the form of strategy packages. Although they effectively alleviate the problem of strong coupling between system development hard coding and decision model release, there are still defects in decision model management, such as the confusion of unpublished strategy packages and sub-models, the difficulty of modifying packaged strategy packages, and the consumption of manpower in the strategy design, approval and deployment links.

[0004] Therefore, it is necessary to propose a new risk control model management scheme to solve at least one of the above technical problems. SUMMARY

[0005] Embodiments of the present disclosure propose a risk control model management method, device, electronic equipment and storage medium.

[0006] In a first aspect, the present disclosure provides a risk control model management method, comprising:

[0007] receiving a risk control sub-model sent by a terminal device, wherein the risk control sub-model comprises a sub-model identifier;

[0008] determining a sub-model version number of the risk control sub-model according to the sub-model identifier;

[0009] store the anti-fraud sub-model with the sub-model version number.

[0010] In some optional embodiments, the determining of the sub-model version number of the anti-fraud sub-model according to the sub-model identifier comprises:

[0011] determining whether there is an existing anti-fraud sub-model with the same name according to the sub-model identifier;

[0012] in response to determining no, determining that the sub-model version number of the anti-fraud sub-model is an initial sub-model version number;

[0013] in response to determining yes, determining the sub-model version number of the anti-fraud sub-model according to the maximum sub-model version number of the existing anti-fraud sub-model with the same name.

[0014] In some optional embodiments, after the storing of the anti-fraud sub-model with the sub-model version number, the method further comprises:

[0015] receiving model assembly information sent by a terminal device, wherein the model assembly information comprises sub-model identifiers and sub-model version numbers of at least two anti-fraud sub-models, and a connection manner between the at least two anti-fraud sub-models;

[0016] assembling the at least two anti-fraud sub-models into an anti-fraud model according to the model assembly information, wherein the anti-fraud model comprises a model identifier and a model version number.

[0017] In some optional embodiments, after the assembling of the at least two anti-fraud sub-models into an anti-fraud model, the method further comprises:

[0018] sending the anti-fraud model to a target device for approval;

[0019] receiving an approval result sent by the target device;

[0020] in a case where the approval result is pass, determining a current state of the anti-fraud model as an active state, wherein the active state indicates that the anti-fraud model can be invoked.

[0021] In some optional embodiments, after the determining of the current state of the anti-fraud model as the active state, the method further comprises:

[0022] obtaining a newly added anti-fraud model;

[0023] in a case where the model identifier of the newly added anti-fraud model is the same as that of an existing anti-fraud model, the model version is different, and the newly added anti-fraud model is in the active state, changing a current state of the existing anti-fraud model from the active state to an offline state, wherein the offline state indicates that the anti-fraud model cannot be invoked.

[0024] In some optional embodiments, before determining the current state of the risk control model as the active state, the method further comprises:

[0025] receiving updated model assembly information sent by the terminal device;

[0026] generating an updated risk control model according to the updated model assembly information and replacing the existing risk control model.

[0027] In some optional embodiments, after changing the current state of the existing risk control model from the active state to the offline state, the method further comprises:

[0028] storing the risk control model in the offline state;

[0029] changing the current state of the target risk control model from the offline state to a rollback success state in response to a rollback instruction sent by the terminal device, wherein the rollback success state indicates that the target risk control model can enter the approval process.

[0030] In a second aspect, the disclosure provides a risk control model management device, comprising:

[0031] a sub-model receiving unit configured to receive a risk control sub-model sent by a terminal device, wherein the risk control sub-model comprises a sub-model identifier;

[0032] a version number determining unit configured to determine a sub-model version number of the risk control sub-model according to the sub-model identifier;

[0033] a storage unit configured to store the risk control sub-model with the sub-model version number.

[0034] In some optional embodiments, the version number determining unit is further configured to:

[0035] determine whether there is an existing risk control sub-model with the same name according to the sub-model identifier;

[0036] in response to a determination of no, determine that the sub-model version number of the risk control sub-model is an initial sub-model version number;

[0037] in response to a determination of yes, determine the sub-model version number of the risk control sub-model according to the maximum sub-model version number of the existing risk control sub-model with the same name.

[0038] In some optional embodiments, the device further comprises a model assembly unit configured to:

[0039] receive model assembly information sent by a terminal device, wherein the model assembly information comprises sub-model identifiers and sub-model version numbers of at least two risk control sub-models, and a connection mode between the at least two risk control sub-models;

[0040] assemble the at least two risk control sub-models into a risk control model according to the model assembly information, wherein the risk control model comprises a model identifier and a model version number.

[0041] In some optional embodiments, the apparatus further comprises an approval unit configured to:

[0042] send the risk control model to a target device for approval;

[0043] receive an approval result sent by the target device;

[0044] in a case where the approval result is passed, determine a current state of the risk control model as an active state, wherein the active state indicates that the risk control model can be invoked.

[0045] In some optional embodiments, the apparatus further comprises a model offline unit configured to:

[0046] obtain a newly added risk control model;

[0047] in a case where the model identifier of the newly added risk control model is the same as that of an existing risk control model, the model version is different, and the newly added risk control model is in the active state, change a current state of the existing risk control model from the active state to an offline state, wherein the offline state indicates that the risk control model cannot be invoked.

[0048] In some optional embodiments, the apparatus further comprises a model modification unit configured to:

[0049] receive updated model assembly information sent by a terminal device;

[0050] generate an updated risk control model according to the updated model assembly information and replace an existing risk control model.

[0051] In some optional embodiments, the apparatus further comprises a model rollback unit configured to:

[0052] store a risk control model in an offline state;

[0053] in response to a rollback instruction sent by a terminal device, change a current state of a target risk control model from the offline state to a rollback success state, wherein the rollback success state indicates that the target risk control model can enter an approval process.

[0054] In a third aspect, the present disclosure provides an electronic device, comprising:

[0055] one or more processors;

[0056] a storage device having stored thereon one or more programs,

[0057] the one or more programs, when executed by the one or more processors, cause the one or more processors to perform the method according to any one of the embodiments of the first aspect of the present disclosure.

[0058] In a fourth aspect, the present disclosure provides a computer-readable storage medium having stored thereon a computer program, wherein the computer program, when executed by one or more processors, performs the method according to any one of the embodiments of the first aspect of the present disclosure.

[0059] The management method, device, electronic device and storage medium of the risk control model provided by the present disclosure realize automatic management of the risk control sub-model version and the risk control model version, and facilitate comparison, rollback and tracing between different versions of decision-making models.

[0060] In some embodiments, the version of the risk control sub-model for assembly can be freely assembled, improving the flexibility of the risk control model design.

[0061] In some embodiments, the unactivated risk control model can be modified, facilitating the design modification of the risk control model.

[0062] In some embodiments, the design, deployment and approval of the risk control model realize full online operation, effectively shortening the offline circulation process, reducing the maintenance complexity of the risk control model, and greatly saving the labor cost. BRIEF DESCRIPTION OF DRAWINGS

[0063] Other features, objects and advantages of the present disclosure will become more apparent from the following detailed description of non-limiting embodiments made with reference to the attached drawings. The drawings are for the purpose of illustrating specific embodiments and are not to be construed as limiting the application. In the drawings:

[0064] Figure 1 is a system architecture diagram of one embodiment of a risk control model management system according to the present disclosure;

[0065] Figure 2 is a flowchart of one embodiment of a risk control model management method according to the present disclosure;

[0066] Figure 3A is a first schematic diagram of a sub-model upload interface of a risk control model management method according to the present disclosure;

[0067] Figure 3B is a second schematic diagram of a sub-model upload interface of a risk control model management method according to the present disclosure;

[0068] Figure 3C is a schematic diagram of a model assembly interface of a management method of a risk control model according to the present disclosure;

[0069] Figure 3D is a schematic diagram of a sub-model connection structure of a management method of a risk control model according to the present disclosure;

[0070] Figure 3E is a schematic diagram of a model upload interface of a management method of a risk control model according to the present disclosure;

[0071] Figure 3F is a schematic diagram of a state machine of a management method of a risk control model according to the present disclosure;

[0072] Figure 4 is a structural schematic diagram of one embodiment of a management device of a risk control model according to the present disclosure;

[0073] Figure 5 is a structural schematic diagram of a computer system of an electronic device suitable for implementing embodiments of the present disclosure. DETAILED DESCRIPTION

[0074] The present disclosure will be further described below in conjunction with the drawings and embodiments. It can be understood that the specific embodiments described herein are only used to explain the related application, and not to limit the application. In addition, it should be noted that only parts related to the application are shown in the drawings for ease of description.

[0075] It should be noted that the embodiments in the present disclosure and the features in the embodiments can be combined with each other without conflict. The present disclosure will be described in detail below with reference to the drawings and in conjunction with the embodiments.

[0076] Figure 1 An exemplary system architecture 100 of embodiments of the management method, device, terminal equipment and storage medium of the risk control model of the present disclosure is shown.

[0077] As shown in Figure 1 , the system architecture 100 can include terminal equipment 101, 102, 103, a network 104 and a server 105. The network 104 is used as a medium to provide a communication link between the terminal equipment 101, 102, 103, the server 105. The network 104 can include various connection types, such as wired, wireless communication links or optical fiber cables, etc.

[0078] The user can use the terminal device 101, 102, 103 to interact with the server 105 through the network 104 to receive or send messages, etc. Various communication client applications can be installed on the terminal device 101, 102, 103, such as voice interaction applications, video conference applications, short video social applications, web browser applications, shopping applications, search applications, instant messaging tools, email clients, social platform software, transaction processing applications, etc.

[0079] The terminal device 101, 102, 103 can be hardware or software. When the terminal device 101, 102, 103 is hardware, it can be various electronic devices with microphones and speakers, including but not limited to smartphones, tablet computers, e-book readers, MP3 players (Moving Picture Experts Group Audio Layer III), MP4 (Moving Picture Experts Group Audio Layer IV) players, portable computers, desktop computers, etc. When the terminal device 101, 102, 103 is software, it can be installed in the above-mentioned electronic devices. It can be implemented as multiple software or software modules, or as a single software or software module. No specific limitation is made here.

[0080] The server 105 can establish a connection with the terminal device 101, 102, 103 and process data (such as risk control sub-model data) sent by the terminal device 101, 102, 103.

[0081] In some cases, the management method of the risk control model provided by the present disclosure can be jointly executed by the terminal device 101, 102, 103 and the server 105, and accordingly, the management device of the risk control model can be respectively arranged in the terminal device 101, 102, 103 and the server 105.

[0082] In some cases, the management method of the risk control model provided by the present disclosure can be executed by the server 105, and accordingly, the management device of the risk control model can be arranged in the server 105.

[0083] It should be noted that the server 105 can be hardware or software. When the server 105 is hardware, it can be implemented as a distributed server cluster composed of multiple servers, or as a single server. When the server 105 is software, it can be implemented as multiple software or software modules (such as for providing distributed services), or as a single software or software module. No specific limitation is made here.

[0084] It should be understood that,Figure 1 The number of terminal devices, networks and servers in

[0085] With reference to Figure 2 , one embodiment of a method for managing a risk control model according to the present disclosure is shown as flow 210, which can be applied to Figure 1 the server 105 in

[0086] As shown in Figure 2 , the flow 210 includes the following steps:

[0087] Step 211, receiving a risk control sub-model sent by a terminal device, wherein the risk control sub-model includes a sub-model identifier.

[0088] The risk control policy designer can decompose the risk control model into several basic units from top to bottom, and each basic unit is a risk control sub-model. The type of risk control sub-model can be a rule set, a function, a single-axis table, a double-axis table, a scorecard, and a decision tree, etc.

[0089] The terminal device can provide an input interface of the risk control sub-model to the user (i.e. the risk control policy designer). The user can input the parameter information of the risk control sub-model in the input interface to complete the definition of the risk control sub-model. Then, the terminal device can send the risk control sub-model defined by the user to the execution subject of the method in the embodiment, i.e. the server.

[0090] The risk control sub-model includes a sub-model identifier. The sub-model identifier is the unique identifier of the risk control sub-model, which can be a sub-model code or a sub-model name, etc. The sub-model code is a series of characters, and the sub-model name is a series of texts.

[0091] Step 212, determining a sub-model version number of the risk control sub-model according to the sub-model identifier.

[0092] In the embodiment, the risk control sub-model has a sub-model identifier and a sub-model version number. In the design process of the risk control model, the risk control sub-model with a specific model identifier can be updated by the risk control policy designer, thereby forming two or more versions. The sub-model version number can be used to distinguish different versions of the risk control sub-model.

[0093] In some embodiments, the sub-model version number can be determined in the following way:

[0094] First, according to the sub-model identifier, it is determined whether there is an existing risk control sub-model with the same name. Here, the existing risk control sub-model with the same name refers to the risk control sub-model that has been stored in the server and has the same sub-model identifier as the newly added risk control sub-model.

[0095] If no existing risk control sub-model with the same name exists, the sub-model version number of the risk control sub-model can be the same as the initial sub-model version number. The initial sub-model version number can be, for example, 0 or 1, and can be determined according to actual needs.

[0096] If an existing risk control sub-model with the same name exists, the sub-model version number of the new risk control sub-model can be determined based on the version number of the largest sub-model of the existing sub-model with the same name. For example, the version number of the new risk control sub-model can be obtained by adding one to the version number of the largest sub-model of the existing sub-model with the same name.

[0097] In one example, the existing risk control sub-models include a first sub-model with sub-model identifier "AAA" and sub-model version number "1", and a second sub-model with sub-model identifier "AAA" and sub-model version number "2". If a new risk control sub-model with sub-model identifier "AAA" is added, the server will automatically add "1" to the maximum sub-model version number "2" of the existing risk control sub-model with the same name, resulting in the version number "3" of the new risk control sub-model.

[0098] Step 213: Store the risk control sub-model with the sub-model version number.

[0099] In this embodiment, storing the risk control sub-model with the sub-model version number on the server can better manage the versions of the risk control sub-model, prevent errors, and improve the convenience of calling the risk control sub-model.

[0100] Figure 3A This is a first schematic diagram of a sub-model upload interface according to the risk control model management method disclosed herein. This interface can be provided to the user by a terminal device to display the upload information of the risk control sub-model.

[0101] like Figure 3A As shown, the sub-model upload interface includes the (upload task) sequence number, sub-model code, sub-model name, check-in status, operator, and version number. The sub-model code for this risk control sub-model is "demoRule01," and the sub-model name is "Example Rules Set." In this example, a unique sub-model code can be generated for each risk control sub-model according to preset rules, thus serving as the sub-model identifier. The version number of this risk control sub-model is "1," corresponding to the initial version number, indicating that this is the first risk control sub-model under this identifier. The version number of the risk control sub-model is generated by the server and then fed back to the terminal device. The check-in status of this risk control sub-model is "Check-in Successful," indicating that the risk control sub-model has been successfully uploaded to the server.

[0102] Figure 3B This is a second schematic diagram of the sub-model upload interface for the risk control model management method disclosed herein.

[0103] As shown in Figure 3B , the two risk control sub-models corresponding to serial numbers "1" and "2" have the same sub-model code and sub-model name, and the difference lies in that the version numbers of the two are different, which are "1" and "2" respectively. Figure 3B The two risk control sub-models are actually different versions of the same risk control sub-model, and the risk control sub-model with the version number "2" is uploaded after the risk control sub-model with the version number "1". The check-in state of the risk control sub-model corresponding to the serial number "1" is "activated", indicating that the risk control sub-model can be called by a specific electronic device or application program, etc. The state management scheme of the risk control sub-model will be further described below.

[0104] In some embodiments, the server-stored risk control sub-models can be assembled into a risk control model, which can specifically include the following steps:

[0105] Firstly, receiving the model assembly information sent by the terminal device, wherein the model assembly information includes the sub-model identifiers and sub-model version numbers of at least two risk control sub-models, and the connection mode between the at least two risk control sub-models.

[0106] Figure 3C is a schematic diagram of a model assembly interface of the management method of the risk control model according to the present disclosure. The interface can be provided by the terminal device to the user for inputting the model assembly information.

[0107] As shown in Figure 3C , the basic information part of the new model includes the model code and the model name, which can be input by the user or generated by the system. The unique model code can be generated for each risk control model according to the preset rules, so that the model code can be used as the model identifier. The sub-model list part shows the types, codes, names and version numbers of each sub-model. The user can select the risk control sub-models used to generate the risk control model, and specify the version numbers of the risk control sub-models through the drop-down menu.

[0108] Figure 3D is a schematic diagram of a sub-model connection structure of the management method of the risk control model according to the present disclosure. As shown in Figure 3D , each risk control sub-model is connected in a serial manner. In addition, each sub-model can also exist in a parallel connection mode. The user can edit the connection order and connection relationship between each risk control sub-model in a graphical form to complete the setting of the connection mode of the sub-models.

[0109] After the user sets the model assembly information, the terminal device sends the model assembly information to the server.

[0110] Secondly, at least two risk control sub-models are assembled into a risk control model according to the model assembly information, wherein the risk control model comprises a model identifier and a model version number.

[0111] The server can assemble the specified at least two risk control sub-models into a risk control model according to the specified connection mode.

[0112] After the risk control model is assembled, the server can generate a model version number of the risk control model. The determination of the model version number can be similar to the determination of the sub-model version number. In the absence of an existing risk control model with the same name, the version number of the risk control model can be determined as an initial version number. In the presence of an existing risk control model with the same name, the maximum version number of the existing risk control model with the same name can be incremented by one to serve as the version number of the risk control model.

[0113] After the model version number of the risk control model is generated, the risk control sub-models with the model version number can be stored in the server to better manage the versions of the risk control model.

[0114] Figure 3E is a schematic diagram of a model upload interface according to the management method of the risk control model of the present disclosure.

[0115] As shown in Figure 3E , the model upload interface comprises a serial number (of the upload task), a model code, a model name, a check-in state, an operator, and a version number, etc. The model code of the risk control model is “demoStrategy”, and the model name is “example strategy package”. In this example, the model code can serve as the model identifier. The version number of the risk control model is “1”, which corresponds to the initial version number, indicating that the risk control model is the first risk control model under the model identifier. The version number of the risk control model is generated by the server and fed back to the terminal device. The check-in state of the risk control model is “check-in success”, indicating that the risk control model has been successfully uploaded to the server.

[0116] In some embodiments, the assembled risk control model can be subject to online approval, which can specifically comprise:

[0117] Firstly, the risk control model is sent to a target device for approval.

[0118] Approval refers to the review and approval of the risk control model by personnel with approval authority, so as to control the quality of the risk control model. The approval personnel can operate on the target device to review the risk control model and input the approval result.

[0119] In some embodiments, the approval process can further comprise two links of peer review and superior review, and accordingly, the server can send the risk control model to a first target device for peer review and a second target device for superior review.

[0120] The second step is to receive the approval result sent by the target device.

[0121] The approval result can be pass or fail. In the case that the approval process includes two steps of peer review and superior review, if the approval results of the peer review and the superior review are both pass, the final approval result is pass. If at least one of the approval results of the peer review and the superior review is fail, the final approval result is fail.

[0122] The third step is to determine the current state of the risk control model as an active state in the case that the approval result is pass, wherein the active state means that the risk control model can be called.

[0123] In the embodiment, the risk control model in the active state can be called by a specific electronic device or application program, so as to input the original data into the risk control model and obtain the risk detection result. The risk detection result can be that there is a risk or there is no risk.

[0124] In the approval process of the risk control model, the risk control sub-models included therein are also approved. In the case that the approval result of the risk control sub-model is pass, the current state of the risk control sub-model will also change to the active state, which can be referred to as the check-in state of the risk control sub-model corresponding to the serial number "1" in Figure 3B

[0125] In some embodiments, the state of the risk control model can be managed to ensure that only one version of the risk control model with the same name is in the active state, so as to avoid confusion when the model is called. A specific implementation is, for example, to obtain a newly added risk control model; in the case that the model identifier of the newly added risk control model and the existing risk control model is the same, the model version is different, and the newly added risk control model is in the active state, change the current state of the existing risk control model from the active state to the offline state, wherein the offline state means that the risk control model cannot be called.

[0126] In other words, after the new version of the risk control model becomes the active state, the previous version of the risk control model with the same name will be offline.

[0127] In some embodiments, the risk control model can be modified before it becomes the active state. A specific implementation is, for example, to receive updated model assembly information sent by a terminal device; generate an updated risk control model according to the updated model assembly information and replace the existing risk control model.

[0128] Further, for the risk control model that has not entered the approval process, it can be directly modified. For the risk control model that has entered the approval process and is not in the active state, it can be withdrawn from the approval node first and then modified.

[0129] ​In the embodiment, the unactivated risk control model can be modified at any time, which is conducive to the modification of the risk control model. The activated risk control model cannot be modified at any time, which is conducive to ensuring the stability of the risk control model.

[0130] In some embodiments, for the offline risk control model, it is still stored in the server and can re-enter the approval process when needed. The specific implementation is, for example, storing the offline risk control model; in response to the rollback instruction sent by the terminal device, changing the current state of the target risk control model from the offline state to the rollback success state, wherein the rollback success state indicates that the target risk control model can enter the approval process.

[0131] In some cases, the use effect of the latest version of the risk control model may not be as good as that of the previous version of the risk control model. At this time, the previous version of the risk control model can be rolled back to re-enter the approval process, and finally be reactivated to realize the switching of the model version and achieve the best effect.

[0132] The above state management of the risk control model, such as offline, modification and rollback, can also be applied to the risk control sub-model, and the specific details are not described again.

[0133] Figure 3F is a schematic diagram of a state machine of a management method of a risk control model according to the present disclosure, which can be applied to the state management of the risk control model and the risk control sub-model.

[0134] As shown in Figure 3F , first, the user can edit the risk control sub-model in the terminal device, and the edited risk control sub-model is in the "uncheck-in" state. The "uncheck-in" state is the initial state unique to the risk control sub-model.

[0135] Secondly, the user can upload the related information of the risk control model or the risk control sub-model to the server, at which time the state of the risk control model or the risk control sub-model becomes the "check-in success" state, and the version number automatically generated by the server is obtained.

[0136] After that, the user can initiate the approval process of the risk control model or the risk control sub-model, and the state of the risk control model or the risk control sub-model becomes the "to be reviewed" state, and then becomes the "to be audited" state after the review is passed, and finally becomes the "audit passed" state after the audit is passed. For the risk control model or the risk control sub-model that passes the audit, the server automatically changes it to the "activated" state, so that the risk control model or the risk control sub-model can be called.

[0137] During the approval process, the user can voluntarily withdraw the approval, or the approver can refuse the approval, so that the state of the risk control model or the risk control sub-model reverts to the "check-in success" state, so as to re-edit or re-approve the risk control model or the risk control sub-model.

[0138] If other versions of the risk control model or the risk control sub-model are activated, the currently activated version of the risk control model or the risk control sub-model will become "offline". The user can make the offline risk control model or the risk control sub-model become "rollback success" through rollback operation, and then make it re-enter the approval process through initiation of approval.

[0139] The management method of the risk control model provided by the present disclosure realizes that both the risk control model and the risk control sub-model have version identifiers, which facilitates the differentiation of each strategy iteration, comparison, rollback and traceability between different versions of the decision model, and does not occupy local storage resources.

[0140] In some embodiments, the version of the risk control sub-model for assembly can be freely assembled, improving the flexibility of the risk control model design.

[0141] In some embodiments, the unactivated risk control model can be modified, facilitating the design correction of the risk control model.

[0142] In some embodiments, the design, deployment and approval of the risk control model realize full online operation, effectively shortening the offline circulation process, reducing the maintenance complexity of the risk control model, and greatly saving the labor cost.

[0143] Further reference Figure 4 , as an implementation of the method shown in Figure 2 , the present disclosure provides an embodiment of a risk control model management device, which corresponds to the method embodiment shown in Figure 2 , and the device can be applied in various terminal devices.

[0144] As shown in Figure 4 , the risk control model management device 410 of the present embodiment includes a sub-model receiving unit 411, a version number determining unit 412 and a storage unit 413. The sub-model receiving unit 411 is configured to receive a risk control sub-model sent by a terminal device, wherein the risk control sub-model includes a sub-model identifier; the version number determining unit 412 is configured to determine a sub-model version number of the risk control sub-model according to the sub-model identifier; and the storage unit 413 is configured to store the risk control sub-model with the sub-model version number.

[0145] In the present embodiment, the specific processing of the sub-model receiving unit 411, the version number determining unit 412 and the storage unit 413 and the technical effects brought by them can be respectively referred to the related descriptions of step 211, step 212 and step 213 in the corresponding embodiment, which will not be repeated here. Figure 2 The corresponding embodiment of step 211, step 212 and step 213, which will not be repeated here.

[0146] In some optional implementations, the version number determination unit 412 is further configured to: determine whether there is an existing risk control sub-model with the same name based on the sub-model identifier; in response to determining no, determine the sub-model version number of the risk control sub-model as the initial sub-model version number; in response to determining yes, determine the sub-model version number of the risk control sub-model based on the largest sub-model version number of the existing risk control sub-model with the same name.

[0147] In some alternative embodiments, the above-described apparatus further includes a model assembly unit ( Figure 4 (Not shown), used for: receiving model assembly information sent by a terminal device, wherein the model assembly information includes sub-model identifiers and sub-model version numbers of at least two risk control sub-models, and the connection method between the at least two risk control sub-models; assembling the at least two risk control sub-models into a risk control model according to the model assembly information, wherein the risk control model includes a model identifier and a model version number.

[0148] In some alternative embodiments, the above-mentioned apparatus further includes an approval unit ( Figure 4 (Not shown), used for: sending the above risk control model to the target device for approval; receiving the approval result sent by the target device; and, if the approval result is approved, determining the current state of the above risk control model as an active state, wherein the active state indicates that the above risk control model can be invoked.

[0149] In some alternative embodiments, the above-mentioned apparatus further includes a model unloading unit ( Figure 4 (Not shown), used for: obtaining newly added risk control models; when the newly added risk control model and the existing risk control model have the same model identifier but different model versions, and the newly added risk control model is in an active state, changing the current state of the existing risk control model from active to offline, wherein the offline state indicates that the above risk control model cannot be called.

[0150] In some alternative embodiments, the above-described apparatus further includes a model modification unit ( Figure 4 (Not shown), used for: receiving updated model assembly information sent by the terminal device; generating an updated risk control model based on the updated model assembly information and replacing the existing risk control model.

[0151] In some alternative implementations, the above apparatus further includes a model rollback unit ( Figure 4 (Not shown), used for: storing the offline risk control model; in response to a rollback command sent by the terminal device, changing the current state of the target risk control model from offline to rollback successful, wherein the rollback successful state indicates that the target risk control model can enter the approval process.

[0152] It should be noted that the implementation details and technical effects of the units in the risk control model management apparatus provided by the embodiments of the present disclosure can refer to the descriptions of other embodiments of the present disclosure, and will not be described here.

[0153] Reference is made below Figure 5 which shows a structural schematic diagram of a computer system 500 suitable for implementing a terminal device or a server of the present disclosure. Figure 5 The computer system 500 shown is merely an example and should not impose any limitation on the functions and use ranges of the embodiments of the present disclosure.

[0154] As Figure 5 shown, the computer system 500 can include a processing device (such as a central processor, a graphics processor, etc.) 501, which can perform various appropriate actions and processes according to programs stored in a read-only memory (ROM) 502 or programs loaded from a storage device 508 into a random access memory (RAM) 503. In the RAM 503, various programs and data required for the operation of the computer system 500 are also stored. The processing device 501, the ROM 502, and the RAM 503 are connected to each other through a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0155] Generally, the following devices can be connected to the I / O interface 505: input devices 506 including, for example, a touch screen, a touchpad, a keyboard, a mouse, a camera, a microphone, etc.; output devices 507 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; storage devices 508 including, for example, a magnetic tape, a hard disk, etc.; and communication devices 509. The communication devices 509 can allow the computer system 500 to communicate with other devices wirelessly or by wire to exchange data. Although Figure 5 The computer system 500 shown with various devices, it should be understood that it is not required to implement or have all the shown devices. More or less devices can alternatively be implemented or included.

[0156] In particular, according to the embodiments of the present disclosure, the processes described above with reference to the flowcharts can be implemented as a computer software program. For example, the embodiments of the present disclosure include a computer program product comprising a computer program carried on a computer readable medium, the computer program containing program codes for executing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network through the communication devices 509, or installed from the storage devices 508, or installed from the ROM 502. When the computer program is executed by the processing device 501, the above-mentioned functions defined in the methods of the embodiments of the present disclosure are performed.

[0157] It should be noted that the computer readable medium in the above disclosure can be a computer readable signal medium or a computer readable storage medium or any combination of the two. The computer readable storage medium may, for example, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or apparatus, or any combination of the above. More specific examples of the computer readable storage medium can include, but are not limited to, an electrical connection having one or more wires, a portable computer diskette, 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 above. In the present disclosure, the computer readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, device or apparatus. In the present disclosure, the computer readable signal medium can include a data signal carried in a baseband or as a part of a carrier wave, which carries computer readable program code. Such a propagated data signal can take many forms, including but not limited to an electromagnetic signal, an optical signal or any suitable combination of the above. The computer readable signal medium can also be any computer readable medium other than the computer readable storage medium, which can send, propagate or transmit a program for use by or in conjunction with an instruction execution system, device or apparatus. The program code contained in the computer readable medium can be transmitted by any suitable medium, including but not limited to a wire, a cable, an RF (radio frequency) or the like, or any suitable combination of the above.

[0158] The computer readable medium described above can be contained in the electronic device described above; or can exist separately and not be assembled into the electronic device.

[0159] The computer readable medium described above carries one or more programs, which, when executed by the electronic device, cause the electronic device to implement the method for managing the risk control model as shown in the embodiments and optional implementation modes thereof. Figure 2 The management method of the risk control model shown in the embodiments and optional implementation modes thereof.

[0160] Computer program code for carrying out operations of the present disclosure can be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like, and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code can 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 server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (for example, through the Internet using an Internet Service Provider).

[0161] The flow diagrams and the block diagrams in the drawings are illustrations of architectures, functionalities, and operations of possible implementations of systems, methods, and computer program products according to various embodiments of present disclosure. In this regard, each block in the flow diagrams or block diagrams can represent a module, a procedure, or a portion of code, which comprises one or more executable instructions for implementing the specific logical functions specified for the block. It should also be noted that in some alternative implementations, the functions noted in the blocks can occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently or in the reverse order, depending on the functionality involved. It is also noted that each block of the block diagrams and / or flow diagrams and combinations of blocks in the block diagrams and / or flow diagrams can be implemented by special purpose hardware-based systems which perform the specified functions or operations, or combinations of special purpose hardware and

[0162] The units described in the embodiments of the present disclosure can be implemented by software, or by hardware. In some cases, the name of the unit does not constitute a limitation on the unit itself. For example, the sub-model receiving unit can also be described as a unit for receiving a risk control sub-model sent by a terminal device.

[0163] The above description is merely that of preferred embodiments of the present disclosure and of the principles thereof. Those skilled in the art should understand that the disclosure scope of the present disclosure is not limited to the technical solutions formed by the specific combinations of the above technical features, and also includes other technical solutions formed by the combinations of the above technical features or equivalent features thereof without departing from the above disclosure concept. For example, the above technical features can be replaced with the technical features disclosed in the present disclosure (but not limited to) having similar functions to form a technical solution.

Claims

1. A method for managing a risk control model, comprising: receiving a risk control sub-model sent by a terminal device, wherein the risk control sub-model comprises a sub-model identifier; determining a sub-model version number of the risk control sub-model according to the sub-model identifier; storing the risk control sub-model with the sub-model version number; after storing the risk control sub-model with the sub-model version number, the method further comprises: receiving model assembly information sent by a terminal device, wherein the model assembly information comprises sub-model identifiers and sub-model version numbers of at least two risk control sub-models, and a connection manner between the at least two risk control sub-models; assembling the at least two risk control sub-models into a risk control model according to the model assembly information, wherein the risk control model comprises a model identifier and a model version number; after assembling the at least two risk control sub-models into the risk control model, the method further comprises: sending the risk control model to a target device for approval; receiving an approval result sent by the target device; in a case where the approval result is passed, determining a current state of the risk control model as an active state, wherein the active state indicates that the risk control model can be invoked; after determining the current state of the risk control model as the active state, the method further comprises: obtaining a newly added risk control model; in a case where the model identifier of the newly added risk control model is the same as that of an existing risk control model, the model version is different, and the newly added risk control model is in the active state, changing the current state of the existing risk control model from the active state to an offline state, wherein the offline state indicates that the risk control model cannot be invoked.

2. The method of claim 1, wherein, The determining of the sub-model version number of the risk control sub-model according to the sub-model identifier comprises: determining whether there is an existing risk control sub-model with the same name according to the sub-model identifier; in response to determining no, determining the sub-model version number of the risk control sub-model as an initial sub-model version number; in response to determining yes, determining the sub-model version number of the risk control sub-model according to a maximum sub-model version number of the existing risk control sub-model with the same name.

3. The method of claim 1, wherein, Before determining the current state of the risk control model as the active state, the method further comprises: receiving updated model assembly information sent by a terminal device; generating an updated risk control model according to the updated model assembly information and replacing an existing risk control model.

4. The method of claim 1, wherein, After changing the current state of the existing risk control model from the active state to the offline state, the method further comprises: storing the risk control model in the offline state; in response to a rollback instruction sent by a terminal device, changing the current state of a target risk control model from the offline state to a rollback success state, wherein the rollback success state indicates that the target risk control model can enter an approval process. 5.A device for managing a risk control model, comprising: a sub-model receiving unit configured to receive a risk control sub-model sent by a terminal device, wherein the risk control sub-model comprises a sub-model identifier; a version number determining unit configured to determine a sub-model version number of the risk control sub-model according to the sub-model identifier; a storage unit configured to store the risk control sub-model with the sub-model version number. A model assembly unit is configured to receive model assembly information sent by a terminal device, wherein the model assembly information comprises sub-model identifiers and sub-model version numbers of at least two risk control sub-models and a connection manner between the at least two risk control sub-models; and the at least two risk control sub-models are assembled into a risk control model according to the model assembly information, wherein the risk control model comprises a model identifier and a model version number; An approval unit is configured to send the risk control model to a target device for approval, receive an approval result sent by the target device, and determine a current state of the risk control model as an active state when the approval result is passed, wherein the active state indicates that the risk control model can be invoked. A model offline unit is configured to obtain a newly added risk control model, and change a current state of an existing risk control model from the active state to an offline state when the model identifier of the newly added risk control model and the existing risk control model is the same, the model version is different, and the newly added risk control model is in the active state, wherein the offline state indicates that the risk control model cannot be invoked. 6.An electronic device, comprising: one or more processors; storage having stored thereon one or more programs, the one or more programs, when executed by the one or more processors, cause the one or more processors to perform the method of any of claims 1-4.

7. A computer readable storage medium having stored thereon a computer program, wherein, the computer program, when executed by one or more processors, performs the method of any of claims 1-4.

Images