EPISODE 1752

[INTRO]

[0:00:00] ANNOUNCER: J.P. Morgan Payments is one of the leaders in payments processing with a staggering 10 trillion in payments handled daily. The company recently released its Payments Developer Portal, or PDP, which serves as a gateway for developers to build and test payment APIs and accept, manage, and send payments on their own platforms. Developing financial APIs at a global scale presents unique engineering challenges, in large part because there is no margin for error.

Jack Gibson is a managing director and head of payments engineering, architecture, and APIs at J.P. Morgan Payments. He joins the podcast with Sean Falconer to explore the design and engineering behind the company's payments API offering.

This episode is hosted by Sean Falconer. Check the show notes for more information on Sean's work and where to find him.

[EPISODE]

[0:01:02] SF: Jack, welcome to the show. 

[0:01:02] JG: Hi, thanks for being here.

[0:01:04] SF: Yes, absolutely. So, where I wanted to start was, so you've spent 15 years or so working with some pretty large financial services companies, companies like PayPal, now JPMorgan Chase. How did you kind of end up spending a good part or the bulk of your career kind of in this space?

[0:01:22] JG: I think there's two things. One is I like solving hard problems and financial services has hard problems to solve. I think the other thing is around industry knowledge. Once you pick up knowledge in a particular area, it's a lot easier to kind of reapply that knowledge over time.

[0:01:37] SF: Yes, in terms of like, hard problems that exist in financial services. I think this is maybe a theme that we'll end up kind of touching on a couple times through this conversation today is. I think people always leap to do like banks and financial services as the place where hard computer science is happening. But maybe you can give a little bit of context there.

[0:01:58] JG: There’s a pretty big breadth of things that we have to deal and solve here. I think that large financial services have those as a whole. Then when you think about the accuracy of what you have to do, people don't want to show up and look at their bank account and be like, “Oh, that number is wrong.” So, there's really not a margin for error around like calculating balances and other things that we do.

From a global scale, we're operating 24 by 7, 365 across the globe. So, we're not really ever down. Whether we're processing transactions in Singapore, whether processing transactions in the US, or everything in the middle, and it's really truly a global footprint. And those things are hard to solve. Then you get into the things outside of the payment in the retail space, you start looking at markets, and you start looking at like high-frequency trading, and where we're making decisions in microseconds.

So, there's a really huge diverse group set of problems that we have to solve. Then that's on the software side. You start thinking the infrastructure, you need to support that. It ranges from bare metal infrastructure to biometrics to highly distributed compute. So, there's a little bit of everything for somebody.

[0:03:02] SF: Yes. There's a lot of surface area, a lot of different types of applications. Also, a lot of different stakeholders and different types of users involved as well. Then, obviously all the scale, like truly global scale that you're talking about. Then on top of that, everyone's expecting things to be real time across these like complicated infrastructures. Some of this stuff's probably been around for a long time. I would think that you also run into some challenges in terms of you can't always be necessarily forward-looking. You also need to make sure that whatever you're doing today is also working with whatever systems were in place there 20 years ago.

[0:03:34] JG: We like to use the analogy of you're changing the wings on the plane as you're flying, which is hard to do because you really can't take down time. You don't really have a chance for a complete rewrite and reset. Because you have that history, you have a large number of clients that have integrated into what you've built.

I tend to think of what we do more as a platform than really as a traditional bank. So, there's applications that are built on top of our applications. Our clients are building systems on top of our services. When we make changes, it's really changes that not only just affect us, but also other enterprises that have integrated with us. So, it's a time-consuming thing. You can't really just swap something out, which I think you start looking at some of the modern technologies and stacks. Whether it's thinking about APIs, thinking about asynchronous integrations, thinking more cloud-based. Those things make that easier for us to change and look forward and make changes faster than we traditionally have the spoke point-to-point integrations. So, I think we're getting better at it and I think there's a higher rate of change as we start adopting newer technologies and approaches to this.

[0:04:39] SF: This kind of like potential ripple effect that you could have with making a change given that you're building on top of systems, people are building and integrating on top of you. Then on top of that, you're a financial service. So, the bar for security is going to be really high and the cost of doing something incorrectly is going to be really, really detrimental to what you're trying to do as a business. For an engineer that's coming to join from maybe a non-financial services background to a bank, is that like a jarring experience? Is it hard for sometimes them to wrap their heads around like, “Why can't we just do it this way?” and get frustrated by that?

