Interest rates are always positive. Or maybe zero. But never negative.
This assumption is so common, it is often unwritten or implied. And the implications for pricing financial contracts when the assumption no longer holds are significant.
However, surely this assumption always holds? Hard cash is a classic example of a zero-rate investment. Just store your currency in a strongbox, and your rate of return is floored at zero. And no-one else is going to pay you to borrow money from them, as they can do the same for themselves.
Apparently not, though, if you're in Switzerland or Denmark. The combination of distressed neighbouring economies and currency pegs has pushed implied rates down through zero and beyond. Not only have short-term deposit rates and even medium-term government debt yields gone negative, but some LIBOR futures prices have traded above 100, implying negative fixings for the LIBOR rates.
This situation offers many topics for discussion on the nature of interest rates, but only if you're not already tied up fixing all of the problems due to assuming that negative rates can never happen. Although simple checks sound like a good idea at the time - after all, this interest rate futures contract can never imply a negative rateset, can it? - there is an important distinction between something that should not happen, and something that can not happen.
However, if we are very careful to reject illegal input, and to tolerate rare but nevertheless valid input, we then make our functionality more dangerous. Sure, some EuroSwiss traded through 100, but I'll wager that the majority of times any analytic functionality has been presented with this rare but valid input is when that input is has been supplied in error. This is nothing new - flexibility versus safety is a common trade-off - but is particularly tricky when the flexibility is perceived, rightly or wrongly, as an esoteric edge case by a significant fraction of a product's user base.
Personally, I have always favoured flexibility over safety, at least in core analytic functionality. Outer layers of a system, generally those concerned with UI, can then, if they so choose, restrict user input - ideally in a way that allows bypassing the restrictions if needed. Experience dictates that there will come a time when generally helpful safety features become an unavoidable obstacle, and that time is usually just before a big important deadline. Unless you can get to the functionality beyond the safety checks, you're stuck.
However, either one encodes a lot of error checking into each interface - which implies a lot of repetition and in turn this brings in its own problems - or simply discards it.
Until now, that is. We've collected all of the safety error checking in one place and made it optional. So if you're in a position to be careful, you can get all of the warnings you like. But if you need to remove the protection, you're free to do so. It may sound blindingly obvious, but then many really good ideas often are.