Pricing a digital credit product is not a single-rate decision. Customers compare the complete experience: how much they can access, how quickly they receive certainty, what they pay in total, how flexible repayment feels and whether the offer is easy to understand.

For the business, the same proposition must account for cost of capital, risk, operating effort, acquisition cost and expected lifetime value. A lower rate can improve consideration but still destroy value if it attracts the wrong risk mix or depends on expensive manual operations.

Build scenarios, not one answer

A useful pricing exercise compares a small set of customer and business scenarios. For each one, make the tradeoff visible: expected conversion, risk, contribution, operational load and the customer promise. Then define guardrails that tell teams when the pricing logic should change.

The product manager's role is to turn that economic logic into comprehensible product behaviour. A sound model only creates value when customers understand the offer and teams can execute it consistently.

An aggregate funnel is useful for monitoring, but weak for diagnosis. It can hide large differences between acquisition channels, customer cohorts, eligibility bands, partners and time-to-complete. A stable top-line number may even conceal one segment improving while another deteriorates.

I usually break the journey into four questions: could the customer proceed, did they intend to proceed, what friction stopped them and how much delay was introduced? Each question needs different evidence. Eligibility needs rules and data quality. Intent needs behavioural context. Friction needs event-level analysis and customer conversations. Delay needs operational timestamps.

Make the metric point to a decision

A useful dashboard should not merely describe performance. It should tell the team where to investigate, which segment is affected and what decision is now possible. If a metric cannot change a priority, experiment or operating action, it is probably reporting noise.

AI is most valuable when it shortens the path from raw material to a better decision. I use it to structure research, compare options, challenge assumptions, draft first versions and expose questions that deserve deeper investigation.

It becomes risky when fluent output is mistaken for verified context. A model does not own the customer promise, understand every commercial dependency or carry accountability for the outcome. Sensitive data, source provenance and human review need explicit guardrails.

The leverage comes from better questions

The quality of an AI-assisted workflow depends on the quality of its framing. Define the decision, provide relevant constraints, ask for competing interpretations and test the output against primary evidence. The goal is not to automate judgment. It is to create more room for it.

Most consumer payment products are built around a simple assumption: one account, one user, one decision-maker.

Real households rarely work that way.

Parents pay for children, adult children manage expenses for elderly family members, partners share household responsibilities, and small businesses frequently allow employees to make controlled purchases. Yet digital payment products have historically forced these relationships into awkward workarounds.

UPI Circle changes the product model from ownership to permission.

NPCI describes UPI Circle as a mechanism through which a payer can extend transaction authorisation to another individual within defined limits. That sounds like a payments feature, but the underlying design principle is more powerful: a financial account can support multiple roles without transferring ownership.

For Product Managers, three areas matter.

First is control design. Delegation should never be binary. Users need intuitive controls for transaction limits, duration, revocation and potentially transaction categories. The product should answer: “What exactly am I allowing this person to do?”

Second is trust visibility. Primary users should have a clear activity feed and immediate alerts. Secondary users should know how much authority remains. A shared financial relationship becomes safer when both parties understand the rules.

Third is failure handling. What happens when a delegated payment exceeds the limit, the primary user removes access, the device changes or fraud is suspected? Edge cases are not operational details; they are part of the core experience.

The opportunity extends beyond families. Similar permission models could support caregiver payments, controlled allowances, field employees, gig-work expenses and micro-business procurement.

The key metric should therefore not be only “delegated users added.” Teams should measure activation, successful payment rate, repeat usage, limit modification, revocation patterns and fraud rates relative to normal UPI transactions.

UPI Circle is interesting because it introduces an enterprise-grade concept—role-based access—into everyday consumer payments.

The winning products will make that complexity feel simple.

What PMs should test next

The key experiments are around granularity of control: daily limits, merchant limits, duration and contextual balance visibility. The challenge is offering enough control without making setup intimidating.

A strong delegated-payments product should also reduce coordination outside the app. If families still need messages and screenshots to understand spending, the permission model has not solved the whole job.

A conventional digital loan has two separate product moments.

The first is access: eligibility, underwriting, approval and disbursal.

