Re-engineering Tokenization Episode 5 | Carrie Jaquith, Global Head of Digital Product, Abaxx Technologies

It should feel easy. It should feel very familiar for the humans that are interacting with these systems. The magic is what's happening under the hood. The magic is the hard work of code that's happening behind the scenes that no one will ever see. - Welcome to Smarter Markets, a weekly podcast featuring the icons and entrepreneurs of technology, commodities and finance, ranting on the inadequacies of our systems and riffing on ideas for how to solve them. Together, we examine the questions, are we facing a crisis of information or a crisis of trust? And will building Smarter Markets be the antidote? This episode is brought to you in part by Apex Exchange, bringing better price discovery and risk management tools to navigate today's commodities markets through centrally-cleared, physically-deliverable features contracts in energy, environmental, buttery materials and precious metals markets. Smarter Markets are here. - Welcome back to Re-Engineering Tokenization on Smarter Markets. I'm Dave Greeley, Chief Economist at Apex Technologies. Our guest today is Carrie Jakewith, Global Head of Digital Product at Apex Technologies. We'll be discussing what makes new technology adaptable by large institutions, the importance of it being interoperable and auditable, and why we should be thinking of augmenting existing PDF-based processes rather than replacing them as we re-engineer tokenization. Hello, Carrie. Welcome back to Smarter Markets. - Thank you, Dave. It is a delight and an honor to be back on Smarter Markets. I am a huge fan. - Well, it's always great to have you here. I always enjoy our discussions on bridging the gap between humans and technology, and how we can make technology fit into our lives rather than forcing our lives to accommodate a new technology. And we've been discussing digitization and tokenization these past few weeks on the podcast. And in doing so, we've been focused on the features that institutions need from tokenization efforts, things like trusted identity, privacy, legal finality. But today, I wanted to discuss with you something else that's needed from these efforts. They need to meet people where they're at in their existing way of doing business, their workflows, processes, and policies. And large companies, asset managers, banks have had to adopt many new technologies over the past several decades. You've been on the inside for many of these transitions. So I was hoping you could share, what is that internal process like? What are the questions that are asked when considering bringing a new technology on board? - That's such a great question, Dave. The questions that are asked are sometimes surprisingly obvious in financial services, technology teams. So they can be as obvious as do we have server rack space? Does this upgrade fall in line with our leasing schedule for all of the machines we have at people's desk? So there are these really pragmatic, sensible, sort of almost accountant type questions that get asked. And then there are layers above that around interoperability. So are the meta tag naming conventions mappable to the meta tag naming conventions we've spent the last 40 years developing? Will we have to remap an entire library of terms? Because if we do, that's real cost. And these discussions have to happen around adoption. So there's that sort of basic, very pragmatic. Does this fit in our CAPEX cycle? Does it fit in our lease cycle to the integration layer? Does this fit into how our data is already structured and works? Does it fit into our security stance? And then there are the human, which I always love, as you know. I really love spending time with solving the human problem. So is it adoptable by all of the humans? We're a global company. Will all of the humans in every country be able to adopt this or just some of the humans? Because maybe there's something we've overlooked. So I always think of those sort of three tiers. There's the pragmatic business operations tier. There's the technical tier of integration layer. And then there's the human. I really do love solving the human tier. Oh, and I'd love to dig into that human tier with you. And this question of, is it adoptable? And are there some examples that you've seen of technologies that were very adoptable and others that may not have been or it was more of a challenge to adopt them? Yeah, adoptable comes up quite a lot. And there are a couple of ways to think about this. There's the, does it fit into my human physical behavior patterns? Is it going to force me to adopt a multi-step change that is going to dramatically slow me down? That is a very common adoption problem, especially on Wall Street, where financial services never stop. The lights don't go off. So if you're bringing change into the environment, you really can't pull the car over on the side of the road and train people. It has to be trainable in flight. It has to be trainable and adoptable in flight. And if it has to be pulled alongside, it can't be so disruptive that the real day-to-day work can't stop. Some of this risk of disruption remediation can be remediated by bringing in extra help for a period of time. And you'll see that happen with different cycles of technology adoption, where you'll see a net new team come onto your trading floor and sit alongside you while this migration is happening. Like that's a very common paradigm. And then there are sometimes failures to adopt where you can really attempt to force the change and the humans resist it. And the team has to go back to the table and rethink their approach on how to deploy. I was thinking about a common learning that comes up when you're teaching students how to design products, data products that sit on very large data sets. Every student goes through a very similar path. Step number one, they dump all of the data into a workspace. And all of the data is visually overwhelming for the human. The human sees 10,000 rows of data, 10,000 columns of data, and the humans who are asked to adopt and test this first version of every student's project immediately shut down and do not adopt the product. They immediately shut down and they're just like, this is too much. What every single student who's building those platforms realizes is, they have to first set up the data, they have to provide a way for that data to be explored and audited, but they have to create a second layer. And this second layer is the human interaction layer. This is the layer of interaction design where the humans are given the ability to see what action they should take and to question and audit if an action seems weird. So if an action, if a recommendation seems weird, they need a way to audit. And I think about this through the lens of adoption. So any technology that is that 10,000 column, 10,000 row presentation will gladly not be adopted. It is too hard, it is too slow. You have to do the hard work of abstracting a way and securing the information that's too much for the human brain. And you need to give them the abstraction layer that is usable, trustable, usable. - And you've used the word audit a few times. Why is that word so important? - It's really important. And it's top of mind right now because so much of what we're interacting with in data space is tied to AI and tied to LLMs. And we're just now as humans interacting with quite a lot of output that is getting generated by machines with very, very slim layers of auditability. And when you're working in financial services with data that is used to direct how nations invest taxpayer funding, how humans purchase bread for the table. When you're working with the data and the tools that affect people's lives and how they're able to manage their finances and manage their day to day, you want to be able to provide them with data that you can attest is true, that it's trustable. And whether that's trading in markets or just buying a loaf of bread, you want to be able to attest that what you're seeing is true. And how do you attest that data is true? Well, you provide humans with a way to attest that data is true by providing them with a way to store a log that is auditable. You provide them with a way to interrogate what you say is true. And how do you prove that the thing that you are auditing is true? Well, you prove it because there's some kind of attribution. So in day-to-day life right now, if you're interacting with chat GPT and you see that little link out to where it is attributing what it is telling you, we're that's such a great accessible way for the audience to link the attribution and audit layer that that is what's happening. And as we apply new technologies and applying that new automations where machines are taking actions on our behalf, attestation, audit, attribution, these three things all become even more important than they already are. And for the large institutions we're talking about, many are regulated, there are compliance obligations. How does that affect adaptability of technology? At the pragmatic, the very basic layer, there's literally a checklist of questions that if you're a software provider and you're coming to a financial institution and saying we have this product, we think it will make your work better. They have literally a checklist where they ask you a series of questions. Do you have this, do you have that? Can you ensure that your data is secured? Can you ensure that the encryption key could be either stored securely on your side or that you could allow us to bring our own encryption key? There are these really lengthy checklists that happen behind the scenes that hopefully most of our listeners will never have to fill out. So there's that layer and then there is the adaptability layer. Will this new product fit into our security perimeter? Or if we have to punch a hole through our security perimeter, are we able to configure that connector securely? - And if you think about some of the transitions that have happened over the recent decades, whether it's paper and pencil to more digital spreadsheets to other ways of interacting with data, moving onto the cloud, were there any interesting lessons that were learned from some of those prior transitions? - I was recently thinking about sitting in NYU Skirball in like 2014 maybe and hearing talks about the future of virtual currency and how important it would be at the time of things that people were really concerned with was privacy, transparency, virtual private cloud, public private cloud and fast forward to today. And so many incredible advancements have been made around securing data on premise in hybrid cloud in virtual private cloud. We've made lots and lots of advances and so many of those advances have happened because we've taken inside financial services, inside the security walls, we've taken care to build in sandboxes and to build in tranches, to build in phases where we'll test things out with public data first and then we'll test it out with private data. But these things, they take years to develop and test and they don't always follow a straight path and they are often informed by on both sides of the development wall, the consumer side informs the non-consumer side or the institutional side and vice versa. There are these sort of leaps ahead on both side that are informed by each other but the development never happens in a vacuum. - And when you think about what's happened in recent years, do you think like a set of best practices has emerged when it comes to adopting new technologies? - This set of best practices for adopting new technologies often centers around the why. So why are we adopting? And that's such a great question to ask. The what will happen if? That has a broad range of what will happen, best case, worst case. And what is the benefit? There are lots of steelmen and strawmen that happen but really the why. The why is probably the biggest anchor. When I think about working on developing digital title in the way we've approached it, there is this why that comes up. Why not a PDF, right? And when you chat with Mike Pell who worked on developing PDF, like PDFs are this incredibly powerful tool for digitization. They were intended to allow you to read data the same, no matter what device you were reading it on. And just that alone has had the most massive impact on how we consume data in digital space, how we consume what was paper in digital space and what PDF didn't do because it was never intended to, was it didn't include privacy components and identity components and encryption components. It was never the goal. The goal was to make this data transportable and readable across many spaces and many devices. Its goal was never to make sure that the data was not duplicatable. It was not copyable. It was never meant to ensure that the data could be attested as a one-time data point that wasn't copied. It was really meant to be very readable. And so when you look at how we're thinking about re-engineering around augmenting that PDF experience, augmenting seeing paper in digital space and embedding it with attributes that allow it to be highly trustable and also privateable TM, that is where building these tools for humans that allow them to both read and trust, read and ensure that something is private. That's where this is such an important piece of work. - And I think it's such an important point, this idea of thinking in terms of augmenting an existing process, augmenting an existing way people work rather than replacing it and requiring them to change what they do and retrain. And I'm curious, how do you think about that approach in the context of some of the approaches we've seen on blockchain and tokenization so far at large institutions? And how do you think about what you're doing at Apex in terms of augmenting the existing process as opposed to replacing it? - I think that you have to approach seismic changes by building bridges to them. It's very hard in institutional finance to turn the switch of a process completely off so that you can turn the switch of the new process on. Rather, it's a much smoother transition for the humans and the machines to build in a way that is augmenting and is interoperable. That word interoperable is key. If you think about in the late aughts, early teens, when Microsoft was required to open its code base, the European Union required that Microsoft made Microsoft Office interoperable with open XML standards. And you may remember starting to see this little X at the end of your Word, Excel, and PowerPoint files. So instead of DOC for doc, it was docX. That change, that was a massive code base change. And one of the ways it was made possible was interoperability. You could open that file on either machine. You could open either type of file and it would feel fairly similar. It was not under the hood. The guts of the code was not similar. And what no one saw in the front of the house or in the user side of the house, no one saw the deep, deep work that was happening behind the scenes to transition from one code base from a binary code base to an open XML code base. But it was made possible by the bridge of being able to open both types of files until that older type of file could be deprecated. That paradigm of helping industry maintain stability and operability by providing interoperability for periods of transition, that's such a powerful tool to bringing change into live work streams that really can't shut the lights off. And so much of the interoperability sounds like it's keeping what happens on the screen as similar as possible while what happens behind the screen gets all the changes. And how do you think about that? Because most of us, we just kind of, I'll speak for myself, would like what happens on the screen to stay the same. - Exactly, it is, you can only affect so many levers of change at any given time without creating risk. And that risk can be human failure risk. So the human failure risks that can happen can happen both where you see them and where you don't see them. They're in the early days of deploying robotic process automation, which is an incredibly powerful tool. And I consider it to be a precursor to a lot of what will happen with AI agents. You could set up automations that were really complex. And I remember talking to a technologist that was an established implementer of this tech. And I remember him telling me about this entire automation that failed out for three months straight because there was no human in the loop. There was no human in the middle and there was no, they had written the automation to run but they had not written any kind of warning that it wasn't running. So I referenced this thinking about the what the humans are doing. And if you ask the humans to do new things and you don't provide them mechanisms to know if they didn't see a thing, if something didn't run the way it should have, that risk can be even bigger than the human not doing the thing that you want them to do, if that makes sense. - Well, and I do want to dig into like this phrase you use, the human in the middle. What is the human in the middle? - Oh, I love that. The human in the middle is depending on the process is there for multiple reasons. Humans in the middle ensure that the automation that was running in the black box that failed have a mechanism to alert that something isn't working the way it should. And the humans in the middle ensure that when the output from the LLM says that Dave Greeley is a Parisian chef who lives in Berlin. And you and I know that you're not a Parisian chef that lives in Berlin. The human in the middle is there to ensure quality control of output. And the humans in the middle are ensuring that the user experience is truly usable and is not harmful, that it's adaptable, that it's safe to use. Humans in the middle are really helpful when you're testing out net new technologies you're in a lab, you're not sure that the radioactive isotope is 100% contained before you get it into the place that it is intended to get into. So when I refer to humans in the middle, it really is humans in the middle of a lot of different places. And we should ultimately be building technology that is doing good for the humans. And therefore you kind of need humans in the middle. - With your work on digital title and that approach to tokenization at Abex, how is that being shaped by the desire to make it more easily adaptable by large institutions? - It's being shaped by experience on the ground with large institutions. And we're fortunate to have team members that have spent lots of time behind the scenes in these institutions, behind the scenes implementing that new technology and being first on street to do things. And that kind of experience is incredibly helpful because it shortcut a lot of the blockers that you would hit if you didn't know. You would just walk into the room and get asked the first five questions and realize you had no idea that you had to meet these five requirements. I think the first thing that's really helpful is experience. The second thing that's really helpful is trust. And this is a very human thing. There's trust in having built successfully and launched into financial institutions. It is a form of attestation. So when we talk about attestation in data space, there is that attestation in human space of being able to build with people and for people that you can attest will use these tools. They are being built intentionally for use in regulated spaces, for people who will use them in regulated spaces. That layer of trust is really important. - And how do you think looking outside of AVEX, but just like the world writ large, we've got so much more AI coming. There's been a lot of technology coming the past decade. How do you think we're doing on making this technology adoptable? - I think one of the things that's really important about how we're thinking about re-engineering around augmenting existing process. So augmenting existing digitization process with this sort of superpower wrapper of verifiable credential that wraps around that digitized piece of paper that is intentionally built to be ready for future use case. We can all see where there's incredible value in being able to move data more quickly from point A to point B, and to move it in a way that preserves privacy, security and trust from system to system. And we know we want to be able to equip AI agents to interact with this data, to do that, we have to augment our traditional PDF. We have to give it metadata. We have to give it encrypted data that allows it to be handled from system to system, securely and safely. And with trust, with trust that the recipient is who they say they are, and the sender is who they say they are. It should feel easy. It should feel very familiar for the humans that are interacting with these systems. The magic is what's happening under the hood. The magic is the hard work of code that's happening behind the scenes that no one will ever see. - Thanks again to Carrie Jaygworth, Global Head of Digital Product at Apex Technologies. We hope you enjoyed the episode. We'll be back next week with another episode of Re-Engineering Tokenization. We hope you'll join us. - This episode is brought to you in part by Apex Exchange, bringing better price discovery and risk management tools to navigate today's commodities markets through centrally-cleared, physically-deliverable futures contracts in energy, environmental, battery materials and precious metals markets. Smarter markets are here. Contact [email protected] to get started. That includes this week's episode of Smarter Markets by Apex. For episode transcripts and additional episode information, including research, editorial and video content, please visit SmarterMarkets.media. Please help more people discover the podcast by leaving a review on Apple Podcast, Spotify, YouTube or your favorite podcast platform. Smarter Markets is presented for informational and entertainment purposes only. The information presented on Smarter Markets should not be construed as investment advice. Always consult a licensed investment professional before making investment decisions. The views and opinions expressed on Smarter Markets are those of the participants and do not necessarily reflect those of the show's hosts or producer. Smarter Markets, its hosts, guests, employees and producer, Apex Technologies, shall not be held liable for losses resulting from investment decisions based on informational viewpoints presented on Smarter Markets. Thank you for listening and please join us again next week.