[0:05:14] JG: It is. I mean, I came from Silicon Valley prior to coming to the bank. Spent a number of years of both PayPal and eBay. It is. It is a change. There is the, have you gone through the thorough vetting of a particular software stack or particular piece of open source? I think we do a very thorough job around that. So, the pace of bringing things in is sometimes slower and I think that is something to kind of get used to.

There is restrictions around data in and out. I think when folks step back and think about it, “Well, I just can't email that file to me, or I can't copy that source code to somewhere else.” Do you want your banker to be able to send an email with your social security number? The answer is no, right? Folks want that, expect that level of privacy for us to provide to them as customers, and for us to be able to provide that, we have to have some kind of, I won't say restrictions, but guardrails around the things that we do that protect our clients, and that does ripple back into the developer experience.

But I also think that there are areas where we are pushing the envelope around that innovation and that change. We do lead a number and have led open source initiatives where we see there's holes and we start to build things up. We invented AMQP for example, which is in Cupid, which we founded and started running. So, whether that's adopted across the board. I mean Microsoft runs Azure, the Azure Event Bus leverages technology that J.P. Morgan built 15 to 20 years ago. So, I do think we kind of balance that out pretty well, which is really interesting.

[0:06:45] SF: Does that also, some of those types of projects that you're talking about there, contributions to open source, some things that are being used by other organizations that are more maybe closely associated with technology than maybe like a bank? Does that feed into how you think about recruiting and bringing in talent to help solve some of these really hard technical problems?

[0:07:05] JG: I do. I think we struggle with it because we do value privacy so much. We don't share the details of exactly what we do. It's hard for folks to really envision of like, well, what am I going to do? Am I going to sit at a cubicle farm and there's these walnut and oak rooms around me? That's not really what it looks like. We look at our tech centers. They're extremely modern. They are really interesting, fun places to work with the latest and greatest technologies. I've had the privilege to kind of travel around the world and see all of them, and they're great places to work. They're some of the nicest facilities that I've ever seen, which is kind of cool from a facility's perspective.

But then you think about the impact that the business provides to the greater economy and not just the common to people's experiences. And I used this analogy at another speaking engagement a while ago and you look at the scope of what Chase does from a retail perspective. There's a number of banks somewhere around or have a relationship with almost 50% of the households in the US. You look at the relationships that J.P. Morgan has from a payments perspective and doing ACHs for large companies to middle market companies.

You can almost imagine that a lot of the folks in the United States either get paid from a company that banks with JPMorgan Chase or banks themselves with it. For us, that's a huge impact to folks because they're expecting that to work every other week or every week or once a month, whatever that frequency is. That's impactful to people's daily lives and folks don't realize that. I think when you look at credit card processing and what we do on the merchant services side, you swipe your card and you expect it to work. And merchant services, almost a third of commerce globally kind of goes through merchant services. It's a huge number of transactions that go through those rails.

You want to be able to show the gas station and swipe your card and it's going to work. You want to be able to go into a large retail store shop online and have things work. And that's the impact that we have to people is their day to day things that they expect to happen. We power a lot of that and whether it's large online marketplaces or whether it's retail stores or whether it's you're trying to buy a house or a car, you want the wire to go through. Work at the back end that powers a lot of that stuff.

[0:09:22] SF: Yes. It's kind of like infrastructure that we all take for granted except for when it doesn't work, and then you then you hear about it. But the like thankless position to be in in some respect.

[0:09:32] JG: That's the part of the business that I'm in within the firm, which is payments. We're kind of the back end to the rest of the firm. You walk into a retail branch and you want to get money out of your account. Well, how's the money getting the account? It's a direct deposit, which is an ACH or it's a wire or something else, and that's payments doing that. If you're working in markets and you're trading stocks and bonds and you want to move money out of that account, that's a sweep that payments is doing. Or if you want to buy a house or buy a car, we are the thing that powers not only our bank, but also the rest of the banks and the markets around the world. So, it's mission-critical, but it is kind of the thankless back end to everybody else.

