What services does CIB PSD2 API offer?
The CIB PSD2 API service provides an opportunity for your business to provide account information and payment initiation services to customers of our bank who have a payment account.
In integrating the PSD2 API our bank follows the Berlin Group guideline version 1.3. Please review the CIB PSD2 API documentation and test your development using the Sandbox.
Once the statutory conditions have been fulfilled and in possession of the required certificates, you can use our service starting from 14 September 2019.
Differences compared to the Berlin Group guideline
1. General information
The purpose of the documentation is to support interface integration testing in the following cases:
- To service providers providing account information and payment initiation services to customers who have accounts at CIB Bank.
- For the confirmation request activity of payment service providers that issue card-based cashless payment instruments.
CIB Bank applied version 1.3.4 of the guideline proposed by the Berlin Group in connection of CIB Internet-based Electronic Services (CIB Online, CIB Bank Mobile Application), and version 1.3.3 in connection of CIB Business Online service in developing the interface, therefore we recommend studying it prior to starting the testing.
Below we present the differences compared to the Berlin Group guidelines.
2. Abbreviations and terms
Abbreviation |
Description |
TPP: |
A service provider other than the bank (so-called Third-Party Payment Service Provider) that provides account information or payment initiation services |
AISP: |
Account Information Service Provider |
PISP: |
Payment Initiation Service Provider |
PIISP: |
Payment Instrument Issuing Service Provider |
PSU: |
Payment Service User |
SCA: |
Strong Customer Authentication |
3. Differences compared to the Berlin Group guideline version 1.3
Detailed field-level documentation for services implemented by CIB Bank is included in the interface definition (YAML) file.
At the time of submitting a consent and a payment, PSU-ID or PSU-Corporate-ID header (only one of them) must be fulfilled to make retail / corporate routing. It can be fulfilled with any kind of value, specific value does not matter. Routing should be interpreted as follows:
If the PSU has a contract with the bank for the CIB Business Online service and therefore wishes to use the credentials belonging to the CIB Business Online via the TPP, filling of the 'PSU-Corporate-ID' field is required; if the PSU has a contract for one of the CIB Internet-based Electronic Services (CIB Internet Bank, CIB Online, CIB Bank Mobile Application), and wishes to use the credentials belonging to these channels via the TPP, filling of the 'PSU-ID' field is required.
Furthermore, please note that the integration requirements may differ for the requests (endpoints) that can be used in both cases. The differences according to the ‘PSU-ID’ and ‘PSU-Corporate-ID’ routing are indicated in the interface definition file (yaml).
In the case of ‘PSU-ID’ routing CIB PSD2 API does not support the following requests:
- POST consents/{consentId}/authorisations
- PUT consents/{consentId}/authorisations/{authorisationId}
- GET card-accounts
- GET card-accounts/{account-id}
- GET card-accounts/{account-id}/balances
- GET card-accounts/{account-id}/transactions
- POST signing-baskets
- POST signing-baskets/{basketId}/authorisations
- PUT signing-baskets/{basketId}/authorisations/{authorisationId}
- GET signing-baskets/{basketId}/authorisations/{authorisationId}
- POST bulk-payments/{payment-product}
- GET bulk-payments/{payment-product}/{paymentId}
- GET bulk-payments/{payment-product}/{paymentId}/status
- POST {payment-service}/{payment-product}/{paymentId}/authorisations
- PUT {payment-service}/{payment-product}/{paymentId}/authorisations/{authorisationId}
- DELETE {payment-service}/{payment-product}/{paymentId}
- POST {payment-service}/{payment-product}/{paymentId}/cancellation-authorisations
- GET {payment-service}{payment-product}/{paymentId}/cancellation-authorisations
- PUT {payment-service}/{payment-product}/{paymentId}/cancellation-authorisations/{cancellationId}
- GET {payment-service}/{payment-product}/{paymentId}/cancelation-authorisations/{cancellationId}
In the case of ‘PSU-Corporate-ID’ routing CIB PSD2 API does not support the following requests:
- PUT consents/{consentId}/authorisations/{authorisationId}
- GET card-accounts
- GET card-accounts/{account-id}
- GET card-accounts/{account-id}/balances
- GET card-accounts/{account-id}/transactions
- POST signing-baskets
- POST signing-baskets/{basketId}/authorisations
- PUT signing-baskets/{basketId}/authorisations/{authorisationId}
- GET signing-baskets/{basketId}/authorisations/{authorisationId}
- PUT {payment-service}/{payment-product}/{paymentId}/authorisations/{authorisationId}
- POST {payment-service}/{payment-product}/{paymentId}/cancellation-authorisations
- GET {payment-service}{payment-product}/{paymentId}/cancellation-authorisations
- PUT {payment-service}/{payment-product}/{paymentId}/cancellation-authorisations/{cancellationId}
- GET {payment-service}/{payment-product}/{paymentId}/cancelation-authorisations/{cancellationId}
OAuth process
- OAuth2 protocol (method) can be used for customer authorization
- OAuth server automatically registers the TPP when it submits its first consent or payment, as long as TPP is properly certified
- As a result of failed OAuth authorization the requester can not access the resource. In this case TPP callback URL is called given in the authorization request, supplemented with error code (’error’ parameter), error description (’error_description parameter). Error code value will be ’access denied’.
In the case of ‘PSU-ID’ routing the PSU can cancel (delete) payment initiations submitted via the TPPs only through other electronic channels provided by our bank.
In the case of 'PSU-Corporate-ID' routing, before the order is successfully sent to the bank (e.g. the order has been successfully signed by a user, but the signature is not yet sufficient to fulfill it and additional signatures need to be placed on the order) it is possible to cancel the order via the Open API.
The orders (consent, payments) can be signes by several users in the case of 'PSU-Corporate-ID' routing.
On the following interface, the use of the “both” value in the bookingStatus parameter is not supported in either case; nor is the “pending” parameter for ‘PSU-Corporate-ID’ routing.
- GET accounts/{account-id}/transactions
Only one transaction by bookingStatus can be queried at a time. bookingStatus parameters that can be used:
In the case of ’PSU-ID’ routing:
- pending: queries the items pending
- booked: items fulfilled
In the case of ’PSU-Corporate-ID’ routing:
- booked: items fulfilled
In the case of payment initiation requests, our Bank supports different payment order types (payment products), which are:
In the case of ’PSU-ID’ routing:
- fx-credit-transfers – one-time foreign currency transfers, non SEPA (intrabank, interbank)
- hungarian-credit-transfers – one-time and recurring forint transfers (intrabank, interbank)
- sepa-credit-transfers – EUR one-time foreign currency transfer (intrabank, interbank)
Payment order types (payment products) and services can be interpreted in the following combinations:
payment product |
payments |
bulk-payments |
periodic-payments |
fx-credit-transfers |
supported |
not supported |
not supported |
hungarian-credit-transfers |
supported |
not supported |
supported |
sepa-credit-transfers |
supported |
not supported |
not supported |
|
|
|
|
In the case of ’PSU-Corporate-ID’ routing:
- cross-border-credit-transfers – one-off foreign currency transfers, non SEPA (intrabank, interbank)
- hungarian-credit-transfers – one-off and recurring forint transfers (intrabank, interbank)
- sepa-credit-transfers – one-off EUR currency transfer within the EEA
- target-2-payments – one-off urgent EUR currency transfer within the EEA
Payment order types (payment products) and services can be interpreted in the following combinations:
payment product |
payments |
bulk-payments |
periodic-payments |
cross-border-credit-transfers |
supported |
supported |
not supported |
hungarian-credit-transfers |
supported |
supported |
supported |
sepa-credit-transfers |
supported |
supported |
not supported |
target-2-payments |
supported |
supported |
not supported |
Things to know about using CIB PSD2 API
From when can the system be used live?
According to the requirements of the PSD2 Directive, CIB PSD2 API Sandbox can be used live starting from 14 September 2019.
On what address can CIB PSD2 API Sandbox be accessed?
https://api.cib.hu
How can we learn of API changes?
The bank publishes the documentation of changes occurring in the technical information required for using the CIB PSD2 API Sandbox by version updates on its website (www.cib.hu).
What international standard does the bank follow in integrating the PSD2 API?
In integrating the PSD2 API our bank follows the Berlin Group guideline version 1.3 (https://www.berlin-group.org), with some differences. The summary of differences is included in the Related documents part.
What do the AISP, ASPSP, PISP, PSU, SCA, TPP abbreviations mean?
- AISP: Account Information Service Provider (TPP)
- ASPS: Account Servicing Payment Service Provider
- PISP: Payment Initiation Service Provider (TPP)
- PSU: Payment Service User
- SCA: Strong Customer Authentication
- TPP: Third-party PSD2 service provider.
PSD2 API technical description
Related document
Due to a technical error, the "Error Rate" fields in the Q1 and Q2 availability report are missing, this error has been corrected for later reports.
CIB PSD2 API Sandbox
CIB TPP Channel user manual
CIB TPP Channel
How can we help?
If you have any question about the CIB PSD2 API Sandbox please send us an email to PSD2_support@cib.hu and we answer you to the e-mail address you have provided. Please check the accuracy of the e-mail address provided. We try to answer as soon as possible. Thank you for your patience.