Fintech apps fail for reasons that have nothing to do with code. They fail because the sponsor bank's review took four months nobody planned for, because the ledger was an afterthought, or because a compliance requirement surfaced after launch. This fintech app development checklist is written from building payment and finance products, and it covers what the app needs, what the law needs, who you will partner with, and what it costs.

It assumes a US consumer or small-business product that holds or moves money, or reads financial data. If you are building a lender, a broker-dealer or a crypto exchange, most of this still applies, with more regulators added.

The five features every fintech app must have

  1. Identity verification (KYC). Document capture, liveness, database checks and sanctions screening, usually through a vendor, with a manual review queue for the cases the vendor cannot decide. Typically 85 to 95 percent of applicants pass automatically. The rest land in the queue: a name mismatch from a recent marriage, a blurry license, a partial watchlist hit on a common name. Someone on your team clears those daily. Build the queue screen, the audit trail of who approved what, and the "request another document" flow in the first release. Teams that skip it end up approving people from a spreadsheet, which no bank examiner accepts.
  2. Account linking or card issuing. Either the user connects an external bank account (via an aggregator) or you issue accounts and cards through a partner. Both come with webhooks, failure states and re-authentication flows that need designing. Linked accounts break when a user changes a bank password or the bank changes its login. Expect a meaningful share of links to need re-authentication within a few months, and design the prompt for it. Card issuing brings its own states: shipped, activated, frozen, reported lost, reissued. Each is a webhook your backend must handle idempotently, because partners retry.
  3. A ledger you own. An append-only record of every balance change, double-entry, with the partner's records reconciled against it daily. This is the heart of the product. Do not let it be a column called balance on the users table. A worked example: a user sends $50 by ACH. You write one journal entry with two lines, a $50 debit to the user's available balance and a $50 credit to a pending-outbound account. When the partner confirms settlement, a second entry moves the $50 from pending to settled. If the transfer is returned three days later, a third entry reverses it. Nothing is edited. The balance is always the sum of entries, and every number on screen can be traced to a row.
  4. Transaction monitoring. Rules and limits that flag unusual activity, with a case queue for a human. Required for anti-money-laundering compliance and for your own fraud losses. Typical first rules are simple. Flag deposits over a daily limit. Flag a new account that receives funds and withdraws them within 24 hours. Flag several transfers just under a reporting threshold. Each flag opens a case with a status, notes and a decision. That record is what your partner asks to see.
  5. Disclosures and statements. Fees, terms, interest, and periodic statements, delivered and recorded. Regulators ask for proof that the user saw them. Store which version of each document the user accepted, when, and from which device. When you change the fee schedule, you need to show who was notified and how. If you deliver disclosures electronically, the E-SIGN Act's consent requirements apply, so the consent step is a designed screen, not a checkbox buried in signup.

The regulations, by name

Bank Secrecy Act and FinCEN rules drive KYC, customer due diligence and suspicious-activity reporting. If you partner with a bank, you perform these on the bank's behalf under its program. In practice the bank hands you its BSA/AML policy and expects your onboarding, monitoring and escalation to match it. Your monitoring cases feed the bank's suspicious-activity decisions, so the case data must be exportable and complete.

State money-transmitter licensing applies if you hold or move customer funds yourself. Most startups avoid it by using a sponsor bank or a licensed payment provider, which is why that partnership is the first decision, not the last. Getting licensed state by state takes a long time and real capital. It is rarely the right first step.

PCI DSS applies the moment card data touches your systems. Keep it out: use a provider's hosted fields or tokenization so your scope is a questionnaire, not an audit. Good looks like this: the card number goes from the user's device straight to the provider, and your servers only ever see a token. Bad looks like a custom card form that posts to your API "just to validate it." That one design choice moves you into a much larger scope.

Regulation E governs electronic transfers and error resolution timelines for consumer accounts. When a user disputes a transfer, the clock starts. You generally have 10 business days to investigate, or longer if you provisionally credit the account, so the dispute flow needs timestamps and reminders built in. Regulation Z applies if you extend credit. GLBA covers privacy of financial information. UDAAP rules shape every fee disclosure and marketing claim. If you serve businesses only, some consumer rules fall away, but the sponsor bank's requirements usually do not.

If you move money over ACH, the Nacha Operating Rules also apply through your bank, covering authorization wording, return handling and fraud monitoring. Data-access rules for aggregation are also shifting at the CFPB. Check the current status of the Section 1033 open-banking rule with counsel before you design around it.

