Consent and account information (AIS)
The Account Information Service (AIS) of Klarna's XS2A v2 (Berlin Group openFinance) PSD2 API — the Berlin Group 2.x consent model (detailed and global), consent structure and lifecycle, and the supported account data (accounts, balances and transactions).
6 min read
The Account Information Service (AIS) lets a licensed AISP read a customer's account data after the customer has given explicit consent. Access requires the
PSP_ role in your certificate (see Authentication) and an authorized consent.Everything starts with a consent — so this page covers the consent model first, then the account data you can read once the consent is authorized.
The consent model
Every AIS access is backed by a consent that the customer authorizes via Strong Customer Authentication. The consent declares which accounts and what data the AISP may access, for how long, and how often.
Klarna supports two Berlin Group consent types:
consentType | What it grants | account reference | Access rights per entry |
|---|---|---|---|
detailed | Access to specific accounts you reference, with the exact rights you list. | Required on every entry | One or more of accountDetails, balances, transactions, trustedBeneficiaries, ownerName, owner, psuName |
global | Access to all of the customer's payment accounts. | Must not be present | Must contain ais; ownerName optional |
The Berlin Group
accountList and aspspManaged consent types remain in the wire enum for compatibility but are not supported — they are rejected with 400 CONSENT_. See Deviations from Berlin Group v2 for the consolidated list of differences from the standard.How a consent is structured (Berlin Group 2.x)
A consent is created with
POST /. The request body follows the Berlin Group openFinance 2.x Consents object:| Field | Required | Description |
|---|---|---|
access | Yes | The requested access, grouped under the payments product bucket. Each entry targets an account and/or carries access rights (shape depends on consentType). |
consentType | Yes | detailed or global (see The consent model). Determines how access must be shaped. |
recurringIndicator | Yes | true for recurring access to the account data, false for a single (one-off) access. |
validTo | Yes | Valid-until date (inclusive), as the ASPSP local date in ISO format, for example 2026-12-31. Capped at 180 days from today for every consent, recurring or one-off: a later date is shortened to today + 180 days. |
frequencyPerDay | Yes | Maximum number of accesses per day without customer involvement. Must be between 1 and 4 for a recurring consent, and exactly 1 for a one-off consent. Only unattended reads (without PSU-IP-Address) are counted, and for transaction history only the first page of a read; the limit is not currently enforced. |
The
access object exposes a single supported bucket, payments, holding the per-account access entries. Each entry has:account— a reference to the account the rights apply to. Mandatory fordetailed, forbidden forglobal. Onlyibanreferences grant access: adetailedentry whoseaccountcarries onlybban,panormaskedPanis ignored.rights— the access right codes for that entry (at least one). Allowed codes depend on theconsentType.
Detailed consent example
JSON
1
2
3
4
5
6
7
8
9
10
{
"access": {
"payments": [
{
"account": { "iban": "SE0000000000000000000000" },
"rights": ["accountDetails", "balances", "transactions", "ownerName"]
}
]
},
"consentType": "detailed",Global consent example
JSON
1
2
3
4
5
6
7
8
9
10
{
"access": {
"payments": [
{ "rights": ["ais", "ownerName"] }
]
},
"consentType": "global",
"recurringIndicator": true,
"validTo": "2026-12-31",
"frequencyPerDay": 4(The IBANs above are placeholders — use the customer's real account reference.)
Consent lifecycle
| Step | Operation | Purpose |
|---|---|---|
| Create | POST / | Create the consent and receive a consentId. |
| Authorize | POST /, then poll the scaStatus — see SCA | The customer approves the consent in the Klarna app. Account data is only accessible once the consent is authorized. The consent creation response contains no links, so build this path from the consentId. |
| Check status | GET / | Retrieve the current consent status. |
| Revoke | DELETE / | Cancel the consent. |
Once the consent is authorized, call the account data endpoints with the
consentId; access is limited to the accounts and rights the consent grants, within its validTo.Required request elements
Requests without these are rejected:
| Element | Where it is required |
|---|---|
X-Request-ID (a UUID) | Every call. |
PSU-IP-Address | Consent creation and payment initiation. On account data reads it is optional, except for one-off consents, which require it. |
Consent-ID (header) | Every account data read. |
bookingStatus (query) | Transaction history. information is rejected with 400 PARAMETER_. |
A one-off consent (
recurringIndicator: false) can only be read with PSU-IP-Address present and within one hour of the consent's creation. The hour is checked first: after it, the request fails with 401 CONSENT_ whether or not the header is present. Within the hour, a request without the header fails with 401 CONSENT_.Account data
With an authorized consent, the AIS covers current accounts (the Berlin Group
payments product bucket) and exposes:| Capability | Endpoint | Notes |
|---|---|---|
| Account list | GET / | The accounts covered by the consent. |
| Account details | GET / | Includes the account holder name (ownerName) when the consent grants it. |
| Balances | GET / | Current balances for an account. |
| Transaction history | GET / | Booked and pending transactions, with pagination. |
Other Berlin Group product buckets (
cards, cardAccounts, savings, loans, securities) are not supported — requests for them are rejected with 400 PARAMETER_.The account holder is provided in the account data: request the
ownerName access right in the consent and the name is returned with the account details.Transaction history is paginated. A transaction report links to further pages through
transactions.: next while more pages exist, and first on every page after the first. There is no last link. Follow next until it is no longer present to retrieve the full history; a page can hold up to 50 transactions, and a shorter page can still carry next.How far back transactions are available
The transaction history window depends on how long ago the consent was created:
- Within the first hour after the consent is created, all available transactions are returned.
- After the first hour, the transaction history is limited to the last 90 days.
To retrieve a customer's full transaction history, fetch it within one hour of creating the consent. After that window, only the most recent 90 days are returned for that consent.
Jump to section...