A fintech client described its banking setup to me in a single breath — “we use one bank for everything” — and then, as we worked through the documents, it turned out not to be one bank and not for everything. One institution was originating the ACH transactions that moved money in and out. A different institution was actually holding the customer balances. The terms of service had been drafted as though a single partner did both, which meant the custody analysis, the FDIC analysis, and the payment-authorization language were all pointed at the wrong entity. None of it was fatal, but all of it was wrong, and the fix started with a step the founder had skipped: mapping which bank did what before drafting a word.
Bank and payment partnerships are where fintech terms most often drift away from reality, because the contracts get drafted against an imagined “the bank” rather than the specific institutions playing specific roles. If you are building consumer or business fintech rails, the discipline that saves you is to map the roles first and draft to the actual structure — because a surprising amount of your legal exposure is determined by which bank holds the money, which bank moves it, and which consumer-protection regime that triggers.
Map the bank roles before you draft
A bank can do two different things in a fintech stack, and they are not the same function. A bank can move money — acting as the originating depository financial institution, the ODFI, for ACH transactions — and a bank can hold money, acting as the custodial or FBO institution where customer balances sit. Sometimes one bank does both. Often they are different institutions, and increasingly the “payments” partner and the “deposits” partner are deliberately separate. The drafting has to follow the real allocation. If a partner you have been treating as “payments only” is in fact holding customer funds, then the entire custody and FDIC pass-through analysis has to be re-run against that bank’s agreements, because the institution holding the money is the one whose records and failure drive deposit-insurance coverage. Get the map wrong and every downstream clause inherits the error.
An ACH clause is not an ACH authorization
Here is a specific and common defect. Terms that say, in general language, “you authorize us to transfer funds to and from your account” are not a valid ACH debit authorization. NACHA’s rules require an express authorization to originate ACH entries, and a real authorization has structure: it must cover debit entries and credit entries, one-time and recurring, with the customer’s clear consent; it must include revocation mechanics; and for recurring entries it must specify amount and frequency, or a method for determining them. The generic “we may move your money” sentence satisfies none of this. A platform relying on it is originating debits on an authorization that would not survive a dispute or a NACHA audit, and the returns and re-presentment mechanics that the rules also require are usually missing entirely. The authorization is not boilerplate; it is a discrete consent that has to be drafted to the network’s specifications.
Reg E is about purpose, not wealth
The most expensive misconception I encounter in this area is the belief that sophisticated or wealthy users are outside consumer payment law. They are not. Regulation E — the implementing regulation for the Electronic Fund Transfer Act, at 12 C.F.R. Part 1005 — turns on the purpose of the account, not the net worth of the holder. What makes an account a consumer account is that it is established primarily for personal, family, or household purposes. A high-net-worth individual moving money for personal purposes is fully inside Reg E; their sophistication and their balance sheet are irrelevant to the analysis. “High net worth” does not buy anyone out of Reg E, and a platform that scopes its consumer-law exposure by user wealth has scoped it by the wrong variable.
The way to actually stay outside consumer payment law, where that is the goal, is to scope the rails to business and institutional users and to say so expressly — that the services are not offered for personal, family, or household purposes. That statement, backed by a real gate, is what keeps the product on the institutional side of the line. The wealth of the users is not a gate; the purpose of the accounts is.
Define the institutional gate the right way
If the strategy is to be institutional-only, the gate has to be built out of the right elements. The defensible version requires that the user be an entity rather than a natural person, that the account be used for a business or commercial purpose, that the user clear KYC, and that the platform retain discretionary approval — an on/off switch it actually controls. What you should not do is borrow thresholds from other regimes to define a general payments gate. “Accredited investor” and “eligible contract participant” are product-specific concepts — the first from securities law, the second from the derivatives and leverage world — and using them as the general gate for a payments product both misstates their function and leaves gaps where a user clears the securities threshold but is still, for payments purposes, a consumer. Define the gate in payments terms: entity, business purpose, KYC, platform approval.
Build the sponsor-bank flow-downs in, and route them for approval
Sponsor-bank agreements come with flow-down obligations, and they are not suggestions. They commonly require prescribed disclosures — that the company is not a bank and that banking services are provided by the named bank, Member FDIC; that accounts are opened “through” the company rather than “by” it; the exact FDIC phrasing, with no bare “Member FDIC” floating free of the bank’s name. They commonly require the bank’s prior written approval of any reference to the bank or to the custody or movement of fiat, approval of the company’s Reg E policies, and a USA PATRIOT Act customer-identification notice in onboarding. The drafting task is to build these into the terms and the onboarding flow and to route the specific language to the bank for approval rather than guessing at it — because a flow-down obligation you satisfied with your own wording, unapproved, is a breach waiting to be cited.
A small but recurring detail: use the bank’s official registered name in the “Member FDIC” disclosure, verified against the FDIC’s BankFind directory, because partner documents are frequently internally inconsistent about the bank’s exact legal name, and the disclosure has to match the entity that actually carries the insurance. The same entity-name precision that governs corporate housekeeping governs here, for the same reason — the protections attach to a specifically named institution.
Vendors, cards, amendments, and privacy
A few more allocations round out the picture. On vendor naming, the sensible strategy is asymmetric: keep service providers generic in the terms, where flexibility matters because vendors change, but name the data-aggregation and payment partners in the privacy policy, where data-recipient transparency is the governing value. On card programs, remember that a card is a consumer EFTA product even when your core rails are institutional — the issuer-and-program-manager structure brings Regulation E error-resolution through the issuer’s cardholder agreement, so keep the scope straight, let the required cardholder disclosures live in the onboarding flow, and have the user agreement incorporate them by reference rather than trying to reproduce or hyperlink them in the contract body.
On amendments, the market norm maximizes flexibility — changes effective on posting, continued use as acceptance, advance notice only where law requires it, prospective-only effect, and account closure as the customer’s sole remedy. But carve the arbitration agreement out of that machinery: changes to the arbitration or class-waiver terms should get real notice, a renewed short window to reject, and no retroactive application to pending disputes, because that is what keeps the arbitration clause enforceable when it matters. And on privacy, recognize that sharing customer data with bank, payment, and account-verification or aggregation partners implicates the Gramm-Leach-Bliley Act’s Title V — so disclose who receives data, what data, and why, and note that the customer may receive a separate privacy notice from the bank partner. For a fintech or crypto platform sitting on top of bank rails, the terms are a map of other people’s obligations as much as your own, and the document only works if it matches the partnerships behind it.
If you are standing up a fintech or crypto product on bank and payment partnerships and want the role-mapping, Reg E scope, and sponsor-bank flow-downs reviewed before launch, feel free to reach out to my firm manager, Magda, at Magda@montague.law, or fill out our contact form. Mention you read this post.
— John
