System and method for detecting unseen overdraft transaction events

System and method configured to evaluate financial transaction information and detect overdraft transaction events regardless of the financial institution associated with the event.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1shows an example of a system configured to evaluate financial transaction information and detect overdraft transaction events in accordance with the disclosed principles.

FIG. 2shows a server device according to an embodiment of the present disclosure.

FIG. 3shows an example machine learning model development process according to an embodiment of the present disclosure.

FIG. 4shows an example of a features table comprising features associated with financial transactions for customers of a first financial institution.

FIG. 5shows an example of a features table comprising features most likely associated with an overdraft transaction event for customers of the first financial institution.

FIG. 6shows an example process of detecting previously unseen and other overdraft transaction events using a transfer learning process according to an embodiment of the present disclosure.

FIG. 7shows an example of a features table comprising features associated with financial transactions for customers of a second financial institution.

FIG. 8shows an example of a features table comprising features most likely associated with a previously unseen and other overdraft transaction events for customers of the second financial institution.

DETAILED DESCRIPTION OF SEVERAL EMBODIMENTS

Embodiments described herein may be configured to evaluate financial transaction information and detect overdraft transaction events regardless of the financial institution associated with the event. For example, and as known in the art, overdraft transactions occur when a consumer does not have enough funds in its account to support the financial transaction. Usually overdraft events, also known as “non-sufficient fund” or “NSF” events, cost the user approximately $30 in fees by the financial institute associated with the event. Fees associated with overdraft events for a single year may total to billions of dollars in the United States alone. Financial management services such as Mint® by Intuit Inc. of Mountain View, Calif., predict overdraft events and are designed to alert users prior to the event. These financial management services will also advise the user as to what steps should be taken to avoid the predicted NFS event.

These predictions oftentimes require a model that is trained with data associated with financial transactions, including the transactions that are overdraft events. As can be expected, predicting overdraft events is a difficult task, which is exacerbated by the fact that there are numerous financial institutions, each with its own format (or multiple formats) for documenting that an overdraft event took place. For example, while some financial institutions use the phrase “overdraft fee” to indicate that an overdraft event took place, others use phrases such as “nsf fee” or “return items fee,” to name a few. Because there are thousands of financial institutions, it is not feasible for a financial management system to track and maintain a list of the various ways each financial institution documents overdraft events. As can be expected, there will be “unseen” overdraft events in the data used to train the financial management services' prediction model. Accordingly, the prediction accuracy may suffer due to the unseen overdraft events. As such, there is a need to identify unseen overdraft events during the prediction process.

The disclosed systems and methods overcome the above-noted deficiencies and improve a model-based overdraft prediction process through use of an automated, transfer-learning approach with association rules to account for the different overdraft reporting methods used by different financial institutions. The disclosed principles may automatically learn signature patterns that are useful for distinguishing between two classes of interest (e.g., users that incurred an overdraft event and users that did not) in a set of transactions belonging to a single, specific financial institution (the “first financial institution”). Knowledge of the first financial institution's transactions and overdraft event transaction descriptions are used to determine a particular set of overdraft signatures. The set of overdraft signatures from the first financial institution are transferred and applied to a different set of users and transactions belonging to a different financial institution (the “second financial institution”) to obtain an initial partition of the second financial institution's users into the two classes of interest (e.g., users that incurred an overdraft event and users that did not). The process continues by identifying transaction description features within the overdraft-incurred group and determining previously unseen overdraft events for the second financial institution.

An example process for evaluating financial transaction information and detecting overdraft/NSF transaction events may be as follows: inputting, at a first computing device and from a second computing device connected to the first computing device through a first network connection, first transaction data for users of associated with a first financial institution; extracting overdraft evaluation features (e.g., tokens) from the input first transaction data; splitting the extracted overdraft evaluation features into a plurality of groups based on previously stored overdraft feature signatures associated with transactions at a second financial institution; and for each group within the plurality of groups, the first computing device being adapted to score the extracted overdraft evaluation features in the group, and identify features within the extracted overdraft evaluation features corresponding to an overdraft transaction event for the first financial institution.

In one embodiment, the previously stored overdraft evaluation scores associated with transactions at the second financial institution are input from a trained machine learning overdraft evaluation model that evaluated second transaction data from the second financial institution.

