Skip to content
yashraj.
[ Case study · 02 of 03 · FinTech · Enterprise KYC ]

iBind KYC 

A config-driven KYC engine: 6+ countries, no country-specific code.

Client
iBind Systems
Role
Software Engineer I (SDE-1)
Year
Dec 2022 — Jun 2024
Duration
1.5 years
Share
iBind KYC
FinTech · Enterprise KYCDec 2022 — Jun 2024
[ Overview ]

The brief, in a paragraph.

iBind Systems builds KYC authentication for enterprise financial-services customers — the CIP and DCID applications. Identity verification differs by country: which documents count, in what order, verified by which vendor SDK, under which regulator. Written naively, that becomes a per-country branch in every flow. I designed a config-driven routing engine that turned country rules into data, built the native Android modules bridging Flutter to the KYC SDKs, and owned the Flutter architecture and its test contract.

6+
Countries supported
−70%
New-country onboarding effort
85%
Unit test coverage
97%
First-attempt verification
[ 01 · Problem ]

Every project has a story before it has a solution. Here's the part nobody writes on the case-study cover.

Every new country was a new code path.

Country-specific verification logic was hardcoded, so supporting another market meant editing the flows themselves — new branches, new regressions, new audit surface. On top of that, the actual document capture and biometrics live in vendor SDKs that are native Android, not Flutter. And because this is regulated software, none of it counts unless it's testable and defensible under compliance review.

  • 01Country-specific KYC logic hardcoded into the verification flows
  • 02Document capture and biometrics only available as native Android SDKs
  • 036+ countries, each with its own regulator and its own document rules
  • 04Audit-mandated test coverage thresholds on a mobile codebase
[ 02 · Approach ]

Make the country a config file, not a code path.

The core move was a unified JSON schema describing a country's KYC workflow — required documents, step order, which SDK verifies what — and a routing engine that reads it. Countries became data. Everything else followed from that: the native Kotlin modules exist to make vendor SDKs addressable from that engine, the REST APIs exist to serve the config, and Clean Architecture exists so the routing rules are testable as pure Dart.

/01

Config-driven routing engine on a unified JSON schema

One schema expresses any country's workflow; the engine interprets it at runtime. Eliminated hardcoded country-specific logic and cut new-country onboarding effort by ~70% — adding a market became authoring config, not editing flows.

/02

Native Kotlin modules over the KYC SDKs

Built 3+ Android modules in Kotlin (MVVM, Coroutines, Jetpack) wrapping multiple vendor KYC SDKs for secure document capture and biometric verification, exposed to Flutter through MethodChannels for request/response and EventChannels for the streaming capture state. Vendor differences stopped at the module boundary.

/03

Clean Architecture with BLoC, AutoRoute, Retrofit

Presentation, domain, and data kept separate so the routing rules and verification logic live in pure Dart — testable without a Flutter binding or a device.

/04

Tests as audit evidence

85% unit and 60% widget coverage, held as a contract rather than a target. Regressions and hotfixes in production dropped significantly, and the coverage doubled as the evidence pack for compliance review.

/05

Configurable REST APIs, co-designed with backend

The workflow config had to be served, versioned, and varied per country without a client release. Co-designed the APIs so identity verification stayed configurable across all 6+ country workflows and their differing compliance requirements.

[ 03 · Solution ]

Two apps, one engine, countries as data.

CIP and DCID both run on the same routing engine and the same native capture modules. A new market is a config change served over the API; a new vendor SDK is a new Kotlin module behind an existing channel contract.

  • 01Config-driven KYC routing engine covering 6+ countries on one JSON schema
  • 023+ native Android Kotlin modules (MVVM, Coroutines, Jetpack) bridged via MethodChannels/EventChannels
  • 0385% unit and 60% widget test coverage across CIP and DCID
  • 0497% first-attempt success on document verification
  • 05100% of regulatory compliance requirements met across all markets
01Document capture
02Selfie verification
03Status flow
[ 04 · Results ]

The numbers, after the dust settled.

−70%
New-country onboarding effort

The routing engine reads a country's workflow from a unified JSON schema, so adding a market is configuration rather than feature work.

6+
Countries supported

Each with its own document rules and compliance requirements, served through configurable REST APIs without a client release.

85%
Unit test coverage

Unit coverage cleared the 70% threshold enterprise audit required, with widget coverage at 60% on top of it. Together they cut production regressions and hotfixes sharply.

97%
First-attempt success

Document verification completed without retry, via the native Kotlin capture and biometric modules.

[ 05 · Before vs after ]

What changed, measured.

MetricBeforeAfter
Adding a new countryHardcoded country-specific logic edited inside the verification flowsConfig authored against a unified JSON schema — ~70% less onboarding effort, 6+ countries live
Unit test coverageBelow the 70% audit threshold85% unit and 60% widget, satisfying enterprise audit requirements
Document verification first-attempt successMulti-retry capture flow, frequent user drop-off97% completed on the first attempt
[ 06 · Stack ]

What it's built with.

Mobile
  • Flutter
  • Dart
  • BLoC
  • AutoRoute
  • Retrofit
Native
  • Kotlin
  • Jetpack
  • Coroutines
  • MVVM
  • MethodChannels
  • EventChannels
Architecture
  • Clean Architecture
  • Config-Driven Routing
  • REST APIs
Quality
  • Unit Tests
  • Widget Tests
  • Integration Tests

Yashraj is highly motivated and proactive, readily embraces challenges and consistently contributes to the team's overall success.

Ravi Raja Jangid
SDE-II · Mobile Lead · iBind Systems
[ Work like this? ]

This is the kind of Flutter and full-stack work I do day to day. The résumé has the rest.

[ Interested in working together? ]

Building a team that needs this?

I'm open to full-time engineering roles. Start with the résumé, then reach out — I reply within a day.