Patent Application
20150356543
The present invention relates to associating transaction identifiers with one or more transactions.
Individuals, businesses, and other organizations typically maintain one or more financial accounts at one or more financial institutions. Financial institutions include, for example, investment institutions, life insurance vendors, banks, savings and loans, credit unions, mortgage companies, lending companies, and stock brokers. Financial accounts may include asset accounts (such as brokerage accounts, investment accounts, 401k accounts, other retirement accounts, mutual fund accounts, life insurance and annuity accounts, bank savings accounts, checking accounts, and certificates of deposit (CDs)) and liability accounts (such as credit card accounts, mortgage accounts, home equity loans, overdraft protection, and other types of loans). Liability accounts may also be referred to as “debt accounts”.
Many financial institutions allow customers to access information regarding their accounts via the Internet or other remote connection mechanism (often referred to as “online banking”). Typically, the customer navigates, using a web browser application, to a web site maintained by the financial institution. The web site allows the customer to login by entering a user identification and an associated password. If the financial institution accepts the user identification and password, the customer is permitted to access information (e.g., account holdings and account balances) regarding the financial accounts maintained at that financial institution.
Similarly, other organizations and institutions allow customer access to other types of accounts, such as email accounts, award (or reward) accounts, online bill payment accounts, etc. A user may navigate a web site or other information source to receive status information regarding one or more of their accounts.
Different financial institutions may use different transaction codes or identifiers for similar transactions. Different types of transactions include buy, sell, transfer, deposit, withdraw, redeem, and the like. For example, a funds transfer transaction at one financial institution may have a particular identifier associated with the transaction (e.g., FXFR0034552), whereas a similar transaction at another financial institution may have a different associated transaction identifier (e.g., XFUNDS-A4D44F). Attempts to aggregate transaction information from different financial institutions is difficult when different identifiers are used for similar transactions, holdings, and other account information.
The systems and methods described herein addresses these and other difficulties by categorizing transaction data from multiple sources using a common set of transaction identifiers.
The system and methods described herein are capable of retrieving data from one or more data sources, such as financial institutions. A particular data source may contain financial transaction information associated with one or more accounts of one or more account holders. Each data element retrieved is associated with a particular identifier, such as an asset identifier or a transaction identifier. Similar identifiers are used for data retrieved from multiple financial institutions and multiple financial accounts, thereby allowing the retrieved data to be normalized across the multiple institutions and accounts.
As used herein, the terms “account holder”, “customer”, “user”, and “client” are interchangeable. “Account holder” refers to any person or entity having access to an account. A particular account may have multiple account holders (e.g., a joint checking account having husband and wife as account holders or a corporate account identifying several corporate employees as account holders).
Various financial transaction and financial institution examples are provided herein for purposes of explanation. However, it will be appreciated that the systems and procedures described herein can be used with any type of data from any data source. Example financial accounts include savings accounts, money market accounts, checking accounts (both interest-bearing and non-interest-bearing), brokerage accounts, credit card accounts, mortgage accounts, home equity loan accounts, overdraft protection accounts, margin accounts, personal loan accounts, and the like. Example financial transactions include buy, sell, transfer, deposit, withdraw, redeem, and the like. Example financial institutions include banks, savings and loans, credit unions, mortgage companies, mutual fund companies, lending companies, and stock brokers.
Additionally, a data aggregation system may aggregate data from multiple sources, such as multiple financial accounts, multiple email accounts, multiple online award (or reward) accounts, multiple news headlines, and the like. Similarly, the data retrieval and data processing systems and methods discussed herein may be applied to collect data from any type of account containing any type of data. Thus, the methods and systems described herein can be applied to a data aggregation system or any other account management system, and are not limited to the financial analysis systems and procedures discussed in the examples provided herein.
Another server 104, a client computer 110 and a financial analysis system 112 are also coupled to network 108. Financial analysis system 112 is coupled to a database 114. Database 114 stores various information used by financial analysis system 112, as discussed herein. Financial analysis system 112 performs various transaction analysis functions, account analysis functions, data analysis functions, and aggregation functions, which are discussed in greater detail below. Although not shown in
Servers 102-106, client computer 110, and financial analysis system 112 may be any type of computing device, such as a desktop computer, a laptop computer, a handheld computer, a personal digital assistant (PDA), a cellular phone, a set top box, or a game console. Client computer 110 is capable of communicating with one or more servers 102-106, for example, to access information about a financial institution, access account information, and execute various transactions.
The communication links shown between network 108 and the various devices (102, 104, 106, 110, and 112) shown in
System 200 classifies transactions into a defined category and associates the transaction with a particular transaction identifier (also referred to as a “transaction code”). The transactions are received from any number of sources (e.g., financial institutions) and, after being categorized, can be queried, sorted, and otherwise processed based on the associated transaction identifier. Categorizing transactions from multiple financial institutions normalizes the transaction data to allow processing of the transaction data across the multiple financial institutions, even though different financial institutions may use different transaction data values or terminology. In one embodiment, the normalized transaction data is accessible by other systems, such as portfolio accounting systems and financial analysis systems, that track and report investment performance and other statistics.
A transaction processor 202 is coupled to receive data, such as transaction data, from a data receiving module 204. Data receiving module 204 can receive data from any number of data sources using various data receiving and data retrieving techniques. For example, data receiving module 204 can “harvest” data from one or more web sites associated with any number of financial institutions. Data harvesting (also referred to as “screen scraping”) is a process that allows, for example, an automated script to retrieve data from one or more web pages associated with a web site. For example, a particular data harvesting script may retrieve transaction data from a particular financial institution by navigating to specific web pages associated with the particular financial institution. The data harvesting script knows where the transaction data is located on each of the web pages and retrieves the data from those locations. Since each financial institution may have a different web site architecture and web page layout, a separate data harvesting script may be required for each financial institution. Additionally, these scripts may require regular modification as one or more financial institutions change their web site architecture or web page layout.
Alternatively, data receiving module 204 may receive data from a data source using, for example, OFX (Open Financial Exchange) standard, QIF (Quicken Interchange Format) format, or any other data format. Alternatively, data receiving module 204 may receive one or more data files (e.g., text files) from financial institutions containing transaction data. OFX is a specification for the electronic exchange of financial data between financial institutions, businesses and consumers via the Internet. OFX supports a wide range of financial activities including consumer and business banking, consumer and business bill payment, bill presentment, and investment tracking, including stocks, bonds, mutual funds, and 401(k) account details. QIF is a specially formatted text file that allows a user to transfer Quicken transactions from one Quicken account register into another Quicken account register or to transfer Quicken transactions to or from another application that supports the QIF format. Data is retrieved from the source and a procedure identifies data of interest. The data of interest may be, for example, data associated with a particular financial institution or a particular type of transaction. The identified data is then processed by transaction processor 202.
Transaction processor 202 categorizes the data received from data receiving module 204 using a matching algorithm 206. As discussed in greater detail below, matching algorithm 206 uses financial institution data 212 and other information to categorize transactions and associate an identifier with each transaction. The received transaction data includes, for example, a financial institution ID and a transaction value. The transaction value is the name of the transaction used by the particular financial institution. For example, one financial institution may use “SELL” to identify a sell transaction while another financial institution may use “SL”, “S”, or some other value to identify a sell transaction.
Transaction processor 202 is also coupled to a queue of failed transactions 208. This queue 208 contains transaction data for transactions that could not be categorized by transaction processor 202. Queue 208 is coupled to an exception handling module 214. Exception handling module 214 may also be referred to as an “exception handling tool”. Exception handling module 214 processes transaction data that was not categorized by transaction processor 202. For example, an administrator (or other user) may review the transaction data and identify an appropriate category for the transaction. Additionally, the administrator may update the financial institution data 212 such that matching algorithm 206 properly identifies similar transaction data received in the future. Exception handling module 214 also allows an administrator to add new categorizing rules, delete existing rules, or modify existing rules. By continually adding, deleting and modifying rules, the overall performance of transaction processor 202 in categorizing transactions improves over time.
A log 216 is coupled to exception handling module 214 and contains a listing of transaction data processed by exception handling module 214. Exception handling module 214 processes transactions that were not recognized (or categorized) by transaction processor 202. Fore example, a transaction may have an unrecognized transaction label, such as “Online Sale”. These unrecognized transaction labels may be new labels that transaction processor 202 had not previously encountered, or the transaction labels may be a modification of an existing label. In these situations, the financial institution data 212 is updated to account for the new or modified transaction label such that future transactions using that transaction label will be handled properly by transaction processor 202.
A storage device 210 is coupled to transaction processor 202, exception handling module 214, a report generator 218, a data query module 220, and a data sorting module 222. Storage device 210 stores various data generated by and used by transaction processor 202 and exception handling module 214. Additionally, other components and modules (such as report generator 218, data query module 220, and data sorting module 222) interact with storage device 210 when performing various procedures or functions.
In particular embodiments, one or more of the components shown in
The seed data shown in Table 1 is intended to grow and change over time based on the data collected from different financial institutions. Initially, the seed data is populated using a data obtained from known systems. Each unique transaction value that is found in the “transaction description” field of the data source will be stored in the seed data and assigned the appropriate transaction identifier. The matching algorithm in the transaction processor will first check financial institution-specific seed data to determine if there is a match. If not, the matching algorithm attempts to match generic seed data.
Generic seed data is generated by analyzing common patterns across multiple financial institutions such that the generic data can be useful with a new financial institution without any specific seed data. The use of generic seed data also reduces the overall amount of seed data by identifying common transaction values used by multiple financial institutions. For example, “Sale=Sell” and “Sold=Sell” are common transaction value matches that work with many different financial institutions. For any financial institutions that do not comply with these generic rules, specific seed data is generated and associated with those financial institutions. This specific seed data takes precedence over the generic seed data for those particular financial institutions. Both the generic seed data and the specific seed data is ordered (or ranked) in a particular manner to ensure that a correct match is identified.
Referring again to
After a transaction has been categorized, procedure 300 continues by associating a transaction identifier with the transaction (block 312). The transaction identifier indicates a particular category with which the transaction is associated. The procedure then stores the transaction and associated transaction identifier (block 314). In one embodiment, the transaction is stored in a transaction table that contains one or more other categorized transactions. Finally, procedure 300 receives additional transaction data (block 316) and returns to block 304 to identify a category associated with the transaction data.
The matching algorithm used to categorize transactions processes seed data in a particular order. The matching algorithm first applies specific seed data (e.g., data specific to a financial institution) prior to applying generic seed data. Thus, if the specific seed data contains an exception to the generic seed data, the specific seed data will be applied first and any appropriate matches will be identified. Additionally, the specific seed data and generic seed data is ordered such that more specific matches occur before less specific matches. For example, “Sell to cover” will be ordered ahead of “Sell” to avoid having a “Sell to cover” transaction be categorized as a general “Sell” transaction. The matching algorithm also attempts to find an exact match before a partial match is accepted. For example, the algorithm would attempt to make an exact match for “Interest-income” or “Interest-bond” prior to matching either value with “Interest”, which is a partial match.
As mentioned above, each transaction that cannot be assigned a transaction identifier is flagged for further processing by the exception handling module 214. The exception handling module performs two functions: 1. queuing the flagged transactions and presenting them to an administrator or other user, and 2. updating the seed data used by the transaction processor to categorize transactions. When a flagged transaction is queued for further processing, a link is provided to the source of the transaction data, such as the html link, OFX location, QIF file, or financial institution data file. Updating the seed data allows an administrator to include the new transaction value in the seed data and to assign the appropriate transaction identifier to the new transaction value.
In one embodiment, operation of the exception handling module bay be activated or deactivated. If the exception handling module is activated, it operates in the manner discussed above. If the exception handling module is deactivated, transactions that cannot be categorized using the existing seed data are ignored.
The normalizing of transaction data (i.e., assigning common transaction identifiers) is useful when transaction data is received from multiple sources (e.g., multiple financial institutions): Each financial institution may use different identifiers or other terms for the same type of transaction. For example, one financial institution may use the identifier “SELL” while another financial institution uses the identifier “SL” for the same transaction. By normalizing the transaction data, transactions from multiple financial institutions can be grouped in a logical manner. Thus, various financial analysis tools and procedures can analyze transactions across multiple financial institutions or other data sources. For example, report generator 218 can generate transaction reports that accurately contain transaction information from multiple different sources.
Computer 400 includes at least one processor 402 coupled to a bus 404 that couples together various system components. Bus 404 represents one or more of any of several types of bus structures, such as a memory bus or memory controller, a peripheral bus, and a processor or local bus using any of a variety of bus architectures. A random access memory (RAM) 406 and a read only memory (ROM) 408 are coupled to bus 404. Additionally, a network interface 410 and a removable storage device 412, such as a floppy disk or a CD-ROM, are coupled to bus 404. Network interface 410 provides an interface to a data communication network such as a local area network (LAN) or a wide area network (WAN) for exchanging data with other computers and devices. A disk storage 414, such as a hard disk, is coupled to bus 404 and provides for the non-volatile storage of data (e.g., computer-readable instructions, data structures, program modules and other data used by computer 400). Although computer 400 illustrates a removable storage 412 and a disk storage 414, it will be appreciated that other types of computer-readable media which can store data that is accessible by a computer, such as magnetic cassettes, flash memory cards, digital video disks, and the like, may also be used in the example computer.
Various peripheral interfaces 416 are coupled to bus 404 and provide an interface between the computer 400 and the individual peripheral devices. Example peripheral devices include a display device 418, a keyboard 420, a mouse 422, a modem 424, and a printer 426. Modem 424 can be used to access other computer systems and devices directly or by connecting to a data communication network such as the Internet.
A variety of program modules can be stored on the disk storage 414, removable storage 412, RAM 406, or ROM 408, including an operating system, one or more application programs, and other program modules and program data. A user can enter commands and other information into computer 400 using the keyboard 420, mouse 422, or other input devices (not shown). Other input devices may include a microphone, joystick, game pad, scanner, satellite dish, or the like.
Computer 400 may operate in a network environment using logical connections to other remote computers. The remote computers may be personal computers, servers, routers, or peer devices. In a networked environment, some or all of the program modules executed by computer 400 may be retrieved from another computing device coupled to the network.
Typically, the computer 400 is programmed using instructions stored at different times in the various computer-readable media of the computer. Programs and operating systems are often distributed, for example, on floppy disks or CD-ROMs. The programs are installed from the distribution media into a storage device within the computer 400. When a program is executed, the program is at least partially loaded into the computer's primary electronic memory. As described herein, the invention includes these and other types of computer-readable media when the media contains instructions or programs for implementing the steps described below in conjunction with a processor. The invention also includes the computer itself when programmed according to the procedures and techniques described herein.
For purposes of illustration, programs and other executable program components are illustrated herein as discrete blocks, although it is understood that such programs and components reside at various times in different storage components of the computer, and are executed by the computer's processor. Alternatively, the systems and procedures described herein can be implemented in hardware or a combination of hardware, software, and/or firmware. For example, one or more application specific integrated circuits (ASICs) can be programmed to carry out the systems and procedures described herein.
Although the description above uses language that is specific to structural features and/or methodological acts, it is to be understood that the invention defined in the appended claims is not limited to the specific features or acts described. Rather, the specific features and acts are disclosed as example forms of implementing the invention.
This application is a continuation-in-part of co-pending application Ser. No. 10/040,314, filed Jan. 3, 2002, entitled “Method and Apparatus for Retrieving and Processing Data”, and incorporated herein by reference. Further, this application claims the benefit of U.S. Provisional Application No. 60/540,667, filed Jan. 30, 2004, the disclosure of which is also incorporated herein by reference.
| Number | Date | Country | |
|---|---|---|---|
| 60540667 | Jan 2004 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 11047359 | Jan 2005 | US |
| Child | 14697557 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 10040314 | Jan 2002 | US |
| Child | 11047359 | US |
