US20210201399A1 - Systems and methods for aggregating and managing financial service accounts - Google Patents

Abstract

The disclosed embodiments include methods and systems for providing an aggregated financial service account based on multiple private label financial accounts. In one embodiment, a process is disclosed that may include receiving a first request from a user for a first private label financial account that is usable for purchases associated with a first merchant and approving the first request for the first private label financial account. The method may also include receiving a request from the user for a second private label financial account that is usable for purchases associated with a second merchant and approving the second request for the second private label financial account. In one aspect, the method may also include generating an aggregated financial account based on the first and second private label accounts such that the aggregated financial account may be used for purchases with the first merchantor with the second merchant.

Description

CROSS REFERENCE TO RELATED APPLICATION
• This application is a continuation of U.S. patent application Ser. No. 16/446,240, filed Jun. 19, 2019, which is a continuation of U.S. patent application Ser. No. 15/823,839, filed Nov. 28, 2017, which is a continuation of U.S. patent application Ser. No. 15/639,195, filed Jun. 30, 2017, which is a continuation of U.S. patent application Ser. No. 14/089,180, filed Nov. 25, 2013, which claims priority under 35 U.S.C. § 119 to U.S. Provisional Patent Application No. 61/776,284, filed Mar. 11, 2013, and entitled “Systems and Methods for Aggregating and Managing Financial Service Accounts,” each of which applications is incorporated herein by reference in its entirety.
BACKGROUND
• To stay ahead of competitors, large merchants offer incentives to motivate customers to shop at their locations, whether online or at the store location. A common incentive used by merchants is the private label credit card (e.g., store credit cards). These cards provide merchants a means to increase loyalty, target offers, track consumer purchases, reduce card processing costs, and increase brand awareness. Consumers also benefit from using private label cards in the form of rewards, discounts, and access to credit.
• Typically, each private label credit card held by a consumer is managed independently, meaning that every card carries separate credit exposure and credit score impact, and is billed separately. To reduce the impact on credit scores and minimize the complexities associated with separate billing processes, consumers are motivated to carry only a relatively small number of private label credit cards.
SUMMARY
• Consistent with the disclosure, systems and methods are provided for providing an aggregated financial service account,1rr one embodiment, a system is disclosed that may include, for example, one or more memory devices storing software instructions. The system may also include one or more processors configured to execute the software instructions to receive a first request from a user for a first private label financial account that is usable for purchases associated with a first merchant. The one or more processors may also be configured to approve the first request for the first private label financial account and receive a request from the user for a second private label financial account that is usable for purchases associated with a second merchant. The one or more processors may also be configured to approve the second request for the second private label financial account and generate an aggregated financial account based on the first and second private label accounts such that the aggregated financial account may be used for purchases with the first merchant or with the second merchant.
• The disclosed embodiments may also include a method for providing an aggregated financial service account. The method may include, receiving a first request from a user for a first private label financial account that is usable for purchases associated with a first merchant. The method may also include approving, by the one or more processors, the first request for the first private label financial account, and receiving a request from the user for a second private label financial account that is usable for purchases associated with a second merchant. In certain aspects, the method may further include approving, by the one or more processors, the second request for the second private label financial account, and generating, by the one or more processors, an aggregated financial account based on the first and second private label accounts such that the aggregated financial account may be used for purchases with the first merchant or with the second merchant.
• It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosed embodiments, as claimed.
• The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate disclosed embodiments and, together with the description, serve to explain the disclosed embodiments.
BRIEF DESCRIPTION OF THE DRAWINGS
• FIG. 1 illustrates an exemplary system consistent with disclosed embodiments.
• FIG. 2 is a block diagram of one or more process flows associated with an exemplary arrangement consistent with disclosed embodiments.
• FIG. 3 is a flowchart of an exemplary financial service account application process, consistent with disclosed embodiments.
• FIG. 4 is a flowchart of an exemplary aggregated financial service account generation process, consistent with disclosed embodiments.
• FIG. 5 is a block diagram of an exemplary data structure associated with a financial service account, consistent with certain disclosed embodiments.
• FIG. 6 is a block diagram of another exemplary data structure associated with a financial service account, consistent with certain disclosed embodiments.
• FIG. 7 is a block diagram of another exemplary data structure associated with a financial service account, consistent with certain disclosed embodiments.
• FIG. 8 is a block diagram on an exemplary process associated with certain aspects of the disclosed embodiments.
• FIG. 9 shows an exemplary financial service account interface, consistent with certain disclosed embodiments.
• FIG. 10 is a block diagram on an exemplary process associated with certain aspects of the disclosed embodiments,
• FIG. 11 is a block diagram on an exemplary process associated with certain aspects of the disclosed embodiments.
• FIG. 12 shows an exemplary financial service account interface, consistent with certain disclosed embodiments.
• FIG. 13 shows another exemplary financial service account interface, consistent with certain disclosed embodiments.
• FIG. 14 is a flowchart of an exemplary financial service account managing process, consistent with disclosed embodiments.
• FIG. 15 is a flowchart of an exemplary aggregated financial service account managing process, consistent with disclosed embodiments.
• FIG. 16 is a flowchart of an exemplary credit checking process, consistent with disclosed embodiments.
DETAILED DESCRIPTION
• Reference will now be made in detail to the disclosed embodiments, examples of which are illustrated in the accompanying drawings. Wherever convenient, the same reference numbers will be used throughout the drawings to refer to the same or like parts.
• The disclosed embodiments provide an aggregation and management platform for private label credit cards that extend the benefits of such financial service products to a broader merchant base. The disclosed embodiments provide a platform that allows a consumer to carry a single; credit exposure that is dynamically allocated to a number of private label credit cards. The disclosed embodiments provide processes that relieve a consumer of separate credit score impacts associated with individual cards while providing the convenience of managing only one financial service account. The disclosed embodiments also enable merchants to retain the loyalty and targeting features provided by private label cards. The disclosed embodiments are applicable to electronic financial service accounts, such as a digital wallet, and to plastic based financial accounts, such as a plastic credit card physically held and used by a consumer at point of sale locations.
• Although disclosed embodiments are discussed primarily in the context of private label financial accounts, other applications are contemplated. For example, disclosed embodiments may be also used with other types of financial accounts, such as bank accounts (e.g., savings, checking, etc.), loyalty cards, and the like. For instance, aspects of the disclosed. embodiments may be used with loyalty cards provided by a merchant that offers incentives based on the number of purchases by the consumer (e.g., buy five cups of coffee and get the sixth one free).
• FIG. 1 is a diagram illustrating anexemplary system100 for performing one or more operations consistent with the disclosed embodiments. In one embodiment,system100 may include afinancial service provider110,client120, one or more merchants150 (exemplary merchants150A and150B shown), acredit assessor160, andnetwork140. The components and arrangement of the components included insystem100 may vary. Thus,system100 may further include other components that perform or assist in the performance of one or more processes consistent with the disclosed embodiments.
• Financial service provider110 may be an entity that provides financial services. For example,financial service provider110 may be a bank, credit card issuer, or other type of financial service entity that generates, provides, manages, and/or maintains financial service accounts for one or more users. Financial service accounts may include, for example, credit card accounts, checking accounts, savings accounts, reward accounts, and any other types of financial service account known to those skilled in the art. Financial service accounts may be associated with electronic accounts, such as a digital wallet or similar account that may be used to perform electronic transactions, such as purchasing goods and/or services online. Financial service accounts may also be associated with physical financial service account cards, such as a plastic credit or check card that a user may carry on their person and use to perform financial service transactions, such as purchasing goods and/or services at a point of sale (POS) terminal.Financial service provider110 may include infrastructure and components that are configured to generate and provide financial service accounts and financial service account cards (e.g., credit cards, check cards, etc.).
• In one embodiment,financial service provider110 may include one or more computing systems that are configured to execute software instructions stored on one or more memory devices to perform one or more operations consistent with the disclosed embodiments. In one embodiment,financial service provider110 may includeserver111.Server111 may be one or more computing devices configured to execute software instructions stored in memory to perform one or more processes consistent with the disclosed. embodiments. For example,server111 may include one or more memory device(s) storing data and software instructions and one or more processor(s) configured to use the data and execute the software instructions to perform server-based functions and operations known to those skilled in the art.Server111 may also be configured to execute stored software instructions to perform operations associated with aggregating and managing multiple private label financial service accounts in a manner consistent with the disclosed embodiments. In one embodiment, a private label financial account may include a financial account that is provided by a specific entity (e.g., merchants, etc) that can be used to purchase goods and/or services from that entity (e.g., a merchant-based credit card usable for purchases at that merchant's store locations (e.g., online or brick and mortar locations). The disclosed embodiments are applicable to any type of private label account, such as, for example: private label/store credit financial accounts, private label debit accounts, gift accounts, prepaid, and other stored value accounts (e.g., rewards/loyalty points), etc. Moreover, in certain embodiments, credit accounts may include, for example, lines of credit, credit card accounts, promotional financing accounts, long term financing accounts, transactional credit accounts, and installment loan accounts.
• Server111 may be a general purpose computer, a mainframe computer, or c;1ny combination of these components. In certain embodiments, server111 (or a system including server111) may be configured as a particular apparatus, system, and the like based on the storage, execution, and/or implementation of the software instructions that perform one or more operations consistent with the disclosed embodiments.Server111 may be standalone, or it may be part of a subsystem, which may be part of a larger system. For example,server111 may represent distributed servers that are remotely located and communicate over a network (e.g., network140) or a dedicated network, such as a LAN, forfinancial service provider110.
• Server111 may include or may connect to one or more storage devices configured to store data and/or software instructions used by one or more processors ofserver111 to perform operations consistent with disclosed embodiments. For example,server111 may include memory configured to store one or more software programs that performs several functions when executed by a processor. The disclosed embodiments are not limited to separate programs or computers configured to perform dedicated tasks. For example,server111 may include memory that stores a single program or multiple programs. Additionally,server111 may execute one or more programs located remotely fromserver111. For example,server111 may access one or more remote programs stored in memory included with a remote component that, when executed, perform operations consistent with the disclosed embodiments. In certain aspects,server111 may include web server software that generates, maintains, and provides web site(s) that are accessible overnetwork140. In other aspects,financial server provider110 may connect separate web server(s) or similar computing devices that generate, maintain, and provide web site(s) forfinancial service provider110.
• Network140 may be any type of network configured to provide communications between components ofsystem100. For example,network100 may be any type of network (including infrastructure) that provides communications, exchanges information, and/or facilitates the exchange of information, such as the Internet, a Local Area Network, or other suitable connection(s) that enables the sending and receiving of information between the components ofsystem100. In other embodiments, one or more components ofsystem100 may communicate directly through a dedicated communication link(s), such as the exemplary links betweenfinancial service provider110 andmerchants150A and150B.
• Client120 may be one or more computing devices that are configured to execute software instructions for performing one or more operations consistent with the disclosed embodiments.Client120 may be a desktop computer, a laptop, a server, a mobile device (e.g., tablet, smart phone, etc.), and any other type of computing device.Client120 may include one or more processors configured to execute software instructions stored in memory, such as memory included inclient120.Client120 may include software that when executed by a processor performs known Internet-related communication and content display processes. For instance,client120 may execute browser software that generates and displays interfaces including content on a display device included in, or connected to,client120. The disclosed embodiments are not limited to any particular configuration ofclient120. For instance,client120 may he a mobile device that stores and executes mobile applications that provide financial service related functions offered byfinancial service provider110 and/ormerchants150A,150B, such as a banking mobile application for checking balances, paying bills, etc.
• In one embodiment, a user101 may useclient120 to perform one or more operations consistent with the disclosed embodiments. In one aspect, user101 may be a customer offinancial service provider110. For instance, financial service provider may maintain a financial service account (e.g., credit card account) for user101 that user101 may use to purchase goods and/or services online or at brick and mortar locations associated with a merchant. In other embodiments, user101 maybe a potential customer offinancial service provider110 or may not be affiliated withfinancial service provider110 from the user's perspective and/or thefinancial service provider110′s perspective.
• Merchants150A and150B may each be an entity that provides goods and/or services (e.g., a retail store). WhileFIG. 1 shows twomerchants150A and150B insystem100, the disclosed embodiments may be implemented in a system involving a single merchant150 or multiple merchants (e.g., two or more merchants). A merchant150 may include brick and mortar location(s) that a consumer (e.g., user101) may physically visit and purchase goods and services. Such physical locations may include computing devices that perform financial service transactions with consumers (e.g., POS terminal(s), kiosks, etc.). They may also include back and/or front-end computing components that store data and execute software instructions to perform operations consistent with disclosed embodiments, such as computers that are operated by employees of merchant150 (e.g., back office systems, etc.). In certain embodiments, merchants150 may also include merchants that provide electronic shopping mechanisms, such as a website or similar online location that consumers may access using a computer (e.g., client120) through browser software or similar software.
• In one embodiment,merchants150A and150B includeserver151A and151B, respectively. Server151 may be one or more computing devices configured to execute software instructions stored in memory to perform one or more processes consistent with the disclosed embodiments. For example, server151 may include one or more memory device(s) storing data and software instructions and one or more processor(s configured to use the data and execute the software instructions to perform server-based functions and operations known to those skilled in the art. Server151 may also be configured to execute stored software instructions to perform operations associated with merchant150, including one or more processes associated with providing private label financial service accounts. Server151 may be a general purpose computer, a mainframe computer, or any combination of these components. In certain embodiments, server151 (or a system including server151) may be configured as a particular apparatus, system, and the like based on the storage, execution, and/or implementation of the software instructions that perform one or more operations consistent with the disclosed embodiments. Server151 may be standalone, or it may be part of a subsystem, which may be part of a larger system. For example, server151 may represent distributed servers that are remotely located and communicate over a network (e.g., network140) or a dedicated network, such as a LAN, for merchant150.
• In certain aspects, server151 may include web server software that generates, maintains, and provides web site(s) for a respective merchant150 that is accessible overnetwork140. In other aspects, merchant150 may connect separate to web server(s) or similar computing devices that generate, maintain, and provide web site(s) for merchant150. For example,merchant150A may use web server(s) that provide a web site specific tomerchant150A, and allows user101 to access, view, and purchase goods and/or services frommerchant150A. Similarly,merchant150B may use web server(s) that provide a web site specific tomerchant1508 and allows user101 to access, view, and purchase goods and/or services frommerchant1508.
• In accordance with certain aspects of the disclosed embodiments,merchant150A may offer and provide private label financial service accounts (e.g., private label credit card accounts) associated withmerchant150A andmerchant1508 may offer and provide private label financial service accounts (e.g., private label credit card accounts) associated withmerchant150B. In certain configurations,financial service provider110 may assistmerchant150A and/ormerchant150B with providing, maintaining, offering, and managing the private label financial service accounts.
• Credit assessor160 may be an entity that performs credit assessments for consumers. For example,credit assessor160 may be an entity that provides credit evaluation services to consumers (e.g., user101) and/or financial service related entities (e.g., merchants150 and financial service provider110). In one example,credit assessor160 may be an entity that provides credit scores to a consumer (e.g., user101) based on the credit history for that consumer.Credit assessor160 may also provide credit assessments tofinancial service provider110 for consumers attempting to apply for financial service accounts offered byfinancial service provider110 and/ormerchants150A and/or150B.Credit assessor160 may include computing components known to those skilled in the art to provide credit check and assessment services and to provide information relating to the credit check and assessment services overnetwork140, such as a web server providing a web site accessible by user101 or a server that communicates withserver111 and/orservers151A and/or151B. The disclosed embodiments are not limited to any particular configuration of the computing components used bycredit assessor160.
• As explained, the disclosed embodiments include methods and systems for aggregating and managing private label financial service accounts.FIG. 2 shows a block diagram of one or more process flows associated with an exemplary arrangement consistent with disclosed embodiments. In one aspect, user101 may request and obtain private label financial service accounts frommerchants150A and1508. In one aspect, user101 may receive physical cards (e.g., plastic credit cards) that are branded for each merchant. For instance, user101 may hold afinancial service account203 that is branded with merchant A that can be used by user101 to purchase goods and/or services frommerchant150A electronically (e.g., such as online shopping).Financial service account203 may include a plastic (or similar) card that can be used by user101 to purchase goods and/or services frommerchant150A at a brick and mortar location ofmerchant150A. Similarly, user101 may hold afinancial service account205 that is branded with merchant B that can be used to purchase goods and/or services frommerchant150B electronically.Financial service account205 may also include a plastic (or similar) card that user101 can use to purchase goods and/or services frommerchant150B at a brick and mortar location ofmerchant1508. In certain embodiments,financial service account203 may only be used to purchase goods and/or services frommerchant150A andfinancial service account205 may only be used to purchase goods and/or services frommerchant150B.
• User101 may also hold a general purpose financial service account with financial service provider110 (in electronic and/or physical card form) that can be used to purchase goods and/or services frommerchants150A and/or15013 or other merchants. In certain aspects,financial service provider110 is configured to perform processes for aggregating and managing the private label accounts provided bymerchants150A and1508.
• In other aspects of the disclosed embodiments,financial service provider110 may generate a single aggregated financial account that encompasses private label accounts from.merchant150A andmerchant150B. For example,financial service provider110 may be configured to execute software instructions (via server111) that create and store an aggregated financial service account that can be used by user101 only for purchases associated withmerchant150A and/or merchant150B.
• FIG. 3 is a flowchart of an exemplary financial service account application process consistent with certain disclosed embodiments. In one aspect, user101 may apply for a private label financial service account from merchant A (step310). User101 may apply for the merchant A private labelaccount using client120. For example, user101 may useclient120 to access an online application web page provided bymerchant150A via the Internet (e.g., network140). Alternatively, user101 may fill out an application for the merchant A private label account at a physical location ofmerchant150A, via, for example, a kiosk or by filling out an application using pen and paper. For the latter,merchant150A may include infrastructure and components for converting user101's application into electronic form for subsequent processing by computing device(s).
• The disclosed embodiments may process user101's request for the merchant A private label account (step320). In one embodiment,merchant150A andfinancial service provider110 may perform one or more operations associated with processing the request. For example, in one aspect,merchant150A (viaserver151A) may generate a request for the user101's application and provide the request toserver111 of financialservice account provider110. The request may be communicated overnetwork140.Server111 may be configured to process the request by performing known credit history checks. For example,server111 may send a request tocredit assessor160 for credit information relating to user101.Credit assessor160 may perform processes for determining credit results (e.g., a credit score, summary credit information, etc.) and provide the results of such processes tofinancial service provider111.
• Based on user101's credit history information (or score) received fromcredit assessor160,financial service provider111 may generate and provide results for user101's request for merchant A's private label account (e.g., step330). In one embodiment,financial service provider111 may provide the results of user101's merchant A private label account request tomerchant150A. In turn,merchant150A may generate and provide a notification to client120 (or directly to user101) informing user101 whether the request was approved. In other embodiments, financial service provider110 (e.g., via server111) may generate and provide a notification toclient120 informing user101 whether the request was approved. In certain aspects, explained further below, financial service provider110 (e.g., via server111) may provide the notification with branded labels associated with merchant A. For instance, the notification may include information and have a look and feel as if it came directly from merchant A (e.g., merchant A logos, text, etc.) even though the notification originated fromfinancial service provider110.
• In some embodiments, user101 may also apply for a private label financial service account from merchant B (step340). User101 may apply for themerchant8 private labelaccount using client120. For example, user101 may useclient120 to access an online application web page provided bymerchant1508 via the Internet (e.g., network140). Alternatively, user101 may fill out an application for the merchant B private label account at a physical location ofmerchant150B, via, for example, a kiosk or by filling out an application using pen and paper. For the latter,merchant1508 may include infrastructure and components for converting user101's application into electronic form for subsequent processing by computing device(s).
• The disclosed embodiments may process user101's request for the merchant B private label account (step350). In one embodiment,merchant1508 andfinancial service provider110 may perform one or more operations associated with processing the request. For example, in one aspect, merchant1508 (viaserver151B) may generate a request for the user101's application and provide the request toserver111 of financialservice account provider110. The request may be communicated overnetwork140.Server111 may be configured to process the request by performing known credit history checks. In one aspect,server111 may send a request tocredit assessor160 for credit information relating to user101.Credit assessor160 may perform processes for determining credit results (e.g., a credit score, summary credit information, etc.) and provide the results of such processes tofinancial service provider111.
• In other aspects,server111 may be configured to locally process the user101's request to form an aggregated financial service account consistent with the disclosed embodiments. In these embodiments,server111 may bypasscredit assessor160 to approve user101's request for a merchant B private label account.
• In certain aspects,financial service provider111 may generate and provide results for user101's request for merchant B′s private label account (e.g., step360). In one embodiment,financial service provider111 may provide the results of user101's merchant B private label account request tomerchant1508. In turn,merchant150B may generate and provide a notification to client120 (or directly to user101) informing user101 whether the request was approved. In other embodiments, financial service provider110 (e.g., via server111) may generate and provide a notification toclient120 informing user101 whether the request for the merchant B private label account was approved. In certain aspects, explained further below, financial service provider110 (e.g., via server111) may provide the notification with branded labels associated with merchant B. For instance, the notification may include information and have a look and feel as if it came directly from merchant B (e.g., merchant B logos, text, etc.) even though the notification originated fromfinancial service provider110.
• FIG. 4 shows a flowchart of an exemplary aggregation account process consistent with certain disclosed embodiments. Instep410, financial service provider110 (e.g., via server111) may execute software that performs operations for creating an aggregated account based on the merchant A and merchant B private label accounts requested and approved for user101. In one aspect, financialservice account provider110 may generate a single financial service account with separate records associated with the merchant A and merchant B private label accounts. Financialservice account provider110 may generate, as one example, a data structure(s) that maintains sub-accounts associated with the merchant A and merchant B private label accounts.
• FIG. 5 shows a block diagram of an exemplaryfinancial service account500 including sub-accounts for the merchant A and merchant B private label accounts. The configuration, parameters, and format offinancial service account500 are exemplary and are not limiting to the disclosed embodiments. In one example, financialservice account provider110 may generate and store records for each merchant sub-account. Each sub-account may be associated with one or more parameters (e.g.,parameters305,310,315,320,325, and330), that provide mechanisms for use of the sub-accounts by user101. For example,financial service account500 may include a sub-account for merchant A private label account with parameters for a credit limit (310), balance (315), payment due dates (320), payment amount (325), and percentage rate (330). When user101 uses its merchant A private label account to make purchases with merchant A (e.g.,account203 shown inFIG. 2),financial service provider110 may execute software to update and edit the parameters associated with the sub-account associated with the merchant A private label account. Similarly, when user101 uses the merchant B private label account to make purchases with merchant B,financial service provider110 may execute software to update and edit the parameters associated with the sub-account associated with the merchant B private label account.
• In other embodiments,financial service provider110 may be configured to execute software processes for creating another form of a single aggregated financial account for the multiple merchant private label accounts of user101.FIG. 6 shows a block diagram of an exemplaryfinancial service account600 including an aggregated account record that is an aggregated form of the two private label accounts for merchant A and merchant B.
• In one embodiment, financialservice account provider110 may generate and store records for each merchant sub-account. Each sub-account may be associated with one or more parameters (e.g.,parameters305,310,315,320,325, and330), that provide mechanisms for use of the sub-accounts by user101. For example,financial service account500 may include a sub-account for merchant A private label account with parameters for a credit limit (310), balance (315), payment due dates (320), payment amount (325) and percentage rate (330). When user101 uses its merchant A private label account to make purchases with merchant A (e.g.,account203 shown inFIG. 2),financial service provider110 may execute software to update and edit the parameters associated with the sub-account associated with the merchant A private label account. Similarly, when user101 uses the merchant B private label account to make purchases with merchant B,financial service provider110 may execute software to update and edit the parameters associated with the sub-account associated with the merchant B private label account.
• The configuration, parameters, and format offinancial service account600 are exemplary and are not limiting to the disclosed embodiments. For instance, whileFIG. 6 shows the data structure forfinancial service account600 including records for merchant A and merchant B, the disclosed embodiments may include configurations where financial service provider111 (or another entity) generates a data structure forfinancial service account600 that does not include fields or records for each merchant private label account. For instance, separate data records may be created for each sub-account associated with a merchant private label account and linked to a common aggregate account, such as that exemplified inFIG. 7. In other embodiments,financial service provider110 may not generate any sub-accounts for the merchant A and B private label accounts and instead generate a single aggregated account including parameters and information reflecting the two private label merchant accounts. The disclosed embodiments are not limited to any particular configuration or format of the data structures generated and stored by financial service account provider110 (or any other entity of system100). Database formats, data types, linked fields, and other forms of known data record management operations may be implemented by the disclosed embodiments to create, maintain, and manage the aggregated and private label financial service accounts disclosed herein.
• Returning toFIG. 4, in certain embodiments,financial service provider110 may execute software processes that determine one or more parameters for the aggregated account relating to private label merchant accounts of a given user (step420). In one embodiment, financialservice account provider110 may determine the parameters for each sub-account for the merchant A and B private label accounts (e.g., such as the sub-accounts forfinancial account500 shown inFIG. 5).Financial service provider110 may consider one or more predetermined account parameters setforth by a given merchant150 in offers provided to user101 for a private label account. For example,merchant150A may provide an offer to user101 (e.g., viaserver151A and client120) that identifies one or more of the parameters for the private label account offered bymerchant150A (e.g., percentage rate of 9%, a credit. limit of $5000.00, etc.). In other aspects, one or more of the parameters for a private label merchant account may not be known or provided to user101 at the time user101 applies for the private label account. In these embodiments,financial service provider110 may execute software processes (via server111) that determines the one or more parameters based on, for example, rules or conditions set by merchants150 (e.g.,merchant150A and/or150B) or byfinancial service provider111.
• In one embodiment,financial service provider110 executes software instructions (via server111) that determines parameters for a single aggregated financial account based on the parameters for the private label accounts associated withmerchants150A and1508 (and any others that may be included). For example,financial service provider110 may determine an aggregated account balance parameter that reflects the total amount user101 may use the aggregated account for purchasing goods and/or services frommerchants150A and1508. In one aspect, the account balance parameter may be linked to the account balance parameters for each merchant private label sub-account. Thus, for example, financialservice account provider110 may be configured to track and deny purchase transactions that involve purchases that exceed the allocated balance for a given merchant. For example, financialservice account provider110 may configure the aggregated account such that the balance parameter for the merchant B sub-account is checked if user101 attempts to purchase goods from merchant B.Financial service provider110 may use merchant identity information provided by a merchant150 when processing a purchase transaction by user101 using an aggregated financial account.
• Financialservice account provider110 may also set one or more parameters for the aggregated account or merchant-specific account based on other factors, such as merchant category information, merchant identity, specific store locations for merchant(s)150, geographical location, etc. When processing applications for any given private label card, financial service account provider110 (via, for example, server111) may use any combination of these or other factors to determine eligibility for an account, or values for any of the account parameters described. Similarly, financial service account provider110 (via e.g., server111) may at any time modify any of these parameters based on any combination of the aforementioned or other factors. Such modifications may include, but are not limited to, changes to credit lines, interest rates, billing and payment settings, etc.Financial services provider110 may also at any time terminate the extension of credit either temporarily for a defined or undefined time period, or permanently, based on any combination of such factors etc. In certain aspects,server111 may be configured to execute software processes that analyze the above exemplary factors to determine whether to terminate the extension of credit as disclosed above.
• Oncefinancial service provider110 determines the parameters for the aggregated account (step420), it may provide the aggregated account to user101 (step430). In one embodiment,financial service provider110 may provide the aggregated account in the form of an electronic account that can be used online for online purchases with any merchants that are associated with the aggregated account (e.g.,merchants150A and1508). The aggregated account may be configured such that it can only be used for transactions with the specific merchants associated with the aggregated account. In another embodiment,financial service provider110 may generate and provide a physical financial service account card that is usable at locations for merchants associated with the aggregated account (e.g., brick and mortar locations formerchants150A and1508).Financial service provider110 may provide the aggregated account directly to user101. In some aspects, the account may be provided via a notification (e.g., email, text, link to web page, etc.) including information with brand labels associated withmerchants150A ormerchant1508, or both. Any physical financial service account cards may also be branded with information associated withmerchants150A and1508 (e.g., the card may include logos for merchant.150A and/or merchant1508). In other embodiments,financial service provider110 may issue a separate financial service account card formerchant150A andmerchant1508. Thus, in one example, user101 may receive one financial service card for use withmerchant1508 and a separate financial service card for use withmerchant150A. Logically, however,financial service account110 may relate any purchases using the separate cards, which may be notified bymerchants150A and1508, with the single aggregated account. In this example, user101 may hold two separate financial service account cards (one formerchant150A and one for merchant1508), but transactions and other financial account management services associated with the two cards are processed by financialservice account provider110 as single aggregated account.
• In other embodiments,merchant150A may be configured to provide notification of the aggregated account to user101 (via, for example,server151A and client120). Similarly,merchant150B may be configured to provide notification of the aggregated account to user101 (via, for example,server151B and client120). The notification may include information that informs user101 that the private label account formerchant150A has been approved, information describing one or more of the parameters for the private label merchant account, etc.
• The disclosed embodiments also provide processes that allow an existing private label financial service account to be configured as an aggregated account that may be used to purchase goods and/or services from more than one merchant150. For example, the disclosed embodiments may generate and provide a private label merchant account for user101 formerchant150A in a manner consistent with the operations described above. Sometime later, user101 may apply for another private label merchant account frommerchant150B. In this example,merchant150B andmerchant150A may have an agreement that allowsfinancial service provider110 to aggregate private label accounts with certain other merchants, such asmerchants150A and150B. For example,merchant150A may be a merchant that provides coffee (e,g., a coffee shop) and merchant B may be a retailer that sells coffee making appliances (e.g., a home goods store). These exemplary merchants may negotiate and agree to arrangements wherefinancial service provider110 processes and manages financial service accounts on behalf of the merchants. In exchange, the merchants allow thefinancial service provider110 to generate aggregated financial accounts for user101 that is usable at the partnered merchant sites in a manner consistent with the disclosed embodiments. Thus, in this example,financial service provider110 may provide a replacement card to user101 that is usable by user at the two exemplary merchant sites (e.g., merchant A coffee shop and merchant B home goods store). The replacement card may include branded labels associated with the two exemplary merchants. Alternatively, the disclosed embodiments may not replace an existing card held by the user (e.g., coffee shop card), but instead may notify the user (viaclient120 or other means) that the existing card is now usable at the other merchant (e.g., the home goods store).
• FIG. 8 shows a block diagram ofsystem800 that may be used to perform private label financial card processes consistent with certain disclosed embodiments. As explained, user101 may useclient120 to access a web site provided bymerchant150A (via, forexample server151A or other server) to apply for a private label merchant account.Client120 may, based on input from user101, issue arequest820 for applying for the account. In response,server151A (or another server) may provideclient120 with an interface810 that is branded with merchant A information (e.g., merchant A logos, text, graphics, etc.). Interface810 may includecontent802,804, and806 that may include advertisements, links to one or more services offered bymerchant150A,financial service provider110, or other entities. Interface810 may include aninterface808 that enables user101 to enter information for applying for the merchant A private label card.
• In another embodiment, instead ofmerchant150A providing interface810,merchant150A may forward therequest820 tofinancial service provider110 viarequest822.Request822 may be a new request generated byserver151A that includes information relating to user101 and/orclient120 such that other components may communicate withclient120. In response to request822,financial service provider110 may generate information used for applying for the new merchant A private label account. In one aspect, financial service provider110 (e.g., via server111) may send a request to824 to aserver115 that may be configured to generate content (e.g., in the form of a web page or similar online location) that is provided toclient120 viacommunication826. In this example,server115 may generate interface810 with the branded information associated withmerchant A. Server115 may be remote tofinancial service provider110 or may be included withfinancial service provider110. Thus, in certain embodiments,financial service provider110 may perform back-end processes that generate and provide interface(s) (such as interface810) toclient120 that have a look and feel as if they originated from merchant1150A, but are actually provided by financial service provider110 (viaserver111 and/or server115).
• The process flow associated withFIG. 8 may also be followed to allow user101 to manage the merchant A private label account. For example, the disclosed embodiments may allow user101 to perform online account management functions associated with the merchant A private label account held by user101. In one example, user101 may useclient120 to access a website associated withmerchant150A to perform account management functions. The web site may have an address affiliated withmerchant150A (e.g., www.merchantA/privatelabelaccountmanagement/), but is provided byfinancial service provider110 viaserver115.Financial service account110 may provide interface(s) that user101 may use (via client120) to perform different account functions, such as paying bills, reviewing statements, etc. The interface may be branded as a merchant A interface.FIG. 9 shows anexemplary interface900 that may be provided byfinancial service provider110 that includes content associated with merchant A.
• The disclosed embodiments may allow similar processes to be performed for merchant B private label accounts.FIG. 10 shows a block diagram of anexemplary system1000 that may be used to perform private label financial card processes consistent with certain disclosed embodiments. As explained, user101 may useclient120 to access a web site provided bymerchant150B (e.g., viaserver151B or other server) to apply for a private labelmerchant account Client120 may, based on input from user101, issue arequest1020 for applying for the account. In response,server151B (or another server) may provideclient120 with aninterface1010 that is branded with merchant B information (e.g., merchant B logos, text, graphics, etc.).Interface1010 may includecontent1002,1004, and1006 that may include advertisements, links to one or more services offered bymerchant150B,financial service provider110, or other entities.Interface1010 may include aninterface1008 that enables user101 to enter information for applying for the merchant A private label card.
• In another embodiment, instead ofmerchant1508 providinginterface1010,merchant150B may forward therequest1020 tofinancial service provider110 viarequest1022.Request1022 may be a new request generated byserver151B that includes information relating to user101 and/orclient120 such that other components may communicate withclient120. In response torequest1022,financial service provider110 may generate information used for applying for the new merchant A private label account. In one aspect, financial service provider110 (e.g., via server111) may send a request to1024 to aserver115 that may be configured to generate content (e.g., in the form of a web page or similar online location') that is provided toclient120 viacommunication1026. In this example,server115 may generateinterface1010 with the branded information associated withmerchant B. Server115 may be remote tofinancial service provider110 or may be included withfinancial service provider110. Thus, in certain embodiments,financial service provider110 may perform back end processes that generate and provide interface(s) (such as interface1010) toclient120 that have a look and feel as if they originated frommerchant1508, but are actually provided by financial service provider110 (viaserver111 and/or server115).
• The process flow associated withFIG. 10 may also be followed to allow user101 to manage the merchant B private label account. For example, the disclosed embodiments may allow user101 to perform online account management functions associated with the merchant B private label account held by user101. In one example, user101 may useclient120 to access a website associated with merchant.150B to perform account management. functions. The web site may have an address affiliated withmerchant150B (e.g., www.merchantB/privatelabel account management), but is provided byfinancial service provider110 viaserver115.Financial service account110 may provide interface(s) that user101 may use (via client120) to perform different account functions, such as paying bills, reviewing statements, etc. The interface may be branded as a merchant B interface,
• FIG. 11 shows a block diagram of anexemplary system1100 that may be used to perform private label financial card processes consistent with certain disclosed embodiments. In certain aspects, user101 may useclient120 to access a web site provided. by financial service provider110 (e.g., viaserver111,server115, or other servers) to apply and/or manage an aggregated financial service account associated with private label merchant accounts. In one example,client120 may, based on input from user101, issue arequest1120 for applying for the aggregated account. In response, server115 (or another server) may forward the user input information viacommunication1150 tofinancial service provider110.Financial service provider110 may perform approval processes or account management processes consistent with the disclosed embodiments.Financial service provider110 may useserver115 to generate and provide interface(s) such as interface1110, toclient120 for receiving and providing information relating to the aggregated account. In one aspect,server115 may provideclient120 with an interface1110 that is branded withfinancial service provider110 information (e.g., logos, text, graphics, etc.), and/or with information associated with merchant A and/or merchant B Interface1110 may includecontent1102,1104, and1106 that may include advertisements, links to one or more services offered byfinancial service provider110, or other entities, such asmerchant150A and/ormerchant150B. Interface1110 may include an interface1108 that enables user101 to enter information for applying or requesting information relating to an aggregated financial service account consistent with the disclosed embodiments.
• Server115 may be remote tofinancial service provider110 or may be included withfinancial service provider110. Thus, in certain embodiments,financial service provider110 may perform back end processes that generate and provide interface(s) (such as interface1110) toclient120 that have a look and feel as if they originated from financial service provider1110,merchant150A,merchant150B, or a combination of these.
• The process flow associated withFIG. 10 may also be followed to allow user101 to manage the merchant B private label account. For example, the disclosed embodiments may allow user101 to perform online account management functions associated with the merchant B private label account held by user101. In one example, user101 may useclient120 to access a website associated withmerchant150B to perform account management functions. The web site may have an address affiliated withmerchant150B (e.g., www.merchantB/privatelabel accountmanagement/), but is provided byfinancial service provider110 viaserver115.Financial service account110 may provide interface(s) that user101 may use (via client120) to perform different account functions, such as paying bills, reviewing statements, etc. The interface may be branded as a merchant B interface.
• As explained, aspects of the disclosed embodiments provide an aggregated account associated with multiple private label financial accounts. In certain aspects, financial service provider110 (viaserver111,server115, both, or other server(s)) may provide a central location for user101 to manage multiple private label financial accounts via an aggregated account provided byfinancial service provider110.FIG. 12 shows anexemplary interface1200 that may be provided byfinancial service provider110 consistent with an aggregated account provided by certain disclosed embodiments.Interface1200 may include, as an example, content including data associated with merchant A financial service account, data associated with merchant B financial service account, and financial service provider account data. Other content may also be provided ininterface1200, such as advertisements, links, graphics, text, etc. associated with merchant A, merchant B, and/orfinancial service provider110.
• FIG. 13 shows anotherexemplary interface1300 that may be provided byfinancial service provider110 consistent with an aggregated account provided by certain disclosed embodiments.Interface1300 may include, as an example, content including data associated with an aggregated financial service account provided by financialservice account provider110 consistent with disclosed embodiments.Interface1300 may include interfaces that are dynamically generated based on different types of account management functions, such as billing, statement review, account reward tracking, etc.
• As explained, in certain aspects, the disclosed embodiments allow user101 to manage private label accounts for different merchants.Merchants150A and150B may collaborate withfinancial service provider110 to allowfinancial service account110 to generate and provide interfaces on behalf ofmerchants150A and150B for managing respective private label accounts. Thus,merchant150A, for example, may advertise online banking services for its merchant A private label accounts without having to provide the backend processes for maintaining and managing such accounts. Instead,financial service provider110 may generate and provide online locations that user101 may access (via client120) that are branded as merchant A locations.
• FIG. 14 shows a flowchart of an exemplary account management process consistent with certain disclosed embodiments. In step1410,merchant150A (viaserver151A) may receive a request from user101 for managing a merchant A private label account held by user101. In one aspect,client120 may send the request toserver151A overnetwork140. For instance,merchant150A may provide a web site that offers services associated with the business affiliated withmerchant150A. The web site may include a link that, when selected by user101 viaclient120, redirects user101 to a web site provided by financial service provider110 (via, for example, server115). Step1410 may also reflect the step offinancial service provider110 receiving a request frommerchant150A for managing the merchant A private label account.
• In step1420,financial service provider110 may process the user request for managing the merchant A private label financial account. Processing the account may include determining what operations user101 is requesting to do based on input or selections by user101 on an interface provided viaclient120. In certain aspects, depending on the preferences of user101, financialservice account provider110 may provide one or more interface(s) overnetwork140 toclient120 for display to user101 (step1430). Financialservice account provider110 may configure the interface(s) with a look and feel associated with merchant A. For example, user101 may use the disclosed embodiments to make payments toward a balance on merchant A private label account. In these aspects,financial service provider110 may generate merchant A branded interface(s) that allow user to make online payments toward the merchant A financial service account. Financialservice account provider110 processes the payment and edits the information associated with the merchant A subaccount associated with user101's aggregated account.
• In similar fashion, user101 may useclient120 to access a web site provided by merchant1509. In step1440, merchant1508 (via server1519) may receive a request from user101 for managing a merchant B private label account held by user101. In one aspect,client120 may send the request to server1519 overnetwork140. For instance,merchant1508 may provide a web site that offers services associated with the business affiliated withmerchant1508. The web site may include a link that, when selected by user101 viaclient120, redirects user101 to a web site provided by financial service provider110 (e.g., via server115). Step1440 may also reflect the step offinancial service provider110 receiving a request frommerchant1508 for managing the merchant A private label account.
• In step1450,financial service provider110 may process the user request for managing themerchant8 private label financial account. Processing the account may include determining what operations user101 is requesting to do based on input or selections by user101 on an interface provided viaclient120. In certain aspects, depending on the preferences of user101, financialservice account provider110 may provide one or more interface(s) overnetwork140 toclient120 for display to user101 (step1460). Financialservice account provider110 may configure the interface(s) with a look and feel associated with merchant B. For example, user101 may use the disclosed embodiments to make payments toward a balance on merchant B private label account. In these aspects,financial service provider110 may generate merchant. B branded interface(s) that allow user to make online payments toward the merchant B financial service account. Financialservice account provider110 processes the payment and edits the information associated with the merchant B subaccount associated with user101's aggregated account.
• In certain embodiments,financial service provider110 may provide an aggregated account that is configured based on one or more parameters associated with one or more private label financial accounts. For instance, as discussed above,financial service provider110 may create an aggregated financial service account that is based on private label accounts frommerchant150A andmerchant1508.Financial service provider110 may be configured to execute software that allows the parameters to be dynamically adjusted based on private label merchant accounts added for user101. Aspects of the disclosed embodiments also provide a central means for managing multiple private label accounts.
• FIG. 15 shows a flowchart of an exemplary aggregated account management process, consistent with certain embodiments. Instep1510, financial service account110 (e.g., via server111) may receive a request to manage an aggregated account. The request may come fromclient120 overnetwork140. In other embodiments,merchant150A ormerchant150B may provide a link on their branded web site to access the aggregated. account management functions offered byfinancial service provider110.
• Based on the request, financial service provider110 (viaserver111,server115, both, or another server) may generate an aggregated account interface (step1520). In one aspect, the aggregated account interface may include content such as that described above in connection withFIG. 13. Financial service provider110 (viaserver111,server115, both, or another server) may generate the aggregated account interface to include options for managing the aggregated account. For example, the interface may include an option for user101 to make a payment on the account. In certain aspect,financial service provider110 may execute software processes that allow user101 to make a single payment that is contributed toward multiple private label financial accounts. For example,financial service provider110 may receive input regarding an aggregated account (step1530). Based on the input,financial service provider110 may process user101's input in accordance with the aggregated account parameters (step1540). For instance, user101's input may reflect a desire to make a payment toward a balance associated with merchant A private label account. In embodiments wherefinancial service account110 provides a single aggregated account that encompasses both merchant A and merchant B private label accounts,financial service provider110 may process the user101's payment such that the balance for both private label accounts are adjusted. For example, a user101's $100 payment may be split between the balance associated with both merchant A and merchant B's sub-accounts associated with the aggregated account. In other aspects,financial service provider110 may apply the payment to a single balance parameter associated with the aggregated financial account. In this way, user101 need only make payments on a single account that effectively cover two private label accounts.
• The disclosed embodiments also provide advantages from a credit assessment perspective. In one aspect,financial service provider110 may provide an aggregated. account process that generates a single credit bureau facing credit account that is based on multiple private label accounts. Thus, the credit exposure to user101 is reduced through use of an aggregated financial account provided by the disclosed embodiments. For instance,FIG. 16 shows a flowchart of an exemplary credit check processing process consistent with certain disclosed embodiments. Instep1610,financial service provider110 may receive a request for credit check information relating to user101. The request may originate fromcredit assessor160 or from another entity or device. In response, financialservice account provider110 may generate a credit check response associated with user101 (Step1620). The user credit check response may include information reflecting a single account held by user101 for purposes for assessing credit exposure, despitefinancial service provider110 providing an aggregated account reflecting multiple private label financial accounts.Financial service provider110 may provide the user credit check response (step1630) to the requesting entity or component (e.g., credit assessor160) overnetwork140 or other communication means. Thus, in certain aspects, the disclosed embodiments a credit check from a credit bureau (e.g., credit assessor160) may only be performed once, even if a user applies for several private label financial service accounts that may be aggregated into a single financial service account in accordance with the disclosed embodiments.
• Other embodiments will be apparent to those skilled in the art from consideration of the specification and practice of the disclosed embodiments. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the disclosed embodiments being indicated by the following claims. For example, the disclosed embodiments are applicable to any type of financial account, such as, for example: private label/store credit financial accounts, but also private label debit, gift, prepaid, and other stored value accounts (e.g., rewards/loyalty points). In some embodiments, a credit financial account may include promotional financing, long term financing, transactional credit, and installment loans. Further, the disclosed embodiments are agnostic to the form factor for the financial service accounts disclosed herein, and the means for authenticating those accounts, e.g., plastic card, mini-card, RFID tags, mobile payments (NFC, QR/barcode), online/remote transactions, biometric authentication, etc.
• In addition, the disclosed embodiments may be configured to enable the financial service accounts (e.g., aggregated accounts, private label accounts, etc) to be managed within single wallet, several wallets, or separate web/mobile applications. For example, the disclosed embodiments may be configured to provide a wallet or collection of wallets/apps to provide a communication platform for merchant-to-consumer messaging, such as, for example, deals, discounts, promotions, brand marketing, and/or targeted marketing. Further, the disclosed embodiments may be configured to generate such messaging (via, e.g.,server111, server151, or a combination of both). In one aspect, the disclosed embodiments may provide such messaging such that they can be targeted based on transaction data at all or a subset of participating merchants. The disclosed embodiments may be configured to provide targeting messaging that is informed by general purpose card spending by a consumer using the aggregated financial service accounts consistent with the disclosed embodiments. In other aspects, the disclosed embodiments may be configured to generate and provide messages based on real-time payments activity (e.g., generating and providing notifications immediately after checkout using an aggregated financial service account consistent with the disclosed embodiments). In other aspects, the disclosed embodiments may be configured to generate and provide follow-on recommendations messages, or generate and provide offers to users of the disclosed aggregated financial service accounts based on location/location-based check-ins, etc. (e.g., location ofclient120, user101, or both).
• In addition, the disclosed embodiments may be configured to provide additional messaging and communications based on transaction data, product data (e.g., SKU data), inventory data, etc., relating to purchase transactions performed using the aggregated financial service account consistent with the disclosed embodiments. For example, the disclosed embodiments may be configured to generate and provide product-level messaging based on product data (e.g., SKU data) associated with purchase transactions made by a user with an aggregated financial service account consistent with the disclosed embodiments,
• Further, the disclosed embodiments may be configured to provide a platform for product manufacturer communications and marketing. For instance, product manufacturers and brands (e.g., Nike, Levi's) may use the platform to send targeted communications and marketing messages to the user (e.g., promotions, local offers, group deals, brand. communications, review requests, post-purchase messages, new product suggestions, event or group invitations, or any other messages promoting the brand or its products, or any other messages promoting the brand or products of affiliated manufacturers or brands). These messages may be based on, e.g., the user's transaction data, product reviews, location, merchant affiliations, etc. The user may also send messages (e.g., requests, reviews, comments, etc) to the product manufacturers and brands, either by responding to their messages, or by initiating the messaging themselves.

Claims (20)

What is claimed is:

1. A server system comprising:

one or more memory devices storing software instructions; and

one or more processors executing the software instructions to perform operations comprising:

receiving a first electronic application for a first private label account corresponding to a first merchant, wherein the first electronic application is generated for an applicant at a first electronic interface corresponding to the first merchant;

performing a first assessment, wherein the first assessment assesses the first electronic application by:

sending a request to an assessor for known information associated with the applicant; and

verifying the known information associated with the applicant;

transmitting, via a first electronic notification, a first decision corresponding to the first electronic application, wherein the first decision is based on the first assessment;

receiving a second electronic application for a second private label account associated with a second merchant, wherein the second electronic application is generated for a second electronic interface corresponding to the second merchant;

performing a second assessment to determine a second decision, wherein the second assessment includes:

retrieving the first decision;

assessing the second electronic application based on the first decision; and

transmitting, via a second electronic notification, the second decision corresponding to the second electronic application.

2. The server system ofclaim 1, wherein the first electronic application and the second electronic application are presented via the first electronic interface and the second electronic interface, respectively, and wherein the first electronic interface and the second electronic interface are one or more of: a website, at a kiosk, or at a terminal at a physical location of the first merchant or the second merchant.

3. The server system ofclaim 1, wherein sending the request to the assessor includes requesting a credit assessor to perform processes for determining credit results, wherein the credit results are related to a credit score or summary credit information associated with the applicant.

4. The server system ofclaim 1, wherein the first electronic notification and the second electronic notification include information related to whether the first electronic application and the second electronic application were approved.

5. The server system ofclaim 4, wherein the first electronic notification includes transmitting, from a financial service provider, a set of commands to modify an interface on an applicant device associated with the applicant, wherein the set of commands display at least one of a logo, text, or graphics associated with the first merchant, such that the first electronic notification appears to be associated with and provided by the first merchant.

6. The server system ofclaim 1, wherein performing the second assessment further includes not sending a second request to the assessor and analyzing the known information locally.

7. The server system ofclaim 4, wherein the second electronic notification includes transmitting, from a financial service provider, commands to modify an interface on an applicant device associated with the applicant, wherein the commands display at least one of a logo, text, or graphics associated with the first merchant, such that the second electronic notification appears to be associated with and provided by the second merchant.

8. A computer-implemented method comprising:

receiving a first electronic application for a first private label account corresponding to a first merchant, wherein the first electronic application is generated for an applicant at a first electronic interface corresponding to the first merchant;

performing a first assessment, wherein the first assessment assesses the first electronic application by:

sending a request to an assessor for known information associated with the applicant; and

verifying the known information associated with the applicant;

transmitting, via a first electronic notification, a first decision corresponding to the first electronic application, wherein the first decision is based on the first assessment;

receiving a second electronic application for a second private label account associated with a second merchant, wherein the second electronic application is generated for a second electronic interface corresponding to the second merchant;

performing a second assessment to determine a second decision, wherein the second assessment includes:

retrieving the first decision;

assessing the second electronic application based on the first decision; and

transmitting, via a second electronic notification, the second decision corresponding to the second electronic application.

9. The computer-implemented method ofclaim 8, wherein the first electronic application and the second electronic application are presented via the first electronic interface and the second electronic interface, respectively, and wherein the first electronic interface and the second electronic interface are one or more of: a website, at a kiosk, or at a terminal at a physical location of the first merchant or the second merchant.

10. The computer-implemented method ofclaim 8, wherein sending the request to the assessor includes requesting a credit assessor to perform processes for determining credit results, wherein the credit results are related to a credit score or summary credit information associated with the applicant.

11. The computer-implemented method ofclaim 8, wherein the first electronic notification and the second electronic notification include information related to whether the first electronic application and the second electronic application were approved.

12. The computer-implemented method ofclaim 11, wherein the first electronic notification includes transmitting, from a financial service provider, a set of commands to modify an interface on an applicant device associated with the applicant, wherein the set of commands display at least one of a logo, text, or graphics associated with the first merchant, such that the first electronic notification appears to be associated with and provided by the first merchant.

13. The computer-implemented method ofclaim 8, wherein performing the second assessment further includes not sending a second request to the assessor and analyzing the known information locally.

14. The computer-implemented method ofclaim 11, wherein the second electronic notification includes transmitting, from a financial service provider, commands to modify an interface on an applicant device associated with the applicant, wherein the commands display at least one of a logo, text, or graphics associated with the first merchant, such that the second electronic notification appears to be associated with and provided by the second merchant.

15. A non-transitory computer readable medium storing instructions that, when executed by a processor, cause the processor to perform operations for:

receiving a first electronic application for a first private label account corresponding to a first merchant, wherein the first electronic application is generated for an applicant at a first electronic interface corresponding to the first merchant;

performing a first assessment, wherein the first assessment assesses the first electronic application by:

sending a request to an assessor for known information associated with the applicant; and

verifying the known information associated with the applicant;

transmitting, via a first electronic notification, a first decision corresponding to the first electronic application, wherein the first decision is based on the first assessment;

receiving a second electronic application for a second private label account associated with a second merchant, wherein the second electronic application is generated for a second electronic interface corresponding to the second merchant;

performing a second assessment to determine a second decision, wherein the second assessment includes:

retrieving the first decision;

assessing the second electronic application based on the first decision; and

transmitting, via a second electronic notification, the second decision corresponding to the second electronic application.

16. The non-transitory computer readable medium ofclaim 15, wherein the first electronic application and the second electronic application are presented via the first electronic interface and the second electronic interface, respectively, and wherein the first electronic interface and the second electronic interface are one or more of: a website, at a kiosk, or at a terminal at a physical location of the first merchant or the second merchant.

17. The non-transitory computer readable medium ofclaim 15, wherein sending the request to the assessor includes requesting a credit assessor to perform processes for determining credit results, wherein the credit results are related to a credit score or summary credit information associated with the applicant.

18. The non-transitory computer readable medium ofclaim 15, wherein the first electronic notification and the second electronic notification include information related to whether the first electronic application and the second electronic application were approved.

19. The non-transitory computer readable medium ofclaim 18, wherein the first electronic notification includes transmitting, from a financial service provider, a set of commands to modify an interface on an applicant device associated with the applicant, wherein the set of commands display at least one of a logo, text, or graphics associated with the first merchant, such that the first electronic notification appears to be associated with and provided by the first merchant.

20. The non-transitory computer readable medium ofclaim 15, performing the second assessment further includes not sending a second request to the assessor and analyzing the known information locally.

Images