APIs Come to Banking [Podcast]

Helpful Links

• Banking APIs: State of the Market
• PrecisionDeveloper: API portal for PrecisionLender

Jessica Stone: Welcome to another episode of the Purposeful Banker, the podcast brought to you by PrecisionLender where we discuss the big topics on the minds of today’s best bankers.I’m your host, Jessica Stone. Thank you for joining us. Today we’re talking about APIs. If you don’t know what that means and if you want to know what the heck APIs have to do with banking, then this episode is definitely for you.

PrecisionLender just released our public API earlier this year. When we’ve been talking about it with our clients, we’ve been getting a lot of, “And what is an API exactly?” We thought this would be a good topic to help shed some light on APIs. To help with that, I am joined by Mike Finger, a software developer here at PrecisionLender. Mike, thanks for taking the time to talk with us today.

Mike Finger: Thanks, Jess. Thanks for having me on.

Jessica Stone: We’ll start on the most basic level. What is an API?

Mike Finger: API stands for application programming interface. It’s a contract between one system and another. To put that in better terms, think of a web site. You’re the user and you open up a browser and you put a web URL in there, you put a web site name and you go to the web site. You’re going to put a URL in the address bar and you’re going to get some data back, or you’re going to get a web page back.

Take that and let’s use that analogy with an API. An API is a system or a script that’s going to talk to another system in script. Just like a URL in a browser window, you’re going to call the API with the URL. The one script’s going to call the other script with the URL.

Instead of getting a web page back, the system is going to get just data. In most cases it’s going to be a formatted data that both systems agree upon. If systems formats are XML, or JSON are the two predominant formats that you’ll find in most places.

Again, just to take that analogy all it is is a system calling another system just like you would bring up a web site. Rather than bringing back a web page, they’re going to bring back data.

Jessica Stone: Mike, what are some everyday uses of APIs that people might be familiar with even if they don’t realize it?

Mike Finger: You’re not going to see it in most cases, again, because it’s one system calling to another system, but the uses are ubiquitous. APIs are generally used for machine to machine communication, you’re not going to see something happen behind the scenes, but you are going to see the end results.

Let’s take amazon.com for example. You can go to amazon.com. You’re going to have a shopping cart in the upper right. You’re going to have items in that shopping cart. You might be logged in. You’re going to have your user name there. You’re going to have recently viewed items. You’re going to have a splash of their featured item. The way Amazon does that is everyone of those things is a different API call that it calls out, gets the data and then puts the data on the web page.

The advantage to this is think of it like a Word document where you have a mail merge. You’ll have a letter document and then you have first name, last name, address and you have a mail merge with an Excel document that’s going to put all the different first names and last names and addresses in. It’s a similar concept with a website when the website is integrated with an API.

Amazon’s going to call and get your information for your name. It’s going to have your shopping cart. It’s going to have your recently viewed items. All these are discreet API calls that then put the web site together. The advantage to this is, in most cases, speed. That’s what we would call a private API. It’s a closed API where you have an Amazon server talking to another Amazon server and then pulling the information in.

Another example of this might be Google Maps using a third party to get traffic information. If you’re familiar with Waze, which is a great traffic app. It’s the one that has all the icons when there’s accidents and things like that. Google actually used this in Google Maps as well to get their traffic information and to supplement their own traffic information.

You don’t see that. You don’t see the Waze icons in Google Maps, but what is happening is Google is calling out to Waze and saying, “Hey, give me additional traffic information and then I’m going take that information. I’m going to integrate it into Google Maps and I’m going to show to my end users, the way we want to format and the way we want to show it.”

Those are two examples that, like I said, you’ll see the front end, but you’re not going to see what’s going on behind the scenes as much. What we’re doing is we’re bringing in more data and we’re able to talk to systems and bring in that data faster to enhance the user experience.

Jessica Stone: One of the reasons that we picked this topic, other than we’ve just released our own API here, is recently we came across a white paper that was called, Banking APIs, State of the Market. To me, the very fact that there is a white paper on the topic of APIs in banks means that this topic is becoming really more and more common for financial institutions. It’s a really long paper so we’ll link out to it for those of you that want to take a look.

What it did call out is some of the ways that banks right now are using APIs. Some of the most popular ways were transaction history and payment APIs. Some of the other ones they found to be pretty common were APIs to pull in customer profiles and data, or credit scores, things like that. Also, a couple interesting ones about locations of branches, or bank card limits, and things like that.

Mike, anything, I know you took a really hard look at that paper, as our resident API expert. Any other thoughts about what stood out in that paper?

Mike Finger: What I really liked was the fact that since there’s a state of the market, they’re going to give you a lot of percentages of how many banks are implementing, or what banks are implementing. What I saw coming through that was a lot of migration from older and less flexible data transfer mechanisms to the newer standards to throw out a little bit of buzz word bingo, things like a restful API which is just a more modern standard of sending the data back and forth as opposed to an older standard you might hear called SOAP.

Again, we can still use those older standards, but there’s a little bit more you can do with some of the newer features. It was nice to see that banks and bank technology divisions are embracing the newer technology and aware of it. Also, there seemed to be a traditional industry awareness and recognition of fintech startups coming around the pike, or coming into the market and pushing some of this adoption. That was really nice to see.

