WEBVTT 00:00:00.000 --> 00:00:02.460 align:middle line:90% [SQUEAKING] 00:00:02.460 --> 00:00:03.440 align:middle line:90% [RUSTLING] 00:00:03.440 --> 00:00:06.870 align:middle line:90% [CLICKING] 00:00:06.870 --> 00:00:10.172 align:middle line:90% 00:00:10.172 --> 00:00:12.380 align:middle line:84% TOMAŽ FLEISCHMAN: So thank you, everyone, for coming. 00:00:12.380 --> 00:00:14.540 align:middle line:90% So my name is Tomaž Fleischman. 00:00:14.540 --> 00:00:17.420 align:middle line:84% I'm coming from a company called Informal Systems, 00:00:17.420 --> 00:00:19.480 align:middle line:84% and I'm working with your professor 00:00:19.480 --> 00:00:25.160 align:middle line:84% here on a subject called MTCS, or Multilateral Trade Credit 00:00:25.160 --> 00:00:25.820 align:middle line:90% Set-off. 00:00:25.820 --> 00:00:29.120 align:middle line:84% So today, we will explore what this 00:00:29.120 --> 00:00:31.620 align:middle line:84% is in a series of small examples, 00:00:31.620 --> 00:00:37.000 align:middle line:84% and we will dive into details to understand what implications 00:00:37.000 --> 00:00:40.280 align:middle line:90% this has to the real world. 00:00:40.280 --> 00:00:42.740 align:middle line:90% So the schedule for today. 00:00:42.740 --> 00:00:46.320 align:middle line:84% We will look at one of the problems that 00:00:46.320 --> 00:00:48.500 align:middle line:90% is prevalent on the market. 00:00:48.500 --> 00:00:51.200 align:middle line:90% This is late payment. 00:00:51.200 --> 00:00:53.560 align:middle line:84% We will try to understand what this is. 00:00:53.560 --> 00:00:57.440 align:middle line:84% Then we will look into how can we 00:00:57.440 --> 00:01:02.120 align:middle line:84% observe this through observing networks, obligation networks. 00:01:02.120 --> 00:01:07.960 align:middle line:84% Then we will formalize the MTCS as an algorithm, 00:01:07.960 --> 00:01:10.120 align:middle line:84% look how it works, and then we will 00:01:10.120 --> 00:01:12.480 align:middle line:90% look at the empirical setting. 00:01:12.480 --> 00:01:16.480 align:middle line:84% So how does it play out in the real-life situations? 00:01:16.480 --> 00:01:22.000 align:middle line:84% And we will look at some things that are, let's say, 00:01:22.000 --> 00:01:23.820 align:middle line:90% challenges in this area. 00:01:23.820 --> 00:01:26.600 align:middle line:90% So the network topology. 00:01:26.600 --> 00:01:30.280 align:middle line:84% And what can we do further by injecting liquidity 00:01:30.280 --> 00:01:32.180 align:middle line:90% using these techniques? 00:01:32.180 --> 00:01:34.960 align:middle line:84% So this is the program for today. 00:01:34.960 --> 00:01:39.180 align:middle line:84% And let's start with definition of the late payment. 00:01:39.180 --> 00:01:43.800 align:middle line:84% So late payment, you might know something about it 00:01:43.800 --> 00:01:47.760 align:middle line:84% from the personal settings like friends owing you money. 00:01:47.760 --> 00:01:54.200 align:middle line:84% So in business setup, that means me offering someone 00:01:54.200 --> 00:01:59.090 align:middle line:84% my goods or services on credit, expecting payment later in, 00:01:59.090 --> 00:02:01.230 align:middle line:90% let's say, 30 days. 00:02:01.230 --> 00:02:04.890 align:middle line:84% And when this does not happen, we have a late payment. 00:02:04.890 --> 00:02:08.810 align:middle line:84% And this late payment is not just, OK, it's delayed. 00:02:08.810 --> 00:02:12.690 align:middle line:84% So there are many, many issues concerning with this. 00:02:12.690 --> 00:02:16.550 align:middle line:84% So it raises cost because we have to finance this, 00:02:16.550 --> 00:02:18.270 align:middle line:90% that it is not paid. 00:02:18.270 --> 00:02:20.470 align:middle line:84% It depletes the cash reserves, and it 00:02:20.470 --> 00:02:22.710 align:middle line:84% depletes the cash reserves of those who 00:02:22.710 --> 00:02:25.730 align:middle line:90% are least capable of doing so. 00:02:25.730 --> 00:02:29.030 align:middle line:90% Small, vulnerable companies. 00:02:29.030 --> 00:02:31.010 align:middle line:84% So there are administrative costs, 00:02:31.010 --> 00:02:34.390 align:middle line:84% so we have to manage the late payments. 00:02:34.390 --> 00:02:36.670 align:middle line:84% It's a drain on labor productivity 00:02:36.670 --> 00:02:38.530 align:middle line:90% because it's unnecessary work. 00:02:38.530 --> 00:02:42.050 align:middle line:84% It creates substantial distractions from the work. 00:02:42.050 --> 00:02:44.150 align:middle line:84% So this is just from the business 00:02:44.150 --> 00:02:47.710 align:middle line:84% point of view of an individual firm, it's a problem. 00:02:47.710 --> 00:02:53.210 align:middle line:84% Looking at systemically, so it might look nice, 00:02:53.210 --> 00:02:55.170 align:middle line:84% your firm might look nice on paper, 00:02:55.170 --> 00:03:00.550 align:middle line:84% but it's not because you have basically losses 00:03:00.550 --> 00:03:05.710 align:middle line:84% and not properly managed working capital because of late payment. 00:03:05.710 --> 00:03:11.630 align:middle line:84% It places a huge burden on small companies to finance this. 00:03:11.630 --> 00:03:13.990 align:middle line:90% It causes unemployment. 00:03:13.990 --> 00:03:15.910 align:middle line:90% It causes bankruptcy. 00:03:15.910 --> 00:03:18.070 align:middle line:90% Actually, this is the major-- 00:03:18.070 --> 00:03:24.910 align:middle line:84% this is the number one reason for bankruptcies. 00:03:24.910 --> 00:03:29.750 align:middle line:84% It's killing otherwise profitable businesses. 00:03:29.750 --> 00:03:34.670 align:middle line:84% And all this basically creates huge barriers for small firms 00:03:34.670 --> 00:03:36.190 align:middle line:90% to enter. 00:03:36.190 --> 00:03:41.110 align:middle line:84% So as such, late payment is not just something that is not 00:03:41.110 --> 00:03:45.150 align:middle line:84% pleasant to see, it is an actual systemic problem 00:03:45.150 --> 00:03:47.870 align:middle line:90% that needs to be resolved. 00:03:47.870 --> 00:03:51.050 align:middle line:90% So how do we measure this? 00:03:51.050 --> 00:03:52.770 align:middle line:84% So how do we observe late payment? 00:03:52.770 --> 00:03:55.960 align:middle line:84% So this is an example of a report. 00:03:55.960 --> 00:03:59.620 align:middle line:90% This is by Intrum Justitia. 00:03:59.620 --> 00:04:04.540 align:middle line:84% It's a firm that does this for European Union annually. 00:04:04.540 --> 00:04:09.220 align:middle line:84% This is just an example from their report, United Kingdom, 00:04:09.220 --> 00:04:10.940 align:middle line:90% year 2020. 00:04:10.940 --> 00:04:12.720 align:middle line:84% And what we see here, for example, 00:04:12.720 --> 00:04:17.920 align:middle line:84% the top chart is comparison of agreed terms and actual terms. 00:04:17.920 --> 00:04:22.100 align:middle line:84% And you see that agreed terms are always 00:04:22.100 --> 00:04:23.640 align:middle line:90% lower than the actual. 00:04:23.640 --> 00:04:28.480 align:middle line:90% So 21 to 31, 45 to 64. 00:04:28.480 --> 00:04:32.420 align:middle line:84% So this extra time needed to actually pay 00:04:32.420 --> 00:04:35.060 align:middle line:90% is actually late payment. 00:04:35.060 --> 00:04:38.420 align:middle line:84% Then here on the middle, you see, 00:04:38.420 --> 00:04:41.820 align:middle line:84% from the size of the companies, how it looks like. 00:04:41.820 --> 00:04:47.500 align:middle line:84% So the larger companies more often demand from the users-- 00:04:47.500 --> 00:04:53.700 align:middle line:84% from their suppliers to extend the payment terms. 00:04:53.700 --> 00:04:58.520 align:middle line:84% And here on the bottom, it's this was just in the COVID, 00:04:58.520 --> 00:05:05.400 align:middle line:84% so you see that the sentiment went very sour during the COVID. 00:05:05.400 --> 00:05:08.420 align:middle line:84% So the expectations that there will be more late payment 00:05:08.420 --> 00:05:12.060 align:middle line:84% went up significantly during the COVID. 00:05:12.060 --> 00:05:16.640 align:middle line:84% So this is how you can see that late payment is there, 00:05:16.640 --> 00:05:19.880 align:middle line:84% and we can see, it's a prevalent problem. 00:05:19.880 --> 00:05:21.820 align:middle line:90% It's not just UK. 00:05:21.820 --> 00:05:26.400 align:middle line:84% This is the latest data from 2024. 00:05:26.400 --> 00:05:30.060 align:middle line:84% And you see, across a number of European countries, 00:05:30.060 --> 00:05:34.320 align:middle line:84% you have this around 60-day payment, 00:05:34.320 --> 00:05:38.240 align:middle line:84% which is definitely above the agreed terms. 00:05:38.240 --> 00:05:42.960 align:middle line:84% And you can also see that this goes across the sectors. 00:05:42.960 --> 00:05:48.640 align:middle line:84% So it's not just manufacturing or services, 00:05:48.640 --> 00:05:53.370 align:middle line:90% it's basically everywhere. 00:05:53.370 --> 00:05:55.330 align:middle line:90% OK. 00:05:55.330 --> 00:06:00.170 align:middle line:84% So from a point of a firm, how does it look like. 00:06:00.170 --> 00:06:01.510 align:middle line:90% So let's look at this chart. 00:06:01.510 --> 00:06:07.410 align:middle line:84% This chart was prepared by the English Association 00:06:07.410 --> 00:06:09.230 align:middle line:90% of Chartered Accountants. 00:06:09.230 --> 00:06:15.290 align:middle line:84% It's basically a toolkit for members of this association 00:06:15.290 --> 00:06:20.330 align:middle line:84% to estimate and then plan, how do I handle the late payment? 00:06:20.330 --> 00:06:24.010 align:middle line:84% And here, you see in this Venn diagram, that this-- 00:06:24.010 --> 00:06:26.510 align:middle line:90% try to sort the reasons. 00:06:26.510 --> 00:06:30.110 align:middle line:84% So you can have a very simple tactical reason, 00:06:30.110 --> 00:06:33.490 align:middle line:90% like, I just don't want to pay. 00:06:33.490 --> 00:06:37.210 align:middle line:90% It serves me well to pay later. 00:06:37.210 --> 00:06:39.570 align:middle line:84% There could be real trouble, like default-- 00:06:39.570 --> 00:06:42.030 align:middle line:90% I don't have means to pay. 00:06:42.030 --> 00:06:44.730 align:middle line:84% And there can be other stuff, like you 00:06:44.730 --> 00:06:49.890 align:middle line:84% are going beyond the regulatory practice, 00:06:49.890 --> 00:06:54.450 align:middle line:84% or maybe you have some administrative issues 00:06:54.450 --> 00:06:58.930 align:middle line:84% and you are just outside of the agreed payment terms. 00:06:58.930 --> 00:07:01.590 align:middle line:84% The interesting one is here in the middle-- 00:07:01.590 --> 00:07:03.690 align:middle line:84% so if you mix everything, you get 00:07:03.690 --> 00:07:07.290 align:middle line:84% this, buyer default in bad faith, 00:07:07.290 --> 00:07:10.270 align:middle line:84% which basically means you did it on purpose. 00:07:10.270 --> 00:07:13.250 align:middle line:84% And unfortunately, this is happening, too. 00:07:13.250 --> 00:07:17.850 align:middle line:84% So the normal thing that happens is like this. 00:07:17.850 --> 00:07:22.210 align:middle line:84% So it starts with, OK, I don't want to pay. 00:07:22.210 --> 00:07:26.770 align:middle line:84% And then it goes into, oh, I demand that you 00:07:26.770 --> 00:07:29.090 align:middle line:90% approve that I pay later. 00:07:29.090 --> 00:07:34.770 align:middle line:84% And then from that, it goes into not just I demand that I 00:07:34.770 --> 00:07:37.890 align:middle line:90% pay later, I want a discount. 00:07:37.890 --> 00:07:41.410 align:middle line:84% So this is a typical extortion scenario 00:07:41.410 --> 00:07:43.930 align:middle line:90% that happens all the time. 00:07:43.930 --> 00:07:47.990 align:middle line:84% And from the other side, I'm a little bit tight on money, 00:07:47.990 --> 00:07:50.410 align:middle line:84% I just don't want to pay right now. 00:07:50.410 --> 00:07:55.970 align:middle line:84% Then you get in all kinds of issues. 00:07:55.970 --> 00:07:59.750 align:middle line:84% And finally, you end up with the same time. 00:07:59.750 --> 00:08:04.630 align:middle line:84% So you are basically going into default and you have to-- 00:08:04.630 --> 00:08:08.730 align:middle line:90% 00:08:08.730 --> 00:08:12.610 align:middle line:84% you have to take action as a firm 00:08:12.610 --> 00:08:17.210 align:middle line:90% against non-performing customer. 00:08:17.210 --> 00:08:19.550 align:middle line:84% So what you can learn from this-- 00:08:19.550 --> 00:08:22.812 align:middle line:90% so this is a tool for a firm. 00:08:22.812 --> 00:08:24.770 align:middle line:84% What you can learn from this, that late payment 00:08:24.770 --> 00:08:26.690 align:middle line:90% is a very complex issue. 00:08:26.690 --> 00:08:30.130 align:middle line:84% So for a firm, it takes a lot of effort to manage this. 00:08:30.130 --> 00:08:38.330 align:middle line:84% So it's-- it is not a trivial matter. 00:08:38.330 --> 00:08:42.570 align:middle line:84% So another way to measure this is 00:08:42.570 --> 00:08:46.580 align:middle line:84% to just take into the account all the late payments, 00:08:46.580 --> 00:08:48.600 align:middle line:84% but this is very difficult to do. 00:08:48.600 --> 00:08:52.300 align:middle line:84% So here, we have an example of a country-- it's Slovenia, 00:08:52.300 --> 00:08:53.720 align:middle line:90% it's my home country-- 00:08:53.720 --> 00:08:55.260 align:middle line:90% where we actually did it. 00:08:55.260 --> 00:09:01.400 align:middle line:84% So here, you have by years, '91 to '94. 00:09:01.400 --> 00:09:02.920 align:middle line:90% Percent of GDP. 00:09:02.920 --> 00:09:07.920 align:middle line:84% And the blue line is reported late payment. 00:09:07.920 --> 00:09:12.000 align:middle line:90% So there was a mechanism set up. 00:09:12.000 --> 00:09:15.440 align:middle line:84% Firms would simply report, I'm late. 00:09:15.440 --> 00:09:16.980 align:middle line:90% Why would they report? 00:09:16.980 --> 00:09:21.320 align:middle line:84% Because this agency doing this also 00:09:21.320 --> 00:09:23.820 align:middle line:84% organized clearing of late payments. 00:09:23.820 --> 00:09:27.240 align:middle line:84% And the red line shows you, in a percentage of GDP, 00:09:27.240 --> 00:09:30.520 align:middle line:84% how much of the late payment was actually 00:09:30.520 --> 00:09:34.080 align:middle line:90% resolved through the mechanism. 00:09:34.080 --> 00:09:38.880 align:middle line:84% The other thing, you can observe this yellow bars, 00:09:38.880 --> 00:09:43.040 align:middle line:84% show you the annual change of the GDP. 00:09:43.040 --> 00:09:48.120 align:middle line:84% So obviously, we were in bad shape in '91. 00:09:48.120 --> 00:09:50.560 align:middle line:84% And then getting better as the economy 00:09:50.560 --> 00:09:53.780 align:middle line:84% gets better, the late payment as a problem is diminished, 00:09:53.780 --> 00:09:59.480 align:middle line:84% so the reported late payment obligations go down. 00:09:59.480 --> 00:10:04.000 align:middle line:84% But this scheme-- so this is a very specific moment 00:10:04.000 --> 00:10:05.260 align:middle line:90% in time for Slovenia. 00:10:05.260 --> 00:10:08.540 align:middle line:84% Slovenia just became independent in '91-- 00:10:08.540 --> 00:10:12.120 align:middle line:84% we had war here, so this is a war economy result. 00:10:12.120 --> 00:10:18.120 align:middle line:84% And '92 is the first year of being a state 00:10:18.120 --> 00:10:20.520 align:middle line:90% and have everything function. 00:10:20.520 --> 00:10:22.120 align:middle line:84% The interesting thing, the mechanism 00:10:22.120 --> 00:10:26.460 align:middle line:84% was set up by Parliament and monitored by Parliament, 00:10:26.460 --> 00:10:29.920 align:middle line:90% so all the data was public. 00:10:29.920 --> 00:10:33.240 align:middle line:84% Then in '95, things went under government, 00:10:33.240 --> 00:10:38.880 align:middle line:84% and then the data became unavailable. 00:10:38.880 --> 00:10:45.510 align:middle line:84% Then in year 2002, the mechanism went into a government agency 00:10:45.510 --> 00:10:47.950 align:middle line:84% and the data became public again. 00:10:47.950 --> 00:10:54.710 align:middle line:84% And we see, we were still doing fine with some nice GDP growth 00:10:54.710 --> 00:10:56.110 align:middle line:90% year by year. 00:10:56.110 --> 00:11:01.390 align:middle line:84% And the reported late payments going down until you-- 00:11:01.390 --> 00:11:04.010 align:middle line:90% I think you know this area. 00:11:04.010 --> 00:11:09.230 align:middle line:84% So we have this financial crisis, 2008 and later. 00:11:09.230 --> 00:11:12.710 align:middle line:84% And you see the interesting jump, yeah. 00:11:12.710 --> 00:11:18.170 align:middle line:84% The late payments went up significantly, 00:11:18.170 --> 00:11:20.310 align:middle line:90% and so did the results. 00:11:20.310 --> 00:11:25.230 align:middle line:84% The similar thing you can observe here for the COVID. 00:11:25.230 --> 00:11:27.870 align:middle line:84% So by observing this graph, you might say, OK, 00:11:27.870 --> 00:11:29.970 align:middle line:84% but this mechanism is not really working. 00:11:29.970 --> 00:11:33.030 align:middle line:84% Why is it going down all the time? 00:11:33.030 --> 00:11:35.770 align:middle line:84% So there is some background information you need, 00:11:35.770 --> 00:11:41.110 align:middle line:84% and this is that, in this crisis, 00:11:41.110 --> 00:11:45.130 align:middle line:84% private firms establish their own clearing mechanisms, 00:11:45.130 --> 00:11:47.990 align:middle line:84% and currently, private firms clear more 00:11:47.990 --> 00:11:51.790 align:middle line:84% than the public agency, but private firms 00:11:51.790 --> 00:11:54.870 align:middle line:90% don't share the data. 00:11:54.870 --> 00:11:59.270 align:middle line:84% But I know the biggest one is bigger than the public service 00:11:59.270 --> 00:11:59.810 align:middle line:90% right now. 00:11:59.810 --> 00:12:04.070 align:middle line:84% So we have this clearing of late payment set up 00:12:04.070 --> 00:12:07.690 align:middle line:90% in Slovenia for years. 00:12:07.690 --> 00:12:15.390 align:middle line:84% And as such, basically the motivation for me to go outside 00:12:15.390 --> 00:12:19.290 align:middle line:84% was to explore, why is not everyone doing this? 00:12:19.290 --> 00:12:24.230 align:middle line:90% So this is the point 00:12:24.230 --> 00:12:27.790 align:middle line:90% OK, so late payments. 00:12:27.790 --> 00:12:30.370 align:middle line:84% Now the question, how do we do-- how do we do it? 00:12:30.370 --> 00:12:35.730 align:middle line:84% So how does the management of late payment actually work? 00:12:35.730 --> 00:12:38.980 align:middle line:84% So what is this agency doing-- or what can 00:12:38.980 --> 00:12:44.020 align:middle line:84% a private firm do to help the wider economy? 00:12:44.020 --> 00:12:48.440 align:middle line:84% And we will look first how to form a graph. 00:12:48.440 --> 00:12:51.165 align:middle line:90% 00:12:51.165 --> 00:12:54.140 align:middle line:84% So the example here is very simple. 00:12:54.140 --> 00:12:57.060 align:middle line:84% My favorite actors, Alice, Bob, and Charlie, 00:12:57.060 --> 00:13:00.460 align:middle line:84% are the main characters of this game. 00:13:00.460 --> 00:13:07.400 align:middle line:84% So Alice owes 2 to Bob, Bob owes 2 to Charlie, 00:13:07.400 --> 00:13:12.060 align:middle line:90% and Charlie owes 1 to Alice. 00:13:12.060 --> 00:13:17.780 align:middle line:84% So these are the outstanding trade credit obligations. 00:13:17.780 --> 00:13:20.400 align:middle line:84% And in this simple example, it's trivial. 00:13:20.400 --> 00:13:23.060 align:middle line:90% So you can see a cycle. 00:13:23.060 --> 00:13:26.740 align:middle line:84% Alice, Bob, Charlie, this is a cycle. 00:13:26.740 --> 00:13:29.460 align:middle line:90% The amounts are not the same. 00:13:29.460 --> 00:13:32.620 align:middle line:84% So we have the smallest amount here, 1. 00:13:32.620 --> 00:13:36.700 align:middle line:84% So a cycle of 1 between Alice, Bob, and Charlie 00:13:36.700 --> 00:13:39.840 align:middle line:84% can be set off in a multilateral setup. 00:13:39.840 --> 00:13:43.860 align:middle line:84% So you can simply clear this without any use 00:13:43.860 --> 00:13:46.340 align:middle line:90% of outside money. 00:13:46.340 --> 00:13:51.250 align:middle line:84% And what remains, then, would be Alice owing 1 to Bob and Bob, 00:13:51.250 --> 00:13:52.580 align:middle line:90% 1 to Charlie. 00:13:52.580 --> 00:13:54.420 align:middle line:90% So this is how it works. 00:13:54.420 --> 00:13:56.140 align:middle line:90% It's very simple. 00:13:56.140 --> 00:14:00.340 align:middle line:84% The problem is, even in this example, 00:14:00.340 --> 00:14:02.380 align:middle line:90% they cannot do it alone. 00:14:02.380 --> 00:14:07.780 align:middle line:84% So Alice, how can she know that Bob owes 2 to charlie? 00:14:07.780 --> 00:14:10.520 align:middle line:90% She cannot, so she has to ask. 00:14:10.520 --> 00:14:15.180 align:middle line:84% So you need some kind-- so you cannot do this alone because you 00:14:15.180 --> 00:14:17.160 align:middle line:84% don't have a full view of a network. 00:14:17.160 --> 00:14:19.160 align:middle line:84% You see yourself, you see your obligation, 00:14:19.160 --> 00:14:24.140 align:middle line:84% you see what other owes you, but without some kind 00:14:24.140 --> 00:14:30.340 align:middle line:84% of coordination, you cannot achieve a thing. 00:14:30.340 --> 00:14:35.080 align:middle line:84% And also detecting a cycle here, as it looks trivial. 00:14:35.080 --> 00:14:40.180 align:middle line:84% Now imagine you have thousands of them, so how do you do this? 00:14:40.180 --> 00:14:45.860 align:middle line:84% So the trick here is that you don't look at cycles at all. 00:14:45.860 --> 00:14:50.800 align:middle line:84% So we have to reformulate the problem. 00:14:50.800 --> 00:14:52.400 align:middle line:84% So we are not looking for cycles. 00:14:52.400 --> 00:14:54.240 align:middle line:90% We are looking for balances. 00:14:54.240 --> 00:14:56.620 align:middle line:90% This is a very simple approach. 00:14:56.620 --> 00:15:03.600 align:middle line:84% So Alice, she has a balanced position minus 1. 00:15:03.600 --> 00:15:04.100 align:middle line:90% Why? 00:15:04.100 --> 00:15:09.300 align:middle line:84% Because she owes 2 and she is out 1, so the difference is she 00:15:09.300 --> 00:15:10.160 align:middle line:90% owes 1 more. 00:15:10.160 --> 00:15:12.020 align:middle line:90% So she is minus 1. 00:15:12.020 --> 00:15:16.520 align:middle line:84% Bob is neutral, so 2 in, 2 out, 0. 00:15:16.520 --> 00:15:22.420 align:middle line:84% And Charlie has balance position of 1, 2 in, 1 out. 00:15:22.420 --> 00:15:24.960 align:middle line:90% So this is our initial setup. 00:15:24.960 --> 00:15:29.420 align:middle line:84% So what we want to do, then, with this is we say, 00:15:29.420 --> 00:15:31.200 align:middle line:84% let's balance this network fully. 00:15:31.200 --> 00:15:35.070 align:middle line:84% So we don't want to have Alice and Charlie with minus 1 and 1, 00:15:35.070 --> 00:15:37.970 align:middle line:90% we want to balance this. 00:15:37.970 --> 00:15:42.570 align:middle line:84% And we do this by introducing imaginary liquidity because we 00:15:42.570 --> 00:15:44.410 align:middle line:90% are talking about late payment. 00:15:44.410 --> 00:15:48.270 align:middle line:84% So late payment happens because there are no funds. 00:15:48.270 --> 00:15:52.650 align:middle line:84% So we are doing here, introducing 00:15:52.650 --> 00:16:00.330 align:middle line:84% imaginary source of funding, and we have a sink of funds. 00:16:00.330 --> 00:16:05.330 align:middle line:84% And we use this source and sink to balance the network. 00:16:05.330 --> 00:16:10.930 align:middle line:84% So Alice was minus 1, so she needs 1 from the source. 00:16:10.930 --> 00:16:14.350 align:middle line:84% Charlie was plus 1, so he has 1 too much, 00:16:14.350 --> 00:16:19.170 align:middle line:84% so this excess flow goes to the sink. 00:16:19.170 --> 00:16:23.650 align:middle line:84% So this is how we balance the network. 00:16:23.650 --> 00:16:27.790 align:middle line:84% Now with the network balanced, at least the original network, 00:16:27.790 --> 00:16:30.370 align:middle line:84% Alice, Bob, and Charlie, balanced, now we 00:16:30.370 --> 00:16:34.050 align:middle line:90% can do some nice algorithms. 00:16:34.050 --> 00:16:38.450 align:middle line:84% And this one is, let's find a saturating flow 00:16:38.450 --> 00:16:39.630 align:middle line:90% from source to sink. 00:16:39.630 --> 00:16:43.970 align:middle line:84% So we are just pushing liquidity from source 00:16:43.970 --> 00:16:47.590 align:middle line:84% to sink in the most efficient way possible, 00:16:47.590 --> 00:16:54.090 align:middle line:84% and this is shown here by the dotted red arrows. 00:16:54.090 --> 00:16:57.010 align:middle line:84% So we have a flow of 1, going from source 00:16:57.010 --> 00:17:01.590 align:middle line:84% to Alice, then 1 from Alice to Bob, 1 from Bob to Charlie, 00:17:01.590 --> 00:17:03.990 align:middle line:90% and 1 from Charlie to the sink. 00:17:03.990 --> 00:17:06.250 align:middle line:90% So we have a saturating flow. 00:17:06.250 --> 00:17:09.690 align:middle line:84% By construction, the outflows of source 00:17:09.690 --> 00:17:13.970 align:middle line:84% are always equal to inflows of the sink. 00:17:13.970 --> 00:17:16.210 align:middle line:84% So if you saturate, it just means 00:17:16.210 --> 00:17:19.970 align:middle line:84% you have to push everything through. 00:17:19.970 --> 00:17:23.130 align:middle line:84% So now we have this saturating s-t flow. 00:17:23.130 --> 00:17:27.329 align:middle line:84% And the next step we do is we simply 00:17:27.329 --> 00:17:31.000 align:middle line:90% remove the saturating flow. 00:17:31.000 --> 00:17:36.700 align:middle line:84% And while removing it, it shows the cycle. 00:17:36.700 --> 00:17:39.500 align:middle line:84% So this is how the cycle is identified. 00:17:39.500 --> 00:17:42.440 align:middle line:90% And this technique works in-- 00:17:42.440 --> 00:17:45.780 align:middle line:84% doesn't matter how large the network. 00:17:45.780 --> 00:17:48.640 align:middle line:90% 00:17:48.640 --> 00:17:51.020 align:middle line:84% So at this point, are there any questions? 00:17:51.020 --> 00:17:57.040 align:middle line:84% So anyone confused, or was I clear enough? 00:17:57.040 --> 00:18:01.120 align:middle line:84% So everyone is nodding, so for the camera 00:18:01.120 --> 00:18:04.160 align:middle line:90% because they don't hear you. 00:18:04.160 --> 00:18:04.740 align:middle line:90% OK. 00:18:04.740 --> 00:18:06.240 align:middle line:90% So everyone is clear? 00:18:06.240 --> 00:18:08.200 align:middle line:90% Good. 00:18:08.200 --> 00:18:11.980 align:middle line:84% So this was just a really simple example. 00:18:11.980 --> 00:18:17.760 align:middle line:84% So let's try to formalize it in a bit of mathematics. 00:18:17.760 --> 00:18:21.040 align:middle line:90% 00:18:21.040 --> 00:18:24.020 align:middle line:90% So what do we have to do? 00:18:24.020 --> 00:18:32.000 align:middle line:84% So we have our network, and we have to introduce the sink and-- 00:18:32.000 --> 00:18:33.520 align:middle line:90% source and sink. 00:18:33.520 --> 00:18:40.640 align:middle line:84% And we do this in order for everything to be balanced. 00:18:40.640 --> 00:18:47.760 align:middle line:84% So we introduced the network, G0 with nodes with edges. 00:18:47.760 --> 00:18:49.720 align:middle line:90% And we say that-- 00:18:49.720 --> 00:18:55.800 align:middle line:84% we define the balance as a difference between the outflows 00:18:55.800 --> 00:19:00.480 align:middle line:90% and inflows for each node. 00:19:00.480 --> 00:19:02.880 align:middle line:84% And then we define the balanced network 00:19:02.880 --> 00:19:08.600 align:middle line:84% G, which is basically the original network plus source 00:19:08.600 --> 00:19:09.920 align:middle line:90% and sink. 00:19:09.920 --> 00:19:12.580 align:middle line:90% And we add the edges. 00:19:12.580 --> 00:19:19.600 align:middle line:84% So just for every node that has a negative balance 00:19:19.600 --> 00:19:22.860 align:middle line:84% in the original network, we add an edge from the sink, 00:19:22.860 --> 00:19:27.150 align:middle line:84% and for every node that has a positive, 00:19:27.150 --> 00:19:32.310 align:middle line:84% we add an edge from that node to the sink. 00:19:32.310 --> 00:19:35.070 align:middle line:84% And the capacity of these edges are 00:19:35.070 --> 00:19:38.390 align:middle line:84% equal to the balance-- or minus balance 00:19:38.390 --> 00:19:41.110 align:middle line:90% in the case of the source. 00:19:41.110 --> 00:19:45.510 align:middle line:90% So this is this part. 00:19:45.510 --> 00:19:49.850 align:middle line:84% And the resulting structure is a balanced graph. 00:19:49.850 --> 00:19:51.430 align:middle line:84% So we can define this balanced graph 00:19:51.430 --> 00:19:56.490 align:middle line:84% as a graph with capacities on each edges. 00:19:56.490 --> 00:19:58.830 align:middle line:84% Capacities are always positive, so we don't 00:19:58.830 --> 00:20:02.230 align:middle line:90% allow negative capacities. 00:20:02.230 --> 00:20:07.590 align:middle line:84% Each edge also gets assigned a cost. 00:20:07.590 --> 00:20:11.310 align:middle line:90% So I will make here a comment. 00:20:11.310 --> 00:20:16.670 align:middle line:84% In today's lecture, we use only the basic case. 00:20:16.670 --> 00:20:21.190 align:middle line:90% Each edge has cost 1. 00:20:21.190 --> 00:20:25.350 align:middle line:84% There are further possibilities, further optimizations 00:20:25.350 --> 00:20:28.730 align:middle line:84% you can do if you play with cost, but for the basic case, 00:20:28.730 --> 00:20:34.510 align:middle line:84% we have cost on all edges set to 1. 00:20:34.510 --> 00:20:37.150 align:middle line:84% So we have a source and the sink, 00:20:37.150 --> 00:20:42.310 align:middle line:84% and all the nodes in the graph except the source and sink 00:20:42.310 --> 00:20:43.490 align:middle line:90% are balanced. 00:20:43.490 --> 00:20:49.790 align:middle line:84% So this is our balanced graph, this is the base. 00:20:49.790 --> 00:20:56.210 align:middle line:84% Now we have to apply the minimum cost, maximum flow algorithm. 00:20:56.210 --> 00:20:59.710 align:middle line:84% So those who study computer science, 00:20:59.710 --> 00:21:04.870 align:middle line:84% if you went to some graph flow algorithm classes, 00:21:04.870 --> 00:21:06.310 align:middle line:90% should know this. 00:21:06.310 --> 00:21:08.710 align:middle line:84% I assumed that at least computer scientists 00:21:08.710 --> 00:21:14.150 align:middle line:84% know this because otherwise, it's another lecture about this. 00:21:14.150 --> 00:21:19.590 align:middle line:84% And we apply this to identify the saturating s-t flow. 00:21:19.590 --> 00:21:21.990 align:middle line:90% So just a basic definition. 00:21:21.990 --> 00:21:26.630 align:middle line:84% The minimum cost, maximum flow is basically 00:21:26.630 --> 00:21:31.270 align:middle line:84% a function that assigns a value to each edge. 00:21:31.270 --> 00:21:35.190 align:middle line:84% So the value is somewhere between 0 00:21:35.190 --> 00:21:38.870 align:middle line:90% and the capacity of the edge. 00:21:38.870 --> 00:21:44.390 align:middle line:84% There must be a flow conservation principle 00:21:44.390 --> 00:21:45.450 align:middle line:90% respected. 00:21:45.450 --> 00:21:51.510 align:middle line:84% So that means whatever goes into the node goes out. 00:21:51.510 --> 00:21:56.430 align:middle line:84% And we want to maximize the total flow. 00:21:56.430 --> 00:22:01.190 align:middle line:84% This is to achieve the saturation of s-t flow. 00:22:01.190 --> 00:22:03.910 align:middle line:84% And we minimize the total cost where 00:22:03.910 --> 00:22:07.750 align:middle line:84% the cost is just flows times the cost of the flow 00:22:07.750 --> 00:22:09.870 align:middle line:90% through the edge. 00:22:09.870 --> 00:22:15.510 align:middle line:84% So this is how the minimum cost, maximum flow is defined. 00:22:15.510 --> 00:22:20.740 align:middle line:84% And the next step is then, as we said, just a subtraction. 00:22:20.740 --> 00:22:25.920 align:middle line:84% So when we subtract, we can, again-- 00:22:25.920 --> 00:22:27.860 align:middle line:84% what we need to observe here is-- 00:22:27.860 --> 00:22:32.540 align:middle line:84% so this is interesting thing to prove, let's say. 00:22:32.540 --> 00:22:36.980 align:middle line:84% If we subtract saturating flow, the expected result 00:22:36.980 --> 00:22:43.380 align:middle line:84% is a cycle, and no flows from source and to sink. 00:22:43.380 --> 00:22:48.540 align:middle line:84% So to prove this we say, OK, the balance 00:22:48.540 --> 00:22:53.300 align:middle line:84% in the new graph, in the resulting graph is what? 00:22:53.300 --> 00:23:00.400 align:middle line:84% Is the new flows, the new capacities of the edges. 00:23:00.400 --> 00:23:05.700 align:middle line:84% But the new capacities are all capacities minus the flow. 00:23:05.700 --> 00:23:08.540 align:middle line:84% And if you rearrange this a little bit, you see, 00:23:08.540 --> 00:23:15.500 align:middle line:84% this is the original balance minus the inflows and outflows 00:23:15.500 --> 00:23:17.540 align:middle line:90% of the saturating flow. 00:23:17.540 --> 00:23:20.660 align:middle line:84% But if you look at the balances, you 00:23:20.660 --> 00:23:24.660 align:middle line:84% will see that, this is all 0, so we have this on the next slide. 00:23:24.660 --> 00:23:28.820 align:middle line:84% So because we have a flow conservation principle, 00:23:28.820 --> 00:23:35.580 align:middle line:84% the inflows and outflows of the saturating flow for each node 00:23:35.580 --> 00:23:37.380 align:middle line:90% are 0. 00:23:37.380 --> 00:23:40.580 align:middle line:84% And the balance, because we made the network balance, 00:23:40.580 --> 00:23:43.620 align:middle line:84% is also 0, so we can easily prove 00:23:43.620 --> 00:23:48.820 align:middle line:84% that we have this situation here where 00:23:48.820 --> 00:23:55.060 align:middle line:84% every node in the resulting graph is balanced. 00:23:55.060 --> 00:23:59.180 align:middle line:84% And now we only need to prove that this is empty. 00:23:59.180 --> 00:24:02.860 align:middle line:84% And we follow the same logic, and we can easily 00:24:02.860 --> 00:24:14.980 align:middle line:84% see that by construction, both source and sink result in 0. 00:24:14.980 --> 00:24:19.130 align:middle line:84% So this is a little bit of mathematics behind it. 00:24:19.130 --> 00:24:22.706 align:middle line:90% Any questions at this point? 00:24:22.706 --> 00:24:23.650 align:middle line:90% No? 00:24:23.650 --> 00:24:25.250 align:middle line:90% Too simple. 00:24:25.250 --> 00:24:30.070 align:middle line:84% I should lift the level here for the next time I come. 00:24:30.070 --> 00:24:32.610 align:middle line:90% 00:24:32.610 --> 00:24:33.110 align:middle line:90% OK. 00:24:33.110 --> 00:24:36.530 align:middle line:84% So we looked at the formal definition, so what 00:24:36.530 --> 00:24:40.470 align:middle line:84% remains now is to look at the actual algorithm. 00:24:40.470 --> 00:24:42.770 align:middle line:90% So how do you-- how do you do-- 00:24:42.770 --> 00:24:44.130 align:middle line:90% how do you do this? 00:24:44.130 --> 00:24:47.610 align:middle line:90% So we have here a pseudocode. 00:24:47.610 --> 00:24:53.330 align:middle line:84% We just follow the same stuff, so what needs to be done. 00:24:53.330 --> 00:24:56.770 align:middle line:84% We have to balance, find the saturating flow, 00:24:56.770 --> 00:25:00.250 align:middle line:90% and then subtract it. 00:25:00.250 --> 00:25:07.930 align:middle line:84% So to make it easier to read, so this is how we do the balancing. 00:25:07.930 --> 00:25:15.170 align:middle line:84% So we just define new nodes, source and sink. 00:25:15.170 --> 00:25:19.850 align:middle line:84% Then we simply go, for every node in the original graph, 00:25:19.850 --> 00:25:25.030 align:middle line:84% you establish the net position and add edges. 00:25:25.030 --> 00:25:30.330 align:middle line:84% So if net position is less than 0, you add an edge from source 00:25:30.330 --> 00:25:31.230 align:middle line:90% to the firm. 00:25:31.230 --> 00:25:35.690 align:middle line:84% If the net position is positive, you add an edge 00:25:35.690 --> 00:25:37.950 align:middle line:90% from that node to the sink. 00:25:37.950 --> 00:25:41.410 align:middle line:84% And this is all there is to it, so there's nothing 00:25:41.410 --> 00:25:44.450 align:middle line:90% more complicated. 00:25:44.450 --> 00:25:49.970 align:middle line:84% The next step is finding the saturated s-t flow. 00:25:49.970 --> 00:25:53.890 align:middle line:84% And here, we use the minimum cost, 00:25:53.890 --> 00:25:58.170 align:middle line:90% max flow as a standard element. 00:25:58.170 --> 00:26:07.810 align:middle line:84% So it's this condition here, if source is element. 00:26:07.810 --> 00:26:12.200 align:middle line:84% So the way we constructed the balanced network, 00:26:12.200 --> 00:26:16.560 align:middle line:84% if the network is already balanced as an input, 00:26:16.560 --> 00:26:20.760 align:middle line:84% there is no source included in the network. 00:26:20.760 --> 00:26:25.180 align:middle line:84% So this is just to identify the already balanced network, 00:26:25.180 --> 00:26:29.320 align:middle line:90% so then you just pass. 00:26:29.320 --> 00:26:33.040 align:middle line:84% So only if there is a source, then you 00:26:33.040 --> 00:26:36.160 align:middle line:84% use the minimum cost, maximum flow. 00:26:36.160 --> 00:26:40.520 align:middle line:84% So for any one of you who will be tempted after this lecture 00:26:40.520 --> 00:26:44.360 align:middle line:84% to try this by themselves, so the easiest way to do 00:26:44.360 --> 00:26:47.560 align:middle line:90% is use Python. 00:26:47.560 --> 00:26:52.280 align:middle line:84% NetworkX is my preferred library. 00:26:52.280 --> 00:26:55.040 align:middle line:84% There are several minimum cost, maximum flow 00:26:55.040 --> 00:26:57.640 align:middle line:90% algorithms available. 00:26:57.640 --> 00:27:01.820 align:middle line:84% They all perform well, but not equally well. 00:27:01.820 --> 00:27:05.440 align:middle line:84% So the difference is shown when you try it 00:27:05.440 --> 00:27:08.440 align:middle line:90% on a really large networks. 00:27:08.440 --> 00:27:12.740 align:middle line:84% But for toy models, everything will work. 00:27:12.740 --> 00:27:13.280 align:middle line:90% Yes? 00:27:13.280 --> 00:27:14.780 align:middle line:84% AUDIENCE: Yeah, so how do you know-- 00:27:14.780 --> 00:27:16.880 align:middle line:84% I mean, the costs that you pick, you 00:27:16.880 --> 00:27:20.520 align:middle line:84% said you're going to pick uniform costs everywhere. 00:27:20.520 --> 00:27:24.100 align:middle line:84% In a real application, how do we interpret those costs? 00:27:24.100 --> 00:27:28.320 align:middle line:84% Are those the costs of the late payments that could 00:27:28.320 --> 00:27:30.680 align:middle line:90% arise from a cycle like this? 00:27:30.680 --> 00:27:32.322 align:middle line:84% And how do you know what they are? 00:27:32.322 --> 00:27:33.280 align:middle line:90% TOMAŽ FLEISCHMAN: Yeah. 00:27:33.280 --> 00:27:36.460 align:middle line:84% So we go for cost of one as a basic. 00:27:36.460 --> 00:27:41.200 align:middle line:84% So you can imagine-- so what are we actually doing? 00:27:41.200 --> 00:27:45.680 align:middle line:84% Normally if you have a network of obligations, 00:27:45.680 --> 00:27:49.000 align:middle line:84% you expect everything will be paid. 00:27:49.000 --> 00:27:51.360 align:middle line:90% But this is not a fact of life. 00:27:51.360 --> 00:27:57.160 align:middle line:84% So what we do, we assume there is no money. 00:27:57.160 --> 00:28:04.080 align:middle line:84% And then we introduce this imaginary money through source 00:28:04.080 --> 00:28:09.360 align:middle line:84% and sink, and we say, let's use-- 00:28:09.360 --> 00:28:12.000 align:middle line:84% let's make as little transactions as possible 00:28:12.000 --> 00:28:19.040 align:middle line:84% with this imaginary money and throw this away. 00:28:19.040 --> 00:28:23.160 align:middle line:84% And what remains is what clears by itself. 00:28:23.160 --> 00:28:27.280 align:middle line:84% And having equal cost of one just 00:28:27.280 --> 00:28:35.840 align:middle line:84% means that we really made the flow as small as possible. 00:28:35.840 --> 00:28:38.440 align:middle line:84% If you introduce costs for whatever 00:28:38.440 --> 00:28:42.620 align:middle line:84% reasons-- for example, you want to play with risks, 00:28:42.620 --> 00:28:48.080 align:middle line:84% so you say, OK, not all obligations have the same risk, 00:28:48.080 --> 00:28:54.640 align:middle line:84% then the solution will optimize for that situation. 00:28:54.640 --> 00:28:56.740 align:middle line:90% But then it depends. 00:28:56.740 --> 00:29:00.100 align:middle line:84% So you might do this like an economist, so with risks, 00:29:00.100 --> 00:29:02.000 align:middle line:84% but then there are other options. 00:29:02.000 --> 00:29:05.560 align:middle line:84% For example, maybe there is some social benefit, 00:29:05.560 --> 00:29:12.430 align:middle line:84% like food safety, and I want to put a cost on how much does this 00:29:12.430 --> 00:29:15.030 align:middle line:84% contribute to the community food safety, 00:29:15.030 --> 00:29:17.690 align:middle line:84% and then you get a different solution. 00:29:17.690 --> 00:29:21.150 align:middle line:90% 00:29:21.150 --> 00:29:23.713 align:middle line:84% AUDIENCE: So you can allow for arbitrary costs? 00:29:23.713 --> 00:29:24.630 align:middle line:90% TOMAŽ FLEISCHMAN: Yes. 00:29:24.630 --> 00:29:26.505 align:middle line:84% AUDIENCE: Then you can then have a backstory? 00:29:26.505 --> 00:29:28.590 align:middle line:84% TOMAŽ FLEISCHMAN: Yeah, but then-- 00:29:28.590 --> 00:29:30.090 align:middle line:90% this is another lecture, then. 00:29:30.090 --> 00:29:32.230 align:middle line:90% So how do we do this? 00:29:32.230 --> 00:29:34.790 align:middle line:90% Yeah. 00:29:34.790 --> 00:29:37.710 align:middle line:84% Any other question at this point? 00:29:37.710 --> 00:29:44.150 align:middle line:84% So my experience is, if you want to truly understand this, 00:29:44.150 --> 00:29:49.550 align:middle line:84% it takes like an hour or so to do it in Python. 00:29:49.550 --> 00:29:52.850 align:middle line:90% It shouldn't be-- it's easy. 00:29:52.850 --> 00:29:55.510 align:middle line:90% 00:29:55.510 --> 00:29:59.930 align:middle line:84% So the last thing to do, then, is simply to subtract, 00:29:59.930 --> 00:30:02.310 align:middle line:90% and here, we just go-- 00:30:02.310 --> 00:30:04.850 align:middle line:84% we say, OK, the result is an empty network, 00:30:04.850 --> 00:30:07.870 align:middle line:84% and then we go through the original network 00:30:07.870 --> 00:30:15.230 align:middle line:84% and subtract the amounts that were 00:30:15.230 --> 00:30:20.430 align:middle line:84% returned by the minimum cost, maximum flow function. 00:30:20.430 --> 00:30:26.190 align:middle line:90% And this is how we get-- 00:30:26.190 --> 00:30:32.950 align:middle line:84% how we get to the result. Any more questions 00:30:32.950 --> 00:30:34.930 align:middle line:90% on the algorithm side? 00:30:34.930 --> 00:30:41.270 align:middle line:90% 00:30:41.270 --> 00:30:43.650 align:middle line:90% OK, so this was simple. 00:30:43.650 --> 00:30:45.478 align:middle line:84% It was just Alice, Bob, and Charlie, 00:30:45.478 --> 00:30:47.770 align:middle line:84% but we went through everything, so now the question is, 00:30:47.770 --> 00:30:52.510 align:middle line:84% what happens if you put this into a real-life situation? 00:30:52.510 --> 00:30:58.390 align:middle line:84% And I will show you here the setting on an empirical network 00:30:58.390 --> 00:31:00.850 align:middle line:90% that we have from Infocert. 00:31:00.850 --> 00:31:03.700 align:middle line:84% So Infocert is an Italian company. 00:31:03.700 --> 00:31:05.780 align:middle line:90% They do tax compliance. 00:31:05.780 --> 00:31:10.580 align:middle line:84% So for you-- in Italy, they have VAT. 00:31:10.580 --> 00:31:12.540 align:middle line:84% And when you issue an invoice, you 00:31:12.540 --> 00:31:16.700 align:middle line:84% have to report to the tax authorities that you issued. 00:31:16.700 --> 00:31:20.220 align:middle line:84% And the process is so complicated 00:31:20.220 --> 00:31:24.560 align:middle line:84% that firms decide to outsource the processing, 00:31:24.560 --> 00:31:29.980 align:middle line:84% and Infocert is one of such invoice processing firms, 00:31:29.980 --> 00:31:32.940 align:middle line:84% and this is why we were able to get 00:31:32.940 --> 00:31:37.660 align:middle line:84% high-quality data about the invoices 00:31:37.660 --> 00:31:40.220 align:middle line:90% among the companies in Italy. 00:31:40.220 --> 00:31:44.040 align:middle line:84% So this is how the Italian network looks like. 00:31:44.040 --> 00:31:48.300 align:middle line:84% So this is just part of the data we have. 00:31:48.300 --> 00:31:54.100 align:middle line:84% We have 45,000 dots on this, so every dot is a firm. 00:31:54.100 --> 00:31:59.580 align:middle line:84% The edges between firms are transparent because otherwise, 00:31:59.580 --> 00:32:03.260 align:middle line:84% it would be a black blob, but you see here 00:32:03.260 --> 00:32:06.600 align:middle line:84% in the center of the network some blackness from the edges. 00:32:06.600 --> 00:32:12.220 align:middle line:84% So there are roughly 2 million edges in this figure here. 00:32:12.220 --> 00:32:15.840 align:middle line:84% So on the right side, it's just aggregated. 00:32:15.840 --> 00:32:20.620 align:middle line:84% So according to the firm size, you see that, by far, 00:32:20.620 --> 00:32:26.180 align:middle line:84% largest group of companies are micro-companies. 00:32:26.180 --> 00:32:28.500 align:middle line:84% Then you have small, medium, and large. 00:32:28.500 --> 00:32:32.720 align:middle line:84% And the largest transactions are among the large firms. 00:32:32.720 --> 00:32:35.740 align:middle line:84% So these blue dots here, basically, 00:32:35.740 --> 00:32:40.900 align:middle line:84% act as major hubs for the network. 00:32:40.900 --> 00:32:44.640 align:middle line:84% But the traffic goes among all of them. 00:32:44.640 --> 00:32:48.180 align:middle line:84% So there is no hierarchy here, really. 00:32:48.180 --> 00:32:55.640 align:middle line:84% So this is our network, and we ran the MTCS algorithm on this. 00:32:55.640 --> 00:32:58.340 align:middle line:90% So how do you do this? 00:32:58.340 --> 00:33:01.530 align:middle line:84% You introduce source and target nodes. 00:33:01.530 --> 00:33:04.530 align:middle line:90% We have a source target. 00:33:04.530 --> 00:33:07.850 align:middle line:84% We do the edges, and here is just the illustrations 00:33:07.850 --> 00:33:11.710 align:middle line:84% of what you saw earlier with the small example, 00:33:11.710 --> 00:33:13.850 align:middle line:84% Alice, Bob, and Charlie, it's now-- 00:33:13.850 --> 00:33:18.890 align:middle line:84% this is how it looks like on a really, really large network. 00:33:18.890 --> 00:33:24.230 align:middle line:84% The same algorithm is applied, and these are the results. 00:33:24.230 --> 00:33:29.210 align:middle line:84% So how heavy is the remaining network? 00:33:29.210 --> 00:33:33.410 align:middle line:84% So we see that the weight of the remaining network on average 00:33:33.410 --> 00:33:38.770 align:middle line:84% is around 11% of the initial depth. 00:33:38.770 --> 00:33:45.410 align:middle line:84% So these are the results of monthly clearing over two years. 00:33:45.410 --> 00:33:54.990 align:middle line:84% And, OK, this is a 95% accuracy rate. 00:33:54.990 --> 00:33:59.550 align:middle line:84% And we have some outstanding values, but not much. 00:33:59.550 --> 00:34:03.050 align:middle line:84% So we see that things are pretty stable. 00:34:03.050 --> 00:34:07.730 align:middle line:84% And it's interesting that they are stable even 00:34:07.730 --> 00:34:11.449 align:middle line:90% in this two-year period. 00:34:11.449 --> 00:34:15.610 align:middle line:84% 2019 and 2020, we had the COVID crisis. 00:34:15.610 --> 00:34:17.510 align:middle line:84% And it turns out that COVID crisis, 00:34:17.510 --> 00:34:21.570 align:middle line:84% yes, it decreased the amount of business, 00:34:21.570 --> 00:34:24.310 align:middle line:84% but the structure of the business remained the same. 00:34:24.310 --> 00:34:28.050 align:middle line:84% So the structure is quite stable. 00:34:28.050 --> 00:34:31.690 align:middle line:84% We also see that micro-firms, those little dots 00:34:31.690 --> 00:34:37.730 align:middle line:84% on the edges on the network, do not gain much. 00:34:37.730 --> 00:34:41.250 align:middle line:84% So the major beneficiaries of this 00:34:41.250 --> 00:34:45.929 align:middle line:84% are a bit larger firms, small, medium, and especially 00:34:45.929 --> 00:34:47.690 align:middle line:90% large firms. 00:34:47.690 --> 00:34:51.989 align:middle line:84% The interesting thing is, if you look by the net position, 00:34:51.989 --> 00:34:55.330 align:middle line:84% whether you are debt or net debt or net credit 00:34:55.330 --> 00:34:59.950 align:middle line:84% or we see that the net creditors benefit more. 00:34:59.950 --> 00:35:04.390 align:middle line:84% So actually, the mechanism works from the business point of view. 00:35:04.390 --> 00:35:10.750 align:middle line:84% It works like a accounts receivable collecting service. 00:35:10.750 --> 00:35:11.910 align:middle line:90% So it's very good. 00:35:11.910 --> 00:35:16.810 align:middle line:84% It helps collecting your receivables. 00:35:16.810 --> 00:35:20.950 align:middle line:84% Now the question here is, how do we understand these numbers? 00:35:20.950 --> 00:35:27.370 align:middle line:84% Is this a lot or is this a little? 00:35:27.370 --> 00:35:28.350 align:middle line:90% So it depends. 00:35:28.350 --> 00:35:31.310 align:middle line:84% So when you say 10% to business, it's always significant. 00:35:31.310 --> 00:35:33.350 align:middle line:90% So it's important. 00:35:33.350 --> 00:35:36.210 align:middle line:90% So it's not like we don't care. 00:35:36.210 --> 00:35:39.590 align:middle line:84% But still, it looks a little bit small. 00:35:39.590 --> 00:35:41.750 align:middle line:90% So why just 10%? 00:35:41.750 --> 00:35:45.290 align:middle line:90% Why just that much? 00:35:45.290 --> 00:35:48.570 align:middle line:84% And here at this point, I would just 00:35:48.570 --> 00:35:51.850 align:middle line:84% like to point out some topological features 00:35:51.850 --> 00:35:56.960 align:middle line:84% of the network that actually prevent the mechanism to have 00:35:56.960 --> 00:36:02.280 align:middle line:84% a different result. And this feature 00:36:02.280 --> 00:36:04.865 align:middle line:90% is the scale-free topology. 00:36:04.865 --> 00:36:06.740 align:middle line:84% So I don't know how much you know about this. 00:36:06.740 --> 00:36:09.120 align:middle line:84% I don't want to put a lot of thought 00:36:09.120 --> 00:36:12.040 align:middle line:90% into this, just very roughly. 00:36:12.040 --> 00:36:16.200 align:middle line:84% It is all about power law distributions. 00:36:16.200 --> 00:36:18.720 align:middle line:90% So here, we have-- 00:36:18.720 --> 00:36:23.400 align:middle line:84% this is what economists like, these whisker plots. 00:36:23.400 --> 00:36:28.240 align:middle line:84% We have amounts on the invoices that were issued. 00:36:28.240 --> 00:36:31.800 align:middle line:84% And we see, by the firm size, the amounts 00:36:31.800 --> 00:36:37.440 align:middle line:84% can be as low as 1 euro or in millions of euro, 00:36:37.440 --> 00:36:39.220 align:middle line:90% but millions are outliers. 00:36:39.220 --> 00:36:45.260 align:middle line:84% So the average amount on the invoice is relatively small. 00:36:45.260 --> 00:36:52.100 align:middle line:84% So 183 euros or 332 for large firms. 00:36:52.100 --> 00:36:55.500 align:middle line:84% So the average amounts are very small. 00:36:55.500 --> 00:36:57.500 align:middle line:84% But what is interesting is the distribution. 00:36:57.500 --> 00:36:59.880 align:middle line:84% So this is what network scientists like. 00:36:59.880 --> 00:37:02.200 align:middle line:84% So we have here, on the x-axis, we 00:37:02.200 --> 00:37:06.040 align:middle line:84% have the amounts in a logarithmic scale. 00:37:06.040 --> 00:37:09.040 align:middle line:84% And on the y-axis, we have a probability 00:37:09.040 --> 00:37:12.800 align:middle line:84% of such amount appearing in the sample. 00:37:12.800 --> 00:37:20.540 align:middle line:84% And you can see that the large amounts are very, very unlikely, 00:37:20.540 --> 00:37:23.320 align:middle line:84% but the distribution, the probability distribution 00:37:23.320 --> 00:37:27.200 align:middle line:90% follows the power law. 00:37:27.200 --> 00:37:32.080 align:middle line:84% And you have this typical long-tail distribution. 00:37:32.080 --> 00:37:34.380 align:middle line:84% And the problem with this is the following. 00:37:34.380 --> 00:37:37.720 align:middle line:84% So we have a cycle, Alice, Bob, and Charlie, 00:37:37.720 --> 00:37:42.600 align:middle line:84% but the most likely amount on this cycle, the most likely 00:37:42.600 --> 00:37:46.800 align:middle line:84% amount is somewhere here, something small. 00:37:46.800 --> 00:37:51.750 align:middle line:84% And this basically, then, acts as the kind of a brake 00:37:51.750 --> 00:37:55.990 align:middle line:84% for larger amounts in the clearing. 00:37:55.990 --> 00:37:59.390 align:middle line:90% Interesting thing, this is-- 00:37:59.390 --> 00:38:04.150 align:middle line:84% it's also about how the firm is connected. 00:38:04.150 --> 00:38:08.990 align:middle line:84% So here again, we have a number of business partners 00:38:08.990 --> 00:38:13.190 align:middle line:84% for different firm sizes, micro, small, medium, and large. 00:38:13.190 --> 00:38:14.950 align:middle line:90% And you see that-- 00:38:14.950 --> 00:38:16.070 align:middle line:90% yeah, OK. 00:38:16.070 --> 00:38:20.010 align:middle line:84% Here, it's more diverse than with the amounts, 00:38:20.010 --> 00:38:23.210 align:middle line:84% but when we look at the network science picture, 00:38:23.210 --> 00:38:26.510 align:middle line:84% when we look at the degree distribution, we, 00:38:26.510 --> 00:38:31.390 align:middle line:84% again, see a very, very specific power law 00:38:31.390 --> 00:38:34.670 align:middle line:84% distribution of the probabilities 00:38:34.670 --> 00:38:37.670 align:middle line:90% how many partners a firm has. 00:38:37.670 --> 00:38:40.070 align:middle line:84% And this is, again, working as a brake 00:38:40.070 --> 00:38:47.910 align:middle line:84% because it is highly likely that a firm in a cycle 00:38:47.910 --> 00:38:50.170 align:middle line:84% will have only a few connections, 00:38:50.170 --> 00:38:53.790 align:middle line:84% and this is basically constraining the amount of flow 00:38:53.790 --> 00:38:57.350 align:middle line:90% that can go through this node. 00:38:57.350 --> 00:39:04.170 align:middle line:84% So this is why we somehow cannot go above this 10%, 11%, 00:39:04.170 --> 00:39:06.930 align:middle line:90% 12% in the network. 00:39:06.930 --> 00:39:11.510 align:middle line:84% So it's a purely topological stuff. 00:39:11.510 --> 00:39:13.610 align:middle line:90% OK, any questions on this? 00:39:13.610 --> 00:39:16.760 align:middle line:90% 00:39:16.760 --> 00:39:20.810 align:middle line:84% AUDIENCE: So the fact that this is a power law is coming from-- 00:39:20.810 --> 00:39:22.313 align:middle line:90% do we know why? 00:39:22.313 --> 00:39:23.230 align:middle line:90% TOMAŽ FLEISCHMAN: Yes. 00:39:23.230 --> 00:39:25.910 align:middle line:90% It's coming from nature. 00:39:25.910 --> 00:39:27.710 align:middle line:90% It's life. 00:39:27.710 --> 00:39:31.750 align:middle line:84% So the mechanism that drives this 00:39:31.750 --> 00:39:38.190 align:middle line:84% is preferential attachment rule that says when something grows, 00:39:38.190 --> 00:39:40.670 align:middle line:90% a network grow. 00:39:40.670 --> 00:39:43.370 align:middle line:84% When something new comes to the network, 00:39:43.370 --> 00:39:48.140 align:middle line:84% it is more likely to connect to already existing strong player 00:39:48.140 --> 00:39:50.920 align:middle line:90% than the one on the fringes. 00:39:50.920 --> 00:39:54.822 align:middle line:84% AUDIENCE: So any growth process that has this feature-- 00:39:54.822 --> 00:39:55.780 align:middle line:90% TOMAŽ FLEISCHMAN: Yeah. 00:39:55.780 --> 00:39:57.800 align:middle line:90% I sometimes play with this. 00:39:57.800 --> 00:40:01.760 align:middle line:84% So I have a nice slide, I didn't include it here. 00:40:01.760 --> 00:40:09.540 align:middle line:84% I have a network of village community economy in Kenya 00:40:09.540 --> 00:40:13.500 align:middle line:84% and protein interaction in yeast. 00:40:13.500 --> 00:40:16.080 align:middle line:84% And then I ask which one is which, 00:40:16.080 --> 00:40:20.440 align:middle line:84% and nobody knows, because it's the same mechanism. 00:40:20.440 --> 00:40:25.420 align:middle line:90% So it goes really from nature. 00:40:25.420 --> 00:40:27.900 align:middle line:84% But we need to do something about it. 00:40:27.900 --> 00:40:31.120 align:middle line:84% So we cannot just say, OK, this is how it is, let's do nothing. 00:40:31.120 --> 00:40:33.340 align:middle line:84% So it doesn't work like this, and this 00:40:33.340 --> 00:40:38.020 align:middle line:84% is how we arrive to liquidity injection. 00:40:38.020 --> 00:40:43.520 align:middle line:84% So yeah, OK, we need to fight the forces, 00:40:43.520 --> 00:40:47.260 align:middle line:84% we need to fight the topology, and we do this 00:40:47.260 --> 00:40:56.620 align:middle line:84% by introducing engineered obligations because liquidity 00:40:56.620 --> 00:41:00.540 align:middle line:90% is something we made up. 00:41:00.540 --> 00:41:03.320 align:middle line:84% And let's start with Alice, Bob, and Charlie, 00:41:03.320 --> 00:41:05.060 align:middle line:90% my favorite players. 00:41:05.060 --> 00:41:11.900 align:middle line:84% So now they have a new player, an engineered node. 00:41:11.900 --> 00:41:14.360 align:middle line:90% It's not a firm, it's a concept. 00:41:14.360 --> 00:41:16.100 align:middle line:90% It can be a bank. 00:41:16.100 --> 00:41:18.100 align:middle line:90% It can be something else. 00:41:18.100 --> 00:41:22.700 align:middle line:84% Mutual credit, crypto, whatever you want. 00:41:22.700 --> 00:41:26.260 align:middle line:90% The point is, it's engineered. 00:41:26.260 --> 00:41:29.260 align:middle line:84% So we have this Alice, Bob, and Charlie cycle. 00:41:29.260 --> 00:41:35.100 align:middle line:84% And Alice, she is in a possession of something 00:41:35.100 --> 00:41:36.480 align:middle line:90% that is accepted. 00:41:36.480 --> 00:41:40.540 align:middle line:84% So Charlie is happy to say, I rather 00:41:40.540 --> 00:41:43.530 align:middle line:90% have two of those than nothing. 00:41:43.530 --> 00:41:47.650 align:middle line:84% So this is what the dashed line means. 00:41:47.650 --> 00:41:52.650 align:middle line:84% And the full line means I have it. 00:41:52.650 --> 00:41:55.890 align:middle line:84% And the whole use of the algorithm 00:41:55.890 --> 00:42:00.130 align:middle line:84% of the MTCS on such an enhanced network where we introduce-- 00:42:00.130 --> 00:42:02.690 align:middle line:84% where we engineer the liquidity into the network 00:42:02.690 --> 00:42:04.730 align:middle line:90% is the same as before. 00:42:04.730 --> 00:42:10.250 align:middle line:84% So we include source and target, and we are looking 00:42:10.250 --> 00:42:15.690 align:middle line:90% for the saturating s-t flow. 00:42:15.690 --> 00:42:21.090 align:middle line:84% When we remove the saturating flow, this is the solution. 00:42:21.090 --> 00:42:25.410 align:middle line:84% And what does this solution mean? 00:42:25.410 --> 00:42:31.650 align:middle line:84% So it means that Alice was able to pay-- 00:42:31.650 --> 00:42:36.250 align:middle line:84% or resolve the debt of 2 with Bob, Bob resolved a debt of 2 00:42:36.250 --> 00:42:38.530 align:middle line:90% with Charlie. 00:42:38.530 --> 00:42:44.170 align:middle line:84% Alice used her 1 of whatever the money was. 00:42:44.170 --> 00:42:48.570 align:middle line:90% Charlie stored 1. 00:42:48.570 --> 00:42:52.530 align:middle line:84% Charlie doesn't owe anything to Alice anymore because it's 1. 00:42:52.530 --> 00:42:55.530 align:middle line:84% And everything that remains of this network 00:42:55.530 --> 00:43:02.930 align:middle line:84% would be, if you look at here, 1-- 00:43:02.930 --> 00:43:05.610 align:middle line:90% Bob still owes 1 to Charlie. 00:43:05.610 --> 00:43:08.450 align:middle line:84% And because this is it, Charlie was 00:43:08.450 --> 00:43:13.230 align:middle line:84% unable to store 2 units on this new liquidity source, 00:43:13.230 --> 00:43:18.450 align:middle line:84% but just 1 because there was not enough liquidity engineered 00:43:18.450 --> 00:43:22.570 align:middle line:84% in the system to clear everything. 00:43:22.570 --> 00:43:25.350 align:middle line:90% Any question on this concept? 00:43:25.350 --> 00:43:25.850 align:middle line:90% No? 00:43:25.850 --> 00:43:28.930 align:middle line:90% 00:43:28.930 --> 00:43:31.770 align:middle line:90% OK. 00:43:31.770 --> 00:43:34.170 align:middle line:84% So how does it work if there is more 00:43:34.170 --> 00:43:35.630 align:middle line:90% than Alice, Bob, and charlie? 00:43:35.630 --> 00:43:37.250 align:middle line:90% So the same as before. 00:43:37.250 --> 00:43:38.270 align:middle line:90% We've seen this picture. 00:43:38.270 --> 00:43:46.330 align:middle line:84% So we just say source and target can be joined, 00:43:46.330 --> 00:43:51.850 align:middle line:84% and they represent the new engineered source of liquidity. 00:43:51.850 --> 00:43:55.770 align:middle line:84% And we did experiments on this by not 00:43:55.770 --> 00:43:57.790 align:middle line:90% providing enough liquidity. 00:43:57.790 --> 00:44:01.290 align:middle line:84% But because the sample is large-- 00:44:01.290 --> 00:44:03.990 align:middle line:84% and I didn't want to complicate stuff, 00:44:03.990 --> 00:44:09.130 align:middle line:84% we said that everyone has the same restriction 00:44:09.130 --> 00:44:10.310 align:middle line:90% in the liquidity. 00:44:10.310 --> 00:44:14.290 align:middle line:84% So I either have nothing or I have 1% or 2% 00:44:14.290 --> 00:44:21.770 align:middle line:84% or I have 100% of whatever I owe as my engineered liquidity. 00:44:21.770 --> 00:44:27.530 align:middle line:84% And we set this parameter how much? 00:44:27.530 --> 00:44:31.870 align:middle line:84% we set it as a gamma, so in an interval from 0 to 1. 00:44:31.870 --> 00:44:35.930 align:middle line:84% So this is how the experiment is set up 00:44:35.930 --> 00:44:40.040 align:middle line:84% to show the effects of liquidity injection. 00:44:40.040 --> 00:44:43.360 align:middle line:90% And these are the results. 00:44:43.360 --> 00:44:49.460 align:middle line:84% So, here on this graph, we have-- on x-axis, we have gamma. 00:44:49.460 --> 00:44:56.160 align:middle line:84% So how much of the indebtedness was created in the-- 00:44:56.160 --> 00:44:58.760 align:middle line:84% engineered in the liquidity source? 00:44:58.760 --> 00:45:02.600 align:middle line:84% And here on the y-axis, we have how much debt in the network 00:45:02.600 --> 00:45:04.080 align:middle line:90% was actually cleared. 00:45:04.080 --> 00:45:08.360 align:middle line:84% And we see, at 0 gamma, we already start somewhere. 00:45:08.360 --> 00:45:14.840 align:middle line:84% It's not at 0 because we have these cycles with no liquidity 00:45:14.840 --> 00:45:15.760 align:middle line:90% clearing. 00:45:15.760 --> 00:45:21.480 align:middle line:84% But then as the gamma increases, it first starts quite steep, 00:45:21.480 --> 00:45:26.640 align:middle line:84% and then it goes like 45 degrees, and at the end, 00:45:26.640 --> 00:45:30.660 align:middle line:84% the efficiency of adding more liquidity is not so obvious, 00:45:30.660 --> 00:45:36.880 align:middle line:84% but when you provide everything, you also clear everything. 00:45:36.880 --> 00:45:39.420 align:middle line:84% But the results in the middle are quite interesting. 00:45:39.420 --> 00:45:43.980 align:middle line:84% So for example, if you engineer 20% of required liquidity, 00:45:43.980 --> 00:45:47.580 align:middle line:84% but you clear close to 50% of all indebtedness. 00:45:47.580 --> 00:45:51.000 align:middle line:84% So there are huge network multipliers effect. 00:45:51.000 --> 00:45:54.540 align:middle line:84% And this line, it looks like a line, it's not really a line. 00:45:54.540 --> 00:46:07.280 align:middle line:84% These are 12 months combined in a 95% confidence interval, 00:46:07.280 --> 00:46:10.000 align:middle line:84% and this just shows that the structure 00:46:10.000 --> 00:46:12.920 align:middle line:84% of this real-life network that we observe 00:46:12.920 --> 00:46:15.720 align:middle line:84% is really stable even from the point of view 00:46:15.720 --> 00:46:20.000 align:middle line:90% of liquidity injection. 00:46:20.000 --> 00:46:23.480 align:middle line:84% Here on the right side, you have the same line, just 00:46:23.480 --> 00:46:28.080 align:middle line:84% broken down to the sizes of the firms 00:46:28.080 --> 00:46:33.720 align:middle line:84% where you see that small firms are really dependent on-- 00:46:33.720 --> 00:46:37.950 align:middle line:84% or micro firms are really dependent on the liquidity that 00:46:37.950 --> 00:46:44.430 align:middle line:84% is engineered into the system, while larger firms benefit 00:46:44.430 --> 00:46:48.270 align:middle line:84% from this kind of stuff even more. 00:46:48.270 --> 00:46:50.370 align:middle line:84% Let's go back to where we started. 00:46:50.370 --> 00:46:53.450 align:middle line:84% So how does this reflect into the late payment? 00:46:53.450 --> 00:46:57.710 align:middle line:84% So we started with the late payment as a problem. 00:46:57.710 --> 00:47:02.630 align:middle line:84% So the red line here, late payment. 00:47:02.630 --> 00:47:05.590 align:middle line:84% So depending on how much liquidity 00:47:05.590 --> 00:47:09.430 align:middle line:84% we engineered into the system, at the beginning, 00:47:09.430 --> 00:47:13.070 align:middle line:84% if the assumption is everything that was reported 00:47:13.070 --> 00:47:20.990 align:middle line:84% is late, you decrease the late payment a little bit, but as 00:47:20.990 --> 00:47:25.930 align:middle line:84% much as you increase the involvement of the liquidity, 00:47:25.930 --> 00:47:30.310 align:middle line:84% the late payment as a problem drops significantly. 00:47:30.310 --> 00:47:34.030 align:middle line:90% And here are the contributions. 00:47:34.030 --> 00:47:38.830 align:middle line:84% So the blue line is how much liquidity 00:47:38.830 --> 00:47:42.310 align:middle line:84% was cleared in several steps through the network. 00:47:42.310 --> 00:47:48.630 align:middle line:84% So it went from Alice to Bob to Charlie to Dave and so forth. 00:47:48.630 --> 00:47:52.790 align:middle line:84% And the green line is the use of liquidity 00:47:52.790 --> 00:47:55.030 align:middle line:90% where only one hop was done. 00:47:55.030 --> 00:47:59.270 align:middle line:84% It just went from Alice to Bob and that's it. 00:47:59.270 --> 00:48:03.470 align:middle line:84% It's just the breakdown of the network effects. 00:48:03.470 --> 00:48:11.090 align:middle line:84% Now, if we try to measure the value added of the mechanism, 00:48:11.090 --> 00:48:18.230 align:middle line:84% you see that it is clearly a mechanism when 00:48:18.230 --> 00:48:20.670 align:middle line:90% there is some kind of crisis. 00:48:20.670 --> 00:48:26.310 align:middle line:84% So when liquidity is short, the use of this mechanism 00:48:26.310 --> 00:48:30.010 align:middle line:90% produces the biggest effect. 00:48:30.010 --> 00:48:32.980 align:middle line:84% And we have seen this in the case of Slovenia, 00:48:32.980 --> 00:48:36.460 align:middle line:84% in the war economy, and then the COVID crisis. 00:48:36.460 --> 00:48:41.260 align:middle line:84% But then you can apply this differently. 00:48:41.260 --> 00:48:45.120 align:middle line:84% There are regions that are liquidity constraints. 00:48:45.120 --> 00:48:47.720 align:middle line:84% Everything is fine in the economy, but you have regions. 00:48:47.720 --> 00:48:52.940 align:middle line:84% And so it makes sense to apply these kind of mechanisms 00:48:52.940 --> 00:48:55.700 align:middle line:90% in places where liquidity-- 00:48:55.700 --> 00:48:59.560 align:middle line:84% or general economic situation is bad 00:48:59.560 --> 00:49:04.860 align:middle line:84% and you want to do something to kickstart the stuff. 00:49:04.860 --> 00:49:06.440 align:middle line:90% Any questions on this point? 00:49:06.440 --> 00:49:11.660 align:middle line:90% 00:49:11.660 --> 00:49:16.200 align:middle line:84% So why is it important to observe this kind of stuff? 00:49:16.200 --> 00:49:25.080 align:middle line:84% So the whole economic life is about transactions. 00:49:25.080 --> 00:49:27.380 align:middle line:90% So we transact. 00:49:27.380 --> 00:49:32.580 align:middle line:84% So what we are observing here is to collaborate on 00:49:32.580 --> 00:49:39.060 align:middle line:84% how do we resolve the economic situation by collaboration. 00:49:39.060 --> 00:49:42.060 align:middle line:90% And we can go far if we want. 00:49:42.060 --> 00:49:46.960 align:middle line:84% So here, I'm showing a concept, but it's made on the real data. 00:49:46.960 --> 00:49:53.260 align:middle line:84% So this is made on a data from the Italian community 00:49:53.260 --> 00:49:57.300 align:middle line:90% from Sardex from Sardinia. 00:49:57.300 --> 00:50:00.300 align:middle line:90% They call the system-- 00:50:00.300 --> 00:50:03.040 align:middle line:84% they have a system of a mutual credit called Sardex, 00:50:03.040 --> 00:50:05.740 align:middle line:90% and I made this on their data. 00:50:05.740 --> 00:50:10.600 align:middle line:84% So what we have here is the real obligations between the firms. 00:50:10.600 --> 00:50:14.140 align:middle line:90% So the firms are all these dots. 00:50:14.140 --> 00:50:18.020 align:middle line:84% And we engineered three different liquidity source, not 00:50:18.020 --> 00:50:18.780 align:middle line:90% one. 00:50:18.780 --> 00:50:21.220 align:middle line:90% Why just one? 00:50:21.220 --> 00:50:22.720 align:middle line:90% They can be different. 00:50:22.720 --> 00:50:28.180 align:middle line:84% And in a real-life example, this could be bank deposits, 00:50:28.180 --> 00:50:32.920 align:middle line:84% it could be mutual credit, it could be cryptocurrency, 00:50:32.920 --> 00:50:35.340 align:middle line:90% it could be many other things. 00:50:35.340 --> 00:50:38.220 align:middle line:90% Vouchers, for example. 00:50:38.220 --> 00:50:44.380 align:middle line:84% Whatever are people willing to accept to discharge 00:50:44.380 --> 00:50:47.340 align:middle line:90% the indebtedness works. 00:50:47.340 --> 00:50:52.180 align:middle line:84% And the interesting thing, is when you combine these liquidity 00:50:52.180 --> 00:51:01.220 align:middle line:84% sources, you are increasing the amount of debt resolved, 00:51:01.220 --> 00:51:07.360 align:middle line:84% but even more interesting result is because of the-- 00:51:07.360 --> 00:51:12.920 align:middle line:84% because algorithm follows the flow conservation principle 00:51:12.920 --> 00:51:16.260 align:middle line:84% and follows the principle of balance, 00:51:16.260 --> 00:51:21.780 align:middle line:84% there is no flow from one liquidity source to another. 00:51:21.780 --> 00:51:26.570 align:middle line:84% So basically, you can have a really different types 00:51:26.570 --> 00:51:29.870 align:middle line:84% of liquidity, but they will not influence each other. 00:51:29.870 --> 00:51:34.610 align:middle line:84% So there is no exchange from Bitcoin 00:51:34.610 --> 00:51:39.150 align:middle line:84% to dollar to mutual credit, something like that. 00:51:39.150 --> 00:51:39.650 align:middle line:90% Yeah? 00:51:39.650 --> 00:51:41.870 align:middle line:84% AUDIENCE: Doesn't that make it less efficient? 00:51:41.870 --> 00:51:44.530 align:middle line:84% It feels like if you have different types of liquidity 00:51:44.530 --> 00:51:47.430 align:middle line:84% that you cannot-- that aren't exchangeable with each other, 00:51:47.430 --> 00:51:50.615 align:middle line:84% it seems like it will be more costly to resolve-- 00:51:50.615 --> 00:51:51.490 align:middle line:90% TOMAŽ FLEISCHMAN: No. 00:51:51.490 --> 00:51:53.450 align:middle line:84% It resolves more cycles because what 00:51:53.450 --> 00:52:00.810 align:middle line:84% happens is, you have a flow that goes from here to here to there 00:52:00.810 --> 00:52:04.210 align:middle line:84% and back, but there is no exchange. 00:52:04.210 --> 00:52:06.370 align:middle line:90% There is no trade. 00:52:06.370 --> 00:52:11.410 align:middle line:84% The interaction happens based on the obligations 00:52:11.410 --> 00:52:12.590 align:middle line:90% within the network. 00:52:12.590 --> 00:52:16.130 align:middle line:90% 00:52:16.130 --> 00:52:19.150 align:middle line:84% Exchange without the trade, this is a tough one, 00:52:19.150 --> 00:52:22.630 align:middle line:84% but we are actually working on this. 00:52:22.630 --> 00:52:26.530 align:middle line:84% So it's a new look on this stuff. 00:52:26.530 --> 00:52:29.930 align:middle line:84% AUDIENCE: Like one Bitcoin goes out of there, 00:52:29.930 --> 00:52:33.530 align:middle line:84% and then how does it go into-- how does it turn into $1? 00:52:33.530 --> 00:52:36.870 align:middle line:84% TOMAŽ FLEISCHMAN: It's a flow conservation principle. 00:52:36.870 --> 00:52:39.670 align:middle line:84% Bitcoin is a Bitcoin, it goes nowhere. 00:52:39.670 --> 00:52:41.650 align:middle line:90% It's always here. 00:52:41.650 --> 00:52:44.850 align:middle line:84% Because all the outflows equal inflows. 00:52:44.850 --> 00:52:47.610 align:middle line:84% Bitcoin is a Bitcoin, it stays here. 00:52:47.610 --> 00:52:48.370 align:middle line:90% AUDIENCE: Right. 00:52:48.370 --> 00:52:51.650 align:middle line:84% TOMAŽ FLEISCHMAN: Bank deposit is a bank deposit. 00:52:51.650 --> 00:52:52.790 align:middle line:90% But this is a bank. 00:52:52.790 --> 00:52:56.130 align:middle line:84% So let's say these are all banks. 00:52:56.130 --> 00:52:57.430 align:middle line:90% These are all banks. 00:52:57.430 --> 00:53:00.490 align:middle line:90% 00:53:00.490 --> 00:53:04.190 align:middle line:84% Dollar on your bank is not the same as dollar on my bank. 00:53:04.190 --> 00:53:09.410 align:middle line:90% 00:53:09.410 --> 00:53:13.310 align:middle line:84% Dollar on your bank account, it stays within the bank, 00:53:13.310 --> 00:53:14.970 align:middle line:90% it goes nowhere. 00:53:14.970 --> 00:53:15.690 align:middle line:90% AUDIENCE: Sure. 00:53:15.690 --> 00:53:16.648 align:middle line:90% TOMAŽ FLEISCHMAN: Yeah. 00:53:16.648 --> 00:53:18.090 align:middle line:84% AUDIENCE: But it will be-- will it 00:53:18.090 --> 00:53:21.960 align:middle line:84% be more efficient if banks can clear among the banks? 00:53:21.960 --> 00:53:24.640 align:middle line:90% 00:53:24.640 --> 00:53:27.440 align:middle line:90% TOMAŽ FLEISCHMAN: Yes. 00:53:27.440 --> 00:53:29.800 align:middle line:84% AUDIENCE: So it will be more efficient here 00:53:29.800 --> 00:53:35.300 align:middle line:84% if there are additional exchange over different kind of asset? 00:53:35.300 --> 00:53:37.960 align:middle line:90% 00:53:37.960 --> 00:53:40.300 align:middle line:84% TOMAŽ FLEISCHMAN: So when you introduce-- 00:53:40.300 --> 00:53:44.680 align:middle line:90% so this is kind of a bias. 00:53:44.680 --> 00:53:50.600 align:middle line:84% So all economy is based on the idea, markets are everything. 00:53:50.600 --> 00:53:54.540 align:middle line:84% So what we see here is the exact opposite. 00:53:54.540 --> 00:53:57.120 align:middle line:90% Collaboration is everything. 00:53:57.120 --> 00:54:00.320 align:middle line:84% So for all practical reasons, none of this system 00:54:00.320 --> 00:54:03.160 align:middle line:90% is good by itself. 00:54:03.160 --> 00:54:09.040 align:middle line:84% So the message is, why not take the best from both worlds? 00:54:09.040 --> 00:54:11.780 align:middle line:84% There is no need to compete for everything, 00:54:11.780 --> 00:54:16.560 align:middle line:84% and there is no way to arrange some kind of dream system 00:54:16.560 --> 00:54:20.920 align:middle line:84% where collaboration resolves everything. 00:54:20.920 --> 00:54:27.680 align:middle line:84% But certain amount of collaboration helps. 00:54:27.680 --> 00:54:31.340 align:middle line:84% And this kind of system, this is a very neutral system. 00:54:31.340 --> 00:54:34.200 align:middle line:90% It doesn't actually break-- 00:54:34.200 --> 00:54:36.380 align:middle line:84% it doesn't interfere with the competition. 00:54:36.380 --> 00:54:39.200 align:middle line:84% It doesn't interfere with the market. 00:54:39.200 --> 00:54:45.300 align:middle line:84% But it introduces wider possibilities for coordination. 00:54:45.300 --> 00:54:48.200 align:middle line:90% 00:54:48.200 --> 00:54:51.920 align:middle line:84% So this is why it's important to study this kind of stuff, 00:54:51.920 --> 00:54:54.960 align:middle line:84% and to see where we could implement it. 00:54:54.960 --> 00:54:57.460 align:middle line:84% So the class is about the blockchain, 00:54:57.460 --> 00:54:59.860 align:middle line:84% so I'm coming from Informal Systems. 00:54:59.860 --> 00:55:01.380 align:middle line:90% We are a blockchain company. 00:55:01.380 --> 00:55:03.420 align:middle line:90% We are starting a new company. 00:55:03.420 --> 00:55:05.900 align:middle line:84% Now it will be called Cycles Protocol, 00:55:05.900 --> 00:55:11.400 align:middle line:84% and what we will deliver in next few months 00:55:11.400 --> 00:55:15.920 align:middle line:90% is something based on this idea. 00:55:15.920 --> 00:55:22.070 align:middle line:84% Let's use blockchain as a single source of truth 00:55:22.070 --> 00:55:24.370 align:middle line:90% to create the networks. 00:55:24.370 --> 00:55:27.990 align:middle line:84% So the users, firms, individuals, 00:55:27.990 --> 00:55:30.390 align:middle line:90% they will encrypt their-- 00:55:30.390 --> 00:55:31.930 align:middle line:90% we call this intents. 00:55:31.930 --> 00:55:37.150 align:middle line:84% So I want to pay someone, so we have an agreement that there 00:55:37.150 --> 00:55:38.850 align:middle line:90% is a debt between two of them. 00:55:38.850 --> 00:55:40.050 align:middle line:90% So these are the intents. 00:55:40.050 --> 00:55:44.350 align:middle line:90% So this goes encrypted on chain. 00:55:44.350 --> 00:55:47.550 align:middle line:84% Then these intents, encrypted, go 00:55:47.550 --> 00:55:54.030 align:middle line:84% to something we call a solver where they get decrypted, solved 00:55:54.030 --> 00:55:57.830 align:middle line:84% with the algorithm we looked just now, 00:55:57.830 --> 00:56:02.330 align:middle line:84% they are encrypted again and written back on chain. 00:56:02.330 --> 00:56:08.390 align:middle line:84% So we put together with the encrypted message, 00:56:08.390 --> 00:56:13.830 align:middle line:84% we include the attestation and the zero-knowledge proof 00:56:13.830 --> 00:56:18.110 align:middle line:84% that the MTCS process was done as it should be. 00:56:18.110 --> 00:56:24.350 align:middle line:84% Verifiers can check this and write the results on chain, 00:56:24.350 --> 00:56:29.670 align:middle line:84% and this then enables the users to read the status 00:56:29.670 --> 00:56:31.010 align:middle line:90% from the chain. 00:56:31.010 --> 00:56:35.390 align:middle line:84% So the whole design is fully privacy-preserving. 00:56:35.390 --> 00:56:40.550 align:middle line:84% And this is exactly to the point to enable collaboration 00:56:40.550 --> 00:56:43.270 align:middle line:84% within the competitive environment. 00:56:43.270 --> 00:56:47.310 align:middle line:84% So you don't want to expose the network to the market 00:56:47.310 --> 00:56:51.790 align:middle line:84% because knowledge of the network is power, 00:56:51.790 --> 00:56:57.870 align:middle line:84% but we want to have a network to be more efficient in resolving 00:56:57.870 --> 00:56:58.890 align:middle line:90% the indebtedness. 00:56:58.890 --> 00:57:04.690 align:middle line:84% So this is the next steps or where does this lead to. 00:57:04.690 --> 00:57:07.790 align:middle line:90% 00:57:07.790 --> 00:57:13.190 align:middle line:84% So anyway, I hope you will find this interesting, 00:57:13.190 --> 00:57:16.230 align:middle line:84% and I'm just inviting you to follow us 00:57:16.230 --> 00:57:20.310 align:middle line:84% because we will deliver this stuff very 00:57:20.310 --> 00:57:24.470 align:middle line:90% soon in various forms. 00:57:24.470 --> 00:57:26.810 align:middle line:90% So thank you very much. 00:57:26.810 --> 00:57:28.872 align:middle line:84% PROFESSOR: Do we have time for discussion? 00:57:28.872 --> 00:57:29.830 align:middle line:90% TOMAŽ FLEISCHMAN: Sure! 00:57:29.830 --> 00:57:32.990 align:middle line:90% 00:57:32.990 --> 00:57:35.590 align:middle line:84% AUDIENCE: I mean, I guess how new is this whole thing 00:57:35.590 --> 00:57:37.470 align:middle line:90% for the startup? 00:57:37.470 --> 00:57:39.213 align:middle line:84% Like, how new is like this technology? 00:57:39.213 --> 00:57:40.630 align:middle line:84% TOMAŽ FLEISCHMAN: This technology? 00:57:40.630 --> 00:57:44.230 align:middle line:84% So in terms of privacy-preserving, 00:57:44.230 --> 00:57:45.950 align:middle line:90% it's brand new. 00:57:45.950 --> 00:57:52.710 align:middle line:84% Because what is used right now for Zcash, for example, 00:57:52.710 --> 00:57:58.710 align:middle line:84% is not useful for what we do because we need this-- 00:57:58.710 --> 00:58:01.910 align:middle line:84% so the encoding has to be done in a way where 00:58:01.910 --> 00:58:05.050 align:middle line:84% multiple parties have access to data, 00:58:05.050 --> 00:58:09.370 align:middle line:84% which is not what is normal for the shielded pools design. 00:58:09.370 --> 00:58:12.980 align:middle line:90% So this will be very new. 00:58:12.980 --> 00:58:16.820 align:middle line:84% When it comes to the idea, let's clear. 00:58:16.820 --> 00:58:19.880 align:middle line:84% It's somewhere in the European renaissance. 00:58:19.880 --> 00:58:23.620 align:middle line:84% So the first documented clearings-- 00:58:23.620 --> 00:58:25.620 align:middle line:84% collaborative clearings within the groups 00:58:25.620 --> 00:58:32.080 align:middle line:84% are from ancient merchant fairs where it worked like this. 00:58:32.080 --> 00:58:36.000 align:middle line:84% So you would go to a fair with your stuff, whatever-- rugs, 00:58:36.000 --> 00:58:38.300 align:middle line:90% for example. 00:58:38.300 --> 00:58:41.740 align:middle line:90% And you would trade there. 00:58:41.740 --> 00:58:43.000 align:middle line:90% And then you would go back. 00:58:43.000 --> 00:58:45.800 align:middle line:84% But travel to the fair and back, you go through forests, 00:58:45.800 --> 00:58:50.840 align:middle line:84% so having cash, gold coins would be a very bad idea. 00:58:50.840 --> 00:58:52.380 align:middle line:90% So they didn't do this. 00:58:52.380 --> 00:58:53.520 align:middle line:90% So how did it work? 00:58:53.520 --> 00:59:01.340 align:middle line:84% So you go to a fair, you trade, you write notes 00:59:01.340 --> 00:59:03.780 align:middle line:90% to other merchants. 00:59:03.780 --> 00:59:08.300 align:middle line:84% And at the end of the trading, there was a banking fair, 00:59:08.300 --> 00:59:12.380 align:middle line:84% and banking fair would last for two days. 00:59:12.380 --> 00:59:15.660 align:middle line:84% And it was actually a choreography. 00:59:15.660 --> 00:59:20.000 align:middle line:90% So merchants were invited. 00:59:20.000 --> 00:59:22.500 align:middle line:84% And then they said, let's commence. 00:59:22.500 --> 00:59:24.480 align:middle line:90% And I owe you-- 00:59:24.480 --> 00:59:30.740 align:middle line:84% I would hold your left shoulder with my right arm, 00:59:30.740 --> 00:59:35.760 align:middle line:84% and we go like this together until you find someone. 00:59:35.760 --> 00:59:39.020 align:middle line:84% And when we are holding a cycle-- oh. 00:59:39.020 --> 00:59:45.200 align:middle line:84% Then we go, sit at the table, put our notes down, reduce, 00:59:45.200 --> 00:59:46.700 align:middle line:90% write new ones. 00:59:46.700 --> 00:59:50.740 align:middle line:84% And this choreography would last like for two days. 00:59:50.740 --> 00:59:54.400 align:middle line:84% And you go home with just new credit notes. 00:59:54.400 --> 00:59:56.380 align:middle line:90% No money. 00:59:56.380 --> 00:59:57.980 align:middle line:90% And then this was-- 00:59:57.980 --> 01:00:01.460 align:middle line:84% in the banking world, the most known example 01:00:01.460 --> 01:00:07.100 align:middle line:84% is our English banking clearing clubs. 01:00:07.100 --> 01:00:10.970 align:middle line:84% And just-- there is a funny anecdote. 01:00:10.970 --> 01:00:14.250 align:middle line:84% A letter from one of the banker explaining 01:00:14.250 --> 01:00:16.270 align:middle line:84% how he is going to these kind of clubs. 01:00:16.270 --> 01:00:18.210 align:middle line:90% He said, oh, it's good. 01:00:18.210 --> 01:00:22.050 align:middle line:84% I only take enough money for food and women, 01:00:22.050 --> 01:00:24.110 align:middle line:90% everything else gets cleared. 01:00:24.110 --> 01:00:27.210 align:middle line:90% So this is-- 01:00:27.210 --> 01:00:34.970 align:middle line:84% So it's an old-- it's ancient, ancient method that we 01:00:34.970 --> 01:00:38.570 align:middle line:84% stopped using because it's difficult to implement. 01:00:38.570 --> 01:00:42.750 align:middle line:84% So you cannot have a choreography here in Boston, 01:00:42.750 --> 01:00:43.350 align:middle line:90% for example. 01:00:43.350 --> 01:00:45.490 align:middle line:90% So how would this look like? 01:00:45.490 --> 01:00:49.650 align:middle line:84% But with privacy-preserving blockchain technology, 01:00:49.650 --> 01:00:52.390 align:middle line:84% we can revive this stuff, and it's very useful. 01:00:52.390 --> 01:00:56.812 align:middle line:90% 01:00:56.812 --> 01:01:01.290 align:middle line:84% PROFESSOR: So maybe-- can go back to the liquidity thing? 01:01:01.290 --> 01:01:01.930 align:middle line:90% Because-- 01:01:01.930 --> 01:01:03.370 align:middle line:90% TOMAŽ FLEISCHMAN: Yeah. 01:01:03.370 --> 01:01:07.790 align:middle line:84% PROFESSOR: We've done more work than you had time to present. 01:01:07.790 --> 01:01:12.650 align:middle line:84% So let me just say that the one way the engineering works 01:01:12.650 --> 01:01:18.530 align:middle line:84% is to solicit from the individual participants 01:01:18.530 --> 01:01:21.128 align:middle line:84% liquidity that they're willing to put in escrow. 01:01:21.128 --> 01:01:22.170 align:middle line:90% TOMAŽ FLEISCHMAN: Mm-hmm. 01:01:22.170 --> 01:01:23.587 align:middle line:84% PROFESSOR: Once it's in escrow, it 01:01:23.587 --> 01:01:25.270 align:middle line:90% can be used to clear the system. 01:01:25.270 --> 01:01:32.850 align:middle line:84% So Alice was the one who was in a net debtor position, 01:01:32.850 --> 01:01:34.830 align:middle line:84% so she owes the money, and she could say, 01:01:34.830 --> 01:01:39.050 align:middle line:84% I'm willing to contribute a quarter or maybe even 01:01:39.050 --> 01:01:45.650 align:middle line:84% half of the money in advance to clear my own debt. 01:01:45.650 --> 01:01:48.610 align:middle line:84% And so all the net debtor nodes are 01:01:48.610 --> 01:01:51.190 align:middle line:84% contributing a certain fraction of the net debt. 01:01:51.190 --> 01:01:54.070 align:middle line:84% That's what the gamma was in that slide. 01:01:54.070 --> 01:01:57.210 align:middle line:90% 01:01:57.210 --> 01:02:02.650 align:middle line:84% And initially-- and that's what you were presenting, 01:02:02.650 --> 01:02:04.170 align:middle line:90% it's obligatory-- 01:02:04.170 --> 01:02:07.840 align:middle line:84% I mean, we're running an experiment from gamma 01:02:07.840 --> 01:02:10.800 align:middle line:90% equals 0 to gamma equal to 1. 01:02:10.800 --> 01:02:14.240 align:middle line:84% When gamma is equal to 1, there's no network effect 01:02:14.240 --> 01:02:16.640 align:middle line:84% because they've all contributed enough liquidity 01:02:16.640 --> 01:02:19.920 align:middle line:90% to pay their own debts. 01:02:19.920 --> 01:02:22.580 align:middle line:84% And when there's 0, then nothing is happening. 01:02:22.580 --> 01:02:24.960 align:middle line:84% So something in between is what Tomaž 01:02:24.960 --> 01:02:27.940 align:middle line:84% is showing where we get, especially initially, 01:02:27.940 --> 01:02:31.760 align:middle line:90% you get a very big multiplier. 01:02:31.760 --> 01:02:34.520 align:middle line:84% TOMAŽ FLEISCHMAN: Yeah, but in real life, 01:02:34.520 --> 01:02:36.920 align:middle line:84% it's always somewhere in the middle. 01:02:36.920 --> 01:02:40.160 align:middle line:84% It's never nothing, it's never everything. 01:02:40.160 --> 01:02:40.960 align:middle line:90% And just-- 01:02:40.960 --> 01:02:42.668 align:middle line:84% PROFESSOR: Another thing to say, I think, 01:02:42.668 --> 01:02:45.120 align:middle line:84% is that it's not as though Alice got something 01:02:45.120 --> 01:02:51.000 align:middle line:84% for nothing because Alice is left owing 1 unit, 01:02:51.000 --> 01:02:55.880 align:middle line:84% and Charlie over there is the guy with the surplus, 01:02:55.880 --> 01:02:57.440 align:middle line:90% so he is owed 1 unit. 01:02:57.440 --> 01:03:04.800 align:middle line:84% And they could take some of the money in escrow as payment for-- 01:03:04.800 --> 01:03:09.320 align:middle line:84% as the end of underplaying that outcome. 01:03:09.320 --> 01:03:11.760 align:middle line:84% But the other thing that we've been exploring 01:03:11.760 --> 01:03:14.202 align:middle line:90% is to solicit the liquidity. 01:03:14.202 --> 01:03:15.160 align:middle line:90% TOMAŽ FLEISCHMAN: Yeah. 01:03:15.160 --> 01:03:16.540 align:middle line:84% AUDIENCE: Which, again, you didn't have time. 01:03:16.540 --> 01:03:17.415 align:middle line:90% Maybe you could say-- 01:03:17.415 --> 01:03:19.780 align:middle line:84% TOMAŽ FLEISCHMAN: Yeah, it's an interesting concept. 01:03:19.780 --> 01:03:25.480 align:middle line:84% So if you remember the English Association 01:03:25.480 --> 01:03:27.060 align:middle line:90% of Chartered Accountants. 01:03:27.060 --> 01:03:32.120 align:middle line:84% So many firms choose not to pay, although they have. 01:03:32.120 --> 01:03:34.640 align:middle line:90% So what is the logic? 01:03:34.640 --> 01:03:36.580 align:middle line:90% I have money on my bank account. 01:03:36.580 --> 01:03:42.520 align:middle line:84% I'm a powerful market player, so I choose not to pay. 01:03:42.520 --> 01:03:47.560 align:middle line:84% The effect is, my balance sheets are a bit larger 01:03:47.560 --> 01:03:52.360 align:middle line:84% and maybe my credit score in the bank looks a little bit better, 01:03:52.360 --> 01:03:55.360 align:middle line:90% so I choose not to pay. 01:03:55.360 --> 01:04:02.360 align:middle line:84% So what can we do to encourage these firms to pay early? 01:04:02.360 --> 01:04:07.880 align:middle line:84% And one of the ideas is, OK, let's offer them a premium. 01:04:07.880 --> 01:04:14.240 align:middle line:84% If you commit liquidity, you receive 1% premium. 01:04:14.240 --> 01:04:18.740 align:middle line:84% And 1% in one month in terms of interest rate is huge. 01:04:18.740 --> 01:04:21.320 align:middle line:84% So there is no way a bank deposit 01:04:21.320 --> 01:04:24.560 align:middle line:90% is worth as much as 1% premium. 01:04:24.560 --> 01:04:27.320 align:middle line:84% On the other side, you have firms 01:04:27.320 --> 01:04:29.920 align:middle line:90% that are desperate for cash. 01:04:29.920 --> 01:04:31.180 align:middle line:90% They want to collect. 01:04:31.180 --> 01:04:33.520 align:middle line:90% Collection is expensive. 01:04:33.520 --> 01:04:34.460 align:middle line:90% What can they do? 01:04:34.460 --> 01:04:36.420 align:middle line:84% They can go to factor, for example, 01:04:36.420 --> 01:04:38.600 align:middle line:90% but how much does factor cost? 01:04:38.600 --> 01:04:42.960 align:middle line:90% Factor will take 10% easily. 01:04:42.960 --> 01:04:47.200 align:middle line:84% 5% if you are super lucky and you have good relationships 01:04:47.200 --> 01:04:50.680 align:middle line:90% and everything, but it's a lot. 01:04:50.680 --> 01:04:58.720 align:middle line:84% So maybe I'm happy receiving a 1% discount from the network. 01:04:58.720 --> 01:05:02.670 align:middle line:84% And this way, we create a market for liquidity. 01:05:02.670 --> 01:05:07.950 align:middle line:84% And it is possible to do this on different discount and premium 01:05:07.950 --> 01:05:08.450 align:middle line:90% levels. 01:05:08.450 --> 01:05:14.710 align:middle line:84% So I'm willing to engage with my liquidity at 1% or maybe at 2%, 01:05:14.710 --> 01:05:21.230 align:middle line:84% and I'm willing to take liquidity for 1%, 2%, 4%. 01:05:21.230 --> 01:05:24.870 align:middle line:90% So you can make a whole range. 01:05:24.870 --> 01:05:28.650 align:middle line:84% But when you do a range, there is always something remaining, 01:05:28.650 --> 01:05:33.710 align:middle line:84% and this reminder can be then given back to participants 01:05:33.710 --> 01:05:37.470 align:middle line:90% as a cashback, let's say. 01:05:37.470 --> 01:05:44.050 align:middle line:84% So the options to engineer here are countless, let's say. 01:05:44.050 --> 01:05:48.830 align:middle line:90% 01:05:48.830 --> 01:05:50.590 align:middle line:84% AUDIENCE: So practically, I imagine 01:05:50.590 --> 01:05:54.630 align:middle line:84% there will be a network effect which will be very 01:05:54.630 --> 01:05:56.173 align:middle line:90% strong in this circle, right? 01:05:56.173 --> 01:05:57.090 align:middle line:90% TOMAŽ FLEISCHMAN: Yes. 01:05:57.090 --> 01:05:57.990 align:middle line:90% AUDIENCE: So how-- 01:05:57.990 --> 01:06:02.950 align:middle line:84% I mean, think about how you want those small firms to adopt 01:06:02.950 --> 01:06:06.870 align:middle line:84% this technology, how that will happen now they are 01:06:06.870 --> 01:06:09.750 align:middle line:90% using this traditional system. 01:06:09.750 --> 01:06:14.952 align:middle line:84% So how do you get them to adopt this new blockchain-- 01:06:14.952 --> 01:06:15.910 align:middle line:90% TOMAŽ FLEISCHMAN: Yeah. 01:06:15.910 --> 01:06:18.590 align:middle line:90% 01:06:18.590 --> 01:06:20.210 align:middle line:90% The incentive to use. 01:06:20.210 --> 01:06:24.730 align:middle line:84% So the basic incentive is, it helps my collection process. 01:06:24.730 --> 01:06:29.410 align:middle line:84% So we have seen from the chartered accountants example, 01:06:29.410 --> 01:06:34.670 align:middle line:84% managing accounts receivable is a costly business. 01:06:34.670 --> 01:06:38.850 align:middle line:84% So the message from anyone who provides this kind of service 01:06:38.850 --> 01:06:43.710 align:middle line:84% is, we will help you reduce the cost of your working capital 01:06:43.710 --> 01:06:45.110 align:middle line:90% management, let's say. 01:06:45.110 --> 01:06:47.310 align:middle line:84% But then in addition to this, you 01:06:47.310 --> 01:06:55.350 align:middle line:84% can add other incentives in terms of liquidity provision. 01:06:55.350 --> 01:07:00.180 align:middle line:84% But the major friction here is knowledge. 01:07:00.180 --> 01:07:03.060 align:middle line:84% People need to know that this exists. 01:07:03.060 --> 01:07:07.060 align:middle line:84% And in terms of administrative process, 01:07:07.060 --> 01:07:09.340 align:middle line:90% it is all about accounting. 01:07:09.340 --> 01:07:13.420 align:middle line:84% Basically, what we do is all about accounting. 01:07:13.420 --> 01:07:16.740 align:middle line:90% And the use of this system-- 01:07:16.740 --> 01:07:19.460 align:middle line:84% so the data is coming from accounting 01:07:19.460 --> 01:07:22.360 align:middle line:84% and the results should go to the accounting. 01:07:22.360 --> 01:07:26.740 align:middle line:84% So I think the major friction for the adoption 01:07:26.740 --> 01:07:30.140 align:middle line:84% would be integration with ERP systems 01:07:30.140 --> 01:07:32.340 align:middle line:84% or accounting systems in general. 01:07:32.340 --> 01:07:37.060 align:middle line:84% And we as a firm, we are doing on this. 01:07:37.060 --> 01:07:42.060 align:middle line:84% Fortunately, stuff in accounting is quite standardized, 01:07:42.060 --> 01:07:45.920 align:middle line:90% so it should go well. 01:07:45.920 --> 01:07:49.200 align:middle line:90% 01:07:49.200 --> 01:07:49.700 align:middle line:90% Yeah. 01:07:49.700 --> 01:07:52.560 align:middle line:90% And so it's interesting. 01:07:52.560 --> 01:07:57.260 align:middle line:84% So me coming from Slovenia where we use this for decades, 01:07:57.260 --> 01:08:00.600 align:middle line:84% nobody thinks about this, so it's not-- so it's everywhere. 01:08:00.600 --> 01:08:04.260 align:middle line:84% So every accounting package has a button. 01:08:04.260 --> 01:08:06.340 align:middle line:90% Report. 01:08:06.340 --> 01:08:07.040 align:middle line:90% That's it. 01:08:07.040 --> 01:08:10.622 align:middle line:90% 01:08:10.622 --> 01:08:12.580 align:middle line:84% AUDIENCE: So one question I have in the context 01:08:12.580 --> 01:08:14.205 align:middle line:84% of instant payments, and you're worried 01:08:14.205 --> 01:08:16.620 align:middle line:84% about real-time settlement, is the algorithm 01:08:16.620 --> 01:08:20.020 align:middle line:84% that you described, there's no notion of timestamp. 01:08:20.020 --> 01:08:22.437 align:middle line:84% And you can think about It, as for each discrete period, 01:08:22.437 --> 01:08:24.479 align:middle line:84% you're running something like what you described, 01:08:24.479 --> 01:08:27.000 align:middle line:84% but in practice, the timestamps could slightly misalign, 01:08:27.000 --> 01:08:28.420 align:middle line:84% that's a motivation for liquidity 01:08:28.420 --> 01:08:30.020 align:middle line:90% lines from central banks. 01:08:30.020 --> 01:08:34.220 align:middle line:84% But then how does this algorithm run when there is not really 01:08:34.220 --> 01:08:37.700 align:middle line:84% a single diagram, but different timestamps associated 01:08:37.700 --> 01:08:40.160 align:middle line:90% with each flow on each edge? 01:08:40.160 --> 01:08:44.180 align:middle line:90% 01:08:44.180 --> 01:08:46.060 align:middle line:90% TOMAŽ FLEISCHMAN: You are right. 01:08:46.060 --> 01:08:48.540 align:middle line:84% You have to construct a network, and network happens 01:08:48.540 --> 01:08:51.500 align:middle line:90% in a certain time period. 01:08:51.500 --> 01:08:56.130 align:middle line:84% So the basic idea is that everything within a observed 01:08:56.130 --> 01:08:59.930 align:middle line:90% time period is equal. 01:08:59.930 --> 01:09:02.770 align:middle line:90% But we mentioned weights. 01:09:02.770 --> 01:09:04.430 align:middle line:90% So our cost of the flow. 01:09:04.430 --> 01:09:08.270 align:middle line:84% So you can adopt different policies. 01:09:08.270 --> 01:09:15.850 align:middle line:84% You can put different weights on flows depending on, 01:09:15.850 --> 01:09:20.069 align:middle line:84% let's say, various things, like timestamps. 01:09:20.069 --> 01:09:21.130 align:middle line:90% It's possible. 01:09:21.130 --> 01:09:24.290 align:middle line:84% But then when it comes to how useful is this, 01:09:24.290 --> 01:09:28.870 align:middle line:84% do we do it monthly, like we did it with Italian data? 01:09:28.870 --> 01:09:31.410 align:middle line:90% Do we do it daily? 01:09:31.410 --> 01:09:36.670 align:middle line:84% So it all depends on the network and the network topology. 01:09:36.670 --> 01:09:40.890 align:middle line:84% So similar, not the same, but very similar 01:09:40.890 --> 01:09:44.210 align:middle line:84% techniques are used, for example, in CHAPS. 01:09:44.210 --> 01:09:48.370 align:middle line:84% CHAPS is a real-time gross settlement system. 01:09:48.370 --> 01:09:53.890 align:middle line:84% And they do this every 15 seconds. 01:09:53.890 --> 01:10:01.370 align:middle line:84% So it really-- so this is an engineering question. 01:10:01.370 --> 01:10:04.250 align:middle line:84% So not every financial system is the same. 01:10:04.250 --> 01:10:07.150 align:middle line:84% The dynamics, the number of participants, 01:10:07.150 --> 01:10:13.010 align:middle line:84% the number of transactions among them, size of transactions 01:10:13.010 --> 01:10:16.270 align:middle line:84% is different, and it's an engineering question. 01:10:16.270 --> 01:10:26.770 align:middle line:90% 01:10:26.770 --> 01:10:30.450 align:middle line:84% PROFESSOR: So there's another aspect-- 01:10:30.450 --> 01:10:32.270 align:middle line:84% I don't want to overwhelm people, 01:10:32.270 --> 01:10:38.170 align:middle line:84% but just to point out the research possibilities here. 01:10:38.170 --> 01:10:43.330 align:middle line:84% This system that Tomaž has been describing 01:10:43.330 --> 01:10:48.370 align:middle line:84% respects the individual bilateral relationships 01:10:48.370 --> 01:10:52.890 align:middle line:90% that the nodes have. 01:10:52.890 --> 01:10:55.270 align:middle line:90% There are alternatives. 01:10:55.270 --> 01:10:58.730 align:middle line:84% For example, like netting, you could 01:10:58.730 --> 01:11:04.950 align:middle line:84% have a rule that just says, for a given node, 01:11:04.950 --> 01:11:08.250 align:middle line:84% I'm happy if a certain fraction of my debts 01:11:08.250 --> 01:11:12.450 align:middle line:84% are offset with receivables that I have. 01:11:12.450 --> 01:11:16.410 align:middle line:84% And you could implement that, but you don't necessarily 01:11:16.410 --> 01:11:19.692 align:middle line:90% get the identical result. 01:11:19.692 --> 01:11:20.650 align:middle line:90% TOMAŽ FLEISCHMAN: Yeah. 01:11:20.650 --> 01:11:26.690 align:middle line:84% The question, netting versus multilateral set of-- yeah. 01:11:26.690 --> 01:11:30.770 align:middle line:84% So let's do Alice, Bob, and Charlie. 01:11:30.770 --> 01:11:32.690 align:middle line:90% Hopefully this works. 01:11:32.690 --> 01:11:35.810 align:middle line:90% Yes, it does. 01:11:35.810 --> 01:11:39.810 align:middle line:84% So we have our Alice, Bob, and Charlie. 01:11:39.810 --> 01:11:48.600 align:middle line:84% The same network we used, 2, 2, 1. 01:11:48.600 --> 01:11:53.020 align:middle line:84% So now, how does the netting solution look like? 01:11:53.020 --> 01:11:56.620 align:middle line:84% The netting solution in this example looks like this. 01:11:56.620 --> 01:11:59.680 align:middle line:90% 01:11:59.680 --> 01:12:04.180 align:middle line:84% Or let's say what remains to be paid after netting. 01:12:04.180 --> 01:12:13.920 align:middle line:90% 01:12:13.920 --> 01:12:15.620 align:middle line:90% So this is the netting solution. 01:12:15.620 --> 01:12:23.120 align:middle line:90% 01:12:23.120 --> 01:12:25.140 align:middle line:84% And let's do the setoff solution. 01:12:25.140 --> 01:12:28.880 align:middle line:90% 01:12:28.880 --> 01:12:38.040 align:middle line:84% So what remains after setoff is Alice owes 1 to Bob, 01:12:38.040 --> 01:12:42.120 align:middle line:90% owes 1 to Charlie. 01:12:42.120 --> 01:12:48.760 align:middle line:84% So you can say netting is more efficient because there is less 01:12:48.760 --> 01:12:49.460 align:middle line:90% remaining. 01:12:49.460 --> 01:12:52.240 align:middle line:90% It's just Alice of 1 to Charlie. 01:12:52.240 --> 01:12:54.720 align:middle line:90% But there is a problem. 01:12:54.720 --> 01:13:00.060 align:middle line:84% The problem is, Charlie owes Alice originally, 01:13:00.060 --> 01:13:04.760 align:middle line:84% but now, after netting Alice, this is something new. 01:13:04.760 --> 01:13:06.060 align:middle line:90% It's a novation. 01:13:06.060 --> 01:13:08.980 align:middle line:90% And now imagine larger networks. 01:13:08.980 --> 01:13:13.800 align:middle line:84% It can be that Alice has nothing to do with Charlie in the larger 01:13:13.800 --> 01:13:16.000 align:middle line:84% network, but now, all of a sudden, 01:13:16.000 --> 01:13:18.620 align:middle line:90% whoa, where does this come from? 01:13:18.620 --> 01:13:21.800 align:middle line:84% So basically, what netting assumes 01:13:21.800 --> 01:13:26.000 align:middle line:84% is that everyone knows everyone, and that everyone 01:13:26.000 --> 01:13:31.540 align:middle line:84% is equal in terms of risk, then it can work. 01:13:31.540 --> 01:13:38.120 align:middle line:84% So network netting typically works inside a very tight closed 01:13:38.120 --> 01:13:39.880 align:middle line:90% groups. 01:13:39.880 --> 01:13:42.760 align:middle line:84% The setoff, we have just a reduction 01:13:42.760 --> 01:13:45.270 align:middle line:90% of the original depths. 01:13:45.270 --> 01:13:51.430 align:middle line:84% So there is no redistribution of-- or the structure of risk 01:13:51.430 --> 01:13:54.050 align:middle line:84% remains the same, it's just reduced. 01:13:54.050 --> 01:13:57.830 align:middle line:84% So a setoff is a pure risk reduction technique, 01:13:57.830 --> 01:14:03.390 align:middle line:84% while netting introduces innovation, new risks. 01:14:03.390 --> 01:14:06.050 align:middle line:84% And so this would be the difference. 01:14:06.050 --> 01:14:09.830 align:middle line:90% And it's a quite important-- 01:14:09.830 --> 01:14:16.670 align:middle line:84% so especially in larger groups, like trade credit, 01:14:16.670 --> 01:14:20.310 align:middle line:84% where players don't necessarily know each other or trust each 01:14:20.310 --> 01:14:24.230 align:middle line:84% other equally, you cannot rely on netting. 01:14:24.230 --> 01:14:28.510 align:middle line:84% You have to use techniques where risk is not redistributed. 01:14:28.510 --> 01:14:33.058 align:middle line:90% 01:14:33.058 --> 01:14:35.350 align:middle line:84% AUDIENCE: In trade credit networks, part of the problem 01:14:35.350 --> 01:14:37.710 align:middle line:90% is, indeed, the timing mismatch. 01:14:37.710 --> 01:14:39.950 align:middle line:84% And when some firms want liquidity 01:14:39.950 --> 01:14:41.890 align:middle line:90% from-- when others provide it. 01:14:41.890 --> 01:14:44.150 align:middle line:84% And that's why it was kind of curious. 01:14:44.150 --> 01:14:45.070 align:middle line:90% So you said monthly. 01:14:45.070 --> 01:14:47.792 align:middle line:84% Like, on what scale do you simulate? 01:14:47.792 --> 01:14:48.750 align:middle line:90% TOMAŽ FLEISCHMAN: Yeah. 01:14:48.750 --> 01:14:52.110 align:middle line:84% The interesting-- so we are observing 01:14:52.110 --> 01:14:54.410 align:middle line:90% business-to-business networks. 01:14:54.410 --> 01:15:00.950 align:middle line:90% 01:15:00.950 --> 01:15:06.430 align:middle line:84% So the monthly time frame comes from the European 01:15:06.430 --> 01:15:08.790 align:middle line:90% business-to-business context. 01:15:08.790 --> 01:15:11.830 align:middle line:84% Because in Europe, we have monthly salaries, 01:15:11.830 --> 01:15:15.990 align:middle line:84% and a lot of firms issue invoices 01:15:15.990 --> 01:15:19.630 align:middle line:84% monthly for the business within that month. 01:15:19.630 --> 01:15:22.390 align:middle line:84% This might be different in the United States 01:15:22.390 --> 01:15:25.950 align:middle line:84% slightly because you have this concept of weekly salaries 01:15:25.950 --> 01:15:27.110 align:middle line:90% and so on. 01:15:27.110 --> 01:15:30.730 align:middle line:90% So it really depends on this. 01:15:30.730 --> 01:15:33.350 align:middle line:84% So what you can see from the sample also 01:15:33.350 --> 01:15:38.670 align:middle line:84% is that in Italy, you still can observe 01:15:38.670 --> 01:15:42.340 align:middle line:90% a bit of a annual invoicing. 01:15:42.340 --> 01:15:47.660 align:middle line:84% So the December, as such, is quite an outlier. 01:15:47.660 --> 01:15:50.540 align:middle line:84% And it's not just because December is like a Christmas 01:15:50.540 --> 01:15:52.380 align:middle line:84% time and people shop more and things 01:15:52.380 --> 01:15:56.620 align:middle line:84% like that, it's also because, at least in Italy, 01:15:56.620 --> 01:15:59.980 align:middle line:84% it goes into extreme in these cases. 01:15:59.980 --> 01:16:05.180 align:middle line:84% So issuing one invoice for the full year 01:16:05.180 --> 01:16:08.000 align:middle line:90% is nothing special there. 01:16:08.000 --> 01:16:19.100 align:middle line:90% 01:16:19.100 --> 01:16:22.300 align:middle line:84% I hope you will find this interesting, 01:16:22.300 --> 01:16:27.620 align:middle line:84% and will lead you to explore this more in whatever you 01:16:27.620 --> 01:16:30.650 align:middle line:90% are studying otherwise. 01:16:30.650 --> 01:16:39.000 align:middle line:90%