The integrations and partners

  • Sponsor bank or banking-as-a-service provider: accounts, payments rails, cards. Their compliance review of your app is the longest item on the schedule. Expect a due-diligence questionnaire, policy documents, a review of your screens and marketing, and often a call with your compliance lead. If you do not have one, they will ask you to name one.
  • KYC vendor: identity documents, liveness, watchlists. Pricing is typically per check, often a dollar or two per applicant, so failed signups cost money. Put cheap checks first and expensive ones last.
  • Account aggregation: linking external bank accounts and reading balances. Often used to verify account ownership before an ACH pull, which cuts returns.
  • Payment rails: ACH, card acquiring, real-time payments, each with its own return and dispute flows. ACH is cheap but slow and reversible for days. Real-time payments settle in seconds and cannot be pulled back. Card acquiring brings chargebacks. Each needs its own states in the ledger.
  • Fraud and monitoring tools, or rules you build on your own ledger events. Building your own rules on ledger events is usually fine for a first version with a few thousand users.
  • Accounting and reconciliation exports for your finance team. A daily file comparing your ledger to the partner's settlement report, with every difference listed, is the minimum.

Fintech app development timeline and cost

A first version that issues accounts through a licensed partner, with KYC, a ledger, transfers in and out, monitoring and statements, takes five to eight months and costs $200,000 to $400,000 at typical 2026 US agency rates. Half the calendar is partner onboarding and review, which is why we start the partner application in discovery. An app that only reads linked accounts and gives insights, with no money movement, is $90,000 to $160,000 over three to five months. Budget 20 percent of the build cost per year for maintenance; partner API changes and compliance updates are constant.

A typical schedule for the money-movement version looks like this:

  1. Weeks 1 to 4: discovery, partner selection, partner application submitted.
  2. Weeks 4 to 12: ledger, KYC and core flows built against the partner's sandbox, while due diligence runs in parallel.
  3. Weeks 12 to 24: transfers, monitoring, statements, admin tools; screens and disclosures submitted for review.
  4. Final weeks: review changes, production credentials, a limited launch to a few hundred users.

Separate from the build, plan for partner fees, often a monthly minimum plus per-account and per-transaction charges, and for per-check KYC costs. These vary widely by partner, so get them in writing before you commit.

Three mistakes first-time buyers make

  1. Choosing the partner after the design. Each partner's capabilities and limits shape the product. Choose first, design within the constraints. A common scenario: a team designs instant payouts, then learns their chosen partner only supports standard ACH for their program. The core screen is redesigned, and the marketing copy with it.
  2. Treating the ledger as a database column. The first reconciliation failure is when teams discover they cannot explain a balance. Double-entry from day one. Retrofitting a ledger means replaying months of transactions from partner reports, and some will not match. That is weeks of work at the worst time.
  3. Under-planning the review cycle. The partner will review every screen that mentions money, every disclosure, and every marketing page. Budget two rounds of changes. Small wording issues cause most rejections: "free" next to a fee, "savings" on a product that is not a savings account, "FDIC insured" without the required qualifier.

Two questions to ask any agency

How do you keep card data out of our PCI scope? The answer should name the hosted-fields or tokenization approach and the resulting self-assessment questionnaire level. A weak answer is "we encrypt everything." Encryption does not remove scope. Keeping the card number off your servers does.

Show me a ledger schema from a previous build. If they cannot sketch double-entry accounts, journal entries and a reconciliation job, they have not built one. A good answer covers how they handle pending versus settled funds, reversals, and idempotency keys on partner webhooks.

If you are planning a fintech product, tell us about it. An engineer who has built with sponsor banks and payment providers will reply with a scope that names the partners and puts their review cycles on the calendar.

Frequently asked questions

Do we need our own license?

Usually not for a first version. A sponsor bank or licensed provider covers it, and you inherit their compliance obligations. Licensing becomes a question at scale, when the partner's fees exceed the cost of your own program.

Can we launch without transaction monitoring?

No partner will allow it, and you would not want to. Start with simple rules and limits; sophistication comes with data.

How is this different from an e-commerce checkout?

Checkout moves money once, through a processor that holds the risk. Fintech holds balances and moves money repeatedly, which is why the ledger, the monitoring and the regulations exist.

How long does sponsor bank approval take?

Plan for months, not weeks. Due diligence, policy review and screen review often run two to four months combined. Starting the application during discovery keeps it off the critical path.

How much does fintech app development cost?

For a first version that moves money through a licensed partner, $200,000 to $400,000 at typical 2026 US agency rates. A read-only insights app runs $90,000 to $160,000. Partner and KYC fees come on top.