MX (Open Banking) Authentication Methods & Security (2026)

Authentication overview

MX (Open Banking) provides an API-driven platform for financial data aggregation and enhancement. Secure access to these services is managed through established authentication protocols designed to protect sensitive financial information. The choice of authentication method depends on the integration's purpose and the nature of data access, whether it's server-initiated processing or user-consented data sharing. MX emphasizes adherence to security standards such as SOC 2 Type II, GDPR, and CCPA to maintain data integrity and privacy across its financial data aggregation products MX compliance information. Understanding the available authentication mechanisms is critical for developers building applications on the MX platform.

Supported authentication methods

MX supports different authentication methods tailored to various integration scenarios, primarily focusing on API keys for direct application access and OAuth 2.0 for user-delegated authorization. These methods ensure that only authorized applications and users can access the financial data managed by MX.

The following table outlines the primary authentication methods, when to use them, and their general security levels:

API Keys

API keys are unique identifiers used to authenticate an application or user to the MX API. They function as a secret token, granting access to MX services. For server-to-server interactions where a user is not directly present to grant consent, API keys are the standard. They are typically passed in the request header (e.g., Authorization: API_KEY your_api_key or MX-API-Key: your_api_key) or as a query parameter, although header transmission is generally more secure MDN Web Docs on Authorization header. MX API keys are associated with a specific client and environment (e.g., production, sandbox) and should be treated as sensitive credentials.

OAuth 2.0

OAuth 2.0 is an authorization framework that enables an application to obtain limited access to a user's protected resources (like financial data) without exposing the user's credentials. It is primarily used when an end-user needs to grant an application permission to access their financial data from their bank or credit union through MX. The flow involves redirecting the user to their financial institution's login page (or MX's aggregation flow), where they authorize the data sharing. Upon successful authorization, MX provides the client application with an access token, which is then used to make API requests on behalf of the user. OAuth 2.0 is the industry standard for delegated authorization, offering granular control over permissions and enhanced security compared to direct credential sharing OAuth 2.0 documentation. MX's implementation of OAuth 2.0 adheres to best practices for secure token management and consent flows MX API documentation on OAuth 2.0.

Getting your credentials

To begin integrating with MX, developers need to obtain API credentials. This process typically starts after signing up for an MX developer account or establishing a commercial relationship. Access to the MX Client Dashboard is essential for managing and retrieving these credentials.

1. Sign Up/Account Creation: Developers must first register for an MX account. This usually involves contacting MX sales to set up a commercial agreement, which provides access to the developer portal and client dashboard MX contact sales.
2. Access the MX Client Dashboard: Once an account is established, developers gain access to the secure MX Client Dashboard. This web-based interface is the central hub for managing all aspects of an MX integration, including credential generation.
3. Generate API Keys: Within the dashboard, navigate to the API Keys or Credentials section. Here, you can generate new API keys for different environments (e.g., sandbox for testing, production for live applications). It is crucial to generate separate keys for each environment to prevent accidental data exposure or misuse.
4. Configure OAuth 2.0 Redirect URIs: For applications using OAuth 2.0, you will need to register your application's authorized redirect URIs in the MX Client Dashboard. These URIs are callback URLs where MX will redirect the user after they have granted or denied consent. This step is vital for the security and proper functioning of the OAuth flow.
5. Store Credentials Securely: Upon creation, API keys and client secrets should be stored securely. MX will typically display the secret key only once upon generation. Loss of a secret key often requires regeneration.

MX provides a sandbox environment that mirrors the production environment, allowing developers to test their integrations thoroughly without impacting live data. Credentials generated for the sandbox environment are distinct from production credentials MX developer documentation.

Authenticated request example

API keys are typically sent in the HTTP request headers. Here's an example using curl to demonstrate how to make an authenticated request to a hypothetical MX endpoint, assuming you have an API_KEY and CLIENT_ID. These are placeholders for the actual credentials you obtain from the MX Client Dashboard.

This example fetches a list of members associated with a user:

curl -X GET \
  'https://api.mx.com/users/USER_GUID/members' \
  -H 'Accept: application/vnd.mx.api.v1+json' \
  -H 'Authorization: API_KEY YOUR_API_KEY' \
  -H 'MX-Client-ID: YOUR_CLIENT_ID'

In this example:

• YOUR_API_KEY is the API key obtained from your MX Client Dashboard.
• YOUR_CLIENT_ID is your unique client ID, also obtained from the dashboard.
• USER_GUID is a placeholder for a specific user's unique identifier within your MX integration.
• Accept: application/vnd.mx.api.v1+json specifies the desired API version and content type.

For OAuth 2.0, after the user completes the authorization flow and your application receives an access token, subsequent API requests will include this token in the Authorization header, typically using the Bearer scheme:

curl -X GET \
  'https://api.mx.com/users/USER_GUID/accounts' \
  -H 'Accept: application/vnd.mx.api.v1+json' \
  -H 'Authorization: Bearer YOUR_ACCESS_TOKEN'

Here, YOUR_ACCESS_TOKEN is the OAuth 2.0 token received after a successful user authorization flow.

Security best practices

Implementing strong security measures is paramount when working with financial data. MX provides guidance and expects integrators to follow industry best practices to protect credentials and user data.

• Keep API Keys and Client Secrets Confidential: Never hardcode API keys or client secrets directly into client-side code (e.g., JavaScript in a browser). Store them in environment variables, secure configuration files, or a secrets management service. Access control should be strictly enforced for any system that stores these credentials.
• Use HTTPS/TLS: All communication with MX APIs must occur over HTTPS (TLS 1.2 or higher) to encrypt data in transit and prevent eavesdropping or tampering. This is a fundamental security requirement for any API handling sensitive data IETF RFC on TLS 1.3.
• Implement Least Privilege: Configure your application to request only the necessary permissions (scopes) when using OAuth 2.0. This limits the potential impact if a token is compromised. For API keys, ensure that keys are only granted access to the specific resources and actions required by the application.
• Rotate Credentials Regularly: Periodically rotate API keys and client secrets. This practice minimizes the window of opportunity for attackers if a credential is ever compromised without detection. MX's dashboard allows for the generation of new keys and revocation of old ones.
• Error Handling and Logging: Implement robust error handling that does not expose sensitive information in logs or to end-users. Log authentication failures for security monitoring and anomaly detection, but avoid logging actual credentials.
• IP Whitelisting: If supported by MX for your integration type, restrict API key usage to a predefined list of trusted IP addresses. This adds an additional layer of security by ensuring that even if a key is stolen, it can only be used from authorized locations.
• Secure Client-Side Implementations: For mobile or web applications utilizing client-side SDKs, follow MX's specific guidelines for secure implementation, especially regarding how tokens are stored and refreshed. Avoid storing refresh tokens directly on client devices without strong encryption and secure storage mechanisms.
• Monitor API Usage: Regularly review API access logs and monitor for unusual activity, such as a sudden spike in requests, requests from unexpected geographical locations, or repeated authentication failures.
• Adhere to MX Documentation: Always refer to the official MX developer documentation for the most current and specific security recommendations and implementation details for their authentication methods MX security guidelines.