Risky Fraud Ring

Stripe Fraud Ring Tasks
This problem is Task 3 of 3 in the Stripe fraud-ring sequence.
Task 1: Directly Linked Users
Task 2: Fraud Ring Size
Task 3: Risky Fraud Ring (current)
Not every connected cluster is malicious. Each transaction includes a risk score, and a fraud ring should be blocked only when its average risk is high.
Each transaction log entry is formatted as user_id,device_id,credit_card,risk_score. Users are connected by shared devices or credit cards. The ring for a target user is the connected component containing that user.
A user with risk score 0 is trusted. Trusted users still keep the graph connected, but they are excluded from both the sum and count when computing the average risk score.
Return true if the average risk score of non-trusted users in the target ring is strictly greater than 75; otherwise return false.
Input
transactions: transaction rows formatted as user_id,device_id,credit_card,risk_score.
targetUser: the user to investigate.
Output
Return whether the target ring should be blocked.

Function
shouldBlockFraudRing(transactions: String[], targetUser: String) → boolean

Examples
Example 1
transactions = ["Alice,D1,CC1,90","Bob,D1,CC2,0","Charlie,D2,CC2,80"]
targetUser = "Alice"
return = true
The connected ring is Alice, Bob, and Charlie. Bob has score 0, so the average is (90 + 80) / 2 = 85, which is greater than 75.
Example 2
transactions = ["Alice,D1,CC1,70","Bob,D1,CC2,0","Charlie,D2,CC2,80"]
targetUser = "Alice"
return = false
Bob still connects Alice and Charlie, but Bob is excluded from the average. (70 + 80) / 2 = 75, and the rule requires strictly greater than 75.

Constraints
0 <= transactions.length <= 10^5
0 <= risk_score <= 100
Each user has the same risk score across all their transactions.

Use union-find over user IDs. For each row, union the user with a key for the device and a key for the card, like "D:" + device and "C:" + card, so shared resources merge users automatically. Store each user's score once, since it's the same across rows. Then find the target's root, loop over every user in that root's component, and skip anyone with score 0. Sum the rest and count them. Compare sum > 75 * count, using integers, so you dodge float issues and the strictly-greater edge case from Example 2. The pitfalls are real. Don't drop score-0 users from the graph, because Bob must still bridge Alice and Charlie. Handle a ring where everyone is trusted, since count is 0 and you should return false. If the OA stalls you, StealthCoder is the hedge, reading the problem and giving a working solution live.

The honest play: practice the pattern, and have StealthCoder ready for the one you didn't see coming.