EN | Building Trust in Stablecoin Payments: Pre-Authorization as the Missing Layer | MERGE Madrid 25

Welcome. I hope you enjoyed the panel discussion just now, thank you for bearing with me for another 20 minutes. Um, for those of you who arrived just now, uh, my name is Katarina. I work at Noten as a director for regulatory and compliance. Uh, and today we're wrapping up a really fantastic week here in Madrid.

And I think it's very obvious that the excitement around stable coin payments is palpable. So, I wanted to take this 20 minutes with you to talk about how we build trust in stable coin payments to unlock the opportunity that we're all seeing in front of our eyes. So, if we look at how payments work today, we see a lot of complexity there that stable coins can help us eliminate, which is great. But we also see some core components of the process that are critical for business operations and compliance. What do I mean by that?

So, first payments move more than just value. They move information. And that information is critical for businesses to be able to tie transactions to invoices or contractual obligations and for institutions institutions to meet their AML obligations. Um, sorry. Second of all, as you see there, there's a very important step that precedes settlement, which is authorization.

Um and the authorization step essentially gives institutions um an opportunity to have a say on whether or not they want to proceed with a transaction before funds move, which for obvious reasons is very important for risk frameworks. If we look at how blockchain transactions work, we see that in contrast they are uh unilateral and they lack context. Um, they like context because what you see on a public ledger tells you nothing about the counterparty that you're transacting with and it doesn't tell you what invoice that transaction is supposed to pay. And they're unilateral because whoever holds the private keys is in full control of whether settlement happens or not. So you as a receiver of a transaction uh have no say on whether you want the transaction to to come because there's no authorization process that precedes the transaction.

Um and without context and authorization, crypto rails cannot power real world payments. Uh and that is part of what explains um the fact that stable coins account for 0.03% of B2B payments today. um the trend uh the adoption trend is definitely positive and upwards but I think we can all agree that the potential here is much higher so the question is how do we get there and that's how we come we come to travel uh so when the travel came out we saw it uh as an opportunity to build or as a great catalyst to build the authorization layer that crypto has been missing we didn't see we didn't get into the travel space because we saw a burden some regulatory requirement that needed a solution. We got into it because we saw it as an opportunity to build the missing pieces that enable crypto to integrate into real economy.

Why did we see that? For context, for those of you who are not so familiar with the travel rule, it was first introduced for crypto in June 2019 in the FATF guidelines and it requires institutions to exchange originator and beneficiary information before or in parallel with the transaction. So for the first time, the travel rule creates this obligation for institutions to collaborate around information exchange before they move funds, which is why we saw it as a very good catalyst for building a pre-transaction uh authorization layer for crypto. Um since travel requirements were introduced back in June 2019, they've been progressively adopted uh across jurisdictions worldwide. Today 85% of jurisdictions with material crypto activity have travel rule regulations in place or are in the process of passing legislation.

Uh and essentially authorization flows in crypto grew with that adoption. So we went from unilateral crypto transactions to more than 1.5 trillion in total volume of authorized transactions in the noten network. Uh and these transactions all finally have counterparty context. uh the travelable information that flows with it allows businesses to tie transactions to uh the real world which is great and at this point you might be thinking so that's great the work here is done we finally have uh a pre-transaction authorization layer for crypto uh crypto is ready to integrate into real economy well unfortunately uh not exactly uh so within the notion network we've been successful in implementing pre-transaction authorization as a best practice um but it's not yet a builtin feature of crypto transactions.

Actually when we look at the results of our latest uh state of travelable report we see that over 60% of companies report that none or almost or only a small portion of incoming transactions include the required travelable information. And these institutions are not able to say no to these non-compliant deposits uh because there's no pre-transaction authorization process that preceded the the the the funds um yeah the the recipient of funds. Um and essentially this means that institutions are left uh to rely on their counterparties willingness to comply with best practices which from a riskmanagement perspective is not an ideal position to be in. Uh the good news is that that is changing. So we recently launched notif flow the open stable coin payments platform for business.

