A sponsor bank can let a fintech partner perform compliance work, but it can never hand off the accountability for it. Oversight is the bank's standing proof to its board and its examiners that it knows what every partner under its charter is doing and can show the controls work. When a BaaS partnership fails an exam, regulators increasingly name the bank.
Banking-as-a-Service (BaaS) lets a fintech offer banking products (accounts, cards, payments) on the rails of a chartered bank. The fintech owns the customer experience; the bank owns the charter. That arrangement creates enormous reach, and one hard rule that trips up newcomers on both sides: regulatory responsibility does not travel with the work. It stays with the bank.
This guide is written for the person who has to live with that rule: the compliance officer at a sponsor bank, or the compliance lead at a fintech trying to prove up to one. It covers what oversight actually means, who owns what, where partnerships break, what examiners look for, and how to build a program that produces evidence instead of binders.
What "sponsor-bank oversight" actually means
Oversight is the ongoing process by which a chartered bank supervises the fintechs operating under its charter. It runs as a repeating cycle: set expectations, monitor activity, test the controls, document the evidence, and remediate what you find, partner by partner, quarter after quarter.
The regulatory backbone is familiar: the same BSA/AML program pillars a bank applies to itself extend across the partnership. The Bank Secrecy Act and its implementing rules, the FFIEC examination manual, and interagency third-party risk-management guidance all point to the same expectation. The bank must understand, monitor, and control the risk each partner introduces, with a human accountable for it.
Who owns what: the bank vs. the fintech
The cleanest way to avoid a finding is to be explicit about the line between doing the work and answering for it. A partner can take on the work. The bank still owns the answer.
| Function | Who can perform it | Who answers to the examiner |
|---|---|---|
| Customer due diligence (CDD/KYC) | Fintech, day to day | The bank |
| Transaction monitoring | Fintech or shared | The bank |
| SAR decisioning & filing | Bank (often with fintech inputs) | The bank |
| Sanctions / OFAC screening | Fintech or shared | The bank |
| Partner risk assessment | The bank | The bank |
| Independent testing of the program | Independent party | The bank |
Notice the right-hand column never changes. That is why oversight has to be real: the bank carries the regulatory weight for activity it does not directly perform, so it needs a way to see that activity and prove it was controlled.
The core oversight obligations
Oversight is the BSA/AML pillars applied across an organizational boundary. Each pillar generates a specific obligation at the partner level:
| Pillar | Partner-level obligation |
|---|---|
| Internal controls | A written, board-approved oversight framework that defines roles, thresholds, and escalation across the bank-fintech line. |
| Designated BSA officer | A named, accountable person at the bank who owns each partner relationship. A shared inbox does not count. |
| Training | Role-specific training that reaches the fintech's operational staff, not just the bank's. |
| Independent testing | Periodic independent review of each partner's BSA/AML controls, scoped to the partner's actual risk. |
| CDD / beneficial ownership | Assurance that the partner's onboarding meets the bank's standard, with the bank able to inspect it. |
Where partnerships actually fail
The failure modes are consistent. From public consent orders and enforcement actions against sponsor banks, the recurring patterns are:
- Oversight on paper, not in evidence. A policy says monitoring happens; nothing proves it did. Examiners treat "we have a policy" and "we can show it worked" as two different claims.
- Stale risk assessments. The partner launched a new product, entered a new customer segment, or 10x'd volume, while the risk assessment still describes last year's business.
- Mis-tuned transaction monitoring. Rules inherited from the bank's own book don't fit the partner's customer base, producing either alert floods or silence.
- Slow SAR escalation across the boundary. Suspicious activity surfaces at the fintech but takes too long to reach the bank's decisioning, and the filing timeline blows.
- No clean audit trail. When the examiner asks for evidence, the bank spends weeks assembling it from spreadsheets and email, which is itself a finding.
The 2024 banking-as-a-service fallout put names to these patterns. The April 2024 collapse of middleware provider Synapse froze roughly $265 million in end-user funds across its partner fintechs and left customers unable to reach their money, and in June 2024 the Federal Reserve issued a cease-and-desist to Synapse's partner bank, Evolve, citing AML and fintech-partner risk-management failures. The lesson examiners drew is the one above: the bank holds the non-delegable obligation, and oversight that cannot produce evidence is the exposure.
What examiners look for
An examiner reviewing a BaaS program is asking one question in several forms: can this bank demonstrate control over what its partners do? Concretely, they want to see:
- A current partner risk assessment that matches the partner's actual business today.
- A board-approved oversight framework with clear ownership and thresholds.
- Evidence that monitoring happened. They want the outputs, not proof that a tool exists.
- Independent testing of the partner's controls, with findings tracked to closure.
- Documented remediation of prior issues, retrievable on demand as examiner-ready evidence.
How to build oversight that holds up
A program that survives an exam tends to share five traits. None of them require a 50-person compliance department; they require the work to produce a durable record as a byproduct.
- Risk-rank your partners. Not every partner deserves the same intensity. Tier them by product, customer base, geography, and volume, and let the tier drive how often you test.
- Make the framework specific. Replace generic language with named owners, real thresholds, and defined escalation paths across the bank-fintech line.
- Instrument for evidence. Design every control so it leaves a timestamped artifact. If an examiner could ask "show me," there should be a "here it is."
- Test independently and on a cadence. Scope each independent review to the partner's real risk, and track findings to closure. Open findings from last cycle are the first thing an examiner reads.
- Keep evidence retrievable. The difference between a calm exam and a painful one is usually whether the proof is one query away or three weeks of assembly away.