Plaid vs MX in 2027: Which Account Data API to Choose

Pick the category before you pick the vendor

An account data API lets your software read balances and transactions from a customer's bank account with that customer's permission, so your team does not collect bank credentials itself. Plaid and MX both sell this capability, and both bundle adjacent products such as identity checks and transaction enrichment.

For a small financial services team, the first decision is not which brand has cleaner data. It is whether you want a self-serve developer API with a published plan structure, or a platform bought through a demo and a quote. Plaid publishes its plan names, commitment terms and a free sandbox. MX's homepage offers demo requests and no list price, so its cost arrives in a proposal.

Our read: choose Plaid if you need to model cost before a sales call and you have engineers who can own sync logic and webhooks. Choose MX if enrichment and analytics are the thing you are buying and you are ready to negotiate a quote.

TL;DR: Plaid is easier to price and prototype on your own, and MX is the one to quote when the purchase is a data platform. Neither vendor publishes a dollar price you can compare line by line, so model the billing unit rather than the sticker.

Key Takeaways

• Plaid's pricing page names its plans, commitment terms and billing units, but shows no dollar figures.

• MX publishes no list price on its homepage, and a comparison site lists only a custom-priced Enterprise tier with no permanent free plan.

• Model cost in billing units: connected accounts, sync calls per month, and the allowance on any free tier.

• The sync designs differ. Plaid uses a saved cursor with /transactions/sync, while MX sends a HISTORY webhook after a completed history fetch.

• The Section 1033 rewrite is unsettled and the fee treatment for third parties is not public, so write fee-change terms into any contract.

• A workflow layer on Zapier, Make or n8n can keep run histories and retries when configured, but your team still owns idempotency, access controls and upkeep.

How we evaluated these tools

This is an informed buyer's guide built from public vendor pages, developer documentation, a government research report, a law-firm update and one review site. We did not run a trial or measure data accuracy. The weights below reflect what a small financial services team has to decide, and they total 100%. We do not give either vendor a total score, because the vendors do not publish comparable prices and a score would rest on guesses.

Regulatory and fee exposure carries the most weight because the rules on third-party access fees are being rewritten. The weights are our judgment about a small buyer's risk, not a vendor ranking.

Plaid and MX side by side: the factual layer

The table below holds only what the vendor pages, developer docs or the comparison site say. Our read follows it.

Both vendors' pages carry 2026 copyright footers (© 2026 Plaid Inc. and © 2026 MX Technologies Inc.). The pages checked for this guide show no rename, merger or discontinued product among the products named here.

Our read: the two products overlap on verification and transaction data, but they differ on how a buyer gets to a price. Plaid lets you start on a published structure, and MX asks you to start with a conversation.

Plaid in practice

Best fit: a team that wants to start in a sandbox, pay per connected account or per request, and keep the option to stop month-to-month. Plaid's Pay as You Go plan has no upfront commitment, and its free tiers are a sandbox and a capped limited production tier.

Limitations: Layer, Signal, Transfer, Consumer Report and Protect are not included on Pay as You Go, and on Growth they are priced by contact. Volume discounts exist on the Custom plan, but the page gives no figures for them.

Implementation: the first /transactions/sync call on an Item has no cursor. Save the returned next_cursor, and keep calling while has_more is true. Each SYNC_UPDATES_AVAILABLE webhook means you should call sync again from the saved cursor. If TRANSACTIONS_SYNC_MUTATION_DURING_PAGINATION appears, restart pagination from the cursor you saved before the change. The sync steps come from the Plaid transactions guide.

Our read: Plaid's model rewards teams that can keep a cursor and handle webhook retries reliably. A small team without that skill should budget for building it before choosing the simplest tier.

MX in practice

Best fit: a buyer whose purchase is the data platform itself. The MX homepage lists Account Aggregation, Data Access, Instant Account Verifications, Data Enhancement and Customer Analytics as its main product names.

Limitations: MX shows no public price. A comparison site lists one custom-priced Enterprise tier with no permanent free plan, according to Toolradar (2026). The homepage routes buyers to demo requests, so budget approval needs a proposal before the first build.

Implementation: the MX documentation we checked names user_guid and member_guid as identifiers. The HISTORY webhook fires only after a completed history fetch, and actions performed on the member through other endpoints do not trigger it, according to MX docs (2026). Its payload carries transactions_created_count and transactions_updated_count, but the payload fields listed on that page do not include transaction records themselves.

Our read: for a team that will fetch data on each notification, MX's webhook is simpler to reason about than a cursor. Any gap between events still needs a reconciliation job, and the buyer owns that job either way.

What each vendor charges to start

Plaid's pricing page names three plans and no dollar figures. Pay as You Go is month-to-month with no upfront commitment, while Growth requires a 12-month commitment, according to Plaid (2026). The page also describes three pricing models: a one-time fee per connected account, a monthly fee per connected account, and a flat fee per successful API call.

Pricing checked October 19, 2026. Plaid's dollar amounts are not published on the page we opened, and MX's are quote-based.

Plaid Limited Production: 200 API calls per product according to Plaid (2026). That is a capped allowance for limited live-data use, not a production plan.

The sizing table below converts an account count into the volume unit that most vendor billing models use. Its rows are illustrative, not customer data.

Calls per 30 days equal linked accounts times syncs per day times 30. The formula assumes one sync call per account per run and ignores pagination and manual refreshes.

