API for implementing scoring functions

Abstract

This technology relates generally to data assembly and analytics, as can be used in the personal finance and banking field, and more particularly to the field of lending and credit notification methods and systems. Embodiments of this technology provide systems and methods for creating objects which can be used in multiple implementations to generate scores.

Description

FIELD

This technology relates to applying a computer-implemented a scoring function to a series of variables in a computer system.

BACKGROUND

When a loan application is presented to a lender, the lender decides whether to fund the loan or not. In modern lending systems, this is done by taking data in the loan application, possibly aggregating it with external data from other data sources, and then applying a scoring function to the data to generate a score. Typically, the lender will fund the loan only if the generated score exceeds a certain threshold. Except in extraordinary cases, a computer program located either locally or remotely performs the scoring operation. Similarly, when a collections agent wishes to prioritize defaulted loans upon which they intend to act, they can apply one or more scoring functions to the defaulted loans to generate a score or scores, and perform one or more collection actions to encourage payment based on a prioritization from the generated score or scores. Similarly, when a marketer wishes to determine how best to execute a marketing campaign through one or more media, the marketer can collect data related to all possible targets of the marketing campaign and rank them by applying a scoring function. This helps to optimize the performance of the campaign for the amount of money spent. All of these applications are homologous: an individual or entity wants to make a decision for one or more business items, so the individual or entity passes information through a scoring function that generates one or more scores. The generated score or scores are then used in making the decision for the one or more business items or prioritize actions.

In general, two groups collaborate to develop these scoring functions, a group of modelers (often referred to as underwriters or other names in different contexts,) and a group of programmers (often referred to as software engineers, developers, or similar names.) The modelers, working in a domain-specific language (DSL) or system such as SAS, SPSS, Stata, R, S-plus, MatLab or others, may build a prototype implementation of the scoring function. This prototype can then be given to the programmers, who reimplement the prototype in a general purpose language (GP language) such as C, FORTRAN, Ruby, or C++, before incorporating the implementation into a larger system that delivers scores.

This method of implementation has a number of drawbacks. First, it can require a long period of time to deploy a scoring function, since the reimplementation process is delicate and difficult.

Additionally, the resulting scoring function is relatively difficult to test because tests typically need to be reimplemented in the GP language.

Additionally, DSL's often incorporate algorithms that make the mathematical operations used in the scoring function more stable or accurate. Most GP languages do not include such algorithms, as they make a minor contribution to the uses for which the GP languages are normally applied. Even in cases where programmers have access to tools that implement special purpose algorithms, it can be essentially impossible to guarantee that in all cases the results in the larger embedded system match the results in the prototype scoring function.

Additionally, scoring functions can return unexpected results for reasonable inputs and thus fail to accurately compute solutions. In such cases a final diagnosis of the nature of the failure and its appropriate fix should fall to the group of modelers. If the prototype has been reimplemented, few if any of members of the modeling team will have the sophistication to diagnose any problems with the reimplemented prototype.

Additionally, systems that solve qualitatively different problems (underwriting versus collections versus marketing) will typically have separate implementations. This introduces additional problems, ranging from a lack of shared context (such as the environment the code was written in, including the tools used to write the code and the members of the team who wrote the code) among different programmers, to a lack of common testing infrastructure, even causing potential political strains within an organization due to replication of roles among different units.

By removing the reimplementation process, the drawbacks listed above can be resolved. If an API between the presentation layer and the scoring layer is suitably designed, introducing or upgrading a scoring function can be trivial, since the scoring layer can be easily replaced (if it is a discrete component of the scoring system) or the scoring system can be stopped and restarted with a new scoring function in place. Modelers can debug the implementation of the scoring function, as they wrote it and are therefore familiar with the implementation language and code. Since the scoring function runs in the DSL itself, the scoring function will continue to use any of the special computational or algorithmic features, above.

The division of the main API into two layers makes the process of building a client for a given system more straightforward and reproducible, particularly since many of the interactions between the kernel and the client level are human readable and can thus be read by non-coders. This exposes most of the internal structure of the client layer in an easy to understand medium, making it easier to share knowledge among and between developers and teams, reducing the cost of building new client layers, and thus reducing costs overall.

BRIEF DESCRIPTION OF THE DRAWINGS

Illustrated in the accompanying drawing(s) is at least one of the best mode embodiments of the present technology in such drawing(s):

FIG. 1A is an example view of a network setup.

FIG. 1B is an example view of a network connected server system.

FIG. 1C is an example view of a user device.

FIGS. 2A-2C are example views of flow chart diagram showing system interaction.

FIGS. 3A-3C are example views of user interface screens embodiment.

FIG. 4 shows an example embodiment of a scoring process outline.

FIG. 5 shows an example embodiment of an underwriting data flow.

FIG. 6 shows an example embodiment of a direct mail data flow.

FIG. 7 shows an example embodiment of a functional API structure.

FIG. 8A shows an example of functional data flow through parsers.

FIG. 8B shows an example of a segment of a UPD file.

FIG. 9A shows an example of a functional data flow through a metadata computation layer.

FIG. 9B shows an example of a segment of a UMD file.

FIG. 10A shows an example of a functional data flow through a filtering layer.

FIG. 10B shows an example embodiment of a blacklist file.

FIG. 11 shows an example embodiment of a functional diagram of horizontal scaling in scoring.

FIG. 12 shows an example embodiment of a functional diagram of blue list filtering.

FIG. 13 shows an example embodiment of a scoring step decomposition into two segments.

FIG. 14A shows an example embodiment of incorporating a scoring step into a decisioning stage.

FIG. 14B shows an example embodiment of incorporating a scoring step into a decisioning stage.

FIGS. 15A-15D show an example embodiments of multi-stage scoring architectures using waterfall scoring processes.

FIGS. 16A-16B show example embodiments of asynchronous steps in combination with waterfall scoring systems.

DETAILED DESCRIPTION

The following description is not intended to limit the, but rather to enable any person skilled in the art to make and use this technology. Although any methods, materials, and devices similar or equivalent to those described herein can be used in the practice or testing of embodiments, the methods, materials, and devices are now described.

The present technology relates to improved methods and systems for replacement of the above-described monolithic approach of re-implementing a prototype in a different language for different applications. Herein is described a multipartite approach in which prototype code can be directly incorporated into a production system. This multipartite system can incorporate an outer presentation layer that duplicates the behavior of the previous approach and an inner scoring layer built from a prototype originally written by a modeling team. These two layers can communicate with one another through a prescribed application programming interface (API) that can be implemented within a single encapsulated unit of execution (a process), between two applications on a single processing system (using an “inter-process communication system”), or between or among applications running on different processing systems (using a “remote communication system”).

