FintechSoftwareDevelopment:TheFiveGatesBetweenaWorkingDemoandaBankThatWillCarryYourMoney

The short version

The demo works. Money moves in sandbox, the screens are done, and the launch date is written down.

It is also tied to a bank, a licence or a store review that has not said yes, and the list of things they want is longer than anyone told you. Somewhere on that list is a thing your build cannot produce, and the first quote you got for fixing it was a rebuild.

Here is the short version.

Fintech software development is ordinary software development plus five gates that ordinary software never meets: a licence or a sponsor bank to carry your regulatory liability, a ledger you own, card data kept off your systems, a customer identification program that produces an audit trail, and two app stores that reject financial apps for reasons that have nothing to do with code.

Most builds that stall are stuck at one gate, not five. Most of the build survives.

Read the rest before you answer the bank or sign the rebuild. What each gate asks for and who enforces it. Why a bank's due-diligence team wants evidence a demo cannot give, with the 2024 collapse that changed what they ask for. Who does not need any of this.

Which licence applies in the US, the UK and the Gulf. Why the ledger is the one component you cannot rent, how to stay out of PCI scope, what KYC means when it is code, why the stores reject financial apps, and the three conditions under which a rebuild is honestly the right answer.

Because sometimes it is, and a page that pretended otherwise would just be selling you something else.

What does fintech software development involve that ordinary software development does not?

Five gates, each enforced by someone who is not your customer, cannot be charmed, and asks the build for evidence rather than a demo.

Fintech software development is the building of software that holds, moves, lends or reports on money on someone else's behalf. The code is ordinary. What separates it from a normal product build is not the framework or the database.

It is that a regulator, a bank, a card network and two app stores each hold a veto over whether the thing ships, and each of them has a list. You do not find out what is on the list by launching. You find out by asking, which is what this page does for you.

Almost every vendor that ranks for this phrase writes the same guide: features, types, steps and costs, for a reader who has not started yet. Read the table instead. That is the list you are actually up against, written from the side of a build that already exists.

Two things fall out of that table. First, only one of the five gates is about code quality, and even that one (the ledger) is really about a data model. The other four are about evidence: records, contracts, licences, declarations.

A build that was scoped as an app produces none of them by default, which is why a demo that works perfectly can be nowhere near shipping. Second, the gates are independent.

Failing the store gate does not mean you have failed the bank gate, and a vendor who looks at one failure and quotes you five is not reading the table.

Why does a working fintech demo stall at the bank?

Because the bank is the one that goes to prison, figuratively and occasionally otherwise, and its examiners hold it responsible for everything your app does.

In the arrangement most fintech apps use, the app does not hold the licence. A bank does. Your customers' money sits in accounts at that bank, often one pooled account held for the benefit of all of your users, and your app is the program that decides who owns what inside it.

That is the banking-as-a-service model, and it is a good model, because it lets you launch without spending a year on a licence application.

What it costs you is that the bank carries the regulatory liability for your product, so before it lets you anywhere near its balance sheet its due-diligence team asks you to prove you will not be the reason it gets a consent order.

Until 2024 that list varied a lot by bank. Then Synapse happened. Synapse Financial Technologies was the middleware between dozens of fintech apps and their partner banks, and it kept the ledger that said which end user owned which dollars in the pooled accounts.

When it went bankrupt in April 2024, the ledger and the bank balances did not agree. The court-appointed trustee, Jelena McWilliams, reported on 21 June 2024 a potential shortfall of USD 65 million to 96 million between what the partner banks held and what end users were owed.

One example in her report: a Synapse ledger dated 11 April showed USD 109 million in balances for users of one fintech, and a ledger dated 17 May showed USD 1.4 million for the same users, with no corresponding transfers to the bank and no apparent payouts.

The FDIC's vice chairman put the human number on it in September: over 100,000 customers lost access to their accounts.

Regulators wrote down what they had learned.

