Clarity, Cut, Ownership: India’s Blueprint for Building Platforms That Scale - Neel Radia

This talk focuses on the payments transformation journey undertaken by Stonex, a financial services company with a century-long legacy. The speaker discusses the challenges faced due to a legacy payments platform that was unable to keep pace with the company's rapid growth. By building an in-house, scalable payments platform known as X Pay, Stonex aimed to achieve zero downtime and support real-time processing. The platform emphasizes resilience, scalability, and a business-driven approach while incorporating modern technologies such as microservices, MongoDB, and AI. The speaker highlights the significant improvements made, including reducing payment processing times from 30 minutes to just 2 seconds, showcasing the platform's tangible business impact.

Today we are going to talk about something which is which looks like leadership mantra clarity cut ownership but by the end of session you'll realize how it will relate to each one of you as a developer sitting in the room, right? So to start the session first of all I would like to introduce you to Stonex what Stonex is what we do as a company and the

next video will tell you something about that. Apologies there is no sound but as you can see we connect clients to markets. We have various business where we connect our clients to multiple markets be it physical hedging as you can see be it the clearing channels be it payments be it equities. So we have multiple business line and this is the My Stonex is the new platform

that we are coming up with which will have one platform and multiple production to that where clients can connect to multiple markets from a single platform, okay? Um So just to give you this idea of some of the numbers that Stonex plays with. We have 100 year old legacy that means we have client that has trusted us for last 100 years. We are the fortune 42 company.

We are often referred as a hidden gem in the fortune 100. The average annual trade volume that we do that is 4.6 trillion dollars. Just to give you the scale of that that's bigger than Indian economy today. Yeah? We cover 180 countries. We do payments in more than 140 currencies. We connect to 40 plus exchanges worldwide. Yeah? And we do all of this just with 5,000 plus

employees globally. Um this slide gives you an idea of depth and breadth of width of the business that we have. We have client base starting from commercials to institutional, uh to payment clients. All the big banks in the world use us and lots of NGO mid-market corporates are our clients. Uh and we have retail customers as well. So, we have more than six 600,000 retail customers using

our platforms daily. Okay? Uh today we are going to deep dive into one of the use case uh that I'm going to cover is the payments transformation journey. Um so, we are going to deep dive into that. Um and today we'll cover the challenges that we face that force us to do this transformation, how we reimagine our payments platform that was there before 4 years and what

it is now. Uh then we'll talk about the people angle of it, how you know, we as a company trusted the teams in India to build it. We'll touch base uh touch base a bit upon that. Um then we'll talk about the business impact, right? Because no matter how good technology that you use, how how good platform that you build, but what is the kind of business

impact that it gives, that's what matters, right? So, we'll touch a bit or upon that and then we'll go on to next journey because if payments transformation was the first chapter, the second chapter is still being written with AI at the center of it, right? So, then we'll touch a little base upon agentic AI and how what we are doing as a company with agentic AI and

all the AI technologies. Yeah? Okay. Um so, I want you guys to imagine something, right? Imagine you got a payment at 9:00 a.m. in the morning and your platform took 30 minutes to process that payment. In 2026, we are talking about 30 minutes, is that really good? That was us 4 years back. And that was not one of the problem that was not the only problem. That

was one of the problem that we were facing, right? Because we had a legacy vendor product to manage the entire payments execution. Now, none of the legacy vendor was um you know, kind of sufficient enough to give us all the requirements that we had. So, what we did was, which every company does, we started building the satellite systems around that. And that created the entire complexity of

the payments platform that we had. The problems that we had, this entire spaghetti could not scale with the volumes. Our business was growing 30% every year. This payment uh this plat- that platform was not able to cope up to that kind of volume. As I said, it it has a high processing time. So, one payment was taking 30 minutes to be processed end-to-end. There were very tightly

coupled workflows throughout the payment engine, and it was impossible for our production support teams to trace out if there are any issues with the payment, right? You have to go to multiple systems, check the logs, and see where the payment is failing. So, those were the problems, and on top of that, because of this whole complex architecture, if there was any new change that business required, it

took us months rather than it should have been taken days. So, all those simple changes turned into big projects, which took a lot of time to get delivered. So, that was our problem. And when you have this kind of system um which is not so much robust and your business is growing, at some point in time, you'll hit that breaking point. And in 2022 was the year

when we hit our breaking point, right? And that's where leadership sat down and decide on the next options, right? So, what we did was, that was our starting point or the starting point of the journey that we embarked on to transform the payment platforms, right? Um so, what we did was, we created a core group of fintech experts out of the payment domain who had domain expertise