In the described system, the scoring layer can be a composite of two layers, a client interface and a kernel. Qualitatively different applications typically use different client layers, but all client layers can share a single kernel. In this model, a batch scoring system that can be applied naturally to a marketing problem can have a first client layer, while a real-time scoring system that can be naturally applied to loan underwriting can have a second client layer. In an example embodiment of this system, one or more client layers can interact with the kernel layer through a single common interface and the one or more client layers can expose the API described above, for instance by enabling objects to be accessed through different means. In order to provide as much common structure as possible, the client layer and the kernel can communicate through an internal API which consists of a set of down-calls from the client layer to the kernel, a set of callbacks by which the kernel extracts information about any input data from the client layer, and a set of human-readable and human-editable files which describe how the callbacks operate and what the callbacks depend upon.

FIG. 4 shows an example embodiment of a scoring process flowchart 400 in accordance with the present technology. In the example embodiment, a request for application specific data 402 can be sent to a data conditioning routine 408. Application specific data request 402 can also include additional required data sent from outside the system with request 402. This additional data can include single records (e.g. as is provided when scoring a single loan application; see FIG. 5) or multiple records (e.g. as is provided when computing marketing or operations scores; see FIG. 6).

External data 404 can include data collected in response to the application-specific data request 402. This data can include results from credit bureaus, alternative credit bureaus, government records, similar sources or other sources located outside the system.

Persistent local data 406 can include data that is kept in a local database repository for more than one scoring operation. Persistent local data 406 can include information collected during previous computations of scores, such as a last date of a loan application, or external data that is present for all applications, such as geographical mapping information such as latitude and longitude coordinates.

Data conditioning routine 408 can condition data from 402, 404 and 406 into a form usable by the system. In the example embodiment this can include compiling the data into a form of one or more completed rows 410. In many embodiments, all rows 410 presented to the scoring function 412 must contain the same columns in the same order during for each call—that is, the scoring function 412 can return scoring values 414 for a rectangular table with a constant columnar structure. Scoring function 412 output can also be saved in persistent local data 406 for later usage.

FIG. 5 shows an example embodiment of an underwriting data flow 500 in accordance with the present technology. In the example embodiment, underwriting data flow 500 shows how a data conditioning layer can gather information to compute scores 520 which support a single item application process. In the example embodiment, loan application data 502 can be sent to one or more parsers 504. Loan application data 502 can include a request and additional required data sent from outside or entered into the system.

Additional credit bureau data 506 can include data collected by parsers 504 in in order to complete a request received from 502. Data 506 can include results gathered from credit bureaus, alternative credit bureaus, government records, similar sources or other sources located outside the system.

Parsers 504 can then send the compiled data from 502 and 504 to a metadata computation module 508. In an example embodiment, metadata computation module 508 can further gather and receive data from proprietary or third party sources. As shown in the example embodiment, these can include geographic information system 510, regional econometric data 512, regional demographic data 514 or other sources and can include data that is kept in a local database repository for more than one scoring operation and which can be updated according to system requirements or rules or from other, external sources. Geographical information system 510 can provide information about physical locations on the Earth, such as the location of the Empire State Building. This data can then be used to determine an unemployment rate, average salary of persons near that location or other representative information. Regional econometric data 512 can include age profiles or other similar data from regional demographic data 514. In addition, these example forms of data can be merged with further forms of useful data (not shown). For example, data from a cable provider can be merged in order to determine if a particular address has cable access, and, if so, what level of service is provided at the address.

Metadata computation module 508 can include one or more sub-modules operable to calculate one or more metavariables as required for a particular embodiment. Metadata computation module 508 can then store data in one or more computed rows 516 for processing by scoring function 518 in order to generate scores 520. In many embodiments, all rows 516 presented to the scoring function 518 must contain the same columns in the same order during for each call that is, the scoring function 518 can return scores 520 for a rectangular table with a constant columnar structure.

FIG. 6 shows an example embodiment of a direct mail data flow 600 in accordance with the present technology. In the example embodiment, direct mail data flow 600 shows how a data conditioning layer can gather information to compute lead rankings 620 which support a multi-record application process. In the example embodiment, filtered white pages data 602 can be sent to one or more parsers 604. Filtered white pages data 602 can include a request and additional required data which is pre-filtered and sent from outside or entered into the system.

Additional credit bureau data 506 can include data collected by parsers 604 in in order to complete a request received from 602. Data 604 can include results gathered from credit bureaus, alternative credit bureaus, government records, similar sources or other sources located outside the system.

Parsers 604 can then send the compiled data from 602 and 604 to a metadata computation module 608. Metadata computation module 608 can further gather data from geographic information system 610, regional econometric data 612, regional demographic data 614 or other sources and can include data that is kept in a local database repository for more than one scoring operation and which can be updated according to system requirements or rules or from other, external sources. Geographical information system 610 can provide information about physical locations on the Earth, such as the location of the Empire State Building. This data can then be used to determine an unemployment rate, average salary of persons near that location or other representative information. Regional econometric data 612 can include age profiles or other similar data from regional demographic data 614. In addition, these example forms of data can be merged with further forms of useful data (not shown). For example, data from a cable provider can be merged in order to determine if a particular address has cable access, and, if so, what level of service is provided at the address.

Metadata computation module 608 can include one or more sub-modules operable to calculate one or more metavariables as required for a particular embodiment. Metadata computation module 608 can then store data in many completed rows 616 for processing by scoring function 618 in order to generate lead ranks 620. In many embodiments, all rows 616 presented to the scoring function 618 must contain the same columns in the same order during for each call—that is, the scoring function 618 can return scores 620 for a rectangular table with a constant columnar structure. Lead ranks 620 can undergo further processing for categorization or other organization.

Architecture

Mobile applications, mobile devices such as smart phones/tablets, application programming interfaces (APIs), databases, social media platforms including social media profiles or other sharing capabilities, load balancers, web applications, page views, networking devices such as routers, terminals, gateways, network bridges, switches, hubs, repeaters, protocol converters, bridge routers, proxy servers, firewalls, network address translators, multiplexers, network interface controllers, wireless interface controllers, modems, ISDN terminal adapters, line drivers, wireless access points, cables, servers and other equipment and devices as appropriate to implement the method and system are contemplated.

FIG. 1A shows a diagram of a server system 100 with multiple servers 140, 150 which can include applications distributed on one or more physical servers, each having one or more processors, memory banks, operating systems, input/output interfaces, and network interfaces, all known in the art and operably coupled and powered, and a plurality of end user devices 120, 130 coupled to a network 110 such as a public network (e.g. the Internet and/or a cellular-based wireless network, or other network) or a private network. User devices include for example mobile devices 120 (e.g. phones, tablets, or others) desktop or laptop devices 130, wearable devices (e.g. watches, bracelets, glasses, etc.), other devices with computing capability, non-transitory computer storage media, processors, power, network interfaces and so on appropriately and operably coupled and powered. The server system 100 includes for example servers operable to interface with websites, webpages, web applications, social media platforms, and others.

