The policy is simple: any incident that degrades customer experience gets a public postmortem within five business days, whether or not funds were affected, and whether or not anyone outside noticed.
The commercial argument against this is obvious. Publishing your failures hands competitors a narrative and gives journalists a headline. We have had both happen.
The argument for it is that the alternative is worse in a way that compounds. An organisation that decides case by case whether to publish will always find a reason not to publish the bad one, and the internal culture adjusts accordingly. Engineers learn what gets written down and what gets quietly handled.
The one we nearly did not publish was a nine-minute window where a deployment left withdrawal approvals running on a stale allow-list. No withdrawal went to a wrong address. Nothing was lost. The control that should have caught it was the one that failed, and the control that did catch it was a monitor someone had added on their own initiative eight months earlier.
We published it. The internal effect was larger than the external one: three teams found the same class of stale-config risk in their own services within a fortnight.