NAV Navigation
Javascript Python Java

enable:Banking SDK

Welcome to Enable Banking SDK developer documentation! We are happy that you are interested our solution. In this documentation you have all information to start use our SDK.

Enable Banking SDK is for connecting your solution to Open Banking APIs without 3rd party solutions. With our solution you can build new business driven solutions and also connect your current solution to Open Banking APIs. We are believer for easy and fast development so we offer all needed documentation and code examples for you.

For starting you need to have developer license which you can order here. You will get your developer SDK, which is connected Open Banking API sandboxes.

For production usage please contact us or If you just need more info contact us at hello@enablebanking.com

SDK reference

Select a language for code samples from the tabs above or the mobile navigation menu.

Currently enable:Banking SDK consists of authorization, account information and payment initiation APIs. The same calls and data structures are used for interacting with different banks. In order to use each of the APIs corresponding API instance needs to be created with bank specific settings.

enable:Banking SDK API is based on STET PSD2 specification.

This API intends to provide an interface for Third Party Providers (TPP) for accessing Account Servicing Payment Service Providers (ASPSP, i.e. banks).

TPP may act as Account Information Service Provider (AISP), Payment Initiation Service Providers (PISP) or both.

The Payment Service User (PSU) is the owner of the accounts held by the ASPSP and gives accreditations to the TPP in order to access his accounts information or initiates payment from these accounts.

License: LicenseRef-LICENSE

Meta API

getConnectors

Code samples

const enablebanking = require('enablebanking');

const metaApi = new enablebanking.MetaApi(new enablebanking.ApiClient());

const connectors = await metaApi.getConnectors({
  country: 'FI' // requesting connectors for Finland
});

import enablebanking

meta_api = enablebanking.MetaApi(enablebanking.ApiClient())

connectors = meta_api.get_connectors(
    country='FI') # requesting connectors for Finland

import com.enablebanking.*;
import com.enablebanking.model.*;
import com.enablebanking.api.MetaApi;

MetaApi metaApi = new MetaApi(new ApiClient());

HalConnectors connectors = metaApi.getConnectors("FI"); // connectors for Finland

Retrieval of the available connectors

This call returns all available connectors (all or for a specified country).

Parameters

Name Type Required Description
country string false Country ISO code

Returned values

Data type Description
HalConnectors List of connectors

Auth API

getAuth

Code samples

const enablebanking = require('enablebanking');

const authApi = new enablebanking.AuthApi(
  new enablebanking.ApiClient('Bank name', [ /* Bank settings */ ]));

const { url } = await authApi.getAuth(
  'code', // using authorization code grant
  'https://example.com/', // redirect URL
  ['aisp'], // API scope
  {
    state: 'test' // state to pass to redirect URL
  });

import enablebanking

