Retail Credit · 3 Variants
KVB Credit Cards
A 108-year-old bank. Three new credit card variants. 9,608 active cards, ₹54.9 Cr+ in monthly transactions. One designer.
Overview
Karur Vysya Bank was founded in 1916. In 2025, it moved its credit card programme from Worldline to Falcon, migrating live cardholders to new infrastructure without a single disruption. I designed the flows for the existing Signature card. In May 2026, KVB goes full Falcon: all three variants live, Infinite (Eternis, Altura), Signature (Samara), and Platinum (Aura). Banks were taking 18 months to launch a card before Falcon existed. KVB did it in 12 weeks.
The problem
A 108-year-old bank carries weight that a fintech startup doesn't. The product had to feel modern enough to compete with new-age issuers, and grounded enough that a 60-year-old KVB account holder would feel at home. Three card tiers - Infinite, Platinum, Signature - each with distinct reward structures, all needing to share the same codebase.
Approach
- 01
One skeleton, three expressions
A single onboarding architecture that flexes to all three tiers at the content and reward layer - not the structural layer. Tier differentiation lives in tokens, copy, and reward logic.
- 02
Card management as a composable surface
Controls, statements, rewards, bill payments, EMI, foreclosure, freeze/block - designed as a composable layout system rather than a feature list bolted together.
- 03
Brand alignment without system compromise
Aligning KVB's century-old visual identity with Tijori's component logic required explicit token-level decisions. The seam was documented, not improvised.
- 04
Three rounds of dev handoff to production parity
Annotated edge states, validated production builds against designs, caught regressions before they reached QA.
- 05
Beyond the screen
Designed the physical card visuals across all three variants, the public microsite, launch invites, packaging, activation booklet, benefit inserts, emailers, and social creatives.
Highlights
Outcome
9,608 active users, 56,994 monthly transactions, ₹54.9 Cr+ in monthly transaction value. KVB transitioned to BAU operations in FY26. 85%+ vendor score from KVB. Zero reconciliation issues in 3 months. Presented at Global Fintech Fest 2024.
Long readView full case study+
CASE STUDY: KVB CREDIT CARDS
Retail Credit · 3 Variants · Mobile App + Issuer Portal
One-line summary
End-to-end credit card product for a 108-year-old bank launching on modern infrastructure for the first time - three variants, one designer, live in market.
Problem
KVB had never launched a digital-first credit card. Their existing card management ran on legacy systems that took 12–18 months to launch a new product. Falcon's promise was to do it in 12 weeks. There was no existing design to build on - no UI patterns, no component library, no precedent. I was starting from a blank file.
The product also had to handle significant complexity under the hood: 3 card variants with different reward structures, full RBI-compliant account lifecycle management (activation → delinquency → NPA → closure), 12 repayment modes, EMI conversions, spend controls per channel, and a separate issuer portal for bank staff to manage all of it.
Business and user goal
For KVB: Launch a competitive credit card product that could be managed digitally without branch dependency, reduce operational overhead for bank staff, and open a new revenue line. For cardholders: A modern credit card experience - digital activation, PIN management, spend controls, bill payments - accessible inside KVB's existing mobile app.
My role
Sole designer. I owned everything: information architecture, user flows, interaction design, visual design, prototyping, design QA, issuer portal, and all launch collateral. I worked directly with the SVP of Product, the engineering lead, and the KVB bank team. No design manager, no design reviews above me.
Constraints
KVB's mobile app was an in-app browser (WebView) - not a native app. Every interaction had to work within those constraints: no native gestures, limited animations, PCI-compliance for PIN screens via hosted page only. RBI regulations were non-negotiable. Card activation, PIN set, online spend enablement, and NPA flows all had prescribed logic. The design had to respect every rule without making users feel like they were filling out forms. Three variants (Infinite, Platinum, Signature) had to share one codebase. I couldn't design three separate products - I had to design one product that worked for three. Phase-wise delivery: Phase 0 features had to ship before Phase 1. The design system had to support both without rebuilding.
Process
Week 1–2: PRD deep-dive and flow mapping
I started by reading every page of the Retail Credit Card PRD - account statuses, delinquency cycles, NPA rules, repayment hierarchy, spend controls, GST logic, card renewal rules. I mapped every state the system could be in (Active-Normal, Blocked-Overdue, Suspended-NPA, Closed) and what the user should see in each one. Most designers would wait for a simplified brief. I went straight to the source because I knew ambiguity at the PRD stage becomes broken UX at the design stage.
Week 3–4: Architecture before screens
Before wireframes, I mapped the full product surface: mobile app (Phase 0 - account summary, card controls, PIN, transactions, freeze/block), issuer portal (customer view, card management, credit limit, delinquency actions), and the onboarding flow. I identified shared patterns - status badges, action sheets, confirmation flows - that could become reusable components.
Week 5–8: Design and system build in parallel
I built the mobile flows and the Tijori component extensions simultaneously. Every screen I designed became a component. Card status states, delinquency banners, spend control toggles, PIN entry, bill payment flows - each went into the system as I designed them. This was the only way to hit the timeline without creating a maintenance debt later.
Week 9–10: Issuer portal
The bank's ops team needed a different surface - data-dense, action-heavy, role-based. I redesigned the information architecture for issuer staff: customer search, account detail view, card management, credit limit changes with maker-checker, and delinquency management.
Week 11–12: Prototype, handoff, QA
Built the prototype used in KVB bank reviews and regulatory alignment sessions. Stayed through three rounds of dev handoff, annotating edge states and validating production builds against designs before each QA cycle.
What I got wrong
My first version of the card management screen tried to show all card controls (online, POS, ATM, contactless, international) in a single flat list. It looked clean but confused bank stakeholders during review. I redesigned it as a channel-grid with visual on/off states. The second version passed bank review immediately. Lesson: for operations audiences, scannable > minimal.
Key design decisions
One skeleton, three variants. I designed the entire product as a single interaction model with variant-level differences in rewards, benefits copy, and card visuals. Compliance-first sequencing. I made online-spend activation a visible step framed as "unlock online spending" rather than "enable a permission." Completion rates went up. Error states as part of the design, not afterthoughts. 15+ account states, each with a specific headline, explanation, and action. Issuer portal: separate design language. Higher information density, table-based layouts, action-primary hierarchy.
Final solution
A complete credit card product spanning: mobile WebView app, issuer portal, three variant visual identities, physical card designs, launch microsite, packaging, activation booklet, emailers, and social creatives.
Measurable impact
9,522 active users on one launched variant 9,608 active cards issued 56,994 monthly transactions INR 54.9 Cr+ in monthly transaction value 85%+ vendor score from KVB KVB transitioned to BAU in FY26 Presented at Global Fintech Fest 2024, 80,000+ attendees
What I'd improve next
The issuer portal maker-checker workflow was delivered as Phase Post-MVP. I'd prioritise this earlier - UX for high-stakes actions needs an approval loop built in from day one.