> The issue is that programmatic checks probably wouldn't work in this particular instance, considering sometimes you do want to repay the principal.

Of course it would - simply have a different top of the decision tree that would hard code "PRINCIPAL REPAYMENT" in one and "NO PRINCIPAL REPAYMENT" in another. Do not allow filling out details on the screen that selects the flow.

Or, as I've seen in consumer bill-paying software, a confirmation dialog with extra info (given that the erroneous payment was two orders of magnitude unexpected): "Your last payment to Verizon was $78.98. Are you sure you wish to pay $7,898.00?"

These are good, and even better when they require confirmation by re-entering the value exactly as it was previously entered; however in this case, I don’t think it would have helped.

The number typed was correct, and it was even in the correct location. It was that it was not also included in two other locations that caused the payment to go through in the incorrect manner.

Given the assumptions presented by the UI, I’m not sure anything other than an extremely detailed confirmation dialog showing exactly where the amounts were going would have solved the problem.

Even then it’s not clear to me that that info would even be available given that the software never seemed to have been designed for the use case of a partial payment in the first place.

FLEXCUBE code base is two decades' worth of hard coded decision trees. Fitting yet another decision tree in there might break something else for every single loan.