plus a good technical knowledge. We created that group, and which will decide the path forward. So, it was not the people sitting somewhere in the world making decisions that we will go this way. No, we created that core group who was identified as the decision-making authority on how we'll move forward from this, right? So, that group sat down and decided on the options. What are the next

options? So, the first option was to continue with the legacy vendor, right? Do some patchwork, increase the memory, increase the hardware, and move on. But, that would have solved the problem only for a couple of months or for 6 months. After 6 months, again we'll hit the same roadblock, yeah? Next option was to buy a payments platform which is available which is available in market. Payments is

a very established domain and there are multiple products available in market. But, because of the complexity that we operate in and the banking network that we have, which is close to 33 300 Sorry, 330 banks across the world, which is by far the largest in the world that we have, right? So, there was no such product which could fulfill all our requirements which we wanted. And then

again it would turn into building the buying a platform and then building a satellite systems around that. So, we did not want it to go that route. So, what the team was decide What the team decided was that we will build a global platform in-house which will 180 countries, 140 currencies out of a single platform, right? And it was not just a cost arbitrage move from the

company. It was a conscious decision taken by the company that this team will sit in India to leverage the talent powerhouse that we have in India to build this platform entirely out of India, right? Not just the development or execution part of it, but owning the decisions and everything. Everything should happen from India. That was the bold bet that we took 4 years back. So, coming to

the vision, right? Our vision was to build 100% business driven driven payment platform that will unify multiple product into one configurable, scalable, and future-ready ecosystem, okay? Um if you if you read that carefully, right? It has that business-driven platform. That means the technology team will not define how the platform will look like or what are the features will be there in the platform. It will be completely

driven by business, okay? So, that core fintech group sat with the business owners, sat with the product owners, and defined the roadmap on what business wants, right? and it it was it was without any safety nets, right? There was no falling back to the vendor because we knew that we hit we need to hit that date, and the date was set in the stone, right? So, there

was no fallback mechanism. We already gave um a kind of notice to vendor that we are getting off your system, and we are building on our own. So, that was the bold that we bold back that we took, and that's how uh the platform X Pay was born. That's what the name we gave, and if you see Stone X Payments, X Pay is right at the heart

of it, right? It literally is the center of Stone X Payments. Before we wrote a single line of code or we designed a single workflow, we decided on what are the core principles that we want our system or platform to be built on, okay? And every time we hit a hard decision that which path to take architecturally, these were the principles that we looked back on, and

these are the four principles which guided us throughout the journey when we wanted to make any decision, right? So, first and foremost was resilience and always-on because banking services never sleeps. Financial institutions never sleeps, right? We have to be on 24/7. And we we we knew from start that we need to build the engine which will be zero downtime deployments, and it will be fault tolerant, right?

So, be it be it deployments or be it any maintenance, that system cannot be down. Um the next was built for scale, right? So, we didn't want it to build the platform for next 2 years or 3 years, but we wanted to build a platform which can support our business for next 20 years. And when we are growing 30 30% every year, it was very important to

build with a vision in mind that if our volume is 1X today, we should be able to support the 20X volume in future. Yeah? Agility by design, right? So, in payments industry and in finance industry, there are lots of rules, norms that changes every day. And we can't be coding each and every rule in the code. It should not be hardcoded, right? It should be config driven.

It the the platform itself should be um you know, very much flexible in way that all the config can be done from UI and by the business, should be owned by the business, and for which we don't require the code deployments. And it should be future ready, right? When we are building in 2022, we knew that uh it's is it's the era of automation, is the era

of AI. So, we should not build platform in such a way that today we are building and after 4 years or 5 years, we need to rewrite entire code base to fit in automation, fit in agentic AI, and fitting AI into the uh engine, right? So, build we built the system uh from start with that vision that we will do all of those things. Okay. Moving on

just to give you idea of when I say platform, what does that actually mean, right? So, Jaguar Land Rover is one of the best car companies in the world. What they do is they have their D8 platform, right? That platform has a floor plan, that platform has an engine assembly, and what they do, they do they build products on top of the same platform. So, they build

the products which are suited for different market, different taste, but with the same platform, right? Now, it did not stop at Jaguar Land Rover. When Tata took over the Jaguar Land Rover, what they did was they extended the same platform to suit the Indian market. And that's how Harrier and Safari was born. So, our philosophy was also similar. We wanted to develop a platform that can support

