Win $20,000. Help build the future of education. Answer the call. Learn more

Archived | Automatically scale to handle peaks in banking transaction demand

Archived content

Archive date: 2019-06-30

This content is no longer being updated or maintained. The content is provided “as is.” Given the rapid evolution of technology, some content, steps, or illustrations may have changed.


In retail banking deposit processing, IT systems are often over-provisioned in anticipation of peak demand, such as a payday that occurs once every two weeks. A serverless architecture scales computing capacity in response to demand, efficiently matching the exact capacity needed and resulting in a better customer experience and more accurate match between bank IT costs and customer demand.


If you’re providing banking services online, you better be ready for any level of demand. A retail bank that can’t handle peak periods from mobile, web, and branch traffic will quickly lose customers to a more agile competitor. The good news is that a serverless architecture can help you efficiently and automatically scale up or down to exactly meet the current workload.

Any developer who works for a retail banking organization has to write code and build systems that can handle major spikes in the number of transactions. If you’re one of those developers, or if you hope to be, finding an efficient way to scale up to respond to demand will make you extremely popular with your IT managers and executives.

This code pattern shows the power of serverless, event-driven architectures to support a retail banking mobile or branch check-deposit system. You’ll learn how check images can be uploaded, resized, parsed, and deposited using 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 archives. It’s then parsed to extract deposit account and routing numbers, which are supplemented with user- or teller-supplied information in order to process the check automatically. This process reduces errors and makes the deposit available more quickly for customers.

If you’re tasked with helping a retail bank complete transactions efficiently and dependably regardless of workload demands, or if you want to understand more about the serverless techniques and tooling that can help you do it, this developer journey is your starting point.



  1. A mobile app user or teller at a bank branch scans and places an image into an object storage service (the incoming container) with the customer email, payee account number, amount of the check, and timestamp encoded in the file name.
  2. An “alarm to poll” trigger invokes a “find checks” 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. The “find checks” action queries the object storage service. For each file found, it invokes a “save-images” action to process the checks asynchronously and in parallel.
  4. That action downloads the image and puts two resized copies (50% and 25% scaled) into an “archived” database and the original in an “audited” database. When all inserts have completed successfully, the files are deleted from the object storage service.
  5. A change trigger on the “audited” database invokes a “parse-check” action to read information from the full size image.
  6. That action retrieves the image, then calls an “OCR action” action to read the payer information and routing number. If it can’t read this information, the check is flagged as needing additional human review. It stores the results in a “parsed” database.
  7. Another trigger is then fired by that change to the “parsed” database and invokes the “record deposit” 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.


Ready to put this code pattern to use? Complete details on how to get started running and using this application are in the README.