Interesting EOY Reversal Dynamics

At one of our acquirer-side payment switch implementations, the terminal-generated reversal/void count is exhibiting its annual end-of-year spike:

What's going on here?  This phenomenon is the result of people rushing to this nation-wide retail chain looking to fully use their Flexible Spending or Health Savings Accounts ('FSA/HSA') prior to those benefits expiring at end of year.  Our implementation supports partial approvals of these transactions.  What's happening in these situations is:

1. We format and send the transaction to our client's FSA/HSA gateway (here, the excellent FDR North network).  As part of this transaction, we turn on an indicator asking FDR to inform the card issuer that we're capable of supporting partial approvals.
2. We get an approval back along with the original amount we requested and the amount the issuer approved.
3. We inform our client's store system of the approval amount.
4. In cases where the approved amount is a partial, the store system instructs the associate to ask for another form of payment to cover the remaining amount.
5. At this point, most people provide the funds to complete the sale from another source.  But, in many cases, the customer elects to void the sale or reduce the size of their market basket.  [This is understandable behavior: many people aren't aware of the exact balance of their card; and HSA transactions are complicated by the item qualification process and card purse dynamics.]
6. The void generates a reversal-class transaction which we take and place into the store and forward ('SAF') queue we maintain for this gateway connection.

The Terminal Reversal category actually tallies two separate transactions: the void (as described above) and reversals (occasions in which the store system didn't get a response from us within the alloted time period).  The former are customer-initiated decisions; the latter are system-generated actions.  We had a very clean day performance-wise, so I know that elevated number is almost purely the result of voids.

[For the record, Host Reversals - see other column - are something else entirely: it's when we (the payment switch) timeout the gateway or endpoint.]

This end-of-year customer behavior has quite a material impact on these metrics.  I went back and took a look at November statistics to get a worthy comparison.  For those 30 days, we - on average - tallied one (1) terminal reversal or void for every 5,174 transactions recorded with a standard deviation of 1,236.  For December 30th, the number was one per 1,573 transactions (a width of 2.9 standard deviations away from the November average).  For December 31st, it was down to 1,136 (3.2 SDs).