On 25 July 2024 the OCC, the FDIC and the Federal Reserve issued a joint statement on banks' arrangements with third parties to deliver deposit products, naming operational, compliance, strategic, liquidity and concentration risks, and risks related to consumer protection, end user confusion and misrepresentation of deposit insurance coverage.

On 17 September 2024 the FDIC proposed a rule requiring banks that hold custodial deposit accounts with transactional features to maintain records of end-user depositors, identifying each beneficial owner and the balance attributable to them, to conduct reconciliations at the close of each business day, and to have those records validated annually by an independent party.

Whatever the final form of that rule, every sponsor bank read the proposal, and the due-diligence list now looks like it.

So here is what the bank asks for, and why your build cannot produce it. A ledger of every end user's balance that the bank can reconcile against its own records, daily. Your build has a balance column in a users table.

A written customer identification program and the audit trail it generates for every account opened, including what was collected, how it was verified, and the result of the screening against government lists. Your build has a signup form. Evidence that card data never touches your systems, or a full PCI assessment if it does.

Your build has a card form somebody wrote in an afternoon. A penetration test report on the version that will go live. An incident response plan with names in it. Contracts that give the bank access to your records and the right to audit them.

A description of how your product represents deposit insurance to users, because the joint statement calls out apps that let users believe their money is insured when it is not.

This is the difference between MVP-compliant and due-diligence-compliant, and it is the gap most rebuild quotes live in. MVP-compliant means the demo does not break a law. Due-diligence-compliant means a bank examiner can trace every dollar and every identity from your system to the bank's statement and back.

One is a product. The other is a product plus a set of records, and records can be added to a product that exists.

What cannot be added is a ledger to a system that never had one, which is the one place the rebuild question is real, and the ledger section below is where it gets answered.

The stakes, plainly. Your launch date is the bank's date, and the bank's date moves every time you send it something it cannot reconcile.

Your customers' money is only as safe as the record of who owns it, and if that record is somebody else's, Synapse is what its failure looks like from the customer's side.

And every month the build sits at the gate is a month of runway spent on a product that cannot take a deposit.

Who does not need a licence, a sponsor bank, or us at all?

More products than the vendors on this SERP would like.

If your app only looks at money, or a licensed provider holds all of it and your code never touches a balance or a card number, you do not need a licence, you do not need a sponsor bank, and you do not need a fintech partner.

You need a normal software team and a good read of your provider's terms.

Read-only apps come first. Budgeting apps, spend analytics, tax estimators, anything that connects to a bank account through a licensed aggregator and shows the user what is in it. Nothing moves, so there is no money transmission, no ledger of funds and no PCI scope.

What you do have is a data protection obligation, because financial data is sensitive under every privacy regime, and an aggregator contract whose terms decide what you may store. Read the contract. Encrypt what it lets you keep. Ship.

Then the merchant shape. A marketplace, a subscription product, a booking app, where a licensed payment provider collects the card, holds the funds, pays you out, and your code sees a token and a webhook. You are a merchant. The provider is the regulated party.

You have one obligation that matters, which is to keep card data off your systems so that you stay in the shortest PCI assessment, and the PCI section below tells you exactly where that line is. If a vendor has told you this product needs a fintech licence, it has misread the product.

Internal tools are the third group. A finance tool that moves one company's own money between its own accounts, a treasury dashboard, an expense approval flow that ends in a bank transfer a human authorises. Moving your own money is not a regulated payment service anywhere we know of.

The controls you need are the ones your auditor asks for, and they are ordinary controls.

And the early ones.

If you have under a hundred users and no real money has moved, stay in sandbox for another month and do three things: put every money movement through a double-entry ledger table now, while the schema is cheap to change, replace whatever card form you have with the provider's hosted one, and write down your customer identification process on one page, even before you automate it.

Those three things are the difference between a build that meets the gates later and one that has to be rebuilt to meet them.

