Understanding Funds Transfer Pricing in SAS Asset and Liability Management

Every bank wants to know one thing above all: where does the money actually come from? Which parts of the business are pulling their weight, and which ones only look profitable on the surface? Funds transfer pricing, or FTP, is how the solution answers that question.

The purpose of this post is to explain what funds transfer pricing does in SAS ALM on Viya, walk you through how the workflow runs from raw data to a signed off report, and open up the calculation itself so you can see how the solution builds an internal rate for every transaction. Whether you are an experienced ALM user or just starting out, you will come away with a clear understanding of how the solution puts a fair price on the money moving through a bank.

What funds transfer pricing really does

A bank has a treasury and two kinds of teams. One team takes in money, mostly through deposits. The other team lends money out, through loans and mortgages. On their own, neither team can tell you how much profit they made, because they share the same pool of cash in the treasury. The deposit team brings money in, the lending team puts it to work, and the profit gets tangled up between them.

FTP untangles it. It puts a fair internal price on every euro that moves through the bank. When the lending team uses money to fund a loan, they pay an internal rate for it. When the deposit team brings money in, they receive an internal rate for it. That internal rate is the transfer price. Once every product carries one, the solution can finally show you the true margin of each part of the business.

Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.

A simple way to understand it

Here is the part that trips people up. A dollar is a dollar. One hundred dollars has the same face value whether a child borrows it for a bicycle or a child saves it from a birthday. So what could there possibly be to price?

The answer is that funds transfer pricing does not price the amount. It prices how long the money is tied up and how likely it is to come back. Take a family where the parents act as a small household bank. One child wants to borrow money for a bicycle and will pay it back slowly over a couple of years. Another child hands over saved birthday money but might want it back any day. The parents charge the borrowing child more, because that money is locked away for a long time. They pay the saving child less, because that money could disappear tomorrow and cannot be relied on. The rate reflects the time and the risk, never the size of the note.

A bank works exactly the same way. Money lent out for a thirty year mortgage needs long and stable funding, which is expensive. Money sitting in an account that can be emptied tomorrow is cheap, but it cannot be counted on. The lending team is the borrowing child, the deposit team is the saving child, and the treasury in the middle is the parents. FTP is simply the set of fair internal rates the parents use, built around how long each dollar stays put and how risky it is. That is why, at the end of the month, everyone can see who really contributed to the family budget and who quietly cost more than they brought in.

How the workflow runs, stage by stage

The FTP workflow in the solution moves through five clear stages. Each stage has an owner, so the work passes from one role to the next like a relay.

Ingest data. A data analyst loads the portfolio records, and any optional synthetic instruments, into the solution. They point the solution at the right data sources and register the staging tables as analysis data objects. This is the raw material for everything that follows.
Process data inputs. The same analyst runs a data quality check to catch records with missing or invalid values before any model touches them. If the quality is too low, they apply automated correction rules and run the check again, repeating until the records are clean enough to trust.
Configure assumptions. A quantitative analyst sets the rules of the run. This is where technical models get assigned to the different products in the portfolio, so every instrument is linked to the correct internal price tag. The analyst reviews these assignments to make sure nothing is missed.
Run transfer pricing calculations. The quantitative analyst executes the run. The solution uses the configured models to produce the base rate and any adjustments on top of it. The analyst then reviews the output for errors and gives technical approval once the numbers reflect the way the bank really prices its business.
Sign off and final review. A manager reviews the full trail and either approves or rejects the cycle. Approval locks the cycle so the data is preserved for auditing and for official financial reporting. Nothing can be quietly changed after that point.

How the rate is actually calculated:

This is where the real work happens. When the calculation runs, the solution builds the transfer rate for every transaction in two layers: a base rate that comes off a curve, and an optional set of adjustments stacked on top. Understanding those two layers is the key to understanding FTP.

The base rate is anchored to a pricing curve. This is a yield curve that lists an interest rate for each term, from very short to very long. Each transaction is matched to a point on that curve according to how long its money is committed. A five year fixed loan is priced off the five year point, an overnight deposit off the short end. This is the matched maturity idea: the rate follows the term, so longer commitments naturally carry a different price than short ones.

How a transaction finds its point on the curve depends on the pricing method assigned to it. The solution offers several methods, so you can pick the one that fits how a product really behaves. A few of the common ones:

Term based. The rate is taken from the point on the curve that matches the term of the instrument. A five year loan receives the five year rate. For a floating rate instrument the term is the gap between repricing dates.
Duration based. The rate is taken from the point that matches the duration of the instrument rather than its final maturity. A five year loan whose cash flows sit, on average, at two and a half years receives the two and a half year rate.
Weighted average life based. Each principal payment is weighted by how far out it is paid, producing a single average life, and the rate is read off that point on the curve.
Locked in spread. Instead of reading the curve directly, a fixed spread is applied to the current customer rate. For an asset the transfer rate is the customer rate minus the spread, for a liability it is the customer rate plus the spread. A loan with a ten percent customer rate and a two percent spread receives an eight percent transfer rate.

The point to take away is that the base rate is never guessed. It is read off a defined curve using a defined method, so the same instrument priced on the same day always lands on the same rate.

The adjustment layer

The base rate is the foundation, not the final word. On top of it the solution can apply adjustments to capture things like a liquidity premium or specific product behaviour. These adjustments can be applied right down to the individual transaction, so a single deal can carry its own adjustment rather than inheriting one blanket number. The final transfer rate is the base rate plus the adjustment, and the output keeps the two separate so you can always see how the final number was built.

From rate to margin

Once each transaction carries a transfer rate, the margin falls out by simple subtraction. For an asset, the margin is the customer rate the bank charges minus the internal transfer rate it pays for the funding. For a liability, the margin is the internal transfer rate the bank receives minus the customer rate it pays the depositor. That single subtraction, repeated across the whole portfolio, is what finally separates the contribution of the lending business from the contribution of the funding business.

Two kinds of reports

When the calculations are done, the solution gives you two very different views of the same results, and it helps to know which one to reach for.

The first is the raw analysis data, which works as the detailed diagnostic log. It is the output tables you can export into a spreadsheet for manual checking or technical auditing. Every number is there, in full detail, ready to be picked apart.

The second is the Visual Analytics reports, which work as the executive control panel. They are interactive dashboards that highlight trends and risks at a glance, and let you drill down from a high level figure into the individual data points behind it. Here below a mockup of such a dashboard from the solution.

Conclusion

Without FTP, a bank is guessing. A loan that looks profitable might be funded by expensive money. A deposit product that looks like a cost might be the cheapest funding the bank has. FTP replaces the guesswork with a fair internal price on every dollar, and the workflow in the solution turns that idea into a controlled, auditable process that runs the same way every time.

That is the whole point. Bring in clean data, set fair internal rates, run the numbers, and get going with business. The value that FTP brings is that you can look at any part of the bank and say with confidence, exactly what it contributed.

For more information on SAS Risk Management Solutions visit the software information page here. For more information on curated learnings paths on SAS Solutions and SAS Viya, visit the SAS Training page. You can also browse the catalog of SAS courses here.

For more details on FTP, the SAS ALM documentation provides step by step guidance. And as always, feel free to reach out if you have questions about applying these concepts to your specific situation.

Find more articles from SAS Global Enablement and Learning here.