Most fintechs can tell you their product is “bank-provided.” Fewer can tell you which regulations apply to each feature, who owns compliance for each one, and where the control actually lives.
That gap tends to surface at the worst time: during sponsor bank due diligence, in the first oversight review after launch, or when the bank’s examiners start asking the bank about you.
The fix is a document that isn’t glamorous and doesn’t take long to start: a regulatory applicability matrix.
What it is, and what it isn’t
A regulatory applicability matrix is a table. Rows are laws and regulations. Columns are your products and features. Each cell answers three questions: Does this apply? Who’s responsible, the bank or you? What control shows we meet it?
It is not a policy library, and it isn’t a list of every regulation that touches financial services. A generic list tells your sponsor bank nothing. A matrix tied to your actual product flows tells them you understand your own program.
Why the bank cares
Your sponsor bank owns the regulatory risk of your program. The agencies’ proposed third-party risk management guidance, published in September, keeps that principle: a bank’s use of third parties “does not diminish its responsibility to meet these requirements to the same extent as if the activities were performed by the banking organization internally.”
So when you send a product change, the bank’s compliance team is asking one question: what new obligations does this create for us? If you can answer that before they ask, you move faster and you earn trust. If you can’t, every change becomes a negotiation.
Why you should care, even with a bank in front of you
A lot of fintech teams assume the bank’s charter absorbs the regulatory exposure. It doesn’t, at least not all of it.
Take Regulation E. It defines a “financial institution” as a bank or credit union, or “any other person that directly or indirectly holds an account belonging to a consumer, or that issues an access device and agrees with a consumer to provide electronic fund transfer services” (12 CFR 1005.2(i)). Depending on how your program is structured, that can reach you directly, not just through your contract.
UDAAP works the same way. The Consumer Financial Protection Act covers “any person that engages in offering or providing a consumer financial product or service” and defines a service provider to include a person who “participates in designing, operating, or maintaining” one (12 U.S.C. 5481). The prohibition on unfair, deceptive, or abusive acts applies to both (12 U.S.C. 5536). Your marketing copy, your app screens, and your fee disclosures are yours, whatever the program agreement says.
The matrix is where you work that out deliberately instead of finding out during a complaint review.
How to build one that’s actually useful
Start from your product flows, not from a regulation list. Walk the customer’s path from start to finish: marketing, application, identity verification, account opening, funding, transactions, disputes, servicing, collections if you lend, and closure. Each step triggers specific rules. Account opening pulls in customer identification and BSA/AML. Funding and card transactions pull in Regulation E. Every customer-facing word pulls in UDAAP.
Go to the section level where it matters. “Reg E applies” isn’t enough. Break out the pieces that create operational obligations. Error resolution is the classic one. Under 12 CFR 1005.11, the institution generally has 10 business days to investigate a reported error, or up to 45 days if it provisionally credits the account within those 10 business days. If your support team takes the dispute and the bank owns the investigation, the matrix should show the handoff and who watches the clock.
Assign one owner per obligation. “Shared” is not an owner. If both parties have a role, say which one: the fintech performs, the bank approves and tests. Ambiguity here is how deadlines get missed.
Tie every “applies” to evidence. Name the policy, procedure, system, or report that shows compliance. If you can’t name one, you’ve found a gap, which is the point of the exercise.
Connect it to your BSA/AML risk assessment. The FFIEC BSA/AML Examination Manual says a risk assessment “should address the varying degrees of risk associated with its products, services, customers, and geographic locations.” Your matrix already maps products and features. Use the same structure, so your risk assessment and your applicability analysis describe the same program.
Where these usually break
In my experience, three patterns show up again and again.
The matrix describes the launch product, not the current one. A new funding method, a new fee, or a rewards feature ships, and nobody updates the map. Make a matrix review part of your change management process, not an annual task.
State law is a single row that says “varies.” Money transmission, lending licenses, and state privacy and disclosure laws often depend on your model and where your customers live. You don’t need a 50-state survey on day one, but you do need to know which questions you’ve answered and which ones you’re relying on the bank’s charter for.
Nobody on the bank side has seen it. A matrix you keep to yourself only helps you. Share it with your sponsor bank, ask them to mark where they disagree on ownership, and settle the disagreements in writing. That conversation is worth more than the document.
Three things to do this quarter
- Draft the first version in a spreadsheet using your top two products. Don’t try to cover everything. Get the structure right on what drives most of your volume.
- Mark every cell where ownership is unclear, and take that list to your sponsor bank. It’s a better agenda than most oversight meetings have.
- Add a matrix check to your product change process. Any change that touches a customer-facing flow updates the matrix before launch, not after.
A good matrix won’t make your program compliant on its own. It will show you, and your bank, exactly where you stand.
When I help a fintech get bank-ready, this is usually the first document we build. Policies, procedures, and testing plans are all easier to write once everyone agrees on which rules apply and who owns them. For a fintech that depends on a bank partner, everything else builds on that.
Sources
- Proposed Third-Party Risk Management Guidance, 91 FR 58536 (Sept. 15, 2026)
- CFPB: 12 CFR 1005.2, Definitions (Regulation E)
- CFPB: 12 CFR 1005.11, Procedures for resolving errors (Regulation E)
- 12 U.S.C. 5481, Definitions (Consumer Financial Protection Act)
- 12 U.S.C. 5536, Prohibited acts
- FFIEC BSA/AML Examination Manual: BSA/AML Risk Assessment
