WO2024076253A1

WO2024076253A1 - Method and system for managing model risk

Info

Publication number: WO2024076253A1
Application number: PCT/RU2022/000305
Authority: WO
Inventors: Максим Николаевич БЕЛОЗЕРОВ; Александр Николаевич СМИРНОВ; Роман Юрьевич ТИХОНОВ
Original assignee: Публичное Акционерное Общество "Сбербанк России"
Priority date: 2022-10-06
Filing date: 2022-10-06
Publication date: 2024-04-11

Abstract

The claimed solution relates to a method and system for the automated management of model risk. A method for the automated management of model risk, implemented using at least one computing device, comprises the steps of: connecting to an execution environment to obtain data related to the performance of a model, containing predictions made by the model and the actual outcomes corresponding to said predictions; determining, on the basis of the model predictions and the corresponding actual outcomes, the existence of a model risk, and initiating a process of self-fine-tuning of the model, comprising the steps of: extracting, from the memory of the execution environment, data that can be provided as input to the model in order to obtain model predictions (updated data); determining a methodology for fine-tuning the model on the basis of data about the model type; fine-tuning the model on the updated data in accordance with the model fine-tuning methodology; releasing the fine-tuned model for commercial use in the execution environment. The technical result is that of enabling automated model risk management without human involvement.

Description

METHOD AND SYSTEM FOR MODEL RISK MANAGEMENT

TECHNICAL FIELD

[0001] The presented technical solution relates, in general, to the field of computer technology, and in particular to a method and system for automated model risk management in order to improve both the quality and efficiency of one individual model, and the quality of multiple models operating in the same process through auto-monitoring to check the quality of the model’s work, auto-additional training in case of deterioration in the quality of the model’s work results, followed by automatic launch of new and additionally trained versions of the models into industrial operation.

BACKGROUND OF THE ART

[0002] Systems and methods for enriching infrastructure modeling tools with semantics are known from the prior art, disclosed in application US 20190340518 A1, publ. 07.11.2019. Known solutions involve: creating a workflow knowledge graph based on information received through the application programming interface (API) of the modeling system, and storing the knowledge graph in the storage system of the modeling system, wherein the knowledge graph identifies at least one model monitoring module and an evaluation module workflow models; detection of unexpected input data during workflow processing, including: during execution of the model estimator by the modeling system and for each feature of the production data sets used by the model estimator: automatic comparison of the production distribution of feature values with the reference distribution of feature values for the feature, and in the case , when the comparison results satisfy an alert condition, providing an alert to an external system indicating the detection of unexpected input data, without assessing the performance of the model itself in the known solution.

[0003] A solution for modeling the risk of a network security breach is also known, disclosed in application US 20180048668 A1, publ. 02/15/2018. In the known solution, one or more agents collect analytical data from multiple sources on the network that identifies the observable characteristics of one or more network nodes, and create using data from the analysis of a multi-layered risk model for the network, which contains a first layer of the model that models the inherent risk of a security breach of network assets based on the observed characteristics of one or more nodes.

[0004] The disadvantage of the known solutions is the inability to manage model risk by automatically retraining the model on new data. Also, the presented solution does not use a knowledge graph, which reduces the computational load on the system in the process of managing model risk and on the system storage, as well as the dependence on the period of data synchronization between the original source and the graph, which is not used in the presented solution.

DISCLOSURE OF INVENTION

[0005] The technical problem or task posed in this technical solution is to create a simple and reliable method and system for managing model risk.

[0006] The technical result that the presented solution is aimed at achieving is to provide the ability to manage model risk automatically without human intervention.

[0007] The specified technical result is achieved by implementing a method for automated model risk management, performed by at least one computing device, containing the steps of:

- connect to the runtime environment to obtain data associated with the operation of the model, containing the predicted results of the model, and the actual results for said predicted results;

- based on the predicted results of the model’s work and the actual results of the model’s work, the presence of a model risk is determined and the process of auto-training the model is initiated, which contains stages in which: the data supplied to the model input is retrieved from the memory of the runtime environment to obtain the predicted results of the model’s work (updated data) ; determine the method of additional training of the model based on data about the type of model; the model is additionally trained on the updated data according to the method of additional training of the model;

- bring the additionally trained model into commercial operation in the runtime environment.

[0008] In one of the particular examples of the method, the stage of determining the presence of a model risk contains stages in which:

- assign to each predicted result a parameter indicating that the predicted result corresponds or does not correspond to the actual result or is within the range of acceptable deviations from the actual result;

- based on the parameters obtained at the previous stage, a value is determined that characterizes the ratio of parameters indicating that the predicted result of the model corresponds to the actual result to parameters indicating that the predicted result of the model does not correspond to the actual result;

[0009] - compare the obtained value with the interval of threshold values established for this model, characterizing the absence of model risk. In another particular example of the method, after determining the presence of a model risk, a command is sent to the runtime environment to decommission the model.

[0010] In another particular example of the method, auto-validation of the additionally trained model and/or updated data is additionally performed, and the additionally trained model is put into commercial operation if auto-validation of the additionally trained model and/or updated data is successful.

[0011] In another particular example of the method, the model autovalidation stage contains stages in which:

- based on data on the type of model, the validation methodology is determined;

- based on the data characterizing the validation methodology, determine the model coefficients that should be validated;

- a data sample associated with the specified results of the model’s operation is fed to the input of the additionally trained model to obtain the results of the model’s operation;

- compare the results obtained at the previous stage with the specified results of the model for the mentioned data sample; h - determine that said results of the model correspond to the specified results of the model;

- form a solution indicating that the coefficients of the additionally trained model have passed the validation process.

