Case Study: Deposit Valuation Analysis - Using FHLBank Boston Advances to Efficiently Price Deposits

Hey everybody. Welcome to part two

of our case study around deposit valuations and how to leverage that information to make better

funding decisions.

Once again, I'm Sean Carraher, and I joined the Federal Home Loan Bank of Boston just a couple of

months ago in May of 2022.

I have over 20 years of experience in the industry, and I'm well versed in asset

liability management.

I've been the treasurer of two different multi-billion dollar banks in the immediate Boston

area and have chaired ALCO groups, created and run funding and derivatives strategies, and created

and managed profitability and risk frameworks.

At the end of the first part of this case study around deposit valuation,

we recognize the fact that we already have ALM metrics that are associated with the economic

factors that create value for deposits.

And, we can leverage those metrics to create a framework that will put a

number against our deposits to actually use in different kinds of quantitative

analysis.

And so, very briefly, again, those economic attributes are the degree to which pricing will

adjust, which is the beta.

The speed with which pricing is going to adjust, which is the lag.

The volatility of our balances,

which is the decay rate.

And the amount of time over which the deposit is expected to remain outstanding. And that's

the average life.

And the fact that our deposits have an opportunity benefit instead of an opportunity cost relative

to other sources of funding because we'll be able to use those client relationships

in other ways. 1:48

So, how are we going to do this? How are we going to go about creating that framework that combines

all those attributes?

Well, first, we're going to take one of those pieces of intuition that we had in the first part

of the case study and recognize the fact that not all accounts and not all deposit products

behave the same.

And so, we can bucket balances within a deposit product by a combination of the

repricing behavior of that product and the volatility of that product.

So, some balances are

going to be really price sensitive, and some balances are not going to be price sensitive.

Some accounts are going to be more volatile,

and some accounts are going to be less volatile.

We can use that information to start to create buckets of dollars, and assign … a percentage of

that overall product to that bucket.

Then we can look at each one of those buckets and create a term, that is a period of time,

that's associated with that behavior.

So, [if] something is not very price sensitive and it's not very volatile,

then it probably has a very long life.

And if

something is really price sensitive or if it is really volatile, then it has a very short life.

Then finally, we're going to add a premium to each one of these buckets to recognize

the fact that, irrespective of the economic attributes of the bucket,

it has an opportunity benefit

relative to other sources of funding.

A lynchpin in creating the framework for this deposit valuation methodology is the

recognition of a hidden mathematical relationship that exists when we identify deposit betas.

While we

normally think of using deposit betas as being applied to all the balances in a product type,

mathematically, we can theoretically divide the balances within a product type into two buckets:

3:37 one bucket that is 100% price

sensitive and one bucket that is 100%

not sensitive, and the size of each one of those buckets is the

beta.

So, for example, if we had a money market account that we assumed had a 60% deposit beta,

what we're actually mathematically saying is that 60% of the balances have 100% price sensitivity.

And 40% of the balances

have a 0% price sensitivity.

And so, when you put those two buckets together, you create an overall sensitivity of 60%.

But we can differentiate that into 2 pieces. One piece is really fully sensitive,

and one piece is really not at all sensitive.

Now, in reality, not every account is going to behave that way, not every account is fully

sensitive or insensitive.

But theoretically mathematically, we can create these two different buckets that sort of create

a framework in which we can now start to think about differentiating different types of accounts.

Deposit betas allowed us

to break an undifferentiated mass of balances in a product type into two discrete buckets.

If we introduce the concept of volatility,

we can now start to break it into three different pockets,

and if we think about what volatile balances would be, first off, if we remember from our

first slide upfront, that every attribute, every economic attribute, has an associated ALM metric,

we can recognize that the decay rate that

we're using to build our eve or any eve modeling, it's essentially the volatility estimate,

and we can also then take a step back and say OK, if a balance is volatile, how do I put that in the

framework of deposit betas?

Is it price sensitive or is it price insensitive?

And I suspect you'd agree that a volatile balance is sort of, by definition, highly sensitive.

And so,

therefore, a volatile portion of our balances is going to come out of the price sensitive bucket.

So, an example that's on the slide, we said,

OK, there was going to be a 60% deposit beta, so 40% of our balances are price insensitive,

and 60% were going to be price sensitive.

Now, what if we assume that we have

a 10% decay rate which is effectively asserting whether it's going to have a 10% average life.

If there's a 10% decay rate on the

product type, then 10% of the overall balance is both sensitive and volatile and now 50%,

the 60% upfront minus the 10% volatility is now sensitive, but not volatile.

That is, these balances are price sensitive,

but they're not here today, gone tomorrow.

The volatile balances are here today, gone tomorrow, and the non-volatile, price-insensitive

balances, are going to stick around indefinitely.

