How to Get Programmatic Access to Your Bank Account Data

You can spin up infrastructure on three continents with a single command. You can query any public API on earth. You can automate your entire development workflow down to the commit message.

But try to read your own bank transactions programmatically and you’ll hit a wall fast.

This question comes up on Hacker News every year. Someone asks how to get API access to their own bank account. The answers are a mix of “use Plaid,” “screen scraping,” and “just download CSVs.” Nobody has a satisfying answer because the landscape is fragmented and most of the tools aren’t built for you.

I’ve spent a lot of time on this problem. Here’s what I’ve learned.

Why You’d Want This

If you’re reading this, you probably already have a project in mind. But in case you need ammunition for the “why bother” conversation with yourself at 11pm:

Tax prep. You have business expenses spread across three bank accounts and need to categorize a year of transactions for your accountant. You’re not doing that by hand in a spreadsheet.
Spending dashboards. Your bank’s built-in charts are useless. You want to query your data your way.
Alerts and automation. Flag transactions over a threshold, track subscriptions, catch duplicate charges.
Data export. Get your transactions into a database, a spreadsheet, or a tool of your choice.

Yes, budgeting apps exist. YNAB, Monarch, Copilot. They’re fine. But if you’re a developer, you don’t want someone else’s dashboard. You want the data. You want to write your own queries, build your own workflows, pipe it into your own tools. The value isn’t the API call. It’s what you do with structured access to your own financial data.

The Problem

Banks don’t offer personal-use APIs.

There is no curl https://mybank.com/api/transactions. There is no developer portal where you sign up and get an API key for your checking account. Your bank has APIs internally, and they share them with partners, but they don’t share them with you.

So you’re stuck with the manual options:

CSV exports. Log in, navigate three menus deep, download a file that’s formatted differently from every other bank. Repeat monthly. Repeat per account.
OFX/QFX downloads. Same drill, different file format. Some banks support it, some don’t, and the format varies.
Screen scraping. Brittle, breaks when the bank updates their UI, and likely violates your bank’s terms of service.

None of these are programmatic access. They’re workarounds.

Your Actual Options

Here’s every real option I’ve found, with honest assessments of each.

Financial Data Aggregators (Plaid, Teller, MX, Finicity)

First, the thing nobody tells you up front: these are all B2B products. Every one of them is designed for a company building a product for end users, not for a developer who wants to query their own transactions. They work with businesses offering bank-data-enabled services. Direct personal access to your own data is not their use case.

With that context:

Plaid has the broadest coverage (10,000+ institutions) and the best docs. But pricing is opaque and designed for businesses. Production access requires an application review, a business entity, and compliance paperwork. It’s also a sync API. You call /transactions/sync and get a data dump. You store it. You build your own query layer. You cannot ask Plaid “give me my transactions from last Tuesday.” You have to sync everything and query it yourself.

Teller takes a different approach with direct bank connections instead of screen scraping. Developer-friendly API. But institution coverage is smaller, and you have to “contact sales” to get started. There’s no self-serve sign-up.

MX and Finicity (Mastercard) are enterprise-grade. If you’re not a company with a sales contact, you’re not getting in.

Open Banking / FDX / Bank APIs

Europe is ahead here. PSD2 mandates that banks provide APIs for authorized third parties. In the US, we’re catching up. Slowly.

The Financial Data Exchange (FDX) is the emerging standard. 114 million consumer accounts are already connected through FDX-aligned APIs. Some banks have developer portals:

Wells Fargo has open banking APIs at developer.wellsfargo.com with a sandbox environment.
Chase has an FDX-aligned API, but access is gated through partnerships.
Akoya acts as an FDX gateway to multiple banks, but it’s B2B.

In practice, using any of these requires registering as a third-party organization, getting approved by each bank individually, handling certificates and compliance. It’s not something you set up on a weekend.

The CFPB’s Section 1033 rule was supposed to change this. Banks would be required to provide consumer data access starting April 2026. But the rule is in limbo. New CFPB leadership called it “unlawful” and restarted the rulemaking process. The timeline is uncertain.

The DIY Route

Download CSVs. Parse OFX files. Get it all into a database or spreadsheet. Do this monthly for each account at each bank.

It works. People do this. But it’s tedious, it doesn’t scale, and it’s exactly the kind of manual process that makes a developer want to automate it in the first place.

What I Actually Did

I went the Plaid route. Here’s what that looked like.

First, you sign up for a Plaid account. Then you realize you need production access. To get production access, you need to provide a business entity. So now you need an LLC or equivalent. Then you need an LEI code (Legal Entity Identifier). That’s a registration process with its own timeline and fees. Then you submit your application, describe your use case, and wait for approval.

I’m not complaining about this. Plaid and the banks need to know who’s accessing financial data. The trust requirements are real. But if you started this project thinking “I’ll just grab my transactions this weekend,” you’re now weeks deep in paperwork before you’ve written a single line of code.

Once you’re approved and you connect an account, the data is good. You get JSON transaction objects with merchant names, amounts, dates, and categories. It’s structured. It’s reliable. It’s what you wanted.

But you’re not done. Plaid is a sync API, so you still need to:

Build a database to store the synced data
Set up a sync schedule and handle pagination
Manage access tokens securely, including rotation and refresh when connections break
Build error handling and retry logic for when syncs fail

You wanted to query your transactions. What you got was a data pipeline project.

I did all of this because I wanted to programmatically process my business transactions for the 2025 tax year. Categorize expenses, match them against receipts, generate reports. The kind of thing that should be a script, not a month of manual work in a spreadsheet.

It worked. But the amount of infrastructure I had to build just to get to the point where I could write that script felt wrong.

This is what led me to build Shim.

The Real Friction Isn’t Technical

The technology to access bank data exists. Plaid works. FDX works. The APIs are real.

The friction is structural:

Institutional. Banks don’t want to make it easy for you to move your data around. Your data staying inside their walls is a competitive advantage.
Regulatory. Aggregators like Plaid exist because direct access doesn’t. They’re the middlemen that banks are willing to work with.
Economic. Plaid charges per connection because they’re the toll booth between you and your own data.

Open banking regulation may change this eventually, but in the US, the regulatory path has stalled. Don’t hold your breath.

Where This Leaves You

This shouldn’t be this hard. You should be able to access your own financial data as easily as you access your GitHub repos.

The tools exist, but none of them are built for a developer who just wants their own data. The aggregators want you to be a business. The banks want you to use their app. The regulators are stuck.

After building all that infrastructure for myself, I decided to make it available to others. It’s called Shim. You sign up, connect your bank accounts, get an API key, and start querying your banking data. No business entity. No sync infrastructure. No “contact sales.”

Remember that curl from earlier that doesn’t exist?

curl "https://api.shim.finance/v1/transactions?from=2025-01-01&to=2025-12-31" \
  -H "Authorization: Bearer your-api-key"

If you’ve solved this problem differently, I’d genuinely love to hear how.

Eric Webb is an independent developer building tools for programmable personal finance.