Chander Shivdasani, Goldman Sachs

Thank you for tuning in to today’s full episode of the Breaking Changes podcast. I’m your host and chief evangelist for Postman, Kin Lane. With Breaking Changes we explore specific topics from the world of APIs, but look at it through the lens of business and engineering leadership. Joining me today we have Chander Shivdasani, Vice President at Marcus by Goldman Sachs. Chander stopped by to share insights about their contract-first approach to API infrastructure at Goldman Sachs and how being API-first helps them be more agile and nimble when it comes to responding to the market needs in the United Kingdom.

Let’s just start with the basics. Who are you and what do you do?

Hi, so my name is Chander, I’m currently the tech lead for Marcus UK based out of London, working on the deposits platform for the consumer side of Goldman Sachs.

So what do APIs mean in your world, in this financial world?

So I mean it’s an interesting question actually. The deposits platform that we currently have, it’s a suite of microservices that a lot of them talk to the external services, so API becomes quite important for us because managing such a big real estate of microservices gets quite tricky if we don’t really have any specific common language that we can talk to across our services. And more importantly, if there’s any change in any sort of part of the system, identifying that change and identifying where that has happened and why that has happened makes it quite easy. The API side of things makes it quite easy.

So is this more about modernization of the existing legacy infrastructure, is it more about new products and services to meet the new demand, or is it all the above?

It’s actually all of the above, because there were some services when we started on the journey of launching the deposits platform, we did have some of the services that we inherited, as well as we had an open slate where we could come up with a bunch of new services, specially tailored for our business. So yeah, it was all of the above. I think more importantly, we wanted to be agile as well in terms of reacting to market-related changes, and it proved quite useful especially in the last two years of COVID where we had to react quite quickly to how the external market movements were impacting the deposits industry.

So let’s talk a little bit about how you got here, how you made yourself this agile and flexible to respond. I’m assuming you’re using Swagger, OpenAPI, some sort of contract-first approach.

So yeah, so basically we internally call it contract-first development. There’s this, the way we started back when we, so back when the original team was working on the whole sort of setting up of services and getting one service to talk to another service, a common problem came up quite quickly, because since we were talking to external services and in our dev and QA environment we were talking to their non-prod environment, we were able to see that they were making changes, and we would find the failures when we deployed the service and started testing those services in different environments. And some of those changes even by the external services were done intentionally, while some of them are trivial, like some optional field was changed to mark as required and then all the clients started failing, and there was no versioning whatsoever around that. So it became quite imminent for us to sort of come up with an approach that would allow us to identify these kinds of things as early in the development cycle as possible.

OpenAPI or Swagger was pretty much the de facto standard back then for writing your API contracts. The open source toolings on top of that made it quite easy for us to generate a lot of boilerplate code, and it also helped in detecting a lot of these backwards-incompatible changes. The other advantage we saw as a side effect of this was, since the APIs were sort of descriptive, it became quite easy for us to start reviewing them. So the type of process we started following was, whenever we wanted to work on a change, a developer would start by either developing the API or modifying the existing API, get through that review cycle, get the feedback, and off the back of that they could do the development. So it basically introduced a form of process around how we manage APIs, and it grew quite a bit in the division that I was in. There was an API governance introduced around APIs, because since a lot of teams within the division were sort of working on API and they were doing API-first development, we started identifying some common patterns and started enforcing those patterns across different teams just to keep our APIs consistent. So yeah, it kind of evolved with a small idea of sort of managing APIs in a more mathematical fashion, and then it’s become quite core to what we do right now.

Do you feel that the, I hear a lot of folks say contract-first but you’re using it as the guiding kind of phrase, do you feel like using that instead of API-first or design-first has some sort of impact bringing it closer to business?

I think with business, what we realized was, having these kinds of conversations around what we are building, especially from an API perspective, made it quite easy, firstly, to start identifying how long will it take for us to build something, because we weren’t just talking about random numbers here. Now we have an API that we can look at and we can get some reasonable estimates on what the development would look like. The second thing where it helped us from a business perspective quite a bit was, quite often when you want to work with a new team or an external vendor, it’s not quite easy to identify what that integration looks like. When some of the vendors who support OpenAPI, they can share us the OpenAPI contract as part of the initial discussions, it makes it quite easy for us to start visualizing what we can do on our side, what that integration looks like, and in most cases it helps us spin up a mock server. While the discussions with the vendor are still ongoing, we can sort of look at, get an idea of what we need to do and start sort of developing our infrastructure around it.

