Skip to main content

Account Information Services (AIS)

Account Information Services (AIS) on bLink enable a Service User (SU) to retrieve account information of a customer from a Service Provider (SP), based on an explicit customer consent granted in the Service Providers e-banking.

AIS is designed for Swiss cash management use cases and follows the Swiss Payment Standards (SPS). It reflects banking business rules such as booking-day finalization, intraday processing, and end-of-day (EOD) settlement. AIS is not a real-time accounting interface. A request may be technically successful while the underlying banking process is still ongoing or not yet finalized.

The AIS API is owned and orchestrated by SFTI. If you want to know more about the release cycle or contribute to the API specification, visit our Release Management section. bLink acts as a standardized, secure connectivity and API delivery platform offering the service.

Scope and consumption models​

AIS provides read-only access to account-related data and supports two complementary consumption models.

JSON-based endpoints offer structured, machine-readable access and are intended for applications that directly process balances and transactions:

  • GET /accounts
  • GET /accounts/{accountId}/balance
  • GET /accounts/{accountId}/transactions

ISO 20022-based endpoints deliver standardized customer-bank messages for accounting, reconciliation and reporting:

  • Statements (camt.053): GET /iso20022/statements and GET /iso20022/statements/{reportId}
  • Intraday reports (camt.052): GET /iso20022/reports and GET /iso20022/reports/{reportId}

For ISO 20022 statements and reports, account discovery via GET/accounts is not required. These resources are delivered for all applicable accounts covered by the consent. Account identification (e.g. IBAN) and the relevant message dates are part of the message content and can therefore be used by the consuming application to filter and process the data accordingly.

Pagination​

AIS list endpoints use cursor-based pagination. Pagination applies to:

  • GET /accounts
  • GET /accounts/{accountId}/transactions
  • GET /iso20022/statements
  • GET /iso20022/reports

If additional results are available, the SP returns an opaque cursor in the X-Next-Cursor response header. The value returned in the X-Next-Cursor response header must be passed unchanged in the cursor query parameter of the subsequent API call to retrieve the next page of data.

The limit parameter controls the number of items returned per page. The maximum supported limit is defined by the Service Provider. If a request specifies a limit that exceeds the provider-defined maximum, the SP truncates the result set to the maximum number of items it is able to return.

If no further results are available, the X-Next-Cursor header is returned empty. This indicates that the last page has been reached.

Banking business logic and status codes​

AIS distinguishes technical success from banking business logic and processing state.

A request can be technically valid and successfully processed while the underlying banking process, such as booking-day finalization or intraday enrichment, is not yet completed. AIS reflects this explicitly via HTTP status codes.

In Swiss banking, booking days are finalized through an end-of-day (EOD) process that typically takes place on working days in the late afternoon or evening. The EOD process always finalizes the last working day.

This is particularly relevant around weekends and holidays:

  • If the last working day is Friday, the EOD process on Friday finalizes the Friday booking day.
  • Bookings that occur during the weekend or on bank holidays are attributed to the next booking day.
  • These bookings remain intraday and are not finalized until the next working day’s EOD process is completed, typically on Monday in the late afternoon or evening.

From an API usage perspective, AIS exposes these booking-day semantics through its request parameters.

  • Requests without a date parameter are interpreted as intraday requests and may return data that is still subject to change during the current booking day.
  • Requests with a date parameter are interpreted as requests for closed booking day data and return finalized data for completed booking days only.

As a consequence, data requests for weekend or holiday dates may legitimately return 202 Accepted, even though bookings already exist. Finalized balances and transactions for those days become available only after the EOD process on the next working day has been completed.

Status codes​

  • 200 OK
    The request is processed and the requested data is available according to the current banking state.

  • 202 Accepted
    The request is valid, but the requested booking day is not finalized yet. The data will become available once the bank’s EOD processing is completed.

  • 204 No Content
    The request is valid, but the requested data will never be available, for example because the account did not yet exist on the requested date or date range lies entirely outside the Service Provider’s supported historical data range.

  • 4XX / 5XX
    Client-side or server-side errors.

Accounts​