multiple products. And you don't need to touch the base again and again. Any new product, any new business that you want to onboard, you just build that product on top of the platform, which is well-tested. So, what are the benefits that it give, right? It significantly reduces the time to market because now your core is set. All you need to do is build the configuration, build the

workflow which business requires. So, your time to market reduces, right? Um you can customize according to any market taste. So, in our case, it was country-specific and currency-specific. So, any new currency that we want to onboard or any new currency rule that changes, let's say India today uh says that to process a payment, I want Aadhaar card also in in in space in lieu of PAN card,

right? So, it's all configurable in the platform. We can do that change very easily without uh without touching the platform, yeah? Moving on to tech stack, right? Uh and this was the fundamental um architecture decision that we took that what kind of technologies we will use uh when we'll build this platform, right? So, this was very uh very fundamental thing uh that we decided. Uh so, we

use micro front-ends uh to give that power to each and every team to develop independently without touching um without, you know, getting in the ways of other teams so that all the teams can develop in parallel and we can deliver faster. Um domain-driven microservices, so every microservice that we build had a clear clear boundary. And it was tied to a domain. Say, if there are payments, there'll

be a payment service. If there are trades, there'll be a trade service. If there is a static data, there'll be static data service, right? And there is no cross-cutting of boundaries between the microservices. Uh we use MongoDB to have the flexible schema because payments world changes very fast. It was empty Swift 2 years back. Now it's all ISO and now we are moving towards faster payments where

every bank has its own proprietary format and we need to connect to various banks to do that. So MongoDB gave us that flexibility to have the flexible um schema and not a hard bound relational schema. Yeah? Um the entire architecture was event-driven uh to make it more scalable, to make it or us more asynchronous uh in future so that we can support any number of volume. Uh

we use mono repo strategy because of the team and the culture that we had. Now mono repo the developer community is divided, right? Some people say that mono repo we should go. Some people still say that we we should go with individual repo repositories, but mono repo was something which suited us because we wanted to have that collaborative approach where all the all the common tools and

all the common technologies are available within the mono repo and all the developers can look at it, contribute to it so that the model is federated, right? It's not tightly bound. Yeah. So you can have only one mono repo which has multiple modules in it and all the microservices can be individually deployable. No, multiple pipelines for multiple microservices, but the repo is single. Your repository is a

single repository, which is a source of truth. But still your microservices are individually deployable. So imagine yourself as a tech lead, right? If you're reviewing one story or one feature that is written in one PR, you are getting all the changes of that. Whether it is a UI change, whether it is a back end change, or whether it is test automation. In the same PR, you get

all of that and you get visibility to end-to-end changes. Okay. Um next thing that we did was feature flag development, feature flag driven development. Now, this is very important when you have a large team working on a product, right? Where you can develop features very fast, and you don't need to worry about how those features will be enabled in production because now we have um, you know,

segregated your development and turning on the feature. So, all of your code can go into production, and as and when required, you can turn it on. Yeah? And if you want to do it user-wise, let's say you want to open that feature for specific users to test on production so that you know that before you roll it out to multiple users, it doesn't break, you can do

that with feature flag development. Yeah? Um, then at some parts we've used Postgres database as well, where there was a need of having the relational schema, like reporting and all that stuff requires a hard bound reporting schema. So, that's where we've used Postgres database. Yeah? Um, and last but not the least, if you have a perfect system in production, if you have um, system in production with

the, you know, latest technology, but if you don't have monitoring and observability in the production, then it's of no use, right? So, that's where Datadog came into picture, and we use Datadog to do all the monitoring and all the observability in the production. Moving on to next slide, and this is something which as a engineering team we are most proud of, where we built the reusable frameworks,

right? Um, now, where this frameworks comes into picture, right? When you build reusable framework, it means that your entire developer community within your company can reuse this framework, and they don't need to reinvent the wheel, right? Um, so, if I take example of rule engine, right? Dynamic decision making. Now, every system will need some kind of decision making. If you build a rule engine, which is common

in nature, which any team can inherit and make the dynamic decision based on the configurable rules, then every team will not need to build it, right? Similar way we build entitlements framework because entitlements in a financial services is uh is not is not optional, right? It has to be there. It's a audit issue if you don't have that. So, every every um you know, platform will need

entitlements framework. Similar to that, we built approval framework, which was very configurable. So, if today my business owner says that I want a two-year approval or four-year approval, I approval, I can change it very quickly in the production without making any code changes. Yeah? Uh we had transformation framework, which helped us to connect to multiple banks in a configurable way. So, if I have a new bank

