So we can go on now with session two on the effectiveness of monetary policy. And I would like to ask the first speaker and the discussant to come up here and sit at the table and that would be Jan Hanes-Lang and Antonia Natoli Segura. So Jan is an economist in our micro-potential policies division here at the ECB and you work on micro-potential policies both on I think both on borough based and capital based measures and a lot on issues that are related to real estate markets. And yeah, and Anna Natoli is economist at the Financial Stability Directorate at the Bank of Italy. Welcome to the ECB and you also work on micro-potential policies, stress testing and bank resolution frameworks. So thanks very much, Jan. I would give the floor to you. Do we have the... And I think there's a pointer. Yeah, so first of all, thanks a lot to the conference organizers for inviting us. So the paper I present today is called the State-Dependent Impact of Changes in Bank Capital Requirements. And this is joint work with Dominic Menow from the Bundesbank. So he's also here in the audience. So if I say something you don't like and you can go to him after the talk. So I think the paper we're presenting today actually speaks to a couple of the questions that were raised yesterday in the policy panel. So in particular, in the current environment, is it still possible to go ahead with tightening micro-potential buffers? That's one of the questions. And the second one is how high are the costs in general of increasing micro-potential buffers? And I think our paper provides reasonable and intuitive answers to both of these. A spoiler already. So I think the key message would be, in our view, you can still go ahead given high profitability of the banking sector. And also the costs, if you do it right, phasing in the higher capital requirements can actually be extremely low. So therefore, you probably want to err on the side of higher buffers in normal times than rather too low buffers. So I hope I caught your interest in our paper and I'm going to provide you some more details of how we get to these conclusions. So given that we work at central banks, the usual disclaimer applies that these are our views and not those of the institutions. So for the talk today, there are four sections. So I will start with a brief motivation and an overview of the key results that we have. Then I will show you the structural model setup that we use for our analysis. And then in section three, I will provide the key results of our model, both analytical results and quantitative results. And in section four, I will provide a brief conclusion and sort of implications for policy. So what's the motivation for the paper? Our key motivation is really that the impact of changes in bank capital requirements seems to be state dependent. So if we look at empirical evidence, there's evidence that there's close to zero impact of increasing capital requirements when you're in good states of the macroeconomy. And you can reduce lending by a few percentage points if you increase requirements in bad states. And you can see this illustrated in the left hand chart. So here we summarize the findings of some key empirical papers. And you can see that basically, for example, when capital buffers are high, the output gap is positive or when banks are profitable. The impact of increasing capital requirements is very low, so very close to zero. But if these factors are adverse, then actually lending is reduced quite a lot if you increase capital requirements. And the second key motivation for our paper is that actually this feature of state dependence is missing from many of the standard macro models, especially the ones that we use for policy evaluation at central banks. And you can see this illustrated in the table on the right hand side of the chart. So we borrowed this from a recent ECB paper, which summarizes basically the quantitative implications of various DSGE models of a one percentage point increase in requirements on lending. And you can see in the first column that basically most of these models would lead to a reduction of roughly one percentage point in lending for one percentage point increase in capital requirements. So this is really the motivation for why we study state dependence in our paper. So let me walk you through sort of the key results and what we do in the paper. So our key result is really that there's strong state dependence and the impact of changes in bank capital requirements can differ by up to two orders of magnitude, depending on whether you're in good macro financial states or in bad macro financial states. So how do we get to these conclusions? So we build a structural nonlinear banking sector model and there are a few key ingredients. So we have monopolistic competition, but that's actually not crucial to derive the results, but it helps in some of the modeling. But we assume that bank equity is always more costly than debt. So this is actually an assumption that makes it or tends to make it actually hard for increasing capital requirements to have low costs. But even with that conservative assumption, we derive the results that I will show you. And then within that framework, we add two occasionally binding constraints. So the first one is a potentially time varying capital requirement. And the second one is that banks cannot issue equity so they can only increase equity through retaining earnings. So this is actually also a standard or an assumption that is done quite often in macro models. And what we show is that the interaction of these two occasionally binding constraints really introduces this very strong state dependence of the impact of changes in bank capital requirements. So when banks are in normal states and we basically term something as normal when banks hold voluntary capital buffers and they make positive profits so that they could actually cope with moderate capital requirement increases. So when banks are in normal states, the impact of increasing capital requirements is actually extremely low. So it's roughly minus one percent in loans for one percentage point increase in capital requirements. And what we show is that the impact can even be lower than this. However, if you're in bad macro financial states, so meaning states where banks don't have voluntary voluntary capital buffers or very low voluntary capital buffers and where they make big losses, the impact of changes in capital requirements can be extremely large. So we show that the impact can be up to 10 percentage point more loans if you are able to release capital requirements by one percentage point in these states of the world. And let me quickly illustrate sort of the intuition behind these results because I think it helps a lot to understand the more technical results that we present later. So in normal states when banks have voluntary capital buffers and are profitable, something that we call a pricing channel is present. So banks have the equity to fulfill higher capital requirements, but because equity is more costly than debt, the funding cost of loans increases. But this impact on funding cost is actually very small. So it means you only move up a little bit on the loan demand curve and the impact on equilibrium loan quantities is extremely small. However, if you're in the bad states, something is present which we dub the quantity channel. And it simply means in these bad states, banks are already equity constrained. So if you are able to actually change the requirement because banks are highly leveraged, that requirement directly affects the loan quantity that banks can supply to the market. And therefore basically it basically means you're controlling something like a financial accelerator. And if you're able to basically alleviate that constraint in the bad states, you can have a big supporting impact on loan supply. So in the interest of time, I will actually skip the presentation of the related literature. But in our view, the key contribution of the paper is really that we spell out clearly these two different state-dependent transmission channels, so pricing channel and quantity channel. And we derive some very clean analytical results regarding the quantitative implication of these transmission channels. So let me briefly run you through the structural model setup that we use. So we assume fairly stylized, but in our view realistic bank balance sheet and profit and loss account. So basically on the asset side, banks hold loans, so there's only one asset that they have, and they finance that via deposits and equity. So the first equation just shows you the balance sheet identity. And then the profits of the bank are defined as net interest income minus the cost of risk, so provisioning and minus operating cost. So in the equation, let me briefly explain the different terms. So net interest income is simply the interest rate that the bank gets on loans times the loans outstanding minus the interest rate on deposits times deposits. And we substituted out deposits by using the balance sheet identity and substituting in loans minus equity. Then cost of risk is simply we assume that a time varying fraction theta of loans default and they need to be written off through the P&L. And then operating costs, we simply assume that they scale up linearly with the size of the bank. So let me mention two important aspects regarding the modeling. So the loan interest rate is endogenous in our model. So we have a monopolistic competition and we have an aggregate loan demand function that is downward sloping with a constant interest rate semi elasticity. It's basically illustrated in the annex, but in the interest of time, I will not show the equations, but it's important to understand that basically the interest rate on loans depends on the loan choice of the bank and on the aggregate loans supplied in the economy. And then the impairment rate already mentioned we assume that it's stochastic and time varying and we assume it follows a log AR1 process. And the reason for assuming a log AR1 is that in the data we have actually a fat right tail of provisioning so that features needed to mimic the data. So as I mentioned, we impose two occasionally binding constraints. But before explaining the constraints, let me quickly explain how equity is built. So banks can only build equity through retaining profits after dividend payouts. So what you can see is basically next period equity of the bank is equal to starting period equity plus the profits during the period minus the dividends that they pay out. And while the dividends are the choice, optimal choice of the bank, we assume that banks cannot issue equity. So the way we impose that occasionally binding constraint is that dividends have to be greater or equal to zero all the time. So some of you might think, okay, that's an extreme assumption to assume that banks cannot issue equity at all. But our reply to that would be, I mean, first, as I mentioned, it's often assumed in macro models. And in the annex, we also show evidence that actually banks rarely issue equity in the Euro area, even when they make losses. So for unlisted banks, even in 90% of the time where they make losses, they don't issue new equity. For listed banks, it's a bit more, but even their 50 to 70% of the time they don't issue new equity when they make losses. So in our view, it's an extreme assumption, but let's say it's a high level first pass approximation. Then the second occasionally binding constraint is that potentially time varying capital requirement are and that must be met by the banks at all times. So the capital ratio, which is defined as equity over risk weighted assets. So Omega is our risk rate that we assume this must be greater or equal than the capital requirement all the time. So the objective of banks in our model is that they maximize the present discounted value of expected dividend payments. And the discount rate that they use is determined by the required return on equity, which we denote by role. And we assume that raw is strictly greater than the debt funding cost of the bank. So we make it basically in principle, we make it costly for increasing capital requirements. And the decision problem of the bank can actually, so this dynamic maximization problem can be represented by the Bellman equation that you see on this slide. Basically the value function has four state variables. So you have the credit risk shock theta, loans of the bank, equity of the bank and the aggregate loans in the economy. Because as I mentioned, the interest rate and therefore also the payoffs depend on the aggregate loans in the economy. And what's important to note is basically the two occasionally binding constraints that we introduced in the second line of the equation. So the first one is the capital requirement constraint. And here we denote the associated Lagrange multiplier with Chai one. And the second one is the equity issuance constraint where the Lagrange multiplier is denoted by Chai two. So the equilibrium of our model is determined by the first order conditions. And after you take the first order conditions to impose the representative bank assumption. So basically the idiosyncratic loan choices and the aggregate choices need to be consistent given that we assume a unit mass of identical banks. So given that I've presented now the model setup, let me briefly run you through the key results. So we have analytical results and we have quantitative results for model that we solve with global solution methods and we calibrated to Euro area data. So the first result is that there is a pricing channel of changing bank capital requirements. So proposition one states that in the absence of an equity issuance constraint, the equilibrium loans respond to changes in capital requirements by a pricing channel. So the percentage change in loans is equal to the right-hand side expression. And let me run you through the intuition behind the right-hand side and this pricing channel. So if you increase capital requirements, given that equity is more costly than debt, this should increase the funding cost of loans. And that's basically captured by the square brackets. So raw minus id is simply the equity premium and omega times delta r is the additional equity that you need to fund the loan. But the key insight is that actually the funding cost impact of higher requirements should be very low. So if you plug in reasonable numbers like an 8% cost of equity, a 2% cost of debt, 50% risk weight and a 1% point increase in requirements, that should increase your funding costs by three basis points. So we're talking about one-eighth of a standard monetary policy rate increment. So this is actually super low. And then given that we assume monopolistic competition in the model, this increase in funding cost is passed on to borrowers with a markup. So that's why you have mu over mu minus one in front of that funding cost increase. And the impact on equilibrium loan quantities then depends on how elastic loan demand is. So that's why you have the epsilon there, which is the interest semi-elasticity of loan demand. And if you look at empirical estimates, they are usually estimated around three this epsilon. So if you put basically the numbers together, you end up with this minus 0.1% decrease in loans for one percentage point increase in capital requirements. So these results are for the model where you don't have the equity issuance constraint, but importantly what we show is for the full model with the issuance constraint in states of the world where banks actually hold voluntary capital buffers before and after changing capital requirements, a similar pricing channel is active and importantly the impact can even be lower than this minus 0.1 on lending. So the key message regarding the pricing channel is really that the impact on lending is very small. And here we illustrate this with simulations from the full model. So what you see in the chart is on the y-axis is the decrease in loans in response to an increase of capital requirements from 10% to 11%. On the x-axis you see basically the relative frequency of these impacts. And we only look at states where banks hold voluntary capital buffers before and after this increase in capital requirements. So focus first on the red bars. So if banks actually hold voluntary capital buffers but they don't pay dividends before and after, then you get this minus 0.1% drop in loans for one percentage point increase in requirements. If banks also pay dividends before and after, the impact is virtually close to zero and that's illustrated by the blue bars. So the impact can even be much smaller than the 0.1 and can basically be almost nothing. The second key result of the paper is that there's also a quantity channel can be present for changing capital requirements. And this is illustrated with Proposition 2. So in states of the world where the equity issues constrained and the requirement constrained are both binding, equilibrium loans respond to changes in requirements via this quantity channel. And the quantity channel simply states that the percentage change in loans that you get in equilibrium is equal to minus the percentage change in the capital requirement. And given that capital requirements tend to be low, so let's say 10% roughly, if you change it by one percentage point, that roughly means a 10% point change in the requirement. So you can already see the quantity channel whenever that is present will have a big impact on lending. So the intuition is really that. If banks are equity constrained, so basically if both constraints bind, they don't hold voluntary capital buffers, they don't pay dividends. So loans are simply determined by equity plus profits and the requirement and equity and profits are given. And you can see from that equation, if you change the requirement, the only thing that can adjust is loans and given the high leverage, the adjustment in loans will be very, very large. So changing requirements when the quantity channel is present can have a big impact on loan quantities. And we illustrate that also with our model. So basically the quantity channel impact on lending can be very large and it can be basically up to 10% point for one percentage point requirement release. And we illustrate that by shocking our model economy with a very big credit risk shock and then comparing the evolution of loans for two different economies. So one where we keep the capital requirement constant at 11%. That's the red line in the charts. And one where we decrease the requirement from 11% to 10% upon the impact of the shock. And the shock basically is the same in both cases. So what are the mechanics? When the bad shock hits, banks make big losses that eat up all the voluntary capital buffers. They're actually forced to deleverage and you see that by the red line in the right hand side chart. So loans would need to drop by almost or by more than 12% to still meet the requirement given the heavy losses that banks incur. But if the regulator is actually able to release the requirements to 10%, this gives banks basically space or available space to absorb losses and mitigates the deleveraging pressure. So you can see in the right hand side chart that the blue line drops much, much less. So roughly 9% points less than the red line. So this illustrates the big impact of the quantity channel. So finally, we ask what kind of capital requirement rules can help you prevent that the quantity channel is present. And in proposition three, we derive such generalized rules. So policymakers can avoid the quantity channel with any time varying capital requirement rule that satisfies that the requirement never turns negative and it satisfies the following condition in all states. And this condition is fairly intuitive. So the requirement that you set for next period has to be lower than the current capital ratio of the banks plus the return on risk-weighted assets and the whole thing is adjusted for a growth rate factor. So G star is basically the desired long growth rate of the banks in the absence of the equitation constraint. And what's the intuition? It's basically the return on risk-weighted assets and long growth together give you the speed limits for how quickly banks can increase their capital ratio. So when profits are positive, a gradual buildup of the capital ratio and therefore also of the requirement is possible without constraining banks. But of course, if banks make losses, you need to release and reduce the requirement because there's basically downward pressure on the capital ratios of banks and to accommodate that, you need to reduce the requirement. So finally, we use our quantitative model to actually implement such a simple state-dependent rule that is consistent with Proposition 3. And what you can see illustrated in the chart is basically the transition dynamics from an economy where you have a constant 10% capital requirement to an economy where basically the capital requirement is varied between 10% and 15% depending on profitability. So when there are positive profits, their gradual continuous increases in the requirement when there are losses, the requirement is reduced. And the blue ranges show the percentile ranges across 100,000 simulations of the economy. And what you can see is that there are actually big gains at rather moderate costs of such a state-dependent capital requirement rule. So after five years, if you focus on the right-hand side chart, basically the far-right tail of credit drops is gone. So credit crunches or severe credit crunches are eliminated from the economy. And you do that at rather moderate costs because the average and upper percentiles of the long-growth distribution are barely affected. So they only reduce very minimally. So let me just provide a brief conclusion so I will not recap the findings but say what we think are the policy implications. So yesterday there was already a lot of mention of positive neutral CCYB and in our view the results that we derive in the paper clearly support such a macro-potential strategy because the cost of building buffers when banks make profits, if you do it gradually, should be very low. But at least you have something that you can release in times of stress to really give banks breathing space and continue supplying loans to the economy. So yeah, how and when should capital requirements be increased? Just do it when banks make profits. It's easily observable. How should you do it? You should do it gradually. So speed limits are given by return on assets and the long-growth. This should be super easy to implement and you will impose almost no costs on lending and the economy if you do it in the simple and transparent way. When should you release capital requirements? Clearly when banking sector makes losses. So recession is not enough. If banks still make positive profits in the current environment, profitability is very good. Not time to release at the moment. How should you do it immediately of sufficient size so banks can actually absorb the losses that they realize. But of course this is a bit harder to implement because you have this observation lag between losses actually being borne by the banks and then being reported. So of course some type of preemptive release might be needed. But I'll leave it there in the interest of time and thanks a lot for your attention and looking forward to Anatoly's discussion. Thanks Jan. So thank you to the organizers for inviting me to discuss this paper. It has been a pleasure to read it. So let me start with a very brief overview of what the paper does. So the authors developed a dynamic, a linear equilibrium model of the banking sector in a context in which banks face two occasionally binding constraints. One arising through a regulatory minimum capital requirement and the other one is by the assumption that banks cannot issue equity. And the results of the paper are that the effects of changes in capital requirements are state dependent. When no of the constraints binds, then the impact of the change in capital requirements is small. And when the both constraints bind, the impact is very large, is 100 times bigger. So this paper provides a very strong policy message going to the direction. It is good to build macro potential space when banks have ample capital headroom and they are doing strong profitability. This comes at a very low cost and has a very sizable potential benefit if losses realized later on in the future. So in my discussion, what I'm going to spend some time in describing the mechanisms and the calibrated results and then I will do some comments. So the model, this is a discrete time infinite horizon. You have a continuum of banks that issue one period loans that are subject to some risk. Some of the loans may default. That is aggregate risk. And this follows and there is some persistence in this aggregate risk. And there is also downward sloping demand for loans. Now banks are funded with some funds, with equity that is expensive and cheaper deposits. The banks face two constraints. They have to satisfy a minimum capital requirement and they cannot issue equity. They can only pay dividends. So essentially the model, the way I see it, is a sort of discrete time version of the Brunner, Meyer and Sannikov AR paper with the capital requirement. So what are the mechanisms in this paper? So let's think before on how this economy responds to shocks. And this is very much in line with what we know from Brunner, Meyer and Sannikov. So when there is a very large shock in this economy, banks are going to hit their capital requirement constraint. Now at that point, the lending supply in the economy is going to be determined by the bank capital. So shocks to the economy that are translating to equity losses for banks then are transmitted and amplified through the funding constraint. So there is amplification of losses when negative shocks are very large. Now banks anticipate that and they dislike hitting their constraints because they realize that when there are bad shocks, aggregate lending supply will be constrained and interest rates will be very high. So banks realize that they would be able to do a lot of profits during crisis and that's why they want to have voluntary buffers. There is a model in which banks endogenously have voluntary buffers in order to protect themselves from the implications of aggregate shocks. Now, given that they have voluntary buffers, if there is a small negative shock, it is not going to deplete entirely the voluntary buffer and this shock is going to be transmitted to the economy but it's not going to be amplified. So this is Brunner, Meyer and Sannikov. And what the main results of the paper are is just they don't look at the impact of shocks but they look at the impact of changes in capital requirements that one might think there are a shock to the banks as well. And the results are new but they are in a way a mirror image of the results in Brunner, Meyer and Sannikov. So when the changing capital requirements is done when banks don't have voluntary buffers, then the capital requirement is binding, lending supply is determined by the capital requirement and there is amplification. There is amplification of the changing capital requirements. When instead banks have ample voluntary buffers, the changing capital requirements is no amplified. So there is an impact but it is very small. So this part of the paper, the analytical part of the paper is very transparent and the analytical results are very intuitive and they're very persuasive. So let me get to my comments. My first comment is on how to place this paper in the context of the existing literature. So there are some quantitative microfinance papers that have occasionally binding financing constraints for the banks and that look at the optimality of state-dependent policy rules. And there are some papers that are even richer in the sense that they have also firms that are facing occasionally binding financing constraints. And let me mention the two papers that come to my mind. One is by one of my co-authors, Viagorta, and this paper, the interplay between banks and firms balance sheets is going to generate two types of resets when there are shocks. The other type of crisis, these are crises in which firms balance sheets are most hit and these crises have a very fast recovery. Then there can be also banking crises that are crises in which the bank's net worth is mostly hit and these crises have a particular feature that the recovery is very slow. And in that paper, Viagorta looks at optimal policies that have not changed the capital requirements. What is the optimal recapitalization rules in this environment? And it is also state-dependent. He shows that it is optimal to direct recapitalizations to the most hit sectors. There is also a paper by Vadim Levin and co-authors published in Econometrics. It's a very rich macrofinance model calibrated for the US and they look, the purpose of the paper is to look at the optimal liberation of capital requirements in the US and they show that cyclically adjusted capital requirements of state-dependent capital requirements dominate fixed capital requirements. So it's important to place the paper in the context of these contributions. My second comment is that the paper should strengthen its normative implications. So the way it is written so far, it has a positive approach to the analysis of capital regulation. And they look at what is the effect of changing capital requirements and the results are in line with what we knew from the literature of the impact of shocks in the presence of financial restrictions. So what is missing is a normative approach. So why are capital requirements? Why are there capital requirements in this economy and how to optimally set them? I would give some suggestions for the authors to try to improve the paper in this front. So a natural question that came to my mind is is the model equilibrium constrained efficient? If it is not constrained efficient, there would be a rationale for policy intervention and potentially for capital requirements. So notice that in this model, the bank's capital accumulation choices affect equilibrium in the loan market. And the equilibrium in the loan market in turn affects how much profits banks do during crisis and those profits enter the financing constraint. So it's the typical setup in which there could be pecuniary externalities. So there could be excessive leverage by the financial sector or too little. We don't know, it depends. And it would be interesting to explore that. Then another thing is that in the model, the authors assume that deposits are insured but still in equilibrium, the calibrated model, so that in equilibrium there is no bank default. Now bank default and deposit insurance is the traditional motive for regulation of the banking sector both in reality and in many models. So I would suggest the authors to allow for bank default that would give rationally for capital regulation in the model and that is also realistic. And at the very least, if that is too complicated, assume a sort of mean variance social preferences for bank lending so that the traders between maximizing aggregate lending and minimizing volatility of lending can be studied with a bit more of a structure. Then my last comment is that, I mean, the authors also push for a particular state-dependent rule for setting capital requirements. It was not presented in the presentation but the way that the proposed rule works is for given banks' capitalization, the capital requirement is set in order for banks to be able to accommodate average lending in the economy and still keep a buffer. With the banks under that rule, when the banks suffer losses, the capital requirement is reduced and when they make profits, the capital requirement is increased. Now, some questions that this type of proposed rule raises to my mind is that in the context of this model it's not so clear that this rule would be so different from the standard macro-publicial buffers that authorities have at their disposal. For example, a counter-cyclical capital buffer in this economy in which there is only one source of aggregate risk and which is the loan impermanent rate, when the loan impermanent rate is low, there are lending expansions and banks make profits. So a counter-cyclical capital buffer would push also towards increasing capital requirements. So the particular situation we are facing in many economies now that credit is contracting and banks are doing a lot of profits does not arise in this model. And this is the particular situation in which many authorities don't know what to do. So I think it would be necessary to introduce some additional shock to break the equivalence between the two policy rules. And to conclude, an important... I think the paper has the potential to speak to something we are very interested in. Vice President Deguindos in his keynote dinner speech concluded with the reference to the discussion between buffer-releasability and buffer-usability. This is a model, there are not so many models there, that has endogenous capital buffers. And the model has the potential to speak to how different are through the lens of macrofinance models usable buffers from releasable buffers. So I think this is something that you might want to explore. And let me conclude with this. Thank you. Thank you very much. And I totally saw lots of ideas, I think, to further work on the paper. We can take one or two questions. And I have Alastair, then there was Stefan. Okay, then here. But please try to be concise in your question. Thank you. Very interesting. But you can observe in the market today a 17% cost of equity being applied to European banks, so that you'd be interested how that would impact the model. And one of the things as a market participant I've observed is that if the central bank treats bank profits as its rather than as fundamentally according to shareholders in most cases, shareholders apply higher and higher discount rate to bank earnings. So what's actually happened is the cost of equity has risen in Europe as the capital levels have risen because the capital's been continually diverted. So, you know, that 17%, I'm interested how your model would work if you increase the cost of equity as you capture the capital, which is observably what's happened. And I'd expect it would be less beneficial. Thank you. So thanks a lot for that presentation. In a sense, it's a very regulatory perspective on the banking system and the role. And I think it's great to have the distinction, no, the state dependence there. But one thought I had was what about changing over time kind of uncertainty? I guess if you have kind of you're in a regime of high uncertainty and you have your banking system and you have your regulations in place and you expect in the future it goes down, the uncertainty goes down or the opposite. Can you say anything now ready or is this a next paper? I guess it's half similar. I will have two comments. The first one, I think you assume that somehow the return on equity gets adjusted as the requirement increases. I think in the real world a lot of the loans are 30-year mortgages. So in reality, it has increased the requirement the return on equity goes down and that's what's happened. You have other businesses which are not able to reprise, which are not loan-based. So in practical terms, the return on equity goes down. As an equity investor, your capital gets trapped in the business because you think you are getting let's say 8 or 17 or whatever you think you should be getting but in reality your remuneration is very, very long. And in the real world, the release of requirements doesn't work because in a crisis nobody wants to be running. If the standard is 15, nobody wants to be running with 10 because basically they will get destroyed by the fixing of market A and B because everybody knows they will have to go back to 15. So in practical terms, nobody is willing to go down to 10 even if technically they could, which is what happened with COVID. So the release doesn't work in practical terms. It only goes up and up and up but there are no step-backs. Thank you very much. Just a question about the timing of capital requirement announcement. So you know that the CCYB is usually announced one year in advance. So I was wondering whether a timeliness and unexpected announcements would change the impact of capital requirements. And would banks price in these early or would it give like a mitigated amount on impact and how does the level of competition or concentration impacts your results? Thank you. Thanks very much. So please proceed. Thanks a lot for the discussion and also for the interesting questions. Now I think you did a really good summary of the paper and indeed I think Bonamaya Zanikov is closely related and we really see our contribution in focusing on the capital requirement and clearly spelling out the state dependent transmission channels of changes in requirements. So indeed I mean the modeling framework itself is not entirely new but I think the perspective of how we use it adds valuable insights especially for the policy debate. So I mean your first related comment would be placing it into the literature and they fully agree we can still do a better job to clearly specify what we do differently and what we focus on differently. In terms of sort of more normative implications these are definitely valuable suggestions and we thought of some of them and I mean we need to see what's actually realistic to model because one of the key strengths of our current paper at least as we see it is that we're actually able to derive very clear analytical results and in our view that actually helps a lot to have a transparent debate if you don't always need to resort to numerical solutions. So we will explore what we can actually add and still stay within let's say a clean and neat framework. Then maybe on your final comment on the relation to the existing CCYB rules they actually disagree because in my view existing CCYB rules depend on a measure of cyclical risk. So you need to first estimate something that is unobservable. Our proposed rule is only based on observable variables capital ratio and profits and it's a completely different approach. You basically say don't care about risks because if you increase gradually and slowly and predictably capital requirements when times are good the costs are very low. I mean you want to err on the side of caution because you don't do much harm by having let's say one or two percentage points of buffer in addition and I think therefore this type of rule deviates quite a lot from this risk based perspective where you say no, no, it's really costly to increase the requirements and therefore you really want to be sure that you need them for high risks. But in my view this type of approach has not really proven that impactful and effective in reality. Some of people who have seen David's talk yesterday would speak also in that direction. Then I mean regarding the questions so indeed I mean cost of equity estimates have gone up also the cost of debt has gone up so what really matters in the model is the difference between the two because that's basically the additional cost that you impose on banks. Of course if you assume that this sort of equity premium goes up this will increase the pricing channel impact but even if you increase that by 50% the equity premium your three basis point funding cost impact will go to 4.5. So in my view of course it will have an impact it will make it more costly but it will not lead to a different order of magnitude compared to what we have shown and then actually I mean my view would be the following what we actually show here is that being simple and transparent and it's not that we're taking away profits from banks the equity stays in banks and even with our rule we basically ensure always that banks can pay dividends even in crisis times because the release will always be bigger than actually what the hit to bank capital ratios would be so the rule we implement in the model allows banks basically to continuously pay out dividends we simply impose that they gradually need to increase requirements ratios when times are good On Stefan's question regarding uncertainty I don't really have a good answer I haven't thought about that part there was a question on potential ineffectiveness of release in times of stress so I didn't mention it here but I think what's important to keep in mind that what I've shown you only works if the market imposed leverage limit or capital requirement is below what the regulator sets so of course if let's say in good times your requirement is not high enough so that actually the losses that banks incur in bad times would force the regulator to reduce capital requirements below a market imposed capital requirement then no effect of release there I fully agree but the flip side of that is in the good times you need to increase the requirement way above what's market imposed so that in bad times you can reduce the requirements sufficiently that you're still above a market imposed leverage requirement final question on timing so in our model the CCYB or the requirement is announced one period in advance and actually what it does is given that banks anticipate this and if you have a clear rule it actually will lead to lower voluntary buffers because there's less self-insurance mechanism in the model because the regulator takes out the insurance motive to some extent because they reduce the requirements okay I'll leave it there thanks very much Jan so I saw a number of hands still up so maybe you can use the coffee break which will start now I would like to thank the presenter and the discussant very much and then we resume at 11.15


