Although I have been involved in document capture for over 20 years, it was not until Datacap joined forces with IBM in 2010 that we started to meet regularly with large banks to help them address their massive mortgage processing challenges.  Even given all the things that I had learned over the years about high-volume document capture, I have been surprised just how many nuances and special considerations that there are when it comes time to scan a mortgage.

Are you considering scanning and advanced document capture in your mortgage business (or are you just interested in learning more capture tricks-of-the-trade)?  If so, then here's my list of the two most important ways that mortgage document capture is special:

1) Document = Batch

Most document capture applications are batch oriented.  Why?  Because it is almost always more efficient to scan a number of documents all at once (a "batch") versus one at a time.  It is also a very useful simplification technique to reduce the number of "things" to track by grouping them into a batch, for example, if a batch consists of 50 documents, then there is a 50-to-1 reduction in 'things' to track.

There are some situations, however, where each document is its own batch.  For example, this is often the case when the capture system reads from faxes.  Typically each transmission is read into its own batch, and the sender is typically sending one document.  Bank branch batch capture (described here) is another good example, where a customer hands over a document to a branch officer and that officer scans that document as a “batch.”

But mortgages are different.  Depending on how you count documents, a mortgage packet of 200 or 250 pages may consist of 15 or 20 fairly generic document types up to 50 to 75 very specific doc types.  In other words, the one meta-document, the "mortgage," is made up of many different individual documents, e.g. the loan agreement, proof of employment, liens, etc.

2) The primacy of document classification

For many years, advanced document capture was called "forms processing" because the task was to read data off of fixed forms.  The archetypical application of forms processing technology was reading tax returns for government revenue departments.  There may be different tax forms and schedules, but typically they had bar codes or other easy-to-identify distinguishing marks.  (Read the Virginia Department of Taxation case study.)

A mortgage "document" with all its sub-documents is a completely different beast.  In the packet there may be some forms with bar codes, but there are many pages that have to be "read" to figure out what they are.  The biggest task - by far - when processing a mortgage is to figure out what each of the sub-documents is, and where they end and the next begins.  There's no easy one-size-fits-all solution.  Doing a good job requires an armory of techniques, some simple and fast like bar code recognition, and some much more sophisticated such as fingerprint matching and textual classification via content analytics.

Of course, mortgage processing shares many challenges and processing characteristics with other large-scale document capture environments. For example, demands for timeliness are high – getting the documents into the repository at the first possible moment in order to make them available for loan servicing or other parts of the organization.  And there is a role – in some organizations – for remote capture in a browser or through MFPs of mortgages and/or related follow-on documents.

Mortgage processing is a bit different than many, perhaps most, document capture applications.  But if you have any experience in document capture, you know that one of the enduring characteristics of capture is that it is “hard” exactly because each application is different.  Even within the category of mortgage processors - e.g. originators, wholesale, correspondent – each have different needs on what document sub-types they want to identify.  The knowledge and experience of one implementation can help with the next, but it is never just a matter of plugging in the same application for two different banks and expecting them to both work the same way!

Ready to learn more?  Check this out: Intelligent Imaging for Financial services White Paper

Scott Blau is IBM's WW Director of Document Capture