Tag Archives: API

Is Privacy Our Sole Concern With Contact Tracing Technology?

This week the Guardian reported an alleged ‘standoff’ between the NHSX (the digital innovation arm of the NHS) and tech giants Google and Apple regarding the deployment of contact tracing technology aimed at curbing the spread of the Covid-19 virus. The debate is on two predominant issues; first, the base technology to be used and second, how the data will be stored.

Sidestepping the first issue which sees Google and Apple aiming to implement their feature directly on a device’s operating system while the NHSX version requires a downloadable dedicated application, this article will focus on the issue of privacy arising from the second issue.

In essence, Apple and Google have insisted that if there is to be any collaboration between the NHSX and them for the purposes of contact tracing the storage of all data will have to be decentralised. The NHSX, on the other hand, is pushing for centralised storage of data.

What’s the difference?

Before deciding on one system or another, it’s best to understand the basics of the distinction between these systems.

A centralised system has a single storage point and controller of the data collected. The central controller of the data may grant access to other users but remains ultimately responsible for the system as a whole. A centralized system is relatively easy to set up and can be developed quickly. Such a system is very useful where continuous modifications to the parameters of the system are expected or where the use of the data needs to be adapted for different purposes.

In contrast, a decentralised system has multiple controllers of data all of whom collect and store copies of the data on their respective systems. This system allows for quicker access to data and less risk of downtime as a fault with one controller will not necessarily affect the others.

The third form known as a distributed system in which there is no single central owner at all and instead gives collective ownership and control to each user on the network is unlikely to be used by either party.

Each system has its advantages and disadvantages and to make a decision between a centralised and a decentralised system the NHS and the tech giants will need to take into consideration a range of issues including:-

  1. The overall effectiveness of the technology;
  2. The adaptability of the system to the shifting demands of research;
  3. The cost of deployment and maintenance;
  4. Whether or not the system is a security risk for the user;
  5. Whether there are compliance concerns.

Why is a decentralised system so important?

Google and Apple have been clear that the reason for a proposed decentralised system is to avoid the risk of mass government surveillance presently or in the future. This is a genuine concern as the data being collected will be directly related to a user’s location and medical history. Although not absent from criticism, this position is the preferred option and has been supported by academics and numerous civil rights groups including the Electronic Frontier Foundation and the American Civil Liberties Union. 

Still, the European position is split with the seven governments supporting the project known as the Pan-European Privacy-Preserving Proximity Tracing (PEPP-PT) which proposes a centralised repository of data and a growing following for the Decentralised Privacy-Preserving Proximity Tracing (DP-3T) advocating a decentralised system.

The NHS itself may not be intent on surveillance however being publicly funded draws immediate speculation to its government links. In addition, both the NHS and the UK government have had a poor record of handling large scale IT projects such as the failed £11bn National Programme for IT, scrapped in 2011 and the plans for a paperless NHS by 2018 which could not even take off.

What about the NHS position?

Unfortunately, the focus on privacy risks coupled with the NHS’s bad track record in the field of technology projects have detracted from the core issue at hand – What does the NHS need right now to curb the spread of the Covid-19 virus?

Ross Anderson, an advisor to the NHS on its contact tracing application highlighted the problem with a decentralised system:-

…on the systems front, decentralised systems are all very nice in theory but are a complete pain in practice as they’re too hard to update. We’re still using Internet infrastructure from 30 years ago (BGP, DNS, SMTP…) because it’s just too hard to change… Relying on cryptography tends to make things even more complex, fragile and hard to change. In the pandemic, the public health folks may have to tweak all sorts of parameters weekly or even daily. You can’t do that with apps on 169 different types of phone and with peer-to-peer communications.