Namaste to all of you. We had started with a new statement that is cash flow statement. I hope you all liked it and you are excited about it. So can you tell now what is a cash flow statement? It is a statement which lists the cash inflows and outflows. Now naturally the question comes is why do you need this statement? Now why is it required? What are your two other important statements? The first statement was balance sheet, the second statement was PNL account. Balance sheet gives you what? It gives you the financials position of the enterprise, PNL gives you the income and expenditure. But both these statements are not able to tell you how much is a cash generated or spent. That is why third important statement was introduced around in 1995 that is known as cash flow statement. It gives you inflows and outflows of cash. Not only that, it gives you those flows under the three heads. What are the three heads? One is operating, next is investing, third is financing. In our last session we had discussed what is operating, today we will go into investing and financing. Now before that what do you mean by cash? That is a first question because we are talking about cash flow. So what is a cash? So cash includes cash plus cash equivalent particularly in cash you are having cash and bank balances. In cash equivalent what do you cover in cash equivalent? You include extremely short term investments which are highly liquid and are not exposed to loss of value because of market forces. So something like money at call with banks or money in certain securities but no change of value is expected there. Very few restricted securities can be included in cash equivalent. Now any movement of cash is considered as a cash flow but there is an exception if there is a movement within cash and cash equivalent items do not consider them as cash flow. So what is such example? So if you deposit money in bank, you withdraw money from bank this is a change within the cash and cash equivalent. One cash item is coming down, other cash item is increasing. So we will not consider it as a cash flow and we will not show it in cash flow statement. So here you have got cash and cash equivalent items taken together and there are several other items. If because of any transaction cash and cash equivalent either reduces or increases we will call it as a cash flow and will be shown in the cash flow statement. This much is what we had discussed and I hope it is clear to you but you can just glance through the slides once again. So this is a index we are slowly going to next items today. Ind AS7 is a new set of standard which we are following for this calculation. This is the definition of cash and cash equivalent, the meaning of cash then the types of cash flows. Now particularly we were discussing what is operating cash flow. So operating as the same suggests means day to day activities or principal revenue generating activities of the enterprise. So any item which is related to either generation of cash or expenditure of cash on day to day business which is considered as operating activity. Any activity which cannot fall in financing or investing but there is a cash movement is also included because it is a residuary head known as operating activity. We have seen a few examples in the last session but today going by the nature of business can you tell what will be the operating activity? For example, suppose you are a web developer, you develop websites or various companies. What will be the operating activity for you? What are the incomes for you? Somebody are charging some fees to your clients for generating new web content. You may be charging fees for hosting their websites. All these would be incomes for you which will go in PNN. They would also be cash generated for you whenever the customer pays you, you are generating cash and that cash is from operating activity. So it falls in the first example that is cash received from sale of goods or rendering services. If you are Tata Motors in the last session we had taken example of Tata Motors. For Tata Motors what is a principal revenue generating activity? I think most of you know the company they sell cars. So selling cars, trucks, vehicles is their business. So money which they generate in cash by sale of car or by sale of a truck will be their principal revenue generating activity. And what are the expenses? I think they are common for any company rent, taxes, salaries, traveling expenses. All of them are considered as for running of business. So they are your operating activity related outflows. Suppose you are a web developer company, you purchase a car, will it be an operating activity outflow? Answer is no, because car is a fixed asset for you, it is not your day to day activity. I do not think you will buy car and sell cars every day. Who will buy and sell cars regularly? For a car dealer, car is a stock item. So purchase and sale of cars is a day to day activity, it will be a operating activity. But for most other enterprises, car is a part of fixed asset. So for them purchase of car will fall in will go in fixed assets in the balance sheet. In cash flow statement, where will it go? It will go in investing activity, not in the operating activity, are you getting me? Some more examples are already listed here, I think we have seen it in the last session. Now there are two methods of preparing cash flow, of which the first method is very simple, it is known as direct method. So please have a look at the format, I think it does not need any much of explanation. It is very similar to P&L actually. In P&L you start with sales, reduce all the expenses, you get profit. Same way, only exception is there we show actual payments plus outstanding expenses. Here you are only concentrating on actual receipts and payments. So receipts from customers plus cash sales, that is your cash received minus payments to employees, payments of rent, payments to creditors, not purchases. Keep in mind in P&L account we show purchases, whether you pay or not it is considered as a expense, here only that much amount which you have paid to creditors. In case of cash purchase the amount will be same, but for credit purchase you are purchasing now paying later. Whenever you are paying it will go in cash flow statement. But this is relatively simple, only one thing you have to keep in mind is almost like a P&L but it should be on cash basis, are you getting me? So you are listing all cash receipts minus all cash payments from operating activities there would be net cash from operating activities. Now the second method is slightly complex because here we are going from P&L to calculating cash from operating activities. So in P&L account we get profit or loss for the period, we start from that or we start from transfer to reserves sometimes, then we add back a few items to begin with we assume that profit is very close to cash from operations. Only those items which require adjustment, suppose there are 40 items in P&L all of them would not need adjustment, few of them which are of two types they would need adjustments only those two types of items we will either add or reduce. So what are these two types of items? One is if it is non-cash I will just show you the format. So we are starting with retained earnings plus dividend plus taxes that is net profit before tax then we add non-cash items best example of it is depreciation because we have already discussed depreciation earlier that it is not a cash expense it is charged to P&L but does not involve cash so we add it back. Similarly, if there are any non-operating items, so what are the non-operating items? Keep in mind most of the items in P&L are operating but a few items like sale of machinery and there is some loss on sale of that machinery that loss part will be shown in P&L but we do not want to have it here in cash flow that is why we add it back. So add loss on sale of some something like a machinery. Similarly if there is a profit on sale of land that is already shown in P&L so we reduce it from there because it is not operating item we make an adjustment for it and after adjusting these items we get funds from operations. After this also there is a third adjustment that is related to your current assets and current liabilities. So what happens is from your current assets if there is a increase in current asset it leads to less cash in the hands of company. So suppose there are receivables so you have sold the goods but you do not get cash your debtors or receivables are increasing your cash is falling. So any increase in current asset there is a fall in cash keep in mind there is a competition between current assets and cash cash is also one of the current asset. So other than cash if any other current asset is increasing it leads to decrease in cash. You can have a look here there is a less increase of current asset similarly if current asset decreases like you have credit you have debtors debtors pay more cash to you their balance will go down and you have more cash that is why add decrease in current assets. So from the balance sheet we will get balances of current assets and liabilities we would have a look at increase and decrease make the adjustments in the funds from operations that will give you cash generated from operations are you getting me? So fund is a amount of profit generated but it is not cash so we are making adjustment and calculating cash generated from operation we will have to deduct the income taxes which are paid that gives you cash flow from operating activities is it clear? This much we have discussed last time but since it is little more complex we have just revised it again we are now going to next two heads the next head is investing activities this also bit of we have discussed last time. So all those activities which are related to long term assets like fixed assets or investments they would be included here in investment investing activities. So what are the examples either purchase or sale of fixed asset so purchase of land sale of land purchase of machinery sale of machinery these are all investing activities or related to investments like keeping FD or withdrawing FD with bank purchasing some shares or selling some shares all this is included as investing activities. So these are few of the examples just have a look at them. If you put FD in bank you will receive interest there on that interest is also an investing related flow if you purchase shares you will receive dividend there on that dividend is received because of your investment that is why it is considered as an investing activity that is also an example of investing activity are you getting? So in operating activities there were two methods what were the two methods direct and indirect luckily there are no two methods in investing activity you have to directly show whatever is you have received or paid that is why calculation of investing activity is very simple there is nothing to be afraid whatever is amount which is paid either on fixed assets or investments or received because of them that will be directly shown. Keep in mind we are not talking of profit or loss on sale of machinery that is for P&N in fact now we are only concerned with the total amount which is either received or paid for fixed assets getting it. Now the third type of activity is known as financing activity now here in the first session if you remember we had seen that business needs resources those resources are assets. Now these assets are financed by somebody so somebody makes you payment you get some money from that money you have purchased the assets. Now from where you have raised the money or from where you have generated those finances they are categorized as financing activities there are two important types in it one is known as equity the other is known as borrowings do you remember when we discussed balance sheet we had discussed this I would request you to go back and have a look at balance sheet format. So what does it fall what does falls under equity these are the owners funds these are the monies of the shareholders like share capital or preference share capital that will be shown and what are the borrowings borrowings are various types of loans taken by you. So either loan taken or loan repaired or interest paid on that loan they are all falling under financing activities. So here some examples are given like issue of shares or debentures borrowings and so on what do you mean by debenture do you remember so debenture is also like a loan company obtains a loan and gives a certificate to the lender in the form of debenture certificate that is called as a debenture but it is just like a loan for the company. So that is also a financing activity. So here there are some specific examples when you issue shares exactly reverse of it is called as buy back of shares that means company takes back the shares from shareholder and gives them money that is called as buy back of shares. So that is also a financing same way issue or redemption of preference shares or debentures in issue what happens company receives money gives preference shares buy back or redemption is exactly opposite company takes back shares gives them cash. Both the cases the cash is involved and it is related to financing of the business. So it will fall in the financing category of cash flows are you getting. Now whenever you raise funds you have to compensate your investors in the form of interest or dividend. If you take loan you will pay interest that is also financing activity. If you raise money by way of shares you will pay them dividend that is also a financing activity. Are you getting all the examples. Now let us consider some specific items in the cash flow of which the first one is interest we have just discussed it already but this will be reinforced in your mind. Interest can be received or paid now to begin with how do you account for interest received. We have already discussed this that you receive interest mainly because you have made investment. So if you have made investment in bank like FD or if you have made investment in debenture of some other company you will receive interest from them that will be categorized as investing flow. But there are some exceptions to it which I have noted please keep in in keep them in mind. Suppose the investment is in cash equivalent for example investment is in ultra short term deposit which you have categorized as cash equivalent then it is not an investment. As far as cash flow is concerned it is not an investment that is why interest received on cash equivalent type of investment will be considered not as an investing activity we will categorize as an operating activity because it is a day to day item. Similarly sometimes we receive interest from trade advances getting me. So suppose we have put some money as an advance to our suppliers and they give us interest on that amount it is rare it does not happen every now and then but suppose it is there we have received some interest from it or suppose there is a bill receivable and on bill receivable we have received interest then it is not related to any investment it is not a long term activity because typically it is for 1 month, 2 months, 3 months, 4 months like less than 1 year that is why those investments and interest there on would be categorized as operating activities. And the third example which is for specific type of undertakings or companies known as finance enterprises. What are the examples of finance enterprises for example a bank a non banking finance companies for them finance is their business. So giving loan is their business so they are bound to receive interest from their customers that is their day to day business activity or principal revenue generating activity. So we will categorize it as operating flows for all finance related companies are you getting? So this is about interest received. Now about interest paid now interest paid as you all know by default we will treat it as a financing activity but there are a few exceptions. Because the loan is obtained as a working capital loan I hope you know what is working capital working capital means current assets minus current liabilities. This is a capital which is used for day to day activities or if you remember our session 1 and 2 we had seen a business cycle. Now whatever is money blocked up in business cycle you can get some loan from bank for specifically for working capital. Now if you pay interest on a working capital loan it should be categorized as an operating flow not as a financing flow. And the third example or a second exception you can say is for a finance enterprise. Now naturally for a finance enterprise paying of interest is a part of their day to day activity. They receive interest they pay interest. So for them interest paid is categorized as a operating flow are you getting? So this was about interest. Now based on this can you imagine what will happen for dividend? Because dividend also you get both the categories like dividend interest and dividend received and dividend paid. Now if it is dividend paid what will happen whom do you pay dividend we raise money by way of shares. So shareholders pay us as a company their money to compensate them we give them part of share of our profit that is known as dividend. So it should fall in which category? Is it operating? Is it investing or is it financing? I think most of you are guessing it correct this is related to raising of funds. So it is a financing activity we have raised funds by way of shares we give dividend to shareholders. So it will be considered as a financing outflow. Are there any exceptions like for interest? Now this is a peculiar item there are no exceptions even if it is a finance company even if it is a operating item or whatever you will never consider it as operating or investing dividend paid is always considered as a financing item. What about dividend received? Where will dividend received go? Dividend received is very similar to interest received actually. By default it will be considered as an investing flow we will just go to that slide. So dividend received what happens is for non-financial enterprises we will always categorize it as a investing flow because we have made investment in shares we get dividend. But for a finance company or for a bank we will categorize it as a operating flow because for them it is a day to day activity and dividend paid we have already discussed is always categorized as a financing flow. So you are getting me? So we have discussed now today few peculiar items first we discussed the investing operating then investing financing and two peculiar items that is interest and dividend. In the next session we will take a few more items and then we will start looking at the problems. Namaste. Thank you.