Yeah, so it sounds like you’re generating code, docs, you’re able to use this as a way for getting partners on the same page. Did it reduce the time it took to engage with partners and get them up and running?

So it made it easy actually. I wouldn’t say it reduced the time that much. To be honest we never really quantified that, how much time did we really save with this, but it made the process a lot more easy, and basically we were able to have quick turnaround times especially in the lower environments whenever we had a contract from a partner in an OpenAPI format.

Yeah, now definitely creates that common vocabulary, gets people on the same page. So how did it look getting teams up to speed? I’m guessing the design review processes, but how do they learn about the governance and the patterns and what they should be doing across all teams?

So we rely quite heavily on code reviews. The API governance team has a bunch of senior people who sort of get together to discuss changes and come up with what the architectural patterns should be. We rely a bit on them to provide us with guidance, especially for things that we don’t have any common patterns across, because for most of the common ones you could easily find what the best practices are. So that is one aspect of it. The techies that work in the division work quite closely with the API governance team, all of them basically talk to them on a regular basis, they are involved whenever there’s an API-related discussion happening. So essentially most of the senior devs are aware of the kind of guidelines. We’ve got a good level of documentation as well defining what the common patterns are, how we should go about them. And in the end, basically the code review process, anytime there’s a code change, we go through a strict review process, so we discuss why a particular change is needed, and we have a whole sort of discussion around it.

What the API governance team has also helped in, in cases, is that they’re building toolings around these kinds of things. As an example, it allows them to create tooling around identifying backwards-incompatible changes. So things like if we’ve made a field, we’ve deleted a field or added a field and made it required without any versioning around it, it basically gives you the advantage of automating a lot of it.

Yeah, that automation and that enablement that is possible in a contract-driven or API-first-driven reality is pretty key. And I’m assuming this is mapped to your existing software lifecycle through source control, CI/CD and all of that?

Yes, all of it is basically managed in a central repository, which is basically the ultimate source of where the contracts sit. All the review process and everything happens over there, like a typical merge request reviews and then merging if everything looks good, and the key services depend on these contracts whenever they want to generate code.

Yeah, it sounds pretty modern as far as what I see across groups, and really using that contract as the standardizing force. What role does, I know you’re in the financial space so regulation’s a reality, what does regulation look like when it comes to this kind of contract-driven approach?

It makes it easy, I think. Since we work a lot with sensitive data, I think the main important thing we have is to make sure that the sensitive data is handled in a correct fashion, like for example things like it doesn’t get logged anywhere across the entire suite of microservices. What contract-first development and OpenAPI make it easy is basically for us to start identifying those things, because you get a clear descriptive contract and you can see that, hey, I’m dealing with a person entity here and the person entity has a lot of PII fields. We do have certain mechanisms in our tooling that allow us to, for example, audit our PII. So whoever accesses the PII, we can log them and get the ID of the person who has viewed that PII. We have a way to handle the logging centrally where a lot of these PII fields by default are not logged, and then if there is a particular reason for us to log them, then we mask them in a particular way, though we haven’t really had any reason to log PII, but there’s mechanisms that can identify these things. So handling PII is like the main thing that this contract-first development as well as the OpenAPI and the tooling around OpenAPI has helped us.

Yeah, really maps that landscape as far as what is PII. I see it in healthcare space with PHI, and so having that OpenAPI-defined landscape really helps you see the landscape, know where you’re doing this. So I’m guessing this helps you with GDPR as well, that you know where all your data is when they come asking.

Exactly, exactly. And then with things like where your aggregates are, and if an aggregate represents a PII object and you know what those PIIs are, where in your entire lifecycle of a request the PII basically flows through from one service to another, you can then have those kinds of dialogues around whether this particular service really needs this particular PII or this particular field, where, whereas in the previous JAX-RS or Spring Boot kind of world without OpenAPI, I mean you can certainly do that but this gets a little difficult, because then you have to really look at the code to see how your request flows through, whereas if you have a self-described document you’ve just got a one place to see where your PII or where your sensitive fields are, and then you can easily trace it through your entire real estate.

Yeah, that’s powerful. Do you think, is this something that is still very much in the domain of technical stakeholders, or are business stakeholders starting to understand the potential of this kind of OpenAPI-defined landscape?

Well, I think in our case it has been purely technical so far. We, this was, I mean APIs and the processing around it was never really an issue when it came to businesses anyways, because we work quite closely together to come up with, like business sort of tell us what needs to happen and we have a discussion around how that needs to happen. So they haven’t really been discussed, but they are aware that we use these kinds of stuff. A lot of times when we have discussions with them, they kind of understand that if there’s an OpenAPI or there’s an API spec that we can look at, it will make things much easier.

