The BaaS / Sponsor-Bank Model and Shared Responsibility

Most fintechs are not banks, but they offer bank-like products: accounts, cards, deposits, payments. They do it through a model called Banking-as-a-Service, or BaaS, where a chartered partner bank rents out its charter and rails, and the fintech builds the app and owns the customer experience. This arrangement is everywhere, and it creates the single most important governance question in fintech AML: when the customer is the fintech's, but the charter is the bank's, where does the Bank Secrecy Act obligation actually live?

Because it has to live somewhere, and regulators will find out exactly where when something goes wrong. This lecture is about getting that answer right before they ask.

Here's the rule, and it's a principle more than a single citation. The chartered partner bank holds the Bank Secrecy Act program obligation, because it's the regulated financial institution. In practice, though, the fintech often operates many of the controls: it runs onboarding, it sees the transactions, it builds the monitoring.

The FFIEC BSA slash AML Examination Manual is clear on the principle that governs this: a bank may use third parties to perform parts of its BSA/AML program, but the bank remains responsible for that program and for ensuring it meets requirements. Outsourcing the work never outsources the accountability. So in a BaaS stack you have a split: the bank is legally on the hook, and the fintech is doing the hands-on work.

If that split isn't carefully documented and overseen, both sides are exposed.

The failure mode is almost cartoonishly predictable, and it goes both ways. On one side, the fintech assumes 'the bank owns compliance, we're just an app,' and quietly under-builds its controls. On the other side, the bank assumes 'the fintech is handling the day-to-day,' and under-supervises.

The result is a gap that falls right between the two parties, where alerts go uninvestigated, customers get onboarded with no real diligence, and suspicious activity goes unreported, with each party believing the other had it. This is not hypothetical. A meaningful share of recent BSA enforcement against partner banks has centered on exactly this: inadequate oversight of fintech program partners, weak monitoring of activity those partners introduced, and unclear ownership of controls.

The lesson: never assume the other party has it. Confirm it, in writing.

So how do you do this right? You document it. A well-run BaaS relationship has a written program agreement and, underneath it, a responsibility matrix that names, for every BSA obligation, who performs it and who oversees it.

Who runs the Customer Identification Program. Who collects beneficial ownership. Who tunes and investigates the transaction monitoring.

Who actually files the suspicious activity report, and in whose name. Who manages sanctions screening. None of those should be blank or ambiguous.

On top of that, the bank performs ongoing oversight: it audits the fintech's controls, sets reporting and escalation expectations, and retains the right to inspect and to intervene. This is exactly what the FFIEC manual and the interagency third-party risk-management guidance expect of a bank using a partner. The matrix plus active oversight is what turns 'shared responsibility' from a slogan into a control.

Here's the practical posture for a fintech: build a real program as if you were responsible, because functionally you often are, and because your bank partner will increasingly demand it. Maintain your own monitoring and escalation, keep clean records, and be ready to hand an examiner a clear picture of who owns what. Expect your bank partner to audit you, and prepare for it as you would a regulatory exam, because in effect it is one.

And don't forget the layer below you: if you use vendors for identity verification, screening, or monitoring, you're now overseeing third parties too, and that oversight rolls all the way up to the bank. The chain of accountability runs from the regulator to the bank to the fintech to the vendor, and every link has to hold.

Let's lock it in. In a Banking-as-a-Service model the fintech owns the customer and the chartered bank owns the BSA obligation, but the work is split and both sides have to oversee that split. The fix is a written responsibility matrix that assigns every obligation, paired with active bank oversight and audit.

Self-check: in your stack, who actually files the suspicious activity report, and can you point to the document that says so? If you can't answer instantly, that's your first gap. The most expensive assumption in fintech AML is 'someone else owns it.'

Eliminate it. Next, we move from who's responsible to what they actually have to build: the pillars of a fintech AML program.