The second is use: what the customer actually does with the money.

Credit on UPI can bring these moments much closer together. When an eligible credit facility can be used through a familiar UPI payment experience, the user no longer needs to think in terms of “taking a loan” before making a purchase. Credit becomes a funding source available at the point of transaction.

That is a major product shift, and most of its difficulty sits below the interface.

One tap on the front end, two clocks on the back end

A bank-funded UPI payment debits an existing balance. A credit-funded one creates a borrowing event. That difference produces two clocks that the product has to reconcile.

The first clock is the authorisation clock, measured in seconds, where the payment either succeeds or fails at the merchant. The second is the credit clock, measured in days, where the drawdown is booked to a loan account, interest begins to accrue under the agreed method, and the amount enters a billing cycle.

The consequence is that every small payment can become a booked credit event with its own accrual start, statement line and repayment obligation. Teams often design the tap and postpone the ledger. In practice the ledger determines what the customer sees on the statement, what support agents can explain, and whether a dispute can be resolved without a manual note.

Payment behaviour and credit economics pull in opposite directions

Payment usage is dominated by small, frequent tickets. Credit products are usually priced and provisioned around larger ones. When a facility built for a ₹20,000 purchase is used for a ₹120 one, three things break quietly:

• interest earned on the transaction can fall below the cost of servicing it, so contribution per drawdown turns negative even while volume looks healthy
• statement readability collapses, because a monthly bill made of two hundred micro-drawdowns is not a document anyone reconciles
• collections effort per rupee outstanding rises, since the same follow-up cost applies to a small balance

The product response is not to block small transactions. It is to decide deliberately where credit should be the default funding source and where it should not appear at all — by ticket band, merchant category, or the customer’s remaining balance in other funding sources.

Instrument selection is the highest-risk screen in the journey

If the user can choose between bank balance, credit card and a credit line while paying, the product must clearly communicate which source is being used, how much it costs and when repayment is due. That transparency cannot be hidden behind a post-transaction statement.

Two failure patterns recur. The first is the silent default, where credit becomes the pre-selected source and the user borrows without registering the decision. The second is the invisible switch, where a failure on the primary source silently retries on credit so the payment succeeds and the funding source changes without acknowledgement. Both improve success rate and both damage trust, which is why success rate alone is a dangerous target for this screen.

Repayment is where the product is actually judged

Approval is a one-time event. Repayment happens every cycle, and its design decides retention.

The details that matter are unglamorous: when the cycle closes relative to the customer’s salary date, whether the autopay mandate has sufficient balance at the moment of presentation, what happens on the first presentation failure, how partial payments are allocated across principal, interest and charges, and whether a customer can pay early without a penalty they did not anticipate.

A mandate that presents the day before salary credit will fail for reasons that have nothing to do with creditworthiness. That single scheduling decision can move early delinquency more than a change in the underwriting cut-off.

Utilisation is a signal, not only a revenue line

For lenders, the funnel moves beyond approval rate. A sanctioned line that is never used generates very different economics from one that becomes a customer’s preferred payment instrument. Product teams therefore need a richer set of metrics:

Eligible → Approved → Activated → First Spend → Repeat Spend → Repayment → Retention

But utilisation should be read as behaviour, not just as balance. Two patterns deserve separate treatment. A rising share of spend on essentials — groceries, fuel, utilities, pharmacy — alongside falling ticket sizes often indicates liquidity stress rather than product success. A sudden jump to near-full limit shortly after activation is a different signal again, and one that most acquisition dashboards happily count as a win.

Useful definitions matter here. Activation is not the first tap; it is the first completed drawdown. Repeat utilisation should be measured on a cohort basis by month on book, not in aggregate, because a growing portfolio hides deteriorating behaviour in older vintages.

The worst experience is a limit that declines

A customer who has been told they have credit available, and is then declined at the counter, experiences something worse than never having been offered it. This happens for ordinary reasons: a velocity rule, a merchant-category restriction, an expired mandate, a step-up authentication that could not complete, or a limit already blocked by an earlier authorisation.

Product teams should treat decline messaging as part of the credit product, not as an error state. The customer needs to know whether to retry, use another source, or wait — in the two seconds they have while standing at a merchant.

