OpenBank Developer
PSD2 · Berlin Group NextGenPSD2 1.3.12 + ČOBS v7.0

Build on OpenBank's PSD2 XS2A API

One published, conformant Access-to-Account interface any EU TPP can integrate against — Berlin Group NextGenPSD2 as the base, the Czech ČOBS profile layered on top. Account information (AIS), payment initiation (PIS) and funds confirmation (CBPII).

Decision of record: ADR-0090 (Berlin Group + ČOBS). This is the sandbox portal — see Sandbox for what differs from production.

Getting started

  1. Register as a TPP. Obtain an eIDAS certificate (QWAC for transport, QSEAL for message signing) and your PSD2 role (AISP / PISP / PIISP). See eIDAS & TPP.
  2. Create a consent. POST /v1/consents with the Berlin access object, then drive the PSU through Strong Customer Authentication. See Consent.
  3. Call the APIs. Use the returned Consent-ID on AIS calls, or POST /v1/payments/{payment-product} for PIS. Full contract in the API reference.

The interface follows the Berlin header set — X-Request-ID, PSU-ID, PSU-IP-Address, TPP-Redirect-URI, TPP-Redirect-Preferred, Consent-ID, Digest, Signature, TPP-Signature-Certificate — and ISO-20022 transactionStatus (RCVD / ACTC / ACCP / ACSC / RJCT).

Authentication & SCA

OpenBank supports the two Berlin SCA approaches that need no TPP-hosted credential entry:

Redirect SCA

The PSU is redirected to the OpenBank-hosted authentication, completes SCA, and is returned to your TPP-Redirect-URI. Set TPP-Redirect-Preferred: true.

Decoupled SCA

The PSU approves the consent or payment in the OpenBank mobile app via device-bound approval (no credentials leave the bank). The TPP polls scaStatus until finalised. Backed by ADR-0021 decoupled device approval.

Embedded SCA (credentials through the TPP) is deliberately not offered — highest fraud surface, lowest demand.

Czech ČOBS profile

ČOBS rides on the Berlin model as a profile, not a fork. Select it by payment-product:

eIDAS & TPP identity

Production access requires an eIDAS certificate issued by a Qualified Trust Service Provider:

Your AISP / PISP / PIISP role is validated against the TPP registry on every call. Requests that fail role or certificate checks are rejected fail-closed.

Sandbox

This portal documents the sandbox. What differs from production:

Versioning & changes