Take the mid-size row. A proposed design that links 1,200 accounts and syncs each one three times a day makes 3,600 sync calls per day, or 108,000 across 30 days (1,200 × 3 × 30). Plaid's Limited Production tier allows 200 API calls per product, and a first pull that makes one call per account would need six times that allowance (1,200 ÷ 200 = 6), so the pilot would need a plan beyond the free tier before go-live. If the product you choose bills per connected account rather than per request, the 1,200 accounts drive the bill, not the 108,000 calls. Either way, the flow starts from the next_cursor value returned by /transactions/sync and calls again only when a SYNC_UPDATES_AVAILABLE webhook arrives, so the three-a-day figure is an assumption to check in the sandbox, not a vendor rate.

Building the sync yourself or configuring it

Zapier, Make and n8n are the usual alternatives when a team wants to stitch a vendor API into its own tools. Those platforms can keep run histories, retries and error branches when you configure them. The buyer still designs and owns observability, idempotency (so a retried webhook does not write the same transaction twice), escalation paths, access controls and maintenance when a vendor changes an endpoint.

Where a proposed US Tech Automations design differs is in how those pieces are configured as one flow. The prerequisites are vendor sandbox and production credentials, a webhook endpoint your team can secure, a stored cursor or member identifier for each account, and a named owner for retention rules. The review points are a person who approves any ledger write and a person who clears removed or modified transactions.

A proposed, configurable workflow for the sync path works like this. Trigger: a SYNC_UPDATES_AVAILABLE webhook from Plaid, or a HISTORY webhook from MX that carries a member_guid. Action: the flow calls the vendor's sync endpoint from the stored cursor, or fetches the changed member, then writes added, modified and removed transactions to a staging table. Output: a summary line with created and updated counts for the operations lead, plus a review queue entry for every removed or modified transaction. The flow is a design to configure and check in a sandbox first, not something running for any customer today.

The 1033 rule decides who can charge what

A Congressional Research Service report published September 30, 2025 says the CFPB finalized the Section 1033 rule in October 2024. Covered depository threshold: $850 million in assets according to CRS (2025). The original compliance start for the largest providers was April 2026, and authorized third parties may collect data for no more than 1 year, according to CRS (2025). The report also says the compliance dates have since been stayed.

The same report says the final rule bans financial institutions from charging consumers or third parties fees for data transfers. It also says JPMorgan Chase and Plaid announced a September 2025 agreement that "includes a pricing structure." The terms are not public, and the companies said the agreement would not affect Plaid's current customer agreements and pricing.

Each figure in the table comes from the Plaid pricing page, the CRS report, or the Consumer Finance Monitor article linked above.

A proposed, configurable workflow for the fee question runs on a schedule and on inbound mail. A proposed US Tech Automations flow would start from a trigger: a vendor price-change notice or contract amendment that reaches a shared inbox. The action extracts the effective date, the fee basis (per connected account, per request or per seat) and the products affected, then compares them with your current order form. The output is a ticket for the operations lead, due before the next billing cycle, that names the clause that changed. The prerequisites are a shared inbox the vendor actually uses, a named owner for contract records, and a current list of the products your team calls. Counsel reviews any change before renewal, because the flow can read a notice but cannot judge whether it is lawful.

Who this is for

Plaid fits a team that must price a pilot before a sales call and can own cursor handling and webhook retries. MX fits a team that is buying enrichment and analytics as a platform, expects a quoted contract and accepts a longer onboarding.

Red flags: you need a published dollar price before any vendor conversation; nobody on your team can own sync logic, retries and data retention; or your budget assumes today's fee levels hold through renewal while the 1033 rewrite is still open.

Common mistakes to avoid

• Comparing sticker prices. Plaid's pricing page shows no dollar figures and MX quotes, so build line items from the billing unit instead.

• Pricing by logins instead of by linked accounts. Under the monthly per-connected-account model Plaid describes, each linked account counts whether or not it is active.

• Treating the 1033 rule as settled. The 2024 rule is under reconsideration, and the fee question is open.

• Skipping sync edge cases in the sandbox. Check pagination changes (TRANSACTIONS_SYNC_MUTATION_DURING_PAGINATION) and removed transactions before go-live.

• Assuming MX's HISTORY webhook covers every change. It does not fire for actions taken through other endpoints.

Questions buyers ask

When NOT to use US Tech Automations: if you need one bank-statement pull a month, the bank's own download or a direct accounting-software connection is simpler to run than any workflow layer. If your only need is a single identity check at onboarding, the vendor's own verification product, used directly, is the shorter path. If your team already runs a mature integration platform with logging and error branches, extend that platform instead of adding another system.

Is Plaid cheaper than MX?

Public pages cannot show that, because Plaid lists plan names and billing units without dollar figures and MX quotes. Compare proposals on the same billing unit and the same volume.

Does MX have a free tier?

No permanent one. The Toolradar comparison page lists none, and MX's homepage lists no free plan. Ask MX for its entry terms in writing before you plan a pilot.

Do I need an engineer to use either API?

Yes for production. Both vendors' documentation describes sync or webhook handling that your code must receive, store and retry safely, and a no-code flow can carry that only when someone configures it.

Will the 1033 rule change what I pay?

It could. OIRA review window: up to 90 days according to Consumer Finance Monitor (2026), and the CFPB's new proposal is not public yet, so the fee treatment for third parties is unknown.

Can a file export replace an aggregator?

For low volume, yes. A monthly statement export reviewed by a person can be enough, at the cost of delay and manual steps.

Our recommendation

Choose Plaid if you need to model cost before a sales call and your engineers can own cursors and webhooks. Choose MX if enrichment and analytics are the purchase and you can negotiate a quote with a clear billing unit. Either way, write fee-change terms into the contract, because the 1033 rewrite could change who can charge what and how much.

If you want to see how the sync, fee-notice and review steps could be configured for your stack, see how US Tech Automations configures this. For other workflow comparisons, see our guide to SaaS writing tools, marketing campaign pacing checks, and membership platforms for in-house dental plans.