Not to benefit flow essentially builds on the authorization uh infrastructure that we've been building over the past five years and extends it to deliver full business payment capabilities including pull payments and uh recurrent subscriptions. uh the team is available to talk to you more about the business case and the the functionalities but I wanted to use our time together to really explain how not to flow embeds compliance at the core and how it turns pre-authorization as a built-in component of stable coin payments. So a core characteristic of payments within notif flow is that they are addressless up until authorization. This means that um the settlement address only becomes known to the to to to the institutions once all the due diligence, consent and compliance checks were completed. So essentially it makes it impossible to settle a transaction without authorization from uh all institutions involved.

And I'll demonstrate how that works in a more palpable way uh in just a second. A core component of flow, another core component of uh travel rule and authorization in flow is that um it supports global coverage. So we have already embedded 50 plus jurisdictional requirements in our system and that facilitates crossber compliance. So essentially any transaction that goes through not to benefit flow is validated against the travel requirements that apply in the jurisdictions involved to make sure that the travel information flowing is compliant with the applicable requirements. And third or last but not least a very important um uh characteristic of flow is its open-source foundation.

So flow is built on uh top of tap uh the transaction authorization protocol. Tap is an open messaging standard uh supported by note which defines how institutions communicate about a payment and flow is also powered by our open network which uh includes institutions from uh 100 plus jurisdictions and that have already processed 1.5 trillion plus uh transaction volume between each other. So these are core characteristics but I wanted to leave you with a very palpable understanding of how not to flow deals with travelable compliance and how it builds in pre-transaction authorization flows. So let's run through uh a concrete example and since we're in Iberian territory I thought that the restaurant related example would resonate with the audience.

Uh so let's take the example of a kitchen supplier that supplied cooking equipment to Iberian restaurants and they want to collect that invoice through notif. So we we have our parties on the screen. Uh kitchen supplier generates an invoice with their PSP orbital. Orbital then is able to initiate a payment request through note of NFlow and once this payment request is initiated there's a travel message being created under the hood uh and at this point this travelable message identifies the initiator of the payments which in this case is actually actually the beneficiary of the payment. So in the end the kitchen supplier LLC is the one that is going to receive this payment but they are initiating the the payment request.

So the initiator is kitchen supplier, their agent is orbital. The transaction amount is 10k uh USCT. Uh we still have some question marks on the travel rule package, if you will. We don't know who the respondent agent is. And very importantly, we don't have a settlement address yet.

We don't start the transaction with a settlement address. We started with a payment request. Um, not of any flow then returns a payment link which is eventually shared by kitchen supplier with the Iberian restaurant. When the Iberian restaurant opens that uh payment link, they see an interface that looks like this. And this interface allows them to decide how they want to pay this invoice.

To pay this invoice, they uh in this case select Gnosis as their respondent agent. Here they're they confirm their selection. And finally uh the the the the payment is eventually authorized through the Gnosis application. So if if we come back to this now we know that the responding agent is Gnosis. So now the travel rule message is starting to have a few less question marks.

So now we have Iberian restaurants as the respondent or the originator of that payment. Uh the Gnosis HQ as the agent. But on the transaction side, we don't have a settlement address yet. And that is because we haven't gone through the authorization process. But given all the information available, Gnosis decides to sorry to authorize the payment.

Um that triggers an authorization message to flow to Orbital. Uh and now Orbital is also in a much better position to decide whether or not they want to authorize this payment because the other side of the transaction is now transparent to them. So based on the information available, orbital decides to authorize the payment and with that authorization message, we orbital shares the settlement address where they want to receive this payment. And finally, Gnosis is able to settle the payments. Um so as I explained before, not to benefit flow builds in uh pre-transaction authorization in stable coin payments and it does so by preventing settlement before authorization.

So before both parties authorize there's no settlement address that is shared and and therefore settlement is not possible. So we make pre-transaction we elevate pre-transaction authorization from a best practice into a built-in feature of stable coin payments which significantly boosts compliance frameworks and uh risk risk mitigations for institutions involved. Um so finally we have the key elements to unlock the integration of crypto into everyday economy. Stable coins provide an amazingly efficient settlement layer and we've built a counterparty trust layer that allows us to unlock uh and materialize the opportunity. Not to benefit flow is open and open for business.

So please uh catch up with us after the the presentation and help us build the future of payments.