Constraints compliant machine-learning techniques

Abstract

In some aspects, a computing system can train a machine learning (ML) model for risk assessment. Once trained, the ML model can determine a risk indicator for a target entity that indicates a level of risk associated with the target entity. Training the ML model can include: receiving compliance metadata and the machine learning model; for each feature, comparing an associated usage value with a threshold usage value for each of the features associated with the machine learning model; for each feature, including that feature in a compliant set of training features based on the comparison; generating a training dataset comprising the compliant set of training features; and generating an updated machine learning model by training the machine learning model using the training dataset.

Description

Attorney Docket No.: 096923-1364025CONSTRAINTS COMPLIANT MACHINE-LEARNING TECHNIQUESTechnical Field

[0001] The present disclosure relates generally to artificial intelligence for risk prediction. More specifically, but not by way of limitation, this disclosure relates to ensuring constraints compliance of machine learning models in machine learning operations (ML Ops).Background

[0002] In machine learning, models can be used to perform one or more functions (e.g., acquiring, processing, analyzing, and understanding various inputs in order to produce an output that includes numerical or symbolic information). A machine learning model, such as a neural network, includes one or more algorithms and interconnected components that exchange data between one another. The model can have numeric parameters that can be tuned based on experience, which makes the model adaptive and capable of learning. For example, the numeric weights of a neural network can be used to train the neural network such that the neural network can perform the one or more functions on a set of input variables and produce an output that is associated with the set of input variables.

[0003] Machine Learning Operations (ML Ops) is a field to apply Data Operations (Data Ops) and Continuous Integration and Continuous Deployment (CI / CD) software principles to machine learning models to continuously develop and deploy predictive models. However, existing ML Ops approaches do not have constraints on the generated predictive models rendering the ML Ops unapplicable to certain applications.Summary

[0004] Various aspects of the present disclosure provide systems and methods for generating constraint compliant training data and constraint compliant machine learning models for use in risk assessment. In one example, a method includes one or more processing devices performing operations including: determining, using a machine learning model trained using a training process, a risk indicator for a target entity from predictor variables associated with the target entity, where the machine learning model is associated with one or more features. The training process can include receiving compliance metadata and the machine learning model, the compliance metadata including a set of features and a usage value1US2008 30389410 1Attorney Docket No.: 096923-1364025 associated with each feature. The usage value can indicate whether each feature can be used to train the machine learning model. The training process can also include, for each feature of the set of features, comparing the usage value with a threshold usage value for each of the one or more features associated with the machine learning model and including that feature in a compliant set of training features based on the comparison. The training process also includes generating a training dataset comprising the compliant set of training features. The training process further includes generating a first version of the machine learning model by training the machine learning model using the training dataset. The method can further include transmitting, to a remote computing device, a responsive message comprising at least the risk indicator for use in controlling access of the target entity to one or more computing environments.

[0005] In another example, a system includes a processing device; and a memory device in which instructions executable by the processing device are stored for causing the processing device to perform various operations. The system can determine, using a machine learning model trained using a training process, a risk indicator for a target entity from predictor variables associated with the target entity, where the machine learning model is associated with one or more features. The training process can include receiving compliance metadata and the machine learning model, the compliance metadata including a set of features and a usage value associated with each feature. The usage value can indicate whether each feature can be used to train the machine learning model. The training process can also include, for each feature of the set of features, comparing the usage value with a threshold usage value for each of the one or more features associated with the machine learning model and including that feature in a compliant set of training features based on the comparison. The training process also includes generating a training dataset comprising the compliant set of training features. The training process further includes generating a first version of the machine learning model by training the machine learning model using the training dataset. The system can further transmit, to a remote computing device, a responsive message comprising at least the risk indicator for use in controlling access of the target entity to one or more computing environments.

[0006] In yet another example, a non-transitory computer-readable storage medium has program code that is executable by a processor to cause a computing device to perform operations. The operations can include determining, using a machine learning model trained using a training process, a risk indicator for a target entity from predictor variables associated with the target entity, where the machine learning model is associated with one or more features. The training process can include receiving compliance metadata and the machine2US2008 30389410 1Attorney Docket No.: 096923-1364025 learning model, the compliance metadata including a set of features and a usage value associated with each feature. The usage value indicates whether each feature can be used to train the machine learning model. The training process can also include, for each feature of the set of features, comparing the usage value with a threshold usage value for each of the one or more features associated with the machine learning model and including the feature in a compliant set of training features based on the comparison. The training process also includes generating a training dataset comprising the compliant set of training features. The training process further includes generating a first version of the machine learning model by training the machine learning model using the training dataset. The operations can further include transmitting, to a remote computing device, a responsive message comprising at least the risk indicator for use in controlling access of the target entity to one or more computing environments.

[0007] This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used in isolation to determine the scope of the claimed subject matter. The subject matter should be understood by reference to appropriate portions of the entire specification, any or all drawings, and each claim.

[0008] The foregoing, together with other features and examples, will become more apparent upon referring to the following specification, claims, and accompanying drawings.Brief Description of the Drawings

[0009] FIG. 1 is a block diagram depicting an example of an operating environment according to certain aspects of the present disclosure.

[0010] FIG. 2 is a flow chart depicting an example of a process for generating a risk indicator according to certain aspects of the present disclosure.

[0011] FIG. 3 is a flow chart depicting an example of a process for training a machinelearning model according to certain aspects of the present disclosure.

[0012] FIG. 4 is a flow chart depicting an example of a process for generating and monitoring a machine-learning model according to certain aspects of the present disclosure.

[0013] FIG. 5 is a flow chart depicting an example of a pipeline design process according to certain aspects of the present disclosure.

[0014] FIG. 6 is a flow chart depicting an example of a data management process according to certain aspects of the present disclosure.3US2008 30389410 1Attorney Docket No.: 096923-1364025

[0015] FIG. 7 is a flow chart depicting an example of a model training process according to certain aspects of the present disclosure.

[0016] FIG. 8 is a flow chart depicting an example of a model check process according to certain aspects of the present disclosure.

[0017] FIG. 9 is a flow chart depicting an example of a population stability monitoring process according to certain aspects of the present disclosure.

[0018] FIG. 10 is an illustration of an example of a compliance scorecard according to certain aspects of the present disclosure.

[0019] FIG. 11 is an illustration of an example of a graphical user interface (GUI) according to certain aspects of the present disclosure.

[0020] FIG. 12 is a block diagram depicting an example of a computing device suitable for implementing aspects of the techniques and technologies presented herein.

[0021] FIG. 13 is an illustration of a table of exemplary compliance metadata according to certain aspects of the present disclosure.Detailed Description

[0022] Certain aspects and features of the present disclosure are directed to providing a predictive model for risk assessment that complies with a set of predetermined requirements or constraints. For example, in some aspects, the systems and methods disclosed herein impose feature requirements at various points in pipeline development, deployment, and execution process in order to automatically create predictive models for use in risk assessment that comply with a set of predetermined requirements or constraints. As an example, the set of requirements or constraints can ensure compliant feature usage and treatment, statistical soundness, and monitor compliance in real time or near real time.

[0023] For instance, systems and methods described herein can enable the dynamic and automatic development, deployment, and execution of a predictive model for risk assessment that complies with a set of requirements. The compliant predictive model can be generated using an ML Ops pipeline that applies the set of requirements, which is received as compliance metadata. For example, the pipeline can include steps for data management, model training, model monitoring, and model publication (e.g., to a production environment) such that the developed and published model is compliant with the set of requirements.

[0024] To generate the compliant model, disclosed implementations can receive the compliance metadata associated with a model and generate a compliant training dataset. For4US2008 30389410 1Attorney Docket No.: 096923-1364025 instance, based on the compliance metadata, a compliant set of features can be generated with which to train a candidate model. The compliant set of features can be based on feature requirements defined by the compliance metadata. Feature requirements can include capping and flooring values, missing value indicators, trends to enforce, and / or imputation values. A candidate model can then be trained using this compliant training dataset based on the compliance metadata. By training the candidate model on the compliant set of features, a compliant model can be developed and published to a production environment for use in risk prediction. For example, disclosed systems and methods enable a prediction model to operate in compliance with defined requirements, which allows the training of the model to be performed more efficiently with little to no post-training adjustment in response to changing model requirements.

[0025] In this example, the training process used to generate the compliant model can receive compliance metadata and the current version of a machine learning model (or a randomly initialized machine learning model if no previous model is available). The compliance metadata can include a set of features and a usage value associated with each feature where the usage value indicates an extent to which each feature can be used to train the machine learning model. For example, the usage value can be based on a compliance scorecard and can reflect a number of characteristics of a feature such as causality and attainability among others. For each feature of the set of features, the system can compare the usage value with a threshold usage value for each of the one or more features associated with the machine learning model. If the usage value is above the threshold usage value for the feature, then the feature can be included in a compliant set of training features.

[0026] The system can generate a training dataset including the compliant set of training features and generating the machine learning model by training the current version of the machine learning model using the training dataset. Thus, the generated training dataset can be generated to be compliant with the compliance metadata such that the model trained on the compliant set of training features adheres with the requirements defined by the compliance metadata. The trained model can be used to generate a risk indicator for the target entity where the risk indicator is output by the trained, compliant model based on the machine learning model.

[0027] Certain aspects described herein provide improvements to machine learning techniques for assessing risks, for example, in access control associated with entities. For instance, the risk assessment model described herein can be dynamically updated to reflect changing compliance requirements of the model. For example, disclosed systems can monitor5US2008 30389410 1Attorney Docket No.: 096923-1364025 a compliance metadata repository for any changes or updates to the stored compliance metadata associated with a particular model. The compliance metadata can describe a set of requirements for a model (e.g., requirements received from an external regulatory body). Implementations described herein enable dynamic and automatic updating of a risk assessment model to meet updating or changing compliance requirements without additional intervention by a user.

[0028] In an example, a system can determine a risk indicator for a target entity from predictor variables associated with the target entity. The risk indicator can use a machine learning model trained using a training process configured to generate a predictive model that is compliant with a set of requirements. As discussed above, exemplary systems can monitor a compliance metadata repository for changes to compliance metadata (e.g., to the model requirements) such that changes in the requirements can be used to update the current version of a model to be in compliance with the changed requirements.

[0029] These illustrative examples are given to introduce the reader to the general subject matter discussed here and are not intended to limit the scope of the disclosed concepts. The following sections describe various additional features and examples with reference to the drawings in which like numerals indicate like elements, and directional descriptions are used to describe the illustrative examples but, like the illustrative examples, should not be used to limit the present disclosure.Operating Environment Example for Machine-Learning Operations