[0012] In another particular example of the method, the model autovalidation stage contains stages in which:

- based on data on the type of model, the validation methodology is determined;

- extract from the data characterizing the validation methodology a list of stages of the data processing algorithm;

- compare the list of stages of the data processing algorithm with the stages of the data processing algorithm of the additionally trained model;

- determine that all stages from the mentioned list are present in the data processing algorithm of the additionally trained model and form a solution indicating that the additionally trained model has passed the validation process in terms of the data processing algorithm.

[0013] In another particular example of the method, the model autovalidation stage contains stages in which:

- based on data on the type of model, the validation methodology is determined;

- based on the data on the validation methodology, determine the data contained in the updated data, which should be validated;

- extract data determined at the previous stage from the updated data;

- compare the extracted data with their threshold values or range of threshold values;

- determine that the data to be validated meets the threshold values and generate a decision indicating that the updated data has passed the validation process.

[0014] In another particular example of the method, the model autovalidation stage contains stages in which:

- updated data is supplied to the input of the additionally trained model to obtain the predicted results of the additionally trained model;

- comparing the predicted results with the actual results for said predicted results and assigning a parameter indicating that said predicted result corresponds or does not correspond to the actual result; - based on the parameters obtained at the previous stage, a value is determined that characterizes the ratio of parameters indicating that the predicted result of the additionally trained model corresponds to the actual result, to parameters indicating that the predicted result of the additionally trained model does not correspond to the actual result;

- compare the value obtained at the previous stage with the interval of threshold values of the model risk value;

- determine that the obtained value is within the interval of threshold values of the model risk value.

[0015] In another particular example of implementation of the method, it further comprises the steps of:

- extract data from an alternative model for the type of the retrained model;

- updated data is supplied to the input of the alternative model to obtain the predicted results of the additionally trained model;

- comparing the predicted results with the actual results for said predicted results and assigning a parameter indicating that said predicted result corresponds or does not correspond to the actual result;

- based on the parameters obtained at the previous stage, a value is determined that characterizes the ratio of parameters indicating that the predicted result of the alternative model corresponds to the actual result to parameters indicating that the predicted result of the alternative model does not correspond to the actual result;

- compare the value obtained at the previous stage with the value obtained for the additionally trained model, let us assume that the value obtained for the alternative model is greater than the value obtained for the additionally trained model, then a decision is made to put the alternative model into commercial operation instead of the additionally trained one.

[0016] In another particular example of implementation of the method, it further comprises the steps of:

- determine that the value obtained for the alternative model is equal to the value obtained for the additionally trained model; - determine the operating speed of the additionally trained and alternative model, and the model whose speed value is less important is put into commercial operation.

[0017] In another particular example of implementation of the method, it further comprises the steps of:

- determine that the value obtained for the alternative model is equal to the value obtained for the additionally trained model;

- determine the amount of computing resources used to process updated data by the retrained model and an alternative model, and the model that consumes less computing resources is put into commercial operation.

[0018] In another preferred embodiment of the claimed solution, a model risk management system is provided, comprising at least one computing device and at least one memory device containing machine-readable instructions that, when executed by at least one computing device, perform the above method.

BRIEF DESCRIPTION OF THE DRAWINGS

[0019] The features and advantages of the present technical solution will become apparent from the following detailed description of the invention and the accompanying drawings, in which:

[0020] In FIG. 1 - an example of the implementation of a model risk management system is presented.

[0021] In FIG. 2 - an example of a method for managing model risk is presented. [0022] in FIG. 3 - shows an example of a general view of a computing device.

IMPLEMENTATION OF THE INVENTION

[0023] The concepts and terms necessary to understand this technical solution will be described below.

[0024] In this technical solution, a system means, including a computer system, a computer (electronic computer), CNC (computer numerical control), PLC (programmable logic controller), computerized control systems and any other devices capable of performing a given task. , a clearly defined sequence of operations (actions, instructions). [0025] By command processing device is meant an electronic unit, a computing device, or an integrated circuit (microprocessor) that executes machine instructions (programs).

[0026] A command processing device reads and executes machine instructions (programs) from one or more storage devices. Storage devices can include, but are not limited to, hard drives (HDD), flash memory, ROM (read-only memory), solid-state drives (SSD), and optical drives.

[0027] A computing device is a counting and solving device that automatically performs one mathematical operation or a sequence of them in order to solve one problem or a class of similar problems (Great Soviet Encyclopedia. - M.: Soviet Encyclopedia. 1969 - 1978.).

[0028] Program - a sequence of instructions intended for execution by a computer control device or command processing device.

[0029] Database (DB) - a collection of data organized according to a conceptual structure that describes the characteristics of that data and the relationships between them, a collection of data that supports one or more application areas (ISO/IEC 2382:2015, 2121423 " database").

[0030] A signal is a material embodiment of a message for use in the transmission, processing and storage of information.

[0031] Logic element - an element that implements certain logical relationships between input and output signals. Logic elements are usually used to construct logical circuits of computers and discrete automatic monitoring and control circuits. All types of logical elements, regardless of their physical nature, are characterized by discrete values of input and output signals.

[0032] Automated system (AS) is an organizational and technical system that ensures the development of solutions based on the automation of information processes.

[0033] Model risk - the risk of adverse consequences arising from incorrect application of models in organizational processes, for example, Bank and/or inaccuracies (errors) in the operation of models associated with both modeling errors and changes in the surrounding world.

[0034] AutoML (Automatic Machine Learning) is the process of automating the end-to-end process of applying machine learning to real world problems.

[0035] Runtime (execution) environment - the computing environment necessary for the execution of a computer program and available during execution of the computer program.

