PayPal, Razorpay & Paytm: Data Science / ML

1. Understand the target and the grain (e.g. predict monthly merchant volume). Check duplicates, the date range and leakage.
2. Clean: - Fix data types. - Handle missing values (median + indicator) and outliers (cap or log). - Encode categoricals. - Use time-aware splits.
3. Baseline: last value or mean; then linear/Ridge regression; then gradient boosting.
4. Evaluate: RMSE/MAE (and MAPE if the scale varies); residual plots; error by segment.
5. Explain: coefficients or SHAP; document the assumptions.

• Hypothesis and metric: the primary metric is payment success rate; guardrails are latency, refunds and support tickets.
• Sample size: from the baseline rate, the minimum detectable effect, α = 0.05 and power 0.8. Randomise by user (not session), run full weeks, and avoid peeking (or use sequential testing).
• Analysis:
• Two-proportion z-test or a bootstrap confidence interval.
• Check for sample-ratio mismatch.
• Segment checks (device, bank).
• CUPED for variance reduction.
• Decide: ship if the lift is significant and the guardrails hold. Report the effect size with its confidence interval.

• For independent, identically distributed samples with finite variance, the sampling distribution of the mean approaches a normal distribution N(μ, σ²/n) as n grows, regardless of the underlying distribution.
• Why it matters: it justifies z/t tests and confidence intervals for means and proportions in A/B tests, even for skewed metrics such as revenue, given enough samples.
• Caveats: heavy tails need larger n (or bootstrap / log transforms), and dependent samples break the assumption.

• z-test: the population variance is known, or the sample is large (n > ~30, by the CLT). Proportions in large A/B tests use z-tests.
• t-test: the variance is unknown and estimated from a small sample, using the t distribution with heavier tails. Use Welch's t-test when variances are unequal; use a paired t-test for before/after on the same units.

WITH first_month AS (
  SELECT merchant_id, DATE_TRUNC('month', MIN(txn_date)) AS cohort
  FROM transactions GROUP BY merchant_id
), activity AS (
  SELECT DISTINCT merchant_id, DATE_TRUNC('month', txn_date) AS active_month FROM transactions
)
SELECT f.cohort,
       (EXTRACT(YEAR FROM a.active_month) - EXTRACT(YEAR FROM f.cohort)) * 12
         + EXTRACT(MONTH FROM a.active_month) - EXTRACT(MONTH FROM f.cohort) AS month_n,
       COUNT(DISTINCT a.merchant_id) AS active
FROM first_month f JOIN activity a USING (merchant_id)
GROUP BY 1, 2 ORDER BY 1, 2;

• Divide by the cohort size at month 0 to get retention percentages, and plot them as a heatmap.

• Corpus: fraud playbooks, past case notes, policy rules, typology write-ups.
• Assistant flow: 1. The investigator opens a case. 2. The system retrieves similar past cases (embedding similarity over case summaries) and the relevant playbook steps. 3. The LLM drafts a case summary, a suggested next action and the evidence checklist, with citations.
• Controls:
• The LLM never decides alone; the human investigator approves.
• PII is minimised; access is role-based.
• Audit logs.
• An evaluation of summary faithfulness and time-to-resolution.
• Impact metric: cases handled per investigator per day, plus decision consistency.

• An evolutionary optimisation method: 1. Keep a population of candidate solutions. 2. Evaluate their fitness. 3. Select the best, apply crossover (combine parents) and mutation (random changes). 4. Repeat for many generations.
• Good for non-differentiable, combinatorial search: feature selection, hyperparameter search, scheduling, routing.
• Trade-offs: no gradient needed, but slow and stochastic. Alternatives are Bayesian optimisation or simulated annealing.