Where the economics change

Credit at the payment layer can reduce the distance between acquisition and utilisation because the user already has purchase intent.

That does not make every transaction a lending opportunity. The better product decision is to surface credit only when it materially improves affordability or liquidity, while suppressing offers when the user is already stretched. Relevance should improve both conversion and portfolio quality.

Success therefore should not be measured purely by gross transaction value. Healthy utilisation, repeat usage, repayment quality, complaints and delinquency by cohort matter just as much.

The most powerful outcome of credit on UPI is not “a loan inside a payment app.”

It is a lending product where approval, availability and utilisation become part of the same continuous journey — and where the ledger, the mandate and the decline message are designed with the same care as the tap.

UPI apps solved one of the hardest problems in consumer fintech: frequency.

Payments give users a reason to return almost every day. But high engagement does not automatically translate into high revenue.

That is why the next battle for payment apps is increasingly about what financial product can be layered on top of payment behaviour.

Credit is an obvious candidate.

A payment app already observes important context: transaction frequency, recurring merchants, bill-payment behaviour and moments of purchase intent. Within regulatory and consent boundaries, this context can help create more relevant credit experiences than a generic “Apply for a loan” banner.

Imagine the difference between two journeys.

Journey A interrupts the customer with a personal-loan advertisement on the home screen.

Journey B recognises that a user is making a larger purchase and presents an already-underwritten credit option with transparent cost and repayment terms.

The second journey is more contextual—and potentially much higher converting.

But the product team must resist an easy trap: turning every payment surface into an advertising surface.

Payments are trusted because they are simple. If monetisation adds clutter, manipulative nudges or constant cross-selling, engagement can deteriorate.

The better approach is to optimise for relevant financial actions per active user, not offers shown per active user.

That means building decisioning systems around user eligibility, intent, lifecycle stage and product suitability.

For credit, useful metrics include offer-to-view rate, view-to-activation, sanctioned-to-utilised limit, repeat utilisation, contribution margin and repayment quality. For the core payments experience, teams should simultaneously watch payment success rate, session time, complaint rate and retention.

The strategic advantage of a UPI app is not that it owns a QR scanner.

It owns a recurring customer interaction.

The companies that convert that interaction into sustainable financial relationships—without compromising trust—will create far more value than those that simply maximise payment volume.

The real competitive moat

Payments frequency alone is unlikely to be a durable moat. The advantage will come from combining distribution with underwriting, merchant context, servicing and trust.

Teams should compare generic cross-sell with contextual triggers while tracking conversion, retention and complaints. If monetisation lifts revenue but weakens payment engagement, the app may be borrowing value from its core product rather than creating new value.

Digital lenders have spent years optimising applications.

Remove a field. Pre-fill an address. Reduce KYC steps. Move a question to the next screen.

Those improvements matter, but they optimise the symptom rather than the architecture.

The deeper problem is that many lending journeys still ask users to manually provide information that already exists somewhere digitally.

Income exists in bank transactions or payroll records. Business turnover may exist in GST-related data. Investments sit with regulated financial institutions. Identity information can often be verified digitally.

The next breakthrough in lending UX is therefore not a five-screen application instead of a ten-screen application.

It is less application altogether.

India’s Account Aggregator ecosystem and the RBI’s work on ULI point toward a model where borrowers can consent to verified financial information being transmitted to regulated Financial Information Users rather than repeatedly uploading screenshots, PDFs and statements.

This changes the PM’s job.

The critical funnel may move from:

Form Start → Form Complete → Document Upload → Verification

to:

Consent Shown → Consent Accepted → Data Fetched → Decision Generated

New failure points emerge. Data may be incomplete. An institution may be unavailable. A user may not understand why access is required. A model may receive contradictory signals.

That means the product needs transparent consent, graceful fallbacks and clear explanations.

The payoff can be substantial: faster decisions, lower operational cost and the ability to evaluate customers who do not fit a traditional salaried-credit template.

But more data should never become an excuse to collect everything.

The principle should be minimum sufficient data: request only what improves the decision or fulfils a regulatory requirement.

The best lending product of the next few years may not feel like an application at all.

