Skip to main content
MX Data Exchange (MDX) is a proprietary specification for exchange of data between financial institutions and MX. MDX v5 consists of five core resources: users, members, accounts, transactions, and holdings. These data objects comprise the foundation of the various MDX APIs, namely MDX Real Time and MDX On Demand.

​
Character Set

UTF-8 encoding is used for all fields in request and response bodies. Some fields have additional restrictions on valid characters.

​
Date and Time Formats

Date and time fields are supported in either Unix Epoch time (no milliseconds, stored as UTC), or in ISO 8601 with no timestamp (YYYY-MM-DD).
  • Fields ending in _at are Unix Epoch time, e.g. 1504224000.
  • Fields ending in _on are ISO 8601, e.g. 2017-09-01.
Dates provided in ISO 8601 format must be convertible to Unix epoch time; values dated earlier than 1970-01-01 are not valid.

​
Default Values

Some fields have a default value, e.g., the status field of a transaction will default to POSTED when a value is not supplied. Default values are noted where applicable in the field description. Partners should not provide placeholder values in data fields, such as passing a value of 0 in the apr field of an account, or a date such as 1970-01-01 in a datetime field.

​
Deleting Objects

​
Deletes Cascade

When deleting an object on the MX platform, all objects belonging to that object are also deleted in a cascading fashion. For example, deleting a member deletes not just the member, but all associated accounts, transactions, holdings, etc. Deleting a user also deletes all members associated with it, and so on.

​
Soft Deletes and Purges

Deleted objects are “soft-deleted” first and later purged. The timeframe for purging objects is roughly two weeks, with the exact time depending on technical factors. A soft-deleted object cannot be explicitly restored via API, but MX may restore a soft-deleted member in some cases described below. Purged objects can never be restored.

​
Some Soft-Deleted Members May Be Restored

When a member (either OAuth or Non-OAuth) is deleted, it goes into a soft-deleted state. If a new member is created for the same user, on the same institution, and utilizing the same credentials, the soft-deleted member is purged, and the new member is created. Once a member has been fully purged, it cannot be restored. To restore a soft-deleted member, a client must contact support prior to it being purged. When a PENDING OAuth member is deleted by MX, it’s immediately purged and cannot be restored. When an OAuth member in any other state is deleted, it will be soft-deleted and can be restored.

​
User Deletes are Permanent

Deleting a user is permanent. Deleted users can never be restored.

​
Escaped Characters

If using JSON format, please use the standard JSON escapement for double quotes (”) if included in any text/string fields. If using XML format, please ensure it is valid XML by using standard XML escapement for all XML-reserved characters, or by wrapping these text/string fields that might contain these characters in CDATA tags.

​
Numbers 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. Scale refers to the number of digits to the right of the decimal. For example, 538.46’s precision,scale is 5,2.

​
Core Resources

User: Represents the person using the MX Platform whether through the mobile application, web application, or proxy via 3rd party application. Member: Represents a user’s relationship with a given financial institution. A single user can have relationships with many financial institutions. For example, the user Jane Doe can have a member relationship with XYZ Bank, and a different member relationship with ABC Credit Union. A member belongs to a user. Account: Represents a financial account held by a member of a financial institution. It’s common for a member to have multiple accounts at a financial institution. For example, Jane Doe has a member relationship with XYZ Bank, and has both a checking and savings account. An account belongs to a member. Account Number: Represents the account numbers of a specific account at a financial institution, which can include account number, routing and/or transit number. An account number belongs to an account and each account can only have one. Transaction: Represents an instance of buying or selling something with the accompanying metadata. A transaction belongs to an account. For a more detailed description of the hierarchy of resources in the MX system, see MX Data Architecture.