Project Summary


For the security of our clients, CIBC monitors sessions and will timeout a client after 10 minutes of inactivity (industry standard). In order to refresh the timer, a backend call needs to be made. Before the solution was implemented, this meant clients who were on long pages, would be kicked out of their session – even if they interacted with content – simply because they weren’t submitting data.

This issue was identified as a client and advisor irritant during a new product pilot, where 13% of all product applications would fail due to this issue.

Meeting accessibility requirements

A global solution for session timeouts was not previously created for product flows. The updated behaviour request came from our accessibility teams to allow the user to extend their session. 

Accessibility requirements asked for the pop-up to be displayed every ten minutes of inactivity, but allow the client to refresh their current page view a minimum of ten times. 

A business target our team wanted to reach was to reduce the 13% of App failures (due to time-out) to 1% after the solution was launched.

One solution, two timers

The current infrastructure of our banking apps, did not include a “heartbeat” between the front and back end systems. This constraint meant that sessions could not be kept alive simply by interacting with screen content, until a backend system call was made.

I discovered that there were two timers counting down in a client’s session, a front end timer controlling what the client sees, enters and interacts with; and a backend timer for what the client submits, data storage and pre-filled content. These two timers however were not in sync which would make any countdown clock or specific “time remaining” statement almost impossible.

This often caused issues in flows since the backend would know if a session was timed out before the front end, but the front end needed to make a call to the backend in order to find out and present to the client. This call was only triggered with data submission. So imagine a long form, where the timer ran out, the client continued to fill in data, but when they tried to submit, the client would be kicked out of their flow and prompted to sign in again.

Reviewing competitor solutions

Given that this project was initiated by our accessibility department, we mostly looked at government sites that followed WCAG 2.1 standards.

We did also look at other secure product flows to see if they were presenting any type of specific language around a timeout warning.

Focusing on users with accessibility needs

We needed to consider clients with accessibility concerns (cognitive, physical, visual, etc.) and how to best build the session timeout alert so that these clients could action quickly to extend their session or choose to leave to the application. 

Our accessibility leads specifically asked us to solve for Linux Screen Readers. Our development team had tested the experience with extra attention to Linux screen readers, reviewing the code with our accessibility leads.

Aligning vision and execution

The solution initially was launched through a cart application called Assisted Cart where advisors would be side by side with clients when they were applying for products. After launch, the solution would be rolled out to over thirty application flows across our banking products (desktop, tablet and mobile) and be the solution for any new flows.

We met with development leads, architect leads and accessibility leads to ensure we were considering all possible client scenarios but also tech constraints per product flow. Stakeholder and management demos were held to get solution acceptance.

Exploring product flows

User journey map

There are over 30 different CIBC product flows that we needed to consider. Some were stand alone apps, while others were single app flows, framed in experiences, or multi-tab experiences. 

We also needed to consider where the client was coming from and whether they were signed in or not (authenticated). These authenticated flows were more complex for tech as any cached or save data would have to be cleared once a session was timed out.

To remove as many dependencies as possible, the flow would be divided into three parts. Entry points, alert, exit points. We did this to reduce dev scope of recoding any product flows or behaviours. We isolated the alert to be triggered from existing flows, and then push the client to the appropriate exit points should the session extension fail, the session times out, or the client chooses to leave.

Testing the solution

We decided to create an alert pop-up to display a timeout warning message. The alert would be displayed every ten minutes, two minutes before the timer would run out, which meant the client had less than two minutes to take action.

The content needed to be clear, and easy for a screen reader to communicate within the time. We tested two different messages and message lengths, ultimately choosing a message with additional content that clients felt more secure knowing if they needed more time, the alert would display again after the next 10 minutes.

Positive client feedback

We tested the two version of copy content, using an unmoderated prototype through

62% of clients preferred the second message option with more text,  and enjoyed the extra details about when the alert would appear again.

The feedback overall was that the alert was easy to understand and felt secure.

The pop-up alert

The final solution was created based off the user testing feedback and stakeholder reviews. The example on the left, is the first session timeout alert launched with our Assisted Cart product.

The alert would darken the background content and show two buttons, one to extend the session (“stay on this page”) and one button to exit the session (“leave this page”). The pop-up would display the same content for all applications.

When clients chose to extend their session, where the client would be focused to once they came back to their page content, was very important. This was especially true for long forms and long page content like terms and conditions or account details. We would want to avoid keeping clients in a loop where they would only get through half the page before the alert appears again.

Phase two enhancements

Ending the client’s session was the most technically difficult part of the session timeout alert. Clearing cached data from all the systems was a huge effort for our developers to build. Specifically for the Assisted Cart product the alert would launch with, we were able to leverage the “close” functionality already built in the app, and place it within the alert pop-up. For other product flows, the function could not be built in time for the roll out date.

As much as possible, we wanted the backend to take care of the conditions, but keep the front end (client facing experience) as simple as possible.

For unauthenticated flows, we didn’t want to loose potential leads coming through our cart application. So when the session was ended or had expired, we displayed additional buttons  to “restart application” or “book an appointment”.

Solving for system failures

In the event a system error would cause the session to not extend, we would display either a failed extension message. We would show a session expired message if clients took no action on the pop-up alert.

For authenticated clients, they would be brought back to the login page with the session expiry message. For unauthenticated clients, they would be brought back to their original entry point. For standalone app flows, regardless of authenticated or unauthenticated clients, they would be directed to a new page with an error message.

The final results


By creating a session timeout pop-up alert, clients and advisors were able to continue with their application flows and set their own pace.

Our application flows now met accessibility requirements and we had a reduced app failure rate caused by session timeout from 13% to 1.6%.