There is a recurring pattern in fintech launches. The founder commits to a launch date eight months out. Engineering ships on time. The fintech launches on time. Six weeks later, the platform is in some combination of: regulatory inquiry, sponsor bank scrutiny, dispute backlog, reconciliation drift, or customer support meltdown. None of these were engineering failures. All of them were artifacts that should have been in place before launch and were not.
This guide is the pre-launch checklist I would run if I were sitting on the founder side of a fintech launch tomorrow. It is not a feature list. It is the regulatory and operational scaffolding that has to be in place before a single dollar moves through your platform.
The framing I use: the day you launch, your platform stops being a software project and starts being a financial institution. The transition has to be planned for. Most fintechs don't plan for it because the software-project mindset has already filled the calendar.
TL;DR
- Sponsor bank, BIN, and MTL strategy are launch-blocking artifacts. Lock them at day −90, not day −14.
- Daily automated reconciliation must be running for at least ten consecutive business days before you launch.
- CNP fraud finds you in week one. Real-time scoring is not optional.
- Customer support model and on-call rotation are pre-launch requirements, not post-launch projects.
- Closed beta with real money exposes everything a feature-test environment cannot.
- Go/no-go is on hard criteria, not on schedule pressure. Missing one means you slip the date.
Why fintech launches go wrong on the operational side
The reason engineering-led fintechs miss this is structural: the work that gets you to launch in the software sense (build features, integrate APIs, ship UI) is visible and trackable, and the work that gets you to launch in the financial institution sense (BSA/AML program, dispute pipeline, reconciliation tooling, support runbooks) is invisible to anyone who isn't operationally minded. The engineer who has shipped on schedule for years assumes the launch date is a function of engineering progress. It isn't. It is a function of the slowest of: engineering, regulatory readiness, operational readiness, and bank sign-off.
If you treat all four as parallel tracks from day −90, you ship on time. If you treat regulatory and operational as something that happens "as we get close," you don't.
The day −90 artifact list
These are the non-negotiables that have to exist by day −90 or your launch date is already at risk.
Bank and network artifacts
- Signed tri-party agreement with the sponsor bank
- BIN range assigned (or sub-issuer arrangement documented)
- Network certification path identified (Visa or Mastercard, with timelines)
- Settlement account opened and funded with minimum reserves
Regulatory artifacts
- Money transmission strategy decided (sponsor bank umbrella, own MTLs, or agent-of-payee — each is a different 12-month project, so this can't be decided in week 11)
- BSA/AML program documented, with a designated BSA officer
- OFAC screening operational
- Customer Identification Program (CIP) operational
Operational artifacts
- Sub-ledger reconciliation pipeline functional (see our sub-ledger guide)
- Incident response runbook for money-movement breaks
- Support escalation paths documented with the BaaS provider or sponsor bank
If any of the above is missing at day −90, the realistic launch date is later than you think. Adjust before you commit.
Reconciliation: ten consecutive clean days
The hardest single number on this list, and the most-skipped, is ten consecutive business days of clean automated reconciliation against the sponsor bank's settlement file before launch.
The reason it is ten and not three: ten days exposes weekend behaviour, mid-month settlement quirks, ACH return cycles (returns typically arrive on T+2 to T+5), and at least one network exception report cycle. Three days exposes none of those. A platform that reconciles cleanly for three days in a row will surprise you on day seven.
If you do not have a daily automated reconciliation pipeline at day −60, you are not launching at day 0. Build the pipeline first; build the dashboards later.
Card-not-present fraud will find you in week one
There is no grace period for fraud rings. They watch for new BIN ranges, they test cards within hours of activation, and they exploit any platform whose fraud controls are not on from the first transaction.
What "on from the first transaction" means in practice:
- Real-time fraud scoring on every authorization (yours, the processor's, or both)
- Velocity rules tuned for cold-start (a single card, multiple merchants, increasing amounts is a red flag everywhere)
- Device fingerprinting and behavioral signals on onboarding
- A documented playbook for shutting down a customer pipeline in under one hour
If your fraud controls "go live next month," you are giving away money for a month.
Disputes are a workflow, not a checkbox
The dispute pipeline has to be:
- A workflow that captures chargeback notifications from the network
- A workflow that surfaces them to support and to the customer
- A workflow that collects evidence (receipts, IP logs, device fingerprints, delivery confirmations)
- A workflow that submits evidence to the network within the required window
- A workflow that posts the outcome to the ledger correctly
Each of those is non-trivial. Each has to be tested before launch with sample disputes. The first chargeback in production is not the time to discover that your dispute pipeline has a typo in the form submission to the network.
Customer support is a pre-launch decision
If your debit card customer is woken up at 2 AM by a hotel that declined their card, they need to reach a human in fifteen minutes or less. The wrong answer is "we'll handle support in-house after we hire the team." The right answer is one of:
- 24/7 in-house support with a documented escalation path
- 24/7 outsourced support with documented SLAs and a contract
- A contractual SLA from the BaaS provider that covers your customer
- A clearly-disclosed limitation on your product (business hours only, no card replacement after hours)
Pick one. Document it. Have it live before launch. The Yelp reviews from your first quarter are written based on the 2 AM call experiences.
The legal artifacts you forget at your peril
Founders consistently underestimate the legal pre-launch list. The non-skippable artifacts:
- Deposit account agreement (the actual agreement your customer signs, in the bank's name not yours)
- Card cardholder agreement
- E-sign disclosures
- Privacy policy
- Reg E error resolution procedure (this is federal law; you must have it)
- Patriot Act / CIP notices at signup
- Terms of service for your specific product
- ADA accessibility statement if you do business in jurisdictions that require it
Each is a legal review item. Each takes longer than you expect. Start at day −60 minimum. Allocate budget.
Closed beta with real money
The transition from a feature-test environment to a real-money environment is the single most informative two weeks in a fintech's launch sequence. Run a closed beta with real cards, real ACH, real customers (ten to fifty, ideally), real customer support calls, and ideally at least one real dispute. Every problem you find in closed beta is one you don't find in production with thousands of customers.
A useful framing: if you cannot survive a closed beta of fifty users, you cannot survive an open launch of fifty thousand. The closed beta is the dress rehearsal for the regulatory and operational stack, not for the features.
Incident response runbooks before launch
Who pages whom at 3 AM when reconciliation breaks? Who has authority to halt money movement? What is the bank notification SLA when you suspect a problem? Who talks to regulators if it becomes a regulatory event? Who talks to the press?
These are pre-launch documents, not post-launch documents. Your first incident is not the time to figure out the chain of command on top of figuring out the technical problem. Write the runbook. Practice it once. Then launch.
Go/no-go on hard criteria
Seven days before launch, run a go/no-go review against hard criteria, not against schedule pressure. The hard criteria:
- Ten consecutive business days of clean automated reconciliation
- Closed beta complete with no unresolved compliance or money-movement defects
- Customer support model live and tested
- Fraud controls live with real-time scoring
- Dispute pipeline tested end-to-end
- Legal review complete on all customer-facing documents
- Sponsor bank sign-off on launch readiness
- Incident response runbook tested
If any of these is missing on day −7, the right answer is to slip the launch date by the time required to fix it. The cost of a one-week or even one-month delay is dwarfed by the cost of launching into an unready stack and spending two quarters cleaning up.
Closing
There is no shortcut around this list. The fintechs that ship cleanly are not the ones that worked harder in the final two weeks. They are the ones that started the regulatory and operational track at day −90, in parallel with engineering. The fintechs that miss are the ones that confused "feature-complete" with "launch-ready" and ran the calendar against the wrong target.
If you want to think about the underlying economics of these decisions, the pillar on composable fintech infrastructure and the BaaS evaluation guide are the natural complements to this checklist. The glossary entries on sponsor banking and interchange round out the vocabulary.
Build the operational scaffolding. Then launch. In that order.
— Darin Petty