Skip to content
This repository was archived by the owner on Jul 22, 2024. It is now read-only.
Daniel Krook edited this page Jun 14, 2017 · 8 revisions

Project OpenChecks on IBM Code

This wiki contains the getting started content posted the IBM Code site.

Page head

Automatically scale to handle peaks in banking customer demand

Hero text

Enable your mobile check deposit processing system to scale automatically in response to payday demand

Intro text

In retail banking deposit processing, IT systems are often over-provisioned in anticipation of peak demand, such as payday (once every two weeks). A serverless architecture scales compute capacity up or down in response to demand and can be used to efficiently match the exact capacity needed. This results in a better customer experience, and a more accurate match between bank IT costs and customer demand.

Overview

This developer journey shows the power of serverless, event-driven architectures to support a retail banking mobile or branch check deposit system. We demonstrate how check images can be uploaded, resized, parsed, and deposited using several serverless functions. This use case highlights how automatic scale and granular pricing for cloud services can make serverless architectures attractive for retail banking workloads that have a high degree of difference between peak and idle demand.

In this scenario, a check image is uploaded to object storage on the cloud where it is resized for use on a customer portal and for archival purpose. It is then parsed to extract deposit account and routing numbers which are supplemented with user or teller supplied information to process the check automatically. This reduces errors and makes the deposit available more quickly for customers.

Flow

  1. A mobile app user or teller at a bank branch scans and places an image into an object storage service (the incoming container) named with the customer email, deposit to account, amount of the check, and timestamp encoded in the file name.
  2. A trigger invokes an action every 20 seconds to poll the object storage service for new check images. (An alternative implementation can push this event instead of polling).
  3. This action queries the object storage service. For each file found, it invokes another action to process the checks asynchronously.
  4. This action downloads the image and puts two resized copies (50% and 25% scaled) into an archive database and the original in an audit database. When all inserts have completed successfully, the files are deleted from the object storage service.
  5. A change trigger on the audit database invokes an action to parse the full size image.
  6. This action retrieves the image, then calls an action to read the from account information and routing number. If it can't read this information, the check is flagged as needing additional human review. It stores the results into a parsed database.
  7. Another trigger is then fired by that change to the parsed database and invokes another action.
  8. This final action retrieves the account details from the parsed record, logs the transaction in the processed database and sends an email alerting the customer.

Components

  • OpenWhisk
  • Cloudant NoSQL DB

Featured technologies

  • Serverless

Related blogs

  • Link to blog post below

Related links

  • What makes serverless architectures so attractive? - Serverless architectures are one of the hottest trends in cloud computing this year, and for good reason. There are several technical capabilities and business factors coming together to make this approach very compelling from both an application development and deployment cost perspective.

  • Build a cloud native app with Apache OpenWhisk - At this live coding event, Daniel Krook provides an overview of serverless architectures, introduces the OpenWhisk programming model, and then deploys an OpenWhisk application on IBM Bluemix, while you watch, step-by-step.

Blog post

Bank deposit processing with OpenWhisk

Imagine that your team is a mobile video game studio of three people. ...

But it doesn't have to be this way. If you had implemented your backend logic as individual microservices deployed to a serverless platform like OpenWhisk, the system could have autoscaled to match demand exactly. ...

This is the promise of an event-driven, serverless architecture for new cloud-native applications such as those that support the microservices needed for mobile gaming backends. Check out the new OpenWhisk demo on ...

Bank of Santander leveraged openwhisk to auto process their nightly check processing batch job using OCR. It would scan the check, translate its amount/bank account number, resize the image and store it. Openwhisk was using to trigger the actions to get the checks processed

Dan Krook has given talks on this at interconnect in conjunction with santandar. They reduced their spend on check processing down to $37k PER YEAR. they process millions and millions of checks per year

Clone this wiki locally