PhonePe Risk Analyst — Interview Questions
PhonePe Risk Analyst Interview Questions
Risk analysts at PhonePe operate across fraud, credit, and compliance — protecting a payments network that moves enormous transaction volume while a growing lending book adds credit risk on top of it. The interviews test whether a candidate can reason under uncertainty with incomplete data, and whether they understand that risk decisions almost always trade off against user friction or business growth, not against some risk-free alternative.
PhonePe's Interview Process for Risk Analyst
Typically includes a screening round, a technical/analytical case round (often SQL and statistics-heavy), a risk-scenario round with a senior risk manager, and a final round covering judgment and communication with cross-functional stakeholders. Expect scenario questions grounded in fraud detection, credit underwriting, and regulatory trade-offs specific to UPI and digital lending.
Question 1: The Sudden Fraud Spike
Unauthorized UPI transactions have spiked 3x in the last 6 hours, concentrated among a specific set of users. You have 30 minutes before a leadership call. What's your immediate response, and what would you tell leadership?
Why interviewers ask this
This tests whether a candidate can act decisively under real time pressure with partial data, distinguishing what needs to happen in the next 30 minutes from what needs deeper investigation afterward — a core skill for real-time fraud response.
Example strong answer
"In the first few minutes, I'd pull whatever's fastest to get: what do the affected transactions have in common — same device fingerprint patterns, same recipient accounts, same geographic cluster, or same onboarding cohort or time window. A 3x spike concentrated in a specific set of users, rather than spread broadly, strongly suggests a specific attack vector rather than a general uptick, which is actually good news for how fast we can contain it.
If I can identify a common thread — say, all affected users registered through a specific channel in the last two weeks, suggesting a compromised onboarding flow or a phishing campaign targeting a specific user list — I'd recommend an immediate, narrow intervention: enhanced authentication for that specific segment, not a blanket friction increase for all users, since overreacting broadly has its own cost in legitimate transaction friction.
If I can't identify a clear common thread within the time I have, I'd recommend a more conservative temporary measure — tightening velocity limits or adding step-up authentication for higher-risk transaction patterns generally — while being explicit to leadership that this is a containment measure based on partial information, not a root-cause fix.
For the leadership call itself, I'd bring three things: what we know for certain (the spike is real, roughly this scale, concentrated in this pattern), what we're doing right now to contain it, and what we don't know yet with a clear timeline for when we'll know more — rather than presenting speculation as if it were confirmed. Leadership needs an honest picture of certainty levels to make good calls above my level, and overstating confidence in an unconfirmed root cause is worse than admitting we're still isolating it."
Follow-up questions
- The common thread turns out to be a specific bank's authentication flow being compromised on their end, not ours. How does your recommendation change?
- Leadership wants to know the financial exposure right now, before the investigation is complete. How do you estimate that responsibly?
Question 2: Underwriting Thin-File Borrowers
PhonePe wants to extend a small personal loan product to users who have strong UPI transaction history but no formal credit bureau file — common among gig workers and small merchants. What data would you use to underwrite them, and what risks does this approach carry?
Why interviewers ask this
This tests whether a candidate understands alternative credit scoring in a real regulatory and ethical context — not just what signals could work technically, but what the model might get systematically wrong for a population that's hard to validate against ground truth.
Example strong answer
"With no bureau file, the transaction history itself becomes the primary signal, and I'd look at a few categories: income stability proxies — consistency and predictability of inbound UPI transactions over 6-12 months, since irregular, unpredictable income is a real credit risk regardless of volume; expense behavior — whether outbound transactions suggest the person is managing cash flow responsibly, including any existing informal repayment-like patterns, such as consistent transfers that resemble EMI or rent payments; and account tenure and consistency, since a longer, stable transaction history is more reliable signal than a short one, even with strong recent activity.
I'd be cautious about over-indexing on transaction volume alone, because volume doesn't equal creditworthiness — someone with high UPI volume from running a small business could still have thin margins and real repayment risk, and a purely volume-based model would systematically misprice that.
The biggest risk with this approach is that we're building a model without the ground truth we'd normally have — bureau data comes with known default outcomes to validate against, and alternative data doesn't, at least not until we've originated a first cohort and watched what happens. That means the earliest version of this model needs conservative loan sizing and tight monitoring, essentially treating the first several months as a live pilot rather than a fully trusted underwriting model, with small initial ticket sizes that limit downside while we gather real repayment outcomes to validate the alternative signals against.
There's also a fairness risk worth naming directly: if the transaction-history features correlate with something like income volatility that itself correlates with specific occupation types or regions, the model could systematically underprice or deny credit to entire legitimate segments even though no explicit demographic data was used — that's a known failure mode in alternative credit scoring, and I'd want the model regularly audited for approval-rate disparities across segments, not just overall accuracy."
Follow-up questions
- Six months in, the model's default predictions and actual defaults are diverging in a specific segment. How do you investigate?
- How would you balance the pressure to grow loan originations quickly against the caution needed with an unvalidated alternative-data model?
Question 3: Detecting Merchant Collusion Rings
The fraud team suspects a group of merchants may be colluding to run fake transactions — possibly for money laundering or to artificially inflate transaction volume for some benefit. How would you investigate this?
Why interviewers ask this
This tests network/graph thinking in fraud detection — collusion rings usually can't be caught by looking at any single merchant in isolation, and PhonePe wants to see whether a candidate reaches for relationship-based analysis rather than individual anomaly detection alone.
Example strong answer
"Individual merchant-level anomaly detection — flagging a merchant with unusual volume — is a reasonable starting filter, but collusion specifically requires looking at relationships between merchants and users, not just single-entity behavior, since the whole point of a collusion ring is that no single participant looks obviously wrong in isolation.
I'd build a transaction graph where merchants and frequent counterparties are nodes, and look for structural patterns that are unusual for legitimate commerce: tight clusters where the same small group of accounts transact repeatedly and almost exclusively with each other, circular transaction flows where money moves through a chain of accounts and returns close to its origin, or transaction patterns with round, suspiciously clean amounts inconsistent with typical retail transaction distributions.
I'd also look at timing patterns — legitimate merchant transactions from real customers tend to cluster around business hours and show natural variance in timing and amount; a group running fake transactions to inflate volume often shows unnaturally regular timing or amounts, since it's easier to generate synthetic transaction patterns programmatically than to fake the organic noise of real customer behavior.
Once I have a candidate cluster flagged by the graph analysis, I'd cross-reference with onboarding data — did these merchants register around the same time, from similar locations or devices, with similar business documentation — since collusion rings are often set up together rather than organically converging.
I'd be careful not to over-flag legitimate business relationships that happen to look similar structurally — a wholesaler and their regular retail customers might show a tight, repeated transaction cluster too. So before escalating to an enforcement action like freezing accounts, I'd want the graph signal combined with at least one independent corroborating signal — document inconsistencies, IP or device overlap, or unusual patterns in how the accounts were funded initially — rather than acting on network structure alone."
Follow-up questions
- The graph analysis flags a cluster, but it turns out to be a legitimate small-business supply chain. How do you refine the model to avoid this false positive in the future?
- How would you estimate the financial exposure or scale of the problem before a full investigation is complete?
Question 4: RBI Compliance vs. User Friction
A new RBI guideline requires additional verification steps for transactions above a certain threshold. Product is worried this will hurt conversion on high-value transactions. How do you balance regulatory compliance with minimizing unnecessary friction?
Why interviewers ask this
This tests whether a candidate treats regulatory requirements as a floor to build on thoughtfully, rather than either resisting compliance for growth reasons or implementing it in the most bluntly restrictive way possible.
Example strong answer
"Regulatory compliance isn't a negotiable input here — the RBI requirement is the floor, not a trade-off variable, so my job isn't to decide whether to comply, it's to implement it in the way that satisfies the requirement with the least unnecessary friction on top of what's actually mandated.
I'd start by getting precise on exactly what the guideline requires — the specific threshold, the specific verification method mandated, and whether there's any flexibility in how the verification is implemented, since regulatory guidelines often specify an outcome or a minimum bar rather than a single implementation, and there can be legitimate room to design a smoother version that still fully satisfies the requirement.
For the actual implementation, I'd push for the verification step to be as contextual as possible — for instance, if a user has completed high-value transactions with the same recipient recently and passed verification then, there may be room to streamline re-verification rather than repeating the full flow from scratch each time, as long as that streamlining is genuinely compliant with the guideline's intent, not a workaround that technically evades it.
I'd also separate the conversation with product into two parts: what verification friction is legally required and non-negotiable, versus what additional friction we might be adding on top for our own risk-appetite reasons that could actually be relaxed. Sometimes teams over-implement a compliance requirement more conservatively than legally necessary, and it's worth explicitly checking whether that's happening here before assuming the entire friction cost is regulatory.
I'd bring product real data on the actual conversion impact once implemented — comparing before and after on the specific high-value transaction segment — because if there's meaningfully higher-than-necessary drop-off, that's useful evidence for whether we're implementing the requirement more restrictively than needed, which is a legitimate thing to revisit with legal and compliance, rather than something to just accept as the cost of doing business."
Follow-up questions
- Legal confirms there's genuinely no flexibility in the verification method — it has to be exactly as specified. How do you handle product's concern then?
- How would you measure whether the added friction is actually driving users to a competitor, versus just a temporary conversion dip that recovers?
Question 5: Rising Delinquency in One Cohort
PhonePe's lending portfolio shows rising delinquency in loans originated three months ago, specifically among borrowers in a particular city. Other cohorts look normal. How do you respond?
Why interviewers ask this
This tests portfolio risk monitoring and root-cause thinking — whether a candidate can distinguish an underwriting problem from an external economic shock, since the response to each is completely different.
Example strong answer
"The first thing I'd want to separate is whether this is an underwriting problem — we approved risk we shouldn't have for that cohort — or an external shock specific to that city that's affecting borrowers who would otherwise have been fine. Those point to very different fixes: one means tightening our model, the other means the model was reasonable given the information available at the time, and this is closer to unavoidable economic risk.
I'd check whether there was anything unusual about how that cohort was underwritten three months ago — a temporary change in approval criteria, a new acquisition channel or partner driving volume in that city during that specific window, or a data or model issue at that time that's since been fixed. If the underwriting process itself was consistent with other cohorts and other cities, that points away from a systemic underwriting flaw specific to this batch.
I'd also look for anything externally unusual in that city over the relevant period — local economic disruption, a major local employer layoff, a seasonal business cycle affecting a disproportionate number of borrowers there, since city-specific delinquency spikes are sometimes driven by shared local economic exposure that a purely individual-level credit model wouldn't have caught, because it's a correlated risk across borrowers rather than an individual creditworthiness issue.
Regardless of root cause, I'd recommend two tracks in parallel: an immediate portfolio-management response — tightening new originations in that specific city or segment until we understand the driver, and increasing monitoring frequency for that cohort specifically — and a slower root-cause investigation that doesn't block the immediate risk-containment step. I wouldn't wait for a fully confirmed root cause before taking any containment action, since delinquency that's already rising tends to compound the longer it's left unaddressed, but I'd also be careful not to overreact by cutting off an entire city's lending permanently based on three months of one cohort's data, since that risks an overcorrection if the driver turns out to be temporary and external."
Follow-up questions
- The investigation finds no clear underwriting flaw and no clear external shock either — the cause remains ambiguous. What do you recommend then?
- How would you distinguish this from normal cohort-to-cohort variance that doesn't actually require any action?
Preparation tip
PhonePe's risk interviews consistently reward candidates who explicitly separate "what I'd do in the next 30 minutes" from "what I'd investigate over the next weeks" — and who name the trade-off they're making rather than pretending there's a risk-free option. Candidates who treat every scenario as having one clean correct answer, without acknowledging the cost of the path not taken, tend to come across as less experienced than they are.