It may feel like a customer granting permission, receiving a decision and choosing whether the offer is right for them.

A new source of competitive advantage

When verified data becomes easier to access, lenders will compete less on document collection and more on who interprets information better. Two lenders can receive similar inputs and still produce different offers because their risk appetite, pricing and servicing models differ.

Infrastructure can standardise access without standardising judgement. Product differentiation then shifts toward decision quality, communication and exception handling.

Open finance is often described as a data-sharing problem.

From a Product Manager’s perspective, it is really a consent-design problem.

India’s Account Aggregator framework enables financial information to move between regulated participants based on customer instructions. RBI’s consumer guidance emphasises that Account Aggregators do not see or store the financial information itself and that data is shared with Financial Information Users based on customer consent.

Technically, that enables richer lending, wealth and personal-finance experiences.

Product-wise, it creates a new responsibility: users must understand what they are permitting.

A poor consent screen says:

“Allow access to financial data.”

A strong one answers four questions:

What data? Why? For how long? What do I get in return?

That distinction matters because consent obtained through confusion may improve short-term conversion while damaging trust.

Account Aggregator journeys also create operational design challenges. A customer may have accounts across multiple institutions. One source may fail. Data may cover an insufficient period. A user may revoke consent halfway through a process.

The experience therefore needs to support partial success rather than treating every technical exception as a dead end.

For a lending product, useful metrics include consent-view-to-approval rate, successful fetch rate, time to fetch, fallback-to-manual rate and conversion by data completeness.

For a wealth product, the value may be different: consolidated portfolio visibility, personalised asset allocation or more accurate financial planning.

The strategic lesson is that Account Aggregator should not be treated as another backend vendor integration.

It is an architecture that allows users to bring verified financial context into a product without manually reconstructing their financial life.

Companies that make that exchange transparent and valuable will build trust.

Companies that simply ask for maximum data because the rails exist will miss the point.

Consent is measurable

Product teams should test whether customers can explain what they authorised immediately after the consent screen. If their understanding differs materially from the actual permission, the screen may be legally complete but product-incomplete.

Open finance depends on repeat trust. Users should clearly understand the exchange: what data they share, for what purpose, and what value they receive.

Many digital lending journeys are technically digital but still structurally offline.

The paper form became a mobile form. The branch checklist became a sequence of screens. The customer still does most of the work.

That model is reaching its limit.

The next generation of loan journeys will be built around three principles: fetch instead of ask, decide before displaying complexity, and reveal only what is necessary at each stage.

Consider the typical funnel.

A user enters personal information, employment details, income, bank information and addresses before knowing whether the lender can make a meaningful offer.

From a conversion perspective, that is backwards.

Where regulation and data availability allow it, the journey should progressively establish identity, obtain explicit consent, retrieve reliable information and evaluate eligibility before asking the customer to invest significant effort.

That changes the role of UX.

The PM is no longer asking, “Can we reduce this form from eight fields to six?”

The better question is, “Why does the user need to type this at all?”

Every field should have a justification.

Every document upload should have a digital-fetch alternative where possible.

Every technical dependency should have a fallback.

And every major commitment—credit bureau pull, data access, agreement, mandate—should be explained at the moment it matters.

The funnel should be measured stage by stage: eligibility start, consent, data fetch, offer generation, offer acceptance, KYC, agreement, mandate and disbursal.

Then pair conversion data with latency. A stage with 90% completion but a four-hour turnaround can still destroy the journey.

The future loan experience may still contain 20 backend steps.

The difference is that the customer should not have to experience all 20 of them.

Great fintech products do not merely digitise complexity.

They absorb it.

What replaces the old form

Shorter journeys do not mean weaker control. Better orchestration can strengthen verification because information is sourced consistently rather than retyped.

The product still needs an exception layer for customers whose data cannot be fetched. Assisted journeys, alternate documents and save-and-resume paths matter.

The 20-screen journey dies when complexity moves behind the interface—not when necessary checks disappear.

“AI agent” is quickly becoming one of fintech’s most overused phrases.

The useful product question is simpler:

What task can the system execute safely without requiring a human to perform every intermediate step?

