Philipp Zahn - Standardizing Supply-Chain Debt: Enhancing Liquidity Through Risk Transfer

All right. Hi everyone. I'm Philip from 20 squares. Uh the title of my presentation is standardizing. Actually, let me look it up because it's so long.

Standardizing supply chain depth, enhancing liquidity through risk transfer. Uh I'm sorry for the title. It sounds like a proposal from a bureaucrat from Brussels. Um but it couldn't be actually further from that. What this is actually about is in fact not bureaucracy but unleashing market forces uh in a scenario or in a situation where we actually have a market failure.

So let me start with the problem. What is the problem? The problem is that thing is not working. Now it's working. Okay.

The problem is the following. If you are a small small company, uh let's say you're a construction company, you might have an actual good contract coming up. But in order to fulfill the contract, you actually need resources. You need to buy equipment. You need to buy a material.

And one regular scenario thatmemes actually face is that they might have this very nice contract looming, but they don't have the liquidity to actually buy the material up front. And obviously the timing is relevant because theme needs to buy something before in order to deliver later. This is a wide uh widely recognized problem. If you look at the European context alone, the estimates vary, but it's something about 400 billion euro basically are missing in order to finance this gap short term. Basically um one out of four companies are affected by it.

And the key criterion still is that these companies are in principle profitable. It's not like that they are, you know, what close to bankruptcy, but they actually want to do stuff that in principle uh should be happening from an economic efficiency perspective, but it's not. They're generally um profitable, but they can't find the sources for the liquidity. If you take one step below beyond that uh go out of the European context and you think about trade cross border this gap is actually even more massive and it's makes a lot of sense because obviously the frictions going from let's say Italy to whatever New Zealand or to the Congo are obviously much more pronounced than you're delivering something to Germany. So this the frictions in between are massive.

All right. Now you might wonder why is this actually the case? Um this is there's a long list of reasons why this is actually a problem. One of the key things is obviously um if I'm a company and I have a contract with another company and maybe I'm basically owing that company some money, it's a company or it's a contract that is spaced between two entities. It's a private contract which means also that you know if that company basically wants to make uh the the receivable liquid they can't just go to some other party and say like hey take over my contract because they need my consent.

So it's there are just from a very basic perspective contractual restrictions of how easy it is actually to forward this uh this the basically the depth that is in inherent in that then also if I'm basically producer and I have you know I'm I'm selling something to a buyer and we have a long ongoing relationship there's a lot of information between us that is not accessible from the outside someone might be interested in buying up the contract but obviously we might be lacking the information the lack of information affects That's pricing. Obviously, in order to buy risk, I need to be somehow able to say, okay, how much is this thing actually risky? What is the price tag that I'm attaching to it? And obviously, it's also high friction. There are, as I said before, legal constraints, but there are also regulatory constraints.

Um, banks if they want to refund credits obviously have to go and under a lot of scrutiny. Same for other non-banking participants that if they accept private credit and they want to somehow put it into the market, they're typically crossing into a different regulatory regime and that is costly and takes time. All right. Now, this is a web 3 blockchain conference. One obvious question that you could raise and people have raised before is shouldn't there be a better way?

And couldn't this better way be actually meaning we're trying to put this form of depth or parts of it on chain and improve the situation. What could the improvements look like? Well, I'm just mentioning three obviously standardization. If you have a token that is tradable, it is standardized. Um the a it's basically also auditable.

You have an information trail that in principle specifically if people interact on chain over a long time, you can gather a lot of information. Uh secondly, you can also make information available that is very easy accessible for possible interested parties buying credit. And lastly, because we have tokens, they can be composed. We can aggregate them, disagregate them. In principle, this is a very effective way of uh forming portfolios efficiently.

And I'm actually there are more things you can also think about settlement. Uh legacy systems are very slow. This has to do with the way they have been set up, you know, 60 70 years ago. uh now there could be a new way of doing this and obviously settlement is a big issue if you think about financial instruments uh like bonds etc that are now tokenized. Okay.

Now the talk basically will be about this question. Is there a way of possibly using blockchains in order to solve this problem or at least uh make the problem less severe? Okay, my talk will have two parts. There is one part which is basically the what you can think about the ascent our struggle. Um the first part basically is when we started working on this problem we were trying to come up with a market design that actually fulfills this criteria and step by step this was a long ongoing journey and it's still obviously an ongoing journey to some degree but we encountered a lot of problems and what we also realized essentially is that the key thing is the legal question the regulatory question whatever we try to come up with a design basically was hampered by this.

