Name: Financial Insights with Workday: KeyBank Achieves Rich and Multidimensional Profitability Insights
Uploaded: 2025-02-27T04:16:12.260Z
Duration: 1 h 4 s
Description: Financial Insights with Workday: KeyBank Achieves Rich and Multidimensional Profitability Insights

Transcript for "Financial Insights with Workday: KeyBank Achieves Rich and Multidimensional Profitability Insights": Thank you very much for joining this workday webinar on financial insights and how KeyBank has been able to achieve rich and multi dimensional profitability insights. This webinar is part of a webinar series called Looking Forward with Workday. This series has been designed to give you insights into how your organization can do more with Workday and in particular, how to better manage your people and your business. During this webinar, we might be talking about unreleased product features or functionality. However, you should make any potential purchasing decisions based upon services, features, and functions that are currently available. Couple of housekeeping items. This webinar is being recorded and we will share with you the recording afterwards. We definitely welcome any question that you might have and please use the chat box on the right side. We are leaving some time for Q and A at the end of this webinar. We will be asking a couple of poll questions during this webinar in order to better understand who you are and then tailor the content of this webinar throughout the way. Then finally, you should expect an e mail within twenty four hours with the recording of this webinar. Let's get started with a quick round of introduction. My name is Jeremy Sepp. I'm in the Product Marketing organization here at Workday. I focus on a product called Workday Prism Analytics for the office of the CFO. I'm joined today by Scott, Joe, and John. Scott, can you? Sure. Scott Moyer, product marketing director at Workday. Been here almost four years. Former CFO, very excited about the topic today. I'll turn it over to Joe with KeyBank. Thanks, Scott. Joe Luffman, KeyBank finance manager. So I'm responsible for management reporting. Really owning methodologies and execution of creating all of our management reporting, line and business profitability, product profitability, etcetera. John? Yeah. John Barr, with KeyBank in the shared services area within finance. Been doing reporting work, within the banking world for the last twenty five years. My role here is primary architect for everything accounting center here at KeyBank and a number of prism development efforts like the management ledger we're going to talk about. Thank you. Thank you, everyone. Here's the agenda for this webinar. I will get started with an overview of what the Prism Analytics for Finance. Then I will transition over to Scott, Joe, and John who will share more about KeyBank and how they've been able to leverage Prism, Accounting Center, and other financial solutions in order to unlock profitability and insights by business, product, and customer, and also how they've been able to allocate revenue and cost of goods sold, indirect expenses, and capital. We will conclude with some of the key outcomes that KeyBank has been able to achieve. We will share some key takeaways. Finally, as I mentioned previously, we will wrap up with time for Q and What is Workday Prism Analytics for Finance? It is a Workday product. It's a highly scalable data hub that helps you bring data from various data sources that live outside Workday and combine those data with your core Workday financials and HR data in order to provide you with comprehensive analytics and reporting. Prism has been designed for business users like yourself. What it means is that finance users can leverage its user friendly point and click interface in order to ingest, cleanse, transform, and analyze data without relying on IT. This analysis will unlock financial insights that you will be able to share securely across your organization, thanks to Workday the consistent security model and our reporting tools. This will help you and your organization act on those financial insights so that you can make better, more confident data driven decisions and increase overall profitability. Finally, Prism has also been designed to coexist and complement your existing analytics ecosystem, for instance, through integrations with your Cloud data warehouse or other BI tools. More than 1,800 organizations already using Prism. It is a very powerful and scalable tool. As you can see, more than 1,000,000 users leverage Prism every month and more than 100,000,000,000,000 rows are being processed any given month. What it means for your organization is that as your business grows and your analytic needs and data grow, Prism has got you covered. Here you can see the top five financial insights that you can unlock thanks to Prism and other workday financial solutions, profitability, M and A, Spend, Workforce Financial, and Operational Insights. Today, we will be focusing on Profitability Insights. Now, I will hand it over to Scott. Thank you, Jeremy. I'm going to let Joe start this off and give us a little bit of an overview of KeyBank, and we'll go to the next slide here. Great. And it it does look like we we have quite a few, bankers bankers on the call and FP and A folks. So hopefully, a lot of people, have at least heard of KeyBank. We are a regional bank. Our footprint is really spread across the country, headquartered in Cleveland, Ohio, but we definitely have a big presence in the Midwest, Northeast, and then some areas out out West as well, Washington, Oregon, Colorado. So we have 18,000 employees, a 88,000,000,000 in assets. That was as of a few quarters ago, but not sure it's moved too much. That puts us right around top 20 banks banks in the country. We have about a thousand branches. And then from the list of of Workday products here, you could see we pretty much are are using a full suite of Workday products. We were always on on, the human capital management platform. But then as of, I think, May of twenty twenty one, that's really when we went live on the finance side. So we built out and converted our general ledger and also, at the same time, made the decision to leverage Prism Analytics for, management line of business and product prop profitability, as well as Adaptive, for planning and forecasting as well. So moving on, I I guess, as we talk about that journey, some of the challenges we faced prior to converting, we were on a thirty year old mainframe general ledger. Right? So many of you that that are on kind of a dated system know some of the the the struggles that come with that. At the time, the general ledger was ingesting something like 85 different sources of data, was was feeding through the general ledger. We and we had limited dimensionality. Really, we were using the account dimension, for example, to break down things that really were attributes or different products or or things like that that really made things a challenge. I I think John can can comment in a second, but the number of accounts we had prior to conversion was in the many thousands. I wanna say, like, 25,000 GL accounts. And it it was a big problem. And then on top of that was a lot of what we needed to do for profitability. That system just didn't lend itself to data transformation, data enrichment. So what was happening is is a lot of extracting and a lot of Excel work. So much time was spent, as you can see in the kind of the third bullet here, 85% is is probably a good estimate of of finance time was spent, you know, putting data into Excel files, manipulating it to create allocations and and different management reporting processes, reloading the data manually back into the system, having to validate it, etcetera. So, really, these were all problems we wanted to solve and we believe Prism could solve for us, as far as kinda that that one source of the truth. And why don't I actually turn it over to John who can kinda talk a little bit on the technical side about what what Prism was able to deliver for us. Yeah. Thanks, Joe Luffman. So those metrics that Joe Luffman mentioned are very important. Right? We had a thirty year old general ledger. Our management ledger was only a few years, after that, and we had no data warehouse, no data lake at the time. So with those limited dimensions and having 16,000 cost centers and sixty eight five hundred ledger accounts, our general ledger basically had to service all of our reporting needs. So when we went to look at the future in Workday, we're like, okay. We got now all virtually unlimited dimensionality. Let's streamline all of that and may and use the dimensions for their proper use. So things like application source that were embedded in our ledger account or product, as Joe Luffman mentioned, that was embedded in our old cost center. Like, we pulled those out. So we're we went from 16,000 cost centers to 1,600 and from 6,500 ledger accounts to a thousand. And then we created a product dimension. So we did all that streamlining before we even went through and said, hey. Let's let's now influence software. So that was very helpful in the process. Again, when you think back to where we started, we had no data lake as I mentioned. So, therefore, we would send all of our source system detail at a transactional level, summarized to our general ledger, and we bring instrument level detail for deposits and loans and such into our management ledger, all those financials. And therefore, we naturally had a point of reconciliation, which was very painful. Right? You had to reconcile those pieces, on a monthly basis at a minimum, figure out where the plugs need to happen. Then, for any enrichment you were doing in the data, you had to deal with those plugs and how to enrich those properly, and we're going to talk about that a bit in the future. Our challenge was, hey, let's optimize. Let's not just upgrade software, let's optimize our environment. Let's enable finance. This was a finance journey. It wasn't a finance event. It was a journey for finance. It was for finance only. We weren't looking at the enterprise as a whole to solve their needs. We were wanting to be efficient and just transparent in all the data we were creating and how it got there and explain any, any issues any of our consumers had with that data. So that's what we're gonna get into. And we solved most of those problems through Prism and the Workday general ledger along with accounting zone. Thank thank you, Joe and John. I just wanna make a point down there at the bottom of the screen. Right? This is a journey. It's about data. Right? And it's really about the finance role. Joe I love this quote from Joe. Finance role has changed from a report producer to more of a strategic partner using all the analytical data now available for business cases and investment decisions. This is Prism, fundamentally, is about bringing data from other sources into Workday so you can see have one source of truth for all your data, and I think these guys have accomplished that. Now we're gonna talk about the business side of this a little bit more. So what are the use cases that we're talking about? There are really three that were the let's say the the the mandate for them was to get these three use cases in place. One of them was, can I get profitable? I call this profit by x, profit by line of business, profit by product or SKU, and then profit by customer. These are the three questions that started this. And how do you how do you get to those endpoints? So, you know, starting with the end in mind is is really the way to think about this. If you look to the far right, you've got these, multiple reporting requirements, as I just mentioned. On the right, line of business, product, and customer profitability. Sounds pretty easy. How how do you get there? Right? So you have to think about what kind of, what kind of data do you need, what calculations do you need to make to get to that level of of profitability, and this should should make sense to everyone. It's a pretty much a a the same as you would look at a a p and l and balance sheet. Right? You gotta have revenues and then the associated cost of goods sold that go with that, and you gotta be able to do that by line of business, by product, by customer. Same for indirect expenses, the things that's some of those that get allocated out, so we have things that are common that need to be allocations. Everyone on this call is familiar if you're on FP and FP and A with their massive amount of work you have to do to get the allocations right and the drivers you need to do that. And then finally down there at the bottom is what's the capital part of this? And capital is is not, is not just for the banking industry. Capital, as we'll get into in a minute, is is a is important for every business to understand where are they consuming capital in those business units. So if you think about any industry, you'd want to be able to attach your your use of capital and allocate it appropriately out to those different lines of business products, etcetera. And I'll just make a quick point on this. Anyone who's understands the the concept of economic value add or economic profit knows why that's important, particularly that capital. And what economic value, the way you calculate it is really no pat minus a capital charge. Right? So you have to think about how much cash flow you you generate and based on the capital you put into it. So how do you how do you know where you're investing your capital inside of your business? This is something that is a tough nut to crack, and I think KeyBank has done an incredible job cracking this, again, for the banking industry, but it applies to any industry. To get a little bit more granular and kind of what we call the the, let's say the, I'm sorry, I didn't I didn't advance that, economic profit calculations there. To the left, you can see what we're talking about. Gross margins, operating profit, and then allocating those capital costs. We're gonna go through all three of those sections, one by one to give you a sense for how we we built out these management reports. But before we do that, just a quick pause and a look at the, what we'll call the sort of the financial data hub, the single source of truth. This is what we sort of an architecture view of the business. Joe and John, you wanna give us just a little bit of a, an overview of what we're looking at here in terms of your architecture. Yes. I can touch on it conceptually quickly, and then I'll I'll hand it to John for the more technical explanation. But, really, I love this view because this this box in the middle here you see is really what what Prism looks like. And within that transformation box, you know, the I I'd like to think of these as all mini modules of things that used to be done in spreadsheets as I alluded to before, where now within Prism, we're calculating cost allocations. The cost of goods sold that Scott just referred to, really, that's FTP in the banking world. A lot of bankers on this call. Hopefully, people are familiar with that. But there's a number of other ones. Here, we just showed six tax allocations, the capital allocation. It's all happening within Prism here, all that data enrichment. And the good news that was always a problem before is all these arrows that you now see pointing into that main box. Right? So it's not just the general ledger that's feeding in for management reporting anymore. Right? We've got all the the external data. Every all the statistics we need from sourcing systems at a transactional, at a loan level, at a deposit level, so that we can really get to a low level of granularity when creating some of these these transformations. And then, also, not gonna get too much into Workday Adaptive today, but you you do see that on the right of the screen as well that we've also created that that loop with with Adaptive planning as well so that all this data can move seamlessly between the two. Right? Whenever we're done with actuals, we wanna pass it along to forecast so that if any given forecast scenario can reflect the most recent trend in actuals. But at the same time, once we're done with a forecast, we wanna pass that data back into Prism so that at the end of the day, we can report against it and we can determine how did actuals come in relative to forecast, where do we have, variances, etcetera. So, John, you wanna you wanna jump on some of the more technical side of it? Yes, sir. Given that this is a PRISM kinda discussion, this is by far the most important slide you'll see in the deck. It is my favorite slide by far. It is for KeyBank, the North Star for by which we make all of our decisions. Right? This is our design for the future slide. So as Joe mentioned, that that big box in the center, right, all but within Prism Analytics, we we do not send data back and forth outside of Prism to do to satisfy our management reporting needs. That bottom area below the box, right, that's our data lake. Right? Didn't exist back when we had our old general ledger. We were feeding source systems directly into all the different places that needed them. Now they're single threaded. Right? We feed all those source systems in, that are needed for accounting through accounting center. Those same source system, from the data lake feed are finance data hub, which is a super cool concept and we're very close to having that fully built out. But basically what happens, right, all of our loan deposit investment systems, feed accounting center, at an instrument level, those things, all those transactions get reconciled and posted to the Workday general ledger with the attribution needed to do that. A a a different set of data goes to our finance data hub. Right? And so that's staying at an instrument level, but things like collateral and other, attribution of of a loan or a deposit or other instrument would go into Finance Data Hub. The linkage there between Accounting Center and Finance Data Hub is that instrument key. Think about that future state. When we want to report instrument level data for federal for fed reporting or for internal reporting, we can get all the postings for a given instrument that actually posted to accounting center. We don't have to pull them from the source system, reconcile them to our GL and say, yeah, these are the these are the financials that posted with this plug. So that's a huge piece for us and that's that's living today for all these sources we enabled in our accounting center. That transformation box that Joe mentioned above is, as he said, modules. But for us, it's reusable components across all those arrows that you see going in and out. Right? So we have adaptive planning, sending plan and forecast data to that box. We have the Workday general ledger sending data into that box. And we have instrument level detail from FDH going into that box and getting the same methodology for funds transfer pricing, for cost allocations, for all those things. So that when people say, hey, my plan and my actuals don't look right for these indirect costs, or allocations. There's no methodology discussion. It's all a question of what the drivers were and what the rates were that were used to drive those costs. So, again, I can't say enough about how how important this picture is for us at KeyBank and, and everything we do for Build for the Future has to reconcile back to this picture. And I think you might have touched on this, but there's a direct question I wanna make sure we're answering, which is, coming from our our one of our participants. Is your EDW, electronic data warehouse, data lake robust enough that you would still continue to use Prism? Asked differently, how does Prism complement or compete with your EDW? Great question. Yeah. So, that's a that's an excellent question. So the data lake is enterprise wide. Right? It has various layers to it. It has a sourcing layer, right, which is just the raw materials from all the source systems without any really transformation or otherwise touching interpretation of that data. That's what we use. And then on top of that, they have an integrated layer and some other things that, other consumers use. We built Workday Prism, analytics and this finance data hub for finance only. Right? We bring in the data and we transform the data for finance's needs. At the end of the day, there are a number of items that we will be authoritative on in accounting center like the work tags of product and cost center and ledger account. The finance data hub will ultimately be authoritative on some items as well that they need to support regulatory reporting. We will then send that data back to our data lake, right? At an instrument level so they don't have to try to replicate how we transform that data. They just get the instrument and they say, here's all the Workday worktags and here's the finance data hub enrichment pieces and it's added back to the data lake so consumers there can get the benefit of what is a finance view of data. Another question is, did you implement any data quality checks in Prism? If so, what kind of, you can't read this, sorry. What was the thought process but what's behind your design, I guess? Yeah. So the biggest part of our data checks at this point and and they're evolving. Right? We have a number of those right before the data even gets to the finance data hub. But within the finance data hubs processing flow, there are data checks for, record counts and domain values and and basic critical data element kinda checks to make sure that the data we're getting is is right in at least in terms of volume and the the critical data elements having been populated. We are then working and we have it this is more manual right now where right? We have published datasets or or tables and and, disco boards that will allow us to quickly validate things. But we're also ultimately looking to have an automation process, an orchestration process, if you will, look at control totals in an automated fashion and say, yep, everything looks really good. Go ahead and and review it manually. So that's a that's an evolving process, but we've we've made a a number of strides there to automate a lot of those controls already. Hey, John. We're getting a ton of questions, which is awesome. I may defer some of these towards the end just so we can get through some of the the meat of this, but one that's come up is how do you decide what's in the data warehouse versus the data hub? So what what's that's a great question. The finance data hub, specifically named finance data hub, I'll I'll mention that. How do you differentiate between that and sort of your more broad data warehouse? Yeah. I'll I'll just keep going back. Right? This journey was for finance. Right? We every time we tried to do something within the data warehouse to define a enrichment or a data element transformation or a a subject matter, it was a long process and a bunch of people had to buy in who were for us to change an element to to change the definition of an element. We did not want to be in that business. We take the elements we need to support all of regulatory reporting, and that was a primary goal. We consume all of those into finance data hub. We will enrich the data we need for finance, and we are happy to share that back to the, enterprise data warehouse. But that was that was not one of our, consumers. Right? The enterprise was not one of our customers. It was the finance folks, the lines of business and the people within the finance world. So Very selfishly, one source of truth for finance, not for everybody. So very, very Very well spent. Yes. So, moving on a bit. Again, we have got lots of great questions. We will get to them, in the q and a section. But I wanna now start talking about the different elements. So that that we mentioned three elements. Right? Matching revenue and cost of goods sold, indirect expenses, and capital. And when we get to capital, that's gonna be an interesting conversation. But I want people that are on this call not from the banking industry. When you hear our team talk about FTP, what they mean is funds transfer pricing. And that is basically in a let's say in a retail environment or in a different world, it would be the cost the cost of doing that business. So it's almost like it approximate cost of goods sold. So let's we'll we'll delineate further when we get to the capital section. But when we talk about revenue and cost of goods sold, these guys are gonna talk a lot about FTP. What what they mean is really how they get their costs into the revenue lines and how they do the matching. So starting off with that, I'm gonna turn it back over to to Joe. Let's let's walk through a little bit on on the, you know, how you match revenues with cost of goods sold down to that level, right, down to that reporting level. And for each of these slides, you'll see, this main slide will show kind of the conceptual finance requirement. That's so Joe is what I call the wow. Right? He's the he's the wow of the business, more the business side. And then John's a little bit more on the technical IT side, so he will be more of the how. So wow versus how. On the wow side, Joe, kinda give us an overview of what needs to be done from a financial, reporting perspective, management reporting. Yeah. For sure. And and and, I actually started this the the the second row because I I think this one is is just a real simple example that goes back to the diagram we just showed and how John talked about that transactional level data that's now available to us dynamically. And this just, relates to debit cards. So anyone who has a debit card, you know, every time you swipe it in a store basically, we have a third party provider that helps us with the kind of the network, the approval, and we pay them about 22¢ per swipe. And that's a that expense is all paid out of one unit, and and we want to ensure that that charge is properly allocated out to the right lines of business. So what really happens here is that data is all contained in that finance data hub, and through the accounting center at a transactional level. So what what used to probably be something that was exported into Excel, someone did the math and had to reload it in, it's very dynamic now that each month we're able to understand every transaction, what cost center owns the customer, the customer rolls up to what cost center. We apply the 22¢ and really create the entry. And in any given month, you know, if if any line of business sees that they had some sort of spike in their expense, it's very easy for us to show that, hey. You went from 7,000,000 transactions last month to December for whatever reason. Usually, it's like seasonal in the summer and in December, holidays, things like that, but the data's all there now, and it's it's there's nothing crazy happening conceptually, rate times volume, every swipe times 22¢. But now all the data's available, it's perfectly dynamic, and that job runs runs instantly. There's no there's no human touch anymore. So getting back up quickly to the cost of goods sold, and this is probably funds transfer pricing is maybe one of the most important concepts, for line of business and product profitability that that that's out there, and really an ability to reflect to best reflect true profitability. And again, we have this fund transfer pricing happening at a very low level. It's happening at the loan level. It's happening at the deposit level. But anyone that has any ever tried to kind of do record matching and instrument level stuff versus the balance sheet, for whatever reason, there's always some disconnects, right? Because a loan paid off on the last day of the month, it just got added. There's always accounting balances that are out there that that are beyond just the true principle of the loan. It could be deferred, FAS 91 type things for people familiar with that. So really, we wanted to ensure what's important to us that our entire balance sheet is in fact transfer priced and does reflect a cost of goods sold and a cost of funds and a credit on the liability side. So that's where we kind of came to this notion of of this factor based approach where we we we certainly leverage the instrument level data, to look at the rates that are assigned to very specific product categories and lines of business. But then how do we take that and aggregate it up to rates to really apply for line of business reporting so that we're truly transfer pricing the entire balance sheet? And that was extremely important to us. And John can hit on the kinda how we handle that on the technical side. Yeah. So, for funds transfer pricing, right, we already we already had the instrument level detail. That was something we didn't have to build. And as Joe mentioned, it doesn't it doesn't represent the entirety of our balances on our balance sheet, but it does represent a a fair, representation of the product and cost center intersection. At any given point, if you aggregate those funding dollars and the balances within those unit product combinations, you can create a rate. And that rate applied to those balances and products from the Workday ledger, would be appropriate. And and we've done the analysis. Right? It's it's really close, really tight as if we entered the instrument level detail. And what it does, as Joe mentioned, it covers the gaps. Right? A manual entry that was made to the Workday ledger or something that again, we didn't have instrument level detail support, but the portfolio rate that we calculated, it really does apply to that manual entry as well. So this diagram just kinda represents how we got there. Right? We summarized the FTP dollars. We then aggregated them up, at various levels of both the product and cost center hierarchy. And again, we did it not just at the lowest level of product and cost center. We aggregated to product family and we aggregated to the, to the various EBUs, SBUs. Those are our strategic business units, so that if there was a cost center that had a balance that we didn't have an instrument level detailed support, it could it can traverse the hierarchy and, and find a rate at that next level. We also had some treasury assigned rates for things that aren't, supported by instruments, things like goodwill, other amounts on the balance sheet. So we bring in those rates as well. So when you think about our rate assignment process and and oh, by the way, we're we got really pretty good at, doing hierarchy lookups in a very efficient manner. So we can traverse a hierarchy extremely fast and know from a leaf level, all of all of the parents of either product or line of business and quickly find a rate. So at the end of the day, every single balance we have could have any one of from one to seven different rates attached to it. And in many cases, multiple rates attached to it of those seven. So, we assign all those rates to every one of the balances, and then we have a decision tree, a a parameter, if you will, that'll say, hey. In these conditions, always use rate number two. But, again, we have all the rates on the record. So if we changed our methodology, changed our strategy, changed our approach, or wanted to explain why a rate was used and what the other rate would have been, we don't have to go and reassign rates. We have all the rates that would have applied to that particular balance available to us. I think the next slide yeah. This this is just proving that that color picture was was real. Right? So this is the prism lineage. Those boxes highlighted on the right are the different rates we assign to every balance if they're available. Most of the boxes you see in this without telling you what each one was, a lot of them are just how we transform hierarchies and make them efficient to assign rates. So, but, again, this is this is working very well for us. It's very efficient. We calculate a couple hundred thousand different rates. We assign them to all the different balance at the intersection of product and, and line of business, for our entire balance sheet. So Alright. Thank you, John. That that's a great overview of revenues and cost of goods sold. So let's talk now about the next level down, which is, again, going back to the three levels of reporting, which would be line of business, product, and customer level profitability reporting. Next thing you need to do after you get your revenues assigned and your cost of goods sold assigned to the right levels to the right places, you gotta talk about your indirect cost down below the line. So this is a big problem for a lot of companies. How do you allocate cost? How do you get them into the right buckets? And for that, we're gonna do the same kind of exercise here. We're gonna go through, and talk about the conceptual financial requirement with with with, Joe, and then John will talk a little bit more about the technical side of that. So go ahead, Joe. Yeah. And and this certainly was this is a pain point I've seen across many banks, to be honest. It certainly was for us, and it was certainly a a place where we saw a lot of room for improvement, that could really add value, and and that's really what we did. We we could probably spend a whole hour on this topic, to be honest, or or more. Number one was we wanted to to really shift the focus of indirect charges from a more GL centric approach, meaning, like, HR charge, right, that was previously done based on some behind the scenes calcs of percentages and things like that. And how do we make it more business and strategic? So how do we create cost pools that are meaningful to the businesses being charged? So in the case of HR, recruiting maybe would be a bucket. Training would be a puck bucket. Comp and administration would would be a bucket. And then putting meaningful drivers behind that. So in the case let's say recruiting is an easy one. What's a good driver? How about the number of new hires? Right? And then that's likely something very intuitive to users that when they get a charge, instead of trying to explain to them why we once calculated 13% of HR belongs to them, we can now say, hey. The unit cost that's calculated in Prism to to hire an employee is $2,000. And you hired 10 this month, you got charged $20. Right? It it it's it's very simple rate times volume, and and being able to get that data in front of the users. So not only is it dynamic, not only was that certainly having dynamic drivers very important, but those work tags that I just mentioned, so, are things that are not available in the general ledger. So the number of new hires, that's not available in the general ledger anywhere. And those cost pools, the ability to create a cost pool of recruiting versus training, that's not really how we break out the cost centers. So that wasn't available. So what we did is we leveraged a lot of extended customized work tags and and extended dimensions within Workday to create the ability to make that transparent to the users. And I'll turn I'll turn it over to John to kinda talk about how how we did that. John, let let me know if you want me to jump to the other slide too. Yeah. Would you mind, Joe? Because I think that would, make your point more more obvious to everyone. So, yeah, what Joe was talk. One more. Nope. There you go. No. Wait. There you go. So what Joe was talking about, again, within the the realm of Prism, we have our management ledger, with the dimensionality you see on the left, and then we had our cost accounting ledger with the dimension you see on the right. Right? The blue the blue highlights are where they share dimensionality. The additional highlighted elements are true work tags within Workday, But you can see there's other items on the right that aren't on the left. So this is what Joe was talking about. Right? We do our cost accounting at a very granular level, but we ultimately feed those costs at those blue items back to our management ledger. We can then, when there's a question on any intersection of those blue items, go and drill right into our cost accounting ledger. Joe can grab all that additional detail, understand the unit cost, the driver, everything that went into that answer, and have a transparent, meaningful conversation with our consumers as to why they got charged. And if there's a change that needs to be made or a discussion about, whether the whether the pool dollars or the unit cost or whatever was needed to be changed. I mean, it's all transparent. Right? He's not going off and looking somewhere else in spreadsheets or or emails or something to find out where all that information is stored. So this, again, for us is is huge. And I I think, Joe, you in your first, go around with this presentation, you focused on the transparency that we are able to give and the conversations we are able to have now that we were never able to have before. Yeah. And it's it's not just that we have all this great underlying data now. It's the fact that not by not only is it transparent, but it's available to the users too. So we we we have reports out there that really union together these two tables you see on the screen. And to the user, they don't even they can't even tell that it's two different datasets. Right? They start drilling down, and they start seeing all the underlying data in in dimensionality. And and let me share that through an example. Joe, while you're doing that, just just something for the audience. Right? So, obviously, the Workday Ledger has allocation capabilities and all that stuff. Right? We chose to use Prism to keep things out of the general ledger and general ledger processing that don't belong there. And we were able to find that Prism can do everything we want from an allocation standpoint, with with, again, not using delivered functionality within the Workday ledger. And I let me interrupt. There's a question about I think I think I know the answer, but I wanna make sure we that this is being addressed here. Is the standard cost recovery rate for a given service derived in prism or in a separate cost pooling tool? I believe I believe it's in prism. Correct? It's not. So the actual unit costs are derived once a year. So we we do use a third party. We we teamed up with PwC, and they have an accelerator tool that we leverage once a year to derive the unit costs. But from there, those unit costs are fed into Prism. Prism then, the whole cost recovery ledger that we showed a minute ago, that all exists in Prism. And that that's where what we call cost execution happens. The rate times volume will all happen. It will create the entries. And then to stay take it a step further, we do at KeyBank use full absorption methodology. We wanna be fully allocated at the end of the day. So Prism will also be able to understand how much of the rate times volume charged out of of the of the provider, let's say $80 out of a hundred, and then it will calculate that residual, the $20, and we will push that out as well as almost like a gross up. But that's just one more piece of transparency we're able to give the users and and book that, in such a way that they can understand what is their true rate times volume and and volume based consumption, And then what is their residual charge? Which could be negative as well, but, you know, in the case of positive, that's really what spurs conversation. Right? That's where the value is added, where if someone's getting a residual charge, they wanna go talk to that provider and and help understand why does this why is this residual here? The question may be, well, why are your volumes lower? Are those volumes gonna continue? Because if they are, oh, you're gonna have lower volumes? I'm gonna go cut some expense now. I can react to that, and I'm gonna manage that residual away. That's where we have buyer seller conversations with points of data that are super relevant that we could not have before. Excellent point. Let's get into this, what we're looking at on the screen here, indirect. Yeah. Just a quick example that I'll run through, and don't worry if you can't read this, it's small. I can explain it. But really what you're just seeing here is a circled item of an expense called default management. So basically it's collections on on loans that that go into default or delinquency. We have an actual charge of $800. Plan was $400. So this is something that in the past my team would probably have to field a ton of questions on because there would be not a lot of data, underlying data to support that. Whereas now, I'm going to jump to what people can really drill through and see into that. So the first thing is, well, what's the driver of that particular rule? And this is a code 30 DPD, which stands for thirty days past due. So the driver for collections is loans that are past due. Makes a lot of sense. Again, back to the intuitive nature of of what we built. Unit costs, you see as well. Also now available to the users, three hun in this case, that's a 353. That's the amount they get charged per loan past due per month. And then we see go down a little further too. We can drill down and see the volumes. Right? Actuals was 1,900 loans. Planner forecast was $8.49. And again, back to pretty easy math at this point. Right? You can see that they have a this business has a thousand more loans past due, than was forecasted. That thousand times three fifty three explains your variance. And it completely removes that black box that used to exist in that we used to struggle in conversations with the executives and it's now just meaningful numbers that they can understand their charge and, you know, start asking more relevant questions like, well, what's going on? Why why did, I mean, these are fake numbers, but why why did our our loans past due spike by, you know, a % over plan, etcetera, etcetera. Great. Do we want to talk at all about reporting here? Do we want it ready to move on? We got about fifteen minutes left. Do you want to talk about this one? I'll maybe just in the spirit of time here, just quickly cover it and just show again. If if you look at the second box down where it says allocations, you see default collections, originations, and this is a loan servicing slide. They originate and do underwriting and then servicing and the servicing of loans. Really the functional view that we didn't have before, we've created these. You can see below it the volume driven subtotal and then that under overcapacity line. And that under overcapacity line is really the residual that I mentioned before that we can now break out in show. And all of this comes together to really just facilitate those conversations between the providers, the buyers, and the sellers as as we like to call them. But if this were a different industry, think about it. This could be HR support, IT support, finance support, business partner support. Right? The time you spend helping people in the business, and you could use different drivers to get there. So this is very specific to banking, but it could apply to any industry. How do you allocate your overhead charges out based on what used to be called, say, activity based type drivers? Awesome. I'm gonna move forward to the capital piece because this is somewhat unique to the business, but I I will just reiterate from a shareholder value perspective, knowing where your capital is going in the business is one of the toughest nuts to crack for most CFOs, and I think you guys have been able to do that. So let's dive into this third and final piece on capital allocations. And for that, I'm gonna go back to Joe and just same same the the wow and how, conceptual finance requirement, Joe. Yeah. Again, so so important to us, the the notion of ROE. Right? And with with capital constrained over the last couple years and being very careful in our capital levels to ensure, you know, we don't pass all stress testing and and that type of stuff, how are we best deploying that capital and getting the best return on it? So since we built Prism, that that that ROE by line of business and by product has become so important. So we definitely wanted to touch on it today. But but again, it's it's something that's that's we've been able to feed in at an instrument level. It's it's back to that original diagram and the finance data hub. But being able to to look at these loans at an instrument level in a basically assign a capital that is appropriate given the characteristics of each individual loan, and then how do we best allocate that out. Right? So there's the notion of of this whole collapse. This is another kind of function that we've built in prism where regular capital at at KeyBank, you know, it it books top a house in in treasury. And because of I don't wanna get into too much tech technical accounting, but because of retained earnings and current period earnings, there there's activity happening across the whole bank. Right? Any cost center that has net income, that'll feed into current period earnings, generate some equity. At the end of the day, we collapse it. Right? We wipe it all out and and we centralize it in one place, treasury, that will then do the allocation. And that allocation, again, is very prescriptive at the the product and line of business level, that we really want to do it at. And I'll again, kind of go to John to talk kind of the technical side of how we have that, the options, the order of operations to ensure that really everything out there, everything on the loan book is getting a capital charge and it's getting an allocation. Let me jump John to, I think it's this slide you want to talk to. Yeah. And and Joe will jump in as well. Right? So let's go all the way back to our reusable components. Everything we do with hierarchies that we did for funding, we reuse here. So even within those components, we're we're reusing the functionality. So very similar to what we did there. We take instrument level detail as you mentioned. We aggregate it up knowing we have, balances and everything across our balance sheet that we need to assign equity to, equity being the most important thing probably for ROE, purposes. And then we aggregate and create rates at various intersections of the hierarchy between our organization and product. We could do it at the lowest level, but I think Joe will allude to a a couple of reasons why we that isn't always the right place to do it. So where we have those bold face, fonts, that's where we're able to assign equity today. And that that's an intentional choice. Right? So when it finds a rate, it'll typically use a first rate of fines within the hierarchy. But if there is a reason, a precedence that needs to take place, we will have accounted for that and say in this use case, go up two levels and use the, banking group level rate rather than, commercial bank rate. So Joe, I don't know if there's anything you need to add, but again, just the reuse of materials that we've already built, makes this an easy process for us. And then the answer, right, equity is a balance sheet item. This goes and feeds the funding process we just talked about. Yeah. Let me maybe just add that, you know, this also even though we're often prescriptive at the level we wanna create and assign those rates, it also kinda protects us for some of those examples of a a new product got created very late that isn't in the hierarchy yet, something like that. If it doesn't find if there was, you know, within this agriculture and commercial loan you see, the non bolded, if there was a new product that got added there, that it's not gonna find a rate, it's just gonna work its way up the chain. And it's gonna it's gonna find the parent there, $4.84. It's gonna assign that rate. And we're that's how we kinda guarantee that at the end of the day, everything everything's getting getting an allocation and getting a capital charge. Why don't we, in the interest of time this is fascinating, but I need to we need to get get to the end because there's lots of q and a stacking up. I wanna just go through some key outcomes and takeaways, and then we'll open it up for questions. Starting with Hey, Scott. Really quick. Do we have this the are we gonna hit the OCFR site at all? It was the Office Connect? Oh, yeah. Yeah. Let's do that. I could jump to it real quick, John. Yeah. It'll take two seconds. So Again, for those of you who are Office Connect users, Office Connect is the Excel add in. In recent releases, they enabled Office Connect for Prism, particularly the accounting center. But because in our case, our management ledger, our cost accounting ledger, and our plan data all exist in Prism with dimensionality that represent it's very similar to what Accounting Center has. We can now retrieve through Excel in a single retrieve what would be our GL actuals, Workday ledger actuals, our management ledger actuals, our plan forecast, and if we want to add a fourth column or cost accounting results altogether in Office Connect, which is critical for us, not only because we're a bank and we love Excel, but it's a lot easier than building reports and disco boards where you can't really hit those multiple data sources in one shot. Just something to ask about for anyone in the audience who hasn't seen this capability. Excellent. Thank you for that. I'm gonna go back a couple of slides and talk about some of the, key outcomes and results for these dimensions. So line of business profitability, better insights in the results and variances. We heard that that peer discussions, the ability to have conversations between buyers and sellers inside of your organization around volumes and costs to kinda unpack the black box on a product side, better understanding of those unit economics, the cost to originate a loan, for example. ROE, we've talked a lot about. That's return on equity broken down to this level at a product. And then kind of in in play for KeyBank still working on it is customer profitability. It's the ability to show that entire relationship, across the board of of your of a customer and all the products that they're using. The, just from a key takeaways perspective before we jump to q and a, you know, three key takeaways for you. Start with the end in mind. Management reporting is a data conversation. You gotta know where your source data is. Unearth those, think about the reporting you wanna do. Second, leverage Workday analytics to bring in that data. And then third, we hear a lot about business drivers being consistent across both planning and actuals. Big, big point. And And then I just wanna show this one more time, finance role changing from a report producer to a more strategic. So now I wanna get into Scott Yeah. If if I could just real quick because I know how much some of this, indirect stuff trying to share. Hold on one second. Yep. I'll leave. As as far as the unit cost economics, I just wanna show it one more time because you did mention the cost to service alone. A lot of times now, we we do come up with this new number. Right? You see at the very bottom, a hundred and $35 and that that's really what people are gonna get charged. But beyond that, I just wanna show the level of granularity because sometimes for whatever reason a certain unit cost is eye opening to the business. Right? It it costs how much to to open a loan. And now we have all these components that sometimes maybe they don't think about because they're thinking, oh, servicing a loan is just the relationship side or the transactions that happen in a branch, but now we can show, hey, beyond that, don't forget about all these other pieces that are happening behind the scenes, whether it's managing credit risk, mailing statements to people, the FDIC expense associated with them. All the little pieces behind the scenes that you don't even think about. Fraud, the call center's a big one, like how many customers are calling to ask a question about their their loan, things like that. There's charges there. We can now show all those pieces to get more buy in from the field and better help them understand and and, I guess, accept the prove that the that the number's right. That's all. Thanks for that. I'm just going to move us forward in the interest of time. Lots of Q and A coming in. Let's start with the first one that came up is how does IT support and administer the finance data hub? Yeah. So so they don't. So this is entirely supported and built within well, I take that back. Right? We've had some reorganizations where the the function of the build of the finance data hub moved out of finance and into what would be considered an IT umbrella, but it's really our strategic reporting group. Again, it was built and conceived of in finance, it still serves finance's needs. But again, the, the management structure now reports through the IT organization. So again, IT skill set not not critical here at all. I am not an IT person. I have an IT background a little bit, but I work in finance as as does almost every one of our Prism developers. All came all came from finance. They did not come from IT. Is that that that kinda leads to our next question. Did you do this through Workday or using internal talent? And I think you mentioned also PwC. Just how did you this is a lot, right, to unpack, and people probably watching this are saying this is a lot of detailed work. Did you do it all internally? Yeah. Yeah. So, again, any database background you have is always helpful. Right? But PwC was brand new to Prism too. When we got it, Prism was new. Accounting center was brand new. We didn't have expertise that we could lean on to try to get us through that. I'll tell you, Prism is extremely easy to, to use. Very UI oriented, not SQL based, not like all behind the scenes, DBA work you need to do. It doesn't work like that. So I would say you could do it on your own. Obviously, design concepts and how you build your structures and where you, where you create keys and things you can join on. Always still important to get some third party or maybe just a Workday person to help you with that or even another banker or or another customer. But, no, it doesn't require any specialty skills in my opinion. Okay. One more question I think we have time for, and this may be one we have to follow-up on, but what's the volume of data you're handling and how are you managing data purging? I think that's gonna be for you, John, and we can follow-up after if we run out of time. Yeah. So I I can I can talk a little bit about the finance data hub? Obviously, accounting center and anything in GL, there is no concept of data purging. Right? Because you need that audit trail. Within, our FDA structure, we are not purging as of present, and we we snapshot we load and snapshot data every single day. Think about all the loans, deposits, instruments that we load their balances and all their attribution and snapshot it every day. I would need to get back to you guys exactly on that volume, but it's a large volume of data. Until you publish or instantiate a large volume of data for reporting, it's not horrible. When you think about how you use Prism, it's all about what do you want to expose to users. All the back end work you do to transform data, that doesn't need to be enabled, and therefore, those rows really aren't meaningful in terms of how you're licensed or anything at this point in time. So we think about our data as let's transform it as efficiently as possible, but then let's only expose the data elements that are are critical to our users and not give them, just have them have to navigate through all this mess. But but I would also say for the the data I need to run jobs and and execute, like going back to that debit card swipe by transaction, we have about 40,000,000 swipes per month. That job runs in about a minute. I mean, I remember being slightly concerned and I asked John, like, is that gonna be an issue? And he kinda laughed and and was like, try running it and see see how it goes with 40,000,000. So we we we've yet on on on our end, bringing in all this super low level data and running jobs and data transformation, we've yet to run into an issue as far as system constraints. Yeah. You're right here. Hundreds of millions and billions of rows aren't a problem. If you're getting into those trillions, then, you know, you can talk. There's customers way bigger than us that are that are moving much bigger volumes than we are. So Well, please join me everyone in thanking our special guest from KeyBank, Joe. And, John, you guys have been awesome. We're a little over time, so we're gonna we're gonna call it now. We've got other questions that have come in. We'll get back to you guys through email, and and we have your email address if you registered. Again, thank you everyone for joining. I hope this has been insightful. I know it has been for me. And, again, thank you to our special guest, KeyBank. And that's a wrap. Thanks everyone for joining, and have a great rest of your workday. Thanks, everyone. Thanks.