Talking Fintech & Fraud with Scott Benson, Sr. Compliance Officer at Melio

Trisha:

‍

"Scott, we would love to learn about your journey. Tell us about your story."

‍

‍

Scott:

‍

"So, up until 10 years ago, I was a legacy guy. I worked at big banks.

‍

I was a FINRA examiner. That was my background. Then, going back to 2013, something that triggered me to want to learn more was crypto and blockchain. And all I knew is that it looked fascinating and like there was a lot of promise there (and there still is), despite everything that's happened over the course of the last few months, especially the last few weeks.

‍

But there's a tremendous amount of promise there, but I wanted to do more with it. And that was just not something I could pursue within the confines of a traditional financial institution. I attempted, at the time, I was working for Citigroup, and they indeed acknowledged that what I was talking about was really intriguing and really interesting and certainly a concern for the bank, but, you know, fractional.

‍

So for me, that was the catalyst. The genesis for the idea of, I want to do something different.

‍

And,  initially, it was crypto, it was blockchain. I wanted to be one of the first compliance people to go out and be active and try to do something in that space. And that's where I've been for the last 10 years. But more broadly now, Fintech and payments, lending, not just crypto, and blockchain anymore."

‍

‍

Trisha:

‍

"It's really great to see FINRA examiner come to the, you know, the dark side.

‍

Well, I'd love to get a better sense in terms of, you know one thing that we talked about was build versus buy. Have you faced that in the organizations that you're in, and what were the significant challenges? Where do you see the pros and cons of different approaches?"

‍

‍

Scott:

‍

"Whenever that topic comes up (and inevitably it comes up), the first thing I always think about is a quote from Jurassic Park.

‍

With Dr. Malcolm, where he's like, 'you know you spend so much time thinking about if you could, you never stop to think if you should.' Right?

‍

And that's always kind of the first thing I think about when it comes to building a solution of this type. In some ways, ego can get in the way. But the question that should be asked internally is 'are we capable of building this?'

‍

And I don't just mean engineering, because to simply say it's engineering's responsibility to build it is a stretch. 'Oh, here, go build it. Here you go. Here's what it looks like. Here's what a competitor does with it.'

‍

Or, take Unit21 for example.

‍

Telling an engineering team to go make Unit21. 'Let us know when it's done.' It's not quite that simple.

‍

I mean, if you're going to commit to building something internally, it's going to be a cross-team effort. It will involve engineering, of course, but it will also involve product, legal, compliance, risk, and fraud. You might even see contributions from teams like customer support.

‍

In my experience, I've always found the customer support team to be a fantastic resource because based on their interactions with the customers, they tend to be on the leading edge of what is coming. You know, maybe they don't have actual access to the data, but they have unique first-party information based on the types of inquiries that they're seeing or questions.

‍

Ultimately, it's a cross-team effort. And the questions that should be asked are about whether the required level of commitment is there, and is that level of capability there: that knowledge, that experience.

‍

‍

And then, after you ask that question and have that question answered, then you can get into the more traditional steps. You can think to yourself, 'so we've done the design, we've done the build, we've done the testing, we've deployed it. Now, do we understand that once it's been pushed out, that's not the end.'

‍

The reality is that a system like this doesn't just sit and operate and function and just kind of hum along. There are going to be improvements, tweaks, and changes that are going to be required.

‍

You have to ask yourself, as an organization, are you going to be committed to that? Are we going to have dedicated resources for compliance concerns or fraud concerns? Are we going to have to fight with development cycles with our engineering team where, we want to roll out a new monitoring rule set, or a series of them, and they come back and say that maybe we can get it on the calendar for the next quarter?

‍

You know, that doesn't work."

‍

‍

Trisha:

‍

"Fraud doesn't wait till the next quarter."

‍

‍

Scott:

‍

"Absolutely not. I'm not trying to break it down into little sound bites or something like that. But I mean, they're fundamental questions.

‍

And if you're going to build it in-house, there are a lot of different disciplines, knowledge, experience, and expertise required. And if you don't have that, I mean, what are you going to give your engineering team?"

‍

‍

Trisha:

‍

"I worked at a forum for four years, and we decided to build everything internally, and no one was ever happy. It was a constant state of dissatisfaction.

‍

And then ultimately, it was just such a horrible experience for a lot of people. We had a core engineering team that was dedicated to risk engineering, and we had competitors who were moving faster.

‍

This was not the core focus of the business was not to build internal tools, but we did lose a lot of time. So I can completely empathize.

‍

Switching gears, you were a federal examiner. What do you think about the whole evolution of the sponsor bank Fintech fraud liability?"

‍

‍

Scott:

‍

"My experience with that would be more so on the compliance side than the fraud side.

‍

But, having reviewed any number of MSAs with bank partners issuing banks, first and foremost whatever your responsibilities, your obligations, your mandates are, that are going to come from that bank partner, they're going to be spelled out there.

‍

And that's not to mean that's where it starts and it stops. You certainly use that as your baseline and, and you want to go from there. But, that's going to be your go-to to identify what your obligations are going to be.

‍

And again, we're not talking about regulatory obligations to the extent that regulated, we're talking about, you know, bank partner obligations. Again my experience, fraud is something that is typically not really spoken to, in an MSA. That is up to you as the Fintech to design and implement a program that is going to sufficiently speak to and address the, you know the risks and risk and fraud that, that your, your platform your service represents.

‍

That said, what is something that's always going to be table stakes? I've always seen it is going to be compliance with you know, the identity theft red flag rule. You're always going to get the questions around what are you doing to prevent identity theft?

‍

And that's, that that can be a pretty wide-reaching inquiry, right? I mean, you know it sounds pretty basic and sounds pretty simple at first but when you actually start to go through, you know, all of the various identity theft red flags that are identified you know, like the FTC communications. So you know, it can impact various types of platforms, various types of service, all lines of business."

‍

‍

Trisha:

‍

"It's really interesting, especially the Blue Ridge, the breakdown of the sponsor bank relationship. I think a lot needs to be built concerning the trust between the two parties.

‍

So, fraud and AML (FRAML), is it a thing? Do you believe in it? Do you feel like it should be separate teams?

‍

‍

Scott:

‍

"Well, it's going to be dependent upon the company. Certainly, if you have an earlier-stage company as opposed to a later-stage company, the more mature the company, the bigger the operations get. You want more dedicated, focused personnel.

‍

You're probably going to have someone directly responsible for having that specific knowledge of fraud versus AML. If you had an earlier-stage company, you might have someone like me who has some exposure to fraud, is stronger on the compliance side, but has a fraud background.

‍

So you can fit in, and you can fill in a little bit there, regardless even if you don't have the, you know, the two teams that are kind of under the same umbrella. Transparency and communication within the organization is key.

‍

Everyone can't be their own island. Fraud is an acknowledged predicate crime, and where you have fraud, you're almost certainly going to have money laundering.

‍

And if you're going to prevent that, you're going to need all of these people working on these teams working in concert together and all rowing in the same direction."

‍