Jim Hunt: Thank you. So what does it take to enable straight through processing with banks?

Paul Miller: Well, it’s, it can be quite a big project. It could be, as quickly as a month or it could be three months. Basically you have to have the services enabled at the bank. You have to define your scope, of course. Are we doing local payments? Are we doing international payments? Are we doing low value type payments like ACH or SEPA? Are we doing a high value payments, like wire transfer. And then which currencies do we operate in, that sort of thing. So you would define your scope, turn the services with the bank and then you’d have to enable in your ERP, basically the creation of the records, first for the accounting, and then secondly to have all the payment instructions created and put on a file. And the way it works is we actually generate a file within our bank software, which in our case, it would be our ERP, talking about SAP in particular.

So in SAP we have a myriad of formats that we would set up, depending on what the bank accepts and what our scope is. But typically everyone’s moving toward an ISO XML format. Don’t worry too much about the technology. If you’re doing STP, you’ll you’ll know what you need, or your consultant will help you find that, but we use the ISO XML and then that file pulls all the data and we use a secure connection to move that file to the bank. And then the bank does its processing from there.

Jim Hunt: So I would guess that some of the factors that might make a project more or less complex would be whether or not you have multiple banks, multiple currencies. That kind of thing?

Paul Miller: Yeah. You’re spot on because all of it, whatever you do in the system, based on your scope, you have to build it, completely from beginning to end, but you also have to test it and all the different scenarios. So the important thing is that you also have the security and controls in place at every step as well. So when you process a payment in your ERP, there’s a lot of front end work that’s already there that you can leverage. For instance, you have your vendors would be set up separately from your payable where the payment instructions are controlled within the vendor. The invoices themselves are controlled with POs, goods-receipts, and invoices. And then multiple people have to have to approve the PO and the invoice and then the payment itself.

So it’s well controlled on the front end. And then that file that gets generated and sent to the bank, there’s also lots of controls in there as well. Not only in terms of processing the payment, but also as the data passes through the channel to the bank. So you’re going to be sending a file over a secure connection with your bank. The file’s normally encrypted, there’s numerous ways to do the encryption. And then when the bank receives the file, then they process it on their system as well. So there’s, there’s quite a bit involved just to get the scope defined, to get all the data scenarios defined as well. So you’re right. The more different types of payments you do, payment methods, and the more currencies you use, there’s more setup required and more data required to be created as well to pass through.

Jim Hunt: Okay. I was going to ask you about fraud prevention and making sure that the payments go where they’re supposed to. I think you touched a little bit on that with separation of responsibilities and so on, but can you elaborate a little bit more about fraud and how to prevent it?

Paul Miller: Probably every company probably has an experience with fraud that they probably won’t share. I’ll tell you the banks certainly don’t they like to keep that a secret, but it’s out there. It’s common. And typically more often than not, it’s an inside job. Some of the more recent frauds have to do with phishing and the spammers are out there trying to take over our email. So sometimes it is process related. Sometimes it’s a bad apple internally. And the best way to prevent fraud is again, to put the controls in place up front so that we have multiple points where we have segregation of duties so that no one person has too much control to move a payment. And then secondly, we also have to have more automation. Our straight through processing also helps alleviate some of the fraud. For instance, it’s hard to set up a spamming or phishing type of a fraud where someone sends an email or they hack into the email of the assistant treasurer, and then use that account to request an analyst to move money.

If that’s not part of our process, then we’re not susceptible to that type of fraud. So if we keep it all system based and we have it locked off from the outside world, that’s one way. And as you mentioned, the encryption, the secure files, the secure networks, those are all ways that we mitigate our risk when it comes to payments going the wrong way.

Jim Hunt: Okay. So what could go wrong if a payment fails or if it was misdirected?

Paul Miller: Well, so this is more mistakes, as opposed to frauds themselves, If someone steals our money, it’s gone, then they’ll skip it through multiple banks. If we don’t catch it fast enough, it’s usually long gone. If an account’s closed, you really can’t retrieve the money. So, so the professional fraudsters, that’s what they’ll do. They’ll wire the money offshore, move it to another account, physically withdraw it and close it. There’s not much you can do other than prevent that upfront, but let’s say we have a payment instruction that’s incorrect. And then it goes to the bank and they charge us. But then the item, basically what happens is the item would be rejected at the bank. Let’s say we sent the wrong account number for our vendor. And that was a mistake that happens quite often, that money would go out and it would just get rejected by the bank and come back in and be sent back to our account. But it doesn’t sound like it’s a major difficulty and we were going to get our money back. But what happens is it takes our analysts, you know, multiple analysts, multiple hours to make the corrections. They have to do reversals and reprocessing. And it’s just the type of work that isn’t very glorious.

