Another real time problem

[Andrew DeFaria]

Here's another problem that makes it appear to the customer like it's
wrong and is a direct result of bank's adherence to old style, batch
mode processing that to me just doesn't fly in this day and age of
instantaneous communications in the 21st century.

I have a transfer from my business checking account -> my main checking
account. I also have an incoming payment to a creditor, an online check,
happening on my main checking account...

Well my transfer finally happened on 10/26. A check also cleared on
10/26. The transfer was more than enough to cover this check. Both
transactions are dated 10/26. Yet the clearing of the check cause a
draft from my overdraft! Why? Because I entered the transfer on 10/25
after 9 Pm so it was processed the next day - 10/26. OK fine you say -
next day (10/26) when the bank opens the transfer will apply. This
additional money should cover that check no problem! But NOOOO! The
transfer is posted 10/26 but will not actually be there until "close of
business" that day. That's funny, the check, again, remember also dated
10/26, applied before close of business that day resulting in the draw
from my overdraft. How the hell does that make any sense?!? Why, in this
day and age, do we need to wait for "close of business" anyway? And if
we must wait till close of day, why wouldn't the two transactions, both
dated 10/26, *both* clear at close of business?!?

Now I'm no conspiracy guy by any sense of the phrase, however the only
explanation for the above that I can think of is that it's because the
bank makes money on the transaction fee assessed from the overdraft
draw! Luckily UBOC was nice enough to listen to me, understand my
problem with the above processing and refunded the fee.
--
God is my co-pilot, but the Devil is my bombardier.

[Steven E. Harris]

Andrew DeFaria <Andrew@DeFaria.com> writes:
Because I entered the transfer on 10/25 after 9 Pm so it was processed the next day - 10/26. OK fine you say - next day (10/26) when the bank opens the transfer will apply. This additional money should cover that check no problem! But NOOOO! The transfer is posted 10/26 but will not actually be there until "close of business" that day.

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

[Andrew DeFaria]

Steven E. Harris wrote:
Andrew DeFaria <Andrew@DeFaria.com> writes: Because I entered the transfer on 10/25 after 9 Pm so it was processed the next day - 10/26. OK fine you say - next day (10/26) when the bank opens the transfer will apply. This additional money should cover that check no problem! But NOOOO! The transfer is posted 10/26 but will not actually be there until "close of business" that day. 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.

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.

[Disciple]

On Fri, 28 Oct 2005 15:26:58 GMT, Andrew DeFaria wrote:
Here's another problem that makes it appear to the customer like it's wrong and is a direct result of bank's adherence to old style, batch mode processing that to me just doesn't fly in this day and age of instantaneous communications in the 21st century.

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.

<snipped: for full text see Andrew's post above>
--
Disciple - Team Z
Do not be deceived; "Bad company corrupts good morals." 1 Cor. 15:33

[Andrew DeFaria]

Disciple wrote:
On Fri, 28 Oct 2005 15:26:58 GMT, Andrew DeFaria wrote: Here's another problem that makes it appear to the customer like it's wrong and is a direct result of bank's adherence to old style, batch mode processing that to me just doesn't fly in this day and age of instantaneous communications in the 21st century. Andrew you have basically answered some of the points raised in your other thread "Posted versus cleared".

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...".
Batch processing, or probably more accurately how/when it is done, is the reason for the strange quirks we see in our banking transactions.

Yes I know, I know! The question is why do they still do batch processing?
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.

As do I. I really don't need the Concurrent Access 101 class lecture
again. I know it well...
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.

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.
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.

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!
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.

No transaction balance should be overwritten if you programmed it
correctly - period!
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.

The scenario you are describing doesn't exist because your premises are
wrong.
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.

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!
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.

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!
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.

Would you really even notice a 20 millisecond delay? My bet is that you
wouldn't.
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.

Yeah the cost effective part comes in when the fees are collected from
the customer! :-(
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.

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.

[Andrew]

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

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.

--
-------------------------------------------------------------
Regards -

- Andrew

[Andrew DeFaria]

Andrew wrote:
Andrew DeFaria wrote: A change that could have been done right now and would have alleviated the problem: Process credits first, debits next! Doesn't each credit processed immediately require a debit somewhere else at the next transaction?

No not in this case. We are not talking about double entry accounting here.
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.

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.
--
My girlfriend always laughs during sex - no matter what she's reading.

[Steven E. Harris]

Andrew DeFaria <Andrew@DeFaria.com> writes:
How can you do that?!? You cannot schedule online transfers. This is not an option in Quicken.

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

--
Steven E. Harris

[Andrew DeFaria]

Steven E. Harris wrote:
Andrew DeFaria <Andrew@DeFaria.com> writes: How can you do that?!? You cannot schedule online transfers. This is not an option in Quicken. 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!
--
If debugging is the process of removing bugs, then programming must be
the process of putting them in.

[Dick Weaver]

> Andrew DeFaria wrote: Here's another problem that makes it appear to the customer like it's wrong and is a direct result of bank's adherence to old style, batch mode processing that to me just doesn't fly in this day and age of instantaneous communications in the 21st century.

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

[Andrew DeFaria]

Dick Weaver wrote:
Andrew DeFaria wrote: Here's another problem that makes it appear to the customer like it's wrong and is a direct result of bank's adherence to old style, batch mode processing that to me just doesn't fly in this day and age of instantaneous communications in the 21st century. Ummm, Banks processing actually makes sense.

No, it doesn't - not to most normal people.
Where the bank has control of the days transactions, they will process them at the close of business in the the following sequence:

It's that "close of business" that doesn't make sense. It should be
immediately!
1. deposits 2. withdrawals - in sequence smallest to largest

Demonstrably false in my case wouldn't you agree?
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.

This is the 21st century. Paper processing is a thing of the past!
The electronic withdrawal doesn't fit in the above, the withdawal happens on receipt.

Aye and that's the rub. BTW there was no paper processing in my case.
Both the transfer and the "check" were electronic!
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").

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.
Customers who manage their account close to the edge, have to know the processing sequences.

No they don't. Things should be processed in real time - as normal
people think of them.
You have a case where the existing rules didn't work for you; "real-time" rules will have similar cases of not working.

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?
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.

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.
dick w dick w dick w

I guess we now know who you are - thrice! :-)
--
If you have a difficult task, give it to a lazy person; they'll find an
easier way to do it.

[Dick Weaver]

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
Andrew DeFaria wrote: Dick Weaver wrote: Andrew DeFaria wrote: Here's another problem that makes it appear to the customer like it's wrong and is a direct result of bank's adherence to old style, batch mode processing that to me just doesn't fly in this day and age of instantaneous communications in the 21st century. Ummm, Banks processing actually makes sense. No, it doesn't - not to most normal people. Where the bank has control of the days transactions, they will process them at the close of business in the the following sequence: It's that "close of business" that doesn't make sense. It should be immediately! 1. deposits 2. withdrawals - in sequence smallest to largest Demonstrably false in my case wouldn't you agree? 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. This is the 21st century. Paper processing is a thing of the past! The electronic withdrawal doesn't fit in the above, the withdawal happens on receipt. Aye and that's the rub. BTW there was no paper processing in my case. Both the transfer and the "check" were electronic! 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"). 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. Customers who manage their account close to the edge, have to know the processing sequences. No they don't. Things should be processed in real time - as normal people think of them. You have a case where the existing rules didn't work for you; "real-time" rules will have similar cases of not working. 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? 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. 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. dick w dick w dick w I guess we now know who you are - thrice! :-) -- If you have a difficult task, give it to a lazy person; they'll find an easier way to do it.