Trust score explainability

Context

Kount scores over a million transactions a day. An analyst sees a number between 0 and 99.9 and decides: approve, hold, or decline. The score was accurate. It was also opaque.

When a merchant challenged a decline, the analyst had no answer beyond the number itself. Disputes escalated to engineering. Analysts hedged toward manual review — the slowest and most expensive path — because review felt safer than a decision they could not defend.

“I trust the model. I just can’t tell a merchant why we blocked their best customer.”
Fraud analyst, internal interview

Two constraints shaped everything. The score comes from a proprietary model, so we could surface contributing factors but not expose weights that would let fraudsters reverse-engineer it. And reason codes were pre-scripted — chosen ahead of time by the risk team, not generated per transaction.

Process

The design problem was not how much we could reveal. It was how to make a limited, pre-scripted set of reasons feel sufficient for a decision an analyst has to defend.

Research synthesis card showing the four questions analysts repeatedly asked about the trust score — Queue observation notes. Analysts re-derived the same four questions on every transaction.

The model is proprietary, so weights were never going to be visible. That constraint was understood from the start. Data Science controlled which reason codes could surface and how many.

Two questions kept recurring in queue observation: how was this score built, and what specifically drove it. The version that worked separated those questions. Composition became a waterfall. Drivers became a two-column list of active and inactive reason codes.

The hardest detail was the baseline. Mathematically the score often started somewhere in the 70s and the starting point shifted with every transaction. A waterfall only reads as an argument if it begins from a stable number. We pinned the visual baseline at 80.0 so the movements up and down stayed consistent and legible, even though the underlying math was more fluid. That single decision made the rest of the interface coherent.

Diagram comparing the shifting mathematical starting point of the score with the fixed visual baseline of 80.0 used in the waterfall — The mathematical starting point shifted per transaction. Pinning the visual baseline at 80.0 made the waterfall readable.

Solution

The review modal answers three questions on one screen: what the score is, how it was built, and what drove it.

Transaction Trust Score modal showing score 85.6, waterfall chart of contributing factors, and two-column reason codes — The trust score explainer. Score bands render at equal width even though their ranges are unequal. Kount's published threshold guidance puts roughly 5% of volume below 61, so the vast majority of traffic sits in the top bands — proportional widths would compress the range where nearly every real decision happens.

The waterfall starts at the 80.0 baseline and shows eight signal categories moving the score up or down. Reason codes sit below in two columns — increased and decreased — with inactive codes dimmed rather than hidden, so analysts learn the full vocabulary and can see what did not fire.

Two-column reason code list with active codes at full opacity and inactive codes dimmed — Inactive reason codes stay visible at reduced opacity. Absence is information.

A feedback control in the footer closes the loop: analysts flag explanations that do not hold up, which routes back to the risk team as reason-code tuning input rather than disappearing.