Now we are now in a state where we are basically to the on the summit of this mountain. So we're looking into a journey that hopefully on the return and the descent will be simpler. Why that we are now quite optimistic that we have identified a way how to kind of combine the legal part and the economic part the token design part so that we basically have a composible stack that solves this problem in a more effective way. Okay. So part one this will be about market design.

I will walk you through uh independently of any kind of legal constraints. I will just walk you through what are the components you need. And we talk about components because we want to make this in a composable way that you can also adapt to different environments to different kind of problems. Depth is not equal to depth. Yeah.

you have a very short term you have you know um bills of uh sorry receivable bills that are let's say 1 1k 5k um traditionally solved into in some cases through factoring and there are kind of bills for projects like the construction yard that I mentioned which might be whatever 500k 1 million I will focus on the design principles so that you get a feeling for what was the reasons we chose specific implementations and I will generally discuss the stack and the components No. And in the middle after part one I will have a short interlude namely the actual problem that's basically the breaking point of every step we take namely the legal dimension and part two basically will be then about what we call a credit container and a container as you can or might know the invention of the container for global trade was a massive thing because it standardized everything and it made it basically enabled the kind of globalization we had so far even though that might be changing in the next years god knows. Um so what we will be introducing is a new building block and that building block is basically unified across the legal and economic dimension. It's a way of simplifying the whole design so that some of the economic choices we have to make will be simplified and made easier and overall the design should by choosing this instrument should become way simpler. All right let me start with the first part.

What are the core principles in designing a market and keep in mind what is the goal overall? The goal is some credit relationship in the real world let's call it the real world for now should be somehow put onchain something happens it should be possible tradable and in the end there should be some settlement or if settlement doesn't work out there should be a way of basically going to court and getting your money back or at least parts of your money. One of the key principles is modularity. We are acknowledging right from the start that credit is not credit. There are different forms.

They need different aspects. It might also be depending on the jurisdiction which we are operating in. Uh we need different ways of implementing the thing. So modularity means that we will have components that can be stacked together and the composite then basically serves the whole pipeline. It also means easy upgrades.

Technology is evolving. Blockchain technology is evolving. So our legal standards obviously on a slower dimension on a slower time scale but still we need to be able to upgrade over time. Another key factor is risk. Risk is basically the essence of depth because someone gets money and the other party is basically expecting money to come back and the key thing is expecting it does not always come back.

So we need to handle risk. And if you think about a pipeline where different agents interact, you clearly have to make sure that whoever has something to say, something to act, some action to choose in that pipeline uh does not affect risk in an unintended way for other parties. Yeah. And of course the participants must participants must be able to price the risk. That's the key thing.

Connected to this is information. We need to provide information to relevant parties. Only if you have information, you have a way, a possible way at least of pricing what a specific credit is actually worth. The way this will be working to preview is that we basically will have two components, an offchain and an on-chain component. Onchain is basically tracking basic data about what is actually held by whom.

And then offchain we have a lot of flexibility of providing additional information that's let's say about a receivable about a specific company and obviously the key challenge is to get this uh mixture right and obviously you can also use onchain components like the access or the holding of a token in order to be authorized authorized to access offchain information. And lastly, incentives. Incentives are key if you think about market design. We must make sure that people who are or entities that are looking for credit as well as those who want to fund it as well as possible third parties that provide let's say risk assessments are actually aligned in their incentives. And as you can see risk, information, incentives, this is one amagam.

It belongs together. If we make a choice on who has information, we are affecting the incentives and also obviously the risk Okay, here's the basic framework, the overview. There are six elements or modules in that stack. I will go through them in in a in detail in a in a second. Um, but just to give you an overview, you can think about this as really there is something a credit between company A and company B being negotiated, signed and then the question first question is basically okay, how do we actually put this into the digital realm?