[0036] According to the diagram shown in FIG. 1, the model risk management system contains: device 1 for developing models, device 2 for validating models, device 3 for making a decision on introducing the model into the industrial environment, runtime environment 4, device 5 for the model library (BM), device 6 for monitoring, device 7 for additional training of the model and device 8 library of ready-to-use techniques. The mentioned devices can be either separate devices connected by well-known wired or wireless data transmission channels, or combined in various ways into a single device, for example, by placing them in a single housing, for example, on a single printed circuit board through well-known assembly operations, and data between the mentioned devices is transmitted by generating appropriate signals.

[0037] The device 1 for developing models can be implemented on the basis of at least one computing device, implemented in hardware and software in such a way as to provide the user with the ability to create (develop) models from scratch or find, select and reuse ready-made models in new business processes . The modeling process by device 1 may include the following steps:

- data transformation (preprocessing necessary to bring the data to a format suitable for training and/or application of the model), for example, filling in missing values in the data, calculating aggregates and generating additional features, encoding information;

- selection of features, in particular characteristics, on the basis of which the model will form predictions;

- selection of the optimal model algorithm with the ability to use AutoML;

- detailed tuning of the model with setting and optimization of parameters. [0038] The model validation device 2 may be implemented on the basis of at least one computing device implemented in hardware and software in such a way as to provide the user with the opportunity to conduct a comprehensive quality check of the model, which includes:

- qualitative analysis: checking the correctness of qualitative (expert) premises used at the development stage, analyzing the correctness of the chosen modeling method, etc.;

- quantitative analysis: conducting quantitative tests to confirm the quality of the model and/or strategy on the available data;

- quantitative assessment of model risk (for classes of models with an approved methodology for calculating model risk);

- formation of a list of recommendations for refining the model and/or strategy aimed at reducing/avoiding a critical level of model risk. [0039] Additionally, the device 2 can be equipped with an autovalidation module 20, through which validation tests are automatically and periodically carried out for models that have been put into commercial use. The autovalidation module 20 can be made on the basis of the software and hardware of the device 2, equipped, for example, with corresponding logical elements on transistors, placed by well-known methods on a printed circuit board in such a way as to perform the functions assigned to the module 20. Also, by means of device 2, an alternative model can be automatically constructed as part of model validation. Depending on the type of model, validation method algorithms are selected from a library of methods (device 8) suitable for the received type of model, for example, for a credit scoring model, the validation method represents the rules for correlating the scoring score and the probability of the target. If an algorithm for a validation technique is not found in device 8 of the method library, then using device 2 the user can develop a validation method, as well as methods for training and/or additional training of the model, which can be saved in said device 8 for subsequent reuse. The validation technique (validation technique) can be saved in the form of ready-to-run executable code/module/workflow. [0040] Additionally, in device 2, the model can be improved, despite the fact that the model validation is in the green zone (all final traffic lights are green - this means that the validation result is positive, where one traffic light is the result of some model verification, which is part of some validation methodology, and there is a main traffic light, which is an aggregation of the results of all traffic light checks and shows the total result of the entire validation methodology), but during the validation, opportunities for its significant improvement were identified, for example, the rule for correlating the scoring score and the probability of the target was not included events in such a way that the average long-term level of the target event is equal to the average long-term forecast value of the probability of this event. In this example, the validator or system automatically selects an algorithm that has higher validation results or changes the process of working with input data taking into account this rule. Thus, the most successful methods for predicting events that are relevant for a given set of types of models are selected, or appropriate recommendations can be formulated based on the test results. This stage also allows you to check whether it is possible to obtain: a simpler model that requires less implementation and support costs in an industrial circuit; a more efficient model, the implementation of which makes it possible to increase the accuracy of predictions with minimal consumption of resources and/or computation time.

[0041] Also, device 2 can be used for semi-automation of the primary validation process during the iterative process of developing the first version of the model by a data scientist, where the data scientist periodically launches the validation methodology himself, for example, through the API interface and refines (retrains) the model based on the results of such validation (without participation of the validator in processes where such an opportunity is provided).

[0042] The result of the stage of passing validation tests is an assessment of the quality of the model in quantitative and/or qualitative dimensions, which serve as the basis for allowing the model to be put into commercial operation. Simulation and validation artifacts are stored in the BM device 5 to be captured for later analysis or provided to regulatory authorities upon request, and development and validation reports are sent to interested parties. If the result is positive, the model will be put into production operation and automatic monitoring of its quality control is configured. To monitor models, the developed validation methodology is periodically launched in automatic mode, the results of which, if an unacceptable loss in the quality of the model’s performance is detected, are the basis for making a decision on the need to additionally train the model, either in manual or automatic modes and/or remove such a model from operation. The additionally trained model (new version of the model) is also subject to validation in module 20 (autovalidation using the same validation methodology that was used for automonitoring). And in case of a positive result of autovalidation in device 3, a decision can be made to bring the additionally trained model into commercial operation of device 4.

[0043] Also, by means of the model validation device 2, as part of the validation, an assessment of the model risk can be carried out, characterizing its magnitude. At this stage, based on the description of the business process where this or that model operates, the user of device 2 creates a mathematical model that adapts to the described business process. As a result of the calculation algorithms, the system generates data on the amount of model risk that will arise when using the current model and an automatically created alternative model, if such a model is built. Also at this stage, the predicted deterioration in the quality of the model’s performance and the potential effect of reducing the magnitude of the model risk can be calculated, in which, periodically or, when a trigger is triggered for a decrease in auto-validation indicators, automatic additional training, auto-validation and automatic launch of a new version (for example, additionally trained) of the model into commercial operation are carried out. or removing the model from service under certain conditions.

