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
Status UNKNOWN
: This is just the enumeration's default.
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 theEXPIRED
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.
Note: Re-authorisation is only supported for flows that are redirect-based but not ones that are embedded. See Account Authorisation Flows and Payment Authorisation Flows for more information.
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.