DEV Community: Muhammad Zeeshan Farooq

How I Built a KYC System in Flutter — Lessons in Fintech

Muhammad Zeeshan Farooq — Wed, 10 Jun 2026 06:07:09 +0000

Real-world experience building identity verification for banking apps in Pakistan’s fintech ecosystem.

What KYC Actually Involves (The Full Picture)
Most developers think of KYC as:

Capture front of CNIC (National ID)
Capture back of CNIC
Take a selfie
Submit
The reality in a regulated financial app is closer to:

Document capture with quality validation (blur, glare, framing)
OCR extraction to prefill form fields
Liveness detection to prevent spoofing with photos
Face match — comparing selfie to ID card photo
Address verification — utility bills, rental agreements
Biometric consent collection and audit trail
Retry logic with graceful degradation when third-party APIs fail
Offline queuing for unstable networks
Compliance logging — every step timestamped for regulatory audit
Underestimate any of these and you’ll be pushing hotfixes at 2am.

The Architecture That Works
After rebuilding this flow three times across different apps, I landed on a state-machine approach using flutter_bloc. Each KYC step is a discrete state, and transitions are explicit and auditable.

// kyc_state.dart
abstract class KycState extends Equatable {
  const KycState();
}

class KycIdle extends KycState {
  @override
  List<Object?> get props => [];
}

class DocumentCaptureInProgress extends KycState {
  final DocumentSide side;
  final DocumentQualityScore? lastScore;

  const DocumentCaptureInProgress({
    required this.side,
    this.lastScore,
  });

  @override
  List<Object?> get props => [side, lastScore];
}

class DocumentCaptureComplete extends KycState {
  final CapturedDocument front;
  final CapturedDocument back;

  const DocumentCaptureComplete({
    required this.front,
    required this.back,
  });

  @override
  List<Object?> get props => [front, back];
}

class LivenessCheckInProgress extends KycState { ... }
class FaceMatchPending extends KycState { ... }
class KycSubmitting extends KycState { ... }
class KycApproved extends KycState { ... }
class KycFailed extends KycState {
  final KycFailureReason reason;
  final bool isRetryable;
  ...
}

The isRetryable flag on KycFailed is something I wish I'd added from day one. Not all failures are equal — a blurry photo is retryable, but a face mismatch after three attempts needs human review, not another retry.

Document Capture: Where Most Apps Cut Corners
The camera widget seems simple. It isn’t.

The Quality Score Problem
Submitting a blurry or glared image to your OCR/verification vendor costs money per API call — and worse, it fails silently (the vendor accepts the image but returns low-confidence data). You want to reject bad images before they leave the device.

class DocumentQualityAnalyzer {
  static Future<DocumentQualityScore> analyze(Uint8List imageBytes) async {
    final img = await decodeImageFromList(imageBytes);

    final blurScore = await _computeLaplacianVariance(imageBytes);
    final brightnessScore = await _computeBrightness(imageBytes);
    final aspectRatioScore = _checkAspectRatio(
      img.width.toDouble(),
      img.height.toDouble(),
    );

    return DocumentQualityScore(
      blur: blurScore,           // Laplacian variance — higher = sharper
      brightness: brightnessScore, // 0.0 to 1.0
      aspectRatio: aspectRatioScore,
      isAcceptable: blurScore > 80 &&
          brightnessScore > 0.3 &&
          brightnessScore < 0.85 &&
          aspectRatioScore,
    );
  }
}

Liveness Detection: Don’t Roll Your Own
I made the mistake once of building a basic “blink detection” liveness check using the front camera and ML Kit. It worked fine in testing and fooled approximately no one in production — a printed photo with a hole cut out for the eyes passed 40% of the time.

Write on Medium
Use a proper liveness SDK. Options I’ve integrated in Flutter:

iProov — most robust, used by UK banks. Flutter plugin available.
FaceTec — widely used in APAC fintech. Good SDK but heavy.
AWS Rekognition Video — simpler to integrate if you’re already on AWS.
Local options — for clients with strict data residency requirements, look at on-device models via TFLite, but set expectations: they’re weaker against sophisticated spoofing.
The integration pattern is the same regardless of vendor:

