Value-Graduated Fallback

When a scoring or verification dependency degrades on a transaction path, the usual design offers one answer: skip the check, or fail the transaction. Both are wrong for part of the traffic. Skipping accepts loss on high-value transactions; failing rejects a large volume of legitimate low-value ones.

The graduated design makes the fallback depth a function of the stake, so the same degraded dependency produces different behaviour for a small payment and a large one.

Why it matters

The expected costs are asymmetric and the asymmetry is knowable in advance. A one-in-a-thousand fraud rate on small transactions costs less than rejecting a large share of them; the same rate on high-value transactions does not. A single policy cannot express that, so it is either too permissive at the top or too restrictive at the bottom.

It also relocates the decision to where it belongs. The trade-off is a risk and product judgement, and a team without that conversation makes the choice implicitly — usually via whatever the timeout handler happens to do.

Implementation patterns

• A ladder with explicit rungs: full model check with a hard deadline → cached scores for known entities (device, merchant, instrument), which covers a large fraction of traffic since most transactions come from returning users → a deterministic local rule set with no external dependency → fail closed.
• The value threshold at which each rung stops applying, set by risk rather than by engineering.
• Local computation for the deepest fallback. If the simple rules call anything over a network, the fallback shares the failure it exists to survive.
• Mark decisions made in degraded mode, so they can be re-evaluated asynchronously and reversed if warranted — which converts an irreversible decision into a deferred one and is the most valuable single addition.
• Emit the degraded proportion as a business metric, so the organisation knows how much traffic passed on weak signals while it is happening.
• Exercise the degraded path regularly, because one that has never run in production will not work.

Industry example

Payment platforms such as PhonePe and Razorpay face this during large commerce events, when the fraud service is under the same load as everything else and the deadline is fixed by the customer's patience. Consumer credit platforms such as Slice face the same shape on approval decisions, and insurance platforms on automated underwriting.

In each case the mature version is not a better model but a better failure mode, decided in advance and graduated by exposure.

Failure scenarios

• A binary skip-or-fail policy, wrong at one end of the value distribution.
• The fallback calling a network dependency, so it fails with the primary.
• Degraded decisions unmarked, making after-the-fact review impossible.
• No visibility, so the business learns about the degraded window from losses rather than from a metric.
• Thresholds set by engineering, which is a risk decision made by people without the loss data.
• An untested fallback, discovered to be broken during the one event it existed for.

Trade-offs

The ladder is more code, more configuration and more states to test, and the thresholds require data that a young product may not have. A simpler binary policy is defensible while volumes are small and the value distribution is narrow.

The point at which it stops being defensible is when the transaction value distribution spans orders of magnitude, which happens earlier than teams expect — and at that point a single policy is guaranteed to be losing money in one direction or the other, invisibly.

Interview question

"Your risk service times out during peak. Give me the exact behaviour for a small payment from a returning customer, a large payment from a new device, and a refund — and tell me who decided each one."