From time to time, we hear from a user whose scanner is experiencing slower-than-normal read rates, but is otherwise functioning fine. While we’ve previously explained why other attributes of a scanner are sometimes more important than straight “speeds and feeds,” if it says 100 documents per minute (DPM) on the box and the device isn’t doing 100 DPM, we want to find out why.
One of the first things we learned is that, if a scanner is going more slowly than normal – but it’s still working – it’s almost never because of a mechanical problem with the scanner itself. Unlike, say, a car, there’s no physical problem that would cause a scanner to “lose power” over time, or operate at less than its rated speed; the motors tend to either turn at full speed or not turn at all. Very occasionally, someone will end up with the wrong model of scanner, which, while infrequent, does happen.
The point is, most mechanical problems tend to cause hard stops, frequent jamming, and so on, but not a partial loss of speed. One example of this is when the lens becomes dirty from frequent use, causing frequent “can’t-read” errors that look like paper jams. A simple cleaning usually takes care of this problem.
So what DOES trigger a partial loss of speed? Most cases can be traced to one of a handful of common causes as the scanner communicates with other banking applications.
Image Processing Tasks
Once a check is converted into an image, the job is not done – the bank’s software has to interpret the image and verify that it is usable. So the software uses optical character recognition (OCR) and performs an image quality analysis to tell whether it is readable or not. All of this has to happen between the time the check passes the image sensor and the time it reaches the exit pocket. In a scanner operating at 100 DPM, that allows just a few hundred milliseconds for the information to be sent out, analyzed by the system, and bounced back to the scanner. Needless to say, that’s cutting it close, and in fact, many banking apps are designed for 75 DPM or less. If that’s the case, the program will slow down the scanner to match its own top speed, which may leave some users scratching their heads.
This is not always the case; some banking applications are “pipelined” so that the scanner can run at rated speed while image quality analysis and recognition take place. In these instances, the device should not slow down except in the event of a jam.
Internet Bandwidth
Cloud-based applications are becoming ever more widespread, and many remote deposit capture services are following that trend. In many cases, this means RDC users can only scan as fast as they can upload data to the system. Today’s broadband connections are more than sufficient for the task; however, a slowdown can occur if your upstream connection (which typically has much less bandwidth than your downstream connection) is experiencing problems. More often, you may notice a loss of speed due to the lag time while the image is transmitted and the RDC service processes it and responds.
Some RDC applications get around this by adding a small buffer of 10 to 20 items, so that the scanner isn’t strictly tied to Internet throughput. So a small stack of checks may go through without trouble, though larger batches will absolutely see this effect.
We generally advise customers that the rated speed cannot be guaranteed with cloud RDC services; for high-speed scanning, the best solution is to download and install a “fat client” desktop software package and scan your checks offline, then upload in bulk. If you can find a fat client service anymore, that is – many banks have eliminated them in favor of cloud-only systems.
Sorting
Much like OCR and other image processing functions, sorting checks into two or more output pockets requires time for the banking software to receive the image and make a decision. Most production-scale scanners designed for branch back counter capture compensate for this by using a longer track length, which allows more time for this process but keeps the checks moving through at top speed. (This is one reason why branch capture scanners tend to be much bigger devices.) However, sorting on a device with a shorter track length will inevitably require the speed to be lowered, and even most branch scanners will suffer a performance hit when sorting is enabled. Digital Check’s BranchXpress scanner is one of the few that was designed to have zero performance loss while sorting.
It should be noted that sorting based on MICR information alone generally happens fast enough that it does not cause any degradation in speed. Sorting on something contained in the image (CAR/LAR or image quality analysis) does slow down the process.
Miscellaneous
Rated speeds are based on the time it takes a series of standard 6-inch checks to pass through the scanner. Using a stack of documents with varying sizes may cause a slight variation, though the items will still be moving through the track at the same speed (the difference probably will not be noticeable to the naked eye).
Another effect occurs with small batches of checks fed through high-speed scanners: The first check through the track has empty space in front of it, so for a split-second, the scanner is running but no checks are coming out into the exit pocket. This technically lowers the wall-clock speed, though as before, it is not noticeable to the naked eye. See our white paper, Deconstructing the Scanner Speed Wars, for a more complete explanation of this phenomenon.
Some scanners also offer an “auto-alignment” or “self-alignment” feature, which basically lines up each check in the feeder if you didn’t straighten out the stack yourself. This sometimes slows down the process because the scanner cannot begin straightening the document that is “on deck” until the one in front of it has left the feeder. Even though the alignment itself only takes a split-second, there will be a longer gap between checks in the track, and therefore the per-minute capacity is reduced.