FIG. 1shows a system100configured to evaluate financial transaction information and detect overdraft transaction events (i.e., NSF events) according to an embodiment of the present disclosure. System100may include evaluation server120, information server140, and/or user device150. Network110may be the Internet and/or other public or private networks or combinations thereof. Evaluation server120, information server140, and/or user device150may be configured to communicate with one another through network110. For example, communication between the elements may be facilitated by one or more application programming interfaces (APIs). APIs of system100may be proprietary and/or may be examples available to those of ordinary skill in the art such as Amazon® Web Services (AWS) APIs or the like.

Evaluation server120may be configured to train an evaluation model based on known overdraft descriptions and other features extracted from financial transactions associated with the first financial institution and evaluate financial transactions associated with the second financial institution to detect previously unseen and other overdraft events for users of the second financial institution. Evaluation server120may include an NSF evaluation service122, which may be configured to collect and process the data, and an NSF evaluation database124, which may be configured to store the collected data and/or the outcome of the processing by the NSF evaluation service122. Detailed examples of the data gathered, processing performed, and the results generated are provided below.

Evaluation server120may gather the data from information server140and/or user device150. For example, information server140may include information service142, which may maintain financial transaction data of users of one or more financial institutions in an information database144and transmit the data to evaluation server120. Information service142may be any network110accessible service that maintains customer usage/interaction with a product. A non-limiting example set of information services142may include Mint®, TurboTax®, QuickBooks®, QuickBooks Self-Employed®, QuickBooks Online®, LinkedIn®, Facebook®, other services, or combinations thereof. Detailed examples of the data gathered from information service142are provided below.

User device150may be any device configured to present user interfaces and receive inputs thereto. For example, user device150may be a smartphone, personal computer, tablet, laptop computer, or other device. In one embodiment, the user device150may execute or access the financial management services application that may be used to store financial transaction data in a database such as e.g., information database144.

Evaluation server120, information server140, and user device150are each depicted as single devices for ease of illustration, but those of ordinary skill in the art will appreciate that evaluation server120, information server140, and/or user device150may be embodied in different forms for different implementations. For example, any or each of evaluation server120and information server140may include a plurality of servers. Alternatively, the operations performed by any or each of evaluation server120and information server140may be performed on fewer (e.g., one or two) servers. In another example, a plurality of user devices150may communicate with evaluation server120and/or information server140. A single user may have multiple user devices150, and/or there may be multiple users each having their own user device(s)150.

FIG. 2is a block diagram of an example computing device200that may implement various features and processes as described herein. For example, computing device200may function as evaluation server120, information server140, or a portion or combination thereof in some embodiments. The computing device200may be implemented on any electronic device that runs software applications derived from compiled instructions, including without limitation personal computers, servers, smart phones, media players, electronic tablets, game consoles, email devices, etc. In some implementations, the computing device200may include one or more processors202, one or more input devices204, one or more display devices206, one or more network interfaces208, and one or more computer-readable media210. Each of these components may be coupled by a bus212.

Display device206may be any known display technology, including but not limited to display devices using Liquid Crystal Display (LCD) or Light Emitting Diode (LED) technology. Processor(s)202may use any known processor technology, including but not limited to graphics processors and multi-core processors. Input device204may be any known input device technology, including but not limited to a keyboard (including a virtual keyboard), mouse, track ball, and touch-sensitive pad or display. Bus212may be any known internal or external bus technology, including but not limited to ISA, EISA, PCI, PCI Express, NuBus, USB, Serial ATA or FireWire. Computer-readable medium210may be any medium that participates in providing instructions to processor(s)202for execution, including without limitation, non-volatile storage media (e.g., optical disks, magnetic disks, flash drives, etc.), or volatile media (e.g., SDRAM, ROM, etc.).

Computer-readable medium210may include various instructions214for implementing an operating system (e.g., Mac OS®, Windows®, Linux). The operating system may be multi-user, multiprocessing, multitasking, multithreading, real-time, and the like. The operating system may perform basic tasks, including but not limited to: recognizing input from input device204; sending output to display device206; keeping track of files and directories on computer-readable medium210; controlling peripheral devices (e.g., disk drives, printers, etc.) which can be controlled directly or through an I/O controller; and managing traffic on bus212. Network communications instructions216may establish and maintain network connections (e.g., software for implementing communication protocols, such as TCP/IP, HTTP, Ethernet, telephony, etc.).