[0030] Referring now to the drawings, FIG. 1 is a block diagram depicting an example of an operating environment 100 in which a risk assessment computing system 130 builds and trains a risk assessment model 120 that can be trained to predict risk indicators based on training data provided at least in part by execution of a compliance pipeline 112. FIG. 1 depicts examples of hardware components of a risk assessment computing system 130, according to some aspects. The risk assessment computing system 130 is a specialized computing system that may be used for processing large amounts of data using a large number of computer processing cycles. The risk assessment computing system 130 can include a model training server 110 for building and training a risk assessment model 120 used to predict risk indicators associated with an entity accessing controlled resources. In some embodiments, input predictor variables 124 of the risk assessment model 120 or factors of the input predictor variables 124 have a monotonic relationship with the output of the risk assessment model 120. The risk assessment computing system 130 can further include a risk assessment server 118 for performing a risk assessment for given predictor variables 124, or features, using the trained risk assessment model 120.6US2008 30389410 1Attorney Docket No.: 096923-1364025

[0031] The compliance pipeline sub-system 110 can include one or more processing devices that execute program code, such as a compliance pipeline 112. The program code is stored on a non-transitory computer-readable medium. The compliance pipeline 112 can execute one or more processes or applications to develop, train, and optimize a risk assessment model 120 for predicting risk indicators based on the predictor variables 124. In some instances, the risk assessment model 120 may predict the risk indicators while maintaining a monotonic relationship between the factors of the predictor variables 124 and the predicted risk indicators.

[0032] In some aspects, the compliance pipeline 112 can build and train a risk assessment model 120 using risk assessment training data 126 in a training process. The risk assessment training data 126 can include multiple training vectors including training predictor variables and training risk indicator outputs corresponding to the training vectors. In some cases, the risk assessment training data 126 may include differing subsets of data sources available. The risk assessment training data 126 can be stored in one or more network-attached storage units on which various repositories, databases, or other structures are stored. An example of these data structures is the risk data repository 122.

[0033] The compliance pipeline 112 can include applications and executable code configured to develop and execute a pipeline to create predictive models for regulated use cases. For example, components of the compliance pipeline 112 can receive or otherwise access compliance metadata 128 and ensure compliant feature usage and treatment in predictive models (e.g., risk assessment model 120). For example, the compliance metadata 128 can include information such as missing value indicators, flooring / capping values, imputation values, and the like that are associated with a set of features. Components of the compliance pipeline 112 can generate a compliant training dataset based on the compliance metadata 128, which can be used to train a model (e.g., the risk assessment model 120) such that the model complies with the requirements defined by the compliance metadata 128. Compliance metadata 128 can be stored in a compliance metadata repository 134 and can include, for example, metadata indicating features that can or cannot be used in the predictive model, as well as metadata indicating allowed feature values. For example, the compliance metadata 128 can define acceptable values for particular features, such that a model trained using the feature values complies with requirements received from an external entity. Compliance metadata 128 can include feature capping and flooring requirements, imputation requirements, and trends to enforce. As an example, the compliance metadata 128 can include imputation values such that a target entity will not be penalized by the model for lacking a value of a particular feature. The7US2008 30389410 1Attorney Docket No.: 096923-1364025 compliance metadata 128 can be received periodically from an external source, such as an entity or regulating body, and stored in the compliance metadata repository 134.

[0034] Network-attached storage units can include the risk data repository 122 and the compliance metadata repository 134. Network-attached storage units may store a variety of different types of data organized in a variety of different ways and from a variety of different sources. For example, the network-attached storage unit may include storage other than primary storage located within the compliance pipeline sub-system 110 that is directly accessible by processors located therein. In some aspects, the network-attached storage unit may include secondary, tertiary, or auxiliary storage, such as large hard drives, servers, virtual memory, among other types. Storage devices may include portable or non-portable storage devices, optical storage devices, and various other mediums capable of storing and containing data. A machine -readable storage medium or computer-readable storage medium may include a non-transitory medium in which data can be stored and that does not include carrier waves or transitory electronic signals. Examples of a non-transitory medium may include, for example, a magnetic disk or tape, optical storage media such as a compact disk or digital versatile disk, flash memory, memory, or memory devices.

[0035] The risk assessment server 118 can include one or more processing devices that execute program code, such as a risk assessment application 114. The program code is stored on a non-transitory computer-readable medium. The risk assessment application 114 can execute one or more processes to utilize the risk assessment model 120 trained during execution of the compliance pipeline 112 to predict risk indicators based on input predictor variables 124. The risk indicators can be used to protect or allocate computing resources of the risk assessment computing system 130.

[0036] Furthermore, the risk assessment computing system 130 can communicate with various other computing systems, such as client computing systems 104. For example, client computing systems 104 may send risk assessment queries to the risk assessment server 118 for risk assessment or may send signals to the risk assessment server 118 that control or otherwise influence different aspects of the risk assessment computing system 130. The client computing systems 104 may also interact with user computing systems 106 via one or more public data networks 108 to facilitate interactions between users of the user computing systems 106 and interactive computing environments provided by the client computing systems 104.

[0037] Each client computing system 104 may include one or more third-party devices, such as individual servers or groups of servers operating in a distributed manner. A client computing system 104 can include any computing device or group of computing devices8US2008 30389410 1Attorney Docket No.: 096923-1364025 operated by a seller, lender, or other providers of products or services. The client computing system 104 can include one or more server devices. The one or more server devices can include or can otherwise access one or more non-transitory computer-readable media. The client computing system 104 can also execute instructions that provide an interactive computing environment accessible to user computing systems 106. Examples of the interactive computing environment include a mobile application specific to a particular client computing system 104, a web-based application accessible via a mobile device, etc. The executable instructions are stored in one or more non-transitory computer-readable media.

[0038] The client computing system 104 can further include one or more processing devices that are capable of providing the interactive computing environment to perform operations described herein. The interactive computing environment can include executable instructions stored in one or more non-transitory computer-readable media. The instructions providing the interactive computing environment can configure one or more processing devices to perform operations described herein. In some aspects, the executable instructions for the interactive computing environment can include instructions that provide one or more graphical interfaces. The graphical interfaces are used by a user computing system 106 to access various functions of the interactive computing environment. For instance, the interactive computing environment may transmit data to and receive data from a user computing system 106 to shift between different states of the interactive computing environment, where the different states allow one or more electronics transactions between the user computing system 106 and the client computing system 104 to be performed.

[0039] In some examples, a client computing system 104 may have other computing resources associated therewith (not shown in FIG. 1), such as server computers hosting and managing virtual machine instances for providing cloud computing services, server computers hosting and managing online storage resources for users, server computers for providing database services, and others. The interaction between the user computing system 106 and the client computing system 104 may be performed through graphical user interfaces presented by the client computing system 104 to the user computing system 106, or through application programming interface (API) calls or web service calls.

[0040] A user computing system 106 can include any computing device or other communication device operated by an entity, such as a user, an organization, or a company. The user computing system 106 can include one or more computing devices, such as laptops, smartphones, and other personal computing devices. A user computing system 106 can include executable instructions stored in one or more non-transitory computer-readable media. The9US2008 30389410 1Attorney Docket No.: 096923-1364025 user computing system 106 can also include one or more processing devices that are capable of executing program code to perform operations described herein. In various examples, the user computing system 106 can allow a user to access certain online services from a client computing system 104 or other computing resources, to engage in mobile commerce with a client computing system 104, to obtain controlled access to electronic content hosted by the client computing system 104, etc.

[0041] For instance, the user can use the user computing system 106 to engage in an electronic transaction with a client computing system 104 via an interactive computing environment. An electronic transaction between the user computing system 106 and the client computing system 104 can include, for example, the user computing system 106 being used to request online storage resources managed by the client computing system 104, acquire cloud computing resources (e.g., virtual machine instances), and so on. An electronic transaction between the user computing system 106 and the client computing system 104 can also include, for example, querying a set of sensitive or other controlled data, accessing online financial services provided via the interactive computing environment, submitting an online credit card application or other digital application to the client computing system 104 via the interactive computing environment, operating an electronic tool within an interactive computing environment hosted by the client computing system (e.g., a content-modification feature, an application-processing feature, etc.).

[0042] In some aspects, an interactive computing environment implemented through a client computing system 104 can be used to provide access to various online functions. As a simplified example, a website or other interactive computing environment provided by an online resource provider can include electronic functions for requesting computing resources, online storage resources, network resources, database resources, or other types of resources. In another example, a website or other interactive computing environment provided by a financial institution can include electronic functions for obtaining one or more financial services, such as loan application and management tools, credit card application and transaction management workflows, electronic fund transfers, etc. A user computing system 106 can be used to request access to the interactive computing environment provided by the client computing system 104, which can selectively grant or deny access to various electronic functions. Based on the request, the client computing system 104 can collect data associated with the user and communicate with the risk assessment server 118 for risk assessment. Based on the risk indicator predicted by the risk assessment server 118, the client computing system 104 can determine whether to grant the access request of the user computing system 106 to certain features of the interactive10US2008 30389410 1Attorney Docket No.: 096923-1364025 computing environment.

[0043] In a simplified example, the system depicted in FIG. 1 can configure, based on the compliance metadata 128, the risk assessment model 120 and the risk assessment training data 126 used to train the risk assessment model 120 to determine risk indicators, such as credit scores, using predictor variables 124. In additional or alternative examples, the risk assessment model 120 may determine adverse action codes or other explanation codes for the predictor variables 124. A predictor variable 124 can be any variable predictive of risk that is associated with an entity. Any suitable predictor variable that is authorized for use by an appropriate legal or regulatory framework may be used.

[0044] Examples of predictor variables 124 used for predicting the risk associated with an entity accessing online resources include, but are not limited to, variables indicating the demographic characteristics of the entity (e.g., name of the entity, the network or physical address of the company, the identification of the company, the revenue of the company), variables indicative of prior actions or transactions involving the entity (e.g., past requests of online resources submitted by the entity, the amount of online resource currently held by the entity, and so on.), variables indicative of one or more behavioral traits of an entity (e.g., the timeliness of the entity releasing the online resources), etc. Similarly, examples of predictor variables 124 used for predicting the risk associated with an entity accessing services provided by a financial institute include, but are not limited to, indicative of one or more demographic characteristics of an entity (e.g., age, gender, income, etc.), variables indicative of prior actions or transactions involving the entity (e.g., information that can be obtained from credit files or records, financial records, consumer records, or other data about the activities or characteristics of the entity), variables indicative of one or more behavioral traits of an entity, etc.

[0045] Compliant predictor variables can be generated based on the requirements set forth by the compliance metadata 128. For example, for a given target entity, compliance metadata can indicate capping or flooring values, such that outliers do not skew the results of the risk assessment model. Additionally, imputation values can be imputed to particular features with null values, such that a missing value for a feature does not penalize the target entity. Further, the compliance metadata can define and enforce trends based on the values of features in the training data set such that a mean value of the feature can be imputed to any entities that are missing a value for that feature. Accordingly, the compliance metadata 128 ensures fair treatment of a target entity by enforcing certain requirements on the training dataset used to train the risk assessment model 120.

