Back to CIC Banque Privée's Developer Portal Homepage

Registration for API Access


PSD2 API Developer Portal Registration for API Access

Access to open banking APIs at https://oauth2-apiii.e-i.com/cic-banqueprivee/ 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-banqueprivee/, and can be used by Qualified Third Party Payment Service Providers, and by other Third Parties upon agreement with CIC Banque Privée.

Qualified Third Party Payment Service Providers

In the context of PSD2, being a qualified Third Party Payment Service Provider means:

  1. 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.

  2. 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.

Mutual-TLS Authentication

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 Banque Privée, 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 kid generated by CIC Banque Privée, or the JWK x5u sent by the TPP when registering the certificate;

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 provided at https://oauth2-apiii.e-i.com/sandbox/cic-banqueprivee/.

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 Banque Privée 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;