US20170004573A1 - Workflow processing and user interface generation based on activity data - Google Patents

Abstract

A system obtains a first set of data associated with interactions by a user conducting a transaction using an interface of a computing device, a second set of data associated with a previous transaction, and a third set of data associated with verification of a user identity. The system generates a first score based at least in part on the first, second, and the third sets of data. If the first score does not cross a threshold, the system updates the interface based at least in part on the first score. However, if the first score crosses the threshold, the system obtains, from an external entity, a fourth set of data associated with the user, generates a second score based at least in part on the fourth set of data, and updates the interface based at least in part on the second score.

Description

BACKGROUND
• These days, many transactions are conducted through the Internet, typically by consumers using a browser with a personal computing system or through an application running on a mobile device, such as a smartphone. In order to keep transaction costs low, merchants, creditors, peer-to-peer lenders, and payment services go to considerable effort to mitigate the risk of default on a transaction by a consumer. To this end, some merchants and payment services may contact a private credit bureau to obtain the consumer's credit score. However, contacting a credit bureau during an online transaction is costly, both in terms of time and money, because such credit bureaus typically charge for their services and because of latency involved in contacting and receiving an answer.
BRIEF DESCRIPTION OF THE DRAWINGS
• Various embodiments in accordance with the present disclosure will be described with reference to the drawings, in which:
• FIG. 1 illustrates an example of online merchant webpages communicating with an application programming interface in accordance with an embodiment;
• FIG. 2 illustrates an example of a risk engine in accordance with an embodiment;
• FIG. 3 illustrates an example of different screens presented to different users based on a fidelity score in accordance with an embodiment;
• FIG. 4 illustrates an example of selecting different payment options based on a fidelity score in accordance with an embodiment;
• FIG. 5 is a flowchart that illustrates an example of displaying payment options based on a fidelity score in accordance with an embodiment;
• FIG. 6 is a flowchart that illustrates an example of selecting payment options for display based on a fidelity score in accordance with an embodiment;
• FIG. 7 is a flowchart that illustrates an example of generating a fidelity score in accordance with an embodiment; and
• FIG. 8 illustrates an environment in which various embodiments can be implemented.
DETAILED DESCRIPTION
• In one example, the system of the present disclosure provides executable instructions, capable of capturing measurements of user interactions with the particular user interface, to a computing device hosting the particular interface. For example, the executable instructions may be a set of JavaScript instructions configured to execute in a web browser in association with one or more webpages of an online merchant website. The executable instructions, as a result of being executed, may collect information such as mouse tracking data (e.g., paths of a cursor, elements in the webpage being hovered over by a cursor, identity of the previous webpage, time between receiving input by the user (e.g., time between clicks of a mouse), identities of elements clicked on in the webpages, identity of the current webpage, and so on. In other examples, the executable instructions may be in the form of a browser plug-in, a Java applet or other embedded executable object, or at least a subset of executable instructions of a standalone application (e.g., software application for a computing device, mobile application for a smart phone, etc.).
• The system of the present disclosure may accumulate this set of measurements up to a point where the user is ready to apply for credit or select payment options for the transaction. Alternatively, in some implementations the computing device hosting the particular interface accumulates the set of measurements and, before payment method selection by the user, may provide the set of measurements and personally identifiable information (e.g., first and family name, address, telephone number, email address, etc.) to the system of the present disclosure. The personally identifiable information or set of measurements may also include information such as Internet protocol address of the computing device, browser type, operating system, and so on. The personally identifiable information and set of measurements may be referred to cumulatively as a set of client data; that is, data obtained from the client device of the user.
• The system may, at this point, obtain a set of internal data associated with the user. The set of internal data may include details stored with this system about previous transactions by the user, such as types of previous purchases, amounts of purchases, payment history, and so on. In some cases, internal data may include geographic and demographic data. In some implementations, the set of internal data includes specific details about one or more previous transactions, while in other implementations the specific details of one or more previous transactions are aggregated into a summary of attributes (e.g., has the user paid before, and if so, when did the user pay, what was the average payment, has the user previously been late with payment, did user pay debt off early, does the user only pay the minimum payment or less or more than the minimum payment, etc.), while, in still other implementations, the specific details are processed (e.g., by a neural network, by a vector machine (relevance or support), by a random forest, or some other supervised learning algorithm) to yield an internal data score, which may be used in part to generate a fidelity score, described below.
• The system may also obtain, from an external source, a set of verification data associated with the user. The set of verification data may include verification data regarding the personally identifiable information. For example, the set of verification data may include simple verification data regarding whether the address provided is a valid address, whether the telephone number is a valid telephone number, whether the provided full name is known by the external source, and so on. Additionally or alternatively, the set of verification data may include more complex verification data, such as whether the address is known to be associated with the provided last and/or given name, or whether the provided email address is known to be associated with the user name by the external source.
• Based on the set of client data, a set of user behaviors and characteristics may be presumed. For example, based on demographic data, certain browser types may be more likely to be associated with certain types of users than others. For example, use of a version of the Internet Explorer browser that is known to have been distributed preinstalled with a computing device operating system may suggest that the user is less fickle than a user using the Google Chrome browser. Similarly, if characteristics of the browser suggest that the user is using an anonymous browser or mimicking another browser type, this may be an indication that the user may be less reliable when making credit commitments. Data received about the type and version of the operating system being used by the client device of the user may be comparably useful. Similarly, if the user hovers the cursor over a submit button for at least a threshold amount of time (as determined from the set of measurements), this may indicate that the user is applying careful consideration before completing the transaction, suggesting that the user may be more reliable in making credit commitments than a user who quickly clicks the submit button. Note that such reliability data is presented for illustrative purposes only, and an amount of weight to give to such behaviors may be based on aggregated transaction and statistical data.
• The weights to be associated with the behavioral and characteristic determinations, the set of internal data, and the set of verification data may be used to generate a fidelity score that may reflect a projected likelihood of default on payment by the user. This fidelity score may be generated by a logistic regression, a random forest similar to the supervised models described in U.S. patent application Ser. No. 14/820,468, entitled “INCREMENTAL LOGIN AND AUTHENTICATION TO USER PORTAL WITHOUT USERNAME/PASSWORD,” U.S. patent application Ser. No. 14/830,686, entitled “METHOD FOR USING SUPERVISED MODEL TO IDENTIFY USER,” and U.S. patent application Ser. No. 14/830,690, entitled “METHOD FOR USING SUPERVISED MODEL TO CONFIGURE USER INTERFACE PRESENTATION,” incorporated by reference herein, or by some other classification algorithm.
• In some cases, the resulting fidelity score may suggest that the user has a likelihood of default above a particular threshold, or the information available on the user (i.e., the client data, internal data, and verification data), may be insufficient to generate a reliable fidelity score (e.g., a minimum number of input values are not available), in which case, the system may submit a request to an external entity (e.g., a credit bureau, a bank, etc.) for additional data. This additional data may include information such as a credit score or credit history of the user, verification of a minimum bank balance, and so on. This additional data may be used to generate a new fidelity score, which in some implementations, includes the original fidelity score as a factor in generating the new fidelity score. Based on either the original fidelity score (if the score indicates that the user is sufficiently reliable) or the new fidelity score, the system may cause the particular user interface being used by the user to conduct the transaction to update in order to display certain payment or credit options that the user has been determined to qualify for.
• In the following description, various techniques will be described. For purposes of explanation, specific configurations and details are set forth in order to provide a thorough understanding of possible ways of implementing the techniques. However, it will also be apparent that the techniques described below may be practiced in different configurations without the specific details. Furthermore, well-known features may be omitted or simplified to avoid obscuring the technique being described.
• Techniques described and suggested in the present disclosure improve the field of computing, specifically the field of e-commerce, by determining risk of default of payment by users based at least in part on interactions between the users and an e-commerce user interface. An e-commerce site to which techniques of the present disclosure can be applied may be a website for buying and/or selling goods or services, such as an interface (e.g., software application residing on a local device, website, or other interface) for a retail outlet, discount house, wholesale outlet, bank, credit provider, currency exchange service, insurance provider, investment services provider, debt resolution service, brokerage, bazaar, auction house, shopping center, boutique, supermarket, chain store, thrift shop, flea market, sales kiosk, concession stand, trade fair, or consignment house. Additionally, techniques described and suggested in the present disclosure improve the usability of computing systems by reducing the latency of risk determination by making the risk determination without recourse to external data. Moreover, techniques described and suggested in the present disclosure are necessarily rooted in computer technology in order to overcome problems specifically arising with network latency caused by obtaining credit risk data from external sources.
• FIG. 1 illustrates an aspect of anenvironment100 in which an embodiment may be practiced. As illustrated inFIG. 1, theenvironment100 may include a set ofweb pages124 of amerchant system118, with at least one of the set ofweb pages120 being acheckout page122 for finalizing a transaction. The set ofweb pages120 may be static web pages, may be dynamic web pages generated based on one or more templates or executable instructions (client-side and/or server-side), or may be a combination of static and dynamic web pages. The set of web pages may be designed to provide information to consumers about a merchant of themerchant system118 and/or products or services being offered by the merchant. Executable code embedded in thecheckout page122 may cause a computing device used by the user in conducting the transaction to collect personally identifiable information (e.g., name, geographic address, telephone number, email address, date of birth, etc.) entered by a user as well as behavioral data relating to interactions between the user and the set of web pages120 (e.g., time and identity of web page elements clicked on, hovered over, etc.) asclient data124. The executable code in thecheckout page122 may cause the computing device to make an application programming interface call (API), such as a GetCredit( )API128 of ascoring engine126, to begin a process of determining a set of payment or credit options to present to the user in thecheckout page122. In some implementations, the data may be captured by calling one or more APIs of the operating system of the computing device. In other implementations, the data may be captured by executing code having direct access to hardware of the computing device (e.g., keyboard, mouse, touch screen, and/or other input devices).
• Themerchant system118 in some examples, may be single devices and, in other examples, may be distributed computer systems comprising multiple devices that operate differently such that the distributed computer system performs the operations described (i.e., all operations of themerchant system118 map not necessarily be performed by a single device). Themerchant system118 configured to present a website or other Internet-accessible platform for providing goods and/or services to users/consumers at a price. Themerchant system118 may have one or more web pages comprising the set ofweb pages120 that are configured to interact with a user/consumer. That is, web pages of the set ofweb pages120 may be configured to display images of various products, descriptions of the various products, reviews of various products, and prices of the various products. Web pages of the set of web pages may have one or more embedded controls, such as clickable images and HyperText Markup Language (HTML) form elements, configured to allow the user/consumer to navigate the website, search for products, compare products, view larger images of the products, post reviews of the product, add/remove products to an online shopping cart, enter delivery and billing information, log in and manage an account profile with the merchant, and so on.
• Executable code may be embedded in one or more of the set ofweb pages120 to collect details (also referred to as a set of measurements) about user interactions with the webpages. For example, each of the set ofweb pages120 may include JavaScript or other client-side executable code that keeps a record of certain actions performed by a user (also referred to herein as a set of measurements). The code may be provided by the merchant or may be embedded in the merchant web pages in an HTML inline frame (iframe), with the iframe source being provided by a payment service provider (which may be the same provider as the provider of system of the present disclosure). The record may be a set of measurements of actions performed by the user, and each measurement of the set of measurements may include information such as a user or session identifier for the particular user/session, a detected action (e.g., onClick, onDblClick, onMouseOver, onMouseOut, onMouseDown, onMouseUp, onMouseMove, and onSubmit event triggers, etc.) performed by the user using a user input device (e.g., mouse, trackball, touch screen, keyboard, light pen, game controller, fingerprint scanner, etc.), and a timestamp for the detected action.
• In some implementations, gaze detection data is used to generate behavioral data. For example, many mobile devices are configured to detect an area of a screen receiving the focus of the gaze of the user, referred to as gaze detection or eye tracking Gaze detection data may be obtained from an image sensor or some other optical sensor that senses reflections of light from the eye. The gaze detection data could be used to determine how long the user spends reading certain portions of the terms and conditions. Similarly, an accelerometer, global positioning system receiver, gyroscope, microphone, and other sensors may provide data useful for generating behavioral data. For example, if the background noise indicates that the user is conducting the transaction in a noisy environment, such as a public bus or sporting event, or an accelerometer suggests that the user is conducting the transaction in a moving vehicle, this could be indicative that the user is hurriedly conducting the transaction and may not be giving it sufficient consideration. In some examples, “behavioral data” may refer to inferences made by the system based on interactions between the user and the user interface. That is, the record of actions performed by the user may be used by the system to infer behavior of the user. The behavioral data and personally identifiable information may be cumulatively referred to as theclient data124.
• Note that it is contemplated that executable code other than JavaScript code and interfaces other than HTML interfaces may be used by themerchant system118. For example, themerchant system118 may additionally or alternatively provide standalone mobile applications for devices like smartphones and tablet computing devices for conducting online transactions. Note too, that the merchant corresponding to themerchant system118 may provide services rather than products; for example, themerchant system118 may be a system to provide an online presence (i.e., e-commerce site, as described above) for commerce and financial transactions. Examples for themerchant system118 would include a system for providing an network (e.g., Internet, local area network, wide area network, etc.) accessible site for a bank, credit union, stockbroker, roofing contractor, landscaper, cleaning service, peer-to-peer lender, and so on.
• At least one web page of the set ofweb pages120 may be thecheckout page122. Thecheckout page122 may be one or more pages configured to handle finalizing the transaction. For example, an initial checkout page may allow the user/consumer to review details (e.g., quantities, colors, sizes, prices, etc.) of items in the shopping cart, other checkout pages may allow the user/consumer to log into his/her account with themerchant system118, to select from a set of delivery options, select gift wrap options, and/or enter delivery and billing addresses. Anothercheckout page122 may involve presenting the user/consumer with one or more payment/credit options. It is an objective of the present disclosure that the one or more payment/credit options presented to the user/consumer may be presented based on the collectedclient data124. Like theother web pages120, the payment or credit options on thecheckout page122 may be generated by a server of the merchant based on the fidelity score and/or other information received from thescoring engine126, or, alternatively, the payment or credit options on thecheckout page122 may be presented through an iframe, application software, or software development kit, provided by a payment service provider.
• In order to determine the one or more payment/credit options to present to the user/consumer, theclient data124 may be fed to thescoring engine126 through the GetCredit( )API128. Thescoring engine126 ofFIG. 1, upon receiving the client data through the GetCredit( )API128 generates a series ofvariables130 and corresponding values based on the client data. For example, a variable “given name” may have the value of “Winston,” a variable “family name” may have the value of “Churchill,” a variable of “time_spent_reading_terms_and_conditions” may have a value of 32 seconds, a variable of “browser_version” may have a value of “8.0,” a variable of “time_between_clickdown_submit_and_clickrelease” may have the value of 2103 milliseconds, and so on.
• Thescoring engine126 may next pass the variable130 to therisk assessment API132 in therisk engine134 to perform a risk assessment of the user/consumer based on thevariables130 and their values. Therisk engine134 may be comprised of one or more computing devices and/or software configured to perform a risk assessment of a user/consumer based on thevariables130 provided. The result of the risk assessment may be a value representing an estimated risk of default of payment by the user/consumer, may be a set of executable code (e.g., executable JavaScript) and/or HTML with payment or credit options, or may be some other output as appropriate based on the determined risk associated with the user/consumer.
• Therisk engine134 may pass thevariables130 through the risk model, described in further detail with respect toFIG. 2. Therisk engine134 may referenceexternal data136 of a third party entity, such as a credit bureau service, in the course of performing its risk assessment. Data obtained from theexternal data source136 may be data such as credit scores, confirmation of personally identifiable information (e.g., name, address, telephone number, email address, date of birth, etc.), and so on. Such data about the user/consumer may be stored in thecache140, and, in some cases, if such external data about the user/consumer is located in the cache and is not out of date, such information may be retrieved from thecache140 without resorting to retrieving it from theexternal data source136. Likewise, personally identifiable information may be used to retrieve details about previous transactions involving the user/consumer frominternal data138 of thescoring engine126.
• As noted, theinternal data138 may include details about one or more previous transactions identified as having been conducted by the user/consumer. If thescoring engine126 has no record of the user/consumer conducting a previous transaction, this lack of information may itself be a factor in computing a risk assessment for the user/consumer. For example, if details of the previous transaction recorded in theinternal data138 indicate that the user/consumer faithfully made payments for the previous purchases and paid in full, these details may weigh toward a favorable risk assessment. However if no records of previous transactions are found, thescoring engine126 has no payment history for the user/consumer, and consequently this lack of payment history may weigh towards a less favorable risk assessment. On the other hand, records of previous transactions indicating that the user/consumer was unreliable with payments for previous purchases may weigh towards an unfavorable risk assessment.
• In some embodiments, the details about previous customer transactions are obtained from arecord matching service146 of the type described in U.S. patent application Ser. No. 14/820,468, U.S. patent application Ser. No. 14/830,686, and U.S. patent application Ser. No. 14/830,690, incorporated herein by reference, configured to store and retrieve records regarding previous transactions by the user/consumer. Therecord matching service146 may be a system comprising one or more computing devices configured to at least identify the user/consumer from theclient data124. As an example, if theclient data124 include details for a large order of flowers by “Henry Gibson” from themerchant system118, but records in theinternal data138 from therecord matching service146 corresponding to the name “Henry Gibson” are typically orders for writing materials, therecord matching service146 may determine that the user/consumer has a low probability of being the same “Henry Gibson” as was found in theinternal data138.
• In addition to the internal and external data, the risk engine may generate its assessment at least in part from the values of thevariables130. For example, if the variable values indicate that the user/consumer added and removed an expensive item from the shopping cart multiple times, this behavioral data may indicate that the user/consumer is operating at a limit of what the user/consumer is able to afford. Consequently, this may weigh towards a less favorable risk assessment. As another example, if thevariables130 indicate that the user/consumer compared a variety of similar products before finally selecting the product with the best reviews, this behavioral data may indicate that the user/consumer has given careful thought to the purchase, and consequently this may weigh towards a more favorable risk assessment. As noted other information in the personally identifiable information may be used to verify the stability of the user/consumer. For example, if the name and address provided by the user is checked against a database, such as theexternal data source136, and theexternal data source136 responds that the name and address are indeed known to be associated with each other, then this may weigh towards a more favorable risk assessment. On the other hand, if theexternal data source136 is unable to find a match against the name and address provided by the user/consumer this may weigh towards a less favorable risk assessment. Likewise if only the family name provided by the user/consumer can be matched to the address provided by the user/consumer, this may weigh towards a more favorable risk assessment but not as much as if the full name provided by the user/consumer had been matched against the address. For example, a matching family name with a non-matching given name may suggest that a child of the household of that address is placing the order, rather than an adult, and consequently the child may be at a higher risk of default of payment on the transaction.
• FIG. 2 illustrates another aspect of anenvironment200 in which an embodiment may be practiced. As illustrated inFIG. 2, theenvironment200 may include auser244 using acomputing device242 to conduct a transaction. At a point before finalizing the transaction, client data, such as theclient data124 ofFIG. 1, may be provided to arisk engine234 in order to determine a risk of default of payment by theuser244. Therisk engine234 may be similar to therisk engine134 ofFIG. 1.
• Theuser244 may be an individual conducting a transaction through thecomputing device242 or may be another entity authorized to conduct such a transaction for the individual. Theuser244 may be a first-time user in theenvironment200, or may have previously conducted transactions using therisk engine234 of theenvironment200, in which case, details of the previous transactions may be recorded in theinternal data206. Thecomputing device242 may be any type of computing device having one or more processors and memory, such as thecomputing device800 ofFIG. 8, capable of receiving input from theuser244 and communicating with components of therisk engine234 through thenetwork248. Thenetwork248 represents the path of communication between the user and therisk engine234. Examples of thenetwork248 include the Internet, a local area network, a wide area network and Wi-Fi.
• As an initial matter, client data may first be passed through a set ofrules202. That is, themodel204 of therisk engine234 is configured to provide a risk assessment based oninternal data206,verification data208, andbehavioral data210, but the set ofrules202 provide an initial screen of theuser244 to determine whether to proceed with the risk assessment. For example, if theuser244 is a returning user who has defaulted on a previous purchase, the set ofrules202 may be configured to immediately reject theuser244 or present of theuser244 with a fixed set of payment or credit options, such as “prepayment required.” In other words, the set of rules are rules that would not be overcome by a risk assessment from themodel204.
• Themodel204 may include a combination of hardware and software configured to output a risk assessment based on one or more of theinternal data206, theverification data208, and thebehavioral data210. An advantage provided by themodel204 is that transactions can be processed and finalized more quickly, because an online transaction system may rely on a risk assessment generated by themodel204 without having to request a credit check of theuser244 by a third party entity, such as a credit bureau. Furthermore, because some credit bureau services charge a fee for credit checking services, cost savings may be achieved by relying on the risk assessment of themodel204. Therisk engine234 may be further configured to update/retrain themodel204 based on the collected data (e.g., client data, details about the transaction, etc.) by associating the collected data in a data store with payments by theuser244 as they are received in a timely, or, as the case may be, in a not so timely fashion from the user, and regenerating the logistic regression or retraining the neural network, vector machine, random forest, or other supervised learning algorithm upon which themodel204 is based.
• Theinternal data206 used by themodel204 may include, if the user is a returning user, details about previous transactions, such as addresses used in previous transactions, purchase amounts of previous transactions, methods of payment used in previous transactions, whether the user paid more or less than the minimum payment, whether the user accrued any late fees, whether any funds are still owed on previous transactions, and so on. If theuser244 is a new user rather than a returning user, this lack of a purchase history for theuser244 is itselfinternal data206 that may be taken into consideration by themodel204. In some implementations, theuser244 is determined to be a new user if theuser244 creates a new account/user profile with the merchant or payment services provider involved in the transaction. In other implementations, the determination that theuser244 is a new user is made by a record matching service of the type described in U.S. patent application Ser. No. 14/820,468, U.S. patent application Ser. No. 14/830,686, and U.S. patent application Ser. No. 14/830,690, incorporated herein by reference. In still other implementations, a determination that theuser244 is a new user is made by determining that there is not a match between personally identifiable information provided by theuser244 and records in theinternal data206. In the latter implementations, a user profile is created for a new user, and if theuser244 conducts transactions in the future, details of the future transactions may be stored in a data store hosting theinternal data206.
• In some embodiments, theinternal data206 component incorporate the record matching service of U.S. patent application Ser. No. 14/820,468, U.S. patent application Ser. No. 14/830,686, and U.S. patent application Ser. No. 14/830,690, incorporated herein by reference. For example, the client data provided by theuser244 may be usable by the random forest of the record matching service to make a determination about the identity of the user. In some implementations, the random forest of the record matching service is trained on behavioral data obtained in a manner as described in the present disclosure. In this way, an identity of theuser244 may be determinable at least in part based on the user's interactions with the user interface, or may provide additional information usable to make a more certain determination about the identity of theuser244. In this manner, in some implementations, theuser244 need not create an account with a merchant, but rather the identity of the user is determined by the record matching service. In other implementations, theuser244 can create an account with the merchant.
• In either embodiment, the record matching service includes detailed information about previous transactions likely conducted by theuser244 based on client data received. Furthermore, in some implementations the behavioral data for the current transaction and previous transactions are stored in a data store accessible to the record matching service, and with recourse to the previously recorded behavioral data, themodel204 may be able to generate more accurate risk assessments. Theverification data208 may include one or more pieces of data indicating that theuser244 has provided accurate information. Theverification data208 may be based on personally identifiable information submitted with client data by thecomputing device244. One example of personally identifiable information may be a device identifier (ID) for the computing device being used by the user to conduct the transaction. If theinternal data206 contains information that shows that the present user has previously conducted a transaction using the same device (based on the device ID), this may be indicative of stability (e.g., not making purchases using borrowed computing devices) and consequently weigh in favor of lower risk.
• Another example ofverification data208 may be a simple result of true or false for whether the address provided by theuser244 actually exists. For example, some of the personally identifiable information (e.g., name, address, etc.) may be transmitted through the network communication to a third party entity, such as a credit bureau, to verify theuser244 associated with that personally identifiable information. Furthermore, each piece ofverification data208 may have an associated strength level. For example, a determination that an address exists may have a strength level of 1, indicating that it is a weak verification of the accuracy of information provided by theuser244. On the other hand, a piece ofverification data208 indicating that a given name and family name provided by theuser244 has been confirmed as being associated with the physical address, email address, date of birth, and telephone number also provided by the user may have a strength level of 5, indicating that it is a very strong verification of the accuracy of information provided by theuser244. As another example, verification that a given name and family name provided by the user is associated with an address provided by the user has a stronger strength level than a verification that only the family name, but not the given name, provided by the user could be verified against that address. However, verification that the family name can be verified as associated with the address has a stronger strength level than verification that the family name is associated with a postcode provided by the user, but could not be verified against the address. In some embodiments, strength levels such as these are provided to themodel204 rather than Boolean values (e.g., yes/no, true/false, etc.).
• Note that theverification data208 may be a set of one or more pieces of data such as described above. In some instances, the verification data may be determined using theinternal data206. For example, if theuser244 is a returning user, the information provided in the present transaction may be compared with information provided in previous transactions to yield theverification data208. Ifsuch verification data208 cannot be obtained from theinternal data206, themodel204 may resort to obtaining at least some of theverification data208 from a third-party data source216, such as a credit bureau, a telephone directory, or an internet search engine.
• Thebehavioral data210 may be data associated with one or more actions performed by theuser244 in the course of conducting the transaction with thecomputing device242. For example, if a record of actions performed by theuser244 indicates that theuser244 clicked a link to read “terms and conditions” of the transaction at a first time, clicked a checkbox next to the words “I agree with the terms and conditions,” at a second time, and the difference between the first time in the second time is 15 minutes, one piece of behavioral data may be a variable and corresponding variable value, “studied_the_terms=15.” On the other hand, if the user clicked the checkbox agreeing to the terms and conditions without actually viewing the terms and conditions, that piece of behavioral data may be stored in a variable similar to, “studied_the_terms=0.” Thebehavioral data210 may additionally or alternatively include more granular data than this. For example, the executable code collecting the actions and the record of actions may collect data indicating that theuser244 scrolled quickly through various portions of the terms and conditions, but paused for 10 minutes on the section relating to consequences of nonpayment. Such behavioral data may be stored in a variable similar to “studied_default_on_payment_terms=10,” which may indicate that the user is concerned about an inability to pay, and consequently may be a less-favorable factor in risk assessment. Other examples of thebehavioral data210 include whether the personally identifiable information was automatically populated by the browser or browser plug-in (indicating that the user has used the same information in previous transactions, and also indicating that the user is not trying to disguise him/herself, suggesting that the user may be more reliable), whether the user click-held the submit button for an amount of time suggesting that the user was being very thoughtful about the transaction (e.g., such as may be captured by onMouseDown and onMouseUp JavaScript event triggers), and whether the user had to make corrections while inputting the address data (possibly suggesting that the user is entering a fake address or that the user has not resided at that address for very long). Still another example ofbehavioral data210 may be if the user repeatedly decreases the amount of items in the shopping cart, which may be suggestive that the user has a limited budget.
• As noted, the third-party data source214 may be third party entity for providingverification data208 about theuser244. For example,such verification data208 could include confirmation that the name provided by theuser244 has been previously known to be associated with an address and/or telephone number also provided by theuser244 in the personally identifiable information. Thus, such third-party data source216 could be a telephone directory service, package delivery service, credit bureau, or mapping service.
• The output may include a value indicating a statistical certainty value of a fidelity score generated by the model based on the information provided to the model and information that was unable to be provided to themodel204. The statistical certainty value may be a variance indicating a whether enough information was provided to the model to generate a reliable fidelity score. That is, available information from thedata206, theverification data208, and thebehavioral data210 may be provided to the model, but not all information may be present. For example, the user may have left a telephone number field blank, no record of a previous purchase may be found in internal data, or an external source may be unable to confirm or deny some of the personally identifiable information. Themodel204 may make a determination whether, if the missing values were provided, the resulting score would be affected such that payment/credit options would change for the user. If so, in some implementations, the system of the present disclosure queries an external entity for theadditional data214 in order to obtain a more certain fidelity score. Alternatively or additionally, in some implementations, the system responds by updating the user interface being used by the user to prompt the user for additional information (e.g., “Please input your telephone number,” “Your email address is required to proceed further,” “Please enter your mother's maiden name,” etc.).
• Theoutput212 of themodel204 may, depending on implementation, take various forms. For example, theoutput212 may be a simple “yes” (the user is a good credit risk), “no” (the user is a bad credit risk), or “not enough information.” As another example, the output may be a number representing an estimated percentage chance of default by theuser244. In the latter case, payment/credit options to present to theuser244 may vary based on the generated number. For example, 0-10% may enable display of a “No money down, pay in 30 days” option, 0-20% may enable display of a “Pay by credit card” option, and 0-30% may enable display of a “Pay on delivery” option. Likewise, 80-90% may only allow a “Pre-pay” option. Additionally or alternatively, terms of credit may be determined or altered based on the output. For example, output indicating a 0-5% risk of default may cause theuser244 to be presented with credit terms having an 8% interest rate, output indicating a 5-10% risk of default may cause theuser244 to be presented with credit terms having a 15% interest rate, output indicating a 10-20% risk of default may cause theuser244 to be presented with credit terms having a 29.99% interest rate, and so on. In this manner, credit terms may be determined for theuser244 through a risk assessment of behavioral data obtained from theuser244.
• In some cases, however, theinternal data206,behavioral data210, andverification data208 alone may be insufficient information to result in a reliable risk estimate (e.g., a “not enough information” result or a numeric range of 40-60%). In such a case, the model may retrieveadditional data214 from a credit bureau service in order to make a more reliable risk estimate. Theadditional data214 may be a credit score of the user, identifying information about the user (e.g., current and past addresses, date of birth, known employers, name of spouse, national identification number, etc.), credit history of the user (e.g., list of bank accounts, list of credit card accounts, list of outstanding loans, how long an account has been open, credit limits on accounts, identities of co-signers, etc.), public records associated with the user (e.g., list of evictions reported, list of bankruptcies, list of tax liens, list of civil judgements), or other information about the user (e.g., identities of other entities who have requested a credit report on the user). In some cases, theadditional data214 may alone be sufficient for the risk assessment, and theadditional data214 may be provided as theoutput212. In other implementations, theadditional data214 is fed back into themodel204, and theadditional data214 in combination with theinternal data206, thebehavioral data210, and theverification data208 may be utilized to generate a new risk assessment for theoutput212.
• Note that an advantage provided by the system of the present disclosure is that in many cases a reliable risk assessment may be generated without resorting to using theadditional data214 from an external data source. This provides advantages in speed, usability, and cost. For example, not having to contact a credit service bureau to obtain a credit assessment of theuser244 may save 1.3 seconds or more of transaction processing time. Although 1.3 seconds may not seem like much, every second spent by a user waiting for his/her computing device to respond can have a negative effect on the user's overall satisfaction with the transaction process. Furthermore, because credit service bureaus may charge a fee for each credit check a merchant or payment service provider may reap savings by being able to generate a reliable risk assessment without recourse to theadditional data214. However, in some cases there may be insufficient amounts of theinternal data206, thebehavioral data210, and theverification data208 for themodel204 to generate a reliable risk assessment, and in such cases theadditional data214 may be needed.
• FIG. 3 illustrates a couple ofscenarios300 from an embodiment of the present disclosure. Specifically,FIG. 3 depicts afirst user344A and asecond user344B at a checkout stage of separate transactions. As can be seen, client data for thefirst user344A is transmitted to therules engine302 of the system of the present disclosure. As noted, the client data may include personally identifiable information and data reflecting interactions of thefirst user344A with the user interfaces during the course of conducting the transaction being finalized. Therules engine302 determines whether, based on the client data received, any rules exist that would preempt risk processing of thefirst user344A by themodel304. If not, the client data of thefirst user344A is passed to themodel304. Based on the client data,internal data306A,verification data308A,behavioral data310A are obtained or generated by themodel304 and processed to yield afirst risk assessment312A. Note that there are various methods by which theinternal data306A, theverification data308A, and thebehavioral data310A may be processed. In one example, theinternal data306A, may be used to generate an internal data score based on details about previous transactions conducted by theuser344A. Similarly, theverification data308A may be used to generate a verification data score indicating a confidence level with the accuracy of information provided by theuser344A. Likewise, thebehavioral data310A may be used to generate a behavioral data score reflecting a level of intent to pay by theuser344A. Each of these three scores may be weighted and/or fed into a risk algorithm, random forest, regression model, neural network, vector machine, other supervised learning algorithm to yield therisk assessment312A. Alternatively, theinternal data306A, theverification data308A, and thebehavioral data310A may be processed to yield a set of variables. An example of the set of variables, may be something like: “time_spent_reading_overall_terms=15,” “time_spent_reading_default_terms=1,” “browser=IE,” “browser_version=10.0,” “time_between_clickdown_submit_and_clickrelease=3,” “transaction_amount=308.00,” “current_debt=0,” “transactions_last 5 months=3,” “last_transaction_payment_method=credit,” “paid_in_full=yes,” “last_transaction_amount=12.99,” “verified_address=yes,” “address_matches_last_transaction_address=yes,” “verified_full_name=yes,” “verified_email=yes,” “verified_phone_number=no,” and so on. The set of variables themselves may be weighted and/or fed into a risk algorithm, random forest, regression model, neural network, vector machine, other supervised learning algorithm to yield therisk assessment312A.
• As can be seen fromFIG. 3, therisk assessment312A suggests that thefirst user344A is estimated to have a low risk of default on payment. Consequently, executable code of the system of the present disclosure, as a result of being executed, may cause thepayment user interface322A to update to display a list of payment/credit options available (“Pre-Pay,” “Credit,” “Debit,” “Pay in 14 Days,”) to thefirst user344A based on therisk assessment312A.
• A similar process is performed for thesecond user344B. That is, client data for thesecond user344B is transmitted to therules engine302 for determination whether, based on the client data, any rules exist that would preempt risk processing of thesecond user344B by themodel304. If not, the client data of thesecond user344B is passed to themodel304. As with thefirst user344A, based on this client data,internal data306B,verification data308B, andbehavioral data310B are obtained or generated by themodel304 and processed in a manner similar to that described for thefirst user344A to yield asecond risk assessment312B. Perhaps in the case of thesecond user344B, an example of the set of variables may be something like: “time_spent_reading_overall_terms=15,” “time_spent_reading_default_terms=10,” “browser=IE,” “browser_version=8.0,” “time_between_clickdown_submit_and_clickrelease=0,” “transaction_amount=1553.00,” “current_debt=0,” “transactions_last 5 months=1,” “last_transaction_payment_method=pay_in_14,” “paid_in_full=no,” “last_transaction_amount=76.95,” “verified_address=yes,” “address_matches_last_transaction_address=no,” “verified_full_name=no,” “verified_email=no,” “verified_phone_number=no,” and so on.
• As can be seen fromFIG. 3, therisk assessment312B suggests that thesecond user344B is estimated to have a high risk of default on payment. Consequently, the executable code of the system of the present disclosure, as a result of being executed, may cause thepayment user interface322B to update the list of payment/credit options available to thesecond user344B based on therisk assessment312B to only allow one method of payment, which is to require the second user344 to pre-pay for the purchase before the merchant will agree to the transaction.
• FIG. 4 illustrates anexample scenario400 of an embodiment of the present disclosure. Specifically,FIG. 4 depicts an example of selecting payment/credit options from a set of payment/credit options442 for display in acheckout user interface422 for the user. The set of payment/credit options442 may be various options for remitting payment for purchases from a particular merchant by users (e.g., credit card, cash on delivery, deferred payment, bank withdrawal, payment service, etc.). Each merchant utilizing the system of the present disclosure may specify which payment/credit options should be included in the set of payment/credit options442. Furthermore, each merchant utilizing the system of the present disclosure may also specify the ranges of fidelity scores necessary to enable the particular payment/credit options of the set of payment/credit options442. In this manner, each merchant utilizing the system can customize which payment/credit options he or she are willing to accept and how much risk they are willing to accept for each particular payment or credit option.
• FIG. 4 illustrates that, for the particular fidelity score generated for the user currently conducting the checkout, the generated fidelity score for the user falls outside of the specified ranges for at least a first payment/credit option442A and a second payment/credit option442B, as well as a second-to-last payment/credit option442N-1. However, the generated fidelity score appears to have fallen within the ranges for a third payment/credit option442C, a fourth payment/credit option442D, and a last payment/credit option442N. As a result, it is seen that after thecheckout user interface442 has been updated, the third payment/credit option442C, the fourth payment/credit option442D, and the last payment/credit option442N are displayed to the user as available methods of payment, while the first payment/credit option442A, the second payment/credit option442B, and the second-to-last payment/credit option442N-1 are not shown to the user. Note that updating thecheckout user interface422 may be achieved with JavaScript. However, alternatively, the updateduser interface422 may be dynamically generated using server-side executable instructions as a security measure in order to prevent a user from accessing hidden payment and credit options. Such server-side executable instructions may be, depending upon implementation, executed by a web server of the merchant or may be executed by a server of a payment service via a call embedded in the merchant website, such as through an HTML iframe, software application, or software development kit.
• FIG. 5 is a flowchart illustrating an example of aprocess500 for determining payment and credit options based on a fidelity score in accordance with various embodiments. Some or all of the process500 (or any other processes described, or variations and/or combinations of those processes) may be performed under the control of one or more computer systems configured with executable instructions and/or other data, and may be implemented as executable instructions executing collectively on one or more processors. The executable instructions and/or other data may be stored on a non-transitory computer-readable storage medium (e.g., a computer program persistently stored on magnetic, optical, or flash media). For example, some or all ofprocess500 may be performed by any suitable system, such as a server in a data center or thecomputing device800 described in conjunction withFIG. 8. Theprocess500 includes a series of operations wherein a request is received by the system performing theprocess500 to determine some payment or credit options for a particular user, client data is received regarding the user, and a fidelity score (i.e., risk assessment score, backspace) is generated and options are displayed based on the fidelity score.
• In502, a request to determine a set of payment or credit options to present to a user in an interface is received. In some implementations, the request is received directly from the client device that the user is using to conduct the transaction. For example, executable code may be embedded in the user interface running in a browser or other application on the client device, that, as a result of being executed, causes the request to be made directly to the system performing theprocess500. In other implementations, the request is received from a computing device of the merchant with whom the user is conducting a transaction. That is, the user may have just clicked a button (e.g., “Proceed to checkout”) which may cause the merchant computing system to submit the request for payment or credit options for the next interface screen to the system performing theprocess500.
• In504, included with the request of502 or in another request subsequent to the request of502, client data comprising personally identifiable information provided by the client device and the user him/herself and a set of information about the interactions between the user and the user interface during the conduct of the transaction may be received. This client data may be used to yield one or more variables and corresponding variable values, from which internal data, verification data, and behavioral data may be obtained, as described in connection withFIGS. 1 and2.
• In506, based on the internal data, verification data, and behavioral data, a fidelity score (also referred to as a risk assessment or risk assessment score) may be generated. The fidelity score may indicate an estimated risk of default by the user conducting the transaction at hand. Consequently, in508, the system performing theprocess500 makes a determination whether the resulting fidelity score is sufficiently reliable to make a determination which payment or credit options to present to the user without recourse to additional information. That is, a statistical certainty value, generated based on the available client data, may be a variance that indicates whether enough information was provided to the model to generate a reliable fidelity score. For example, it may be that behavioral data included some factors suggesting a high risk of default as well as other factors suggesting a low risk of default by the user. In such a case, the system performing theprocess500 may determine that insufficient information is available for reliable fidelity score determination. In some implementations, additionally or alternatively, theprocess500 may determine to obtain additional information if the generated fidelity score, using only the client data received in504, is near a threshold value used for determining whether or not to show a payment/credit option. For example, if a threshold value for displaying a particular payment/credit option is 40 and the generated fidelity score is 41, the system performing theprocess500 may determine to obtain additional information and regenerate the fidelity score. If the regenerated fidelity score indicates a lower risk of default (e.g., 39), the system performing theprocess500 may determine that the regenerated fidelity score is more reflective of the actual security risk of the user, and present the particular payment/credit option to the user.
• As a result of determining that additional information is needed, the system may proceed to510, whereupon the system may make a request to the computing device of a third party entity for additional data; for example, the system may request a credit score of the user from a credit service bureau. With this additional information, the system performing theprocess500 may return to506 to update the fidelity score based at least in part on the additional information. It should be noted, that there may be one or more third-party entities from which the system can obtain additional information. For example, in510, the system may query three different credit service bureaus for three different credit scores for the user. Additionally or alternatively, the system performing the process may repeat the operations of506-10 multiple times, each time at510 querying a different third party entity until a determination on a fidelity score is made. For example, at a first time at510 the system may query a first third-party entity which may provide additional information about the user (e.g., how long the user has resided at the given address, age of the user, etc.). This information may be obtained quickly and inexpensively, but may be less valuable for risk assessment than more expensively obtained additional information. Thus, in this example, if the information from the first third-party entity is determined in508 to be insufficient for generating a reliable fidelity score, the system performing theprocess500 may query a second third party entity, which may be slower or may require a larger fee than the first third-party entity, for more additional information, and so on.
• Lastly, in512, the system may determine which payment or credit options to present to the user for selection and cause the client device of the user to display the determined payment/credit options. For example, if, despite attempting to obtain additional information, the system performing theprocess500 was still unable to generate a reliable fidelity score, the system may err on the side of caution and only present conservative payment/credit options (e.g., “Pre-pay,” “Cash on Delivery,” etc.). Likewise, such conservative payment/credit options may be determined and displayed if the fidelity score for the user indicates that the user is a high risk of default on payment. On the other hand, if the generated fidelity score indicates that the user is at low risk of default, more generous payment/credit options may be determined and presented (e.g., “0% down, no payments for 90 days,” “Pay in 12 easy monthly installments,” etc.). Payment and credit options may be even more granular; for example, an installment payment option on a checkout webpage may include a slider bar allowing the user to select the number of as many installments (e.g., three months, six months, 12 months, 24 months, etc.) as a fidelity score may allow. Note that one or more of the operations performed in502-20 may be performed in various orders and combinations, including in parallel.
• FIG. 6 is a flowchart illustrating an example of aprocess600 for displaying payment and credit options in a user interface in accordance with various embodiments. Some or all of the process600 (or any other processes described, or variations and/or combinations of those processes) may be performed under the control of one or more computer systems configured with executable instructions and/or other data, and may be implemented as executable instructions executing collectively on one or more processors. The executable instructions and/or other data may be stored on a non-transitory computer-readable storage medium (e.g., a computer program persistently stored on magnetic, optical, or flash media). For example, some or all of theprocess600 may be performed by any suitable system, such as a server in a data center or by thecomputing device800 described in conjunction withFIG. 8. Theprocess600 illustrates in further detail the operations performed in512 ofFIG. 5.
• In602, the fidelity score generated by the system performing theprocess500 ofFIG. 5 is obtained by the system performing theprocess600. Note that the systems performing theprocesses500 and600 may be the same or different systems. In604, a set of potential payment options are obtained. Each of the payment/credit options of the set may be associated with a fidelity score range. For example, a fidelity score range of 0-60 may be associated with the option “Pay by credit card.” In other words, if the resulting fidelity score falls within a range of 0-60, the option to pay by credit card may be displayed in the interface for the user. The set of payment/credit options may be arranged in various orders, such as the most conservative payment/credit options first and the most generous payment/credit options at the last of the set. Thus, starting with the first payment/credit option of the set, the system performing the process may proceed to606.
• In606, the system performing theprocess600 may determine whether the fidelity score obtained in602 falls within the range associated with the current payment/credit option being considered. In some implementations, the fidelity score may indicate an estimated risk of default, with a higher number meaning greater risk. In other implementations, the fidelity score may be generated such that a lower number indicates a greater risk. In still other implementations, a negative fidelity score may indicate an above average risk of default while in a positive fidelity score may indicate a below average risk of default, or vice versa. In some implementations, certain payment and credit options may be shown to or hidden from the user if the fidelity score crosses/exceeds a particular high threshold, while in other implementations, certain payment and credit options may be shown to or hidden from the user if the fidelity score crosses/falls below a particular low threshold. In theprocess600, payment and credit options are shown if the fidelity score lies within a range of values (e.g., an upper and lower threshold). If the fidelity score does not fall within the range associated with the current payment/credit option, the system performing theprocess600 may return to604 to obtain the next payment/credit option. However, if the fidelity score falls within the range of the current payment/credit option, the system performing theprocess600 may proceed to608 to select the payment/credit option for display in the checkout user interface.
• In610, the system performing theprocess600 determines whether it has assessed all of the possible payment and credit options in the set of payment/credit options. If not, the system may return to604 to retrieve the next payment/credit option and repeat the operations of604-10. However, if the last payment/credit option has been processed, the system may proceed to612, whereupon the selected payment/credit options from608 may be displayed in a checkout user interface for finalizing the transaction. For example, if the fidelity score is 40 (i.e., 40% chance of default of payment), and a first payment/credit option has a range of 0-20, the fidelity score can be seen to be out of range of the payment/credit options. Consequently, the operations of604 retrieved a second payment/credit option which has a range of 0-35, which again falls short of the fidelity score in this example. However, if the operations of604 retrieved a third payment/credit option that has a range of 0-55, it can be seen that the user qualifies for this payment/credit option. Consequently, in608 the third payment/credit option would be among the payment/credit options selected. This process may repeat from604 through610 until all possible payment and credit options are considered, and then in612 the third payment/credit option and any others whose range overlapped the fidelity score and selected in608 may be displayed on the checkout user interface for the user. It is contemplated that theprocess600 may be one of several methods for selecting payment and credit options based on fidelity score may be possible. Note also that one or more of the operations performed in602-20 may be performed in various orders and combinations, including in parallel.
• FIG. 7 is a flowchart illustrating an example of aprocess700 for generating a fidelity score in accordance with various embodiments. Some or all of the process700 (or any other processes described, or variations and/or combinations of those processes) may be performed under the control of one or more computer systems configured with executable instructions and/or other data, and may be implemented as executable instructions executing collectively on one or more processors. The executable instructions and/or other data may be stored on a non-transitory computer-readable storage medium (e.g., a computer program persistently stored on magnetic, optical, or flash media). For example, some or all ofprocess700 may be performed by any suitable system, such as a server in a data center or by thecomputing device800 described in conjunction withFIG. 8. Theprocess700 includes a series of operations wherein sets of behavioral data, verification data, and internal data are transformed into a set of variables and corresponding variable values, which are then input into a data model to generate the fidelity score.
• In702, behavioral data is transformed into one or more variables and corresponding variable values. As noted, behavioral data may include data about the interactions between the user and the user interface being used to conduct a transaction. Examples may include variables such as time_between_clickdown_submit_and_clickrelease, user_misspelled_last_name, and time_spent_reading_terms_and_conditions.
• In704, verification data may be transformed into one or more variables and corresponding variable values. As noted, verification data may be data verifying one or more elements of personally identifiable information provided by the user. Examples of variables generated from verification data include variables such as email_associated_with_user_name, user_name_associated_with_phone_number, user_name_associated_with_address, and so on. Values for the verification data variables may be obtained from internal data (e.g., data regarding previous transactions conducted by the user, etc.) or may be obtained with reference to an external data source, such as a credit bureau service or a telephone directory service.
• In706, internal data is transformed into one or more variables and corresponding variable values. As noted, internal data may include details regarding previous transactions conducted by the user. Examples of variables generated from internal data may include variables such as number_of_purchases_in_last_3 months, amount_of_last_purchase, payment_method_of_last_purchase, and so on.
• In708, the system performing theprocess700 may determine whether additional data is available. For example, if a previous attempt to generate a fidelity score was made, and, per a determination such as the determination made via the operations of508 ofFIG. 5, the available behavioral data, verification data, and internal data was insufficient to generate a reliable fidelity score, the system of the present disclosure may have made a call to an external data source, such as a credit bureau, to obtain additional information. Thus, if such additional information is available, the system performing theprocess700 may proceed to710, whereupon the additional data is transformed into one or more variables having corresponding values. An example of such a variable may be credit_score.
• In712, the various variables and their corresponding values generated in steps702-10 may be passed through a data model. It is contemplated that the data model may be any of various types of data models, such as a random forest generated from a large data set of similar data, neural network, vector machine, other supervised learning algorithm, or some other regression model generated from a sample set representative of typical user data for conducting transactions in the manner described in the present disclosure. The output of the model may be indicative of a risk of default on payment by the present user. Upon generating the output, in714, the output may be provided to the merchant, some other entity, or to an internal process for determining which payment and credit options to present to the user in an interface, such as a checkout-type interface.
• As noted, a statistical certainty value may accompany a fidelity score, indicating a whether enough information was provided to the model to generate a reliable fidelity score. That is, if some information was unavailable to be provided to the fidelity score, the statistical certainty value may indicate, if the missing information were available and favored positive or negative risk assessment, whether the fidelity score would change such that payment and credit options provided to the user would also change. The statistical certainty value may be output in various formats. For example, the statistical certainty value may be in the form of a variance/standard error (e.g., standard deviation) or other value indicative of how the fidelity score could change based on worst case/best case scenario. In one example, the model determines a fidelity score for a particular user that indicates that the user has a 5% chance of default on payment. However, this fidelity score may have been generated by the model without having certain information (i.e., some behavioral data, verification data, and/or internal data may have been unavailable). However a statistical certainty value may indicate that, if certain unavailable information favored higher risk (e.g., worst-case information), the user's risk of default could rise to 30%. In this case, the system of the present disclosure may make a determination whether, based on the potential risk of default of 30%, the cost of obtaining additional data from an external source is worth mitigating the potential risk. It may be that the system determines that 30% is an acceptable risk when weighed against the costs in time and money associated with obtaining the additional data. Note too that one or more of the operations performed in702-20 may be performed in various orders and combinations, including in parallel.
• In some embodiments, the system of the present disclosure is configured as a service that provides the fidelity score, and, in some cases, as the statistical certainty value based on internal data, verification data, and client data provided by a subscriber to the service. For example, the service may be offered to subscribers as a faster and cheaper alternative for obtaining credit risk data than traditional credit bureau services. In some embodiments, the system of the present disclosure is configured to update a checkout page with items other than payment and credit options, or may be configured to update one or more webpages with information different than payment and credit options but based on collected client data. For example, if the client data (i.e., personally identifiable information and behavioral data) suggests that the user is within a certain demographic, such as age group, the system of the present disclosure may present product offers believed to be of interest to such an age group, such as clothing of certain styles and so on. As another example, if the client data suggests that the user is within a certain age group or participates in certain high risk activities (such as conducting transactions while in a moving vehicle), this information may be usable by the system in determining insurance premiums, loan interest rates, whether to offer an option for a reverse mortgage, and so on.
• In the context of describing disclosed embodiments, unless otherwise specified, use of expressions regarding executable instructions (also referred to as code, applications, agents, etc.) performing operations that “instructions” do not ordinarily perform unaided (e.g., transmission of data, calculations, etc.) denote that the instructions are being executed by a machine, thereby causing the machine to perform the specified operations.
• Embodiments of the disclosure can be described in view of the following clauses:
• • 1. A computer-implemented method, comprising:
• under the control of one or more computer systems configured with first executable instructions,
• • providing second executable instructions to a first computing device associated with a user that, as a result of being executed by the first computing device, causes the first computing device to collect, as a set of client data, personally identifiable information and a set of measurements associated with interactions by the user with a user interface of the first computing device;
  • obtaining a set of internal data associated with the user, the set of internal data associated with one or more previous transactions involving the user;
  • obtaining a set of verification data associated with the user, the set of verification data including identification verifying that the personally identifiable information is accurate;
  • transforming the set of client data, the set of internal data, and the set of verification data into one or more variables;
  • generating a fidelity score based at least in part on the one or more variables, the fidelity score indicating a risk of default on the transaction by the user;
  • based at least in part on a comparison of the fidelity score against a threshold, determining not to request, from a second computing device, additional information associated with the user; and
  • updating the user interface based at least in part on the fidelity score.
  • 2. The computer-implemented method of clause 1, wherein:
  • the user is a first user;
  • the set of client data is a first set of client data;
  • the personally identifiable information is first personally identifiable information;
  • the user interface is a first user interface;
  • the set of internal data is a first set of internal data;
  • the set of verification data is a first set of verification data;
  • the one or more variables are a one or more first variables;
  • the fidelity score is a first fidelity score; and
  • the method further comprises:
    • providing the second executable instructions to a third computing device associated with a second user that, as a result of being executed by the third computing device, causes the third computing device to collect a second set of client data associated with the second user;
    • obtaining a second set of internal data associated with the second user, the second set of internal data associated with one or more previous transactions involving the second user;
    • obtaining a second set of verification data associated with the user, the second set of verification data including identification verifying that second personally identifiable information in the second set of client data is accurate;
    • transforming the second set of client data, the second set of internal data, and the second set of verification data into one or more second variables;
    • generating a second fidelity score based at least in part on the one or more second variables, the second fidelity score indicating a risk of default on the transaction by the second user;
    • based at least in part on a comparison of the second fidelity score against the threshold, determining to submit a request, to the second computing device, for additional information associated with the second user;
    • receiving the additional information from the second computing device in response to the request;
    • updating the second fidelity score based at least in part on the additional information to yield an updated second fidelity score; and
  • updating a second user interface based at least in part on the updated second fidelity score.
  • 3. The computer-implemented method of clause 1 or 2, further comprising generating a statistical certainty value indicating a variance of the fidelity score, and updating the user interface is further based at least in part on the statistical certainty value.
  • 4. The computer-implemented method of any of clauses 1 to 3, wherein the user interface is updated based at least in part on the fidelity score to provide one or more payment options for the transaction.
  • 5. A system, comprising:
  • one or more processors;
  • memory including instructions that, as a result of being executed by the one or more processors, cause the system to:
    • obtain a set of client data, including personally identifiable information of a user and one or more measurements associated with interactions by the user with an interface;
    • obtain a set of internal data associated with the user;
    • obtain a set of verification data associated with the user;
    • generate a score based at least in part on the set of client data, the set of internal data, and the set of verification data; and
    • determine based at least in part the score whether to:
      • request, from a third party entity, additional information associated with the user; and
      • update the score based at least in part the additional information; and
  • update the interface based at least in part on the score.
  • 6. The system of clause 5, wherein the set of client data includes one or more of:
  • a type and version of web browser being used by the user,
  • a type of operating system installed on a computing device being used by the user, or
  • a device identifier.
  • 7. The system of clause 5 or 6, wherein the one or more measurements are obtained from one or more of:
  • a user input device,
  • a gyroscope,
  • an image sensor,
  • accelerometer,
  • global positioning receiver, or
  • microphone.
  • 8. The system of any of clauses 5 to 7, wherein set of internal data includes one or more of:
  • whether the user has made a payment on a previous transaction,
  • a payment type of the previous transaction,
  • an amount owed from the previous transaction, or
  • an amount paid on the previous transaction.
  • 9. The system of any of clauses 5 to 8, wherein the set of verification data includes one or more of:
  • confirmation that a name of the user is associated with a geographical location provided by the user,
  • confirmation that the name of the user is associated with an email address provided by the user, or
  • confirmation that the name of the user is associated with a date of birth provided by the user.
  • 10. The system of any of clauses 5 to 9, wherein the set of client data includes a set of measurements, individual measurements of the set of measurements including:
  • an action performed by the user to an object in the interface;
  • an identity of the object; and
  • a time value indicating a time at which the action was performed on the object.
  • 11. The system of any of clauses 5 to 10, wherein the additional information includes one or more of:
  • a credit score of the user,
  • credit history of the user, or
  • public records associated with the user.
  • 12. The system of any of clauses 5 to 11, wherein the set of verification data is obtained from an entity external to the system.
  • 13. A non-transitory computer-readable storage medium having stored thereon executable instructions that, as a result of being executed by one or more processors of a computer system, cause the computer system to at least:
  • obtain a first set of data associated with interactions by a user conducting a current transaction using an interface of a computing device;
  • obtain a second set of data associated with a previous transaction conducted by the user;
  • obtain a third set of data associated verification of an identity of the user;
  • generate a first score based at least in part on the first set of data, the second set of data, and the third set of data; and
  • if the first score does not cross a threshold, update the interface based at least in part on the first score; and
  • if the first score crosses the threshold:
    • obtain, from an external entity, a fourth set of data associated with the user;
    • generate a second score based at least in part on the fourth set of data; and
  • update the interface based at least in part on the second score.
  • 14. The non-transitory computer-readable storage medium of clause 13, wherein the executable instructions that cause the computer system to update the interface based at least in part on the first score or the second score further include executable instructions that cause the computer system to:
  • determine a subset of payment options, based at least in part on the first score or second score, from a set of payment options; and
  • update the interface to present the subset of payment options to the user.
  • 15. The non-transitory computer-readable storage medium ofclause 13 or 14, wherein the executable instructions that cause the computer system to update the interface based at least in part on the first score or the second score further include executable instructions that cause the computer system to:
  • determine one or more product or services offerings based at least in part on the first score or second score; and
  • update the interface to present one or more product or services offerings to the user.
  • 16. The non-transitory computer-readable storage medium of any of clauses 13 to 15, wherein the first set of data includes one or more of:
  • a geographic address of the user,
  • a telephone number of the user, or
  • an email address of the user.
  • 17. The non-transitory computer-readable storage medium of any of clauses 13 to 16, wherein:
  • the first set of data is obtained by the computer system by execution of code embedded in a web page of a merchant;
  • the computer system is a computer system of a payment service provider different from the merchant; and
  • the code, as a result of being executed, causes the first set of data to be transmitted to the computer system.
  • 18. The non-transitory computer-readable storage medium of any of clauses 13 to 17, wherein:
  • the interface is a web page hosted by a first entity;
  • the computer system is a computer system of a second entity different from the user and the first entity; and
  • the executable instructions that cause the computer system to update the interface include executable instructions that cause the computer system to provide at least a portion of the web page of the first entity for display on the computing device of the user.
  • 19. The non-transitory computer-readable storage medium of any of clauses 13 to 18, wherein the instructions further include instructions that cause the computer system to generate a variance for the first score.
  • 20. The non-transitory computer-readable storage medium of clause 19, wherein the executable instructions that cause the computer system to obtain the fourth set of data, generate the second score, and update the interface based at least in part the second score are further executed if the first score combined with the variance crosses the threshold.
• FIG. 8 is an illustrative, simplified block diagram of anexample computing device800 that may be used to practice at least one embodiment of the present disclosure. In various embodiments, thecomputing device800 may be used to implement any of the systems illustrated herein and described above. For example, thecomputing device800 may be configured for use as a data server, a web server, a portable computing device, a personal computer, or any electronic computing device. As shown inFIG. 8, thecomputing device800 may include one ormore processors802 that may be configured to communicate with, and are operatively coupled to, a number of peripheral subsystems via abus subsystem804. Theprocessors802 may be utilized for the traversal of decision trees in random forest of supervised models in embodiments of the present disclosure (e.g., cause the evaluation of inverse document frequencies of various search terms, etc.). These peripheral subsystems may include astorage subsystem806, comprising amemory subsystem808 and afile storage subsystem810, one or more userinterface input devices812, one or more userinterface output devices814, and anetwork interface subsystem816.Such storage subsystem806 may be used for temporary or long-term storage of information such as details associated with transactions described in the present disclosure, databases of historical records described in the present disclosure, and storage of decision rules of the supervised models in the present disclosure).
• Thebus subsystem804 may provide a mechanism for enabling the various components and subsystems ofcomputing device800 to communicate with each other as intended. Although thebus subsystem804 is shown schematically as a single bus, alternative embodiments of the bus subsystem utilize multiple busses. Thenetwork interface subsystem816 may provide an interface to other computing devices and networks. Thenetwork interface subsystem816 may serve as an interface for receiving data from, and transmitting data to, other systems from thecomputing device800. For example, thenetwork interface subsystem816 may enable a data technician to connect the device to a wireless network such that the data technician may be able to transmit and receive data while in a remote location, such as a user data center. Thebus subsystem804 may be utilized for communicating data, such as details, search terms, and so on to the supervised model of the present disclosure, and may be utilized for communicating the output of the supervised model to the one ormore processors802 and to merchants and/or creditors via thenetwork interface subsystem816.
• The userinterface input devices812 may include one or more user input devices, such as a keyboard, pointing devices such as an integrated mouse, trackball, touchpad, or graphics tablet, a scanner, a barcode scanner, a touch screen incorporated into the display, audio input devices such as voice recognition systems, microphones, and other types of input devices. In general, use of the term “input device” is intended to include all possible types of devices and mechanisms for inputting information to thecomputing device800. The one or more userinterface output devices814 may include a display subsystem, a printer, or non-visual displays such as audio output devices, etc. The display subsystem may be a cathode ray tube (CRT), a flat-panel device such as a liquid crystal display (LCD), light emitting diode (LED) display, or a projection or other display device. In general, use of the term “output device” is intended to include all possible types of devices and mechanisms for outputting information from thecomputing device800. The one ormore output devices814 may be used, for example, to present user interfaces to facilitate user interaction with applications performing processes described herein and variations therein, where such interaction may be appropriate.
• Thestorage subsystem806 may provide a computer-readable storage medium for storing the basic programming and data constructs that may provide the functionality of at least one embodiment of the present disclosure. The applications (programs, code modules, instructions) that, as a result of being executed by one or more processors, may provide the functionality of one or more embodiments of the present disclosure, and may be stored in thestorage subsystem806. These application modules or instructions may be executed by the one ormore processors802. Thestorage subsystem806 may additionally provide a repository for storing data used in accordance with the present disclosure. Thestorage subsystem806 may comprise amemory subsystem808 and a file/disk storage subsystem810.
• Thememory subsystem808 may include a number of memories, including a main random access memory (RAM)818 for storage of instructions and data during program execution and a read only memory (ROM)820 in which fixed instructions may be stored. Thefile storage subsystem810 may provide a non-transitory persistent (non-volatile) storage for program and data files, and may include a hard disk drive, a floppy disk drive along with associated removable media, a Compact Disk Read Only Memory (CD-ROM) drive, an optical drive, removable media cartridges, and other like storage media.
• Thecomputing device800 may include at least onelocal clock824. Thelocal clock824 may be a counter that represents the number of ticks that have transpired from a particular starting date and may be located integrally within thecomputing device800. Thelocal clock824 may be used to synchronize data transfers in the processors for thecomputing device800 and all of the subsystems included therein at specific clock pulses and may be used to coordinate synchronous operations between thecomputing device800 and other systems in a data center. In one embodiment, thelocal clock824 is an atomic clock. In another embodiment, the local clock is a programmable interval timer.
• Thecomputing device800 may be of various types, including a portable computer device, tablet computer, a workstation, or any other device described below. Additionally, thecomputing device800 may include another device that may be connected to thecomputing device800 through one or more ports (e.g., USB, a headphone jack, Lightning connector, etc.). The device that may be connected to thecomputing device800 may include a plurality of ports configured to accept fiber-optic connectors. Accordingly, this device may be configured to convert optical signals to electrical signals that may be transmitted through the port connecting the device to thecomputing device800 for processing. Due to the ever-changing nature of computers and networks, the description of thecomputing device800 depicted inFIG. 8 is intended only as a specific example for purposes of illustrating the preferred embodiment of the device. Many other configurations having more or fewer components from the system depicted inFIG. 8 are possible.
• The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. However, it will be evident that various modifications and changes may be made thereunto without departing from the broader spirit and scope of the invention as set forth in the claims.
• Other variations are within the spirit of the present disclosure. Thus, while the disclosed techniques are susceptible to various modifications and alternative constructions, certain illustrated embodiments thereof are shown in the drawings and have been described above in detail. It should be understood, however, that there is no intention to limit the invention to the specific form or forms disclosed, but on the contrary, the intention is to cover all modifications, alternative constructions and equivalents falling within the spirit and scope of the invention, as defined in the appended claims.
• The use of the terms “a” and “an” and “the” and similar referents in the context of describing the disclosed embodiments (especially in the context of the following claims) are to be construed to cover both the singular and the plural, unless otherwise indicated herein or clearly contradicted by context. The terms “comprising,” “having,” “including” and “containing” are to be construed as open-ended terms (i.e., meaning “including, but not limited to,”) unless otherwise noted. The term “connected,” where unmodified and referring to physical connections, is to be construed as partly or wholly contained within, attached to or joined together, even if there is something intervening. Recitation of ranges of values herein are merely intended to serve as a shorthand method of referring individually to each separate value falling within the range, unless otherwise indicated herein and each separate value is incorporated into the specification as if it were individually recited herein. The use of the term “set” (e.g., “a set of items”) or “subset” unless otherwise noted or contradicted by context, is to be construed as a nonempty collection comprising one or more members. Further, unless otherwise noted or contradicted by context, the term “subset” of a corresponding set does not necessarily denote a proper subset of the corresponding set, but the subset and the corresponding set may be equal.
• Conjunctive language, such as phrases of the form “at least one of A, B, and C,” or “at least one of A, B and C,” unless specifically stated otherwise or otherwise clearly contradicted by context, is otherwise understood with the context as used in general to present that an item, term, etc., may be either A or B or C, or any nonempty subset of the set of A and B and C. For instance, in the illustrative example of a set having three members, the conjunctive phrases “at least one of A, B, and C” and “at least one of A, B and C” refer to any of the following sets: {A}, {B}, {C}, {A, B}, {A, C}, {B, C}, {A, B, C}. Thus, such conjunctive language is not generally intended to imply that certain embodiments require at least one of A, at least one of B and at least one of C each to be present.
• Operations of processes described herein can be performed in any suitable order unless otherwise indicated herein or otherwise clearly contradicted by context. Processes described herein (or variations and/or combinations thereof) may be performed under the control of one or more computer systems configured with executable instructions and may be implemented as code (e.g., executable instructions, one or more computer programs or one or more applications) executing collectively on one or more processors, by hardware or combinations thereof. The code may be stored on a computer-readable storage medium, for example, in the form of a computer program comprising a plurality of instructions executable by one or more processors. The computer-readable storage medium may be non-transitory.
• The use of any and all examples, or exemplary language (e.g., “such as”) provided herein, is intended merely to better illuminate embodiments of the invention and does not pose a limitation on the scope of the invention unless otherwise claimed. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the invention.
• Embodiments of this disclosure are described herein, including the best mode known to the inventors for carrying out the invention. Variations of those embodiments may become apparent to those of ordinary skill in the art upon reading the foregoing description. The inventors expect skilled artisans to employ such variations as appropriate and the inventors intend for embodiments of the present disclosure to be practiced otherwise than as specifically described herein. Accordingly, the scope of the present disclosure includes all modifications and equivalents of the subject matter recited in the claims appended hereto as permitted by applicable law. Moreover, any combination of the above-described elements in all possible variations thereof is encompassed by the scope of the present disclosure unless otherwise indicated herein or otherwise clearly contradicted by context.
• All references, including publications, patent applications, and patents, cited herein are hereby incorporated by reference to the same extent as if each reference were individually and specifically indicated to be incorporated by reference and were set forth in its entirety herein.

Claims (20)

1. A computer-implemented method, comprising:

under the control of one or more computer systems that execute instructions,

providing second executable instructions to a first computing device associated with a user that, as a result of being executed by the first computing device, causes the first computing device to:

collect a set of client data that includes:

personally identifiable information about the user;

an identifier associated with the first computing device; and

a set of measurements associated with interactions between the user and a user interface of the first computing device, individual measurements of the set of measurements including:

 an action performed by the user to an object in the user interface;

 an identity of the object; and

 a time value indicating a time at which the action was performed on the object; and

provide the set of client data to the one or more computer systems;

obtaining a set of internal data associated with one or more previous transactions involving the user;

obtaining a set of verification data verifying that the personally identifiable information is accurate;

transforming the set of client data, the set of internal data, and the set of verification data into one or more variables;

generating a fidelity score based at least in part on the one or more variables; and

updating the user interface based at least in part on the fidelity score.

2. The computer-implemented method ofclaim 1, the method further comprising:

providing the second executable instructions to a third computing device associated with a second user that, as a result of being executed by the third computing device, causes the third computing device to collect a second set of client data associated with the second user;

obtaining a second set of internal data associated with the second user, the second set of internal data associated with one or more previous transactions involving the second user;

obtaining a second set of verification data associated with the user, the second set of verification data including identification verifying that second personally identifiable information in the second set of client data is accurate;

transforming the second set of client data, the second set of internal data, and the second set of verification data into one or more second variables;

generating a second fidelity score based at least in part on the one or more second variables, the second fidelity score indicating a risk of default on the transaction by the second user;

based at least in part on a comparison of the second fidelity score against a threshold, determining to submit a request, to the second computing device, for additional information associated with the second user;

receiving the additional information from the second computing device in response to the request;

updating the second fidelity score based at least in part on the additional information to yield an updated second fidelity score; and

updating a second user interface based at least in part on the updated second fidelity score.

3. The computer-implemented method ofclaim 1, further comprising generating a statistical certainty value indicating a variance of the fidelity score, and updating the user interface is further based at least in part on the statistical certainty value.

4. The computer-implemented method ofclaim 1, wherein the user interface is updated based at least in part on the fidelity score to provide one or more payment or credit options for the transaction.

5. A system, comprising:

one or more processors; and

memory including instructions that, as a result of being executed by the one or more processors, cause the system to:

obtain a set of client data, including:

personally identifiable information of a user;

an identifier associated with a computing device associated with the user; and

one or more measurements associated with interactions by the user with an interface, each of the one or more measurements including:

an action performed by the user to an object in the interface;

an identity of the object; and

a time value indicating a time at which the action was performed on the object;

obtain a set of internal data associated with the user;

obtain a set of verification data associated with the user;

generate a score based at least in part on the set of client data, the set of internal data, and the set of verification data;

determine, based at least in part the score, whether to:

request, from a third party entity, additional information associated with the user; and

update the score based at least in part the additional information; and

update the interface based at least in part on the score.

6. The system ofclaim 5, wherein the set of client data further includes one or more of:

a type and version of web browser being used by the user, or

a type of operating system installed on a computing device being used by the user.

7. The system ofclaim 5, wherein the one or more measurements are obtained from one or more of:

a user input device,

a gyroscope,

an image sensor,

accelerometer,

global positioning receiver, or

microphone.

8. The system ofclaim 5, wherein set of internal data includes one or more of:

whether the user has made a payment on a previous transaction,

a payment type of the previous transaction,

an amount owed from the previous transaction, or

an amount paid on the previous transaction.

9. The system ofclaim 10, wherein the set of verification data includes one or more of:

confirmation that a name of the user is associated with a geographical location provided by the user,

confirmation that the name of the user is associated with an email address provided by the user, or

confirmation that the name of the user is associated with a date of birth provided by the user.

10. The system ofclaim 5, wherein the set of verification data provides verification that at least a subset of the personally identifiable information of the user is accurate.

11. The system ofclaim 5, wherein the additional information includes one or more of:

a credit score of the user,

credit history of the user, or

public records associated with the user.

12. The system ofclaim 5, wherein the set of verification data is obtained from an entity external to the system.

13. A non-transitory computer-readable storage medium having stored thereon executable instructions that, as a result of being executed by one or more processors of a computer system, cause the computer system to at least:

obtain a first set of data associated with interactions by a user conducting a current transaction using an interface of a computing device associated with the user, the first set of data indicating:

an identifier associated with the computing device;

an action performed by the user to an object in the interface;

an identity of the object; and

a time value indicating a time at which the action was performed on the object;

obtain a second set of data associated with a previous transaction conducted by the user;

obtain a third set of data associated with verification of an identity of the user;

generate a first score based at least in part on the first set of data, the second set of data, and the third set of data;

on a condition that the first score does not reach a value relative to a threshold, update the interface based at least in part on the first score; and

on a condition that the first score reaches a value relative to the threshold:

obtain, from an external entity, a fourth set of data associated with the user;

generate a second score based at least in part on the fourth set of data; and

update the interface based at least in part on the second score.

14. The non-transitory computer-readable storage medium ofclaim 13, wherein the executable instructions that cause the computer system to update the interface based at least in part on the first score or the second score further include executable instructions that cause the computer system to:

determine a subset of options for payment or credit, based at least in part on the first score or second score, from a set of options for payment or credit; and

update the interface to present the subset of options to the user.

15. The non-transitory computer-readable storage medium ofclaim 13, wherein the executable instructions that cause the computer system to update the interface based at least in part on the first score or the second score further include executable instructions that cause the computer system to:

determine one or more product or service offerings based at least in part on the first score or second score; and

update the interface to present one or more product or service offerings to the user.

16. The non-transitory computer-readable storage medium ofclaim 13, wherein the first set of data includes one or more of:

a geographic address of the user,

a telephone number of the user, or

an email address of the user.

17. The non-transitory computer-readable storage medium ofclaim 13, wherein:

the first set of data is obtained by the computer system by execution of code embedded in a web page of a merchant;

the computer system is a computer system of a payment service provider different from the merchant; and

the code, as a result of being executed, causes the first set of data to be transmitted to the computer system.

18. The non-transitory computer-readable storage medium ofclaim 13, wherein:

the interface is a web page hosted by a first entity;

the computer system is a computer system of a second entity different from the user and the first entity; and

the executable instructions that cause the computer system to update the interface include executable instructions that cause the computer system to provide at least a portion of the web page of the first entity for display on the computing device of the user.

19. The non-transitory computer-readable storage medium ofclaim 13, wherein the instructions further include instructions that cause the computer system to generate a variance for the first score.

20. The non-transitory computer-readable storage medium ofclaim 19, wherein the executable instructions that cause the computer system to obtain the fourth set of data, generate the second score, and update the interface based at least in part the second score are further executed if the first score combined with the variance crosses the threshold.

Images