Episode 125 of the Public Key podcast is here! From the fundamentals of decentralized identity to the intricacies of Travel Rule compliance and the evolving regulatory landscape, Alice Nawfal (Co-Founder & COO, Notabene) covers it all in this episode. She discusses the challenges and solutions for seamless cross-border transactions and how regulatory clarity, like the EU’s MiCA is poised to revolutionize institutional trust and compliance in the crypto world.
You can listen or subscribe now on Spotify, Apple, or Audible. Keep reading for a full preview of episode 125.
Public Key Episode 125: Trust and Verification in Digital Assets: The New Era of the Travel Rule and Secure Transactions
The Travel Rule has recently seen regulatory implementations in various jurisdictions, but are VASPs complying?
In this episode, Ian Andrews (CMO, Chainalysis) gets that answer and many more from Alice Nawfal, who co-founded and is acting COO of one of the leading Travel Rule solutions, Notabene.
Alice shares her origins working in the decentralized identity space and how she ventured into the intricacies of Travel Rule compliance and the evolving regulatory landscape.
Alice talks about the challenges in creating solutions for seamless cross-border transactions, while highlighting how regulatory clarity, like the EU’s MiCA, is poised to revolutionize institutional trust and compliance in the crypto world.
The conversation focuses on the focus on self-hosted wallets and counterparty risk assessments in the crypto space, while offering insights into how the interoperability challenges for travel rule solutions can be solved.
Quote of the episode
“I would say the first thing to look at is the evolution of the adoption of the travel rule over the last two years looks very similar to the uptake of licensing and registration regimes globally.” – Alice Nawfal (Co-Founder & COO, Notabene)
Minute-by-minute episode breakdown
2 | Alice’s journey from getting a MBA, going through YC and ending up in decentralized identity
4 | How to solve the identification problem using a trustless decentralized approach
8 | How does Notabene approach decentralized ID and what is the Travel Rule
12 | Has Travel Rule adoption improved over the last 2 years?
16 | The major impact on the Travel Rule on crypto transactions
22 | Facilitating real-time counterparty risk checks for secure transactions
28 | Proof of ownership for self-hosted wallets to solve for EU Transfer Rule requirements
33 | Solving interoperability challenges in the Travel Rule industry
Related resources
Check out more resources provided by Chainalysis that perfectly complement this episode of Public Key.
Speakers on today’s episode
Mentioned Episodes:
This website may contain links to third-party sites that are not under the control of Chainalysis, Inc. or its affiliates (collectively “Chainalysis”). Access to such information does not imply association with, endorsement of, approval of, or recommendation by Chainalysis of the site or its operators, and Chainalysis is not responsible for the products, services, or other content hosted therein.
Our podcasts are for informational purposes only, and are not intended to provide legal, tax, financial, or investment advice. Listeners should consult their own advisors before making these types of decisions. Chainalysis has no responsibility or liability for any decision made or any other acts or omissions in connection with your use of this material.
Chainalysis does not guarantee or warrant the accuracy, completeness, timeliness, suitability or validity of the information in any particular podcast and will not be responsible for any claim attributable to errors, omissions, or other inaccuracies of any part of such material.
Unless stated otherwise, reference to any specific product or entity does not constitute an endorsement or recommendation by Chainalysis. The views expressed by guests are their own and their appearance on the program does not imply an endorsement of them or any entity they represent. Views and opinions expressed by Chainalysis employees are those of the employees and do not necessarily reflect the views of the company.
Transcript
Ian:
Hey everyone, back with another episode of Public Key. This is your host, Ian Andrews. Excited for my guest today. This has been two years in the making. One of our first guests on the Public Key Podcast was CEO of… and co-founder of the company that my guest today, Alice Nawfal, who’s COO at Notabene. It’s exciting to have you here and get an update two years in the making. How are things going?
Alice:
Yeah, thanks so much, Ian, for having me join here. Things for going really well. Excited to be here and chat about, I guess, all the things we’ve missed talking about in the past two years.
Ian:
Yeah, it’s going to be fun.
Alice:
Yes.
Ian:
Let’s start with a little of your background, Alice. So I noticed you’re a Y Combinator graduate. You started your career in consulting. It seems like you’ve been in digital assets for a long time. Take us through what drew you into the world of digital assets, blockchain, and cryptocurrency.
Alice:
Yeah, good question. Yeah, earlier in my career, I was in consulting and, around that time, decided to take a bit of a break, go back to school, and did an MBA like many people did, combined it with a policy degree, and at the time I was looking at very much what are some of the fundamental changes that we will be seeing from a technology perspective over the next 10, 15 years. And I was very interested in that kind of connection between how we’re evolving as a world from technology perspective and how does that kind of interact with policy both at a local level and global level.
And during that time, it was around 2015 or so, 2016, there was obviously a lot of great things happening from a FinTech perspective, whether these were the payment processing and point of sale solutions, the kind different trading platforms coming out, et cetera. And while a lot of it was very exciting, I was fundamentally interested in how can we basically help with a lot of the infrastructure, key infrastructure that will enable even greater access to financial services globally. And hence entered kind of the rabbit hole of, I guess, blockchain, crypto, and decentralized identity around that time.
Went and kind of talked to a lot of people to see what was going on in this space. And I definitely saw the promise for kind of infrastructure which can enable… infrastructure such as identity at the core, which can enable greater kind of access to different services, including financial access and so forth. So anyway, long story short, at the time decided to look at different digital identity and, more specifically, decentralized identity teams around the space. And that’s where I met the teams at Consensys and uPort, more specifically, was a product team at Consensys and ended up joining the space around 2017.
Ian:
Yeah. Tell me about what uPort was doing because decentralized identity seems to have a bit of a resurgence or a hot streak at the moment, right. I mean, a lot of people are trying to figure out what the folks at Worldcoin are doing as an example.
Alice:
Yes.
Ian:
But Circle’s got a project in the area. There’s quite a few smaller startups that are focused on this. It feels like you were way ahead of the curve, maybe back in 2016, 2017. What was uPort’s take on the space?
Alice:
Yeah, it’s interesting because today I see there has been almost like, in many ways, many steps forward, but also, it still feels like we’re going around in circles in that space. Ultimately, the problems that we’re trying to solve are really big and will have such a big impact, but it’s just… and these problems have only exacerbated since. And so that’s why you continue to see resurgence. However, it’s just really hard to solve identity problems with an identity solution because, fundamentally, it’s linked to every single use case.
And so, doing… since 2016, we’ve seen a lot of teams working on everything from trying to solve identity problems for healthcare or for things like Worldcoin or for any kind of… for driver licenses and so forth. But ultimately, it’s a bit of a hard chicken and egg problem. But I can just talk very briefly. At the time, we were building some core infrastructure to really help solve one of the problems that we identified within the blockchain space, which is by design ledgers, are public, and they should not have identifying information there. However, for most transactions, you should be able to identify your counterparty, and you should be able to, as needed, depending on the use case, be able to link-real world identities of people and businesses to their blockchain addresses.
And so that in and of itself as a problem still exists today. There are different ways of tackling this. And every day, I hear different companies in the space across different parts of the space trying to tackle it. But we were building fundamental kind of, I would say, infrastructure for that initially within the Ethereum ecosystem and then more broadly. And some of that infrastructure that we built is today part of the worldwide web standards and forms, I would say, almost like the basics of what everyone else is working on today.
Ian:
Oh, fascinating.
Alice:
Which is… Yeah, it’s great to see that, and I’m very bullish in the long term, but nonetheless, I still think it’s going to take time.
Ian:
Yeah. Can I be maybe a little bit controversial on this topic? At the core of, it seems like any sort of identification system relies on a level of trust, and decentralization, I think, has been made synonymous in this industry with absence of trust, or at least we don’t need to have trust in order for the system to function. And so, to me, those seem in collision in some way. The easiest way to build a digital identity system is to have a trusted real-world identity provider who credential… validates and credentials you.
And then, you get in digital form… that credential in digital form, and you can use it with applications. It’s basically what we do with digital certificates for websites today and kind of how Verisign works, as an example. That’s not perfect, but it’s a system that seems like plausible we could deploy at scale and copy and improve on. And this idea of trustless identity is a big head-scratcher to me because I don’t know how we get this original validation without some proof. Am I totally missing the obvious capability here?
Alice:
Yes, it is a good question. I think, Ian, it fundamentally is. I wouldn’t say that you’re missing it. I would say it’s a very valid point.
Ian:
Yeah.
Alice:
But what I would say is, as an industry, we’ve actually thrown around the word decentralized and trustless and make basically… How should I say it? But essentially, we’ve done all of us a disservice here because at the core of the way decentralized identity systems work, and maybe I should use a different word… world, which is self-sovereign identity. But essentially, what we’re doing here is, and part of what we had built back then, but also I must say Notabene’s infrastructure is also built on decentralized identity infrastructure.
And what this means is in that world, there are credential issuers who basically would issue a verifiable credential, which is essentially just digitally signed proof, and then would hand it over to you as an individual or institution. But you have that record that it has been similar to kind of the very signed kind of example that you gave where you would essentially have that signed proof. Let’s say that you own a specific bank account or that you are a Coinbase account holder or maybe that you have, I don’t know, certain types of medical data and so forth. And then you can be able to share it with a third party.
But in essence, the data that you have here, now if, let’s say, a medical provider shared it with you, and you’re taking it to another medical provider, they know to trust it because it’s been digitally signed by the first medical provider. And so it is, I would say, kind of similar to what you’ve said, but done in a more self-sovereign fashion. But it’s not about trustless. It is all about creating trust between those within the specific use case. I’ll give another example. Basically I can use decentralized identity kind of mechanisms to issue a credential that I like ice cream. That’s cool.
Everyone likes ice cream. However, now, if I have another credential that says I’m a Coinbase account holder, and maybe let’s say there is some sort of a DeFi platform which only allows KYC individuals to interact with it, then I can take that credential and prove that I can work on it. And so it’s really just about, I would say, the system on the backend. And it’s not about being trustless, it kind of depends on the use case itself.
Ian:
Yeah. But so it’s not about being trustless. It does sound though there needs to be a reliance on a central verifier or credential issuing authority in that example you just gave if I’m following it correctly.
Alice:
Exactly. And rather than have these… potentially having the issuing a authorities manage all that data and create a centralized honeypot, the idea here is then that they can provide that back to the individual or the entity, and then you can take it elsewhere. And so, and thinking back to the example of, let’s say, a medical provider, you go to one doctor, they issue you a certain amount of kind of data, and then you want to go to another hospital system, and you’re able to take that with you.
Ian:
Okay. Fascinating. Okay. So now, after doing that at uPort for a while, that was a nice tangent divergence there into a topic I’m fascinated with, you decided to start Notabene. Tell me about what led you to wanting to work on this problem.
Alice:
Yeah. It’s actually really related. And if we go back even to that question that you asked me around trustless systems, fundamentally, and here kind of thinking back to the crypto space, public ledgers are, again, I’ll say it, I mentioned it earlier in the call, are by design, don’t have identifying information about the counterparties of a transaction. And that makes sense because this is how we can preserve the privacy of the interacting parties. However, for many use cases, you need to be able to identify the counterparty.
So there needs to be a mechanism by which the two parties of a transaction are able to identify, verify each other, and then be able to trust that they’re sending funds to the right counterparty. And so stemming from that, and from our work on decentralized identity, we knew that this is something which has to be built for the space. There needs to be a way in which the counterparties of a transaction are able to identify each other securely in a privacy-preserving way, if they want to do that, to be able to allow those transactions to happen.
And so, from our perspective, we knew that this has to happen at some point, and it has to happen for proliferation of use cases, but everything from e-commerce, cross-border payments, all types of use cases like that. And then the FATF, or the Financial Action Task Force, around that same time that we were already thinking about this came out with their virtual asset guidelines for the space. And as part of that, they made the requirement of Travel Rule a necessary thing for the industry. And so what exactly is Travel Rule?
And before I jump into that, I would say from our perspective, we saw basically when the Financial Action Task Force came out was I think it was mid-2019, late 2019 came up with a regulatory framework for the crypto industry. We thought that was a really good endorsement from the regulators that, essentially, they’re coming in to provide that regulatory clarity to allow companies in this space to be able to start transacting compliantly with one another, get regulated, get the licenses that they need, and be able to interact with the broader financial ecosystem.
And so, from our perspective, then around that time, we’re like, “Okay, this sounds like a great moment for this space because this will unlock a lot of new companies. It will allow a lot of growth. But at the same time, there are specific rules to how they need to interact with each other.” And one of those rules was the Travel Rule. And so we saw in that a parallel to some of the work that we had done earlier. And the requirement in and of itself is that financial institutions and crypto asset service providers need to perform risk assessment of the counterpart of a transaction prior or with the transaction settlement.
And so this specifically means that for every transaction that’s going from one institution to another, the institution will have to identify and verify, who the counterparty is of the transaction. And as part of that, also be able to communicate with the counterpart institution if that exists, unless it’s a transaction to a self-hosted wallet. And what does this mean kind of more specifically? So, in let’s say, if I would like to send you right now a crypto transaction. My institution or the institution that the exchange I’m working with will need to, first of all, identify who you are.
They’re going to perform, basically based on their own risk-based approach, specific checks to ensure that you’re not a high-risk individual. They’re going to check whether your account is at another centralized institution. If it’s not, there’s potentially some requirements, depending kind of on the jurisdiction. But if your account is at a centralized institution, then the requirement is also that they collaborate and communicate with each other to ensure that neither you nor I are high-risk individuals.
And you may ask, “What is the point of all this?” Well, clearly, here, the point is to identify any suspicious activity. They want to make sure that you’re not potentially sanctioned individual, a high-risk individual. They also want to make sure that the institution that you have your funds at is a trustworthy institution. So again, this is taking almost that opposite of trustless, right, where-
Ian:
Yeah, it’s…
Alice:
… my institution and your institution have to… Oh, sorry, go ahead.
Ian:
Well, I was going to say it’s interesting to think about where you started, which was wanting to facilitate counterparty trusts in the transaction so that you and I could know that we’re sending to the right people, which at it’s-
Alice:
Yes.
Ian:
… most basic level in crypto is kind of that terrifying moment where you put in an address and you’re going to send off some digital assets and you hope there wasn’t a-
Alice:
Yes.
Ian:
… misfire on a copy-paste operation and your assets are gone forever or you sent to the wrong address somehow and your assets have been burned. That seems like something that everyone in the industry would use. The second case where the solution evolved to seems much more like a back office process that large financial institutions have to by regulation are sort of being pushed to embrace. Any thoughts on that reflection?
Alice:
It’s an excellent reflection, and it’s crazy because I would say that from an institutional perspective, that second part, it is true. It is part of the back office checks that they have to perform to ensure that they’re in compliance with the regulatory requirements.
But it is also fundamentally, as they’re performing, this is the first time where they are able to identify and verify counterparties in a deterministic fashion. This is the time where they are able to, because of that communication that they do with their counterpart institution, is actually determined that X amount of transactions are going to these jurisdictions or to these exchanges or to these on-ramps off-ramps.
Ian:
Yeah.
Alice:
And it kind of goes hand in hand. And it is kind of interesting because, I would say, we’ve kind of gone from us seeing where this could end up in a few years because all around transaction authorization, but there was the regulatory requirement of Travel Rule, and that’s what we’re helping companies with. But we already see a lot of our customers come to us for the transaction authorization piece. It’s the same data, it’s the same flows. But, ultimately, are you doing this just as a compliance function, which is a very important piece for companies?
But with that, as you’re also starting to understand and get that data around who your counterparties are, the types of transactions you’re doing, and then this also becomes part of that enablement of those use cases. Now, it is still a bit of a tricky kind of thing, but ultimately, you are writing your reflection, and it’s kind of like the, “Two sides of the same…” I’m not sure what the expression is, but, “Two side of the same coin.”
Ian:
I knew two years ago when we had your co-founder Pelle on the podcast, the capability was still, I would say, in the nascent early stages, right. Most organizations in the crypto industry, were still trying to figure out, “What do we actually need to do with the Travel Rule?” Catch us up on the last two years. I know that a number of jurisdictions have put into effect the requirement that transactions abide by the regulation. What else is going on in the industry over the intervening time since we last covered this topic?
Alice:
Yeah. I mean, like in all things in crypto, the last two and a half years have definitely evolved quite dramatically and look very different.
Ian:
Understatement of the year, Alice. Understatement of the year.
Alice:
Exactly. But where shall I start? I would say the first thing to look at is the evolution of the adoption of the travel over the last two years looks very similar to the uptake of licensing and registration regimes globally because, ultimately, it’s tied to that. And so I would say two years ago, crypto companies generally operated in a largely unlicensed, unregulated world with the exception of a few jurisdictions. Their transactions were also largely non-compliant.
And that’s basically because the rules were at an early stage where the regulators were still trying to understand exactly how they should introduce those requirements and what they should look like. The technology was evolving quickly, and they had to really determine what this exactly should look like and how it should apply in different scenarios and so forth. And so I would say it wasn’t only that Travel Rule adoption was in its nascent days, but I would also say the requirements were in the nascent days.
And so this has radically shifted where today we have, I think the most recent stat from the FATF earlier this month in July 2024, is that 65 countries have already passed legislation that includes Travel Rule, and then there’s another 15 or so who are in the process. So, from a regulatory standpoint, the FATF has been pushing globally old regulators over the last two years to push that forward. And I would say this is dramatically larger today than it was a year ago, and so forth. And again, this is very similar to the amount of jurisdictions who have put licensing regimes for crypto.
So, with that regulatory clarity, this is kind of shifting fast. I believe the latest to jurisdictions are, Seychelles and New Zealand, who are in the process of instituting the Travel Rule. But what we saw over the last year were some key jurisdictions such as the UK, the UAE, Hong Kong, and now we’re at a place where with the EUs, MiCA & TFR, which is their version of the Travel Rule coming into effect later this year, we’re nearing that point where there is a global regulatory tipping point. And we look at this from the perspective of where are we today and where will we be in a year to two years’ time.
Because, fundamentally, we talked about institutions having to collaborate to perform the Travel Rule. So it takes two to tango in this case. And one of the key things that we had probably, and when Pelle was also here on the podcast two years ago, is it takes two to tango, but it probably, in most cases, felt like there was one dancer and the other one was absent. And that’s because of an issue that regulators call the Sunrise Challenge, where jurisdictions roll out the rules on different dates, companies get licensed not all on the same day.
Ian:
Sure.
Alice:
And so, ultimately, it’s really hard for institutions to have performed the travel properly two years ago. And so where we are today, with… when I talk about a global tipping point, is that we’re reaching the place where most companies do expect to be able to send a Travel Rule message to their counterparties and receive a Travel Rule message from their counterparties.
And so I think in the next six months, we’re seeing with the EU rules a very kind of rapid adoption, and not just within the EU. But, globally, most larger crypto companies, whether in the US or APAC, are getting EU licenses or are also getting ready, if they were not fully compliant before or complying before, to also comply because the rules in the EU require that your counterparties comply, and if they don’t, you can report them to the regulator.
And so we believe that this is kind of that moment where things will look radically different in three months, in six months, and in 12 months. But also, where we are today in terms of kind of volumes and activation is very different from where we were last year.
Ian:
Yeah.
Alice:
I’ll give a couple of examples. We see today more than our customers, and this is just looking at our customer base, but we see transactions going from over 30 jurisdictions originating going to over 85. And I would say in terms of volumes transacted through Notabene, we’ve 100 x volumes to today versus where we were January of last year. And this just talks to that rapid kind of growth over the last year to year and a half from an industry perspective. But we expect this to be literally still kind of that early days of where we’re going to end up over the next 18 months.
Ian:
I’m curious the impact of that. So, I mean, the growth in volume is fantastic, right? 100 x and more than almost tripling the number of jurisdictions who are participating. What does that mean practically? Is it users are getting tricked into sending funds less than they were in the past, like less exposure to scams? Are VASPs detecting more money laundering and kind of stopping funds in transit? What’s… Have you been able to pull any of those results out through your analysis?
Alice:
Yeah, great questions. So we have a policy engine for our customers whereby they basically institute their own kind of compliance processes to be able to identify high-risk activity and prevent those transactions from happening. And what we have seen is close to $1 billion in preventive volumes to date.
Ian:
Wow.
Alice:
And we don’t know what are the specific reasons, but we expect a lot of it is probably due to either identifying high-risk counterparties, whether this is specific blockchain addresses, or whether this is based on named sanctions. It’s also potentially going to whether it’s high-risk or non-compliant counterpart institutions or jurisdictions and so forth.
And I still think this is the early days because, in most cases, companies are still trying to figure out what does this exactly look like. What does it mean? And that’s why I think the next two years will be interesting because that’s where companies will finally have access to the data on their end around who their counterparties are and be able to make smart decisions on whether they should interact with them.
Ian:
Mm-hmm.
Alice:
It’ll also enable them to expand access to potentially counterparties, where previously they didn’t have the mechanism to be able to assess whether they’re high risk or not or whether they can be trusted or not. And so I think that the way we see this is we’re equipping companies with tools to be able to get smarter in real-time to allow more transactions to more counterparties. So that’s one part. Another part, and you touched-
Ian:
Sorry, before you go on-
Alice:
Oh, sorry. Go ahead.
Ian:
… can I just pull on-
Alice:
Yes.
Ian:
… that thread a little bit? So, ultimately, the goal is allow more transactions through because you’ll have more confidence where in the past you just didn’t know. And is that actually true, though? My sense in the crypto industry is the attitude was if I don’t know for certain that it’s bad, I’m not getting in the middle of it.
I’m not going to stop anything, and I’m going to seek as a little knowledge as possible. Maybe that’s a little too cynical way to represent the industry. But I would say that was kind of the historical behavior that I observed when I first got into the space three and a half years ago.
Alice:
Yes, I would say that there’s probably a couple of different camps. Definitely, I would say three and a half years ago, that was probably the case for the majority of companies in the space. But I would also say that they didn’t have tools to do any better-
Ian:
Okay.
Alice:
… and the requirement was not there as well. But in essence, for most companies… or sorry, for many companies, since who have started operating in space, whether these are new companies within an… who are crypto native or whether these are FinTechs or banks who are starting to transact with crypto, essentially they come in, especially the ones right now who are going through all the licensing requirements, they’re starting in with very much kind of that, “Who are the counterparties I can trust and how do I even perform diligence on them? Shall I onboard more than 2, 3, 5, maybe 10 counterparties?
Because how do I assess who, besides a couple of companies where I have a lot of information about them, how do I assess that they are low risk and that they will pass my risk department’s kind of assessment and so forth?” And so we are working right now with a couple of our [inaudible 00:29:43] customers on helping them expand who they can transact with because of now that they have the tools to perform that diligence on their counterparties and have been able to show that those counterparties are travel compliant and perform kind of the right checks when transacting with them in a compliant way.
Ian:
Got it. That’s good to hear that attitudes are shifting in that way. And I’m curious also, so my understanding of your solution is that there’s a data exchange that happens between the two participants in a transaction that’s sort of sent out a band. So if I’m sending you some funds from my exchange account to your exchange account, I request that withdrawal or that transaction be initiated.
And then, out of band via Notabene, the exchange will pass my details and confirm your details, the destination information, so that basically exchanges roughly simultaneous to the transaction. Am I missing that you all are now providing some measure of risk on those counterparties?
Are you saying to the initiating VASP, “Hey, I know Ian wants to send Alice some money, but Alice is doing business at a very shady exchange and you probably should not allow Ian to send this money.” Is that a capability that you’re offering or is that information supplied through other partners or third-party means? How do you get to that assessment?
Alice:
Yeah, good question. So essentially, this maybe goes back to we talked roughly around the travel requirements and then transaction authorization.
Ian:
Mm-hmm.
Alice:
What we do at Notabene is we help companies perform in real-time those counterparty risk checks both on the end counterparty and on the counterpart institution and then decide whether the transaction should go through. And part of that is also the out-of-bound communication and message layer. However, you think about the requirement, it’s about identifying and verifying the counterparty, performing those risk checks, performing VASP due diligence, and communicating that message.
And what part of it as well is there are in… if the counterpart institution is… Sorry, if the transaction is not going to a counterpart institution a self-host… is owned by the end-user using a self-hosted wallet, the requirements are still there without the messaging part, meaning that the onus is on the originating institution, in this case, to perform those checks of the counterpart. And so what we help companies with is with performing all those checks, and as part of this, the data that they have at hand includes some third-party data.
It also includes the data that they’re gathering at the point of transaction around the counterpart, and it also includes data which the counterpart institution can share with them. So we do allow for VASP due diligence within the product. And so each VASP creates a profile, and then there is some third-party data. There’s some self-reported data, but ultimately, they can also build trust through their transactions with the counterparties.
Ian:
I see. So it’s not Notabene providing risk assessment of any particular entity, it’s just the tools to facilitate the process of data collection. And I guess I’m curious in the moment of transaction in my example where I’m like, “Hey, send Alice some money,” are your customers frequently interceding in that withdrawal request moment and saying, “Oh no, no, Alice’s wallet is hosted by an institution that we don’t want to do business with?” Or is it-
Alice:
Yes.
Ian:
… more of a broad process where they kind of periodically evaluate all counterparties, and they’re like, “You know what? This exchange that we seem to have a lot of customers sending funds to, they’re not sanctioned. But they are… there’s some indication of illicit activity happening broadly, and we want to stop users sending funds there, so we’re just going to block any transaction requests that terminates that provider.”
Alice:
Yeah, it’s actually both.
Ian:
Okay.
Alice:
And so, in essence, it is correct. We don’t perform any kind of risk assessment ourselves, but what we do is provide the tools for our customers to do that. And it makes sense. I would say the regulatory obligation is on them to perform those assessments, but also, no two institutions are similar, and each one is going to approach this in a separate way. And maybe this also goes back to some of our earlier conversations here around what does trust mean and empowering institutions to be able to perform those to basically come up with their own risk-based approach and based on their own risk appetite, decide who they want to transact with, what rules they want to have in place.
And it could be that for different products, they may have different appetites, it could be as well because of different rules and requirements in every jurisdiction they may apply different. And so we leave it to the VASP themselves. And often, what we do see is the teams would upfront put together a robust kind of process in place where they may say, “We’re not comfortable with transacting with these jurisdictions, and we’re only comfortable allowing these types of transactions with these types of institutions.” However, it’s also a very fast-moving space, as I’m sure you’re aware. And we often see that companies regulatory status may change as many companies are waiting for their licenses. Or in some cases, some companies may lose their trusted status.
And while it makes sense to kind of do that more kind of robust upfront and then put that into our policy and rules engine, and we see companies do that and then periodically they also go back and review, especially once they have their data, probably on a quarterly basis or half annual basis, biannual, to be able to see what are some of the misses that we’ve done… we’ve had and what are some of the edge cases, and then go back and re-review those. But ultimately, at the point of transaction too we do see there it’s probably less on a VASP to VASP kind of part where… but it’s probably more around the end user is where most transactions which get rejected would happen, where there could be some missing information, beneficiary names may not match, and so forth.
Ian:
It’s back to our question of decentralized identity, and can I withdraw my funds out to a self-hosted unknown wallet, or do I need to actually verify that the wallet’s somehow in my control? I’ve seen all sorts of proposals bouncing around about means… technical means by which I could validate I have control of the wallet, like a signed message that I could demonstrate to sort of ensure that the withdrawal is satisfied. But I’m not aware that anyone’s actually implemented anything like that. So it seems to all be living in the technology specification land, not actually in practice.
Alice:
Well, it’s funny that you say this. We have actually provided proof of ownership for self-hosted wallets for the last two years-
Ian:
Okay.
Alice:
… and we’ve only recently expanded the types of wallets that we support, and we’ll continue to do that. And ultimately-
Ian:
Tell me more about this. I’ve totally missed this capability.
Alice:
Yes.
Ian:
So how does it work if we wanted to implement it for a customer today? Where do you start?
Alice:
Yeah, so today, we support basically ERC-20 type wallets as well as hardware wallet.
Ian:
So it works with my MetaMask or my Trezor or my…
Alice:
Yes.
Ian:
Okay.
Alice:
Yes.
Ian:
Got it.
Alice:
Exactly. Ledger wallets, et cetera, and we’re in the process of adding more methodologies right now, and I would say there’s a couple of drivers for us right now to expand this. And the main one is that the EU travel requirements will require when customers transact… sorry, withdraw funds, or receive funds from a self-hosted wallet, that they do prove ownership of that wallet if the funds are above €1,000. And so that is a regulatory requirement, and it’s important that we do solve it as an industry because otherwise, it puts transactions with self-hosted wallets at risk.
I think the specific requirement is that VASP will have to implement a risk-based approach to this. So, in addition to identifying the owner of a self-hosted wallet, they will have to verify it for above that threshold using only one method. Originally, it was two methods, and then we basically push back as Notabene and as an industry, and we’re able to get it to one method. But in this case, it’s also up to the VASP after that, whether they want to request potentially additional information or conduct kind of enhanced ongoing monitoring and so forth.
In practice, we’re going to see how that exactly looks like. But I can tell you that this is not a new requirement in some places like Singapore and a few other jurisdictions where it’s been there for at least a year or more. And many of our customers do use that functionality already. It’s not exhaustive yet just because there’s a lot of different types of self-hosted wallets, and there’s a bunch of different methodologies that can be used. You’re right in saying that some things stay in the technical specification land, and others are just really suboptimal.
Ian:
Yeah. But my impression was-
Alice:
But…
Ian:
… that to meet this requirement, most people were just going with some sort of self-attestation, right. I basically signed a form saying, “Yes, I own the-
Alice:
Ah, yes.
Ian:
“… wallet.” And so it’s legalistic, maybe enforceable. I’m not a lawyer, so I won’t comment on that. But it’s not technical in terms of demonstrating actual possession of the Private Key. And so I think a lot of crypto people were taking that as an affront because it was like, no, it’s so cryptographically provable that you actually do control that wallet. Why aren’t we using a technical solution to this problem versus requiring documentation and this sort of theater of signing-
Alice:
Definitely.
Ian:
… a legal agreement?
Alice:
Yes. From a…
Ian:
I’m curious.
Alice:
Yeah.
Ian:
So I’ve got a MetaMask wallet, and what happens next? How do I use your solution? Am I paying not be money? Do I have to have my exchange support your product? And then they give me some sort of tool. What happens next?
Alice:
Yeah. It’s actually a very neat solution. So our customers usually integrate into their front end a UI element. It kind of looks like a Stripe Checkout popup.
Ian:
Yep.
Alice:
So essentially, at the point of transaction, when you’re putting in a wallet address, we will perform the checks on whether this is an address which the VASP has already identified before and worked with or whether it’s part of our network and so forth.
If it is a new address, at that point in that popup, we will ask the end user to identify whether they’re sending that address to another institution or to a self-hosted wallet. And think of this as when you’re doing a wire transfer where you’re going to have to then provide some information to identify the counterpart of the transaction, such as providing an iPad number, account number, and so forth.
Ian:
Sure.
Alice:
So, at that point, basically, if you say it’s going to an institution, then we would initiate a travel transaction with that institution and check that they indeed own that wallet address before performing the Travel Rule and sharing any PII with them. But if it is a self-hosted wallet, and in this case, for example, a MetaMask, what would happen is it’s a two-second flow.
As an end user, you would receive a little popup through your MetaMask where then you would sign with a cryptographic signature. From a UI perspective, it literally is just one button, but at that point, basically, there would be a cryptographic signature stored with the exchange that, at this particular point in time, you, as their customer, signed that you own that wallet.
Ian:
Very cool.
Alice:
And then this happens in real-time at the point of transaction, and then it’s up to the institution or VASP in this case, whether they want to have this be a reusable thing or whether you have to do that at every withdrawal to a self-hosted wallet.
Ian:
Yeah, that’s fantastic. And you’ve got customers who are live running this today?
Alice:
Yes. And some have probably been using it for over two years.
Ian:
That’s exciting. If you’re willing to point us to a particular exchange [inaudible 00:44:08] I’d love to go try it out, but we can do that offline if you don’t want to name any particular customers.
Alice:
Yes, for sure. Let’s do it offline probably.
Ian:
All right, perfect. I’m going to go test it out. I would be… I think I would be remiss to let you go without asking this question. I recently had a group of our customers together, and I think their biggest… one of the biggest challenges they identified with Travel Rule was the fact that there’s not one provider and one standard as fantastic. As you all are, there are competitors out there. And so, it becomes not only this challenge of getting multiple businesses and jurisdictions all around the world to collaborate but then also a data interoperability problem-
Alice:
Yes.
Ian:
… with kind of competing system architectures. It’s like, what’s your thinking on this? Because I heard a bunch of frustration from our customers who are like, “There’s got to be a solution here. We either need consolidation in the industry, or we need some sort of meta layer across all this stuff.” How does this eventually play out? Because it seems like it might be the biggest point of friction, particularly as the regulations come into effect, where this has to get very real in the near future.
Alice:
Yeah, it’s a great question, Ian, and I would say it’s not only a frustration from the industry and your customers, but I would also say from the regulators’ perspective and from ours as well. And I think we’ve… In many case, I would say, we talk a lot in the industry about interoperability across different messaging layers.
But you hit the nail on the head when you said that, ultimately, that creates a system architecture problem because while it sounds ideal in practice, it’s a large waste of energy because you have different messaging protocols, they have different flows, they’ve evolved in different ways, and so that makes it really hard.
Another part of it also is many of the different protocols have low usage, so we’d be wasting a lot of energy creating gateways from one to the other. And I do think, as an industry, we’ve already wasted time doing that, and we could have spent that time really helping the industry move along on some more critical questions, such as having fantastic technical solutions to self-hosted… for self-hosted wallet transactions, for example.
Ian:
Yep.
Alice:
And so, from our perspective, we have been pushing a lot the… pushing a lot on the industry front, but also in speaking with the regulators that instead of focusing on interoperability between protocols is let’s focus on VASP to VASP breachability. We need to make sure that we don’t create isolated islands, and we need to make sure that there aren’t unfair advantages or disadvantages created due to competitive purposes where there could be an isolated island that basically allows or does not allow certain exchanges in.
And so I think as an industry, it would be great if we could, instead of wasting energy on creating interoperability between different messaging protocols, just take a step back and choose one that makes sense and create really a global network in terms of reachability. Because ultimately, we all benefit from all institutions being able to have access to transact with each other. And then, going back to some of our earlier points here, it’s up to the institution itself and their own compliance processes whether they want to trust another institution and whether they want to allow another transactions with another institution.
And that goes back to equipping them with the tools to make those decisions and for it to happen on an institution, institution basis rather than at a network basis. And I don’t think that we are alone in thinking this. I would imagine most of us across the industry feel this. I hear it from our customers every day, but ultimately, I would say this is kind of the method to go forward. Now, from our perspective, we’ll continue to rally the industry around us. And we do think that we’re reaching that tipping point where everyone’s afraid of having isolated islands or networks, and it makes sense for us all to work together on bridging that gap.
The other part as well is we’re taking a bit of a novel approach as Notabene by thinking about what are the networks where crypto transactions are already occurring? And so these happen in networks like the, let’s say, think about the custody providers or MPC wallet providers. And so what we are thinking from our side as well is, why don’t we make it easy to bring a layer of compliance to the networks where crypto transactions are already occurring? So, for instance, think about fire blocks. They’re both a partner of Notabene as well as a partner of Chainalysis. And clearly they have a very large network of companies who transact with one another.
It makes sense for them to be able to enable because, given that compliance layer has to happen right before the transaction settles, that we could just meet it… meet them where they’re at. And so for this, we just launched recently, I think it was last month, a solution called SafeTransact for Networks. And we’re seeing already a lot of interest on that front from some really big players. We’ll be hopefully announcing them shortly. But with that, it’s all about how do we think about where companies are already transacting today and just making sure to break barriers and not create more walls and more islands in the space.
Ian:
That’s fantastic because I think the usability in the crypto ecosystem is already challenged. So creating islands of… that have walls around them, and we’re unable to send transactions through, does not do anyone anything beneficial. I want to close the podcast and give you the opportunity. Looking forward, what are you excited about? What should we expect from the company, and what have you got your eyes on across the industry over the next 12 or 18 months that we should be watching for?
Alice:
Yeah, I’m excited for a couple of things. The first one is I’m really excited with MiCA coming in by the end of the year that we are providing regulatory clarity when it comes to stablecoins as well as the regulatory clarity that a lot of financial institutions need to start launching crypto products, whether this is within the stablecoin [inaudible 00:51:10], whether this is within tokenization, but we see this through a lot of our pipeline and new customers.
And I’m really excited about how quickly we’re moving alongside that and putting this hand in hand with as well the Travel Rule and the trust element where what we are bringing in here is, and tying it back to earlier in the podcast when I shared around transaction authorization, we believe that for many of the institutions coming in new into this space, that added layer of trust is really going to help them launch some of the use cases that we’ve been talking about here for years. So everything from the remittance corridor use cases to cross-border payments more broadly.
And I’m seeing this kind of rapidly evolve almost, I think, in every strategic conversation I’ve been part of in the last three months. And from Notabene’s perspective, we’ll continue to build the tools that will equip those institutions with being able to perform due diligence quickly in real-time, be able to instill trust internally in which are the right counterparties they should transact with, and also be able to measure success daily. And so with that, I think it’s going to be kind of hand in hand as we see kind of the industry evolving over the last… over the next 18 months.
Ian:
Really exciting. I’m looking forward to it. Alice, this was a fantastic conversation. Thanks so much for joining us on Public Key.
Alice:
Thanks, Ian.