# Event-Driven Migration Strategies for Legacy Financial Systems

**Podcast:** The InfoQ Podcast
**Published:** 2026-02-16

## Transcript

If you're the kind of senior engineer, architect, or technical leader who people look to for what's next, QCon London is probably on your radar.
Join us in London from March 16th to the 19th, where we go deep on the topics that matter, like the architectures you've always wondered about, engineering productivity and applying AI in the real world.
This isn't about trends for their own sake.
It's about getting practical insights from senior practitioners to help you make smarter calls on where to invest your time in tech.
With Software Changing Fast, QCon London is a conference that helps you lead the change.
Learn more at QCon London.com.
Hello and welcome to the InfoQ podcast.
I'm Thomas Betts, and today I'm speaking with Muzeeb Mohammed.
Muzeb is a senior manager of software engineering at JP Morgan Chase and a senior member of IEEE.
He specializes in designing secure, resilient, and high performance distributed microservices for large-scale financial platforms.
And that's what we're going to be talking about today.
So, Muzeeb, welcome to the InfoQ podcast.
Thank you so much, Thomas.
It's a very pleasure to be part of this uh podcast.
I'm looking forward to share some of my experiences where I worked, you know, my previous employer as well as the current company.
Well, great to have you here.
InfoQ has covered event-driven systems before, but in your view, what makes a good event-driven system?
How do they differ from traditional, say request and response or monolithic architectures?
So we actually do have a lot of applications built in the monolithic uh technology stack, like you know, RSTOL APIs, you know, soap-based web services.
Uh but the the challenges that we were facing is I think to, you know, do time to the market or to scale up the solutions.
I think we were having some of the you know common challenges, the industry experiences.
So we have tried some of the event-driven approaches.
Uh, you know, very specifically, we started with the Kafka, uh, is one of the uh architecture patterns.
Uh we started seeing a very good uh improvement.
I will explain some of the examples that we uh successfully implemented.
SCI.
SEA was one of my previous employer.
So part of, you know, when when the customer tries to open a checking account, uh, you know, it goes through a various systems behind the scenes.
We were actually kind of not reaching the SLA within the time.
So what we did was we introduced uh a Kafka event-driven system in the back-end processing.
Uh so for example, customer goes to the SCI.com and try to open the account, a checking account.
So what happens is behind the scenes, we loosely decouple the whole backend processing.
You know, I think the customer checking account goes through the credit check, you know, it looks at the various factors like whether customer is eligible to open the account or not.
And once those systems are loosely decoupled, so basically the the customer account information is getting published to a couple of topics, and then there are a couple of consumers basically.
Uh, frag check is one of the consumers.
Uh-huh.
And account opening is one of the uh dependent system, which basically takes the customer information, opens up the a brand new account in the system.
You know, I think we have seen this particular implementation helped, you know, navigating through a customer journey very efficiently.
And also the various dependent systems are like asynchronously processing the end-to-end flow.
So there is a completely decoupling uh uh solution we implemented.
And ultimately, you know, I think uh the SLA we were able to achieve like within the agreed timeline.
Yeah, I think you talked about the customer journey.
I think that's what works with event-driven systems.
You're talking about the events, and if um the business process says, well, the the customers request a new checking account, and then that's the first event that happens, and then other things trigger off of that.
Oh, we need to do a fraud check, we need to do this, and eventually there will be an event that says the new checking account was created, or maybe the checking account was declined, but there are steps along the way, and each of those events happen.
So you would have different message streams, right?
That that process those, and you design the system to be asynchronous.
And it's um, I think it's sometimes counterintuitive that we're making all these things that are asynchronous and out of band, but that can actually speed up the process.
You mentioned you know, meeting your SLA demands.
How does that trade-off happen?
How do you do things separately and it comes out faster?
What we have done was we basically uh part of this whole customer journey, the when you look at the the architecture solutioning.
So we introduced uh one uh I think there are like multiple Kafka topics for each of the downstream applications.
For example, fraud check is one of the downstream applications that you know process independently.
And the new account build when the customer basically applies, was the fraud check is successful, you know, the next process is is to invoke the new account build so what we did is we had two different Kafka topics and each of the topic is consumed by a multiple consumers right so fraud check process is one of them and then credit scoring check is one of the processes and then then there is an actual new account build that is another process.
So all these different downstream systems were subscribed to one of the Kafka topic and each of the process independent independently process their you know things uh and at the end we are basically letting the customer know that your icon is successfully created and then there is a notification process goes back to the customer uh you know I think the main success criteria what we have seen is when we introduced asynchronous processing and when we when we let the downstream applications process independently and also we have a freedom to deploy the changes more frequently.
So because of this asynchronous nature and decoupling, we let each team deploy their application solutioning independently without impacting each other.
Yeah.
So there's that process for the the full developer experience, the full CI CD like cycle and and software delivery life cycle of not only can the software get better, but where we find there's a bottleneck, we can now target just that as opposed to working on the whole monolith.
So there's a little bit of an aspect of good reasons to do microservices to break it up to have individual teams be able to work on individual processes.
And also the fact that you you had to redesign it to be asynchronous, I'm assuming.
So it used to be like start the process, like customer requests and then like you're waiting for that one thread to basically finish versus now it can fan out and do parallel work.
Is that one of the benefits you're seeing is that all these things can go independent, you know, side by side as opposed to serially.
Exactly Thomas uh that's what uh we used to have so we used to have one monolithic uh big giant application you know that handles all of these processes systematically like in a synchronously when the customer there is a UI application that tightly coupled with this monolithic uh web application and then you know it needs to process everything like step by step.
If one of the steps fails, we are not letting to process the other systems.
So because of this asynchronous decoupling and microservice architecture, we actually you know decoupled all this monolithic application into multiple microservices, introduced event streaming via Kafka.
And then you know, we we we saw very good performance.
As I said, you know, I think uh the engineering teams are independently working on each part of this uh back end processing, and we are able to deploy more often deployments.
Earlier it was like, you know, maybe every quarter we used to do do the deployment.
Now it is like on-demand deployment.
Whenever the team is ready to be the new capabilities, we are basically you know uh more frequently doing a deployment via C S V D pipeline.
And you mentioned SLAs at the beginning.
Do you see other reliability and performance benefits with splitting this up?
Um and how is that measured?
How did you detect and and you know what were the metrics you used to decide that we are now a healthier system and it was worth the the re-architecture?
So we have the observability pattern implemented across the different uh services, uh starting from the UI screen to all the way to the uh different microservices level.
So what we used is a concept called trace ID.
So one of the common attributes that we shared across the stack.
So if you want to basically see what happened with one particular transaction, we go to you know some of the uh observability tools like Splunk.
We we look at the trace ID and it gives the whole history like from the beginning to the end.
So I think Splunk is one of our main uh you know observability tools.
And also we use uh Dynatrace and uh dynamic app dynamics.
Uh those like we'll give you like when you when there is an issue happens, tools gives you like more granular level where exactly the problem happened.
So we sometimes you go to Dynetrace to drill down and find out where exactly the exceptions are maybe when where exactly the failure is.
So I think uh we rely sometimes Splunk, Dynatrice, and app dynamics.
Yeah, and that's all built on using open telemetry, I presume, and standards that the industry has come up with.
Like, here's how you do all this stuff with modern cloud native solutions.
Now we we were talking about financial services and look especially in the US, financial services have this uh like old, stodgy mindset of we use technology and it works.
Like I worked at a bank not that long ago and we still had mainframes.
And I think they there's a lot of banks that still have mainframes, those are very much not modern technology.
And you're talking about Kafka and event streams and and stuff that's within the last few decades really taken off versus integrating with stuff that's several decades old.
How do you make those systems work together and how does the business adapt to transitioning from something so legacy and stable and reliable to you know this new newer technology and newer architectures?
Right.
Yeah, I think that's a very uh interesting aspect.
Uh I think every organization has been going through this uh shift.
Uh so at SCI, we do have uh we used to have the mainframes, the core processing.
I think the whole check-in and uh credit card platform was built in uh mainframes.
So what we used to do is I think we look at the system end to end, see if there is any particular domain we can build shift and you know, build outside the mainframe.
So we tried with the uh very specifically in the credit card side.
Uh, you know, we took one of the functionality called uh new account build.
Right.
So what we did is the system still relies, still goes through the mainframe, but once the mainframe builds the account, we are actually introduced an MQ layer, right?
So the COBOL, the mainframes COBOL program basically published that into one of the MQ layer.
And then from distributed technology side, we actually develop one MQ listener that listens to the events that listens to this MQ messages, and then basically translate that to a Kafka event and publish to the one of the topic.
And we have a downstream systems which actually consumes.
I think there are like four to five consumers.
They continuously look into this newly built account.
Based on that newly created account, and we had some of the use cases.
Whenever we open, whenever customer opens the new credit card, you know, I think uh there is a you know there is a concept called uh priority pass.
So basically, uh customers without relying uh on the manual manually opting for the priority pass.
So this because of this, you know, the event streaming solutioning upfront, we are basically creating the priority pass.
So it's basically hybrid solutioning, like you know, the all the way from the UI screen, check uh US screen to the mainframes to the you know the outside solution, what we build, you know, AWS public cloud, where this information is being available to the outside world, and then we are basically creating some of these uh you know business use cases out of it.
Well, and I like how that um encapsulation of the mainframe, the mainframe emits events effectively.
Like this is the data, but an event occurred.
And so it seems like event streaming and event sourcing sounds like a natural fit for how to use those legacy systems rather than have some tightly coupled down at the you know cobalt layer, you you look at where's the business boundary, where's the business event that occurred, and that's the thing we we build our systems around and we respond to that.
Did that mindset help with design and development and requirements to say, hey, this is how we build the systems?
Yeah, we started with uh hybrid, you know, solutioning in the keeping in the mind.
Uh, you know, I think uh slowly we are moving towards the the event sourcing and uh event-based mechanism.
The idea is once we have the data available outside the mainframe, and once we create the SOR systems, the system of record SOR system, slowly we will move away from the mainframe system.
That was our main thought behind it.
So we are basically moving some of the functionalities outside the mainframe.
And then you know, once some of the critical functionalities become available using a distributed technologies like you know, the microservices, event streaming, observability patterns, and then you know, the maybe in the next decade, probably you will be slowly moving away from the mainframes.
And do you see the event streaming as a way to help move that away?
That you can get to this event occurred and it doesn't rely on this technology implementation.
If the checking account was created, you shouldn't care that the checking account created means this record in the mainframe exists.
It's the checking account is created.
So is that gonna help with the future migration plans?
Exactly, exactly, Tango.
So one of the benefits we are seeing with this event streaming is you know, I think we we have a capability to look back the whole history of the events.
For example, customer opened the checking account, and then he started depositing the money.
So for each of the actions the customer performs, you know, we are actually relating those actions to an event, and then there is a capability to look back what exactly happened for the particular customer interactions with the system.
So I think event sourcing and event streaming is really helping us.
Not only just creating the SOR system of record outside the mainframe, and also look back what are the unrated ability standpoint and replace standpoint.
You know, I think all these capabilities are really helping.
You know, very particularly this history of events, whatever the history happened, you know, we we could able to replay those events.
And so do you have a you mentioned a system of record.
You also have a system of reference.
I know that's one sometimes one model is we're doing this gradual transition.
We'll um have what's in the the mainframe is replicated into a system of reference, but it's not the source of truth.
We know that we still treat the mainframe as the system of record, but you can then start gradually transitioning, sort of using the strangler fig pattern of we use the system of reference to query stuff, but now we can get to our updates instead of writing back to the mainframe, start writing into the new system of record.
Is that on your your roadmap of how to make that transition happen?
Exactly.
So that is our complete uh roadmap.
So we are looking after after, I think we implemented in our area like maybe five critical business processes using this event sourcing, event streaming.
And as I said, system of references, you know, getting translated very nicely end to end.
And we are looking after to become our the distributed side solutioning, becomes the S system of record that is our top game goal.
And also there are a few patterns we implemented apart from you know streaming the data outside the mainframe.
There are a few tools like there is a tool called CDC, change data capture.
So whenever there is a change happens on the mainframe, uh, for example, IMS is one of the mainframe database.
So this tool streams the data and we have a reconciliation patterns.
So what we do is, you know, we take the CDC stream the data and the system of risk reference data, we compare.
We have some of the solution implemented using some of the Java framework, uh, Java and Spring.
So what we do is we throw the day, we run a reconciliation process.
We just compare how the data is looking at uh on the AWS public cloud side, like the uh you know the distributed side versus the mainframe side, and we generate the report out of it.
So eventually we are looking at how the quality of the data data is so far.
We have seen very positive results.
You know, I think the data is like pretty much accurately reflecting in both the places.
Uh, once we get like more confidence, probably some of the other processes also we will slowly move to the the new, you know, distributed side.
Yeah, it's it's definitely a gradual transition.
How do you get all of your stakeholder buy-in to what is not a you know quick quick win?
Like we have to do this and it'll be done on Tuesday, but this is going to take a while.
And how do you build the confidence into we're measuring that these two systems are getting to be more in sync?
And now we're at a point where we can trust it.
How do you get the, like I said, the the product owners and the business sponsors and other people that aren't just the technical side to all agree with what's what's the process and how do we do that?
Right.
So some of our stakeholders, like product owner, you know, tech manager, execute directors, we have shown them some of the successful implementation.
Uh, for example, this new technique con we have built, you know, using this event streaming solution outside the mainframe that has become very successful.
And also we've shown the confidence by running through this reconciliation process, right?
So there are two to three critical solutions uh literally implemented outside the mainframe.
And one of the big advantage and one of the one liking factor from our leadership team is that this new solution that we are building outside the mainframe, we are actually keep on adding additional capability and the time to the market has improved a lot.
Whereas the mainframe system, you know, I think if you want to incorporate any of the changes, I think there is an auto process, a very delay, lengthy process involved.
So our leadership team, our stakeholders really love to see that's new capability implemented in the faster way.
So with these two solutions, what we implemented so far, they'll really load it and they want to basically move forward with the the some of the other critical processes as well.
Well, that that leads into my next question, which is what were the the big motivations for this?
I think people hear mainframing, like, well, that's old technology, we want to get off of that.
But that's somewhat the engineer perspective of can't we just use a new shiny thing?
Um, but there's also the business aspect.
There's not a whole lot of people who still know how to program COBOL.
And there's just good business reasons to start moving away from that.
Uh, you touched on a little bit of we want to add new features and functionality so that it doesn't look like we're still working in the in the 1980s.
And you can't do that quickly.
Uh, what were the other factors?
You mentioned reliability and just the um the speed for the SLA is not being met.
What were the other factors that said, hey, this is when it's time to actually go through this process and do this this major migration?
Yeah, I think one of the major challenges that we are seeing is the continuous integration, continuous uh deployment.
That is actually one of the major uh lacking part in the mainstream side.
You know, whenever there is a lot of tools, you know, I think on the distributor side, there is a continuous improvement is happening.
Uh, whenever a developer writes the code, there is a thorough end-to-end solutioning already in place.
The moment that developer commits the code to executing the automated functional test to running the score scans to, you know, uh deploying into some of the cloud regions like blue-green way, right?
So uh automatically checks after the code is got deployed to one of the region, there is automated functional test we are executing, ensuring the new code is meeting the expected behavior, and then you know, turning on the traffic to the newly deployed code.
But this pattern, this solutioning is missing on the mainframe side.
So if we are struggling.
So I even uh to deploy, there is a lot of downtime.
There is a, you know, some of the uh we actually clue with there is a concept called packaging.
Um, you know, I think uh even the CICD part is very little difficult on the mainframe side.
Um yeah, so the main advantages we are saying is like our main goal is to time to market.
So time to market is one of our uh main goals.
We want to continuously add the additional capabilities, and we can basically speed up the things very fast.
But whereas this mainframe, I think uh, you know, we have some of the challenges, right?
So that is a main motivation to move towards the uh distributor side.
Was security also a factor?
I know mainframes have a different security posture, like they're safe in some ways because they're not the same stuff that's hackable.
That's you know, oh, here's the new Linux, and everyone knows how to get into it or whatever MPM package.
So they're sort of shielded in a way because they're legacy, but they're also notoriously difficult to upgrade.
And even if we're not talking mainframe, if we're talking about other systems that are just you know, 10, 20 years old, those things need patching as they're some benefit to doing modern microservices.
And how do you make sure that you're not introducing new security issues because you're not on the bleeding edge, but closer to modern technology?
How do you get again all those factors come into play with building these new systems and keep everything secure?
Yeah, so definitely.
I think uh mainframe has been amazing in terms of the security standpoint.
You know, I think uh historically it was proven.
I think we never have, I mean, continuously, you know, mainframe is being a fantastic job.
So one of the factors what we are doing on the distributed side is that uh we are introducing a environment as a code.
So it's one of our uh new offering.
What we do is uh we write the code to spin up the new environment.
And you know, behind the scenes, we are using a uh uh, you know, I think it's an open source tool called uh Terraform.
So what happens is uh we keep on adding the security policies on top of you know this environment code.
So developer standpoint, the developer is just focuses on the business code implementation.
Um, but there is a couple of departments delicately working on creating this uh you know security policies on top of this platform.
I think we call it as an environment as code.
So I think the security processes are continuously evolving, and we are actually implementing at the platform level.
And developers, you know, the engineering side, the engineers are also responsible to you know expose some of the capabilities using the, you know, maybe OAuth-based mechanism.
For each of the API that we expose, you know, we have uh very uh thorough process involved.
You know, each of the API needs to go through API governance process.
And, you know, part of that we ensure we have this OAuth-based mechanism.
And we look at the each use case independently, uniquely.
There are various patterns we follow, not only just OAuth.
There are some of the other patterns.
Maybe sometimes it depends on the business use case.
We go with the you know third-based uh mechanism as well.
So there is a XYZ9-based OAuth-based.
We are continuously evolving on the security standpoint.
One, we are implementing at the platform environment as code level.
And another one is you know, looking at the each aspect, what are the best practices we can implement?
Yeah.
And I think that that's a good case study of these aren't like bleeding edge new ideas.
These are established patterns that you can go out and find.
Here's how we build a good platform, here's the benefits of doing that.
That the platform now handles widespread security updates and like everyone gets it as opposed to each team has to individually go and patch things.
But I think that's also a lesson for other companies that are still in the well, we have legacy systems that are working, and how do we make the transition?
And was setting up all of those platform teams and creating build servers and CI CD and infrastructure as code.
Was that a huge lift for within the financial services industry?
Or is that something that everyone's just doing now?
It's a huge shift, uh, Thomas.
Absolutely agree with you.
End software engineer used to just focusing on the software you know requirements, you know, business requirement, implement the solutions.
Now the software engineer is responsible to look after the security aspect as well as this infrastructure provisioning as well, right?
So at SCI, the engineer is responsible end-to-end solutioning, starting from the platform creation to the introduce ensuring the security standpoint.
We thoroughly spend very good amount of time on the security standpoint.
We look at the solutioning end-to-end, not just one particular small component, whether this security practices are implemented thoroughly or not.
For example, whenever we see any business use case implemented end-to-end, if there is any PI data is being used or not.
So if there is a PI data, we enforce PCA compliance processes.
Uh internally, it's SCI.
So the PCA compliance certifies that the PI data is properly encrypted, properly shared, end-to-end solution, not just like one system.
Each of the system needs to certify the PCI is like certified.
That is one way of you know doing it.
The another one is like we mask the the PI data across the systems.
You know, whenever there is a information is store uh shared data in transit or data rest.
We ensure the data is basically getting masked when we are basically going with this you know logging or you know observation standpoint.
So my ultimate point is the engineer looking at every solutioning very carefully thinking the security in this you know forefront always looking after the business use case if there is any PI data involved ensure you know certain regulatory processes thoroughly followed and we are doing consistently across the different systems.
So just like security and all those things are coming in you know or all this new platform stuff is coming into financial services we have to ask about AI on every episode of the podcast I think.
Where does AI fit into financial services?
Is it something that everyone's pushing for like we need to show that we have AI or is there a trend to you know stay away for it and let it mature a little bit until it's a little bit safer and how do you add AI into the product or into how you're building the products and how do you do that safely and securely and ensure you're getting you know whatever goals you're hoping to achieve by having AI incorporated.
So I think internally at SCI, we started implementing some of the proof of concepts.
One of the ideas we started exploring is anomaly detection.
Anomaly detection is like one aspect without engineers spending a lot of time looking at the various other various metrics like Splunk, dynat race, UI, screenside, you know, it's taking a lot of engineers' effort, right?
So what we are doing is there is a proof of concept we are trying to come up with.
We are actually building one AI model.
That AI model continuously gets the various you know observability metrics, you know, locks is one of them, traces, and we feed this information to this AI model.
So this AI model also we spent good amount of time fine-tuning and you know looking after very specific one, which is really you know doing a good job in terms of site rebuilt engineering.
So we have chosen one particular model, and then we are continuously feeding this different observability metrics to this model.
The model is actually doing a lot of you know uh analysis and giving a different aspect, like where the problem is.
So it is basically giving us a very uh clear information where the problem is actually occurred.
Because if you look at our end-to-end solutioning, there are like close to 50 plus microservices involved, and you know, engineer needs to spend very good amount of time to look after each of the system logs and fine-tune and find out where exactly the problem relies.
But using this AI anomaly detection model, I think as per the initial uh result, it is showing very promising.
So, engineered straight away uh knows where exactly the problem is based on this uh AI model output analysis output, and uh we have successfully implemented one proof of concept.
It's showing a very positive result.
Likewise, we are also looking up looking after the other areas as well.
One more POS proof of concept we are doing, which is like more on the uh introducing a dynamic security policies.
You know, I think some of these policies relies within the microservice code level.
So we want to basically see if we can you know spin up a common platform level um, you know, the security policies.
This AI model basically uh continuously look at the the uh various uh you know the incoming payloads based on that dynamically apply some of the security policies at the platform level.
You know, that is another proof of concept we are doing.
But so far, it has been amazing.
You know, the kind of result it is showing, it is very promising.
Yeah, so you're talking about anomaly detection for anomalous behavior of how the system is performing to say here's a bug.
Uh when somebody says anomaly detection with financial systems, I'm thinking, you know, fraud or there was an unusual card transaction.
Um, but you're not looking at that specifically, you're looking at this from the engineering side, like how to make sure the system is behaving and something went weird, and a human might not notice it, but the model you're creating is able to detect.
This looks strange.
Exactly.
Exactly, Thomas.
Um, yeah, and we internally at SCI, I think we brainstormed some of the use cases.
Uh, I think the one that you highlighted, fraud detection system.
Yeah, I think that is uh there is some thought we have given, and not only this product detection, there are some of the other use cases we are you know exploring.
I think we are at the exploring stage, but the kind of result these two POCs gave us, you know, very good confidence.
Eventually we will be implementing uh at the business driven use cases as well.
So I think that leads us to like let's just look ahead like five, 10 years.
Um, since you're in financial services, where do you see software changing?
You see us moving more into these event-driven services, and that that's catching up with the industry.
And will AI be more involved?
What's what's your predictions?
We are looking for if we're talking about the next uh decade or so.
I think uh one of the major shifts is happening is on the software engineering side.
You know, I think LR we used to spend a good amount of time to deploy one particular business driven solution, right?
To develop and build and deploy.
But now speed to the market is drastically improved.
You know, we have some of the tools internally, the engineers can start using some of these AI tools to speed up the application development all the way to deployment, right?
So that is a one aspect is continuously evolving with this new AI revolution.
So I think time to the market is one aspect.
The next decade you'll see a significant change.
And also we started looking at the you know the advantages of uh AI capabilities.
Uh very soon we will be implementing some of the solutioning on the business-driven use cases.
So far, we have implemented at low risk level.
But I see in the next decade or so, you will see a lot of you know business-driven use cases implemented at the financial sectors, starting from you know checking account all the way to, you know, there is a field, there is a concept called taxonomy.
So customer, when the customer applies for the you know, credit card checking account or credit card account or checking account, uh, you know, they get to know where exactly the system, the customer request is right now.
The whole thing happening at the back end uh you know within the bank, but customer can see more visibility where exactly the request went through, where exactly it is stopping.
Uh, you know, I think the whole inside you will get it.
So what I'm my ultimate point is maybe in the next couple of decades, you will see a lot of business-driven use cases implemented using AI.
Well, I like how that that circles back to our our opening discussion about how having event systems makes it more visible to see.
Here's what has happened.
Um, and surfacing those to the customer can also be useful in saying here's a better customer experience, here's a better you know, product experience, and also helps design and architect the systems.
So I think that's a great place to wrap it up.
Um, so Muzeeb, thanks again for joining me today on the podcast.
Thank you so much, Thomas.
It's a pleasure.
And listeners, we hope you'll join us again soon for another episode of the Imputy Q podcast.