In banking, the best starting points are usually bounded workflows rather than high-consequence autonomous decisions.

Consider a customer-service complaint.

An AI agent could retrieve the customer’s recent transaction history, identify the relevant policy, classify the complaint, draft a response and route the case to the right team.

That removes repetitive work without allowing the system to move money or make an irreversible credit decision.

The same principle applies to lending.

An agent could coordinate document collection, detect missing information, trigger permitted data fetches and prepare an underwriting summary. The final approval can remain within established rules or human authority.

A useful automation framework has four levels:

Assist: AI recommends an action.
Prepare: AI completes the work but waits for approval.
Execute: AI performs a reversible action within limits.
Autonomously decide: AI takes a high-impact action without intervention.

Financial institutions should move through these levels deliberately, not because the model technically can.

Every agent also needs an authority boundary.

What systems can it access?
What data can it read?
What can it write?
What monetary limit applies?
When must it escalate?
How can an action be reversed?

Those controls are part of the product specification.

Metrics should include task-completion rate, human-review rate, error rate, time saved, customer impact and recovery success when the agent fails.

The biggest mistake would be to evaluate agents only on how much human work they eliminate.

In financial services, the goal is not maximum autonomy.

It is reliable autonomy inside a clearly defined box.

Choose workflows with visible economics

A strong first agent use case has high repetition, clear rules and a recoverable failure mode.

PMs should estimate human time saved, automation coverage, exception rate and the cost of a wrong action. A workflow producing reviewable outputs is often a better candidate than a glamorous autonomous use case with rare but severe errors.

Rank the roadmap by value × controllability, not novelty.

KYC has always created a difficult product trade-off.

Make onboarding too strict and legitimate users drop off.

Make it too easy and fraud risk rises.

Aadhaar face authentication is interesting because it can reduce some of that tension by enabling biometric authentication through commonly available smartphones and tablets. UIDAI identifies face as an Aadhaar authentication mode, alongside fingerprint, iris and other permitted methods.

The product opportunity is not simply “replace OTP with face.”

It is to design a more resilient identity journey.

For example, a customer could begin with a low-friction digital step. If risk signals remain normal, the journey continues. If the device, identity or behaviour requires additional confidence, the system can step up authentication.

That creates adaptive KYC rather than one identical flow for everyone.

But face authentication has its own edge cases: lighting, camera quality, connectivity, accessibility and failed matches.

A product that treats every failure as fraud will exclude legitimate users.

A product that ignores repeated failures will create risk.

The correct UX therefore includes clear capture guidance, retry logic, alternative authentication paths and escalation.

PMs should measure more than “KYC completion rate.”

A stronger identity scorecard includes:

• authentication success on first attempt
• average retries
• fallback usage
• fraud detection
• false rejection rate
• time to completion
• device-level failure patterns
• assisted-support rate.

The broader lesson is that identity should not be viewed as a compliance screen customers must survive.

It is a trust layer.

When identity infrastructure becomes more capable, the best product teams use it to make legitimate customers move faster while making suspicious behaviour work harder.

That is a better objective than simply removing one more step.

Design for the user who fails

The true quality of an authentication journey is often visible in its fallback path.

If face authentication fails twice, the screen should not simply say “Try again.” It should diagnose likely causes—lighting, framing, camera permissions or connectivity—and offer an alternate permitted route when appropriate.

This is especially important for financial inclusion. A biometric technology can technically expand access while poor retry UX creates a new exclusion layer. PMs should analyse failure by device, geography and user cohort so that an infrastructure improvement actually becomes an experience improvement.

Fraud teams traditionally worked behind the product.

That separation is becoming impossible.

Every fraud control affects a customer journey: an OTP, a transaction limit, a blocked payment, a cooling period, a device challenge or a manual review.

The product experience is therefore partly the output of the fraud system.

This matters because fraud prevention has two failure modes.

The obvious failure is letting fraud through.

The less visible failure is blocking legitimate customers.

A rule that reduces fraud by aggressively declining new-device transactions may look excellent on a risk dashboard while quietly destroying conversion and trust.

Product and risk teams need a shared objective.

One useful metric is:

