1 00:00:18,404 --> 00:00:19,625 The Payments Podcast 2 00:00:20,324 --> 00:00:21,224 from Bottomline. 3 00:00:22,564 --> 00:00:25,125 Welcome to The Payments Podcast. I'm your host, 4 00:00:25,125 --> 00:00:27,464 Bottomline Managing Editor, Owen McDonald. 5 00:00:28,160 --> 00:00:30,480 We're focusing on data security and risk in 6 00:00:30,480 --> 00:00:31,219 this episode. 7 00:00:31,519 --> 00:00:33,780 Specifically, we're looking at the use of tokenization 8 00:00:34,159 --> 00:00:35,219 in business payments. 9 00:00:35,759 --> 00:00:37,840 But if you think I mean the payment 10 00:00:37,840 --> 00:00:41,700 card industry data security standard or PCI DSS 11 00:00:41,760 --> 00:00:43,140 for short, you'd be mistaken. 12 00:00:43,734 --> 00:00:45,195 There's another form of tokenization 13 00:00:45,575 --> 00:00:47,354 tailor made for b two b payments. 14 00:00:47,975 --> 00:00:49,835 We're going to talk about that. 15 00:00:50,375 --> 00:00:52,695 Joining us for this adventure in payment security 16 00:00:52,695 --> 00:00:56,155 is Mark Bish, principal product manager at Bottomline. 17 00:00:56,770 --> 00:00:58,710 Mark Bish, welcome to the payments podcast. 18 00:00:59,010 --> 00:01:00,710 Hi. Thank you for having me along. 19 00:01:01,409 --> 00:01:03,090 Let me jump right in by asking you, 20 00:01:03,090 --> 00:01:05,590 Mark, to explain the difference between tokenization 21 00:01:06,209 --> 00:01:08,770 for consumer payment cards, like I mentioned in 22 00:01:08,770 --> 00:01:11,994 my opening and this, dare I say, better 23 00:01:11,994 --> 00:01:13,935 approach to business payments tokenization? 24 00:01:14,954 --> 00:01:16,155 Yeah. I think I think that's a great 25 00:01:16,155 --> 00:01:18,234 place to start as the the focus of 26 00:01:18,234 --> 00:01:21,194 the two services is, very different. When you 27 00:01:21,194 --> 00:01:24,394 mentioned tokenization, you immediately think about credit and 28 00:01:24,394 --> 00:01:26,599 debit cards, And that's because the risk of 29 00:01:26,599 --> 00:01:29,400 exposure of details in those services is so 30 00:01:29,400 --> 00:01:29,900 significant. 31 00:01:30,680 --> 00:01:33,180 And so those services are really highly visible. 32 00:01:33,239 --> 00:01:33,979 They simplify 33 00:01:34,439 --> 00:01:37,180 compliance with regulations like PCI DSS 34 00:01:37,799 --> 00:01:39,659 that have been put in place to protect 35 00:01:40,185 --> 00:01:41,885 cardholder information and protect 36 00:01:42,504 --> 00:01:43,564 people from fraud. 37 00:01:44,104 --> 00:01:46,204 The focus we've taken is on providing 38 00:01:47,144 --> 00:01:48,745 a sort of a very similar kind of 39 00:01:48,745 --> 00:01:51,805 protection for bank account data, but enabling organizations 40 00:01:52,185 --> 00:01:54,924 to not only replace the bank account data 41 00:01:55,390 --> 00:01:58,109 that they hold with a unique, randomly generated 42 00:01:58,109 --> 00:02:00,829 token, but also verify the account holder at 43 00:02:00,829 --> 00:02:02,049 the same time as well. 44 00:02:02,750 --> 00:02:04,130 And that's been driven by 45 00:02:05,150 --> 00:02:07,469 a continued need to firstly minimize the risk 46 00:02:07,469 --> 00:02:10,189 of payments to a fraudulent account by ensuring 47 00:02:10,189 --> 00:02:12,504 that the account holder is who you believe 48 00:02:12,504 --> 00:02:13,324 it to be, 49 00:02:13,625 --> 00:02:16,264 and secondly, the growing emphasis on avoiding the 50 00:02:16,264 --> 00:02:18,365 storage of sensitive bank account details 51 00:02:19,145 --> 00:02:21,544 due to the risk of data breaches, whether 52 00:02:21,544 --> 00:02:24,104 that's hacking, insider fraud, or or just simple 53 00:02:24,104 --> 00:02:24,960 human error. 54 00:02:26,159 --> 00:02:29,840 Now we spoke recently about a problem businesses 55 00:02:29,840 --> 00:02:33,120 have managing the risk attack surface, and that's 56 00:02:33,120 --> 00:02:34,500 a term describing 57 00:02:35,280 --> 00:02:37,840 having bank account details held in multiple places 58 00:02:37,840 --> 00:02:39,460 from spreadsheets to ERPs, 59 00:02:40,094 --> 00:02:40,754 each with 60 00:02:41,215 --> 00:02:42,354 different levels of security. 61 00:02:42,894 --> 00:02:45,935 Mark, explain the major points in that risk 62 00:02:45,935 --> 00:02:46,435 equation 63 00:02:46,814 --> 00:02:47,955 and how tokenization 64 00:02:48,655 --> 00:02:50,275 shrinks the risk footprint. 65 00:02:51,215 --> 00:02:53,134 I think the challenge is as you've alluded 66 00:02:53,134 --> 00:02:53,634 to, 67 00:02:54,014 --> 00:02:54,914 in in the question. 68 00:02:55,699 --> 00:02:57,080 Frequently, people hold 69 00:02:57,539 --> 00:03:00,439 account details in multiple places within their business. 70 00:03:00,740 --> 00:03:02,419 And the tools that they use to hold 71 00:03:02,419 --> 00:03:05,560 the data vary greatly dependent on the purpose. 72 00:03:06,020 --> 00:03:08,099 And each of those tools has different security 73 00:03:08,099 --> 00:03:08,599 levels. 74 00:03:09,405 --> 00:03:10,865 Some examples could be, 75 00:03:11,485 --> 00:03:14,125 customer account data held in an ERP, an 76 00:03:14,125 --> 00:03:14,625 enterprise 77 00:03:15,085 --> 00:03:16,385 resource plumbing system, 78 00:03:17,085 --> 00:03:19,104 a customer relationship management system, 79 00:03:19,805 --> 00:03:22,064 or payroll might hold account details 80 00:03:22,365 --> 00:03:23,185 in a spreadsheet, 81 00:03:23,569 --> 00:03:25,169 or they might do the same for one 82 00:03:25,169 --> 00:03:26,550 off or supplier payments. 83 00:03:27,090 --> 00:03:29,349 And then when you create a payment file, 84 00:03:29,889 --> 00:03:31,909 again, that process is going to vary. 85 00:03:32,450 --> 00:03:35,010 ERPs or CRMs may generate a payment file 86 00:03:35,010 --> 00:03:37,010 directly and place it in a folder ready 87 00:03:37,010 --> 00:03:37,669 for processing. 88 00:03:38,614 --> 00:03:41,414 But payment files are often submitted without first 89 00:03:41,414 --> 00:03:44,134 verifying the account holder. As I mentioned earlier 90 00:03:44,134 --> 00:03:46,055 on, it's really key to make sure that 91 00:03:46,055 --> 00:03:47,414 the person that you're paying is who that 92 00:03:47,414 --> 00:03:48,634 you believe them to be. 93 00:03:49,094 --> 00:03:50,794 And there could be challenges around 94 00:03:51,189 --> 00:03:52,569 auditing the file contents 95 00:03:52,870 --> 00:03:54,789 and traceability to the source. How do you 96 00:03:54,789 --> 00:03:56,469 know what's in that file when you make 97 00:03:56,469 --> 00:03:58,650 a payment is what you put in there, 98 00:03:59,189 --> 00:04:01,270 when you created the file. If you look 99 00:04:01,270 --> 00:04:03,430 at things like payroll supplier, where they've maybe 100 00:04:03,430 --> 00:04:03,930 got 101 00:04:04,469 --> 00:04:06,330 payments held within a spreadsheet, 102 00:04:06,814 --> 00:04:08,254 They may create the file, pass it on 103 00:04:08,254 --> 00:04:09,555 to another team for processing. 104 00:04:10,094 --> 00:04:11,955 Those files are often sent unencrypted 105 00:04:12,414 --> 00:04:15,455 by email or, you know, passed across through 106 00:04:15,455 --> 00:04:16,115 a folder. 107 00:04:16,415 --> 00:04:18,495 Again, there's no audit trail. There's no version 108 00:04:18,495 --> 00:04:19,795 control of those files. 109 00:04:20,250 --> 00:04:22,970 And those unencrypted files could be viewed, edited, 110 00:04:22,970 --> 00:04:25,930 rekeyed into separate portals, and there's little or 111 00:04:25,930 --> 00:04:28,810 no traceability back to the original source. And 112 00:04:28,810 --> 00:04:29,949 that's a real challenge. 113 00:04:30,490 --> 00:04:32,170 So if you look at all of the 114 00:04:32,170 --> 00:04:34,270 numerous places where the data is held, 115 00:04:34,735 --> 00:04:37,215 that means there's numerous places where problems can 116 00:04:37,215 --> 00:04:37,715 occur. 117 00:04:38,095 --> 00:04:40,975 So internal fraud with limited traceability, you know, 118 00:04:40,975 --> 00:04:42,435 altered bank account details 119 00:04:42,975 --> 00:04:44,115 without any verification. 120 00:04:44,975 --> 00:04:47,455 Manually rekeying can do something as simple as 121 00:04:47,455 --> 00:04:48,754 just introduce a mistake. 122 00:04:49,419 --> 00:04:51,899 Unintentional data leaks, you know, somebody sending an 123 00:04:51,899 --> 00:04:53,339 email could send it to the wrong person 124 00:04:53,339 --> 00:04:55,439 or could even send it outside the business. 125 00:04:56,060 --> 00:04:57,899 And because the files are all over the 126 00:04:57,899 --> 00:05:00,620 business, there's multiple places where hackers can get 127 00:05:00,620 --> 00:05:01,919 in and access that information. 128 00:05:03,205 --> 00:05:04,585 If you think about it, 129 00:05:06,085 --> 00:05:08,485 from our perspective, as a payment processor, we 130 00:05:08,485 --> 00:05:09,865 have to have account details, 131 00:05:10,245 --> 00:05:12,025 because we're processing the payment. 132 00:05:12,645 --> 00:05:15,080 But as a payment requester, then that's not 133 00:05:15,080 --> 00:05:16,920 really the case. You just need to be 134 00:05:16,920 --> 00:05:18,439 able to tell us who you are paying, 135 00:05:18,439 --> 00:05:19,879 how much and when, and then we can 136 00:05:19,879 --> 00:05:21,560 deal with the rest of it. And that's 137 00:05:21,560 --> 00:05:23,259 really the solution that we have. 138 00:05:24,360 --> 00:05:26,680 What we've enabled customers to do is to 139 00:05:26,680 --> 00:05:28,595 manage their risk by removing 140 00:05:29,615 --> 00:05:31,875 bank account details from their business systems 141 00:05:32,334 --> 00:05:34,675 and replacing them with anonymous tokens. 142 00:05:35,454 --> 00:05:37,214 The service can work through an API, so 143 00:05:37,214 --> 00:05:39,214 you can embed it into front end forms 144 00:05:39,214 --> 00:05:41,535 where you're capturing people's information, or where you've 145 00:05:41,535 --> 00:05:42,514 got low volume 146 00:05:43,330 --> 00:05:46,209 environments such as payroll. You could process that 147 00:05:46,209 --> 00:05:47,509 information via a UI. 148 00:05:48,050 --> 00:05:49,490 When you want to make a payment, you 149 00:05:49,490 --> 00:05:51,330 use the token instead of the bank account 150 00:05:51,330 --> 00:05:51,830 details. 151 00:05:52,209 --> 00:05:54,850 There's no rekeying, no unexpected errors. There's no 152 00:05:54,850 --> 00:05:57,714 manual fixes required to the system. It's a 153 00:05:57,714 --> 00:05:59,714 simple file of, here's the token, here's the 154 00:05:59,714 --> 00:06:01,795 value, here's the date, and we can process 155 00:06:01,795 --> 00:06:02,535 that information. 156 00:06:03,314 --> 00:06:04,214 What the tokenization 157 00:06:04,514 --> 00:06:07,314 service will do, it will, take that file, 158 00:06:07,314 --> 00:06:09,415 enrich it with the verified account data, 159 00:06:09,759 --> 00:06:11,520 convert it to the correct format for the 160 00:06:11,520 --> 00:06:13,459 payment system, and push it downstream, 161 00:06:13,839 --> 00:06:15,759 through the payment processor. So it's a really 162 00:06:15,759 --> 00:06:16,899 straightforward service. 163 00:06:18,160 --> 00:06:19,620 And it shrinks the 164 00:06:20,000 --> 00:06:23,865 risk footprint down to virtually zero, doesn't it? 165 00:06:24,104 --> 00:06:26,264 Replacing the bank account data with tokens just 166 00:06:26,264 --> 00:06:29,064 really reduce the the risk surface area because 167 00:06:29,064 --> 00:06:29,964 you're not holding, 168 00:06:30,745 --> 00:06:33,144 banking account details in multiple places around the 169 00:06:33,144 --> 00:06:33,644 business. 170 00:06:34,104 --> 00:06:35,944 If you don't hold the bank account data, 171 00:06:35,944 --> 00:06:38,285 therefore, that bank account data is not exposed 172 00:06:38,629 --> 00:06:41,289 to leakage, to hacking, to misdirected files. 173 00:06:41,589 --> 00:06:43,829 Plus from an internal fraud perspective, it's not 174 00:06:43,829 --> 00:06:46,069 exposed internally to your own users either. So 175 00:06:46,069 --> 00:06:47,930 it's a much better way to do things, 176 00:06:47,990 --> 00:06:50,229 and you're not exposing that kind of data 177 00:06:50,229 --> 00:06:51,529 across your business systems. 178 00:06:52,785 --> 00:06:54,865 You're based in The UK where we saw 179 00:06:54,865 --> 00:06:58,485 recent high profile as cyberattacks on household names 180 00:06:59,585 --> 00:07:01,345 that I won't mention, but we all know 181 00:07:01,345 --> 00:07:03,904 who they are. To what extent can such 182 00:07:03,904 --> 00:07:04,404 attacks 183 00:07:04,785 --> 00:07:06,870 and those targeting b to b payments 184 00:07:07,189 --> 00:07:08,889 be stopped using tokenization 185 00:07:09,910 --> 00:07:11,129 like we're talking about? 186 00:07:12,229 --> 00:07:14,870 So the the short answer is that, no, 187 00:07:14,870 --> 00:07:16,629 you you can't really do a lot to 188 00:07:16,629 --> 00:07:19,910 deflect hostile attacks as fraudsters are continuously looking 189 00:07:19,910 --> 00:07:20,410 for 190 00:07:20,725 --> 00:07:23,125 weaknesses within business systems. They want to gain 191 00:07:23,125 --> 00:07:24,904 access to whatever data they can. 192 00:07:25,365 --> 00:07:26,185 What tokenization 193 00:07:26,485 --> 00:07:28,725 does, though, is it reduces, as we've mentioned 194 00:07:28,725 --> 00:07:30,425 before, the risk surface area. 195 00:07:30,725 --> 00:07:32,964 So not holding that bank account data that 196 00:07:32,964 --> 00:07:34,425 you rely on to make payments. 197 00:07:34,959 --> 00:07:35,860 So by putting 198 00:07:36,720 --> 00:07:38,399 the bank account data out of reach of 199 00:07:38,399 --> 00:07:39,139 the fraudsters, 200 00:07:39,919 --> 00:07:41,360 the breadth of the data they can gain 201 00:07:41,360 --> 00:07:43,199 access to is reduced. And that helps to 202 00:07:43,199 --> 00:07:45,199 lessen the impact of a data breach on 203 00:07:45,199 --> 00:07:46,259 customers, suppliers, 204 00:07:46,639 --> 00:07:49,574 employees. So, no, you can't stop the attacks, 205 00:07:49,574 --> 00:07:51,254 but you can lessen the impact of them 206 00:07:51,254 --> 00:07:51,995 for certain. 207 00:07:52,935 --> 00:07:54,714 Seems to me this form of tokenization 208 00:07:55,574 --> 00:07:59,495 could be especially effective against insider fraud. You 209 00:07:59,495 --> 00:08:00,795 alluded to that earlier. 210 00:08:01,180 --> 00:08:03,120 It's a huge and growing problem. 211 00:08:04,139 --> 00:08:05,039 How does tokenization 212 00:08:05,339 --> 00:08:06,399 help prevent 213 00:08:06,779 --> 00:08:08,879 insider fraud specifically, Mark? 214 00:08:09,339 --> 00:08:10,779 I think a good place there is to 215 00:08:10,779 --> 00:08:11,599 think about 216 00:08:12,139 --> 00:08:14,334 what we mean by an insider fraud and 217 00:08:14,334 --> 00:08:16,095 and why it can happen. So think of 218 00:08:16,095 --> 00:08:18,274 all of the attack vectors. So, 219 00:08:18,735 --> 00:08:21,055 if I can change account details against a 220 00:08:21,055 --> 00:08:22,915 record in an ERP or a CRM, 221 00:08:23,694 --> 00:08:25,774 is it audited, and would they know that 222 00:08:25,774 --> 00:08:26,514 I did it? 223 00:08:27,670 --> 00:08:29,430 If I can access a folder where payment 224 00:08:29,430 --> 00:08:31,830 files are processed, ready for processing, if I 225 00:08:31,830 --> 00:08:33,910 edit the file and change the bank account 226 00:08:33,910 --> 00:08:37,129 details, will I be identified as the culprit? 227 00:08:38,149 --> 00:08:40,470 The same for, account numbers in, say, a 228 00:08:40,470 --> 00:08:42,845 payroll or a supplier file. Will I be 229 00:08:42,845 --> 00:08:45,485 identified if I, type a different account number 230 00:08:45,485 --> 00:08:46,764 in that's been given to me into a 231 00:08:46,764 --> 00:08:48,605 payment system? And perhaps I can change the 232 00:08:48,605 --> 00:08:50,044 file that was sent. So will you be 233 00:08:50,044 --> 00:08:51,985 able to identify that I was the corporate 234 00:08:52,204 --> 00:08:53,504 and I perform that? 235 00:08:54,459 --> 00:08:55,600 If I've got a spreadsheet, 236 00:08:56,539 --> 00:08:57,600 can I copy it? 237 00:08:58,539 --> 00:09:00,220 Will you know that I've copied it? Can 238 00:09:00,220 --> 00:09:01,899 I take a photograph of it with my 239 00:09:01,899 --> 00:09:03,500 phone so I have it on my phone? 240 00:09:03,740 --> 00:09:05,740 Could I even email it to myself outside, 241 00:09:05,740 --> 00:09:07,919 or would you even identify that I've sent 242 00:09:08,125 --> 00:09:10,225 those account details out? So 243 00:09:11,004 --> 00:09:13,004 if you change nothing else in that whole 244 00:09:13,004 --> 00:09:15,485 process with those systems the way that they 245 00:09:15,485 --> 00:09:17,884 work right now, if you replace the account 246 00:09:17,884 --> 00:09:19,585 number with an anonymous token 247 00:09:20,125 --> 00:09:21,985 only relevant to me in my business, 248 00:09:23,059 --> 00:09:25,220 none of those actions would provide the insider 249 00:09:25,220 --> 00:09:27,000 with the ability to commit fraud 250 00:09:27,620 --> 00:09:29,779 because they can't steal the account details because 251 00:09:29,779 --> 00:09:31,860 they're not there. They can't overkey them because 252 00:09:31,860 --> 00:09:34,340 they're not there. They're anonymous tokens. I mean, 253 00:09:34,340 --> 00:09:35,445 how simple is that? 254 00:09:36,325 --> 00:09:38,565 And I'm not saying that organizations shouldn't do 255 00:09:38,565 --> 00:09:40,965 more to tighten things up to if they 256 00:09:40,965 --> 00:09:42,884 can make their services more secure, but that 257 00:09:42,884 --> 00:09:45,845 simple straightforward change just removes a whole chunk 258 00:09:45,845 --> 00:09:47,365 of data and makes it useless to the 259 00:09:47,365 --> 00:09:47,865 fraudster. 260 00:09:48,779 --> 00:09:51,019 Agreed. And and we talk a lot here 261 00:09:51,019 --> 00:09:52,639 at Bottom Line, various, 262 00:09:53,340 --> 00:09:55,820 subject matter experts about a layered approach to 263 00:09:55,820 --> 00:09:58,779 security, but clearly this has its place. Last 264 00:09:58,779 --> 00:10:01,120 question, Mark. What parting advice 265 00:10:01,815 --> 00:10:04,315 would you give to AP teams and others 266 00:10:04,375 --> 00:10:06,774 as it relates to improving the security of 267 00:10:06,774 --> 00:10:08,475 payment accounts and particularly 268 00:10:08,855 --> 00:10:11,754 the processes used to make payments more secure? 269 00:10:12,535 --> 00:10:13,735 I think the first thing that I need 270 00:10:13,735 --> 00:10:14,955 to do is to look across 271 00:10:15,429 --> 00:10:17,830 the business and identify where they I'll look 272 00:10:17,830 --> 00:10:18,490 at details. 273 00:10:19,190 --> 00:10:20,950 Who has access to the data? Where do 274 00:10:20,950 --> 00:10:23,429 they store payment files? Who has access to 275 00:10:23,429 --> 00:10:24,410 payment files? 276 00:10:24,950 --> 00:10:26,950 How are files shared around the business? You 277 00:10:26,950 --> 00:10:28,870 know, are they done securely? Are they encrypted, 278 00:10:28,870 --> 00:10:29,370 etcetera? 279 00:10:30,325 --> 00:10:32,565 What processes are in place to ensure data 280 00:10:32,565 --> 00:10:35,605 lineage? And that's sort of the knowledge that 281 00:10:35,605 --> 00:10:37,065 the information that you've captured 282 00:10:37,524 --> 00:10:39,524 at the point where you've onboarded a customer 283 00:10:39,524 --> 00:10:40,184 or supplier 284 00:10:40,565 --> 00:10:42,245 is the same as the account that you're 285 00:10:42,245 --> 00:10:44,985 paying. That that that's really important to understand. 286 00:10:46,120 --> 00:10:48,279 I'm sure that lots of organisations have got 287 00:10:48,279 --> 00:10:50,600 that totally nailed down. But I'm sure there's 288 00:10:50,600 --> 00:10:53,000 lots and lots that would be able to 289 00:10:53,000 --> 00:10:55,179 do a lot more to prevent their exposure. 290 00:10:55,799 --> 00:10:57,720 And if they did that investigation, they might 291 00:10:57,720 --> 00:10:59,639 find they're more exposed than they perhaps thought 292 00:10:59,639 --> 00:11:01,784 they were. And then if they think about 293 00:11:01,784 --> 00:11:03,225 what it would mean to them just by 294 00:11:03,225 --> 00:11:05,225 simply removing bank account details and how it 295 00:11:05,225 --> 00:11:07,544 would improve that exposure for them, I think 296 00:11:07,544 --> 00:11:08,824 that's the the key place where they need 297 00:11:08,824 --> 00:11:09,725 to start off. 298 00:11:10,504 --> 00:11:11,485 There it is. 299 00:11:11,944 --> 00:11:14,159 Chances are that you started listening to this 300 00:11:14,399 --> 00:11:16,659 episode with one understanding of tokenization 301 00:11:17,600 --> 00:11:19,699 and you are leaving with a different understanding. 302 00:11:20,079 --> 00:11:22,559 We hope so. Thanks to our excellent guest, 303 00:11:22,559 --> 00:11:25,220 Mark Bish, principal product manager at Bottomline. 304 00:11:26,654 --> 00:11:28,735 To our audience, the smartest people in payments, 305 00:11:28,735 --> 00:11:30,514 thanks for listening. Hit subscribe. 306 00:11:30,975 --> 00:11:33,235 Catch us again on your favorite podcast platforms, 307 00:11:33,455 --> 00:11:36,274 including Apple and Spotify. Bye for now. 308 00:11:49,209 --> 00:11:50,429 The payments podcast, 309 00:11:51,129 --> 00:11:52,350 from bottom line.