top of page

Don't Fall into the Browser Trap

Technology Decisions in Private Banking


Communication is the essence of the relationship between the private banking client and the client advisor. Traditionally, private banking clients have met with their advisors to discuss investments and wealth planning. Today, even hard-core private bankers who strongly believe in face-to-face communication concede that their clients are increasingly using electronic devices to communicate, gather information, and share ideas.

The question today is not whether digital services are needed but rather what services banks should provide, as well as how they should integrate those services into a multi-channel, wealth management experience. Typically, clients do not think in terms of channels, nor do they care about the underlying technology, as long as the services are available, trustworthy, comprehensive, and easy to use. A bank's digital strategy must ensure that these qualities are present in its provided services.​


Over the past decade, digital banking services have been based on Internet browsers. Early web applications provided elementary functionality; layouts and styles were simple and unrefined. Over time, the evolution of browser technology has enabled enhanced interactivity, online creation of new content, better communication, and increased networking.

A couple of years ago, mobile devices entered the game. Given the rapid spread of smartphones and tablets, banks today are forced to offer their services on these new devices. Faced with this demand, banks have to decide between two implementation options: web browser applications or "native" applications. The first option is enabled by the fact that all mobile devices offer at least one of the familiar browsers. The second option— "native" apps—refers to using applications that run directly on either iOS or Android, the two leading mobile operating systems.

Secure Communication between Client and Advisor: Go Native

Mobile apps allow advisors to improve the communication and interaction with their clients. Think about the option to record a secure chat call with the client and directly store it as a call report. You might think this would save the bank and the client a lot of time, but that's not the case if the service is implemented as a browser application. Cross-browser security is a notorious topic in the developer community. Security features are highly platform dependent, and HTML5 doesn't really solve the problem. As a consequence, such a service would have to be developed individually for each browser version. In light of this, why not implement a native app instead?

At first glance, the web browser-based approach seems to garner the strongest arguments:

  • Browser technology is proven and has evolved significantly in the past 20 years. For example, HTML5 (the fifth revision of HyperText Markup Language) and CSS3 (the third revision of Cascading Style Sheets) are widely accepted standards supporting sophisticated user interaction paradigms that go far beyond the primitive options offered by older browser applications.

  • Browser applications run both on desktop computers and on mobile devices. Applications need to be developed only once, and clients can enjoy the same user interaction on their PC and any mobile device, irrespective of the latter's operating system.


Taking a closer look, these seemingly strong arguments are countered by facts that may not be obvious to the manager but are very real for the engineer who is tasked with creating an application:


  • Web applications are accessed from different browsers and browser versions. The most common browsers are Chrome and Firefox, followed by Internet Explorer and Safari. Despite the HTML5 and CSS3 standards mentioned previously, these browsers support widely different features. The same application may behave or present things differently in the different browsers. In some cases, the impact may be minor; for example, some lines may be missing. In other cases, the impact may be more critical; for example, some functionality may not be supported at all.


  • The more sophisticated a web service (for example, to provide some personalized service), the more likely the developer will be using building blocks from frameworks and libraries to achieve the desired results. This in turn increases the incompatibility with other browsers, and testing and debugging becomes a never-ending process. As clients become accustomed to high-quality user experiences, ease-of-use, and fast performance, the use of additional frameworks and libraries is likely to worsen compatibility issues, thereby reducing the overall reliability of applications.


In our view, the web browser-based approach should be chosen for truly simple applications only. Any mildly sophisticated functionality calls for native apps running on both iOS and Android. More often than not, developing separate applications on each of these platforms will not only result in a much better user experience, but it will also be cheaper because, compared to browser environments, both iOS and Android offer stable, robust, and simple platforms that enable rapid development and easy maintenance.

Conclusion

The demand for digital private banking services has been developing quickly and dramatically. Because mobile devices are indispensable today, private banks are facing the choice between "native" mobile apps and mobile browser applications.

The promises of HTML5 may tempt your bank's IT department to create new applications or adapt existing browser-based applications that your clients can access via their smartphone and tablet browsers. Don't do it. Developing stable, consistent, controllable, and reliable applications that run across browsers is extremely difficult. In view of the high quality, personalized mobile services that clients demand and the relevance of such services for the industry, banks are well advised to forget browser applications and instead go for the de facto standard platforms of smartphones and tablets.


6 views
bottom of page