| AccountAccess
|
Requested access services for a consent.
|
| AccountDetails
|
The ASPSP shall give at least one of the account reference identifiers: - iban - bban - pan - maskedPan - msisdn If the account is a multicurrency account currency code in \"currency\" is set to \"XXX\".
|
| AccountList
|
List of accounts with details.
|
| AccountReference
|
Reference to an account by either * IBAN, of a payment accounts, or * BBAN, for payment accounts if there is no IBAN, or * the Primary Account Number (PAN) of a card, can be tokenised by the ASPSP due to PCI DSS requirements, or * the Primary Account Number (PAN) of a card in a masked form, or * an alias to access a payment account via a registered mobile phone number (MSISDN).
|
| AccountReport
|
JSON based account report. This account report contains transactions
resulting from the query parameters. 'booked' shall be contained if
bookingStatus parameter is set to \"booked\" or \"both\". 'pending' is not
contained if the bookingStatus parameter is set to \"booked\".
|
| AccountReport
|
JSON based account report. This account report contains transactions resulting from the query parameters. 'booked' shall be contained if bookingStatus parameter is set to \"booked\" or \"both\". 'pending' is not contained if the bookingStatus parameter is set to \"booked\".
|
| AccountStatus
|
Account status. The value is one of the following: - \"enabled\": account is available - \"deleted\": account is terminated - \"blocked\": account is blocked e.g. for legal reasons If this field is not used, than the account is available in the sense of this specification.
|
| AdditionalInformationAccess
|
Optional if supported by API provider. Is asking for additional information as added within this structured object. The usage of this data element requires at least one of the entries \"accounts\", \"transactions\" or \"balances\" also to be contained in the object. If detailed accounts are referenced, it is required in addition that any account addressed within the additionalInformation attribute is also addressed by at least one of the attributes \"accounts\", \"transactions\" or \"balances\".
|
| AdditionalInformationStructured
|
Is used if and only if the bookingStatus entry equals \"information\". Every active standing order related to the dedicated payment account result into one entry.
|
| Address
|
|
| AllPsd2Enum
|
|
| Amount
|
|
| AuthenticationObject
|
Authentication object.
|
| AuthenticationType
|
Type of the authentication method. More authentication types might be added during implementation projects and documented in the ASPSP documentation. - 'SMS_OTP': An SCA method, where an OTP linked to the transaction to be authorised is sent to the PSU through a SMS channel. - 'CHIP_OTP': An SCA method, where an OTP is generated by a chip card, e.g. a TOP derived from an EMV cryptogram. To contact the card, the PSU normally needs a (handheld) device. With this device, the PSU either reads the challenging data through a visual interface like flickering or the PSU types in the challenge through the device key pad. The device then derives an OTP from the challenge data and displays the OTP to the PSU. - 'PHOTO_OTP': An SCA method, where the challenge is a QR code or similar encoded visual data which can be read in by a consumer device or specific mobile app. The device resp. the specific app than derives an OTP from the visual challenge data and displays the OTP to the PSU. - 'PUSH_OTP': An OTP is pushed to a dedicated authentication APP and displayed to the PSU.
|
| AuthorisationConfirmation
|
Content of the body of an authorisation confirmation request
|
| AuthorisationConfirmationResponse
|
Body of the JSON response for an authorisation confirmation request.
|
| Authorisations
|
An array of all authorisationIds.
|
| AvailableAccountsEnum
|
|
| AvailableAccountsWithBalanceEnum
|
|
| Balance
|
A single balance element.
|
| BalanceType
|
The following balance types are defined: - \"closingBooked\": Balance of the account at the end of the pre-agreed account reporting period. It is the sum of the opening booked balance at the beginning of the period and all entries booked to the account during the pre-agreed account reporting period. For card-accounts, this is composed of - invoiced, but not yet paid entries - \"expected\": Balance composed of booked entries and pending items known at the time of calculation, which projects the end of day balance if everything is booked on the account and no other entry is posted. For card accounts, this is composed of: - invoiced, but not yet paid entries - not yet invoiced but already booked entries and - pending items (not yet booked) For card-accounts: \"money to spend with the value of a pre-approved credit limit on the card account\" - \"openingBooked\": Book balance of the account at the beginning of the account reporting period. It always equals the closing book balance from the previous report. - \"interimAvailable\": Available balance calculated in the course of the account ?servicer?s business day, at the time specified, and subject to further changes during the business day. The interim balance is calculated on the basis of booked credit and debit items during the calculation time/period specified. For card-accounts, this is composed of: - invoiced, but not yet paid entries - not yet invoiced but already booked entries - \"interimBooked\": Balance calculated in the course of the account servicer's business day, at the time specified, and subject to further changes during the business day. The interim balance is calculated on the basis of booked credit and debit items during the calculation time/period specified. - \"forwardAvailable\": Forward available balance of money that is at the disposal of the account owner on the date specified. - \"nonInvoiced\": Only for card accounts, to be checked yet.
|
| BulkPaymentInitiationJson
|
Generic Body for a bulk payment initiation via JSON. paymentInformationId is contained in code but commented since it is n.a. and not all ASPSP are able to support this field now. In a later version the field will be mandatory.
|
| BulkPaymentInitiationWithStatusResponse
|
Generic JSON response body consistion of the corresponding bulk payment initiation JSON body together with an optional transaction status field.
|
| Cancellations
|
An array of all cancellationIds.
|
| CardAccountDetails
|
Card account details.
|
| CardAccountList
|
List of card accounts with details.
|
| CardAccountReport
|
JSON based card account report. This card account report contains transactions resulting from the query parameters.
|
| CardAccountsTransactionsResponse200
|
Body of the JSON response for a successful read card account transaction list request. This card account report contains transactions resulting from the query parameters.
|
| CardTransaction
|
Card transaction information.
|
| ChallengeData
|
It is contained in addition to the data element 'chosenScaMethod' if challenge data is needed for SCA. In rare cases this attribute is also used in the context of the 'startAuthorisationWithPsuAuthentication' link.
|
| ConfirmationOfFunds
|
JSON Request body for the \"Confirmation of funds service\". | cardNumber | String | Optional | Card Number of the card issued by the PIISP. Should be delivered if available. | | account | Account Reference | Mandatory | PSU's account number. | | payee | Max70Text | Optional | The merchant where the card is accepted as an information to the PSU. | | instructedAmount | Amount | Mandatory | Transaction amount to be checked within the funds check mechanism. |
|
| ConsentInformationResponse200Json
|
Body of the JSON response for a successfull get consent request.
|
| ConsentStatus
|
This is the overall lifecycle status of the consent. Valid values are: - 'received': The consent data have been received and are technically correct. The data is not authorised yet. - 'rejected': The consent data have been rejected e.g. since no successful authorisation has taken place. - 'valid': The consent is accepted and valid for GET account data calls and others as specified in the consent object. - 'revokedByPsu': The consent has been revoked by the PSU towards the ASPSP. - 'expired': The consent expired. - 'terminatedByTpp': The corresponding TPP has terminated the consent by applying the DELETE method to the consent resource. - 'partiallyAuthorised': The consent is due to a multi-level authorisation, some but not all mandated authorisations have been performed yet. The ASPSP might add further codes. These codes then shall be contained in the ASPSP's documentation of the XS2A interface and has to be added to this API definition as well.
|
| ConsentStatusResponse200
|
Body of the JSON response for a successful get status request for a consent.
|
| Consents
|
Content of the body of a consent request.
|
| ConsentsResponse201
|
Body of the JSON response for a successful consent request.
|
| DayOfExecution
|
Day of execution as string. This string consists of up two characters. Leading zeroes are not allowed. 31 is ultimo of the month.
|
| Error400AIS
|
Standardised definition of reporting error information according to [RFC7807] in case of a HTTP error code 400 for AIS.
|
| Error400AISAdditionalErrors
|
This is a data element to support the declaration of additional errors in the context of [RFC7807].
|
| Error400NGAIS
|
NextGenPSD2 specific definition of reporting error information in case of a HTTP error code 400.
|
| Error400NGPIIS
|
NextGenPSD2 specific definition of reporting error information in case of a HTTP error code 400.
|
| Error400NGPIS
|
NextGenPSD2 specific definition of reporting error information in case of a HTTP error code 400.
|
| Error400NGSBS
|
NextGenPSD2 specific definition of reporting error information in case of a HTTP error code 400.
|
| Error400PIIS
|
Standardised definition of reporting error information according to [RFC7807] in case of a HTTP error code 400 for PIIS.
|
| Error400PIISAdditionalErrors
|
This is a data element to support the declaration of additional errors in the context of [RFC7807].
|
| Error400PIS
|
Standardised definition of reporting error information according to [RFC7807] in case of a HTTP error code 400 for PIS.
|
| Error400PISAdditionalErrors
|
This is a data element to support the declaration of additional errors in the context of [RFC7807].
|
| Error400SBS
|
Standardised definition of reporting error information according to [RFC7807] in case of a HTTP error code 400 for signing baskets.
|
| Error400SBSAdditionalErrors
|
This is a data element to support the declaration of additional errors in the context of [RFC7807].
|
| Error401AIS
|
Standardised definition of reporting error information according to [RFC7807] in case of a HTTP error code 401 for AIS.
|
| Error401AISAdditionalErrors
|
This is a data element to support the declaration of additional errors in the context of [RFC7807].
|
| Error401NGAIS
|
NextGenPSD2 specific definition of reporting error information in case of a HTTP error code 401.
|
| Error401NGPIIS
|
NextGenPSD2 specific definition of reporting error information in case of a HTTP error code 401.
|
| Error401NGPIS
|
NextGenPSD2 specific definition of reporting error information in case of a HTTP error code 401.
|
| Error401NGSBS
|
NextGenPSD2 specific definition of reporting error information in case of a HTTP error code 401.
|
| Error401PIIS
|
Standardised definition of reporting error information according to [RFC7807] in case of a HTTP error code 401 for PIIS.
|
| Error401PIISAdditionalErrors
|
This is a data element to support the declaration of additional errors in the context of [RFC7807].
|
| Error401PIS
|
Standardised definition of reporting error information according to [RFC7807] in case of a HTTP error code 401 for PIS.
|
| Error401PISAdditionalErrors
|
This is a data element to support the declaration of additional errors in the context of [RFC7807].
|
| Error401SBS
|
Standardised definition of reporting error information according to [RFC7807] in case of a HTTP error code 401 for signing baskets.
|
| Error401SBSAdditionalErrors
|
This is a data element to support the declaration of additional errors in the context of [RFC7807].
|
| Error403AIS
|
Standardised definition of reporting error information according to [RFC7807] in case of a HTTP error code 403 for AIS.
|
| Error403AISAdditionalErrors
|
This is a data element to support the declaration of additional errors in the context of [RFC7807].
|
| Error403NGAIS
|
NextGenPSD2 specific definition of reporting error information in case of a HTTP error code 403.
|
| Error403NGPIIS
|
NextGenPSD2 specific definition of reporting error information in case of a HTTP error code 403.
|
| Error403NGPIS
|
NextGenPSD2 specific definition of reporting error information in case of a HTTP error code 403.
|
| Error403NGSBS
|
NextGenPSD2 specific definition of reporting error information in case of a HTTP error code 403.
|
| Error403PIIS
|
Standardised definition of reporting error information according to [RFC7807] in case of a HTTP error code 403 for PIIS.
|
| Error403PIISAdditionalErrors
|
This is a data element to support the declaration of additional errors in the context of [RFC7807].
|
| Error403PIS
|
Standardised definition of reporting error information according to [RFC7807] in case of a HTTP error code 403 for PIS.
|
| Error403PISAdditionalErrors
|
This is a data element to support the declaration of additional errors in the context of [RFC7807].
|
| Error403SBS
|
Standardised definition of reporting error information according to [RFC7807] in case of a HTTP error code 403 for signing baskets.
|
| Error403SBSAdditionalErrors
|
This is a data element to support the declaration of additional errors in the context of [RFC7807].
|
| Error404AIS
|
Standardised definition of reporting error information according to [RFC7807] in case of a HTTP error code 404 for AIS.
|
| Error404AISAdditionalErrors
|
This is a data element to support the declaration of additional errors in the context of [RFC7807].
|
| Error404NGAIS
|
NextGenPSD2 specific definition of reporting error information in case of a HTTP error code 404.
|
| Error404NGPIIS
|
NextGenPSD2 specific definition of reporting error information in case of a HTTP error code 404.
|
| Error404NGPIS
|
NextGenPSD2 specific definition of reporting error information in case of a HTTP error code 404.
|
| Error404NGSBS
|
NextGenPSD2 specific definition of reporting error information in case of a HTTP error code 404.
|
| Error404PIIS
|
Standardised definition of reporting error information according to [RFC7807] in case of a HTTP error code 404 for PIIS.
|
| Error404PIISAdditionalErrors
|
This is a data element to support the declaration of additional errors in the context of [RFC7807].
|
| Error404PIS
|
Standardised definition of reporting error information according to [RFC7807] in case of a HTTP error code 404 for PIS.
|
| Error404PISAdditionalErrors
|
This is a data element to support the declaration of additional errors in the context of [RFC7807].
|
| Error404SBS
|
Standardised definition of reporting error information according to [RFC7807] in case of a HTTP error code 404 for signing baskets.
|
| Error404SBSAdditionalErrors
|
This is a data element to support the declaration of additional errors in the context of [RFC7807].
|
| Error405AIS
|
Standardised definition of reporting error information according to [RFC7807] in case of a HTTP error code 405 for AIS.
|
| Error405AISAdditionalErrors
|
This is a data element to support the declaration of additional errors in the context of [RFC7807].
|
| Error405NGAIS
|
NextGenPSD2 specific definition of reporting error information in case of a HTTP error code 401.
|
| Error405NGPIIS
|
NextGenPSD2 specific definition of reporting error information in case of a HTTP error code 401.
|
| Error405NGPIS
|
NextGenPSD2 specific definition of reporting error information in case of a HTTP error code 401.
|
| Error405NGPISCANC
|
NextGenPSD2 specific definition of reporting error information in case of a HTTP error code 401.
|
| Error405NGSBS
|
NextGenPSD2 specific definition of reporting error information in case of a HTTP error code 401.
|
| Error405PIIS
|
Standardised definition of reporting error information according to [RFC7807] in case of a HTTP error code 405 for PIIS.
|
| Error405PIISAdditionalErrors
|
This is a data element to support the declaration of additional errors in the context of [RFC7807].
|
| Error405PIS
|
Standardised definition of reporting error information according to [RFC7807] in case of a HTTP error code 405 for PIS.
|
| Error405PISAdditionalErrors
|
This is a data element to support the declaration of additional errors in the context of [RFC7807].
|
| Error405PISCANC
|
Standardised definition of reporting error information according to [RFC7807] in case of a HTTP error code 405 for a pament cancelation (PIS).
|
| Error405PISCANCAdditionalErrors
|
This is a data element to support the declaration of additional errors in the context of [RFC7807].
|
| Error405SBS
|
Standardised definition of reporting error information according to [RFC7807] in case of a HTTP error code 405 for signing baskets.
|
| Error405SBSAdditionalErrors
|
This is a data element to support the declaration of additional errors in the context of [RFC7807].
|
| Error406AIS
|
Standardised definition of reporting error information according to [RFC7807] in case of a HTTP error code 406 for AIS.
|
| Error406AISAdditionalErrors
|
This is a data element to support the declaration of additional errors in the context of [RFC7807].
|
| Error406NGAIS
|
NextGenPSD2 specific definition of reporting error information in case of a HTTP error code 406.
|
| Error409AIS
|
Standardised definition of reporting error information according to [RFC7807] in case of a HTTP error code 409 for AIS.
|
| Error409AISAdditionalErrors
|
This is a data element to support the declaration of additional errors in the context of [RFC7807].
|
| Error409NGAIS
|
NextGenPSD2 specific definition of reporting error information in case of a HTTP error code 409.
|
| Error409NGPIIS
|
NextGenPSD2 specific definition of reporting error information in case of a HTTP error code 409.
|
| Error409NGPIS
|
NextGenPSD2 specific definition of reporting error information in case of a HTTP error code 409.
|
| Error409NGSBS
|
NextGenPSD2 specific definition of reporting error information in case of a HTTP error code 409.
|
| Error409PIIS
|
Standardised definition of reporting error information according to [RFC7807] in case of a HTTP error code 409 for PIIS.
|
| Error409PIISAdditionalErrors
|
This is a data element to support the declaration of additional errors in the context of [RFC7807].
|
| Error409PIS
|
Standardised definition of reporting error information according to [RFC7807] in case of a HTTP error code 409 for PIS.
|
| Error409PISAdditionalErrors
|
This is a data element to support the declaration of additional errors in the context of [RFC7807].
|
| Error409SBS
|
Standardised definition of reporting error information according to [RFC7807] in case of a HTTP error code 409 for signing baskets.
|
| Error409SBSAdditionalErrors
|
This is a data element to support the declaration of additional errors in the context of [RFC7807].
|
| Error429AIS
|
Standardised definition of reporting error information according to [RFC7807] in case of a HTTP error code 429 for AIS.
|
| Error429AISAdditionalErrors
|
This is a data element to support the declaration of additional errors in the context of [RFC7807] in case of a HTTP error code 429 for.
|
| Error429NGAIS
|
NextGenPSD2 specific definition of reporting error information in case of a HTTP error code 429.
|
| ExecutionRule
|
\"following\" or \"preceding\" supported as values. 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.
|
| FrequencyCode
|
The following codes from the \"EventFrequency7Code\" of ISO 20022 are supported: - \"Daily\" - \"Weekly\" - \"EveryTwoWeeks\" - \"Monthly\" - \"EveryTwoMonths\" - \"Quarterly\" - \"SemiAnnual\" - \"Annual\" - \"MonthlyVariable\"
|
| HrefType
|
Link to a resource.
|
| InlineResponse200
|
|
| InlineResponse2001
|
|
| InlineResponse2002
|
|
| InlineResponse2003
|
Equals \"true\" if sufficient funds are available at the time of the request, \"false\" otherwise.
|
| LinksAccountDetails
|
Links to the account, which can be directly used for retrieving account information from this dedicated account. Links to \"balances\" and/or \"transactions\" These links are only supported, when the corresponding consent has been already granted.
|
| LinksAccountReport
|
|
| LinksAll
|
A _link object with all available link types.
|
| LinksAuthorisationConfirmation
|
A list of hyperlinks to be recognised by the TPP. The actual hyperlinks used in the response depend on the dynamical decisions of the ASPSP when processing the request. **Remark:** All links can be relative or full links, to be decided by the ASPSP. Type of links admitted in this response, (further links might be added for ASPSP defined extensions): - 'scaStatus': The link to retrieve the status of the corresponding transaction resource.
|
| LinksCardAccountReport
|
|
| LinksConsents
|
A list of hyperlinks to be recognised by the TPP. Type of links admitted in this response (which might be extended by single ASPSPs as indicated in its XS2A documentation): * 'scaRedirect': In case of an SCA Redirect Approach, the ASPSP is transmitting the link to which to redirect the PSU browser. * 'scaOAuth': In case of an OAuth2 based Redirect Approach, the ASPSP is transmitting the link where the configuration of the OAuth2 Server is defined. The configuration follows the OAuth 2.0 Authorisation Server Metadata specification. * 'confirmation': Might be added by the ASPSP if either the \"scaRedirect\" or \"scaOAuth\" hyperlink is returned in the same response message. This hyperlink defines the URL to the resource which needs to be updated with * a confirmation code as retrieved after the plain redirect authentication process with the ASPSP authentication server or * an access token as retrieved by submitting an authorization code after the integrated OAuth based authentication process with the ASPSP authentication server. * 'startAuthorisation': In case, where an explicit start of the transaction authorisation is needed, but no more data needs to be updated (no authentication method to be selected, no PSU identification nor PSU authentication data to be uploaded). * 'startAuthorisationWithPsuIdentification': The link to the authorisation end-point, where the authorisation sub-resource has to be generated while uploading the PSU identification data. * 'startAuthorisationWithPsuAuthentication': The link to the authorisation end-point, where the authorisation sub-resource has to be generated while uploading the PSU authentication data. * 'startAuthorisationWithEncryptedPsuAuthentication': Same as startAuthorisactionWithPsuAuthentication where the authentication data need to be encrypted on application layer in uploading. * 'startAuthorisationWithAuthenticationMethodSelection': The link to the authorisation end-point, where the authorisation sub-resource has to be generated while selecting the authentication method. This link is contained under exactly the same conditions as the data element 'scaMethods' * 'startAuthorisationWithTransactionAuthorisation': The link to the authorisation end-point, where the authorisation sub-resource has to be generated while authorising the transaction e.g. by uploading an OTP received by SMS. * 'self': The link to the Establish Account Information Consent resource created by this request. This link can be used to retrieve the resource data. * 'status': The link to retrieve the status of the account information consent. * 'scaStatus': The link to retrieve the scaStatus of the corresponding authorisation sub-resource. This link is only contained, if an authorisation sub-resource has been already created.
|
| LinksDownload
|
A list of hyperlinks to be recognised by the TPP. Type of links admitted in this response: - \"download\": a link to a resource, where the transaction report might be downloaded from in case where transaction reports have a huge size. Remark: This feature shall only be used where camt-data is requested which has a huge size.
|
| LinksGetConsent
|
A list of hyperlinks to be recognised by the TPP. Links of type \"account\" and/or \"cardAccount\", depending on the nature of the consent.
|
| LinksPaymentInitiation
|
A list of hyperlinks to be recognised by the TPP. The actual hyperlinks used in the response depend on the dynamical decisions of the ASPSP when processing the request. **Remark:** All links can be relative or full links, to be decided by the ASPSP. Type of links admitted in this response, (further links might be added for ASPSP defined extensions): * 'scaRedirect': In case of an SCA Redirect Approach, the ASPSP is transmitting the link to which to redirect the PSU browser. * 'scaOAuth': In case of a SCA OAuth2 Approach, the ASPSP is transmitting the URI where the configuration of the Authorisation Server can be retrieved. The configuration follows the OAuth 2.0 Authorisation Server Metadata specification. * 'confirmation': Might be added by the ASPSP if either the \"scaRedirect\" or \"scaOAuth\" hyperlink is returned in the same response message. This hyperlink defines the URL to the resource which needs to be updated with * a confirmation code as retrieved after the plain redirect authentication process with the ASPSP authentication server or * an access token as retrieved by submitting an authorization code after the integrated OAuth based authentication process with the ASPSP authentication server. * 'startAuthorisation': In case, where an explicit start of the transaction authorisation is needed, but no more data needs to be updated (no authentication method to be selected, no PSU identification nor PSU authentication data to be uploaded). * 'startAuthorisationWithPsuIdentification': The link to the authorisation end-point, where the authorisation sub-resource has to be generated while uploading the PSU identification data. * 'startAuthorisationWithPsuAuthentication': The link to the authorisation end-point, where the authorisation sub-resource has to be generated while uploading the PSU authentication data. * 'startAuthorisationWithEncryptedPsuAuthentication': Same as startAuthorisactionWithPsuAuthentication where the authentication data need to be encrypted on application layer in uploading. * 'startAuthorisationWithAuthenticationMethodSelection': The link to the authorisation end-point, where the authorisation sub-resource has to be generated while selecting the authentication method. This link is contained under exactly the same conditions as the data element \"scaMethods\" * 'startAuthorisationWithTransactionAuthorisation': The link to the authorisation end-point, where the authorisation sub-resource has to be generated while authorising the transaction e.g. by uploading an OTP received by SMS. * 'self': The link to the payment initiation resource created by this request. This link can be used to retrieve the resource data. * 'status': The link to retrieve the transaction status of the payment initiation. * 'scaStatus': The link to retrieve the scaStatus of the corresponding authorisation sub-resource. This link is only contained, if an authorisation sub-resource has been already created.
|
| LinksPaymentInitiationCancel
|
A list of hyperlinks to be recognised by the TPP. The actual hyperlinks used in the response depend on the dynamical decisions of the ASPSP when processing the request. Remark: All links can be relative or full links, to be decided by the ASPSP. Type of links admitted in this response, (further links might be added for ASPSP defined extensions): * 'startAuthorisation': In case, where just the authorisation process of the cancellation needs to be started, but no additional data needs to be updated for time being (no authentication method to be selected, no PSU identification nor PSU authentication data to be uploaded). * 'startAuthorisationWithPsuIdentification': In case where a PSU identification needs to be updated when starting the cancellation authorisation: The link to the cancellation-authorisations end-point, where the cancellation sub-resource has to be generated while uploading the PSU identification data. * 'startAuthorisationWithPsuAuthentication': In case of a yet to be created authorisation sub-resource: The link to the cancelation authorisation end-point, where the authorisation sub-resource has to be generated while uploading the PSU authentication data. * 'startAuthorisationWithEncryptedPsuAuthentication': Same as startAuthorisactionWithPsuAuthentication where the authentication data need to be encrypted on application layer in uploading. * 'startAuthorisationWithAuthenticationMethodSelection': The link to the authorisation end-point, where the cancellation-authorisation sub-resource has to be generated while selecting the authentication method. This link is contained under exactly the same conditions as the data element 'scaMethods'
|
| LinksSelectPsuAuthenticationMethod
|
A list of hyperlinks to be recognised by the TPP. The actual hyperlinks used in the response depend on the dynamical decisions of the ASPSP when processing the request. **Remark:** All links can be relative or full links, to be decided by the ASPSP. **Remark:** This method can be applied before or after PSU identification. This leads to many possible hyperlink responses. Type of links admitted in this response, (further links might be added for ASPSP defined extensions): - 'scaRedirect': In case of an SCA Redirect Approach, the ASPSP is transmitting the link to which to redirect the PSU browser. - 'scaOAuth': In case of a SCA OAuth2 Approach, the ASPSP is transmitting the URI where the configuration of the Authorisation Server can be retrieved. The configuration follows the OAuth 2.0 Authorisation Server Metadata specification. * 'confirmation': Might be added by the ASPSP if either the \"scaRedirect\" or \"scaOAuth\" hyperlink is returned in the same response message. This hyperlink defines the URL to the resource which needs to be updated with * a confirmation code as retrieved after the plain redirect authentication process with the ASPSP authentication server or * an access token as retrieved by submitting an authorization code after the integrated OAuth based authentication process with the ASPSP authentication server. - 'updatePsuIdentification': The link to the authorisation or cancellation authorisation sub-resource, where PSU identification data needs to be uploaded. - 'updatePsuAuthentication': The link to the authorisation or cancellation authorisation sub-resource, where PSU authentication data needs to be uploaded. - 'updateEncryptedPsuAuthentication': The link to the authorisation or cancellation authorisation sub-resource, where PSU authentication encrypted data needs to be uploaded. - 'updateAdditionalPsuAuthentication': The link to the payment initiation or account information resource, which needs to be updated by an additional PSU password. - 'updateAdditionalEncryptedPsuAuthentication': The link to the payment initiation or account information resource, which needs to be updated by an additional encrypted PSU password. - 'authoriseTransaction': The link to the authorisation or cancellation authorisation sub-resource, where the authorisation data has to be uploaded, e.g. the TOP received by SMS. - 'scaStatus': The link to retrieve the scaStatus of the corresponding authorisation sub-resource.
|
| LinksSigningBasket
|
A list of hyperlinks to be recognised by the TPP. The actual hyperlinks used in the response depend on the dynamical decisions of the ASPSP when processing the request. Remark: All links can be relative or full links, to be decided by the ASPSP. Type of links admitted in this response, (further links might be added for ASPSP defined extensions): * 'scaRedirect': In case of an SCA Redirect Approach, the ASPSP is transmitting the link to which to redirect the PSU browser. * 'scaOAuth': In case of a SCA OAuth2 Approach, the ASPSP is transmitting the URI where the configuration of the Authorisation Server can be retrieved. The configuration follows the OAuth 2.0 Authorisation Server Metadata specification. * 'startAuthorisation': In case, where an explicit start of the transaction authorisation is needed, but no more data needs to be updated (no authentication method to be selected, no PSU identification nor PSU authentication data to be uploaded). * 'startAuthorisationWithPsuIdentification': The link to the authorisation end-point, where the authorisation sub-resource has to be generated while uploading the PSU identification data. * 'startAuthorisationWithPsuAuthentication': The link to the authorisation end-point, where the authorisation sub-resource has to be generated while uploading the PSU authentication data. * 'startAuthorisationWithEncryptedPsuAuthentication': The link to the authorisation end-point, where the authorisation sub-resource has to be generated while uploading the encrypted PSU authentication data. * 'startAuthorisationWithAuthenticationMethodSelection': The link to the authorisation end-point, where the authorisation sub-resource has to be generated while selecting the authentication method. This link is contained under exactly the same conditions as the data element 'scaMethods' * 'startAuthorisationWithTransactionAuthorisation': The link to the authorisation end-point, where the authorisation sub-resource has to be generated while authorising the transaction e.g. by uploading an OTP received by SMS. * 'self': The link to the payment initiation resource created by this request. This link can be used to retrieve the resource data. * 'status': The link to retrieve the transaction status of the payment initiation. * 'scaStatus': The link to retrieve the scaStatus of the corresponding authorisation sub-resource. This link is only contained, if an authorisation sub-resource has been already created.
|
| LinksStartScaProcess
|
A list of hyperlinks to be recognised by the TPP. The actual hyperlinks used in the response depend on the dynamical decisions of the ASPSP when processing the request. **Remark:** All links can be relative or full links, to be decided by the ASPSP. Type of links admitted in this response, (further links might be added for ASPSP defined extensions): - 'scaRedirect': In case of an SCA Redirect Approach, the ASPSP is transmitting the link to which to redirect the PSU browser. - 'scaOAuth': In case of a SCA OAuth2 Approach, the ASPSP is transmitting the URI where the configuration of the Authorisation Server can be retrieved. The configuration follows the OAuth 2.0 Authorisation Server Metadata specification. * 'confirmation': Might be added by the ASPSP if either the \"scaRedirect\" or \"scaOAuth\" hyperlink is returned in the same response message. This hyperlink defines the URL to the resource which needs to be updated with * a confirmation code as retrieved after the plain redirect authentication process with the ASPSP authentication server or * an access token as retrieved by submitting an authorization code after the integrated OAuth based authentication process with the ASPSP authentication server. - 'updatePsuIdentification': The link to the authorisation or cancellation authorisation sub-resource, where PSU identification data needs to be uploaded. - 'startAuthorisationWithPsuAuthentication': The link to the authorisation or cancellation authorisation sub-resource, where PSU authentication data needs to be uploaded. - 'startAuthorisationWithEncryptedPsuAuthentication': Same as startAuthorisactionWithPsuAuthentication where the authentication data need to be encrypted on application layer in uploading. - 'selectAuthenticationMethod': The link to the authorisation or cancellation authorisation sub-resource, where the selected authentication method needs to be uploaded. This link is contained under exactly the same conditions as the data element 'scaMethods'. - 'authoriseTransaction': The link to the authorisation or cancellation authorisation sub-resource, where the authorisation data has to be uploaded, e.g. the TOP received by SMS. - 'scaStatus': The link to retrieve the scaStatus of the corresponding authorisation sub-resource.
|
| LinksTransactionDetails
|
|
| LinksUpdatePsuAuthentication
|
A list of hyperlinks to be recognised by the TPP. Might be contained, if several authentication methods are available for the PSU. Type of links admitted in this response: * 'updateAdditionalPsuAuthentication': The link to the payment initiation or account information resource, which needs to be updated by an additional PSU password. This link is only contained in rare cases, where such additional passwords are needed for PSU authentications. * 'updateAdditionalEncryptedPsuAuthentication': The link to the payment initiation or account information resource, which needs to be updated by an additional encrypted PSU password. This link is only contained in rare cases, where such additional passwords are needed for PSU authentications. * 'selectAuthenticationMethod': This is a link to a resource, where the TPP can select the applicable second factor authentication methods for the PSU, if there were several available authentication methods. This link is only contained, if the PSU is already identified or authenticated with the first relevant factor or alternatively an access token, if SCA is required and if the PSU has a choice between different authentication methods. If this link is contained, then there is also the data element 'scaMethods' contained in the response body. * 'authoriseTransaction': The link to the resource, where the \"Transaction authorisation request\" is sent to. This is the link to the resource which will authorise the transaction by checking the SCA authentication data within the Embedded SCA approach. * 'scaStatus': The link to retrieve the scaStatus of the corresponding authorisation sub-resource.
|
| LinksUpdatePsuIdentification
|
A list of hyperlinks to be recognised by the TPP. The actual hyperlinks used in the response depend on the dynamical decisions of the ASPSP when processing the request. **Remark:** All links can be relative or full links, to be decided by the ASPSP. Type of links admitted in this response, (further links might be added for ASPSP defined extensions): - 'scaStatus': The link to retrieve the scaStatus of the corresponding authorisation sub-resource. - 'selectAuthenticationMethod': This is a link to a resource, where the TPP can select the applicable second factor authentication methods for the PSU, if there are several available authentication methods and if the PSU is already sufficiently authenticated.. If this link is contained, then there is also the data element \"scaMethods\" contained in the response body.
|
| MessageCode2XX
|
Message codes for HTTP Error codes 2XX.
|
| MessageCode400AIS
|
Message codes defined for AIS for HTTP Error code 400 (BAD_REQUEST).
|
| MessageCode400PIIS
|
Message codes defined for PIIS for HTTP Error code 400 (BAD_REQUEST).
|
| MessageCode400PIS
|
Message codes defined for PIS for HTTP Error code 400 (BAD_REQUEST).
|
| MessageCode400SBS
|
Message codes defined for signing baskets for HTTP Error code 400 (BAD_REQUEST).
|
| MessageCode401AIS
|
Message codes defined for AIS for HTTP Error code 401 (UNAUTHORIZED).
|
| MessageCode401PIIS
|
Message codes defined for PIIS for HTTP Error code 401 (UNAUTHORIZED).
|
| MessageCode401PIS
|
Message codes defined for PIS for HTTP Error code 401 (UNAUTHORIZED).
|
| MessageCode401SBS
|
Message codes defined for signing baskets for HTTP Error code 401 (UNAUTHORIZED).
|
| MessageCode403AIS
|
Message codes defined for AIS for HTTP Error code 403 (FORBIDDEN).
|
| MessageCode403PIIS
|
Message codes defined for PIIS for HTTP Error code 403 (FORBIDDEN).
|
| MessageCode403PIS
|
Message codes defined defined for PIS for PIS for HTTP Error code 403 (FORBIDDEN).
|
| MessageCode403SBS
|
Message codes defined for signing baskets for HTTP Error code 403 (FORBIDDEN).
|
| MessageCode404AIS
|
Message codes defined for AIS for HTTP Error code 404 (NOT FOUND).
|
| MessageCode404PIIS
|
Message codes defined for PIIS for HTTP Error code 404 (NOT FOUND).
|
| MessageCode404PIS
|
Message codes defined for PIS for HTTP Error code 404 (NOT FOUND).
|
| MessageCode404SBS
|
Message codes defined for signing baskets for HTTP Error code 404 (NOT FOUND).
|
| MessageCode405AIS
|
Message codes defined for AIS for HTTP Error code 405 (METHOD NOT ALLOWED).
|
| MessageCode405PIIS
|
Message codes defined for PIIS for HTTP Error code 405 (METHOD NOT ALLOWED).
|
| MessageCode405PIS
|
Message codes defined for payment cancelations PIS for HTTP Error code 405 (METHOD NOT ALLOWED).
|
| MessageCode405PISCANC
|
Message codes defined for payment cancelations PIS for HTTP Error code 405 (METHOD NOT ALLOWED).
|
| MessageCode405SBS
|
Message codes defined for SBS for HTTP Error code 405 (METHOD NOT ALLOWED).
|
| MessageCode406AIS
|
Message codes defined for AIS for HTTP Error code 406 (NOT ACCEPTABLE).
|
| MessageCode409AIS
|
Message codes defined for AIS for HTTP Error code 409 (CONFLICT).
|
| MessageCode409PIIS
|
Message codes defined for PIIS for HTTP Error code 409 (CONFLICT).
|
| MessageCode409PIS
|
Message codes defined for PIS for HTTP Error code 409 (CONFLICT).
|
| MessageCode409SBS
|
Message codes defined for signing baskets for HTTP Error code 409 (CONFLICT).
|
| MessageCode429AIS
|
Message codes for HTTP Error code 429 (TOO MANY REQUESTS).
|
| MonthOfExecution
|
Month of execution as string. This string consists of up two characters.
Leading zeroes are not allowed. 12 is ultimo.
|
| MonthsOfExecutionEnum
|
|
| OtpFormatEnum
|
|
| PaymentExchangeRate
|
Exchange Rate.
|
| PaymentInitationRequestResponse201
|
Body of the response for a successful payment initiation request.
|
| PaymentInitiationBulkElementJson
|
Generic body for a bulk payment initiation entry. The bulk entry type is a type which follows the JSON formats for the supported products for single payments excluding the data elements (if supported): * debtorAccount * requestedExecutionDate, * requestedExecutionTime. These data elements may not be contained in any bulk entry. This data object can be used to represent valid bulk payment initiations entry for the following JSON based payment product, which where defined in the Implementation Guidelines: * sepa-credit-transfers * instant-sepa-credit-transfers * target-2-payments * cross-border-credit-transfers For the convenience of the implementer additional which are already predefined in the Implementation Guidelines are included (but commented in source code), such that an ASPSP may add them easily. Take care: Since the format is intended to fit for all payment products there are additional conditions which are NOT covered by this specification. Please check the Implementation Guidelines for details. The following data element are depending on the actual payment product available (in source code): | Data Element | SCT EU Core | SCT INST EU Core | Target2 Paym. Core | Cross Border CT Core |
|---|
| endToEndIdentification | optional | optional | optional | n.a. | | instructionIdentification | n.a. | n.a. | n.a. | n.a. | | debtorName | n.a. | n.a. | n.a. | n.a. | | debtorId | n.a. | n.a. | n.a. | n.a. | | ultimateDebtor | n.a. | n.a. | n.a. | n.a. | | instructedAmount | mandatory | mandatory | mandatory | mandatory | | transactionCurrency | n.a. | n.a. | n.a. | n.a. | | exchangeRateInformation | n.a. | n.a. | n.a. | n.a. | | creditorAccount | mandatory | mandatory | mandatory | mandatory | | creditorAgent | optional | optional | optional | conditional | | creditorAgentName | n.a. | n.a. | n.a. | n.a. | | creditorName | mandatory | mandatory | mandatory | mandatory | | creditorId | n.a. | n.a. | n.a. | n.a. | | creditorAddress | optional optional | optional | conditional | | creditorNameAndAddress | n.a. | n.a. | n.a. | n.a. | | ultimateCreditor | n.a. | n.a. | n.a. | n.a. | | purposeCode | n.a. | n.a. | n.a. | n.a. | | chargeBearer | n.a. | n.a. | optional | conditional | | remittanceInformationUnstructured | optional | optional | optional | optional | | remittanceInformationUnstructuredArray | n.a. | n.a. | n.a. | n.a. | | remittanceInformationStructured | n.a. | n.a. | n.a. | n.a. | | remittanceInformationStructuredArray | n.a. | n.a. | n.a. | n.a. | IMPORTANT: In this API definition the following holds: * All data elements mentioned above are defined, but some of them are commented, i.e. they are only visible in the source code and can be used by uncommenting them. * Data elements which are mandatory in the table above for all payment products are set to be mandatory in this specification. * Data elements which are indicated in the table above as n.a. for all payment products are commented in the source code. * Data elements which are indicated to be option, conditional or mandatory for at least one payment product in the table above are set to be optional in the s specification except the case where all are defined to be mandatory. * Data element which are indicated to be n.a. can be used by the ASPS if needed. In this case uncomment the the related lines in the source code. * If one uses this data types for some payment products he has to ensure that the used data type is valid according to the underlying payment product, e.g. by some appropriate validations.
|
| PaymentInitiationCancelResponse202
|
Body of the response for a successful cancel payment request.
|
| PaymentInitiationJson
|
Generic Body for a payment initiation via JSON. This generic JSON body can be used to represent valid payment initiations for the following JSON based payment product, which where defined in the Implementation Guidelines: * sepa-credit-transfers * instant-sepa-credit-transfers * target-2-payments * cross-border-credit-transfers For the convenience of the implementer additional which are already predefined in the Implementation Guidelines are included (but commented in source code), such that an ASPSP may add them easily. Take care: Since the format is intended to fit for all payment products there are additional conditions which are NOT covered by this specification. Please check the Implementation Guidelines for details. The following data element are depending on the actual payment product available (in source code): | Data Element | SCT EU Core | SCT INST EU Core | Target2 Paym. Core | Cross Border CT Core |
|---|
| endToEndIdentification | optional | optional | optional | n.a. | | instructionIdentification | n.a. | n.a. | n.a. | n.a. | | debtorName | n.a. | n.a. | n.a. | n.a. | | debtorAccount | mandatory | mandatory | mandatory | mandatory | | debtorId | n.a. | n.a. | n.a. | n.a. | | ultimateDebtor | n.a. | n.a. | n.a. | n.a. | | instructedAmount | mandatory | mandatory | mandatory | mandatory | | transactionCurrency | n.a. | n.a. | n.a. | n.a. | | exchangeRateInformation | n.a. | n.a. | n.a. | n.a. | | creditorAccount | mandatory | mandatory | mandatory | mandatory | | creditorAgent | optional | optional | optional | conditional | | creditorAgentName | n.a. | n.a. | n.a. | n.a. | | creditorName | mandatory | mandatory | mandatory | mandatory | | creditorId | n.a. | n.a. | n.a. | n.a. | | creditorAddress | optional optional | optional | conditional | | creditorNameAndAddress | n.a. | n.a. | n.a. | n.a. | | ultimateCreditor | n.a. | n.a. | n.a. | n.a. | | purposeCode | n.a. | n.a. | n.a. | n.a. | | chargeBearer | n.a. | n.a. | optional | conditional | | remittanceInformationUnstructured | optional | optional | optional | optional | | remittanceInformationUnstructuredArray | n.a. | n.a. | n.a. | n.a. | | remittanceInformationStructured | n.a. | n.a. | n.a. | n.a. | | remittanceInformationStructuredArray | n.a. | n.a. | n.a. | n.a. | | requestedExecutionDate | n.a. | n.a. | n.a. | n.a. | | requestedExecutionTime | n.a. | n.a. | n.a. | n.a. | IMPORTANT: In this API definition the following holds: * All data elements mentioned above are defined, but some of them are commented, i.e. they are only visible in the source code and can be used by uncommenting them. * Data elements which are mandatory in the table above for all payment products are set to be mandatory in this specification. * Data elements which are indicated in the table above as n.a. for all payment products are commented in the source code. * Data elements which are indicated to be option, conditional or mandatory for at least one payment product in the table above are set to be optional in the s specification except the case where all are defined to be mandatory. * Data element which are indicated to be n.a. can be used by the ASPS if needed. In this case uncomment the the related lines in the source code. * If one uses this data types for some payment products he has to ensure that the used data type is valid according to the underlying payment product, e.g. by some appropriate validations.
|
| PaymentInitiationRequestResponse201
|
Body of the response for a successful payment initiation request.
|
| PaymentInitiationStatusResponse200Json
|
Body of the response for a successful payment initiation status request in case of an JSON based endpoint. *Remark:* If the PSU does not complete a required SCA within the required timeframe the payment resource's status must be set to \"RJCT\". Particularly, if a multi-level-SCA is required and the number of successful SCAs during the required timeframe is insufficient, the status must also be set to \"RJCT\".
|
| PaymentInitiationWithStatusResponse
|
Generic JSON response body consistion of the corresponding payment initiation JSON body together with an optional transaction status field.
|
| PeriodicPaymentInitiationJson
|
Generic Body for a periodic payment initiation via JSON. This generic JSON body can be used to represent valid periodic payment initiations for the following JSON based payment product, which where defined in the Implementation Guidelines: * sepa-credit-transfers * instant-sepa-credit-transfers * target-2-payments * cross-border-credit-transfers For the convenience of the implementer additional which are already predefined in the Implementation Guidelines are included (but commented in source code), such that an ASPSP may add them easily. Take care: Since the format is intended to fit for all payment products there are additional conditions which are NOT covered by this specification. Please check the Implementation Guidelines for details. The following data element are depending on the actual payment product available (in source code): | Data Element | SCT EU Core | SCT INST EU Core | Target2 Paym. Core | Cross Border CT Core |
|---|
| endToEndIdentification | optional | optional | optional | n.a. | | instructionIdentification | n.a. | n.a. | n.a. | n.a. | | debtorName | n.a. | n.a. | n.a. | n.a. | | debtorAccount | mandatory | mandatory | mandatory | mandatory | | debtorId | n.a. | n.a. | n.a. | n.a. | | ultimateDebtor | n.a. | n.a. | n.a. | n.a. | | instructedAmount | mandatory | mandatory | mandatory | mandatory | | transactionCurrency | n.a. | n.a. | n.a. | n.a. | | exchangeRateInformation | n.a. | n.a. | n.a. | n.a. | | creditorAccount | mandatory | mandatory | mandatory | mandatory | | creditorAgent | optional | optional | optional | conditional | | creditorAgentName | n.a. | n.a. | n.a. | n.a. | | creditorName | mandatory | mandatory | mandatory | mandatory | | creditorId | n.a. | n.a. | n.a. | n.a. | | creditorAddress | optional optional | optional | conditional | | creditorNameAndAddress | n.a. | n.a. | n.a. | n.a. | | ultimateCreditor | n.a. | n.a. | n.a. | n.a. | | purposeCode | n.a. | n.a. | n.a. | n.a. | | chargeBearer | n.a. | n.a. | optional | conditional | | remittanceInformationUnstructured | optional | optional | optional | optional | | remittanceInformationUnstructuredArray | n.a. | n.a. | n.a. | n.a. | | remittanceInformationStructured | n.a. | n.a. | n.a. | n.a. | | remittanceInformationStructuredArray | n.a. | n.a. | n.a. | n.a. | | requestedExecutionDate | n.a. | n.a. | n.a. | n.a. | | requestedExecutionTime | n.a. | n.a. | n.a. | n.a. | | startDate | mandatory | mandatory | mandatory | mandatory | | executionRule | optional | optional | optional | optional | | endDate | optional | optional | optional | optional | | frequency | mandatory | mandatory | mandatory | mandatory | | dayOfExecution | conditional | conditional | conditional | conditional | IMPORTANT: In this API definition the following holds: * All data elements mentioned above are defined, but some of them are commented, i.e. they are only visible in the source code and can be used by uncommenting them. * Data elements which are mandatory in the table above for all payment products are set to be mandatory in this specification. * Data elements which are indicated in the table above as n.a. for all payment products are commented in the source code. * Data elements which are indicated to be option, conditional or mandatory for at least one payment product in the table above are set to be optional in the s specification except the case where all are defined to be mandatory. * Data element which are indicated to be n.a. can be used by the ASPS if needed. In this case uncomment the the related lines in the source code. * If one uses this data types for some payment products he has to ensure that the used data type is valid according to the underlying payment product, e.g. by some appropriate validations.
|
| PeriodicPaymentInitiationWithStatusResponse
|
Generic JSON response body consistion of the corresponding periodic payment initiation JSON body together with an optional transaction status field.
|
| PsuData
|
PSU Data for Update PSU authentication.
|
| PurposeCode
|
ExternalPurpose1Code from ISO 20022. Values from ISO 20022 External Code List ExternalCodeSets_1Q2018 June 2018.
|
| RateTypeEnum
|
|
| ReadAccountBalanceResponse200
|
Body of the response for a successful read balance for an account request.
|
| ReadCardAccountBalanceResponse200
|
Body of the response for a successful read balance for a card account request.
|
| RemittanceInformationStructured
|
Structured remittance information.
|
| ReportExchangeRate
|
Exchange Rate.
|
| ScaStatus
|
This data element is containing information about the status of the SCA method applied. The following codes are defined for this data type. * 'received': An authorisation or cancellation-authorisation resource has been created successfully. * 'psuIdentified': The PSU related to the authorisation or cancellation-authorisation resource has been identified. * 'psuAuthenticated': The PSU related to the authorisation or cancellation-authorisation resource has been identified and authenticated e.g. by a password or by an access token. * 'scaMethodSelected': The PSU/TPP has selected the related SCA routine. If the SCA method is chosen implicitly since only one SCA method is available, then this is the first status to be reported instead of 'received'. * 'unconfirmed': SCA is technically successfully finalised by the PSU, but the authorisation resource needs a confirmation command by the TPP yet. * 'started': The addressed SCA routine has been started. * 'finalised': The SCA routine has been finalised successfully (including a potential confirmation command). This is a final status of the authorisation resource. * 'failed': The SCA routine failed. This is a final status of the authorisation resource. * 'exempted': SCA was exempted for the related transaction, the related authorisation is successful. This is a final status of the authorisation resource.
|
| ScaStatusAuthorisationConfirmation
|
This data element is containing information about the status of the SCA method in an authorisation confirmation response. The following codes are defined for this data type. * 'finalised': if the transaction authorisation and confirmation was successful. * 'failed': if the transaction authorisation or confirmation was not successful.
|
| ScaStatusResponse
|
Body of the JSON response with SCA Status.
|
| SelectPsuAuthenticationMethod
|
Content of the body of a Select PSU authentication method request
|
| SelectPsuAuthenticationMethodResponse
|
Body of the JSON response for a successful select PSU authentication method request.
|
| SigningBasket
|
JSON Body of a establish signing basket request. The body shall contain at least one entry.
|
| SigningBasketResponse200
|
Body of the JSON response for a successful get signing basket request. * 'payments': payment initiations which shall be authorised through this signing basket. * 'consents': consent objects which shall be authorised through this signing basket. * 'transactionStatus': Only the codes RCVD, ACTC, RJCT are used. * '_links': The ASPSP might integrate hyperlinks to indicate next (authorisation) steps to be taken.
|
| SigningBasketResponse201
|
Body of the JSON response for a successful create signing basket request.
|
| SigningBasketStatusResponse200
|
|
| StandingOrderDetails
|
Details of underlying standing orders.
|
| StandingOrderDetails
|
Details of underlying standing orders.
|
| StartScaprocessResponse
|
Body of the JSON response for a Start SCA authorisation request.
|
| TppMessage2XX
|
|
| TppMessage400AIS
|
|
| TppMessage400PIIS
|
|
| TppMessage400PIS
|
|
| TppMessage400SBS
|
|
| TppMessage401AIS
|
|
| TppMessage401PIIS
|
|
| TppMessage401PIS
|
|
| TppMessage401SBS
|
|
| TppMessage403AIS
|
|
| TppMessage403PIIS
|
|
| TppMessage403PIS
|
|
| TppMessage403SBS
|
|
| TppMessage404AIS
|
|
| TppMessage404PIIS
|
|
| TppMessage404PIS
|
|
| TppMessage404SBS
|
|
| TppMessage405AIS
|
|
| TppMessage405PIIS
|
|
| TppMessage405PIS
|
|
| TppMessage405PISCANC
|
|
| TppMessage405SBS
|
|
| TppMessage406AIS
|
|
| TppMessage409AIS
|
|
| TppMessage409PIIS
|
|
| TppMessage409PIS
|
|
| TppMessage409SBS
|
|
| TppMessage429AIS
|
|
| TppMessageCategory
|
Category of the TPP message category.
|
| TransactionAuthorisation
|
Content of the body of a transaction authorisation request
|
| TransactionDetails
|
Transaction details.
|
| TransactionStatus
|
The transaction status is filled with codes of the ISO 20022 data table: - 'ACCC': 'AcceptedSettlementCompleted' - Settlement on the creditor's account has been completed. - '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. **Usage:** this can be used by the first agent to report to the debtor that the transaction has been completed. **Warning:** this status is provided for transaction status reasons, not for financial information. It can only be used after bilateral agreement. - 'ACSP': 'AcceptedSettlementInProcess' - All preceding checks such as technical validation and customer profile were successful and therefore the payment initiation 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. - 'RCVD': 'Received' - Payment initiation has been received by the receiving agent. - 'PDNG': 'Pending' - Payment initiation or individual transaction included in the payment initiation is pending. Further checks and status update will be performed. - 'RJCT': 'Rejected' - Payment initiation or individual transaction included in the payment initiation has been rejected. - 'CANC': 'Cancelled' Payment initiation has been cancelled before execution Remark: This codeis accepted as new code by ISO20022. - 'ACFC': 'AcceptedFundsChecked' - Preceding check of technical validation and customer profile was successful and an automatic funds check was positive . Remark: This code is accepted as new code by ISO20022. - 'PATC': 'PartiallyAcceptedTechnical' Correct The payment initiation needs multiple authentications, where some but not yet all have been performed. Syntactical and semantical validations are successful. Remark: This code is accepted as new code by ISO20022. - 'PART': 'PartiallyAccepted' - A number of transactions have been accepted, whereas another number of transactions have not yet achieved 'accepted' status. Remark: This code may be used only in case of bulk payments. It is only used in a situation where all mandated authorisations have been applied, but some payments have been rejected.
|
| TransactionStatusSBS
|
The transaction status is filled with codes of the ISO 20022 data table. Only the codes RCVD, PATC, ACTC, ACWC and RJCT are used: - 'ACSP': 'AcceptedSettlementInProcess' - All preceding checks such as technical validation and customer profile were successful and therefore the payment initiation 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. - 'RCVD': 'Received' - Payment initiation has been received by the receiving agent. - 'RJCT': 'Rejected' - Payment initiation or individual transaction included in the payment initiation has been rejected.
|
| TransactionsResponse200Json
|
Body of the JSON response for a successful read transaction list request. This account report contains transactions resulting from the query parameters.
|
| UpdatePsuAuthentication
|
Content of the body of a Update PSU authentication request Password subfield is used.
|
| UpdatePsuAuthenticationResponse
|
Body of the JSON response for a successful update PSU authentication request.
|
| UpdatePsuIdentificationResponse
|
Body of the JSON response for a successful update PSU identification request.
|
| UsageEnum
|
|
| UsageEnum
|
|