completed 7.19.2021

Prompt -

• Company X is in the fiat-crypto business and currently takes on all chargeback risk + fraud for our partners. We're thinking about selling this to our partners. What does Company X's Risk API look like?

Framework

My thought-process for this question loosely follows:

1. How fraud factors in (why does Company X care)
2. Consider Company X users
1. Who are they
2. What are their painpoints in the area of fraud and payments
3. How does Company X solve these problems
1. Which tradeoffs exist?
2. How will this solution fail, how will it succeed?
4. How does Company X position itself as the best option to solve these problems?
1. How would users benefit from Risk API
2. How can Company X communicate value of the offering
5. How will this solution address the above pain points in a way that underpins Company X's mission

What I wish I knew:

How does Company X handle addressing disputes currently, is evidence automatically submitted when a claim is created?

Does Company X pass the chargeback fee cost on to the user?

What is Company X's tolerance threshold for dispute activity for a given user?

What is the existing Fraud Engine featureset—how does Company X prove that this saves end-users time and money?

Note: For the purpose of this exercise, I'm assuming that the existing Fraud Engine functionality blocks or holds payments from fiat sources when a given set of suspicious behavior threshold limit is reached.

1. Business goals & fraud as an area of focus

When determining why Company X should or shouldn't pursue a product offering or strategic change, we should first confirm that these changes are in line with Company X's overall company goals. Company X has a few stated goals, one of which is to increase the global crypto userbase, by building functionality that supports and enables the crypto developer community to that end.

Trust and security are at the crux of any successful fintech solution—they're table stakes in the space and should be prioritized. In seeking to provide a developer-friendly infrastructure, a fintech platform should build and expose intelligent tools providing developers with the support to create amazing products. Company X's core mission is to "change the future of how international payments are done," which it will achieve through "balanc[ing] experience and intelligence, with opportunity and innovation," since we know that any payment offering must prioritize providing a stable, secure experience for developers, we can be confident that efforts to reduce the negative impact of fraud on the end-user is within Company X's area of interest.

It will be impossible to onboard the next 1 billion crypto users without guard rails in place to inspire confidence in the various solutions built on public chains and L2 solutions. Company X should consider risk solutions as part of its core business offering because such featuresets protect risk-taking developers from needing to build their own fraud solution, instead allowing them to focus their energies on their unique product solutions within their area of expertise. Company X is a solution to an issue-area that saves developers time and money, it should emphasize the role it plays in making engineer's lives easier by removing abstraction from some of its core risk functionality.

2. Company X users and their pain points

Users: Developers building tools that utilize crypto to service a broad spectrum of end-users

Pain points:

• Engendering trust in their service built on an emerging technology with a public perception issue (lasting impact of silk road, mt. gox breach, etc.)
• Educating their app users on a cutting edge payment experience (turning cash in their bank account/credit card into crypto)
• Prevalence of friction in overall DAPP onboard process for new crypto users
• Forced to rely on outside services to effectively convert users interested in YOUR product (e.g. Ethereum onboarding process requires ETH purchased using fiat through a centralized entity, then transferring that ETH out of a managed wallet THEN interacting with DAPP, lots of steps to onboard a brand new user to your platform)
• Fraudulent transactions via fiat payment rails exchanged for crypto assets that are then transferred on-chain (entity left exposed when chargeback hits)

3. How does Company X solve the problem

Company X is already handling the responsibility for fraud and chargeback activity incurred by their developer-users' products, without much fanfare. Exposing the Risk API as a standalone product offering would be beneficial to Company X for two reasons: Market perception and a diversified revenue stream.

There are a few milestones that can be targeted in the release of this as an isolated product offering:

1. Exposing the existing Fraud Engine functionality as a standalone product offering that can be enabled on a per-API token basis.
2. Exposing Fraud Engine metrics in an account's dashboard (call it the Risk Dashboard)
1. Metrics of interest: Dispute Activity, Count of disputes over a given period of time, Dispute trend (increase or decrease over time)
2. Dashboarding to include all disputed payments and relevant metadata associated (status of dispute, user associated, type of charge, etc.)
3. Allow management of rules related to fiat payments (i.e. "payments from this country should be automatically placed in review" similar to Stripe Radar functionality)
1. Allows for developer-users to set their acceptable risk tolerance threshold based on their unique business model and usecase

Concerns:

• Existing users who are accustomed to benefitting from this functionality without additional cost. Is there a 90 day grace period before changes are implemented or are they grandfathered in as legacy accounts with full access to Risk API functionality, gratis?
• Is fraud considered to be a big enough pain point to the developer-user, such that it would warrant incurring additional costs?
• Perception of "either you pay us to manage your fraud or you run all of the risks of such" might be off-putting for developers. Perception of platform might overshadow the revenue benefits of splitting the offering off. A possible solution here is offering a baseline level of fraud protection as out-of-box with upgradeable modularity possible.

4. Why Company X is trusted to solve this problem

As a leading solution in the crypto onboarding process, Company X's volume and impact at scale allows for the potential to be a market-leading risk solution for developers in a space that doesn't yet have a clear market dominator.

Google Trends indicates an increase in focus on risk within the crypto space.

5. What I would want to know before further action

Conclusion

When seeking to build tooling and functionality that will underpin the onboarding of the next 1 billion crypto users, Company X should consider the risks and pain points associated with those 1 billion people's crypto introduction, and work on the featuresets that mitigate those. This approach, if done at scale, will provide developer partners with the infrastructural support requisite to build applications that draw in such a disparate userbase. Allowing developers to manage their own risk tolerance as it related to fraud and chargebacks could further reinforce Company X's position as a modular, flexible base on which to build dapps that appeal to a market of users who aren't necessarily crypto-native.