The Payment Product Decision Has the Wrong Owner

A bank chartered this correctly, on paper. The head of payments product is named in the decision matrix, the launch review has a standing agenda, and the sign-off is logged in the system everyone points to when asked who decided. Even so, the same failure keeps recurring: a new method launches on schedule, the fraud-loss curve moves in month two, and by month five the method is quietly unwound or restricted to a smaller merchant set than the business case assumed. The postmortem calls it a modeling miss and schedules a review of the fraud model.

It was not a modeling miss. The launch was authorized by the function positioned to want it, and no function that wants an outcome is well positioned to weigh that outcome's downside honestly. The decision right existed, was written down, and was exercised exactly as designed. It simply sat with the wrong desk, and a decision right sitting with the wrong desk produces confident, well-documented, wrong calls at a steady rate — which reads, from the outside, exactly like a modeling problem, and gets treated as one, every time.

How the assignment actually happens No committee votes to hand product the decision right. It accretes. Product owns the roadmap, so product writes the business case. Product wants the launch date, so product schedules the review. Over a few cycles the review stops being a check the proposal passes through and becomes a formality the proposal's own sponsor chairs — attended by the same functions as before, but attended now in an advisory capacity rather than a deciding one, a shift nobody voted on and few people would defend if it were stated plainly.

A companion piece traced the opposite failure: a proposal with no chartered owner at all, stalling for months on whichever objection reaches it first, because no function's sign-off is designed to end the conversation. This failure is quieter, and in a sense more dangerous, because the decision does get made, on schedule, by someone with a title for it. Nobody in the room experiences it as a gap. The question worth asking is not whether the decision was made. It is which title made it, and whether that title was ever the right one to be holding the pen.

Where the downside actually lands A new payment method's fraud-loss curve lands on risk's books, not product's. Its settlement gap, if the method has one, becomes compliance's exposure to explain at the next audit. Its disputed-transaction volume lands on whoever staffs the call center, which is rarely payments product. Product's own metric — a method shipped, adoption trending up in the first quarter — is fully satisfied the day the feature goes live, months before any of the downside metrics have had room to move and long before anyone is asked to reconcile the launch against what it actually cost.

• Fraud loss typically shows up two or three billing cycles after launch, once fraud rings have located and started working the new rail.
• A settlement or AML gap often does not surface until an audit or a regulator asks a pointed question about a flow nobody had reason to model closely at launch.
• Dispute volume is visible within weeks, but it is scored against operations' budget and headcount plan, not against product's.

A decision maker measured on launch and never on loss is not being dishonest. They are optimizing correctly for the only metric they were actually given, and the fact that the metric is incomplete is a design failure, not a character one. Asking that person to also weigh a cost that will not appear on their own scorecard for two quarters is asking them to act against their own incentives on faith, which is not a decision process — it is a hope.

The rule, stated narrowly The fix is not a reorg, and product does not have to lose the roadmap to get it. It requires writing down, for the specific decision class "launch or materially change a payment method," that the go or no-go sits with whichever function's own metrics move if the launch goes wrong — risk, jointly with compliance on anything touching settlement — and that product's role is to bring a complete, well-argued case to that function, not to chair the review of it. Product keeps the roadmap, keeps the business case, keeps the relationship with the merchant asking for the method. What it does not keep is the final call on a class of decision whose consequences land somewhere else.

This is a narrower version of the question decision architecture exists to answer on this site: not who has visibility into a decision, but who is structurally positioned to weigh its full cost without asking them to override their own scorecard to do it. The same swap already runs, quietly, on every checkout roadmap item — product proposes, risk holds the veto, and the arrangement is unremarkable precisely because nobody expects product to also own the fraud number. A payment method launch is the identical shape, running at a longer time horizon and with a larger, slower-to-arrive downside, which is exactly what makes it easier to assign to the wrong desk without anyone noticing for two quarters.

Moving one proposal to the right desk fixes one proposal. The pattern recurs unless the rule for the decision class itself changes, because the incentive that produced the first bad call — reward the launch, absorb none of its downside — is still sitting with whoever chairs the next review, waiting to produce the same confident, well-documented, wrong decision on the next method that reaches it.

A payment decision that keeps producing launches the loss curve later disowns is not a modeling problem. It is a decision right sitting with a function that was never going to weigh the loss honestly, because nothing on its scorecard asked it to. This is the kind of rewrite we do directly in consulting engagements — naming, one decision class at a time, which function's metrics actually have to move before its sign-off counts as informed, and moving the pen there before the next proposal arrives rather than after the postmortem for this one is filed.