[0046] The predicted risk indicator can be used by the service provider to determine the11US2008 30389410 1Attorney Docket No.: 096923-1364025 risk associated with the entity accessing a service provided by the service provider, thereby granting or denying access by the entity to an interactive computing environment implementing the service. For example, if the service provider determines that the predicted risk indicator is lower than a threshold risk indicator value, then the client computing system 104 associated with the service provider can generate or otherwise provide access permission to the user computing system 106 that requested the access. The access permission can include, for example, cryptographic keys used to generate valid access credentials or decryption keys used to decrypt access credentials. The client computing system 104 associated with the service provider can also allocate resources to the user and provide a dedicated web address for the allocated resources to the user computing system 106, for example, by adding it in the access permission. With the obtained access credentials and / or the dedicated web address, the user computing system 106 can establish a secure network connection to the computing environment hosted by the client computing system 104 and access the resources via invoking API calls, web service calls, HTTP requests, or other proper mechanisms.

[0047] Each communication within the operating environment 100 may occur over one or more data networks, such as a public data network 108, a network 116 such as a private data network, or some combination thereof. A data network may include one or more of a variety of different types of networks, including a wireless network, a wired network, or a combination of a wired and wireless network. Examples of suitable networks include the Internet, a personal area network, a local area network (“LAN”), a wide area network (“WAN”), or a wireless local area network (“WLAN”). A wireless network may include a wireless interface or a combination of wireless interfaces. A wired network may include a wired interface. The wired or wireless networks may be implemented using routers, access points, bridges, gateways, or the like, to connect devices in the data network.

[0048] The number of devices depicted in FIG. 1 is provided for illustrative purposes. Different numbers of devices may be used. For example, while certain devices or systems are shown as single devices in FIG. 1, multiple devices may instead be used to implement these devices or systems. Similarly, devices or systems that are shown as separate, such as the compliance pipeline sub-system 110 and the risk assessment server 118, may be instead implemented in a single device or system.Examples of Operations Involving Machine Learning

[0049] FIG. 2 is a flow chart depicting an example of a process 200 for using a compliance pipeline 112 to generate a risk assessment model 120 that is compliant with one or more requirements defined by the compliance metadata 128. Once trained, the risk assessment model12US2008 30389410 1Attorney Docket No.: 096923-1364025120 can generate risk indicators for a target entity based on predictor variables 124 associated with the target entity. One or more computing devices (e.g., the risk assessment server 118) implement operations depicted in FIG. 2 by executing suitable program code (e.g., the risk assessment application 114). For illustrative purposes, the process 200 is described with reference to certain examples depicted in the figures. Other implementations, however, are possible.

[0050] At block 202, the process 200 involves determining, using a machine learning model trained using a training process, a risk indicator for a target entity from predictor variables associated with the target entity. In some cases, the risk assessment computing system 130 (e.g., the risk assessment server 118) may receive a risk assessment query associated with a particular entity (e.g., the target entity). The risk assessment query may be received from the target entity requesting the risk assessment. In additional or alternative implementations, the risk assessment query may be received from a remote computing device associated with an entity authorized to request risk assessment of the target entity. Once the risk assessment server 118 receives the risk assessment query, the risk assessment server 118 can execute the trained risk assessment model 120 to determine the risk indicator for the target entity.

[0051] The trained risk assessment model 120 can be deployed to a production environment as a step in the compliance pipeline 112. For example, the risk assessment model 120 can be trained on a compliant training data set, evaluated for performance, and subsequently published to a model repository for use in determining risk indicators.

[0052] In some aspects, risk assessment training data 126 can be stored in a risk data repository 122 and can be used to train the risk assessment model 120 to output the risk indicator. The process for generating the compliant risk assessment model 120 and training the risk assessment model 120 is described below in further detail with reference to FIG. 3.

[0053] Once trained, the risk assessment model 120 can be used to determine the risk indicator for the target entity based on predictor variables 124 associated with the target entity. For example, the predictor variables 124 can be used as inputs to the risk assessment model 120. The predictor variables 124 associated with the target entity can be obtained from a predictor variable database configured to store predictor variables 124 associated with various entities. The output of the risk assessment model 120 can include the risk indicator for the target entity based on its current predictor variables.

[0054] For example, a customer can submit an access request to access the interactive computing environment using a user computing system 106. Based on the request, the client computing system 104 can generate and submit a risk assessment query for the customer to the13US2008 30389410 1Attorney Docket No.: 096923-1364025 risk assessment server 118. The risk assessment query can include, for example, an identity of the customer and other information associated with the customer that can be utilized to generate predictor variables.

[0055] At block 204, the process 200 includes transmitting, to a remote computing device, a responsive message comprising at least the risk indicator for use in controlling access of the target entity to one or more computing environments. For example, the risk assessment server 118 can perform a risk assessment based on predictor variables 124 generated for the customer and return a responsive message to the client computing system 104. The responsive message can include at least the risk indicator and explanatory data associated with the risk indicator. The explanatory data can indicate relationships between changes in the risk indicator and changes in at least some of the predictor variables 124 associated with the target entity.

[0056] The risk indicator can correspond to a level of risk associated with the target entity, for example with respect to accessing protecting computing resources. The risk indicator can be used for one or more operations that involve performing an operation with respect to the target entity based on a predicted risk associated with the target entity. In one example, the risk indicator can be utilized to control access to one or more interactive computing environments by the target entity. The risk assessment computing system 130 can communicate with client computing systems 104, which may send risk assessment queries to the risk assessment server 118 to request risk assessment. The client computing systems 104 may be associated with technological providers, such as cloud computing providers, online storage providers, or financial institutions such as banks, credit unions, credit-card companies, insurance companies, or other types of organizations. The client computing systems 104 may be implemented to provide interactive computing environments for customers to access various services offered by these service providers. Customers can use user computing systems 106 to access the interactive computing environments thereby accessing the services provided by these providers.

[0057] At block 206, the process 200 includes receiving an updated model based on updated compliance metadata. As discussed in further detail below, a component of the compliance pipeline 112 can monitor the compliance metadata repository 134 for updates or changes to the compliance metadata 128. Such changes can trigger the compliance pipeline 112 to execute such that an updated model is generated to comply with the requirements of the updated compliance metadata. The updated model can be used to determine the risk indicator for a target entity next time the model is executed in block 202.14US2008 30389410 1Attorney Docket No.: 096923-1364025

[0058] Based on the received risk indicator, the client computing system 104 can determine whether to grant the customer access to the interactive computing environment. If the client computing system 104 determines that the level of risk associated with the customer accessing the interactive computing environment and the associated technical or financial service is too high, the client computing system 104 can deny access by the customer to the interactive computing environment. Conversely, if the client computing system 104 determines that the level of risk associated with the customer is acceptable, e.g., is below a predetermined threshold, the client computing system 104 can grant access to the interactive computing environment by the customer and the customer would be able to utilize the various services provided by the service providers. For example, with the granted access, the customer can utilize the user computing system 106 to access clouding computing resources, online storage resources, web pages or other user interfaces provided by the client computing system 104 to execute applications, store data, query data, submit an online digital application, operate electronic tools, or perform various other operations within the interactive computing environment hosted by the client computing system 104.

[0059] FIG. 3 is a flow chart depicting an example of a process 300 for using the compliance pipeline 112 to generate and train a risk assessment model 120 that is compliant with one or more requirements defined by the compliance metadata 128. As discussed above with reference to FIG. 2, once trained, the risk assessment model 120 can generate risk indicators for a target entity based on predictor variables 124 associated with the target entity. One or more computing devices of the compliance pipeline sub-system 110 implement operations depicted in FIG. 3 by executing suitable program code. For illustrative purposes, the process 300 is described with reference to certain examples depicted in the figures. Other implementations, however, are possible.

[0060] In some implementations the process 300 can be initiated periodically at predetermined intervals. In other implementations, the process 300 can be initiated manually, or can be triggered in response to updates to the compliance metadata 128. For example, the risk assessment computing system 130 can monitor the compliance metadata repository 134 for the receipt of new compliance metadata, deletions of compliance metadata, and / or updates to existing compliance metadata. As such, process 300 can run to ensure that any additions, deletions, or changes in the compliance metadata 128 are captured in the risk assessment model 120.

[0061] At block 302, the process 300 involves receiving compliance metadata and a candidate machine learning model. The compliance metadata can include a set of features and15US2008 30389410 1Attorney Docket No.: 096923-1364025 a usage value associated with each feature. For example, a component of the compliance pipeline 112 can access compliance metadata 128 from the compliance metadata repository 134. In some aspects, the compliance metadata 128 can be received from an external source, such as a database managed by an external entity, and can be updated periodically. In some aspects, a component of the compliance pipeline 112 can receive a training dataset (e.g., risk assessment training data 126), the compliance metadata 128, the risk assessment model 120, and metrics associated with the risk assessment model 120.

[0062] In some aspects, the candidate model can be an existing model or a newly developed model that is not yet deployed in a production environment. The received compliance metadata 128 can define requirements fortraining the candidate model such that either the existing model is updated to comply with the compliance metadata 128 or the newly developed model is trained on a compliant training dataset.

[0063] At block 304, the process 300 involves comparing, for each feature in the set of features, the usage value with a threshold usage value for each feature of the set of features associated with the machine learning model. The usage value can indicate, for example, whether the feature can be used by the machine learning model. In some implementations, the threshold usage value is set through experimentation during development of the machine learning model. In other implementations, the threshold usage value may be predetermined.

[0064] FIG. 13 illustrates an exemplary set of compliance metadata. For each feature, the compliance metadata can include an “exclude” property with a value between 0 and 1 (which can be a usage value) indicating whether the feature should be used in the model. The compliance metadata also can include an expected trend sign indicating whether the feature should be monotonically increasing or decreasing in the risk indicator, an imputation value for a null feature, a capping value, a flooring value, a missing indicator of whether a compliant dummy variable can be calculated and used if the feature value is null, and a reason code associated with the feature. The imputation value, and capping / flooring values will be discussed in further detail below.

[0065] In an example, a variable can be selected from a data set (e.g., a feature such as a credit card balance). The exclude property of the metadata can be observed to determine whether a missing indicator dummy variable can be used for the feature (e.g., the credit card balance). In some examples, a missing indicator dummy variable can be generated to represent valid and null / invalid feature values.

[0066] Returning to FIG. 3, at block 306, the process 300 involves including that feature in a compliant set of training features based on the comparison. For example, a feature can be16US2008 30389410 1Attorney Docket No.: 096923-1364025 included in the compliant set of training features if the usage value is above the threshold usage value associated with the feature. Thus, the set of threshold usage values associated with the set of features can indicate which features should be excluded from and included in the compliant set of features. Accordingly, features can be excluded from a model, based on the compliance metadata, that may skew or otherwise bias the model’s treatment of particular target entities.