FIG. 1B shows a diagram of a server 140 according to an embodiment of the technology including at least one user device interface implemented with technology known in the art for communication with a scoring system. The server 140 also includes at least one web application server system interface for communication with web applications, websites, webpages, websites, social media platforms, and others. The server 140 may further include an application program interface (API) 142 that is coupled to a database 141 and may communicate with interfaces 143, 144 such as the scoring system interface 143 for a user device interface and web application server system interface 143, or others. The API 142 may instruct the database 141 to store (and retrieve from the database 141) information such as scoring information, user account information, user information, applicant information, geographical information or others as appropriate. The database 141 may be implemented with technology known in the art such as relational databases and/or object oriented databases or others.

FIG. 1C shows a diagram of a user mobile device 120 according to an embodiment of the technology that includes a network connected scoring application 121 that is installed in, pushed to, or downloaded to the user mobile device. In many embodiments user mobile devices 120 are touch screen devices. In other embodiments, desktops, tablets or other user devices can be used.

Setup, User and Viewer Interaction

In the current system, the outward-facing or front end portion of the code can be written in one or more general purpose languages often used for building web sites and web services and stored in non-transitory, computer-readable memory. In some example embodiments this language can include “Ruby”. The inner-facing or back end portion of the system, including the scoring function can be written in one or more open source domain-specific languages designed particularly to handle statistical computations. In some example embodiments this language can include “R”. In the example embodiment, the “Ruby” front end and the “R” back end portions of the code run in separate processes on the same computer. They can also communicate with one another across a local socket using a special purpose binary protocol. The front end process can also implement a web service with a “RESTful” API (where REST is Representational state transfer).

General Approach to Scoring Functions

In general, scoring functions of a scoring system (e.g. for interface with scoring system interface 143 of FIG. 1B) can work on data other than input data. This can be accomplished either by merging data from another source (such as merging census or unemployment data, as stored in a database, for a metropolitan statistical area into a marketing model to target customers) or from variables constructed from the input data (such as computing a distance from a home to an office in an underwriting model). In an example embodiment of the technology, data other than input data are referred to as outside variables and metavariables, respectively.

In many embodiments, since a scoring function is a function, operating as a set of instructions stored in a non-transitory, computer-readable medium and executable by a processor, then the data upon which the scoring function is to be evaluated can be an array of one or more rows containing all of the base columns within the scoring function's domain. In this case, the scoring function returns one value for each row in the matrix. A value may not be a single real number or integer, but can be a compound object, as in a marketing model embodiment, to provide multiple priority scores for each potential target.

This structure is implemented in a mail API (e.g. as implemented in an API 142 of FIG. 1B) by requiring an outward-facing code to call to an inner-facing code using an entry point, for example, called “build.compound.row” (BCR). BCR can take a stored collection of data, merge it with outside data and compute any metavariables that are associated with a desired or chosen call. BCD can then remove any columns that should not be returned before returning the resulting array. The scoring function can be called on the resulting array and return one score per row of the array.

Metavariables can be derived quantities which can be used to compute scores in example embodiments. In a loan application example, three metavariables examples can include: (1) a latitude and longitude of a point from which an application for a loan is made, (2) a latitude and longitude of a loan applicant's claimed address, and (3) a distance between a point at an application is submitted and a loan applicant's claimed home address. Although each of these three are examples of metavariables, the third example is not computable directly from a loan applicant's loan application data. Rather, it must be computed indirectly using the first two metavariable examples. Thus, metavariables can be independent of one another, as the first two examples show, meaning that it does not depend on other metavariables. Alternately and additionally, metavariables can be dependent on other metavariables, as the third example shows, where the third example metavariable is dependent on the first two example metavariables.

The process of parsing the data, using a processor, into a form to which outside data can be joined and from which metavariables can be computed is configured as a part of the client layer. In some embodiments, this configuration can be implemented using a text file containing a Universal Parsing Definition (UPD) object represented in JSON, a standard textual format for storing or exchanging structured data. A Universal Metadata Definition (UMD) object, also represented as a JSON object, can describe how the metavariables are computed from the resulting parsed objects. A black-list, also represented by a JSON object, can then describe which variables are obscured before running the scoring function.

FIG. 7 shows an example embodiment of a functional API flow structure 700 in accordance with the present technology. In the example embodiment, a first step 701 can include an external client 710 calling into a data conditioning and row creation process through a standard, well known, API 720 (e.g. API 142 of FIG. 1B).

Data can be passed through the API layer of the Standard API 720 and can be collected with other external data requested from or sent by the external client 710 to the Standard API 720 and any persistent data stored in a local or otherwise coupled system database or databases and parsed in step 702 using a set of parsing functions according to a set of protocols described by a Universal Parsing Definition (UPD) file 702. A further example embodiment of step 702 is described below with respect to and shown in FIGS. 8A-8B.

The parsed data 730 can then be transformed into enriched data 740 with a set of high value signals according to a set of recipes, functions, or other instruction sets defined in a Universal Metadata Definition (UMD) file in step 703. These signals can exist in the form of variables or meta-variables in some embodiments. A further example embodiment of step 703 is described below with respect to and shown in FIGS. 9A-9B.

The enriched data 740 can then be filtered through one or more black lists, if applicable, yielding a filtered signal set of data 750 consisting of a named list of vectors. If no black lists are applicable then step 704 can be skipped in some embodiments. In many embodiments it can be essential that the list of vectors includes vectors with compatible lengths either a length of 1 or a constant of a length greater than one.

The list of vectors in the filtered signal set 750 can then be assembled into a table, for example a rectangular table, in step 705. A further example embodiment of steps 704 and 705 is described below with respect to and shown in FIGS. 10A-10B. In many embodiments, this can be a data frame. As such, this can lead to a row creation 760.

The row creation 760 can then be returned to the external client 710 for further processing in step 706. The external client 701 can then view, edit, manipulate or otherwise use the data as required. In the example embodiment, this can include sending the data through one or more scoring functions 770 (locally or remotely) and then receiving results in step 708.

UPD Objects

FIGS. 8A-8B show parsing for input data. This can be an example embodiment of step 702 described previously and shown in FIG. 7.

FIG. 8A shows an example embodiment of functional data flow 800 through a parser in accordance with the present technology. Unparsed data 802 can enter a parser segment, which can be a type-dependent parser 804, as a list of named items. These items can then be parsed according to a set of records specified in a UPD file. These can then be passed to 806.

FIG. 8B shows an example of a segment 810 of a UPD file in accordance with the present technology. The UPD file segment 810 is shown in JSON. Shown are parsers for each of two different data sources: ‘app.data’ 812, which can be parsed using a function called ‘parse.application’ 814, and ‘price.records’ 816, which can be parsed using a function named parse. price.records' 818.

