The IBAN of the sender account for which the transfer flow should be executed.

Some banks provide the customer with an option to change the account from which the money is sent during the payment authorization. This could happen even if an account was already selected through this field.

The account identifier - as provided in the result of an accounts flow - of the sender account for which the transfer flow should be executed.

Some banks allow the customer to change the account from which the money is sent during the payment authorization.

The account number - as provided in the result of an accounts flow - of the sender account for which the transfer flow should be executed.

Some banks allow the customer to change the account from which the money is sent during the payment authorization.

A configuration for filtering the options at the account selection for the consumer. This can't be used in combination with the iban and account_id fields.

The amount that should be transferred.

The reference for the transfer. The actual reference for the transfer might differ from this and can be found in the adjusted_reference property in the response (see below).

The reference for this transfer will be visible to the recipient of the funds. There are several things to be aware of when setting references:

• In some cases the reference could be received in an altered or incomplete way, depending on the banks involved. Best practice is to put the most relevant information at or near the beginning of the reference string. Furthermore, some banks restrict the content of the reference. Therefore the XS2A API strips or replaces special characters such as "ä","ö" and "ü" (RegEx: [^a-z0-9-+.]).
• The reference should be unique as some banks reject transactions with identical references as duplicate.

Note for Klarna Branded Integrations: This is the reference, which will be shown to the customer when being requested to authorize the payment within the Klarna Branded Open Banking App.

Additional references that should be used for a transfer. In case an additional bank reference is not supported by the bank we use the reference field as a fallback.

The unstructured reference will be shown on debtor and creditor account and will be ignored if not supported by the bank interface. Even if the debtor bank supports the unstructured reference it is possible that it is not supported by the creditor bank and not available there.

The structured reference will be shown on debtor and creditor account and will be ignored if not supported by the bank interface. Even if the debtor bank supports the structured reference it is possible that it is not supported by the creditor bank and not available there.

The end_to_end reference will be shown on debtor and creditor account and will be ignored if not supported by the bank interface. Even if the debtor bank supports the end_to_end reference it is possible that it is not supported by the creditor bank and not available there.

The message reference will exclusively be shown on the debtor account and will be ignored if not supported by the bank interface.

The opposing_message reference will be shown on debtor and creditor account and will be ignored if not supported by the bank interface. Even if the debtor bank supports the opposing_message reference it is possible that it is not supported by the creditor bank and not available there.

A reference used for a national transfer. The format for this parameter could vary for countries/banks and is not supported by all banks. For now a national reference is only supported by Finnish banks.

Example: In Finland banks support a national reference with a specific format including a checksum which leads to a lower fee amount for national transfers.

The Merchant Category Code that should be used for the transfer. The expected format is a String of 3 or 4 numbers (\d{3,4}). Information follows the ISO-18245 Standard.

The Purpose Code that should be used for the transfer. The expected format is a String of 4 letters.

The transfer_method property sets the type of the transfer being made (default: "sct") :

• choose sct when using the SEPA Credit Transfer
• choose sct_instant for starting a SEPA Instant Credit Transfer

The date for which the transfer should be scheduled. The date for which the transfer was actually scheduled might differ from this and can be found in the adjusted_date property in the response (see below).

The default value or if it's not supported by the Integration for preferred_date is the current date in the UTC timezone.

This feature is not available for all Integrations at the moment. Please reach out to us before using this field.

The to property acts as a wrapper object for the information on the receiving party.

The IBAN of the receiving account.

This property is validated with regard to correctness and structure.

The holder name of the receiving account.

The address of the holder of the receiving account.

Some banks might reject transfers without the holder_address, especially international transfers. This mostly concerns the to.holder_address.street_address, to.holder_address.postalcode, to.holder_address.city and to.holder_address.country.

The BIC of the bank of the receiving account.

This property is validated with regard to correctness and structure.

The name of the bank (branch) for which the receiver account is registered.

The address of the bank of the receiving account.

For successful flows the type property always holds the value transfer.

The adjusted_date property contains the date on which the transaction will be executed as provided by the bank. This date may differ from the one provided in the preferred_date property provided in the request.

The adjusted_reference property contains the reference as displayed and possibly modified by the bank.

The adjusted_bank_references property contains information about the used and possibly modified references.

The adjusted unstructured reference.

The adjusted structured reference.

The adjusted end_to_end reference.

The adjusted message reference.

The adjusted opposing_message reference.

The adjusted national reference.

The adjusted Merchant Category Code provided by the bank.

The adjusted Purpose Code provided by the bank.

[deprecated] Please use the property bank_transfer_id instead.

The bank_transfer_id property contains the transfer reference that was used internally by the bank. This could be useful for further turnover matching. The values of this object are not normalized and the meaning and format could differ per PSD2-framework or even per bank. For more information, visit the related PSD2-API documentation of the specific banks.

