Never assume - at least not in Payment Processing

src

This is an interesting read and relates to what I say to my team members - Never assume. It may prove very costly and in this case the cost was very high. Whenever we do requirement analysis I always insist that they are very clear and documented and then signed off. In this case, poor software design along with human assumption proved costly. And I believe, the root cause of a poor software design is primarily because of unclear requirements.

The actual work of entering this transaction into Flexcube fell to a subcontractor in India. He was presented with a Flexcube screen that looked like this:

The subcontractor thought that checking the "principal" checkbox and entering the number of a Citibank wash account would ensure that the principal payment would stay at Citibank. He was wrong. To prevent payment of the principal, the subcontractor actually needed to set the "front" and "fund" fields to the wash account as well as "principal." The subcontractor didn't do that.
Citibank's procedures require that three people sign off on a transaction of this size. In this case, that was the subcontractor, a colleague of his in India, and a senior Citibank official in Delaware. All three believed that setting the "principal" field to an internal wash account number would prevent payment of the principal. As he approved the transaction, the Delaware supervisor wrote: "looks good, please proceed. Principal is going to wash."

So in this case as you see, there was no clarity what that check box would do behind the screens. And on top of that, all the three people actually assumed - believing without any fact. Imagine, if this were envisioned when the screen was designed or the requirement was analyzed. That's the price of investment done by product companies to build great software where quality is the most important aspect.

The message is clear - If you don't have documented clarity around a requirement, never assume it to be the way you believe. Because you leave a gap there - for the unforeseen way the actual end user can use it. And it's very crucial for product development - in this case, it also hampered the reputation of Flexcube and the brand behind it - Infosys. I think, this might have been escalated and fixed by now but unfortunately lesson learnt hard way.

Posted Using LeoFinance ^Beta