That is not a surprise. For this “best effort” report, we are using a data element from captured ISO data. (Refers to the files where we store the many back-and-forth messages between merchant, card processor, and core, that make up each individual debit card transaction.)
This particular data element simply states whether negative balance (courtesy pay) limits and/or overdraft protection balances were included when making the initial debit card authorization decision, or not. If that flag indicates the program looked at those limits, we can charge a fee, if they weren’t, we can’t.
The trickiest part is linking the breadcrumbs between that original authorization and the final transaction that is finally posted. The report relies on being able to look back though all of those interactions to follow the breadcrumbs to determine what happened a Step A compared to what happened at Step Z. Sometimes the breadcrumb trail gets interrupted by one thing or another and becomes hard to follow.
That’s why the technique we will ultimately use in our program enhancements will be different from what we can do with this report, because we’ll be capturing new data elements in order to more consistently link the approval and final posted transaction.
Bottom line, while the report is not guaranteed to identify every potential APSN fee instance, it’s intended to allow for good-faith review and refunding of fees that are likely the result of an APSN scenario. Your credit union may choose to refund other fees, as well. For example, a fee might be material in causing additional fees to be charged for subsequent transactions, even if those aren’t technically APSN transactions according to the definition above. In those cases additional fee refunds may be appropriate. The report is not intended to assist with those decisions, only to point out potential APSN transactions that should be researched further.