Another real time problem

I've seen similar behavior with Washington Mutual's online banking transfers. If you perform a transfer with the date set to the current day, the transfer happens immediately. If you schedule it for any day in the future, the transfer happens at the end of that day.

I'm pretty sure that Washington Mutual won't ding you for an overdraft, though, unless the balance at the end of the day is negative, so these pending transfers are perhaps not as much of a problem as an annoyance.

Steven E. Harris wrote: Andrew DeFaria < snipped-for-privacy@DeFaria.com> writes: Because I entered the transfer on 10/25 after

How can you do that?!? You cannot schedule online transfers. This is not an option in Quicken. I know, I have many online accounts and wish I could schedule online transfers. The closest thing you can get is to schedule an online payment to your bank's direct deposit address. In Quicken, if you attempt to do an online transfer of funds between two online accounts you have to use the current date. Anything else generates an error.

--------------090309050802050905030605--

I apologize in advance for this being so long.

Andrew you have basically answered some of the points raised in your other thread "Posted versus cleared". Batch processing, or probably more accurately how/when it is done, is the reason for the strange quirks we see in our banking transactions. Although I am not in the banking industry, I do have a bit of experience with Relational Database Programming and the inherent problems with providing transaction integrity. Which simply is making sure two or more transactions being entered by different people do not undo or erase any other entered transaction. Using your transfer (credit/deposit) and debit/check as an example a /real time/ transaction would flow like this:

Let's say that the transfer transaction was initiated prior to the debit transaction, but not completed prior to the person starting the debit. Both people get the same account balance information, because neither transaction has completed prior to the others accessing your account. the transfer/credit transaction completes first and is posted and your account now has sufficient funds to cover the check. But remember the person handling the check only has account balance data prior to the completion of the credit. So when the debit is posted it wipes out the transfer/credit transaction and the updated correct account balance is overwritten with the now incorrect account balance and a debit which causes an overdraft condition. Now compound this situation by the bank being one of the national mega-banks with branches all across the country. Since each branch has access to your account data to process transactions that occur at their location, the chance of transactions colliding in this way increase.

Now let's apply this a bit further and look at the implications it would have on the economy. Although this could work to ones benefit when the transaction that was over written is another debit, say for your mortgage payment. Now instead of being out 100's/1,000's of dollars that transaction would have been removed from your account, they are still there. However your mortgage company has credited your account with a payment, that now according to your account has never taken place. I don't think it would be to long before our economy would be thrown into total chaos.

There are methods of preventing the above, account locking and/or transaction rollback. But it would take adding a good bit of programming code as well as adding processing time for each transaction. Account locking would be the most simple to accomplish, whereby when the first person accesses the account the account is locked and now one else can write to that account until the first person finishes their transaction and frees the account. (This is basically what we have in Quicken and other programs, applied on the file level, that prevent two networked computers from opening the same file and making/saving changes to that file.) Transaction rollback is a bit more complicated, in that all people can access the account at the same time. But when any changes are being written back to the account, the account is read again and compared to the original read of that account. If any change is detected the transaction is basically discarded and has to be recreated. Both methods would add some time, not to much though, to the over all transaction length. Which in today's instant gratification I want it now society, may not be well received.

Which brings us back to batch processing, that offers us the consumer the least amount of time spent in front of a teller to conduct a given transaction. It also gives a cost effective way for the banking industry to handle the millions/billions of transactions conducted daily across the country and around the world. I do agree that there should be some changes made in how/when credits and debits are applied to our accounts that would better protect us from overdrafts. Unfortunately until the Feds make such change mandates we are stuck with a system that benefits the banks and not the consumer.

Actually I was answering nothing, rather I was providing yet another example of how this batch processing screws people up. That's probably why I decided to start off by saying "Here's another problem...".

Yes I know, I know! The question is why do they still do batch processing?

As do I. I really don't need the Concurrent Access 101 class lecture again. I know it well...

Yes that's the scenario that's almost always posed in that course, followed quickly by how to resolve such a problem. You do know that we have resolved this problem, not years but decades ago do you not? Hell I remember this class from back in the '80s! That's some 20 years ago! Trust me this problem has indeed been solved.

Not really. Exactly how many concurrent transactions do you think happens in my account?!? If I'm at an ATM in San Jose depositing money you can bet your paycheck that I'm not also at an ATM in Los Angeles withdrawing it at that same time! And on the rare occasions when two people are hitting the same account transaction locks can and should be used to avoid the problem you describe. This is basic concurrent transaction processing 101!

No transaction balance should be overwritten if you programmed it correctly - period!

The scenario you are describing doesn't exist because your premises are wrong.

Utter nonsense! It's not really a good bit of programming - it's second nature to anybody writing systems like that. In fact, even the nightly batch processing needs to do similar locking unless they do all of the processing serially, which I highly doubt. So the code's already there!

Add some time?!? It would, at best, add milliseconds and the normal human being can barely sense a 20 millisecond delay. In any event it would be thousands of folds less than 1 day which is what is currently being done, let along the confusion it causes. Truth is the bank stands to make money on this little charade and that's why it is the way it is!