class LivenessCheckBloc extends Bloc<LivenessEvent, LivenessState> {
  final LivenessService _service;

  LivenessCheckBloc(this._service) : super(LivenessIdle()) {
    on<StartLiveness>(_onStart);
    on<LivenessSessionComplete>(_onComplete);
  }

  Future<void> _onStart(StartLiveness event, Emitter<LivenessState> emit) async {
    emit(LivenessInProgress());
    try {
      final sessionToken = await _service.createSession();
      emit(LivenessSessionReady(token: sessionToken));
    } catch (e) {
      emit(LivenessFailed(error: e.toString(), isRetryable: true));
    }
  }

  Future<void> _onComplete(
    LivenessSessionComplete event,
    Emitter<LivenessState> emit,
  ) async {
    emit(LivenessVerifying());
    final result = await _service.verifySession(event.sessionId);
    if (result.passed) {
      emit(LivenessApproved(sessionId: event.sessionId));
    } else {
      emit(LivenessFailed(
        error: 'Liveness check failed',
        isRetryable: result.attemptsRemaining > 0,
      ));
    }
  }
}

When the upload is queued, show the user a clear message: “We’ve saved your progress. We’ll submit automatically when your connection improves.” Then use a background service (WorkManager on Android, BGTaskScheduler on iOS) to retry.

Never make the user redo the capture step because of a network failure. That is a UX sin I have witnessed firsthand and it destroys completion rates.

Security Considerations
A KYC flow handles some of the most sensitive personal data your app will ever touch. A few non-negotiables:

Never store raw ID images in app cache unencrypted. Use flutter_secure_storage for tokens and encrypted SQLite (via sqflite_sqlcipher) if you need local persistence of any captured data.
Wipe captured images from memory immediately after upload.

Future<void> _submitAndCleanup(KycPayload payload) async {
  try {
    await _uploadService.uploadDocuments(payload);
  } finally {
    // Wipe regardless of success or failure
    payload.dispose(); // Zero out byte arrays
    await _tempFileManager.clearKycTemp();
  }
}

Certificate pinning for your KYC API endpoint. Use dio_certificate_pinning or a custom HttpClient. A KYC endpoint that can be MITMed is a regulatory nightmare.
Screenshot prevention during the flow.

// In your KYC screen's initState
SystemChrome.setPreferredOrientations([DeviceOrientation.portraitUp]);
// For Android: use FLAG_SECURE via platform channel
// For iOS: it's handled at the OS level, but add a blur overlay for app switcher
The Compliance Audit Trail
Every regulator I’ve encountered in Pakistan’s fintech space (SBP, SECP) wants an audit trail. Every step, every retry, every failure — timestamped and associated with the user session.

class KycAuditLogger {
  Future<void> log(KycAuditEvent event) async {
    await _auditRepository.insert(
      KycAuditEntry(
        userId: event.userId,
        sessionId: event.sessionId,
        step: event.step.name,
        outcome: event.outcome.name,
        metadata: event.metadata,
        deviceInfo: await _deviceInfoService.getDeviceSnapshot(),
        timestamp: DateTime.now().toUtc(),
      ),
    );
  }
}

Log everything on the client side too (not just server-side), because network failures mean some events may never reach the server. When a user calls support claiming “the app ate my KYC,” your client-side logs are gold.

Completion Rates: The Metric Nobody Talks About
KYC flows have notoriously low completion rates in the industry. From my experience across 4 fintech apps in Pakistan:

Average drop-off is 35–50% if you just stack all the steps sequentially
Showing a progress indicator (Step 2 of 4) reduces drop-off by ~15%
Letting users save and resume a partially complete KYC reduced total abandonment by ~22% in one app I worked on
In-app guidance (short animated tutorials before each capture step) reduces retry rate significantly
The technical work means nothing if users don’t complete the flow.