The transfer_id property contains a generated id by Klarna. It can be used to fetch the transfer state via the Consent Transfer-State API.

The transfer_token property contains a transfer token to fetch the state of a payment. This Token is only present for PSD2 integrations and can be used via the Consent Transfer-State API.

The transfer_state property contains the current state of the transfer.

• AUTHORIZED - The transfer was authorized but not yet booked by the bank.

• COMPLETED_DEBTOR - The transfer was booked and sent by the debtor bank.

• COMPLETED_CREDITOR - The transfer was received by the creditor bank.

The bank_transfer_state property contains the current state of the transfer as provided by the bank.

The values are not normalized and the meaning and format could differ per PSD2-framework or even per bank. For more information, visit the related PSD2-API documentation of the specific banks.

The from property holds information about the account from which the money was sent.

This account might be empty if the banks don't provide the account which was used for the transfer.

This account might differ from the one selected when starting the transfer.

Furthermore it has to be noted that in this case the data.result.from.id field is not always provided. All other properties behave as documented in the account object.

The amount that was transferred.

The to property holds information about the account to which the money was sent.

The IBAN of the receiving account.

The holder name of the receiving account.

The address of the holder of the receiving account.

The BIC of the bank of the receiving account.

The name of the bank (branch) for which the receiver account is registered.

The address of the bank of the receiving account.

The to_fee property denotes the fee on the sender that incurred for the executed transaction.

The transfer_method property indicates which transfer method was used for the transfer.

• SCT - SEPA Credit Transfer

• SCT_INSTANT - SEPA Instant Credit Transfer

• SE_BANKGIROT - Bankgiro Transfer in Sweden

• SE_PLUSGIROT - Plusgiro Transfer in Sweden

• GB_DOMESTIC - Domestic Transfers in Great Britain

The authentication_method property indicates which authentication method was used for the transfer. Most of them involve transaction numbers (TANs) that are one-time passwords (OTPs) used for authentication.

• CLASSIC_TAN - The OTP was given to the user by the bank on a sheet of paper that holds many of these OTPs, hence the OTP is not generated on the consumer-side. CLASSIC_TAN is one of the oldest authentication methods.

• ITAN - The OTP was given to the user by the bank on a sheet of paper that holds many of these OTPs, like CLASSIC_TAN, but in this case the OTPs are denoted with an index that is referred to during the transaction process.

• MTAN - The OTP is sent to the consumer via text message.

• CHIPTAN_MANUAL - The OTP is generated on the consumer-side by means of a card-reader device. The consumer has to insert their debit/credit card into the device and also input a number provided during the transaction process. The device is not connected to the consumer's computer/smartphone.

• CHIPTAN_FLICKER - The OTP is generated on the consumer-side by means of a card-reader device, like CHIPTAN_MANUAL, but instead of entering a number manually the consumer has to hold the device up to the screen to enable an optical transmission of information from their computer to the device. The optical transmisson is realized via the flicker method. The device might be connected to the consumer's computer.

• SMARTTAN - The OTP is generated utilizing a dedicated device that may or may not require the consumer's ec card. No data about the transaction is entered into the device.

• SMARTTAN_PLUS - The OTP is generated utilizing a dedicated device that may or may not require the consumer's ec card. Additionally data about the transaction is entered into the device.

• PHONE_TAN - The OTP will be communicated via speech synthesis in an automatic call to the consumer's phone.

• PASSWORD - The consumer has to enter a password (different to the login password) to authenticate the transaction. Consequentially the password will be the same for all transactions of a specfic consumer.

• PHOTO_TAN - The OTP is generated on the consumer's smartphone or hardware device which is used to scan an image file provided by the bank. There are also cases in which the consumer confirms the transaction in the smartphone app and does not have to enter an OTP. The image that is to be scanned is not animated and in most cases made up of a pattern that includes multiple colors.

• USB_DONGLE - The USB-Dongle is a device that is connected to the consumer's computer via USB and either displays an OTP or enables the consumer to confirm the transaction by pushing a button.

• EMAIL_TAN - The OTP is sent to the consumer via e-mail.

• PUSH_TAN - A specific app on the consumer's smartphone receives a push notification stating that the OTP is available in the app. In most cases a password is required to enter the app.

• TAN_SELECTION - A mostly internal step which indicates that the customer has to select an authentication method. Usually this state will be overwritten by the actual authentication method, but if it does not then this indicates that the consumer did not make a selection and aborted the process.

• HBCI_KEYFILE - The consumer used an HBCI keyfile to authenticate. Along with the file a PIN and optionally a username have to be provided.

• APP_TAN - A specific app on the consumer's smartphone receives a push notification which the consumer can interact with and confirm the payment within the app. This process does not involve an OTP.

• UNKNOWN - The authentication method was unknown or could not be determined.

• OTHER - The authentication method is known. However, it does not fit into one of the other categories and it is also not common enough to demand a seperate category.

• NONE - Authentication was not required.