If you have pets on Masawa Air Force Base, there's a chance they've stayed here. Masawa's pet kennel. Petty Officer Larshide tells us more about the care your furry friends receive while you are away. If you have pets here on Masawa, there's a chance they've stayed here. Masawa's pet kennel. We play with them and just kind of keep them company and take care of them while their owners are either overseas or deployed and if they leave during the holidays and stuff like that, it's kind of like a pet hotel. And it's around this time of year that this pet hotel is the busiest. It makes me feel really good to take care of them and give them extra love, especially around the holiday times because they kind of get, they kind of miss their families too. They don't know it's the holidays but they still want that love and attention that they get from their owners. So pet owners can rest assured that when things come up, the kennel is there to take care of your pets and will have them ready for you when you get back. Petty Officer Ben Larshide, Masawa Air Base, Japan.


Hello, this is Laptop Media, and today, we will show you how to open the HP Elitebook 650G9 and what's inside of it. To open this notebook, you need to undo a total of 5 Phillips head screws. Three of them are captive and will remain attached to the bottom panel. After that, take a plastic tool and pry the panel, starting around the hinge gaps. Please remember, it would be of great help to us if you just hit the like button and subscribe to our channel. That would motivate us to make even more and better videos for you. Our configuration is equipped with a 42.75Wh battery pack. It lasts for 9 hours of web browsing, or 7 hours of video playback. To remove it, unplug the connector from the motherboard, and undo all 6 Phillips head screws that keep it in place. Here, we see 2 Sodom slots for up to 64GB of DDR4 RAM, working in dual channel mode. Storage wise, there is 1 M.2 PCIe X4 slot that supports both Gen3 and Gen4 SSDs. There is a 2nd M.2 PCIe slot, which fits either a WWAN card or a secondary SSD. This laptop's cooling comprises a single heat pipe, a heat sink, and a fan. If you'd like to see more disassembly videos of the latest notebooks we would highly appreciate if you hit the like button and subscribe to the channel.


