Building a BSA Program at a Seed-Stage Fintech: Minimum Viable Compliance

Before we built Riftbeacon, I spent three years as a BSA analyst at a neobank. One of the things I remember most clearly from that period is how the compliance program was assembled: reactively, often in response to a partner bank asking for documentation we did not have yet, or a prospective investor asking questions we could not fully answer. The program got built, but it got built in the wrong order, which created gaps that took years to fully close. This guide is an attempt to describe the right order, for the seed-stage founders and first compliance hires who are at the start of that process.

Why "Minimum Viable" Is the Right Frame

Seed-stage fintechs applying for banking charters or BaaS partnerships face a real tension. Bank Secrecy Act program requirements were written for institutions with compliance departments, legal teams, and technology budgets that a seed-stage company does not have. The full FFIEC BSA Examination Manual describes a program with five core elements, and each of those elements has sub-elements with their own requirements. A literal reading of the guidance might lead a founder to conclude that BSA compliance requires a team of 10 and a six-figure software budget before you can open a single account.

That is not the right interpretation. Regulatory guidance is explicitly risk-based, which means the depth and breadth of each program element should be proportionate to the institution's actual risk profile. A seed-stage fintech with 2,000 customers and one payment product has a materially different risk profile than a bank with 500,000 customers and eight product lines. The program requirements are not the same, and regulators who examine early-stage institutions know the difference.

Minimum viable compliance, as I think about it, means building the five required program elements in a form that is honestly proportionate to your current risk profile, with clear documentation of the design decisions you made and the risk basis for them. Not a placeholder program that looks complete on paper but is not operational. Not a program so modest that it cannot scale as the institution grows. Something in between, built to be extended.

The Five Required Elements, Sequenced

The BSA requires five program elements for covered financial institutions: internal policies, procedures, and controls; a designated BSA Officer; employee training; independent testing; and customer due diligence. Here is how a seed-stage fintech should sequence building them.

Start with the BSA Officer designation. This is the most operationally straightforward element and the one that unlocks everything else. The BSA Officer needs to be a named individual with board-level authority and documented responsibility for the program. At a seed-stage fintech, this is often the CEO or a co-founder initially, with the expectation that a dedicated compliance hire follows Series A. What matters is that someone owns the program in writing, before any customer accounts are opened. Regulators and BaaS partners both verify this designation early in the due diligence process.

Build policies and procedures second. The policies and procedures document is not a compliance formality. It is the design specification for the program. A well-written policy document describes who your customer is, what transaction types your product supports, what your risk appetite is, and what monitoring and reporting processes the institution will follow. Writing it forces clarity about the program design before you are operating under pressure. A minimum viable policy document for a seed-stage fintech can be 15 to 20 pages if it is specific to your actual product and customer base. A generic 80-page document copied from a vendor template is worse than a short specific one because it will have procedures your team cannot actually follow.

Build CDD and KYC third. Customer due diligence requirements depend entirely on your product and customer type. If you are opening consumer accounts, you need identity verification, beneficial owner collection for business accounts, and a customer risk rating methodology. The risk rating does not need to be sophisticated at seed stage. A three-tier model, low, medium, and high, based on account type, geography, and transaction behavior, is defensible and operable. What matters is that you have one and that you apply it consistently to every account opened.

KYC vendors including Alloy and Sardine make identity verification operationally accessible for seed-stage fintechs. The vendor relationship handles the bureau checks, sanctions screening, and document verification. Your program documentation needs to describe how you use those outputs, not replicate the underlying infrastructure.

Transaction Monitoring at Seed Stage

Transaction monitoring is the element that seed-stage fintechs get most wrong, typically in one of two directions: either they deploy an enterprise monitoring system they are not resourced to manage, generating alert volumes the team cannot process, or they defer monitoring entirely, planning to add it "when we have more customers."

Neither approach is adequate. The BSA requires transaction monitoring proportionate to your risk profile from the point you begin processing transactions. For a seed-stage fintech, proportionate monitoring might mean a small set of targeted rules covering the highest-risk transaction patterns for your specific product, combined with manual periodic review of transaction activity for early accounts.

• Structuring detection relevant to your transaction types (ACH, wire, P2P, or cash depending on your product)
• High-volume rapid movement patterns, particularly for accounts opened within the last 90 days
• Transactions involving OFAC-sanctioned geographies or counterparties
• Account activity that deviates significantly from the stated purpose at account opening

This does not require an enterprise monitoring platform. It requires monitoring logic that covers those risk areas and analyst capacity to investigate alerts that fire. At 1,000 to 5,000 customers, that is achievable with targeted rules and a compliance analyst reviewing a manageable alert queue weekly.

SAR Filing and Recordkeeping

SAR filing is an operational requirement, not a theoretical one. Every covered institution must have a documented process for identifying suspicious activity, escalating it to the BSA Officer, making the filing decision, preparing the narrative, and submitting to FinCEN. At seed stage, you will file fewer SARs than a mature institution. But you need the process documented before you need to use it, not while you are trying to meet a 30-day filing deadline on your first real suspicious activity case.

FinCEN's online SAR filing system is straightforward. The narrative is the most demanding component, because it needs to describe the who, what, when, where, and why of the suspicious activity in specific, examiner-grade language. Even at seed stage, building a SAR narrative template that walks analysts through the required elements reduces the time and error rate on actual filings significantly.

BSA recordkeeping requirements include five-year retention of account opening documentation, transaction records, SAR filings, and alert disposition records. Cloud storage satisfies retention requirements if the records are organized, searchable, and accessible on examiner request. A shared drive with consistent folder structure and naming conventions works. Documents scattered across personal email threads do not.

Independent Testing: The Element That Gets Deferred

Independent testing is typically the last element that seed-stage fintechs build, partly because it requires an external party and has a direct cost, and partly because it feels like something you do once you have a real program to test. In practice, the right trigger for a first independent test is before your first formal regulatory examination, not after it. Most BaaS partnerships require evidence of independent testing as part of ongoing compliance monitoring, which creates a forcing function.

A first independent test for a seed-stage fintech can be narrow: a review of the program documentation, an assessment of whether the monitoring coverage matches the stated risk profile, a sample test of alert dispositions, and a KYC file review for a sample of recently-opened accounts. An experienced BSA consultant can complete this scope in two to three days. The findings from that review are more valuable than the compliance checkbox, because they identify gaps while the program is still small enough to fix quickly.

Building a BSA program before you have customers is harder than it sounds when you are also building a product, hiring a team, and raising capital. But it is materially easier than building it while you are also managing a BaaS partner audit, preparing for examination, and onboarding your 10,000th customer. The right time to build the foundation is before you need to rely on it.