# Support
source: https://developer.mastercard.com/open-finance-data/documentation/support/index.md

## FAQ {#faq}

### General {#general}

The Mastercard Open Finance Data API enables you to access bank-verified financial information directly from your users' accounts with their explicit consent. Our platform allows you to retrieve account details, balances, transaction history, and account holder information from thousands of banks and financial institutions across Europe. The examples of possible use cases include verifying account ownership during onboarding, assessing creditworthiness for lending, enabling personal finance management tools, or validating payment account details for direct debits. Yes, we are currently integrating banks' PSD2 Account Information Service (AIS) APIs across Europe. However, to ensure you get the best experience possible, we may still use enhanced connectivity methods if the quality of banks' PSD2 APIs does not meet our standards. Our platform abstracts these differences and provides you with a consistent, normalized data model regardless of the underlying bank connection. Consent is an integral part of PSD2 and collaboration with third parties. Under PSD2, the only way Account Information Service Providers (AISPs) can access financial data on behalf of customers is if the customer has given explicit consent (authorization). The process by which a Payment Service User (PSU) gives a Third Party Provider (TPP) permission to access their financial data from their Account Servicing Payment Service Provider (ASPSP) is called Consent. In Mastercard Open Finance Data, consent can be either one-off (for single data retrieval, such as Account Opening) or ongoing (for recurring access, such as Financial Management or Lending). You are initially onboarded in the Sandbox environment. Test banks and test users are provided in this environment, which provides the same features as live banks without exposing real financial institution data. The Sandbox allows you to test consent flows, data retrieval, webhooks, and error scenarios in a safe environment.

Production is a paid tier that allows partners to access the Mastercard Open Finance Data API services with supported banks across Europe, available after onboarding and integration validation.
You can [Contact us](mailto:openbankingeu_support@mastercard.com%3E) to get in contact with our sales team who can walk you through the process of getting onboarded so that you can start integrating with the Mastercard Open Finance Data APIs. During onboarding, you will receive sandbox credentials, API documentation, and technical support to help you build and test your integration. Mastercard Open Finance Data supports multiple data scopes that you can request based on your use case:

* **Accounts**: Basic account information including account identifiers (IBAN, account numbers)
* **Holders**: Account holder names and identity information
* **Balances**: Current account balances (available, current, and other balance types)
* **Transactions**: Transaction history including dates, amounts, descriptions, and merchant information

You specify the required scopes when creating a consent, and users see exactly what data they are authorizing you to access.

### Licenses and certificate {#licenses-and-certificate}

No. Although you can leverage your own Account Information Service Provider (AISP) license if you have one, this is not necessary. Mastercard Open Finance operates under appropriate regulatory permissions, allowing you to access financial data through our platform. [Contact us](mailto:openbankingeu_support@mastercard.com%3E) to understand how you can benefit from our solution without obtaining your own license. For Sandbox testing, you can use self-signed certificates. However, for Production, you must acquire a certificate from a supported Certificate Authority (CA). We recommend generating your private key in a Hardware Security Module (HSM) or similar secure environment, exporting the public key, and sharing the public certificate with us during onboarding. We will add your certificate to our list of trusted certificates to enable OAuth 2.0 authentication with JWT assertions.

### Markets and coverage {#markets-and-coverage}

We support banks and financial institutions across the European Union and European Economic Area (EEA). Our coverage continues to expand as we integrate additional banks and markets. For a full overview of supported countries and banks, refer to our **Supported Banks** documentation or contact our sales team for the latest coverage information. We support a vast majority of banks across Europe, including major retail banks, challenger banks, and regional financial institutions in both the B2B and B2C markets. Our bank coverage continues to grow as we integrate new institutions.

For a full overview of supported banks and their capabilities (such as available data scopes and consent durations), refer to our Supported Banks documentation or contact our support team.

### Compliance and security {#compliance-and-security}

Yes. Compliance and security are integral to Mastercard Open Finance Data, including adherence to EU legislation and PSD2 (Revised Payment Service Directive). We operate as a regulated Account Information Service Provider, ensuring that all data access follows PSD2 requirements for consent, Strong Customer Authentication, and data protection. To make data access safer and reduce fraud, Strong Customer Authentication (SCA) is an EU requirement under PSD2. When a customer authorizes access to their financial data, the bank requires the customer to authenticate using at least two of the three following authentication measures:  

* Something that the customer knows (password or pin)
* Something that the customer has (phone or laptop)
* Something the customer is (fingerprint or face recognition)

SCA is handled directly by the customer's bank during the consent flow. Mastercard Open Finance orchestrates the flow but never handles the customer's banking credentials.
User financial data is protected through multiple layers of security:

* **Consent-based access** - Data is only accessed with explicit user consent
* **Strong Customer Authentication** - Required by banks before granting access
* **Encrypted communication** - All API calls use HTTPS with TLS encryption
* **OAuth 2.0 with JWT** - Industry-standard authentication with signed assertions
* **Scoped access** - You only receive the specific data scopes the user authorized
* **Consent expiry** - One-off consents expire automatically; ongoing consents have defined validity periods
* **User revocation** - Users can revoke consent at any time through their bank or your application

### Consent management {#consent-management}

**One-off consent** is used for use cases that require data retrieval only once, such as Account Opening verification. The data is retrieved immediately after the user authorizes access, and the consent automatically expires within 24 hours.