NSF evaluation service instructions218may include instructions to train an evaluation model based on known overdraft features and other features extracted from financial transactions associated with a first financial institution and evaluate financial transactions associated with a second financial institution to detect previously unseen and other overdraft events for users of the second financial institution as described herein.

Application(s)220may be an application that uses or implements the processes described herein and/or other processes. The processes may also be implemented in operating system214.

To provide for interaction with a user, the features may be implemented on a computer having a display device such as a CRT (cathode ray tube) or LCD (liquid crystal display) monitor for displaying information to the user and a keyboard and a pointing device such as a mouse or a trackball by which the user can provide input to the computer.

FIGS. 3 and 6respectively illustrate an example process300for training an evaluation model based on known overdraft event features and other features extracted from financial transactions associated with a first financial institution and a process600of evaluating the financial transactions associated with a second financial institution based on the trained model to detect previously unseen and other overdraft events for users of the second financial institution. System100may perform some or all of these processes illustrated inFIGS. 3 and 6.

Specifically,FIG. 3shows an example machine learning model development process300according to an embodiment of the present disclosure. At step302, the evaluation server120, via NSF evaluation service122, accesses and or receives financial transaction data for customers/users associated with the first financial institution. The financial transaction data for the customers/users associated with the first financial institution may be accessed or received from the information database144of the information server140executing the information service142. In one embodiment, the information service142may be a financial management service such as Mint®, a tax preparation application such as TurboTax®, or an accounting application such as QuickBooks®, QuickBooks SelfEmployed®, or QuickBooks Online®, each of which are provided by Intuit Inc. of Mountain View, Calif.

The input financial transaction data may include user data and transaction attributes such as e.g., transaction date and amount, the identification of the merchant or payee, the identification of the financial institution, and a description of the transaction. As can be appreciated, the input financial transaction data may contain data associated with transactions that lead to overdraft events and transactions that did not. As is described below in more detail, the descriptions of the transactions, which may be a textual and/or graphical descriptions of the transactions, may be used to identify transactions that were or were not associated with an overdraft event. In one embodiment, the first financial institution is an institution that has been well-studied or previously studied, such that knowledge of the transaction descriptions typically used by the first financial institution are already known, which may assist in the accuracy of the training process300.

At step304, features are extracted from the transaction descriptions of the financial transaction data and stored in a features table. In one embodiment, the features are “tokens.” As is known in the art, tokenization is the process of chopping characters, such as sentences or phrases, into pieces referred to as tokens. The tokens are usually words or parts of words and the tokenization process usually discards punctuation. For example, the phrase “first, second, third” may be split into three tokens: 1) “first”; 2) “second”; and 3) “third”. Neither token in this example would include the “,” separating the words in the phrase.

FIG. 4shows an example of a features table400comprising features associated with transactions for customers of the first financial institution. For example, in the illustrated example, the features table400may include a column402of extracted features (i.e., tokens) from step304. For example, column402includes tokens identified as “activity,” “actoverdraft,” “canceled,” “cdn,” “checkingoverdraft,” “cheque,” among others. The table400includes a column404listing the number of times the token was associated with an overdraft event (nsf_count) and a column406listing the number of times the token was not associated with an overdraft event (nonsf_count). The features table400may also include a column408for a normalized number of times the token was associated with an overdraft event (nsf_count_norm), a column410listing a normalized number of times the token was not associated with an overdraft event (nonsf_count_norm), and a column412containing a score (ratio) in accordance with the disclosed principles and as described below. It should be appreciated that the illustrated features table400is merely an example and that the contents of the extracted features would be dependent upon the transaction descriptions utilized by the first financial institution.

