A recent post by Marco Arment prompted me to gather my thoughts on making deposits from a smartphone into your bank account. I have a healthy amount of experience working in banking, and some experience developing software, most of which overlaps the banking experience. I want to discuss how I think Chase implemented this feature and how I would approach the implementation.
Marco ended his post with “Sometimes, new technology is not progress.” I’d like to alter that slightly, to say that poorly implemented technology is not progress. I believe that Chase has implemented a “checklist feature”, a feature that a company creates to stand out in a direct product comparison, rather than to create something great for its customers. I figure that you will see these types of features in industries that are lower margin or maybe just full of accountants.
Personally, I cannot stand “checklist features” – I am too attached to things being “done the right way.” But, from anecdotal evidence, this feature is benefitting Chase quite well. I have heard that people are changing banks simply to have the ability to deposit checks in this manner, and my mom hasn’t complained about the poor implementation (other than the time that I had to explain to her that her deposit had been rejected, days after it was initially deposited.)
Now, to the implementation – when offering a feature like this to my customers, I would be concerned about the following factors:
Identifying check information (routing number, account number, amount, images) Getting the check information to the Bank securely Ensuring that checks have not already been deposited Determining when to give the customer credit for the deposit Providing confirmation of the deposit to the customer
From what I can gather, and I must emphasize that I have no first hand knowledge of Chase’s practices, this is how Chase implemented this feature:
First, they prompt the customer for the amount of the check.
Second, the app sends the images to the server without doing any image quality verification. (Why else would the check get rejected later?)
Chase seems to have combined the third through fifth steps. I am guessing that someone manually looks at each set of images and makes the deposit manually, and that this is why it would it take days to receive a confirmation. That long confirmation time could also be explained by Chase waiting to get the funds from the other bank before approving the deposit, but I hope not, because this is poor way of handling this problem. I am not usually an advocate of pestering a customer with confirmations, but when it comes to money, I don’t think you can give too many. In this case, give the customer two confirmations, one saying that the deposit is good and another saying when the funds are available.
In summary, in Chase’s implementation the iPhone is being used to digitally hand the checks to a teller.
Here is how I would implement it:
First, I would have the customer take a picture of the front and the back of the check. On the iPhone, I would do some basic calculations to determine whether the image was skewed or too out of focus.
Second, if the images passed these basic tests, they would be securely sent to a server via HTTPs. The server would do additional image quality checks and then use OCR to determine guesses for the routing number, account number, check number, check date, and amount. The first three have a high likelihood of being correct, since checks in the United States all use the same font. The amount and check date would be more difficult, since it could be typed in any font or even handwritten. Therefore, after the check has been OCRed, the server would send the information back to the phone for confirmation by the customer. The customer would be prompted to change the information or confirm that it is correct.
Third, once this information is confirmed, the server would ensure that that same check had not been deposited in the past, in any account.
Fourth, the server would determine when the deposit would be available. In most cases, availability should be immediate. This risk rating would be determined by the customer’s account history, average balance, and how long the customer had been with the Bank. Monthly and daily deposit limits would also be put in place based upon this same risk rating.
Fifth, and most importantly for customer experience, the customer will be given confirmation before exiting the app, and will be told to write “VOID” on the front of the check.
In summary, the iPhone and the server work together to bypass the teller.
I’ve left out a lot of implementation details, but other things like not being able to connect to the server or deposit multiple checks in the same deposit are relatively simple to solve. And of course, to actually make my way work you need to know about Check 21 and x9.37 file formats, and have a good way of risk rating your customers, hopefully based upon historical evidence. But compared to having a human being touching every deposit, that stuff is easy.
The key difference between how I would implement this feature, and how Chase seems to have implemented it, is that I would put a lot more of the work and the trust on the technology. Yes, I would still have human eyes review at least a sample of the checks that are deposited. But technology is meant to reduce the burden of repetitive tasks. Let’s use it that way.