The Power of Connectivity and API Technology in Treasury Management

Announcer  00:04

Welcome to the Treasury Update Podcast presented by Strategic Treasurer, your source for interesting treasury news, analysis, and insights in your car, at the gym, or wherever you decide to tune in.

 

Craig Jeffery  00:17

Welcome to the Treasury Update Podcast. This is Craig Jeffery. Today I have German Karaivanov from GTreasury. Our topic is connectivity in API technology, GTreasury’s strategy for connectivity. Welcome to the podcast, German.

 

German Karaivanov  00:32

Thank you, Craig, I’m super excited to be here today.

 

Craig Jeffery  00:35

Technology for connectivity has been developing over the years from old old versions to newer and newer versions. API’s are a very large topic and hot topic of conversation. In some ways, API’s are all the rage, others have a more skeptical view of adoption and the change that they’ll bring. Maybe you give us a background on your work experience in your role at GTreasury.

 

German Karaivanov  01:00

Sure. So I’m the VP of Product here at GTreasury, I have over 16 years of product management experience working at some of the super big banks in North America, and financial services companies. My background has been really explicitly focused on cash management in payments.

 

Craig Jeffery  01:17

You know, this idea of connectivity and API technology, this section I think we’ve called differences in what matters. Maybe we could start with technology differences, we’ll move into practical differences. And then how that matters to companies. What what makes sense? But let’s start with technology differences, what are the core technological differences of SFTP, or file based transfers or connectivity methods? And API-based approaches? Why is, what’s similar, and what’s different?

 

German Karaivanov  01:47

That’s a great question, Craig. So let’s start with some of the core differences. You said, if you think about an API versus an SFTP, so with an API, you’re actually talking from one system directly into to another, and trying to exchange the data, where so you have that direct connectivity between those two systems. If you think about the file exchange method, that’s a bit different. So with the file exchange, what you’re doing is you’re extracting data from one system, you’re putting it somewhere, and then you’re sending that file with the data using an SFTP, to another place that’s sitting on the other end of the receiving channel. And in that database, it doesn’t go directly into the system, it’s sitting somewhere in a file folder. And from there, the actual system that needs the data has to pick it up and ingest it. So if you see the key difference, there is no direct system to system data exchange. And then there’s also multiple steps to actually get the data out and get the data in when you compare it out to the SFTP. Another key difference there that I’ll mention is the integration of those, and how you manage the integration, the SFTP route. Really, if you’re a client, a treasurer, or treasury management system, trying to integrate with an SFTP method, typically, what happens is the file you’re receiving doesn’t really meet the expectations of what you have on your end. So you have to do some file mapping and maybe file transformation in order to be able to ingest that. And there’s testing that you’ll be dependent on whoever sending you the file. For example, if you’re doing a bank integration, you have to make sure you have bank testing resources that helping you with the testing once you do the mapping and file transformation on your own. When you do the API connectivity, especially if you’re working with a treasury management system, the treasury management system can do all the API mapping on your behalf. And then you as the treasurer, all you need to do is enter your API authentication credential within the treasury management system. And your implementation is done right there. So there is no testing you have to do with the bank, there is no mapping that you have to do with the bank as well. Much faster in terms of actually getting on boarded with an API versus file exchange.

 

Craig Jeffery  04:04

Yep, yeah, that’s, that’s getting a little bit into the practical differences, too, right. Getting up to speed sooner. Onto the technology differences. Here’s, here’s a question. So files come in with an SFTP. Let’s say it’s an MT message, say, coming from Swift, and there’s some missing data, they’ve missed a page, or there’s an unbalanced file or the file totals don’t match the detail records that are sent somehow some data is lost in a SFTP transfer. Before that’s loaded, some of that information is oftentimes checked by the system. And if it’s out of balance, it’s suspended. It’s not loaded into the database. So there’s a ability to prevent that. How is that handled in an API world if there’s missing data or some type of problem with the data?

 

German Karaivanov  04:51

Good question. So typically, what we’ll have for the API’s, you have fields that were required, and then fields are optional within the API, as you’re receiving the data. And if no other data is missing, you can go back and actually do another request to an API to gather the data and pull it. So there is no manual intervention that needs to happen there on the client, to re drop the file or resend the file, you can automatically have the system go back to the bank, for example, and do another ask for the data to be sent to you.

 

Craig Jeffery  05:20

We started talking about the practical differences where you talked about it’s faster to implement. But from the treasurer perspective, from a non technological perspective, what’s what are some of the other differences faster to implement, what what else matters?

 

German Karaivanov  05:35

I think the other thing that really matters to treasures is actually I can get data whenever I need it. So if you think about the file exchange, with the file exchange, you’re dependent on when the bank is scheduled to create a file and send the file out. And typically, that’ll happen only a few times a day. If you think about an API, as a treasurer can say, hey, I want the data now. So I can, you can just initiate a one off request to get the data right now. Or you can actually have a scheduled pull of the data with the API and say, hey, I want to pull the data every 15 minutes, for example, and get the data into my system. So much more quicker availability of data, and more recent data.

 

Craig Jeffery  06:15

So if we’re looking at, you know, banking data, information that comes in, they have a lot of different systems, much of the banking process at many banks is geared towards once a day. And so prior day information gets delivered early in the morning, has all of the transactions fed from multiple systems from wire transfer platforms, maybe check platforms, low value transfer platforms, other areas, when we think about current day, usually, current day information tends to be limited, right? It’s pulling from a particular platform and not for most banks, all platforms aren’t feeding into the interface area that an API or SFTP process would work for current day. Is that an accurate way to put it or concern? Or is that, how should we think about the fact that some of the cycle time of banks are daily not not real time, when we think about real time connections like API’s?

 

