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 hardcore 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 the banks should provide, and how they should integrate them 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. It is the digital strategy of the bank that has to ensure that these qualities are fulfilled.
Over the last decade digital banking services were all based on internet browsers. Early web applications provided elementary functionality; layouts and styles were simple and unrefined. Over time, the evolution of browser technology enabled enhanced interactivity, online creation of new content, better communication and networking.
A couple of years ago mobile devices entered the game. Given the rapid spreading of smart phones and tablets, banks today are forced to offer their services on these new devices. Faced with this demand, the banks have to take a decision between two implementation options: the first option is to realize the applications in the web browser. This option is enabled by the fact that all mobile devices offer at least one of the familiar browsers. The second option is to go for so-called “native” apps, i.e. applications that run directly either on the operating system iOS or Android.
At first sight, strong arguments speak for a browser-based approach:
Browser technology is proven and has evolved significantly in the past 20 years. There is HTML5, the 5th revision of HyperText Markup Language, and CCS3, the 3rd revision of Cascading Style Sheets. These standards are widely accepted and support 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. Any application needs to be developed only once, and clients 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 for the manager, but very real for the engineer who is tasked to realize 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 “standards” HTML5 and CSS3 mentioned, these browsers support widely different features. The same application may behave or present things differently. 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.
Developers are forced to use numerous hacks, plugins and work arounds to overcome the differences between browsers and limitations of specific browsers. Engineering the compatibility across browsers is extremely time consuming. In addition, the work arounds required increase the complexity of the applications, making them very vulnerable and difficult to maintain.
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 are getting 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.
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. Wouldn’t this save the bank and the client a lot of time? Not 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 does not really solve the problem. As a consequence, such a service would have to be developed individually for each browser version. Why not implement a native app instead.
In our view, the 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. 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 fast and dramatically. Since 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 or adapt existing browser-based applications that your clients can access via the browser of their smartphones and tablets.
Don’t do it. It is extremely difficult to develop stable, consistent, controllable, and reliable applications that run across browsers. In view of the high quality, personalized mobile services that clients demand and the relevance of such services for the industry, the banks are well advised to forget browser applications and instead go for the de facto standard platforms of smartphones and tablets.