Building trustworthy fintech with consumer consent workflows

With Europe’s opening of bank functionalities and customer data via APIs, new fintech apps and products can now be connected to customers’ bank accounts. Under the European Second Payment Services Directive (PSD2) and UK Open Banking regulations, banks must make payment APIs and customer account information APIs available for use. This open banking ecosystem allows providers to innovate and create targeted apps and products that go beyond traditional bank offerings—the main motivator for these regulations.

Regulatory safeguards and security are built into the European open banking ecosystem. In the UK, banks build APIs to agreed standard templates. In Europe, banks use regulatory technical standard guidelines.  Third-party providers, such as fintech companies that make use of bank APIs, must be accredited by registering with the relevant national financial authority. If they’re providing products across Europe, they need to apply for “passporting right.” In some countries, fintech companies are encouraged or even required to use regulatory sandboxes that allow for the testing of new products and services in a controlled environment. Fintech application prototypes must gain approval from banks, who check accreditation and ensure the app is secure and meets regulatory responsibilities.

The right of consumer consent means that consent over the apps and products connected to a bank account can be removed or given at any time.

Using authentication to increase customer consent

Increasing consumer consent via authentication and authorization of personal data use is at the forefront of many banking and finance regulations. The PSD2, for example, outlines requirements that online banking providers must follow for Strong Customer Authentication (SCA). The requirements protect consumers against fraud during the authentication process and add additional security to payments. A similar regulatory requirement is set in the UK, where the Financial Conduct Authority (FCA) requires SCA adherence in these three scenarios:  

1. When an electronic payment transaction is initiated.
2. When an online payment account is accessed.
3. When any action that may imply a risk of payment fraud is carried out remotely (some exemptions apply).

The Berlin Group, composed of almost 40 European banks, associations, and payment service providers, incorporated an SCA approach into its PSD2 framework, the NextGenPSD2 XS2A, by including API access with mandatory consent endpoints. The API endpoints, used by over 1,000 banks as a template when designing APIs, establish user consent for account transactions. It also requires consent a second time, when the transaction occurs. 

In Europe, SCA regulations require two of three elements, often referred to as knowledge, possession, and inherence:

1. Something the customer knows, like a password or PIN.
2. Something the customer owns, like a mobile phone.
3. Something the customer is, like facial recognition or a thumbprint.

This authentication is essential for making payments. Additional features like dynamic linking requirements mean templated standards for what information should be shared with the customer at the point of authenticating and consenting to a payment, and ensures that a payment link can be used only once. For example, the payment amount, and the entity to which the payment will be made should be clear during the payment consent process.

Best practices to enable data sharing: Authentication and consent 

When linking a product, like a budget app to a customer’s bank account, additional consent is needed. From a customer experience perspective, customers don’t want to reconfirm linking their bank account to their budget app each time they open the app. But an app that a customer is no longer using, with continued access to the customer’s bank account data, is a liability for the customer, the bank, and the fintech company. 

Fintech apps that might regularly access a customer’s bank account data to provide their features include:

• Budget and financial management apps.
• Wealth management and trading products.
• Savings features in fintech apps.
• Business bookkeeping and Enterprise Resource Planning (ERP) software.
• Carbon calculators and Environmental Social Governance (ESG) dashboards.

There are three best practices to follow when ensuring customers fully agree to link their bank in an application. 

1. Create tiered access: Group information that a customer would need to access in the app and set restriction levels that trigger consent workflows. For example, some bank product data such as publically available interest rates, could be classified as low-risk and be displayed in your app without consent. However, data on an individual’s transaction history and expenditure patterns could be classified as higher risk and would require stronger consent processes.
    
2. Explain your intentions clearly: Consumers need to easily understand what data points an app will access from their bank accounts. Explain how you will use the data. Spell out who will have access to the data, for how long, why, and what data is involved. For example, you might have to detail that your app will calculate expenditure patterns and provide real time budget advice, which will use an individual’s personal data. Or, you might tell customers that your app will list their transaction history including all payments and transfers made, who they paid, and the transaction amounts.
    
3. Enable time limitations: In Europe and the UK, companies must reconfirm the customer’s desire to continue linking their banking accounts every 90 days. There should also be mechanisms, such as a button, that allow a customer to revoke access at any time.

What to measure in customer consent workflows

Measuring consent workflows is an excellent mechanism to monitor the customer experience of an app or product. It can also provide insights into how to communicate and build trust with app users. Fintech startups can also use data on consumer consent to advocate for better quality bank APIs that make seamless digital connections for customers.

Success rate

What it is: The number of app users who connect their bank account to an app. This metric represents the number of successful customer authorizations.
Why it's important: If your success rate is low, your consent onboarding workflow might not clearly explain how customer data will be used or protected. It could also indicate that the bank API integration isn’t performant. To start, look at whether the success rate is common for all bank integrations or if it varies by the bank. This will determine whether there’s an issue with the app or the bank integration itself.

Bank or API aggregator response and performance rates

What it is: API response rates measure how long it takes for an API call to respond. This is usually measured in the microseconds elapsed time between receiving the API request and sending the response. While performance rate measures how often APIs return error messages.
Why it's important: Slow API responses affect customer experience, leaving customers unsure about whether a transaction was successful or giving up during the consent process because an API is failing to integrate their accounts. The error rate, and type of error code, can give you insight into API design and coding issues.

Consent exit points

What it is: Exit points, or drop-off points, are the specific links at which users abandon the consent process. Each screen or process stage of a consent flow has a path link. Measuring the total number of completed consent flows divided by the number of consent processes started and multiplied by 100 will give the consent abandonment rate overall. This can then be calculated at each stage of the consent flow in order to identify which steps are most confusing or worrisome to users.
Why it's important: Tracking the exit points, and where the percentage is at its highest, can show where customer experience can be improved. If app users exit when shown text on how their data will be used, it may indicate an unclear explanation. Another possibility is that your description of data use might be too broad to gain customers’ confidence. 

Usage and activity rates

What it is: Usage and activity rates measure how often customers log in to an app or website, how long they stay, whether they open and close an app without doing anything, and what activities they carry out.
Why it's important: Customers who connect their bank accounts are more likely to make use of an app and perform more transactions within the app than those who do not integrate their bank data. Measuring activity and usage rates can provide insights that help improve customer experience and lead to opportunities to improve the current user experience or inspire new feature ideas.