Yeah. And how is this helping you with your legacy infrastructure and evolving? Is it helping you kind of map the monolithic, what’s existed before, and move it forward?

So in terms of that we are halfway there actually. We haven’t really fully gotten rid of all the monoliths or all the legacy systems, but what we’ve done in some cases is introduce these anti-corruption layers in between whenever we talk to services that we don’t have any direct control over. So those, then we define a clear contract for the anti-corruption layer, so basically all the microservices that talk to this external service go via anti-corruption layer. So the contracts on our side we try to keep as clean as possible and as standardized as possible, and all the adaptation that we have to do then sits on the anti-corruption layer. The other thing that we’ve been able to do is, in some services that don’t traditionally follow the model of contract-first development, we’ve still been able to use the client generators for them using the existing contracts, and we’ve tried to reduce the bridge as much as possible. Though that being said, there’s still certain aspects where we have to go and modify the API directly in some of these services, and that’s something that we were sort of looking at and trying to move to a more standardized way of doing that. But it has certainly helped us with the code generation side of things.

Yeah, so gen docs and codegen are the two top drivers of folks, but then realizing the benefits of getting everyone on the same page and mapping the landscape is kind of the next level where people are usually amazed at the visibility, at the control they get over their infrastructure once they start mapping it out. So is this helping you understand dependencies as well? I mean you’re talking about the microservices relationships in there.

Yes, yes. Like a lot of times when we talk about moving a particular component from the old way of doing things to using OpenAPI, a lot of times we start identifying things that, you know, this particular service has this dependency but it’s not using it, so let’s get rid of it. It makes it quite easy, because when you try and start integrating it with the services that do use OpenAPI and you’ve got these code generators, you start seeing things like, okay, this particular POJO is not being used at all, which is quite difficult when you have all this magic happening behind the scenes, like using serialization and stuff, it’s not that easy for you to visualize even using some of the smart benefits of your IDE to identify these kinds of things.

Yeah, and it’s critical to be able to move the enterprise ship forward in any sort of meaningful way. But when it comes to enforcement, and when we talked about governance, when it comes to enforcement of governance, are you finding more success in shifting left, design time, application of governance, or is it more pipeline, hey, nothing’s going to get out the door, or is it combo of, and design reviews help with that?

So design reviews help quite a bit. We essentially try to have everything during the code reviews time, and that’s what the API governance team is quite focused on as well, and that’s why they’re investing quite heavily on the toolings around it, because once the API is merged and let’s say being released to production, then it’s out of your hand, modifying something in production then becomes quite a costly affair. So we try to shift left and try to identify as much as possible during the SDLC. We basically get our changes merged by not just one person but quite a few people. Some of the simple stuff, you’ve got standard patterns, that’s fine, but when it comes to tricky things like pagination and those kinds of things where you don’t really have an established pattern, because you basically are dealing with another service that requires some fields that are not standardized, so we try to have discussions around it. We do involve other teams, because sometimes what happens is you’re working quite closely with this, it gets a bit difficult for you to take a step back and understand if there’s a better way to do things. So we leverage other teams in the division as well, if we need to understand how they’ve been doing things, whether they’ve come across similar patterns. So yeah, it basically gives us a way to have all these dialogues quite upfront, and we try to do it as upfront as possible.

Yeah, and it sounds like it really kind of naturally gets everyone on the same page, they’re more aware, it’s just the pipeline’s not breaking and they don’t know why, or someone’s not gatekeeping, and they’re able to actually understand the reasons and the logic behind it.

Exactly, which helps out a lot.

So what’s the API lifecycle from your view? And I know this is a hard one, it means different things to different people, but if you were to lay out, you know, define, design, deploy, what’s your general lifecycle view of how you move APIs forward?

