Abstract:
A technique for identifying related transaction records from a database storing transaction records for multiple entities includes grouping transaction records with a common attribute value into transaction record sets, receiving a selection of an exemplar record set and determining the probability the transaction record set stores transaction records associated with a first entity. Other operations include resolving the transaction record set as storing transaction records associated with the first entity. This improves the process of identifying related transaction records because related transaction records missed by string comparisons transaction record attributes are detected.

Description:
BACKGROUND OF THE INVENTION 
       [0001]    1. Field of the Invention 
         [0002]    Embodiments of the present invention generally relate to data analysis and, more specifically, to resolving similar entities from a transaction database. 
         [0003]    2. Description of the Related Art 
         [0004]    Financial institutions store transactional data for analysis. A financial institution generates transactional data from credit and debit card purchases at companies that have a merchant account with the financial institution. The merchant account may be used to processes individual credit or debit card purchases. In turn, each such purchase is stored as a transaction record in a transaction database. A transaction record associated with a particular merchant account oftentimes includes a merchant ID attribute that links the transaction record to the merchant account. A merchant ID may be any data type, including a number, a string, or some combination thereof. The financial institution may then analyze the transaction records from one or more merchant accounts. For example, an analysis may involve aggregating the transaction records of a merchant account or particular merchant accounts. The analysis may then compare the performance of the merchant account to that of competing merchant accounts in the same geographic area. 
         [0005]    Although the financial institution stores the transaction records in a database of transactions, certain analysis may require the data to be organized in ways that are not part of the transaction records in the database. These databases contain sets of transaction records that an analysis should group together, even though there is no single attribute value that relates the transaction records. For example, if a financial institution configures a database of transactions with a merchant ID attribute that links each transaction record to a merchant account, then an analysis would easily aggregate transaction records with the same merchant ID together. However, a single company may have multiple merchant accounts with a financial institution. If the financial institution provides distinct merchant IDs for every merchant account, even when multiple merchant accounts belong to a single company, then it is difficult to aggregate transaction records together from the multiple merchant accounts of that company. For instance, a franchise company may have distinct merchant accounts with distinct merchant IDs for each franchisee location. In such a case, an analysis could not aggregate the transaction records of the franchise company together based on identical merchant IDs alone. Instead, an analysis can use similarities between the merchant ID attribute values to aggregate the transaction records of the franchise company together. 
         [0006]    Existing techniques rely upon simple tests, such as string comparisons between an attribute in a database of transaction records to detect similarities between groups of transaction records. Transaction records including attribute strings that meet a measure of similarity are then aggregated together for analysis. These techniques may work as long as the attribute contains strings that are identical or similar for groups of transaction records that should be aggregated together and strings that are distinct for groups of transaction records that should not be aggregated together. 
         [0007]    However, such identifiers are not always (or even usually) available. For example, different merchant IDs for the merchant accounts of a single company may prevent an analysis system from aggregating the transaction records of the company together. Furthermore, transaction records may contain similar identifiers that an analysis system may base aggregations upon, even if the transaction records should not be aggregated together. For example, two different companies may have merchant accounts with similar merchant IDs, which an analysis system could mistakenly match to one company. The analysis system may then mistakenly aggregate the transaction records of the two companies together. 
         [0008]    As the foregoing illustrates, there remains a need for more effective techniques evaluating financial transaction records. 
       SUMMARY OF THE INVENTION 
       [0009]    One embodiment of the present invention sets forth a method identifying related transaction records from a database storing transaction records for multiple entities includes grouping transaction records with a common attribute value into transaction record sets, receiving a selection of an exemplar record set and determining the probability the transaction record set stores transaction records associated with a first entity. The method also includes resolving the transaction record set as storing transaction records associated with the first entity. 
         [0010]    Other embodiments of the present invention include, without limitation, a computer-readable storage medium including instructions that, when executed by a processing unit, cause the processing unit to implement aspects of the approach described herein as well as a system that includes different elements configured to implement aspects of the approach described herein. 
         [0011]    One advantage of the disclosed technique is that two record sets in a database of transaction records that have no identical attributes, but belong to the same common entity, may be linked to the common entity. Therefore, resolutions that would be missed with string comparisons alone are made and incorrect resolutions based only on similar strings are avoided, which improves the resolution precision. Another advantage of the disclosed technique is that it reduces the number of mistaken aggregates resulting from transaction records having similar identifiers despite being associated with different entities. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0012]    So that the manner in which the above recited features of the present invention can be understood in detail, a more particular description of the invention, briefly summarized above, may be had by reference to embodiments, some of which are illustrated in the appended drawings. It is to be noted, however, that the appended drawings illustrate only typical embodiments of this invention and are therefore not to be considered limiting of its scope, for the invention may admit to other equally effective embodiments. 
           [0013]      FIG. 1  is a block diagram illustrating a computer system configured to implement one or more aspects of the present invention. 
           [0014]      FIG. 2  is a block diagram of the flow of data in through the application server. 
           [0015]      FIG. 3  illustrates a method for training the classifier, according to one embodiment. 
           [0016]      FIG. 4  illustrates a method of resolving merchant ID to a merchant, according to one embodiment. 
           [0017]      FIG. 5  illustrates an example of a computing environment, according to one embodiment. 
       
    
    
     DETAILED DESCRIPTION 
       [0018]    Embodiments of the invention may be used to aggregate certain financial transaction records that are resolved to a common entity, but might not otherwise be grouped with one another. Assuming a transaction database of a financial institution identifies transaction records from each distinct merchant account of a company by a distinct merchant ID attribute, then the distinct merchant IDs attributes may not be matched correctly to link the transaction records of the accounts with the company. As another example, different franchisees of common franchisor will have spate merchant accounts, making it difficult to aggregate the transaction records associated with all franchisees of the franchisor from the transaction records alone. In one embodiment, a financial analysis system combines transaction records into merchant ID sets based upon identical merchant IDs, so each merchant ID set contains all of the transaction records with a particular merchant ID. As this example illustrates, a single company may be represented by multiple merchant IDs. To evaluate the full set of transaction records for a single entity (company) each collection of financial transaction records (the merchant ID sets) associated with the single entity need to be merged together. 
         [0019]    In one embodiment, the analysis system aggregates transaction records from a large collection of merchant ID sets. This aggregation may include calculating the average transaction size, the transaction size standard deviation, or the average amount that an individual has spent. The analysis system uses the aggregates to train a classifier. Once trained, the analysis system produces a confidence score of whether two merchant ID sets belong to a company, based upon the aggregates from the pair of merchant ID sets. To associate the merchant ID sets to the company, the analysis system receives a selection of an exemplar merchant ID set that should be associated with the company and best represents the characteristics of the company. The analysis system compares the exemplar merchant ID set with other merchant ID sets to determine a confidence score. The confidence score represents the likelihood that the exemplary merchant ID set and the other merchant ID set is associated with the company. The analysis system associates every merchant ID set having a confidence scores above a threshold, when compared with the exemplar, to the company. Doing so results in a collection of financial transaction records that presumably all belong to one company, despite the fact that many of such records may include different merchant IDs. 
         [0020]    In the following description, numerous specific details are set forth to provide a more thorough understanding of the present invention. However, it will be apparent to one of skill in the art that the present invention may be practiced without one or more of these specific details. 
         [0021]      FIG. 1  is a block diagram illustrating an example data analysis system  100 , according to one embodiment of the present invention. As shown, the data analysis system  100  includes an application server  140  running on a server computing system  130 , a client  120  running on a client computer system  110 , and at least one transaction database  160 . Further, the client  120 , application server  140 , and transaction database  160  may communicate over a network  180 . 
         [0022]    The client  120  represents one or more software applications configured to present data and translate user inputs into requests for data analyses by the application server  140 . In this embodiment, the client  120  connects to the application server  140 . However, several clients  120  may execute on the client computer  110  or several clients  120  on several client computers  110  may interact with the application server  140 . In one embodiment, the client  120  may be a browser accessing a web service. 
         [0023]    Alternatively, the client  120  may run on the same server computing system  130  as the application server  140 . In any event, a user would interact with the data analysis system  100  through the client  120 . 
         [0024]    The application server  140  is configured to include a merchant resolution tool  150  and an analysis engine  155 . The merchant resolution tool  150  links matching merchant IDs to a company. The merchant resolution tool  150  reads data from the transaction database  160 . The merchant resolution tool  150  may store resolution data on the server computer  130  or on the transaction database  160 . 
         [0025]    The analysis engine  155  uses the resolution data from the merchant resolution tool  150  to analyze data retrieved from the transaction database  160 . The analysis engine  155  aggregates and compares the transaction records from the transaction database  160  to provide insights about a particular company. For instance, a financial institution may design a data analysis to evaluate the seasonal spending trends for a franchise company. However, each franchisee of the franchise company may have a distinct merchant account with the financial institution. The financial institution stores the transaction records from the merchant accounts with distinct merchant IDs that associate a transaction record with a merchant account. To evaluate the full set of transaction records for the franchise company the analysis engine  155  needs to merge each collection of financial transaction records from each franchisee together. Therefore, the analysis engine  155  uses the resolution data from the merchant resolution tool  150  to merge the financial transaction records from each franchisee together into a full set of transaction records for the franchise company in order to evaluate the seasonal spending trends for the franchise company. 
         [0026]    In this embodiment, the transaction database  160  stores data records of financial transactions associated with a financial institution. For example, the transaction database may include data records for a large number of merchant accounts processing credit and debit card transaction. In such a case, each record would include data attributes for the amount spent, the transaction date and time, the address of the merchant, and a merchant ID to associate the record with a particular merchant account. 
         [0027]    The transaction database  160  may be a Relational Database Management System (RDBMS) that stores the transaction data as rows in relational tables. Alternatively, the transaction database  160  may be stored on the same server computing system  130  as the application server  140 . The data records of a financial institution 
         [0028]      FIG. 2  illustrates a flow of data from the transaction database  160  through the merchant resolution tool  150 , according to one embodiment of the present invention. As shown, the transaction database  160  includes merchant ID sets  210 . Each merchant ID set  210  includes transaction records  215  with the same merchant ID, such as credit and debit card transactions processed for a single merchant account at a financial institution. The merchant resolution tool  150  includes an aggregator  240 , candidate aggregates  242 , exemplar aggregates  244 , training data set  260 , and an identity resolver  250 . The identify resolver  250  itself includes a classifier  255  and a resolve list  270 . 
         [0029]    In one embodiment, the classifier  255  is a random forest classifier. A random forest classifier is a machine learning algorithm that is generally known to be highly accurate on large databases that include discrete, continuous, and missing data, as may be the case for financial transaction records  215  in the transaction database  160 . Random forest classifiers include multiple decision trees. The decision trees evaluate features of input data. In the present context, of financial transaction records that are associated with merchant accounts by a merchant id, the evaluated features may include:
       Word overlap count and frequency of merchant ID attributes   Word-based cosine similarity weighted by per-term inverse document frequency scores of merchant ID attributes   Character-based cosine similarity of merchant ID attributes   Placement of word overlap of merchant ID attributes   Identification of the string “.com”   If the merchant ID attributes includes a store code   Overlap of prefix or suffix digits in the merchant ID attributes   Whether the provided city is numeric   Matching unique merchant category codes   Fractional difference in average ticket amounts   Standard deviations from the average ticket amounts   Fractional difference in magnitude of the ticket amount variances
 
