Late last week I read an article on "Mobile Banker" titled "In New Mobile Model, Carriers Welcome Many Bank Partners." The article was very well written and outlined the differing opinions on the future of the mobile landscape. However, there was one topic that I'd like to discuss in further detail and that is - browser based mobile banking solutions.
For years this solution has been shunned as slow, unsecure and impossible to develop because of rendering. However, I'm here to unequivocally state that those are myths. Now, I'm not going to speculate on the source of such "tales" but I do believe that they are meant to scare bankers. After all, who benefits if a bank spends just a few bucks to develop an in-house browser solution? That's right - the banks do.
So lets take just a moment to debunk each of the rumors individually.
Security
Lets first tackle the issue of security, because after all it is priority #1. For those new to the space let me begin by clarifying that modern day browser applications are not WAP applications. In fact, you might be surprised to know that the code is actually xhtml which is a fancy way of saying, "the same code that runs your online banking solution." Now, if anyone would like to claim that online banking is not secure we can go down that path, but the discussion would likely end with the topic of Reg E, which interestingly enough, also covers all mobile banking solutions. Additionally, you should now that browser solutions are not simply built and launched. They are subject to the very same safety and security reviews as every other electronic channel and they pass with flying colors.
Speed
Next, lets analyze the speed of a browser solution against a downloadable application and an SMS solution. For this test I'll reference the videos on YouTube that show a step by step balance request utilizing two of the most successful vendors in the market. The results of the test are as follows:
Time to Conduct a Balance Inquiry
Downloadable (Firethorn) - 1:03
SMS (Clairmail) - :32 seconds
Browser (Bank of America) - :58 seconds
Rendering
The final myth is that browser applications can not render properly across the thousands of handset/carrier/browser combinations. This one is simple to refute - it's simply not true. Design for the lowest common denominator and your done.
Finally, to drive home the fact that browser based solutions are popular and are taking hold I'll reference the 276 sites on cantoni.mobi where you can sample just a fraction of the existing browser solutions on the market today.
Subscribe to:
Post Comments (Atom)
5 comments:
Interesting post Brandon but I'm not sure you can necessarily classify these as myths.
Security - Out of interest, do you have any references to back up your assertion about the security of mobile browsers?
Just as one example, take a look at Opera's own FAQ page about their Opera Mini product, their older versions of Opera Mini did not encrypt data between the browser and the Opera servers.
Aside from security I would also argue that there are several points missing from your post.
Reach - How many phones have suitably compliant browsers. The iPhone has set a standard but there are plenty of older phones out there that don't have browsers (or are bad enough to be effectively negated). You also need to combine that with a question over how many consumers have flat rate data tarrifs. A standard XHTML page will typically be a much larger download than the data required for a mobile app for example.
Cost - What is the cost associated with a mobile banking site compared to banking via SMS or application? How does this relate globally? Some regions have incredibly cheap data tarrifs but comparatively expensive SMS costs, others are the opposite. Is this an option that works globally for a bank?
Usability - Even if a phone is able to display an XHTML page, and be generally usable, there has to be a question about whether the format is the most accessible for a user. Scrolling through pages of links to get to your statement may be less preferable than having an application or SMS displaying the data in an optimised format.
I think you make some good points but I think there's a wider debate to be had here than you have suggested.
Why do you moderate comments? Why not let people speak their minds? If they are profane, you can always take the comment down. But moderating comments before allowing them to post really negates the spirit of a blog: the sharing of ideas.
If you would like to have your comments published please be sure to identify yourself.
Post a Comment