Key considerations

In our work on Kiva Protocol, we wrestled with a number of key issues, ranging from our technical design choices, to our ecosystem-building approach, to the ethical considerations of "do no harm" and mitigation of potential negative usage of the system. Here we summarize some of these in the hopes they might be useful to the communities of practice in which we operate.

Working with emergent technology

Incorporating emergent technology is a long-term, strategic investment that should not be taken lightly.

New technologies, particularly those that are open source and open standard, can be very attractive for different reasons, including drawing targeted funding, contributing to an innovation story, reducing certain development costs, and increasing attractiveness to customers who don’t want vendor lock-in. However, leveraging emergent tech also introduces new costs and vulnerabilities, particularly where core infrastructure has not yet been battle-tested for security, scale, and usability. Open source work can also move very slowly and requires proactive investment of staff time to participate in draft development and community calls.

Don’t waste time and resources being the solution looking for a problem.

Come back to your customer/user/stakeholders immediate needs in the context of their goals, and then work backwards to the minimum critical technologies-including emergent and open-source technologies-that will meet those needs.

Critically assess the tech in question before taking it on as a core dependency.

Take the time up front to evaluate the potential value and risks of core tech. Helpful questions to ask include:

  • Is this technology mission-critical to advancing our core value proposition?
  • What alternative options exist (if any) and what is their relative maturity?
  • Is this emergent tech necessary now or could it be a future upgrade?
  • Is this technology tested at scale with enterprise-size partners in different regions/contexts?
  • Are there examples in production for which uptime statistics and security reports are available?
  • Is this open source/standard something that differentiates the product in a critical way?
  • Where is this technology in the hype cycle?
  • How actively is this technology being contributed to by community members?
  • How diverse are those contributors?
  • Who has the power (individual or company) to significantly change or even remove access to these tools?

Use of Biometrics

Biometrics are an excellent choice for inclusion purposes

  • Biometrics are keys that individuals will always have with them, making it an extremely straightforward way of gaining access to protected systems. This can be especially important for inclusion of individuals negatively affected by the digital divide, lacking in literacy skills, or otherwise disadvantaged.
  • Biometrics are a universal source of identity. This can have significant impacts on inclusion efforts for populations which otherwise lack official identities.

Biometrics are easily abused, so their use should not be taken lightly

  • If an individual’s biometrics are stolen, they will be valid for the lifetime of that individual. Unlike passwords, you cannot easily change your fingerprints in the event of a data breach. Therefore, caution must be taken when using them as an authentication mechanism.
  • Biometrics can easily be correlated back to an individual, which is dangerous for certain populations. Therefore, caution must be taken when tying biometrics to a source of identity.

Choosing a biometric modality is a balancing act between ease of use, reliability, and purpose (do not collect what you do not need)

  • Fingerprints are widely used and accepted. Many governments already have large data sets of citizens’ fingerprints. However, the quality of those fingerprint images varies enormously. Another restriction is that capturing fingerprints typically requires a special device, which requires training to use properly.
  • Facial recognition systems have seen incredible adoption in recent years and can be used with just a smartphone camera. There is a lot of pre-packaged facial recognition software available and many researchers improving that software. However, there are legitimate concerns over racial bias in facial recognition systems, which can be especially problematic if your application aims to address sensitive topics like financial inclusion, voting rights, law enforcement, etc.
  • You should always ask yourself if you really need a biometric. As with all personally identifiable information, no more data should be collected and used than is absolutely necessary.

When possible, prefer 1:1 biometric matching over 1:n.

  • 1:1 biometric matching is simply faster and less resource-intensive. We used biometrics as a component in our authentication system such that we knew which ID the user was trying to authenticate against. We used the ID to retrieve a stored fingerprint template to match against, thus enabling 1:1 matching.
  • From an ethical standpoint, 1:n matching systems are more easily abused. If you are working with vulnerable populations (refugees, abuse victims, etc.), then this is especially important. As a point of interest, mass surveillance use cases use 1:n biometrics matching. Consider if you want your use case to be exposed to the accusation that it is being used or could be used for mass surveillance.
  • There are ways around these limitations if 1:n matching is important to you. For example, you can shard your data to reduce the search space, use indexes, and other tricks to speed up the matching process. To address ethical considerations, you might make sure your biometrics data is kept segregated from all other identity data to ensure that it can’t actually be used to identify individuals.

