Often there is an online set of credentials that identify a user and match them to a piece or set of data that a third party would like to have that user matched to. The present invention is a method to use the success or failure of an online log-in using a set of credentials to create or verify a user on another system and/or match the user on the to a piece or set of data on a third system.
The invention has many uses across many industries, but will be discussed with regard to a specific example. There is a specific application of the invented method that solves an acute need in the world of online banking. Financial institutions (including banks, credit unions and other institutions that hold or process money for customers) have recognized the desire of customers or members to access their accounts, view financial data, and perform transactions online from a remote location such as from a home or office rather than in-person in a physical bank, or credit union, stock brokerage, etc. Customers, members and account holders (hereinafter “customers”) often find online banking more convenient and efficient than having to visit a branch in person and the number that find online banking more convenient is increasing.
To facilitate online banking, financial institutions (hereinafter “FI”) establish their own or contract with an online banking provider (OLBP) which allows the FI's customers to access their accounts and perform transactions through a remote computer system rather than in-person at the FI's physical location. Referring to FIG. 1, an example of such a system is depicted.
In FIG. 1, the FI 101 typically creates and manages all accounts as well as processes all transactions through or using the FI's core computer system (or core banking system) 102. That is where confidential data such as customer or member account information is stored, such as on a data store 102a. An OLBP 103 is established to provide an online banking interface with the FI's customers. The OLBP utilizes custom APIs to establish its access to information on the FI's core computer system. The OLBP 103 will typically store or connect to certain information, like usernames and passwords that allow a user to access online banking; on a database it controls or has access to.
In the prior art in a traditional OLBP arrangement, an FI's customers have accessed their financial accounts held at the individual's bank or credit union through the institution's OLBP 103 via a remote desktop computer 109. That computer may be located at a home, office or elsewhere. Such interaction was typically conducted through the internet or other network. The OLBP utilizes a web server to maintain such service.
With the growing popularity and ubiquity of mobile computing devices (hereinafter “MCD” 106), such as smart phones (Apple iPhone® and Android® phone), tablet computers (Apple iPad®, etc.), and other mobile devices, FI customers now wish to access their accounts and conduct their financial transactions wirelessly from those MCDs. However due to size constraints, device limitations, the strong preference for native apps, etc., the standard OLB experience does not normally work well on these MDCs.
Mobile banking providers (hereinafter “Mobile Banking Provider” or “MBP” 108 with its own data store 108a) arose to bridge this gap in user experience and develop sites that can be viewed better on the smaller screen of MCDs, as well as create native apps that work on the MCDs. In order for a user to authenticate to an MCD and gain access to their banking information, the MCD would normally need to have a connection to the OLBP that would allow the authentication to occur via an API or similar connection that involves some work or authorization from the OLBP for the MBP to connect in that way. Not all OLBPs are willing to allow this type of connection to MBPs and many charge burdensome or prohibitive fees to do so. The OLBP can also take a very long time to do the work/authorization on their side to allow the MBP to connect this way. Some relationships that MBPs desire to form with OLBPs may never come about, which may result in the financial institution not being able to provide certain mobile account functionality to its customers. Consequently an MBP investing in an application to support mobile banking on a particular MCD cannot be certain when, if ever, the application in question will be able to integrate with a particular FI. And with approximately 13,000 banks and credit unions in the United States alone, the task of creating necessary integrations with each financial institution's OLBP is enormous.
It is important to note that MBP are not alone in this, any provider wishing to provide services to a FI that wants users' accounts behind the OLBP wall would usually need to pair its users to OLBP user data behind that wall.
The limitations of this situation in the prior art should be obvious. Not only is it time-consuming and expensive to create the necessary relationships with the OLBPs and write all of the APIs, but those OLBPs must be maintained at great expense. The MBP also has no guarantee that the OLBP or similar partner will ever grant the authorization or do the work needed for the MBP to connect in this manner.
Further, as FIs generally focus on the banking business and not on the software development business or even on new technologies such as mobile devices and mobile banking, it is typically left to third party application developers and MBPs to develop relevant new software applications.
Many FIs are under arduous and lengthy contracts with OLBPs that are not motivated to integrate best of breed new technologies, especially those the OLBP feels are a threat. In these situations the OLBPs often act like a “troll” that will either inflict punishing integration fees, costing the FI more than the MBP service in the first place to try to keep a competitor out. Often, the OLBP will unfortunately do this even if it is against the FI's wishes and best interest and even though the FI is supposed to be the customer the OLBP is meant to serve. This is a very abusive practice by the OLBP, the entrenched provider. Making matters even worse for the FI or the customer that is meant to be served, some OLBPs will simply not allow anyone to cross that integration bridge even if the FI or MBP is willing to pay the abusive fee.
At best the process of a MBP having to integrate with an OLBP in order to serve an FI is slow, inefficient and costly. At worst, it is either impossibly expensive or simply blocked, to the detriment of the FI.
The prior art reveals a clear need for a way to provide efficient connectivity between MCDs and FIs other than either working one at a time through OLBPs or establishing a connection direction with each of the many FIs. The invention seeks to provide a more efficient method or technique for MBP's to authenticate account information in order to correlate with financial institutions banking platforms and support mobile banking, PFM and other applications of that nature for all or substantially all financial institutions.