[0:10:11] SF: Right. Well, can you tell me a little bit about JP's architecture when you joined? Were hey running on the cloud at that time? Or is that something that you were part of that movement to cloud? 

[0:10:22] JG: I'd say a little bit of both. Part of the movement and we were already a little bit already there. We've gone through kind of the same journey that I would say the rest of financial services and the rest of technology as a whole has gone through. We started out with containers, containerization, whether it was on a mainframe, or whether it was distributed systems. We looked at framework-based application deployment, and PAS-type architectures and we moved through that lifecycle a bit and to more into compute-on-demand via Kubernetes and distributed architectures around that. And that journey has been going on since I've been here for eight years now.

I remember originally bringing in some of the Kubernetes work when I was working on some other projects and it was really about how do we solve developer and test environment experiences. I wanted to be able to test something like production really fast, tear it up, tear it down, kind of have that ephemeral experience. We have large interconnected ecosystem that's hard to do that with bare metal hardware or virtual servers. So, Kubernetes was a great fit for that. Now, it's migrated from those kind of use cases into production use cases. We're running large swaths of the organization around containerized ephemeral kind of compute, which I think is really kind of cool.

[0:11:38] SF: Yes. In terms of like making an investment from a company standpoint into something like Kubernetes or even cloud. How do you work through a project like that? Obviously, you're not going to boil the ocean from day one and do huge migration. You just couldn't afford the time to do something like that. So, are you starting kind of like, we have a problem here. We have a net new project kicking off. Let's build that as if we can just build that from where the best tooling available is, and then you could kind of land and expand that technology throughout the organization by having success?

[0:12:09] JG: It depends. We were just having this conversation this morning around some of the transformation work we're doing on some of our core systems. In that case, it's really around, when I think of a sandwich, we’re working on the slices of bread and really kind of avoiding the middle because that's where the hard stuff happens. So, how can we affect change from a technology perspective on the areas that aren't really going to break things as much, gain experience with those, really get kind of comfortable about how we operate, and then work our way to the middle where some of the harder problems are at and things that are, if they do break, they have more damaging impacts across the estate.

So, we try to minimize stuff where it could break things, where could customer client impact until we get to a point where we're comfortable running it. I think that goes back to your earlier question on
adopting new technologies and change. We're very, very measured about where we first deploy something because we think about what the client's going to feel if we get it wrong. Then, we do that relatively fast. We take on new technologies and experiment pretty much on pace with the rest of the industry. In some areas, even faster. When you look at AI and some of the investments we have there, we look at some of the things we do for low-latency computing. We tend to be in front on those because they really affect the business and other areas were a little bit measured.

But when we get down to the core processing, we take our time and kind of work through that. Again, you don't want to hurt a client. That's the first thing.

[0:13:33] SF: Is there parts of your sort of critical infrastructure that you need for a reason, has to always exist under JP's control and you wouldn't be able to move into something like a cloud service to take on?

[0:13:48] JG: I think there's opportunity to move a lot of the estate there. I think when we get into systems that have globally systemic impacts, we're going to think twice, three times, four times, about the pace that we want to put it out there. I think there's bits and pieces of those that are already kind of moving towards cloud, whether it's private or public, as we run both. We think about those things.

Now, there are regulatory constraints around what sits where and how that data is managed, and we're exposed to things like KPR. You look at some of the privacy laws in the US, in different states, they vary. California has a different set of rules than we do in Texas, for example, where I'm at. And we have to be aware of those and manage really around the client and the regulators and what they're – how they're steering us. But I think we do have mixed workloads for a lot of our state. And we'll continue to have mixed workloads. I don't see an end to that, just based upon the diversity of the requirements coming in, which really kind of drives us to compatibility and portability.

When you think multi-cloud, for us, it's the ability to run workloads wherever the client requirements or the regulatory requirements drive us. So, my goal is the head of architecture and engineering is to make sure when we select technologies, we're selecting ones that can run wherever we need to go run them. So, whether I need to run it on public cloud, I want to choose a database that can run both in our private cloud and in our public cloud. I want to choose messaging infrastructure that can do that, which is why we push for open standards and then we push for compatibility. We leverage a lot of open source and things start with open source because it gives us flexibility around different providers that we could possibly choose in different software stacks we could choose.

