...
Register an intent to retrieve account information by creating an "account access consent". This registers the data "permissions" and historical period allowed for transactions/statements - that the user/customer has consented to provide to the AISP; and
Subsequently, retrieve account and transaction data.
...
Step 1: Request Account Information
This flow begins with a user/customer consenting to allow an AISP to access account information data.
...
The AISP connects to the ASPSP that services the user/customer’s account(s) and creates an account-access-consent resource. This informs the ASPSP that one of its user/customers is granting access to account and transaction information to an AISP. The ASPSP responds with an identifier for the resource (the ConsentId - which is the intent identifier). This step is carried out by making a POST request to / account-access-consents endpoint.
The account-access-consent resource will include these fields below - which describe the data that the user/customer has consented with the AISP:
Permissions - a list of data clusters that have been consented for access.
Transaction Validity Period [D1] [D2] - the From/To date range which specifies a historical period for transactions and statements which may be accessed by the AISP.
An AISP may be a broker for data to other parties[D3] , and so it is valid for a user/customer to have multiple account-access-consents for the same accounts, with different consent/authorisation parameters agreed.
Step 3: Authorise Consent
The AISP requests the user/customer to authorise the consent. The ASPSP may carry this out by using a redirection flow or a decoupled flow.
In a redirection flow, the AISP redirects the user/customer to the ASPSP.
The redirect includes the ConsentId generated in the previous step.
This allows the ASPSP to correlate the account-access-consent that was setup.
The ASPSP authenticates the user/customer.
The ASPSP updates the state of the account-access-consent resource internally to indicate that the account access consent has been authorised.
Once the consent has been authorised, the user/customer is redirected back to the AISP.
In a decoupled flow, the ASPSP requests the user/customer to authorise consent on an authentication device that is separate from the consumption device on which the user/customer is interacting with the AISP.
The decoupled flow is initiated by the AISP calling a back-channel authorisation request.
The request contains a 'hint' that identifies the user/customer, paired with the consent to be authorised.
The ASPSP authenticates the user/customer and updates the state of the account-access-consent resource internally to indicate that the account access consent has been authorised.
Once the consent has been authorised, the ASPSP can make a callback to the AISP to provide an access token.
The principle we have agreed is that consent is managed between the user/customer and the AISP - so the account-access-consent details must not be changed (with the ASPSP) in this step. The user/customer will only be able to authorise or reject the account-access-consent details in its entirety.
During authorisation, the user/customer selects accounts that are authorised for the AISP request (in the ASPSP's banking interface).
...
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 user/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 user/customer.
The ASPSP responds with a ConsentId. This is the intent-id that is used when initiating the authorisation code grant.
...
The ASPSP authenticates the user/customer.
The ASPSP plays back the consent (registered by the AISP) back to the user/customer - to get consent authorisation. The user/customer may accept or reject the consent in its entirety (but not selectively).
The ASPSP presents the user/customer with a list of accounts to which the consent will apply.
Once these steps are complete, the consent is considered to have been authorised by the user/customer.
3.3.1 Consent Elements
The Account Access Consent resource consists of the following fields, which together form the elements of the consent provided by the user/customer to the AISP:
Permissions: The set of data clusters that the user/customer has consented to allow the AISP to access..
TransactionFromDateTime: The earliest point of the transaction/statement historical period that the user/customer has consented to provide access to the AISP.
TransactionToDateTime: The last point of the transaction/statement historical period that the user/customer has consented to provide access to the AISP
...
Permissions | Endpoints | Business Logic | Data Cluster Description |
ReadAccountsBasic | /accounts |
| Ability to read basic account information |
ReadAccountsDetail | /accounts | Access to additional elements in the payload | Ability to read account identification details |
ReadBalances | /balances |
| Ability to read all balance information |
ReadBeneficiariesBasic | /beneficiaries |
| Ability to read basic beneficiary details |
ReadBeneficiariesDetail | /beneficiaries | Access to additional elements in the payload | Ability to read account identification details for the beneficiary |
ReadDirectDebits | /direct-debits |
| Ability to read all direct debit information |
ReadTransactionsBasic | /transactions | Permissions must also include at least one of:
| Ability to read basic transaction information |
ReadTransactionsDetail | /transactions | Access to additional elements in the payload Permissions must also include at least one of:
| Ability to read transaction data elements which may hold silent party details |
ReadTransactionsCredits | /transactions | Access to credit transactions. Permissions must also include one of:
| Ability to read only credit transactions |
ReadTransactionsDebits | /transactions | Access to debit transactions. Permissions must also include one of:
| Ability to read only debit transactions |
ReadStatementsBasic | /statements |
| Ability to read basic statement details |
ReadStatementsDetail | /statements | Access to additional elements in the payload Access to download the statement file (if the ASPSP makes this available). | Ability to read statement data elements which may leak other information about the account |
ReadProducts | /products |
| Ability to read all product information relating to the account |
ReadOffers | /offers |
| Ability to read all offer information |
ReadParty | /accounts/{AccountId}/party |
| Ability to read party information on the account owner. |
ReadPartyCustomer | /party |
| Ability to read party information on the user/customer logged in. |
ReadFutureDatedPaymentsBasic | /future-dated-payments |
| Ability to read basic statement details |
ReadFutureDatedPaymentsDetail | /future-dated-payments | Access to additional elements in the payload |
|
ReadPAN | All API endpoints where PAN is available as a structured field | Request to access to PAN in the clear | Request to access PAN in the clear across the available endpoints. If this permission code is not in the account-access-consent, the AISP will receive a masked PAN. While an AISP may request to access PAN in the clear, an ASPSP may still respond with a masked PAN if:
|
...
It is expected that transactions will be returned in the payload irrespective of whether they are reversing entries, as long as the user/customer has provided consent for that type of transaction.
If the user/customer has provided permission for ReadTransactionsCredits, the ASPSP must include all credits, including debit reversals.
If the user/customer has provided permission for ReadTransactionsDebits, the ASPSP must include all debits, including credit reversals
...
Account Access Consents are long-lived consents.
A user/customer can re-authenticate an Account Access Consent if:
...
Where there is no change in the consent parameters required, TPPs should perform a re-authentication / refresh upon the original consent using the same intent-id as before, instead of issuing a new, duplicate consent.
An AISP and user/customer may have multiple consents at any point in time
3.4 Consent Revocation
A user/customer may revoke consent for accessing account information at any point in time.
The user/customer may request the AISP to revoke consent that it has authorised. If consent is revoked with the AISP:
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 user/customer) as soon as is practically possible, to indicate to the ASPSP that the user/customer has revoked consent
3.5 Access Revocation
A user/customer may revoke AISP's access directly with the ASPSP, via the access dashboard. In such a situation:
The ASPSPs may revoke the access token provided to the AISP.
The status of the account-access-consent must remain unchanged and the AISP must be allowed to request user/customer to re-authenticate the same account-access-consent resource.
Upon successful re-authentication by user/customer, an ASPSP may issue new authorisation code and subsequently new access token to the AISP.
3.6 Changes to Selected Account(s)
The user/customer must select the accounts to which the consent should be applied at the point of consent authorisation.
...
The account being closed.
The account is barred or frozen.
The beneficial owner of the account revokes the user/customer’s mandate or power of attorney to operate the account.
...
The ASPSP does not provide historical transactions/statements for that date range.
The user/customer has not consented to transactions/statements for that date range.
...