[0067] At block 308, the process 300 involves generating a training dataset including the compliant set of training features. In some implementations, one or more components of the compliance pipeline 112 can generate the risk assessment training data 126 based on the compliant set of features. That is, features that had usage values that did not meet the threshold usage values can be removed from the training dataset. The resulting training dataset is a dataset including the compliant set of training features.

[0068] At block 310, the process 300 involves generating an updated machine learning model by training the candidate machine learning model using the training dataset. The candidate model can be trained, for example, by applying the model to the compliant training data set.

[0069] In some implementations, the candidate model can be deployed to a model repository and can be made accessible for use in a production environment. The process 300 can be used to update the deployed model when changes are made to the associated compliance metadata.Example of Compliance Pipeline

[0070] FIG. 4 is an exemplary system 400 for generating a compliant machine learning model for risk assessment. The system 400 can be, for example, the compliance pipeline subsystem 110.

[0071] The system 400 can include a pipeline design sub-system 402. For example, the pipeline design sub-system 402 can receive or generate a pipeline (e.g., compliance pipeline 112). In some aspects, a user can interact with the pipeline design sub-system 402 via a user computing system 106 to build or modify a pipeline, and the output of the pipeline design subsystem 402 can be a pipeline published to a pipeline repository 404. The pipeline repository 404 can be a data repository of risk assessment computing system 130, or can be an external database. A pipeline can be, for example, a set of steps to be executed to construct a predictive model (e.g., risk assessment model 120). The pipeline can be executed automatically on real data at scale to construct the risk assessment model 120. In some examples, the pipeline can be designed according to a set of requirements. Requirements can be, for example, regulatory17US2008 30389410 1Attorney Docket No.: 096923-1364025 requirements for statistical soundness and for fair target entity treatment. Additional requirements can force feature values to adhere to a trend or can impute flooring or capping values to eliminate the risk of outliers skewing the model. Other requirements may be imposed for regulatory or technical reasons.

[0072] The pipeline design sub-system 402 is described in further detail with respect to FIG. 5, which illustrates a pipeline design process 500. Process 500 can be executed by the pipeline design sub-system 402 or by another component of the compliance pipeline subsystem 110. The pipeline design process 500 can be performed in an experimentation phase conducted to define a model pipeline to be deployed for execution, e.g., in a production environment of the risk assessment computing system 130. For example, the pipeline design sub-system 402 can execute the pipeline design process 500 to experiment on a sample of data to test different modeling techniques and packages, establish data management and data treatment processes, compute model targets, and code statistical soundness checks.

[0073] At block 502, a candidate model pipeline with explanations can be received at the pipeline design sub-system 402. In some examples, a model developer can experiment on sample data in a sandboxed environment to establish the pipeline prior to publication to the pipeline repository 404. At block 504, the pipeline design sub-system 402 can execute a series of one or more experiments on a sample of data. For example, the series of one or more experiments can include performance monitoring or evaluation for statistical soundness. In some aspects, the sample of data is a subset of the risk assessment training data 126 that is small enough to execute on a local machine (e.g., on a client computing system 104). Once the pipeline is published or deployed to a production environment, the deployed pipeline will be scaled up to execute on full data (e.g., on the risk assessment training data 126).

[0074] At block 506, the pipeline design sub-system 402 can analyze the pipeline experimentation results . For example, experimental results can be measured against one or more baseline requirements for accuracy, performance, statistical soundness, and the like. A candidate pipeline, for example, can be analyzed to determine whether the pipeline will produce models that meet compliance requirements as defined by the compliance metadata 128. Requirements can be use-case requirements such as predictive strength and accuracy and stability and soundness. The pipeline experimentation results can be analyzed using one or more techniques for data analytics, statistical analysis, or machine learning model evaluation, such as regression testing, integration testing, or A / B testing.

[0075] Based on the analysis at block 506, at block 508, the pipeline design sub-system 402 can determine if the pipeline is approved. A pipeline can be approved for publication, for18US2008 30389410 1Attorney Docket No.: 096923-1364025 example, if execution of the pipeline yields a machine learning model that is compliant with all input compliance requirements. This can be determined by comparing model output with an expected output, as well as by comparing the model performance, stability, and soundness with established threshold values. In some examples, if a pipeline does not yield a compliant machine learning model, the process 500 can return to block 502 to refine the pipeline and perform experimentation and analysis until the process 500 yields a compliant machine learning model.

[0076] If the pipeline is approved at block 508, the process 500 can proceed to block 510 to define a reason code explanation library and methodology. In some implementations, the reason code explanation methodology can be based on SHapley Additive exPlantations (SHAP), individual conditional explanation (ICE), or integrated gradient (IG) techniques. The model explanation methodology can attribute which model inputs affect the output risk indicator and to what degree. At block 510, the pipeline design sub-system 402 can also define pipeline artifacts including pipeline code and required packages. The pipeline artifacts can be used to enable the pipeline (e.g., compliance pipeline 112) to run on the compliance pipeline sub-system 110.

[0077] At block 512, the pipeline, including all pipeline artifacts, can be containerized and registered to be executed at a future time. Prior to publication of the pipeline, at block 514, a security scan is performed over the pipeline artifacts in the container to check for vulnerabilities in the pipeline code. For example, the security scan can be used to detect outdated libraries, to detect an incorrectly configured container, to check for a malicious container image, and the like.

[0078] At block 516, the pipeline design sub-system 402 can determine, based on the results of the security scan, whether the pipeline code has a vulnerability or defect. If the security scan has identified one or more vulnerabilities, the process 500 can return to block 510 to refine the model library (e.g., by updating an outdated library and addressing one or more bugs or compiler errors).

[0079] If no vulnerability is identified by the security scan, the process 500 can proceed to block 518 and publish the pipeline design to the pipeline repository 404. The pipeline repository can be accessible to components of the compliance pipeline sub-system 110 or other components of the risk assessment computing system 130.

[0080] Returning to FIG. 4, the pipeline repository 404 can include pipeline designs that have successfully completed the pipeline design process 500. In some aspects, the pipeline repository 404 can be a code repository such as GitHub. In some aspects, a pipeline can be19US2008 30389410 1Attorney Docket No.: 096923-1364025 published and registered to the pipeline repository 404 using a continuous integration and continuous delivery (CI / CD) process. In other aspects, one or more pipelines can be managed and installed in the pipeline repository 404 manually.

[0081] A particular pipeline of the pipeline repository 404 can be periodically initiated based on a trigger 406. The trigger 406 can be a periodic trigger such that the pipeline is kicked off at a predetermined time interval (e.g., daily, weekly, monthly, etc.). In other aspects, the trigger 406 can be a request for a risk indicator from the client computing system 104. In yet another aspect, the trigger 406 can be an event, such as a change to a model version or to the compliance metadata 128.

[0082] In some implementations, the compliance pipeline 112 can include a data management component 408. The data management component 408 is described in further detail with respect to FIG. 6, which illustrates a data management process 600. The data management process 600 can be executed, for example, by the compliance pipeline sub-system 110 or by another component of the risk assessment computing system 130.

[0083] The data management process 600 can be used to assemble a dataset for model training. For example, the data management process 600 can be used to assemble the risk assessment training data 126. As an input, the data management process 600 can receive feature data, e.g., a set of features, used by the model to compute a target variable, e.g., the risk indicator.

[0084] In some aspects, the data management process 600 can include a step of defining a target variable. The target variable can be determined based on feature data from a data warehouse 410, shown in FIG. 4. In order to form the training dataset a target variable needs to be defined. The target variable can be defined, in some aspects, based on data associated with “matched” and “unmatched” inquiries. In some examples, an inquiry can refer to a request, by an entity, for a risk indicator associated with the target entity. The risk indicator can be used by the entity, for example, to grant the target entity access to a resource or service of the entity, such as an installment loan. A matched inquiry can refer to an instance in which an inquiry is made for a target entity, and the target entity subsequently enters into a transaction to access a resource or service of the entity. As an example, for illustrative purposes, a credit inquiry can be made by an entity for a credit score of a target entity. If, subsequently, the target entity enters into a transaction, such as an installment loan, the inquiry made by the entity is considered a matched inquiry associated with the target entity. If the credit inquiry is made and there is no record of a transaction of the target entity, the inquiry is considered an unmatched inquiry associated with the target entity.20US2008 30389410 1Attorney Docket No.: 096923-1364025

[0085] In another example, a computing resource can request authentication credentials with which to access a secure database. A matched inquiry can be generated when, subsequently, the computing resource uses the authentication credentials to successfully access the secure database. An unmatched inquiry can be generated if the authentication credentials are generated, but there is no record that the computing resource attempted to access the secure database using the authentication credentials.

[0086] In one implementation, at block 602, the data management process can include identifying and monitoring matched inquiries over a performance period. For example, the data management component 408 can monitor one or more databases to identify, for a target entity, transactions associated with a previous inquiry and to correlate the inquiry with the transaction. In some aspects, the risk assessment computing system 130 can monitor records associated with booked inquiry transactions over a performance period defined by a start date and / or time and an end date and / or time. The performance can indicate whether or to what extent the target entity satisfies the terms of the transaction over the performance period.

[0087] At block 604, based on the observed performance of the matched inquiry transaction, the data management component 408 can extract the target variable. In some aspects, a target variable can measure the performance of the target entity with respect to the transaction over the performance period.

[0088] In some aspects, the data management process 600 can, at block 606, identify unmatched inquiries. As an example, an unmatched inquiry can be associated with a target entity that was approved for, but declined a transaction, or a target entity that was denied a transaction. Identifying unmatched inquiries can include analyzing inquiry and transaction records and determining a set of inquiries for which no corresponding transaction occurred.

[0089] At block 608, the data management process 600 can include identifying a proxy performance. For example, unlike matched inquiry transactions, unmatched inquiries cannot be monitored over a performance period. Accordingly, the risk assessment computing system 130 can determine a proxy transaction associated with an unmatched inquiry. A proxy transaction enables the data management component 408 to approximate the performance over the performance period of a transaction of the target entity based on the unmatched inquiry. Accordingly, target entities not associated with a history of matched inquiry transactions can be accounted for by the data management component 408 and represented in the risk assessment model 120.

[0090] In some aspects, a proxy transaction can be identified by correlating an inquiry and a transaction that are outside the window for a matched inquiry transaction. As an example, a21US2008 30389410 1Attorney Docket No.: 096923-1364025 matched inquiry transaction can be a transaction that takes place within a certain time period (one week, two months, etc.) of an inquiry. The proxy transaction can be a transaction of the target entity that falls outside of the time period for a matched inquiry transaction. Thus, the proxy transaction can approximate the performance of the target entity if a transaction had occurred within the matched inquiry time period.

