How We Built a Mobile Banking Application
By Richard Rodger

Our company, [nearForm][1], builds complex systems. We do this for start-ups and for established companies. Sometimes, delivering even a small feature set means conquering a mountain of hidden technical and structural complexity. {.alignment9}

[Permanent TSB][2]



Permanent TSB are one of Ireland’s leading financial institutions. A bank with high-street branches, and a significant mortgage business. At the start of the project, they had a well-designed, multi-featured online presence. But this was purely desktop experience, and they needed a mobile app.

Desktop to mobile

We built and delivered the Permanent TSB mobile banking application on time and on budget. This is the story of that project. A mobile banking application has a small set of features. In fact, if you add too many extras, you make the app less usable! People just want to get their specific banking tasks completed. Look at my balance. Make a payment. View a statement. In theory, you can implement the user interface in a week or two at most, hook it up to a secure web service, and upload to the App Store.


Let’s scratch the surface. Mobile banking needs to be secure. Security is an exceptionally hard thing to get right. The technology world is full of supposedly secure systems that are relatively easy to break into. The worst kind of mistake to make is to create some sort of custom security solution. It can be done, but you’ve increased your costs tenfold. Why?


To verify that a system is secure, you need it to be built by experienced practitioners. Solid cryptography requires not only solid mathematics, but also solid implementation. You’re going to have to get independent experts to validate not only your mathematics, but also your code. The reviewers have to be independent, otherwise you will fall victim to blind spots.


The alternative is to use existing standards for secure communication. This enables you to leverage the vast body of research and testing that these system have undergone. The systems used for secure websites are definitely a good place to start. The question is, how can you use web security in the context of a mobile app?


Even when you have solved the problem of securely communicating the customers bank records to the device, you’re not done. What happens if the phone is stolen? Or if a mischievous friend or co-worker takes a screenshot? I hope you didn’t use a cache to improve performance, because that might contain sensitive data, right?


Let’s leave security aside for the moment.


A mobile banking application is a mass-market app. That means it needs to work on a wide variety of devices. It’s not good enough just to support the latest versions of the iPhone and Android. It certainly is not acceptable to require a phone update before the app can run.


The app needs to support some important platforms with lower market share. In particular, Microsoft and Blackberry. While these platforms may not be as popular, they are often used by key stakeholders, especially in the financial services industry.

blackbry wdws


Building four separate versions of the app for each platform was simply not a runner. It was not even a cost issue. The real challenge would have been to coordinate the development schedules for launch. And the security implications are simply unfeasible. Each platform would require analysis by platform experts who were also security experts. Let’s just say the Venn diagrams would make your head spin.


And there’s one more thing. A mobile web version of the app was also required. That’s not a fifth version. That’s (almost) a doubling, as the mobile browser on each platform has it’s own quirks and limitations.


Nonetheless, our brief was to support as many Permanent TSB customers as possible. The fragmentation of the mobile device market posed a huge headache for the project.


That was the front-end. On the back-end, we faced a task of similar proportions. There was no public web service interface to talk to. In fact, the central bank mainframe did not even have the full set of queries and transactions deployed to implement the desired functionality. We faced the task of integrating with new systems, as they were being built. We would need to work with the Permanent TSB technical team to bootstrap the system.


Many developers take a naïve view that integration can be solved by silver bullets. Just a define a service gateway. Define an API. Introduce a well-defined schema! This approach does not account for the fact that there is significant technical and institutional knowledge that defines the way things work, and why they work that way. That knowledge lives inside people. Systems integration is all about creating that understanding.


We found limitations on what the mainframe could do. We found concern over the additional load of existing infrastructure. Proposed integration solutions, such as a web services gateway, create knock-on institutional issues. Staffing and skills capability also informed the scope of the solution space. To address these problems, there is simply no alternative to rolling up your sleeves and spending time on the ground.


If all of these challenges are met, you still run into the issue of culture. At nearForm we work aggressively. We like to get things working right away, and then refine the solution. This works very well for startups, and, in fact, just as well for larger organizations. But you have to put it in context.


There is simply no way that a large financial institution will agree to a project with a detailed plan and costings. Projects like these are built in response to a request for proposal, which outlines the delivery requirements. There is no getting around this.


The other significant factor in the complexity of this project was the number of stakeholders. One company does not simply deliver a system of this scale and gravity alone. We worked very closely with a number of other solution providers, such as Digital Reach Group, to ensure a complete delivery. The importance of creating a shared sense of the project vision, and of working collaboratively with multiple stakeholders requires an acceptance that flexibility for other approaches, and reasoned advocacy for one’s own, is essential to project health.


Every once in a while, one may read of a corporate sponsor that stuck their head out, ran with a fully agile project, and was victorious. You do not read about the projects that failed. The reality is that forward planning is an essential element of large organizational culture.


