Skip to main content

Account Information Service (AIS)

An Open Banking service that lets a Third-Party Provider retrieve account information from a user's payment account. The Account Information Service (AIS) covers account details, balances, and transaction history, accessed under PSD2 with the user's consent.

What TPPs can access​

  • Account list and details.
  • Account balances (available, booked, and pending).
  • Transaction history, with filtering and pagination.

Common AIS use cases​

  • Accounting and financial management software importing bank transactions automatically.
  • Personal finance management apps aggregating balances across multiple banks.
  • Business expense tracking and reconciliation tools.

Access conditions​

  • The Swan user must authenticate and grant explicit consent.
  • The user must have an active account membership with the canViewAccount permission.
  • Consent must be valid, meaning it has not expired or been revoked.
  • The connection must be active, meaning Salt Edge's daily refresh is working.

Transaction history​

  • By default, Swan returns all transactions since account creation, including cards and transfers.
  • TPPs commonly filter results to the last 3 months on their end.
  • Some TPPs expose an endpoint that lets users retrieve transaction history beyond 3 months.

Account scope​

By default, Swan returns all accounts the user has access to.

All or nothing

The consent flow does not currently allow users to select a subset of accounts; it is all or nothing.

No accounts visible after authentication​

This most often happens when a user authenticates with their personal phone number, but their Swan account is tied to their professional phone number. The phone number is Swan's unique user identifier, so authentication succeeds but returns no accounts.

Solutions:

  • Option 1, try with the correct phone number: authenticate again using the professional phone number linked to the Swan account.
  • Option 2, transfer accounts to the personal phone number:
    1. If the personal phone number is already linked to another Swan user, that user must first be deactivated to free the number (see the deactivateUser mutation preconditions).
    2. The user linked to the professional phone number (and to the accounts) then changes their phone number to the personal one at link.swan.io/edit-phone.
    3. Once complete, the accounts are accessible using the personal phone number.

For complex cases involving multi-project users, contact Swan Support.

Transaction field mapping​

The table below maps Swan's internal transaction fields to the external fields exposed through Salt Edge, following the Berlin Group standard.

Internal field (Swan)External field (Salt Edge)Notes
idid
amount.valueamountNegative string for debit, positive for credit.
amount.currencycurrencyCurrency code, such as EUR or USD.
statusInfo.bookingDatebooking_dateOptional. Date in YYYY-MM-DD format.
statusInfo.statusstatusOnly Booked and Pending transactions are exposed. Rejected transactions are not served through AIS.
statusInfo.valueDate when Booked, otherwise updatedAtvalue_dateDate in YYYY-MM-DD format. When the transaction is not booked, this refers to the updatedAt date.
labelremittance_information.unstructuredTransaction label or description. Swan defaults to something like Transfer to/from X if the input was empty when initiating a SEPA Credit Transfer.
referenceremittance_information.structuredStructured payment reference.
paymentIdextra.additional_informationNot the same as the transaction ID. A payment can have multiple transactions, for example for fees.
For SCTs: creditor.name. Else if user is on the credit side: account.holder.info.name. Else: counterparty.creditor_details.nameCreditor or recipient name.
creditor.IBANcreditor_details.account.ibanOptional. Always served when the transaction is a SEPA Credit Transfer or the end user is on the credit side.
creditor.currencycreditor_details.account.currencyOptional. Only served when the end user is on the credit side.
For SCTs: debtor.name. Else if user is on the debit side: account.holder.info.name. Else: counterparty.debtor_details.nameDebtor or payer name.
debtor.IBANdebtor_details.account.ibanOptional. Always served when the transaction is a SEPA Credit Transfer or the end user is on the debit side.
debtor.currencydebtor_details.account.currencyOptional. Only served when the end user is on the debit side.
Why rejected transactions are not served

Rejected transactions were never actually debited or credited. They represent failed payment attempts rather than completed financial movements, so they are excluded from AIS data.

Reconciliation: do not use value_date for pending transactions

For pending transactions, value_date maps to updatedAt, which changes every time the transaction is updated.

Instead:

  • Use id as the stable unique key across all states.
  • Use booking_date as the date anchor.
  • Only reconcile transactions with status Booked.

References​