Would you really even notice a 20 millisecond delay? My bet is that you wouldn't.

Yeah the cost effective part comes in when the fees are collected from the customer! :-(

A change that could have been done right now and would have alleviated the problem: Process credits first, debits next!

And don't use the Feds as an excuse. Even the law quoted here said something to the effect "would not take more than a day" which does not preclude a bank from instituting real time transaction. After all real time satisfies the "not more than one day" requirement - and then some.

There may be reasons why the bank does this but they are not the reasons you state above.

Doesn't each credit processed immediately require a debit somewhere else at the next transaction? You can't 'stack' all the credits up first then do all the debits, can you? I am assuming if you're trying to do 'real time' transactions against two accounts at the same time, albeit at different banks.

No not in this case. We are not talking about double entry accounting here.

You misunderstand. Here's an example: You have $10 in your account. In the morning you deposit $100. In the afternoon you withdraw $40. OK, now nightly batch processing occurs as it is happening today. Tell me, which transaction do *you* want them to process first? The $40 withdrawal or the $100 deposit?

That's what happened to me. The deposit (in this case a transfer but from the viewpoint of my checking account it was money coming in) was processed *after* the withdrawal (again, in this case the withdrawal was a check written to another party that was clearing that day). Both transactions were dated 10/26. I expected that days "deposits" to be processed before that days "withdrawals". But the bank processed the withdrawal first so it caused a trigger to pull from my overdraft and conveniently allowed them to assess a fee. How nice! Luckily I have overdraft, otherwise they would have been able to charge a higher bounced check fee. Stupid, just plain stupid.

Sorry, I was talking about scheduling transfers through my bank's site, not directly through Quicken.

Exactly! Can't be done, though I'd really like to do it. It can be simulated by cutting online checks directly to the bank, if the bank allows it. I've been doing this for years!

Ummm, Banks processing actually makes sense.

Where the bank has control of the days transactions, they will process them at the close of business in the the following sequence:

1. deposits
2. withdrawals - in sequence smallest to largest

Thus, in the case of overdrafts, minimizing the number of overdraft items. This is historic good customer service - you can write a check overdrawing your account and rush to the bank to make a deposit before close of business and then be ok. And, in the case of multiple branches handling paper transactions, you don't get an overdraft depending on which branch got their transaction processed first.

The electronic withdrawal doesn't fit in the above, the withdawal happens on receipt. THus your case, the withdrawal processed first - overdraft (the bank can't respond to the electonic withdrawal with "lets wait and see what happens tonight").

Customers who manage their account close to the edge, have to know the processing sequences. You have a case where the existing rules didn't work for you; "real-time" rules will have similar cases of not working.

Real-time is coming, btw. Checks are debit cards, give a store a check and they will (or will soon) scan it and debit your account right then - real-time and no bad checks. So we are going to have to learn that the transaction processing sequence is sometimes real-time, sometimes not, and not predictable.

dick w

dick w

dick w

No, it doesn't - not to most normal people.

It's that "close of business" that doesn't make sense. It should be immediately!

Demonstrably false in my case wouldn't you agree?

This is the 21st century. Paper processing is a thing of the past!

Aye and that's the rub. BTW there was no paper processing in my case. Both the transfer and the "check" were electronic!

But the bank is exactly responding with "Lets wait and see what happens tonight" now aren't they? The transfer (non paper mind you) was delayed until close of business. That's what doesn't make sense.

I'm not sure what you mean by "overdraft" above. There was a transfer from business checking to my regular checking account and an incoming payment to a creditor. Had the transfer been processed first the payment would have cleared no problem. That didn't happen! Because that didn't happen an overdraft happened to cover the check.

No they don't. Things should be processed in real time - as normal people think of them.

Quite possibly, assuming the withdrawal hits before the deposit. The current processing failed in this case. Both transactions were electronic. Both were dated the same day. There was an increase of funds and a decrease. Had the increase been applied first there would be no problem. That didn't happen. Your "sensible" rules that you say the banks use didn't make any sense now did they?

Your thinking is limited. You mention only checks. I do way more ATM transaction, debt card transaction, etc. than just checks. Also, banks classify online checks or EFT differently than paper checks or online checks that are paper issued. There should be no "soon" about it. It should happen when it happens. When I withdraw $40 from the ATM it should happen right then. When I use my debit card to purchase $12.75 of stuff it should happen right then. When a transfer is made from one account to the other it should happen right then.

I guess we now know who you are - thrice! :-)

Andrew:

There are two different discussions: what does happen now, and what you think should happen. I'm only addressing what does happen. In your response, you missed a beginning detail:

"where the bank has control of the days transactions...".

That control is why your electronic transaction was batched for close of business while the external withdrawal (not in the banks control) was processed real-time. It's from your experience that we can derive the banks processing schedule - and it makes sense, a step in the direction that you want, but not all the way there just yet.

dick w

btw, my thinking might be limited, but please read that section again. The observation is that checks can now be processed just like an ATM transaction - there is no need for a store to keep & forward your check.

end