At step306, the collected set of features are split into two groups: a first group identified as features from transactions that incurred an overdraft event (i.e., group 1) and a second group identified as features from transactions that did not incur an overdraft event (i.e., group 2). In one embodiment, the process of splitting up the features into groups 1 and 2 can be performed randomly, splitting the features into one of the groups by any random process. In one embodiment, the process of splitting up the features into groups 1 and 2 can be performed based on known overdraft event signatures that were previously studied for the first institution and stored in the evaluation database124. In another embodiment, the collected set of features are split into the two groups based on overdraft event signatures that were obtained manually by e.g., an operator of the evaluation server120, information server140, or from the first financial institution itself. In one embodiment, the features in group 1 can be put into a separate features table for group 1 features while the features in group 2 can be put into a separate features table for group 2 features. Alternatively, instead of separate tables, an additional column/identifier can be added to the feature table400in which the identifier indicates whether a token is in group 1 or group 2.

At step308, each feature in the features table is assigned a score in accordance with the disclosed principles. In one embodiment, features in group 1 (i.e., the features split into a group of transactions that incurred an overdraft event) may be scored as follows:

1) apply a smoothing factor to the nsf_count within column404(i.e., the number of times the token was associated with an overdraft event) and apply the smoothing factor to the nonsf_count within column406(i.e., the number of times the token was not associated with an overdraft event).
2) generate normalized counts of the smoothed nsf_count and nonsf_count. For example, the smoothed number of times a particular token was associated with an overdraft event (nsf_count) may be normalized (nsf_count_norm) by being divided by the total number of users with overdraft events and the smoothed number of times the token was not associated with an overdraft event (nonsf_count) may be normalized by being divided by the total number of users without overdraft events. The normalized nsf_count (i.e., nsf_count_norm) may be stored in its own column (e.g., column408) and the normalized nonsf_count (i.e., nonsf_count_norm) may be stored in its own column (e.g., column410). Sample values for the normalized nsf_count (i.e., nsf_count_norm) and normalized nonsf_count (i.e., nonsf_count_norm) are shown inFIG. 5(discussed below).
3) calculate the score based on the normalized counts. For example, the score for an overdraft incurred token is the normalized count of overdraft incurred users (nsf_count_norm) divided by the normalized count of never incurred overdraft users (nonsf_count_norm). In essence, the score for an overdraft incurred token is a ratio of the normalized counts. That is, the score for an overdraft incurred token (Score_NSF_Token)=nsf_count_norm/nonsf_count_norm. That score may be stored in a “score” column (e.g., column412). Sample scores are shown inFIG. 5(discussed below).

In one embodiment, features in group 2 (i.e., the features split into a group of transactions that did not incur an overdraft event) may be scored by taking the inverse of the score for an overdraft incurred token (Score_NSF_Token) calculated above. That is, the score for a did not incur an overdraft token (Score_NONSF_Token)=1/Score_NSF_Token. That score may be stored in the score column (e.g., column412).

In accordance with the disclosed principles, the higher the score, the more likely the token is affiliated with its group. In one embodiment, a smoothing factor is a number between 5 to 10. It should be appreciated, however, that the disclosed embodiments could use other smoothing factors, or no smoothing factor at all. A smoothing factor may be required in the above calculations to compensate for the tokens that are strongly over-expressed (as discussed below) within one of the two groups.

At step310, labels may be assigned to the scored features. That is, in one embodiment, each feature is assigned an “Incurred NSF” label or a “Did not incur NSF” label. In one embodiment, the labels are applied randomly while preserving the counts described above. Once the features are labeled, the highest scores for each group are recorded/stored in the evaluation database124. Thus, the labels are shuffled. In one embodiment, the shuffling occurs as follows. After scoring each feature (token) a cutoff value (i.e., a threshold) is defined. Each feature with equal or higher value will be defined as “overexpressed.” Setting an arbitrary cutoff value is problematic—different datasets and domains need different thresholds. One way to solve this problem is to define thresholds against the expected score of a random set. In one embodiment, the labels are shuffled between the two sets while preserving proportions (i.e., if the initial ratio was 1:10 for the overdraft Incurred group, it will stay1:10after the shuffle). The score to each member in the two shuffled groups is calculated and the highest score is used as an anchor for the threshold (e.g., twice the score as the highest score of a member in a random set of the same size).

Features (e.g., tokens) that are significantly over-expressed for each of the two groups may be detected at step312and stored in respective feature tables at step314. In one embodiment, “over-expressed” features/tokens are the features/tokens having a score that exceeds the highest score in the shuffled set for their group by at least a factor of 2 or more.FIG. 5shows an example of a features table500of features (e.g., tokens) determined to be most likely associated with an overdraft event for customers of the first financial institution. Although not shown, there may be a similar looking features table for features (e.g., tokens) determined to be most likely not to be associated with an overdraft event for customers of the first financial institution.

