A multi-lender architecture evaluates applicant data against lending rule sets of multiple lenders. Rule sets provided by different lenders may be expressed differently. The multi-lender architecture transforms the rules in each rule set and represents the rules in a normalization grid. The normalization grid allows a single algorithm to evaluate the rules of different lenders.

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.

The system described herein provides a secure unified system for users to get prequalified for a loan based on a link provided by a seller. The link may include seller identification information. A user can use a user device to launch a website by actuating a link. The user device may receive input corresponding to the user's personal information on the website. The user may transmit a prequalification request using the website, to a central system. The central system may generate prequalification results. The central system may ensure the pricing structures generated for a given product are consistent with the generated prequalification results within a specified time period.

In an embodiment, the system provides consistent pricing structures of a loan irrespective of the type of application requesting the pricing structure. The system generates a prequalification result for a product and user, in response to processing an initial prequalification request received from a given application. The system uses the prequalification result to generate a pricing structure. The prequalification result and pricing structure are stored. The system receives a subsequent purchase request for the product and user, from a different type of application. The system retrieves the prequalification result and pricing structure to generate a second pricing structure including the same pricing information as the previously generated pricing structure for the product and user. This ensures the customer is provided consistent pricing for a loan across platforms.

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.

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.

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.

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.

Encryption is performed at the field level within a data object, in response to an encryption indicator. Encrypted fields are nulled or zeroed out and the encrypted values are stored in encryption metadata with a path identifying the locations of the encrypted fields. An encrypted data key is appended with a decryption identifier and stored in the encryption metadata. The encrypted data object may be reformatted while encrypted. The encrypted data key is extracted from the encryption metadata and the decryption identifier is used to identify a master key used to decrypt the encrypted data key. The data key is used to decrypt the encrypted values and the decrypted values are stored in the fields identified by the paths.

Described herein is a system, method, and non-transitory computer readable medium related to a service provider using a third party identity provider to authenticate a user with improved security. An authentication token is received from the identity provider, and can be verified against internal configuration information. The internal configuration information includes data that is not included in the authentication token, and therefore, is not vulnerable to some security attacks, such as a man-in-the-middle attack. After the authentication token is verified, the internal configuration information and authentication token may be used to create a custom identifier, referred to as an identity ID. The identity ID may be used by the service provider to verify user access to resources.