Data Privacy and Informed Consent

Plan to invest in data privacy as a context-dependent, living process

  • Privacy work is never “done”-it continues to evolve as risk vectors shift with new project phases, stakeholders, and regulation.
  • Dedicate time and talent to co-designing training programs with those who will be walking clients through consent agreements. This is particularly important for distilling complex ideas (for example: digital wallets, key management, data guardianship, and distributed ledgers!) into their relative benefits and risks articulated in a way that the listener can make an informed decision from.
  • Find creative ways to collect qualitative and quantitative feedback from clients, administrators, and other stakeholders during the typical workflow and use this information to inform improvements to things like staff training and consent language.

Embed data privacy accountability structures into the DNA of your governance plans.

  • All stakeholders should know exactly who is responsible for what data, how that data is protected, and how other privacy risks are mitigated.
  • Privacy impact assessments are one common output that can be referenced by internal and external parties.
  • Include data privacy as a regular part of project stakeholder check-ins, including discussion of new potential risk areas.

Find other experts and communities to advance best practices.

  • Data privacy work is increasingly pre-competitive table stakes for doing business or receiving funding for philanthropic projects. And, it is incredibly hard to get it all “right” as an organization working in a silo.
  • Take the time to join with others in data protection communities to share tools and learnings. If possible, dedicate part of a team members time to proactively engaging in this work, including sharing out your own learnings and resources for the benefit of others.

Designing for low-resource populations

Informative error messages are crucial for running pilots in locales where connectivity, bandwidth, and electricity are not guaranteed.

  • We faced unexpected issues around connectivity in remote areas and needed to ensure that eKYC works across the country reliably. Informative error messages enabled our team to react quickly to any outages or unexpected issues with the production environment. It helps to know not only exactly what the problem is, but also where the problem is coming from, physical locations of specific pieces of hardware experiencing outage, as well as the connectivity and power state of every piece of hardware in use.

Spending time on the ground in the locale where your software is being used can help to uncover unexpected issues with your design early on.

  • Confounding and unexpected factors: The Sierra Leonean civil war resulted in a situation where around 11% of the population had missing hands and would be unable to use fingerprints as an authentication method. We needed to design an alternative workflow for those individuals with missing hands to verify ID, as well to prevent our system from disadvantaging that particular subset of the population.
  • Engaging with local development teams early on to get feedback on design can be helpful, as can user testing with people from your target user base. Technical literacy can vary heavily with locale, and both technical and non-technical groups of people will have different perspectives on how a design should function.

Design with hardware costs in mind.

  • Pay special attention to cases where multiple users may share the same device. Fewer financial resources may mean that anyone – employees, customers, customer’s household members, or unknown individuals in public spaces like internet cafes - may need to share the same devices to perform tasks, so workflows should be able to accommodate easily logging into and out of accounts.
  • Fingerprint readers were far cheaper when compared to other options such as facial recognition or iris scanning. We went with fingerprinting as our biometric of choice because, while it was potentially easier to fake, it was also the only affordable option for many of the FSPs we were working with.

Design workflows for both smartphones and more basic feature phones.

  • For those who only have feature phones, USSD and SMS can be used as ID verification since the NCRA has a one-to-one mapping of fingerprint biometrics to phone numbers.

Consider providing alternative workflows that account for reading literacy.

  • Consent language in our pilot could be read out loud by a bank teller, for example, and verbal consent would be given to perform an eKYC check on a customer.

Fully digitized workflows and documents may be more efficient, but may not necessarily be perceived as more trustworthy than their non-digital counterparts by stakeholders and/or their customers.

  • Most of the financial service providers we visited in Sierra Leone were operating largely through stamped paper documentation and excel spreadsheets because both customers and bank employees were less likely to trust the integrity of a digital data store without stamped physical paper trails of banking activity. To accommodate this, we included PDF generation tools and a way to download eKYC logs into CSV files.

Gender, age, and socioeconomic level affect adoption.

  • Socioeconomic status influences access to devices and services: smartphones, internet access, etc.
  • In general, younger age groups are more open to adopting disruptive technologies.