Fraud loss prevented relative to legitimate customer friction created.

That forces teams to examine false positives.

Instead of applying the same friction to every user, modern financial products can build risk-adaptive journeys.

A normal low-value payment from a recognised device may proceed with minimal interruption. A high-value transaction to a new beneficiary immediately after a device change may require step-up authentication.

The interface also matters after a block.

“Transaction failed” is not an adequate recovery experience.

Was the payment blocked for security?
Can the user verify it?
How long will the restriction remain?
What should they do next?

Recovery UX can turn a scary event into a trust-building one.

Fraud should also influence product analytics. Segment payment success rate by risk decision. Track customer abandonment after challenges. Measure how many support contacts are generated by controls.

The best fintech companies will not treat fraud as something added after the journey is designed.

They will design risk and experience as one system.

Because when money is involved, safety is part of the product—not a layer behind it.

Fraud controls need experimentation discipline

Risk interventions should be tested like product features. A new step-up challenge should be evaluated against fraud reduction, payment success, completion time and support contacts.

Before making a blocking rule permanent, understand which legitimate cohorts it affects.

Product, Risk, Data Science and Operations therefore need one shared review. Fraud changes continuously, so the experience must be continuously optimised too.

Digital lending has made decisions faster.

It has not necessarily made them easier to understand.

A customer can complete an application, consent to data access and receive a result within minutes—only to see:

“Unfortunately, we are unable to offer you a loan.”

From the lender’s perspective, the decision may involve policy rules, bureau variables, affordability checks and fraud signals.

From the customer’s perspective, it feels arbitrary.

That creates a product opportunity: explainability as customer experience.

Explainability does not mean exposing a proprietary underwriting model or giving customers a recipe to game risk controls.

It means providing useful, compliant and understandable information.

For example:

“Your current repayment obligations are high relative to the income information available to us.”

is more useful than:

“Rejected due to internal policy.”

The same principle applies to partial approvals.

If a customer requested ₹5 lakh and receives ₹2 lakh, the product should clearly explain the offer rather than making the customer infer that something went wrong.

Explainability improves more than sentiment.

It can improve future conversion. A customer who understands that the issue is incomplete income data may return with stronger information. Someone declined because of existing obligations may become eligible later.

PMs should measure rejection-page exits, support contacts after decisions, repeat applications, complaint rate and future eligibility conversion.

There is also an internal benefit.

If product, risk and customer-support teams cannot explain the major reasons behind outcomes, the decision system itself may be too opaque.

As lending becomes more automated, transparency has to increase with it.

Speed without explanation can feel arbitrary.

Speed with clear reasoning feels like a product.

Explanations can become a feedback loop

Decline reasons can improve the product internally. If many applicants fail because income cannot be verified, the answer may be a better data-fetch or fallback journey—not more acquisition.

Structure decision reasons for analytics by channel, cohort and funnel stage. Explainability then becomes an input into roadmap prioritisation.

A good credit system should explain both why it said no and what the team can learn from that no.

One of the most expensive sentences in fintech product development is:

“Let’s get compliance sign-off before launch.”

If compliance is seeing the product for the first time at that stage, the team is already late.

Financial products are shaped by questions that affect architecture itself.

Who is the regulated entity?
Who acquires the customer?
Who can display an offer?
Where does money move?
What data is collected?
Who stores it?
What consent is required?
What must be disclosed?
Who handles grievances?

These are not launch-checklist questions.

They influence APIs, screens, agreements, analytics and partner contracts.

Compliance-by-design means bringing regulatory constraints into product discovery.

A PRD for a lending partnership, for example, should map the customer journey and the responsibility journey side by side.

The user may see one seamless experience, but behind it different entities can own sourcing, underwriting, disbursal and servicing.

If the team cannot clearly explain those roles internally, the customer experience will eventually expose the confusion.

The same applies to wealth products. Distribution, advice, research and execution may have different regulatory implications. A seemingly small change in copy or recommendation logic can alter the nature of the experience.

This does not mean Product Managers need to become lawyers.

They need to become good translators.

Product explains the user flow and system behaviour. Compliance explains the rule and risk. Together they design an implementation that achieves the business objective within the permitted structure.

