Skip to content
This repository was archived by the owner on Jul 24, 2025. It is now read-only.

Home

Jump to bottom
Daniel Krook edited this page Jun 13, 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 every other Friday. A serverless architecture scales compute capacity in response to demand and can be used to efficiently match the exact capacity needed. This results in a better customer experience, and an overall better 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 ...

Clone this wiki locally