Second, how do we put it on chain? Um, how do we risk assess it? then there will be a primary market so that whoever has the risk let's say I'm a I'm a seller and I'm sitting on a receivable and I want to sell it uh there must be a primary sale and possibly secondary markets where whoever bought it let's say investment company C then might be willing or might want to resell the debt and lastly obviously also important we need to have settlement at some point the initial buyer of whatever the goods has to fulfill the credit has to deliver the receivable or if not we need a way basically how to handle default or late payments. Now depending on the use case um and the specifics of the scenario you're interested in you might not need all of these um elements. For instance, if you're dealing with professional investors on the other side who are able and maybe much more able than anyone else to price the credits that are put on the market, an independent risk assessment might not be needed.

It might also be that time horizons are so short or the investment vehicle the credit is so specific that a secondary market is actually not ne not needed or not sensible. Good. Okay. I will walk you through the modules. Module one um this is basically how do we get from something in the extreme case it's just pen and paper on chain uh we need a step basically where we're digitizing this has to have at least two elements we need to prove that the thing is real and it has to be unique yeah so that you know not something comes up not someone doesn't copy the paper and goes to the next organizational element that has doesn't have to happen now depending on the use case so when we started designing this um we We were focused on a very narrow case on factoring in a specific country.

Um I think the use case should be public in a couple of weeks. Um in that case there is a government imposed system on invoices. It's basically to avoid tax fraud on VAT. Now in this case the problem is essentially solved for us because we can just the government is serving as us as an oracle. Basically if someone tries to tamper with invoices they are directly dealing with the government expost.

So it's a much it's just basically an enforcement through government but private solutions are possible. Now if you also think about the European context the e invoices that are now mandatory at least to accept there are more and more interfaces where you basically can lean on existing systems that you can leverage. Okay. Once we are in the digital realm we actually need to tokenize. Now how this works?

So what we will basically do is we will you know we don't have to talk much about the standards here but essentially it will be an NFT that has specific key information about the amount the maturity the parties involved and then an off-chain data link offchain data link might be in the case of factoring the underlying receivable so that someone who wants to buy that can actually inspect what is the underlying receivable is it actually you know sound what is it about etc. Data link can also be all kinds of external services that assess information about the companies involved. It might be that we have you know an audit before before you can get onto the onto the platform that you're a company actually who has some financial means and you're not you know in the bankruptcy proceeding etc. Now you might wonder if you think about a factoring case as a leading example. I have a company A and they have let's say three receivables from the same company B.

These receivables should be very similar. So why do we impose an NFT? Again, this is basically about providing a strong interface with conservative assumptions. The assumptions that we are working on is essentially that each individual title is different. Even if you're looking from the outside, they might be immediately clear that they are very much related.

uh at the beginning basically as an interface we we impose that each title is different. Why do we do this? Again we want to cover a whole range of scenarios and in some cases again think about a construction yard where there is one receipt there's one project funding request for this credit that will be very idiosyncratic and it will be very different from let's say the same company coming up with something one year later or a different construction yard somewhere totally different doing something very different. Yeah. So it's a strong assumption in order to protect what comes next.

All right. Now depending on the type of instrument and the downstream market that we want to design, we might need external parties actually assessing the parties involved as well as the receivables or the underlying uh data on which the credit is based. Again, think about a factoring case. Factoring is a well established thing. There are companies out there that do an assessment and provide risk ratings essentially for the companies involved and possibly even for specific receivables.

Depending on the investor, whether they are able to price things or not, if they are not able to price it themselves, they might be needing to rely on external parties doing this risk assessment. In the simplest case, again factoring, think about receivable being classified at different different tiers. I mentioned before, it's optional. It's not needed for in all cases. There will be professional investors that buy private credit and they actually will be much better in assessing the risk than any kind of third party.

But again we want to be modular. We want to keep open the uh the system so that we can accommodate for this scenario. What happens is that the NFT that I described before has basically an optional field. A risk score can be attached. it will be attached only by uh registered and accredited raiders.

The idea essentially is that if there is a quest request for tokenization in some case if I want to sell it on the second on the market afterwards it might actually be needed that this field is f is is is uh filled by one of the raers. Now I also want to highlight one thing. I said before once you put things on chain there is a better tracking of information and basically overall more recording of what is normally not known or basically opaque. In the case of the raiders their rating behavior the assessment and obviously also the fact whether let's say a specific receivable is paid or not is tracked over time. So in in in principle at least uh we can reward or also punish raiders that are behaving in a way that is uh exposed shown not to be in line with what actually happens in the market.