connectivity tomorrow, I don't need to make code changes. There is a framework transformation framework. I just do the configuration change, and boom, you can put it in production the next day. Yeah? Um we had a static data framework. All the reference data, all the static data that is referred in entire platform is at one centralized place, and that is also in the in in the control of

business. Whenever they want to change static data, they don't they don't need to come to IT teams to make those changes. They can do their changes on their own. Um no, so for rule engine, we built it based on uh Java technologies, and then under the hood we used uh um uh something called uh framework DSL. We used DSL to build that rule engine, but it was

a very uh generic framework that we built where the rules were defined on the screen, and any business user can come in and make those rules. All of these seems to be solved problems like Drools is rule engine open source and all that. Any particular reason you built all of them and not reused what was already available? >> Mhm. So, Drools is a business rules engine, as

you see it, but it is very tightly coupled within the code. Drools, any business person cannot understand, right? And anytime you need to change a rule, you need to deploy that into production. Even if those are config files, you need to push them. The rule engine that we build was from the screen. Right? So, any business user, as I gave example of INR, right? So, we have

lots of currency rules that goes into play, if any any currency rule changes for the payment, our business users can go on to the platform, make the changes on to that rule, and no code changes are required. It gets applied from the very next payment that comes into the system. Thank you. It's auditable, right? So, that framework built in with auditable capability, and it has four eye

approval as well. So, again, when approval of rule comes into picture, that's when approval framework comes into picture, right? So, you can define that this kind of rule needs four eye check, this kind of rule needs six eye check. So, based on the rules also, you can define and everything is audited, right? Who made the rule change? Who approved that? And again, we track Again, we trace

that at the payment level as well, that when this payment was processed, which rules were applied? So, if someone comes and tells me that we made a new rule INR payment, and it was it was not getting applied, I can clearly see by the by looking at the payment that this rule was created after this payment went out. Hope it makes sense. I'll move on quickly now

because I think I have only 10 minutes left. Uh So, we use AIML to solve the business complex business problems. We use AIML to automate what a human cannot, right? Um So, I'll give you an idea about STP rate, right? STP is something which is very paramount in any financial industry. It is straight-through processing. What that means is how many transaction went out without human touching it,

right? So, all the clients love it. All the financial advisors love this number, right? So, our STP was somewhere around 80% and to increase that to 98% AML was the main driving factor. The problems that we were seeing with historical data, we applied machine learning on top of that and we built the AML based automation which helped us to move from 80% STP to close to 98%

STP. Right? Right? We use the pattern detection across the payment transactions which are beyond the human capabilities because a human cannot remember the past 100 transactions, right? So, that's that's where we use AML to increase our STP numbers. Okay, now this is something which is very important, right? Building technology is one thing, but how do you build capabilities within India was our main focus as well along

with building the platforms, right? So, how we did was we created a core fintech leadership which was in the decision-making on how this platform will be built and and what what all frameworks we'll use, what all technology we'll use, but that's not enough, right? You need enough manpower to build the entire platform. So, that's when we went to early career strategy and we hired people straight out

of college. Now, when some companies hear this straight out of college, it looks a bit scary, right? But, we used that as our powerhouse. We paired them up with the fintech leaders that we had, the leadership group, and there was a strong mentoring, there was a strong investment that they did we did with the early careers, right? And that helped us build a group which can deliver

a platform which is a world-class platform, right? So, we trust we trusted them early, we gave them opportunity to work on real-life problems, and now I'm proud to say that many of those early careers people are leading one or the other module within the company, right? They are taking the architecture decisions. They are take uh they are talking to business stakeholders on how to build the platform,

what kind of um uh what kind of business decisions we we need to take, and those are the people who came straight out of college before 4 years. Yeah? And as you can see in the photo, that's our team of core fintech group plus the early careers members. Uh moving on quickly to the business impact, right? Because as I said, there has to be a significant business

outcome of the platform that you build. So, we went live with this platform last year in February um as expected, and what impact what business impact did it has created? Uh so, this platform is used by eight out of 10 largest bank in the Right? That's a big number. So, all the big banks use us to make the payments. Our processing time went down from 30 minutes

to 2 seconds. Yeah? So, from batch processing, we went to the real-time payments. Now, all the payments that is processed within our system, which are STP, takes on an average 2 seconds. The volume it supports today is 20x, right? So, as I said, we didn't want it to build for 2 years, 3 years, or 5 years. We wanted to build for next 20 years. So, now it

