Every now and then I get to talk to companies either going into payments or having to deal with the effects of risk and fraud in payments. Usually that's a good sign - you need to be big enough to care, and that mostly means that you have good trajectory - but having to deal with risk and user behavior in payments without a manual (none exists) is difficult. To make matters worse, there aren't a lot of folks with this specific experience who are ready to hop on to a company looking to start a team from scratch.
Naturally every company is slightly different in the way its product utilizes payments. A marketplace for tangible items having to manage both merchant and consumer risk is different than a gaming platform with immediate delivery and high refund rates; business models also impact loss tolerance and use of various payment options. And so, providing one general advice constantly fails - well, other than "take it slow and iterate quickly", but you already knew that. There is, however, some advice I keep repeating at these very early stages.
Naturally every company is slightly different in the way its product utilizes payments. A marketplace for tangible items having to manage both merchant and consumer risk is different than a gaming platform with immediate delivery and high refund rates; business models also impact loss tolerance and use of various payment options. And so, providing one general advice constantly fails - well, other than "take it slow and iterate quickly", but you already knew that. There is, however, some advice I keep repeating at these very early stages.
- Hire the right person. As I describe in The Factory Approach, your first hires are crucial for the way your risk and decision team will grow. I've written multiple times in the past about the importance of hiring people who can articulate complex patterns. Find someone who combines a knack for patterns and data, can understand technology, but is able to deliver results in an operational environment. You may be looking for two different people (although my experience shows that these people exist - only outside of standard engineering practices)... hire the right person, and a huge number of the childhood illnesses of your department (over-reacting to losses, solving problems with low quality man power) will be spared. oh, and if you read this and feel like you're the right person for the job, I'm hiring!
- Instrument, instrument, instrument. No one has ever looked back at the first two years of his company running and said "I shouldn't have kept all that data". From the payments and risk perspective, this means a few things: decide on an entity-focused data structure and stick to it. When you add functionality, properly abstract rather than add flags and columns that are called "is_transaction_refunded_yes_no". Never delete rejected, refunded or cancelled orders. Properly document state changes. Instrument internal decisions and manual decision clicks. Finally, never build a complex ETL process to provide Risk folks with data; risk isn't business analytics - it is engineering with a sprinkle of manual review. Trust me, this will be one of your most precious assets even a few months down the road.
Are these enough for building a successful risk management team? No. But they are a good start and two things to keep in mind while you think about this complex task.
As always, I'm available for questions at @ohadsamet
5 comments:
"never build a complex ETL process to provide Risk folks with data; risk isn't business analytics - it is engineering with a sprinkle of manual review. "
Agreed.
Out of curiosity, do you have a reporting database for other internal groups, or is everyone just hitting what's more or less a copy of production?
There is a reporting DB and a BI tool for lighter, business analytics functions. Risk analysts, however, must swim in SQL IMHO.
In theory, your hiring approach may work, however I fail to see how testing a potential candidate to identify complex patterns in a time restricted environment really helps you ascertain said candidates aptitude for risk and decisioning.
I have been subjected to such tests and think its flaw is two fold;
A) Setting a "right" or "wrong" answer in a field that is as subjective as patten matching will leave you with a team that is completely homogenous in their reasoning;
B) Following on from point a, the candidate should be given an opportunity to explain, in plain English, the pattern they do see. Who knows, while their reasoning may not be optimal in the statistical sense, there may be an element of truth in their reasoning.
Having had some experience dealing with risk and fraud analysts, I've noticed that the modus operandi is generally reactive, and fraudsters/those in voluntary arrears are almost always one step ahead. Time to think outside of the square maybe?
@anon, you're assuming too much. The tests don't have a right or wrong answer and take place in a conversation that allows people to reflect and correct.
That said, some people don't have the right intuition and cannot come up with a reasonable answer even during a debate, as they're being guided. Much like I can't be a pilot, we're not all good for everything.
As for the reactive approach... I don't think you've worked in one of my teams or the ones I consult to.
Incredible story there. What happened after? Good luck!
Post a Comment