So like, typically let’s say we’ve got a particular requirement that we are working on. So there would be two things, either that would require us to modify an existing API or it would require us to introduce a new API, and then we typically start with contracts, that’s the first thing we do. What that helps us also from an SDLC perspective is, once we have the contracts, then we can have two individuals, one focused on implementing that contract and the other person focused on thinking about testing, how are we going to test this, and it doesn’t really block us because we don’t have to wait for the SDLC or the development to complete before a person can start testing that. So what we essentially do is we get the contract, send it out for review, the individual might be making changes or at least implementing that contract while the review process is happening just to get a bit more insight, but the contract needs to be approved and merged before we can actually consider the code change to be done. So that happens, and then basically once the contract is merged, then we go through a typical process of the code change, the code change gets merged, and then changes get deployed to dev, and then it goes through other higher environments before reaching production. I think what certainly helps is the testing side of things, because once you know, from a testing perspective, all you need is what the input is going to be and what the output is going to be, which OpenAPI makes it quite easy to visualize, and then we don’t really have to have a waterfall kind of a thing within our scrum where one person is waiting for the other person to implement everything before they can start doing something. So we tend to use contract as that starting point really.

It feels like it gives multiple people, multiple roles, what they need to move the whole thing forward, and everyone just kind of falls in line in a certain process, and it comes together and moves to production. So how many different types of roles are involved in this process? Is it purely developers and QA, is there security folks part of the handoff, what are all the roles involved?

So typically the reviewers also, where the security is at, pretty much all the time, because as we deal with sensitive data, each one of the developers, especially senior developers, have to be quite wary of the changes that are happening, and again coming back to the PII or any sort of authentication-related stuff. So essentially, from our perspective, when a review gets merged, that typically has two aspects to it. It needs to be reviewed from a tech risk perspective, what we call is like application security champion, so we have a process where typically each one of the developers goes through a formal training to understand the risk and security patterns that are needed, so they can embed that as part of their own development lifecycle. So a review means basically two things, the patterns from an API perspective are being reviewed as well as anything from a security or technology risk perspective has been reviewed. So both of these are sort of done at the review stage.

Nice, yeah. The role is not just a design review, it’s a general review, and it encompasses governance, quality, security and education, people learn, the developers who are learning along the way as well, is pretty key. So what’s the gateway landscape going out the door like? Are you guys one central gateway rules them all, more federated approach, multiple gateways, what’s yours?

So we’ve got a multiple gateways model, because different businesses operate a little differently, and so specifically for the business that I’m involved in, we’ve got a separate gateway which we use to, it’s kind of like our front line from where all the requests come in, and we do a lot of big initial checks and stuff over there, and then basically it gets sent to the federated suite of microservices that we have running depending on what the flow looks like.

Yeah, now that makes a lot of sense, pretty common pattern that I see across different enterprise organizations. And so, in the grand scheme of things, are you UK-focused or are you addressing multiple regional concerns as well when it comes to your deployments?

So I think, I mean, we focus purely on the UK business, so not necessarily the deployments are UK-focused, but the business is UK-focused. But it’s quite a collaborative division, as I said, we talk to each other quite a bit, try and understand if there’s a piece of functionality that we can reuse if we need to, but yeah, essentially when we do the development, some of it would be focused quite heavily on the UK business because of the nature of the things.

Yeah. Do you feel, I’m not an expert on PSD2 or financial regulations, but I’ve been following along as a spectator for a while, would you say that the UK is the most advanced when it comes to this type of regulation in not just Europe but the world? Would you say that the model is something that’s healthy and should be emulated throughout the world? Maybe that’s too big of a question.

Well, I mean, to be honest, that’s a bit outside my domain, because we work quite a bit from a GDPR perspective, but anything outside of that is certainly not something that I can comment on. It’s a little different than the different regional-based services that I’ve been involved with, so definitely there’s a bit more strict processes around it.

Yeah, I appreciate your honesty on that. I’m always trying to, there’s a lot of different opinions on whether PSD2 and Open Banking are a failure or not, or a successful one, so I’m always trying to scratch and get new views. But for you, personally, why are you doing APIs? Why does this type of work even, something that you’re interested in?

I mean, I’ve been doing APIs for a while now, different flavors of APIs, because APIs mean different things to different people. Even within the firm that I am, APIs mean different things to different people, but I think it just basically, one of the things I really enjoy about APIs is basically the whole sort of language aspect to it. It’s basically, you’ve got, you’re trying to get one service to talk to another service, how effectively and how efficiently you can make that conversation happen. So that’s something that I quite enjoy. Then you’ve got different aspects around synchronous communication versus asynchronous communication, which you might not use OpenAPI, you might use things like Avro and stuff, but again they sort of, you’re trying to come up with a unified language that you can establish between two services that speak completely different languages.

Yeah, one of the more interesting API conversations I’ve ever had was I went up to Oxford for a full day and spent time with the Oxford English Dictionary API folks. And so it wasn’t just like the OED as an API, but it was their story about how language, they’ve tracked language across generations but across country boundaries, and it really reminds me a lot of APIs. So here’s the question for you, how much of your job is technical versus business versus people stuff? Is technical the majority of it, or is it a lot?