Note, the classifier  255  may evaluate a variety of other features, depending on the needs of a particular case and data available from the underlying transaction records. Further one of ordinary skill in the art will recognize that a random forest classifier is used as a reference example of a classifier and that a variety of other machine learning classifiers could be used.
       
 
         [0042]    To evaluate the variety of features the classifier  255  grows decision trees based upon the probability that a selected feature should lead to a certain classification. In the present context, the classifier  255  grows several decision trees based upon different combinations of the features, so that each decision tree classifies a pair of merchant ID sets  210  as matching the same company or not. The output of the classifier  255  is the percentage of decision trees that classify a pair of merchant ID sets  210  as matching the same company. 
         [0043]    To prepare for linking merchant IDs to a company, the classifier  255  grows the decision trees by training on the training data set  260 . The training data set  260  includes pairs of merchant ID sets  210  that match the same company and pairs of merchant ID sets  210  that do not match the same company. The pairs of merchant ID sets  210  that match the same company are classified as positive examples in the training data set  260 . The pairs of merchant ID sets  210  that do not match the same company are classified as negative examples in the training data set  260 . As the classifier  255  processes the features of each pair of merchant ID sets  210  as a positive or negative example, the classifier  255  becomes more accurate by refining the probabilities used in the decision trees. 
         [0044]    The training data set  260  may also include difficult edge cases, such as pairs of merchant ID sets  210  that do not match, but have similar merchant ID strings. A pair of merchant ID sets  210  with similar merchant ID strings that should not be linked to the same company is an edge case, because oftentimes similar merchant ID strings come from merchant ID sets  210  that should be linked to the same company. Adding such edge cases to the training data set  260  causes the classifier  255  to adjust the probabilities in the decision trees of the classifier  255  to better classify pairs of merchant ID sets  210  with similar merchant ID attributes. 
         [0045]    To create a large training data set  260 , the merchant resolution tool  150  may generate pairs of randomly selected merchant ID sets  210 , which typically provide negative training examples. 
         [0046]    The training data set  260  may include transaction records  215  retrieved from the transaction database  160 , may include synthetic transaction records  215 , or may include some combination thereof. While a training data set  260  of  4 , 000  pairs of merchant ID sets  210  has proven to be effective, the actual size of the training data set  260  may be set as a matter of preference. 
         [0047]    Once the classifier  255  is trained, the merchant resolution tool  150  may be used to associate merchant IDs from distinct merchant account to a company, so that the analysis engine  155  may run data analyses on full sets of transaction records  215  from all merchant accounts of the company. 
         [0048]    The transaction database  160  is configured to include a mechanism for providing transaction records  215  with a common merchant ID attribute as merchant ID sets  210 . For example, the transaction database  160  may store transaction records  215  with equal merchant ID attributes together in merchant ID sets  210  or the transaction database  160  may store transaction records  215  sequentially by the value of a transaction date attribute. Regardless of the arrangement of the transaction records  215 , the merchant resolution tool  150  may retrieve merchant ID sets  210  from the transaction database  160 . 
         [0049]    After a user selects a merchant ID set  210  as an exemplar merchant ID set  210 ( 0 ), other merchant ID sets  210  may be considered as candidate merchant ID sets  210 ( 1 ) through  210 (M−1). The user selects the exemplar merchant ID set  210 ( 0 ) as being representative of the characteristics of the company to be resolved. The exemplar merchant ID set may include a large number of transaction records  215 . A large number of transaction records  215  may provide aggregates, such as the average transaction size, that are more accurate than merchant ID sets  210  with fewer transaction records  215 . Other factors, such as geographic locations, the merchant ID string, or other business heuristics may also guide the selection of the exemplar merchant ID set  210 ( 0 ) from the available merchant ID sets  210 . 
         [0050]    When linking merchant IDs to a company, the merchant resolution tool  150  retrieves the transaction records  215  of the exemplar merchant ID set  210 ( 0 ) and the transaction records  215  of a candidate merchant ID set  210 ( 1 ). The aggregator  240  aggregates the attributes of the transaction records  215  of the exemplar merchant ID set  210 ( 0 ) to produce exemplar aggregates  244 . For example, the aggregator  240  calculates the average transaction size, the transaction size standard deviation, or the average amount that an individual has spent. The merchant ID attribute of the exemplar merchant ID set  210 ( 0 ) is also included with the exemplar aggregates  244 . The aggregator  240  also calculates the candidate aggregates  242  from the candidate merchant ID set  210  and includes the merchant ID attribute of the candidate merchant ID set  210 ( 1 ) with the candidate aggregates  242 . Note that the aggregator  240  may calculate additional aggregate values, according to numerous different designs that the tool developer can choose. 
         [0051]    After the aggregator  240  determines the aggregate values, the merchant resolution tool  150  passes the exemplar aggregate  244  and the candidate aggregate  242  to an identity resolver  250 . The classifier  255  determines the values used as features in the decision trees from the data included in the exemplar aggregates  244  and the candidate aggregates  242 . The classifier  255  processes the exemplar aggregate  244  and the candidate aggregate  242  to produce a confidence score between zero and one equal to how likely the exemplar merchant ID set  210 ( 0 ) matches the candidate merchant ID set  210 ( 1 ) and should therefore be linked to the same company. If the exemplar merchant ID set  210 ( 0 ) and the candidate merchant ID set  201 ( 1 ) receive a score over some threshold, such as 0.70, then the identity resolver  250  stores the merchant ID of the candidate merchant ID set  201 ( 1 ) in a resolve list  270 . 
         [0052]    The merchant resolution tool  150  compares candidate merchant ID sets  210 ( 2 ) through  210 (M−1) with the exemplar merchant ID set  210 ( 0 ). The identity resolver  250  adds the merchant ID of each candidate merchant ID set  210 ( 1 ) through  210 (M−1) that produces a high confidence score to the resolve list  270 . Therefore, the merchant IDs on the resolve list  270  represent the merchant ID sets  210  that belong to the same company as the exemplar merchant ID set  210 ( 0 ). 
         [0053]    The merchant resolution tool  150  stores the resolve list  270  for use by the analysis engine  155 . In turn, the analysis engine  155  may analyze the full collection of transaction records  215  of the company independent of the various merchant IDs included in the transaction records  215  of the company. For example, if the various merchant IDs in a resolve list  270  associate transaction records  215  with multiple merchant accounts from multiple franchisees of a franchise company. Then the analysis engine  155  should merge the transaction records  215  with the merchant IDs in the resolve list  270  to analyze the full collection of transaction records  215  of the franchise company. 
         [0054]      FIG. 3  is a flow diagram of method steps for training the classifier  255 , according to one embodiment of the present invention. Although the method steps are described in conjunction with the systems of  FIGS. 1-2  and  5 , persons of ordinary skill in the art will understand that any system configuration to perform the method steps, in any order, is within the scope of the invention. 
         [0055]    As shown, method  300  beings at step  305 , where a merchant resolution tool  150  creates a training data set  260  of positive examples of pairs of merchant ID sets  210  that link to the same company. The merchant resolution tool  150  adds edge cases to the training data set  210 . The edge cases include pairs of merchant ID sets  210  that do not match, but have similar merchant ID strings. The edge cases may also include pairs of merchant ID sets  210  that have similar aggregate values, but are from different companies, so are actually negative training examples. 
         [0056]    In step  310 , the merchant resolution tool  150  adds randomly selected pairs of merchant ID sets  210  to the training data set  260 . The randomly selected pairs of merchant ID sets  210  should include a majority of negative training examples. 
         [0057]    In step  315 , the merchant resolution tool  150  submits each merchant ID sets  210  in the training data set  260  to the aggregator  240  to generate candidate aggregates  242 . When training the classifier  255 , there is no exemplar merchant ID set  210 ( 0 ), so all merchant ID sets  210  in the training data set  260  are considered candidates merchant ID sets  210 ( 1 ) through  210 (M−1). A user may review these candidate aggregates  242 . 
         [0058]    In step  320 , the user selects pairs of merchant ID sets  210  that should be linked to the same company as positive training examples. 
         [0059]    In step  325 , the user selects pairs of merchant ID sets  210  that link to different companies as negative training examples. These negative training examples include several difficult edge cases. Additionally, the training data set  210  includes a majority of random selections, so the majority of the pairs of merchant ID sets  210  in the training data set  260  are negative training examples. 
         [0060]    In step  330 , the merchant resolution tool  150  trains the classifier  255  with the training data set  260 . As described, the classifier  255  is a random forest learning algorithm. 
         [0061]    After training the classifier  255  with the training data set  260 , the classifier  255  may evaluate a pair of merchant ID sets  210  to produce a confidence score, e.g., a value between zero and one. The confidence score equals the percent of decision trees in the random forest algorithm used by the classifier  255  that determine that both merchant ID sets  210  in the pair should be linked to the same company. Therefore, the classifier  255  is able to produce a confidence score that represents whether a pair of merchant ID sets  210  including an exemplar merchant ID set  210 ( 0 ) and a candidate merchant ID set  210 ( 1 ) should be linked to the same company. 
         [0062]      FIG. 4  is a flow diagram of method steps for linking merchant IDs to a company according to one embodiment of the present invention. Although the method steps are described in conjunction with the systems of  FIGS. 1-2  and  5 , persons of ordinary skill in the art will understand that any system configuration to perform the method steps, in any order, is within the scope of the invention. 
         [0063]    As shown, method  400  beings at step  410 , where the merchant resolution tool  150  receives an exemplar merchant ID as the merchant ID attribute for an exemplar merchant ID set  210 ( 0 ). As described, a user selects the exemplar merchant ID set  210 ( 0 ) as being representative of the characteristics of the financial transaction records  215  associated with a company, e.g., the franchisee that best represents a given franchise company. Alternatively, the system may automatically choose an exemplar merchant ID set  210 ( 0 ) based on user-specified criteria. 
         [0064]    In one embodiment, the merchant resolution tool  150  presents an exemplar selection tool to the user. The exemplar selection tool provides assistance in selecting an exemplar merchant ID that is representative of a company to be resolved. The exemplar selection tool may accept a search string from the user to identify merchant IDs that should potentially be linked to the company. The exemplar selection tool may also use some subset of the company name as the search string. Furthermore, the exemplar selection tool may submit the merchant ID sets  210  associated with the identified merchant IDs to the aggregator  240 . The aggregator  240  then computes aggregates  242  that assist the user in selecting the exemplar merchant ID. 
         [0065]    In step  420 , the merchant resolution tool  150  generates exemplar aggregates  244  for the selected exemplar merchant ID set  210 ( 0 ). After the merchant resolution tool  150  retrieves the exemplar merchant ID set  210 ( 0 ) from the transaction database  160 , the aggregator  240  calculates the average transaction size, the transaction size standard deviation, and the average amount that an individual has spent. 
         [0066]    In step  430 , the merchant resolution tool  150  generates candidate aggregates  242  for a candidate merchant ID set  210 ( 1 ). The merchant resolution tool  150  identifies a merchant ID set  210 ( 1 ) through  210 (M−1) that has not been compared to the exemplar merchant ID set  210 ( 0 ), as the candidate merchant ID set  210 ( 1 ). Once identified, the merchant resolution tool  150  retrieves the candidate merchant ID set  210 ( 1 ) from the transaction database  160 , and submits the candidate merchant ID set  210 ( 1 ) to the aggregator  240 . The aggregator  240  generates the candidate aggregates  242 . 
         [0067]    The aggregation and comparison of every possible merchant ID record set  210 ( 1 ) through  210 (M−1) may be very time consuming, so reducing the number of comparisons is desirable. In one embodiment, the merchant resolution tool  242  does not compare every merchant ID record set  210 . The merchant resolution tool  242  skips merchant ID record sets  210  that do not meet a certain qualification. Assuming a franchise company only has franchisee locations in the state of California and the transaction records  215  include an attribute for the address at which the transaction occurred, then the merchant resolution tool  242  would skip those merchant ID record sets  210  that do not include transaction records  215  from California. In this case, the merchant resolution tool  242  reduces the number of comparisons by skipping those merchant ID sets  210  that are not from California. 
         [0068]    In step  440 , the merchant resolution tool  150  determines if the exemplar merchant ID set  210 ( 0 ) and the candidate merchant ID set  210 ( 1 ) match one another and therefore should be linked to the same company. The identity resolver  250  submits the exemplar aggregates  244  and the candidate aggregates  242  to the classifier  255 . As described, the classifier  255  produces a confidence score between zero and one equal to the percent of decision trees in the random forest algorithm used by the classifier  255  that determine that both merchant ID sets  210  in the pair should be linked to the same company. If the classifier  255  produces a confidence score under a threshold, then the method  400  proceeds to step  460 . If, however, the confidence score is over the threshold, then method  400  proceeds to step  450 . While a threshold confidence score of 0.70 has proven to be effective, the actual threshold may be set as a matter of preference. 
         [0069]    In step  450 , the identity resolver  250  stores the merchant ID attribute of the candidate merchant ID set  201 ( 1 ) in a resolve list  270 . 
         [0070]    In one embodiment, the merchant resolution tool  242  merges the exemplar merchant ID set  240 ( 0 ) and the candidate merchant ID set  240 ( 1 ) into a combined merchant ID set, which becomes a new larger exemplar merchant ID set  240 ( 0 ). Then the merchant resolution tool  242  re-generates the exemplar aggregates  244  for the remaining comparisons. In doing so, the new exemplar merchant ID set  240 ( 0 ) may better represent the company and improve the resolution of the remaining candidate merchant ID sets  240 ( 2 ) through  240 (M−1). 
         [0071]    In step  460 , the merchant resolution tool  150  determines if there are more merchant ID sets  210  in the transaction database  160  that have not been compared. If the merchant resolution tool  150  determines there is another candidate merchant ID set  210 ( 2 ) to compare, then the method  400  returns to step  430 . Once no more candidate merchant ID sets  210  remain to compare, the merchant resolution tool  150  links merchant ID sets  210  listed in the resolve list  270  for the company. 
         [0072]    In step  470 , the merchant resolution tool  150  links the exemplar merchant ID set  210 ( 0 ) with the candidate merchant ID sets  210 ( 1 ) through  210 (M−1) listed in the resolve list  270 . As described, the resolution of the merchant ID sets may involve storing a list of merchant ID attributes that the analysis engine  155  can use to identify the transaction records  215  of the company. Alternatively, the merchant resolution tool  150  may link the transaction records  215  of the merchant ID sets  210  on the resolve list  270  to the company by populating an attribute of the transaction records  215  with the company name, so that the analysis engine  155  can query the transaction database  160  for the transaction records  215  belonging to the company. 
         [0073]      FIG. 5  illustrates an example server computing system  130  running a merchant resolution tool  150 , according to one embodiment. As shown, the server computing system  130  includes, a central processing unit (CPU)  550 , a network interface  570 , a memory  520 , and a storage  530 , each connected to an interconnect (bus)  540 . The server computing system  130  may also include an I/O device interface  560  connecting I/O devices  580  (e.g., keyboard, display and mouse devices) to the computing system  130 . Further, in context of this disclosure, the computing elements shown in server computing system  130  may correspond to a physical computing system (e.g., a system in a data center) or may be a virtual computing instance executing within a computing cloud. 
         [0074]    The CPU  550  retrieves and executes programming instructions stored in memory  520  as well as stores and retrieves application data residing in memory  520 . The bus  540  is used to transmit programming instructions and application data between the CPU  550 , I/O device interface  560 , storage  530 , network interface  570 , and memory  520 . Note that the CPU  550  is included to be representative of a single CPU, multiple CPUs, a single CPU having multiple processing cores, a CPU with an associate memory management unit, and the like. The memory  520  is generally included to be representative of a random access memory. The storage  530  may be a disk drive storage device. Although shown as a single unit, the storage  530  may be a combination of fixed and/or removable storage devices, such as fixed disc drives, removable memory cards, or optical storage, network attached storage (NAS), or a storage area-network (SAN). 
         [0075]    The communications between the client  120  and the merchant resolution tool  150  are transmitted over the network  180  via the network interface  570 . 
         [0076]    Illustratively, the memory  520  includes a merchant resolution tool  150 , exemplar aggregates  244 , candidate aggregates  242 , and a resolve list  270 . The merchant resolution tool  150  itself includes an aggregator  240  and a classifier  225 . The storage  530  includes a training data set  533 , which the merchant resolution tool  150  uses to train the classifier  225 . 
         [0077]    The aggregator  240  generates the exemplar aggregates  244  and the candidate aggregates  242  from transaction records  215  retrieved from the transaction database  160 . The merchant resolution tool  150  issues database queries over the network  180  to the transaction database  160  via the network interface  570 . Once the aggregator  240  generates the exemplar aggregates  244  and candidate aggregates  242 , the merchant resolution tool  150  uses the classifier  225  to determine if the merchant IDs sets  240  should be linked to a company. 
         [0078]    Although shown in memory  520 , the merchant resolution tool  150 , exemplar aggregates  244 , candidate aggregates  242 , and resolve list  270 , may be stored in memory  520 , storage  530 , or split between memory  520  and storage  530 . Likewise, the training data set  533  may be stored in memory  520 , storage  530 , or split between memory  520  and storage  530 . 
         [0079]    In some embodiments, the database repository  160  may be located in the storage  530 . In such a case, the database queries and subsequent responses are transmitted over the bus  540 . As described, the client  120  may also be located on the server computing system  130 , in which case the client  120  would also be stored in memory  520  and the user would utilize the I/O devices  580  to interact with the client  120  through the I/O device interface  560 . 
         [0080]    While the foregoing is directed to embodiments of the present invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof. For example, aspects of the present invention may be implemented in hardware or software or in a combination of hardware and software. One embodiment of the invention may be implemented as a program product for use with a computer system. The program(s) of the program product define functions of the embodiments (including the methods described herein) and can be contained on a variety of computer-readable storage media. Examples of computer-readable storage media include (i) non-writable storage media (e.g., read-only memory devices within a computer, CD-ROM disks readable by a CD-ROM drive, flash memory, ROM chips or any type of solid-state non-volatile semiconductor memory); and (ii) writable storage media (e.g., floppy disks within a diskette drive or hard-disk drive or any type of solid-state random-access semiconductor memory) on which alterable information is stored. 
         [0081]    The invention has been described above with reference to specific embodiments. Persons of ordinary skill in the art, however, will understand that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention as set forth in the appended claims. The foregoing description and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. 
         [0082]    Therefore, the scope of the present invention is determined by the claims that follow.