Introduction

How the API works: actors, consents, customer authentication, Berlin Group conformance, and the core registration flows.

This portal documents the OpenFinance integration on OpenFinance (Berlin Group openFinance XS2A API). Every request is made over mutual TLS with your QWAC and signed with your QSealC — the certificates identify you, so there is no separate authentication step. Access to customer data is governed by consents: you create one, the customer approves it, and its identifier accompanies your data requests. Payments follow the same pattern — create, the customer authorises, you track the status.

Actors and terminology

Term	Definition
TPP	Third Party Provider — the licensed entity (you) accessing accounts or initiating payments on behalf of a customer.
ASPSP	Account Servicing Payment Service Provider — the bank holding customer accounts.
PSU	Payment Service User — the customer who authorises access to their accounts or payments.
AIS	Account Information Service — read access to accounts, balances, and transactions.
PIS	Payment Initiation Service — initiation of payment orders on behalf of the PSU.
CoF	Confirmation of Funds — a yes/no check whether an account covers a given amount.
Provider code	Bank identifier in the API base URL path, for example test_bank or test_bank_sandbox. Selects the environment.

Consents

A consent is the customer’s permission to access their data. It defines what you may read (the access object), for how long (validTo, up to 180 days), and how often without the customer present (frequencyPerDay, up to 4). The structure of access depends on the consent type — the types and the access rights they carry are defined in Data types. Full attribute schemas and request examples are in the API reference under Consents.

A consent starts as received and becomes valid once the customer authorises it. Check the current value at any time via the consent status endpoint; all statuses are defined in Data types.

Customer authentication

Strong customer authentication (SCA) uses the redirect approach. Creating a consent or a payment returns a _links.scaRedirect URL — send the customer there, they authenticate with the bank and approve the action, and the bank redirects them back to the URL you supplied in Client-Redirect-URI. The resource status then advances (for example, a consent becomes valid). The sandbox runs the same flow with the test credentials.

Berlin Group conformance

The API implements the Berlin Group openFinance framework — the successor of NextGenPSD2. Account information, payment initiation, and confirmation of funds follow the standard request and response schemas; the exact set of implemented endpoints is the API reference in the sidebar.

Porting an integration built on Berlin Group NextGenPSD2 1.3: account information reads (accounts, balances, transactions) carry over nearly 1:1 — the notable changes are elsewhere:

Consents — consentType plus asset-class access sections with rights replace the 1.3 permission arrays (access.accounts/balances/transactions); validTo replaces validUntil.
Headers — TPP-* headers are renamed to Client-* (for example Client-Redirect-URI); Signature + TPP-Signature-Certificate are replaced by the detached x-jws-signature.
Payments — bodies follow a more ISO-structured model: creditor.name replaces creditorName, paymentIdentification.endToEndId replaces endToEndIdentification, and postal addresses nest under the creditor object.
Bulk payments — a creditTransfers array with batch metadata (paymentInformationId, numberOfTransactions, controlSum) replaces the flat payments array.
Paths — /v1/… becomes /v2/…, and consents carry their category in the path (/v2/consents/account-access).

Access to environments

Validate AIS and PIS against the sandbox provider code test_bank, then promote to test_bank after certification. PSU authentication in sandbox runs on https://openfinance-sandbox.saltedge.com.

Environments

Staging:: https://openfinance.saltedge.com/test_bank/api

Registration

An AISP certificate is required for AIS APIs and a PISP certificate for PIS APIs. Create consents before account information or payment calls.

Example consent creation for account access:

HTTP request

POST /test_bank/api/v2/consents/account-access
Host: openfinance.saltedge.com
Content-Type: application/json
Authorization: Bearer <access_token>
Digest: SHA-256=<digest>
x-jws-signature: <jws>
X-Request-ID: 99391c7e-ad88-49ec-a2ad-99ddcb1f7721

{
  "access": {
    "cards": [
      {
        "rights": [
          "ais"
        ]
      }
    ],
    "payments": [
      {
        "rights": [
          "ais"
        ]
      }
    ],
    "cardAccounts": [
      {
        "rights": [
          "ais"
        ]
      }
    ]
  },
  "validTo": "2026-09-30",
  "consentType": "detailed",
  "frequencyPerDay": 4,
  "recurringIndicator": true
}

Registration endpoints

Method	Path	Description
POST	`/v2/consents/account-access`	Create an AIS consent before account information requests.
POST	`/v2/consents/funds-confirmations`	Create a PIIS funds-confirmation consent.

API endpoints

Request pattern: {host}/{provider_code}/api/v2/{resource}. Full schemas are in the sidebar API reference.

Method	Path	Description
GET	`/v2/accounts`	List accounts available under an authorised consent.
GET	`/v2/accounts/{account-id}/balances`	Retrieve balances for a single account.
POST	`/v2/payments/sepa-credit-transfers`	Initiate a SEPA credit transfer payment.
DELETE	`/v2/consents/{consent-id}`	Revoke an existing consent resource.

Scopes

Term	Definition
AIS	Account information scopes for balances, transactions, and account lists.
PIS	Payment initiation scopes for SEPA and domestic payment products.
PIIS	Funds confirmation scopes for availability checks before payment.