From Spreadsheets to Security: Tokenizing Business Payments

In this episode, we speak with Bottomline’s Mark Bish about how tokenization—beyond PCI DSS—can secure B2B payments, and the importance of not holding customer banking data in spreadsheets or on systems where it’s accessible by employees. Mark shares how replacing bank account data with anonymous tokens, reduces fraud risk, simplifies compliance, and protects against both external and insider threats.

Episode Transcript

(00:18):
The Payments Podcast
from Bottomline.
Welcome to The Payments Podcast. I'm your host,
Bottomline Managing Editor, Owen McDonald.
We're focusing on data security and risk in
this episode.
Specifically, we're looking at the use of tokenization
in business payments.
But if you think I mean the payment
card industry data security standard or PCI DSS

(00:41):
for short, you'd be mistaken.
There's another form of tokenization
tailor made for b two b payments.
We're going to talk about that.
Joining us for this adventure in payment security
is Mark Bish, principal product manager at Bottomline.
Mark Bish, welcome to the payments podcast.
Hi. Thank you for having me along.
Let me jump right in by asking you,

(01:03):
Mark, to explain the difference between tokenization
for consumer payment cards, like I mentioned in
my opening and this, dare I say, better
approach to business payments tokenization?
Yeah. I think I think that's a great
place to start as the the focus of
the two services is, very different. When you
mentioned tokenization, you immediately think about credit and

(01:24):
debit cards, And that's because the risk of
exposure of details in those services is so
significant.
And so those services are really highly visible.
They simplify
compliance with regulations like PCI DSS
that have been put in place to protect
cardholder information and protect
people from fraud.
The focus we've taken is on providing

(01:47):
a sort of a very similar kind of
protection for bank account data, but enabling organizations
to not only replace the bank account data
that they hold with a unique, randomly generated
token, but also verify the account holder at
the same time as well.
And that's been driven by
a continued need to firstly minimize the risk

(02:07):
of payments to a fraudulent account by ensuring
that the account holder is who you believe
it to be,
and secondly, the growing emphasis on avoiding the
storage of sensitive bank account details
due to the risk of data breaches, whether
that's hacking, insider fraud, or or just simple
human error.
Now we spoke recently about a problem businesses

(02:29):
have managing the risk attack surface, and that's
a term describing
having bank account details held in multiple places
from spreadsheets to ERPs,
each with
different levels of security.
Mark, explain the major points in that risk
equation
and how tokenization
shrinks the risk footprint.

(02:51):
I think the challenge is as you've alluded
to,
in in the question.
Frequently, people hold
account details in multiple places within their business.
And the tools that they use to hold
the data vary greatly dependent on the purpose.
And each of those tools has different security
levels.
Some examples could be,

(03:11):
customer account data held in an ERP, an
enterprise
resource plumbing system,
a customer relationship management system,
or payroll might hold account details
in a spreadsheet,
or they might do the same for one
off or supplier payments.
And then when you create a payment file,
again, that process is going to vary.

(03:32):
ERPs or CRMs may generate a payment file
directly and place it in a folder ready
for processing.
But payment files are often submitted without first
verifying the account holder. As I mentioned earlier
on, it's really key to make sure that
the person that you're paying is who that
you believe them to be.
And there could be challenges around
auditing the file contents

(03:52):
and traceability to the source. How do you
know what's in that file when you make
a payment is what you put in there,
when you created the file. If you look
at things like payroll supplier, where they've maybe
got
payments held within a spreadsheet,
They may create the file, pass it on
to another team for processing.
Those files are often sent unencrypted
by email or, you know, passed across through

(04:15):
a folder.
Again, there's no audit trail. There's no version
control of those files.
And those unencrypted files could be viewed, edited,
rekeyed into separate portals, and there's little or
no traceability back to the original source. And
that's a real challenge.
So if you look at all of the
numerous places where the data is held,
that means there's numerous places where problems can

(04:37):
occur.
So internal fraud with limited traceability, you know,
altered bank account details
without any verification.
Manually rekeying can do something as simple as
just introduce a mistake.
Unintentional data leaks, you know, somebody sending an
email could send it to the wrong person
or could even send it outside the business.
And because the files are all over the

(04:57):
business, there's multiple places where hackers can get
in and access that information.
If you think about it,
from our perspective, as a payment processor, we
have to have account details,
because we're processing the payment.
But as a payment requester, then that's not
really the case. You just need to be
able to tell us who you are paying,

(05:18):
how much and when, and then we can
deal with the rest of it. And that's
really the solution that we have.
What we've enabled customers to do is to
manage their risk by removing
bank account details from their business systems
and replacing them with anonymous tokens.
The service can work through an API, so
you can embed it into front end forms

(05:39):
where you're capturing people's information, or where you've
got low volume
environments such as payroll. You could process that
information via a UI.
When you want to make a payment, you
use the token instead of the bank account
details.
There's no rekeying, no unexpected errors. There's no
manual fixes required to the system. It's a
simple file of, here's the token, here's the