The other thing that this paper will focus on is it tends to focus a lot on the consumer application. Just like I just mentioned Amazon and Google Maps as an example, the examples that they point out are your consumer apps on your mobile phone for mobile banking, doing things like depositing a check, or pulling your balance, or getting locations. These are all, again, discreet API calls coming into a mobile application and getting that specific data for the user.

That really just covers a part of what we can use APIs for. In fact, what we use APIs for in Precision Lender, with our clients and in future integrations with our clients, is actually a little bit more robust than that. It brings into how you can talk within multiple systems within a life cycle for things like a loan management life cycle. I think we can actually go right into that and talk about that next if you like, Jessica.

Jessica Stone: Yeah, tell us a little bit more about some of the ways that, again, our public API is new, but some of the ways that either currently our clients are interested in it, or the potential where you see it going for our banking clients.

Mike Finger: Right now we use it for two discrete purposes. We use it for repetitive work that our clients don’t want to do manually I should say. They definitely want it to be done, but they don’t want to do it in a manual fashion. They want to automate repetitive work and then also for loan workflow.

By repetitive work I mean, for example, a daily update of the custom funding curves. Some of our clients have custom funding curves. The old way would be somebody opens up, logs into Precision Lender, goes to our web page, uploads a CFC file, or an Excel file that has their custom funding curve for that day. Somebody does that every day. Somebody has to remember to do that every day.

Where we’ve moved to and where we have some of our clients that have moved to is we open up an API that you can upload a custom funding curve. Now what the banks can do with their technology departments and their developers is have a script that pulls their custom funding curve from somewhere in the bank and then pushes it up to Precision Lender every day.

You alleviate that manual process. You alleviate just the human aspect of forgetting to do it, or something like that. You also free up your employees to do other more meaningful things than upload a CFC file every day.

The second part, which actually gets even more exciting is the loan workflow. We have this already implemented in things like our Salesforce connector, and our Dynamics connector, and loan origination service connectors as well. In those, we’ll use a combination of some of it is you’re calling us the web app. For example, in our CRM connectors for Salesforce or Dynamics, there’s a button that gets added to Salesforce, or Dynamics that the lender will click on and then it opens PrecisionLender. That’s just a link. That’s just clicking on a hyperlink in a web page. That’s not really utilizing our API.

As a part of that, when a user updates an opportunity in Salesforce, or Dynamics, or any CRM system, we’re sending a little message to our API that’s saying, “Hey, upload this offer, update this opportunity.” That update might be they changed the opportunity name, or they changed the sales stage, or they changed the close date. We’re sending little discreet pieces of information back to PrecisionLender behind the scenes when you update an opportunity in the CRM system without the user going in the PrecisionLender and then updating that data in two places, or double data entry.

We’re also doing that on the other side when an opportunity is done pricing, or is ready in the process to be sent to underwriting or a loan origination system. For example, an underwriter will open it up in the loan origination system. They might have some changes that need to be made and they might need to send it back to the lender, or they might move this stage along and say, “Okay, yeah, this is great, but we want that data to get back into PrecisionLender.”

Even if it’s just the underwriter saying, “Yeah, the loan’s approved and that you’re good to go and you don’t need to go back into PrecisionLender and reprice it or anything like that, we still want to keep the stage in sync. Rather than having a two-step process where the underwriter has to go in to the system, approve the loan, and then log into PrecisionLender, or maybe send an email back to the lender and say, “Hey, change the stage in PrecisionLender so it’s in sync.” or something like that, we can automate that process.

We can just have the loan origination system make an API call back to PrecisionLender and update that sales stage, or if it’s the other circumstance, and you need to reprice the loan, send some information back to Precision Lender to notify the lender to reprice the loan.

That’s where we’re at now. In the future, what we really want to get is more of that workflow, have a coupled workflow so when you do something in another product, in another third party service where you do something at the bank that needs some kind of notification, or some kind of attention in PrecisionLender we have those API end points open so you can send that notification that, “Hey, something’s changed”, or some status changed, or some action changed in another system and it needs to be made aware in PrecisionLender for that opportunity that the loan officer, or a lender might be looking at.

That’s where it starts to get really exciting. You get this what used to be loosely coupled services and products across the bank suddenly tightly coupled. The information is shared across the systems automatically so you don’t have data lost that would come with manual double data entry, or triple data entry, or more. Since you have this data and this information, you can notify and have actions occur in the different systems based on data change.

Like I said, in summary the whole gain of that is you have a more tightly coupled process whereas you might have had a workflow, or you probably did have a workflow that worked, but there was a lot of manual gaps and places where communication could get lost and data could get dropped. That’s all done behind the scenes. It’s all automated now. Your workflow can just get a lot tighter. You can focus on actually executing the process rather than the details of all the data in the process.

Jessica Stone: Awesome. Mike, I think that will do it for us. Thank you again, Mike, for talking through this. We appreciate it.

Mike Finger: Sure, absolutely.

Jessica Stone: Thanks to everyone for listening. We will provide some links in the show notes for this episode. We’ll include that white paper and a couple other items. As always, you can find those at precisionlender.com/podcast. If you like what you’ve been hearing, please make sure to subscribe to our feed in iTunes, SoundCloud, or Stitcher. We love to get ratings and feedback there. Thanks for tuning in. Until next time, this has been Jessica Stone. You’ve been listening to the Purposeful Banker.