This guide explains the different methods you can use to send your held data to MX.
Held data is the account and transaction information that financial institutions manage for their users. For example, when a user logs into their account with your institution and reviews their latest transaction history, they’re accessing your held data.
Held data is handled differently than aggregated data, which is data that your users connect to your institution from a third party, such as an external account for a credit card or auto loan.
Once we receive your held data, we can process, cleanse, and deliver an enhanced version of account and transaction information to your users.
Method Overview
We provide three methods for sending held data: MDX On Demand, MDX Real Time, and Batch. Each method serves different system configurations and use cases, and you can use more than one method in a hybrid approach. Refer to the following table for an overview of what each method offers:
MDX On Demand
MDX On Demand is a pull-based method where MX requests data from your system.
This method is optimal for systems that are scaled to handle frequent requests triggered by user login sessions. It’s also the best method for handling aggregated data, such as credit card data hosted externally.
MX manages data reconciliation in this method. This means that any data updates (such as a change from a pending to a posted state) happen without you having to track anything.
To learn more about how this method works, refer to MDX On Demand Workflow.
MDX Real Time
MDX Real Time pushes user, member, account, transaction, and holding data to MX as changes occur, enabling your users to see events like a transfer or bill payment as your system provides the data.
This method is optimal for event-driven backends where account, balance, and transaction updates occur throughout the day.
You’re responsible for reconciling changes, such as when a transaction changes from a pending to a posted state.
To learn more about how this method works, refer to MDX Real Time Workflow.
Batch
Batch pushes large, CSV-formatted files to MX via SFTP on a periodic basis (typically nightly). It’s the most efficient way to get bulk data onto the MX system.
This method is optimal for banking cores that process data once daily or for bulk initial data loads and ongoing bulk data management. While it’s efficient for processing millions of records, it can involve processing delays.
You’re responsible for reconciling changes, such as when a transaction changes from a pending to a posted state.
Learn more about Batch in the Batch API Overview.
Hybrid Approaches
You can combine any or all of these methods to optimize performance. Common hybrid approaches include:
- Performing an initial data load via Batch, then maintaining updates via Real Time.
- Using Batch for daily core data while handling intra-day events (such as transfers and payments) via Real Time.
- Using Batch for held data and On Demand for aggregated data.
- Using On Demand for core data and Real Time for aggregated data.
Assigning Resource IDs
No matter which method you choose, you must assign a unique and persistent ID to each resource so it can be created, updated, and tracked. To learn the recommended method of assigning resource IDs, refer to our Best Practices guide.
MX also assigns a unique GUID to every resource you create. This is a separate value consisting of a three-letter prefix that identifies the object type, and is required for externally-aggregated data that is returned in Real Time responses and Batch response files. You must map your assigned IDs to these MX-defined GUIDs.
Don’t use the following three-letter prefixes, they’re reserved for MX-generated GUIDs: USR-, MBR-, ACT-, TRN-, HLD-.