It’s always exciting to work with new colleagues. And, within a company focused on payments, working with an industry veteran with deep experience in ISO 20022 – well, it doesn’t get much better than that! So, after giving Lenin Desai, Volante’s ISO 20022 service product manager, two months to get acclimated, I asked him to sit with me and answer a few questions about his background and the payments industry.
– Chris Dunn, Director of Platforms Marketing
Lenin, can you give us a bit of background on you and why you chose to join Volante?
I am a payments professional, and have specialized in payments for around two decades. From paper instruments to real time payments using ISO 20022 messaging and APIs, I have had a ringside view of how payments are processed by banks and their customers. I’ve also clearly seen the problems banks and their customers have with payments.
What excited me about Volante was that their vision of ‘freedom to evolve’ was reflected in the services they’ve brought and are bringing to the market. From a state-of-the-art payments engine and the most advanced payments as a service solution in the market, to tactical solutions like on-prem and cloud hosted translators, they seemed to have the most important needs of a bank covered.
With respect to your role as product manager for our API-based ISO 20022 service, why do you think APIs are useful when it comes to migrating to ISO 20022?
If you look at the payments space, APIs are as close to a plug-and-play model as you can get. Our API-based ISO 20022 service lets banks focus on their core competencies while leaving the creation and transformation of ISO 20022 messages to us. Taking it a step further, our APIs also take away a bank’s integration challenges since we act as the translator between their systems and the rest of the market. They only have to worry about implementing the specification published by us.
What trends are you seeing in the market around ISO 20022 that are going unnoticed?
At the moment, banks are focusing on two aspects. The first is compliance in the interbank space, from a short-term perspective. The second is the ability to use the rich ISO 20022 data, in the long run, to develop insights by applying ML.
However, in order to increase revenue from ISO 20022, I believe there is a third angle to consider – developing services leveraging not just payments messages but also associated non-payment messages e.g., Request to Pay (called Request for Payment in the TCH RTP system). With request to pay, banks can develop innovative products for accounts receivables and account payables. Also, the value of ISO 20022 can only be realized if applied end-to-end, as in it is used not only in the interbank space but also in the customer-to-bank space.
There has been a lot of talk about the value of the ‘richer payload’ but is there any truth to that? Is there value that can be had from that payload in your perspective?
Yes definitely! The promise of ISO 20022 lies in the richness of the data it can support and the structure it brings to it, which facilitates increased automation and efficiency. From automated reconciliation of payments for invoices to reducing the number of false positives, there are a wide range of benefits that can accrue from adopting ISO 20022 correctly. However, a bank must have a strategy in place for leveraging ISO 20022 for generating both internal efficiencies and additional revenue.
Has any new functionality/capability been introduced into our ISO 20022 service over the past quarter that is worth highlighting?
The ISO 20022 service has a busy roadmap with a focus on both, technical and functional enhancements. Notably, in addition to performing transformations, our APIs can also support custom logic prior to and post invocation of the APIs. This allows for an institution to use their own canonical format for input into our APIs as well as tweak the standard MI format output to make it compatible with their systems. On the functional side we are building support for new market infrastructure formats such as CHIPS, FedNow® and FedWire.
We’ve made the service available for free to any banks who want to try it. That’s a bit unusual in our space, why have you and the team made a conscious decision to open it up free of charge?
We want banks and institutions to be able to see the power that APIs can bring to their operations, and the best way to do that is to remove barriers. So, we’ve made accessing the service incredibly simple: sign-up; select the message types you want to create, validate, and transform; and then start executing your API calls. It doesn’t get much simpler than that. Once signed-up, users can experience what it is like to easily transform and create financial messages without having to worry about writing the logic for handling validations and transformations. This simplified ‘trial’ experience includes access to our sandbox where users can both execute API-calls but also try the service out in ‘manual mode’ through a simple to use UI.
Click here to sign up for free access to our Developer Sandbox Portal.
