Defensive programming
Defensive programming (assume the input is incorrect or malicious until proven otherwise) used to be a standard feature of important software. Unfortunately this has fallen by the wayside as the urge to cut software development time down has overtaken the requirement that the software works correctly.
For any financial application that is responsible for significant amounts of money, common sense would suggest that the code should be built using defensive programming techniques - unfortunately "common sense" is not very common.
(For a simple example of defensive programming take the following example - paraphrased from the RSX-11M operating system
Is the function number in range - if not then reject the request
Does the call have the right number of parameters - if not then reject the request
Does the program have the right to call the function - if not then reject the request
Are all the parameters accessible - if not then reject the request
Only if the above checks were passed would the request be passed on to the requested function which may itself need to carry out further checks on the values of the parameters.
)