What I’d Do Differently
If I were starting a new KYC integration today:

Use a hosted KYC solution (Shufti Pro, Jumio, Sum&Substance) for the heavy lifting — OCR, liveness, face match — and build only the capture UI yourself. The API cost is almost always cheaper than the engineering cost.
Design the state machine before writing a single widget. The KYC flow has more states than you think.
Add analytics from day one — funnel tracking on every step, not just the final submission.
Test on low-end Android devices. The front camera on a ~$80 Android phone in the Pakistani market produces very different image quality than your development device.
KYC is one of those features that looks boring from the outside and is genuinely interesting once you’re deep in it — it sits at the intersection of computer vision, security, UX psychology, and regulatory compliance. Get it right and you’re shipping trust. Get it wrong and you’re fielding compliance audit findings.

If you’re building something similar or have questions about any of the patterns above, drop a comment — happy to go deeper on any section

React State Management: Stop Over-Rendering Your Components!

Muhammad Zeeshan Farooq — Mon, 08 Jun 2026 07:36:12 +0000

In the React ecosystem, one of the most common pitfalls developers encounter is the excessive and unnecessary use of useState. As React developers, we often fall into the trap of treating state as the default solution for every piece of data, leading to performance bottlenecks and difficult-to-debug codebases.

In this article, we will explore how state truly works and how adopting a modular approach can lead to cleaner, more maintainable code.

Understanding State Updates: The Performance Cost In React, every time a state variable updates, the component re-renders. If you are updating state unnecessarily—or placing state at too high a level in your component tree—you trigger a cascade of re-renders that can significantly degrade your application’s performance.

The Golden Rule: If a value is not needed to drive the UI, do not place it in useState. Use useRef or simple variables for internal logic that doesn't require a re-render.

Clean Architecture: The Power of Component Decomposition The days of monolithic, 500-line components are over. The secret to a clean codebase is effective component decomposition. By breaking your UI into smaller, purpose-driven components, you gain several advantages:

Simplified Debugging: When an issue arises, you can instantly isolate the problematic child component rather than hunting through a massive file.

Enhanced Reusability: Modular components can be easily abstracted and reused across different parts of your application.

Example: A Scalable Pattern
Instead of housing all logic in a single component, separate your concerns:

Debugging Simplified When you manage state with intention and prioritize component modularity, debugging becomes a structured process rather than a guessing game:

Leverage React DevTools: Use it to profile your application and identify which specific components are triggering re-renders.

Optimize useEffect: Always maintain precise dependency arrays to prevent infinite loops and unintended side effects.

Lift State Judiciously: Only "lift state up" when absolutely necessary. Keep state as close to the point of consumption as possible.

Conclusion
React development is not just about updating state; it is about architectural mastery. By being selective with your state and modular with your components, you build applications that are not only performant but also a joy to maintain and scale.

React State Management: When to Use What (A Simple Guide)

Muhammad Zeeshan Farooq — Thu, 04 Jun 2026 06:14:42 +0000

We’ve all been there. You start a new React project, everything is simple and clean. But a few hours later, you find yourself "prop-drilling"—passing data through five layers of components just to get it to a button that needs it.

You start wondering: Should I use Context? Redux? Zustand?

The problem isn't that there are no solutions; it’s that there are too many. Let’s strip away the technical jargon and use a simple analogy to clear the fog.

The Three Ways to Manage Your Data
Think of your React app like a House. Where you store your things depends on who needs to use them.

useState: Your Pocket useState is like your pocket. It’s meant for small, personal things you need right now (like your keys or phone).

Best for: Local data. If only one component needs to know if a dropdown is open or if an input field is changing, keep it in your "pocket."

The Rule: Keep it local whenever possible.

Context API: The Family Fridge Context is like the family fridge. It’s in a central place, and anyone in the house can walk up and grab a snack (data) without asking for permission every time.

Best for: Data that many parts of your app need, but rarely changes.

Examples: User login status, theme settings (dark/light mode), or language preferences.

