With the increase in popularity of the Internet, a global internetwork of networks that allow for data transport between Internet nodes including nodes accessible by consumers and financial institutions, there has been an increase in the number and variety of uses of the Internet. For example, consumers can interact with merchants over the Internet to obtain information about the merchant's products or to make purchases. Also, some merchants and service providers that maintain data about the consumer can provide that data over the Internet. For example, financial institutions maintain data about their customers, such as transaction histories, balances and the like, and provide that data to their customers, often in the form of a printed statement. A more convenient method of providing the information to customer might be to allow the customer to connect a customer client to a server operated by the financial institution so that the customer client can obtain the customer's data and present the customer's data to the customer.
This client-server approach is quite common. A typical form of this service couples the financial institution's databases to a HyperText Transport Protocol (HTTP) server so that a customer using an HTTP client, such as a Web browser, can access the HTTP server and get the customer information. One drawback of this arrangement is that when the customer has many different accounts, the customer cannot see the data in one place. Some financial institutions have used this fact to create consolidated services, such as a checking account, savings account, credit card and brokerage account, all offered by one financial institution. While this is convenient for some customers, many other customers prefer to pick and choose the best of each type of service from their preferred provider.
One portal solution is the “stand-in” system, where a portal operator stands in place of the user to get data from the financial institution. FIG. 1 is a block diagram of such a system. As shown there, a user interacts with the system using a user client 12 that is coupled to a portal site 14. Portal site 14 is shown comprising a portal server 16 and a stored user authentication database 18. Portal server 16 is coupled to a financial institution (FI) server 20 at a financial institution, which is shown coupled to a user account database 22. The connections shown provide a path for user client 12 to provide the user's FI username and password to portal server 16, a path for portal server 16 to read and write user authentication data (such as username, password, associate FI, etc.) to database 18, a path for portal server 16 to provide user authentication data to FI server 20, a path for FI server 20 to read and write user account data in database 22, and paths for the user account data to flow from FI server 20 to portal server 16 and then to user client 12.
To set up a stand-in arrangement, the user sets up an account with a portal operator, including portal user authentication data, such as a user ID and password that authenticates the user to the portal. The user then provides the portal operator with all the financial institution authentication data the user uses to connect to the financial institution servers and an indication of the financial institution (e.g., domain name, URL, or IP address). The portal operator stores the user's financial institution authentication data at its servers. When the user makes a request for information from the portal, the portal server connects to the financial institution server and, using the user authentication data, logs on as the user and gets the information it needs. In some cases, since the financial institution does not necessarily know that a computer posing as the user is accessing the financial institution server and not the user directly, the portal server must do some additional processing to format the data in a form suitable for computer processing, if the information is only obtainable in a form suitable for display to the user. However, in many cases today, financial institution on-line services provide OFX connectivity, where the financial institution does not assume that an interactive user is the client, but instead provides information according to the OFX protocol.
However the data is formatted, the financial institution generally cannot control what the portal system does with the user's account when the portal system logs on as the user. Consequently, there is a risk that if a database of user IDs and passwords stored at the portal is compromised, the attacker could then access many users' financial institution accounts and even make transactions on those accounts. If such compromise occurs, it would be difficult to determine which transactions are legitimate and would require all the affected users to change their passwords and possibly even change their user IDs.
Another solution that doesn't require storage of financial institution user authentication data at the portal is a client-handoff system, wherein the user logs onto the financial institution system using an interactive client that is programmed to get the user's information from the financial institution system and provide it to the portal site for storage there.
FIG. 2 is a block diagram illustrating such a system. The diagram shows a user client 32, a database 34 for locally stored user authentication data, a portal server 36, a database 38 for stored user data and an FI server 40. In one embodiment of such a system, the user client is a browser that includes an authentication plug-in. The plug-in is programmed to either prompt the user or passively follow the user as the user logs onto the financial institution server and the portal server.
The connections shown provide a path for user client 32 to read and write authentication data to or from database 34, a path for user client 32 to log onto FI server 40, a path for user client 32 to retrieve user data from FI server 40, a path to provide the retrieved data from user client 32 to portal server 36 (with the data possibly also stored at user client 32), a path for portal server 36 to read and write data to or from database 38, and a path between user client 32 and portal serer 36 over which user client 32 might request user data and over which portal server 36 would provide user data to user client 32. Of course, for the system shown to be more desirable than a direct log on system, portal server 36 would provide the user's data in a more desirable form than could, or would, be provided by FI server 40. For example, portal server 36 might format the data in a better format and/or might combine the user's data from multiple FI servers to provide an integrated view of the data.
In operation, the user would log user client 32 onto the FI server 40 and retrieve user data stored there, then provide that user data to portal server 36. Unless the user performs that action with respect to each of the user's FI's, the data at portal server 36 might be out of date when user client 32 retrieves a view of the data from portal server 36. Thus, a disadvantage of this approach is that the information at the portal server is not current, but is only current as of the last time the user logged onto the financial institution server and performed a transfer of data to the portal servers.