We address this by embedding agile into the traditional project structure. The primary benefits of agile can still be retained, despite the rigidity of the project schedule. We have written before about weekly demonstrations. This is at the heart of the way we work. We do not wait until the project or app is pristine to show it to senior stakeholders. We are up-front about in-progress delivery. The result is a feeling of empowerment. For Permanent TSB, they were able to guide the project as new information and feedback arrived.


As a result of the traditional project management approach we faced another challenge. How to ensure that the resulting app was user-friendly. We need to ensure that users could actually achieve the tasks desired. Normally, in a fully agile project, we ensure that this happens as part of the development process, with usability testing feeding back into the weekly demonstrations. In this project, this would not be possible – we would need to find a way to ensure a usable app before development began.

Mobile banking application

Delivering the App.

Overcoming these challenges of this project was something that grew our company, both professionally and our internal culture. Here’s what we did.

Many developers treat security as an obstruction to completing the project. We stepped back and tried to see the big picture. This would either be a great project for us, or a total disaster if there was a security breach. In other words, if the security implementation made the project late, so be it. We would be advocates for a secure solution.


This changed the dynamic of our relationship with the internal security team. We collaborated to identify the best option. In the end we opted to use the standard technologies for secure websites. This meant we would be leveraging the huge industry investment in these technologies. It avoided the need to build a custom communications channel back to the bank.

What was the practical result of this decision?

It meant that we decided to deliver the functional banking pages as HTML5, direct from the bank’s own website. These pages could the be displayed using an embedded browser inside the main application. From a security perspective, this has many advantages. Any ongoing audits or security reviews of the existing web infrastructure would encompass the app as well. Improvements or fixes offered by Apple, Google, and other device vendors would be applicable to the solution without requiring application-specific updates. The security infrastructure would also be verifiably secure, with no hidden custom components.


The use of HTML5 is something rather close to our hearts. We’ve written books taking the position that HTML5 is the future of user interfaces. It is a happy congruence that the chosen security solution also aligns with the challenge of delivering a cross-platform app.


The beauty of HTML5 is that, if you are careful, you only need to develop the app once. All the major app platforms can display HTML5 to a level sufficient for banking applications. Three-dimensional animations and sound effects are most definitely not required. Nor are outlandish user interface experiments. The application must be suitable for a mass audience, many of whom use only a limited set of apps.


There was an additional win in this decision. The same codebase that powers the downloadable (“native”) applications, can also be used for the mobile web version of the banking application. This means that customers with Microsoft or Blackberry devices can also use the app.


Despite these advantages, HTML5 does not entirely remove all cross-platform considerations. There is still a wide degree of variation. Often, we find that customers may initially require support “for all platforms”. While an admirable goal, the cost implications are expensive. As with all things technical, there are trade-offs. Our approach is to be data-driven.


We help the customer understand the device distribution of their user-base in terms of platforms and versions, and the future likely movements of the segments. They can then make an informed decision as to the coverage goal, whether this be 95% or 99%.


Even this is insufficient for practical use. In a real project, actual devices must be chosen for development and testing. We therefore recommend the selection of a specific set of exact hardware, designed to meet the coverage goal to the greatest extent possible. This means that the customer does not spend an inordinate amount of time testing on devices and platform versions with very low usage numbers.


There is one important exception to this rule. We also find out what device your CEO is using, and make sure to support that exact one!


The integration of the application into Permanent TSB’s existing infrastructure could not wait for the role out of an enterprise-wide gateway solution. We therefore took the time to understand the actual topology of the system we were dealing with, and spent a good deal of time exploring the best approaches within the constraints of the present environment. This is not a technical problem, and there are no technical solutions as such. It is about making the commitment to work with multiple internal stakeholders, across teams.


There can be very severe critical paths in any project. In this case, the updates to the mainframe system needed many months of lead-time. They would be long in production by the time the app was ready to talk to the intermediate systems. The project therefore required an intense technical engagement right from the very start. Our investment in communication during the requirements phase enabled our respective teams to work together effectively.


Finally to address the challenge of building a truly usable app, we brought in Dr. Mikael Fernström of the University of Limerick Interaction Design Centre. This was a key success factor in the entire project. To address the requirements of the project structure, we needed to move the “agility” to the requirements phase, so that once development began, we could ensure that the delivery would be made on time.


Dr. Fernström’s approach is to produce design prototypes in multiple media. This includes paper, software, and hardware. These prototypes are used in interactive design sessions with user groups. This means that real users are exposed to the app concepts before code is committed to production. The approach is far more successful a predicting high usability than the more traditional “wireframes” approach. It is also data-driven, which avoids needless discussion of inconsequential elements.


The outputs from the usability analysis allowed us to have a very high degree of confidence in the final designs, and we saw a much reduced level of tweaks and changes in the later stages of the project.


The Permanent TSB project made us grow as a company. It also gave us confidence that our convictions are correct, that our project philosophy works. As we grow the company, this project is a reference for new employees, part of our history. We are proud to have built this app.

[1]: [2]:

New Call-to-action
join the discussion