Open Banking APIs: A Developer’s Guide to Getting Started

By Nick Smith, Founder, Anchor Filings

Two years ago I started wiring small businesses into their bank data. I run Anchor Filings, a Madison-based business formation and compliance company, which means the customer base sits at the messiest end of the small-business spectrum: brand-new LLCs, sole props transitioning into corporations, people who applied for an EIN last Thursday. Some of them bank with Mercury. Some bank with the local credit union that still uses an ASP.NET portal that times out for maintenance at 11pm Central. Whatever stack I picked had to handle both.

Below is what I wish someone had told me before I picked an aggregator.

Know which layer of the stack you are actually integrating with

Before you write a line of code, get clear on what kind of entity is on the other end of your API call. People new to this space treat Mercury, Stripe, and a national bank as roughly the same thing. They are not. They sit on different layers, and confusing the layers is how you end up with a strategy that demos well and falls over in production.

• Chartered banks sit at the bottom. They hold the bank charter, FDIC insurance, and the master account at the Fed — a national bank or your local credit union.
• Banking-as-a-Service middleware sits between chartered banks and software companies, normalizing account opening, ledger movement, and compliance plumbing so a fintech can ship without holding a charter.
• Fintech layer is the brand the customer sees. Mercury, Brex, and their peers. They look and feel like banks but generally are not the chartered institution. They are software on top of a sponsor bank.
• Programmable financial infrastructure is a different shape entirely. Stripe is the canonical example. Historically, Stripe has not functioned as a traditional business bank the way Mercury does. It is where you build products that move money on behalf of someone else, and your customers may never know Stripe is in the loop. Stripe’s Treasury and financial-account products have started to blur that line by letting platforms ship checking-like experiences, but the core positioning still holds: Mercury is something you bank with, Stripe is something you build with.

These layers are converging — the infrastructure players now offer banking-like accounts, and the fintechs now offer APIs and venture tooling. But the distinction still matters when things go wrong. When Synapse filed for bankruptcy in April 2024, the freeze that followed that May locked customer funds at downstream fintechs for months because the BaaS layer between the fintech and the chartered bank failed. When you choose a fintech as your “bank-direct” source, you are implicitly choosing its sponsor bank and any middleware in between. Read the stack before you sign.

Choosing between bank-direct APIs, aggregators, and screen scraping

The default advice online is “pick Plaid and move on.” That works well when your customers cluster at the major national banks, which generally have mature data-sharing partnerships with the big aggregators. It gets harder the moment you onboard a customer whose bank runs an older core, or one that has not yet adopted FDX-compatible data sharing.

A production integration usually layers three things:

1. Bank-direct or fintech-direct APIs where available. Mercury, for instance, exposes a clean developer API and lets you build against it once your customer authorizes the connection. If a meaningful slice of your users live on a fintech with a real API, use it. Just remember the layer point above: you are integrating with the fintech, not the chartered bank, and your access can shift if its sponsor relationship shifts.
2. An aggregator as the wide net. Plaid, Teller, MX, and Finicity (now Mastercard Open Banking) are the names you will see most, with Akoya — bank-owned — worth knowing if your customers cluster at big banks. They are not interchangeable. Teller is generally developer-friendly on pricing with a narrower bank list. Plaid typically offers the broadest US coverage, though pricing varies substantially by product, volume, and contract. MX and Finicity tend to be stronger in mid-market and in credit unions. Pick based on where your customers actually bank.
3. A screen-scraping fallback for the long tail. Some aggregators bundle this. If yours does not, accept that 5 to 10 percent of customers will have to upload a CSV.

How to work with a bank or fintech’s integrations department

“Direct API” does not mean “self-serve sandbox key.” For most chartered banks and the larger fintechs, getting to production means working with their integrations team for weeks to months.

A realistic timeline:

• Discovery call. You explain your product, expected volume, and the data you want. Common ask from their side: a one-page architecture diagram showing where the data flows and where it sits at rest.
• Legal and security review. Expect a vendor security questionnaire (SIG Lite is common), a request for your SOC 2 report or a roadmap to one, and a redlined data sharing agreement. Banks of any meaningful size will generally insist on their own paper rather than signing yours. Fintechs are sometimes more flexible but still bound by what their sponsor bank requires.
• Sandbox access. You get test credentials weeks before production. Build the entire integration against sandbox, including the unhappy paths.
• Production review. A human reads your code or watches your demo, then issues production credentials. Some require a named technical contact and an SLA on incident response.
• Ongoing relationship. Banks rotate signing keys. Fintechs sometimes change their sponsor bank entirely, which can invalidate routing numbers overnight. You need a Slack channel, a shared alias, or at minimum a named contact.

Ask early whether their integrations team supports startups directly or only through a sponsor bank. The answer determines your procurement path.

Token refresh and the reconnect problem in open banking

Aggregator marketing talks about “connections.” What they do not put in 30-point font is that connections die. Customers reset their bank password. The bank rotates its OAuth signing key. A new MFA flow goes live and the saved auth state stops working. The access token you quietly assumed was a long-lived bearer credential silently breaks — and RFC 6749 never promised otherwise: OAuth expects access tokens to expire and hands you refresh tokens for exactly that reason.

Your churn metric is secretly your reconnect rate. If 15 percent of your active connections lapse every 90 days and you do not catch them inside that window, your user count looks flat while data freshness rots from the inside.