(05:59):
value, here's the date, and we can process
that information.
What the tokenization
service will do, it will, take that file,
enrich it with the verified account data,
convert it to the correct format for the
payment system, and push it downstream,
through the payment processor. So it's a really
straightforward service.
And it shrinks the

(06:20):
risk footprint down to virtually zero, doesn't it?
Replacing the bank account data with tokens just
really reduce the the risk surface area because
you're not holding,
banking account details in multiple places around the
business.
If you don't hold the bank account data,
therefore, that bank account data is not exposed
to leakage, to hacking, to misdirected files.

(06:41):
Plus from an internal fraud perspective, it's not
exposed internally to your own users either. So
it's a much better way to do things,
and you're not exposing that kind of data
across your business systems.
You're based in The UK where we saw
recent high profile as cyberattacks on household names
that I won't mention, but we all know
who they are. To what extent can such

(07:03):
attacks
and those targeting b to b payments
be stopped using tokenization
like we're talking about?
So the the short answer is that, no,
you you can't really do a lot to
deflect hostile attacks as fraudsters are continuously looking
for
weaknesses within business systems. They want to gain
access to whatever data they can.

(07:25):
What tokenization
does, though, is it reduces, as we've mentioned
before, the risk surface area.
So not holding that bank account data that
you rely on to make payments.
So by putting
the bank account data out of reach of
the fraudsters,
the breadth of the data they can gain
access to is reduced. And that helps to
lessen the impact of a data breach on
customers, suppliers,

(07:46):
employees. So, no, you can't stop the attacks,
but you can lessen the impact of them
for certain.
Seems to me this form of tokenization
could be especially effective against insider fraud. You
alluded to that earlier.
It's a huge and growing problem.
How does tokenization
help prevent

(08:06):
insider fraud specifically, Mark?
I think a good place there is to
think about
what we mean by an insider fraud and
and why it can happen. So think of
all of the attack vectors. So,
if I can change account details against a
record in an ERP or a CRM,
is it audited, and would they know that
I did it?

(08:27):
If I can access a folder where payment
files are processed, ready for processing, if I
edit the file and change the bank account
details, will I be identified as the culprit?
The same for, account numbers in, say, a
payroll or a supplier file. Will I be
identified if I, type a different account number
in that's been given to me into a
payment system? And perhaps I can change the

(08:48):
file that was sent. So will you be
able to identify that I was the corporate
and I perform that?
If I've got a spreadsheet,
can I copy it?
Will you know that I've copied it? Can
I take a photograph of it with my
phone so I have it on my phone?
Could I even email it to myself outside,
or would you even identify that I've sent
those account details out? So

(09:11):
if you change nothing else in that whole
process with those systems the way that they
work right now, if you replace the account
number with an anonymous token
only relevant to me in my business,
none of those actions would provide the insider
with the ability to commit fraud
because they can't steal the account details because
they're not there. They can't overkey them because

(09:31):
they're not there. They're anonymous tokens. I mean,
how simple is that?
And I'm not saying that organizations shouldn't do
more to tighten things up to if they
can make their services more secure, but that
simple straightforward change just removes a whole chunk
of data and makes it useless to the
fraudster.
Agreed. And and we talk a lot here
at Bottom Line, various,

(09:53):
subject matter experts about a layered approach to
security, but clearly this has its place. Last
question, Mark. What parting advice
would you give to AP teams and others
as it relates to improving the security of
payment accounts and particularly
the processes used to make payments more secure?
I think the first thing that I need

(10:13):
to do is to look across
the business and identify where they I'll look
at details.
Who has access to the data? Where do
they store payment files? Who has access to
payment files?
How are files shared around the business? You
know, are they done securely? Are they encrypted,
etcetera?
What processes are in place to ensure data
lineage? And that's sort of the knowledge that

(10:35):
the information that you've captured
at the point where you've onboarded a customer
or supplier
is the same as the account that you're
paying. That that that's really important to understand.
I'm sure that lots of organisations have got
that totally nailed down. But I'm sure there's
lots and lots that would be able to
do a lot more to prevent their exposure.

(10:55):
And if they did that investigation, they might
find they're more exposed than they perhaps thought
they were. And then if they think about
what it would mean to them just by
simply removing bank account details and how it
would improve that exposure for them, I think
that's the the key place where they need
to start off.
There it is.
Chances are that you started listening to this
episode with one understanding of tokenization

(11:17):
and you are leaving with a different understanding.
We hope so. Thanks to our excellent guest,
Mark Bish, principal product manager at Bottomline.
To our audience, the smartest people in payments,
thanks for listening. Hit subscribe.
Catch us again on your favorite podcast platforms,
including Apple and Spotify. Bye for now.

(11:49):
The payments podcast,
from bottom line.