(https://www.lightbluetouchpaper.org/2020/04/12/contact-tracing-in-the-real-world/)

The Covid-19 virus took approximately 2 months to infect 100,000 UK residents and the spread has shown few signs of a slowing infection rate. Time is critical in this situation and correspondingly, flexibility in adapting to the constantly changing nature of the infection is a necessity. Decentralised systems do not allow for rapid evolution.

In addition, we should consider that unlike centralised systems, decentralised systems are often unencrypted. While trying to prevent a government from carrying out surveillance, the Google and Apple system may inadvertently open itself up to more security problems than expected. In fact, they have themselves admitted this risk stating that nothing is “unhackable”.     

As a second consideration, the API that Google and Apple will release will likely have strict limitations on the type of data that may be collected. For example, the NHS would not be able to gather a list of every person a user has been in contact with based on user proximity. Instead, it will utilise a more manual version of contact tracing involving sending every phone in the system a list of other phones that have been reported as contagious, and asking the user whether they have “seen this user” Such a system relies heavily on user verification which is often incorrect or simply disregarded.

Key location data which may be used for developing population flow maps and anticipating the further spread of the virus will likely not be made available under Google and Apple’s current proposal. It is also important to note that data from contact tracing could be used beyond the scope of curbing the spread of the virus i.e. for decisions on directing the flow of emergency aid, development of temporary healthcare facilities, deployment of healthcare equipment and personnel.   

What has been going on elsewhere?

Contrasting the UK’s situation, the Asian experience, having less stringent data protection regulations, have taken remarkably different approaches to Europe in general.

Hong Kong, for example, introduced the mandatory use of an electronic wristband connected to a smartphone application to enforce quarantine for arrivals from overseas. Users refusing to adopt this requirement are refused entry into the country.

South Korea won praise for both tracking and publishing data relating to affected person’s travel routes and affected areas, the data being collected through the government’s application as well as numerous independent applications. Residents also receive numerous location-based emergency messages and are not allowed to opt-out of this function.

China’s measures, which have come under considerable question, see a private entity collaboration through the Alipay Health Code. Citizens are given a ‘traffic light’ status that determines the restrictions that will be imposed on them. Although the exact basis for determining a person’s status is not known the status has widespread application including restriction of access to certain public facilities and payment systems.

Privacy concerns of these measures aside, all these countries have seen a considerable reduction in the spread of the Covid-19 virus. While it would be premature to suggest that this is solely attributable to the contact tracing measures implemented there is no doubt that the quick and extensive deployment of the technology has contributed to the battle against the virus’ spread which begs the question:

Is privacy getting in the way?

In 1890, Brandais and Wallace, pioneers of modern day privacy wrote:-

…To determine in advance of experience the exact line at which the dignity and convenience of the individual must yield to the demands of the public welfare or of private justice would be a difficult task…

The UK and indeed Europe are at this juncture and need to decide on the cost of the compromise as the death toll and infection rate continue to increase. History reminds us that the greatest privacy and surveillance violations occurred when the world was focused on a raging war and in fact it is times like this that we must be most vigilant about rights.    

Boosting Banks’ Customer Experience with Operational Efficiency

The way banking is being conducted around the world is changing, especially with customers who are always connected through mobile phones and with 5G not far away in many places.

Coupling that with the rising levels of wage growth entrepreneurship and government policies for financial inclusion, banking’s traditional customer journeys and distribution models won’t scale nor reach the average consumer, and will be significantly cost-prohibitive for the average bank to service. The idea that a consumer needs to visit a branch doesn’t even come into their equation.

Moreover, the consumption of banking products from FinTechs, including unsecured lending, peer-to-peer payments, merchant payments, and business credit, is on the rise. Providers like Ascend Money and Rakuten are fast, simple and digital-first. Simply put, they engender customer satisfaction.  

To catch up with those competitors, many banks have embarked on digital transformation in an effort to transform their customer experiences. However, while many banks have — to some degree — a maturing “front end”, their middle and back offices are often made up of fragile and inflexible applications and data systems. Since such systems limit the bank’s ability to scale and adapt to change quickly, it prevents the front office from running efficiently, which in turn hinders banks from delivering innovative customer journeys.

Furthermore, as net interest margins will likely stay very slim, the continual pressure to make these middle and back-office systems operationally efficient is becoming a higher priority in CFO’s targets.

What are we seeing in the middle and back office in banking?

The prioritization to modernize the back-office applications, databases, and platforms in order to be agile can help re-engineer the customer journey and lower business as usual operations and change management costs. To achieve that, banks need to focus on the following areas:

  • IT infrastructure modernization, as most banks are still running on legacy IT systems that were deployed in silos. With business functions isolated from one another, it can be difficult for banks to deliver a seamless and consistent customer experience across various channels and services.
  • Digital process-driven application modernization. Many banking processes still rely heavily on manual or clunky processes to ensure compliance with policies and historic procedures. Credit adjustments, credit disputes, loan approvals, case management, fraud event management, for example, require human reviews and hand-written approval signatures. When coupled with KYC (know your customer) as a principal operating model, integrating this into manual or clunky processes is a must-have for improving customer experience.  

The keys to improving operational efficiency

Taking the application and infrastructure design lessons learnt from the digital front-end services — such as being API-oriented, able to be deployed on a Linux container architecture, can scale horizontally, and have updates delivered rapidly through a microservice architecture — and applying them to the middle and back-office systems can help deliver the desired operational efficiencies.

Most banks, however, have decades of IP, rules, and processes hardcoded deep into the system, or have multiple clunky expensive business process management middleware workflow tools, each with their own proprietary extensions and interfaces. As such, modernization can be a difficult task, especially when they don’t know where to start.

Examples of success

BBVA — which operates in 30 countries with their associated regulatory jurisdictions and serves more than 72 million customers — was one bank that faced legacy issues. The bank managed to overcome these by modernizing the middle office business process and rules centric applications to be API first, easily extendable, globally reusable with consistent developer experience, scalable, container-based and open.

Capital One undertook a similar exercise with its middle office systems. Since the bank was initially using multiple case management process tools (each with their own interfaces, runtimes and toolsets), it decided to standardize and simplify its case management processes to improve its operations. By implementing an open source, API-oriented, easily scalable, and changeable case management and process management layer, Capital One managed to speed up delivery and drive down costs.

Speaking of APIs, these have typically been utilized as a software design principle for digital front ends in banking. However, having middle and back-office systems and data with an API layer across these can drive much greater operational efficiency. With customer journeys or compliance services increasingly demanding back-office systems to be integrated, what better way of connecting those systems than to leverage APIs?

The trick to doing so successfully is to design and modernize middle and back-office applications with useable and scalable APIs to integrate the digital and front office systems of engagement with.

Moreover, as these applications and databases become updated with APIs as integration points, the use of microservices can be important in improving transactional and operational efficiency. This relates to the lowering of IT infrastructure costs and driving down the cost of IT delivery year on year.

As applications are modernized with APIs and a microservice application architecture, they are often deployed on Linux containers. For the product and customer support managers in the bank looking for ways to make constant variations to their systems — either to improve the back-office process, enhance a customer experience or meet compliance — having these systems running as small componentized microservices gives their IT team the ability to roll out updates to their system without taking down the entire application. This can give the bank a higher degree of agility, while helping to save cost because it can take significantly less time and fewer people to release an update.

All in all, providing exceptional customer experiences may call for banks to transform their digital experiences beyond impressive user interfaces. APIs, microservices, and other open source solutions can help with back-end processes that are highly integrated and streamlined. With more efficient back-office operations, banks around the world will be better prepared to provide the seamless user experience that customers expect.