If you are in any of those four groups, close this tab. You do not need us, and we will tell you the same thing if you send us the repository.

Which licence does your fintech app actually need, by market?

It depends on whether you hold money, move money, or only look at it, and on where your customers are. Every market has the same shape. Only the names and the thresholds differ.

In the United States, moving other people's money is money transmission, and money transmission is licensed state by state, which is why almost every US fintech app launches under a sponsor bank instead.

The bank holds the licence and the deposits, the app is the bank's program, and the bank's obligations under the Bank Secrecy Act flow down to you by contract.

Either way you need an anti-money-laundering program, and the customer identification rule described below is the part of it that lives in code. Two documents decide what your sponsor bank asks for today, the FDIC's custodial-account proposal and the July 2024 joint statement. Read both before you talk to one.

In the United Kingdom, the Financial Conduct Authority regulates payment and e-money firms under the Payment Services Regulations 2017 and the Electronic Money Regulations 2011. If you move money you are a payment institution, and if you issue stored value you are an e-money institution.

Each comes in a small form and an authorised form.

The small payment institution registration is capped at an average of EUR 3 million of payment transactions a month, and the small e-money institution at EUR 5 million of average outstanding e-money, with the full authorisation required above those lines and carrying its own capital and safeguarding requirements.

Where founders get caught is building for the small form and growing out of it, because the upgrade is a full application, not a form.

In the United Arab Emirates, the Central Bank of the UAE licenses retail payment services under the Retail Payment Services and Card Schemes Regulation, issued in 2021.

The regulation names nine categories of retail payment service, including payment account issuance, payment instrument issuance, merchant acquiring, payment aggregation, domestic and cross-border fund transfer, payment token services, payment initiation and payment account information, and it prohibits providing any of them without a licence.

Wallets that store value fall under the separate Stored Value Facilities regulation. If your customers are in the Gulf, the category you fall into decides the licence, and the category is decided by what the app does with money, not by what the marketing calls it.

In India, the Reserve Bank of India requires authorisation for payment aggregators and issues its own directions for prepaid payment instruments, which is the wallet shape.

We mention it because a lot of the products we see are built in India for customers elsewhere, and the licence that matters is the one where the customer is, not where the code was written.

One thing the table cannot show. Every one of these regimes asks for the same underlying evidence: who your customers are, where their money is, and a record that proves both. A licence is the wrapper.

Your ledger and your identity trail are the contents, and they are the same contents in every market, which is why the next three sections are about them and not about forms.

Why is the ledger the part you cannot outsource?

Because the ledger is the only thing that says whose money is whose, and if it belongs to somebody else, then somebody else's failure is your customers' loss. That is not a theory. It is what happened to the users of every app that ran on Synapse.

Start with what a ledger is, because a balance column is not one. Stripe, which has more reason than anyone to get this right, describes its Ledger as an immutable and auditable log that serves as the trustworthy system of record for all of its financial data.

It is based on double-entry bookkeeping, which Stripe calls a standard method for guaranteeing that all money in a system is fully accounted for by balancing credits and debits.

Ledger sees five billion events a day, and Stripe reports that 99.99 percent of its dollar volume is fully ingested and verified within four days, with over 99.9999 percent explainability of money movement.

The mechanism that makes those numbers possible is the part you can copy at any size: a single missing, late or incorrect transaction immediately creates a detectable accuracy issue with a simple query.

Translate that to an app with ten thousand users. A ledger is an append-only table of entries. Nothing is updated and nothing is deleted.

Every movement of money is written as at least two entries that sum to zero, one account debited and one credited, so that a movement that only half happened is impossible to record. A user's balance is not stored anywhere.

It is derived by summing their entries, which means it cannot drift from the truth because it is computed from the truth. Every movement carries an idempotency key, so a retried request cannot move money twice.

And once a day, a job compares the sum of every user's derived balance against the balance the bank reports for the pooled account, and refuses to start the day if the two disagree.

