Integrating Scanners and Other Hardware with Virtual Teller Workstations – Linn Area Credit Union

Here’s why an Iowa-based credit union used network-ready scanners for its virtual branch environment, and how it solved other technical challenges along the way.

Other Sections in this Case Study: Summary / Main Menu | Networking – Virtualizing the Branch | ID Card Image Capture |  Download as PDF

 
A virtual desktop environment is a great way to simplify your IT operations in the long run, but it can take some planning to bring your peripherals along with you. Banks and credit unions in particular tend to have a lot of extra equipment at the teller window, so getting this part right is critically important.

In the nearly 10 years that Linn Area Credit Union has been virtualized, they’ve had experience getting nearly every kind of add-on to work on thin-client virtual workstations. While they’ve been through multiple iterations of software and equipment by now, their IT staff was willing to share some of their stories, and pointers, about making sure everything runs smoothly. USB-connected devices like printers, scanners, and signature pads can usually be plugged in with no issues – but if they’re not designed to be driven remotely, it can be a problem.

 
Check Scanners

A check scanner is one of the peripherals in which built-in network support makes a critical difference – but not necessarily for the reasons you might think. With most USB add-ons, the main issue that arises is how to drive it remotely: Can it be located properly? Is it saturating the system with constant network calls, or becoming “lost” when not in use? Can it be shared properly with other devices, or does it need to be unplugged and reconnected every time?

These types of issues can sometimes happen with check scanners too, but the one that’s frequently overlooked is that of bandwidth usage. Linn Area Credit Union experienced this issue during its original move to virtualization in 2012, when all of its scanners were of the ordinary USB-connected type.

“We did try USB-connected scanners over the network,” explains Blake Rodemeyer, Linn Area’s information systems manager, “but we could not get teller capture to work over USB. The bandwidth just did not allow it.”

The problem Rodemeyer mentions is one that often comes as a surprise to those who aren’t intimately familiar with a check scanner’s internals. The raw images that come off the scanner’s image sensors are sizeable – about 2-3 MB on average, depending on the surface area of the check. In a traditional teller setup, each of those raw image files is sent across a USB cable to the teller’s PC, where it is processed and compressed to its final size of about 10-20 KB before being sent on.

Replace that PC with a pass-through thin-client terminal, though, and there’s nothing to process or compress the image until it reaches the server. That means the 2-3 MB raw image must travel all the way out across the network at full size. With modern check scanners capable of speeds up to 200 documents per minute, those 2-3 MB files can sneakily add up to more than half a gigabyte of data per minute – enough to overwhelm an individual branch’s network and slow the scan speed to a crawl.

That’s the same obstacle that Linn Area was facing back in 2012, and so it opted to use back-counter branch capture, with a scanner connected to a standalone PC instead of a thin-client terminal. “It was the only workstation in our branches that was not part of the main virtual environment,” recalls Rich Head, Linn Area’s VP of information technology,

When the credit union updated its core software in 2019, it also took the opportunity to replace some of its hardware, and USB-connected check scanners were at the top of the list. It chose Digital Check’s network-enabled SmartSource® Expert Elite model, and the bandwidth issue disappeared.

One of the main differences between a regular USB-connected check scanner and a network-ready scanner is that the latter has a small onboard CPU and extra memory built in. That allows it to handle certain key tasks onboard – including the image compression. With checks going out over the network as 10 KB finished images instead of 3 MB raw files, the difference was immediately noticeable.

“The raw data files were just too big,” Head said of the previous USB-connected scanners. “The image compression was really what did it.”

 
Receipt Printers

The other main “mandatory” piece of equipment for teller stations, receipt printers come in all shapes and sizes. They tend to be among the simpler peripherals to direct in a virtual environment. The most typical challenges have to do with resource sharing – for example, when a USB receipt printer and a USB scanner are connected to the same thin-client workstation, sometimes the system will not switch between them cleanly, requiring one or both to be unplugged or rebooted so that it is recognized.

Under Linn Area’s teller pod branch design – in which tellers moved around a lot – another challenge for the system was identifying the specific physical workstation at which the employee was located. The credit union managed to find a workaround with its provider using expanded registry key searches, although this was not a “true” networkable solution.

When Linn Area updated its hardware in 2019, it chose the ReceiptNOW Elite modular printer to go along with its SmartSource Elite scanners. As a device designed to be network-addressable, the ReceiptNOW eliminated the lingering detection and sign-in/sign-out issues – but more importantly, it saved a considerable amount of counter space. With square inches at a premium in the credit union’s compact teller pod designs, the units’ stackable design freed up a big area on the countertop by fitting underneath the scanner.

