QoE Certification for Banking Services? Not Such a Bad Idea After All…

Says Tim Cruddas Spirent Communications

Dear CEO
We regret to inform you that your bank has failed its yearly MOT test on the following counts:

• Speed and continuity of Internet banking
• Slow and opaque telephone call handling system
• Excessive delay in cash transfers and bill payment

For full details see the attached report. You have three months to reapply before your bank’s certificate will be withdrawn…

Oh what a lovely fantasy for anyone fuming over poor banking service! But is it really such a crazy idea?

Banks have come under the legislative, and the criminal, spotlight in a big way recently. The economic failure of 2008 did much to tarnish the sector’s image in the eyes of the public, and since then there have been more new stories – like the recent “computer problems” afflicting RBS accounts – serving to whip up further public displeasure, rather than refresh the finance sector’s odour of sanctity.

There is much talk about “regulation” of the sort that would please, or displease, economic theorists, but not so much about regulating the actual quality of service delivered to the public.

Let’s face it, Internet banking is an enormous convenience, and one most people choose to rely on. But the trouble with a mostly reliable service is always the same: it catches you out on the few occasions when it fails. The bills you are paying just before you go on holiday, the cash transfer from savings you need to make sure a standing order does not bounce… but when the bank’s website “regrets that the system is temporarily out of order” it brings a chill of utter helplessness to the unhappy customer.

You cannot expect anyone to actually like an automatic telephone call directing service. But I do remember the first time a credit card company’s helpline – after the usual blurb about “unusually high call numbers” – asked me to put down the phone and wait for a call-back, instead of hanging on for aeons of muzak, I felt so utterly grateful. With today’s technology, there has to be better ways to handle telephone enquiries.

Then there is the time taken to clear payments (and whether that leaves a black mark on the credit agency score), the time to deliver statements, process a loan, the reliability of ATM machines… and so on. Most customers would welcome legislation that required banks to guarantee a certain basic level of service, below which the customer would have a right to complain or expect recompense.

Of course the customers would welcome this, but is it practicable?

It would mean running standardized tests on an extremely complex and diverse set of systems. The entire networked banking operation has to handle its own internal management processes, financial operations, VoIP and other internal and external communications, Internet access to its websites, security, government legislative conformance and so on. To meet these challenges, today’s networks are increasingly “application aware”, with the added complexity of intelligence distributed across next generation firewalls, Unified Threat Management (UTM) systems, Intrusion Prevention or Detection Systems (IPS/IDS), web and Email gateways, QoS-shaping edge routers, policy routers, mobile packet gateways, Deep Packet Inspection (DPI) engines and application delivery controllers.

How can we possibly guarantee a percentage of Internet portal uptime in the face of so many conflicting calls on the network – not to mention the constant pressure of cyber attacks and criminal intervention – in what is in any case a dynamic virtual system?

It is not easy – but necessity is the mother of invention. If the MOT test for motor vehicles did not exist, it would equally be dismissed as an impractical idea. How can you expect motor service staff all around the country to be able to run consistent, reliable tests on today’s sophisticated electronic vehicle management systems? How many mechanics have the necessary background in chemical analysis to understand, let alone measure, vehicle emissions? The answer is that the motor industry now has standardized machines that not only perform the relevant tests, but also enable them to be operated consistently and reliably throughout Britain by relatively low-skilled staff.

Perhaps surprisingly, the same is now true for testing even the most complex application-aware ICT networks. Here the challenge is to achieve three things reliably and consistently:

• Accurate modeling of real life traffic
• Rapid adaptation of tests to match new applications, traffic protocols and cyber attacks
• Flexibility and simplicity in the actual test process

Accurate modeling means you need a tool that not only recreates real world application traffic but also maintains a realistic application state – ie taking account of cookies, session IDs, NAT translations, authentication challenges etc. The test tool itself must behave exactly like a real client in the face of traffic congestion, and it must be designed for repeatable testing, not just maximal throughput.

Rapid response to new applications, traffic scenarios and cyber attacks means having access to a massive library of ready-to-run tests that are constantly updated to keep ahead of technological, behavior and criminal developments. But you also need a test tools offering complete visibility into transactions, field types, payload and content for fast debugging and validation of test cases. A single, unified solution that covers performance, security and functional testing also saves time translating and duplicating between tests.

For even greater resiliency in a world of fast evolving applications and user behavior, there is so-called “fuzz testing” that takes account of unpredictable divergences from what is normal. Very few test tools support this, and those that do often rely on random “bit flipping” and flooding of malformed packets – a rudimentary form of fuzzing, that does not build comprehensive fuzz test cases. More sophisticated fuzz testing technology is needed to provide confidence in the foggy, shifting cloud environment.

Finally, test tool must have a simple and flexible user interface to make it easy to upgrade, fine tune and customize tests for every need. Many tools are too inflexible, forcing testers to rely on test vendors to develop custom tests. More complicated and labour-intensive setup, adjustment and reporting, increases the risk of testing being postponed or sidelined in favour of higher-profile business demands.

In short, MOT testing a bank’s service delivery would require a unified scale, security and functional testing solution that can recreate any application, any protocol, at any time. It would need also to be the quickest, simplest solution to optimize test coverage, accelerate its test cycles and accurately recreate the many traffic, attack and fault situations that could arise..

It’ sounds like a tall order, but the industry’s leading test specialists are staying ahead of these new developments, and test tools – linked to continually updating Cloud databases of test cases and malware attack – are now available that meet these exacting criteria.

The government is demanding greater control of our wayward financial institutions, but is the proposed legislation focused on better and more consistent service delivery?

But why need we legislate for this? If any bank offered me the sort of service guarantees suggested, then I would beat a path to their door. In a competitive financial environment, is it not in the bank’s own interest to run these tests and to differentiate themselves by offering service guarantees?

It isn’t really about MOT testing, but rather about a marketing and brand building opportunity.