The Role, Decoded
What "Senior PM, Payments — Emerging Markets" actually means inside the Payments & Blockchain team, and the constraints that shape every answer you'll give in the loop.
The team mandate — "first and last mile of every dollar"
the Payments & Blockchain team is responsible for the first and last mile of every dollar (fiat or digital) that goes in or out of the company. That's the framing to internalize:
- First mile — a customer in São Paulo wires BRL via PIX, taps a card in Lagos, or scans a UPI QR in Bengaluru. The money must arrive, be reconciled, be credited, in seconds.
- Last mile — that same customer wants to withdraw GBP, BRL, INR, PHP, NGN back to a local account or wallet. The money must leave correctly, on the right rail, with the right compliance hooks, at the right cost.
Everything between the first and last mile is owned by other product teams (Pro trading, custody, futures, Krak). Payments owns the doors. If the doors don't open, nothing else matters.
You will be tempted in design rounds to talk about trading UX, custody, or crypto product surface. Resist. Your job is the door. Your KPIs are about who got through it, how fast, at what cost, and how often it slammed shut.
The portfolio model — rails × geographies
The JD says you'll "own and evolve a set of payment rails across both specific methods and geographic regions." That phrasing matters. You don't own "all of payments." You own a portfolio, defined two ways:
| Slice | What it means in practice | Examples |
|---|---|---|
| By method | A specific payment instrument or rail | UPI, PIX, SEPA Instant, FPS, local debit cards, Open Banking |
| By geography | A country or regional cluster | India, Brazil, SE Asia, MENA, Sub-Saharan Africa, LATAM |
| By customer segment | Who's on the rail | Retail consumer, Pro trader, Krak app user, institutional partner |
Most Payments PM portfolios are organized by some mix. A common shape: "You own LATAM deposits and SE Asia withdrawals plus the orchestration layer that routes between PSPs in those corridors." Expect ambiguity here in the interview — they may ask you to propose how you'd carve the portfolio.
What "high-growth and emerging markets" means concretely
"Emerging markets" is sloppy as a term — practitioners use it to mean markets where the local rails are different, the regulator is active, and the customer behavior diverges from the US/EU defaults. Operationally:
| Region | Dominant fiat rails | Regulator | Notable quirks |
|---|---|---|---|
| India | UPI, IMPS, NEFT, RuPay cards | RBI, NPCI | UPI is dominant for retail; RBI restrictions on crypto-INR are live and shifting |
| Brazil | PIX (instant), TED, boleto, Elo cards | BACEN | PIX free for P2P, MED/MEC recall windows, Open Finance live |
| SE Asia | PromptPay (TH), DuitNow (MY), PayNow (SG), GCash/Maya (PH), VietQR (VN) | BSP, MAS, BNM, BoT, SBV | QR-driven, mobile wallet first, GCash/Maya are de facto bank accounts |
| Africa | M-Pesa (KE), MoMo (across), Verve cards (NG), NIP | CBN, CBK, BoG | Mobile-money rails dominate; USSD still material |
| LATAM | PIX (BR), SPEI (MX), PSE (CO), Pago Móvil (VE) | BANXICO, Superintendencia | OXXO cash voucher in MX; cash-in/out points still material |
| MENA | Mada (SA), KNET (KW), Fawry (EG), local schemes | SAMA, central banks | Sharia-compliance overlay; local-acquirer mandates |
You will not be expected to be fluent in all of these. You will be expected to (a) know that the list looks like this, (b) be able to reason about an unfamiliar rail from first principles, and (c) have at least one corridor you can speak about confidently.
The triple stack — backend, UX, compliance, all in one PM seat
The JD calls out three explicit areas of responsibility, and they are unusually broad for a single PM:
"Lead cross-functional efforts spanning backend integrations, partner onboarding, frontend UX, and compliance-sensitive flows."
- Backend / orchestration — payment service architecture, PSP integrations, smart routing rules, idempotency, retry logic, vault/tokenization.
- Frontend / UX — the deposit and withdraw flows in the consumer app, Pro, Krak, and partner surfaces. 3DS step-up UX, BIN-aware optimisations, error-state copy, currency selection, fee disclosure.
- Compliance / fraud — Travel Rule for crypto, AML transaction monitoring, sanctions screening, chargeback policy, dispute workflow, local licensing constraints (EMI in UK/EU, MTLs in US).
Most fintech PM seats let you specialize in one of these. Here, you bridge all three on every project. Practice talking about all three in a single answer.
The multi-product surface — where your rails plug in
Your rails are not consumed by one app. They power four surfaces minimum:
| Surface | Customer | What they need from payments |
|---|---|---|
| Consumer-app product / app | Retail customer, often new to crypto | Frictionless first deposit, low minimum, instant credit, trust signals |
| Pro / active-trader product | Active trader | Higher limits, low fee, fast settle, predictable withdrawal SLA |
| Krak app | Consumer (newer the company product) | Local fiat in/out, spending, peer transfers |
| On/off-ramps | External partner integrations (e.g. wallets, dApps, third parties) | API-driven, headless, programmatic deposit / withdraw |
Implication: a single rail decision can cascade across four user types. You can't optimize for a single funnel; you have to think in shared-infrastructure tradeoffs.
Vendor-dependent reality
The JD ends with: "comfort managing multiple parallel workstreams in a fast-moving, vendor-dependent environment." That word — vendor-dependent — does a lot of work. It means:
- You don't control your own uptime. A PSP outage is your outage.
- You don't fully control your own cost. Interchange and scheme fees move; FX spreads move; partner deals expire.
- You don't fully control your own roadmap. If your acquirer doesn't support 3DS2 in a market, you can't ship 3DS2 in that market — until you switch acquirers, which is a year of work.
- Most of your job is partnership management at strategic level — RFPs, SLAs, escalation paths, monthly business reviews.
Strong candidates show comfort with this reality. Weak candidates pretend they can engineer around it.
The metrics you'll own (and be hired against)
Get fluent in these six numbers. They show up in every Payments PM round, often by name:
| Metric | What it measures | Why it matters |
|---|---|---|
| Authorization rate (AAR) | % of attempted payments approved by issuer/network | The headline KPI. 1pp lift = real money. |
| Settlement speed | Time from auth to funds usable | UX trust; capital cost |
| Cost per successful payment | All fees ÷ approved txns | The bottom-line counterweight to AAR |
| Conversion through funnel | Initiate → success | Captures abandonment, not just decline |
| Fraud / chargeback rate | bps of TPV | Scheme thresholds, partner risk profile |
| Time to availability | Funds credited to balance | Customer perceived speed |
See 07-evaluation-quality for how to define each rigorously and avoid the most common metric traps (e.g. conflating AAR with conversion).
The seniority clause
JD asks for "5-7+ years of product management experience." If you don't have that, the reframe:
JDs are written to attract a broad senior pool. Recruiters bring in candidates who don't tick every box when there's signal elsewhere — adjacent depth, learning velocity, motivation, referral. If you're in the loop, someone decided your conversation was worth their hour. The interview is to confirm that. Not to convince them you have years you don't.
See 02-positioning-from-scratch for specific language.
What to ask them
- "Which corridor in the portfolio do you see as the highest-leverage in the next 6 months, and what's currently blocking it?"
- "What's the current authorization rate baseline you'd hand me on day one, and how confident is the team in the measurement?"
- "How is the org currently splitting work between this PM seat and the engineering payment-orchestration leads? Where is the ambiguity?"
- "When was the last time you de-platformed a PSP, and what triggered it?"
- "For a new rail in a new market — what's the team's typical timeline from RFP signal to first successful production payment?"
These show you're thinking like the role, not interviewing into it.