Hiring Fintech PMs: Twelve Interview Questions That Actually Separate Senior From Junior

The standard fintech PM interview loop runs four to six conversations, draws from a SaaS-PM rubric, and produces candidates ranked by polish more than by depth. Most of the questions in market have been blog-posted, YouTube-prepped, and Glassdoor-leaked enough that a candidate with twelve practice rounds and a senior CV can comfortably out-perform a candidate with the actual operating chops.

The twelve questions below are the ones I have used (in three rounds of hiring payments PMs) where preparation hits diminishing returns. Each one is open-ended enough that the answer reveals depth. Each one has a "good answer shape" and a "bad answer shape". None of them is a brain-teaser.

Use them as the open conversation in 60-minute slots, not as multi-choice scoring items. The point is not to grade. The point is to see how the candidate thinks about the things that decide whether a payments PM ships or sinks.

1. Walk me through a payment from cardholder to merchant settlement

What it tests. Whether the candidate has actually internalised money movement, or has memorised a pipeline diagram.

Good answer. Names the stages, authentication, authorisation, capture, clearing, settlement, funding, and the parties at each stage (cardholder, issuer, scheme, acquirer, merchant). Distinguishes authorisation (a promise of funds) from capture (actually drawing them) from settlement (scheme netting) from merchant funding (the payout). Mentions float, the T+1 cycle, and which party carries the risk during each window.

Bad answer. "The card goes to the bank, then the merchant gets the money." Cannot distinguish auth from settlement. Glosses over the scheme. Treats the acquirer and the merchant as the same party.

Watch for. Whether the candidate explains the gap between authorisation and settlement, where the money actually lives in that window, and which party carries the risk of failure at each stage.

2. What's the difference between MIT, CIT, and recurring?

What it tests. Familiarity with PSD2 vocabulary at the operational level.

Good answer. CIT (customer-initiated transaction) is the cardholder making a purchase in the moment; SCA applies. MIT (merchant-initiated transaction) is the merchant pulling funds against a previously-authenticated mandate; SCA does not apply if the indicator is set correctly. Recurring is the subset of MITs that are fixed-amount, same-merchant subscriptions; an exemption applies that requires the first transaction to be authenticated. Mentions that the MIT indicator must be set at authorisation, not at capture.

Bad answer. Confuses MIT with recurring. Cannot explain when SCA applies and when it does not. Misses the prior-authentication-reference requirement.

Watch for. Whether the candidate can name a concrete failure mode (e.g., subscription amount drift breaking the recurring exemption) or only the textbook definitions.

3. A merchant tells you their auth rate is two points below the platform average. Where do you start?

What it tests. Diagnostic posture under ambiguity. The right answer is a method, not a list of fixes.

Good answer. Pulls the merchant's decline-reason mix and compares it to the portfolio. If "do not honor" dominates, investigates issuer-side risk perception (BIN-issuer relationships, merchant category code mismatch). If "fraud" decline dominates, looks at 3DS2 step-up rate and step-up abandonment. If insufficient funds dominate, may not be the platform's problem. Cuts the data by network, BIN range, transaction size, time-of-day, and 3DS2 outcome. Picks the largest contributing band and addresses it first.

Bad answer. "We'd enable 3DS2 and see what happens." Skips the diagnosis. Reaches for a feature.

Watch for. Whether the candidate names the decline-reason taxonomy and reads it as data, or treats auth-rate as a single number to push up.

4. Tell me about a time you killed a feature you championed

What it tests. Ego, judgment, and willingness to reverse a stated position when evidence changes.

Good answer. Specific feature, specific reason it was killed, specific data point that turned the call. Names the cost of the reversal (sunk effort, stakeholder relationships, narrative). Says what they would do differently next time, but does not over-apologise for the original call.

Bad answer. A feature that was killed because "the team didn't get behind it" (translation: the candidate cannot reverse course). Or a story about a feature the candidate did not really champion in the first place.

Watch for. Whether the candidate names the evidence that turned the call. Senior PMs reverse on data, not vibes.

5. How does dispute lifecycle differ from authorisation lifecycle?

What it tests. Whether the candidate has actually worked on the dispute surface (a common gap for SaaS PMs moving into payments).

Good answer. Authorisation runs in seconds; dispute runs in days-to-months. Authorisation involves cardholder, issuer, scheme, acquirer, merchant in real time; dispute involves the same parties in async exchanges through the scheme's case-management infrastructure. Authorisation has clear states (authorised / declined / referred); dispute has chargeback / representment / pre-arbitration / arbitration / second-chargeback. Authorisation evidence is real-time fraud signals; dispute evidence is structured (CE3.0 for Visa, equivalent for Mastercard). Names the reason-code taxonomy.

Bad answer. "A dispute is when the customer doesn't pay." Cannot name the lifecycle states. Treats the scheme portal as a black box.

