How to Build a Neobank: Key Decisions Before Launch

When launching a neobank, the app is what clients see, but it’s not the most vital feature. Behind it sits a partner bank that holds the deposits, a ledger that must match that bank’s records to the cent, and compliance and operations teams that answer for every account. If that back end fails, the app can’t save the business.

For example, after middleware provider Synapse Financial Technologies went bankrupt in April 2024, a staff memo from the Federal Deposit Insurance Corporation (FDIC) described consumers cut off from their money for months while banks worked out whose funds were whose.

This guide walks founders, executives, and investors through how to build a neobank by way of the decisions that come before launch.

What Building a Neobank Includes

What is a neobank? It’s a financial company that offers accounts, cards, and payments through an app rather than at a branch. In the US, most neobanks aren’t banks in the legal sense because a chartered partner bank holds the deposits, which affects every other decision.

The founders of Tidewell (a hypothetical startup building a neobank apps for companies gig drivers) walked into their first sponsor-bank meeting with a product demo: a cash-out button and a debit card with their logo on it. The bank spent little time on the screens as it wanted to know who would review flagged accounts, who would answer complaints, and how the startup would prove its numbers matched the bank’s.

A neobank turns out to be five operations stacked together, and the engineers built one of them.

1. The license layer. Someone needs legal permission to take deposits and move money. In the US, that comes from a bank charter granted by the Office of the Comptroller of the Currency (OCC) for national banks, by a state regulator, or from a sponsor bank that lets a startup offer products under its charter. Tidewell chose the sponsor route, a decision that belonged to the founders and their lawyers, not the dev team.
2. The partner layer. Around the bank sit the card issuer, the payment processor, and the identity-verification vendor. Each one is a contract with its own fees, service levels, and data formats, and each one sets limits on what the product can do.
3. The software layer. This is the engineering team’s turf: the ledger that tracks every dollar, the connections to partners, and the internal tools staff will use. It’s where most of the build budget lands.
4. The channel layer. The mobile app and website are the part a driver touches. It gets the most airtime in a pitch deck and carries the least weight in a regulator’s review.
5. The operations layer. The people who review suspicious activity, settle disputes, answer support tickets, and file reports. Software routes the work to them; it doesn’t make the work disappear.

Drawing these lines before the first sprint saves money, because the obligations don’t move when the org chart does. The Interagency Guidance on Third-Party Relationships, issued in June 2023 by the Federal Reserve, the FDIC, and the OCC, expects banks to manage the risks of each outside partner from the first round of due diligence through the end of the relationship.

To put it simply, Tidewell’s sponsor bank will hold Tidewell to bank-grade standards, and Tidewell’s product team needs to know which of those standards it owns before it promises anything to a customer.

Choose the Operating Model First

With the layers sorted, Tidewell’s next move was to answer six questions that would dictate those choices. Because a team that jumps ahead to the development stage ends up redesigning it once the answers arrive.

Who is the customer? Tidewell chose independent gig drivers because they want instant access to earnings, run their lives from their phones, and may have thin credit files. A neobank for small businesses would face a different challenge, since business accounts require verifying the people who own and control the company before an account is opened.

What will it sell at launch? A spending account and a debit card. Tidewell parked ideas like earnings advances and savings goals, because each new product brings its own disclosures, partners, and risk reviews, and the team wanted a first release it could run without cutting corners.

Where will it operate? Drivers cross state lines, so geography matters. US money transmission is licensed state by state, and the Conference of State Bank Supervisors (CSBS) drafted the Money Transmission Modernization Act (MTMA) to bring those rules into closer alignment. As of August 2026, CSBS reports that 35 states have adopted it in full or in part, though states apply it in different ways. Whether Tidewell’s setup needs its own licenses or can operate under the bank’s charter is a call for its counsel, and that answer redraws the launch map.

How does the money move? Tidewell’s customer money sits in a pooled custodial account at the partner bank, known as a “for benefit of” (FBO) account. Each driver’s slice can qualify for FDIC coverage through pass-through rules, but that coverage depends on records showing which slice belongs to whom.

After Synapse, the FDIC proposed a rule in September 2024 that would require banks to maintain owner-level records for such accounts, reconcile them every business day, and retain direct access to records held by outside firms. For Tidewell, the takeaway was practical: its ledger had to produce records the bank could pull at any hour, not reports stitched together when someone asked.

