In other fields, fuzzing data while still maintaining accuracy is a well-established practice. A simple example that fits closely to debits/credits is the "vot

In other fields, fuzzing data while still maintaining accuracy is a well-established practice. A simple example that fits closely to debits/credits is the "vote fuzzer" on reddit. This was important back when reddit allowed you to easily access not just the point score of a post but also the count of up and down votes. The points are calculated as (upvotes - downvotes), but spambots could take advantage of that to figure out if their votes were really being counted, or being thrown away by the spam detection systems. So suppose the score on a post is currently 20 points with 30 up, 10 down votes. Reload, and you might see 32/12. Or 37/17. The fuzzer would give back fictional always-increasing counts of up/down votes which happened to add up to the correct score. It would also add phantom votes to offset spambots it had detected, so a spambot might see 32/12, issue an upvote, and then see 33/13, where the 13th downvote was a complete fiction invented by the fuzzer, to cover up for throwing away the bot's upvote. Apple's differential-privacy implementation in iOS does something similar; it boils down the metrics it will submit into a fixed-size data structure, then randomly flips some bits before submitting. But the weighting and occurrence of the bit flips is set up so that on average for every time, say, the third bit of a given submission flips from 1 to 0, there will be another submission that flipped its third bit from 0 to 1. This preserves the overall statistics while making it impossible to know which bits of any submission were "real" versus which were flipped by the fuzzer.