Patent Publication Number: US-9842367-B2

Title: Centralized financial account migration system

Description:
BACKGROUND 
     Financial institutions are increasingly allowing customers to directly access and manage account information. For example, customers can manage one-time or recurring funds transfers, pay bills, set up automated withdrawals, or authorize Automated Clearing House (ACH) transactions for a particular customer account. Typically, this is allowed at automated teller machines (ATMs) or via an online portal at which customer data can be accessed (for example, via a web browser). 
     When a customer moves from one bank to another, however, some problems can arise. Transferring bank account information from one or more financial institutions to a new financial institution require customers to manually close their old bank accounts and to manually reestablish previously existing services at their new bank accounts. Under the new bank accounts, customers manually reestablish information, such as their list of bill pay payees, bill pay payment schedule, scheduled transfers, electronic bills (“eBills”), and automatic debits and credits. The process of manually reestablishing old bank account services at the new bank account can be inefficient and can waste time, energy, and resources. Furthermore, it can be difficult for customers to remember to establish such bank account services, in particular for payment occurrences which occur relatively infrequently (e.g., semi-annually, annually, or less frequently or erratically). 
     In some cases, financial institutions have attempted to at least partially automate a process by which new customers can import settings for such automated services from a prior account into a new account. However, even such systems have drawbacks. For example, such systems often are able to detect and import bill pay information or other types of transactions originating at the former account, they are not as able to detect cases in which third party automated transfers would occur, such as in the case of an Automated Clearing House (ACH) transaction. This is because such transactions are not represented within the settings of an account at the financial institution but are instead managed by that third party (e.g., a utility provider). From the perspective of the former financial institution, such ACH or other third-party originated transactions are only reflected in a transaction history for that account. 
     Furthermore, existing attempts by financial institutions to automate importation of settings for such bill pay services are also limited in terms of the flexibility of the services provided. Typically, if a financial institution provides such settings importation services, it does so only with respect to the customer&#39;s new account at that financial institution. In other words, such solutions are not configurable to be used in connection with any desired new account at any desired new financial institution. Because financial institutions lack any motivation to provide a tool by which customers could export bank account settings (among other reasons), such tools remain unavailable from financial institutions. 
     For these and other reasons, improvements in the area of financial account migration are desired. 
     SUMMARY 
     In accordance with the following disclosure, the above and other issues are addressed by the following: 
     In a first aspect, a system for migration of financial account settings are disclosed. The system includes a migration server. The migration server includes a database for tracking account settings migration including one or more switch tracking numbers associated with account migrations. The migration server further includes a web interface configured to receive from a user a switch tracking number, identification and login information associated with one or more existing financial accounts, and login information associated with a target financial account. The migration server also includes a transaction analysis module configured to parse transaction histories associated with each of the existing financial accounts to determine one or more likely automated funds transfers associated with each of the one or more existing financial accounts. The migration server further includes a migration module configured to initiate a migration of one or more likely automated funds transfers associated with each of the existing financial accounts. 
     In a second aspect, a method for managing automated migration of account settings between financial accounts is disclosed. The method includes receiving identification and login information associated with one or more existing financial accounts at a migration server, each of the one or more existing financial accounts including one or more automated funds transfers associated therewith. The method also includes receiving login information associated with a target financial account to which account settings are to be migrated. The method further includes parsing transaction histories associated with each of the one or more existing financial accounts to determine one or more likely automated funds transfers associated with each of the one or more existing financial accounts, and receiving at the migration server a selection by a user of one or more of the likely automated funds transfers. The method includes receiving user authorization to initiate migration of the selected automated funds transfers, and initiating migration of the selected automated funds transfers to the target financial account by extracting information associated with the selected automated funds transfers from the one or more existing financial accounts and creating corresponding automated funds transfers associated with the target financial account. The method also includes tracking the migration of the selected automated funds transfers in a database at the migration server, the migration of the selected automated funds transfers associated with a switch tracking number generated by the migration server. 
     In a third aspect, a method for migrating account settings between financial accounts is disclosed. The method includes providing login information and institution information associated with one or more existing financial accounts into a user interface provided from a migration server, each of the one or more existing financial accounts including one or more automated funds transfers associated therewith. The method also includes providing login information associated with a target financial account to which account settings are to be migrated into the user interface provided from a migration server. The method further includes selecting one or more displayed automated funds transfers displayed in a user interface provided by the migration server, the displayed automated funds transfers based at least in part on an automated analysis of a transaction history of each of the one or more existing financial accounts. The method includes providing electronic approval of the selected automated funds transfers from the one or more existing financial accounts to the target financial account, thereby initiating migration of settings of the one or more existing financial accounts to the target financial account. 
     This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  illustrates an overall network in which customers can interact with new and old financial institutions and third party payment initiators, according to an example embodiment; 
         FIG. 2  illustrates a block diagram of a conversion server useable in connection with the present disclosure; 
         FIG. 3  illustrates an example schema illustrating data managed by the migration server to perform configurable financial settings importation processes, according to an example embodiment; 
         FIG. 4  is a schematic illustration of an example computing system in which aspects of the present disclosure can be implemented; 
         FIG. 5  is a flowchart of a method by which a user can interact with a conversion server to initiate an automated financial account settings migration, according to an example embodiment; 
         FIG. 6A  is a flowchart of a method of activating an automated financial account settings migration based on a request from a financial institution, according to an example embodiment; 
         FIG. 6B  is a flowchart of a method of converting automated financial account settings at a conversion server, according to an example embodiment; 
         FIG. 7  is a schematic user interface of an initial welcome page presented to a user by a conversion server for initiating an automated financial account settings migration, according to an example embodiment; 
         FIG. 8  is a schematic user interface of a terms of service page presented to a user by a conversion server for initiating an automated financial account settings transfer, according to an example embodiment; 
         FIG. 9  is a schematic user interface of an old accounts login page presented to a user by a conversion server for initiating an automated financial account settings migration, according to an example embodiment; 
         FIG. 10  is a schematic user interface of a new account login page presented to a user by a conversion server for initiating an automated financial account settings migration, according to an example embodiment; 
         FIG. 11  is a schematic user interface of a login confirmation page presented to a user by a conversion server for initiating an automated financial account settings migration, according to an example embodiment; 
         FIG. 12  is a schematic user interface of a billpay confirmation page presented to a user by a conversion server for initiating an automated financial account settings migration, according to an example embodiment; 
         FIG. 13  is a schematic user interface of an ACH confirmation page presented to a user by a conversion server for initiating an automated financial account settings migration, according to an example embodiment; 
         FIG. 14  is a schematic user interface of a migration review page presented to a user by a conversion server for initiating an automated financial account settings migration, according to an example embodiment; 
         FIG. 15  is a schematic user interface of a status notification page presented to a user by a conversion server for initiating an automated financial account settings migration, according to an example embodiment; and 
         FIG. 16  is a schematic user interface of a migration status page presented to a user by a conversion server for initiating an automated financial account settings migration, according to an example embodiment. 
     
    
    
     DETAILED DESCRIPTION 
     Various embodiments of the present invention will be described in detail with reference to the drawings, wherein like reference numerals represent like parts and assemblies throughout the several views. Reference to various embodiments does not limit the scope of the invention, which is limited only by the scope of the claims attached hereto. Additionally, any examples set forth in this specification are not intended to be limiting and merely set forth some of the many possible embodiments for the claimed invention. 
     The logical operations of the various embodiments of the disclosure described herein are implemented as: (1) a sequence of computer implemented steps, operations, or procedures running on a programmable circuit within a computer, and/or (2) a sequence of computer implemented steps, operations, or procedures running on a programmable circuit within a directory system, database, or compiler. 
     In general, the present disclosure relates to methods and systems for enabling automated migration of financial account settings from one or more existing financial accounts, including accounts at different financial institutions, to a target account at a designated financial institution. The financial accounts, as discussed herein, can include any of a variety of types of accounts that support financial transfers that are initiated either from the account itself or from external to the account, for example from an Automated Clearing House (ACH) transaction. Such accounts can include customer checking or savings accounts at banks, credit unions, or other types of financial institutions. 
     The methods and systems described herein provide for, in certain embodiments, a centralized migration server that can be used in connection with target accounts of different financial institutions, and can be used to migrate account settings from one or more existing accounts at a time. These include both bill pay and ACH transactions, which are initiated from within the account and by third parties, respectively. Accordingly, the methods and systems of the present disclosure provide a number of advantages over existing solutions. For example, the present disclosure provides for additional flexibility with respect to the institution associated with the target account, and to allow for different financial institutions to receive migrations of account settings. Additionally, the methods and systems of the present disclosure support not just those settings within a financial account such as bill pay settings, but also support analysis of transactions to determine likely third party recurring payments that are indicated in the transaction histories of the accounts from which settings are transferred. This is despite the fact that the account under analysis by the migration server may not include any indication, other than the existence of the transaction, that such a transaction may occur, and may occur with a particular frequency. 
     Referring now to  FIGS. 1-4 , a generalized computing environment in which aspects of the present disclosure can be implemented is disclosed.  FIG. 1  illustrates an overall network  100  in which customers can interact with new and old financial institutions and third party payment initiators, according to an example embodiment of the present disclosure. 
     In the exemplary embodiment shown, the network  100  includes a plurality of financial institutions  102 . In the embodiment shown, three such financial institutions  102 , shown as financial institutions  102   a - c  are shown; it is understood that additional financial institutions could be included in any such example network but that the three financial institutions  102   a - c  are depicted for purposes of simplicity. Each of the financial institutions  102   a - c  generally will manage a plurality of customer accounts, any may allow online access to customers to manage accounts held with those institutions. Such online access may be provided by way of an internet-based portal to view account balances, manage bill pay processes, and view transaction histories associated with such accounts. Other functionalities are typically available from such institutions (e.g., reordering checks, balance transfers, etc.) and are well known in the art. 
     In conjunction with the present disclosure, a plurality of clients can be allowed to access financial accounts held at one or more of the financial institutions  102   a - c . In the example shown, a client using a computing system  104 , or mobile device  106 , could access accounts at various financial institutions by providing login information (e.g., username and password or other identifying information) to access account information. The computing system  104  or mobile device  106  can connect to a financial institution from among financial institutions  102   a - c  via a secure connection over a network  106 , such as the Internet. Any of a variety of secure communications protocols (e.g., SSL/TLS, etc.) can be used. 
     In addition, a client may be a customer of a third party service or carrier, such as an insurance carrier, a cell phone carrier, or a utility (shown as third party  110 ). Such third parties  110  may provide a service to the client in which bills are, rather than being paid by periodic check, instead paid using an Automated Clearing House (ACH) transaction in which electronic transfer is provided based on authorization previously provided by a client/user. Such ACH transactions often take the place of traditional check-based bill payments, since they can be instituted by an entity to whom payment is owed upon authorization of the payee (i.e., the client), but do not require the lag time traditionally incurred during a check clearance process. 
     In the embodiment shown, a migration server  200  is also communicatively connected to the network  108 . The migration server  200  generally manages a process by which automated payments, whether bill pay, ACH, or other types of payment, can be migrated from accounts associated with the client to a new account at a new financial institution  102 . 
     As seen in  FIG. 2 , the migration server  200  includes a web interface component  202  that is configured to provide a plurality of web-based user interfaces to manage processes by which account transfers can be performed. Example methods enabled by the web interface are described in connection with  FIGS. 6A-6B , and example user interfaces are discussed in further detail below in connection with  FIGS. 7-16 . 
     The migration server  200  further includes a switch tracking module  204 , which includes a database for managing and tracking account migration processes. The migration server  200  will, in some embodiments, associate a switch tracking number with a particular target account in a database internal to the migration server  200 , for managing the migration process. The switch tracking number can be, in various embodiments, be affiliated with target account information (e.g., an identity of the financial institution holding the target account and username/login information of the customer to whom the account is associated) as well as one or more settings to be migrated to that target account. 
     In connection with the present disclosure, a transaction analysis module  206  will parse transaction histories and settings of one or more existing accounts to detect various types of transactions that a customer may wish to migrate to his/her target account. The transaction analysis module  206  will access transaction histories of existing accounts identified by the customer to determine the existence of bill pay or ACH transactions. Preferably, the transaction analysis module  206  will access at least one year or more of transaction history for each of the one or more existing accounts from which to migrate settings, to allow the transaction analysis module  206  to (1) determine, for monthly or other frequent transactions, a reliable or average amount which will be expected for an ACH transaction or bill pay transaction, and (2) to detect transactions that do not occur regularly, such as bi-annual insurance payments, or annual payments of other types (e.g., property taxes, etc.). The detected recurring electronic transfers will be marked, by the transaction analysis module  206 , by type, for review by the customer to determine if migration is desired. 
     Those transactions or transfers selected by the customer will be passed to a migration module  208 , which will manage migration of those automated transfer settings from the existing accounts to the target account. The migration module  208  determines settings for bill pay transactions and establishes such bill pays at the target account. This can include, for example, setting up the bill pay, as well as receiving confirmation from the financial institution of the target account that the setup of that bill pay was successful (e.g., by receiving a confirmation message from the financial institution). Migration can also include setting up expected ACH transactions, by notifying one or more third party carriers (e.g., third parties  110 ) of the new destination account to which those ACH transactions are to be targeted. In such embodiments, notification of the ACH-related third parties can include a consideration of a number of factors. These include the typical day on which ACH transactions are initiated by the third party, as well as typical amounts of funds transferred as part of that transaction. 
     In accordance with the present disclosure, it is noted that although in some embodiments a settings transfer among accounts may include a funds transfer from existing accounts to the target account to ensure that funds exist in the target account to satisfy the various bill pay or ACH transactions, it is also possible that it may take some time for, in particular ACH transactions, to take effect. As such, in accordance with the present disclosure, the migration module  208  performs a timed migration process by which at least a portion of funds is retained in existing accounts in case third parties performing ACH transactions do not update the account associated with the ACH transaction. If that account is not updated to the target account but funds are transferred to the target account, the ACH transaction will fail, with negative effects for the third party (a delay in payment) and for the customer (late fees, insufficient funds charges associated with the existing account, etc.). After a period of time, typically less than a full period between ACH transactions from a given third party, the amount of funds expected to be associated with the ACH transaction (as detected by the transaction analysis module  206 ) will be released, allowing for its transfer to the target account. 
     It is noted that, although in the embodiments of  FIGS. 1-2  only a single migration server  200  is shown, it is recognized that equivalently a plurality of computing systems could be used to implement the migration server  200 . For example, a separate web server could implement the web interface component  202 , from a database server implementing the switch tracking module  204 . Other transaction servers could be used as well for the transaction analysis module  206  or the migration module  208  as well, with each of the servers used to implement the migration systems and processes of the present disclosure being communicatively interconnected. Additional details regarding the settings migration, including migration of direct deposit, bill pay, and ACH or other transactions are described below in connection with  FIGS. 5 and 6A-6B , as well as the user interfaces of  FIGS. 7-11 . 
     Referring now to  FIG. 3 , an example schema  300  illustrating data managed by the migration server to perform configurable financial settings importation processes is shown, according to an example embodiment. In the embodiment shown, the example schema  300  includes a plurality of record directories, including a migration webserver directory  302 , a customer banks directory  304 , and a third party interface directory  306 . 
     The migration webserver directory  302  maintains web server files, such as screen data and security rules used to maintain secure communications with financial institutions and customers seeking to migrate accounts among such financial institutions. The customer banks directory  304  maintains a list of customer banks from whom requests for migration can be received, as well as information about those customer banks. This information can be used to determine whether to issue a switch tracking number to a particular bank, and whether to initiate a switch tracking record using the switch tracking module  204  described above. The third party interface directory  306  provides a similar interface defining how to connect to third parties, for example to notify those third parties of changes to ACH settings (i.e. the change to a new target account from an existing account identified by the ACH settings). 
     The schema  300  further includes a secure login directory  308 , a bill pay transfer directory  310 , and automated payment transfer directories  312 ,  314 . The secure login directory  308  defines user credentials for which customers can access a switch tracking record, to allow the customer to access partially-completed migration requests, or to otherwise log in to the migration server to access historical records or to view a status of a requested migration. The user credentials can include, for example, username and password, or a switch track number and/or login credentials associated with the target financial account. 
     The bill pay transfer directory  310  stores information associated with pending bill pay migrations that are entered by a user and are to be migrated to new accounts. Similarly, the automated payment transfer directories  312 ,  314  store data associated with scheduled automated funds transfers, such as ACH payments. 
     The directories can be implemented in a variety of ways. In an example embodiment, the directories can be maintained within the file system of the migration server  200 . In alternative embodiments, the directories can each be implemented as one or more tables of a database. Other possibilities exist as well, as are known in the art. 
     Referring now to  FIG. 4 , a schematic illustration of an example computing system in which aspects of the present disclosure can be implemented. The computing device  300  can represent, for example, a migration server, such as migration server  200  of  FIGS. 1-2 . In particular, the computing device  400  represents the physical construct of an example computing system at which an endpoint or server could be established. In particular, in various embodiments, the computing device  400  implements one particular instruction set architecture, and can be used to execute non-native software and/or translate non-native code streams in an adaptive manner, for execution in accordance with the methods and systems described herein. 
     In the example of  FIG. 4 , the computing device  400  includes a memory  402 , a processing system  404 , a secondary storage device  406 , a network interface card  408 , a video interface  410 , a display unit  412 , an external component interface  414 , and a communication medium  416 . The memory  402  includes one or more computer storage media capable of storing data and/or instructions. In different embodiments, the memory  402  is implemented in different ways. For example, the memory  402  can be implemented using various types of computer storage media. 
     The processing system  404  includes one or more processing units. A processing unit is a physical device or article of manufacture comprising one or more integrated circuits that selectively execute software instructions. In various embodiments, the processing system  404  is implemented in various ways. For example, the processing system  404  can be implemented as one or more physical or logical processing cores. In another example, the processing system  404  can include one or more separate microprocessors. In yet another example embodiment, the processing system  404  can include an application-specific integrated circuit (ASIC) that provides specific functionality. In yet another example, the processing system  404  provides specific functionality by using an ASIC and by executing computer-executable instructions. 
     The secondary storage device  406  includes one or more computer storage media. The secondary storage device  406  stores data and software instructions not directly accessible by the processing system  404 . In other words, the processing system  404  performs an I/O operation to retrieve data and/or software instructions from the secondary storage device  406 . In various embodiments, the secondary storage device  406  includes various types of computer storage media. For example, the secondary storage device  406  can include one or more magnetic disks, magnetic tape drives, optical discs, solid state memory devices, and/or other types of computer storage media. 
     The network interface card  408  enables the computing device  400  to send data to and receive data from a communication network. In different embodiments, the network interface card  408  is implemented in different ways. For example, the network interface card  408  can be implemented as an Ethernet interface, a token-ring network interface, a fiber optic network interface, a wireless network interface (e.g., WiFi, WiMax, etc.), or another type of network interface. 
     The video interface  410  enables the computing device  400  to output video information to the display unit  412 . The display unit  412  can be various types of devices for displaying video information, such as an LCD display panel, a plasma screen display panel, a touch-sensitive display panel, an LED screen, a cathode-ray tube display, or a projector. The video interface  410  can communicate with the display unit  412  in various ways, such as via a Universal Serial Bus (USB) connector, a VGA connector, a digital visual interface (DVI) connector, an S-Video connector, a High-Definition Multimedia Interface (HDMI) interface, or a DisplayPort connector. 
     The external component interface  414  enables the computing device  400  to communicate with external devices. For example, the external component interface  414  can be a USB interface, a FireWire interface, a serial port interface, a parallel port interface, a PS/2 interface, and/or another type of interface that enables the computing device  400  to communicate with external devices. In various embodiments, the external component interface  414  enables the computing device  400  to communicate with various external components, such as external storage devices, input devices, speakers, modems, media player docks, other computing devices, scanners, digital cameras, and fingerprint readers. 
     The communication medium  416  facilitates communication among the hardware components of the computing device  400 . In the example of  FIG. 4 , the communications medium  416  facilitates communication among the memory  402 , the processing system  404 , the secondary storage device  406 , the network interface card  408 , the video interface  410 , and the external component interface  414 . The communications medium  416  can be implemented in various ways. For example, the communications medium  416  can include a PCI bus, a PCI Express bus, an accelerated graphics port (AGP) bus, a serial Advanced Technology Attachment (ATA) interconnect, a parallel ATA interconnect, a Fiber Channel interconnect, a USB bus, a Small Computing system Interface (SCSI) interface, or another type of communications medium. 
     The memory  402  stores various types of data and/or software instructions. For instance, in the example of  FIG. 4 , the memory  402  stores a Basic Input/Output System (BIOS)  418  and an operating system  420 . The BIOS  418  includes a set of computer-executable instructions that, when executed by the processing system  404 , cause the computing device  400  to boot up. The operating system  420  includes a set of computer-executable instructions that, when executed by the processing system  404 , cause the computing device  400  to provide an operating system that coordinates the activities and sharing of resources of the computing device  400 . Furthermore, the memory  402  stores application software  422 . The application software  422  includes computer-executable instructions, that when executed by the processing system  404 , cause the computing device  400  to provide one or more applications. The memory  402  also stores program data  424 . The program data  424  is data used by programs that execute on the computing device  400 . 
     Although particular features are discussed herein as included within an electronic computing device  400 , it is recognized that in certain embodiments not all such components or features may be included within a computing device executing according to the methods and systems of the present disclosure. Furthermore, different types of hardware and/or software systems could be incorporated into such an electronic computing device. 
     In accordance with the present disclosure, the term computer readable media as used herein may include computer storage media and communication media. As used in this document, a computer storage medium is a device or article of manufacture that stores data and/or computer-executable instructions. Computer storage media may include volatile and nonvolatile, removable and non-removable devices or articles of manufacture implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. By way of example, and not limitation, computer storage media may include dynamic random access memory (DRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), reduced latency DRAM, DDR2 SDRAM, DDR3 SDRAM, solid state memory, read-only memory (ROM), electrically-erasable programmable ROM, optical discs (e.g., CD-ROMs, DVDs, etc.), magnetic disks (e.g., hard disks, floppy disks, etc.), magnetic tapes, and other types of devices and/or articles of manufacture that store data. Communication media may be embodied by computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and includes any information delivery media. The term “modulated data signal” may describe a signal that has one or more characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media may include wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, radio frequency (RF), infrared, and other wireless media. 
     Referring to  FIGS. 5 and 6A-6B , various methods by which the automated migration of account settings are described.  FIG. 5  generally describes a method  500  performed by a customer of a financial institution who wishes to migrate account settings to a target account.  FIGS. 6A-6B  illustrate methods  600 ,  650 , respectively, performed by the migration server to accomplish the account settings migration process. 
     Referring now to  FIG. 5 , method  500  by which a user can interact with a conversion server to initiate an automated financial account settings migration includes a login operation  502 . The login operation  502  includes, in some embodiments, providing a switch tracking number received by the user from a financial institution that holds a target financial account to which settings are to be migrated. The login operation  502  can be accomplished, for example, via a browser window and accessing a user interface generated by the migration server, such as user interface  700  of  FIG. 7 . 
     A terms of service operation  504  corresponds to accepting terms of service applied by the migration server; such terms of service can be any of a variety of conventional terms of service or notice provisions relating to migration of funds or migration of settings between accounts. An example of a browser-based user interface with which the terms of service operation  504  can be performed is discussed below in connection with user interface  800  of  FIG. 8 . 
     An old accounts login operation  506  includes providing, via a further user interface, an identity of one or more source financial accounts from which settings and/or funds are to be transferred. This can include, for example, providing a name of the financial institution at which the existing account resides, as well as access credentials, such as a username and password, of a customer associated with the account. An example of a browser-based user interface with which the old accounts login operation  506  can be performed is discussed below in connection with user interface  900  of  FIG. 9 . 
     A new account login operation  508  includes providing, via a still further user interface, access credentials to a target account to which user settings, such a funds transfer settings (e.g., bill pay, direct deposit, ACH, etc.) can be migrated. An example of a browser-based user interface with which the new account login operation  508  can be performed is discussed below in connection with user interface  1000  of  FIG. 10 . 
     An account confirmation operation  510  presents to the user a summary of the accounts to be accessed for the account migration process. Optionally, the user can opt to add additional old accounts, selecting a button indicating a desire to return to the old accounts login operation  506  to add additional accounts to be migrated. Or, the user can confirm the accounts to be migrated and opt to proceed to select specific settings and/or features of those accounts to be migrated. An example of a browser-based user interface with which the account confirmation operation  510  can be performed is discussed below in connection with user interface  1100  of  FIG. 11 . 
     Following the account confirmation operation  510 , the migration server will access the accounts identified by the user, and will access both settings associated with those preexisting accounts, as well as transaction history information associated with the accounts. The migration server will, based on parsing of the transaction history (to the extent available, and preferably for at least the past year of account transactions), determine whether one or more funds transfers have occurred in any of those accounts, and whether such funds transfers correspond to recurring events that should potentially be transferred to the target account. 
     A bill pay selection operation  512  corresponds to selection of one or more detected bill pay operations that the user wishes to transfer to the target account associated with the migration operation. In example embodiments, the user is presented with a plurality of different bill pay operations that are detected by the migration server. The bill pay selection operation  512  includes a user selecting at least one of the identified bill pay transactions that were detected based on the user&#39;s old (i.e., preexisting) account information. 
     Similarly, an ACH selection operation  514  corresponds to selection of one or more detected ACH operations that the user wishes to transfer to the target account. As with the bill pay operation, the user is presented with a selectable list of operations that are detected by the migration server. Example user interfaces associated with the bill pay selection operation  512  and ACH selection operation  514  are described below in connection with  FIGS. 12-13 . 
     Although in the context of the present disclosure a bill pay and ACH type operations are discussed, it is recognized that these types of payments are exemplary, rather than limiting. In particular, the bill pay transactions can represent any of a variety of transactions associated with funds transfers originating at the institution holding the existing account, while ACH operations represent types of operations that are initiated remote from the institution (e.g., ACH payments, direct deposits, etc.). 
     An approval operation  516  corresponds to review and approval of the selected list of funds transfer operations that are to be migrated to the target account. The approval operation  516  can include providing an electronic signature to authorize the switch of bill pay and ACH transactions. An example of a user interface useable to perform the approval operation  516  is described below in connection with  FIG. 14 . 
     Following the approval operation  516 , the migration server will initiate a migration process. This will include migration to the target account any selected bill pay or ACH transactions. For bill pay transactions, this can include the migration server copying the bill pay transaction to the target account, validating the bill pay transaction, and removing the bill pay transaction from the account from which it was migrated. For ACH transactions, this can include notifying an ACH-originating entity (typically a third party unaffiliated with the financial institutions) and verifying that confirmation of a changed ACH transaction is received. Optionally, the migration server can also transfer funds from existing accounts to the new (target) account. In such embodiments, it may be suggested to the user that at least some of the funds in the existing account not be transferred until the customer is sure that the ACH transaction has successfully been transferred to the target account. 
     A status operation  518  allows a user to access a migration operation by way of either notifications or through use of a switch track number. To use a switch track number, a user can enter such a number into the user interface of  FIG. 7 , discussed below. To register for notifications, a user interface can receive contact information, such as an email address or cell phone number. When changes have completed successfully, a link can be sent to the user to view a status of the migration. An example user interface for registering for such notifications is discussed in further detail below in connection with  FIG. 15 , and an example user interface for reviewing an account status for a particular migration is discussed in connection with  FIG. 16 . 
     Referring now to  FIGS. 6A-6B , flowcharts of methods performed by a migration server, such as server  200 , are disclosed, and which describe in further detail operations performed by the migration server to accomplish an automated migration of financial account settings. 
       FIG. 6A  is a flowchart of a method  600  of activating an automated financial account settings migration based on a request from a financial institution, according to an example embodiment. The method  600  is instantiated when the migration system receives a request from the financial institution to institute a migration. The financial institution from which the request is received is stored in a database, such as in schema  300 , and the migration server performs a generation operation  602 , which generates a new switch track number. The switch track number is associated with the financial institution at an association operation  604 , and provided to the financial institution associated with a target account at a transmission operation  606 . The financial institution can then provide the switch track number to a customer, or can use the switch track number to assist the customer in migrating automated funds transfers to the account associated with that financial institution. The switch track number can take any of a variety of forms, such as any combination of alphanumerical characters useable to uniquely identify the migration process to a particular target account of the financial institution associated with that target account. 
       FIG. 6B  is a flowchart of a method  650  of converting automated financial account settings at a conversion server, according to an example embodiment. The method  650  is generally performed by the migration server in response to access by a customer, which may be the customer receiving the switch track number as noted in  FIG. 6A . 
     In the embodiment shown, the method  650  includes a switch track number receipt operation  652 , which receives a switch track number from a user in a user interface presented to the user, such as user interface  700  of  FIG. 7 . The method further includes an old account operation  654 , which includes receiving old account identity and login information in a user interface, such as interface  900  of  FIG. 9 . The method also includes a new account operation  656 , which includes receiving new account login information in a user interface, such as interface  1000  of  FIG. 10 . It is noted that the user can opt to enter additional old account information, for example by returning to user interface  900  to enter additional old account login information. As such, multiple existing accounts can be migrated into a single “new”, or target, account. 
     Upon receiving user authorization (as discussed above in connection with  FIG. 5 ), an analysis operation  658  accesses the old accounts (i.e., preexisting accounts) to determine the existence of any funds transfer operations that may be desirable to migrate to a new target account. This can include reviewing scheduled payments associated with the accounts themselves, as well as ACH or other third party initiated payments that are reflected in the transaction history of each account. In preferred embodiments, transaction histories are reviewed across a long amount of time to ensure that even intermittent or infrequent funds transfers are captured. For example, it may be, in some embodiments, preferable to review at least a year of transaction data from preexisting accounts, to the extent such information is available via the online access provided by the financial institutions associated with those existing accounts. In other embodiments, as much transaction data as is available from the preexisting financial institution can be used. 
     A billpay display operation  660  displays each of the billpay operations that are detected in the account settings or transaction history, allowing the user to view and select one or more of the billpays to be migrated to the target account. Similarly, an ACH display operation  662  displays each of the ACH operations that have been executed on each of the existing accounts, allowing the user to view and select the desired ACH transactions to migrate to the target account. Example user interfaces providing for such functionality are illustrated in  FIGS. 12-13 , described below. 
     A confirmation operation  664  requests and receives confirmation from the user that the selected transactions and settings are to be migrated to the new account, receiving an electronic signature from the user. An example user interface providing for such confirmation is illustrated in  FIG. 14 . 
     An account switch operation  666  executes upon receiving the confirmation from the user, and transfers any selected account settings, automated funds transfers, and optionally any desired funds from one or more existing accounts to the target account associated with the switch tracking number. In the example of billpays, a transfer can be performed quickly, and little delay in either the billpay migration or funds transfer may be required. However, for the example ACH or other third party transactions that may occur, the migration server may be configured to maintain those migrations in a pending state until receiving confirmation that the ACH was successfully migrated by either the ACH request issuer (e.g., a third party  110 ) or from the financial institution associated with the target account, indicating that the target account received an ACH request based on the migration request. In particular the migration server will provide to each ACH request issuer updated account information, such that the bank routing and account number for the target account. 
     During the pendency of any account migration, it is noted that it may be possible for a funds transfer request to be received by a preexisting institution, rather than the target institution. For this reason, in cases where funds are to be transferred alongside settings, the migration server will act to hold at least some funds in the existing accounts until receiving confirmation that the delayed migration of funds transfer operations has occurred. The amount of holdback of such funds may vary, in different implementations. In some example embodiments, a maximum amount for the automated withdrawals over the past 6 months to a year is used, to ensure that adequate funds are maintained in the existing account in case an ACH or other funds transfer request that is received by the institution associated with the existing account can be fulfilled. In other embodiments, the funds transfer is initiated by the user, and the system described herein provides a recommendation as to funds transfers to be performed that would maximize the amount of funds transferred to a target account. In such embodiments, the system can be configured to advise the user/customer of an amount of funds to retain in an existing account to ensure that any ACH transaction or other lingering transactions that are not immediately migrated to the target account. 
     A status operation  668  allows a user to review a status of a migration process, by displaying or notifying a user of the status of migration of various account settings and automated funds transfers. For example, the status operation can display completed migration of some accounts or pending migration status of others, as illustrated in  FIG. 16 , below. Additionally, a user can opt to receive notifications, for example at an email address provided to the migration server using a user interface such as user interface  1500  of  FIG. 15 . 
     Referring to  FIGS. 7-16 , various user interfaces presented to a customer (user) who wishes to initiate a migration of automated funds transfer operations are illustrated which depict functionality of the migration server  200 , above. In general, the user interfaces described below are intended as exemplary, rather than required; as such, it is understood that various functionality in addition to that described could be incorporated into such user interfaces to enhance the features of the migration server. 
       FIG. 7  illustrates a user interface  700  of an initial welcome page presented to a user by a conversion server for initiating an automated financial account settings migration, according to an example embodiment. The user interface  700  includes a welcome message as well as a user entry region  702  for receiving a switch track number from a customer who wishes to initiate an account migration. A confirmation button  704  allows the user to confirm that the switch track number has been entered. 
       FIG. 8  illustrates a user interface  800  of a terms of service page presented to a user by a conversion server for initiating an automated financial account settings transfer. The user interface  800  can be presented after a user selects the confirmation button  704 , and displays terms of service for use of the migration server to migrate automated payments between accounts. An acceptance button  802  allows the customer to proceed with the account migration, and a disagree button  804  confirms that the customer has changed his/her mind, and does not allow the customer to proceed with the automated account migration. Of course, the customer could opt to manually transfer such data, but in that case the customer lacks the convenience provided by the migration server, and risks missing one or more of the automated funds transfer operations (e.g., bill pay or ACH) when transferring settings to a new account. 
     After acceptance of the terms of service,  FIG. 9  illustrates a user interface  900  of an old accounts login page presented to a user by a conversion server for initiating an automated financial account settings migration. The user interface  900  receives a name of an existing institution holding an account for the customer in a data entry field  902 , as well as login credentials in a username field  904  and password field  906 . A login button  908  causes the migration server to contact the identified financial institution to confirm that the login credentials and name of the institution are correct. 
     After receipt of  FIG. 10  illustrates a user interface  1000  of a new account login page presented to a user by a conversion server for initiating an automated financial account settings migration. The user interface  1000  includes a message confirming the identity of the financial institution that holds the target account to which settings are to be migrated, and includes a username field  1002  and password field  1004  for receiving login information associated with that customer&#39;s target account. A login button  1006  causes the migration server to contact the financial institution associated with the target account to confirm that the migration server can communicate with the financial institution and access that target account. 
       FIG. 11  illustrates a user interface  1100  of a login confirmation page presented to a user by a conversion server for initiating an automated financial account settings migration. The user interface  1100  confirms that the entered information in user interfaces  900 ,  1000  was received and that the migration server can successfully communicate with financial institutions and access both the existing accounts from which migration is desired, as well as a target account to which account information, including automated funds transfers, will be migrated. The user interface  1100  includes a return button  1102  allowing a customer to enter additional existing financial institutions and accounts to be migrated into a target account. The user interface also includes a confirmation button  1104  allowing the customer to proceed with migration of the accounts listed in the user interface  1100 . 
       FIG. 12  illustrates a user interface  1200  of a billpay confirmation page presented to a user by a conversion server for initiating an automated financial account settings migration. The user interface  1200  includes a listing  1202  including detected bill pay events in the selected existing accounts that are analyzed by the migration server (in conjunction with analysis operation  658  of  FIG. 6B ). The listing  1202  includes various details of each detected billpay operation, including a name, nickname, account number, last payment, payment amount and payment frequency of the automated billpay. A selection button is associated with each billpay listing to allow the user to select one or more of the billpays to be migrated. A cancel button  1204  cancels billpay migration, while a switch button  1206  registers the selected billpay listings to be migrated, and allows the migration server to proceed to ACH migration (as in  FIG. 13 ). 
     Following display of the user interface  1200 ,  FIG. 13  illustrates a user interface  1300  of an ACH confirmation page presented to a user by a conversion server for initiating an automated financial account settings migration. The user interface  1300  includes a listing  1302  which includes various details of each ACH operation detected during analysis of the existing accounts of the customer by the migration server (in conjunction with analysis operation  658  of  FIG. 6B ). The listing  1302  includes information associated with each ACH listing, including a name of the entity triggering the ACH request, an account number with which the ACH is connected, a last payment, a payment amount, and occurrences over the past 12 month period. The listing includes a selection button associated with each entry to allow the user to select one or more of the ACH transactions to be migrated. A cancel button  1304  cancels billpay migration, while a switch button  1306  registers the selected ACH listings to be migrated. 
       FIG. 14  illustrates a user interface  1400  of a migration review page presented to a user by a conversion server for initiating an automated financial account settings migration. The user interface  1400  includes a listing of various types of automated funds transfers that are to be migrated to the target account associated with the migration process. In the embodiment shown, the user interface  1400  includes a billpay listing  1402  and an ACH listing  1404 ; however, as noted above, if other types of automated funds transfers were included, different listings could be included here as well. The user interface  1400  allows the user to view the various accounts to determine whether they wish to proceed with the migration to the target account. If so, the user interface includes an electronic signature field  1406  and a confirmation button  1408  allowing the user to electronically sign and confirm that they wish to perform the automated funds transfer migration to the target account. 
     After the migration server receives this confirmation, the migration server will trigger migration of the various existing accounts to a new target account. This can include importing billpay settings from existing accounts to the new account, and communicating with the selected third parties submitting ACH requests against the preexisting accounts, to notify those third parties to, in the future, use a different target institution and routing number for those ACH transactions. Optionally, the migration server can also trigger transfer of some or all of the user funds included in the existing accounts to the target account. Such functionality can be as described above in connection with  FIG. 6B . 
     After the migration is triggered, a customer may wish to view the status of migration of various automated funds transfers that were selected for migration. As such,  FIG. 15  illustrates a user interface  1500  of a status notification page presented to a user by a conversion server for initiating an automated financial account settings migration. The user interface  1500  includes a contact entry field  1502  in which the customer can enter an email address (or alternatively a phone number or other contact information) at which the customer can receive notifications when various funds transfers have been migrated. A completion and status button completes the customer&#39;s involvement in the migration process, and takes that user to a user interface  1600  showing migration status for the target account according to the selected settings as illustrated in  FIGS. 7-15 . 
     As seen in  FIG. 16  a user interface  1600  of a migration status page presented to a user by a conversion server for initiating an automated financial account settings migration. The user interface includes a plurality of listings of various types of automated funds transfers, and notes the status of the migration of the settings associated with those scheduled, automated funds transfers. In the embodiment shown, the user interface  1600  includes a billpay listing  1602  showing completed migration of billpay settings to the target account. The user interface  1600  also includes a listing  1604  of ACH transactions that have successfully been migrated to the target account, and a further listing  1606  of ACH transactions that remain pending (e.g., in case the migration server has not yet received confirmation from either the financial institution associated with the target account or the third party issuing the ACH transaction request that the ACH transaction has successfully been migrated to the target account. A logout button  1608  causes the customer to exit the system provided by the migration server, and can optionally return the customer to the user interface  700  of  FIG. 7 , to initiate a further migration based on a different switch tracking number, or to track the status of the current migration using the same switch tracking number. 
     It is noted that the various user interfaces disclosed above in connection with  FIGS. 7-16  may be displayed in alternative orders, in accordance with the present disclosure. For example,  FIGS. 12 and 13  could be presented in reverse order, allowing for customers to review ACH transactions prior to billpay transactions. Other reordering of such user interfaces into alternative sequences is possible as well. 
     Furthermore, and referring to the systems and methods of  FIGS. 1-16  generally, a number of advantages are provided by the automated migration features discussed herein. For example, it assists in guiding a user through a migration to a new account, while avoiding requiring the customer or account holder from contacting all of the ACH entities associated with an account. Furthermore, because the systems and methods include analysis of transactions associated with existing accounts, rather than simply reviewing settings for those existing accounts, sporadic or rare ACH transactions can be detected and captured, ensuring that no fund withdrawal requests are made against an account that either has had all funds withdrawn or has been closed. Additionally, the systems and methods of the present disclosure allow for increased speed and simplicity of account migration, and can be used by a variety of different financial institutions concurrently to cause migration of funds transfer data and other account settings concurrently, without requiring each institution to separately implement such a solution. Additional advantages are present as well, and are apparent from the above disclosure and the foregoing claims. 
     The above specification, examples and data provide a complete description of the manufacture and use of the composition of the invention. Since many embodiments of the invention can be made without departing from the spirit and scope of the invention, the invention resides in the claims hereinafter appended.