How to use the Consent API

According to the PSD2 RTS the intended use of consents differs depending on if the PSU is actively involved in the call.

In general, PSU attended calls are subject to higher limits which is why they should be flagged accordingly by setting the psu object in the request (see the respective pages of the consent section). Please be aware this object must hold the current PSU information, and must not contain outdated or placeholder values. Klarna is obliged to deactivate clients without notice which do not share the current PSU information to comply with the PSD2 regulation.

In general, in case a consent call has successfully returned the requested data, it can be considered finished.

In case a consent call could not retrieve the data from the bank (due to expiry, revocation, bank maintenance or other technical issues), the request towards the Consent API might result in an error (see error handling). In that case, the same call might be sent again and is considered a retry. All retries must always apply exponential backoff (see RFC 2988, Section 5, Recommendation 5.5) to not cause issues with the bank's systems.

The intention of an attended call is that the PSU is actively requesting information.

Upon request of the PSU, a request is expected to be sent towards the Consent API, querying for the requested data. As per definition scheduling of requests cannot be applied to a PSU actively requesting information.

In case of a Non-Successful Consent Call, the same call might be sent again (see Non-Successful Consent Calls) while the PSU is actively present. The retry should stop as soon as the PSU is no longer actively requesting the data.

Unattended calls are intended to be used for asynchronous refreshes of PSU data using for example a scheduled background task.

Typically unattended calls are subject to limitations through daily quota. According to the PSD2 RTS (Article 36(5)(b) of Commission Delegated Regulation (EU) 2018/389) the daily quota allows querying for account data 4 times a day. As the majority of banks follow this definition (either in a 24 hour window, or per calendar day, depending on the underlying bank), this is a good number to keep in mind when thinking about scheduling the refreshes. Important: The “4 times per day” limit is not defined per API request or call. The definition implies that all data of one account can be requested 4 times per day, applying for each account individually.

As the typical (bank side) applied daily quota introduces a strict limitation, it is important to find reasonable times to schedule Unattended Consent Calls. Most banks exclusively update the provided data at fixed booking times, typically between 8 AM and 8 PM (in the respective bank’s time zone). This means, in case a data refresh is required in a timely manner, the requests should be scheduled to roughly follow standard business hours. Those are usually in line with the times where users are most active, and therefore more interested in data refreshes. If providing the most recent updates to the consumers is not relevant for your use-case, a refresh during the night times or out-of-business hours should be preferred, to put less stress on all downstream systems. In general, it must be ensured that scheduled requests are evenly distributed (jittered) to prevent Rate Limiting (see Rate Limiting).

If you are integrated with our Account Insights offering, we recommend to use the automated data refreshes via the autorefresh/scheduling API, which will handle this complexity internally and follows all rules and restrictions automatically.

In case of a Non-Successful Consent Call, the failure can either be ignored, relying on the next scheduled call to succeed, or the same call might be sent again as a retry (see Non-Successful Consent Calls).

As the underlying bank might also apply the daily quota to non-successful calls, in this case a skip should be preferred over a retry. This will ensure the best availability of data, as a new call at a later point in time is more likely to succeed (as the bank might for example underlie some maintenance during the non-successful call).

results matching ""

    No results matching ""