Abstract: The system and methods described herein allow users to give their applicant information when seeking to purchase a good with financing from multiple potential lenders, and may be pre-screened by one or more rule sets implemented by a marketplace client in an eligibility analysis to ultimately submit applicant information to a subset of the multiple potential lenders which are found to be suitable for lending to an applicant based on the applicant information, wherein lender microservices are then run in a jailed, firewalled, and self-contained, autonomous environment, and the results of said lender microservices are reported to the user and may be used to change the one or more rule sets implemented by the marketplace client for future pre-screening of applicants.

Abstract: The system and methods described herein allow users to apply for a purchase of a good from multiple providers using provider specific methodologies for generating offers for the product. For example, the system described herein may include a multi-layer architecture that includes interactive micro-services that communicate together in a bi-directional manner to create a normalized process for the purchase of a good, such as commercial goods/products (e.g. a vehicle) or real property. The micro-services may assess prequalification for a loan or financing for a good, followed by determining eligibility of the good for financing, and further followed by calculating pricing details for loans (e.g. for financing purchase of the good) that would be offered for a consumer's particular financial credentials, for each of a plurality of lenders. Prequalification and pricing may be performed on a good by good basis, or for a plurality of goods near or substantially simultaneously.

Abstract: The system and methods described herein allow users to give their applicant information when seeking to submit an inquiry associated with a product provided by at least one entity, and have various lender microservices run in parallel, segregated by entity, in a jailed and self-contained, autonomous environment. The result of these microservices may be returned as a response to the inquity, being determined autonomously for each respective entity based on one or more respective rule sets or executable logic for each respective entity. Payloads for multiple entities may be combined in a single output from the jailed and self-contained environment due to outputs from the environment being encrypted in a universal format, wherein the outputs are decrypted in a user session in an application, allowing the user to see the results of the respective responses of each of the at least one entity, to their inquiry.

Abstract: A self-service lender portal provides lenders with a suite of tools for interacting with a multi-lender architecture configured to provide loan applicants with automated pre-qualification and eligibility evaluation for multiple candidate lenders. The lender portal provides lenders with an interface for uploading rule sets defining lending and eligibility criteria, downloading operational data generated from processing loan applicant information, generating and managing security keys for encryption and decryption of sensitive data, and managing access policies for providing single sign-on by interfacing with the lender's own identity management systems.

Abstract: Described herein is a system for providing version control across APIs. In an embodiment, an application of a client device may transmit communications to a service application API that are in a format not accepted by the service application API, using the application API. A central (or public) API may receive the communication transmitted by the application's API. The central API may identify the versions of the application's API and the service application API. The central API may format the communication based on the mapped fields, to a format accepted by the service application API. The central API 106 may forward the formatted communication to the service application.

Abstract: A system for interfacing with a decisioning service from a third-party domain. A backend system may receive a request to interface with the decisioning service to generate a prequalification result for a user for a specified product, in response to the actuation of a button included in a third-party web domain rendering a product. The backend system may execute a call on a website of the decisioning service. The backend system may receive the product information from the button. The backend system may generate the website within the third-party domain, including a request for information about the user, in response to executing the call to the website. The backend system may transmit a request for generating prequalification result for the product to the decisioning service. The backend system may receive the prequalification result from the decisioning service.

Abstract: Described herein is a system for providing version control across APIs. In an embodiment, an application of a client device may transmit communications to a service application API that are in a format not accepted by the service application API, using the application API. A central (or public) API may receive the communication transmitted by the application's API. The central API may identify the versions of the application's API and the service application API. The central API may format the communication based on the mapped fields, to a format accepted by the service application API. The central API 106 may forward the formatted communication to the service application.

Abstract: A system for interfacing with a decisioning service from a third-party domain. A backend system may receive a request to interface with the decisioning service to generate a prequalification result for a user for a specified product, in response to the actuation of a button included in a third-party web domain rendering a product. The backend system may execute a call on a website of the decisioning service. The backend system may receive the product information from the button. The backend system may generate the website within the third-party domain, including a request for information about the user, in response to executing the call to the website. The backend system may transmit a request for generating prequalification result for the product to the decisioning service. The backend system may receive the prequalification result from the decisioning service.

Abstract: The system and methods described herein allow users to apply for a purchase of a good from multiple providers using provider specific methodologies for generating offers for the product. For example, the system described herein may include a multi-layer architecture that includes interactive micro-services that communicate together in a bi-directional manner to create a normalized process for the purchase of a good, such as commercial goods/products (e.g. a vehicle) or real property. The micro-services may assess prequalification for a loan or financing for a good, followed by determining eligibility of the good for financing, and further followed by calculating pricing details for loans (e.g. for financing purchase of the good) that would be offered for a consumer's particular financial credentials, for each of a plurality of lenders. Prequalification and pricing may be performed on a good by good basis, or for a plurality of goods near or substantially simultaneously.

Abstract: Described herein is a system for providing version control across APIs. In an embodiment, an application of a client device may transmit communications to a service application API that are in a format not accepted by the service application API, using the application API. A central (or public) API may receive the communication transmitted by the application's API. The central API may identify the versions of the application's API and the service application API. The central API may format the communication based on the mapped fields, to a format accepted by the service application API. The central API 106 may forward the formatted communication to the service application.

