Before a fintech can launch on a sponsor bank's rails, the bank has to be convinced the fintech's compliance program is real. Compliance gates the launch, and it gates it before any customer is onboarded. You need the program pillars stood up, onboarding controls (CIP, KYC, CDD), transaction monitoring matched to your model, SAR readiness, and the evidence the bank's examiners will later ask for. Build it before go-live. Retrofitting after a finding costs far more than building it right the first time.
Most founders meet compliance the hard way: a launch date on the calendar, a sponsor-bank diligence questionnaire in the inbox, and the slow realization that the product is ready but the program behind it is not. The rails belong to a chartered bank, and the bank does not lend its charter to a fintech it cannot defend to its own examiners.
This guide is the fintech's side of the table. (For the bank's view of the same relationship, see the sponsor-bank oversight guide.) It covers why compliance gates the launch, what the bank checks, the program you need at go-live, the controls that have to work on day one, and a checklist to run before you start diligence.
Compliance is the launch gate
In a Banking-as-a-Service model, the fintech builds the experience and the bank holds the charter. From that split comes the order of operations. The bank carries the regulatory responsibility for what the fintech does, so the bank has to be satisfied with the fintech's program before any customer is onboarded. A polished app with no defensible compliance program does not launch, because we treat the program as part of the product the fintech is shipping.
What the sponsor bank checks before go-live
Sponsor-bank diligence is thorough, and it previews the exam your program will eventually face. Expect the bank to ask for:
| Area | What the bank wants to see |
|---|---|
| Written program | A BSA/AML policy and procedures sized to your product, not a generic template. |
| Risk assessment | A current assessment that matches your real customers, products, and geographies. |
| Accountable owner | A named compliance officer on the fintech side who can answer for the program. |
| Onboarding controls | CIP, KYC, and CDD procedures, including beneficial ownership for business customers. |
| Monitoring & SARs | A transaction-monitoring approach fit for your customer base and a SAR / escalation process. |
| Evidence it operates | Proof the controls run in practice, not just that the policy exists. |
Diligence runs both ways. The 2024 banking-as-a-service fallout, the April 2024 Synapse collapse that froze roughly $265 million in end-user funds and the consent orders that followed at several partner banks, is the reason a fintech should vet the sponsor in return: its reconciliation and for-benefit-of ledger practices, its enforcement history, and whether it can actually support the oversight it will demand of you. A sponsor operating under a consent order can freeze your roadmap.
The program you need at launch
You do not need a 50-person department. You need the BSA program pillars stood up for real, sized to your stage:
- Internal controls. Written policies and procedures that describe what you actually do.
- A designated BSA officer. A named, accountable person, even if the role is fractional at first.
- Training. Role-specific training for the people who touch onboarding, support, and operations.
- Independent testing. A plan for periodic independent review, scoped to your risk.
- Customer due diligence. Risk-based CDD and beneficial-ownership collection at onboarding.
The program does not have to be large. It has to be genuine, documented, and matched to the product you are actually launching.
Onboarding controls: CIP, KYC, CDD
Most of your early risk concentrates at onboarding, so the bank looks here closely. At a minimum you need a Customer Identification Program that verifies who the customer is, due diligence that risk-rates the customer and accounts for their expected activity, and for business customers, beneficial-ownership collection that identifies the people behind the entity. You want a defensible, risk-based decision at account opening, documented well enough that you can show your work months later.
Transaction monitoring and SAR readiness from day one
You cannot wait for volume to build before you can detect suspicious activity. Before launch you need a monitoring approach tuned to your specific customer base and product, rather than generic rules borrowed from a different business, plus a working path from a detected alert to a filing decision. SAR readiness means knowing who reviews, who decides, and how fast, before the first suspicious pattern appears. (When it is time to write one, see the SAR narrative guide.)
The evidence the bank wants
One thing runs through every item above. The bank wants evidence, not assertions. A policy that says monitoring happens carries less weight than a record showing it did. Design your controls so each one produces a timestamped artifact from the start. A fintech that can show the work tends to clear diligence fast. One that can only describe the work tends to spend months in back-and-forth.
A pre-launch compliance checklist
- A written BSA/AML program sized to your product, not a template.
- A current risk assessment matching your real customers and products.
- A named compliance officer accountable on the fintech side.
- CIP, KYC, and CDD procedures, including beneficial ownership for businesses.
- Transaction monitoring tuned to your customer base, not borrowed rules.
- A working SAR and escalation process with named reviewers and timelines.
- A plan for independent testing, scoped to your risk.
- Evidence that each control operates, retained from day one.
- Compliance work started before sponsor-bank diligence, not during it.
The fintechs that launch fastest build compliance alongside the product rather than bolting it on at the end. Stand up a genuine program early and instrument it so every control leaves a record. When the sponsor-bank review comes, you spend it confirming work you already did.