Skip to main content

Sending Held Data

The following guide explains how we manage data that is held by your financial institution and the possible methods you can use to send that data directly to us.

Managing financial data held by your own institution is critical to getting the most out of our products. However, financial institutions differ in how their own systems are set up and the resources available to them. We provide three different ways of getting your data over to us so it can be processed, enhanced, and delivered to end users:

Each has particular strengths and weaknesses depending on your systems and use case. They can also be combined with one another easily to achieve an ideal solution for you.

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 are used for managing held data. Aggregated data and the aggregation process are handled with the Platform API.

For example, one of your end users may have a checking and savings account with you, and data for these accounts should be passed to us using the methods outlined here. But they might also choose to connect a credit card held by another institution. This credit card data would be aggregated by us, and that process and the resulting data must be 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 that have real-time data available in their system.

Real Time is a RESTful API that allows you to push your user, member, account, transaction, and holding data directly to us as soon as a change has taken place on your systems.

Real Time is the optimal, event-driven solution if your backend systems are also real time, where transaction and account updates are posted throughout the day, not just in nightly batches. You'll need to be able to push us data for all accounts, including those where data is held by a third party.

You also must handle data reconciliation. For example, if a PENDING transaction is sent to us, you will have to either delete it or update it to a POSTED transaction. You must track this and make the necessary Real Time requests. If a POSTED transaction can ever 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 the Batch system, you are pushing data to us. However, unlike Real Time, you're sending us large, CSV-formatted batch files (via SFTP) on a periodic basis rather than making a large number of requests for individual changes. The common pattern is for you to create a batch file every night and send it to us for processing over several minutes or hours depending on the size. Because of possible processing delays, Batch is not the ideal solution to support intra-day transactions.

Batch is the optimal solution if account and transaction updates are only processed on your banking core once a day — so long as you have access to summary data for all accounts. If any account data is held by a third party and a daily summary of that data (including transactions) is not available, then Batch can't be used for those accounts.

Batch can also be used for other scenarios and use-cases such as: pre-loading historical data prior to go-live, deleting inactive users, updating fields that were sent incorrectly, etc.

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 in many ways the reverse of Real Time. You implement a RESTful API on your systems according to a specification that we provide. We then make requests to that API as necessary. We handle data reconciliation on our end.

To use On Demand, your user and member must already exist on our platform. Which means you had to have already created them either using Batch or Real Time. The On Demand model may make it easier to handle account data that is housed by third parties, such as a credit card whose transactions are hosted externally. MX will request data for each account individually, so your system could go to multiple sources to gather that data.

On Demand also allows us to make requests for user-managed members, where the user has created a second connection to their home institution. This is most often used to bring in a separate set of accounts, such as those for a spouse. We will send the login and password provided by the user to retrieve data from you. Multifactor Authentication is supported and encouraged for user-managed connections.

However, On Demand requires that you scale your systems to handle the large number of requests that we will be making to your systems. You should expect at least one On Demand session per user per day, where each session requires 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 extremely similar data models, it's possible to combine multiple methods to achieve an optimal solution.

One of the most common approaches is that you may choose to send us a one-time initial load of data using our Batch API and then continue to use MDX Real Time to update new users, accounts, and transactions after that.

Another example is that you may choose to send daily batch files for most data, but handle some intra-day events (like transfers or bill payments) via Real Time. This allows you to deliver the data that's needed efficiently but still provide useful real-time information to end users.

Yet another example is using Batch to push data to us for the internally-held accounts, but using On Demand to have us pull in accounts held by a third party, or vice versa.

Hybrid approaches require that you use consistent ids for the users, accounts, etc. across all methods being employed.

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 particular accounts, transactions, etc. Because of the way most banking systems are set up, this is the best approach for handling held data.

However, we also assign a unique guid to every resource you create. Because we deal with externally aggregated data and make that data available to you and your end users, this separate guid is also required, and is returned to you in Real Time responses and Batch response files. For that reason, the Platform API requires the use of MX-defined guids for accessing and managing resources, including the resources created by you via APIs like Real Time. If your integration uses the Platform API, you'll need to keep track of MX-defined guids and correctly map them to the unique id you assign when passing your held data to us.

MX-assigned guids are UUID values with a three-letter prefix to identify the type of object they belong to. For example, a user guid will start with “USR-”. This format allows you to easily identify MX-generated GUIDs. These prefixes are also reserved by our system for our internal GUIDs and must not be used for your own assigned ids. Examples of the guids include but are not limited to:

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