The Berlin Group
NextGenPSD2 XS2A Framework
The de facto default across DE, AT, NL, ES, the Nordics and most of CEE. Defines AIS, PIS and PIIS as one JSON API with four interchangeable SCA approaches. Banks implement subsets, so capability discovery is part of onboarding.
Security profile
- Client authentication
- mTLS with a QWAC (eIDAS website certificate). The PSD2 role attributes in the certificate carry the TPP roles: PSP_AI, PSP_PI, PSP_IC.
- Message signing
- Optional per ASPSP. When required: HTTP Signature (draft-cavage-12) over Digest, X-Request-ID and TPP-Redirect-URI, sealed with a QSeal certificate passed in TPP-Signature-Certificate.
- Tokens
- No OAuth2 in the base profile — the consent resource itself is the authorisation. The OAuth2 SCA approach layers an authorisation-code grant on top and binds the token to the consentId.
- Certificates
- QWAC for transport, QSealC for signatures. Both issued by a QTSP listed in the EU Trust List.
SCA approaches
What bites integrators
- X-Request-ID must be a fresh UUID per call and is echoed back — log it, it is the only handle support desks accept.
- recurringIndicator=false plus frequencyPerDay>1 is invalid, but several ASPSPs accept it and then throttle you at four calls a day anyway.
- A consent with access.availableAccounts=allAccounts returns the account list only. Asking for balances afterwards yields CONSENT_INVALID.
- scaRedirect links can expire in as little as five minutes. Do not persist them.
- The 90-day reauthentication rule was relaxed by RTS amendment for AIS, but ASPSP behaviour still varies — handle CONSENT_EXPIRED on every read.
- instant-sepa-credit-transfers is a separate product: check capability and scheme reachability; PRODUCT_INVALID / AB05 are common.
- Under the Instant Payments Regulation, Verification of Payee sits in front of SCT Inst — plan a VoP step in the PISP UX.
APIs and endpoints
Account Information Service
AISConsent-first. You create a consent resource, drive it through SCA, then read accounts, balances and transactions until it expires or the frequency budget runs out.
- POST
/v1/consentsCreate an account information consent - GET
/v1/consents/{consentId}Read consent content - GET
/v1/consents/{consentId}/statusRead consent status only - DELETE
/v1/consents/{consentId}Revoke consent - GET
/v1/accountsList accessible accounts - GET
/v1/accounts/{accountId}/balancesRead balances - GET
/v1/accounts/{accountId}/transactionsRead booked and pending transactions, or a camt.05x report - GET
/v1/card-accountsList card accounts - GET
/v1/trusted-beneficiariesRead the PSU trusted beneficiary list
Payment Initiation Service
PISOne endpoint shape covers every product. The payment-product path segment decides the payload: JSON for SEPA, pain.001 XML for bulk and periodic in several markets.
- POST
/v1/payments/{payment-product}Initiate a single payment - POST
/v1/payments/instant-sepa-credit-transfersInitiate an SCT Inst (instant SEPA) payment - POST
/v1/bulk-payments/{payment-product}Initiate a bulk payment - POST
/v1/periodic-payments/{payment-product}Initiate a standing order - GET
/v1/payments/{payment-product}/{paymentId}Read the initiation you sent - GET
/v1/payments/{payment-product}/{paymentId}/statusRead transaction status - DELETE
/v1/payments/{payment-product}/{paymentId}Cancel a payment - POST
/v1/payments/{payment-product}/{paymentId}/authorisationsStart an explicit authorisation sub-resource - PUT
/v1/payments/{payment-product}/{paymentId}/authorisations/{authorisationId}Select SCA method or submit an authentication factor
Payment Instrument Issuer Service
PIISA single yes/no on funds availability for card-based instruments. No amount is returned, ever.
- POST
/v1/funds-confirmationsConfirm funds availability
Signing Baskets
PISBundle several pending initiations or consents into one SCA. Optional, and unevenly implemented.
- POST
/v1/signing-basketsCreate a signing basket - GET
/v1/signing-baskets/{basketId}/statusRead basket status
Flows using this standard
- Account access with redirect SCA7 steps
- SEPA credit transfer with decoupled SCA6 steps
- Funds confirmation (PIIS)2 steps
- Clearing leg: initiation to settlement6 steps
- Rejection: reading a pacs.002 RJCT4 steps
- Recall: camt.056 to pacs.0044 steps
- Verification of Payee4 steps
- Non-Instant Payment (Standard Batch) flow via Payment Hub & ILM9 steps
- Payment cancellation before settlement4 steps
Sample payloads
- AIS consent requestjson
- AIS consent response (201)json
- Account list responsejson
- SEPA credit transfer initiationjson
- Funds confirmation requestjson
- Error: CONSENT_INVALID (401)json
- Core Banking / T24 fund holdjson
- Payment Hub orchestration routejson
- Berlin Group DELETE paymentjson
- Berlin Group payment status CANCjson
- Berlin Group SCT Inst initiationjson
- Berlin Group SCT Inst status ACSCjson
- Berlin Group SCT Inst status RJCTjson
- Berlin Group SCT Inst status PDNGjson