**Ongoing consent** is used for use cases that require recurring data access, such as Financial Management, Lending, or Direct Debit monitoring. Ongoing consent is valid for a specified duration (for example, 90 days or 12 months), during which data can be refreshed at regular intervals. Users can revoke or renew their consent at any time.
**One-off consent** : Expires within 24 hours after data retrieval **Ongoing consent** : Validity period varies by use case and bank, typically ranging from 90 days to 12 months **User control**: Users can revoke consent at any time, regardless of the original validity period Yes. Users retain full control over their consent and can revoke it at any time through their bank's interface or through your application if you implement consent management features. When consent is revoked, you will no longer be able to access the user's financial data, and you should delete or anonymize any stored data according to your data retention policies and GDPR requirements.

### Using webhooks and receiving notifications {#using-webhooks-and-receiving-notifications}

Yes. We provide you with the ability to receive real-time notifications for important events through webhooks. Supported webhook events include:

**Consent modified** : When consent status changes (for example, authorized, revoked, expired)
**Connection modified** : When bank connection status changes (for example, expired, active after reauthentication)
**Account data modified** : When account information has been updated
**Transaction data modified**: When new transactions are available

Refer to [Webhooks](https://developer.mastercard.com/open-finance-data/documentation/event-notifications/index.md) for implementation details, payload structures, and signature verification requirements.
To receive webhook notifications:

1. Expose a public HTTPS endpoint in your application
2. Configure the webhook URL during onboarding or through the API
3. Implement signature verification to validate that webhooks originate from Mastercard
4. Respond with HTTP 200 status code within the timeout period to acknowledge receipt
5. Process webhook payloads asynchronously to avoid timeouts

If we do not receive a successful acknowledgment, we will retry the webhook up to 10 times with exponential backoff.

### Data refresh and updates {#data-refresh-and-updates}

For ongoing consent, data refresh frequency depends on your use case and configuration:

* **Scheduled refresh**: Data is automatically refreshed at regular intervals (for example, daily)
* **On-demand refresh**: You can trigger a data refresh by calling the appropriate API endpoints
* **Webhook-driven**: Subscribe to webhooks to be notified when new data is available

The refresh frequency and mechanisms are configured during onboarding based on your use case requirements.
For ongoing consents, we refresh end-users' account and transaction data from their provider institutions on a regular basis. During this refresh, we re-fetch transactions from the recent past to ensure that any updates to transaction status and details are captured. During this process, if a transaction's information has changed, we match the transaction against its previous version and overwrite it.

However, in some cases the updated transaction information will be sufficiently different from the original that matching will not be possible. In this case the original transaction will be shown as a shadow transaction, with a status of SHADOW, and another transaction will be returned that will replace it. When processing the transaction information, you should remove any shadow transactions from the transaction
set.

More generally, a shadow transaction is one previously retrieved from the provider institution but missing in the subsequent updates. As well as occurring when the transaction details have changed so much that they cannot be matched against the previous version, they may also arise when the provider removed the transaction from the account and it does not exist anymore.
If a bank connection expires (for example, due to the bank's session timeout or reauthentication requirements), you will receive a webhook notification indicating that the connection status has changed. You should prompt the user to reauthenticate with their bank to restore the connection. The consent remains valid during this time, and data access resumes once the connection is reestablished.

### Testing and development {#testing-and-development}

The Sandbox environment provides multiple test banks that simulate different scenarios:

* **Standard test bankd**: Simulate successful consent flows and data retrieval
* **Error scenario banks**: Test specific error conditions and edge cases
* **Different bank types**: Represent various authentication methods and consent flows used by real banks

Refer to the [Testing](https://developer.mastercard.com/open-finance-data/documentation/testing/index.md) documentation for a complete list of test banks, test user credentials, and testing scenarios.
Sandbox test users are provided with predefined credentials. Common test usernames include:

* max.mustermann / password: Standard successful flow
* erika.mustermann / password: Multi-step authentication flow
* nomoney.mustermann / password: Scenarios with no accounts or transactions

Detailed test credentials and their behaviors are provided in the [Testing](https://developer.mastercard.com/open-finance-data/documentation/testing/index.md) documentation.

### Integration and technical support {#integration-and-technical-support}

We provide code samples in multiple languages (curl, Java, C#) covering common integration scenarios:

* OAuth 2.0 authentication with JWT
* Consent creation and flow initiation
* Data retrieval with various scopes
* Webhook signature verification

Code samples and Postman collections are available in the **Resources** section.
1. Check the error response for specific error codes and messages
2. Consult the [Error Handling](https://developer.mastercard.com/open-finance-data/documentation/code-and-formats/index.md) documentation for common errors and solutions
3. Review logs for consent IDs, flow IDs, and correlation IDs to help troubleshooting
4. Contact support through the form below if you need assistance
Use the [Contact us](mailto:openbankingeu_support@mastercard.com%3E)s form to report bugs, request features, or provide feedback on the API. Include as much detail as possible, such as consent IDs, error messages, and steps to reproduce issues.

## Get Help {#get-help}

Complete the [Contact us](mailto:openbankingeu_support@mastercard.com%3E) form if you have any questions or require assistance. Our support team is available to help with technical integration questions, onboarding support, and general inquiries about Mastercard Open Finance Data.