Two things to instrument from day one:

• Track last-successful-fetch timestamp per connection, not per user.
• Build the reconnect UI before you launch. Wire the aggregator’s hosted reauth flow into a notification email and an in-app banner. If a connection has been stale for more than seven days, prompt.

If you are building against a bank that has implemented the OpenID FAPI profile, the consent and reauth flows are standardized. Most US community banks have not yet.

Webhook idempotency when the source of truth is somebody else’s API

Whether you are consuming Plaid webhooks, Mercury account events, or Stripe payment intents, the same rules apply: at-least-once delivery, occasional gaps, and the obligation to handle both. Stripe’s engineering team has a widely-cited writeup on idempotency keys that is required reading even if you are not using Stripe. The pattern shows up everywhere because the underlying distributed-systems reality shows up everywhere.

Three patterns I now apply to every bank-data webhook handler:

1. Idempotency keys on the inbound side. The payload includes an event ID. Store it. If you see the same ID twice, no-op the second one.
2. Periodic reconciliation pulls. Run a daily job that pulls the last seven days of transactions for every active connection and reconciles against what you have stored. The half-percent the webhook stream dropped will show up here.
3. A status table separate from your data table. You want to say “this connection has been silent for four hours, alert” without entangling it with whether yesterday’s transactions look right.

Plaid’s own docs recommend an out-of-band sync job for the same reason. If the vendor whose webhooks you are consuming tells you to also poll, listen.

Open banking compliance: GLBA, SOC 2, and sponsor bank risk

Three things land on your plate if you handle US small-business bank data.

GLBA and the FTC Safeguards Rule. The updated Safeguards Rule has teeth. You need a written information security program, a named Qualified Individual, an inventory of what you collect, encryption at rest and in transit, multi-factor authentication, and a breach response plan. Write it before a partner bank asks during diligence.

State privacy laws. California’s CCPA/CPRA, plus the growing list of states that have followed (Virginia, Colorado, Connecticut, Utah, Texas), impose disclosure and deletion obligations. A clean privacy policy and a working deletion process cover the 80 percent case.

SOC 2 and sponsor bank risk. Your partner banks and your aggregator will both ask for SOC 2. Start the Type I audit before you think you need it. Beyond that, due-diligence the chartered bank sitting underneath any fintech you depend on. The Interagency Guidance on Third-Party Relationships published by the FDIC, OCC, and Federal Reserve in 2023 is now the framework regulators expect bank-fintech arrangements to follow. If your fintech partner cannot tell you who their sponsor bank is, that is information in itself.

What CFPB Section 1033 and PSD3 mean for developers building today

In the US, the CFPB’s Section 1033 rule, finalized in October 2024, was meant to establish consumer rights to financial data portability — but do not build today as if it is settled law. It was challenged in court the same day it dropped, and under new leadership the CFPB has moved to vacate it as unlawful; in October 2025 a federal court enjoined enforcement and stayed the compliance deadlines while the Bureau rewrites it. The first compliance date never took effect. Treat 1033 as paused and contested, not as a mandate you can design against. What has not stalled is the market-led standardization underneath it: the CFPB recognized the Financial Data Exchange (FDX) as an open-banking standard-setting body in early 2025, and FDX-style data sharing keeps spreading regardless of the rule’s fate.

In the EU, the picture is the reverse — the payments overhaul is nearly finished. PSD3 and the accompanying Payment Services Regulation reached provisional political agreement in late 2025 and are expected to be published in 2026, tightening consent management and strong customer authentication beyond PSD2. But note the scope: PSD3 and the PSR are mostly about payments, licensing, and account access. The EU’s real analog to Section 1033 — consumer-permissioned data portability — is the separate Financial Data Access (FiDA) regulation, which is still working through trilogue. If you plan to expand to Europe, build SCA-aware consent flows now, and watch FiDA for the data-sharing rules rather than assuming PSD3 covers them.

The throughline is messier than it looked a year ago. The regulatory road to customer-controlled, portable data has stalled in the US and is still being paved in the EU. But the market-side standardization — FDX in the States, the API obligations baked into the EU framework — keeps moving. Build for permissioned, portable, standardized access on the assumption that the standards bodies, not any single rule, will end up defining it. You will be in a better position three years out.

The thing nobody tells you

The integration that demos well and the integration that survives a real customer base are different artifacts. The demo connects one account, pulls one month of transactions, and renders a chart. The production version handles 50,000 accounts, 14 banks the demo never tested against, MFA flows that change without warning, a fintech whose sponsor bank just swapped, and a support team triaging “why don’t I see yesterday’s deposit” tickets in real time.

If you are at the start of the journey: figure out which layer you are actually consuming, pick the aggregator that covers your real customer base, start the bank-direct or fintech-direct conversations early because they take months, write the reconnect flow before you write anything else, and treat webhook events as suggestions rather than facts. Everything gets easier from there.

About the author

Nicholas Grant Smith is an attorney, computer scientist, and the creator of Anchor Filings, a Madison-based business formation and compliance company.
He earned his Bachelor of Science in Computer Science from Northern Illinois University in 2007, and his Juris Doctor from Marquette University in 2011.
At Anchor Filings, he pairs that legal foundation with his original training as a software engineer to design the systems that connect new businesses to the banking, identity, and compliance infrastructure they depend on from day one.