Paul Miller: It takes time and it kind of holds us down. So if we have even a 1% error rate on the back end, it just takes a lot of time, every process. So we want to kind of avoid things going wrong. So that’s one of the things that can go wrong. We can have an incorrect instruction, or maybe our customer had an issue with their account and it was closed. That sort of thing. Rejections happen for that reason. Sometimes there’s a technical error between the banks. So with the payment network, those are rare, but those are the types of things that could happen.

Jim Hunt: So that kind of brings us back to the importance of the robustness of the straight through processing end-to-end payment channel. So back to the penny test, is that something that you would do one time to confirm setting up the system or do you come back and do the penny test with small payments multiple times? How does it fit into the overall picture?

Paul Miller: Hey, penny testing is kinda like having a belt with suspenders, right? So your suspenders is all the testing you do on your normal project. You have your scenarios, well-defined you test every single scenario. You do it in a test system. You make sure internally that all your scenarios pass, it’s a well-documented process. When you’re ready, then you can move it into production. But before you move it into production, I guess I skipped the step. Not only do we do our testing internally within our system. We also test with the bank. So from our test system to their test system, just to ensure that when we send a file, it has the right format and has the right types of instructions.

Paul Miller: The right information is in the right place, so that they’re able to process correctly. And so that’s purely a technical test. What it doesn’t do is prevent some of the real world examples, for instance, where you have the wrong vendor instructions set up, or there’s things that the bank needs to do at, at runtime to make sure that the payment goes so you do all of your suspender testing right upfront, and you think you’re good to go. And, you know, I would say more than half, the three quarters of projects might run with only that type of testing. The penny testing is the extra credit. That’s where you put the belt on, on top of your suspenders, because what could happen is you want to make sure that, that bank, if you’re sending a single payment file and maybe you’re combining some local payments with some foreign payments with some merchant payments in the same file, the bank has to split those payments up all three and route them different ways.

Paul Miller: And the only way to test that the bank can get it right on their backend is to do it in real time in a live system. You can’t do live testing before go live. Obviously you can do the best you can within a test system, but nothing beats doing it in the productive system. Some of the banks recommend that you do that others don’t, but I would highly recommend all my clients to ask your bank, to allow them to do the penny tests and all these cases, because not only does it test the channel, the pipe between us and the bank and that everything works correctly, that we have the encryption keys set up properly, that the file format and layouts are correct, one last time. It also makes sure that the end to end processing works so that the bank can route the payments correctly. And then also has the added benefit of going out to the receiving bank and doing a double check on those vendor payment instructions as well. So when you make that million dollar payment next week, we know it’ll work because we made the penny test this week.

Jim Hunt: Perfect wrap up. So you said that, approximately 75% of the projects you’ve worked on companies, do penny testing, why does the 25% not do penny testing?

Paul Miller: I think we’ve evolved over time. I think upfront, it wasn’t really that critical. Some of our scope seems smaller. Um, it was less complex in terms of how we did our work. I think the one thing with the single payment file and the ISO XML makes it more important that we do it.

Jim Hunt: Because there’s more with today’s systems and straight through processing, that end to end channel once you’ve set it up, that it better be working well because you don’t have stop points along the way to look at it and make sure it’s working well.

Paul Miller: There’s a lot more complexity involved. And if you look at our banks, we’ve boiled down to four or five large multinational cash management banks. Where in the past, that may have been a dozen or more. And so the dozen connection points are still there, but they’re behind the scenes. Now they’re part of the larger bank, you know? So like Bank of America has absorbed four or five different legacy banks, same with Chase. And so when you send the file to them to one location, they still route through a lot of those old systems. So it’s, it’s more, it’s more of a check for us to make sure that our bank counter-parties have their act together on their side.

Jim Hunt: It’s kind of like, you want to make sure that the, there are no leaks in the hose before you turn on full water pressure.

Paul Miller: Yeah, that’s real money we’re moving. Sometimes you can’t get it back once you move it. So you have to be very careful.

Jim Hunt: This has been a great session. Is there any wrap up you’d like to provide or advice to companies that are looking at instituting end-to-end payment?

Paul Miller: Just be very thorough, you know, try and make sure you have all your scenarios documented and just take your time. Don’t, don’t be surprised if it takes you three months to get something in that you thought you could do in a month or two it’s well worth the time.

Jim Hunt: Very good wrap up, Paul. Thank you very much for your time today. It’s been very informative.

Paul Miller: I appreciate it, Jim, anytime.