is supporting the 20x of the volume which vendor system was supporting. Uh that resulted into cost saving of 1.8 million dollars that went into licensing, the physical servers that were supporting the infra, uh which was vendor managed, and all that stuff. So, that's the right dollar save um which gave which it gave to the company. Yeah? STP we've talked we've talked about uh we've talked about the

end-to-end automation. I want you to focus on the last number. After we went live last year, in just 1 year, we were able to connect to 18 real-time payment rails. So, now our engine is capable enough to do real time payments for those 18 currencies, and we are adding more every week. Right? So, that's the speed we are moving at um by having this platform, and that's

the that's the real business value it gives us. So, now we can go back to our client, our sales team can go back to our clients and say that what real what real time payment really you want to support, and we are ready to onboard that within 15 days. Yeah? Okay. Now, this was example of one of the platform. As a StoneX company, we are going through

a transformation phase where we'll be where we are building many such platform. We are building MyStoneX, which is our client-facing platform. We are building OurStoneX, which is our internal platform for all the operation user. We are building many such platform for uh let's say security settlements team, for metals team. Now, when all this platform comes together and when it produces a lot of data, right? When all

this data comes into picture, it becomes a data spaghetti. Now, each one of you might have seen this kind of data spaghetti in your organization. I'm 100% sure on that, right? So, that same problem we were also having. What we did was to transform this kind of data into a unified data which we can leverage to do AI on top of that, to do analytics on top

of that, and to leverage that data to do cross-sell across the client segments, right? So, we created a unified data platform which resulted organizing all of this data into a unified data platform in a very structured way. Yeah, we use Databricks technology to do this, uh and we have a very good data team in India who supports this platform now. So, now we have all the data

centralized at one place which we can leverage. Moving on, what that resulted StoneX India into, right? So, Stonex India is not defined by scale, but it is defined by the ownership it takes over the execution. So, now India offices are not just back office system or the execution teams. This is where the decision happens. This is where the platforms are designed, and this is where the platform

are getting delivered from. Yeah? We prefer talent over titles. So, we have people, as I said, who have come from early careers. So, there's a guy who has like 4 years of experience, and the system or the module that he built, he is the most knowledgeable in the company right now, apart from anyone else, right? So, we prefer talent over We trust the people over the control.

We don't believe in micromanaging people. We trust them to build the right to build the right kind of solution, to take the right decisions. Now, this is very important for a global company, right? When you do this, you might need to accept that people will take decisions that you don't like, but sometimes those decisions will be betterment will be for betterment of the company, right? So, you

need to trust people, and that's what we do. Coming to the next chapter, right? Where agentic AI is taking over how the SDLC looks like. Um so, this is what we are doing as a Stonex with agentic AI, right? So, we have agents built into our platforms, which takes care of each part of the SDLC. So, we have a BA agent who can take in the requirements

from product owners, from business analysis. They give the requirement, and this BA agent will take care of all the repetitive work that a BA was doing, right? So, to give you an idea, if BA was spending, let's say, 4 hours in just defining and writing the user stories. Now, that work is being taken by BA. Right? Similarly, we have a dev agent, which takes care of boiler

plate coding, and now engineers are focusing on better design, how to build a system that is scalable, and how to build a system you know that is configurable. And here the role of engineer comes into play where engineers needs to review each and everything that is written by agent AI just to make sure that it is within the control and the and the frameworks that we have.

It is well within that premises, right? Similar to that we have QA agent who takes care of end-to-end test automation. So here now QA automation engineers just needs to give the direction to agent and all the end-to-end tests are written by the agents. If there are defects found in that, we have automated at such a level that it will go ahead and create those defects in Jira

board as well. So there we use the Jira MCP server, Playwright MCP server, and Karate MCP server to do that. Yeah? And it's a continuous feedback loop. We learn every day, we learn every sprint. Whatever things that were gone that has gone wrong in the current sprint, we modify our agents to be better at that in the next sprint. Yeah, so it's a continuous iterative process. And

to answer your question where the ownership lies, so that's where agents are just an enablement for the developers. The code that it generates, it's still owned by the developers. So after 1 month, developer cannot come and say that this was written by agent and I don't own this code. No, that's not the culture we have. It's still the developers who own the code. Entire team. When I

say developers, code is owned by the developers. If it's requirement, it's owned by BAs along with the product owners, right? Yeah, I guess the timeout signal has been signaled from there. So thank you. We have a booth downstairs. If you're interested to know more about this, please come and meet us. We can discuss more in detail. Yeah? >> [music]