If I'm basically constantly giving very good ratings to something and constantly these things are failing something has to give. Okay. Um now we are now at a stage in the pipeline we digitalized it it's tokenized we risk assessed it possibly now the question is how do we sell it and again modularity because we are now operating in a dedicated L2 um we actually what we have to do is essentially is to switch out a contract that encodes the market logic which market logic should we choose well That depends again on the characteristics. If you have credits that are asking for let's say 1 to5 million each each time and they are very idiosyncratic on the extreme sense on the extreme side it might just be that we you know have an order book or have an auction that basically sells us to the highest bidder. Then there is an intermediate thing where we basically have let's say receivables and they have been classified as belonging to whatever three categories of risk.

among one category of risk we might do just batch auctions. So because the volume is small we are selling it basically whatever 10 15 20 depending on the exact volume in one go and whoever is the highest bidder basically gets it. Um we can also think about a more kind of crypto native solution which is a pool. It's all it's basically functioning a bit like a monetary fund um in the sense that there's a pool, it has liquidity, it has an algorithmic pricing and it's buying up essentially any kind of credit instrument that comes in up to a threshold, you know, certain risk profiles and then the investors basically are participating in that pool through tokens that are uh encoding their share there in the token in in the pool itself. And the pool basically will be run infinitely.

And obviously if it's working and it's making money the value of this pool should increase over time. It's a very standard instrument just translated into the uh D5 setup. But again this is not the only way and we are you know our background is basically in market design. That's our bread and butter. We design specific markets platforms for specific allocation platforms.

And that's exactly the point. The main the main thing here is that we will accommodate depending on the kind of market on the demand on the supply side characteristics we can just deploy one of the contracts that is actually making sense for that scenario. Okay. Uh what happens next? Primary market that could be the end of it.

Well, not completely but it could also be that we actually want to have a secondary market where whoever bought it on the primary market has a way of selling it up. Why would this be the case? Um it might be like in general if you think a pipeline in finance there are actors who buy stuff but they also want to refund it in order to get things off their books or in order to you know reduce the risks. So obviously in some cases we might have a secondary market where the initial primary market buyers can settle sorry can um sell off their positions. Um just to point out there is a dependency.

If we had an auction before this also informs or constrains what the secondary market can look like for instance uh it might mean that we actually build up a platform that is basically an OTC uh order book. In the case of a pool the problem is solved because if you own shares in the pool you can just sell it on the decks. Okay last point. We need to settle at some point. The construction company that I mentioned or whatever the tomato producer that sold tomatoes to the to the supermarket uh at some point who bought it on the other end needs to settle the depth.

And what this requires is and what the way the system is built up these entities will not even know that they're interacting with a blockchain. They basically will, you know, your normal tomato producer will not expect or the supermarket will not want to pay in stable coins, at least not yet. They will receive fiat and we obviously have a component that basically seamlessly solves the problem of someone puts in fiat, it was turned into stables. The payment onchain is then happening in stables. Why this?

Um, I mentioned before that one of the targets is trade finance. So, if you're moving within the European system, you clearly might not need all of that. But once you move out of that again having the capability of solving and settling instables and also seamlessly transferring different currencies is useful and again tracking information what happens if some someone defaults. Um again depending on the on the on the structure for instance in the pool there could be an automatic uh vehicle that actually then goes to in some sense goes to the legal proceedings and tries to get at least a share of the initial claim back. Moreover, because we are tracking this information if you're adapter and you're failing to pay it might just mean that you you know you're not having access to the platform anymore or at least for a period of time.

Okay, let me summarize so far. What do we have? We have an oracle phase that turns something that happens outside of crypto into information that can be consumed. We put it on chain. We have a risk assessment component basically that makes clear depending on the instrument what is going on how can it put how can it be priced and we have a set of markets and a settlement short modular components for different scenarios from the factoring case to something which is more project based larger depending on the scenario all right let me do a short interlude here all what I described is actually pretty simple.

There's nothing complicated there. Um the market design, these are things, these are problems, but you can solve them. It's not it's not rocket science. The actual challenge in all of that and which dictated also parts of the interfaces we chose is basically the legal and reg regulatory requirements and it starts with very simple stuff. For instance, when we made this distinction between something on the Oracle side and then the NFT side, if you have a private contract between two parties and let's say I'm holding the depth, so someone owes me money, it's not just that I can go to someone else and say, "Hey, do you want to buy that contract?"

