Fintech is the one category where founders still ask us whether cross platform is a real option. The worry is reasonable. A lending app carries identity documents, bank credentials and money movement, and nobody wants to discover a framework limitation during a security review.
We have now shipped lending, crypto, auction and point of sale products on Flutter, including an ONDC based personal loan app and a crypto to Naira exchange with full identity verification. This is what we have learned about where Flutter genuinely helps, where it is neutral, and where it will not save you.
- Flutter removes duplicated product logic, not duplicated compliance work. Budget for both platforms in your audit timeline.
- The framework is security neutral. Your protection comes from platform keystores, certificate pinning and a hardened backend, not from Dart.
- Model a loan application as an explicit server owned state machine. The client should render state, never decide it.
- Keep documents, tokens and rate data off the widget tree and out of any logging path.
- Reach for native when you need deep hardware access such as NFC card reads, or a vendor SDK that ships iOS and Android only.
Section 01
Why fintech teams keep landing on Flutter
The pitch for cross platform is usually framed as cost. In regulated products the more valuable win is consistency. A loan application has branching rules, eligibility checks, interest calculations and disclosure copy that must be identical everywhere. Every time that logic is written twice, in Swift and in Kotlin, you create a chance for the two to drift.
Drift in a photo gallery app is a cosmetic bug. Drift in an amortisation schedule is a regulatory finding. Flutter lets the rules live in one Dart layer that both platforms execute, which means one test suite proves the behaviour rather than two suites proving it separately and hoping they agree.
- One implementation of eligibility, tenure and interest logic, verified by one set of unit tests.
- Disclosure and consent copy that cannot fall out of sync between platforms.
- A single release train, so a rate change or a compliance fix does not sit waiting on the slower platform.
- Pixel level control over forms and statements, which matters when a layout has to match a mandated document format.
Section 02
One codebase, two compliance surfaces
Here is the caveat that gets skipped in most Flutter marketing. Sharing code does not mean sharing an audit. You still ship two binaries into two app stores, running on two operating systems with different keychain semantics, different biometric prompts and different background execution rules.
A penetration tester will attack the iOS build and the Android build separately, because the attack surface genuinely differs. Android gives you a rooted device problem and a far easier repackaging story. iOS gives you a stricter sandbox but a keychain whose items can survive an app uninstall if you configure them carelessly.
Section 03
What Flutter gives you on security, and what it does not
Flutter is security neutral. It does not make your app safer than a native build and it does not make it weaker. What it does is give you one place to enforce the decisions, so a rule cannot be applied on one platform and forgotten on the other.
Storage
Nothing sensitive belongs in shared preferences. Tokens, refresh credentials and any cached identity data go into the platform backed secure store, which resolves to the iOS Keychain and to Android EncryptedSharedPreferences on top of the hardware keystore.
final _storage = const FlutterSecureStorage(
aOptions: AndroidOptions(encryptedSharedPreferences: true),
iOptions: IOSOptions(
// Keychain items outlive an uninstall by default. Scope them to this
// device and unlock state so a reinstall starts from a clean session.
accessibility: KeychainAccessibility.first_unlock_this_device,
),
);
Future<void> persistSession(String refreshToken) =>
_storage.write(key: 'refresh_token', value: refreshToken);Transport
Certificate pinning is table stakes for a lending app, and it is one of the places the single codebase pays off directly. You configure the trusted certificate once against your HTTP client and both platforms inherit it, instead of maintaining an ATS exception list and a network security config that slowly disagree.
Runtime integrity
Root and jailbreak detection, screenshot suppression on statement and document screens, and a check that the app has not been repackaged are all worth adding. Treat every one of them as a signal you report to the backend, not as a client side gate. Anything the client decides alone can be patched out of the binary by anyone who cares enough.
The client is a rendering surface for decisions the server has already made. If a screen can approve, price or disburse anything on its own, that is the vulnerability, whatever framework drew it.
Section 04
Model the loan application as state, not as screens
The most common architectural mistake we see in lending apps is treating the application as a sequence of pages. It works until the product team adds a lender who wants an extra income check, or a rejection that can be appealed, or an offer that expires while the user is mid flow. Then the navigation stack becomes the source of truth and it cannot answer basic questions about where an application actually is.
Give the application an explicit status that the server owns, and let the client route from it. On the Hindustan loan app this mattered a great deal, because one guided application fans out across several lender partners on the ONDC network and each of them can respond at its own pace.
- Draft: the borrower is still filling in details and nothing has been submitted anywhere.
- Consent captured: Account Aggregator consent is granted, so financial data can be pulled without manual document uploads.
- Search dispatched: offers have been requested from lender partners and responses are arriving asynchronously.
- Offers presented: the borrower compares live offers, each with its own expiry.
- Selected and confirmed: one offer is locked, and from here the flow is irreversible without a formal cancellation.
- Disbursed or declined: a terminal state with a reason code the app can explain in plain language.
With that in place, resuming an abandoned application becomes trivial. The app fetches the status and routes to the right step, whether the borrower comes back in ten minutes or ten days, on a new phone, or after switching platforms entirely.
Section 05
KYC, identity and document capture
Identity verification is where teams expect Flutter to fall down, and mostly it does not. The major vendors ship Flutter plugins or a well documented native bridge. On the QuickChain build we ran Veriff through the app for identity checks before any payout could be released, and the integration work was a bounded task rather than an open ended risk.
The harder problems are ones every platform shares. Document photographs taken in bad light get rejected downstream, and a rejection that arrives hours later is expensive because the user has already left.
- Validate capture on the device. Check focus, glare and edge detection before upload, and tell the user immediately if the shot will fail.
- Compress deliberately. Verification vendors have resolution floors, and an over aggressive compression setting will quietly raise your rejection rate.
- Upload in the background with resumable chunks. Users on unreliable mobile data should not have to restart a document upload.
- Never write captured documents to the gallery or to any path other app can read, and clear the temporary file as soon as the upload is acknowledged.
- Keep document bytes out of your logging and crash reporting pipeline. Redact at the source, not in the dashboard.
Section 06
Payments, payouts and the money path
Wherever money moves, the client initiates and the server decides. That principle sounds obvious and is violated constantly, usually by an app that computes a final amount locally and posts it to an endpoint that trusts the number.
Two patterns have saved us the most grief across payment work on Stripe, on verified bank payouts and on point of sale checkout.
Idempotency on every write
Mobile networks retry. Users tap twice. If the same request can create two disbursements you have a real financial incident, not a bug. Generate an idempotency key on the client, attach it to the request, and have the server return the original result for any repeat.
Server confirmed terminal states
Never show a success screen because a network call returned 200. Show it when the backend confirms the transaction reached a terminal state, ideally via a webhook that the app polls or subscribes to. The gap between an accepted request and a settled payment is where support tickets are born.
Section 07
Performance, offline behaviour and audit trails
Fintech apps are not usually graphically demanding, so raw rendering performance is rarely the constraint. Two other things are.
The first is cold start. A user opening a lending app to check an offer expiry is impatient in a way a casual app user is not. Defer non essential initialisation, avoid blocking the first frame on a remote config fetch, and measure on the cheapest Android device in your target market rather than on a recent flagship.
The second is offline honesty. A banking or lending app should never present cached financial data as though it were live. Either label it clearly with the time it was fetched, or do not show it. Ambiguity here is a compliance problem as much as a usability one.
On audit, log the events a regulator or a dispute will ask about: consent granted and withdrawn, offer viewed, offer selected, terms accepted, document submitted. Log them server side. Client side analytics can be dropped, replayed or blocked, so it is evidence of user behaviour, not evidence of what the system did.
Section 08
When Flutter is the wrong call
We would rather tell a client this before a contract than during one. There are fintech products where Flutter is a poor fit.
- Deep hardware work such as NFC contactless card reads, secure element access, or certified tap to pay. These are native problems and the plugin layer is thin.
- A mandated vendor SDK that ships native only, with no maintained bridge and a contract that will not let you wrap it yourself.
- A team with deep native expertise and no Dart experience, on a short regulated timeline. Framework migration and compliance pressure are a bad combination.
- Products where the app is a thin wrapper around an existing well built web experience. A web view or a progressive web app may be the honest answer.
Outside those cases, the framework has not been the limiting factor on any regulated build we have delivered. Backend design, vendor integration timelines and compliance review have been.
Section 09
A pre launch checklist
Run this before a security review rather than after one. Everything on it has cost somebody a week at some point.
- No secrets, keys or endpoints hardcoded in the Dart source or in the compiled asset bundle.
- Certificate pinning active, with a documented rotation plan so an expiring certificate does not brick every installed app.
- All tokens and identity data in the platform secure store, with keychain accessibility scoped correctly.
- Obfuscation and split debug info enabled on release builds, and the symbol files archived somewhere you can actually find them.
- Screenshot and screen recording suppressed on statement, document and credential screens.
- Root, jailbreak and repackaging signals reported to the backend and acted on there.
- Crash reporting and analytics scrubbed of personally identifiable and financial data at the point of capture.
- Session timeout and biometric re authentication verified on both platforms, including after the app is backgrounded.
- Every money moving endpoint idempotent and covered by a duplicate submission test.
- Cold start measured on a low end Android device, not on a simulator.
Frequently asked questions
Is a Flutter app secure enough for a regulated financial product?
Yes, provided the security work is done at the platform and backend layers. Flutter neither adds nor removes protection on its own. Apps built with it pass the same penetration tests and compliance reviews as native builds when tokens are held in the platform keystore, transport is pinned, and no financial decision is made on the device.
How much development time does Flutter actually save on a fintech build?
In our experience the saving lands on product and business logic, which is often 50 to 60 percent of the client work, rather than on the whole project. Compliance, vendor integration, platform hardening and store review are largely unchanged, so a realistic expectation is a meaningfully shorter build rather than a halved one.
Can Flutter handle KYC and identity verification vendors?
Most major providers ship a Flutter plugin or a documented native bridge, and we have run full identity verification flows through Flutter apps in production. Confirm plugin support and its maintenance status during vendor selection, because that is far cheaper than discovering a gap mid build.
What about NFC payments and tap to pay?
This is the clearest limitation. Contactless card reads, secure element access and certified tap to pay are native concerns with a thin plugin layer. If they are core to your product, plan for native modules alongside the Flutter app or reconsider the approach.
