Access to open banking APIs at
https://oauth2-apiii.e-i.com/cic/ is restricted to
qualified Third Party Payment Service Providers.
A sandbox environment for open banking APIs is also provided at
https://oauth2-apiii.e-i.com/sandbox/cic/, and can be used by Qualified Third Party Payment
Service Providers, and by other Third Parties upon agreement with
Qualified Third Party Payment Service Providers
In the context of PSD2, being a qualified Third Party Payment Service Provider means:
Having obtained the authorization from a National Competent Authority (NCA) to operate as a Payment Services Provider, with the roles it requires (AISP, CBPII, PISP). The list of National Register entities can be found on the Open Banking Europe Website.
Having obtained from a Qualified Trust Service Provider (QTSP), Qualified Website Authentication Certificates (QWAC) and Qualified Sealing Certificates (QSealC), that have a PSD2 eIDAS certificate profile.
Details on Qualified Trust Service Providers and the PSD2 eIDAS certificate profile can also be found on the Open Banking Europe Website.
In order for a third party to qualify for production API Access, both steps must have been completed and they must have matching data (the NCA delivers a registration number that must written in the certificate data).
It is possible for a qualified third party to lose its qualification, either because the certificate becomes invalid, or because the NCA decides to revoke the TPP's authorization.
Note that this authorization is also required for access to the Fallback Mechanism.
All API calls require mutual-TLS authentication, with a Qualified Website Authentication Certificate (QWAC) issued to the TPP by a QTSP.
Mutual-TLS authentication with a Qualified Website Authentication Certificate (QWAC) is also required for accessing the Fallback Mechanism.
Third Party Payment Service Provider Registration
In order to register for API Access, a Third Party Payment Service Provider must use the OAuth 2 client registration API to register at least one OAuth 2 client with CIC, giving the following information:
- A name for the client registration, that will be shown to the Payment Service User;
- If provided, a logo will also be shown to the user;
- The client scope, which must be a scope matching the TPP's role, documented on the OAuth 2 and SCA Workflows page
- A list of redirection endpoints that will be used for the OAuth 2 authorization code workflow;
- The full set of Qualified Sealing Certificates (QSealC) as a JSON Web Key
Set object specified by RFC 7517, specifying, for each key
object, the full certificate chain;
- In order to sign requests by the TPP, the private key associated to a
qualified sealing certificate will be used - in order to signal which
certificate is in use, the TPP can use either the JWK
kidgenerated by CIC, or the JWK
x5usent by the TPP when registering the certificate;
- In order to sign requests by the TPP, the private key associated to a qualified sealing certificate will be used - in order to signal which certificate is in use, the TPP can use either the JWK
After registration, the caller will be provided with a
client_id, for use
in obtention of OAuth 2 access tokens. The registration can also be updated
by using the OAuth 2 client management API.
Sandbox API Access
For technical qualification of workflows and APIs, a sandbox environment is
Access to that environment is allowed for:
Qualified Third Party Service Providers - in that case, the registration process is the same as the one for the Production Environment - with the caveat that, on the Sandbox Environment, a qualified TPP may also register scopes and then use APIs that do not match their authorized role according to the NCA;
Other Third Parties - in that case, the TPP must contact CIC and send them Certificate Signing Requests for:
- The Website Access Certificate that will be used for mutual-TLS authentication on the API;
- The Sealing Certificate that will be used to sign the request headers;