Posts

Posted on

Three key focus areas for a bank to get started on mobile journey

Mobile has been significantly changing the way banks service their customers. It’s forcing banks to innovate, transform and try new ways of reaching, engaging and communicating with customers. At the same time it is moving the banking industry away from specific places, products and processes to capabilities that are available when and where customers need them. If your bank was to get started on a mobile journey today, below are three key focus areas that you should consider.

Mobile banking

Mobile banking enablement recently became an important deciding factor for a customer choosing a bank—just as important as fees, branch location or services.

This is the first transformation action you should take for your bank in order to monetize opportunities brought in by mobile. It starts with offering basic banking functions such as:

  • account balance
  • funds transfer
  • bill payments
  • share trade
  • check order
  • transaction notification alerts on mobile devices

The transformation then moves up to providing rich and personalized banking capabilities user experience on a mobile platform[h1] , including high-value services such as remote deposit capture (RDC), wealth management, ATM and branch locator finders, property finders and so on.

Mobile payment

Garner predicts an explosion in the mobile payments market worldwide that is expected to have 448 million users and $617 billion in transaction value by 2016. This trend could potentially introduce a major source of revenue that banks cannot ignore.

In developed markets, where mobile access to financial services is more prevalent and comfortable, mobile payments represent a chance to create feature-rich products that enhance consumers’ banking experience and consequently create better consumer sentiment toward the use of mobile in financial transactions.

Even in developing countries where a significant number of people do not have any bank accounts, mobile still can fill the gap, bring the banking to a new customer base, the un-backed people. This represents an opportunity to create profitable services for the unbanked populations through partnerships between banks and payment or telecommunication companies.

As predicted by the Aite Group, the top mobile payment markets in 2015 by volume will be bill payments, bankcard acceptance, mobile commerce, NFC payments and person-to-person transfers. More information about mobile payment patterns currently available in the market worldwide can be found here.

In all cases, in order to catch the explosion of mobile payments, banks will need to act quickly with a complete mobile strategy that not only covers their infrastructure adaptation as the inevitable transaction volume increases and puts growing pressure on their traditional systems, but also innovates their processes to serve this new, always-on revenue stream.

Mobile marketing

Timing is critical to creating delightful engagement experiences for banking customers. It’s about reaching them in the right place, at the right time, with the right kind of service or message. With the natural, always-on characteristic, and its many other features, mobile could provide a new opportunity to engage, cross-sell, up-sell and promote other banking products or services, like analytics-powered, event-driven and location-based services—just to name a few. As an example, an air ticket purchase might present a chance to cross-sell travel insurance; or a person who steps into a mall could trigger sending him information about a retail promotion program of the bank to buy things in the mall.

People nowadays are embracing mobile in their day-to-day lives and are more likely to forget their wallet at home than their mobile phone. Every mobile device a consumer has can potentially be a commerce device. Your bank needs to transform to catch the trends, be well prepared and focus on key areas that could effectively drive your benefits

Posted on

Would WebSockets Security Vulnerabilities Be A Showstopper?

When you’re developing interactive applications with simultaneous editing ability (for example, a virtual collaborative whiteboard, chat, online game or real-time reporting system over the web), using the traditional loosely coupled HTTP request/response web model is obviously not an efficient way to go. That approach is simply not designed for a real-time model. We need a more lightweight protocol that can provide a full-duplex communication channel between endpoints of the system to achieve as near a real-time experience as possible.

This need is becoming critical as such applications are deployed and run in the mobile world, where the resources for staying connected are sometimes very limited: limited bandwidth, limited memory, lots of potential latency.

A number of creative approaches—work-arounds—aiming to create a real-time feeling for users have been implemented (for example, Ajax, Comet). So far these have served the connected world well by bringing together good user experience with the ability to shorten the time in which data is being sent between client and server. But these approaches still have several limitations from a resource-consumption perspective: a huge redundancy of network traffic, server demands and the complication of maintaining two HTTP connections between endpoints (one for the upstream and another for the downstream).

Using WebSockets is a big step forward in the effort to create an engaging, interactive user experience. It could provide capabilities such as real bidirectional communication, low latency, significant reduction of overhead and dramatically reduced complexity of implementation.

From a security standpoint, though, some people are afraid of using WebSockets due to some risks that would create vulnerabilities. WebSockets’ application programming interface (API) allows establishing WebSockets connections across domains without the user’s acknowledgement, and requests are sent without notifying the user. This makes it possible for the attacker to inject malicious JavaScript code into the victim’s client application (the user agent; for example, browser, mobile app and so forth) to establish a WebSockets connection to an arbitrary target. The connection can then be utilized by the attacker for malicious purposes, such as:

  • Remote shell, web-based botnet, port scanning

Cross-site scripting (XSS) vulnerability has been common in web technology, but utilizing WebSockets introduces some threats that would give an attacker more power to control the victims—assuming that the user somehow visits a malicious service, or a website that has XSS vulnerability exploited, from the user agent. Once loaded in the user agent, malicious JavaScript code can be executed and the attacker can easily establish a WebSockets connection to a malicious server and create a remote shell to utilize the victims for malicious purposes: a Distributed Denial of Service (DDoS) attack (with lots of victims), access to the company’s intranet services for information, port scanning or using the victim’s user agent as a proxy, a springboard for other attacks.

  • Friendship between WebSockets and proxies, firewalls

In November 2010, a serious security issue involving WebSockets was reported. WebSockets was still not adopted widely enough, so some transparent proxies didn’t correctly understand the HTTP upgrade mechanism being used for the handshaking of WebSockets and thus can potentially allow a cache poisoning attack. Frame-masking was added to avoid that vulnerability, but in turn the frame-masking and other natural lightweight features of the protocol (lack of metadata like HTTP header, content length) challenge the virus and malware scanning tools in analyzing the data patterns to detect malicious content in a malicious usage of WebSockets channel.

The vulnerabilities are mostly not specific to WebSockets API or the protocol, but the freedom of the new data exchange model opens up more threats and more attention is needed to secure the communication. Best practices for traditional web programming should still be applied for WebSockets.

  • Maximize the validation on both client and server side against the received input. Client and server basically should not trust each other by default.
  • Maximize the use of Transport Layer Security (TLS) encryption to achieve integrity.
  • Carefully implement authentication and session management between endpoints.

When you are struggling with the trade-off between security and performance while deciding whether or not to use WebSockets, it might be a good choice to utilize a well-known solution for your particular need. One of the proposals to deploy your application that uses WebSockets is to not make it a mobile web application that runs on web browsers of the users’ mobile devices, but instead to use an alternative way—to build a hybrid mobile application and stick your client application with a proven server-side solution, for example, Node.JS (and Socket.IO, or Worlize). IBM Worklight offers you a way to easily build a hybrid mobile application (and much more). You can basically build your app in a web-based code such as JavaScript, CSS or HTML just like a web application, but the code will eventually run on top of a thin native container that utilizes the device’s webkit engine, instead of using the mobile browser itself (you need some work-around for dealing with Android though, because unfortunately WebSockets has not been widely supported in its embedded webkit engine yet).

Be well aware of the security vulnerabilities of using WebSockets. Dealing with them properly will help you to build a secure, interactive mobile application and enjoy the near real-time experience on your mobile devices in a collaborative world where time is precious and conserving resources is critical