What happens if the bank stumbles? A sponsor bank’s regulatory trouble flows downstream. In June 2024, the Federal Reserve issued an enforcement action against Evolve Bank & Trust, citing deficiencies in its anti-money laundering, risk management, and consumer compliance programs and requiring tighter oversight of its fintech partners. Startups working with that bank inherited new limits through no product decision of their own. Tidewell added a review of each candidate bank’s enforcement history to its diligence list.

Who signs off? Tidewell named a person, not a department, for each duty: the Bank Secrecy Act (BSA) and anti-money laundering (AML) program, complaint handling, and marketing review. The FDIC’s Part 328 rules on misrepresenting deposit insurance apply to non-banks as well as banks, so a careless “FDIC-insured” badge in an app store listing can become a regulatory issue. Data rules belong on the same list: the Customer Identification Program (CIP) rule requires banks to keep identity records for years after an account closes, which imposes storage and access requirements on the platform.

Six answers, written down, gave Tidewell’s engineers a spec instead of a guess. The next question was how much of the system to build.

Custom Development vs. BaaS vs. White Label

Tidewell had three ways to get from spec to product. It could write its own platform from the ground up. It could build on a Banking-as-a-Service (BaaS) provider, a company that packages a partner bank’s accounts, cards, and transfers into a neobank API that developers plug into. Or it could license a white-label neobank, a ready-made app and back end that it would brand as its own.

 

The table above makes the paths more defined. Tidewell’s plan used all three: a BaaS provider for accounts and ACH (Automated Clearing House) transfers, a card program partner’s white-label tools for card controls, and a custom ledger and onboarding flow. Instant cash-out was the feature that would win over drivers, and Tidewell couldn’t afford to rent it from a vendor that also served its competitors.

That mix points to a handy rule of thumb. Own the parts that make customers pick you and the parts that hold your records. Rent the parts every neobank needs, and nobody chooses a bank for. A company testing a niche might start on a white-label stack, prove demand, and pull pieces in-house as volume grows.

A company whose pitch rests on a one-of-a-kind experience might go custom from day one. Either way, the neobank platform should follow the strategy, and every contract should include a way out if a provider no longer fits.

How to Build a Neobank Step by Step

With the build chosen, Tidewell turned the plan into stages. Each stage below ends with two things: what it produces, and a test that tells the team it’s finished. For founders figuring out how to start a neobank, those tests separate progress from motion.

Stage 1: Map the Business Model, Regulatory Dependencies, and Partner Responsibilities

Tidewell’s team started at a whiteboard, not a keyboard. They charted every path a dollar could take through the system: a payout from a gig platform, a swipe at a gas station, a refund, a cash-out to an external account.

What it produces: a business map showing every money path, account status, permission, and exception, alongside a responsibility chart that splits duties among Tidewell, the sponsor bank, and each vendor.

How to know it’s ready: anyone on the team can pick a transaction type and name, and specify who records it, who checks it, and who answers if it goes wrong. A blank square on that chart is a future incident.

Stage 2: Define Launch Features and Customer Journeys, Including Exceptions and Manual Reviews

Next, the team wrote out each journey a driver could take, start to finish. Opening an account was the obvious one. The valuable ones were less obvious: a selfie that fails verification at 2 a.m., a payout held for review, a driver who reports a card charge she didn’t make, a transfer that bounces back.

What it produces: a ranked launch feature list and a journey map that covers success, rejection, manual review, reversal, dispute, and escalation for each feature.

How to know it’s ready: every branch of every journey ends somewhere defined, and each step that needs a human has a named team and a tool. If the answer to “what happens next?” is a shrug, the journey isn’t done.

Stage 3: Design the Architecture and Select Providers

Here, the map becomes a blueprint. Tidewell’s design centered on six core systems:

1. Customer apps for sign-up, login, balances, cash-out, card controls, statements, and alerts, with strong authentication guarding them all.
2. KYC and AML. Know Your Customer (KYC) checks start with the CIP minimums, a name, date of birth, address, and identification number for each individual, then move through verification, screening against government lists, risk scoring, and human review of flagged cases, with each decision logged.
3. Accounts and a double-entry ledger. Every movement gets recorded twice, as a debit in one place and a credit in another, so the books balance at every moment, and any figure on a driver’s screen can be traced to the entries that produced it.
4. Payments and cards for ACH transfers, card issuing and processing, spending limits, holds, reversals, and fraud rules.
5. Reconciliation that compares Tidewell’s ledger with the bank’s and each processor’s records every business day, flagging mismatches for follow-up.
6. Back office and reporting with work queues, approval steps, case notes, audit trails, and the reports the bank and regulators expect.

Provider selection was based on this blueprint, not on sales pitches. Tidewell scored candidates on product and state coverage, uptime record, how the contract divides compliance work, data access and export, webhook reliability, sandbox depth, incident support, and the cost and effort of leaving.