[0044] The device 3 can be implemented on the basis of at least one computing device configured in hardware and software in such a way as to make the following decisions: 1 a decision to launch into commercial operation (into runtime 4) a new model after initial validation, or a new version of the model after auto-training in device 7 based on the results of auto-validation in module 20; 2. decision on the need for auto-training of the model in device 7 based on the results of auto-monitoring in device 6 or periodic validation of the model according to a given schedule or in accordance with the received validation command. If the validation result is negative, then module 3 makes a decision about the need for additional training of the model. After additional training of the model according to a given schedule or according to the appropriate command, validation of the model and the additionally trained model on updated data can also be carried out, within the framework of which the quality indicators of the models, for example, the magnitude of model risk, can be compared to make a decision on putting the additionally trained model into commercial operation.

[0045] Runtime 4 is hosted in a production environment and may be implemented on at least one computing device configured to connect to an unlimited number of external data sources to collect data for processing by at least one model to produce prediction results . For example, runtime 4 may be an automated system hosted by any organization, and in a particular example a banking system, and may be configured to analyze, through a model, customer transaction and credit product data for the purpose of predicting the value of credit risk, in alternative embodiments, for example, a forecast for the occurrence of an insured event for a motorist based on statistics of traffic violations or medical forecasts for the development of diseases based on analysis data and information about the patient’s lifestyle. In the presented solution, runtime 4 can be part of the presented model risk management system or be an external system.

[0046] The BM device 5 can be implemented by widely known methods, for example, those disclosed in patent RU2724799C1, publ. 06/25/2020, and be at least one database designed for storing modeling artifacts, including, for example, model coefficients and an algorithm for processing incoming data, written in any of the known programming languages; sample data that was used to train the model; reports on model development and validation, which can be presented in a pre-selected free format.

[0047] The model monitoring device 6 may be implemented on the basis of at least one computing device configured to connect to the primary data source, including the runtime environment 4, to automatically monitor the operation of the model. To do this, the autovalidation process is periodically initiated by sending the corresponding command to module 20, where the validation methodology is automatically launched on updated data related to the operation of the model. For each model, device 6 configures its own monitoring schedule. The launch of the validation methodology can be initiated not only according to a schedule, but also by any other method, for example, through the open API of device 6. The results of auto-validation are transferred to device 3 to make a decision on the need to further train the model in the event, for example, of a negative validation result and can be transferred to device 5 for saving history of monitoring of each model.

[0048] The device 7 for additional training of the model can be implemented on the basis of at least one computing device, implemented in the hardware and software part in such a way that, after making a decision about the need to additionally train the model by device 3, ensure automatic additional training of the model on updated data with the ability to configure training for each individual models to work with updated data, by referring to the original source of this data, and/or changing the algorithm of the model, if the alternative model obtained as a result of the work of device 2, for example, showed a better efficiency assessment, i.e., for example, more green traffic lights in the validation report. If the efficiency indicators of the main and alternative models are the same, for example, the speed of obtaining the final result can be taken into account; the one that gets the required indicator faster than its alternative will have priority.

[0049] Method Library device 8 can be implemented on the basis of at least one computing device, implemented in hardware and software in such a way that users of the system or in automatic mode have the opportunity to save developed and ready-to-use new methods that can be reused later for , for example, carrying out auto-validation or auto-additional training.

[0050] The model risk management system operates as follows.

[0051] In the first step, modeling artifacts of at least one model from the model development device 1 are supplied to the model validation device 2. The resulting model data may contain: in particular, the model identifier, model coefficients and an algorithm for processing incoming data; sample data that was used to train the model; report on model development, etc. For example, if the model is intended for forecasting the client’s credit risk and making a decision on issuing or refusing to issue a patent, then these models may contain:

- model coefficients used to process customer transaction data, and program code containing instructions for processing said data;

- samples of data on customer transactions on which the model was trained;

- report on the development of the model.

[0052] In an alternative implementation of the presented solution, if the model was developed on an external system, for example, in the runtime environment 4, and not in the device 1, then the modeling artifacts can be loaded automatically or upon user request into the BM device 5. The obtained data can also be used to validate models in device 2.

[0053] Model validation is a multi-stage process covering the stage of collecting information/data, studying the model, preparing a validation sample, comprehensive analysis of the model, ending with the preparation of a report documenting the identified weak areas of the model and recommendations for their possible solution. Model validation is usually carried out on the same data on which the model was trained, but does not exclude the preparation of special validation samples. The generated sample for validation must correspond to the data characterizing the target segment on which the model is planned to be used. Model developers provide the validation department via device 1 or device 5 with data specifications (examples of scripts for downloading data, rules for generating data sets, example data, etc.), as well as a link to centralized data sources used in developing and testing models. In a particular example, when assessing credit risk, the data provided by the developer should contain:

1. Modeling object identifiers, for example: a. D applications; b. D loan agreement; c. Date of the loan agreement;

2. Information on the target event: d. Target event implementation flag; e. Date of implementation of the target event; f. The reason for the implementation of the target event.

Using the above identifiers and target event information, modeling artifacts can be unambiguously extracted, including user transaction data, credit history, and other data that can be used in model training and validation. This information can be extracted from any database, including from the BM device 5, if this data was previously loaded into it. Representative samples for the purposes of model validation can be formed, for example, according to the following algorithm: observations are selected taking into account the requirement that the structure of the general population and the representative sample match the segments and the actual level of the target event (for example, the default rate). To do this, the entire set of observations according to the model is divided into two subsets: observations with a realized and unrealized target event. A random selection method is then applied to each subset based on the established selection percentage. The selection percentage for each subset is the same, which ensures an identical structure of target events in the population and sample.

