Skip to main content
MX Data Exchange (MDX) is a proprietary specification for the exchange of data between financial institutions and MX. Its core resources are users, members, accounts, transactions, and holdings, which are the data objects that comprise the foundation of the MDX APIs MDX Real Time and MDX On Demand:
  • The user object represents the end user who is accessing the MX platform through the mobile application, web application, or proxy via a third-party application.
  • The member object represents the connection between the user and their financial institution(s).
  • The account object represents the individual financial account that is connected to a financial institution through the member object. The member object can hold multiple accounts for the same user.
  • The account number object represents the account, routing, or transit numbers that identify the account object. There can be only one account number per account object.
  • The transaction object represents a debit or credit to the account object and includes the accompanying metadata. There can be multiple transactions per account.
  • The holdings object represents a financial asset such as stock shares, bonds, funds, real estate, or other investments in a portfolio.
For a more detailed description of these resources, see MX Data Architecture. Use the standards laid out in this guide to help you work in the MDX API.

​
Character Set

MDX uses UTF-8 encoding for all fields in request and response bodies. Note that some fields have additional restrictions on valid characters.

​
Date and Time Formats

Date and time fields are supported in either Unix epoch time or ISO 8601 format.

​
Unix epoch time

Fields in Unix epoch time end in _at. This format doesn’t contain milliseconds. The value is stored as UTC, such as 1504224000.

​
ISO 8601 format

Fields in ISO 8601 format end in _on. This format doesn’t contain a timestamp. The value is stored as YYYY-MM-DD, such as 2017-09-01, and values dated earlier than 1970-01-01 are invalid.

​
Decimal Number Limits

The limits for decimal numbers are described by their precision and scale in the format precision,scale. Precision refers to the total number of digits, and scale refers to the number of digits to the right of the decimal. For example, 538.46 has a precision of 5 and a scale of 2, described in precision,scale format as 5,2.

​
Default Values

Some fields have a default value that populates automatically when no value is supplied. These values are noted where applicable in the field description, such as in the name field of the Member Fields endpoint. Don’t enter placeholder values in fields that have default values.

​
Deleting Objects

When you delete an object on the MX platform, all of its child objects are also deleted. For example, if you delete a member object, you also delete its associated accounts, transactions, and holdings.

​
Soft deletions and purges

There are two different types of deletions:
  • Soft deletions: An object that is soft deleted still exists in the database, but is no longer accessible and is slated to be purged. In some cases, MX can restore soft-deleted members.
  • Purges: An object that is purged has been permanently erased from the system. Purged objects can never be restored.
When an object is deleted, it is typically soft deleted and then fully purged within two weeks; the exact timeframe can vary. Some delete actions result in immediate purges as outlined in permanent deletions.

​
Restoring deleted members

A soft-deleted object can’t be explicitly restored via the API, but MX may be able to restore a soft-deleted member in some cases. When you delete a member, it goes into a soft-deleted state. If a new member is created for the same user on the same institution with the same credentials, the soft-deleted member is purged and the new member is created. To restore a soft-deleted member, you must contact MX Support before it’s purged. Once a member is purged, it can’t be restored.

​
Permanent deletions

There are some cases in which deleted objects are immediately purged without first entering the soft-deleted state and can’t be restored:
  • An OAuth member is in a pending state: When MX deletes an OAuth member in a pending state, it’s immediately purged and can’t be restored.
  • All client data is purged: If you request that MX purge all data in the client, the data is immediately purged and can’t be restored.

​
Deprecated Fields and Endpoints

MX sometimes deprecates a field or an endpoint in favor of a new one. Deprecated fields and endpoints exist for the sole purpose of supporting existing integrations. If you have a new integration, avoid using deprecated items.

​
Escape Characters

Use the standard escape characters in text or string fields that use either JSON or XML formats:
  • JSON format: Use the backslash (\) to escape double quotes in any text or string fields.
  • XML format: Either use the standard XML escape characters to escape XML-reserved characters in any text or string fields, or wrap the text or string fields that might contain these characters in CDATA tags.