That last sentence is the FDIC's proposed rule, reconciliation at the close of each business day, written as a cron job.

Now look at what Synapse's users had instead. A ledger kept by the middleware, not by the app and not by the bank.

When the middleware failed, the trustee found a ledger that said one fintech's users held USD 109 million on 11 April and USD 1.4 million on 17 May, with nothing in the bank's records to explain the difference.

Apps built on it had no independent record of what their own users were owed, so they could not reconcile, because they had nothing to reconcile with. Banks could not pay out because they did not know who to pay. Customers waited.

That is why the ledger is the one component you cannot rent. You can rent the bank account, the card issuing, the KYC verification, the payment rails and the fraud model, and you should, because each of them is a licensed product that took years to build.

But the record of what your customers own has to be yours, in your database, derived from entries you wrote, reconciled against the bank by a job you run. If your build has that, the bank gate is mostly paperwork.

If it has a balance column, or a ledger that lives in the provider's dashboard and exports as a CSV, then this is the one place on this page where the word rebuild is honest, and the section on rebuilds says exactly when.

How do you keep a fintech app out of PCI DSS scope?

By never letting a card number pass through anything you run. The difference between a form the provider hosts and a form you built is the difference between the shortest PCI assessment and nearly the whole standard.

PCI DSS is the card networks' security standard, and every merchant that accepts cards has to validate against it through a self-assessment questionnaire. Which questionnaire is decided by where the card data goes.

If your site sends the customer to a compliant provider's hosted page, or embeds an iframe served from the provider's own origin, so that the card number is typed into something the provider controls and never touches your servers or your page's scripts, you qualify for SAQ A.

Schellman, a PCI assessor, counts SAQ A at about 22 requirements.

If your own page collects the card number, with your JavaScript or a direct post to the provider, and your code decides where it goes, you are SAQ A-EP, which Schellman counts at about 191 requirements covering most of the standard except cardholder data storage.

Same provider, same processing fees, and one of those is an afternoon of paperwork while the other is a programme of work with a quarterly scan on top.

Since PCI DSS v4.0 there is a catch even for the short form. Requirements 6.4.3 and 11.6.1 now apply to SAQ A merchants with an embedded payment form, because attackers learned to inject scripts into the page around the iframe to skim what is typed into it.

So you have to inventory and authorise every script that runs on your payment page, and detect when one changes. That is manageable. It is a content security policy and a change-detection check, and it is in the security practices our team runs on every build.

What is not manageable is discovering, during the bank's due diligence, that a card number has been passing through your API because somebody wanted a prettier form.

For a fintech app the rule is simple and slightly stricter than the merchant rule, because your bank will ask. Card entry happens in the provider's hosted element. Card storage is a token from the provider.

Your systems never see, log or store a primary account number, not even in an error message, and your logging is checked for exactly that.

If an engineer on your build cannot tell you within a minute which of your systems a card number passes through, the answer is probably more of them than you think.

What does KYC and AML mean in code, not on a slide?

A customer identification program is four fields, a verification, a screening, a retention rule and a trail, and the trail is the part the bank audits.

Start from the US rule, because everything else is a variation on it.

Under 31 CFR 1020.220, a bank must have a written customer identification program that collects, before opening an account, at minimum a name, a date of birth for an individual, an address, and an identification number, which is a taxpayer identification number for a US person and a passport or similar government document for anyone else.

It must verify the identity using documents, such as a government-issued photo identification, or non-documentary methods, such as a consumer reporting agency or a database check, and the program must describe when it uses which. It must check the customer against government lists of known or suspected terrorists.

And it must retain the identifying information for five years after the account is closed, and a record of what it verified and how for five years from when the record was made.

Why does any of this matter to an app that is not a bank? Paragraph (a)(6) of the same rule. A bank may rely on another financial institution to perform its customer identification program, but only under a written contract and with an annual certification that the other institution has implemented its program.

