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

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.
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
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.
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.
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.
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.
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.
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.
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
The numbers, after the dust settled.
The routing engine reads a country's workflow from a unified JSON schema, so adding a market is configuration rather than feature work.
Each with its own document rules and compliance requirements, served through configurable REST APIs without a client release.
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.
Document verification completed without retry, via the native Kotlin capture and biometric modules.
What changed, measured.
| Metric | Before | After |
|---|---|---|
| Adding a new country | Hardcoded country-specific logic edited inside the verification flows | Config authored against a unified JSON schema — ~70% less onboarding effort, 6+ countries live |
| Unit test coverage | Below the 70% audit threshold | 85% unit and 60% widget, satisfying enterprise audit requirements |
| Document verification first-attempt success | Multi-retry capture flow, frequent user drop-off | 97% completed on the first attempt |
What it's built with.
- Flutter
- Dart
- BLoC
- AutoRoute
- Retrofit
- Kotlin
- Jetpack
- Coroutines
- MVVM
- MethodChannels
- EventChannels
- Clean Architecture
- Config-Driven Routing
- REST APIs
- Unit Tests
- Widget Tests
- Integration Tests
From the blog.
Why Every Full Stack Developer Needs TypeScript in 2026
A comprehensive guide to TypeScript in 2026 covering its evolution, essential patterns, benefits for full stack development, and why it has become the standard for modern web and mobile projects.
Building SaaS Dashboards with React and Next.js: A Complete Guide
A comprehensive guide to building production-grade SaaS dashboards with React and Next.js, covering architecture, authentication, real-time updates, data visualization, role-based access, multi-tenancy, and deployment strategies.
“Yashraj is highly motivated and proactive, readily embraces challenges and consistently contributes to the team's overall success.
This is the kind of Flutter and full-stack work I do day to day. The résumé has the rest.
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.