Financial Data Consents

Learn more about how to manage consents when retrieving financial data from a user's bank.

The Consent Status value that will be seen for an AIS related consent will depend on

• The type of authorisation required (dependent on the Institution and PSU) during the authorisation flow - e.g. Redirect, Decoupled or Embedded
• The success or failure of the authorisation process
• Actions that are performed by TPP, Instituion or PSU after an AUTHORIZED state has been reached

Status Transitions

Revoked Consents

At any point in time, the user can revoke their consent directly in the Institution which will make the consent token unusable within Yapily.

In this case, the Consent status may still display as AUTHORIZED but will return 403 Forbidden errors when you attempt to use it to obtain financial data.

To resolve, you will need to create a new consent using the appropriate authorisation endpoint.

Re-Authorisation

A re-authorisation can be requested for a consent using Re-authorise Account Authorisation

This is typically to be used when:

• A consent-related failure keeps occurring (e.g. 401 status code) despite it being in AUTHORIZED state
• Enable a greater history of financial transactions to be retrieved (i.e. when a bank limits these to the first 5 minutes after consent creation)
• To increase the duration of the consent prior to it expiring while maintaining the original feature scope requested. By default, an AIS consent-token is valid for up to 90 days before requiring secure customer authentication (SCA) from the user again
• To re-authorise a Consent in the EXPIRED status.

If re-authorisation executes successfully, the consent-id and the consent-token remain unchanged which will allow you to avoid having to update any references to a Consent you store for a user. When this occurs, the status of the Consent will be AWAITING_RE_AUTHORIZATION. In the event that the re-authorisation fails, the status will remain unchanged.

Limited Access

Different Institutions can enforce their own restrictions on some endpoints when obtaining financial data. The main example of this is when requesting transactional data using GET Transactions where the request is for historical data (older than 90 days). We have seen Institutions limit the time you can request historical data for as little as five minutes from when the authorisation was made. While you will still be able to use the consent-token to access current data, your requests for historical data will be rejected. Yapily recommends that if you need historical data, that you retrieve it and store it within the first five minutes of obtaining the consent-token.

Deleting Consents

Yapily also provides the means to delete a Consent from the api using DELETE Consent. By default, this will attempt to delete the Consent both in the Yapily system and from the Institution. If this is not supported by the Institution, the Consent will only be deleted from the Yapily system.