[0091] In another aspect, a proxy transaction can be a transaction that is not associated with an inquiry, but that has similar characteristics to a transaction that would have occurred in response to the inquiry. Thus, the performance of the entity with respect to the proxy transaction can be used to approximate the performance of the target entity with respect to the unmatched inquiry. Exemplary characteristics of a transaction can include a duration, an amount of the transaction, a payment frequency, an interest rate or interest type, and the like.

[0092] Thus, at block 608, a target variable associated with the proxy transaction can be used as the target variable of the unmatched inquiry to approximate the target entity’s performance had a transaction occurred.

[0093] In some aspects, at block 610, the data management process 600 can include determining a target variable based on a reject inference model. A reject inference model can refer to a pre-established model that may be external to the risk assessment computing system 130 and whose output can be used to classify the target entity. For example, the model can predict risk associated with a target entity with a score or a classification on a scale from low risk to high risk.

[0094] At block 612, the data management component 408 can apply a model to classify the target entity based on the target variable output at block 608 or block 610. For example, the data management component 408 can apply one or more machine learning techniques, such as parceling or fuzzy augmentation to classify the target entity.

[0095] In some embodiments, at block 614, the data management component 408 can extract features for the determined or inferred target variable and output a training dataset. The features can be extracted, for example, from data associated with a known matched population (e.g., based on the output of block 604) and an inferred unknown population (e.g., based on the output of block 612). The output training dataset can include the training data with the features appended. In some aspects, the training dataset can be stored in a database, e.g., the risk data repository 122. In other aspects, the training dataset can be stored in a feature store that includes a layer for feature extraction.

[0096] Returning back to FIG. 4, the compliance pipeline 112 can include a model training component 412. The model training component 412 is described in further detail with respect22US2008 30389410 1Attorney Docket No.: 096923-1364025 to FIG. 7, which illustrates a model training process 700. The model training process 700 can be executed, for example, by the model training component 412 or by another component of the risk assessment computing system 130.

[0097] In some aspects, the model training component 412 can receive compliance metadata from a compliance metadata repository 414, training data from the data management component 408 or a risk data repository 122, and a previous model and model metrics from a model repository 416. The model repository 416 can be a data repository configured to store one or more models that have been approved by the pipeline design sub-system 402.

[0098] At block 702, the model training process 700 can load compliance metadata from the compliance metadata repository 410. The compliance metadata can include, for example, information on which features can be used. Further compliance metadata can include feature capping and flooring requirements, imputation requirements, and trends to enforce.

[0099] The compliance metadata can include a usage value for each feature. At block 704, the model training process 700 can include deciding whether to use a feature in a model. For example, the model training component 412 can compare the usage value of the feature with a threshold usage value. In some aspects, the threshold usage value can be set during experimentation (e.g., as part of the process 500 executed by the pipeline design sub-system 402). The threshold usage value can be based, in part, on whether the model use case in conservative in its risk assessment of a target entity. For example, in a conservative use case, the threshold usage value for features having little effect on the target variable may be high, such that only those features having a large effect on the model are used. In other examples, low threshold usage values for a set of features ensure that many of the features are used in training the model.

[0100] As an example, FIG. 13 illustrates exemplary compliance metadata which can include exclusion, or usage, values that determine whether a feature is to be included in a training dataset. In some examples, the exclusion or usage value can range from 0 to 1. If, for example, if the usage value of attr_2 is greater than the usage value threshold of 0.5, attr_2 can be excluded from the training dataset.

[0101] The output of block 704 can be a training dataset including a set of compliant training features. For example, for each feature, the model training component 412 can compare the usage value of the feature with the threshold usage value associated with that feature (received as compliance metadata). If the usage value of the feature is greater than the threshold usage value, the feature can be included in the compliant set of features. In another example, if the usage value of the feature is lower than the threshold usage value of the feature, then the23US2008 30389410 1Attorney Docket No.: 096923-1364025 feature can be included in the compliant set of features. In some implementations, the feature can be included in the compliant set of features if the usage value of the feature is greater than or equal to the threshold usage value. Accordingly, data associated with features not included in the compliant set of features are removed from the training dataset.

[0102] In some aspects, the model training process 700 can include block 706 for determining missing value indicators. For example, for one or more features of the compliant set of features, the model training component 412 can create a missing value indicator. For example, the missing value indicator can have a value of 1 for missing and / or invalid values, and a value of 0 for valid values. The output at block 706 can be a training dataset, including data associated with the compliant set of features, with the missing value indicator features appended. A determination of whether a feature value is invalid can be based on whether the feature value is equal to a specified value or within specified bounds included in the compliance metadata 128. Missing values can be, for example, where a particular feature value is null.

[0103] As shown in FIG. 13, attr_l has a Missing Indicator value of 1. A Missing Indicator value of 1 may indicate that the feature can be represented by a missing indicator dummy variable in the model even if the feature value is null or invalid. In another example, the Missing Indicator for attr_2 is 0. . A Missing Indicator of 0 may indicate that a missing indicator dummy variable cannot be created for that feature. In some aspects, the model training process 700 can include a block 708 for applying feature capping and flooring values to generate compliant values for each feature. As previously described, the compliance metadata can include rules for capping / flooring features and for applying expected trends to features. A capping value can describe a maximum allowable value for the feature and a flooring value can describe a minimum allowable value for a feature. Accordingly, the model training component 412 can remove data associated with features having a value above or below a capping or flooring value, respectively.

[0104] As an example, in FIG. 13, attr w can have a Capping Value of 100 and a Flooring Value of 10. Thus, when attr w has a value outside that range, that feature can be excluded or can have a value imputed to it that is within the allowable range defined by the capping and flooring values. In some aspects, the compliance metadata can include an expected trend for a feature. In such an example, the risk assessment computing system 130 can iterate over ordered unique values or order statistics computed from the feature to identify capping and flooring values that produce an observed trend that agrees with the expected trend. For example, the capping or flooring values can be data driven such that the respective capping and flooring values are determined based on an analysis of the training dataset.24US2008 30389410 1Attorney Docket No.: 096923-1364025

[0105] In some aspects, the compliance metadata may not include rules for a feature. In such an example, data-driven capping and / or flooring can be derived from order statistics computed on that feature from the training dataset. For example, data-driven capping and / or flooring values can be set at a percentile or standard deviation based on a distribution of the feature values in the training dataset. In one example, the capping and flooring values can be set such that a lower 5% and upper 95% of the feature values are excluded to avoid undue influence of outliers on the model training.

[0106] The model training process 700 can further include a block 710 for compliance and data-driven imputation. The compliance metadata can include imputation values for one or more features. The model training component 412 can attempt to apply compliant imputation per feature to any missing or invalid values based on specified imputation values in the compliance metadata. In some examples, invalid values can represent coded information about why a value is missing. In this case, the compliance metadata can specify different imputation values based on the coded invalid value. For example, the compliance metadata can map a coded invalid value to a particular imputation value.

[0107] FIG. 13 illustrates imputation values for the listed attributes. For example, Imputation Null can indicate a value to assign to an attribute when the attribute value is null. In other examples, the compliance metadata can include imputation values that map to various reason codes such that if an attribute’s value is invalid for a particular reason, the imputation value associated with that reason code is assigned to that attribute. A specified imputation value can be a valid value or a treatment option. For example, a specified imputation value can indicate that a missing or invalid value should be replaced with the specified valid value. In some aspects, the specified imputation value can be a treatment option. The treatment option can be, for example, “min” or “max.” “Min” can indicate that the missing or invalid values should be replaced with the minimum observed value for the feature in the training dataset. “Max” can indicate that the missing or invalid value should be replaced with the maximum observed value for the feature in the training dataset.

[0108] In some aspects, the compliance metadata may not include imputation values for a particular feature. In such examples, the model training component 412 may perform data driven imputation. For example, invalid values can be mapped to a valid value that has a certain target rate. A target rate can indicate, for example, a value that appears a particular number of times in the training dataset.

[0109] The output at block 710 is a compliant dataset ready for model training that contains allowable variables with compliant data according to capping / flooring and imputation rules.25US2008 30389410 1Attorney Docket No.: 096923-1364025

[0110] The model training process 700 can include a block 712 for checking the model repository 416 for a stable model. This can occur in sequence or in parallel with blocks 702 through 710 of model training process 700. At block 712, the model training component 412 can fetch a previously trained version of the model. For example, the previously trained version of the model can be a model that was generated by the pipeline design sub-system 402 illustrated in FIG. 4 and deployed in a production environment.

[0111] If there is an existing version of the model in the model repository 416, The model training process 700 can proceed to block 714 in which the parameters from the existing version may be used as a starting point for training the new version of the model. For example, the model can be initiated at the parameters from the existing, published version. Otherwise, at block 716, initial parameters for the new model may be defined randomly. The output of this component and process are initial parameters to be tuned during model training at block 718.

[0112] At block 718, the model training component 412 can execute a model training algorithm with parameter restriction. The model training component 412 can apply a numerical optimization algorithm to tune the parameters (e.g., the randomly defined parameters, or the parameters of the existing model) on the data while enforcing any trends defined by the compliance metadata. For example, for a particular feature, the compliance metadata can indicate that a positive trend must exist in the model. Accordingly, the model training algorithm can force positive monotonicity in the modeled trend. Alternatively, the compliance metadata can specify that a negative trend must exist for a certain feature in the model. In this case, the model training algorithm can force negative monotonicity in the modeled trend. If no trend is specified in the compliance metadata for a particular feature, then the modeled trend can be driven by the observed data in the training dataset. In some aspects, for augmented features appended with a missing value indicator (e.g., at block 706), the model training algorithm can determine a compliant trend from the imputation value and trend defined by the compliance metadata. As an example, if the imputation value is “max”, the trend to be enforced on the missing value indicator is the same as the trend for that feature in the compliance metadata. In another example, if the imputation value is “min”, the trend to be enforced on the missing value indicator is the opposite as the trend for that feature in the compliance metadata. If no value is specified for imputation or trend, then no trend is enforced on the missing value indicator during training. The output at block 718 is a compliant candidate model.

[0113] In some aspects, the model training process 700 can optionally include a block 720 for model refinement. For example, at block 720, the model training component 412 can perform additional statistical refinement on the candidate model generated at block 718. For26US2008 30389410 1Attorney Docket No.: 096923-1364025 example, multi -collinearity or statistical significance / information gain tests may be performed. Features that exhibit high multi-collinearity or low statistical significance / information gain may be removed from the candidate model and retrained.

[0114] In another aspect, the model training process 700 can optionally include a block 722 for calibration alignment. As an example, calibration alignment can include multiplying a probability p of the risk indicator score by 1000 and rounding to the nearest integer. Another example of calibration alignment can be a formula that aligns to a log-odds scale where the good rate of the target variable doubles or halves as the risk indicator goes up or down, respectively, by a fixed amount. For example, the log-odds double by going up 50 points or halve by going down 50 points, on a 0 to 1000 scale.