The team also set its neobank API approach: Tidewell’s apps would talk to its own internal interfaces, which in turn talk to providers, so swapping a vendor meant changing one connector instead of the whole product.

What it produces: an architecture document that names the system of record for each kind of data, the boundaries between systems, how events flow, and the chosen providers with their contract duties.

How to know it’s ready: for any number a driver or the bank might question, the team can name the one system whose record wins, and no single vendor’s exit would force a ledger rebuild.

Stage 4: Develop Customer Channels and Integrate Core Systems

Construction ran in short cycles, with the app and the back end growing side by side. A cash-out button means nothing until it’s wired to a ledger, a payment rail, and a fraud check. Companies without in-house banking engineers can bring in a specialist for neobank app development to build the channels, connect the core systems, and stand up the internal tools as a single program.

Tidewell’s engineers held to a few rules that protect money: separate test and live environments, locked-down secrets and staff access, versioned contracts between services, and idempotency on every money-moving action. That last safeguard counts a retried request once, so a driver who taps “cash out” twice on a weak signal gets paid only once.

What it produces: working apps connected to the ledger, KYC, payments, cards, and back office, with automated reconciliation running against partner data.

How to know it’s ready: a duplicate request produces a single payment in testing, and partner transactions flow into the ledger and match without hand edits.

Stage 5: Test Security, Financial Reconciliation, and Operational Readiness

Tidewell’s testing plan focused on bad nights rather than good demos. Security testers went after login, APIs, and internal access. Finance ran large batches of transactions through the ledger and matched them against bank records to the cent. Engineers staged failures: a processor that stops responding, a notification that arrives twice, a transfer stuck halfway.

The operations team was tested as well because federal rules set the pace. Under Regulation E, which covers consumer electronic transfers, an institution investigating a reported error has 10 business days, or up to 45 business days if it provides the customer with a provisional credit and meets other conditions. Tidewell ran mock disputes through its queue against those clocks.

What it produces: security test results with fixes logged, a reconciliation report with no unexplained gaps, failure-test outcomes, and trained staff with written procedures.

How to know it’s ready: the team can walk the bank through what happens when a payment fails mid-flight, and support can close a mock dispute inside the legal window.

Stage 6: Launch in Stages and Establish Ongoing Support

Tidewell opened the doors in waves: staff accounts first, then a small group from the waitlist, then the public. Each wave was a chance to watch fraud alerts, sign-up drop-off, failed payments, and support load while problems were small. After launch, the work took shape rather than shrinking: an on-call rotation for incidents, a process for tracking rule changes and partner updates, a release schedule, and capacity plans for growth.

What it produces: a wave-by-wave launch plan with go and stop thresholds, plus a support model naming who handles incidents, compliance updates, monitoring, and reporting.

How to know it’s ready: the numbers that would halt the next wave are written down before the first wave starts, and every support duty has a person’s name next to it.

Common Neobank Development Mistakes

Tidewell is made up, but the traps it sidestepped are real, and they show up across the industry in familiar forms:

1. Signing providers before drawing the funds flow. A vendor chosen from a slick demo can lock the product into a money structure that doesn’t fit, and undoing it means migrating live customer accounts.
2. Treating KYC as a single API call. Identity checks are a chain of collection, verification, screening, scoring, and human judgment. Wiring up one vendor endpoint and calling it done leaves gaps that bad actors find first and examiners find next.
3. Letting reconciliation slide. Small mismatches between the ledger and the bank grow. Synapse showed the end state: when no one can say whose money is whose, customers wait, and no app update fixes it.
4. Skipping tools for manual work. Every held payout and disputed charge lands on someone’s desk. Without proper queues and case tools, staff fall back on spreadsheets and email threads, response times stretch, and legal deadlines slip by.
5. Getting locked into one vendor. When one provider holds the ledger, the data, and the customer relationship, it holds the pricing power as well. Any change turns into a rebuild, and that provider’s problems become the neobank’s problems.
6. Leaving ownership blank after launch. The project plan ends at go-live; the job doesn’t. Without named owners for incidents, partner changes, and new rules, a platform drifts until something breaks loud enough to get noticed.

Every item on this list started as a shortcut that saved time in the moment, and every one sent a bill later, with interest. Founders who settle on the operating model first, decide to build rather than buy one component at a time, and refuse to leave a stage until its test passes end up with more than a sleek app. They end up with a neobank that can show its bank, its regulators, and a driver in a parking lot where every dollar sits, down to the cent.