Building a fintech app is ordinary app development with four extra layers on top: a licence or a licensed partner, identity checks on every user, security that assumes someone is trying to steal, and a ledger that has to balance to the last cent. The screens and the backend are built much like any other product. What changes is that you can't move money without permission, you must know who your users are, and every mistake costs real money. This guide covers each of those layers in the order you'll meet them.
What makes fintech different
In a normal app, a bug shows the wrong screen. In a fintech app, a bug can pay someone twice, or not at all. That one fact shapes most decisions: how data is stored, how errors are handled, who can change what, and how much testing is enough. It also means a bank partner, and sometimes a regulator, will look at your product before your users do.
Licensing, or partnering with someone who has a licence
Holding customer money, issuing cards, lending and sending money across borders are regulated activities almost everywhere. The rules differ by country and by activity, but there are broadly two routes.
- Get your own licence. Slow and expensive: capital requirements, compliance staff, audits and months of back and forth with the regulator. It tends to make sense once the business is proven and the volumes justify it.
- Partner with a licensed bank or payment service provider (PSP). The partner holds the licence and the customer funds. You build the product and the customer experience on top of their accounts, cards or payment rails, under a contract that sets out who is responsible for what.
Most new fintech products start with a partner. That choice shapes the technical plan more than founders expect. The partner's APIs decide what your app can do, their onboarding rules become your onboarding rules, and their review process sits inside your launch timeline. Talk to two or three partners before designing anything in detail, and ask for API documentation and sandbox access early. A partner with a clear API and a responsive integration team can save months.
KYC and AML onboarding
Know your customer (KYC) means confirming each user is who they say they are. Anti-money laundering (AML) means watching for activity that looks like fraud or laundering, and reporting it. Your licensed partner will set the minimum, and it usually includes:
- Capturing a government ID and checking that it's genuine.
- A selfie or liveness check matched against the ID photo.
- Screening names against sanctions and politically exposed persons lists.
- Tiered limits, so a user with basic checks can do less than a fully verified one.
- Ongoing monitoring of transactions, with alerts for unusual patterns.
Most teams use a specialist identity verification provider rather than building this themselves. The design problem is keeping onboarding short enough that people finish it. Explain why you need each document, let users save progress and come back later, and show a clear status while a check is pending. A user stuck on "verifying" with no explanation will simply leave.
Security that assumes attack
Fintech apps are targets, so security has to be designed in from the start, not added the week before launch. The basics we expect in any fintech build:
- Encryption in transit (TLS everywhere) and at rest, with keys held in a managed key service, never in the code.
- Two-factor authentication for login and for sensitive actions such as adding a payee or changing a phone number.
- Device binding, so an account is tied to known devices and a new device triggers extra checks.
- Audit logs that record who did what and when, for users and for your own staff. Staff access to customer data should be limited and logged too.
- Session controls such as short timeouts, and detection of rooted or jailbroken phones where the risk justifies it.
Reducing PCI DSS scope with tokenisation
If your app touches card numbers, PCI DSS applies. The simplest way to keep that burden small is never to hold card data at all. Use your PSP's SDK or hosted fields to collect the card, and store only the token they return. The token lets you charge the card again, but it's useless to anyone who steals your database. Our payment gateway integration guide covers the integration methods and what each means for PCI DSS.
Ledgers and reconciliation
This is the part most often underbuilt. A fintech app needs its own ledger: a record of every movement of money that can be checked against the partner's records and the bank statements.
- Use double-entry. Every transaction debits one account and credits another, so the books always balance and errors show up quickly.
- Never edit or delete entries. Corrections are new entries that reverse the old ones. That gives you a full history for auditors and for support.
- Store money as whole numbers in the smallest unit (cents, fils, rupee cents), never as floating-point numbers, and record the currency on every entry.
- Make every money operation idempotent, so a retried request can't move money twice.
- Reconcile daily against the partner's settlement files, and send every difference to a person to look at.
Any balance shown in the app should be calculated from the ledger. If the two are stored separately and can drift apart, sooner or later they will.
Testing with real money
Sandboxes are essential, but they aren't the real world. A partner's test environment may not copy slow settlements, unusual error codes or the exact format of production reports. Plan a controlled live phase:
- Run the full test suite in the partner sandbox, including failures, reversals and duplicate callbacks.
- Go live with internal staff only, using small real amounts, and reconcile every transaction by hand.
- Open to a small group of friendly users with low limits.
- Raise limits and widen access only once reconciliation has been clean for a set period.
Budget for the real money you'll move during testing, and know how you'll return it.
Regulatory sandboxes
Many central banks run programmes that let new financial products be tested with real customers under supervision, often with limits on user numbers or transaction sizes. The Central Bank of Sri Lanka, the Central Bank of the UAE (CBUAE), the Saudi Central Bank (SAMA) and Bank Negara Malaysia all run sandbox or innovation programmes. Entry criteria, timelines and what happens after the sandbox vary and change over time. If your product doesn't fit neatly under an existing licence, read what your regulator offers before you fix a launch plan. This article is a general overview, not legal advice, so check current rules with your bank partner or regulator.
Fintech readiness checklist
| Area | Question to answer before the build |
|---|---|
| Licence | Which licensed partner holds funds, and what does the contract make you responsible for? |
| Onboarding | What level of KYC does each feature or limit need? |
| Card data | Is every card collected by the PSP and stored only as a token? |
| Access | Are 2FA, device binding and audit logs in the first release? |
| Ledger | Is there a double-entry ledger that every balance is calculated from? |
| Reconciliation | Who checks the daily settlement match, and what happens when it doesn't match? |
| Launch | What are the limits and user numbers for the first live phase? |
How long does it take?
The build is often not the slowest part. Partner agreements, compliance reviews and onboarding approvals can take as long as the engineering. A focused first version, such as a wallet or a single payment flow on top of one partner, is usually a matter of months rather than weeks. Our guide to what an app costs explains what drives the size of a build. Starting partner conversations while design is still under way is the best way to shorten the timeline.
Our founder previously led technology at a Sri Lankan payment gateway, so we know these problems from the inside. See how we approach apps and platforms, including payments and fintech, or contact us for a quote.
Questions people ask
How do I choose a bank or PSP partner?
Compare the products they support, the quality of their API and sandbox, their onboarding requirements, how they price, which countries and currencies they cover, and how quickly their integration team responds. Ask to speak to their technical team before you sign.
Can a fintech app be built with Flutter or React Native?
Yes. Cross-platform frameworks work well for most fintech apps. Check that your partner's and identity provider's SDKs support your framework, and use the platform's secure storage for keys and tokens.
Should we build our own ledger or use a ledger service?
Both are valid. A ledger service can be quicker to start with. Building your own gives more control when your money flows are unusual. Either way, follow double-entry rules and never edit past entries.
Do we need a security audit before launch?
It's strongly advised, and many bank partners require a penetration test before going live. Plan it into the timeline, with time to fix what it finds.