[0115] Once model training, refinement, and calibration are complete, the model training process 700 can include a block 724 for computing a compliant baseline record. The baseline can be used downstream to produce model explanations (e.g., reason codes). The baseline can be computed automatically from the compliance metadata by analyzing the specified imputation values and trends. The baseline value per feature can be determined based on the information of Table 1, shown below.Table 1

[0116] For example, when invalid values are imputed to “max” and a positive trend is enforced, then the invalid value will receive a score greater than or equal to the largest valid value. The score received by the invalid value will be equal to the largest valid value when missing value indicators are not used and the score received by the invalid value will be greater than the largest valid value when missing value indicators are used. If a trend is not specified, the baseline may be taken as the observed feature value that produces the maximum score. The output of block 724 is a feature baseline.

[0117] Finally, at block 726, the process 700 can include receiving the candidate compliant model, training dataset, and baseline to produce performance metrics for testing (e.g., for A / B testing). A statistical analysis can be performed over the candidate compliant model to capture performance metrics over the training dataset. Performance metrics may include coverage,27US2008 30389410 1Attorney Docket No.: 096923-1364025 measures of statistical separation (KS, Gini), accuracy, capture rates, etc. The candidate model with baseline and statistical metrics are produced as final outputs of the process 700.

[0118] Returning back to FIG. 4, the compliance pipeline 112 can include a model check component 418 configured to execute performance checks based on the trained candidate model, model metrics, and data metrics. The model check component 418 can validate if the candidate model is in compliance with the compliance metadata and checks the statistical soundness of the candidate model and data using historic and out of sample data.

[0119] FIG. 8 illustrates a model check process 800 that can be executed by the model check component 418 or by another component of the risk assessment computing system 130.

[0120] In some aspects, the model check process 800 can include three sub-processes: compliance validation (blocks 802 and 804); stability validation (blocks 806 through 810); and performance validation (block 812). Compliance validation checks that observed trends on out- of-time (GOT) datasets are stable and match expected trends. Performance validation compares the previous model development metrics against the current model development metrics to ensure the current model performs at an acceptable level benchmarked against the previous version. Stability validation benchmarks both the previous model and current model on an GOT dataset to perform stability testing, such as A / B testing.

[0121] In order to perform the validations, the model check process 800 receives a candidate model output by the model training component 412. In some examples, inputs can include: a candidate model to be registered (e.g., output by model training component 412); metrics from the training dataset set and candidate model (from model training component 412); GOT samples from the data warehouse 410; if there is one, a previous version of the candidate model from the model repository 416; and compliance metadata from the compliance metadata repository 414.

[0122] For the compliance validation sub-process of the model check process 800, block 802 can include computing observed trends based on an GOT sample. For example, the model check component 418 can compute the observed trend in the GOT sample between the target variable and each feature. The observed trend can be determined by correlation analysis, univariate modeling, or exploratory data analysis using binning.

[0123] At block 804, the compliance validation sub-process can include comparing the observed trends with the trends defined by the compliance metadata. For example, the model check component 418 can compare each observed trend against the expected trend specified in the compliance metadata for each feature of the candidate model. Compliance with the trend can be determined, for example, based on a measure of similarity of the observed and expected28US2008 30389410 1Attorney Docket No.: 096923-1364025 trends. In some aspects, if the observed trend has below a threshold similarity with the expected trend, the candidate model does not satisfy compliance validation.

[0124] A stability validation sub-process, can include performing A / B testing to ensure candidate model stability on the OOT sample exceeds the previous version of the model. The stability validation sub-process can include a block 806 for computing metrics on the previous model for an OOT sample. For example, the model check component 418 can receive the previous model from the model repository 416 and an OOT data sample. The model check component 418 can score the OOT sample using the previous model and compute statistical performance metrics such as a Kolmogorov-Smirnov (K-S) statistic, a Gini coefficient, accuracy, capture rates, etc.

[0125] At block 808, the model check component 418 can receive the candidate model from model training component 412 and the same OOT sample. The model check component 418 determines a score for the OOT sample using the candidate model and computes the same statistical performance metrics as those determined for the previous version of the model at block 806.

[0126] At block 810, the stability validation sub-process can include comparing the previous model metrics with the candidate model metrics. For example, metrics from the training dataset and candidate model are compared against metrics obtained from the previous version of the training dataset and model. Comparing the metrics can include comparing metrics per feature in the new training dataset versus the previous training dataset. In some aspects, comparing the metrics can also include comparing previous model metrics on the previous training dataset to candidate model metrics on the new training dataset. Block 810 can further include A / B testing on metrics over the OOT sample from the previous model and candidate model.

[0127] In some aspects, a candidate model can satisfy the performance and stability validation sub-process if the metrics over the OOT sample from the previous model and candidate model are within a threshold amount of similarity. For example, the model check component 418 can determine, for each metric, a difference between the metric from the previous model and the metric of the candidate model. If the difference is greater than a predetermined threshold, the candidate model may not satisfy the stability validation sub-process.

[0128] A performance validation sub-process can include block 812. At block 812, the model check component 418 can receive metrics associated with the previous model and metrics associated with the candidate model determined by the model training component 412. The model check component 418 can compare the received metrics to determine a delta29US2008 30389410 1Attorney Docket No.: 096923-1364025 between each metric associated with the candidate model and each metric associated with the previous model. If any metric has changed more than a pre-defined threshold or falls below another pre-defined threshold, an alert flag can be set by the model check component 418.

[0129] At block 814, the model check process 800 can include validating the candidate model. The candidate model can be validated, for example, if the three validations (compliance, performance, and stability) are cleared by the candidate model. If the candidate model fails one or more of the validations, the model check component 418 can trigger an alerting system 420, shown in FIG. 4.

[0130] If the candidate model successfully passes the three validation sub-processes, the candidate model can be marked as “approved” and can proceed to deployment. As part of the deployment of the approved model, the risk assessment computing system 130 can execute a register model component 422. The register model component 422 can publish the approved version of the model to the model repository 416. The model repository 416 can store the approved version of the model, as well as versioning information, model metadata, model definition or serving code, and model and development metrics.

[0131] The model deployment component 424 of the system 400 can automatically deploy the approved model to a serving system to process online transactions or batch jobs. For example, the approved model can be deployed to the risk assessment computing system 130 such that it is accessible for use by client computing systems 104 . When generating a risk indicator at the request of a client computing system 104 or a user computing system 106, the risk assessment application 114 can retrieve the risk assessment model 120 from the model repository 416 and use this approved and compliant model to generate the risk indicator for a target entity.

[0132] In some aspects, model deployment component 424 can create a model serving endpoint, create a model container package that includes the model definition or serving code along with required libraries and packages, and install the model container at the endpoint. Every approved version of a model may be deployed and version controlled. The version of the model to be used in a particular use case or in response to a particular request may be defined in the request itself. In other aspects, the most recent version of a model may be selected.

[0133] In some aspects, the system 400 can include a model serving component 426 to receive and execute scoring requests. A scoring request can be, for example, a request for a risk indicator associated with a target entity. The model serving component 426 can receive a data record associated with a target entity to be scored by the approved model. In an example,30US2008 30389410 1Attorney Docket No.: 096923-1364025 the risk assessment application 114 can execute on the risk assessment model 120 in response to a request for a risk indicator. The risk assessment application 114 can receive and execute the request and output a risk indicator, health status, reject code, score and attributes, and / or model explanations (e.g., reason codes).

[0134] In some aspects, the system 400 can include a logging sub-system 428 to record scoring transaction results, as well as datetime stamps. For example, in some implementations, the scoring requests can be fulfilled and logged using middleware such as PubSub such that results of the scoring requests are published by the logging sub-system 428 and are accessible to subscribers having permissions to access the scoring results. Accordingly, permissioned subscribers can stream the fulfilled scoring results.

[0135] The system 400 can include executing a population stability monitoring sub-system 430. The population stability monitoring sub-system 430 can have access to datetime stamped fulfilled requests on the logging sub-system 428. For example, the population stability monitoring sub-system 430 can be a subscriber to the PubSub fulfilled scoring request. The population stability monitoring sub-system 430 can receive or monitor the fulfilled scoring and attribute requests and compare these requests to historical metrics. If there is a change in the distributions of the scores (e.g., risk indicators) or attribute or if there is a change in distributions of the scores that is above a pre-determined threshold, the population stability monitoring sub-system 430 can trigger a new run of the entire pipeline to create a new version of the model or trigger an alert to the alerting system 420. The population stability monitoring sub-system 430 is described in further detail with reference to FIG. 9.

[0136] FIG. 9 illustrates a population stability monitoring process 900 that can be executed, for example, by the population stability monitoring sub-system 430. The population stability monitoring subsystem 430 can provide, by executing the population stability monitoring process 900, real-time monitoring of the distribution of fulfilled scoring requests against an expected distribution of scoring requests.

[0137] At block 902, the population stability monitoring sub-system 430 receives performance metrics and statistics from the training dataset. The population stability monitoring sub-system 430 can compute observed score distributions, such as the distribution of expected volumes per score range. At block 904, the population stability monitoring subsystem 430 can also receive feature data and can compute observed feature distributions. The real-time observed feature and score data can be received, for example, from the logging subsystem 428.31US2008 30389410 1Attorney Docket No.: 096923-1364025

[0138] At block 906, the population stability monitoring sub-system 430 can analyze the real-time metrics and distribution changes. For example, the observed score and feature distributions for the model can be compared to the expected score and feature distributions storing with the model in the model repository 426. If the difference between the observed and expected distributions is larger than a pre-defined threshold, then an alert is triggered in the alerting system 420. In some aspects, the alert can trigger the pipeline to be re-executed to adjust the model to reflect that the scoring population may have changed. In some implementations, the population stability monitoring sub-system 430 can run continuously to dynamically detect any changes in the score or feature distributions that indicate a need to adjust the model. In other implementations, the population stability monitoring sub-system 430 can run periodically at predetermined intervals or can be initiated manually.

[0139] Returning to FIG. 4, system 400 can include a validate compliance sub-system 432 that can run periodically to monitor for changes to the compliance metadata. The validate compliance sub-system 432 can receive the most recent compliance metadata from the compliance metadata repository 414 and the latest approved version of the model from the model repository 416. The validate compliance sub-system 432 determines whether any trends or missing value imputation values have changed in the compliance metadata that affect the features in the model. If a change in the compliance metadata is detected, an alert will be triggered (e.g., to the alerting system 420), signaling that the pipeline may need to be reconfigured in the pipeline design sub-system 402. For example, the validate compliance subsystem 432 can run periodically or continuously to identify a change in compliance metadata and determine if a registered model in the model repository 416 is affected by the change to the compliance metadata. If a registered model is affected by change the alerting system 420 will be triggered.