Your sponsor bank is going to rely on your KYC flow. Which means it is going to audit your KYC flow, every year, and the thing it audits is not the vendor you chose. It is the trail.

So here is what the trail contains, per account, if the build is going to pass. What was collected, and when. Which verification method was used and what it returned, including the document images or the database response, stored for the retention period.

The result of the list screening, with the list version and the date. Who or what approved the account, and if a human overrode a failed check, who and why. Every later change to the identity record, as a new entry, not an update.

And a retention job that keeps all of it for five years after closure and deletes it after, because keeping it forever is its own finding under privacy law.

Verification providers exist for the collection and the checking, and they are worth using, because document verification and liveness are hard problems that somebody else has solved. But the choice of provider is not what passes due diligence.

Two apps can use the same provider, and the one that stores the provider's response, the screening result and the approval decision as immutable records passes, while the one that stores a boolean called verified does not.

Anti-money-laundering is the same story after onboarding: transaction monitoring rules, alerts, a case record for every alert, and a suspicious activity report process, each of which is a record your bank will ask to see.

Why do the app stores reject fintech apps, and how do you avoid it?

Because both stores now require financial apps to come from a licensed legal entity, and a lot of fintech apps are submitted from a founder's personal developer account.

Apple's App Review Guidelines say it in guideline 5.1.1(ix): apps that provide services in highly regulated fields, such as banking and financial services, healthcare, gambling, legal cannabis use, air travel and crypto exchanges, or that require sensitive user information, should be submitted by a legal entity that provides the services, and not by an individual developer.

Guideline 3.2.1(viii) goes further for money: apps used for financial trading, investing or money management should be submitted by the financial institution performing such services and must have necessary licensing and permissions in the locations where you make them available.

And 3.1.5(i) allows a wallet app to store virtual currency only when it is offered by a developer enrolled as an organisation. None of those is a code review.

They are checks on who submitted the app and what licence they hold, and a beautiful build submitted by an individual fails all three.

Google Play's Financial Services policy runs the same way. Any app that contains any financial features must complete the Financial features declaration form in Play Console, and Google defines financial products and services as those related to the management or investment of money and cryptocurrencies, including personalised advice.

Personal loan apps must provide a verifiable connection to the licences or documentation that allow them to lend in each region they target, must display the maximum annual percentage rate calculated consistently with the Truth in Lending Act, may not require repayment in full within 60 days of the loan being issued, and, in the United States, may not offer loans at an APR of 36 percent or higher.

Google expanded the personal loans rules to line-of-credit apps in May 2025. The declaration is not optional and it is not fast to fix after rejection, because the fix is a licence.

Getting through is boring. Enrol as an organisation on both stores before you submit, which means a registered company and, for Apple, a D-U-N-S number.

Hold, or partner with someone who holds, the licence the store will ask about for the markets you list the app in, and be ready to attach it. Fill in the financial features declaration truthfully, because a declaration that says no financial features on an app that moves money is a removal, not a rejection.

And if your app started life as a web app and is being wrapped for the stores, read our page on what the wrap has to bundle to pass review, because a financial app that fails 4.2 for being a web clipping and 5.1.1 for being submitted by an individual has two rejections to clear, not one.

When is a rebuild honestly the right answer?

In three cases, and in each the reason is a record that cannot be recovered, not code that is ugly.

Start with the ledger. If your customers' balances exist only in the provider's system, or as a column that has been updated in place for a year, then the history of who owned what and when does not exist anywhere and cannot be reconstructed.

You can build a proper ledger from today forward, opening it with the current balances as the first entries, but the bank will ask how those opening balances were arrived at, and the honest answer is that they are what the old column said. Whether that is acceptable is the bank's call.

What is certain is that the money-movement code that wrote to that column has to be replaced, because it cannot write double-entry records, and in most builds that code is the core of the product. That is a rebuild of the core, not of the app.