auth_api = enablebanking.AuthApi(enablebanking.ApiClient(
    'Bank name',
    {
      # Bank settings
    })

url = auth_api.get_auth(
    'code', # using authorization code grant
    'https://example.com/', # redirect URL
    ['aisp'], # API scope
    state='test', # state to pass to redirect URL
).url

import java.util.List;
import java.util.ArrayList;
import java.util.Arrays;
import com.enablebanking.ApiClient;
import com.enablebanking.model.*;
import com.enablebanking.api.AuthApi;

List bankSettings = new ArrayList();
// Filling in bank settings here...

AuthApi authApi = new AuthApi(new ApiClient("Bank name", bankSettings));

String url = authApi.getAuth(
    "code", // using authorization code grant
    "https://example.com/", // redirect URL
    new ArrayList(Arrays.asList("aisp")), // API scope
    "test" // state to pass to redirect URL
).url;

Request Authorization Data

Get authorization data such as authorization URL

Parameters

Name Type Required Description
response_type string true none
redirect_uri string true none
scope array[string] true none
client_id string false none
state string false none

Enumerated Values

response_type

ValueDescription
code

scope

ValueDescription
aisp Access AISP (account information) APIs
pisp Access PISP (payment initiation) APIs

Returned values

Data type Description
Auth Authorization Data

makeToken

Code samples

const enablebanking = require('enablebanking');

const authApi = new enablebanking.AuthApi(
  new enablebanking.ApiClient('Bank name', [ /* Bank settings */ ]));

const token = await authApi.makeToken(
  'authorization_code', // grant type, MUST be set to "authorization_code"
  'so43ls-3ldg03sd-hl4saa3l2sl5czfhl3'); // The code received in the query string when redirected from authorization

import enablebanking

auth_api = enablebanking.AuthApi(enablebanking.ApiClient(
    'Bank name',
    {
      # Bank settings
    })

token = auth_api.make_token(
    'authorization_code', # grant type, MUST be set to "authorization_code"
    'so43ls-3ldg03sd-hl4saa3l2sl5czfhl3') # The code received in the query string when redirected from authorization

import java.util.List;
import java.util.ArrayList;
import com.enablebanking.ApiClient;
import com.enablebanking.model.*;
import com.enablebanking.api.AuthApi;

List bankSettings = new ArrayList();
// Filling in bank settings here...

AuthApi authApi = new AuthApi(new ApiClient("Bank name", bankSettings));

Token token = authApi.makeToken(
    "authorization_code", // grant type, MUST be set to "authorization_code"
    "so43ls-3ldg03sd-hl4saa3l2sl5czfhl3" // The code received in the query string when redirected from authorization
);

Request Access Token

Partner makes a request to the token endpoint by adding the following parameters described below

Parameters

Name Type Required Description
grant_type string true Value MUST be set to "authorization_code" as per RFC
code string true The code received in the query string when redirected from authorization
redirect_uri string false none

Detailed descriptions

code: The code received in the query string when redirected from authorization page

Enumerated Values

grant_type

ValueDescription
authorization_code

Returned values

Data type Description
Token Authorisation token (Bearer)

Exceptions

Data type Description
HttpError As per RFC authorisation server responds with 400 in case of error

deleteToken

Invalidate access token

Returned values

Data type Description
None Empty body with 200 code

Exceptions

Data type Description
None Access Token already invalidated or not found
None Internal server error

getCurrentToken

Code samples

const enablebanking = require('enablebanking');

const authApi = new enablebanking.AuthApi(
  new enablebanking.ApiClient('Bank name', [ /* Bank settings */ ]));

const token = await authApi.getCurrentToken();

import enablebanking

auth_api = enablebanking.AuthApi(enablebanking.ApiClient(
    'Bank name',
    {
      # Bank settings
    })

token = auth_api.get_current_token()

import java.util.List;
import java.util.ArrayList;
import com.enablebanking.ApiClient;
import com.enablebanking.model.*;
import com.enablebanking.api.AuthApi;

List bankSettings = new ArrayList();
// Filling in bank settings here...

AuthApi authApi = new AuthApi(new ApiClient("Bank name", bankSettings));

Token token = authApi.getCurrentToken();

Get current token data

This method is used to retrieve current values of access, refresh and id tokens used for accessing AIS and PIS APIs.

Returned values

Data type Description
Token Current token. Values for some fields might be missing if not used.

Exceptions

Data type Description
HttpError Error in case token data is not available

AISP API

getAccounts

Code samples

const enablebanking = require('enablebanking');

const aispApi = new enablebanking.AISPApi(
  new enablebanking.ApiClient('Bank name', [ /* Bank settings */ ]));

const accounts = await aispApi.getAccounts();

import enablebanking

aisp_api = enablebanking.AISPApi(enablebanking.ApiClient(
    'Bank name',
    {
      # Bank settings
    }))

accounts = aisp_api.get_accounts()

import java.util.List;
import java.util.ArrayList;
import com.enablebanking.ApiClient;
import com.enablebanking.model.*;
import com.enablebanking.api.AispApi;

List bankSettings = new ArrayList();
// Filling in bank settings here...

AispApi aispApi = new AispApi(new ApiClient("Bank name", bankSettings));

HalAccounts accounts = aispApi.getAccounts();

Retrieval of the PSU accounts (AISP)

Description

This call returns all payment accounts that are relevant the PSU on behalf of whom the AISP is connected. Thanks to HYPERMEDIA, each account is returned with the links aiming to ease access to the relevant transactions and balances. The result may be subject to pagination (i.e. retrieving a partial result in case of having too many results) through a set of pages by the ASPSP. Thereafter, the AISP may ask for the first, next, previous or last page of results.

Prerequisites

  • The TPP has been registered by the Registration Authority for the AISP role.
  • The TPP and the PSU have a contract that has been enrolled by the ASPSP
    • At this step, the ASPSP has delivered an OAUTH2 "Authorization Code" or "Resource Owner Password" access token to the TPP (cf. § 3.4.2).
  • The TPP and the ASPSP have successfully processed a mutual check and authentication
  • The TPP has presented its OAUTH2 "Authorization Code" or "Resource Owner Password" access token which allows the ASPSP to identify the relevant PSU and retrieve the linked PSU context (cf. § 3.4.2) if any.
  • The ASPSP takes into account the access token that establishes the link between the PSU and the AISP.

Business Flow

The TPP sends a request to the ASPSP for retrieving the list of the PSU payment accounts. The ASPSP computes the relevant PSU accounts and builds the answer as an accounts list. The result may be subject to pagination in order to avoid an excessive result set. Each payment account will be provided with its characteristics.

Returned values

Data type Description
HalAccounts The ASPSP return a PSU context

Exceptions

Data type Description
HttpError Unauthorized, authentication failure.
HttpError Forbidden, authentication successful but access to resource is not allowed.
HttpError Not found, no request available.
HttpError Method Not Allowed.
HttpError Not Acceptable.
HttpError Request Timeout.
HttpError Too many requests.
HttpError Internal server error.
HttpError Service unavailable.

getAccountBalances

Code samples

const enablebanking = require('enablebanking');

const aispApi = new enablebanking.AISPApi(
  new enablebanking.ApiClient('Bank name', [ /* Bank settings */ ]));

const balances = await aispApi.getAccountBalances('203059694928560295396833');

import enablebanking

aisp_api = enablebanking.AISPApi(enablebanking.ApiClient(
    'Bank name',
    {
      # Bank settings
    }))

balances = aisp_api.get_account_balances('203059694928560295396833')

import java.util.List;
import java.util.ArrayList;
import com.enablebanking.ApiClient;
import com.enablebanking.model.*;
import com.enablebanking.api.AispApi;

List bankSettings = new ArrayList();
// Filling in bank settings here...

AispApi aispApi = new AispApi(new ApiClient("Bank name", bankSettings));

HalBalances balances = aispApi.getAccountBalances("203059694928560295396833")

Retrieval of an account balances report (AISP)

Description

This call returns a set of balances for a given PSU account that is specified by the AISP through an account resource Identification
  • The ASPSP must provide at least the accounting balance on the account.
  • The ASPSP can provide other balance restitutions, e.g. instant balance, as well, if possible.
  • Actually, from the PSD2 perspective, any other balances that are provided through the Web-Banking service of the ASPSP must also be provided by this ASPSP through the API.

Prerequisites

  • The TPP has been registered by the Registration Authority for the AISP role
  • The TPP and the PSU have a contract that has been enrolled by the ASPSP
    • At this step, the ASPSP has delivered an OAUTH2 “Authorization Code” or “Resource Owner Password” access token to the TPP (cf. § 3.4.2).
  • The TPP and the ASPSP have successfully processed a mutual check and authentication
  • The TPP has presented its OAUTH2 “Authorization Code” or “Resource Owner Password” access token which allows the ASPSP to identify the relevant PSU and retrieve the linked PSU context (cf. § 3.4.2) if any.
  • The ASPSP takes into account the access token that establishes the link between the PSU and the AISP.
  • The TPP has previously retrieved the list of available accounts for the PSU

Business flow

The AISP requests the ASPSP on one of the PSU’s accounts.
The ASPSP answers by providing a list of balances on this account.
  • The ASPSP must provide at least the accounting balance on the account.
  • The ASPSP can provide other balance restitutions, e.g. instant balance, as well, if possible.
  • Actually, from the PSD2 perspective, any other balances that are provided through the Web-Banking service of the ASPSP must also be provided by this ASPSP through the API.

Parameters

Name Type Required Description
accountResourceId string true Identification of account resource to fetch

Returned values

Data type Description
HalBalances The ASPSP answers with a list of account balances
None No content.

Exceptions

Data type Description
HttpError Invalid status value
HttpError Unauthorized, authentication failure.
HttpError Forbidden, authentication successful but access to resource is not allowed.
HttpError Not found, no request available.
HttpError Method Not Allowed.
HttpError Not Acceptable.
HttpError Request Timeout.
HttpError Too many requests.
HttpError Internal server error.
HttpError Service unavailable.

getAccountTransactions

Code samples

const enablebanking = require('enablebanking');

const aispApi = new enablebanking.AISPApi(
  new enablebanking.ApiClient('Bank name', [ /* Bank settings */ ]));

const transactions = await aispApi.getAccountTransactions('203059694928560295396833');

import enablebanking

aisp_api = enablebanking.AISPApi(enablebanking.ApiClient(
    'Bank name',
    {
      # Bank settings
    }))

transactions = aisp_api.get_account_transactions('203059694928560295396833')

import java.util.List;
import java.util.ArrayList;
import com.enablebanking.ApiClient;
import com.enablebanking.model.*;
import com.enablebanking.api.AispApi;

List bankSettings = new ArrayList();
// Filling in bank settings here...

AispApi aispApi = new AispApi(new ApiClient("Bank name", bankSettings));

HalTransactions transactions = aispApi.getAccountTransactions("203059694928560295396833");

Retrieval of an account transaction set (AISP)

Description

This call returns transactions for an account for a given PSU account that is specified by the AISP through an account resource identification. The request may use some filter parameter in order to restrict the query
  • on a given imputation date range
  • past a given incremental technical identification
The result may be subject to pagination (i.e. retrieving a partial result in case of having too many results) through a set of pages by the ASPSP. Thereafter, the AISP may ask for the first, next, previous or last page of results.

Prerequisites

  • The TPP has been registered by the Registration Authority for the AISP role
  • The TPP and the PSU have a contract that has been enrolled by the ASPSP
    • At this step, the ASPSP has delivered an OAUTH2 "Authorization Code" or "Resource Owner Password" access token to the TPP (cf. § 3.4.2).
  • The TPP and the ASPSP have successfully processed a mutual check and authentication
  • The TPP has presented its OAUTH2 "Authorization Code" or "Resource Owner Password" access token which allows the ASPSP to identify the relevant PSU and retrieve the linked PSU context (cf. § 3.4.2) is any.
  • The ASPSP takes into account the access token that establishes the link between the PSU and the AISP.
  • The TPP has previously retrieved the list of available accounts for the PSU

Business flow

The AISP requests the ASPSP on one of the PSU’s accounts. It may specify some selection criteria. The ASPSP answers by a set of transactions that matches the query. The result may be subject to pagination in order to avoid an excessive result set.

Parameters

Name Type Required Description
accountResourceId string true Identification of account resource to fetch
dateFrom string(date-time) false Inclusive minimal imputation date of the transactions.
dateTo string(date-time) false Exclusive maximal imputation date of the transactions.
afterEntryReference string false Specifies the value on which the result has to be computed.

Detailed descriptions

dateFrom: Inclusive minimal imputation date of the transactions.

Transactions having an imputation date equal to this parameter are included within the result.

dateTo: Exclusive maximal imputation date of the transactions.

Transactions having an imputation date equal to this parameter are not included within the result.

afterEntryReference: Specifies the value on which the result has to be computed.

Only the transaction having a technical identification greater than this value must be included within the result

Returned values

Data type Description
HalTransactions Complete transactions response
None No content.

Exceptions

Data type Description
HttpError Invalid status value
HttpError Unauthorized, authentication failure.
HttpError Forbidden, authentication successful but access to resource is not allowed.
HttpError Not found, no request available.
HttpError Method Not Allowed.
HttpError Not Acceptable.
HttpError Request Timeout.
HttpError Too many requests.
HttpError Internal server error.
HttpError Service unavailable.

modifyConsents

Code samples

const enablebanking = require('enablebanking');

const aispApi = new enablebanking.AISPApi(
  new enablebanking.ApiClient('Bank name', [ /* Bank settings */ ]));

const consent = await aispApi.modifyConsents({
  access: {
    balances: ['203059694928560295396833'],
    transactions: [],
    trustedBeneficiaries: false,
    psuIdentity: true
  }
});

import enablebanking

aisp_api = enablebanking.AISPApi(enablebanking.ApiClient(
    'Bank name',
    {
      # Bank settings
    }))

consent = aisp_api.modify_consents(
    access=enablebanking.Access(
        balances=['203059694928560295396833'],
        transactions=[],
        trusted_beneficiaries=False,
        psu_identity=True,
    ),
)

import java.util.List;
import java.util.ArrayList;
import java.util.Arrays;
import com.enablebanking.ApiClient;
import com.enablebanking.model.*;
import com.enablebanking.api.AispApi;

List bankSettings = new ArrayList();
// Filling in bank settings here...

AispApi aispApi = new AispApi(new ApiClient("Bank name", bankSettings));

Consent consent = aispApi.modifyConsents(
    new Access(
        new ArrayList(Arrays.asList("203059694928560295396833")), // balances
        new ArrayList(), // transactions
        false, // trusted benefeciaries
        true // PSU identity
    )
);

Forwarding the PSU consent (AISP)

Description

In the mixed detailed consent on accounts
  • the AISP captures the consent of the PSU
  • then it forwards this consent to the ASPSP
This consent replaces any prior consent that was previously sent by the AISP.

Prerequisites

  • The TPP has been registered by the Registration Authority for the AISP role.
  • The TPP and the PSU have a contract that has been enrolled by the ASPSP
    • At this step, the ASPSP has delivered an OAUTH2 "Authorization Code" or "Resource Owner Password" access token to the TPP (cf. § 3.4.2).
  • The TPP and the ASPSP have successfully processed a mutual check and authentication
  • The TPP has presented its OAUTH2 "Authorization Code" or "Resource Owner Password" access token which allows the ASPSP to identify the relevant PSU and retrieve the linked PSU context (cf. § 3.4.2) if any.
  • The ASPSP takes into account the access token that establishes the link between the PSU and the AISP.

Business Flow

The PSU specifies to the AISP which of his/her accounts will be accessible and which functionalities should be available. The AISP forwards these settings to the ASPSP. The ASPSP answers by HTTP201 return code.

Parameters

Name Type Required Description
access Access false List of consents granted to the AISP by the PSU.

Returned values

Data type Description
Consent Created or modified consent

Exceptions

Data type Description
HttpError Invalid status value
HttpError Unauthorized, authentication failure.
HttpError Forbidden, authentication successful but access to resource is not allowed.
HttpError Method Not Allowed.
HttpError Not Acceptable.
HttpError Request Timeout.
HttpError Too many requests.
HttpError Internal server error.
HttpError Service unavailable.

getCurrentConsent

Code samples

const enablebanking = require('enablebanking');

const aispApi = new enablebanking.AISPApi(
  new enablebanking.ApiClient('Bank name', [ /* Bank settings */ ]));

const consent = await aispApi.getCurrentConsent();

import enablebanking

aisp_api = enablebanking.AISPApi(enablebanking.ApiClient(
    'Bank name',
    {
      # Bank settings
    }))

consent = aisp_api.get_current_consent()

import java.util.List;
import java.util.ArrayList;
import java.util.Arrays;
import com.enablebanking.ApiClient;
import com.enablebanking.model.*;
import com.enablebanking.api.AispApi;

List bankSettings = new ArrayList();
// Filling in bank settings here...

AispApi aispApi = new AispApi(new ApiClient("Bank name", bankSettings));

Consent consent = aispApi.getCurrentConsent();

Returns current consent (AISP)

Description

Returned values

Data type Description
Consent Current consent used for accessing AIS APIs.

Exceptions

Data type Description
HttpError Invalid status value
HttpError Unauthorized, authentication failure.
HttpError Forbidden, authentication successful but access to resource is not allowed.
HttpError Not found, no request available.
HttpError Method Not Allowed.
HttpError Not Acceptable.
HttpError Request Timeout.
HttpError Too many requests.
HttpError Internal server error.
HttpError Service unavailable.

PISP API

makePaymentRequest

Code samples

const enablebanking = require('enablebanking');

const pispApi = new enablebanking.PISPApi(
  new enablebanking.ApiClient('Bank name', [ /* Bank settings */ ]));

const requestCreation = await pispApi.makePaymentRequest({
  creditTransferTransaction: [{
    instructedAmount: {
      amount: '12.3', // amount
      currency: 'EUR' // currency code
    },
    beneficiary: {
      creditor: {
        name: 'Creditor Name' // payee (merchant) name
      },
      creditorAccount: {
        iban: 'FI3420301544117544' // payee account number
      }
    }
  }],
  debtor: {
    name: 'Debtor Name' // payer (account holder) name
  },
  debtorAccount: {
    iban: 'FI6120301544118028' // payer account number
  }
});

import enablebanking

pisp_api = enablebanking.PISPApi(enablebanking.ApiClient(
    'Bank name',
    {
      # Bank settings
    }))

request_creation = pisp_api.make_payment_request(
    enablebanking.PaymentRequestResource(
        credit_transfer_transaction=[
            enablebanking.CreditTransferTransaction(
                instructed_amount=enablebanking.AmountType(
                    amount='12.3', # amount
                    currency='EUR'), # currency code
                beneficiary=enablebanking.Beneficiary(
                    creditor=enablebanking.PartyIdentification(
                        name='Creditor Name'), # payee (merchant) name
                    creditor_account=enablebanking.AccountIdentification(
                        iban='FI3420301544117544'), # payee account number
                ),
            ),
        ],
        debtor=enablebanking.PartyIdentification(
            name='Debtor Name'), # payer (account holder) name
        debtor_account=enablebanking.AccountIdentification(
            iban='FI6120301544118028'), # payer account number
    ))

import java.util.List;
import java.util.ArrayList;
import com.enablebanking.ApiClient;
import com.enablebanking.model.*;
import com.enablebanking.api.PispApi;

List bankSettings = new ArrayList();
// Filling in bank settings here...

PispApi pispApi = new PispApi(new ApiClient("Bank name", bankSettings));

HalPaymentRequestCreation requestCreation = pispApi.makePaymentRequest(
    new PaymentRequestResource(
        // credit transafer transaction
        new ArrayList(Arrays.asList(
            new CreditTransferTransaction(
                // instructed amount
                new AmountType(
                    "12.3", // amount
                    "EUR" // currency code
                ),
                // beneficiary
                new Beneficiary(
                    // creditor
                    new PartyIdentification(
                        "Creditor Name" // payee (merchant) name
                    ),
                    // creditor account
                    new AccountIdentification(
                        "FI3420301544117544" // payee account number
                    ),
                )
            )
        )),
        // debtor
        new PartyIdentification(
            "Debtor Name" // payer (account holder) name
        ),
        // debtor account
        new AccountIdentification(
            "FI6120301544118028" // payer account number
        )
    )
)

Payment request initiation (PISP)

Description

The following use cases can be applied:
  • payment request on behalf of a merchant
  • transfer request on behalf of the account's owner
  • standing-order request on behalf of the account's owner

Data content

A payment request or a transfer request might embed several payment instructions having
  • one single execution date or multiple execution dates
    • case of one single execution date, this date must be set at the payment level
    • case of multiple execution dates, those dates must be set at each payment instruction level
  • one single beneficiary or multiple beneficiaries
    • case of one single beneficiary, this beneficiary must be set at the payment level
    • case of multiple beneficiaries, those beneficiaries must be set at each payment instruction level
A standing order request must embed one single payment instruction and must address one single beneficiary.
  • The beneficiary must be set at the payment level
  • The standing order specific characteristics (start date, periodicity...) must be set at the instruction level

Prerequisites for all use cases

  • The TPP has been registered by the Registration Authority for the PISP role
  • The TPP was provided with an OAUTH2 "Client Credential" access token by the ASPSP (cf. § 3.4.3).
  • The TPP and the ASPSP have successfully processed a mutual check and authentication
  • The TPP has presented its "OAUTH2 Client Credential" access token

Business flow

Payment Request use case
The PISP forwards a payment request on behalf of a merchant.
The PSU buys some goods or services on an e-commerce website held by a merchant. Among other payment method, the merchant suggests the use of a PISP service. As there is obviously a contract between the merchant and the PISP, there is no need of such a contract between the PSU and this PISP to initiate the process.
Case of the PSU that chooses to use the PISP service:
  • The merchant forwards the requested payment characteristics to the PISP and redirects the PSU to the PISP portal.
  • The PISP requests from the PSU which ASPSP will be used.
  • The PISP prepares the Payment Request and sends this request to the ASPSP.
  • The Request can embed several payment instructions having different requested execution date.
  • The beneficiary, as being the merchant, is set at the payment level.
Transfer Request use case
The PISP forwards a transfer request on behalf of the owner of the account.
  • The PSU provides the PISP with all information needed for the transfer.
  • The PISP prepares the Transfer Request and sends this request to the relevant ASPSP that holds the debtor account.
  • The Request can embed several payment instructions having different beneficiaries.
  • The requested execution date, as being the same for all instructions, is set at the payment level.
Standing Order Request use case
The PISP forwards a Standing Order request on behalf of the owner of the account.
  • The PSU provides the PISP with all information needed for the Standing Order.
  • The PISP prepares the Standing Order Request and sends this request to the relevant ASPSP that holds the debtor account.
  • The Request embeds one single payment instruction with
    • The requested execution date of the first occurrence
    • The requested execution frequency of the payment in order to compute further execution dates
    • An execution rule to handle cases when the computed execution dates cannot be processed (e.g. bank holydays)
    • An optional end date for closing the standing Order

Authentication flows for all use cases

As the request posted by the PISP to the ASPSP needs a PSU authentication before execution, this request will include:
  • The specification of the authentication approaches that are supported by the PISP (any combination of "REDIRECT", "EMBEDDED" and "DECOUPLED" values).
  • In case of possible REDIRECT or DECOUPLED authentication approach, one or two call-back URLs to be used by the ASPSP at the finalisation of the authentication and consent process :
    • The first call-back URL will be called by the ASPSP if the Payment Request is processed without any error or rejection by the PSU
    • The second call-back URL is to be used by the ASPSP in case of processing error or rejection by the PSU. Since this second URL is optional, the PISP might not provide it. In this case, the ASPSP will use the same URL for any processing result.
    • Both call-back URLS must be used in a TLS-secured request.
  • In case of possible "EMBEDDED" or "DECOUPLED" approaches, the PSU identifier that can be processed by the ASPSP for PSU recognition must have been set within the request body [debtor] structure.
The ASPSP saves the request and answers to the PISP. The answer embeds:
  • A location link of the saved Request that will be further used to retrieve the Request and its status information.
  • The specification of the chosen authentication approach taking into account both the PISP and the PSU capabilities.
  • In case of chosen REDIRECT authentication approach, the URL to be used by the PISP for redirecting the PSU in order to perform a authentication.
Case of the PSU neither gives nor denies his/her consent, the Request shall expire and is then rejected to the PISP. The expiration delay is specified by each ASPSP.
Redirect authentication approach
When the chosen authentication approach within the ASPSP answers is set to "REDIRECT":
  • The PISP redirects the PSU to the ASPSP which authenticates the PSU
  • The ASPSP asks the PSU to give (or deny) his/her consent to the Payment Request
  • The PSU chooses or confirms which of his/her accounts shall be used by the ASPSP for the future Credit Transfer.
  • The ASPSP is then able to initiate the subsequent Credit Transfer
  • The ASPSP redirects the PSU to the PISP using one of the call-back URLs provided within the posted Payment Request
Decoupled authentication approach
When the chosen authentication approach is "DECOUPLED":
  • Based on the PSU identifier provided within the Payment Request by the PISP, the ASPSP gives the PSU with the Payment Request details and challenges the PSU for a Strong Customer Authentication on a decoupled device or application.
  • The PSU chooses or confirms which of his/her accounts shall be used by the ASPSP for the future Credit Transfer.
  • The ASPSP is then able to initiate the subsequent Credit Transfer
  • The ASPSP notifies the PISP about the finalisation of the authentication and consent process by using one of the call-back URLs provided within the posted Payment Request
Embedded authentication approach
When the chosen authentication approach within the ASPSP answers is set to "EMBEDDED":
  • The TPP informs the PSU that a challenge is needed for completing the Payment Request processing. This challenge will be one of the following:
    • A One-Time-Password sent by the ASPSP to the PSU on a separate device or application.
    • A response computed by a specific device on base of a challenge sent by the ASPSP to the PSU on a separate device or application.
  • The PSU unlock the device or application through a "knowledge factor" and/or an "inherence factor" (biometric), retrieves the Payment Request details and processes the data sent by the ASPSP;
  • The PSU might choose or confirm which of his/her accounts shall be used by the ASPSP for the future Credit Transfer when the device or application allows it.
  • When agreeing the Payment Request, the PSU enters the resulting authentication factor through the PISP interface which will forward it to the ASPSP through a confirmation request (cf. § 4.7)

Parameters

Name Type Required Description
paymentRequest PaymentRequestResource true ISO20022 based payment Initiation Request

Returned values

Data type Description
HalPaymentRequestCreation The request has been created as a resource. The ASPSP must authenticate the PSU.

Exceptions

Data type Description
HttpError Invalid status value
HttpError Unauthorized, authentication failure.
HttpError Forbidden, authentication successful but access to resource is not allowed.
HttpError Method Not Allowed.
HttpError Not Acceptable.
HttpError Request Timeout.
HttpError Too many requests.
HttpError Internal server error.
HttpError Service unavailable.

getPaymentRequest

Retrieval of a payment request (PISP)

Description

The following use cases can be applied:
  • retrieval of a payment request on behalf of a merchant
  • retrieval of a transfer request on behalf of the account's owner
  • retrieval of a standing-order request on behalf of the account's owner
The PISP has sent a Request through a POST command.
The ASPSP has registered the Request, updated if necessary the relevant identifiers in order to avoid duplicates and returned the location of the updated Request.
The PISP gets the Request that might have been updated with the resource identifiers, the status of the Payment/Transfer Request and the status of the subsequent credit transfer.

Prerequisites

  • The TPP has been registered by the Registration Authority for the PISP role
  • The TPP was provided with an OAUTH2 "Client Credential" access token by the ASPSP (cf. § 3.4.3).
  • The TPP has previously posted a Request which has been saved by the ASPSP (cf. § 4.5.3)
    • The ASPSP has answered with a location link to the saved Payment/Transfer Request (cf. § 4.5.4)
  • The TPP and the ASPSP have successfully processed a mutual check and authentication
  • The TPP has presented its "OAUTH2 Client Credential" access token

Business flow

The PISP asks to retrieve the Payment/Transfer Request that has been saved by the ASPSP. The PISP uses the location link provided by the ASPSP in response of the posting of this request.
The ASPSP returns the previously posted Payment/Transfer Request which is enriched with:
  • The resource identifiers given by the ASPSP
  • The status information of the Payment Request and of the subsequent credit transfer
The status information must be available during at least 30 calendar days after the posting of the Payment Request. However, the ASPSP may increase this availability duration, based on its own rules.

Parameters

Name Type Required Description
paymentRequestResourceId string true Identification of the Payment Request Resource

Returned values

Data type Description
HalPaymentRequest Retrieval of the previously posted Payment Request

Exceptions

Data type Description
HttpError Invalid status value
HttpError Unauthorized, authentication failure.
HttpError Forbidden, authentication successful but access to resource is not allowed.
HttpError Not found, no request available.
HttpError Method Not Allowed.
HttpError Not Acceptable.
HttpError Request Timeout.
HttpError Too many requests.
HttpError Internal server error.
HttpError Service unavailable.

modifyPaymentRequest

Modification of a Payment/Transfer Request (PISP)

Description

The PISP sent a Payment/Transfer Request through a POST command.
The ASPSP registered the Payment/Transfer Request, updated if necessary the relevant identifiers in order to avoid duplicates and returned the location of the updated Request.
The PISP got the Payment/Transfer Request that might have been updated with the resource identifiers, the status of the Payment/Transfer Request and the status of the subsequent credit transfer.
The PISP request for the payment cancellation or for some payment instructions cancellation
No other modification of the Payment/Transfer Request is allowed.

Prerequisites

  • The TPP was registered by the Registration Authority for the PISP role
  • The TPP was provided with an OAUTH2 "Client Credential" access token by the ASPSP (cf. § 3.4.3).
  • The TPP previously posted a Payment/Transfer Request which was saved by the ASPSP (cf. § 4.5.3)
    • The ASPSP answered with a location link to the saved Payment/Transfer Request (cf. § 4.5.4)
    • The PISP retrieved the saved Payment/Transfer Request (cf. § 4.5.4)
  • The TPP and the ASPSP successfully processed a mutual check and authentication
  • The TPP presented its "OAUTH2 Client Credential" access token.
  • The TPP presented the payment/transfer request.
  • The PSU was successfully authenticated.

Business flow

the following cases can be applied:
  • Case of a payment with multiple instructions or a standing order, the PISP asks to cancel the whole Payment/Transfer or Standing Order Request including all non-executed payment instructions by setting the [paymentInformationStatus] to "RJCT" and the relevant [statusReasonInformation] to "DS02" at payment level.
  • Case of a payment with multiple instructions, the PISP asks to cancel one or several payment instructions by setting the [transactionStatus] to "RJCT" and the relevant [statusReasonInformation] to "DS02" at each relevant instruction level.
Since the modification request needs a PSU authentication before committing, the modification request includes:
  • The specification of the authentication approaches that are supported by the PISP (any combination of "REDIRECT", "EMBEDDED" and "DECOUPLED" values).
  • In case of possible REDIRECT or DECOUPLED authentication approach, one or two call-back URLs to be used by the ASPSP at the finalisation of the authentication and consent process :
    • The first call-back URL will be called by the ASPSP if the Transfer Request is processed without any error or rejection by the PSU
    • The second call-back URL is to be used by the ASPSP in case of processing error or rejection by the PSU. Since this second URL is optional, the PISP might not provide it. In this case, the ASPSP will use the same URL for any processing result.
    • Both call-back URLS must be used in a TLS-secured request, including mutual authentication based on each party’s TLS certificate.
  • In case of possible "EMBEDDED" or "DECOUPLED" approaches, a PSU identifier that can be processed by the ASPSP for PSU recognition.
  • The ASPSP saves the updated Payment/Transfer Request and answers to the PISP. The answer embeds
    • The specification of the chosen authentication approach taking into account both the PISP and the PSU capabilities.
    • In case of chosen REDIRECT authentication approach, the URL to be used by the PISP for redirecting the PSU in order to perform an authentication.

    Authentication flows for both use cases

    Redirect authentication approach

    When the chosen authentication approach within the ASPSP answers is set to "REDIRECT":
    • The PISP redirects the PSU to the ASPSP which authenticates the PSU
    • The ASPSP asks the PSU to give (or deny) his/her consent to the Payment Request
    • The PSU chooses or confirms which of his/her accounts shall be used by the ASPSP for the future Credit Transfer.
    • The ASPSP is then able to initiate the subsequent Credit Transfer
    • The ASPSP redirects the PSU to the PISP using one of the call-back URLs provided within the posted Payment Request
    If the PSU neither gives nor denies his/her consent, the Payment Request shall expire and is then rejected to the PISP. The expiration delay is specified by each ASPSP.

    Decoupled authentication approach

    When the chosen authentication approach is "DECOUPLED":
    • Based on the PSU identifier provided within the Payment Request by the PISP, the ASPSP gives the PSU with the Payment Request details and challenges the PSU for a Strong Customer Authentication on a decoupled device or application.
    • The PSU chooses or confirms which of his/her accounts shall be used by the ASPSP for the future Credit Transfer.
    • The ASPSP is then able to initiate the subsequent Credit Transfer
    • The ASPSP notifies the PISP about the finalisation of the authentication and consent process by using one of the call-back URLs provided within the posted Payment Request
    If the PSU neither gives nor denies his/her consent, the Payment Request shall expire and is then rejected to the PISP. The expiration delay is specified by each ASPSP.

    Embedded authentication approach

    When the chosen authentication approach within the ASPSP answers is set to "EMBEDDED":
    • The TPP informs the PSU that a challenge is needed for completing the Payment Request processing. This challenge will be one of the following:
      • A One-Time-Password sent by the ASPSP to the PSU on a separate device or application.
      • A response computed by a specific device on base of a challenge sent by the ASPSP to the PSU on a separate device or application.
    • The PSU unlock the device or application through a "knowledge factor" and/or an "inherence factor" (biometric), retrieves the Payment Request details and processes the data sent by the ASPSP;
    • The PSU might choose or confirm which of his/her accounts shall be used by the ASPSP for the future Credit Transfer when the device or application allows it.
    • When agreeing the Payment Request, the PSU enters the resulting authentication factor through the PISP interface which will forward it to the ASPSP through a confirmation request (cf. § 4.7)
    Case of the PSU neither gives nor denies his/her consent, the Payment Request shall expire and is then rejected to the PISP. The expiration delay is specified by each ASPSP.

    Parameters

    Name Type Required Description
    paymentRequestResourceId string true Identification of the Payment Request Resource
    paymentRequest PaymentRequestResource true ISO20022 based payment Initiation Request

    Returned values

    Data type Description
    HalPaymentRequestCreation The modification request has been saved. The ASPSP must authenticate the PSU before committing the update.

    Exceptions

    Data type Description
    HttpError Invalid status value
    HttpError Unauthorized, authentication failure.
    HttpError Forbidden, authentication successful but access to resource is not allowed.
    HttpError Not found, no request available.
    HttpError Method Not Allowed.
    HttpError Not Acceptable.
    HttpError Request Timeout.
    HttpError Too many requests.
    HttpError Internal server error.
    HttpError Service unavailable.

    makePaymentRequestConfirmation

    Confirmation of a payment request or a modification request (PISP)

    Description

    The PISP confirms one of the following requests
    • payment request on behalf of a merchant
    • transfer request on behalf of the account's owner
    • standing-order request on behalf of the account's owner
    The ASPSP answers with a status of the relevant request and the subsequent Credit Transfer.

    Prerequisites

    • The TPP has been registered by the Registration Authority for the PISP role
    • The TPP was provided with an OAUTH2 "Client Credential" access token by the ASPSP (cf. § 3.4.3).
    • The TPP has previously posted a Request which has been saved by the ASPSP (cf. § 4.5.3)
      • The ASPSP has answered with a location link to the saved Payment Request (cf. § 4.5.4)
      • The TPP has retrieved the saved request in order to get the relevant resource Ids (cf. § 4.6).
    • The TPP and the ASPSP have successfully processed a mutual check and authentication
    • The TPP has presented its "OAUTH2 Client Credential" access token

    Business flow

    Once the PSU has been authenticated, it is the due to the PISP to confirm the Request to the ASPSP in order to complete the process flow.
    In REDIRECT and DECOUPLED approach, this confirmation is not a prerequisite to the execution of the Credit Transfer.

    Parameters

    Name Type Required Description
    paymentRequestResourceId string true Identification of the Payment Request Resource
    confirmation PaymentRequestConfirmation false parameters needed for confirmation of the Payment Request, especially in EMBEDDED approach

    Returned values

    Data type Description
    HalPaymentRequest retrieval of the Payment Request enriched with the status report

    Exceptions

    Data type Description
    HttpError Invalid status value
    HttpError Unauthorized, authentication failure.
    HttpError Forbidden, authentication successful but access to resource is not allowed.
    HttpError Method Not Allowed.
    HttpError Not Acceptable.
    HttpError Request Timeout.
    HttpError Too many requests.
    HttpError Internal server error.
    HttpError Service unavailable.

    Data types

    Auth

    Fields

    Name Type Required Restrictions Description
    url string false none URL for authorization

    Token

    Fields

    Name Type Required Restrictions Description
    access_token string false none The access token value
    token_type string false none Type of the token is set to "Bearer"
    expires_in integer(int32) false none The lifetime in seconds of the access token
    refresh_token string false none The refresh token value
    scope string false none Scopes of the token

    Enumerated Values

    token_type

    ValueDescription
    Bearer

    HalConnectors

    HYPERMEDIA structure used for returning the list of the connectors for given countries

    Fields

    Name Type Required Restrictions Description
    connectors [Connector] true none List of connectors
    _links ConnectorsLinks false none links that can be used for further navigation when browsing connector information

    links that can be used for further navigation when browsing connector information

    Name Type Required Restrictions Description
    self GenericLink true none hypertext reference

    Connector

    Information about connector used for interaction with a bank

    Fields

    Name Type Required Restrictions Description
    name string false none The name of connector
    countries [string] false none The list of all countries supported by connector
    scopes [string] false none The list of all scopes supported by connector

    AuthenticationApproach

    The ASPSP, based on the authentication approaches proposed by the PISP, choose the one that it can processed, in respect with the preferences and constraints of the PSU and indicates in this field which approach has been chosen

    Fields

    Name Type Required Restrictions Description
    anonymous string false read-only The ASPSP, based on the authentication approaches proposed by the PISP, choose the one that it can processed, in respect with the preferences and constraints of the PSU and indicates in this field which approach has been chosen

    Enumerated Values

    anonymous

    ValueDescription
    REDIRECT the PSU is redirected by the TPP to the ASPSP which processes identification and authentication
    DECOUPLED the TPP identifies the PSU and forwards the identification to the ASPSP which processes the authentication through a decoupled device
    EMBEDDED the TPP identifies the PSU and forwards the identification to the ASPSP which starts the authentication. The TPP forwards one authentication factor of the PSU (e.g. OTP or response to a challenge)

    GenericIdentification

    ISO20022: Unique identification of an account, a person or an organisation, as assigned by an issuer. API: The ASPSP will document which account reference type it will support.

    Fields

    Name Type Required Restrictions Description
    identification string true none API Identifier
    schemeName string true none Name of the identification scheme. Partially based on ISO20022 external code list
    issuer string false none ISO20022: Entity that assigns the identification. this could a country code or any organisation name or identifier that can be recognized by both parties

    Enumerated Values

    schemeName

    ValueDescription
    BANK BankPartyIdentification. Unique and unambiguous assignment made by a specific bank or similar financial institution to identify a relationship as defined between the bank and its client.
    COID CountryIdentificationCode. Country authority given organisation identification (e.g., corporate registration number)
    SREN The SIREN number is a 9 digit code assigned by INSEE, the French National Institute for Statistics and Economic Studies, to identify an organisation in France.
    SRET The SIRET number is a 14 digit code assigned by INSEE, the French National Institute for Statistics and Economic Studies, to identify an organisation unit in France. It consists of the SIREN number, followed by a five digit classification number, to identify the local geographical unit of that entity.
    NIDN NationalIdentityNumber. Number assigned by an authority to identify the national identity number of a person.
    OAUT OAUTH2 access token that is owned by the PISP being also an AISP and that can be used in order to identify the PSU
    CPAN Card PAN
    BBAN Basic Bank Account Number. Represents a country-specific bank account number.

    AccountIdentification

    Unique and unambiguous identification for the account between the account owner and the account servicer.

    Fields

    Name Type Required Restrictions Description
    iban string false none ISO20022: International Bank Account Number (IBAN) - identification used internationally by financial institutions to uniquely identify the account of a customer.

    Further specifications of the format and content of the IBAN can be found in the standard ISO 13616 "Banking and related financial services - International Bank Account Number (IBAN)" version 1997-10-01, or later revisions.
    other GenericIdentification false none ISO20022: Unique identification of an account, a person or an organisation, as assigned by an issuer.
    API: The ASPSP will document which account reference type it will support.

    AmountType

    ISO20022: structure aiming to carry either an instructed amount or equivalent amount. Both structures embed the amount and the currency to be used.

    API: only instructed amount can be used

    Fields

    Name Type Required Restrictions Description
    currency string true none Specifies the currency of the amount. A code allocated to a currency by a Maintenance Agency under an international identification scheme, as described in the latest edition of the international standard ISO 4217 "Codes for the representation of currencies and funds".
    amount string true none ISO20022: Amount of money to be moved between the debtor and creditor, before deduction of charges, expressed in the currency as ordered by the initiating party.

    ClearingSystemMemberIdentification

    ISO20022: Information used to identify a member within a clearing system. API: to be used for some specific international credit transfers in order to identify the beneficiary bank

    Fields

    Name Type Required Restrictions Description
    clearingSystemId string false none ISO20022: Specification of a pre-agreed offering between clearing agents or the channel through which the payment instruction is processed.
    memberId string false none ISO20022: Identification of a member of a clearing system.

    FinancialInstitutionIdentification

    ISO20022: Unique and unambiguous identification of a financial institution, as assigned under an internationally recognised or proprietary identification scheme.

    Fields

    Name Type Required Restrictions Description
    bicFi string true none ISO20022: Code allocated to a financial institution by the ISO 9362 Registration Authority as described in ISO 9362 "Banking - Banking telecommunication messages - Business identification code (BIC)".
    clearingSystemMemberId ClearingSystemMemberIdentification false none ISO20022: Information used to identify a member within a clearing system.
    API: to be used for some specific international credit transfers in order to identify the beneficiary bank
    name string false none Name of the financial institution
    postalAddress PostalAddress false none ISO20022 : Information that locates and identifies a specific address, as defined by postal services.

    PostalAddress

    ISO20022 : Information that locates and identifies a specific address, as defined by postal services.

    Fields

    Name Type Required Restrictions Description
    country string true none ISO20022: Country in which a person resides (the place of a person's home). In the case of a company, it is the country from which the affairs of that company are directed.
    addressLine [string] true none Unstructured address. The two lines must embed zip code and town name

    PartyIdentification

    API : Description of a Party which can be either a person or an organization.

    Fields

    Name Type Required Restrictions Description
    name string true none ISO20022: Name by which a party is known and which is usually used to identify that party.
    postalAddress PostalAddress false none ISO20022 : Information that locates and identifies a specific address, as defined by postal services.
    organisationId GenericIdentification false none ISO20022: Unique identification of an account, a person or an organisation, as assigned by an issuer.
    API: The ASPSP will document which account reference type it will support.
    privateId GenericIdentification false none ISO20022: Unique identification of an account, a person or an organisation, as assigned by an issuer.
    API: The ASPSP will document which account reference type it will support.

    ResourceId

    Identifier assigned by the ASPSP for further use of the created resource through API calls

    Fields

    Name Type Required Restrictions Description
    anonymous string false read-only Identifier assigned by the ASPSP for further use of the created resource through API calls

    PaymentIdentification

    ISO20022: Set of elements used to reference a payment instruction.

    Fields

    Name Type Required Restrictions Description
    resourceId ResourceId false none Identifier assigned by the ASPSP for further use of the created resource through API calls
    instructionId string false none ISO20022: Unique identification as assigned by an instructing party for an instructed party to unambiguously identify the instruction.

    API: Unique identification shared between the PISP and the ASPSP
    endToEndId string false none ISO20022: Unique identification assigned by the initiating party to unambiguously identify the transaction. This identification is passed on, unchanged, throughout the entire end-to-end chain.

    API: Unique identification shared between the merchant and the PSU

    PriorityCode

    ISO20022: Indicator of the urgency or order of importance that the instructing party would like the instructed party to apply to the processing of the instruction.

    Fields

    Name Type Required Restrictions Description
    anonymous string false none ISO20022: Indicator of the urgency or order of importance that the instructing party would like the instructed party to apply to the processing of the instruction.

    Enumerated Values

    anonymous

    ValueDescription
    HIGH High priority
    NORM Normal priority

    CategoryPurposeCode

    ISO20022: Specifies the high level purpose of the instruction based on a set of pre-defined categories. This is used by the initiating party to provide information concerning the processing of the payment. It is likely to trigger special processing by any of the agents involved in the payment chain.

    Fields

    Name Type Required Restrictions Description
    anonymous string false none ISO20022: Specifies the high level purpose of the instruction based on a set of pre-defined categories. This is used by the initiating party to provide information concerning the processing of the payment. It is likely to trigger special processing by any of the agents involved in the payment chain.

    Enumerated Values

    anonymous

    ValueDescription
    CASH Transaction is a general cash management instruction (CashManagementTransfer).
    DVPM Code used to pre-advise the account servicer of a forthcoming deliver against payment instruction (DeliverAgainstPayment).

    ServiceLevelCode

    ISO20022: Agreement under which or rules under which the transaction should be processed. Specifies a pre-agreed service or level of service between the parties, as published in an external service level code list.

    Fields

    Name Type Required Restrictions Description
    anonymous string false none ISO20022: Agreement under which or rules under which the transaction should be processed. Specifies a pre-agreed service or level of service between the parties, as published in an external service level code list.

    Enumerated Values

    anonymous

    ValueDescription
    NURG Other Credit Transfer
    SEPA SEPA Credit Transfer

    LocalInstrumentCode

    ISO20022: User community specific instrument. Usage: This element is used to specify a local instrument, local clearing option and/or further qualify the service or service level.

    Fields

    Name Type Required Restrictions Description
    anonymous string false none ISO20022: User community specific instrument.
    Usage: This element is used to specify a local instrument, local clearing option and/or further qualify the service or service level.

    Enumerated Values

    anonymous

    ValueDescription
    INST Only "INST" value is allowed in order to ask for an SEPA instant Payment. Can only be used if ServiceLevel is equal to "SEPA"

    PaymentTypeInformation

    ISO20022: Set of elements used to further specify the type of transaction.

    Fields

    Name Type Required Restrictions Description
    instructionPriority PriorityCode false none ISO20022: Indicator of the urgency or order of importance that the instructing party would like the instructed party to apply to the processing of the instruction.
    serviceLevel ServiceLevelCode false none ISO20022: Agreement under which or rules under which the transaction should be processed. Specifies a pre-agreed service or level of service between the parties, as published in an external service level code list.
    localInstrument LocalInstrumentCode false none ISO20022: User community specific instrument.
    Usage: This element is used to specify a local instrument, local clearing option and/or further qualify the service or service level.
    categoryPurpose CategoryPurposeCode false none ISO20022: Specifies the high level purpose of the instruction based on a set of pre-defined categories. This is used by the initiating party to provide information concerning the processing of the payment. It is likely to trigger special processing by any of the agents involved in the payment chain.

    PurposeCode

    ISO20022: Underlying reason for the payment transaction, as published in an external purpose code list.

    Fields

    Name Type Required Restrictions Description
    anonymous string false none ISO20022: Underlying reason for the payment transaction, as published in an external purpose code list.

    Enumerated Values

    anonymous

    ValueDescription
    ACCT Funds moved between 2 accounts of same account holder at the same bank.
    CASH general cash management instruction, may be used for Transfer Initiation.
    COMC Transaction is related to a payment of commercial credit or debit.
    CPKC General Carpark Charges Transaction is related to carpark charges.
    TRPT Transport RoadPricing Transaction is for the payment to top-up pre-paid card and electronic road pricing for the purpose of transportation.

    ChargeBearerCode

    ISO20022: Specifies which party/parties will bear the charges associated with the processing of the payment transaction.

    Fields

    Name Type Required Restrictions Description
    anonymous string false none ISO20022: Specifies which party/parties will bear the charges associated with the processing of the payment transaction.

    Enumerated Values

    anonymous

    ValueDescription
    SLEV Service level. Charges are to be applied following the rules agreed in the service level and/or scheme.
    SHAR Shared.

    UnstructuredRemittanceInformation

    ISO20022: Information supplied to enable the matching of an entry with the items that the transfer is intended to settle, such as commercial invoices in an accounts' receivable system. API: Only one occurrence is allowed

    Fields

    Name Type Required Restrictions Description
    remittanceLine string false none Relevant information to the transaction

    PaymentInformationStatusCode

    ISO20022: Specifies the status of the payment information.

    Fields

    Name Type Required Restrictions Description
    anonymous string false none ISO20022: Specifies the status of the payment information.

    Enumerated Values

    anonymous

    ValueDescription
    ACCP AcceptedCustomerProfile. Preceding check of technical validation was successful. Customer profile check was also successful.
    ACSC AcceptedSettlementCompleted. Settlement on the debtor's account has been completed.
    ACSP AcceptedSettlementInProcess. All preceding checks such as technical validation and customer profile were successful. Dynamic risk assessment is now also successful and therefore the Payment Request has been accepted for execution.
    ACTC AcceptedTechnicalValidation. Authentication and syntactical and semantical validation are successful.
    ACWC AcceptedWithChange. Instruction is accepted but a change will be made, such as date or remittance not sent.
    ACWP AcceptedWithoutPosting. Payment instruction included in the credit transfer is accepted without being posted to the creditor customer’s account.
    PART PartiallyAccepted. A number of transactions have been accepted, whereas another number of transactions have not yet achieved 'accepted' status.
    RCVD Received. Payment initiation has been received by the receiving agent.
    PDNG Pending. Payment request or individual transaction included in the Payment Request is pending. Further checks and status update will be performed.
    RJCT Rejected. Payment request has been rejected.

    TransactionIndividualStatusCode

    ISO20022: Specifies the status of the payment information group.

    Fields

    Name Type Required Restrictions Description
    anonymous string false none ISO20022: Specifies the status of the payment information group.

    Enumerated Values

    anonymous

    ValueDescription
    RCVD Payment request or individual transaction included in the Payment Request has been received by the receiving agent.
    RJCT Payment request or individual transaction included in the Payment Request has been rejected.
    PDNG Pending. Payment request or individual transaction included in the Payment Request is pending. Further checks and status update will be performed.
    ACSP All preceding checks such as technical validation and customer profile were successful and therefore the Payment Request has been accepted for execution.
    ACSC Settlement on the debtor's account has been completed.

    StatusReasonInformation

    ISO20022: Provides detailed information on the status reason. Can only be used in status equal to "RJCT".

    Fields

    Name Type Required Restrictions Description
    anonymous string false none ISO20022: Provides detailed information on the status reason. Can only be used in status equal to "RJCT".

    Enumerated Values

    anonymous

    ValueDescription
    AC01 IncorectAccountNumber. the account number is either invalid or does not exist
    AC04 ClosedAccountNumber. the account is closed and cannot be used
    AC06 BlockedAccount. the account is blocked and cannot be used
    AG01 Transaction forbidden. Transaction forbidden on this type of account
    CH03 RequestedExecutionDateOrRequestedCollectionDateTooFarInFuture. The requested execution date is too far in the future
    CUST RequestedByCustomer. The reject is due to the debtor (refusal or lack of liquidity)
    DS02 OrderCancelled. An authorized user has cancelled the order
    FF01 InvalidFileFormat. The reject is due to the original Payment Request which is invalid (syntax, structure or values)
    FRAD FraudulentOriginated. the Payment Request is considered as fraudulent
    MS03 NotSpecifiedReasonAgentGenerated. No reason specified by the ASPSP
    NOAS NoAnswerFromCustomer. The PSU has neither accepted nor rejected the Payment Request and a time-out has occurred
    RR01 MissingDebtorAccountOrIdentification. The Debtor account and/or Identification are missing or inconsistent
    RR03 MissingCreditorNameOrAddress. Specification of the creditor’s name and/or address needed for regulatory requirements is insufficient or missing.
    RR04 RegulatoryReason. Reject from regulatory reason
    RR12 InvalidPartyID. Invalid or missing identification required within a particular country or payment type.

    RegulatoryReportingCode

    Information needed due to regulatory and statutory requirements. Economical codes to be used are provided by the National Competent Authority

    Fields

    Name Type Required Restrictions Description
    anonymous string false none Information needed due to regulatory and statutory requirements.
    Economical codes to be used are provided by the National Competent Authority

    RegulatoryReportingCodes

    List of needed regulatory reporting codes for international payments

    Fields

    Name Type Required Restrictions Description
    anonymous [RegulatoryReportingCode] false none List of needed regulatory reporting codes for international payments

    RequestedExecutionDate

    ISO20022: Date at which the initiating party requests the clearing agent to process the payment. API: This date can be used in the following cases:

    Fields

    Name Type Required Restrictions Description
    anonymous string(date-time) false none ISO20022: Date at which the initiating party requests the clearing agent to process the payment.
    API:
    This date can be used in the following cases:
    - the single requested execution date for a payment having several instructions. In this case, this field must be set at the payment level.
    - the requested execution date for a given instruction within a payment. In this case, this field must be set at each instruction level.
    - The first date of execution for a standing order.
    When the payment cannot be processed at this date, the ASPSP is allowed to shift the applied execution date to the next possible execution date for non-standing orders.
    For standing orders, the [executionRule] parameter helps to compute the execution date to be applied.

    EndDate

    The last applicable day of execution for a given standing order. If not given, the standing order is considered as endless.

    Fields

    Name Type Required Restrictions Description
    anonymous string(date-time) false none The last applicable day of execution for a given standing order.
    If not given, the standing order is considered as endless.

    ExecutionRule

    Execution date shifting rule for standing orders This data attribute defines the behaviour when recurring payment dates falls on a weekend or bank holiday. The payment is then executed either the "preceding" or "following" working day. ASPSP might reject the request due to the communicated value, if rules in Online-Banking are not supporting this execution rule.

    Fields

    Name Type Required Restrictions Description
    anonymous string false none Execution date shifting rule for standing orders
    This data attribute defines the behaviour when recurring payment dates falls on a weekend or bank holiday.
    The payment is then executed either the "preceding" or "following" working day.
    ASPSP might reject the request due to the communicated value, if rules in Online-Banking are not supporting
    this execution rule.

    Enumerated Values

    anonymous

    ValueDescription
    FWNG following
    PREC preceding

    FrequencyCode

    Frequency rule for standing orders. The following codes from the "EventFrequency7Code" of ISO 20022 are supported. However, each ASPSP might restrict these values into a subset.

    Fields

    Name Type Required Restrictions Description
    anonymous string false none Frequency rule for standing orders.
    The following codes from the "EventFrequency7Code" of ISO 20022 are supported.
    However, each ASPSP might restrict these values into a subset.

    Enumerated Values

    anonymous

    ValueDescription
    DAIL Daily
    WEEK Weekly
    TOWK EveryTwoWeeks
    MNTH Monthly
    TOMN EveryTwoMonths
    QUTR Quarterly
    SEMI SemiAnnual
    YEAR Annual

    CreditTransferTransaction

    ISO20022: Payment processes required to transfer cash from the debtor to the creditor. API:

    Fields

    Name Type Required Restrictions Description
    instructedAmount AmountType true none ISO20022: structure aiming to carry either an instructed amount or equivalent amount. Both structures embed the amount and the currency to be used.

    API: only instructed amount can be used
    beneficiary Beneficiary true none Specification of a beneficiary
    paymentId PaymentIdentification false none ISO20022: Set of elements used to reference a payment instruction.
    requestedExecutionDate RequestedExecutionDate false none ISO20022: Date at which the initiating party requests the clearing agent to process the payment.
    API:
    This date can be used in the following cases:
    - the single requested execution date for a payment having several instructions. In this case, this field must be set at the payment level.
    - the requested execution date for a given instruction within a payment. In this case, this field must be set at each instruction level.
    - The first date of execution for a standing order.
    When the payment cannot be processed at this date, the ASPSP is allowed to shift the applied execution date to the next possible execution date for non-standing orders.
    For standing orders, the [executionRule] parameter helps to compute the execution date to be applied.
    endDate EndDate false none The last applicable day of execution for a given standing order.
    If not given, the standing order is considered as endless.
    executionRule ExecutionRule false none Execution date shifting rule for standing orders
    This data attribute defines the behaviour when recurring payment dates falls on a weekend or bank holiday.
    The payment is then executed either the "preceding" or "following" working day.
    ASPSP might reject the request due to the communicated value, if rules in Online-Banking are not supporting
    this execution rule.
    frequency FrequencyCode false none Frequency rule for standing orders.
    The following codes from the "EventFrequency7Code" of ISO 20022 are supported.
    However, each ASPSP might restrict these values into a subset.
    ultimateCreditor PartyIdentification false none API : Description of a Party which can be either a person or an organization.
    regulatoryReportingCodes RegulatoryReportingCodes false none List of needed regulatory reporting codes for international payments
    remittanceInformation UnstructuredRemittanceInformation false none ISO20022: Information supplied to enable the matching of an entry with the items that the transfer is intended to settle, such as commercial invoices in an accounts' receivable system.
    API: Only one occurrence is allowed
    transactionStatus TransactionIndividualStatusCode false none ISO20022: Specifies the status of the payment information group.
    statusReasonInformation StatusReasonInformation false none ISO20022: Provides detailed information on the status reason. Can only be used in status equal to "RJCT".

    BalanceStatus

    Type of balance

    Fields

    Name Type Required Restrictions Description
    anonymous string false none Type of balance

    Enumerated Values

    anonymous

    ValueDescription
    CLBD (ISO20022 ClosingBooked) Accounting Balance
    ITAV (ISO20022 InterimAvailable) Available balance calculated in the course of the day
    ITBD (ISO20022 InterimBooked) Booked balance calculated in the course of the day
    OTHR Other Balance
    VALU Value-date balance
    XPCD (ISO20022 Expected) Instant Balance

    TransactionStatus

    Type of Transaction

    Fields

    Name Type Required Restrictions Description
    anonymous string false none Type of Transaction

    Enumerated Values

    anonymous

    ValueDescription
    BOOK (ISO20022 ClosingBooked) Accounted transaction
    PDNG (ISO20022 Expected) Instant Balance Transaction
    OTHR Other

    Transaction

    structure of a transaction

    Fields

    Name Type Required Restrictions Description
    transactionAmount AmountType true none ISO20022: structure aiming to carry either an instructed amount or equivalent amount. Both structures embed the amount and the currency to be used.

    API: only instructed amount can be used
    creditDebitIndicator string true none Accounting flow of the transaction
    status TransactionStatus true none Type of Transaction
    remittanceInformation UnstructuredRemittanceInformation true none ISO20022: Information supplied to enable the matching of an entry with the items that the transfer is intended to settle, such as commercial invoices in an accounts' receivable system.
    API: Only one occurrence is allowed
    resourceId ResourceId false none Identifier assigned by the ASPSP for further use of the created resource through API calls
    entryReference string false none Technical incremental identification of the transaction.
    bookingDate string(date) false none Booking date of the transaction on the account
    valueDate string(date) false none Value date of the transaction on the account
    transactionDate string(date) false none Date used for specific purposes:
    - for card transaction: date of the transaction
    - for credit transfer: acquiring date of the transaction
    - for direct debit: receiving date of the transaction

    Enumerated Values

    creditDebitIndicator

    ValueDescription
    CRDT Credit type transaction
    DBIT Debit type transaction

    AccountResource

    PSU account that is made available to the TPP

    Fields

    Name Type Required Restrictions Description
    name string true none Label of the PSU account
    In case of a delayed debit card transaction set, the name shall specify the holder name and the imputation date
    cashAccountType string true none Specifies the type of the account
    currency string true none Currency used for the account
    _links AccountLinks true none links that can be used for further navigation when browsing Account Information at one account level
    - balances: link to the balances of a given account
    - transactions: link to the transactions of a given account
    resourceId ResourceId false none Identifier assigned by the ASPSP for further use of the created resource through API calls
    bicFi string false none ISO20022: Code allocated to a financial institution by the ISO 9362 Registration Authority as described in ISO 9362 "Banking - Banking telecommunication messages - Business identification code (BIC)".
    accountId AccountIdentification false none Unique and unambiguous identification for the account between the account owner and the account servicer.
    details string false none Specifications that might be provided by the ASPSP
    - characteristics of the account
    - characteristics of the relevant card
    linkedAccount string false none Case of a set of pending card transactions, the APSP will provide the relevant cash account the card is set up on.
    usage string false none Specifies the usage of the account
    product string false none Product Name of the Bank for this account, proprietary definition
    balances [BalanceResource] false none list of balances provided by the ASPSP
    psuStatus string false none Relationship between the PSU and the account - Account Holder - Co-account Holder - Attorney

    Enumerated Values

    usage

    ValueDescription
    PRIV private personal account
    ORGA professional account

    cashAccountType

    ValueDescription
    CACC Cash account
    CARD List of card based transactions
    LOAN Loan account

    BalanceResource

    Structure of an account balance

    Fields

    Name Type Required Restrictions Description
    name string true none Label of the balance
    balanceAmount AmountType true none ISO20022: structure aiming to carry either an instructed amount or equivalent amount. Both structures embed the amount and the currency to be used.

    API: only instructed amount can be used
    balanceType BalanceStatus true none Type of balance
    lastChangeDateTime string(date-time) false none Timestamp of the last change of the balance amount
    referenceDate string(date) false none Reference date for the balance
    lastCommittedTransaction string false none Identification of the last committed transaction. This is actually useful for instant balance.

    PaymentRequestConfirmation

    Contains data for confirmation of payment request

    Fields

    Name Type Required Restrictions Description
    psuAuthenticationFactor string false none authentication factor forwarded by the TPP to the ASPSP in order to fulfil the strong customer authentication process

    User consent

    Name Type Required Restrictions Description
    consentStatus string false none none
    consentId string false none none
    _links ConsentLinks false none none

    PaymentInformationId

    ISO20022 : Reference assigned by a sending party to unambiguously identify the payment information block within the message.

    Fields

    Name Type Required Restrictions Description
    anonymous string false none ISO20022 : Reference assigned by a sending party to unambiguously identify the payment information block within the message.

    CreationDateTime

    ISO20022: Date and time at which a (group of) payment instruction(s) was created by the instructing party.

    Fields

    Name Type Required Restrictions Description
    anonymous string(date-time) false none ISO20022: Date and time at which a (group of) payment instruction(s) was created by the instructing party.

    FundsAvailabilityInformation

    indicator that the payment can be covered or not by the funds available on the relevant account

    Fields

    Name Type Required Restrictions Description
    anonymous boolean false read-only indicator that the payment can be covered or not by the funds available on the relevant account
    - true: payment is covered
    - false: payment is not covered

    BookingInformation

    indicator that the payment can be immediately booked or not

    Fields

    Name Type Required Restrictions Description
    anonymous boolean false read-only indicator that the payment can be immediately booked or not
    - true: payment is booked
    - false: payment is not booked

    PaymentRequestResource

    ISO20022: The PaymentRequestResource message is sent by the Creditor sending party to the Debtor receiving party, directly or through agents. It is used by a Creditor to request movement of funds from the debtor account to a creditor. API: Information about the creditor (Id, account and agent) might be placed either at payment level or at instruction level. Thus multi-beneficiary payments can be handled. The requested execution date can be placed either at payment level when all instructions are requested to be executed at the same date or at instruction level. The latest case includes:

    Fields

    Name Type Required Restrictions Description
    debtorAccount AccountIdentification true none Unique and unambiguous identification for the account between the account owner and the account servicer.
    creditTransferTransaction [CreditTransferTransaction] true none ISO20022: Payment processes required to transfer cash from the debtor to the creditor.
    API: Each ASPSP will specify a maxItems value for this field taking into accounts its specificities about payment request handling
    resourceId ResourceId false none Identifier assigned by the ASPSP for further use of the created resource through API calls
    paymentInformationId PaymentInformationId false none ISO20022 : Reference assigned by a sending party to unambiguously identify the payment information block within the message.
    creationDateTime CreationDateTime false none ISO20022: Date and time at which a (group of) payment instruction(s) was created by the instructing party.
    initiatingParty PartyIdentification false none API : Description of a Party which can be either a person or an organization.
    paymentTypeInformation PaymentTypeInformation false none ISO20022: Set of elements used to further specify the type of transaction.
    debtor PartyIdentification false none API : Description of a Party which can be either a person or an organization.
    debtorAgent FinancialInstitutionIdentification false none ISO20022: Unique and unambiguous identification of a financial institution, as assigned under an internationally recognised or proprietary identification scheme.
    beneficiary Beneficiary false none Specification of a beneficiary
    purpose PurposeCode false none ISO20022: Underlying reason for the payment transaction, as published in an external purpose code list.
    chargeBearer ChargeBearerCode false none ISO20022: Specifies which party/parties will bear the charges associated with the processing of the payment transaction.
    paymentInformationStatus PaymentInformationStatusCode false none ISO20022: Specifies the status of the payment information.
    statusReasonInformation StatusReasonInformation false none ISO20022: Provides detailed information on the status reason. Can only be used in status equal to "RJCT".
    fundsAvailability FundsAvailabilityInformation false none indicator that the payment can be covered or not by the funds available on the relevant account
    - true: payment is covered
    - false: payment is not covered
    booking BookingInformation false none indicator that the payment can be immediately booked or not
    - true: payment is booked
    - false: payment is not booked
    requestedExecutionDate string(date-time) false none ISO20022: Date at which the initiating party requests the clearing agent to process the payment.

    PaymentCoverageRequestResource

    Payment coverage request structure. The request must rely either on a cash account or a payment card.

    Fields

    Name Type Required Restrictions Description
    paymentCoverageRequestId string true none Identification of the payment Coverage Request
    instructedAmount AmountType true none ISO20022: structure aiming to carry either an instructed amount or equivalent amount. Both structures embed the amount and the currency to be used.

    API: only instructed amount can be used
    accountId AccountIdentification true none Unique and unambiguous identification for the account between the account owner and the account servicer.
    payee string false none The merchant where the card is accepted as information to the PSU.

    HalAccounts

    HYPERMEDIA structure used for returning the list of the available accounts to the AISP

    Fields

    Name Type Required Restrictions Description
    accounts [AccountResource] true none List of PSU account that are made available to the TPP
    _links PsuContextLinks true none Links that can be used for further navigation when browsing Account Information at top level
    - self: link to the list of all available accounts
    connectedPsu string false none Last name and first name that has granted access to the AISP on the accounts data
    This information can be retrieved based on the PSU's authentication that occurred during the OAUTH2 access token initialisation.

    HalBalances

    HYPERMEDIA structure used for returning the list of the relevant balances for a given account to the AISP

    Fields

    Name Type Required Restrictions Description
    balances [BalanceResource] true none List of account balances
    _links BalancesLinks true none links that can be used for further navigation when browsing Account Information at one account level
    - self: link to the balances of a given account
    - parent-list: link to the list of all available accounts
    - transactions: link to the transactions of a given account

    HalTransactions

    HYPERMEDIA structure used for returning the list of the transactions for a given account to the AISP

    Fields

    Name Type Required Restrictions Description
    transactions [Transaction] true none List of transactions
    _links TransactionsLinks true none links that can be used for further navigation when browsing Account Information at one account level
    - self: link to the transactions of a given account
    - parent-list: link to the list of all available accounts
    - balances: link to the balances of a given account
    - first: link to the first page of the transactions result
    - last: link to the last page of the transactions result
    - next: link to the next page of the transactions result
    - prev: link to the previous page of the transactions result

    HalPaymentRequest

    HYPERMEDIA structure used for returning the original Payment Request to the PISP

    Fields

    Name Type Required Restrictions Description
    paymentRequest PaymentRequestResource true none ISO20022: The PaymentRequestResource message is sent by the Creditor sending party to the Debtor receiving party, directly or through agents. It is used by a Creditor to request movement of funds from the debtor account to a creditor.
    API:
    Information about the creditor (Id, account and agent) might be placed either at payment level or at instruction level. Thus multi-beneficiary payments can be handled.
    The requested execution date can be placed either at payment level when all instructions are requested to be executed at the same date or at instruction level.
    The latest case includes:
    - multiple instructions having different requested execution dates
    - standing orders settings
    _links PaymentRequestLinks true none links that can be used for further navigation when having post a Payment Request in order to get the relevant status report.

    HalPaymentRequestCreation

    data forwarded by the ASPSP to the PISP after creation of the Payment Request resource creation

    Fields

    Name Type Required Restrictions Description
    paymentRequestResourceId ResourceId false none Identifier assigned by the ASPSP for further use of the created resource through API calls
    appliedAuthenticationApproach AuthenticationApproach false none The ASPSP, based on the authentication approaches proposed by the PISP, choose the one that it can processed, in respect with the preferences and constraints of the PSU and indicates in this field which approach has been chosen
    _links PaymentRequestResourceCreationLinks false none links that can be used for further navigation, especially in REDIRECT approach

    HalPaymentCoverageReport

    HYPERMEDIA structure used for returning the payment coverage report to the PIISP

    Fields

    Name Type Required Restrictions Description
    request PaymentCoverageRequestResource true none Payment coverage request structure. The request must rely either on a cash account or a payment card.
    result boolean true none Result of the coverage check :
    - true: the payment can be covered
    - false: the payment cannot be covered
    _links PaymentCoverageReportLinks true none links that can be used for further navigation to post another coverage request.

    Beneficiary

    Specification of a beneficiary

    Fields

    Name Type Required Restrictions Description
    creditorAccount AccountIdentification true none Unique and unambiguous identification for the account between the account owner and the account servicer.
    id string false none Id of the beneficiary
    isTrusted boolean false none The ASPSP having not implemented the trusted beneficiaries list must not set this flag.
    Otherwise, the ASPSP indicates whether or not the beneficiary has been registered by the PSU within the trusted beneficiaries list.
    - true: the beneficiary is actually a trusted beneficiary (when set by ASPSP)
    - false: the beneficiary is not a trusted beneficiary
    The PISP may set this flag to "true" to indicate that the PSU considers the beneficiary as trusted and to be inserted within the trusted beneficiaries list, as far as this feature was implemented by the ASPSP.
    - true: the beneficiary should be registered as a trusted beneficiary (when set by PISP)
    creditorAgent FinancialInstitutionIdentification false none ISO20022: Unique and unambiguous identification of a financial institution, as assigned under an internationally recognised or proprietary identification scheme.
    creditor PartyIdentification false none API : Description of a Party which can be either a person or an organization.

    HalBeneficiaries

    HYPERMEDIA structure used for returning the list of the whitelisted beneficiaries

    Fields

    Name Type Required Restrictions Description
    beneficiaries [Beneficiary] true none List of trusted beneficiaries
    _links BeneficiariesLinks true none links that can be used for further navigation when browsing Account Information at one account level
    - self: link to the beneficiaries
    - parent-list: link to the list of all available accounts
    - first: link to the first page of the beneficiaries result
    - last: link to the last page of the beneficiaries result
    - next: link to the next page of the beneficiaries result
    - prev: link to the previous page of the beneficiaries result

    AccessibleAccounts

    List of accessible accounts for one given functionality

    Fields

    Name Type Required Restrictions Description
    anonymous [AccountIdentification] false none List of accessible accounts for one given functionality

    Access

    Requested access services.

    Fields

    Name Type Required Restrictions Description
    balances AccessibleAccounts true none List of accessible accounts for one given functionality
    transactions AccessibleAccounts true none List of accessible accounts for one given functionality
    trustedBeneficiaries boolean false none Indicator that access to the trusted beneficiaries list was granted or not to the AISP by the PSU
    - true: the access was granted
    - false: the access was not granted
    psuIdentity boolean false none Indicator that access to the PSU identity, first name and last name, was granted or not to the AISP by the PSU
    - true: the access was granted
    - false: the access was not granted
    recurringIndicator boolean false none - true: the consent is for recurring access to the account data.
    - false: the consent is for one access to the account data.
    validUntil string(date) false none This parameter is requesting a valid until date for the requested consent.
    The content is the local ASPSP date in ISO-Date Format, e.g. 2017-10-30.
    Future dates might get adjusted by ASPSP.
    frequencyPerDay integer false none This field indicates the requested maximum frequency for an access without PSU involvement per day.
    For a one-off access, this attribute is set to "1".
    The frequency needs to be greater equal to one.
    combinedServiceIndicator boolean false none If "true" indicates that a payment initiation service will be addressed in the same "session".

    HAL

    hypertext reference

    Name Type Required Restrictions Description
    href string true none URI to be used
    templated boolean false none specifies "true" if href is a URI template, i.e. with parameters. Otherwise, this property is absent or set to false

    Links that can be used for further navigation when browsing Account Information at top level

    Name Type Required Restrictions Description
    self GenericLink true none hypertext reference
    beneficiaries GenericLink false none hypertext reference
    first GenericLink false none hypertext reference
    last GenericLink false none hypertext reference
    next GenericLink false none hypertext reference
    prev GenericLink false none hypertext reference

    links that can be used for further navigation when browsing Account Information at one account level

    Name Type Required Restrictions Description
    balances GenericLink false none hypertext reference
    transactions GenericLink false none hypertext reference

    links that can be used for further navigation when browsing Account Information at one account level

    Name Type Required Restrictions Description
    self GenericLink true none hypertext reference
    parent-list GenericLink false none hypertext reference
    transactions GenericLink false none hypertext reference

    links that can be used for further navigation when browsing Account Information at one account level

    Name Type Required Restrictions Description
    self GenericLink true none hypertext reference
    parent-list GenericLink false none hypertext reference
    balances GenericLink false none hypertext reference
    first GenericLink false none hypertext reference
    last GenericLink false none hypertext reference
    next GenericLink false none hypertext reference
    prev GenericLink false none hypertext reference

    links that can be used for further navigation when browsing Account Information at one account level

    Name Type Required Restrictions Description
    self GenericLink true none hypertext reference
    parent-list GenericLink false none hypertext reference
    first GenericLink false none hypertext reference
    last GenericLink false none hypertext reference
    next GenericLink false none hypertext reference
    prev GenericLink false none hypertext reference

    links that can be used for further navigation when having post a Payment Request in order to get the relevant status report.

    Name Type Required Restrictions Description
    self GenericLink false none hypertext reference
    confirmation GenericLink false none hypertext reference

    links that can be used for further navigation to post another coverage request.

    Name Type Required Restrictions Description
    self GenericLink true none hypertext reference

    links that can be used for further navigation, especially in REDIRECT approach

    Name Type Required Restrictions Description
    consentApproval GenericLink false none hypertext reference
    confirmation GenericLink false none hypertext reference

    Name Type Required Restrictions Description
    redirect GenericLink false none hypertext reference
    self GenericLink false none hypertext reference
    status GenericLink false none hypertext reference

    Exceptions

    HttpError

    Generic communication error report structure

    Fields

    Name Type Required Restrictions Description
    status integer(int32) true none HTTP error code
    message string true none HTTP textual reason phrase
    timestamp string(date-time) false none current timestamp
    error string false none HTTP error text
    path string false none Relevant path that was used