I'm Vidya Ishwar. I'm the chief product and technology officer at Forge Global, which is a fully owned subsidiary of Charles Schwab.And today, I'm gonna talk about designing systems that protect financial lives. So early in my career, I actually I'm gonna take you guys back twenty years ago. 2007, there was a big financial crisis with the market crash. I was working at the New York Stock Exchange, and I actually saw firsthand what happens when technology isn't built to handle the real world stress. They all did. Market volumes spiked way beyond what the systems were designed for. Automated trading systems at that time didn't have enough controls and guardrails. So we saw companies that were trading at hundreds of dollars start trading at pennies, and that wasn't just an abstract technical failure. It had real world impact.

People lost billions of dollars. Retirement accounts like four zero one k were wiped out. Infected everyday people, not just institutions, not just faulty investors. Out of these moments, came regulatory changes. We had circuit breakers, short sale restrictions, and those were designed to protect people when the market started moving too fast for humans to intervene intervene and take the night the right steps and controls. So this experience early on really shaped how I think about technology. So when systems fail at scale, the consequences are real and personal. And also seeing this so early, in my career, gave me a different lens that I've now carried into every project, every system, every company that I've worked on. So recently, I joined Forge in, 2021, and we was still trying to define and create the private market category.

People wanted to trade private stocks like you trade public stocks, but it's actually way more complicated because you have bespoke rules, that every company has. There's no centralized clearing, no centralized data, but it's still highly regulated. And one of the big challenges is actually there's no transparency on pricing. On top of that, I inherited a monolithic, technology platform built on Ruby, and that wasn't working well for anyone. Not the investors who came to invest in high growth companies, not the shareholders who wanted to find buyers for these private company shares they hold, or the brokers who are facilitating the process. And it lacked real insight into the pricing for these private company stocks. There was no visibility around what's available, what's the fee, how do you even trade these stocks. And to me, this is a problem that technology can solve. Right?

But with my experience in capital markets, I also understood that this is only gonna be successful if the participants actually trust the system. So data visibility, compliance, security, these can be an afterthought. They have to be foundational from day one. So at Forge, we start, building a whole new better experience with trust at the base framework of everything at the score. And trust is not shiny new features. It's actually what people can see, what they can verify, and what actually holds up when things get messy. And that's very true in financial systems. So when we built our next gen platform, I wasn't trying to polish. It was really trying to solve for something basic, which was lack of transparency at the core. Users didn't understand what was happening, when it was happening, or why. And if you can't explain a system, you can't ask anybody to trust it.

So I told the team that we are gonna build this with four promises to the user. Clear rules, clear data, clear expectations, and clear protections when things go wrong. And in order to do that, we have to start with the foundational data with the right compliance and the regulatory framework that's incorporated to protect the investors. And these are done from the get go, not as an afterthought. Because what people don't realize is when you start taking shortcuts, it actually erodes trust. And people trust systems that actually hold up in a crisis. So if you think about it, the most regulated industries are health care and financial services. And why do you think that is? It's because health care deals with people's lives and finance deals with people's lives earnings and that's the scale of what we are talking about.

And the other big thing was not just having data. We needed to become the source of truth so that people would trust our pricing, and that meant you couldn't compromise on quality or time lateness. So we built, a source of truth for price, forged price. Our proprietary price that has dozens of automated checks, it's built on authenticated event that's used to source them, and our pricing started getting used, you know, by the trusted. So CNBC uses our pricing on air. Yahoo Finance, you can see our pricing along with the public markets. You can compare a SpaceX with a Tesla. And ICE Data Services distributes our pricing to the institutions with 40,000,000,000,000 in assets, and that again goes to the core of the integrity and accuracy that was foundational to the platform.

And we show all of this to our customers with historical trends, real time book, and all of this goes into improving the level of transparency because that leads to more informed decision and that builds confidence in the customers. So that's one leg of the stool because you have visibility that builds confidence. But the second aspect is about building systems that are resilient, and that's key to earning customer trust. And this was another thing, I learned, at NYC when we're building a new platform pillar, and that was about ten years ago. When we talked about resiliency and when we talked about our latency, we didn't talk about averages or what's a peak. We actually focused on what's a 99.99% look like. And why that's important? Because we focused on reducing standard deviation.

We wanted to know how the system would behave under high loads and low loads because otherwise, you're not giving customer a consistent experience, and they don't know what to expect when things actually go wrong. And that's when you really own the trust. So applying a lot of those lessons even at Forge, we had, as I said, a legacy monolithic platform. And one of the key decisions to make was, do we build on top of it or do we actually rebuild? And we made the decision to rebuild, But that was a hard decision because that meant saying, this will take a long time. It'll cost a lot of money, and we have to keep our business running while we build a new platform. But if we didn't make this choice, then we knew the architecture couldn't scale and get us to where we want it to go.