[0140] In some aspects, an end user of a deployed model from the model repository 416 can choose a version of the model to use for a scoring request or a version can be automatically chosen by, for example, the risk assessment application 114 based on information received in a scoring request. As the pipeline (e.g., compliance pipeline 112) runs, new versions of the model are deployed periodically. The end user may desire to switch to a new version automatically or make the decision depending on the particular use case of the end-user. When an end user submits a request to the model serving module 426, the end user can specify, in the scoring request, a version of the model to use for the score determination . If no version is specified, the model serving component 426 can use the most recently version of the model.32US2008 30389410 1Attorney Docket No.: 096923-1364025Example of a Compliance Scorecard

[0141] As described above, compliance metadata can be stored in a compliance metadata repository and used (e.g., by one or more components of the compliance pipeline sub-system 110) to determine if a model is compliant with requirements defined by the compliance metadata or to generate a model that is compliant with the requirements defined by the compliance metadata. In some aspects, the compliance metadata can be generated based on a compliance scorecard.

[0142] FIG. 10 is an illustration of an exemplary graphical user interface (GUI) for generating a compliance scorecard 1000. The GUI displaying the compliance scorecard 1000 can be displayed on a user device (e.g., client computing device 104). The compliance scorecard 1000 can be used to generate compliance metadata, such as a score, or usage value, for each feature of a model.

[0143] The compliance scorecard 1000 can include, for example, an attribute lookup column 1002, which displays a lookup code for each listed attribute associated with a model (e.g., a model stored in the model repository 416). The compliance scorecard 1000 can also include a number of columns 1004 configured to receive input data. Each column 1004 can be associated with a score parameter such as: causality, controllability, attainability, comprehensibility, whether the attribute is behavioral, proxy, reliability, and whether the attribute is contextually sensible.

[0144] In some aspects, via the compliance scorecard 1000 displayed by the GUI, a user can select (e.g., from a drop-down menu 1006) a value for each score parameter. As an example, each drop-down menu can include a selectable list of possible scores. In some implementations, the parameter scores can be integer values ranging from 0 to 5. In other aspects, the score parameter for each attribute can be input into a text field. In other embodiments, one or more components of the compliance pipeline sub-system 110 can determine and populate values for each score parameter.

[0145] The compliance scorecard 1000 can be configured to capture a set of score parameters for each attribute of a model. The compliance scorecard 1000 can be associated with a standardized scoring method. Possible score parameters and the explanations associated with each possible score on a scale from 0 to 5 are described below:Causal:• 0 to 1: Weak association with the target variable. A change in this attribute may correspond to a change in the target variable, but a change in the target variable will not33US2008 30389410 1Attorney Docket No.: 096923-1364025(or will rarely be) reflected by this attribute. The association is correlational in one direction.• 2 to 3: Moderate association with the target variable. A change in this attribute will correspond to a change in the target variable, but a change in the target variable may not correspond to a change in this attribute. The association is primarily correlational in one direction.• 4 to 5: Strong association with the target variable. A change in this attribute will correspond to a change in the target variable, and a change in the target variable will result in a change in this attribute. The association is bidirectional.Controllable:• 0 to 1: The value of the attribute is largely or entirely out of the target entity’s control. There is little or nothing the target entity can do to alter the future value of the attribute .• 2 to 3: The value of the attribute is due to actions taken (or not taken) by the target entity, although the actions may not be entirely discretionary. Actions taken by the target entity today will eventually be reflected by the value of the attribute in the future.• 4 to 5: The value of the attribute is due to actions taken (or not taken) by the target entity that were entirely self-directional, voluntary, and discretionary. Moreover, the target entity can perform actions today that will favorably affect the value of the attribute in the future.Attainable:• O to 1: A relatively “good” value of the attribute may not be attainable in terms of time and effort by every target entity. Attainability varies significantly with respect to a status (e.g., a socioeconomic status) of the target entity.• 2 to 3: A relatively “good” value of the attribute is attainable, in terms of time and effort, to any target entity willing to take steps to improve the value of the attribute. The requisite time and effort can vary with respect to a target entity’s status (e.g., socioeconomic status).• 4 to 5: A relatively “good” value is attainable with relatively low time and / or low effort invested by any target entity. Attainability does not vary with respect to a status of the target entity.Comprehensible:• O to 1: The attribute does not map straightforwardly to reasons that are comprehensible by a user. It is not possible to explain what the target entity could do differently to achieve a different outcome. Counterfactual reasoning is impossible.34US2008 30389410 1Attorney Docket No.: 096923-1364025• 2 to 3: The attribute maps straightforwardly to reasons that are comprehensible to an expert user (e.g., a data scientist), but that are difficult for an average user to understand. The average user may have difficulty determining what a target entity could do differently to achieve a different outcome. Counterfactual reasoning is difficult.• 4 to 5: The attribute maps straightforwardly to reasons understood by any user. The average user or target entity can easily understand what actions can be taken or could have been taken to achieve a different outcome. The explanation facilitates counterfactual reasoning.Behavioral:• O to 1: The attribute is largely a reflection of the resources available to the target entity (e.g., what resources the target entity has access to).• 2 to 3: The attribute captures behavioral characteristics of the target entity moreso than its available resources. To the extent that the attribute can be influenced by a target entity’s resources, those resources are under the sole discretion of the target entity (as opposed to the target entity’s broader network).• 4 to 5: The attribute captures behavioral characteristics of the target entity. The attribute is insensitive to the resources of the target entity.Proxy:• 0 to 1: The attribute is completely uncorrelated with a demographic characteristic of the target entity.• 2 to 3: The attribute is somewhat correlated with a demographic characteristic of the target entity.• 4 to 5: The attribute is significantly correlated with a demographic characteristic of the target entity.High Fidelitv / Reliable:• O to 1: The attribute covers little of the population of target entities that it should cover. For example, the attribute field frequently has null / treated-as-default values for entities in the target segment. Moreover, the reported attribute value can be inaccurate and / or inconsistently reported or out of date and the quality may vary based on data provenance.• 2 to 3: The attribute covers much of the population of target entities that it should cover. For example, the attribute field can have some null / treated-as-default values for entities in the target segment. Moreover, the reported value is decently accurate and35US2008 30389410 1Attorney Docket No.: 096923-1364025 consistently reported. Data quality is reasonably consistent regardless of data provenance.• 4 to 5: The attribute covers most or all of the population of target entities that it should cover. For example, the attribute field does not have null / treated-as-default values for entities in the target segment. Moreover, the reported value is accurate and consistently reported regardless of the data provenance.Contextually Sensible:• 0 to 1: The attribute is not an obvious predictor of the target variable (to those with reasonable domain knowledge). The attribute is entirely ad hoc and data-driven. The associated logic(s) are difficult to enumerate and articulate and the logic(s) are inconsistent and divergent.• 2 to 3: The attribute may not be a priori or intuitively obvious (to those with reasonable domain knowledge), but it may be a logical predictor of the target variable in hindsight. The associated logic(s) are relatively straightforward to enumerate and articulate, and the logic(s) mostly cohere.• 4 to 5: The attribute is an obvious, a priori choice to use when modeling a target variable (to those with reasonable domain knowledge). The associated logic(s) are easy to enumerate and articulate, and the logic(s) are consistent and convergent.

[0146] The compliance scorecard 100 can receive scores based on a rubric, such as that described above. The input can be received by the client computing system 104 and transmitted to the risk assessment computing system 130. The risk assessment computing system 130 can determine a score for each feature based on the associated score parameter values. In some aspects, the score can be an average of the score parameter values. In other aspects, the score can be weighted average of the score parameter values, or can be generated using another function.

[0147] The score associated with each attribute of a model can be stored as compliance metadata associated with the model in the compliance metadata repository 134. For example, for a particular feature, the score can be used as a threshold usage value (e.g., the “Exclude” column shown in FIG. 13). The model training component 412 can compare the threshold usage value, based on the score, to the attribute usage value associated with a candidate model to determine whether the attribute is used according to compliance requirements associated with the candidate model. For example, if the threshold usage value is greater than the attribute36US2008 30389410 1Attorney Docket No.: 096923-1364025 usage value, the attribute can be excluded from a set of compliant attributes used to generate a training dataset on which to train the candidate model.

[0148] FIG. 11 is an illustration of an exemplary GUI 1100 displaying compliance metadata associated with a set of attributes of a model. In some aspects, the compliance scorecard 1000 can be combined with GUI 1100 such that the compliance scorecard is displayed with the additional attribute data shown in GUI 1100.

[0149] In one implementation, the GUI 1100 can, for each attribute associated with a model, display the attribute lookup, an attribute concept which may be a description of the attribute, a number of attributes based on the attribute concept, attribute logic(s), attribute sign, and attribute score based on the score parameter values received via the compliance scorecard 1000.

[0150] In some aspects, the GUI 1100 is interactive to enable a user to explore the attributes of a particular model registered in the model repository 416. For example, each model can be stored with a set of attribute lookup codes that map to particular attributes in the compliance metadata repository 414.Example of Computing System for Machine-Learning Operations

[0151] Any suitable computing system or group of computing systems can be used to perform the operations for the machine -learning operations described herein. For example, FIG. 12 is a block diagram depicting an example of a computing device 1200, which can be used to implement the risk assessment server 118 or the model training server 110. The computing device 1200 can include various devices for communicating with other devices in the operating environment 100, as described with respect to FIG. 1. The computing device 1200 can include various devices for performing one or more transformation operations described above with respect to FIGS. 1-9.

[0152] The computing device 1200 can include a processor 1202 that is communicatively coupled to a memory 1204. The processor 1202 executes computer-executable program code stored in the memory 1204, accesses information stored in the memory 1204, or both. Program code may include machine -executable instructions that may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statements. A code segment may be coupled to another code segment or a hardware circuit by passing or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc. may be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, among others.37US2008 30389410 1Attorney Docket No.: 096923-1364025

[0153] Examples of a processor 1202 include a microprocessor, an application-specific integrated circuit, a field-programmable gate array, or any other suitable processing device. The processor 1202 can include any number of processing devices, including one. The processor 1202 can include or communicate with a memory 1204. The memory 1204 stores program code that, when executed by the processor 1202, causes the processor to perform the operations described in this disclosure.

[0154] The memory 1204 can include any suitable non-transitory computer-readable storage medium. The computer-readable medium can include any electronic, optical, magnetic, or other storage device capable of providing a processor with computer-readable program code or other program code. Non-limiting examples of a computer-readable medium include a magnetic disk, memory chip, optical storage, flash memory, storage class memory, ROM, RAM, an ASIC, magnetic storage, or any other medium from which a computer processor can read and execute program code. The program code may include processor-specific program code generated by a compiler or an interpreter from code written in any suitable computerprogramming language. Examples of suitable programming language include Hadoop, C, C++, C#, Visual Basic, Java, Python, Perl, JavaScript, ActionScript, etc.

