Scope of the Card API

Card types covered with the Card API

In scope:

• Debit Cards
• Credit Cards
• Prepaid Cards
• Deposit Cards and Loyalty Cards (provision of these cards is at the discretion of the data provider)

Ouf of scope:

• Loyalty Cards with non-Scheme-based payment functionalities

The primary focus for developing the Card API specification was on the Mastercard and Visa schemes. However, the standard is designed to be inclusive of other schemes as well. Feedback that suggests necessary adaptations will be considered and implemented.

Transaction types covered with the Card API

• All transactions authorized or settled via a payment card (given that the card type is in scope of this API)
• Card account-based transactions (e.g. fees, deposits, bill payments) are only available in Level 2.
• Only financial transactions are covered (i.e., no PIN changes, balance inquiries, or status checks).

Matching transactions retrieved via Card API with debit card transactions which are accessible on the bank account via the XS2A API is not actively supported.
The Card API only provides card transactions in Level 2 on the card account as well. Please note that this card account is not equivalent to the bank account.

The current data model allows only one card account to be linked to a card and the card account will be linked to the main bank account for the card. ATM Futura transactions which are debited to a different bank account will not be included in the API to maintain consistency between the balance and the sum of transactions.

Provider and User of the API

Provider

It refers to the technical provider of the data which can rely on the Card API to allow a user to retrieve such information.
Any organization capable of implementing API endpoints that comply with the Common API Card API specifications (e.g., providing mandatory fields) can serve as a provider.
For the Level 2, this means for example that all mandatory fields for a card account and other Level 2 entities must be provided as defined in the standard for credit and debit cards.
In addition, the provider must be the party that can authenticate the user when a consent for data sharing needs to be confirmed.
It is expected that most often Card Service Providers will act at least as technical providers of the Card API. It is important to note that the approval of the data owner, i.e., the issuer, is a prerequisite for any party to act as Card API provider.
The data provider does not aggregate data across issuers. Data users could enable this, if the user grants the necessary consents.

User

The target user group of the Card API are third parties (e.g. fintechs) who can do business and/or enable new services based on the data retrieved via Card API (depending on the Level 1 or 2 they have been enabled for). Direct usage of the API by end-customers is not foreseen.
The user journey can be different depending on the requirements for data access defined by the provider and the established connectivity (e.g. via a hub vs. direct).

Use Cases

Using the Card API for integrating Card Service Providers with distribution partners or issuers is not the main focus, as more detailed information and further enhanced use cases are usually required.

Conditions for data access

The contractual and technical requirements for exchanging card data and the allowed uses can be freely agreed upon between Provider and User. The standard does not set any specific rule in this regard.