Choose which method is best to send your held data to MX.
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.
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:
Criteria
MDX On Demand
MDX Real Time
Batch
Data Flow
MX pulls data from you
You push data to MX
You push data to MX via SFTP
Data Update Frequency
Session based, on demand
Real time, driven by events as they happen
Periodic via batch files, typically nightly
Best For
External account data and user-triggered requests
Frequent real-time event updates
Daily bulk data processing and initial data loads
Reconciliation
Done by MX
Done by you
Done by you
System Capabilities
Must be able to handle frequent on-demand requests
Must be able to handle high-volume, real-time API requests
Must be able to handle large periodic file transfers via SFTP
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 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 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.
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-.