Wells Fargo - Quicken Compatibility Issues
Problem #1: Description Field / Payee Field Length Discrepancy Problem #2: Superfluous and Meaningless Description Field Data How WFB and Quicken Could Easily Improve Service By 1000%
An Open Letter To Wells Fargo Bank And Intuit By [name withheld]
Introduction In order for customers to enjoy smooth and effortless banking with Wells Fargo Bank (WFB), WFB must work together seamlessly with Quicken; or whatever financial application the customer chooses. Conversely, Quicken, MS Money, GNUCASH, etc. should seek input from WFB when they make modifications to their software.
In the past, I have attempted to point out technical problems with WFB Online, only to be told "That's a Quicken issue" or "No one else has complained about that problem." When pursuing the matter with Quicken (Intuit), their response was "That's a WFB issue."
Thus, we consumers have been stuck in the middle without a champion to further our cause. There has been an attempt to establish an ultimate standard for financial data exchange files by the OFX Group:
To see this behavior in action, create a transaction in QIF format with a description field of 110 characters. (NOTE: I have seen transactions both online and in CSV format with 117 characters for the full Description field. I am not sure what the official field length for this field is.)
E.g. !Type:Bank D12/19/2005 T-7.63 C* N PCHECK CRD PURCHASE 12/17 SUBMARINA MURRIETA MURRIETA CA NNNN09XXXXXX3126 3535NNNNNN13728 ?MCCX14 121042882DA ^
Next, import this transaction into Quicken and notice how the description is actually truncated as: CHECK CRD PURCHASE 12/17 SUBMARINA MURRIETA MURRIETA CA NNNN09XX
Now, this was a manually created QIF transaction. In reality, the same transaction as downloaded from the WFB online banking site would look like this:
!Type:Bank D12/19/2005 T-7.63 C* N PCHECK CRD PURCHASE 12/17 SUBMARI ^
Notice that the description, is truncated by WFB at 32 characters, even though Quicken allows 64 characters. This IS in accordance with the OFX specification. However, we are looking at a QIF transaction. Regardless, of the format, it would be more prudent for WFB to send the entire description to Quicken and allow Quicken to truncate the field according to its limitations.
All in all, the 32 character length of the description field might not be as big of a problem if it weren't for Problem #2 which is clearly a WFB issue.
Problem #2 The auto-categorization of transactions in Quicken depends upon memorizing the Payee field of a transaction. The Payee field in Quicken is mapped to the Description field of the QIF/OFX/QFX, etc. file.
When a transaction is memorized, its Payee(description) is added to a table and used for comparison when importing subsequent transactions. Once the first characters of the Payee field match an entry in the table, the transaction is auto-categorized. Thus, any transaction where the Payee begins with "CHECK CRD PURCHASE" or "POS PURCHASE" is auto-categorized the same.
E.g. Open Quicken with an existing transaction that has the following Payee and a category of Auto:Gas (This is one of my categories.)
CHECK CRD PURCHASE 11/23 UNION 76 00367060 TEMECULA CA NNN024XXX
Next, import a QIF file (or OFX/QFX) with transactions that have the following descriptions:
!Type:Bank D12/19/2005 T-7.63 C* N PCHECK CRD PURCHASE 12/17 SUBMARI ^ D12/19/2005 T-11.95 C* N PCHECK CRD PURCHASE 12/17 YAH*YAH ^
Notice that the two imported transactions are auto-categorized as Auto:Gas when in reality, they would be Dining:Fast Food and Internet:Subscription:WebHosting according to my categories.
As you can see, there are 25 characters of non-unique information in the case of "CHECK CRD PURCHASE ##/## " and 15 characters of non-unique information in the case of "POS PURCHASE - ". Another way of putting it is that WFB only provides 7 characters of the actual Payee in the former case and 17 characters in the latter.
The type of transaction is not really as useful nor as important as the Merchant/Payee. You will find that MOST people want to know how much was paid, to whom, and when before you tell them whether it was used as a debit card or credit card.
Furthermore, the OFX format has a more elegant solution for what WFB is attempting to achieve. According to Section 11.4.3.1 of the OFX Specification:
11.4.3.1 Transaction types used in Transfers generated from a model are treated identically to individually requested transfers by OFX. Therefore, they should have the transaction types listed below once they are processed. Transfers initiated out of band with respect to OFX should also be handled in this fashion when they appear in a statement download.Type Description CREDIT Generic credit DEBIT Generic debit INT Interest earned or paid Note: Depends on signage of amount DIV Dividend FEE FI fee SRVCHG Service charge DEP Deposit ATM ATM debit or credit Note: Depends on signage of amount POS Point of sale debit or credit Note: Depends on signage of amount XFER Transfer CHECK Check PAYMENT Electronic payment CASH Cash withdrawal DIRECTDEP Direct deposit DIRECTDEBIT Merchant initiated debit REPEATPMT Repeating payment/standing order OTHER Other
As you can see, there is a wide variety of transaction types available which follow the standard. If WFB wants to distinguish between two types of POS transaction, then WFB should petition the OFX organization to have another field added to the specification. WFB should NOT mis-use the NAME/PAYEE field.
Ultimately, the OFX has two specifications for Payee: and . If we look at an actual excerpt from a downloaded QFX transaction from WFB, we see the following:
... POS
20051209-3.85
20NNNNNN5 CHECK CRD PURCHASE 12/07 WENDYS-POS
20051209-10.95
20NNNNNN4 CHECK CRD PURCHASE 12/08 SUPER NPOS
20051209-13.07
20NNNNNN3 CHECK CRD PURCHASE 12/07 LOS PRIDIRECTDEBIT
20051209-1000.00
20NNNNNN2 MBNA ONLINE PYMT ONLINE PMT 0512...
So, WFB is assigning a of POS and then pre-pending the with "CHECK CRD PURCHASE ##/## " when the is only really intended for Payee information, according to the OFX specification.
If WFB did not pre-pend these descriptions, the Payee field could remain the indicated 32 characters (according to the OFX specification) and the information could actually be useful.
E.g. Note the following comparisons:
Current: CHECK CRD PURCHASE 12/17 SUBMARI Proposed: SUBMARINA MURRIETA MURRIETA CA 4
Current: CHECK CRD PURCHASE 12/17 YAH*YAH Proposed: YAH*YAHOO SM BUS/MAIL 408-349-51
Current: POS PURCHASE - SOU BEST BUY #1SO Proposed: SOU BEST BUY #1SOU BEST BMURRIET
Current: POS PURCHASE - ALBERTSONS ALBERT Proposed: ALBERTSONS ALBERTSONSWILDOMAR CA
Further note that there is not another single financial institution out there that performs this sort of pre-pending of information to the Description field. I have queried numerous places including forums, newsgroups, etc. and I would be confident in stating that WFB is the ONLY financial institution that does this.
Summary of Proposed WFB Actions Action Item #1 - Option A - Cease adding the following information to the description field of transactions: "CHECK CRD PURCHASE ##/## " and "POS PURCHASE - "
Action Item #1 - Option B - Post-pend the following information to the description field of transactions: "CHECK CRD PURCHASE ##/## " and "POS PURCHASE - "
Action Item #2 - Option A - Allow the complete description field to be sent to a customer's financial management application, thereby relying upon the financial management application to perform the truncation according to its capacity.
Action Item #2 - Option B - Truncate the description field according to the OFX specification, i.e. at 32 characters.
Action Item #2 - Option C - Consult with the financial management application manufacturers, other financial institutions, and the OFX standards group to encourage standardization on 64 characters rather than 32 for Payee/Name/Description. Truncate the description field at
64 characters in accordance with the new, improved standard AND follow Action Item #1 - Option A above.DISCLAIMER I am a Principal QA Engineer and functional Product Manager in the financial software industry. I have over 20 years of combined QA, development, and product management experience.
In some of the above examples, the character 'N' has been used to replace numeric digit for the sake of security and privacy.