A universal parser definition (UPD) object as shown in the example embodiment starting at 820 and ending at 821 can be a list of parsing transformations that takes raw data fields (e.g. 812) and parses each into another list of lists of elements (e.g. 814) that can then be used as input to a set of metavariables. Each UPD object can include a list of two string fields: a name field 830 and a parser field 831. When a named element (e.g. 812) is passed into a function, such as a build.compound.row function, a value of the named element can be parsed using a function named by the parser field 831. A value of the parser function can be a named list with a length greater than or equal to a list containing the results of parsing the named object using the parser field 831.

In an example embodiment, if a named element 830 is an XML record or a JSON object 812 then a returned list might include individual values parsed out of the XML record or JSON object 812. In embodiments where the list is a list of JSON objects 812, then a returned list can be expected to contain a list of items parsed out of each individual JSON object 812 where, in turn, each sublist is the same length.

In an example embodiment of the client API, UPD objects can be defined in JSON (Javascript Object Notation). Alternatively, UPD objects can be defined in an XML file with a known schema, as a comma-separated value (CSV) file, or in an opaque format such as might arise from serializing an object and storing it.

UMD Objects

FIGS. 9A-9B show an example embodiment of how high value signals can be built or created using parsed data. This can be an example embodiment of step 703 described previously and shown in FIG. 7.

FIG. 9A shows an example of a functional data flow 900 through a metadata computation layer in accordance with the present technology. Parsed data 902 (e.g. parsed data 730 of FIG. 7) can be passed through one or more metavariables high value scoring (HVS) functions 904a, 904n. In many embodiments, the inputs to one HVS function 904n may include an HVS output 906a from a different HVS function 904a. HVS outputs 906a, 906n can be enriched data (e.g. enriched data 740 in FIG. 7) which can then be passed through a filtering layer 908 (e.g. step 704 in FIG. 7). For instance, in an embodiment, the latitudes and longitudes of two different points can be parsed data 902. These latitudes and longitudes can be processed or computed using HVS function 904a and returned as metavariables HVS 906a. The distance between the latitude and longitude of the two different points might be combined using another HVS function 904n to compute the geodetic distance between them. Then, if necessary, this information could be filtered in a filtering layer 908.

FIG. 9B shows an example of a segment 920 of a UMD file in JSON in accordance with the present technology. The example embodiment shown of UMD file segment 920 describes the computation of four HVS metavariables. A first HVS metavariable ‘phone.book.name’ 928 can be computed from a variable ‘first.name’ 922 and a variable last.name’ 924 through the function ‘build.reversed.name’ 926. A second HVS metavariable ‘zip.four’ 930 can be computed from a variable ‘zipcode’ 932 and a variable ‘zip plus four’ 934 using the function compute.zip.four’ 938. A third HVS metavariable item.ids’ 940 and a fourth HVS metavariable ‘prices’ 942 can be computed from five variables, including the second HVS metavariable ‘zip.four’ 930, which was previously computed as described above.

A universal metadata definition (UMD) object can be a list of transformations that compute HVS metadata from other data variables and, in some embodiments, from other HVS metadata. Each of these UMD objects can contain three parts: 1) a string naming a transform 950 that creates one or more HVS metavariable names and two lists of strings; 2) “dependencies” 952 of the transform; and 3) “siblings” 954 computed by the transform. So, in the example embodiment shown in FIG. 9B, a first UMD object starting at 960 and ending at 961 includes each of the following. First, a string naming a transform 950 that creates one HVS metavariable names “build.reversed.name” 926. First string list 2 “dependencies” 952 of the transform including “first name” 922 and “last name” 924. Second string list “siblings” 954 including “phone.book.name” 928 computed by the transform.

As described above, a transform (e.g. 950) can be a function that uses two or more variables and returns at least one computed metavariable. The list of dependencies (e.g. 952) and the list of siblings (e.g. 954) can be related only by the fact that the list of dependencies are used to construct the list of siblings through the specified transformation; the two lists need not be the same length nor need the elements of the two lists match up in any way in some embodiments. A transform member can be the name of a function that performs the transform. The function to which a given transform name is associated can be looked up by name when a UMD file is loaded. This operation can be accomplished in languages which support reflection, such as Java, R, S-plus or Python. Additionally, this operation can be accomplished in languages which support dynamic loading by name, such a C or C++ or in any language with access to a DLL's symbol table in Windows environments.

As described above, values of one metavariable can depend on the values of other metavariables. For instance, the distance between two addresses can typically be computed from the geodetic distance between their latitudes and longitudes, but the addresses themselves would not usually be presented in that form. As an example, a human may know that the Taj Mahal is a building in India but would likely be unaware that the Taj Mahal is located at 27.175015 North, 78.042155 East. Typically, the latitude and longitude (as initial metavariables) corresponding to a given address can be first computed using a geographical information system before geodetic distances between points can be computed from those initial metavariables.

In an example embodiment of the client API, UMD objects can be defined in JSON (Javascript Object Notation). Alternatively, a UMD object can be defined in an XML file with a known schema, or in an opaque format such as might arise from serializing an object and storing it.

Blacklisted Variables

FIGS. 10A-10B show an example of removing unwanted signals using a black list.

FIG. 10A shows an example of a functional data flow 1000 through a filtering layer in accordance with the present technology. The filtering layer can receive enriched data (e.g. see 740 of FIG. 7) emitted by a metavariables computation layer and filter out any signals 1004 from a collective set of signals 1004a and 1004b which are not to be included in a final output frame. These filtered signals 1004a might either been barred by regulatory or legal reasons, or because they are not compatible with an output frame.

To elaborate, in the example embodiment, some or all generated HVS signals 1002 (e.g. in the form of enriched data 740 of FIG. 7) can be a group of collective HVS signals 1004a and 1004b sent to a black list filter 1006 for processing. Black list filter 1006 can then block blacklisted HVS signals 1004a of the group of collective HVS signals 1004a and 1004b based on particular rules or regulations (e.g. as step 704 in FIG. 7). A group of acceptable, allowable or otherwise usable HVS signals 1008 (e.g. in the form of a filtered signal set 750 of FIG. 7) can then be sent (e.g. as step 705 of FIG. 7) to a row builder 1010 (e.g. for row creation 760 of FIG. 7).

