Dejan

The invisible product decision behind every swipe – and what happens in the milliseconds between “tap” and “approved.”

Product case study · Role: Product Manager · Domain: Payments / Risk / Authorization

TL;DR I owned the product side of transaction authorization: the real-time decision to approve or decline every card transaction, and the customer experience wrapped around that decision. The work spanned decline-reason taxonomy, customer messaging and self-cure flows, approval-rate optimization, and the constant balancing act between fraud losses and false declines. Over the program we lifted approval rates by roughly two percentage points while holding fraud losses within target, and cut decline-driven support contacts by about a quarter.

The problem

A decline at the register is one of the most emotionally charged moments in fintech. Done wrong, it is a customer standing at a checkout, embarrassed, with no idea why their card failed or what to do next. Industry-wide, a large share of declined transactions are false positives – legitimate customers blocked by over-cautious rules – and each one erodes trust, spend, and eventually retention.

On the other side sits real fraud, which is adversarial, fast-moving, and expensive. The product problem is not “decline less” or “decline more” – it is making the right decision more often, and making every decline explainable and recoverable.

What we built

This was less a single feature than an ongoing product surface with three layers:

• The decision layer – the rules and risk logic that evaluate every authorization in real time: account status, available balance/credit, card state, spending controls, and fraud signals.
• The explanation layer – a decline-reason taxonomy that maps every possible decline to a customer-comprehensible cause, powering instant push notifications that say what happened and why.
• The recovery layer – self-cure paths attached to the notification: verify it is you and retry, unfreeze your card, make a payment to free up credit, or update the expired card a merchant has on file.

How it works

The authorization moment

When a customer taps their card, the merchant’s request travels through the network to our authorization system, which has a strict real-time budget to answer. The decision engine runs its checks – is the card active, is there balance or credit available, do the customer’s own controls allow this, does the transaction look like fraud – and returns an approval or a decline with a specific response code. If it is a decline, the customer gets a notification within seconds explaining the reason and, where possible, offering the fix.

Key product decisions

• Every decline needs an owner and an explanation. We audited every path to a decline and assigned each a reason, a message, and (where possible) a recovery action. “Your card was declined” with no context was treated as a bug.
• Self-inflicted declines are the easiest wins. A surprising share of declines come from the customer’s own settings – a frozen card, a spending limit, a paused authorized user. Recognizing these and saying so (“You froze this card – unfreeze?”) converts a failure into a feature moment.
• Fraud friction should be a question, not a wall. For suspicious-but-plausible transactions, verify-and-retry (a push confirmation) recovers good customers that a hard decline would lose.
• Measure false declines like fraud losses. Fraud losses appear on a dashboard automatically; the customers you wrongly declined disappear silently. We built the measurement to make both costs visible in the same conversation.

Under the hood (for the engineers)

• Latency budget. The entire decision – data fetches, rules, risk scoring – must fit inside the network’s real-time authorization window, which rules out anything slow and forces careful engineering of the hot path.
• Response codes. Networks speak in standardized response codes (ISO 8583 era conventions), which are far coarser than real reasons. Internally we kept a fine-grained reason taxonomy and mapped it both outward (to network codes) and inward (to customer messaging).
• Decision logging and replay. Every authorization decision is logged with full inputs, so any decline can be explained after the fact, rules can be back-tested against historical traffic before rollout, and disputes have an audit trail.
• Rule lifecycle. Fraud rules ship like code: staged rollout, shadow mode (log what a rule would do before letting it decline anyone), monitoring, and fast rollback. Shadow mode was the single most valuable safety mechanism.
• Edge cases of the rails. Offline authorizations, forced posts, incremental auths, stand-in processing when systems degrade – the rails have decades of accumulated behavior that the decisioning has to handle correctly.

My role

• Owned the decline experience end to end: taxonomy, messaging, notification flows, and self-cure paths.
• Partnered with risk/fraud teams on the approve/decline policy trade-offs, bringing the customer-experience cost of false declines into decisions that had historically been loss-driven only.
• Defined the metrics framework: approval rate, false-decline proxies, fraud basis points, decline-driven support contacts, and recovery-flow conversion.
• Drove the decline-messaging revamp and the approval-rate initiative that brought the cost of false declines into the same review as fraud losses.

Challenges and trade-offs

• Two failure modes with asymmetric visibility. Fraud losses are measured to the cent; false declines hide inside “customer attrition.” Building organizational belief in the second cost was as important as any feature.
• Explaining without teaching fraudsters. Decline messages must inform the customer without revealing which check they tripped. Fraud-related messaging stays deliberately general while self-inflicted reasons are fully specific.
• Adversarial drift. Fraud patterns change weekly; a rule set is never done. The product answer was investing in the meta-process – shadow mode, fast iteration, measurement – rather than any single rule.

Results

• Approval rate improved by roughly two percentage points over baseline.
• Fraud losses held at or below target while approvals rose.
• Decline-driven support contacts fell by about 25%, and verify-and-retry flows recovered roughly 40% of challenged transactions.

What I learned

Authorization is where a card product’s promises become real – rewards and design mean nothing if the card does not work at the register. The deepest lesson was that a decline is not the end of a transaction but the start of a conversation: the products that win are the ones that treat that moment with the same care as onboarding, because that is the moment trust is actually decided.