[0155] The computing device 1200 may also include a number of external or internal devices such as input or output devices. For example, the computing device 1200 is shown with an input / output interface 1208 that can receive input from input devices or provide output to output devices. A bus 1206 can also be included in the computing device 1200. The bus 1206 can communicatively couple one or more components of the computing device 1200.

[0156] The computing device 1200 can execute program code 1214 that includes the risk assessment application 114 and / or the model training application 112. The program code 1214 for the risk assessment application 114 and / or the model training application 112 may be resident in any suitable computer-readable medium and may be executed on any suitable processing device. For example, as depicted in FIG. 12, the program code 1214 for the risk assessment application 114 and / or the model training application 112 can reside in the memory 1204 at the computing device 1200 along with the program data 1216 associated with the program code 1214, such as the predictor variables 124 and / or the model training samples. Executing the risk assessment application 114 or the model training application 112 can configure the processor 1202 to perform the operations described herein.

[0157] In some aspects, the computing device 1200 can include one or more output devices. One example of an output device is the network interface device 1210 depicted in FIG. 12. A network interface device 1210 can include any device or group of devices suitable for38US2008 30389410 1Attorney Docket No.: 096923-1364025 establishing a wired or wireless data connection to one or more data networks described herein. Non-limiting examples of the network interface device 1210 include an Ethernet network adapter, a modem, etc.

[0158] Another example of an output device is the presentation device 1212 depicted in FIG. 12. A presentation device 1212 can include any device or group of devices suitable for providing visual, auditory, or other suitable sensory output. Non-limiting examples of the presentation device 1212 include a touchscreen, a monitor, a speaker, a separate mobile computing device, etc. In some aspects, the presentation device 1212 can include a remote client-computing device that communicates with the computing device 1200 using one or more data networks described herein. In other aspects, the presentation device 1212 can be omitted.

[0159] The foregoing description of some examples has been presented only for the purpose of illustration and description and is not intended to be exhaustive or to limit the disclosure to the precise forms disclosed. Numerous modifications and adaptations thereof will be apparent to those skilled in the art without departing from the spirit and scope of the disclosure.39US2008 30389410 1

Claims

Attorney Docket No.: 096923-1364025Claims1. A method that includes one or more processing devices performing operations comprising: determining, using a machine learning model trained using a training process, a risk indicator for a target entity from predictor variables associated with the target entity, wherein the machine learning model is associated with one or more features and wherein the training process includes operations comprising: receiving compliance metadata and the machine learning model, the compliance metadata comprising a set of features and a usage value associated with each feature, the usage value indicating whether each feature can be used to train the machine learning model; for each feature of the set of features, comparing the usage value with a threshold usage value for each of the one or more features associated with the machine learning model and including the feature in a compliant set of training features based on the comparison; generating a training dataset comprising the compliant set of training features; and generating a first version of the machine learning model by training the machine learning model using the training dataset; and transmitting, to a remote computing device, a responsive message comprising at least the risk indicator for use in controlling access of the target entity to one or more computing environments.

2. The method of claim 1, wherein the operations further comprise: automatically deploying the first version of the machine learning model to a serving system to process online transactions or batch jobs.

3. The method of claim 1, wherein the compliance metadata comprises a capping value and a flooring value for at least one feature of the compliant set of training features and wherein the training process further comprises: for the at least one feature of the compliant set of training features, applying a capping rule and a flooring rule based on the capping value and the flooring value,40US2008 30389410 1Attorney Docket No.: 096923-1364025 respectively, to generate a compliant value for the at least one feature of the compliant set of training features.

4. The method of claim 1, wherein the compliance metadata comprises an expected trend for at least one feature of the compliant set of training features and wherein the training process further comprises: for the at least one feature of the compliant set of training features, iterating over ordered unique values to identify a suitable capping value and a suitable flooring value, wherein applying the suitable capping value and the suitable flooring value produces an observed trend that agrees with the expected trend; and applying the suitable capping value and the suitable flooring value to the at least one feature of the compliant set of training features to generate a compliant value for the at least one feature of the compliant set of training features.

5. The method of claim 1, wherein the training process further comprises: for at least one feature of the compliant set of training features, computing order statistics from the training dataset; deriving a capping value and a flooring value for the at least one feature of the compliant set of training features based on the order statistics; and applying the capping value and the flooring value, respectively, to a value of the at least one feature of the compliant set of training features to generate a compliant value for the at least one feature of the compliant set of training features.

6. The method of claim 1, wherein the compliance metadata comprises a specified imputation value associated with at least one feature of the compliant set of training features and wherein the training process further comprises: applying, to a feature of the compliant set of training features that comprises an invalid value, a regulatory-compliant imputation based on the specified imputation value to generate a compliant value for the at least one feature of the compliant set of training features.

7. The method of claim 6, wherein the specified imputation value comprises a treatment option and wherein the operations further comprise:41US2008 30389410 1Attorney Docket No.: 096923-1364025 for the at least one feature of the compliant set of training features, imputing a valid value by applying the treatment option to the training dataset.

8. The method of claim 1, the method further comprising: generating the compliance metadata based on a compliance scorecard, wherein the compliance scorecard comprises an average usage value for each of the one or more features and wherein the average usage value is based on a minimum number of input usage values.

9. A system comprising: a processing device; and a memory device in which instructions executable by the processing device are stored for causing the processing device to perform operations comprising: determining, using a machine learning model trained using a training process, a risk indicator for a target entity from predictor variables associated with the target entity, wherein the machine learning model is associated with one or more features and wherein the training process includes training operations comprising: receiving compliance metadata and the machine learning model, the compliance metadata comprising a set of features and a usage value associated with each feature, the usage value indicating whether each feature can be used to train the machine learning model; for each feature of the set of features, comparing the usage value with a threshold usage value for each of the one or more features associated with the machine learning model and including the feature in a compliant set of training features based on the comparison; generating a training dataset comprising the compliant set of training features; and generating a first version of the machine learning model by training the machine learning model using the training dataset; and transmitting, to a remote computing device, a responsive message comprising at least the risk indicator for use in controlling access of the target entity to one or more computing environments.42US2008 30389410 1Attorney Docket No.: 096923-136402510. The system of claim 9, wherein the operations further comprise: monitoring a compliance metadata repository to identify updated compliance metadata associated with the machine learning model or monitoring population stability changes compared to a pre -determined threshold; determining, using an updated machine learning model trained using a training process, an updated risk indicator for the target entity from predictor variables associated with the target entity, wherein the updated machine learning model is associated with one or more updated features and wherein the training process includes training operations comprising: receiving the updated compliance metadata and the first version of machine learning model, the updated compliance metadata comprising at least one updated feature in the set of features wherein the updated feature is associated with an updated usage value; for the updated feature of the set of features, comparing the updated usage value with the threshold usage value for the updated feature associated and including the updated feature in the compliant set of training features based on the comparison; generating an updated training dataset comprising the compliant set of training features; and generating the updated machine learning model by training the first version of the machine learning model using the training dataset.

11. The system of claim 9, wherein the operations further comprise: determining a set of risk indicators and maintaining, by the machine learning model, a monotonic relationship between factors of the predictor variables and the set of risk indicators.

12. The system of claim 9, wherein the operations further comprise: determining one or more reason codes associated with the risk indicator; and transmitting, to the remote computing device, the one or more reason codes as part of the responsive message.

13. The system of claim 9, wherein the operations further comprise:43US2008 30389410 1Attorney Docket No.: 096923-1364025 publishing a pipeline to a pipeline repository using a continuous integration and continuous delivery (CI / CD) process, wherein the pipeline comprises steps associated with the training process.

14. The system of claim 9, wherein the training process further comprises: applying a numerical optimization algorithm to tune parameters of the machine learning model while enforcing trends defined by the compliance metadata.

15. A non-transitory computer-readable storage medium having program code that is executable by a processor to cause a computing device to perform operations, the operations comprising: determining, using a machine learning model trained using a training process, a risk indicator for a target entity from predictor variables associated with the target entity, wherein the machine learning model is associated with one or more features and wherein the training process includes training operations comprising: receiving compliance metadata and the machine learning model, the compliance metadata comprising a set of features and a usage value associated with each feature, the usage value indicating whether each feature can be used to train the machine learning model; for each feature of the set of features, comparing the usage value with a threshold usage value for each of the one or more features associated with the machine learning model and including that feature in a compliant set of training features based on the comparison; generating a training dataset comprising the compliant set of training features; and generating a first version of the machine learning model by training the machine learning model using the training dataset; and transmitting, to a remote computing device, a responsive message comprising at least the risk indicator for use in controlling access of the target entity to one or more computing environments.

16. The non-transitory computer-readable storage medium of claim 15, wherein the compliance metadata comprises a capping value and a flooring value for at least one44US2008 30389410 1Attorney Docket No.: 096923-1364025 feature of the compliant set of training features and wherein the training process further comprises: for the at least one feature of the compliant set of training features, applying a capping rule and a flooring rule based on the capping value and the flooring value, respectively, to generate a compliant value for the at least one feature of the compliant set of training features.

17. The non-transitory computer-readable storage medium of claim 15, wherein the compliance metadata comprises an expected trend for at least one feature of the compliant set of training features and wherein the training process further comprises: for the at least one feature of the compliant set of training features, iterating over ordered unique values to identify a suitable capping value and a suitable flooring value, wherein applying the suitable capping value and the suitable flooring value produces an observed trend that agrees with the expected trend; and applying the suitable capping value and the suitable flooring value to the at least one feature of the compliant set of training features to generate a compliant value for the at least one feature of the compliant set of training features.

18. The non-transitory computer-readable storage medium of claim 15 , wherein the training process further comprises: for at least one feature of the compliant set of training features, computing order statistics from the training dataset; deriving a capping value and a flooring value for the at least one feature of the compliant set of training features based on the order statistics; and applying the capping value and the flooring value, respectively, to a value of the at least one feature of the compliant set of training features to generate a compliant value for the at least one feature of the compliant set of training features.

19. The non-transitory computer-readable storage medium of claim 15, wherein the compliance metadata comprises a specified imputation value associated with at least one feature of the compliant set of training features and wherein the training process further comprises: applying, to a feature of the compliant set of training features that comprises an invalid value, a regulatory-compliant imputation based on the specified imputation45US2008 30389410 1Attorney Docket No.: 096923-1364025 value to generate a compliant value for the at least one feature of the compliant set of training features.

20. The non-transitory computer-readable storage medium of claim 15, wherein the compliance metadata is generated based on input received via a compliance scorecard, wherein the compliance scorecard is generated based on user input received via a graphical user interface, the user input comprising a value of one or more score parameters used in generating the usage value.46US2008 30389410 1

Images