In the illustrated example, the features table500may include a column502of extracted features (i.e., tokens) with scores that are over-expressed in favor of the overdraft Incurred group. In the illustrated example, these features include tokens identified as “actoverdraft,” “transactionposted,” “checkingoverdraft,” “canceled,” among others. The table500may also include a column504listing the number of times the token was associated with an overdraft event (nsf_count) and a column506listing the number of times the token was not associated with an overdraft event (nonsf_count). The features table500may also include a column508for a normalized number of times the token was associated with an overdraft event (nsf_count_norm), a column510listing a normalized number of times the token was not associated with an overdraft event (nonsf_count_norm), and a column512containing a score (ratio) in accordance with the disclosed principles and as described above with respect to step308.

In this example, there were 940 users that experienced an overdraft event and 9,659 that did not. The normalized number of times each token was associated with an overdraft event (nsf_count_norm) of column508, normalized number of times each token was not associated with an overdraft event (nonsf_count_norm) of column510, and score (ratio) of column512may be determined as discussed above. In the illustrated example, the tokens, counts, and scores are prioritized such that the highest 20 scores are listed first. Although not shown, in a feature table for features (e.g., tokens) determined to be most likely not to be associated with an overdraft transaction event for customers of the first financial institution, the tokens, counts, and scores are prioritized such that the lowest 20 scores are listed first. As should be appreciated, the counts, normalized counts and scores are merely examples and should not be used to limit the disclosed embodiments in any way. In one embodiment, more than 20 or less than 20 scored features may be presented in the features table500. The knowledge of overdraft and non-overdraft features/tokens (i.e., signatures of overdraft events and non-overdraft events) associated with the first financial institution may be stored in the evaluation database124so that they may be used in subsequent processing.

As noted above, one feature of the disclosed principles is to transfer the learned knowledge associated with the first financial institution (i.e., the signatures associated with the first financial institution) to the financial transaction data associated with a second financial institution to identify previously unknown/unseen and other overdraft events for the second financial institution. One process for doing so is illustrated inFIG. 6. Specifically,FIG. 6shows an example of a process600of detecting previously unseen and other overdraft events using a transfer learning process according to an embodiment of the present disclosure.

At step602, the evaluation server120, via NSF evaluation service122, accesses and or receives financial transaction data for customers/users associated with the second financial institution. The financial transaction data for the customers/users associated with the second financial institution may be accessed or received from the information database144of the information server140executing the information service142. In one embodiment, the information service142may be a financial management service such as Mint®, a tax preparation application such as TurboTax®, or an accounting application such as QuickBooks®, QuickBooks Self-Employed®, or QuickBooks Online®, each of which are provided by Intuit Inc. of Mountain View, Calif.

The input financial transaction data may include user data and transaction attributes such as e.g., transaction date and amount, the identification of the merchant or payee, the identification of the financial institution, and a description of the transaction. As can be appreciated, the input financial transaction data may contain data associated with transactions that lead to overdraft events and transactions that did not. As is described below in more detail, the description of the transaction, which may be a textual and/or graphical description of the transaction, may be used to identify transactions that were or were not associated with an overdraft event. Unlike the financial transaction data associated with the first financial institution, the input financial transaction data associated with the users of the second financial institution is not well-known or previously studied, making it difficult (absent the processing disclosed herein) to detect and predict overdraft events.

At step604, features are extracted from the transaction descriptions of the input financial transaction data and stored in a features table. In one embodiment, the features are “tokens.”FIG. 7shows an example of a features table700comprising features associated transactions for customers of the second financial institution. For example, in the illustrated example, the features table700may include a column702of extracted features (i.e., tokens) from step604. For example, column702includes tokens identified as “activity,” “actoverdraft,” “canceled,” “check,” “checkingoverdraft,” “dividend,” “doug,” among others. As can be appreciated, the features table700may include features that match features in the features table400associated with the first financial institution as well as features that are not found in the in the features table400associated with the first financial institution. The table700includes a column704listing the number of times the token was associated with an overdraft event (nsf_count) and a column706listing the number of times the token was not associated with an overdraft event (nonsf_count). The features table700may also include a column708for a normalized number of times the token was associated with an overdraft event (nsf_count_norm), a column710listing a normalized number of times the token was not associated with an overdraft event (nonsf_count_norm), and a column712containing a score (ratio) in accordance with the disclosed principles and as described below. It should be appreciated that the illustrated features table700is merely an example and that the contents of the extracted features would be dependent upon the transaction descriptions utilized by the second financial institution.