The Rule: Use it for "global" things that don't change every single second.

Zustand: The Professional Storage Unit Zustand is like renting a professional storage unit. It’s clean, organized, and specifically designed for when you have a lot of stuff.

Best for: Complex data that changes frequently and needs to be accessed anywhere in the app (like a shopping cart or a complex dashboard).

The Rule: Use it when your app starts feeling "heavy" or messy.

The "When Should I Switch?" Cheat Sheet
Don't overthink it. Follow this simple logic:

Final Thoughts: Stop Over-Engineering
The biggest mistake developers make is reaching for a complex library before they actually need it.

My advice: Start with useState. When you feel the pain of passing props through too many layers, move that specific data to Context. If the data becomes complex or the performance starts to lag, that is the perfect time to bring in Zustand.

Keep it simple, keep it clean, and happy coding!

The Hidden Danger in React Server Actions: How to Prevent Accidental Data Leaks

Muhammad Zeeshan Farooq — Mon, 01 Jun 2026 06:24:30 +0000

With Great Power Comes Great Responsibility. Here is how to secure your backend logic when using React's newest server features.

React's newest architectural shift—Server Components and Server Actions—has completely changed how we build full-stack web applications. Being able to database query directly inside your component or invoke a server-side function with a simple action={formAction} feels like magic.

But this magic brings a serious architectural risk: Data Leakage and Security Vulnerability.

In traditional architectures, your Node.js API acts as a hard boundary. If you don't explicitly send a database column to the client, the client never sees it. With React Server Actions, that boundary becomes blurry, and it is incredibly easy to accidentally expose sensitive data or run unsecured code.

Let’s look at the major issue and how to resolve it properly.

The Issue: Accidental Over-fetching and Poisoned Payloads
Imagine you have a Server Action to update user profile information. A developer might write something like this:

// actions.js (Server Action)
'use server'

import { db } from '@/lib/db';

export async function updateUserProfile(formData) {
const userId = formData.get('id');
const rawData = {
name: formData.get('name'),
email: formData.get('email'),
};

// ISSUE: Directly updating using raw input without strict validation
await db.user.update({
where: { id: userId },
data: rawData
});
}

Why is this dangerous?
Parameter Injection: A malicious user can intercept the request or modify the hidden form fields to pass extra parameters (like role: "admin" or balance: 99999). If your server-side database logic spreads or directly accepts the object, you've just given them admin rights.

Missing Token/Session Verification: Because Server Actions look like regular JavaScript functions, it's easy to forget to check if the incoming session actually has permission to modify that specific resource ID.

🛠️ The Resolution: Strict Input Validation and Context Binding
To fix this structural issue, we need to apply production-grade software engineering principles: Strict Input Validation and Server-Side Context Verification.

Step 1: Enforce Schemas using Zod
Never trust formData.get() values directly. Wrap them in a strict schema validator.
// actions.js
'use server'

import { z } from 'zod';
import { db } from '@/lib/db';
import { verifyAuth } from '@/lib/auth'; // Your session handler

// Enforce strict length and types
const ProfileSchema = z.object({
name: z.string().min(2).max(50),
email: z.string().email(),
});

export async function updateUserProfile(formData) {
// 1. Authenticate the user securely on the server
const session = await verifyAuth();
if (!session) throw new Error("Unauthorized access");

// 2. Safely parse incoming data
const validatedFields = ProfileSchema.safeParse({
name: formData.get('name'),
email: formData.get('email'),
});

if (!validatedFields.success) {
return { error: "Invalid form input data" };
}

// 3. Update using securely bound session ID, NOT client-supplied ID
await db.user.update({
where: { id: session.userId }, // Secure
data: validatedFields.data, // Cleaned
});

return { success: true };
}

Key Takeaways for Production React Apps
If you want to use React's server-driven features safely, memorize these three rules:

Treat Server Actions like Public APIs: Just because you didn't write an explicit fetch('/api/user') endpoint doesn't mean it isn't one. Under the hood, React creates an HTTP POST endpoint for every server action.