[0:15:29] SF: How much of that is like abstracted away from me as an engineer? So, if I'm working on a particular application at JP, like do I have to be thinking about, where is this going to run? Is this running on hybrid cloud or a cloud? Or is that sort of piece of it? Are there good systems in place essentially to abstract away some of that complexity for me?

[0:15:48] JG: I think that's a bit of a journey. I think we've put so much effort historically into our private cloud that our engineers don't think as much about it, because it's a lot more mature from the tooling that we've surrounded around it. So, if I want to get something live in our private cloud, it's relatively straightforward. It's almost point, click. We're built into the CI/CD pipeline, and our whole SDLC is around that.

When we start thinking of public cloud, we haven't built a tooling necessarily around that yet, right? And we are building that. We're building parity into that. So, I think over time, developers really shouldn't really care all that much where things go. Now, there's always going to be subtle differences, whether it's monitoring or how we think about capacity or how some of the networking and particularly IM is different between the two different deployment models.

Those are things we'll have to be aware of, but generally speaking, I need a database. I need to be compatible with this interface or this underlying language or this protocol. I need to be relational. I'm going to pick one or two that we have and you're going to go there. I need something that's distributed. That's going to be a key-value store. I know that's quorum-based, run across multiple geographic regions. I'm going to pick one or two that we support. When it's on-prem, it's relatively straightforward. There's a bunch of tooling around it. There's probably two or three more steps to get that thing up and running in our public cloud infrastructure, but that's not a reference of the capabilities between the two. It's just our tooling hasn't evolved there for parity yet. That's work in progress.

[0:17:20] SF: Okay. In terms of people doing development, are they actually developing this stuff
within some sort of dev container environment so that I can have an experience? During development, it's going to be hopefully similar to what's going to really exist in production? Because those environments are drastically different. You can run into all kinds of challenges. But given how complicated things are set up, it's kind of a hard thing to replicate in the local dev environment.

[0:17:46] JG: We have a couple of different set of tools around that. We have a whole developer shell where there's automation at a command line that looks like it's a Linux kind of interface to it and you can set things up and spin them up and kind of work in that command line if you're comfortable with that. We have containers on the desktop for developers that work in a containerized environment if that's what they so choose. We have some really interesting new automation and experiences that come out with more kind of a web-based development environment.

So, we have a bunch of different flavors depending on kind of what your needs are. And the same goes with IDEs. Developers are a particular bunch and we like what we like. When I first started developing, I was stuck in a command-line Java development tool. That's what I want to use, almost like a text pad. I stuck with that even when Eclipse came out for a while because that's what I liked, right? I think we offer Eclipse-based environments. We offer more of a Notepad++-type environment for folks that want to do that, and there's folks that want to run like VS Code and other types of tools.

We offer multiple different IDEs, multiple different experiences, that really kind of fit your development needs and your preferences. We have folks that are on the same team that use different tools because that's what they're more comfortable with.

[0:19:03] SF: Yes, I think you're right. People want to use what they want to use. Even if you look at
the latest survey results from Stack Overflow Developer Survey, Vim is still hanging on there, still like the top 10 of development IDEs, which is amazing.

[0:19:18] JG: I still use it, man. There's folks that still use Emacs.

[0:19:20] SF: Yes. Emacs was what I started out with. So, going back to Kubernetes, given sort of the scale that we're talking about, as well as the fact that its financial institution can have downtime, how do you manage the scalability and reliability of those Kubernetes environment?

[0:19:37] JG: We approach everything kind of from a blue game perspective. We want multiple copies of everything up and running at any kind of time. So, think of multiple pools. I want an A pool and a B pool and we look at that not only within a particular deployment, but also geographically. I want
an A prime and a B prime in another location and we roll out software changes and infrastructure changes around that, particularly in the payment space. It's one of our mandates.

So, we think about how we're going to introduce change and how we're going to scale up inside and outside of the containerized system at the pure infrastructure layer, as well as within the container and then within the software itself. Each one of those layers, we try to have a redundancy, scalability, and compartmentalization of failures and change so that we can introduce change, have failures and not take out the whole estate at one time.

