Answer:
Answer by John Burnett:
I think that the key here is managing your customers' expectations. And putting some explanatory language on your Web site is the most effective way to do it, I suspect. From your post, you suggest that although customers can initiate a stop order, a bank employee or agent needs to input the data to your system before the stop will be effective. You might post on the screen used by the customer to provide the stop information something like "Your stop payment request will not be effective until we have received it and placed the required information on our processing system. Requests you make after X p.m. on business days and on non business days will not be received by us until X a.m. on the next business day."
As for the risks in accepting stop orders online, you have already identified one -- delay in getting the stop on your system. Another is the authenticity of the request. If your customer has signed into your secure banking system, this problem is minimized.
Finally, there is the matter of customer error. While a stop order taken in person or by telephone provides for some probing and reminding the customer of the need for accuracy (account number, check number, amount), Web sites are usually not so interactive. So you should consider adding warning language that emphasizes the need for accuracy.
Answer:
Answer by Brooke Stokes
Generally, the implication when a user submits a stop payment is that if the check has not yet cleared at the moment the bank confirms receipt of that request, then the request has been made in time to institute the Stop Payment. How FIs actually make sure they either adjust the user's expectations with regard to this implied agreement or insure they can honor this implication is really up to them. There's no set rule/regulation, so you can adjust the user's expectations with appropriate disclaimers. Ideally, you want to provide users with a way to submit a real-time, instant stop to the host such that the host will automatically update the request as soon as possible with either a confirmation that the stop was placed or that the check has already cleared and the stop could not be placed. However, we have seen FIs who cannot justify the expense of implementing a real-time interface into their host system for this capability batch these requests and manually work them at different intervals throughout the day. This is ok, but not ideal. Batching these requests and only working them at end of day is really not acceptable for the reasons indicated above.
In terms of liability, it really depends on the disclaimer language you use to make it clear that this is a request to place a stop payment - not a confirmed stop payment. Also, until the stop is confirmed by the bank, there's no commitment that the stop has actually been placed.
First published on BankersOnline.com 06/16/03
print
share