iBind KYC.
A config-driven KYC engine: 6+ countries, no country-specific code.
- My contribution
- I designed the config-driven Flutter routing engine and built native Kotlin modules for document capture and biometric verification.
- The constraint
- Different compliance rules, document flows and biometric SDKs in every market.
- The decision
- A config-driven Flutter routing engine, with Kotlin modules connecting native verification SDKs.
CONFIGURATION OVER DUPLICATIONrouting : "schema-driven"
markets : 6+
native_bridge : "Kotlin"captureNative
biometricsIdentity
verification
DELIVERY & ENGINEERING OUTCOMES
What I took ownership of.
iBind Systems builds onboarding and KYC authentication for enterprise banking clients including Emirates and HDFC — 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 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.
- Country-specific KYC logic hardcoded into the verification flows
- Document capture and biometrics only available as native Android SDKs
- 6+ countries, each with its own regulator and its own document rules
- Audit-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.
Read all 5 decisions together
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.
- Config-driven KYC routing engine covering 6+ countries on one JSON schema
- 3+ native Android Kotlin modules (MVVM, Coroutines, Jetpack) bridged via MethodChannels/EventChannels
- 85% unit and 60% widget test coverage across CIP and DCID
- 97% first-attempt success on document verification
- 100% of regulatory compliance requirements met across all markets
The work, measured.
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.
Countries supported
Each with its own document rules and compliance requirements, served through configurable REST APIs without a client release.
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.
First-attempt success
Document verification completed without retry, via the native Kotlin capture and biometric modules.
| 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 |
Built with purpose.
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.”
Android, Kotlin & Flutter · Bengaluru & remote teams.
Send the role and a little about your team. I’ll take it from there.