razorpay Machine Learning Engineer Interview: Questions, Experience & Prep (2026)

Razorpay is one of India's largest payment infrastructure companies, serving millions of merchants across India and Southeast Asia. The ML team works on problems like fraud detection, payment success optimisation, credit risk scoring for Razorpay Capital, and merchant analytics. With 42 open ML roles on knok jobradar as of July 2026, the company is actively expanding its data and ML function.

Candidates report the interview process typically spans four to five rounds: an initial screening call, one or two technical rounds covering ML concepts and coding, a system design round focused on large-scale ML infrastructure, and a final culture or leadership round. The process is known for being domain-heavy, with a strong emphasis on real-world payment scenarios rather than abstract puzzles.

Razorpay interviewers value engineers who connect ML theory to business outcomes. Understanding why fraud detection precision matters differently from recall, or how latency constraints shape model architecture, will set you apart from candidates who only know the textbook definitions.

These questions reflect candidate reports and the known focus areas of Razorpay's ML team. They typically appear across technical and system design rounds.

1. How would you build a real-time fraud detection model for a payment gateway handling very high transaction volumes?
2. Explain how you would handle severe class imbalance in a fraud dataset where fraudulent transactions are a tiny fraction of all payments.
3. How would you design a credit scoring model for small merchants applying for a Razorpay Capital loan?
4. Razorpay's payment success rate directly affects merchant revenue. How would you build a model to optimise payment routing?
5. Walk through how you would design a feature store for a large ML platform serving multiple teams.
6. How do you detect and respond to concept drift in a production fraud model, especially after a major market shift like a UPI policy change?
7. Describe your approach to designing a low-latency ML inference system. What trade-offs do you make between model complexity and response time?
8. How would you A/B test a new credit risk model in a live lending product without exposing the business to unacceptable risk?
9. Explain precision and recall. In a payment fraud use case, which matters more and why?
10. How would you explain a model's fraud flag decision to a merchant who disputes it?
11. Describe how you approach feature engineering for transaction time-series data.
12. Tell us about a time a data quality issue hurt your model in production. How did you find it and fix it?

Q: How would you build a real-time fraud detection model for a high-volume payments platform?

*Situation:* At my previous company, we processed a large volume of digital transactions daily and were seeing an increasing rate of fraudulent chargebacks that were hurting merchant trust and revenue.

*Task:* I was asked to build and deploy a fraud detection system that could flag suspicious transactions within a tight latency budget without blocking legitimate payments.

*Action:* I started by analysing historical transaction data and working with the risk team to label fraud cases. I engineered features like velocity checks (how many transactions a card had made in a short rolling window), merchant category codes, device fingerprint signals, and geolocation anomalies. I trained a gradient boosting model for offline scoring, then worked with the infra team to deploy it behind a feature store using fast in-memory retrieval. I tuned the decision threshold for high recall to catch more fraud even at the cost of some false positives, and built a human review queue for borderline cases so legitimate transactions were not automatically blocked.

*Result:* Fraud-related chargebacks dropped noticeably according to the risk team's internal reports, and average inference latency stayed within the product's target. The model went into production within a short timeline and the review queue reduced the manual workload compared to the previous rule-based approach.

---

Q: Tell us about a time a data quality issue hurt your model in production.

*Situation:* Several months after deploying a merchant risk-scoring model, I noticed the model's precision was degrading steadily in our weekly monitoring reports.

*Task:* I needed to find the root cause quickly because the model was used to auto-approve or reject merchant onboarding applications, and incorrect rejections were hurting sales.

*Action:* I ran a data pipeline audit and compared the feature distributions in the current serving data against those at training time. I found that a third-party bureau we relied on for business vintage data had quietly changed their API response format, causing one key feature to return null values that were being silently filled with a default of zero. This was creating a systematic bias toward rejecting newer businesses. I filed a bug with the data engineering team, patched the ingestion pipeline, and retrained the model on clean data.

*Result:* Precision recovered to near its original level within a couple of weeks of the fix. We also added distribution-shift alerts for all external data sources so this class of issue would surface much faster in future.

---

Q: How would you design an A/B test for a new credit scoring model?

*Situation:* I was part of a team at a fintech building a new credit model intended to replace the existing one for small business loans.

*Task:* We needed to validate the new model's performance in production without exposing the business to outsized credit risk during the test period.

*Action:* I proposed a shadow-mode phase first, running the new model in parallel for several weeks and logging its decisions without acting on them, so we could compare its outputs against the live model and spot divergences early. Once satisfied with offline metrics, we moved to a traffic-split experiment where a small fraction of new applicants were scored by the new model. We defined clear success metrics including default rate and approval rate, and set a stopping rule if the new model's default rate crossed a pre-agreed threshold. We also stratified the test to exclude high-value merchants until confidence was high enough.

*Result:* The new model showed a better approval rate on lower-risk applicants in the test cohort, according to the team's internal analysis, without a meaningful increase in defaults. We rolled it out fully after the test cohort's loan tenure gave us enough outcome data to be confident.