FIG. 10B shows an example embodiment of a segment 1020 of a blacklist file in accordance with the present technology. This blacklist segment 1020 is shown as a JSON file segment containing a list 1022 of regular expression that represent the names of all fields which must be removed prior to row construction (e.g. “zipcode” and “zip plus four” are listed here, corresponding to 932 and 934.

Some elements may not eligible for use in implementing the system and methods described herein. For instance, in some embodiments, scoring functions may be required to depend only upon variables available at a particular scoring time or set of scoring times. In many embodiments there are variables that are available during a training time in which functions are being trained which are computable during the training but which are not available during the scoring time. In one example embodiment, loan performance of a previously given loan can be used to train a function. For reproducibility, any values associated with such variables from a previously given loan may need to be erased at the scoring time of a new loan processing. In addition, there can be variables which are available in implementation of a function but which may not be used for reasons such as privacy protection, legal reasons such as non-discrimination, or data source usage restriction. To guarantee that these variables are not available during production calls in the form of actual loan processing, each client layer can contain one or more blacklists of variables which can be removed, blocked or otherwise not used at production time.

Data Flow in this Notional System

In an example embodiment, an external customer or other third party can call an outer layer of an API through a specified external endpoint, either through a web service as in a real time client accessing the system over a network or by instantiating one or more files in a jointly-accessible repository or other networked database. In the first step of a subsequent process, the reference implementation can consume or otherwise process that data and produce a set of one or more rows of assembled data to be scored by an associated scoring function. In a second step, this a set of one or more rows of assembled data is passed on to a scoring function, which can return one or more scores for each row to the external customer or other third party, either directly as at least one file through a web service or by saving one or more result files in a jointly-accessible repository or other networked database.

Other Aspects of the Technology Horizontal Scaling

FIG. 11 shows an example embodiment of a functional diagram of horizontal scaling 1100 in scoring in accordance with the present technology. The diagram shown in FIG. 11 demonstrates how some embodiments can implement flow processes (e.g. FIG. 7) in parallel in order to achieve scaling in calculating and implementing large numbers of metavariables. To the extent that different scoring functions are completely independent of one another—that is, have no shared state—then many different scores can be simultaneously computed by simply replicating scoring stacks horizontally. In many cases where there is a shared state, horizontal scaling can be accomplished by storing shared data in a shared database.

Many domain specific computer programming languages can be slow. R, for instance, can be as much as two orders of magnitude slower than a general purpose language such as C or C++ when performing tasks such as string manipulations or list constructions. Two broad ways to work around or otherwise avoid these time delays include re-implementing portions of an API, scoring functions or both in a general purpose language or by scaling out the API, scoring function calls or both horizontally and then running or otherwise processing API, scoring function calls or both with few interactions between multiple machines or modules simultaneously. In some embodiments, as a rule, a re-implementing process can be implemented for the API kernel code. Since the API kernel code is frequently called and is typically managed by a single team of developers in an organization, it can be worth optimizing. Because scoring functions themselves or outer layers of API clients can be typically maintained by modelers or other data scientists, there may be little or no benefit to optimizing the code of the scoring functions themselves or outer layers of API clients. This can also result in unnecessarily high costs for their optimization. Functions in an outer layer of the API implementation are typically small and often vectorized. DSLs for mathematical or statistical operations are typically highly optimized for individual implementations within a system. As such, rewriting parser functions or metadata generator functions may provide a minimal speed-up during production. Since client layers should have a common structure across many clients in order to optimize sharing production and test code and since scoring functions typically need to readable by relatively unsophisticated coder such as modelers or other data scientists, rewriting either of them can be wasted effort.

In some embodiments, horizontally scaling a system by replicating an API across many machines in parallel is a desirable approach to meeting throughput and latency requirements if they are not met when running the system on a single processor. In various embodiments, this form of horizontal scaling can be performed in many different ways. In some embodiments this can include sharing outer API layers and distributing the calls to the API from the outer API layers to scoring layers. In some embodiments this can include replicating entire stacks across many machines and load balancing at the machine level. In either case, the result of load balancing can be a significant increase in the throughput of data in the API and can result in reduction in data latency.

Blue Lists

FIG. 12 shows an example embodiment of a functional diagram of blue list filtering 1200 in accordance with the present technology. Blocking scoring on the basis of certain variables can have both legal and performance advantages in some embodiments. Legal advantages can be recognized when an operator needs to demonstrate that a given variable does not enter, directly or indirectly, into a computation. Performance advantages can be recognized if the system is able to blocks computations of expensive time or processing intensive variables.

Latency can increase when extra, lengthy or unnecessary computations of metavariables occurs in various implementations or embodiments. Metavariables can be computed automatically for scoring functions which may eventually use them in addition to preserving scoring function code for the metavariables across multiple scoring functions. However, some scoring functions may require only a small subset of metavariables and by restricting computations performed on various variables to those necessary for a particular scoring function, the latency of each call for a variable can be reduced.

Various embodiments can support “blue lists.” “Blue lists” can be lists of all variables actually used or otherwise processed by the scoring function during a calculation, regardless of whether they are externally or internally computed. Associated kernels may only require the scheduling of computations of variables that are actually used or otherwise processed by the scoring function based on one or more particular “blue lists,” thus reducing the number of metavariables actually computed. An example embodiment can use a particular set of UMD, UPD, and black list files along with the stored code that defines the parser and metadata construction code.

As shown in the example embodiment in FIG. 12, parsed data 1202 can be sent through a blue list 1204. The blue list 1204 can pass through the list of variables that are included in the blue list to an HVS function 1206 for processing. As described previously, an HVS function 1206 can then send a computed HVS 1208 to a filtering layer 1216. For data not included in blue list 1204, the data be blocked or otherwise not forwarded along to a functional block 1210 which is not required in the particular embodiment. Functional block 1210 can include a HVS function 1212 which would otherwise output an HVS 1214 to be passed to filtering layer 1216. Since functional block 1210 is avoided completely by filtering using blue list 1204 because it is not used in the embodiment, no resources are unnecessarily expended in unnecessary processing. This can save a great deal of time and improve processing performance, especially in embodiments where a multitude of HVS functions would otherwise be processed.

In an example embodiment, adding one or more blue lists can reduce the latency of each scoring call from almost three seconds to approximately 100 msec.

Statelessness

There are a number of scoring function applications that may require statefull behavior, in which a final score of an array is computed by several back-and-forth exchanges between a client and one or more scoring functions. An example is multi-pass scoring. In multi-pass scoring the client can call a function such as build.compound.row, as described elsewhere herein, and initially score the result using a first scoring function. Depending on the initial score from the first scoring function, the client can call build.compound.row again and create a second score result using a second scoring function. To the extent that the two calls to build.compound.row share common parse results or common metavariables, unnecessarily repetitions in processing can be avoided in the second build.compound.row call by storing the results of the first call. In an example embodiment, an applicant borrow may apply for a loan. In embodiments where the loan application is denied, an underwriting system may need to generate an “adverse action letter” for the denied applicant borrower which details the reasons why their application was denied. In order to reduce a cost of proxy computation, it can be helpful to delay processing of the reasons for inclusion in the adverse action letter to a time after the application itself is scored. This is due to the temporal cost of proxy computations involved in generating the reasons for inclusion in the adverse action letter. Delaying determination processing requires that the system be able to return the result of that determination with the portion of the system which initially requested that determination. In some embodiments of this system, this return is performed by invoking a ‘callback function’ which can be passed to the determination processing. A callback function can be a function which is expected to be called when an asynchronous processing step such as the determination processing step completes its task. In some embodiments of this system, the content of the object passed to the callback function can be the actual result of the computation, such as the text of an adverse action letter. In other embodiments, the determination process can pass a reference to the desired output, such as a file name or a database key, to the callback function. In yet other embodiments, the determination system can invoke the callback function with only the data required to construct the final result, as when a determination system computes only codes for the reasons to be reported in the adverse action letter, leaving the actual construction to the callback function.

Data allowing the determination of the content of the callback function must be available to the determination process. In some embodiments, this data can constitute an encapsulation of the function itself, a mechanism by which the callback can be recovered from memory, or a pointer to a persistent resource within which the result of the determination system can be stored. In other embodiments, there may be no explicit callback function, but rather a second subsystem which is only invoked when the determination system stores its results in a known location which was provided to the determination system when it was invoked.

These data items: the nature of the content function, a key or location within which the results are to be stored, or the like, is referred to as persistent state. Systems which retain such information are referred to as stateful. They are said to exhibit statefullness.

FIGS. 2A-2C

FIGS. 2A-2C are example views of flow chart diagrams of a first stage 200a, a second stage 200b and a hybrid first and second stage batch request 200c respectively, of system interaction according to an embodiment of the present technology.

As shown in FIG. 2A, in a first stage 200a of a real-time request in an example embodiment, a first step 210 can be a client 202 assembling and passing information required to construct a scorable object, along with a request that a scorable object be constructed, to a web service 204. The web service 204 can then pass this to an API client layer 206 which can construct the scorable object without passing any information on to a scoring function (not shown in FIG. 2A). The construction process can request information in step 212 from other sources 208 during the process of object construction. The requested information from other sources 208 can then be received in step 214 at the API client layer. The scorable object 216 can be created and stored along with a unique identifier in step 216 inside the API client layer 216. The unique identifier (e.g. a scorable object ID) for the scorable object can then be sent back to web service 204 in step 218 for forwarding to the client 202 in step 220. In order to minimize the amount of information transmitted to and from the client 202, only the object ID is passed to the client 202. This can help optimize the system by reducing processing and timing costs associated with data in the system.

As shown in FIG. 2B, in a second stage 200b of a real-time request in an example embodiment, the client 202 may request that the score for a particular object be computed in step 232. As such, client 202 thus invokes the web service 204 requesting that the score for the object with a unique scorable object ID (e.g. the one received in step 220 of FIG. 2A). Web service 204 can pass or copy and pass this information on to the API client layer 206 in step 234, which in turn can assemble one or more blocks and invoke a scoring function 236 in step 236 by calling it. Scoring function 207 can then process the invocation and create a score before returning the score to the API client layer in step 238. The score can be transmitted from the API client layer 206 and copied by the web service 204 in step 240. Web service 204 can then report completion to client 202 in step 242, along with sending any information necessary for client 202 to associate the score with the request from step 232. This score can be reflected, described or reported to client 202 in a format understood by client 202 for whatever subsequent processing client 202 may require.

As shown in FIG. 2C, a batch request 200c in an example embodiment, can be a merger of a first stage 200a and a second stage 200b of the real-time request. A batch request can differ from a real-time because scores computed in response to a batch request are not expected to be returned immediately. In general, a batch request can include many queries, and many scores can be returned in response to such queries. In the example embodiment, a client 202 can send a scoring request to a web service 204 along with one or more pointers to stored data in step 250. The information and data necessary to compute scores in scoring functions 207 can be stored in a storage 209 that is accessible by Web service 204. The Web server can request data information from storage 209 in step 252 and receive data information in step 254. Web service 204 can forward all necessary data information on to API client layer 256 in step 256, where API client layer 256 can assemble a set of requests corresponding to the input data in step 258. These requests can then be forwarded to scoring functions 207 in step 260 where scores can be generated in step 262. Scores can then be stored in storage 209 which client 202 can access and one or more completion reports can be passed to client 202 through steps 266, 268 and 270.

FIGS. 3A-3C

FIGS. 3A-3C show example embodiments of user interfaces 300, 310 and 320 respectively, for an end-user implementing the systems and methods described herein. In FIG. 3A a user may be presented a user interface 300 with a user selectable option 302 to generate a scoring report for an applicant, for instance in an underwriting context. If the user elects to generate a scoring report for the applicant by selecting an affirmative option such as yes and choosing a next button 302, the user may be presented with a next screen, such as in FIG. 3B.

FIG. 3B shows an example embodiment of an applicant information input screen 310. In the example embodiment a user may input information about the applicant in user input area 312 such as identifying information including a first and last name, an address including city state and zip code, and a length of time living at a residence. Dropdown menus may be used to allow the user to select years, months, days, fortnights, or other time lengths or other listed options. The user can then select a next button 314 and be presented with another screen, such as in FIG. 3C.

FIG. 3C shows an example embodiment of a variable selection screen 320 which allows a user to select either a type or a number and type of selectable variables 322 to include in generating a scoring report for a particular applicant. These can be in the form of dropdown menus as shown in the example embodiment. In other embodiments there may be checkboxes, radio buttons, text input or other ways of selecting variables to use.

Once selectable variables 322 have been chosen by a user, the user can select a generate report button 324. This will cause the program to apply a particular scoring function as described herein and to generate a report. In the example embodiment this can include outputting a report for the user determining the applicant's reliability or likelihood of paying back a loan and whether the applicant's request should be granted.

FIG. 13 shows an example embodiment of scoring step decomposition 1300 into two segments. In an example embodiment it can be a computation which is used between parsers and metadata computation before completed rows are created (e.g. as 504, 508, 516 in FIG. 5 or 604, 608, 616 in FIG. 6). In many embodiments, scoring functions can be naturally decomposed into two segments. In the example embodiment, a decisioning stage 1302 is in communication with a stage scoring step 1304. Stage scoring step 1304 can include a first segment 1308 and a second segment 1306. First segment 1308 can be a relatively quickly changing or evolving segment which can be constructed on rapidly-changing and novel information, e.g. the scoring function (SF). A second segment 1306 can be a more slowly varying segment which performs initial analysis and processing of data to generate single or individual inputs that reflect signals drawn directly from input data and metavariables computed from the data, the row generating client (RGC). The decisioning stage 1302 can be viewed as depending on a distinguished ‘stage scoring step” 1304, which, in turn, can include a row generation step, embodied by a row generating client (RGC) and a scoring function (SF). The RGC can correspond to the composition of the Parsers 504 and the Metadata computation 508 in FIG. 5 or the similarly named Parsers 604 and Metadata construction 608 in FIG. 6. The SF step 1308 corresponds to the Scoring function step 518 in FIG. 5 or the Scoring function step 618 in FIG. 6.

FIGS. 14A-14B show example embodiments of how scoring steps can be incorporated into a decisioning stage 1402. As shown in FIG. 14A, a process 1400 by which data flows through a decisioning stage 1402 can be mediated by code implementing the decisioning stage 1402 itself. In the example embodiment, RGC 1406 can be invoked from the decisioning stage 1402 and return at least one row directly to decisioning stage 1402. This row can then be passed on to scoring function 1404 from which a score can be calculated. This embodiment has the advantage that the output of an RGC 1406 can be stored or modified prior to the SF 1404. As shown in FIG. 14B, a call to a SF 1404 can be performed without returning an output of a RGC 1406 to decisioning stage 1402. In the example embodiment, decisioning stage 1420 can invoke RGC 1406 as in FIG. 14A, but the result from RGC 1406 is not passed to decisioning stage 1402. Instead, the newly constructed row is passed directly to SF 1404 without any intermediation by decisioning stage 1402. This can require that RGC 1406 and SF 1404 are running in a module which can preserve states, as discussed elsewhere herein. This can provide advantages including minimizing an amount of cross-process communication between the components of the scoring tool and the main decisioning process module.

FIGS. 15A-D show example embodiments of multi-stage scoring architectures using waterfall scoring processes 1500a-1500d. As shown in FIG. 15A, a first, straightforward waterfall scoring process 1500a can include two stages, Stage1 1502a and Stage2 1506a. In Stage1 1502a of the waterfall scoring process, incoming data can be exchanged with RGC/SF 1508a and yield an initial score which is then compared to a threshold 1504a or other acceptance step, which can be a binary threshold of yes or no. If that acceptance step fails as failure 1512a, then the scored object can be rejected and the process terminated. If the acceptance step of comparing to a threshold 1504a succeeds, then the process can be repeated in Stage2 1506a by exchanging data with RGS/SF 1510a and using a subsequent acceptance criterion (not shown), which can be different than the first. This kind of waterfall system can be repeated indefinitely as indicated by the ellipses after the output of Stage2 1506a.

FIG. 15B shows a second, alternate embodiment of a waterfall scoring process 1500b in which the decision is not yes or no, but multi-level. As such, this embodiment operates in a similar fashion to that for process 1500a but a varying threshold 1504b is used. Embodiments of process 1500b thus permit a lender or other operator to compare the response rates for different applicants to different proposed loans terms (terms testing).

FIG. 15C shows a third, alternate embodiment of a waterfall scoring process 1500c in which different pathways are chosen based on input configuration. This version can support path testing or other forms of AB testing. In Stage1 1502c of the waterfall scoring process 1500c, incoming data can be exchanged with RGC/SF 1508c and yield an initial score which is then processed by Varying configuration 1504c. Varying configuration 1504c can return one of two different values depending on whether the initial score was above or below a certain value or threshold. Based on the output of Varying configuration 1504c, a data gathering and processing pathway can follow a path to either Stage2a 1506c or Stage2b 1507c and in some embodiments, both. If Stage2a 1506c is taken, data can be exchanged with RGS/SF 1511c to generate output data. If Stage2b 1507c is taken, data can be exchanged with RGS/SF 1510c to generate output data.

FIG. 15D shows a fourth, alternate embodiment of a waterfall scoring process 1500d in which different scoring regimens are applied based on configuration. This architecture can support percentage-wise testing in some embodiments and permit gradual transitions from one regiment to another. Percentage-wise testing can be used when one system, such as a new scoring function, needs to replace a different system, such as an old scoring function. It is often the case that the new system needs to be tested in production before it is deployed, but the risk of shifting completely from the old to the new is too high to be accepted. In that case, the new element is tested by using it in some percentage of cases before it is deployed in general. In addition, the new element can be brought into production incrementally thereafter, realizing a gradual transition from an old system to a new system. In Stage1 1502d of the waterfall scoring process 1500d, incoming data can be exchanged with RGC/SF 1508d and yield an initial score which can then be processed by Varying configuration 1504d. Using that score, Stage2 1506d can select one or another of SF(a) or SF(b) to score the application, and score that data with RGS/SF(a) 1513d or RGC/SF(b) 1510d as appropriate to generate output data.

FIGS. 16A-B show example embodiments of asynchronous steps in combination with waterfall scoring systems 1600a and 1600b. As shown in FIG. 16A, in Stage1 1602a of the waterfall scoring process 1600a, incoming data can be exchanged with RGC/SF 1604a and yield an initial score which is sent to a Dispatcher 1606a. Dispatcher 1606a can be a module which accepts scores and applications and then dispatches them to subsequent stages. In an example embodiment, Dispatcher 1606a can then transmit data to Synchronous stage 1608a or Asynchronous stage 1614a based on an initial score. A Synchronous stage 1608a can receive data from Dispatcher 1606a and compute a score by exchanging data with RGS/SF 1610a before transmitting the score as an output to Combiner 1612a. When data are scored through Synchronous stage 1608a, the system which will handle the returned score may not progress until a score is returned. An asynchronous scoring step can be launched indicated by the dotted line path from Dispatcher 1606a through Asynchronous stage 1614a to Combiner 1612a. When data are scored through Asychronous stage 1614a, the system which will handle the returned score can continue without interruption. In the asynchronous path, a score can be computed in a separate location at Asynchronous stage 1614a by exchanging data with RGS/SF 1616a and that computed score can then be returned to a main pipeline via a callback or other kind of inter-thread synchronization process by Combiner 1612a. Process 1600a can be particularly valuable during tests of the same type as percentage tests, except that instead of scoring a fraction of all applications through a new scoring function, all applications can be scored along a separate pathway which does not interact with the old scoring system in use. This type of process can be used before percentage testing to show that a given new scoring function is stable enough to be used in production in a very low risk fashion: if an asynchronous invocation fails, then the application will still be scored, but the instability won't affect the main pathway. In that case, a decision to an applicant through process 1600a can depend on an old scoring regimen, while the new scores can be computed for testing purposes.

As shown in an example embodiment in FIG. 16B, an asynchronous scoring step of an alternate waterfall scoring process 1600a can be launched if a given step in an original (non-alternate) waterfall expects no response. Similar to the waterfall process in 1600a, in waterfall process 1600b, Stage1 1602b of waterfall scoring process 1600b, incoming data can be exchanged with RGC/SF 1604b and yield an initial score which is sent to a Dispatcher 1606b. Dispatcher 1606b can be a module which accepts scores and applications and then dispatches them to subsequent stages. In the example embodiment, Dispatcher 1606a can transmit data to Synchronous stage 1608b or Asynchronous stage 1610b based on an initial score which can be compared to a threshold or otherwise judged by the module. A Synchronous stage 1608b can receive data from Dispatcher 1606b and compute a score by exchanging data with RGS/SF 1610b before returning that score to the main on-line process, which can wait for the score to be returned before making any further progress. However, unlike in waterfall scoring process 1600a, in the asynchronous case shown in waterfall scoring process 1600b, an extra step in which asynchronous and synchronous outputs are resynchronized is never performed. Therefore, no Combiner element is needed. As such, the asynchronous output of the asynchronous step signified from the Dispatcher 1606b through Asynchronous stage 1614b and transmitted or stored as an output after exchanging data with RGS/SF 1616b is merely allowed to run to completion. The waterfall scoring process 1600b can be appropriate when an asynchronous step generates an artifact, whether that artifact is a score, an object such as a letter, or any other entity which is not used by the main waterfall. An example embodiment can occur in a case when the construction of an adverse action letter is complete, and the letter is ready for transmission to the applicant.

Any of the above-described processes and methods may be implemented by any now or hereafter known computing device. For example, the methods may be implemented in such a device via computer-readable instructions embodied in a computer-readable medium such as a computer memory, computer storage device or carrier signal. Similarly, storage, storing, or other necessary functions such as processing can be implemented by operative devices including processors and non-transitory computer-readable media.

The preceding described embodiments of the technology are provided as illustrations and descriptions. They are not intended to limit the invention to precise form described. In particular, it is contemplated that functional implementations of the technology described herein may be implemented equivalently in hardware, software, firmware, and/or other available functional components or building blocks, and that networks may be wired, wireless, or a combination of wired and wireless. Other variations and embodiments are possible in light of above teachings, and it is thus intended that the scope of invention not be limited by this Detailed Description, but rather by Claims following.

Claims

1. A server device, comprising a first scoring kernel, an application programming interface (API) client layer, memory having instructions stored thereon, and one or more processors coupled to the memory and configured to execute the stored instructions to: construct a scorable object at the API client layer and based on a first request received at the API client layer from a web server and associated with a client device;send a unique identifier to the web server in response to the first request and using the API client layer, wherein the unique identifier is associated with the scorable object and generated at the API client layer;generate a first score for the scorable object using the first scoring kernel; andprovide the first score to the web server using the first scoring kernel and in response to a second request received from the web server that specifies the unique identifier.

2. The server device of claim 1, wherein the one or more processors are further configured to execute the stored instructions to select the first scoring kernel from a plurality of scoring kernels based on the scorable object.

3. The server device of claim 1, wherein the one or more processors are further configured to execute the stored instructions to: control a second scoring kernel to generate a second score for the scorable object; andcompare the first and second scores to validate the first score before providing the first score to the web server.

4. The server device of claim 1, wherein the API client layer constructs the scorable object by processing instructions of a Domain Specific Language (DSL) and the first scoring kernel creates the first score by processing instructions of a General-Purpose Language (GPL).

5. The server device of claim 4, wherein the one or more processors are further configured to execute the stored instructions to modify the GPL instructions, without modification to the DSL instructions, to update the first scoring kernel.

6. The server device of claim 1, wherein the first request comprises a first set of metavariables and the one or more processors are further configured to execute the stored instructions to enrich the first set of metavariables with a second set of metavariables associated with one or more of accessed information, or a third set of metavariables determined based on both the first and second sets of metavariables, to construct the scorable object.

7. The server device of claim 6, wherein the accessed information comprises one or more of regional econometric data or regional demographic data.

8. The server device of claim 6, wherein the one or more processors are further configured to execute the stored instructions to filter out one or more metavariables from one or more of the first, second, or third sets of metavariables during construction of the scorable object.

9. The server device of claim 1, wherein the first request identifies the first scoring kernel.

10. A server device, comprising memory having instructions stored thereon and one or more processors coupled to the memory and configured to execute the stored instructions to: provide information of a first request from a client device to an application programming interface (API) client layer and receiving a unique identifier from the API client layer in response to the information of the first request, wherein the first request is to construct a scorable object;receive from the client device a second request that specifies the unique identifier after providing the unique identifier to the client device as a response to the first request; andreceiving a score from the API client layer and providing the score to the client device as a response to the second request, wherein the score is generated by a scoring kernel and for the scorable object constructed by the API client layer after the information of the first request is provided to the API client layer and before the second request is received.

11. The server device of claim 10, wherein the one or more processors are configured to execute the stored instructions to select the scoring kernel from a plurality of scoring kernels based on the scorable object.

12. The server device of claim 10, wherein the one or more processors are configured to execute the stored instructions to construct the scorable object by processing instructions of a Domain Specific Language (DSL) and the scoring kernel creates the score by processing instructions of a General-Purpose Language (GPL).

13. The server device of claim 12, wherein the one or more processors are configured to execute the stored instructions to modify the GPL instructions, without modification to the DSL instructions, to update the scoring kernel.

14. The server device of claim 10, wherein the first request identifies the scoring kernel.

15. A server device, comprising: memory having instructions stored thereon comprising an application programming interface (API) client layer and a scoring kernel; andone or more processors coupled to the memory and configured to execute: the API client layer to provide a scoring request to the scoring kernel based on a score received from the scoring kernel in response to the scoring request, wherein the scoring kernel is selected based on a stored scorable object identified by a unique identifier extracted from a first request received from a web server and the score is provided to the web server in response to the first request; andthe scoring kernel to provide the score created for the scorable object to the API client layer in response to the scoring request.

16. The server device of claim 15, wherein the first request comprises a first set of metavariables and the one or more processors are further configured to execute the stored instructions to enrich the first set of metavariables with a second set of metavariables associated with one or more of accessed information, or a third set of metavariables determined based on both the first and second sets of metavariables, to construct the scorable object.

17. The server device of claim 16, wherein the accessed information comprises one or more of regional econometric data or regional demographic data.

18. The server device of claim 16, wherein the one or more processors are configured to execute the stored instructions to filter out one or more metavariables from one or more of the first, second, or third sets of metavariables during construction of the scorable object.

19. A server device, comprising a plurality of scoring kernels, memory having instructions stored thereon, and one or more processors coupled to the memory and configured to execute the stored instructions to: construct a scorable object based on a first request received from a web server and associated with a client device;send a unique identifier to the web server in response to the first request, wherein the unique identifier is associated with the scorable object;select a scoring kernel from the plurality of scoring kernels based on the scorable object;generate a first score for the scorable object using the scoring kernel; andprovide the first score to the web server using the scoring kernel and in response to a second request received from the web server that specifies the unique identifier.

20. A server device, comprising a first scoring kernel, a second scoring kernel, memory having instructions stored thereon, and one or more processors coupled to the memory and configured to execute the stored instructions to: construct a scorable object based on a first request received from a web server and associated with a client device;send a unique identifier to the web server in response to the first request, wherein the unique identifier is associated with the scorable object;generate a first score for the scorable object using the first scoring kernel and a second score for the scorable object using the second scoring kernel;compare the first and second scores to validate the first score; andprovide the first score to the web server using the first scoring kernel after the comparison and in response to a second request received from the web server that specifies the unique identifier.