JPMorgan Chase & Co. Bank Account Or Service Complaint

JPMorgan Chase & Co. Bank account or service department,

Checking account Making/receiving payments, sending money Michigan

On -/-/- I updated my Chase checking - repeating payment, changing the amount and designating a 12-month duration. The 1st payment would be made on -/-/-, the 12th on -/-/-. On -/-/- Chase made a 13th EFT payment. Chase Customer Service ( CS ) claims I made - other duration updates. Why was the 13th payment made? Multiple programmatic errors in the code that addresses the following timing issue. My update was made the same day the current month payment was scheduled for payment, but 9 hours before the payment was transmitted. Only after transmission would the -/-/- payment record be created.


Chase 's solution to this timing issue is to modify the -/-/- record, posting my update duration plus one month ( 13 ) to the Remaining Transactions ( RT ) field. When the payment is transmitted and the new -/-/- record created, the code subtracts one from the -/-/- RT and posts that count ( 12 ) to the -/-/- ( effective date ) record presumably to match the duration in my update made earlier in the day. The -/-/- record was not affected by my update but from the 13 RT it contains, CS infers and asserts that a 14-month update was made prior to payment. This is the basis for CS 's alleged 14-month update. The -/-/- effective date payment record, which after the 1st of 12 payments should have 11 RT contains 12 RT, from which in turn CS infers then asserts that an update for 13 months was made prior to payment. This is the basis for the - 13-month updates CS alleges. Each future record subtracted one month from the previous record RT to determine the new RT, culminating in the 13th payment on -/-/-. Anyone who makes a duration update on the same day a current payment is scheduled is unwittingly signing up for an extra payment and for many customers, resulting overdraft fees. Further, Chase has -, mutually exclusive, payment histories going on : One for CS from which payments are made, and one for Chase customers with correct RT : RT history is available only to CS. It is not available online, but current-day RT is and it 's calculated correctly ( it does n't reference CS payment history ). Victims of this programmatic snafu have no clue something is amiss. The -/-/- CS payment record contains 11 RT. On -/-/- I saw 10 RT online ( documented ). The latter was correct. To illustrate : If an online Chase customer RT history existed with payment records reflecting what I would have seen on any given day in the duration period, with the -/-/- and -/-/- records corrected for actual status and RT, are placed in a table and the table is positioned concurrent to Chase CS payment records, the result ( a 13th payment ) of the programmatic errors described herein is clear. Chase customers have no defense. Many thousands of updates can be inferred for any Chase CS payment record. That is precisely what CS does, throwing out alleged, unverifiable updates - as many and as often, however implausible - as needed. Every customer argument is countered with a new alleged update. All customer documentation is ignored. The theory presented here is a plausible and reasonable accounting of the 13th payment. It fits precisely all available information ; it requires not one incredible or even ordinary leap of imagination to be true. In other words, Occam 's Razor. Chase trotting out as many alleged updates as it takes to chase the customer away, updates for which no means of customer verification exists, is not merely an unreasonable, implausible response to the 13th payment, it 's ludicrous. Until Chase presents a plausible and verifiable response to the 13th unauthorized payment, Chase has some splainin ' to do, payments to give back, and overdraft fees to refund where applicable, to me and to every other customer caught in this timing trap.