[0:20:29] SF: What about security and compliance within the clusters?

[0:20:31] JG: So, when you think about that, we start with the SDLC. As we go through the process, we're inspecting everything as it goes in and recording the changes and differences from what we expect. We're inspecting the whole manifest of what is getting deployed in the Kubernetes cluster to what's getting deployed within a Docker file of somebody who's doing that, to what ports and stuff you're allowed to interact with and where are secrets kept, et cetera.

So, all of those things, where they can be are shared type services that we protect and allow the developer interface with through an API, or we protect it through the interfaces in the SDLC itself. We think about the Kubernetes infrastructure, the control is managed out of our infrastructure organizations. So, the developer really doesn't get access to the control plane and things that run within that.

If you play within the sandbox, it's relatively easy to get things up and into production, up and running, and then we manage interfaces outside of the sandbox that you're building your application in.

[0:21:33] SF: Where are you investing in serverless today, and how are those kind of decisions made? 

[0:21:38] JG: Our serverless interfaces right now and our functions are really kind of focused on the public cloud. We haven't brought a ton of serverless into the private cloud yet. I think that's one of the
differences where I think public cloud and the public cloud providers are really ahead of the game. When you get into the Kubernetes space, I wouldn't say it's awkward, but you don't have the same kind of rich capabilities that you have with the public cloud providers, particularly the abstraction of the programming around it. You still have a little bit of the, I'm building a container, I’m deploying the function as a container into Kubernetes, and running it there. Versus, I'm just deploying on a Lambda or a function or something else.

The maturity is not there. I think when you start talking about the infrastructure, we still end up managing a Kubernetes cluster at that point in time. You're still looking at your main space, you're just still looking at deploying your own set of resources. And when you're thinking about your node groups and how those are all set up, you're still managing all that infrastructure, so you haven't really abstracted away. I think that public cloud has still a bit ahead on that one than the cube status, right?
Because we still manage the infrastructure. We haven't got out of that.

[0:22:51] SF: I mean, do you see, I guess like value, if you move away from having to manage an infrastructure just around the cost optimization?

[0:22:58] JG: I think developer efficiency, not necessarily infrastructure cost. I think when you start thinking about, I just want a focusing at a task at hand, I want to automate that task or I have a particular set of responses that I want to manage. We're going to get the most value out of that first because we don't have to build the rest of the ecosystem around it that you would normally have to build. I don't know if we're at the point of where some of the larger ecosystem of Internet-type companies that have built full applications suites. Their whole front-end. Their shopping carts, everything on functions, and they're not running any servers behind the stage, or not running containers.

That's a big leap for us. I don't think we're there yet. I do think serverless and functions really are for us around the automation space and taking care of tasks outside of the main applications. That I see picking up as we kind of get that more automation, more manageability, and abstraction with the infrastructure a little bit better in the cube space. I see that coming much more quickly than building a whole serverless estate for a mobile app or for our web-facing applications.

That being said, I do see some really kind of interesting ideas around particularly AI and automation around that. I see serverless could have a really interesting interplay there, but again, that's still all taking shape still.

[0:24:19] SF: How do those investigations into new emerging and innovative technology work with JP? Is there dedicated teams that are just trying to stay abreast of what's always happening and then bring that stuff back into the organization, and then eventually, may find its way into either infrastructure or product?

[0:24:38] JG: There's a couple of different ways that we kind of address that. So, we'll start at the kind of the highest level. There's a whole innovation group and set of processes and functions that even I'm involved with. I'm looking for new technology companies that we want to get to know their technology with. We want to partner with. That goes all the way up to the senior leadership from our CIO down to our CTOs. We’re all the chief architects and heads of engineering. We’re all involved in that level, which is that's a really cool company. They're doing something interesting. Let's go figure out what they're doing and could we use it? Could we help accelerate them? Could we partner with them?

The development teams, they're incentivized to go and experiment at the ground level. Let's go try something out. As long as they have the proper risk profile around and they're not creating an exposure, you can go play with something. Our whole bringing a software, we have the ability to bring in software and market as, for investigation. It means, it can get adopted by everybody. But we kind of lower the guardrails on some of the stuff. We allow some of the process stuff to kind of take a backseat because we know it's for experimentation and it's not going to have wider adoption. Once we've vetted and played with it for a bit and maybe we would have run through a couple use cases or a couple of prototypes or one small application of production, then we step back and reevaluate and say, “Hey, do we want this for a larger set of options?”

