Skip to content
This repository has been 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
  • Object Storage
  • SendGrid

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

Serverless, autoscaled check deposit processing with OpenWhisk

Santander is one of the largest companies in the world, yet size is no guarantee of future survival given several challenges in the retail banking industry, primarily from disruptive new startups and a changing regulatory landscape.

Success requires cutting-edge cloud computing solutions that achieve better resource utilization through automatic application scaling to match demand; and an associated, finer-grained cost model that helps distribute compute load at a lower cost.

Developers at IBM and Santander partnered to create a next-generation prototype for retail banking with the OpenWhisk open source project hosted on IBM Bluemix, which enables serverless architectures for event-driven programming.

In the OpenChecks journey, you can learn how to develop an event-driven serverless architecture that autoscales in response to highly variable workload demands. For Santander, this means deploying a system that scales up as needed to handle payday check deposits, and scales down the other days of the two week period.

This results in fewer outages for customers when they need access to their money quickly, and it means that Santander does not pay for idle capacity (nor worry about underprovisioning server capacity) in its data center.