Klarna requires Acquiring Partners to provide settlement bank account details, such as IBANs or local account numbers, when onboarding Partners to Klarna. This data is essential for Klarna’s fraud assessment and regulatory compliance processes.

Because bank account numbers are considered sensitive personal data, transmitting them in raw form raises privacy and data-protection concerns. To address this, Klarna offers a privacy-preserving approach that allows Acquiring Partners to submit a hashed version of the account number.

This enables Klarna to perform fraud assessment without accessing the original, unmasked data, balancing strong privacy safeguards with the need for effective risk controls.

To support fraud assessment while preserving data privacy, Acquiring Partners may hash settlement bank account numbers before sending them to Klarna. Hashes must be generated using the Argon2id algorithm with a standardized configuration and a pre-shared salt.

This ensures the data:

  • Cannot be reversed to reveal the original account number.
  • Produces consistent output for matching across requests.
  • Is strongly protected against brute-force attacks.

To ensure consistent and accurate hashing, the input data must be preprocessed in a standardized way before hashing. This includes remove any whitespace since all value after the whitespaces will be removed and ensure content is uppercase. For example:

Do

DE1912312312

Don't

DE19 1231 2312

Do

DE1912312312

Don't

De1912312312

Standardizing preprocessing is essential to ensure consistent hash output and reliable matching.

New fields, iban_hash and account_number_hash, will be added to supplementary_business_data. Acquiring Partners may use these fields when onboarding a new Partner using this endpoint, to provide a hashed IBAN or generic bank account value if there are privacy concerns. Otherwise, the existing iban or bank_account fields should be used.

Hashing is supported only for the iban and account_number inputs. When submitting a hashed version of either, the object must include three properties:

PropertyDescription
valuethe Base64-encoded Argon2id output
sanitization_methodenum, currently only "uppercase-no-spaces"
algorithmenum, currently only "Argon2id"

Sample request 1

JSON
{
  "partner_business_entities": {
    "supplementary_business_data": {
      "partner_payouts_state": {
        "bank_accounts": [
          {
            "bank_account_type": "IBAN",
            "account_holder": "John Doe Stakehouse",
            "bic": "NDEASEGGXXX",
            "iban_hash": {

When the standardized Argon2id configuration and pre-shared salt are applied to "DE1912312312", it produces the Base64 output shown above.

Sample request 2 - US account

JSON
{
  "partner_business_entities": {
    "supplementary_business_data": {
      "partner_payouts_state": {
        "bank_accounts": [
          {
            "bank_account_type": "LOCAL_US",
            "account_holder": "John Doe Stakehouse",
            "routing_number": "123456789",
            "account_number_hash": {