German Karaivanov  07:13

Yeah, I think that’s a valid concern. And this will depend bank by bank, right? Some of the banks actually moving to provide a more current day data by either posting, like, no hold on accounts, but posting actually entries to show that a transaction has happened, even if the money has not been moved yet. So banks, actually very cautious that they do have some of the limitations. And they try to bring more data to the current day posting. But each of them will be different bank by bank. So I think what’s important from a client perspective, what when they think about current day data, what is an API or what is a file exchange, they have to know the limits of some of their banks and know what to expect. And then obviously, I think that’s just a no brainer for auditor treasurers, you have to make sure you’re getting the prior day data as well over the next day. So you have the full set of data that’s coming from the bank, but you still have the ability to make some very important decisions with the current data that’s coming from the bank.

 

Craig Jeffery  08:10

Perfect. The other question here is, as we think about how this matters to treasury groups, is it more important for them that it’s easier to get more connectivity? Or that it’s faster, and you get better information, maybe not real time, but faster information, and that’s important? How would you weight that? You said, easier process, better information.

 

German Karaivanov  08:35

Yeah, so it’s a great question. So it depends. Okay, so let me give you two different examples. So one example is, hey, I’m a treasury department, I have my own internal system that I use for connectivity, I don’t use a TMS, okay, in our scenario, multiple file exchange and both for an API, you actually have to bring your IT resources to help you with the connectivity and getting the data. Now if you’re using a TMS it’s a bit different. So once you’re connected, you have your TMS stood up and connected to that. The TMS will connect on your behalf with the API to the bank, for example. So there is no treasury department, technology department needs from your company to actually do any connectivity there. So no need for IT resources, much faster onboarding, to get the API working, because your TMS provider has done it on your behalf. And then the data will be available for you there in your single source of truth within the TMS.

 

Craig Jeffery  09:34

All right. So when we think about the mindset and implications or maybe we should think about the mindset and implications of API’s, how are we to think about these? You know, just saying API, and this is where I think there’s some negative views on API’s that there’s hype about it, you know.  Hey, we got an API. That doesn’t magically make every connection work out of the box across 10s of 1000s of banks across dozens of ERPs. You know, I know you’ve talked about in our other conversation that there’s a maybe a library of connections, you might not have used that word, but how do you grow your library of connections? And you have a, I call it an API suite that you’re building out. But how do we think about that, and what what types of connections are you building in your API suite?

 

German Karaivanov  10:21

Yeah. So before we talk about API suite, I want to go back to what you’re saying, Are there related to hype about API’s? Is there hype about API’s? Absolutely. And I think there are also some misconceptions. Okay. So let’s talk about bank API’s. When people say, bank API’s, they’re thinking, you know, they’re standardized. They’re just transaction data and balances that we’re getting from the bank. Well, I gotta tell you, wrong. Okay, yes, it’s transaction and balance data. But these API’s do not have any global standards across the banks for treasury data. So what’s happened is, each bank has gone and developed their own flavor, their own version of an API, so you can get treasure data out of the bank. And what ends up happening is bank one versus bank two. They all have different limitations, or different capability of those API, even though you’re providing the same data. Or, for example, one bank may say, Hey, I have a limit that with an API call, you can only bring in 10,000 transaction at a time. And then you just got to initiate another API call for the rest of the transactions that you have as a company, right. As you’re building connectivity with these banks, you have to be aware of those limitations. And you have to build for those limitations to make sure you get all the necessary data for the treasurer. Each bank has their own different authentication method with their API as well. So what we’re doing on the GTreasury side, we’re building our own connectivity suite for API’s, we’ve created an internal tool that we called ClearConnect Gateway. And that tool enables us to do a couple things. So first of all, it actually enables us to map the different bank API’s to the GTreasury system without any development effort. So a non developer person, somebody from implementation teams, or somebody from our product team, will go and use that tool and it will map the bank API for bank one, using a graphical user interface, and some text as well. And once the data is mapped, they can go on map bank two based on their specifics. And what will happen is, we’ll build all these connections, all these connections with the banks on the behalf of our clients to treasurers, of course. And when they want to use them, they don’t have to do anything in terms of mapping or building the API in north us. And all they have to do is get their credentials from the bank. It’s completely self serve onboarding within GTreasury. They go to the specific through the GTreasury, they put in the bank credentials, and they say how often they want to pull the data, and they’re good to go. And they can start pulling data from the bank the same day.

 

Craig Jeffery  12:53

Okay, so that addresses the speed issue, right. It’s much more configuration. It’s a simpler configuration, as opposed to development and configuration. German, thanks for this discussion on connectivity and API technology. I want to give you an opportunity for any final thoughts for the technologists out there in finance, or for the treasury professionals about connectivity and API tech.

 

German Karaivanov  13:20

I think the best thing as a treasurer or technologist is, don’t always trust everything you hear, per se, make sure you’re doing your own research, and you’re aware of the limitations and benefits of different connectivity methods or different technologies that are available out there. So make sure you do your research. And if you’re struggling to find out what’s true or what’s not, or you need some advice, lots of experts in the field like Craig, or if you’re a treasury management customer of GTreasury, come and talk to your managers. You’ll get help and you’ll get advice.

 

Craig Jeffery  13:52

Alright, thanks German.

 

German Karaivanov  13:53

You’re welcome, Craig.  It’s been a pleasure.

 

Announcer  13:58

You’ve reached the end of another episode of the Treasury Update Podcast. Be sure to follow Strategic Treasurer on LinkedIn. Just search for Strategic Treasurer. This podcast is provided for informational purposes only and statements made by Strategic Treasurer LLC on this podcast are not intended as legal, business, consulting, or tax advice. For more information, visit and bookmark StrategicTreasurer.com.