Doesn't work. The initial party has to consent. And actually, while we're at it, even if you're selling it once and you want to sell it twice, again, you need consent. So, it's a very frict friction uh system full of frictions. And this is just touching on certain things.

What is actually the meaning of a pool? What is the regulatory legal status? I have no idea. Depends where you are. And even if depending, you know, if you're in a specific country, even then it might not be totally obvious.

Legal friction is the main hindrance in all of that. Many of the interfaces we build on the economic side are actually just that we have a stopping point where we can say whatever happens next let's break here and pause so that we can basically uh heal or make sure that the legal thing is actually still in line. Okay, I'm not a lawyer so whatever comes next don't sue me. Uh this is no legal advice and I mentioned this now because we are now entering the legal real. We are basically coming up with an instrument where we feel this is a way of moving forward.

So if you remember the red part what was the ascent we now basically at the summit we're now going down everything will be smooth everything will be simple. Okay. So what we are now building on the experience that we have gathered in the project before and others is we need to solve the core problem namely the compos composibility of the actual underlying claim and that is a legal question that we have to solve. So what is a possible path forward um we are using something which is very weird. It's an instrument that actually I think actually has been even invented in Italy a long long time ago.

It has been key for centuries in trade al international trade and has basically become almost obscure and not used anymore. Now that instrument now has been basically experienced a revival in some countries due to the fact that it has been through new legislation been updated to the digital real. What this enables is what I said before. Before we had this modularity on the different interactions, but it also allows it to vertically structure it. Whenever I do a transaction, basically the legal instrument stays intact.

And that's a key feature. The thing is tradable. It can be aggregated, disagregated. Once I aggregate or disagregate, I'm not changing the legal structure or the regulatory regime. Again, if I have credit and I want to sell it wholesale onto the financial market, typically I'm engaging in something which is called securitization, which is regulated in a different way than if I give a private credit.

This is not the case here. Okay. So, the instrument that we using is called a bill of exchange. Again, this is something which people have been using for ages. We refer to it as a depth container because it really has this feature of like for international trade once you standardize things and everything in the whole pipeline is standardized along the way.

So you have the ships, you have the trucks, you have the capabilities of unloading the trucks, you have a suddenly you have a very nice and modular pipeline. Why is this actually relevant? So bill of exchange which have you know exists in different countries for ages as I said in different legal frameworks the key features are roughly the same and they are the following. A bill of exchange encapsulates a payment application and specific legal rights importantly detached from an underlying contract. What that means if I'm selling tomatoes to someone to a supermarket the supermarket owes me money.

Now, if we are creating a bill of exchange, what this means is that the payment obligation is independent of any kind of problem with the underlying contract. It's still a payment obligation. Concretely, if I'm selling tomatoes, but I'm actually delivering bananas and I have a BOE, bill of exchange from the supermarket, the supermarket has to pay me anyway. I can take the instrument, go to court, and I will get my money even if I'm delivering something wrong. Now you might wonder what the heck is that?

Note, it is not changing my obligation on the underlying contract to deliver what I promised. The supermarket going to go after me and say, "Wait a second. You promised tomatoes and brought banana. What the hell?" They can go to court and they will get right.

But that will be separate from my obligation, sorry, from my right to get the money. And that separation is key because my obl the obligation from the supermarket to pay me is now independent and that's the thing I basically can put forward and I can also give and sell to other entities. And now if you just take the old instrument where I do this on pen and paper it has these features but once you move it into the digital realm blockchain or not you obviously get additional features. you have programmability, you can have constraints on top. Um the bill of exchange in principle also allows to shift and to spread risk.

For instance, the supermarket uh or if I'm owning if I'm basically owing the BOE from the supermarket, I can sell it, but I can also endorse it and endorsement means basically that if the supermarket fails to pay, whoever has now the bill of exchange can go to me and get the money from myself. So it's basically it's a re it's a virtual very old blockchain in the sense that I'm actually have a chain of depth rights encapsulated. Okay. Now jump from Italy to the UK where the weather is much worse. In the UK the bill of exchange is has been around for ages.

It was then finally codified. Again the UK has a very different um legal structure than most continental Europe. It's much more bottom up in the sense people do something and then you know later on the law follows suit. Um the bill of exchange basically has been enacted in the 19th century has been around for ages. Now here's the kicker.