Card data is the second. If card numbers have passed through your API, your logs or your database, even once, even in an error message, then your systems are in scope for PCI DSS today and the question is not how to get out of scope but how to prove you are out of it.

The code paths that touched card data have to go, the logs have to be found and purged, and the assessment has to be done on what remains. This is often smaller than it sounds, because it is usually one form and one endpoint.

It is a rebuild of the payment path, and it is not negotiable.

Identity is the third. If verification decisions were made and not recorded, if the provider responses were discarded and a boolean kept, then every account opened so far has no trail, and the bank's reliance on your program cannot be certified for those accounts.

The fix is a re-verification of the existing base under the new program, which customers hate, and a KYC flow rebuilt to write records. The onboarding code is replaced. The rest of the app is not.

Notice what is not on that list. Your framework is not on it. Neither is your database engine. Nor is the fact that the app was built fast, on a no-code tool or with an AI assistant or by a contractor who left.

A fintech app generated by Lovable with a proper ledger table is closer to passing the bank than a hand-built one with a balance column.

The rest of the rebuild question follows the same rule as any other system that still works: move it in slices behind a facade, one gate at a time, with the live product up throughout.

We wrote that argument in full for systems that were quoted a rewrite, and every word of it applies to a fintech app that was quoted one.

One confession, because this page would be dishonest without it. Geminate Solutions makes money from fintech builds too, and a rebuild bills more than a slice. The difference we can offer is not that we have no interest.

It is that the read comes before the quote, on your code, and it names which of the three cases above applies, if any, before anyone at Geminate Solutions says the word rebuild.

What should you ask a fintech development partner before you sign?

Six questions, and the last one is the test. Ask them of us too.

Which gate is blocking, specifically? A partner who has read your build will name one: the ledger, the card path, the KYC trail, the store enrolment, the licence category. Anyone who says compliance is a concern in general has not read it.

What does the bank's list look like, and which items already exist in my build? Use the evidence list in the due-diligence section above as the baseline. A good answer maps each item to a file, a table or a document you already have, and says which ones are missing.

Where will the ledger live, and who owns it? The only acceptable answer is in your database, as double-entry entries, reconciled daily against the bank, with the code and the data yours. A partner that proposes its own platform or the provider's dashboard as the ledger is proposing the Synapse shape.

Which of my systems will a card number pass through? Listen for none, with the provider's hosted element named. Anyone who wants to build a custom card form because it converts better is trading your PCI scope for a percentage point.

What will the KYC audit trail contain, per account? Listen for the list from the identity section: what was collected, how verified, the provider response, the screening result and version, the approval and any override, all as immutable records with a retention job.

What in my current build justifies a rebuild, if you are quoting one? Someone with a real reason will name one of the three cases above and point at the table or the code path. Someone without one will say best practice. That word, in a rebuild quote, is the tell.

Our fintech engineering team answers this question in writing before it quotes anything, and if the honest answer is that nothing in the build justifies a rebuild, the written answer says so.

How does Geminate Solutions run a fintech engagement?

Read first, then a paid pilot sprint on the one gate that is blocking, then the build. In that order, because the order is what stops a rebuild being quoted for a ledger problem.

First the read, which is free. You send the repository, or access to the running system, and the list the bank or the store sent you if there is one.

A senior engineer reads the data model, the payment path, the onboarding flow and the store configuration against the five gates, and writes down which gate is blocking, which evidence already exists, which is missing, and whether any of the three rebuild cases applies.

It is a written document, not a call, so you can send it to the bank, your board or another vendor. If the read says you are in one of the four groups that do not need us, it says so, and that is the end of it.

If there is work, it starts with a paid pilot sprint on the blocking gate, scoped from the read.

Usually that is the ledger: a double-entry entries table, the migration of current balances into it as opening entries, the money-movement code rewritten to write entries instead of updating a column, and the daily reconciliation job against the bank. Sometimes it is the card path, which is a smaller sprint.