At step606, the collected set of features are split into two groups: a first group identified as features from transactions that incurred an overdraft event (i.e., group 1) and a second group identified as features from transactions that did not incur an overdraft event (i.e., group 2). In one embodiment, the features are split by using the over-expressed feature scores from the stored signatures concerning the first institution. In one embodiment, the decision to which group a user is assigned to may be done by looking at the group of the highest scored tokens affiliated with the user's transactions that exist in the over-expressed sets, and choosing the group of tokens with the highest score.

There are two use cases, which exemplify the benefit of this process. First, the set of tokens identified for each group are used to classify unseen users to the right category. For example, if “dividend” and “inquiry” represent never incurred users with the scores 0.4 and 0.2, respectively, and “canceled” and “odp” represent incurred users with scores 0.6 and 0.8, respectively, an unseen user's transactions containing “odp”, “dividend” and “inquiry” tokens would be classified as NSF-incurred since 0.8 is higher than 0.4+0.2. In another example use case, if the overexpressed tokens of the two groups is used to classify users on an untagged domain (FI), under conventional processing a less than optimal performance would be expected since the model is trained on a different FI. However, since the terminology overlaps, the classification according to the present disclosure can be used to bootstrap the process—that is, looking for overexpressed token at the two newly classified groups and captured new tokens on the way.

Once split, the process600will detect over expressed tokens in the overdraft incurred set of users based on the data for the second financial institution. In one embodiment, the process600may perform similar steps as discussed above with respect toFIG. 3.

For example, at step608, each feature in the features table is assigned a score in accordance with the disclosed principles. In one embodiment, features in group 1 (i.e., the features split into a group of transactions that incurred an overdraft event) may be scored as follows:

1) apply a smoothing factor to the nsf_count within column704(i.e., the number of times the token was associated with an overdraft event) and apply the smoothing factor to the nonsf_count within column706(i.e., the number of times the token was not associated with an overdraft event).
2) generate normalized counts of the smoothed nsf_count and nonsf_count. For example, the smoothed number of times a particular token was associated with an overdraft event (nsf_count) may be normalized (nsf_count_norm) by being divided by the total number of users with overdraft events and the smoothed number of times the token was not associated with an overdraft event (nonsf_count) may be normalized by being divided by the total number of users without overdraft events. The normalized nsf_count (i.e., nsf_count_norm) may be stored in its own column (e.g., column708) and the normalized nonsf_count (i.e., nonsf_count_norm) may be stored in its own column (e.g., column710). Sample values for the normalized nsf_count (i.e., nsf_count_norm) and normalized nonsf_count (i.e., nonsf_count_norm) are shown inFIG. 8(discussed below).
3) calculate the score based on the normalized counts. For example, the score for an overdraft incurred token is the normalized count of incurred overdraft users (nsf_count_norm) divided by the normalized count of never incurred overdraft users (nonsf_count_norm). In essence, the score for an incurred overdraft token is a ratio of the normalized counts. That is, the score for an overdraft incurred token (Score_NSF_Token)=nsf_count_norm/nonsf_count_norm. That score may be stored in a “score” column (e.g., column712). Sample scores are shown inFIG. 8(discussed below).

In one embodiment, features in group 2 (i.e., the features split into a group of transactions that did not incur an overdraft event) may be scored by taking the inverse of the score for an incurred overdraft token (Score_NSF_Token) calculated above. That is, the score for a did not incur overdraft token (Score_NONSF_Token)=1/Score_NSF_Token. That score may be stored in the score column (e.g., column712).