Watch for. Whether the candidate mentions CE3.0 or scheme-equivalent evidence rules. The reason codes 10.4, 13.1, 13.5, 4853 should be in their working vocabulary if they have shipped dispute product.

6. What KPIs would you put on a $1B+ TPV payments business OKR slate?

What it tests. Whether the candidate has thought about payments OKRs as a discipline different from SaaS OKRs.

Good answer. Names the five metric families: volume + growth, quality of throughput (auth rate, 3DS2 health), money-handling reliability (settlement timing, reconciliation breaks, dispute cycle), risk + licence posture (fraud rate, AML closure, regulator findings), operating capacity (KYB cycle time, gateway uptime, ops headcount per $TPV). Mentions that 30–40% of payments KRs are guard-rails / adverse-direction. Names the floors that exist to protect the licence.

Bad answer. A list of SaaS KPIs adapted. MAU. Conversion rate. NPS. Does not mention any reliability or risk-side metrics.

Watch for. Whether the candidate volunteers floor-style KRs without prompting. The senior PM has internalised the asymmetric downside of payments work.

7. Walk me through how you'd write a PRD for a new recurring-billing feature

What it tests. Whether the candidate's PRD instincts have been shaped by payments work or by SaaS work.

Good answer. Names the nine sections of a payments PRD (problem, goal/non-goals, money movement + timing, regulator + scheme posture, reconciliation + ledger, failure modes, KPIs + acceptance criteria, rollout + reversibility, open questions). Names what is in the money-movement section for recurring, first transaction is CIT (SCA), subsequent are MIT (no SCA if flagged correctly), failure recovery for the retry ladder, refund/dispute mechanics for partial captures. Names the reconciliation pairing for recurring (each scheduled charge has a defined settlement file row).

Bad answer. Reaches for a SaaS PRD template. Talks about user stories, wireframes, A/B tests. Does not mention money movement or reconciliation. Treats recurring as a UX feature.

Watch for. Whether the candidate mentions the failure modes (subscription-amount drift breaking the recurring exemption, lapsed cards needing reissuance webhook handling, dunning logic per market).

8. What did you build with engineering that you wouldn't have shipped without them pushing back?

What it tests. Whether the candidate genuinely collaborates with engineering or just hands them PRDs.

Good answer. A specific feature where engineering pushed back on the design and the candidate changed it. Names what engineering caught, usually a hidden complexity, a scaling implication, or a failure mode the candidate had missed. Credits engineering by name (in spirit if not literally).

Bad answer. A feature engineering "complained about" but the candidate "still got shipped". A defensive answer about prioritisation.

Watch for. Tone. Senior PMs treat engineering as co-owners. Junior PMs treat engineering as a service provider.

9. A regulator publishes a circular tomorrow mandating a new compliance flow with a six-month deadline. The roadmap is already full. What happens?

What it tests. Decision-making posture under regulatory pressure. Whether the candidate has shipped under a regulator deadline.

Good answer. Reads the circular for the actual scope (not the marketing summary). Maps the work, what is greenfield product, what is config, what is policy. Pulls the highest-RICE existing roadmap item that the regulator work displaces. Re-ranks the slate; pulls the displaced item to Q+1 or Q+2 with a documented owner. Communicates to the merchant base and the org, what is shipping, what is slipping, why. Briefs the engineering team on the new cadence within 48 hours.

Bad answer. "We'd talk to legal and see." Or, "We'd push hard to do both." Does not name the trade-off. Treats the roadmap as fixed.

Watch for. Whether the candidate accepts the trade-off without hedging. Senior PMs in payments have internalised that regulators win priority arguments.

10. How do you decide whether to build, buy, or partner for fraud detection?

What it tests. Strategic instinct on the build/buy/partner axis in a domain where buying is often the right answer.

Good answer. Names the criteria: time-to-deploy, model performance on the actual portfolio, lock-in cost, data sovereignty constraints, integration footprint, ongoing tuning capacity. For most platforms below ~$5B TPV, buy or partner wins on the first criterion alone (a vendor with 100M transactions of training data outperforms a portfolio with 100k). At larger scale, build becomes viable for the senior fraud surface (challenger scoring) while still buying for the heavy lifting (sanctions screening, device fingerprinting). Treats build/buy/partner as a portfolio decision, not a single choice.

Bad answer. "We'd build it." Or "We'd buy from vendor X" without naming the criteria.

Watch for. Whether the candidate distinguishes between build/buy at different layers of the fraud stack. The reflexive answer is wrong; the layered answer is right.

11. What's the worst incident you've shipped, and what did you learn?

What it tests. Self-awareness, post-mortem discipline, and willingness to own failure.

Good answer. A specific incident, with concrete impact (number of affected transactions, financial impact, regulator implication if any). Owns the part of the call the candidate made wrong. Names the systemic fix (what changed in the post-mortem). Does not over-blame the team or under-blame themselves.