For ML system design questions: Lead with the problem framing (what are you predicting, what is the cost of a wrong answer), then walk through data collection and labelling, feature engineering, model selection, offline evaluation, and finally deployment and monitoring. Always tie your choices back to the payment domain. If you mention latency, say why it matters for a checkout flow specifically.

For 'explain a concept' questions: Define the term clearly, give a concrete payments example, and then explain the practical implication. For precision vs recall, define both, then say something like 'in fraud detection, a false negative means missed fraud and a false positive means a blocked legitimate payment, and the right balance depends on the business risk appetite.' Follow up by describing how you would tune the threshold in practice.

For behavioural questions: Use a STAR structure (Situation, Task, Action, Result) and keep the Situation and Task brief, two to three sentences at most. Spend most of your answer on the Action, since Razorpay interviewers want to understand how you think and what you personally drove, not just what the team did. End with a concrete, honest Result, even if it includes a setback and what you learned.

For 'how would you improve X' questions: Start by asking a clarifying question out loud, such as 'Is the main constraint latency, accuracy, or engineering cost?' This signals senior thinking. Then outline two or three approaches with trade-offs rather than jumping straight to one answer. Interviewers want to see your reasoning process, not just the conclusion.

Domain fluency over textbook answers. Razorpay interviewers want to see that you connect ML concepts to payment-specific problems. Saying 'I would use SMOTE for class imbalance' is acceptable. Adding 'and in a fraud context, I would also consider the cost of false negatives when setting my threshold' is what gets you to the next round.

Production mindset. Candidates who have shipped models, monitored them, and dealt with real-world issues like data drift, pipeline failures, or sudden distribution shifts stand out clearly. Bring examples of things that went wrong and how you drove them to resolution.

System design at scale. Razorpay's payment volume is substantial, so interviewers test whether you think about latency, throughput, and fault tolerance when designing ML systems. Practise articulating trade-offs clearly: batch vs streaming, model complexity vs inference cost, accuracy vs explainability.

Clear communication. Because ML decisions at Razorpay directly affect merchants' money and creditworthiness, interviewers value candidates who can explain a model's behaviour in plain language. Practise answering the question 'how would you explain this decision to a merchant?' before your interview.

Ownership and initiative. Razorpay's culture rewards people who spot problems and drive them to resolution without waiting to be told. In behavioural rounds, look for opportunities to share examples where you identified an issue independently and saw it through to a fix.

Week 1: ML fundamentals and domain context

Revise classification metrics (precision, recall, F1, AUC-ROC) with a focus on imbalanced datasets. Study gradient boosting methods such as XGBoost and LightGBM, which appear frequently in payments fraud and risk modelling. Read publicly available case studies on fraud detection and credit scoring in fintech to build domain vocabulary and sharpen your ability to speak the interviewer's language.

Week 2: System design for ML

Study the components of a production ML platform: data pipelines, feature stores, model serving, and monitoring. Practise designing systems with latency and scale constraints out loud, as if explaining to an interviewer. A question like 'design an ML system that scores every payment in real time' is a strong candidate for a Razorpay system design round and is worth practising end-to-end.

Week 3: Coding and SQL

Candidates report coding questions typically cover data manipulation using Pandas and SQL, implementing ML algorithms from scratch, and occasionally algorithmic problem-solving. Practise on a competitive coding platform at a medium difficulty level and time yourself, since Razorpay rounds are structured.

Week 4: Behavioural preparation and mock interviews

Write out five or six STAR stories covering: a model you built end-to-end, a production failure you resolved, a time you influenced a non-technical stakeholder, and a disagreement you navigated on a technical decision. Do at least a couple of mock interviews with someone who will give honest, critical feedback rather than reassurance.

If you are actively job searching at the same time, knok checks 150+ job sites nightly, applies to jobs matching your resume, and messages HR for you, so your applications keep moving while you focus on interview preparation.

Giving textbook answers without payment context. Saying 'I would use a random forest' without explaining why it suits a fraud detection problem, or without discussing how you would set the decision threshold based on business risk appetite, signals shallow preparation to a Razorpay interviewer.

Skipping the monitoring step in system design. Many candidates describe building and deploying a model but forget to mention how they would detect when it starts performing badly in production. Razorpay interviewers specifically probe this because payment models can degrade quickly when user behaviour shifts.

Using 'we' instead of 'I' in behavioural answers. It is fine to set context by mentioning your team, but interviewers want to know what you personally did. Vague team-level answers make it impossible for them to assess your individual contribution and ownership level.

Not asking clarifying questions in system design. Jumping into an answer without asking about constraints (latency requirements, data volume, team size) looks reactive rather than senior. A quick scoping question before you start shows that you think like an engineer, not like someone reciting a memorised answer.

Overcomplicating the solution. Candidates sometimes propose a deep learning approach when a well-tuned gradient boosting model would be more appropriate given latency and explainability requirements. Razorpay values pragmatic engineering. Simpler, well-justified solutions often score higher than impressive but impractical ones.

Ignoring business impact. Framing everything in pure ML terms (loss functions, accuracy scores) without tying it to business outcomes (chargeback rate, merchant approval rate, revenue at risk) can make you seem detached from how the product actually works and what the company cares about.