Skip to main content

Sending Held Data

This guide explains how to send data held by your financial institution to MX for processing, enhancement, and delivery to end users.

Financial institutions differ in their system configurations and available resources. We provide three methods for sending your data:

Each method has strengths and weaknesses depending on your systems and use case. They can be combined to achieve an optimal solution.

Held Data vs. Aggregated Data​​

We handle both data held by your financial institution and externally aggregated data from other institutions. MDX Real Time, Batch, and MDX On Demand v5 manage held data. The Platform API handles aggregated data and the aggregation process.

For example, an end user may have checking and savings accounts with you (held data sent using the methods outlined here) and a credit card from another institution (aggregated data handled via the Platform API).

Determining the Best Method to Use​​

Keep the following questions in mind when determining which integration method is appropriate for you.

  • What do your systems look like? Does your back end or banking core produce data continuously or does it produce data in batches?
  • Is your data housed on-premises or with a third party?
  • If with a third party, can your data be accessed continually, or do you have access to batches of summary data?
  • Can you perform reconciliation of things like pending versus posted transactions?
  • What kinds of costs can you handle? Frequent requests to core banking services managed by a third party may be costly even if it provides the best experience for end users.

MDX Real Time​​

MDX Real Time is the best solution for clients with real-time data available in their systems.

Real Time is a RESTful API that lets you push user, member, account, transaction, and holding data directly to MX as soon as changes occur.

Real Time is optimal for event-driven backends where transaction and account updates post throughout the day, not just in nightly batches. You'll need to push data for all accounts, including those held by third parties.

You must handle data reconciliation. For example, if you send a PENDING transaction, you must either delete it or update it to POSTED. If a POSTED transaction can change or be deleted, these changes must also be tracked and sent to MX.

Possible Advantages:

  • Event-driven. Push data whenever it changes.
  • End users see updated data as soon as it exists rather than waiting for daily change or for back-end aggregation to occur.

Possible Concerns:

  • You must handle data reconciliation.
  • Scale: Your systems must be able to handle the large number of requests necessary to keep everything up to date.

Batch API​​

With Batch, you push data to MX using large CSV-formatted files (via SFTP) on a periodic basis rather than making numerous requests for individual changes. The common pattern is to create a batch file nightly and send it for processing, which takes several minutes to hours depending on size. Because of processing delays, Batch is not ideal for intra-day transactions.

Batch is optimal if account and transaction updates process on your banking core once daily and you have access to summary data for all accounts. If account data is held by a third party and daily summaries aren't available, Batch can't be used for those accounts.

Batch can also be used for other scenarios: pre-loading historical data before go-live, deleting inactive users, and updating incorrectly sent fields.

Possible Advantages:

  • A large amount of data representing millions of changes can be processed in an efficient manner.
  • Batch may closely match your existing backend or core banking system.

Possible Concerns:

  • Not event-driven.
  • Data isn't available to your end users in real time.
  • It takes time for us to process batch files; you don't get immediate feedback on changes like you do with real time.
  • You must handle data reconciliation, as with Real Time.
  • Intra-day transactions are not well supported due to the delayed nature of batch processing.

MDX On Demand v5​​

MDX On Demand v5 is essentially the reverse of Real Time. You implement a RESTful API on your systems according to our specification, and we make requests to that API as necessary. We handle data reconciliation.

To use On Demand, your users and members must already exist on our platform, meaning you must have created them using Batch or Real Time.

The On Demand model simplifies handling account data housed by third parties, such as credit cards with externally hosted transactions. MX requests data for each account individually, allowing your system to gather data from multiple sources.

On Demand also supports user-managed members, where users create a second connection to their home institution (most often to bring in a spouse's accounts). We send the login and password provided by the user to retrieve data from you. Multifactor authentication (MFA) is supported and encouraged for user-managed connections.

On Demand requires that you scale your systems to handle numerous requests. Expect at least one On Demand session per user per day, with each session requiring multiple requests to various endpoints.

Possible Advantages:

  • There's no need to reconcile data on your end.
  • It's easier for you to retrieve data from third parties including data that can only be accessed one user at a time.
  • Good handling of user-managed members.

Possible Concerns:

  • It's resource intensive.
  • Scale: Your systems must be able to handle the large number of requests necessary to keep everything up to date.

Hybrid Approaches​​

Because Real Time, Batch, and On Demand v5 share the same resource structure and similar data models, you can combine multiple methods to achieve an optimal solution.

Common hybrid approaches include:

  • Send a one-time initial data load using Batch, then use Real Time for ongoing updates
  • Send daily batch files for most data, but handle intra-day events (transfers, bill payments) via Real Time
  • Use Batch to push internally-held account data and On Demand to pull third-party account data, or vice versa

Hybrid approaches require consistent IDs for users, accounts, and other resources across all methods.

MX-Defined GUIDs vs IDs Defined by You​​

All resources managed via Real Time, Batch, and/or On Demand v5 must be assigned unique IDs by you. These IDs are how you create, update, and track accounts, transactions, and other resources.

We also assign a unique GUID to every resource you create. This separate GUID is required for externally aggregated data and is returned in Real Time responses and Batch response files.

The Platform API requires MX-defined GUIDs for accessing and managing resources, including those created via Real Time. If your integration uses the Platform API, you must track MX-defined GUIDs and map them to the unique IDs you assign.

MX-assigned GUIDs are UUID values with a three-letter prefix identifying the object type. For example, user GUIDs start with USR-. These prefixes are reserved for MX-generated GUIDs and must not be used for your assigned IDs. Examples include:

  • USR-
  • MBR-
  • ACT-
  • TRN-
  • HLD-
On this page