In accordance with the disclosed principles, the higher the score, the more likely the token is affiliated with its group. In one embodiment, a smoothing factor is a number between 5 to 10. It should be appreciated, however, that the disclosed embodiments could use other smoothing factors, or no smoothing factor at all. A smoothing factor may be required in the above calculations to compensate for the tokens that are strongly over-expressed (as discussed below) with one of the two groups.

At step610, labels may be assigned to the scored features and, once labeled, the highest scores for each group are recorded/stored in the evaluation database124. For example, in one embodiment, each feature is assigned an “Incurred NSF” label or a “Did not incur NSF” label. In one embodiment, the labels are applied randomly while preserving the counts described above.

Features (e.g., tokens) that are significantly over-expressed for each of the two groups may be detected at step612and stored in respective feature tables at step614. In one embodiment, “over-expressed” features/tokens are the features/tokens having a score that exceeds the highest score in the shuffled set for their group by at least a factor of 2 or more.FIG. 8shows an example of a features table800of features (e.g., tokens) determined to be most likely associated with an overdraft event for customers of the second financial institution. Although not shown, there may be a similar looking features table for features (e.g., tokens) determined to be most likely not to be associated with an overdraft event for customers of the second financial institution.

In the illustrated example, the features table800may include a column802of extracted features (i.e., tokens) with scores that are over-expressed in favor of the overdraft Incurred group. In the illustrated example, these features include tokens identified as “activity,” “posting,” “odp,” “transactionposted,” “canceled,” “checkingoverdraft,” among others. The table800may also include a column804listing the number of times the token was associated with an overdraft event (nsf_count) and a column806listing the number of times the token was not associated with an overdraft event (nonsf_count). The features table800may also include a column808for a normalized number of times the token was associated with an overdraft event (nsf_count_norm), a column810listing a normalized number of times the token was not associated with an overdraft event (nonsf_count_norm), and a column812containing a score (ratio) in accordance with the disclosed principles and as described above with respect to step608.

In this example, there were 76 users that experienced an overdraft event and 1,182 that did not. The normalized number of times the token was associated with an overdraft event (nsf_count_norm) of column808, normalized number of times the token was not associated with an overdraft event (nonsf_count_norm) of column810, and score (ratio) of column812may be determined as discussed above. In the illustrated example, the tokens, counts, and scores are prioritized such that the highest 20 scores are listed first. Although not shown, in a feature table associated for features (e.g., tokens) determined to be most likely not to be associated with an overdraft transaction event for customers of a first financial institution, the tokens, counts, and scores are prioritized such that the lowest 20 scores are listed first. As should be appreciated, the counts, normalized counts and scores are merely examples and should not be used to limit the disclosed embodiments in any way. In one embodiment, more than 20 or less than 20 scored features may be presented in the features table800. The knowledge of overdraft and non-overdraft features/tokens (i.e., signatures of overdraft events and non-overdraft events) associated with the second financial institution may be stored in the evaluation database124so that they may be used in subsequent processing.

In one embodiment, by backtracking the tokens to their original descriptions, it can be confirmed if a description is an overdraft event or not. In the illustrated example, it was determined that the tokens “fdes” and “nmo” were derived from transaction descriptions such as “forced closed account fdes nmo 0009999 999999 (amount: $37.31)” and “OD protection fee refund fdes nmo 0009999 999999 (amount: $12).” Both descriptions related to a previously unseen overdraft event. With the inclusion of the tokens “fdes” and “nmo” into the evaluation database124, the evaluation service122is enhanced and capable of more accurate overdraft event detection, allowing the financial management services to better predict overdraft events.

It should be appreciated that the disclosed principles provide technological advancements in the art of computerized financial management and other systems. The disclosed processing utilizes a concatenation (e.g., pipeline) of a few linear processes. As such, the disclosed embodiments are very fast (i.e., reduced linear runtime complexity) and may utilize less computing resources (e.g., memory, processor time) than conventional computerized financial management and other systems. In addition, the disclosed principles provide easy to interpret scoring and detection of events that can only be determined using the unique computer implementation disclosed herein.

Moreover, the disclosed principles help users that incur overdraft/NSF events by advising them how to improve their financial situation (e.g. calling the financial institution to have it drop/reduce NSF fees, transfer money from other resources, request a loan, check its account more often etc. In addition, organizations providing financial management services can offer additional overdraft protection/processing specifically targeted to these users.