So, we baked into the software lifecycle, the ability to experiment. There is a culture of try stuff out, but try it out in a way that is measured and protected, but bring it in fast for that, or relatively fast to the top of the house. There are parts of our CTO organization that's out and looking at that stuff, and that is kind of their full-time job. So, we have a bunch of different ways that we look at it, all the way from the senior executive level to the engineer on the ground, wanting to try an open-source framework or something new to dedicated teams in different areas.

[0:26:36] SF: As an engineering leader, how do you create a culture where if want to be able to or have the, I guess, the freedom to kind of play with the technology?

[0:26:44] JG: I think it's exposure. Folks want to know that they're appreciated. They want to know that their leadership is invested. They want their ideas to kind of be recognized. I think really staying engaged with the engineers that are at the ground level, writing the code, experimenting, playing with things, and knowing what they're doing and taking an interest in it, I think it's huge. I think that reinforces that it's important, because if you have a senior leader that's involved with it, they're seeing you on a day-to-day basis involved with that stuff.

As an organization, we have a bunch of programs that we're doing on a regular basis. We have an annual developer’s conference that has grown so large that now we have two. We have one in the US and one in APAC. The one in the US kicks off this week in our Dallas Plano office, and we're flying engineers from all over the world to present the things that they're working on.

With innovation, we have folks that are out trying new things. As an organization, they're carving out time and presenting things to each other and leading classes. These are the engineers that are leading it and showing each other what they're working on. We have Ignite, which is a traveling developer, I wouldn't say symposium, but a set of workshops where we're sharing new innovative ideas from different groups to each other and leading tracks around that.

Then within payments, we have a stability and resiliency because that's really important to us. Quarterly sessions where we carve out time with our engineering community to go experiment, go try things, fix some stuff, find new ways to go fix things, or make them more resilient, or create a more stable environment. So, we're creating incentives, we're creating rewards, and we're carving out time to focus on the engineer and the work that they're doing and really kind of celebrate it.

[0:28:31] SF: I mean, besides some of these things you're talking about, these like sort of internal programs that have focused on innovation and creating like a real engineering focus within JP, I think one of the things I've noticed just as an external person is that you seem to also have invested in external sort of like developer communities as well. I see JP and a lot of the types of events that I go to and I speak at and engage with, either you're putting on workshops, or hosting a variety of talks, or being there as a sponsor. Also, it feels like you really modernize your approach to API's like everything's open. You have a developer portal. The documentation, it all looks super modern, just like you would expect interacting with any kind of Bay Area startup.

What do you think, like on the external side, what has motivated a lot of this change that's happened? 

[0:29:19] JG: When we started this conversation, you and I earlier, we talked about the shift from point-to-point integration. You're a customer, we've developed your relationship with you through our sales staff or a banker, and we integrate them. I wouldn't say we walk away, but we never reintegrate again. You're sending us a file and we're done with it. What we've noticed is that really, we're providing a platform for other companies to build their stuff on. Whether the platform marketplace and they need to do a checkout, or whether it's somebody that needs to build a set of systems to handle their treasure and they're moving large amounts of money and they need it reconciled at the end of the day. They're building software systems on our software systems.

We’re all engineers. That's where I started at. An engineer is going to find the easiest way to get something done that they possibly can. So, they're going to go out and experiment and play with things. They're going to want to learn how our stuff works. They're going to want to compare us to other financial institutions in FinTech to say, “Hey, does this stuff actually work? Can I actually build it with it?” When I would build stuff, I would go home and do it. I didn't do it necessarily in the office.

So, we want to create an interface for the developer because they're part of the ecosystem that's going to be our advocate to using our systems and our software. If they don't like using our stuff, they're going to drag their feet and they're not going to be happy about it and they're going to be [inaudible 0:30:42]. You don't want that. You want people that are going to use your stuff to like, “This is cool stuff. It works.” 