So, I mean, on an average if I consider the last six months or so, it’s been like you could just split that evenly across all three. Though there are different aspects where certain weeks I’m focused a lot on technology and development side of things, certain periods where I’m focused a lot on people management especially around feedback discussions, end of year reviews and stuff. So it kind of shifts depending on what was going on in the business, but yeah, in a six-month period I think that would be evenly spread across all of it.

Yeah, and the people, in my experience, it’s very much a human-driven thing, but you have to know your technology, and you have to understand, like you mentioned asynchronous and Avro, you have to start understanding these other technologies alongside, otherwise you’re going to make mistakes, and that’ll impact your business, cause people issues, and things can happen. I find the people side of it and the org shifting, changing an organization, to be very fascinating. Why the financial sector? What about the financial sector attracts you?

I think the challenge actually. The scale of things that we do is quite impressive with the way we’ve managed it. It’s been quite a fascinating journey, like I joined the team before the business went live, and seeing how things have been before, when we were still sort of trying to figure out what does production environment mean for us and what would the business look like when we go live, to where we are now, it’s been a fascinating journey. The other thing, like the people I work with on a day-to-day basis, they’ve been one of the major reasons, all of them are quite smart, part of the reason I can pick up new technologies is because you just call up someone and chat with them about the particular technology, because there’s just so many different people with diversified interests, it just makes it easier for you to understand what’s really out there. So that’s been the people side of things, working here has been quite fascinating. And then I think the kind of challenges, when you’ve got one sort of, I don’t want to call it legacy system but let’s say old system, because we don’t really deal with legacy systems that much, but the things that we’ve built three, four years ago, people are going to call it old legacy systems now, and how do you keep those kinds of systems continuously evolved with the latest trends and stuff, so that’s another fascinating aspect to it. The other thing was the domain itself is quite interesting as well, because if you think from a customer perspective, you’re building something that I can actually tell my parents, my wife, what I’m doing, it’s a digital bank, they understand what that is, so from a customer point of view it’s a simplified view, but there’s a lot of technical integrity that happens underneath, like when you’re dealing with payments, when you’re dealing with regulations. So it’s been challenging from all across the corners, and it’s been quite rewarding as well, because when you build something and you can tell people that this is something you’ve built, you can visually get some sort of feedback from that.

Yeah, I think relating to normal people what we do is always an interesting challenge. I think most of my family thinks I play video games for a living because they really don’t understand APIs. So payments are pretty universal, everyone’s going to understand that one, so I like that. As far as being able to do it, do you think being API-first, because of what you said about legacy a little bit ago, an interview I did a few weeks back on an AWS architect, he said, well, did you write it yesterday? It’s legacy code. And so do you think being API-first is going to help prevent so much pain with legacy in the future, that we’re going to be able to move forward and iterate?

I mean, it definitely will help, but I think it needs to be continuously evolved as well, from my perspective, because, and this has happened to us as well, quite a few times where we’ve taken some API-related decisions that made sense to us a year or two ago, but a lot of the assumptions that we’ve made, a lot of the preconceived notions that we have, and our technical expertise have also since then increased and changed. So as long as you keep up and as long as you go back and revisit and just try and understand whether it still makes sense, sometimes it might not make sense and you have to figure out whether we want to do things differently. But I think what I find quite useful in this case is, it’s just one document I need to go back and check whether it still makes sense, whether the learning that we did today can be retrospectively applied to any of the things we’ve done in the past, and OpenAPI gives you that sort of power and tooling, because you could just version your API, deploy a new version of API, test that in different environments, and just flip a DNS area somewhere to get customers to start using the new servers. So it definitely helps, but I think as a technologist or as a developer, we need to go back and keep re-evolving the things that we’ve done only if it makes sense.

Agreed. So has COVID world changed your approach or in any way who you are, what you’re building?