[0054] During validation, the compliance of the model architecture stated in the documentation with its software implementation during development can also be checked.

[0055] Technically, the process of model validation consists of analyzing data quality in samples, qualitative and quantitative analysis of the model (see, for example, the article “Validation of machine learning models”, htps://habr.com/ru/company/glowbyte/blog /569970/). The general structure of the tests used for qualitative and quantitative analysis is a list of tests used in the validation process to assess the effectiveness and quality of the models. The purpose of the tests is to evaluate the quality of the algorithms used, analyze the operating features of the model and its components, and compare the quality of the result obtained with the declared or required quality, as well as the quality observed during development.

[0056] Validation of the model under conditions of a sufficient number of target events (for example, defaults) and validation of the model with an insufficient number of target events are distinguished. Standards for the sufficiency of the target event level for a sample depend on the total number of observations in the sample, the number of target events, and the level of acceptable confidence interval for the calculation. [0057] To reflect the results of validation (where applicable), for example, a simple three-level color coding can be used:

* Green traffic light: the model meets the requirements laid down in the test;

* Yellow traffic light: in general, the model meets the requirements laid down in the test, but there are possibilities for its improvement;

* Red traffic light: the model does not meet the test requirements and needs to be improved.

Assigning a green color to a group of tests means that the model meets the criteria set for it and can be introduced into the industrial environment automatically in its current form. If the color is yellow, the model can be released into an industrial environment, but if certain conditions are met (acceptance of risks by the owner, for example) and, as a rule, not in automatic mode. When the traffic light is red, the model is usually not launched into an industrial environment.

[0058] The results of each test in the validation report are usually provided with information about the samples that were used to conduct this test, including the names of the tables in the internal database. Summary characteristics of all samples used during validation (for example, default rate, average probability of default, number of observations, etc.) are also provided in the validation report in the “Data Used” section in an aggregated form.

[0059] Qualitative analysis includes a preparatory phase and a testing phase of the model structure and is intended to evaluate the quality and appropriateness of the choice of model option/factors when compared with similar models. In this case, special attention is paid to the prerequisites used in the cleaning/modification of primary data for development, for example: Does the selected modeling approach correspond to the current methodology for developing models for assessing the probability of default / the approach adopted by the bank or does the modeling take into account all significant information that affects the borrower’s risk .

[0060] The results of the qualitative analysis of the model are documented in the corresponding section of the validation report. For each qualitative test, a final traffic light color is assigned. [0061] Quantitative analysis of the model consists of conducting quantitative tests that involve calculating indicators, as well as interpreting the results obtained. The following key groups of tests for assessing the effectiveness of models are carried out:

• influence of data quality on model performance;

• efficiency of the model ranking;

• model specification;

• model calibration;

• stability of the model;

• concentration of model results;

• additional tests for corporate models and counterparty models for transactions in financial markets;

[0062] Quantitative analysis of the model is carried out on samples that fully correspond to its field of application (including in the case where the model was developed on an incomplete sample that does not completely cover the target segment). The final conclusion about the effectiveness of the model is made for all areas of its application, based on the analysis of the matrices of the final traffic lights, which are processed by the decision-making device 3.

[0063] When validating models, all tests are carried out using the final results of the model used in business processes (for example, probability of default, rating, etc.).

[0064] Accordingly, the model validation procedure carried out by the user of the model validation device 2 is stored by said user in the memory of the device 2 as a workflow. The saved validation procedure may contain: data about the model type, for example, model identifier; data on model coefficients that need to be validated; data on threshold values of model coefficients; list of stages of the data processing algorithm; references to data in the data sample that should be validated; threshold values of data in the data sample and the threshold value of the model risk, etc. The saved validation technique can be used by the autovalidation module 20 to validate the model in an automated mode.

[0065] Accordingly, the result of model validation carried out automatically by the system or by the user is stored in the device 5 Library Models. Next, the system automatically, through device 3 or the user, makes a decision to put the model into commercial operation using the following algorithms:

- If the model does not satisfy or does not fully satisfy the requirements for it (there is a red or yellow pass indicator for one or more test blocks), an action plan is generated to eliminate the model’s deficiencies and includes it in the model validation report.

- In case of receiving a red traffic light for the final quality of the model, a note is made in the validation report about the impossibility of using this model to solve the assigned business problems.

- Or if all the final traffic lights have received a green value, a note is made about the recommendation of this model to solve the business problems set and the process of putting the model into commercial operation in runtime environment 4 is initiated automatically by device 3 or by the user through device 5. The model is put into commercial operation by transmitting the model data by device 3 or device 5 to said runtime environment 4, after which the runtime environment processes the data through the received model in order to obtain predicted results of the model. All obtained results are stored in the database of the mentioned runtime environment 4 or can be given to consumers upon request, including for auto-monitoring (periodic validation of such a model) or for auto-additional training. The results of monitoring and additional training are saved in device 5 BM. Along with each predicted result of the model, updated data that was fed to the model input can also be saved for further auto-training.

[0066] For example, if the model is intended to make a decision about issuing or refusing to issue a loan, then the runtime 4, for example, will collect transaction data regarding at least one user, transmitting said transaction data, for example, in the form vectors to the input of the said model, determining the value of the model risk based on transaction data and obtaining the predicted result of the said model, indicating that the client will repay the loan or not repay the loan. Accordingly, the predicted result of the model is stored in the database of said runtime environment 4 along with transaction data submitted to the input of said model. Also the predicted results of the model can be transferred to external systems upon their request.

[0067] Also, in the runtime database 4 for the predicted result of the model, information about the actual result for this predicted result can be added. Said actual result information can be added either by the user of the runtime environment 4 or collected using well-known automated data collection methods and tools. Information about the actual result is usually added with some time delay, but for some systems the information mentioned can be added simultaneously with the predicted result of the model.

[0068] For example, if the model predicts that a customer will repay a loan, then the customer is issued a loan and subsequently factual information is stored indicating that the customer has or has not repaid the loan. Accordingly, if the model predicted that the client will not repay the loan, then the actual result is not saved, since the loan is not issued to the client.

[0069] Automatic monitoring and control (100, see Fig. 2) of the model risk of the model is carried out as follows. During the operation of the runtime environment 4, the model monitoring device 6 can, using known methods, for example, according to a schedule set by the developer or the administrator of the environment 4, connect (101) to the runtime environment 4, in particular to the database or its replicas, to obtain data related to the work model, including, for example, the predicted results of the model and the actual results for a period of time specified by the developer and assign to each predicted result of the model a parameter indicating that the predicted result corresponds or does not correspond to the actual result or is within the range of acceptable deviations from the actual result , wherein the interval can be set by the developer or administrator of said device 7 or obtained, for example, from device 5, where meta-information about the models is stored, including threshold values, intervals and other model attributes.

[0070] For example, if the runtime database 4 stores a predicted model output indicating that the customer will repay the loan, and the actual result indicates that the customer has repaid the loan, then device 6 assigns a parameter to the predicted model output, indicating that said predicted result matches the actual result. Accordingly, if the runtime database 4 stores the predicted result of the model indicating that the client will repay the loan, and the actual result indicates that the client did not repay the loan, then device 6 assigns to the predicted result of the model a parameter indicating that that the said predicted result does not correspond to the actual result.

[0071] Certain mentioned parameters are then transmitted by the monitoring device 6 to the autovalidation module 20, which, based on the received parameters, determines a value characterizing the ratio (for example, percentage) of the parameters indicating that the predicted result of the model corresponds to the actual result to the parameters indicating that the predicted result of the model does not correspond to the actual result. The obtained value is compared by device 2 with the interval of threshold values established for a given model, for example, by the developer or owner of the model in device 5 BM, which characterizes the absence of model risk. If the received value falls outside the threshold value interval, then device 2 transmits the results about the presence (102) of a model risk to decision-making device 3, which in turn determines and makes a decision, based on the above mentioned results, about the need for auto-training (103) of the model installed in runtime 4.

[0072] To further train the model, the decision-making device 3 initiates the operation of the additional training device 7, which, to carry out auto-training, retrieves from the database of the runtime environment 4 updated data related to the operation of the model for a given period of time, for example, data supplied to the input of the model, predicted results of the model’s operation and actual results and possibly other data suitable for the type of model specified by the device 7 and specified in the model development report or in its parameters, after which it retrieves model metadata from the BM device 5, in particular model coefficients, threshold values, etc. ., an algorithm for processing incoming data, and can also extract additional training methods from device 8 and carry out additional training in automatic mode. Alternatively, additional training can be carried out in device 4, where the additional training technique must be implemented as some part of the supplied model. Alternatively implementation of the presented solution, additional training of the model can be performed with the preliminary decommissioning of the model.

[0073] Next, the additional training device 7, using known methods, performs additional training of the model on previously extracted data, and the resulting artifacts of the new additional trained version of the model are saved (fixed) in the BM device 5 and sent to the autovalidation module 20 located in device 2.

[0074] After receiving the data from the additionally trained model, the autovalidation module 20 validates the additionally trained model. To validate the retrained model, module 20 determines a validation methodology based on the model type. Information about the type of model can be contained in data about the model and the additionally trained model stored in the BM device 5, and can be found, for example, by the identifier (ID) of the model. Accordingly, module 20, through device 2, sends a request with the model ID to BM device 5, which stores the correspondence between model IDs and their type, and which in response sends the model type, according to which module 20 retrieves the corresponding model validation technique from device 8. In an alternative embodiment of the presented solution, the model IDs and model types may be stored in a memory of the device 2 with which it may be equipped.

[0075] As part of performing a validation technique based on data characterizing the validation technique, said module 20 may determine model coefficients to be validated. Next, module 20 retrieves a data sample for a given type of model, which is intended for validating the model coefficients, and the specified results of the model associated with the said sample. The data samples and the corresponding model outputs may be preset in the memory of the module 20 or in any other memory area of any other device to which the module 20 has access. For example, said data sample may contain data on customer transactions, their income, etc. , and the given results of the model can indicate whether the client has repaid the loan or not.

[0076] The above-mentioned data sample is then fed by module 20 to the input of the additionally trained model to obtain the results of the model, which are compared with the specified results of the model for the said data sample. If the obtained mentioned results correspond to the specified results of the model, then module 20 generates a solution indicating that the coefficients of the additionally trained model have passed the validation process. Accordingly, if the obtained mentioned results do not correspond to the specified results of the model, then module 20 generates a decision indicating that the coefficients of the additionally trained model did not pass the validation process.

[0077] As part of the implementation of the validation technique, the autovalidation module 20 can additionally extract from the data characterizing the validation technique a list of stages of the data processing algorithm and compare it with the stages of the data processing algorithm of the additionally trained model. If all the stages from the mentioned list are present in the data processing algorithm of the pre-trained model, then module 20 generates a solution indicating that the pre-trained model has passed the validation process in terms of the data processing algorithm. Accordingly, if at least one stage is missing, then module 20 generates a solution indicating that the retrained model in terms of the data processing algorithm has not passed the validation process.

[0078] As part of the execution of the validation methodology, the autovalidation module 20 can additionally, based on data about the validation methodology, determine updated data in the data sample that was used to further train the model and which must be validated. Next, the mentioned module 20 extracts from the data sample that was used for additional training of the model, the data that should be validated, and compares them with the data threshold values or a range of threshold values. For example, the data that should be validated may be characterized by missing data (for example, age is not specified for calculating a credit score), the number of duplicate data, the number of anomalies in the data, etc.

[0079] Accordingly, if the data that should be validated corresponds to the declared parameters (for example, threshold values), then module 20 generates a decision indicating that the data that was used to further train the model has passed the validation process. Otherwise, module 20 generates a decision indicating that the data that was used to further train the model did not pass the validation process. Additionally, as part of the validation of updated data in the data sample, the impact of gaps, duplicate data, anomalies and data exceeding threshold values on the quality of the model can be checked, as well as the representativeness and relevance of the data can be assessed, and stability can be checked population and data characteristics, stress testing of the impact of data changes on the quality of the model was carried out.

[0080] As part of the validation procedure, module 20 can additionally submit to the input of the pre-trained model that has undergone the validation procedure, the data that was used to re-train the model to obtain predicted results of the pre-trained model. The obtained said predicted results are compared by module 20 with the actual results stored for the said data, which were used for additional training of the model, stored in the BM device 5, after which module 20 assigns to each predicted result of the additional trained model a parameter indicating that the said predicted result corresponds or does not correspond to the actual result.

[0081] Next, module 20, based on the parameters obtained above, can determine a value characterizing the ratio (for example, percentage) of parameters indicating that the predicted result of the pre-trained model corresponds to the actual result to parameters indicating that the predicted result of the work the pretrained model does not correspond to the actual result. The obtained value is compared by module 20 with the interval of threshold values of the model risk value established for this model, for example, by the developer of the mentioned module 20, characterizing the absence of model risk. If the obtained value falls outside the range of threshold values of the model risk value or the coefficients of the additionally trained model, the stages of the data processing algorithm of the additionally trained model, or the updated data in the data sample that was used for additional training of the model did not pass the validation process, then module 20 decides that the additionally trained the model has not passed the validation procedure, after which it transmits the validation results to the decision-making device 3, which in turn determines and makes a decision, based on the obtained mentioned results, if necessary, to take the model out of service if it has not previously been taken out of service . Accordingly, if the mentioned value is within the interval of threshold values and all the decisions generated above indicate that all checks (data) have passed the validation process, then module 20 decides that the additionally trained model has passed the validation procedure, and decision-making device 3 makes decision to put the model into commercial operation (104), i.e. to runtime 4.

[0082] Thus, by monitoring the performance of a model operating in an industrial environment, in particular the magnitude of model risk, and auto-training the model, in the event of a drop in quality indicators, using updated data, the achievement of the specified technical result is achieved, which consists in providing the ability to manage model risk automatically without human intervention. Additionally, the accuracy of model risk management can be increased by performing auto-validation of the additionally trained model and/or updated data before putting the additionally trained model into commercial operation. Also, due to the fact that additional training of the model is carried out on updated data extracted from the runtime environment for a given period of time, the computational load on the computing device that performs additional training of the model is reduced, since the said device does not need to store and process the entire array of data received as the input of the model.

[0083] In an alternative embodiment of the presented solution, the autovalidation module 20, after determining that the mentioned value characterizing the ratio of parameters is within the threshold value interval, can extract from device 2 or device 5 BM data about at least one alternative model for the type the additionally trained model, and then send the mentioned updated data, which was used for additional training of the model, to the model input to obtain the predicted results of the alternative model. The obtained said predicted results are compared by module 20 with the actual results stored for said updated data, which were used for additional training of the model, in the BM device 5, after which module 20 assigns to each predicted result of the alternative model a parameter indicating that the said predicted result corresponds or does not correspond to the actual result.

[0084] Next, the autovalidation module 20, based on the parameters obtained above, can determine (in the manner described above) a value characterizing the ratio of parameters indicating that the predicted result of the alternative model corresponds to the actual result to parameters indicating that the predicted result of the work the alternative model does not correspond to the actual result. The received mentioned value by module 20, together with the value obtained for the alternative model, is sent to device 3, which compares the received values and if the mentioned value obtained for the alternative model is greater than the value obtained for the additionally trained model, then device 3 decides to output an alternative model into industrial operation, i.e. to runtime environment 4. If the value obtained for the alternative model is less than the value obtained for the additionally trained model, then device 3 decides to put the additionally trained model into commercial operation.

[0085] If the value obtained for the alternative model is equal to the value obtained for the additionally trained model, then device 3 determines the speed of operation of the additionally trained and alternative models. To determine the speed of the models, device 3 sends a corresponding request to the autovalidation module 20, which can be equipped, for example, with a counter - an electronic device for determining the degree of accumulation of any value over time, by integrating the value of the current measurement. To determine the time, module 20, using a counter, records the time value of sending the data model to the input and the time value of obtaining the predicted result of the model's operation and, on their basis, determines the value of the model's operation speed.

[0086] Accordingly, module 20 sends the operating speed values of the additionally trained and alternative models to device 3, which compares the obtained values and puts into commercial operation the model whose speed value is lower.

[0087] Also, using known methods, module 20 can estimate the amount of computing resources used to process updated data by the retrained model and the alternative model. For example, the load on RAM, processor, hard drive, etc. during data processing by the mentioned models can be assessed. Accordingly, the model that consumes less computing resources can be put into commercial operation.

[0088] In general (see Fig. 3), a computing device (200) contains one or more processors (201), memory devices such as RAM (202) and ROM (203), and interfaces connected by a common information exchange bus. input/output devices (204), input/output devices (205), and network communication device (206).

[0089] The processor (201) (or multiple processors, multi-core processor, etc.) may be selected from a variety of devices commonly used today, for example, from manufacturers such as: Intel™, AMD™, Apple™, Samsung Exynos ™, MediaTEK™, Qualcomm Snapdragon™, etc. The processor or one of the processors used in the device (200) must also include a graphics processor, for example an NVIDIA GPU with a CUDA-compatible programming model or Graphcore, the type of which is also suitable for carrying out the method in whole or in part, and can also be used for training and application of machine learning models in various information systems.

[0090] RAM (202) is a random access memory and is designed to store machine-readable instructions executed by the processor (201) to perform the necessary logical data processing operations. The RAM (202) typically contains executable operating system instructions and associated software components (applications, program modules, etc.). In this case, the available memory capacity of the graphics card or graphics processor can act as RAM (202).

[0091] The ROM (203) is one or more permanent storage devices, such as a hard disk drive (HDD), a solid state drive (SSD), flash memory (EEPROM, NAND, etc.), optical storage media ( CD-R/RW, DVD-R/RW, BlueRay Disc, MD), etc.

[0092] To organize the operation of device components (200) and organize the operation of external connected devices, various types of I/O interfaces (204) are used. The choice of appropriate interfaces depends on the specific design of the computing device, which can be, but is not limited to: PCI, AGP, PS/2, IrDa, FireWire, LPT, COM, SATA, IDE, Lightning, USB (2.0, 3.0, 3.1, micro, mini, type C), TRS/Audio jack (2.5, 3.5, 6.35), HDMI, DVI, VGA, Display Port, RJ45, RS232, etc.

[0093] To ensure user interaction with the computing device (200), various means (205) of I/O information are used, for example, a keyboard, a display (monitor), a touch display, a touch pad, a joystick, a mouse, a light pen, a stylus, touch panel, trackball, speakers, microphone, augmented reality, optical sensors, tablet, light indicators, projector, camera, biometric identification tools (retina scanner, fingerprint scanner, voice recognition module), etc.

[0094] The network communication means (206) provides data transmission via an internal or external computer network, for example, an Intranet, the Internet, a LAN, etc. One or more means (206) may be used, but not limited to: Ethernet card, GSM modem, GPRS modem, LTE modem, 5G modem, satellite communication module, NFC module, Bluetooth and/or BLE module, Wi-Fi module and etc. [0095] Additionally, satellite navigation tools can also be used as part of the device (200), for example, GPS, GLONASS, BeiDou, Galileo.

[0096] The specific selection of device elements (200) for implementing various software and hardware architectural solutions may vary while maintaining the required functionality provided. [0097] Modifications and improvements to the above-described embodiments of the present technical solution will be apparent to those skilled in the art. The foregoing description is provided by way of example only and is not intended to be limiting. Thus, the scope of the present technical solution is limited only by the scope of the attached claims.

Claims

CLAIM

1. A method for automated model risk management, performed by at least one computing device, containing the steps of:

2. The method according to claim 1, characterized in that the stage of determining the presence of a model risk contains stages in which:

- compare the obtained value with the interval of threshold values established for this model, characterizing the absence of model risk.

28

3. The method according to claim 1, characterized in that after determining the presence of a model risk, a command is sent to the runtime environment to decommission the model.

4. The method according to claim 1, characterized in that they additionally perform auto-validation of the additionally trained model and/or updated data, and the additionally trained model is put into commercial operation if the auto-validation of the additionally trained model and/or updated data is successful.

5. The method according to claim 4, characterized in that the model auto-validation stage contains stages in which:

- based on data on the type of model, the validation methodology is determined;

- compare the results obtained at the previous stage with the specified results of the model for the mentioned data sample;

- determine that said results of the model correspond to the specified results of the model;

6. The method according to claim 4, characterized in that the model auto-validation stage contains stages in which:

- based on data on the type of model, the validation methodology is determined;

7. The method according to claim 4, characterized in that the model auto-validation stage contains stages in which:

- based on data on the type of model, the validation methodology is determined; - based on the data on the validation methodology, determine the data contained in the updated data, which should be validated;

- extract data determined at the previous stage from the updated data;

8. The method according to claim 4, characterized in that the model auto-validation stage contains stages in which:

- based on the parameters obtained at the previous stage, a value is determined that characterizes the ratio of parameters indicating that the predicted result of the additionally trained model corresponds to the actual result, to parameters indicating that the predicted result of the additionally trained model does not correspond to the actual result;

9. The method according to claim 8, characterized in that it additionally contains the steps of:

- extract data from an alternative model for the type of the retrained model;

- compare the predicted results with the actual results for said predicted results and assign a parameter, indicating that said predicted result corresponds or does not correspond to the actual result;

- compare the value obtained at the previous stage with the value obtained for the additionally trained model, and the value obtained for the alternative model is greater than the value obtained for the additionally trained model, then a decision is made to put the alternative model into commercial operation instead of the additionally trained one.

10. The method according to claim 8, characterized in that it additionally contains the steps of:

- determine the operating speed of the additionally trained and alternative model, and the model whose speed value is less important is put into commercial operation.

11. The method according to claim 8, characterized in that it additionally contains the steps of:

12. A model risk management system comprising at least one computing device and at least one memory device containing machine-readable instructions that, when executed by at least one computing device, perform the method according to any one of claims. 1-11.