Sometimes it is the identity trail. The sprint ends with the gate closed and evidence you can hand to the bank, and you decide whether to continue on the strength of that, not on a proposal.

After that, the remaining gates are taken in the order the bank's list puts them, in slices, with the live product up throughout, by the same fintech engineering team that did the read. We are a software and product development partner, not a staffing agency.

Our team owns the delivery and you own every line of the code and every record in the ledger, which for a fintech is not a slogan. It is the whole point.

Our proof is only what is real: Upwork Top Rated Plus with a 4.9 rating, 50+ products shipped, an exam platform we built that holds 10M+ requests a minute at peak, which is the kind of load a ledger has to survive on payday.

Nothing on this page claims a fintech credential we cannot show you, and the read is where we show you the rest.

Frequently Asked Questions

What is fintech software development?

Fintech software development is the building of software that holds, moves, lends or reports on money on someone else's behalf. The code is ordinary.

What is different is that a regulator, a bank, a card network and two app stores each hold a veto over whether the product ships, and each one asks the build for evidence rather than a demo.

In practice that means five gates: a licence or a sponsor bank to carry the regulatory liability, a ledger the company owns and reconciles daily, card data kept off the company's own systems, a customer identification program that produces an audit trail, and app store rules that require financial apps to come from a licensed legal entity.

Does my fintech app need a licence?

Only if it holds or moves money. An app that reads account data through a licensed aggregator and shows budgets or analytics does not move money and needs no payments licence.

An app where a licensed payment provider holds the funds end to end and the app never touches card data or balances is a merchant, not a payment institution.

An app that holds customer balances, moves money between people, issues cards or lends is regulated in every market it serves: state money transmission or a sponsor bank in the US, FCA authorisation or registration as a payment or e-money institution in the UK, a Central Bank of the UAE licence under the Retail Payment Services and Card Schemes Regulation in the UAE.

What does a sponsor bank's due-diligence team actually ask a fintech for?

Evidence, not a demo. In the arrangement most fintech apps use, the bank is the regulated institution and the app is its program, so the bank carries the liability and its examiners hold it responsible for what the app does.

After the Synapse collapse in 2024, the US banking agencies said in a joint statement that these arrangements carry operational, compliance, liquidity and concentration risk and risk of misrepresenting deposit insurance, and the FDIC proposed that banks keep records of every end-user depositor and reconcile them at the close of each business day.

So the bank asks for a ledger it can reconcile against its own records, a written customer identification program and the audit trail it produces, proof that card data never touches the app's systems, a penetration test, an incident response plan, and the contracts that give the bank access to the app's records.

A build that passed a demo usually cannot produce the first two.

Can I use Stripe and stay out of PCI DSS scope?

Mostly, if the card form is theirs and not yours.

Under PCI DSS, a merchant that sends the customer to a compliant provider's hosted page, or embeds the provider's iframe, so that card data never passes through the merchant's own systems, qualifies for SAQ A, the shortest self-assessment, which Schellman counts at about 22 requirements.

A merchant whose own page collects the card number with JavaScript or a direct post and then forwards it is SAQ A-EP, which Schellman counts at about 191 requirements covering most of the standard.

Since PCI DSS v4.0, even SAQ A merchants must meet requirements 6.4.3 and 11.6.1 on the scripts that run on the payment page. The card form you wrote yourself is the single most common way a small fintech walks into full scope.

How long does it take to get a fintech app through the bank, the licence and the stores?

It depends on which gate you are stuck at and how much of the evidence already exists. A licence application is measured in months in every market and the clock does not start until the application is complete.

Sponsor bank due diligence runs on the bank's calendar, not yours, and repeats whenever the bank's examiners ask it to. The store gates are the fastest to fix and the most often ignored: enrol as an organisation, hold the licence the store asks for, and submit from the licensed entity.

Geminate Solutions starts every fintech engagement with a written read of the build against all five gates, so the timeline is built from the gate that is actually blocking rather than from a template.