What is AIS
An ‘account information service’ is an online service which provides consolidated information on payment accounts held by a payment service user with payment service providers. This will ensure that account information service providers (AISPs) can receive access to payment accounts, whilst also placing requirements on them to ensure security for users.
API endpoints
| Link | Resource | Endpoints |
|---|---|---|
| Account Access Consent | account-access-consents | POST /consents |
| Accounts | accounts | GET /accounts GET /accounts/{account-id} |
| Balances | balances | GET /accounts/{account-id}/balances |
| Transactions | transactions | GET /accounts/{account-id}/transactions |
How does it work?
KBC/CBC has decided to develop its APIs according to the Berlin standards. Terminology used is therefore via this standard.
- The process begins with a PSU consenting to an AISP accessing their account information
- The AISP connects to KBC/CBC’s API Gateway and creates an account-access-consent resource
- This informs KBC/CBC that one of our PSUs is granting access to account and/or transaction information to an AISP
- KBC/CBC responds with an identifier for the resource, ConsentId - 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 the fields below:
- Permissions - a list of data clusters that have been consented for access
- Expiration Date - date when the AISP will no longer have access to the PSU's data
- Transaction Validity Period - 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. And so it is valid for a PSU to have multiple account-access-consents for the same accounts, with different consent/authorisation parameters agreed
- The AISP requests the PSU to give its consent to authorise the AISP to deliver services enabling access to account information and to access this information for the designated payment accounts and associated payment transactions
- The AISP redirects the PSU to the ASPSP
- The redirect includes the ConsentId generated in the previous step
- This allows the ASPSP to identify the account-access-consent that was setup
- The ASPSP authenticates the PSU
- 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 PSU is redirected back to the AISP
- The principle is that consent is managed between the PSU and the AISP - the account-access-consent details must not be changed in this step.
- The PSU will only be able to authorise or reject the account-access-consent details in its entirety
- During authorisation, the PSU selects the accounts that will be authorised in the AISP request. This is done in the ASPSP's banking interface
- This is carried out by making a GET request the relevant resource
- The unique account-id(s) that are valid for the consent will be returned with a call to GET /accounts
- This will always be the first call once an AISP has a valid access token