The base URL for all AIS APIs is: https://rs1.openbanking.saltgb.com/open-banking/v3.1/aisp/**
Salt Bank supports the following Berlin Group v1.3.12 account information consent and resource request endpoints.
| Resource | Endpoint Path |
|---|---|
| Consent | POST /v1/consents |
| Consent | GET /v1/consents/{consentId} |
| Consent | DELETE /v1/consents/{consentId} |
| Consent | GET /v1/consents/{consentId}/status |
| Account Detail | GET /v1/accounts |
| Account Detail | GET /v1/accounts/{account-id} |
| Account Balances | GET /v1/accounts/{account-id}/balances |
| Account Transactions | GET /v1/accounts/{account-id}/transactions |
| Account Transactions | GET /v1/accounts/{account-id}/transactions/{transactionId} |
[1] The optionality elements relating to the POST /v1/consents endpoint allow the Salt Bank to accept:
| Service | Supported |
|---|---|
| Consent Model - Dedicated Accounts | ✔ |
| Consent Model - Bank Offered Consent | ✔ |
| Consent Model - Global Consent | ✔ |
| Combined AIS & PIS consents | ✖ |
| Support of Signing Baskets | ✖ |
| Support of Multilevel SCA Approach | ✖ |
| SCA Validity for a current consent | 180 days |
| SCA Validity for a one-off consent | 10 mins |
| Maximum Frequency Per Day Value on Consent Request | 4 |
| PKCE OAuth 2.0 flow | ✔ |
| Service | Supported |
|---|---|
| IBAN | ✔ |
| BBAN | ✖ |
| PAN | ✖ |
| MaskedPan | ✖ |
| MSISDN | ✖ |
| Other | ✖ |
As permitted under the Berlin Group XSA2 API Salt Bank has implemented OAuth2 as the authorisation of the PSU towards the TPP for the account information service. In this case, the TPP will be the client, the PSU the resource owner and the ASPSP will be the resource server in the abstract OAuth2 model.
The OAuth2 SCA Approach will be used for authorisation of account information consent and will be integrated by using the following core steps:
| Attribute | Description |
|---|---|
| response_type | Must be code as only the Authorization Code Flow is supported |
| client_id | ‘organizationIdentifier’ as provided in the eIDAS certificate |
| scope | Must be AIS:<consentId> The Consent ID will be provided in the Consent response |
| state | A dynamical value set by the TPP and used to prevent XSRF attacks. |
| redirect_uri | The URI of the TPP where the OAuth2 server is redirecting the PSU's user agent after the authorization. |
| code_challenge | PKCE challenge according to cryptographic RFC 7636 used to prevent code injection attacks. |
| code_challenge_method | S256 must be provided and used |
| Attribute | Description |
|---|---|
| Location: | This will be redirect URI of the TPP |
| code | The Authorization code to exchange for an access token as part of Step 6 |
| state | Same value provided in the Authorization request must be returned |
| Attribute | Description |
|---|---|
| grant_type | Must be "authorization_code" |
| client_id | organizationIdentifier as provided in the eIDAS certificate |
| code | Authorisation code from the authorisation response |
| redirect_uri | The exact uri of the TPP where the OAuth2 server redirected the user agent to for this particular transaction. |
| code_verifier | PKCE verifier according to cryptographic RFC 7636 used to prevent code injection attacks. |
The Token response will provide an Access Token and where applicable a Refresh Token, which can be utilised to obtain a fresh access token when the access token has expired
The access token returned can then be used to access the /accounts endpoint for authorised account information for the validity period of the authorised consent or validity period of the access token.
Salt Bank’s API allows Third Party Providers to request different types of PSU consent - Dedicated Accounts (Detailed Consent), Bank Offered Consents and Global Consents.
Requests made by TPPs will not fail if any one of these consent types is requested, however Salt Bank’s standard PSU consent authorization flow by default allows the PSU to select the accounts they would like to enable for sharing.
This means that in practice, irrespective of which of the below account types are requested by the TPP, the flow will be aligned with a ‘Bank Offered’ consent.
The consent models are described by the Berlin Group standard as per the below:
The consent management is between the TPP and PSU with the PSU confirming the details of the accounts they wish the TPP to access directly to the TPP. The consent request body MUST include the payment account identification(s) provided by the PSU to the TPP.
The access object can contain accounts, balances and transactions entries, each of which MUST contain one or more account references.
The inclusion of the balances and/or transactions arrays means by default the TPP can access the detailed account information.
In addition to providing the access required and account references the following mandatory information MUST be provided in the Request body:
recurringIndicator: must be true if the consent is for recurring access or false when the consent is for one-time access to account data.
validUntil: When the recurringIndicator is true this date must reflect the validity period of the consent. Recurring consents are allowed with up to 180 days validity. When the recurringIndicator is false this date must reflect today’s date.
frequencyPerDay: A value between 1 to 4 must be provided to reflect the maximum number of unattended requests (no PSU involvement) will be made by the TPP during a 24 hour period. When the recurringIndicator is false, this attribute MUST be set to “1” .
combinedServiceIndicator: Must always be false as the optional combination of an account information and payment initiation consent in one session is not supported.
The TPP asks the ASPSP to manage the consent management. The ASPSP will display the available accounts for selection to the PSU as part of the PSU SCA authentication flow.
The TPP MUST still confirm if access to balances and/or transactions should be included in the consent by providing an empty list if the access is required. If the balance and/or transaction access is not required, the corresponding field can be omitted.
All other fields are the same as for the Detailed Consent Model.
The consent management is between the TPP and PSU. Rather than confirm the payment accounts directly to the TPP, the TPP will request access to all available accounts.
The options supported are:
| Access Sub-Attribute | Value | Access Granted | Supported |
|---|---|---|---|
| availableAccounts | allAccounts | Account Information Only | ✔ |
| availableAccounts | allAccountsWithOwnerName | Account Information Only with owner name | ✔ |
| availableAccountsWithBalance | allAccounts | Account Information & Balances | ✔ |
| availableAccountsWithBalance | allAccountsWithOwnerName | Account Info & Balances with owner name | ✔ |
| allPSD2 | allAccounts | Account, Balance & Transactions | ✔ |
| allPSD2 | allAccountsWithOwnerName | Account, Balance & Transactions with owner name | ✔ |
The following “WithBalance” options are not supported:
POST /v1/consents
Creates an account information consent resource at the ASPSP.
As the OAuth2 SCA Approach is supported by Salt Bank the following Request Headers should be provided in addition to the attributes flagged as mandatory by the Berlin Group:
TPP-Redirect-URI: The URI of the TPP the PSU will be redirected back to after the successful execution of the PSU SCATPP-Nok-Redirect-URI: If required, this will be the URI the PSU is redirected to when the PSU SCA fails or is cancelled by the PSU.When successfully processed, the response will return the scaOAuth link where the configuration of the OAuth2 Server is defined. The configuration follows the OAuth 2.0 Authorisation Server Metadata specification.
On 25 July 2023, Article 10a came into force as part of the EU RTS SCA CSC technical standards. This new article changed the requirement for the PSU to SCA re-authenticate from 90 days to 180 days to continue to access payment account information through an AISP.
When the PSU has not SCA re-authenicated after 180 days, payment account information through that AISP will cease and any resource requests will be rejected.
GET /v1/consents/{consentId}/status
Checks the status of an account information consent resource.
GET /v1/consents/{consentId}
Returns the content of an account information consent object.
DELETE /v1/consents/{consentId}
Deletes an account information consent.
Once an access token has been obtained, the applicable account information, balances and transactions data can be requested based on the consent granted by the PSU.
All account access API requests must provide the following Request headers in addition to the standard Signing headers:
In addition if the account access request has been initiated by PSU activity then the PSU-IP-Address Request header must be populated with the PSU’s ID address. If this request header is not provided, the access request will count towards the daily limit of unattended requests.
Your QWAC certificate must also be provided when calling any Accounts endpoints, along with a valid access token.
Additional Response Header
As part of each resource response returned, we will include an additional response header x-fapi-interaction-id. This response header will be in addition to the return of the mandatory X-Request-ID.
The X-Request-ID and x-fapi-interaction-id values should be provided when contacting us for any support queries or issues.
Summary of Account Data Extended Services Supported
| Services | Supported |
|---|---|
| Card Accounts Endpoints | ✖ |
| List of Trusted Beneficiaries Service | ✖ |
| AIS for Savings and Loans Accounts Service | ✖ |
Read Account List: GET /v1/accounts
Returns all the account details for the accounts associated with the Consent ID.
Read Account Details: GET /v1/accounts/{account-id}
Returns the accounts details for the specific account ID provided in the path parameter, providing that account ID is associated with the Consent ID
Account, Transaction and Funds Confirmation API Specification
Summary of Account Information Request Services Supported
| Services | Supported |
|---|---|
| Return of Account ownerName and ownerNames | ✔ |
| Return of Account ownerNames | ✔ |
| Return of Account psuName | ✖ |
| Account ownerName returned without taking into account the consent scope | ✖ |
| Query parameter withBalance | ✔ |
Endpoints Read Balance: GET /v1/accounts/{account-id}/balances
Returns the balance details for the specific account ID provided in the path parameter, providing that account ID is associated with the Consent ID and the PSU has granted permission to access their balance information.
Account, Transaction and Funds Confirmation API Specification
[!WARNING]
THE BALANCES SWAGGER (YAML) LINKS MUST BE ADDED
Balance Types Supported The following balance types may be provided in the Balance response:
| Services | Supported |
|---|---|
| closingBooked | ✔ |
| expected | ✔ |
| openingBooked | ✖ |
| interimAvailable | ✖ |
| interimBooked | ✖ |
| forwardAvailable | ✔ |
| nonInvoiced | ✖ |
Read Transaction List: GET /v1/accounts/{account-id}/transactions
Returns the transaction data for the specific account ID provided in the path parameter, providing that account ID is associated with the Consent ID and the PSU has granted permission to access their transaction information.
Transactions requests are limited to a period of 90 days from the time the request is made. The only exception to this limitation applies during the first 10 minutes of an AIS consent lifecycle. In this time period, any GET /transactions request made will not be limited by the 90 days time range. After this time period, the above limitation will apply, and any requests to retrieve transactions older than 90 days will be rejected.
Account, Transaction and Funds Confirmation API Specification
[WARNING]
THE TRANSACTIONS SWAGGER (YAML) LINKS MUST BE ADDED
Transactions Query Parameters Supported
| Services | Supported |
|---|---|
| dateFrom | ✔ |
| dateTo | ✔ |
| entryReferenceFrom | ✖ |
| bookingStatus = booked | ✔ |
| bookingStatus = pending | ✔ |
| bookingStatus = both | ✔ |
| bookingStatus = information | ✖ |
| bookingStatus = all | ✔ |
| deltaList | ✖ |
| withBalance | ✖ |
The list of standing orders will be returned when the optional “information” or “all” Booking Status code is provided in the query parameter.
When the bookingStatus equals "information", the query parameters dateFrom and
dateTo will be ignored as they have no effect on the transaction response that will be returned.
The optional withBalance query parameter will be ignored by Salt Bank when provided.
Read Transactions Detail: GET /v1/accounts/{account-id}/transactions/{transactionId}
Returns the transaction details for a given transaction addressed by “transactionId” on a given account addressed by "account-id".
The Read Transaction List query parameters are not applicable for this endpoint.