A useful product artifact is a regulatory decision log: requirement, interpretation, product implication, owner and evidence.

That turns compliance knowledge into institutional memory.

The best compliance teams do not slow product development.

They prevent expensive redesign.

And the best fintech PMs do not ask, “How do we get this approved?”

They ask earlier:

“How should this be designed so that approval is a consequence of good architecture?”

Make compliance observable

The implementation should leave evidence: when consent was captured, which disclosure version a customer saw, what partner handled a stage and where a regulated hand-off occurred.

That observability helps audits, incidents and customer support. Compliance-by-design is not only about legal interpretation; it is about building a system whose behaviour can later be reconstructed and explained.

The first generation of embedded finance was mostly about placement.

Put a loan inside a commerce app.
Put insurance next to a purchase.
Put payments inside a marketplace.

The next generation should be about context.

A product should not ask, “Where can we place a financial offer?”

It should ask, “What financial problem appears naturally inside this customer journey?”

Consider a small seller on a marketplace.

A generic personal-loan banner may be irrelevant.

But a short-term working-capital facility triggered by verified settlement history and inventory needs solves a specific problem.

That difference is the essence of Embedded Finance 2.0.

The same principle applies to consumers.

Travel insurance makes sense during travel booking. A credit facility may make sense when there is a genuine affordability gap. A savings or investment action may be relevant after a recurring salary credit.

Context improves conversion because the customer does not need to mentally translate a generic product into their situation.

But embedded finance creates an important responsibility: the host platform should not use context merely to maximise financial extraction.

A high-intent moment can make users more vulnerable to poor choices. Pricing, provider identity and terms must remain clear even when the financial product feels seamlessly integrated.

PMs should measure more than attachment rate.

Useful metrics include need-to-offer eligibility, offer acceptance, subsequent usage, cancellation, repayment quality, claims experience and repeat adoption.

The strategic moat is not the embedded widget.

APIs can be replicated.

The moat is understanding the host journey deeply enough to know when finance genuinely improves it.

The best embedded financial product may feel almost invisible—not because disclosures are hidden, but because the solution appears exactly when the customer needs it.

The platform must protect the context

Embedded distribution creates a subtle conflict: the host app wants conversion, while the financial provider must manage suitability, risk and disclosures.

The integration should therefore define clear ownership of eligibility, offer communication, consent, servicing and complaints before launch. A seamless front end cannot hide ambiguous accountability behind the scenes.

The best embedded-finance partnership feels native to the user but remains operationally explicit. Context should improve relevance—not blur who is providing the financial product or what the customer is agreeing to.

Lending growth teams usually obsess over the top of the funnel.

More leads.
More applications.
Higher approval.

But for many credit products—especially revolving facilities, lines of credit and loans against financial assets—approval is not revenue.

Utilisation is.

A customer may complete KYC, sign an agreement and receive a ₹5 lakh credit limit, yet draw only ₹50,000—or nothing at all.

If the product team celebrates sanction value, it can mistake available credit for active credit.

That changes the funnel.

A more useful model is:

Eligible → Applied → Approved → Limit Activated → First Drawdown → Repeat Utilisation → Repayment

Each stage has different product levers.

Low activation may indicate that the customer does not understand how to use the facility.

Low first utilisation may indicate weak need at the moment of approval.

Low repeat utilisation may indicate poor pricing, difficult withdrawals or an inferior repayment experience.

The best growth intervention may therefore happen after approval.

Examples include clearer available-limit visibility, contextual use cases, faster drawdown, transparent interest calculation, repayment reminders and intelligent prompts when the product is genuinely relevant.

But utilisation cannot be pushed blindly.

For credit, more usage is not always better. The team should pair utilisation metrics with portfolio health: repayment behaviour, delinquency, customer complaints and concentration.

A useful North Star might be healthy utilised balance rather than sanctioned balance.

That metric captures both customer adoption and credit quality.

The broader product lesson is simple:

Acquisition creates the possibility of a lending relationship.

Utilisation proves whether the product is actually useful.

Utilisation is a product diagnosis tool

