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