It's really kind of embracing the end user of our systems is the engineer. If we don't embrace that and we just talk to the CIO or we just talk to the CFO, they're going to make a decision, but they're
not going to have an advocate on the inside that's actually building the system on top of our stuff. I think there's a huge change for us to recognize is that a large part of our constituents are engineers. They're the ones that actually touch J.P. Morgan more than the CFO and the CTO and CIO does because they're doing their day-to-day and there's hundreds and thousands of those.

So, recognizing that was a huge paradigm shift for us and then we had to build the ecosystem around that whether it's the developer portal, whether it's some of the open source work that we've done. We have an open-source application called Unicorn Finance that shows how you use this stuff and gives them a full application. Allows them to show and demonstrate how they move money. We went to Fintech DevCon here in Austin, and I think that's where we all met at, was one of the primary sponsors for that, and we built a game. Here's a game of how you could move money and shows how that works with our APIs, and it's really about embracing the developer, showing that you can build stuff with our stuff in an easy way. We do that across the board, and we have our developing teams, marketing teams as well as our engineers, are engaged in conferences like that that we're sponsoring to much larger events where we have partnerships both at a client and at a technology level.

[0:32:16] SF: One of the things you touched on there was this idea that developers adopting JP into their day job, they're going to be comparing you, not only I don't think necessarily to even other financial services. They're going to compare you to best in industry standards of what a technical integration looks like. So, whoever does that best is what you're compared to, even if it's completely outside of the financial services. Because to a developer who's like, I'm consuming an API now, or I'm integrating an SDK, that should work the same way regardless of what the actual service is. So, the bar for that stuff has gotten really, really high because companies have invested so many resources
into it.

[0:32:54] JG: It's a tough bar for us to reach. I think there's something that we're learning and getting better at. I think we've made some really nice strides as far as the quality of the documentation, the ease of use, trying to, I would say, democratize financial services, because it can be really complicated. We have a much more complicated ecosystem that we work within instead of partnerships and regulators and currencies to clearing types. All these things we do are like, there's variable after variable after variable. So, we're just not saying, give us a card, move your money. It's, well, give us your card, move your money. And what currency would you like that in? Would you like a different interchange rate? Do you want that deposited and also hold it and clear it later? Do you want us to aggregate all these different options and optionality makes it more complicated? And how do we make that easier for folks to use?

So, we've taken some of the proprietary financial services languages and gone with Rest and use common nouns and verbs as folks would expect and try to really kind of simplify things for the developer.

[0:33:59] SF: Yes. I think when you're a big platform and you have to serve tons and tons of needs, it can be really difficult to create something that's like actually digestible and simple to use. Of course, someone who's doing something much more narrower, it's always going to look like way easier or more elegant, but they won't necessarily have the flexibility. So, from a design perspective, that's always the trade-off. Besides that, what are some of the unique challenges with building API infrastructure for a bank?

[0:34:25] JG: I think scale is one of the biggest things, right? And accuracy is the other. So, scale and accuracy in computer science tend to kind of go against each other, right? When think of databases, you end up with, “I want something very accurate.” Well, that means you're going to lock that particular record as you're doing an update. That's slow. That doesn't scale as well. I think trying to balance those things out with trying to be precise, but also providing the level of scale and performance that folks expect, is one of the hardest challenges.

I think the other thing is trying to normalize things at a global scale, recognizing that there are different security schemas that are required by law in different places, makes it challenging. Like, “Hey, I want OAuth everywhere,” but I can't always just do OAuth. I may have to do TLS because I was required to go do that on top of it. Those are the things that, I think, make it more complicated, make it more challenging for us, and some of that optionality and some of the differences in trying to make it simple yet flexible enough that you can do different things with it.

I think of our payment API, we can transact in many different ways through a single API and you can really kind of give us four data elements, and we can move money in hundreds of different ways with it, or you can give us a thousand data elements and you can get very precise about how you want to do it. That's providing that, in elegant and simple ways, is challenging.

[0:35:53] SF: Yes. How do you optimized for thinking through, okay, well I have probably some people who are like really, really experienced, have really, really, specific requirements. They want to be able to touch every knob, essentially, to get what they need. But then, you also need to balance that with people who are, this is their first-time experience and you want to make sure that they have a good experience. So, going back to some of those things we talked about earlier where they are not just doing something because the CIO came and told them to do it, but they're doing it also because they're hopefully happy with the experience.