Never Pass Sensitive Objects as Props: If your server component passes a full user object (including password hashes or internal IDs) down to a Client Component, that data is serialized into the HTML document stream and can be inspected by anyone.

Validate the Payload Size: Always enforce maximum string lengths on your inputs to avoid buffer or memory calculation hangs during high concurrent server loads.

Digital Cheque Books — How QR Codes Can Replace Physical Cheques in Banking

Muhammad Zeeshan Farooq — Fri, 22 May 2026 10:55:30 +0000

The Problem
Fraud — cheques can be forged or altered
Delays — issuance takes 3-7 days
Cost — printing and courier add operational expense
No real-time validation — bounced cheques discovered too late

The Solution — Dynamic QR Cheques
Each cheque = a unique encrypted QR code, generated on demand from your phone.

User requests cheque in app
↓
Biometric authentication
↓
Bank server generates encrypted QR
↓
User shows QR to payee
↓
Payee scans → Bank validates → Payment processed
↓
QR invalidated — cannot be reused

Example

QR Payload
{
"cheque_id": "CHQ-2026-UUID-7a3f9c",
"payee_name": "Ali Hassan",
"amount": 50000,
"currency": "PKR",
"expiry_date": "2026-06-21",
"signature": "RSA_SIGNED_HASH",
"one_time_token": "OTT-9f2a1b3c"
}

6 Layers of Fraud Prevention

Biometric issuance — stolen phone cannot generate cheques
RSA server signature — tampered QR instantly detected
One-time token — scan once, invalidated forever
Time expiry — auto-reject after 30 days
Device binding — new device requires re-authentication
Real-time balance check — no more bounced cheque

Conclusion
The technology exists today — Flutter, QR codes, biometrics, real-time APIs. Pakistani banks that implement this will see reduced fraud, lower costs, and better customer experience.
The era of the paper cheque book is ready to end.

Muhammad Zeeshan Farooq — Software Engineer | Fintech | Flutter
linkedin.com/in/zeeshanfarooq | zeeshan-dev.web.app

How I Built Real-Time Banking APIs with 99.9% Uptime

Muhammad Zeeshan Farooq — Fri, 22 May 2026 07:28:57 +0000

Building real-time banking APIs is not just about writing code — it's about building trust. In fintech, a single failed transaction can cost a customer forever.
After 11 years of building production banking applications, here are my key lessons.

The Stack That Works
Node.js + Express — Backend
WebSockets — Real-time updates
GraphQL — Flexible data fetching
MongoDB — Transaction storage

Always Use Circuit Breakers Banking APIs fail. Third-party services go down. Circuit breakers prevent cascading failures. const circuitBreaker = async (apiCall) => { try { return await apiCall(); } catch (error) { console.error('Circuit broken:', error); return fallbackResponse(); } };
WebSockets for Real-Time Updates
Polling kills performance. WebSockets give instant transaction updates.
io.on('connection', (socket) => {
socket.on('transaction', async (data) => {
const result = await processTransaction(data);
socket.emit('transaction-status', result);
});
});
Never Trust Input — Validate Everything
const validateTransaction = (data) => {
if (!data.amount || data.amount <= 0) {
throw new Error('Invalid amount');
}
if (!data.accountId) {
throw new Error('Account ID required');
}
};

Results
Following these patterns helped us achieve:

✅ 99.9% API uptime
✅ 40% faster transaction processing
✅ Zero security breaches in production

Final Thought
In banking, reliability is everything. Your API is not just code — it is someone's money.

Building Secure KYC Systems in Flutter — Lessons from Production Banking Apps

Muhammad Zeeshan Farooq — Thu, 21 May 2026 07:24:58 +0000

**What is KYC and Why Does it Matter?
**KYC is a mandatory regulatory process that financial institutions use to verify the identity of their customers. In digital banking, this means:

Verifying government-issued identity documents (NIC, Passport)
Biometric face matching
Liveness detection to prevent spoofing
Real-time database checks against government records

