...
An AISP must not create a Consent on a newer version, and use it on a previous version
E.g., A ConsentId for an account-access-consent created in v3, must not be used to access v2 endpoints.
2.3.1.2 GET2 GET
An AISP must not access a Consent on an older version, via the Id for a Consent created in a newer version:
E.g., An account-access-consent created in v3 accessed via v2 account-request.
An ASPSP must allow a Consent to be accessed in a newer version.
An ASPSP must ensure Permissions set associated with a Consent are unchanged when accessed in a different version:
E.g., An account-request created in v2 will have the same details when accessed via v2 and v3 (as an account-access-consent).
An ASPSP must ensure a Consent's fields are unchanged when accessed in a different version.
An ASPSP may choose to populate new fields introduced in a resource from previous version sensible defaults (if mandatory) or not populate at all (if not mandatory):
E.g., OBAccountAccessConsentResponse /Data/StatusUpdateDateTime introduced in v2 accessed with v1 AccountRequestId can be populated with Last accessed date time, if not already available in the system of records.
...
2.3.2 Account Information Resources
2.3.2.1 GET1 GET
An AISP may use a token that is bound to a Consent in a previous version, to access an endpoint of a newer version.
An AISP may use an Id for a Consent created in a previous version to retrieve Account Information resources in a newer version:
E.g., AccountRequestId from v2 can be used as ConsentId in v3, to GET /accounts.
An AISP must not use an Id for a Consent from a newer version to access Account Information resources in a previous version:
E.g., ConsentId for an account-access-consent created in v3, must not be used to access v2 Account Information endpoints.
An AISP must not use an Id for a Consent from a previous version to access a resource introduced in a newer version (as the Consent will not have Permissions required to access the new resource).
An ASPSP must allow an AISP to use an Id for a Consent from a previous version to access Account Information resource endpoints in a newer version:
E.g., AccountRequestId created in v2 must be allowed to access Account Information resource endpoints in v3.
An ASPSP must reject the request to access a resource, for which a Consent's Permissions set does not permit.
An ASPSP may choose to populate new fields introduced in a resource from previous version sensible defaults (if mandatory) or not populate at all:
E.g., OBAccountAccessConsentResponse /Data/StatusUpdateDateTime introduced in Version2 accessed with V1 AccountRequestId can be populated with Last accessed date time, if not already available in the system of records.
...
AISPs must use an authorisation code grant using a redirect or decoupled flow to obtain a token to access all other resources. In the specification, this grant type is referred to as "Authorisation Code").
3.3 Consent 3 Consent Authorisation
The AISP must create an account-access-consent resource through a POST operation. This resource indicates the consent that the AISP claims it has been given by the customer to retrieve account and transaction information. At this stage, the consent is not yet authorised as the ASPSP has not yet verified this claim with the customer.
...
Permissions: The set of data clusters that the customer has consented to allow the AISP to access..
TransactionFromDateTime: The earliest point of the transaction / statement historical period that the customer has consented to provide access to the AISP.
TransactionToDateTime: The last point of the transaction / statement historical period that the customer has consented to provide access to the AISP
3.3.1.1 Permissions1 Permissions
Permissions codes will be used to limit the data that is returned in response to a resource request.
...
If the customer has provided permission for ReadTransactionsDebits, the ASPSP must include all debits, including credit reversals
3.3.1.2 Transaction 2 Transaction To/From Date Time
The TransactionToDateTime and the TransactionFromDateTime specify the period for consented transaction and/or statement history. Both the fields are optional and one may be specified without the other.
...
An AISP and customer may have multiple consents at any point in time
3.4 Consent 4 Consent Revocation
A customer may revoke consent for accessing account information at any point in time.
...
The AISP must cease to access the APIs at that point.
The AISP must call the PATCH operation on the account-access-consent resource (before confirming consent revocation with the customer) as soon as is practically possible, to indicate to the ASPSP that the customer has revoked consent
3.5 Access 5 Access Revocation
A customer may revoke AISP's access directly with the ASPSP, via the access dashboard. In such a situation:
...
In these scenarios, only the affected account is removed from the list of selected accounts. The ASPSP must not revoke authorisation to other accounts.
3.7 Risk 7 Risk Scoring Information
Information for risk scoring and assessment will come via:
...