[0:36:24] JG: So, one of the things we do is we give them really simple working examples. You land up the developer portal, for example, and you go look at API specification. You go to the right-hand side. There's the ability to enter in and you pick your language, you set up a couple of basic parameters, and it will give you any of the code, and a working response that you can then take with you and like just copy into your application.

So, we try to get folks get a really simple way of doing things to try it out experiment with it. You don't have to do everything. If you want to get into the swagger docs and like go into detail and figure out that the third nested party is something, right? That means something in some currency, you can go do that. But you can also just start out with, I'm just going to copy the Python version or the Java version or the C# version and run with it, with a couple handful of parameters.

[0:37:16] SF: Between like both modernizing internally on some of the investments that you've made in core technologies, as well as some of the things that you're doing externally around like this developer experience. Was there a necessary to have like a cultural shift or organizational changes in order to do that?

[0:37:35] SF: I don't think we did any organizational changes as a result of it. I think I'm pretty lucky in that our senior leadership gets it and has gotten it for a while. I think they put folks in a position and empowered them just to run with it for the most part. At cultural there is, right? And it's really around creating the incentives. We talked a little bit earlier on senior leadership having visibility and showing folks by taking the time as part of their careers that this is important. So, on the tech side, a lot of that has gone on.

I think on the product, the shift in product is really still ongoing. I think that's pervasive across financial services where if you look at us and you look at other large institutions, it's that shift into the product isn't necessarily an ACH. It's the ACH plus the data, plus the reporting, plus the APIs. That's the product that you're building and you're selling that overall platform set of things to deliver it versus just that one thing. I think that is still evolving. I think you see that across the industry.

[0:38:48] SF: In terms of looking ahead, obviously, there's so much changing all the time in technology, especially I feel like people are really feeling that pace over the last 18 months with everything that's happening in Generative AI. Where's your time and attention right now over the next 6 to 12 months as you look ahead with the roadmap?

[0:39:07] JG: For me, it's three things. Generative AI is huge, and how can it make our customers' lives better? How can it make us more efficient on what we do? How does it free up time, capacity for us to do more innovative things? That's how I kind of look at the GenAI space. Then it's stability and resiliency. How do I make sure that when our customers expect things to work that they work and continue to get better about that? Then the rest is around modernization of our platforms and the continued adoption of both private and public cloud and accelerating that, and getting off of some of the traditional brick and mortar type infrastructure that we would run historically.

Those are kind of the three things. I think the latter is the latter, because we've done so much work in that. I think we've done a lot of work in stability and resiliency, but there's still some work to be done there and get better about that. Then, I think the AI space is really going to get up a lot more of our time going forward.

[0:40:08] SF: So, Jack, as we start to wrap up, is there anything else you'd like to share?

[0:40:10] JG: When I think about, and I think we've hit on this a lot, engineering is, particularly at J.P. Morgan, is a core part of the business. I mean, we are probably one of the largest engineering organizations if not in the US, in the world. I mean, there's almost 70,000 engineers at JPMorgan Chase and it's pervasive and it's how we built all of our products. I've been here for eight years now and I've had three different, maybe four different jobs. Some of them have been because of things that I wanted to do different. A couple of them because I've been asked to go do something different to help out. I think that that's really kind of a fun thing to do about this place is that you have the opportunity to kind of do what you want to do and scale and grow that if you want to focus on something. Or you can kind of be a free agent and go do different things throughout the source of your career. And there's just so much opportunity to do that. It's really kind of interesting and there's not a lot of places like that.

I think if you look senior leadership down, Jamie on down, technology is a huge focus of what we're doing, and it's part of our daily conversations. I don't think a lot of places you had that senior level of the
executives that in sponsorship, that are actually looking at technology as a primary part of the business, which is kind of cool.

[0:41:26] SF: Yes, that's awesome. Well, Jack, thanks so much for being here. I can see why you've been there for eight years. I can feel that you have a real passion for it. You're a good ambassador for JP and all the things that you're doing there from an engineering perspective. So, thanks for sharing that and cheers.

[0:41:39] JG: Thank you, sir. Take care.

[END]