OKRs at $1B+ TPV: How Payment Goals Differ From SaaS Goals
There is a moment in every payments business, somewhere around the third year, when annualised total payment volume crosses a billion and the OKRs the team has been writing for five quarters quietly stop making sense.
The phrasing is still right ("Increase X by Y by date Z"). The cadence is still right (quarterly with monthly check-ins). The cascading still works (company → product → squad). What breaks is what the goals are measuring. The SaaS OKR playbook the team learned in the early years rewards growth, activation, retention, and revenue. The payments operating reality at $1B+ TPV rewards stability, audit posture, settlement reliability, and risk-adjusted throughput.
A team that does not re-write its OKRs at this scale spends the next two years optimising the wrong thing.
This is what the rewrite looks like.
Six differences from SaaS OKRs
1. The numerator is money, not users.
SaaS OKRs measure user-side metrics (MAU, retention, NPS, conversion). Payments OKRs at scale measure money-side metrics (TPV, settled volume, authorised volume, dispute volume, recovery rate). A SaaS team that grows MAU 30% wins. A payments team that grows TPV 30% wins only if dispute volume, fraud rate, settlement breaks, and licence-risk indicators have not grown faster.
2. Guard-rails are first-class OKRs, not just dashboards.
In SaaS, "do not break things" is implicit. In payments, "do not break things" is half the OKR list, written as numeric guard-rails with hard floors. "Maintain authorisation rate at 92%+" is an OKR. "Keep fraud rate under 12 bps" is an OKR. Guard-rails are not nice-to-have; they are the boundary inside which growth OKRs are allowed to run.
3. Time horizons stretch.
SaaS OKRs run quarterly with bias. Payments OKRs run quarterly because the cadence is shared with the rest of the org, but many of the metrics they touch (scheme certification, regulator engagement, settlement-engine refactor, dispute-cycle optimisation) do not move on a quarter-by-quarter rhythm. The senior payments leader writes the quarterly OKR in the context of an 18-month roadmap and accepts that some quarters move 30% of the journey and some quarters move 5%.
4. External counterparties get veto.
A SaaS OKR is something the team can deliver if it builds and ships well. A payments OKR depends on scheme certification timelines, regulator approvals, sponsor-bank decisions, and correspondent-bank readiness. Half the OKRs the team writes have an external dependency that can move outside the quarter window. The grading system has to allow for "we did the work, the external dependency moved." Teams that punish themselves for external slippage stop writing ambitious OKRs by the second quarter.
5. "Done" is a five-month tail.
A SaaS feature is done when it ships and is used. A payments feature is done when it has run a full settlement cycle, been through a month-end reconciliation, survived an audit pass, and weathered the first dispute. The OKR cycle that books "completed" at launch books incomplete work as complete. Senior payments OKRs distinguish between "shipped" and "stabilised", and reward only the latter.
6. Adverse goals exist.
SaaS rarely has metrics the team wants to drive down. Payments has many: dispute rate, refund rate, fraud rate, reconciliation breaks, support contacts, regulator findings, audit observations. A payments OKR list that is not 30–40% adverse-direction metrics is missing half the work.
The metric families that matter at $1B+ TPV
A working frame for senior payments OKRs uses five metric families. Every quarter, the OKR slate touches all five.
Volume and growth. TPV, authorised TPV, settled TPV, merchant count, transaction count, new-rail share. These are the SaaS-shaped metrics. They look familiar.
Quality of throughput. Authorisation rate by network, decline-reason mix, 3DS2 step-up rate, frictionless rate, recurring success rate. These are the metrics where the SaaS playbook is least at home, because the levers are part product, part scheme, part fraud model, part issuer relationship.
Money-handling reliability. Settlement timing adherence, reconciliation break rate, ledger-to-statement match rate, refund completion time, dispute cycle time. These are the metrics that the SaaS OKR playbook simply does not have.
Risk and licence posture. Fraud loss rate, AML alert closure time, regulator finding count, sanctions screening false-positive rate, CSP attestation status, audit observation count. These are licence-protecting metrics; they belong on the OKR slate at every level, not in a separate compliance scorecard.
Operating capacity. Time-to-onboard a new merchant, KYB cycle time, gateway uptime, support contact rate per 1000 transactions, ops headcount per $100M settled. These are the metrics that decide whether the platform scales or buckles in the next year.
A senior payments OKR slate has at least one objective per family. A slate that has four growth objectives and no risk objectives is the slate of a team that has not yet been through an audit.
A worked example: one quarter at $2.5B annualised TPV
Imagine a regional acquirer-processor, annualised TPV $2.5B, operating in three primary markets, 1,800 active merchants. The senior leader writes the Q-N OKR slate.
Objective 1, Lift quality of throughput without lifting risk
Why this objective. Authorisation rate on the iOS Safari + cross-border combination is 4 points below the rest of the portfolio. Closing the gap is worth roughly $90M of incremental successful TPV per quarter.
| Key Result | Direction | Target |
|---|---|---|
| Increase iOS Safari + cross-border auth rate from 88% to 92% | Up | +4 pts |
| Hold overall fraud rate below 12 bps | Floor | < 12 bps |
| Hold 3DS2 step-up rate below 22% on the affected traffic | Floor | < 22% |
Two of the three KRs are guard-rails. They are written as KRs, not footnotes, because they are first-class.
Objective 2, Compress dispute cycle time without lifting loss rate
Why this objective. Dispute cycle time is currently 21 days median; merchant escalations on the dispute portal are at an all-time high; large merchants are threatening to multi-source.
| Key Result | Direction | Target |
|---|---|---|
| Reduce median dispute cycle time from 21 to 12 days | Down | -9 days |
| Hold dispute loss rate (lost / total disputed) at or below current 38% | Floor | ≤ 38% |
| Reach 95% merchant adoption of the new evidence-upload flow | Up | ≥ 95% |
Objective 3, Get the network-tokenisation rollout to GA across the portfolio
Why this objective. Central-bank deadline; scheme push; PCI scope reduction; foundation for several next-quarter features.
| Key Result | Direction | Target |
|---|---|---|
| Tokenise card-on-file for 90% of active merchants | Up | ≥ 90% |
| Maintain post-tokenisation auth rate within 0.5pt of pre-tokenisation baseline | Floor | ± 0.5 pt |
| Pass EMVCo / scheme certifications with zero outstanding findings | Binary | 0 findings |
Objective 4, Bring CSP attestation back onto cadence and close all audit observations
Why this objective. Past attestation slipped two cycles; current audit has 7 open observations; correspondent banks are starting to ask.
| Key Result | Direction | Target |
|---|---|---|
| Submit CSP attestation by the scheme-set deadline with no late evidence | Binary | On-time submission |
| Close all 7 open audit observations | Down | 0 open |
| Establish quarterly evidence-collection cadence with named owner per control | Binary | Adopted |
Objective 5, Reduce ops cost per $100M of settled volume
Why this objective. Ops headcount has grown linearly with TPV for three quarters. The internal target is to flatten that curve.
| Key Result | Direction | Target |
|---|---|---|
| Cut manual reconciliation break-handling hours by 40% | Down | -40% |
| Hold settlement break rate at or below current 0.04% | Floor | ≤ 0.04% |
| Bring KYB median cycle time from 9 days to 4 days | Down | -5 days |
Five objectives. Eighteen key results. Six of them are guard-rails. Three are adverse-direction. Two are binary. Every metric family is represented.
A SaaS OKR slate for the same business would have had four KRs about TPV growth and merchant count, and not noticed that disputes were eating margin, attestation was slipping, or ops cost was scaling linearly.
How the slate is graded
Senior payments OKRs are not graded on a single number. The slate has three grades, scored separately.
Growth grade. The Volume / Growth and Quality-of-Throughput KRs. Scored against ambition: 0.7 is on target for stretch goals; 0.5 is acceptable for cautious quarters; below 0.5 prompts a strategy review.
Reliability grade. The Money-Handling, Risk, and Operating KRs. Scored against the floors and binary commitments: any breach of a floor is a 0.0 on that KR regardless of growth elsewhere. Reliability KRs do not have stretch grades; they are pass-fail.
Externalities grade. A note (not a number) per KR that was affected by scheme, regulator, sponsor-bank, or correspondent-bank decisions outside the team's control. The next-quarter slate is adjusted by what the externalities grade revealed.
The slate as a whole is "delivered" only if reliability is 1.0 and growth is at least 0.5. A slate that hits 0.9 on growth but breaks one reliability floor is not a delivered slate; it is a near-miss the leadership team must explain to the board.
What the OKRs do not say
Three categories of work are deliberately not on the OKR slate.
Hygiene work. Bug fixes, dependency upgrades, small UX improvements. These are tracked in the engineering backlog and reported as throughput, not as goals.
Internal projects without external evidence. Refactors that have no observable customer or audit consequence belong on the engineering plan, not the company OKR slate.
Aspirational themes. "Be best-in-class on disputes" is a theme, not an OKR. If it cannot be expressed as a numeric or binary KR, it does not belong on the slate.
The reason the slate is disciplined about exclusion is that payments OKRs at scale are read by the board, by the regulator (sometimes), and by the next round of investors. Vague themes signal a leadership team that does not yet know what it is measuring.
The senior-leader tell
The interview question that separates senior payments leaders from middle-management ones is: "Show me an OKR slate you wrote at $1B+ TPV and walk me through why each objective made the slate."
The middle-management answer reads the slate. The senior answer narrates the trade-offs: why this growth objective was sized at +4 points and not +6, why the floor on fraud was set at 12 bps and not 10, why the CSP attestation made the slate as its own objective rather than rolling under "operating capacity", and what was deliberately not on the slate.
That conversation is the operating posture the rest of the team learns from. It is also the conversation the best CPOs in payments can have unprompted. If a payments leader cannot have it, they are not yet writing the OKRs at the scale their title claims.
FAQ
How does this differ from a SaaS OKR slate? SaaS OKRs are mostly upward-direction growth metrics. Payments OKRs at scale are 30–40% adverse-direction or floor-style guard-rails, because protecting the money-handling and licence is a first-class outcome, not a hygiene assumption.
Are guard-rails really OKRs, or are they a separate scorecard? Both views work; the senior posture is that they are KRs. Treating them as a separate scorecard lets the team rationalise growth-at-risk decisions. Putting them on the OKR slate forces the trade-off to be visible in the same review meeting.
What about engineering team OKRs vs product team OKRs? At $1B+ TPV, the line blurs. Settlement timing is owned by engineering operationally but tracked by product because it is a customer-visible metric. The slate is set jointly. Splitting product and engineering slates by function rather than by outcome creates the silos the OKR ritual is supposed to dissolve.
How long should objectives be written for? A typical senior payments objective is one short sentence, three to four KRs. If the objective needs a paragraph to explain, it is a strategy, not an objective.
What if the regulator changes the deadline mid-quarter? The slate adjusts mid-quarter, with a documented amendment. Treating the slate as frozen for three months in a regulated business is theatre; the rituals exist to align the team, not to ignore reality.
Does the same slate work at $10B+ TPV? The structure scales. The metric families stay the same; the targets get harder and more granular (e.g., guard-rails per rail, not portfolio-wide; fraud floors per merchant category). The five-family discipline holds.
If this resonated, you might also want to read CSPO + RICE in Practice: A Real Payments Roadmap Walkthrough, Payments PRD Template: The Nine Sections Every Senior PM Writes, or Product Management for Payments Platforms.
Rizwan Zafar — Chief Product Officer · Payments, Fintech & AI.
Related reading
A payments PM is a SaaS PM with three extra constituencies and one extra reflex. Get the reflex wrong and the other constituencies stop trusting you.
RICE is a clean ranking framework that does not know payments exists. CSPO is a clean product mindset that does not know prioritisation maths. Put together, with a risk-adjusted overlay, they become a working operating system for a payments backlog. Here is the walkthrough.
A payments PRD is not a SaaS feature brief with a money movement appendix. It has to explain state, risk, settlement, compliance and operational failure before engineering starts.