Preventing Fraud in the Mercari customer journey / メルカリのカスタマージャーニーにおける不正防止の取り組み

When a person wants to use the Mercari app, they go through multiple phases over the course of their customer journey, from registering their account to liking, buying, and selling items and more. During these phases, we must take the utmost care in handling customer actions because there is a risk of fraud.
In this session, I will discuss a few architecture details and design discussions that we took to prevent fraud in the Mercari/Merpay ecosystem.

メルカリのアプリを利用するとき、アカウント登録、いいね、購入、出品など、カスタマージャーニーにおける複数のフェーズがあります。これらのフェーズには不正のリスクが伴うため、お客さまのアクション処理には細心の注意を払う必要があります。
本セッションでは、メルカリ・メルペイのエコシステムにおけるアーキテクチャの詳細と、不正を防ぐために行った設計上の議論についてお話します。

------
Merpay & Mercoin Tech Fest 2023は3日間のオンライン技術カンファレンスです。
IT企業で働くソフトウェアエンジニアおよびメルペイ・メルコインの技術スタックに興味がある方々を対象に2023年8月22日（火）、23日（水）、24日（木）の3日間、開催します。 Merpay & Mercoin Tech Fest は事業との関わりから技術への興味を深め、プロダクトやサービスを支えるエンジニアリングを知ることができるお祭りです。

今年のテーマは「Unleash Fintech」。 メルペイ・メルコインのこれまでの技術的な取り組みはもちろん、メルカリグループのFintech事業における新たな挑戦をお伝えします。 セッションでは事業を支える組織・技術・課題などへの試行錯誤やアプローチなど多面的にご紹介予定です。

メルペイ・メルコインが今後どのようにUnleash（解放）していくのか、ぜひ見に来てください。

■イベント関連情報
- 公式ウェブサイト：https://events.merpay.com/techfest-2023/
- 申し込みページ：https://mercari.connpass.com/event/286670/
- Twitterハッシュタグ： #MerpayMercoinTechFest
■リンク集
- メルカリ・メルペイイベント一覧：https://mercari.connpass.com/
- メルカリキャリアサイト：https://careers.mercari.com/
- メルカリエンジニアリングブログ：https://engineering.mercari.com/blog/
- メルカリエンジニア向けTwitterアカウント：https://twitter.com/mercaridevjp
- 株式会社メルペイ：https://jp.merpay.com/

Transcript

1. Session Title Preventing fraud from Mercari customer journey Gajula Shiva Chaitanya Merpay Engineer
2. @codechaitu 1. Joined mercari in 2018 after my graduation. 2. Contributed to the development of Mercari’s internal Customer Relationship Management (CRM) tools. 3. In November 2022, joined merpay to improve knowledge about fraudulent transactions. Merpay TnS Platform Team
3. Mercari Customer Journey… ?
4. Scene: Customer moves from start to account registration step
5. Comparison between suspicious customer and normal customer after account creation.
6. Scene: customer moves to transaction step
7. Introduce Trust and Safety team [ TnS ] system overview #1 Sources #2 Pre Processing Output Processing Rule Engine #3 Rule Engine #3 #3 #4
8. 1. How we receive them ? a. streaming events from CDC [ change data capture ] b. other microservices. c. 3rd party data. #2 Pre Processing Output Processing Stream Engine #3 #1 Sources #4 #2 Pre Processing Output Processing Stream Engine #3 #1 Sources
9. 1. We want to filter out data from multiple sources and prepare in required format. 2. To filter the data we prepared some services, in them I would like to present two features which I like the most. #2 Pre Processing Output Processing Stream Engine #3 #1 Sources #3 #4
10. #2 Pre Processing Output Processing Stream Engine #3 #1 Sources #3 #4 1. あんしん支払い [ Safe payment settings ] 2. 3D Secure Some significant feature introduction
11. #2 Pre Processing Output Processing Stream Engine #3 #1 Sources #3 #4 Feature: あんしん支払い More about this feature can be read here.
12. #2 Pre Processing Output Processing Stream Engine #3 #1 Sources #3 #4 Feature: 3D Secure - If a transaction is found suspicious, what we do…?
13. 1. Splunk [ currently using for batch-processing ] a. We are using Splunk cloud. 2. Flink [ under development for real-time-processing ] #2 Pre Processing Output Processing Rule Engine #3 #1 Sources #4
14. #2 Pre Processing Output Processing Rule Engine #3 #1 Sources #4 Why Apache Flink ? About Google Dataflow 1. Pro’s a. Easy to deploy as a fully-managed service. b. Autoscaling on high-load. 2. Con’s a. Can’t handle checkpoint on developer side. b. High availability option, which Flink provides compared to SLA for dataflow. c. A bit expensive. About Apache Flink 1. Pro’s a. We can have checkpointing and savepoints. b. OSS, so we can deploy our jobs on kubernetes, so we can debug easily. c. We have a team internally already worked on Flink and provide support, when needed. 2. Con’s a. Need to manage resource ourselves.
15. #2 Pre Processing Output Processing Rule Engine #3 #1 Sources #4
16. #2 Pre Processing Output Processing Rule Engine #3 #1 Sources #4 Example Rule: If an customer spends more than 1 Million Yen within 6 hours, then it is a suspicious transaction. To easily demonstrate our system, let’s use cloud scheduler.
17. #2 Pre Processing Output Processing Rule Engine #3 #1 Sources #4 Example Rule: If an customer spends more than 1 Million Yen within 6 hours, then it is a suspicious transaction.
18. How we debug locally - Setup #2 Pre Processing Output Processing Rule Engine #3 #1 Sources #4 There are steps written in the GitHub, please try it. Docs link
19. How we debug locally - Example #2 Pre Processing Output Processing Rule Engine #3 #1 Sources #4 we use FlinkSQL in local by using SQL gateway. Let’s watch a video together and understand it.
20. 1. Manually check the data if it is a suspicious transaction or not. 2. If it is suspicious, apply some restrictions on customer, like restriction from buying for x number of days, restriction from selling for y number of days, etc. 3. Based on case-by-case it changes. 4. We use GCP memory store as cache to filter out duplicate events. #2 Pre Processing Output Processing Rule Engine #3 #1 Sources #4
21. The reason to present our work. A small attempt to inform engineers and general audience that we are taking our best care to prepare mercari a safe environment from fraud.