Abstract: A system for interfacing with a decisioning service from a third-party domain. A backend system may receive a request to interface with the decisioning service to generate a prequalification result for a user for a specified product, in response to the actuation of a button included in a third-party web domain rendering a product. The backend system may execute a call on a website of the decisioning service. The backend system may receive the product information from the button. The backend system may generate the website within the third-party domain, including a request for information about the user, in response to executing the call to the website. The backend system may transmit a request for generating prequalification result for the product to the decisioning service. The backend system may receive the prequalification result from the decisioning service.

Abstract: The system and methods described herein allow users to apply for a purchase of a good from multiple providers using provider specific methodologies for generating offers for the product. For example, the system described herein may include a multi-layer architecture that includes interactive micro-services that communicate together in a bi-directional manner to create a normalized process for the purchase of a good, such as commercial goods/products (e.g. a vehicle) or real property. The micro-services may assess prequalification for a loan or financing for a good, followed by determining eligibility of the good for financing, and further followed by calculating pricing details for loans (e.g. for financing purchase of the good) that would be offered for a consumer's particular financial credentials, for each of a plurality of lenders. Prequalification and pricing may be performed on a good by good basis, or for a plurality of goods near or substantially simultaneously.

Abstract: Described herein is a system for providing version control across APIs. In an embodiment, an application of a client device may transmit communications to a service application API that are in a format not accepted by the service application API, using the application API. A central (or public) API may receive the communication transmitted by the application's API. The central API may identify the versions of the application's API and the service application API. The central API may format the communication based on the mapped fields, to a format accepted by the service application API. The central API 106 may forward the formatted communication to the service application.

Abstract: A system for interfacing with a decisioning service from a third-party domain. A backend system may receive a request to interface with the decisioning service to generate a prequalification result for a user for a specified product, in response to the actuation of a button included in a third-party web domain rendering a product. The backend system may execute a call on a website of the decisioning service. The backend system may receive the product information from the button. The backend system may generate the website within the third-party domain, including a request for information about the user, in response to executing the call to the website. The backend system may transmit a request for generating prequalification result for the product to the decisioning service. The backend system may receive the prequalification result from the decisioning service.

Abstract: The system and methods described herein allow users to give their applicant information when seeking to purchase a good with financing from multiple potential lenders, and may be pre-screened by one or more rule sets implemented by a marketplace client in an eligibility analysis to ultimately submit applicant information to a subset of the multiple potential lenders which are found to be suitable for lending to an applicant based on the applicant information, wherein lender microservices are then run in a jailed, firewalled, and self-contained, autonomous environment, and the results of said lender microservices are reported to the user and may be used to change the one or more rule sets implemented by the marketplace client for future pre-screening of applicants.

Abstract: The system and methods described herein allow users to give their applicant information when seeking to purchase a good with financing from multiple potential lenders, and may be pre-screened by one or more rule sets implemented by a marketplace client in an eligibility analysis to ultimately submit applicant information to a subset of the multiple potential lenders which are found to be suitable for lending to an applicant based on the applicant information, wherein lender microservices are then run in a jailed, firewalled, and self-contained, autonomous environment, and the results of said lender microservices are reported to the user and may be used to change the one or more rule sets implemented by the marketplace client for future pre-screening of applicants.

Abstract: Methods and systems are also described for generating qualitative graphical representations of the standardized metrics. For example, in order to allow contributors to intuitively understand and compare the standardized metrics, the methods and systems convert the standardized metrics into graphical representations that allow for a qualitative comparison of contributors. This conversion includes the retrieval of the standardized metrics and the use of non-conventional techniques for filtering the metrics based on dynamic criteria to generate software development scores that may be used to compare different contributors.

Abstract: The system and methods described herein allow users to apply for a purchase of a good from multiple providers using provider specific methodologies for generating offers for the product. For example, the system described herein may include a multi-layer architecture that includes interactive micro-services that communicate together in a bi-directional manner to create a normalized process for the purchase of a good, such as commercial goods/products (e.g. a vehicle) or real property. The micro-services may assess prequalification for a loan or financing for a good, followed by determining eligibility of the good for financing, and further followed by calculating pricing details for loans (e.g. for financing purchase of the good) that would be offered for a consumer's particular financial credentials, for each of a plurality of lenders. Prequalification and pricing may be performed on a good by good basis, or for a plurality of goods near or substantially simultaneously.

Abstract: A self-service lender portal provides lenders with a suite of tools for interacting with a multi-lender architecture configured to provide loan applicants with automated pre-qualification and eligibility evaluation for multiple candidate lenders. The lender portal provides lenders with an interface for uploading rule sets defining lending and eligibility criteria, downloading operational data generated from processing loan applicant information, generating and managing security keys for encryption and decryption of sensitive data, and managing access policies for providing single sign-on by interfacing with the lender's own identity management systems.

Abstract: The system and methods described herein allow users to give their applicant information when seeking to submit an inquiry associated with a product provided by at least one entity, and have various lender microservices run in parallel, segregated by entity, in a jailed and self-contained, autonomous environment. The result of these microservices may be returned as a response to the inquity, being determined autonomously for each respective entity based on one or more respective rule sets or executable logic for each respective entity. Payloads for multiple entities may be combined in a single output from the jailed and self-contained environment due to outputs from the environment being encrypted in a universal format, wherein the outputs are decrypted in a user session in an application, allowing the user to see the results of the respective responses of each of the at least one entity, to their inquiry.