Step 1 Meeting with Stakeholders (Business+Risk+Legal)

● Defining the problems

○ Account compromise/Account Takeover
Account takeover fraud, also known as account compromise, occurs
when a cyber attacker gains control of a legitimate account.

○ User loss
Fraudulent account take over activities cause user losses amounting to :
? (please find out from user report or any source)

○ Tokopedia reputation/User trust

Sample Case : on march 2020, millions of tokopedias user data was
breached and for sale on the online forum. Dozens of news articles
questioning Tokopedia data security. There is a decrease on user trust
and follows in decreasing the number of transactions during the period
(please find out from history transactional data or any source)

○ Distribution of Account Takeover cases

- 53% Marketplace (Physical Goods) transactions manipulations (order
finish, cancelled, and rejected)
- 31% Withdrawal (Refund Balance & Income Balance)
- 16% Digital Transactions
Most of the account takeover activity is on transaction
manipulation.

○ Revenue Loss
Transaction manipulation exploits our voucher/cashback program that
follows revenue loss. (Please check historical fraud activity and link
it with our voucher/cashback promotion)

○ Fraudulent Syndicate
Find out if there is any syndicate that is doing this fraud and affecting our
revenue. Legal team should be aware and planning for the further step.

● Defining the Goals

○ Mitigation for account takeover activity
> Create Account Takeover Detections
○ Metrics :
■ Cut down our user loss by (?) percent
■ Cut down our revenue loss by (?) percent
● Business Requirements
Step 2 Product Planning and PRD
● Conduct meeting with Tech Lead + Business team
○ Invite Business analyst + Data Scientist team + Fraud Specialist
if possible
● Design an Account Takeover Detections / PRD
○ Data Availability:
- Login/Registration Data (Message Queue)
- Device Data (API & Message Queue)
- Payment Data (API & Message Queue)
- Location Data (Message Queue)
- Transactional Data (API & Message Queue)
- User Data (API & Message Queue)
- Withdrawal Data (API)
- Bank Information Data (API)
- Banned User Data (API)
○ The system should be monitoring :
■ Transactional activity
■ Account activity
○ System has Dashboard for user (business team/operations team/risk
team)
○ System have an alert for suspicious activity
○ System has CMS, user can make changes/configuration for the rule
threshold
○ System can accommodate many rules
○ Rules/threshold defined by Business analyst/Data Scientist team
/Fraud Specialist/Risk team
○ Define action/penalty for suspicious activity
○ Specific action for each rule (example : one user transaction doing
transactions to one merchant in n minutes → banned for x days)
○ Create timeline for projects

Step 3 Product Development

○ Grooming meeting
■ Tech team digest the PRD
■ Project breakdowns from stories into subtask
○ Sprint Planning
○ Development
○ System Integration Testing (SIT) by QA and Bug fixing
○ Development review and retrospective
○ User Acceptance Testing (UAT) by PM (alongside users)
○ Product Deployment
RACI MATRIX Product development cycle
Business Product PRD UI/UX Test Grooming Sprint Develo System Sprint UAT Prod Penetration PTR
Requirem Require Approval Develo Scenario meeting planning pment Integrati review deploy test
ent ment pment Develop meeting on and ment
Develop Develop ment Testing retrosp
ment ment (SIT) ective

CEO
CTO A A I
CPO A
Business R/A C I I I I A
Risk C C I I
Legal C C I I
Data Science C I I
PM R R/A R A A R/A C C C R/A R/A R A R
Tech Leader C C C C C R/A R/A C R C R C C
Developer C I I I C C R C C C C
QA C I I R C C R R/A C C C C
UI R I
DevOps R
DBA R
Security R