A poorly implemented KYC system can lead to regulatory fines, fraud, and data breaches. Getting it right is critical.
The Core Architecture
After building KYC systems for multiple banking apps, I settled on a Clean Architecture approach that separates concerns clearly:
Presentation Layer → Bloc/Riverpod
Domain Layer → Use Cases + Entities
Data Layer → Repositories + Remote/Local Sources
This separation means:

KYC business logic stays independent of UI
Easy to swap SDKs without touching business logic
Testable in isolation — critical for regulated environments

Key Component 1 — NIC Scanning

abstract class NicScanRepository {
Future> scanNic();
}

class NicScanRepositoryImpl implements NicScanRepository {
final NicScanDataSource dataSource;

NicScanRepositoryImpl({required this.dataSource});

@override
Future> scanNic() async {
try {
final result = await dataSource.initiateScan();
return Right(result.toDomain());
} on ScanException catch (e) {
return Left(ScanFailure(message: e.message));
}
}
}

Key Component 2 — Biometric Authentication with IdWise SDK
class BiometricKycDataSource {
Future initiateKyc({
required String journeyDefinitionId,
required String referenceNumber,
}) {
final completer = Completer();

IdWise.initialize(
  clientKey: AppConfig.idWiseClientKey,
  environment: IdWiseEnvironment.production,
);

IdWise.startJourney(
  journeyDefinitionId: journeyDefinitionId,
  referenceNumber: referenceNumber,
  locale: 'en',
  delegate: _KycDelegate(completer),
);

return completer.future;

}
}

class _KycDelegate implements IdWiseSDKDelegate {
final Completer completer;
_KycDelegate(this.completer);

@override
void onJourneyCompleted(String journeyId, bool isCompleted) {
completer.complete(KycResult(
journeyId: journeyId,
status: isCompleted ? KycStatus.completed : KycStatus.failed,
));
}

@override
void onJourneyResumed(String journeyId) {}

@override
void onError(IdWiseError error) {
completer.completeError(KycException(message: error.message));
}
}

Key Component 3 — State Management for KYC Flow
enum KycStep { idle, scanning, biometric, verifying, completed, failed }

@riverpod
class KycNotifier extends _$KycNotifier {
@override
KycState build() => const KycState(step: KycStep.idle);

Future startNicScan() async {
state = state.copyWith(step: KycStep.scanning);

final result = await ref.read(nicScanRepositoryProvider).scanNic();

result.fold(
  (failure) => state = state.copyWith(
    step: KycStep.failed,
    errorMessage: failure.message,
  ),
  (nicData) => state = state.copyWith(
    step: KycStep.biometric,
    nicData: nicData,
  ),
);

}

Future startBiometric() async {
state = state.copyWith(step: KycStep.verifying);

final result = await ref.read(biometricKycRepositoryProvider)
    .initiateKyc(referenceNumber: state.nicData!.nicNumber);

result.fold(
  (failure) => state = state.copyWith(
    step: KycStep.failed,
    errorMessage: failure.message,
  ),
  (kycResult) => state = state.copyWith(
    step: KycStep.completed,
    kycResult: kycResult,
  ),
);

}
}

Lessons Learned
After building KYC for multiple production banking apps, here is what I wish I had known earlier:

Abstract your SDK dependencies early — KYC SDK providers change, merge, and update APIs frequently
Test on real low-end devices — camera performance varies dramatically across the Android ecosystem
Handle network failures gracefully — KYC mid-flow network drops are common; build resumable journeys
Log anonymously — never log NIC numbers or biometric data, even in development
Design for accessibility — banking apps serve all demographics; KYC flows must work for elderly users too

Conclusion
Building secure KYC systems in Flutter for production banking applications requires a combination of clean architecture, robust state management, and security-first thinking. The patterns described here have been battle-tested across multiple live digital banking applications serving real users in regulated financial environments.
If you are building a fintech app and have questions about KYC implementation, feel free to connect — I am always happy to discuss secure mobile architecture.