Customers Want Data Protection: How Can Open API Providers Deliver?

Most of us have signed up for a digital service and been asked to agree to terms and conditions. Even on nonsmart phones, USSD menus ask us to consent to terms before we can access the service we want. If you’re a digital financial services (DFS) provider opening up APIs, your customers probably don’t understand what data or account services they are giving third parties permission to access when they click “accept.” And if this is the case, there are some measures you can and should take to make this easier for your customers to understand.

The notion of consent is the foundation of data privacy and protection around the world and the reason we see so many terms and conditions. According to the Euro Banking Association, consent includes the right of customers “to allow authorised third parties to access their personal and business information.” When a DFS provider opens APIs, it is required to get customers’ consent to share access to their accounts and data with third parties. But this is often a confusing process, with consumers unsure of what they are agreeing to and therefore not providing consent in a meaningful way. It can be especially confusing when a DFS provider shares data via APIs with multiple third parties.

The consent workflow as it is now offered is broken. As our colleague David Medine explains in a recent episode of CGAP's Financial Inclusion Frontiers podcast, what ultimately is needed is a new model that shifts more responsibility for data privacy and protection from consumers to DFS providers. However, this isn’t likely to happen overnight. In the meantime, DFS providers need to take responsibility for creating a clearer consent experience. There is also a business reason to improve consent. CGAP research in India and Kenya has shown that clear and strong data protection policies can give providers a competitive edge and that customers are willing to pay more for services with data privacy features. In fact, low-income customers in Nairobi were even willing to pay double for loans with such features.

The typical USSD consent interface encapsulates the shortcomings of the consent system. Generally, there is no easily available information on the type of data or account access customers are agreeing to, how it will be used and for how long, or the process to revoke access. Requiring customers to consult a website is not a practical way to convey this information.

Here are a few best practices that can help DFS providers create more meaningful customer experiences with consent forms.

Create tiered access to consumer data

Regulators like the Mexican government and the UK Open Banking Authority suggest DFS providers establish multiple security and access levels for the data they are sharing with third parties. Tiered access allows DFS providers to put customers in control of their data and accounts while minimizing inconvenience to the customer.

For example, data about a DFS provider’s financial products, agent and branch locations and exchange rates may be grouped as a low-risk security tier that does not even require consent from customers because personal data are not exposed. At a higher risk level, customer transaction information — which a third party might want to access for credit scoring or a range of other applications — requires a more detailed consent workflow. For instance, customers could choose to provide consent for a period of time but retain the ability to revoke access.

An even higher level may be required when third parties are expected to initiate payments, transfer savings to other accounts or conduct similar activities. As per our recent guidance note on legal terms and conditions for open APIs, DFS providers may require customer consent before any payment can be initiated.

Provide clarity of purpose

DFS providers should include a legitimate purposes test in their partnership agreements so that they know how third parties will use their customer data and that such uses will be limited to what consumers would reasonably expect given the type of product or service being offered. Later, customers need to be informed of these legitimate purposes through clear, concise information screens, rather than an opaque, potentially all-encompassing, terms and conditions agreement. According to API management provider WSO2, “Consumers must be made aware of who they are granting access to their data, for what period of time, for what purpose, and for which specific data.”

Instate time constraints

Customers should be able to revoke their consent at any time. Tech companies like Google display all the consent agreements a customer has agreed to in his or her account dashboard. The customer can click a “revoke access” button at any time. Other approaches suggest that consent should not be open-ended but instead include an expiration date, at which time customers are reminded and asked to reconfirm they wish to continue sharing their DFS data or account functionality with third parties.

Example of consent in action

User experience site Scott Logic describes a variety of consent models used in open banking. One of the clearest consent processes is offered by UK challenger bank Starling Bank in its partnership with Yolt, a financial management app that connects a customer’s financial accounts and helps them budget and set savings goals.

Starling Bank’s open APIs enable Yolt to connect to customers’ bank accounts. When a Starling Bank customer seeks to link their bank account to Yolt via the company’s app, the app redirects them to the Starling Bank consent workflow. At this stage, Starling Bank clearly explains to the customer what data and level of account access they will be sharing with Yolt, and the customer must authorize an agreement. The customer can revoke access at any time through the Starling Bank app.

While Starling Bank exemplifies some best practices, improvements could still be made. First, customers would benefit from a clearer description of how Yolt will use their information beyond “in order for its integration with Starling to work.” Second, consent could be time-bound. Customers could be reminded of the consent agreement, perhaps every 6-12 months, to ensure they understand what data and account access they are sharing. This would help ensure they do not allow a collection of unused apps to access their bank records.

While it may be easier to offer a high-quality customer experience on a smartphone display, there is no reason why similar ground rules can’t be clearly explained in a USSD consent agreement menu.

As DFS providers increasingly open APIs so that third parties can offer shared customers new services, there is a need to be clear about what these partnerships will mean for the end-customer. Ideally, policy makers will work with providers to build modern data protection and privacy regimes that are fit for the future. In the meantime, improving consent workflows is a way for DFS providers to indicate to their customers that they are integrating and opening their data to third parties.