Looking at utilisation by cohort can reveal where the product is misaligned. A low-utilisation segment may have been acquired too early, offered an unnecessarily large limit or given a facility whose drawdown experience is too cumbersome.

Teams should segment sanctioned customers by acquisition channel, limit size, pricing, tenure and first-use timing. The goal is to distinguish “does not need credit” from “needs credit but does not use this product.”

Those are completely different problems. The first calls for better targeting. The second calls for product improvement.

That is why utilisation is not simply a revenue metric; it is evidence of product-market fit after approval.

A common question about India’s digital rupee is:

Why do we need it when UPI already works?

The question mixes two different layers.

UPI is a payment system. It allows users to instruct participating financial institutions to move money efficiently.

The digital rupee, or e₹, is central-bank digital currency—digital money issued by the Reserve Bank of India.

The customer experience can look similar because both may involve scanning a QR code.

The product architecture is different.

RBI’s CBDC FAQ notes that transactions between e₹ wallets can settle between those wallets without passing through the user’s bank account, while e₹ apps can also scan UPI QRs in supported scenarios.

That interoperability is important because it means customers should not have to care about infrastructure before paying.

The strongest product opportunities for CBDC are therefore unlikely to come from recreating ordinary UPI payments.

They come from capabilities that digital currency itself can enable.

RBI is exploring offline payments for locations with limited connectivity and programmability, where funds can be restricted by parameters such as purpose, expiry, geography or merchant category.

Those features create use cases in targeted benefits, controlled institutional payments and potentially specific lending flows.

UPI remains extraordinarily strong for everyday payments.

CBDC can complement it where the properties of the money itself matter.

For Product Managers, the principle is simple:

Do not ask which technology is more advanced.

Ask what job requires which architecture.

If the user only needs to pay a merchant, UPI may already solve the problem beautifully.

If the use case requires offline value, specific programmability or central-bank digital money, CBDC becomes more interesting.

Good infrastructure disappears behind the task.

That should be the product goal for both.

The user should not have to choose infrastructure

Consumers should not have to understand payment architecture before every transaction.

Interoperability can let the product surface the right rail or wallet while keeping the funding source clear. The infrastructure decision belongs mostly to the system; the financial consequence belongs in the interface.

Hide protocol complexity, not important user information. That is how UPI and e₹ can coexist coherently.

Most digital money is smart only at the application layer.

The bank or fintech knows why the payment is happening, but the money itself is interchangeable.

Programmable CBDC introduces a different possibility.

RBI says the digital rupee’s programmability feature can allow a sponsor entity or user to ensure funds are used for a designated purpose, with parameters such as expiry date, geography, merchant category or merchant VPA. Current exploration includes use cases involving benefits, lending and defined employee allowances.

That creates fascinating product possibilities.

Consider agricultural credit.

A lender may want to ensure that a subsidised facility is used for eligible agricultural inputs. Programmability could potentially encode part of that end-use control into the money flow itself.

Or consider an employee allowance intended only for meals or travel. Instead of collecting receipts after the fact, spending rules could be embedded into the instrument.

The benefit is clear: lower reconciliation cost and stronger end-use control.

But programmability also creates serious UX questions.

What happens when a legitimate merchant is incorrectly categorised?
Can the user appeal a failed transaction?
What happens when funds expire?
Can restrictions be changed?
How clearly are the conditions disclosed before the user accepts the money?

Without strong recovery journeys, programmable money can feel like broken money.

That is why PMs should treat policy logic as part of the interface.

Before accepting programmable funds, a user should understand:

where they can spend, what they can spend on, until when, and what happens if payment fails.

The most exciting part of CBDC is not that currency becomes digital.

Most money already feels digital to consumers.

The real product frontier begins when digital currency can carry behaviour and constraints that previously required separate systems.

That is where programmable money becomes genuinely new.

Programmability needs governance UX

Users should know who created the restriction, what the rules are and where to raise a dispute.

Analytics also need distinct failure reasons: insufficient balance is different from “merchant category not permitted” or “programme expired.” If those failures are lumped together, support teams cannot diagnose them and users cannot recover.

Programmable money will succeed only when its rules are as understandable as its technology is powerful.