We wouldn't actually be building a resilient system that is required by for the customers. And the key aspect of learning when you think about designing resilient systems is this decision is not just a technology. You need the right people. You need the right culture, and you also need an executive team that supports those hard decision. So resiliency to me is not just a technology problem. It's an organizational one, and trust is earned as an organization. So resilient systems need a good failure recovery handling, but it also needs good judgment, and that's judgment at every step. So you need teams that understand the risk of balancing speed, risk regulation, and need to understand the consequence of every decision downstream, whether it's financial, reputational.

And that organizational judgment is what actually allows a platform to succeed, not just technically, but even commercially to have the right pricing, the right support, the right execution. And that comes to the other third leg of the stool when you think about is in order to achieve that, representation matters. Who's in the room matters? So the people who are building these, systems and when you're designing, influence how the decisions are made, what the system is designed for, what failure modes are being considered, which users are protected, which customers you're targeting. And you need architects that you can ask, what are the five ways the system will fail? Have you tested for those? And that's not just testing the happy path. That includes understanding the recovery time, how the degraded experience would be, what do customers see. And I feel this is really critical because a lot of the financial services company do have existing infrastructure.

So when you build something new, a lot of time, it involves a transformation that you're trying to manage the legacy and the new. And this is something that I learned at every, part of my career, whether it was at NYC or ICE or even at Forge. So recently at Forge, when we decided to launch our core marketplace, we did that last year. But prior to that, we had to run our business by maintaining the legacy systems, meet all the regulatory requirements, support our customers through this transition, while we kept shipping the new system at the same time. So I wanna summarize a few key points that I think would be very helpful for a lot of people when you think about how you design a system to protect financial lives. So designing the system is not about the technology, but it's also about the right guardrails, the right regulatory framework, the right data and visibility.

And when you're building not from scratch, but also transitioning from something legacy, Transformation is not about moving fast or slow. It's actually about moving intentionally. That's technically, that's organizationally, and with respect for the team and the people who are doing the work. If you get that right, technology usually follows. So I would say one of the common things that I've seen people tend to miss, and I'm guilty of that, is people tend to design the end state, the architecture, but people don't plan for the middle. And so everybody kinda gets into it unprepared. But transformation is really a sequence of cutovers, parallel systems, handoffs. And if you don't design that deliberately, then the system and the people can fail for all the wrong reasons. And the riskiest moments are usually not in the old system or the new system that people think.

It's actually during the overlap because that's when you have two systems that are active, the ownership gets fuzzy, and most mistakes get made. So in my career, twenty plus years I've seen when transformation fail, it's rarely at the technology layer. It's actually mostly at the people layer. And I really wanna stress this because I think this is very relevant, especially now with AI. When the technology changes is happening faster than the organization's ability to understand or even govern it. And it's not because people are resisting the change. It's because we are underestimating how hard it is to live inside the change. And the real work is helping people understand what's changing, get through the messy middle, and believe that the end state is worth it.

So transformation works when the team who are doing feel trusted, feel included, and they're able to influence the outcome, not just the decisions made elsewhere. And protecting financial lives requires more than technology. It demands a culture of responsibility. So coming back to one of the lessons I learned in 2007, trust is not earned when things are easy. It's actually earned when they break, when things are hard. So getting it right 80% of the time is not enough because trust is usually built in the last 20% in edge cases, in failures, in moments of stress. And this is very relevant in the age of AI. Our systems are moving not just from implementing the decisions to actually making them, so the risks are even higher. The bias, blind spots, shortcuts actually don't show up evenly, and they may affect the user that you didn't even think of as a default user.

Now I do think women in tech can play a critical role here. Why? Because we ask different questions. What's at stake? Who gets hurt if this is wrong? What happens if this fails? So my call to action really is simple. Don't just focus on shipping faster. Push for guardrails. Demand transparency, design for failure, not perfection. And when something feels off, speak up. That's not slowing progress. That's how trust is built. So big takeaways, I would say, if you're trying to build systems that are resilient, which is a key part of financial systems, build the team as deliberately as the system because you need teams that can raise concerns earlier. You need to treat trust as a core principle, and it's built into the mindset at every step. And financial systems depend on precise data. Otherwise, it has a lot of con large monetary and reputational consequences. So we all know technology shapes lives. We've seen that in the last fifty years.

And as women in tech, I think we have both the opportunity and the responsibility to build systems that protect people where it matters the most. Thank you so much.