One of the major traps in fintech is implementing the requirements of a financial institution without questioning the value it is expecting from them. Many times, the client would be describing how he or she operates a given business process in the system being replaced rather than the functional value expected from that process regardless of the platform. Many times, what the client does in a system is actually a workaround for a gap in functionality and you don’t want to be implementing workarounds and accumulating technical debt in the platform you are delivering to him.
Many years ago, I found myself in a meeting room somewhere in the UK, surrounded by representatives of the treasury, operations and finance departments of a humongous financial institution, trying to come up with a proper design for their treasury business processes to implement and automate in our platform. At some point, we stumbled on a concept we had never encountered before, the FTP, or Fund Transfer Pricing, which only started gathering interest by the end of the 2000s, after the sub-prime crisis had washed international finance ashore, a very recent topic back then. It felt like the client was speaking a different language and the meeting was reaching a dead-end when the senior architect suddenly rose to the challenge. He asked a simple question with his typical French accent.
“Why do you do it?”
Sometimes the most basic question can yield the most effective answers and this one proved it right. The client ended up explaining what he actually wanted to do rather than how he wanted it to be done. For the less experienced consultant that I was back then, it felt like magic. A very complex business requirement was unraveling, bit by bit, with every question the senior architect was asking. The guy was walking on water that day, and even the client was amazed by his magic: He went into the meeting not knowing a thing about FTP but still managed to save the day and get out of it with a clearly described business requirement which we could design into the platform. And all he did was ask questions. The right questions. That was my first true lesson into requirement gathering and design, my Fintech 101 moment if you will. It was very humbling, and I remembered thinking I could never pull off something like that.
I would however get a shot at it, some years later, when I found myself in a meeting room somewhere in northern Europe, in the middle of winter, surrounded by half the treasury department of one of my clients, trying to come up with an elegant design for their banking book accrual P&L reports. Fintech 101 was far away in time and I had done enough mistakes by then to have learnt a few tricks of the craft. It felt like walking on water to me and I like to think the client felt the same magic. But nothing is less sure…
Let the board sound