Not much actually. We’ve had a lot of these asynchronous ways of communication, and even pre-COVID we were sort of moving towards a more memo-driven approach to how we do architectural stuff, because a lot of times the common challenge we had, and this was pre-COVID as well, that a lot of the architectural decisions that you take, everyone sort of agrees to and it makes sense when you’re taking it, but since it’s not documented, like a year or two down the line or even a few months down the line, you look at it and you think, why did we make this decision? So what we’re trying to do is to get a bit more of these decisions documented, and then the process that we want to follow is a lot of asynchronous way of getting feedback from stakeholders, because it’s just not scalable to have meetings all the time and expect people to join and provide their opinions all the time. So having a document where you define your constraints, the architectural approach that you’re taking and why you’re taking it, and then sharing that across to different stakeholders so they can provide asynchronous feedback, that’s something that we started to do even pre-COVID, and it helps on multiple levels. You’ve got new joiners joining and you’ve got documentation completely ready of your architecture that they can just review and they can reason out as well, because a lot of times it gets quite difficult for new joiners to reason why they are doing it in a particular way, because you’ve got a fresh perspective and you think that this could be done in that way or this way. So having a well-documented reason, and more importantly the kind of architectural compromises that you make, having that documented helps quite a bit as well.

Yeah, it feels like the contract-first approach allows us to not just document the decision now, but we have that historical record that anyone can learn from and come and go, because we’re going to have to build for turnover in our staff and our teams, people are going to change departments, people are going to come and leave, and we need that codified as part of our overall capacity. This is what we do, these are our resources and capabilities, and the quality, the security, all that work has to be codified and translatable across teams and stakeholders.

Yeah, exactly. And I think it just makes it easy for us to share it across the different teams as well, like for example if we’ve built something that is common enough for other teams to use, we could just share the contracts with them, they can review it and they can help us platformize a particular component that we’re working on as well. So a lot of it is, and granted a lot of it was not something I don’t think anybody really thought of before doing contract-first, but the kind of benefits that we’ve seen, we not just detect technical benefits but also the communication aspect of what you do has been quite impressive. And I think that has just re-emphasized to us the kind of path that we are on and this is something that we need to continue to follow, and that’s why even from a firm perspective there’s been a lot of investments around how we do things and how do we get this out there to other teams.

Yeah, I mean I talk to a lot of people doing APIs and I tend to categorize people based upon how they respond to things, and the contract being contract-driven or API-first or not is a big piece of it, and how people use that. Because a lot of people will say, well, yeah, we use Swagger or OpenAPI and we publish our docs with it, and then they stop there, and I go, oh, that shows they’re not as far along in their journey. But where y’all are at, you see it’s not just docs and codegen, it’s that holistic collaboration, automation, governance, that whole full suite that comes with it, and that shared understanding that’s essential to move things forward.

Definitely, definitely. And I think huge credit to the people before me who’ve been pushing this API side of things, and it has helped us immensely.

I love the API journey, that’s what this is all about for me. I’ve been doing it since 2010 full time, and so I’ve seen a lot of people at different points in the journey. I’m on my own as far as my understanding. But what do you do to stay interesting, curious, passionate outside of APIs? What keeps you going?

I love poker, I do enjoy cooking, at one point in time I was actually studying to become a chef before I committed myself to technology, so cooking is something I really enjoy. Spending time with my family, I have a two-and-a-half-year-old, he keeps me quite busy and entertained as well. And I would have said traveling, but I haven’t done much traveling in the last two and a half years as well because of COVID, but traveling is another thing I quite enjoy, especially being here in London, it opens up a lot of gates, there’s a lot of nearby destinations that you can simply hop on to and get a completely different perspective.

Yeah, well, enjoy those years, those years that your son is right now, those are the good ones. I think it’s somewhat of a blessing that you get to stay home. My daughter, she’s off doing university in Seoul, South Korea, so I don’t see her as much.

Oh wow.

I miss those days. But enjoy them. Well, I really appreciate this, it’s been a fascinating walk in your shoes as far as how you see the API space. Really impressed how far along in your journey you all are. I would love to definitely stay in touch, feel free to ping me when new releases or new interesting areas that you want to chat about, because I love exploring this and educating folks about the financial space, but even beyond, a lot of people are interesting to learn from, from your experience. So I really appreciate your time today, thanks for joining me.

Thank you so much, and really had a wonderful time chatting with you about everything API. It’s been a good conversation actually, a lot of things I never really sat down and actually thought about, and only sort of thought about how important this has all been while chatting with you, so really thank you so much.

Well, I appreciate you thinking on your feet too, because for everyone listening, we talked before and we had some notes, but I did not provide them with any scripted questions, and I just kind of grilled you and you did great, so thank you so much.

Thanks a lot.

Thanks again to Chander for stopping by. You can find more about Marcus by Goldman Sachs at marcus.co.uk, and you can find Chander on LinkedIn. You can subscribe to the Breaking Changes podcast at postman.com/events/breaking-changes. I’m your host Kin Lane, and until next time, cheers.