Transcription:
Mark Braden: (
Welcome to today's session on Build vs. Buy, the Tech Stack for the conference this year. My name is Mark Braden, and I'm a managing director with KPMG, and we are hosting today's session. We have a great set of panelists, a strong moderator that I'll introduce to you in a moment. A couple of the key questions that we're really looking at during this session is going to be, does anyone today really build their own tech stack for mortgage originations and servicing? Those are the major systems, as everyone knows in our industry. To build these, it's a major undertaking and to own it and to have to support it. So you really need to look at what are those competitive differentiators if you're going to go down that path?
Mark Braden: (
The other area is really around — are the fintechs today — are they moving too fast? Or are they moving fast enough? They're definitely disrupting the industry in, I believe, in a very good way. They're causing a lot of the traditional technology players to be a little more aggressive in making changes to their platforms and driving the change towards a full digital perspective. Coexisting between the fintechs and traditional is really unavoidable. We're going to have that as we continue to grow an industry, and technology continues to evolve. So really looking forward to the session.
Mark Braden: (
And today, what we have, we have the moderator, we have Paul Centopani. He's a content editor with Full Beaker. And we have four panelists. We have Jeff Reeves. He's a cofounder of Box Home Loans. We have Blair Sirman, senior vice president, program director with Citizens Bank. We have Srikant Iyer. He's the head of home lending, originations product strategy and transformation with Wells Fargo. And we have Brittney Tay, who's a manager, process automation and innovation with Thrive Mortgage. Look forward to the session, and hopefully you guys really enjoy it. Thank you.
Paul Centopani: (
Good afternoon, and welcome to the Build vs. Buy Tech Stack Circa 2022 panel. I'm your moderator, Paul Centopani, content editor with The Mortgage Reports, and I'd like to introduce our panelists. We have Jeff Reeves cofounder of Canopy Mortgage; Blair Sirman, senior vice president at Citizens Bank; Srikant Iyer, lead retail transformation and home lending at Wells Fargo and Brittany Tei, process innovation and automation experience manager at Thrive Mortgage. Thank you everyone for joining us. And just a quick reminder, we will be taking audience questions at the end, so put any that you may have into the chat.
Paul Centopani: (
All right. Let's talk tech stacks. Jeff, I'll start with you. Does Canopy build or buy?
Jeff Reeves: (
We've built? We've been doing so since about 2007.
Paul Centopani: (
Okay. Uh, Brittany, how about at Thrive?
Brittany Tei : (
So we're a blend of build and buy, but it's been a more intentional transition the last — I guess recently — with more emphasis on building those internal solutions versus buying.
Paul Centopani: (
Blair, what does Citizens Bank do?
Blair Sirman: (
Yeah, much like Brittany, we purchase most of our technology. We build where we wish to differentiate or where we don't believe that there's a viable option in the market.
Paul Centopani: (
And Srikant, how about Wells Fargo?
Srikant Iyer: (
Yeah, very similar, where we have a mix with build and buy. And very similarly, what we look to do is where we are looking to differentiate, or where we believe we can build better, we build. And where we feel there's a solution, which is a commodity, or we would look to accelerate based on what's out there in the market, we look to buy and integrate.
Paul Centopani: (
All right. So for each of you, how are those decisions made? Are there certain parts of the tech stack that are better bought versus built?
Jeff Reeves: (
You know, I'm a firm believer in the idea that you should only build the things that you can be the best in the world at. Or, if you can't elegantly integrate a third-party solution into your user experience, then you got to build it. But where possible, always buy, because you can just leverage the experience and expertise of someone else. In our case, we started building, an LOS, a point-of-sale pricing engine back in 2007, when such things weren't really available in the way we wanted them off the shelf. And so we've stuck with that, and it's, and it's been a good thing for us. But I can imagine that would be a very daunting thing for most people to even consider at this point. Anyway, so...
Brittany Tei : (
I would say kind of, I think —Srikant, you touched on this a little bit — we look at the build opportunities when what's prebuilt or what's out there today continues to fall short of our needs, specifically around ability to integrate with our other systems to Jeff's point. And I think what we're seeing is at Thrive, we continue to outpace those prebuilt solutions because of the way we're approaching new and innovative processes, and they can't be as nimble to deliver the technology to support the unique products, all the channels of business and the required flexibility to adapt quickly to those multichannels and product offerings as they change. So that's kind of the influence and the decisions on the why.
Blair Sirman: (
Yeah, our experience at Citizens is very similar, where specifically, items that are, say regulatory in nature, where it's better to be part of a pack. A lot of times we will purchase those. Specifically, the loan origination system as a core component, we have actually in our technology both — one that we built as part of an acquisition that we had, and one that we purchased. I can tell you the one that we own that belongs to us, I spend most of my capital and resource time keeping it up to date, as opposed to innovating and improving on the other things that are available to us. So it's a different proposition based on where are you spending limited resources. Whether it's time or money, if you're spending all of your time and money on just maintaining regulatory compliance because of ERLA changes and other things, and not able to innovate and move the ball forward there, purchasing something where someone else is doing that. And as long as you're aligned with their guidance and opinion of the regulatory changes, makes sense to us,
Srikant Iyer: (
Yeah, on very similar lines, we've also,when we've gone through our decision process, it has been one, what we want to ensure is we have a collective vision of where we are trying to take our business both from a customer perspective and from a supporting product and technology-architecture perspective. And so based on that, we've, decided on certain areas where we think building makes sense, because we can either build faster or build more differentiated that's much more, much more adaptable to our needs. And then in certain cases like today, we use, we have Blend as our digital originations partner, and we've leveraged Blend significantly as an accelerator and as an enabler to provide digital originations for our customers. So we very much look at that mix and where it makes sense, having that build option versus , a buy that integrates into our architecture.
Paul Centopani: (
So Srikant, you just said something that was interesting to me gow you try to differentiate when you build your products, What do you try to do? How do you differentiate what you're building versus what's on the market?
Srikant Iyer: (
Yeah, so I think when we think about differentiation, we think about it in the context of one, the customer experience. And we want to make sure that we are creating the experience we want for our customers. Or two, here are specific business objectives around things like efficiency or risk, or growing our share within our own customers. When we look at those business objectives, if we feel like there isn't something in the market that truly provides solutions that are best adapted to what we're looking, then we're looking to build it. If we find that there are solutions that are either already available, they're thinking the same way like we are, and they're already built, so they can serve as accelerators for us, then we're looking to buy. And so that's kind of our thought process is we're starting with the key problems we're trying to solve for our customers and differentiate that customer experience. And once we look at those problems, if we have solutions out there, we'll leverage them. Otherwise, we'll go.
Paul Centopani: (
Got it. Now, is there a preference typically for origination software versus servicing software?
Blair Sirman: (
Let me chime in a little bit on this one. So in the servicing space, there are a handful of players in the market that have the vast, vast majority of market share, and it's an area that I actually think is sort of a little ripe for disruption. It's an interesting conversation that we continue to have around how do you want to differentiate the customer's experience and perhaps not touch the core servicing systems, right? How do you build customers' experience, and that customer's experience by the way. We always think of customers as the borrower in this particular case, but I actually think that we have spent a lot of time over the last two or three years really focusing on internal customers, internal efficiency plays that we can make to make people more efficient at what they're doing. And this is an area where I think the primary servicing platforms that are out there are very, very powerful at doing core servicing functions, but they're not that great yet at driving efficiency plays or rethinking how we do certain things, right?
Blair Sirman: (
It's always, it's now end of December, beginning of January, let's, let's start the processes of generating the 1098s, right? Let's go through that exercise now. I think that there's an opportunity in this space to, as we've shopped, it seems as though there's an opportunity in this space to build because of the lack of sort of options out there in that space. I think originations gets a lot more love from a technology perspective of things in the marketplace than servicing does. And that's a bit of a shame actually.
Jeff Reeves: (
Yeah, it's been our focus. We have just started servicing this year, and so our whole focus has been on the sales and fulfillment side of the mortgage itself and have put no thought into service. It's all outsourced for us
Paul Centopani: (
Now, does the borrower experience influence any of these decisions?
Jeff Reeves: (
Oh, it's massive. And it really, it always starts with a borrower. A borrower will do heavy lifting if you'll let them do it. And we found that if you want to help your efficiency of loan officer or processor or underwriter, you must start with the borrower,
Srikant Iyer: (
Completely agree. And it is at the center of everything, and what we're trying to do is consistently draw that thread to everything we're building and ensuring that it connects back to our customers. And kind of similar to what Jeff said, right. And allowing for supporting the customers when and how they want to engage, especially when you think about in the mortgage origination space, a lot of times customers will want to drive themselves, and in other cases, they really want advice, and ensuring that we are positioning to best support the customers , in how they want to engage with us.
Brittany Tei : (
Yeah. I think at Thrive, we really look at the end of the day, we are in the people business. We help people get into homes, and there's a lot of people that make that happen in the process. Essentially, everybody is — we're supporting internal teams that are supporting external teams that are ultimately there to serve our borrowers. So it's user experience at every level. And our thought is if we can make improvements to do that, then we should do it. So I think just to echo what everyone else has said, it's a constant. It's top of mind. The borrower experience is probably, I would say arguably, the most important aspect of all of this. You can have — our people are really almost as important as our products. If we don't have excellent people that you want to do business with, it doesn't matter how great our product is or how great our technology is, it's going to sit unused.
Paul Centopani: (
Yeah. Yeah. No, that makes sense. Gotta put people first.
Paul Centopani: (
So let's talk about the advantages and disadvantages of buying, because every vendor out there is going to tell you that their product's going to save the world and have you discern what will actually improve your company versus what is just fluffy jargon.
Jeff Reeves: (
Yeah. It's so important that you don't chase every shiny object that comes around. You have to be really disciplined and really saying "no" to most things you look at. And understanding, even if you're patching it all together with buying a bunch of products, which gets more complicated the more you patch together, you have to understand where are we going, what are the big rocks and does this tool — as cool as it is — really solve my greatest problem. And understanding what to do first, what problem to solve first is really more important than the solution that you're picking. I think,
Blair Sirman: (
Yeah, I agree, Jeff. It's defining the North Star and then figuring out what tools are needed to get there, right? But being crystal clear about what that objective is, and then putting everything that you're looking at or contemplating building, perhaps even up against that North Star, right? Is this going to drive towards my objective or is it a deviation from it? And if it's goint to drive towards my objective, is it the best solution towards that objective? Or are there better alternatives? But it's constantly turning back to what is that North Star that we're going towards. By the way, you have a bunch of North Stars, right? It isn't just one thing, right? I personally currently have about six, Things that I look to to improve in either our customer's experience or our product offerings or operations efficiencies. But turnin back to each of those items as a huge filter point against whether what the thing you're looking at is viable or not — is it the best option or not — is the way that we approach it.
Srikant Iyer: (
And just to add to that, right. A couple of things, Paul, I'll answer your question. One is we think about evaluating, just buy versus build, right? The way you think about it is the opportunity for buying is the ability to accelerate. Blair mentioned a little bit about, especially in areas like compliance and regulatory, you have the ability to be on an upgrade path that manages your tech resources on a limited basis. But the potential considerations on the other side are things like cost. Does it integrate into your architecture as well as the potential lack of differentiation. Whatever a vendor would build is going to build it for all their customers. So that kind of the buy versus build. But then I'll kind of build on what, Jeff and Blair said. When we then decide if it is a buy decision then, and go through how best to select the right vendor, t is multiple rounds of truly getting deep into the vendor solution and ensuring that we understand the solution at a pretty detailed level, right? Both. So in initial rounds there are usually sales pitches, but then as we go through an RFP process going through every detail to ensure that the solution really does what it's expected to do. It works within our architecture, and having been through enough integrations, to know that this is something we can integrate seamlessly. So those are all considerations as we go through that kind of like detailed buy process.
Brittany Tei : (
We follow almost that same trajectory. I do think, as we know, buying can be successful when you know what you're looking for and you have the resources with the time allocated to actually complete that comprehensive review. And, like you said, it's not just conversations with salespeople and solution architects. I think we're a big proponent of put in the time upfront. Do a pilot, see it with your data, your processes. I think it allows additional team members to be involved and weigh in on that decision, because at the end of the day, it touches so many different people. And if you make the wrong decision, you can be locked into a solution that may not meet your ultimate needs. And the advantage is, though, is when you find the right solution, and you put the time into it, then you've got a solution that's going to'work for you.
Brittany Tei : (
The disadvantages I think of buying, and what we've spoken to already, is the flexibility of being able to tailor it to your processes. If you're doing something that stands out and differentiates, you're not going to be able to do that with a fully off the shelf without a lot of manual interventions or that additional customization to integrate multiple systems.
Brittany Tei : (
I think the ability to evolve quickly as well. I think that's the biggest thing that we keep in mind as a disadvantage of buying is, if it falls short, you may not have any influence on that road map and what the next set of features that comes out. And I think taking it to the next step, we look at, well, what's the impact to our people? If we're constantly buying and ripping and replacing systems, every one to two years, you can start to put a lot of doubt into teams. Are we on the right path? Do we know what we are and where we're going? And I think that's the piece that we can talk technology, and I'll, again, bring it back to the teams. They're the ones that are having to learn and adapt and go through that pain of, "Oh, we didn get the right system. We didn't vet it out properly when we bought it upfront."
Paul Centopani: (
So how do you make sure that these products are, A, going to work together with your stack and then also work together with your stack in the future?
Blair Sirman: (
Yeah, this was one that we sort of asked a little bit about in prep. We ask or we ask about a million questions, nd, and that's probably not even enough. It's asking questions of the salesperson who's trying to sell you the product or the technology lead, who is conveying how we would build it, Internally build as well. And then asking to speak with their current support team, and then asking to speak with their current customer that are willing to share information with you. It's understanding all of the nuances of the experience of delivery and ownership as a starting point. And then contemplating the answers that you got from that, and how it relates to your organization, right? Your organization is different than everybody else's organization, and the way that you approach risk items will be different than others. Or the way that you approach how APIs are working or not working, are going to be different than others.
Blair Sirman: (
So it's taking all of those answers that you get in a million and a half questions that you ask and pairing it up against what you know to be true about your organization, it's really the only way to determine that you'll end up with a successful delivery. And even then, you will miss something. So it's a matter of being able to quickly identifying, empowering your teams to quickly identify that, "Hey, this is something we didn't contemplate, and let's bring it up and talk it through," as you're delivering. But it's really just about inquiry and understanding all of the pieces of delivery.
Paul Centopani: (
All right, let's move to the build side. Walk me through what the development process is like. What kind of resources go into developing a product?
Brittany Tei : (
I feel like the short answer is everyone. To a degree, we're all technologists nowadays. For us, it's an org wide discussion participation at every step. We've got head of everybody at the table. Operations, they're doing the work. We've got IT, we've got marketing, we've got sales, training, our design teams, our development teams, accounting, finance. It's everybody, and our process is very incremental. We're always prioritizing. We have to identify. We can't deliver everything upfront. We want to get that speed of delivery. We want to get it in the hands, so we do a lot of prioritization, phasing, just the standard, I would say, continuous development, continuous improvement. And making sure that across the org, all of our executive leaders are aligned on what are the goals, what are the things we're working towards and how is the technology going to support the goals that they've put in place. If anyone is out of step, then that development process, again, it will, it will crack. We don't always know everything upfront, but we'll learn as we go, but we have to make sure we keep those priorities and just continuously iterate and deliver.
Jeff Reeves: (
We've learned that you have to have an exchange between the mortgage people and the programmers, and you have to be challenging each other constantly. We started building our LOS and point of sale, like I said, back in 2007, and the first five, six years we built it, it was me and a bunch of contractors. And I had no idea what it meant to build something. And they didn't know anything about mortgages, and our first iteration of our product, which actually was quite effective. I think, because I fundamentally kind of got what every stakeholder had to do in the process, was under the covers of house of cards. And because I didn't know enough about the other side of the fence to ask the right questions. And the programmers didn't know enough about my side of the fence to also ask the right questions. And so after about a decade of that, we became really good at questioning each other and making sure that both sides were fully represented. So you have to have dedicated resources on both the technology side and the mortgage side, who begin to inch closer to the other side of the fence.
Srikant Iyer: (
I agree, and I think just to build on what both Jeff and Brittany said, a couple of things, right? First, is when we think about about building that vision really, it is a truly full-team effort across the entire organization. And especially when we think about the products we're now building, which are truly transforming what we're building for our customers. And it is really kind of that intersection between being unconstrained and thinking about what your customers problems and needs are, and ensure that we can think outside of the proverbial box, and bringing together the art of the possible from a technology perspective. Because if you just start with one, you can flow one way and you may not be open to other ideas. So really, that intersection becomes extremely critical around building something which doesn't already exist in the marketplace. It isn't exactly a clone of what everybody else has done. But I think from our management, very similar process, we think about the customer problems. We, start with those needs. We then look at all available data and information to come back with a set of solutions that we have a hypothesis around. And then, at that point, you start to build quickly, test, learn and then iterate from it. And so very, very attritive, an incremental end process, but aligned towards a broader North Star that you are kind of, everybody's stacked hands. That's what we're working towards.
Blair Sirman: (
Yeah. And to just continue that a little bit more, one of the things that, just to be cautious of, — this is the product manager hat I'm going to put on for a second. Everybody will advise what they believe the outcome is supposed to be that you're trying to solve against. So creating clarity around what problem are we solving, and if needed, clarity around what problems are we not solving with this particular thing is super important at all levels, from executives on down, to frontline folks that are within your initiative. Here is the problem that we're trying to solve, and in the effort of avoiding scope creep, and also in the effort of avoiding taking something that's really exciting — building things are exciting, It just is — but you can take a little bit of the wind out of the sales if people think that you're solving a problem, and you end up not solving that. So being clear about what we're doing, why we're doing it and then, as people have questions about, "Well, does that mean we're also going to tackle this?" If the answer is yes, great and celebrate that, but if it's not, be clear, it's not. And that is a problem that we need to solve and separately, we will, because generating excitement is important. It's twice as easy to generate aggravation in people, who think that you're solving a problem, the problem that they experience daily, and that you're not.
Blair Sirman: (
Building things need to be clear. We need to be clear with all of the participants. This is what we're doing; here's why we're doing it. And if needed, here's what we're not doing, right? Here's what's not in scope of this. So that you keep people aligned on what the outcome should be.
Paul Centopani: (
All right, we have about three minutes left, and I'm going to go to audience questions. The first one, it seems organizations use robotic process automation to satisfy specific needs that are met by a purchase product. How do you effectively navigate transitioning from those RPA solutions as an interim to a more stable and part of the permanent solution quickly, while saving overall resource costs.
Blair Sirman: (
So, I'll tackle this, and then others can chime in. The way that we approach it is in that effort of efficiency gain, I look at what tasks are we doing today that a human being is doing that doesn't require the brains of a human being. I'll give you a very easy example. Task assignment. Task assignment is something that you can solve with a bunch of different things of technology tools that are out there and other. We've solved it with RPA simply because we want a little bit more flexibility around the logic, and RPA gives us a lot of flexibility around that. But looking at new loans that came in for underwriting, comparing those against the signing authorities required to underwrite said loans, availability of resources to underwrite said loans. And then assignment within the systems is an example where RPA serves really well.
Blair Sirman: (
It's, to me, it started out as the interim point towards building logic to do the file assignment. And I have since changed my opinion of this. I actually believe that it is the end point, simply because the moment that I code it, I want to change it. We learn every single day this was a scenario that we didn't quite contemplate, or we added this new loan product or we hire people and lose people on a fairly regular basis on our industry. So this is an area where RPA has really served us well, not as an interim step, but more as the end solution.
Paul Centopani: (
All right. And then last question, and really quick, one sentence answers. We have under a minute left. What would you consider a successful buy decision?
Jeff Reeves: (
Something that costs less than humans doing the same process
Srikant Iyer: (
Solution that integrates very well with our overall architecture and delivers what we intended for it to deliver.
Blair Sirman: (
I'll chime in because I think Brittany's still on mute. I agree with Jeff and Srikant. We got the outcome that we desired, ideally for the budget that we anticipated, in the timeframe that we also anticipated.
Brittany Tei : (
Yeah. I think the — I guess my gut feel is — if I'm just as happy to resign or extend that contract as happy as we were in the presales process, that's a good buy solution.
Paul Centopani: (
All right. I think that's a perfect way to end this. Everybody thank you for your time and insights, and everyone on the other end, thanks for watching.
Speaker 7: (
Thank you.