TOP

PSD2 Core Services

The following services are available to third-party providers:

  • Account information services - a set of services that allow third-party service providers to access customer accounts, balances, and transactions with customer consent.
  • Payment initiation services - a set of services that allow third-party service providers to initiate a payment on behalf of a client. There are also services available for checking the payment status and obtaining payment information. PSD2 states that all electronic transactions must be strictly authenticated by customers, so after initiating a payment, the customer authorizes the payment with the ASPSP authorization tool.
  • Confirmation of funds service - a service that allows you to check whether a given amount of money is available in a particular account.

Below is the list of APIs available in Open Banking System.

Accounts Accounts Information Services
endpoints
GET /v1/api/accounts Reads a list of bank accounts,
with balances where required.
GET /v1/api/accounts/{account-id}/balances Give detailed balance information
about the addressed account.
GET /v1/api/accounts/{account-id}/transactions Read transaction reports or
transaction lists of a given account.
GET /v1/api/accounts/{account-id} Reads details about an account,
with balances where required.
Consents Consents endpoints
GET /v1/api/consents/{consentId} Returns the content of an account
information consent object.
DELETE /v1/api/consents/{consentId} Terminates the addressed consent.
POST /v1/api/consents Creates an account information
consent resource at the ASPSP
GET /v1/api/consents/{consentId}/authorisations/{authorisationId} Returns the SCA status of the
authorisation.
GET /v1/api/consents/{consentId}/status Read the consent status of the
addressed consent resource.
FundsConfirmation Funds confirmation endpoints
POST /v1/api/funds-confirmations Creates a confirmation of funds
request at the ASPSP.
Payments Payment Services Endpoints
GET /v1/api/payments/{paymentId}/status Returns the transaction status of
the payment.
GET /v1/api/payments/{payment-product}/{paymentId}/authorisations/{authorisationId} Returns the SCA status of the
authorisation.
GET /v1/api/payments/{payment-product}/{paymentId}/authorisations Returns a list of all
authorisation sub-resources IDs which have been created.
POST /v1/api/payments/{payment-product} Creates a payment initiation
request at the ASPSP.
GET /v1/api/payments/{paymentId} Returns the content of a payment
object.

Authorization

Authorization to Open Banking is based on Oauth2 Protocol

For the OAuth approach the individual steps of the SCA are not executed at the XS2A interface, but directly between the PSU and the ASPSP. In this case, the PSU is redirected to a web interface of the ASPSP for authentication.

Once the PSU has been redirected to the ASPSP the SCA of the PSU is executed step by step and directly between the ASPSP and the PSU. After completion of the SCA the PSU is redirected back to the TPP. The following figure shows the top level information flow for a account information request with SCA based on the OAuth approach.

When applying the OAuth approach the TPP does not need detailed information about the individual steps of the SCA of the PSU. The redirect approach therefore allows the TPP to avoid the implementation of the different SCA methods at its PSU – TPP interface.

Consent authorization

  1. Execute “POST /resource/v1/api/consents” endpoint. You will get a consent object in JSON format as a response.

Params:

  • SwaggerClient = Application Key;
  • X-Request-ID = ID of the request, unique to the call, as determined by the initiating party;
  • PSU-IP-Address = The forwarded IP Address header field consists of the corresponding http request IP Address field between PSU and TPP.

Body:

{

"access": {

"accounts": [],

"balances": [],

"transactions": []

},

"recurringIndicator": "true",

"validUntil": "",

"frequencyPerDay": "",

"combinedServiceIndicator": "false"

}

  1. As a next step, created consent need to be authorized.

To start authorization process, PSU must be redirected to URL formatted according to OAUTH2 specification:

Error! Hyperlink reference not valid.>

Params:

  • response_type = code;
  • <TPP_KEY> = Application key;
  • <REDIRECT_URI> = Application redirect URL;
  • <CONSENT_ID> = Consent id received in previous step;
  • <RANDOM_NUMBER> = random number (request ID).

Example:

Error! Hyperlink reference not valid.477a-afff-e9f6697a7b47&redirect_uri=http://test1748.lv&scope=AISP%3A8f1d0343-7866-4e36-824d-334dcf31ddd0&state=587454

3. Go through Internetbank authorization process:

4. Select client accounts, enter authorization code and press “Send”.


5. After account selection you will be redirected to the redirect URL with code. This code will be used to get token.

6. To get token must be called “POST Error! Hyperlink reference not valid.” endpoint.

Params:

  • grant_type = authorization_code;
  • redirect_uri = Application redirect URL;
  • code = code received in previous step;
  • client_id = Application key;
  • client_secret = Application secret.


Response example:

7. Now we can use received token to get information about accounts, balances etc.

Authorization type OAuth 2.0.

Params:

  • Access Token = token received in the previous step.

Params:

  • SwaggerClient = Application Key;
  • X-Request-ID = ID of the request, unique to the call, as determined by the initiating party;
  • Consent-ID = Consent ID received in 1. step.