GET /accounts returns a paginated list of accounts accessible under the granted consent, including identifiers and descriptive attributes such as accountId, account owner, account type and currency. The endpoint is called before using JSON-based balance or transaction endpoints, as those operate on accountId.

Balances​

GET /accounts/{accountId}/balance returns balance information for a specific account.

When called without a date parameter, the endpoint returns the interim booked balance (ITBD) for the current booking day. This balance is calculated during the SP’s business day and may change until EOD processing is completed.

When called with a past date, the endpoint returns the closing booked balance (CLBD) for that day. If the specified booking day has not yet been finalized, the response status is 202.

Transactions​

GET /accounts/{accountId}/transactions returns a list of transactions for a specific account. The endpoint supports cursor-based pagination and optional date range filtering using date_from and date_to. Transactions are sorted by booking date in descending order. SPs may apply additional provider-specific sorting but must ensure stable pagination behavior.

When called without a date range, the endpoint returns transactions since the last completed booking day. Depending on the entryStatus parameter, both booked and pending entries may be included. This mode is intended for intraday activity.

When called with a date range, the endpoint returns booked transactions from completed booking days within the requested range.

If the requested range defines only booking days that are not yet finalized, the response status is 202 Accepted and no transactions are returned.

If the requested range includes both completed and non-finalized booking days, the response status is 200 OK. All transactions from completed booking days within the range are returned. Non-finalized booking days are ignored and not included in the result.

The transaction endpoint follows standardized behavior for intraday, historical, and non-finalized booking days in alignment with the principles of the Swiss Payment Standards. To clarify the different response behaviors depending on the request pattern (for example intraday retrieval, historical date ranges, or requests including non-finalized booking days), a consolidated table overview is provided in the SFTI Transactions Endpoint Factsheet and must be interpreted accordingly.

ISO 20022 statements and reports​

ISO 20022 endpoints deliver standardized customer-bank messages aligned with SPS Cash Management.

Statements (camt.053) represent closed booking days. Once a booking day is finalized, a bank may generate a day statement containing the balances and bookings of that day. If no bookings occurred on the particular date, a statement may not be generated. bLink currently supports statements in schema version camt.053.001.08.

Intraday reports (camt.052) are snapshots of an unclosed booking day and are generated during the business day. Reports may be provided as full or incremental, depending on the SP configuration. bLink currently supports reports in schema version camt.052.001.08.

For both statements and reports, retrieval follows a two-step pattern:

  1. Retrieve the list of available resources (GET /iso20022/statements or GET /iso20022/reports).
  2. Retrieve individual resources using the returned identifiers.

Message content and booking variations​

ISO 20022 cash management messages follow the standard SPS structure, consisting of account-level information, entry-level bookings, and entry details.

Depending on the SP’s booking system:

  • Transactions may be booked immediately or transition through pending states
  • Intraday entries may be less enriched than finalized entries
  • Full enrichment typically completes during EOD processing

Some banks support external batch booking breakdown, where aggregated bookings are shown in camt.053 and detailed entry information is delivered separately via camt.054 through other channels. This configuration must not be active for customers connected via bLink, as camt.054 messages cannot be delivered through a bLink connection. For bLink-connected customers, banks must ensure that booking details are included directly in the delivered account data or that customers are explicitly informed that their configuration needs to be adjusted accordingly.

Data availability​

The availability and historical depth of AIS data depends on the Service Provider Offering. Service Users must design their retrieval strategy based on the supported history ranges and must not assume uniform retention across banks.

info

Details on data availability and endpoint-specific restrictions are defined in the Service Provider Offering.

Integration guidance​

Service Users integrating AIS should ensure:

  • Correct handling of 200, 202, and 204 responses
  • Retry logic aligned with booking-day finalization, including weekends and holidays
  • Proper cursor-based pagination, including empty X-Next-Cursor handling
  • A retrieval strategy appropriate for the use case, using JSON endpoints for structured processing and ISO 20022 endpoints for reconciliation and reporting
  • Finalized data is available after the bank’s end-of-day (EOD) processing. Batch retrieval of data is recommended in the early morning to reduce the risk that the data is not yet available.
Last updated on