90 Day Consent Changes

Overview

A new FCA policy has been announced that no longer requires ASPSPs (Financial Institutions) to re-authenticate users every 90 days. Instead, it will be TPPs (API Clients) that will be responsible for renewing consent every 90 days.

This initial change will devolve consent to TPP's over a phased period to Sept 2022 in line with individual ASPSP's making the change on their systems. At present this change will support re-consents for a single connection at a time. We will be making further changes in the near future to harmonise the consent journey for PSU's who have multiple connections to one or many ASPSP's to provide a more streamlined 90 day consent journey.

📘

Connections eligible for reconsent

It is expected that initially the tppConsent field will be false in most cases. This is until banks (ASPSPs) implement changes to enable long lived access for TPPs without requiring reauthentication every 90 days.

Timelines between ASPSPs will vary, but many have indicated they will be implementing these changes in September 2022.

Until this time the usual reauthentication journey can be used.

How to use the new reconsent journey

To enable this, the following changes have been made:

  1. New fields will be exposed on the Identity API GET /users/{userId}/connections endpoint

    • tppConsent - a boolean flag added to connections to indicate if they require re-consent or full re-authentication. If true, this means the TPP is required to gain consent from the user every 90 days. If false, the existing process of re-authenticating every 90 days still applies.
  2. The expiresAt field on connections can be used to identify if a connection has an expired consent. If the consent expires, connections will no longer sync and will be in credentials_error status.

  3. A new endpoint will be added to the Identity API to update the consent on a connection once consent has been gained from the user. This endpoint will only be available for those API Clients that use their own consent screens. The endpoint will be PATCH /users/{userId}/connections/{connectionId}.

  4. A new consent flow will be added for https://identity.moneyhub.co.uk/oidc/auth. There is a new scope called reconsent. If this scope is used, the consent screen that is shown will redirect back to the redirect_url of the API Client rather than the bank after gaining user consent. This will update the connection (the expiresAt date on the connection will be updated from this).

Clients with their own consent screens

  • If a connection has credentials_error status (or expiresAt is in the past) and tppConsent flag is true on a connection then the PATCH /users/{userId}/connections/{connectionId} can be used to extend the consent on the connection (after the user has been shown the consent screen.
  • This new PATCH /users/{userId}/connections/{connectionId} endpoint is only intended for clients that use external consent screens i.e. have the bypass consent option enabled.
  • POST /auth-requests can still be used for when full re-authentication is required.

Clients that use Moneyhub consent screens

  • If a connection has credentials_error status (or expiresAt is in the past) and tppConsent flag is true on a connection, this means that the reconsent scope can be used with https://identity.moneyhub.co.uk/oidc/auth to trigger a re-consent to keep the connection syncing successfully.
  • The reauth scope can also still be used as usual to fully re-authenticate the customer.

Webhooks

  • Reauth reminders will remain the same for expired connections. The only difference is that the tppConsent field has now been added to the reauth reminder event body e.g.
{
    "connectionId": "7d235ab0-e951-487f-acde-73cae1a18be0",
    "bankName": "Test Bank",
    "timeUntilReauthorizationInDays": 5,
  "tppConsent": false
}

Example use cases

Below is a diagram illustrating some examples of the following:

  • How the expiresAt and tppConsent field can be used to identify connections that require re-consent (as opposed to full re-authentication).
  • How the new update connections endpoint (PATCH /users/{userId}/connections/{connectionId}) can be used to set the new expiresAt value.