“Our focus on teller capture really got the ball rolling. We were already looking for an IP-based printer; we wanted no USB-attached devices,” Head recalls. “In the evaluation process for core providers, we asked each of them, ‘Which network scanners do you support?

“We had heard that Digital Check’s SmartSource line used to be made by Burroughs, which Corelation® supported. We had liked one of a competitor’s scanners, but the footprint was an issue. Stackable is a must for us, and stackable plus network-ready is really an ideal combination.”

With the sharing issues addressed, Head and his team have considered moving their teller pods to a setup where one printer would be shared between two workstations: “In the teller pod scenario, having shareable devices between two stations is key. With a printer, it’s not that hard – your staff just has to pay attention.”

 
ID Card Scanners

Fitting an ID card scanner into a virtual environment can be tricky, since most of these devices were originally designed with standard USB operation in mind. Both of Linn Area’s top IT people had experience working with this particular device, with different complications.

“At a previous institution, we had these ID scanners, and we had to follow the same procedure of, ‘If it doesn’t work, follow these steps of unplugging it, and plugging it back in, and relaunching it, and then it’ll work,’” says Information Systems Manager Blake Rodemeyer. “But there was never anything we could do to make it work consistently.”

Linn Area managed to ease the connectivity issues in a roundabout way: “We bought keyboards that had built-in magstripe readers and USB ports, and we connected the ID scanners off of the keyboards,” Rodemeyer recalls. However, that wasn’t the end of the network challenges.

“We could get the USB to redirect and that kind of stuff, but the scanners themselves were problematic. The other aspect of what made them challenging was keeping them calibrated,” Head says. “The only way you could get what I would call a quality scan was if you kept them calibrated. Well, the calibration file is done per device. The physical device may not move around, but the calibration file that you just did on the virtual machine does move around.”

“Although we worked out how to retain the calibration … so that when somebody moves, we move the calibration file – the other issue is that people actually have to calibrate!” Despite the IT department’s reminders to staff, “It was lucky if they were calibrated once per month,” he said.

When shopping for check scanners, the prospect of an IP-based device with ID capture built in was naturally appealing: “The Digital Check SecureLink™ protocol with ID support caught our attention,” Head says. “Since our core supported Burroughs scanners, they said, ‘No problem at all.’ But the interface turned out to be more complicated than anticipated.”

As with many types of novel integrations, a few kinks had to be worked out on the way to launch. At the core of the matter this time was that the core platform, Corelation’s KeyStone package, did not natively support the SecureLink network API. The credit union was able to make them work together with the help of DaLand CUSO, a credit union service organization specializing in custom integration and application development. But that wasn’t the end of it, either.

Linn Area’s teller check capture platform was designed to run on the legacy SmartSource DeviceSuite API, and for ID capture, the core platform was designed to accept images from a TWAIN interface, which was not part of either scanner API package. It was a three-way convergence of software and devices working toward the same goal, but with slightly different (and incompatible) ways of getting there.

To get the project up and running on time, Linn Area called on DaLand again. They were able to devise an ingenious solution, using a unique property of the SmartSource Expert Elite: Each scanner contains both the DeviceSuite and SecureLink APIs onboard, but typically uses only one at a time. DaLand was able to build a software bridge allowing the APIs to “share” scanner resources – when capturing checks, it would be driven by DeviceSuite; when capturing IDs, it would switch to SecureLink. From there, it was just a matter of emulating a TWAIN output so that the core platform could read the resulting ID card image.

“We ran this past DaLand for a fix, and they did it all within a week or two before deployment,” Head says. What’s more, they added in workflow changes to make the images appear directly in the teller program – a feat for which he credits both DaLand’s familiarity with the process and KeyStone’s open API.

“They were very familiar with how to inject code and drive KeyStone with what it needs. The KeyBridge API – it’s an open book. If you, hypothetically, said, I don’t like the UI and I want the client to be completely different, you could do that. … They use the exact same API that they do for developers. So, if a teller can do it, your program can do the same thing.”

The SecureLink API itself also contributed to making the process go smoothly, according to Head. Digital Check purposely designed the SecureLink network protocol to use a streamlined and standardized command set – not only for maximum compatibility, but also to make working with it simple.

“I think the simplicity of Digital Check’s API facilitated that as well. It wasn’t like you’ve got these 80 parameters to deal with. It was pretty much, ‘You make this call, this is what you get in response.’

“Having that clearly defined so that DaLand knew, ‘When I send this, I get A, B, or C in response,’ was important. With some of these other APIs, it might not be overly challenging for someone who understands the API – but if you don’t well define what the results can be and when those would happen … writing a program around that is challenging.”