I consider this a great example of why systems dealing with money should be carefully engineered with sufficient safeguards in place that even reckless kindergarteners could operate with reasonable confidence they can't shoot themselves in the foot.

This is not a field where you want complexity or cognitive overhead.

I've encountered some ugly code while consulting in the payments space and had to educate and advocate (sometimes less gently than that word conveys) with developers concepts like atomicity, rollback, instrumentation, reconciliation, monitoring, diagnosability, etc. even after their creations had misplaced literally hundreds of thousands of dollars. It's always easy to blame the user; a good developer/architect understands how their code/systems can fail and stays on the lookout for edge cases and potential gaps.