Bad answer. A small bug that "we fixed quickly". Or an incident that "wasn't really our fault". Or a deflection.

Watch for. Whether the candidate has actually been in the room when something broke. Senior payments PMs almost always have at least one production incident on their record; the ones who claim they don't have either never shipped at scale or are not telling the truth.

12. Why payments? Why not something easier?

What it tests. Motivation. Whether the candidate genuinely chose this domain or fell into it.

Good answer. A specific reason that does not sound rehearsed. Often something tactile, they shipped a payment feature once and saw something light up in production that no SaaS ship ever had. Or the regulatory complexity intrigued them. Or the cross-functional surface area (engineering + finance + compliance + ops) was the part of the work they wanted to spend a career in.

Bad answer. "Payments are the future of money." Or, "Fintech is a huge market." Generic, market-sized answers.

Watch for. Whether the candidate has stayed in payments long enough to know what the work is actually like. Senior payments PMs are often partly trapped (it is hard to leave once you have ten years of scheme knowledge) and partly committed (the work is concrete in a way SaaS rarely is). The honest answer often contains both.

How to score the round

Resist the temptation to grade each question 1–5. The signal in a senior PM interview is cumulative: a candidate who answers eight of twelve well at the senior level is hireable; a candidate who answers eleven well at the mid-level is not.

Specific senior-level patterns to watch for, across all twelve answers:

• Specificity. Concrete examples, named features, real numbers.
• Trade-offs named. Senior PMs do not hide the cost side of decisions.
• Self-correction. When the interviewer pushes back, the candidate updates rather than defends.
• Engineering reverence. Senior PMs treat engineering as co-thinkers, not as implementers.
• Regulator literacy. A working vocabulary on PSD2, SCA, PCI, AML, scheme rules. Not encyclopedic, the senior PM names the parts that touched their work.

Specific junior-level patterns:

• Framework reflex. Every answer routes to RICE / OKRs / Jobs-to-be-Done without acknowledging the framework's limits.
• Defensive deflection. Failures are always "the team" or "the context", never the candidate's call.
• Buzzword density. "Agentic", "platform", "API-first", "AI-powered" without a concrete grounded example.
• No-incident track record. Has been in payments three years and has not shipped anything that broke. Either has not shipped, or is hiding.

What this rubric does not test

A few things the twelve questions deliberately do not measure:

• Wire-frame craft. Important; better assessed by a portfolio walkthrough.
• Stakeholder management at executive level. Better assessed in a peer-feedback round.
• Engineering hands-on depth. Important; better assessed by an engineering-PM round.
• Data literacy in detail. Better assessed with a working dataset exercise.

The twelve are about operating posture in payments. The other surfaces matter; they get their own rounds.

A note on diverse hiring

The candidate pool for senior payments PMs has historically been narrow. Two practical patterns that widen it without lowering the bar:

• Run the rubric against the SaaS-PM-with-fintech-exposure pool. Strong SaaS PMs who have worked on adjacent fintech surfaces (subscription billing, marketplace payouts, accounting integration) frequently answer 8+ of these well with two months of immersion.
• Run the rubric against the engineering-lead-moving-to-PM pool. Engineering leads with 3–5 years of payments work often crush questions 1, 2, 5, 7, 8 and benefit from coaching on 4, 11, 12. The cross-over is a strong source of senior PMs.

Both pools widen the funnel. Neither lowers the bar.

FAQ

How long should the interview be? 60 minutes. Twelve questions is too many for one round; pick six per round and run two product-depth rounds.

Should you give candidates the questions in advance? No. The point is to see how they think on the spot, not to test their preparation. (Senior candidates who have read this post will recognise the shape; that is fine, the answers still reveal depth.)

What about take-home exercises? A short take-home (a real PRD against a real problem the team is facing) is a strong companion to the live rounds. Keep it under 4 hours; respect the candidate's time.

How is this different from a SaaS PM interview? Five of the twelve questions (1, 2, 3, 5, 9) are payments-specific. Four (6, 7, 10, 12) take SaaS analogues and add a payments lens. Three (4, 8, 11) are domain-agnostic but tend to reveal payments depth when shared examples are used.

Should you hire a payments PM with no payments experience? Sometimes, at junior and mid levels with strong fundamentals. Rarely at senior. Senior payments PMs need the scheme knowledge, the regulator instinct, and the ops vocabulary in their bones; coaching from scratch at that level takes 18 months you do not have.

What's a fair compensation range? Geographic, but as of 2025: senior payments PMs in UAE, KSA, Singapore, London, NYC are commanding total compensation in the $200–400k+ range. The market is tighter than SaaS at the equivalent level because the candidate pool is smaller.

---

If this resonated, also read Product Management for Payments Platforms, CSPO + RICE in Practice, and Payments PRD Template.