There was basically an update in 2023 which made the instrument which before was forced to be in paper digital. And now you can think about if you go back 40 50 years when digitalization happened in finance. You can clearly see that the bill of exchange as an instrument becomes pretty much boring and out of date, right? You can't put them on on on a computer. You can't trade them, but you have to deliver this damn paper.

It's just a big big disadvantage. Now, that that disadvantage is now basically changing to the changing regulation. Why did the UK come up with it? It's actually part of an initiative by the United Nations to digitalize and to basically um improve international trade. Again, in trade you have a lot of paper.

You have a container that has a bill of laden attached to it. It has to be paper. So that initiative basically was a way of lifting it and basically digitizing these processes. the finding part negoti the negotiable instruments among which the bill of exchange is one is one instance okay I have to speed up a bit because I'm coming to the end of my time but uh let me add one more feature and then I'm basically stop with the kind of legal the legal ease but I said before I can separate the underlying contract from the payment obligation what this also means is that there is a specific court procedure if someone fails to pay the bill of bill of exchange And that's a key thing. It's basically a fast track.

Uh it's an enforcable title. In Germany, for instance, there are where are similar instruments exist. You can go to court and basically the court can make the operation stop and the company that owes the money. And it's not like a private contract. A private contract I can also take to court, but that might take ages depending on where you are.

Okay, let me jump through this. It's pretty simple. The UK is the first of the major G7 countries who has adapted the bill of sorry the the UN regulation and it also embeds basically not only this specific regulation it embeds it into a general initiative on digitalization finance and using blockchains. So this is an ideal setup. Okay.

Now how will this look like? It's pretty simple. what I said before when you think about the market platform that I described there will be elements that you can recognize again the buyer basically issues an electronic bill through our platform the idea being again there's a buyer and a seller the buyer wants to uh basically shift let's say the supermarket wants to get liquidity um the platform basically means the bill of exchange it stores data offchain investors then we are back in the marketplace can buy it basically buy this token and the vendor receives cash instantly. Again, you can see stable cash transformation happens in between and this is the the key thing. Um the smart contract at the end of maturities basically settles and then legal recourse is still preserved.

All I described so far is tradable instrument and there's no consent needed. If I hold the BOE and I want to sell it, I can do that. No one can stop me. Um I already mentioned this let me go through that fast. The key thing is the what is called the holder in due course doctrine.

That is what I mentioned before. Even if the underlying contract is broken or I'm failing to deliver the payment obligation is true. Which means if you are buying it let's say there's there's a party which buys it from me. They don't have they don't have to worry about the legal underlying contract. And that's obviously a big simplification when it comes to forecasting and also understanding and pricing the risk.

What are the benefits? Pretty much simple. SM vendors, they get immediate working capital and lower costs. The buyers, they can extend terms without harming suppliers. On the capital provider side, new transparent asset class.

And then lastly, overall kind of turning back to where I started, there is a market failure. Liquidity is not provided. And that market failure hopefully will be improved. Okay, last slide. Do I have this one minute?

Okay. Um, we're in Italy. Uh, so maybe I should say something about what is the Italian context because I talked about UK and here's now the actual kicker and does all all of these things. Um in principle to make it very short it is at least conceivable um that you can actually do set up essentially the settlement in the United Kingdom but still have it applicable in other countries that have not adapted the standard yet. Um this is true for Germany where we actually started as as a as a kind of base case but it's principle also applicable to Italy.

So what you do something settlement like happens in the UK the Italian tomato producer will not see that they will just have an ERP interface or some dashboard they can trigger it they they will basically get their fear everything which happens in the back basically is independent and if it comes to a problem of enforcing it in court the UK courts fasttrack basically is ready to to handle it. What it also means is that there is no transfer of local assets. The underlying commercial contracts, asset involved, material etc. they will stay here. And lastly, Italy also has adapted the invoicing initiative from the European Union.

So in principle, there are already interfaces that should make the integration simpler. And lastly, it's future proof. If Italy at some point actually adapts the same legislation or the same, I mean not the same, but basically conforms to the UN standards, all the better. Then basically you can switch out the settlement system. The logic will be the same.

Last thing uh this is under development. We have a specific target for how much we want to handle in one year. Sorry. Um we will after the first year basically extend into trade finance. If you're interested stay tuned.

Thank you. [Applause]