Hello. Welcome. Thank you for coming to my talk. I'm going to talk about high-performance transactional queues implemented on top of HBase. My name is Andreas Neumann. I work for Continuity. What is Continuity? We're building an application platform called The Reactor. It's built on top of Hadoop and HBase and makes it easy to develop, to deploy, to manage your applications. And it's really squarely on top of Hadoop and HBase. So we're on top of the open source ecosystem. My agenda is the following. I'm going to motivate. Why are transactions valuable? I'm going to explain how we do transactions and then I will explain how our queues work in that transactional system. If I have time, I might talk about transactions and batch processing and end with a little outlook. So The Reactor is an application platform built over Hadoop and HBase and ZooKeeper and MapReduce and many other of the Apache open source stack components. Here I'm going to focus on HBase. We use HBase as a storage engine. What we do is we allow you to collect data in real-time and store it. Then you can process it in real-time or in batch. You can store the results of that processing and you can query that data through a unified API that we provide. The way that you process data in real-time in this platform is called a flow. A flow is similar to a lot of you probably have heard of Storm or S4 or SAMHSA. There's a lot of flavors of that real-time stream processing now. It basically decomposes the processing into small units where every unit in the flow is called a flowlet. In Storm they're called bolts, I believe. So each flowlet receives events on an input queue. It does something with these events. Maybe it does some aggregation. Maybe it stores it away somewhere and then it emits events to its outputs. And then you can connect multiple of these flowlets into a graph or a topology. That's what we call a flow. And then you can run it and you can feed it with real-time events and it'll do the real-time processing for you. Most of the real-time stream processing engines out there do not really talk about what happens to the data. They just give you guarantees like we will never drop events. We will reprocess if a failure happens or we can replay the events from a certain time. But what happens to the data that you've already written? And then the event gets reprocessed. Now you write again. Do you have to worry that all your operations are idempotent? How do you deal with these scenarios? In this platform we perform the operations of a flowlet in a transaction and that means when a failure happens none of its effects have actually happened. When the flowlet crashes or when the power goes out your data is always in consistent state because the transaction gives you asset guarantees. So this is what processing of a flowlet looks like. You have an input queue. There's events on the queue. The flowlet reads them and now it can emit events to its output queues. And then there is downstream there's other flowlets that consume that. Excuse me. Now of course the flowlet typically will not just do processing. It will persist some information that it has extracted from the event or that it has aggregated. And so in our platform a table is called a data set. We have an abstraction called data set that allows you to store information and now what could happen is that you have two different real-time processors, two flows, and they both operate on the same data set. For example your data set could be user profiles and the same user is watching videos on Netflix and he's also making purchases on Amazon and you happen to get both of those events streams and you have two flows that consume that and they both write to that user profile. So now both of them write to the same data set. The data set is shared. But what happens if they try to update the same record in that data set at the same time? This is what we call a conflict. If we don't take care of this situation then the consistency of the data is at risk because we don't know. Maybe flowlet 2 will overwrite the effect of flowlet 1. Maybe flowlet 1 overrides what flowlet 2 did. Maybe the operation isn't even atomic. Maybe some of flowlet 1's operations go through and some of flowlet 2's operations go through and in a highly distributed system, a scalable system, you may have hundreds of agents running at the same time. So it is very likely that eventually you're going to hit this situation and you better be prepared for that. So that's why we have transactions. Whatever a flowlet does for a single event happens in a transaction. So this includes the reading of an input event from its input queue, the processing and the data operations that it performs as a consequence of that, and then the emission, the writing of output events to its output queues for the downstream flowlets. This happens in a transaction. So what does this mean? A transaction gives you asset properties. A stands for atomicity. Everything you do in this transaction becomes visible at once. Nobody will ever see a partial write from you and either everything gets committed or nothing gets committed. So if you fail halfway, you crash, you run out of memory, whatever, whatever you have done up to that point in the transaction will be undone. How that happens, the system takes care of that, right? Second one is consistency. Consistency means you will never have a partial effect, a partial state change due to conditions that happen. The third point, very important is isolation. So we know that transactions can fail and they may roll back if they fail. If other transactions can see writes of transactions that are in progress, they might make conclusions based on that data. But if that data gets rolled back, then it's actually invalid. And again, your data could become inconsistent. So we provide a strong isolation guarantee, which is that you don't see any dirty writes. And the fourth one is durability. Durability means once you have committed your transaction, it is persisted in a way that you're not going to lose it, no matter what happens. So this is very similar to the traditional notion of asset in relational databases. In relational databases, consistency, for example, refers to a table and its indexes. It can never happen that the table gets updated and its index doesn't. But in big data, it's not much different. Often we make two writes to two different tables or to two different column families in HBase. And one of them might be an index for the other one. HBase doesn't have that feature built in, but your application may have a pattern that is similar to an index. So this idea of consistency is equally important here. So how do we implement transaction? We follow a style called omit, which was introduced to the HBase community from a group in Yahoo. Yahoo research, actually, probably about two years ago. And so we adopted that approach. And what we're doing is, who here is not familiar with HBase? Okay, who is familiar with HBase? Okay, and half of you don't know whether you are or not. Okay, that's inconsistency, by the way. It's not assets. Okay, so HBase, I have no slides on this. HBase is the Apache open source implementation of Google's big table. So it's a columnar store. It's built on top of HDFS, which is the Hadoop distributed file system. It achieves durability in its persistent consistency by persisting to HDFS. And HDFS has replication and failover and all these nice properties. So HBase uses that to get the same guarantees. I don't have the time to go into a lot of detail here, but an important feature of HBase is that for every cell that you write to the table, you can have multiple versions. Each version has a timestamp. And with that timestamp, you can refer to it. And the timestamps, of course, are ordered. When you do a read, you can give it an upper bound for the timestamps you want to see. And then you will only see data that is older or equal to that timestamp. So this is the way that you could do snapshots over an HBase table. What we do for the transactions is we hijack those timestamps to implement multi-version concurrency control. So every transaction is assigned an ID. The IDs are ascending. They only get bigger and similar to timestamps. And so we get a total ordering of all the transactions. And then we use that transaction ID as the timestamp that we use to write to HBase. And then in order to achieve isolation, we read from HBase in a way that there's a filter that filters out all the transactions that have not committed yet. Transactions that have not committed yet are transactions that may have performed the write, which at this time is a dirty write. Or if we would read it, we would call that a dirty read, because we're reading something that we don't know whether it will actually persist. So for isolation, we use an HBase filter that excludes those versions that have not been committed. For avoiding, for consistency, for avoiding two different agents cancelling out each other's writes, we have to do something else, right? We have to prevent that two different flowlets can write to the same cell or the same row of a database at the same time and not notice that they're overriding each other. So in relational databases, this is typically done by locking. When you intend to write to a row of the database, you lock that row. Now nobody else can, it depends on your isolation level, now nobody else can write to it. Most likely nobody else can actually read it.  So that's how it's done traditionally. And we are taking a different approach. We believe that in big data throughput is everything. And locking. Locking an agent that does real time processing, making him wait for somebody else to give up the lock means he's busy waiting. He's just idling and he's sacrificing his precious compute resources for waiting for a lock. What optimistic concurrency control does is it avoids this lock. Instead of locking, we simply allow concurrent writes to happen. And because they use different versions, different timestamps, an hbase supports multiple timestamps for each value, multiple versions. These writes can actually go into the database, into the table without problem. The only problem now is we have to, yeah, so the thing with the timestamps is that if you use, say, microseconds, you may be unlucky. And you could have two parallel transactions starting in the same millisecond. And they get the same transaction ID. So that doesn't work, right? So what we have is, now we're going to detail, we have an oracle that produces transaction IDs. And in a way, they are timestamps. But it needs to make sure that it doesn't issue duplicate timestamps, right? So they go in increments of one. And there's various ways of generating unique monotonic ascending IDs. Okay, so now we say we allow two transactions to modify the same value. Now what we have to do is, when that happens, we have to detect it. And when we detect it, we have to fail one of the two transactions. That's what optimistic concurrency control does. So instead of locking up front, it allows the rights to happen. But then at commit time, every time we commit a transaction, we have to verify that it did not have a conflict with another transaction. And if it did, then we failed the transaction and rolled it back. And then the processing is retried and hopefully succeeds. So the flow is like this. This is what happens in a flowlet, the red stuff here. It starts a transaction and then it does its work. How does it start the transaction? It talks to what we call the Oracle. The Oracle is our central transaction management guru. It's an agent that sits there somewhere in the data center. And its only purpose is to maintain what are the active transactions, that was the last transaction ID I issued so I can do the next one. And are there conflicts between transactions? So every unit of work starts with talking to the Oracle and asking it for a transaction ID. Then you do your work. In a flowlet, that means, yes. So I can go into that later. The Oracle, there's various ways of implementing it, giving you different levels of reliability. The most efficient way is simply having it in memory. But then, of course, if it crashes, it's a single point of failure. So you want to have at least a second replica and the two of them synchronizing each other to get high availability. But there is an implementation that actually persists every right to HBase. And then when it crashes, you can just bring up a new one. But it's less efficient. It depends on how many transactions you need to do per second. If you're talking about several hundreds, no big deal. If you need 30,000 per second, better do some in-memory thing. OK, so now you do the work. Doing the work means I get an event from the input queue. I do my aggregations, my processing. I persist whatever I want to persist. I write to datasets. And I emit events to my outputs. And then I commit the transaction. As part of committing the transaction, I find out whether there are conflicts or not. If there are conflicts, I abort the transaction. And part of aborting the transaction means I have to roll back the rights that I have made to HBase, to my storage engine. I could actually leave the rights there. These are just versions that are stored in HBase.  I could just use the same mechanism to filter out transactions that have failed. But over time, I would build up a really large backlog of failed transactions that I have to filter out at runtime. And I'm going to see performance problems because of that. So what I will do is I will always try to undo the right. So if I did an increment, I can undo that by doing a decrement. If I did a right of a new version, I can undo it by deleting that particular version from HBase. So we always attempt to do that. But if that fails, sometimes we have failure because HBase is down. I simply can't do it. Then we need to somehow keep track of the transactions that were aborted, but weren't able to undo their rights, so they become invalid and excluded from future transactions. So this is the general flow. As I said, optimistic concurrency control avoids the cost of locking up front. And the good thing that we get is we don't have idle processes. We're always busy. Especially, we never get deadlocks.  And you really waste precious time there in real-time processing. Another thing you see in relational database is often there's lock escalations. If your transaction locks many rows of the same table, eventually the lock gets escalated to the table level because it gets too expensive for the database to maintain all those individual locks. And so when you have too many locks on the table, it will simply lock the entire table and not let anybody else access that. And that's terrible too. It just means other agents are blocked from doing their work. So this doesn't happen with optimistic concurrency control. But of course, we have to pay a price for that. And the price is that we pay the price of conflict detection every time we commit. We need to make that check. And if we have to roll back, the cost is higher too because these are now actual write operations, probably IOs in the storage engine, IO operations that we have to perform to undo that transaction. So why do we think it's good? Well, this is good if we know that our application is designed to have few conflicts. If we know that conflicts are rare, then we can pay that after the fact cost for a conflict once in a while, as opposed to paying the smaller cost of locking every time. Why do we think that conflicts are rare? Well, it depends how good you write your code. But typically, when you write a big data solution, you're going to partition the work. You're going to have a flowlet. The flowlet, a single flowlet cannot do, a single instance of a flowlet cannot do 50,000 events per second. Just not doable. So what do you do?  Now you partition the work. If you do a random partitioning, and the flowlet does some writes based on the keys in the events that it receives, now each instance of the flowlet will receive random keys. So you have a chance of conflict. But if you partition by that key that will actually be the key for the write, then you know that writes for the same key will always go to the same instance of the flowlet, and you will never have conflicts. So there are techniques and best practices and design patterns that help you avoid conflicts. And these are patterns that you want to follow, regardless of whether you have transactions or not, for the sake of locality and caching, and just better throughput. So if you follow those patterns, then you actually will rarely have conflicts. And so that's what we are taking advantage of here. OK, so in a little more detail, what does the transaction oracle do? The transaction oracle, and this is a slightly different view of what we saw before. Everything that's red happens in the flowlet on the processing side. Everything that's blue happens in the oracle. So the oracle maintains all the active transactions. So when I start working, the first thing I do is I get a transaction from the oracle. Oracle gives me back a transaction ID. And it also gives me back a filter. We call that a read pointer that tells me what other transactions do I have to exclude from my read. Now I do my work. And when I'm done, I try to commit the transaction. Committing the transaction actually happens through the oracle. We send to the oracle, we send the keys of the rows that we have modified in this transaction. The oracle keeps track of, we call that the row set, the row set of a transaction. So what the oracle has is it has an in-memory map of all the transactions that may possibly have overlapped with any ongoing transaction. This is only all the transactions of a short window of time, as long as transactions are short. So it has a map of all those rowsets in memory. And it can very, very quickly determine whether the intersection of two rowsets is non-empty. And if so, the oracle will come back and say, there's conflicts. If the response is that there's conflicts, then the flowlet will abort the transaction by rolling back its rights, by doing the reverse operation of what it initially did. And when it's done with that, it goes back to the oracle and says, I'm done. Now the oracle can remove that transaction from its list of active transactions. In case the transaction is successful, if there's no conflict, there's no more work needed on the client side. It's only on the oracle side. The oracle will respond, there's no conflicts. The client goes back to the oracle immediately and says, I'm done. And the only thing the oracle does is remove that transaction ID from the active transaction list. And it'll remember the row set of this transaction for a short time. And it'll remember that as long as any transaction that started that might be overlapping, because when that next transaction commits, we need to do a conflict check for that transaction. So the oracle actually becomes key to this. The oracle needs to perform well, needs to scale well, needs to be reliable. The moment the oracle is not there, nothing's going to happen in this system. So kind of tricky. How do we make this oracle fast, super fast, and persistent? So we have been experimenting with various ways of doing this. The best way to do this appears to be to write everything that happens in the oracle to a writer-head log. We don't persist to HBase. It's too expensive. HBase under the covers also uses a writer-head log. But every write to HBase will actually result in probably six writes to disk eventually. Because HBase writes everything to its own tables, and the tables get persisted to a file store, and they get replicated three times by HDFS. And HBase also writes to a writer-head log, and that also gets replicated three times. There are faster implementations of writer-head logs, for example. There's an open source one called bookkeeper. So in case my entire cluster has a power outage or whatever, that writer-head log is persisted. Yes. No. No, no, it's not an oracle database. It's an oracle in the sense that it can make predictions. Like the oracle of Delphi are. Not sure I understand the question. Yes, yes, yes, that's right. Better scale. Air scale? Yeah. Cheaper. We don't have benchmarks, because we are an oracle company. So we don't actually run relational databases. So the whole idea of, it's actually a very interesting question, because when Hadoop started, people saw it as an alternative to the traditional relational databases and traditional data warehouses. Because the traditional databases hit a point where they couldn't scale further. Or the cost factor of scaling out more became so high that it wasn't affordable to scale. Can you scale an oracle database to five petabytes? Very hard, very hard. I don't even know if it can do that, but it's extremely expensive. And you can use other databases that were designed from scratch for more scalability, like Teradata. But it's going to be very, very expensive. So Hadoop came up as an open source, free, cheap software to do analytics over very large amounts of data on commodity hardware with a much lower cost factor. And how could it be cheaper? It was cheaper because it gave up the asset constraints of relational databases. Yeah. That is true, yeah. I see. No, yeah. I guess we can. So just to finish that previous thought, is what we see is that even in big data, you need actual asset constraints. And so H-Base has evolved as one of the major databases used in the NoSQL world. So we implemented it on top of H-Base. We do also have an implementation over level DB. We have one over SQL database. And I'm sure we could implement the same thing on top of Oracle NoSQL. I mean, in the end, it's just code, right? So Oracle NoSQL is not an option that we had when we started this work. I mean, this may exist now. Still Oracle, I don't think Oracle is open source. I don't know that particular. Okay, that's great. I mean, I'm sure you can do similar things on it. I would have to do a deep dive on Oracle NoSQL. What are the asset properties that you get out of it? I don't know. It's an alternative approach. I mean, all I can say is that Oracle, to me, represents the old SQL, the old relational database world. And then this whole NoSQL world has evolved in parallel to the Oracle world, right? And now Oracle is bridging the gap and they're coming over and say, we have a solution too. So yeah, I mean, I'm sure you can use Oracle if you want to. So, all right, so how can we achieve performance and reliability in the Oracle? So we use a write ad log to persist, but we don't actually operate on that. We only use that for recovery. And we have a second replica of the Oracle that in real time replicates everything that the primary Oracle does. And if the primary one crashes, it can take over right away. Well, as I explained, the transactions give you asset properties, but they give you those properties in a different way. And in the traditional asset world, the I means isolation, right? And relational databases have various levels of isolation. Here we only implement one, which is pretty much complete isolation now. What is that called? We call it snapshot isolation. Snapshot, it's actually a flavor of isolation that's not really implemented by most databases. I don't know if you wanna run your financial operations in HBase. I think you probably don't, right? No, so the motivation for this work is to do real time stream processing, right? And you want to have reliable processing and you want the stream processing to be able to persist its state fast. For financial stuff, I don't know. I think eventually this technology will be mature enough for that, but today I don't think that is the domain. Okay, okay. All right, so the motivation for this was, but thank you for the question because it gives me the introduction to cues. So the motivation for this was that we want our flowlets to operate in transactions. And what flowlets do is they read data from cues and they write data to cues. They don't just interact with tables. They also interact with cues.  So a typical cue is a FIFO, right? You write something to the cue. You have producers that push to the cue and then you have consumers and things come out in the same order that they were enqueued. But everything comes out only once, right? So that's the traditional kind of cue. In this case, the cue is slightly more complex. So every consumer of the cue, because we're in a highly scalable system, can itself be a distributed agent. It may have 16 instances, may have 50 instances, and they will all concurrently try to dequeue, try to read from that cue. Also, in a flow, the flow is not just a pipeline. The flow can have a branch. So a single flowlet can have an output that is consumed by two downstream flowlets, which means when an event has been consumed from the cue, we can't just remove it from the cue. We have to wait until all of those flowlets have read all the events. Then we can evict them from the cue. So here we can see this. The green, the light green boxes are flowlets, right? So the first one has two instances. Between the instances of one flowlet, the cue is partitioned, right? Every event on the cue goes only to exactly one of the instances of the flowlet. But there may be a second flowlet that also reads this cue. And it also needs to see all the entries. I'm actually running out of time. So a quick, very quick overview of what the cues do. So a cue and age base is simply a table. And every entry translates into a row. There's two synchronization points for the cue. When I write to the cue, I need to make sure that the elements are ordered. So there's a right pointer, it's basically a counter. Every time I write, I increment that counter and then I insert a row. In case the transaction fails, I'm gonna mark that as invalid. I'm not gonna remove it from the table anymore. The reason is that the right pointer is a counter and we want to have entry IDs in the cue that are consecutive. We don't like to have gaps in there. Because if there are gaps, then we don't know whether the gap is there because a transaction failed and it removed its entry or because a transaction is still ongoing. It has written, but because of read isolation, we don't see it yet. So when we detect a gap, we don't know whether we can skip it or not. So what we do is when we roll back a transaction, we don't remove that entry that we've written because that would cause a gap. We simply put a tombstone on it, mark it as invalid. Everybody who tries to read it will then skip it. So when we see a gap, we know that this must be an entry that has been added to the cue, but it's not committed yet. So we have to wait for that transaction to commit. We can't proceed with the processing because otherwise we would process events out of order. Consumers also have a counter, which is the read pointer. So that's the head of the cue where you read from. And when I dequeue, I do the same thing. I increment that pointer. And because I know all the entries have consecutive IDs, I know I can read the next one. The dequeue needs to be able to roll back too. If the transaction that processes that event fails, I have to undo that dequeue. But the read pointer is actually a counter that is optimized for only incrementing. Do nothing else but increments. And all the code is written in a way that it assumes that this will only move forward. So what we do is every consumer has a state, and in that state it remembers the entries that it has claimed, and that's persisted. So if a transaction, when I do a dequeue, I just put it into that claimed list and then give it to the client. If the client fails, I simply leave it in the claimed entry list. And next time he dequeues, he will see the same entry again because we read it from that claimed entry list. But if the transaction commits, then I have an action to do on commit of the transaction, which is removing that entry from the claimed list so that next time he moves on and gets the next element. And I can actually use the same mechanism to do prefetching of elements. I could fetch 100 at a time, put them in my claimed list, and then I don't need to go back to edge base and read next time. It's like a cache for me. So this is the idea. So what we see is what happens for every entry is in order to enqueue, we have to do an increment and a write. And in order to dequeue, we have to do an increment and then a write, which is the state. So it's four writes for every entry. Something is out of order here. So with that, my throughput is kind of limited because edge base can only do that many writes per second. When I do partitioning, I can get concurrency. And concurrently, edge base can do many more writes. What I can really do to improve my throughput is to do prefetching. When I prefetch 100 or even 1,000 at a time, then that's one I owe to get 1,000. And after that, my state is in memory. If I crash, then I fall back to the last state that was persisted. And everything gets undone. So operating in small batches helps me a lot. And I can still preserve the asset guarantees of my stream processing system. So what we see in our performance test is that we see roughly 10,000 enqueues per second per producer. With multiple producers, we see more. There is a saturation at some point. We haven't seen, with a single queue, we haven't seen more than 40 or 50,000 per second. But that's a pretty good number. There's few real-time processing systems that get more than 50,000 events per second. For DQ, we're a little bit slower. We get about half of that. And that is because the DQ consists of two steps. The first step is claiming the entry. Then we do some processing, and then we come back and we say, we can actually mark it as processed. So it's a two-step, so it kind of translates into two RPC calls. We have a, I don't want to go into this, we have some wish list for HBase improvements. If we would get these things into HBase, our queues would become much faster. And I will have to skip the batch. I can say one quick thing about batch. So when you run batch jobs, batch jobs run for a very long time. MapReduce, in a way, gives you assets. Because MapReduce, even though it runs for a long time, it will commit its output to the file system only if the whole job succeeds. And if part of the job fails, then that part gets retried. And whatever the output of the failed task was, it gets discarded and gets replaced with whatever the retry produced. So Hadoop can do this. And we know that the stream processing can do this. Where we're struggling a little is when you have a data set that is manipulated both by a real-time stream processor and by a batch job. If you would impose a transaction on the batch job, now you would have a very, very, very long running transaction in the batch job. The MapReduce jobs often run for 15 minutes, half an hour, sometimes hours, which means it is so very, very likely that it's going to have right conflicts. So the batch job will always be rolled back. And that's kind of tricky. So what we do is we take a pragmatic approach and we say, if you actually do this, A, we don't recommend doing this. We recommend to use two different tables and then just merge on the fly when you read so that you can segregate the rights. You can isolate them from each other. But if you have to do it, then the idea is that the batch job will run over historic data. So it will not have the latest information. If you have a real-time job that writes the same data, it probably has newer information. So instead of rolling back the batch job in case of conflict, we simply let the short transaction, the one that came from the real-time system, we let that one prevail. Regardless of who commits first or in which order things happen, we say the short transaction prevails. So this is just a pragmatic approach and strictly speaking it violates acid. But sometimes you have to take this kind of short cuts. I don't know if we have time for questions. We started five minutes late. Well, thank you for your attention.