So, we've created three buckets just from two economic attributes: the beta and the volatility.

And the volatility

is the decay rate.

We've created these three buckets based upon the price sensitivity and relative volatility

of the balances within a product type.

And so that insensitive non-volatile bucket,

we can call that core fixed. It's funding that's not going to move around its core funding,

and it's not price sensitive.

The highly sensitive, highly volatile bucket, we can call non-core float because these balances are

not core balances.

They're balances that could be in flux and they're, they're price-sensitive balances.

And then the in-between bucket

are those balances that are core funding, they'll stick around but they'll stick around if we pan.

And so that's sort of the

in-between hybrid core-float piece.

Now we set upfront in the framework that not only do we have to identify the different

kinds of buckets or the size of the buckets within this framework based upon repricing

and volatility characteristics, we have to put a term against each one of these.

Remember, if we're going to value a bond,

we need to know the cash flows, and we need to know how long those cash flows are going to last.

Well, within this framework, if we have a piece

of the puzzle, that's this core fixed bucket that isn't price sensitive, and isn't very volatile,

it's not responding to price inputs and its behavior. It's only going to respond to life

events, so to speak, within its behavior.

So, the term of it is the average life. It's got a very long life associated with it.

The non-core float, the really

volatile price-sensitive piece, is assumed to have only an overnight value because those are balances

that are here today and gone tomorrow.

And then the in-between piece, the core float has a life that's the, that's the

same as our lag term that we're using it and I'm modeling, that is to say those balances will stay

so long as we pay him within some timeframe.

And that timeframe doesn't have to be today or tomorrow.

It could be two months,

three months, six months, a year, but we're going to have to pay them to keep them happy.

Upfront we identified that there were five economic attributes that created value

for deposits, and we've used four of them.

We figured out the price sensitivity, we figured out how quickly prices will change,

we figured out volatility in average life, and we use the deposit beta

to figure out the initial buckets and then we add in volatility to identify three different buckets.

Then we tried to figure out the term by

looking at average life and the lag terms.

The last piece of the puzzle is the economic benefit.

The opportunity benefit, having client deposits

relative to wholesale funding in the first place.

So, I think it's clear that client deposits do have value over wholesale funding sources.

Typically, they're not collateralized.

You can facilitate client

development by using deposits, and they can reduce your capital and liquidity, liquidity requirements

through regulatory perception.

So how do we figure out the value of those deposits relative to wholesale funding sources?

And this concept of term liquidity

premium can accomplish that, and very simply, it's just the marginal cost of borrowing relative to

the swap rate associated with the long term.

So, an example that's on the slide and left-hand side.

If we know that a 10-year advance is

3.71%, and a tenure swap is 2.62%, the liquidity premium’s just the difference in those two things,

which is 1.09%.

That is to say, the marginal cost of locking in your liquidity of funding

for your balance sheet is 109 basis points relative to just taking care of the interest-rate

risk in a swap.

So, that represents the value of having client liquidity versus wholesale

funding.

Let's walk through a couple of different examples about using this framework to value different

types of accounts.

So, on this slide, we're taking a look at an average sensitivity NOW

account.

And the key assumptions around that account, which could be taken or derived from the ALM modeling

that you are already accomplishing,

is identified in the light green up on the right-hand side.

So, the rate paid on this

account is 25 basis points.

So, NOW account. So, it's got some beta, but it's not very high, 30%.

The lag pricing assumption is that

it won't reprice for six months.

The decay rate’s 8%. 11:53

It's got some fee revenue and servicing costs, and deposit insurance associated with it.

And the deposit

life in this tool is just assumed to be the inverse, the reciprocal of the decay rate.

That's just a mathematical truism.

So,

given those assumption inputs, if you recall how we put together the framework,

we know with a 30% beta that means there is a 70% core-fixed allocation.

That is to say 70% of

the balances in this account type are assumed to be not volatile and not price sensitive,

while 30% are assumed to be some

combination of volatile and price sensitive.

And so, you see here that the non-core float is the same as the decay rate, 8%.

So that's the percentage of balances

that are assumed to be volatile

because the decay rate is the amount of balances that are assumed to be gone within a year.

And then the core float piece,

the piece, the balances that are price sensitive, but not particularly volatile,

that's 22% of the overall pie because if

we pay those balances, they'll stick around.

And then we know the term associated with each one of those things.

The core fixed has a very long life,

and that's this deposit life number of 12.5.

And so, we look to the swap curve to figure out what's a 12.5-year swap worth. And it's worth

266 in this example.

The core float piece is basically, the pricing lag.

And so, what would be a six-month

rate. In this example, it's 284.

And, again, those numbers may seem a little odd right now, but that's because the yield curve

right now is inverted.

Then, finally, the non-core float just gets an overnight rate, and as I record this,