Process to prevent triangulation fraud

[thiagorb]

Hello. I've been trying recently some tactics to try to prevent triangulation fraud in my sales, and it would be great if an "official" process existed, and were incentivized by RoboSats somehow.

To make it clear, what I refer to as triangulation fraud is when I am selling crypto for an X amount of fiat, a scammer takes my offer, creates an offer to sell any amount of crypto for the same X amount of fiat (not necessarily RoboSats), and when they find a real buyer for their offer, they complete the order with me, but send my payment details to the real buyer. I then confirm the payment, the crypto is released to the scammer, but the real buyer never gets it. The buyer might lose their money, or they might ask the payment provider to get a refund, which may cause me to lose the money, or even get my account blocked for fraud.

Since most payment providers (Revolut, PayPal, Wise, etc.) provide the possibility to communicate with the person who sent you money, I started using this feature to confirm that this person is the one buying from me in RoboSats. I tried different processes, trying to keep the payments as private as possible.

Here are some approaches I tried:

• In the payment provider chat, ask the buyer to send a random word in the "other chat" (RoboSats chat). Once I get the random word in RoboSats chat, I confirm the payment.
  Problem: if this process becomes popular, the scammer can simply forward any message it gets from the real buyer.
• Ask the buyer to write something like "rs [order id]" in the payment reference.
  Problem: it can become obvious that this payment is being used to buy crypto from RoboSats, and if the scammer forwards the request to the real buyer, they might just comply, since they wouldn't know what "rs 1234" stands for.
• In the payment provider chat, send a Private Bin link that contains a message that is burned after reading, and in the message write the buyer to confirm that they are buying crypto from RoboSats, with the order ID, and then ask them to write a random word in the RoboSats chat to confirm.
  Problem: buyers will often refuse to open random links to websites they don't know.

I also thought about more sophisticated options, like to ask the buyer in the payment provider chat, to use an online tool to generate a hash of the URL from the RoboSats order. But I cannot mention "RoboSats URL" in the payment provider chat, so that the payment destination can't be identified, which makes it very hard for the buyer to understand the instructions.

Does a common approach for this already exist?

[cadayton]

Here is a thought to consider. In the payment provider chat asked the buyer to open a private chat with in you Bisq2 to confirm order details. This should eliminate the third party.

[openoms]

The Robosats chat is already encrypted and peer-to-peer. Opening an other channel does not stop the scammer from just forwarding any request the seller makes to the real buyer.

[openoms]

Using only the order ID (a five digit number, no "rs") in the reference is obscure enough.
Should it become a general instruction to include it?
That would make the payer double check and provide verification to the seller that the buyer is part of the same transaction.

Also the order ID itself could be made to be random length letters and / or numbers so it is not a consistent pattern risking censorship.

[thiagorb]

@openoms It is an improvement, but the scammer could still tell the real buyer to add the order ID as reference, and the buyer will do it, because they don't know what this number, or characters represent.

[dipunm]

This is really interesting. After thinking a little, this really feels like a man in the middle attack and feels like it needs a man in the middle solution.

The issue is that the real client never starts the conversation, so it's much harder IMO.

You need a way to establish a connection with the payer in a way that is irrefutably from the sender.

I keep coming back to time. Time is the best indicator. You need to get into lockstep with the hacker and then ask them a question that they won't be able to answer up front. A timed question challenge.

Maybe robo-sats can help make that feel more official and maybe it can also help to make the judgement so that other sellers are more likely to do the process too.

The other challenge is that you have to make it obvious to the victim that they need to take certain precautions but you can't communicate with them directly and at the same time, you cannot make it obvious to the bank what you are doing either.

What if robo-sats requires you to give your account number BEFORE you can take an order?

[thiagorb]

That's an excellent idea. The buyer is forced to give their payment details before taking the order, RoboSats hashes this information and stores it, and then to confirm the payment, the seller types the incoming payment account, and the hashes are validated.

[openoms]

This is similar to having preregistered payment accounts in Bisq1 except the payer details are not revealed in the contract only after the payment is marked sent.

The payer can have a clear notification that the payment should be sent from the preregistered account.

The seller should have the details revealed in the final payment acceptance like:
Did the Payment arrive from the Revolut account John D (@johncd89)?

An automatic verification can be difficult here as the payer might not know how the details appear exactly for the seller.

For example in Revolut with the max privacy settings only the revtag and the name revealed in the format like: John D (first name and the first letter of the surname of John Carl Doe).

[dipunm]

I will say that I have experienced a situation where a bank refuses to allow a payment and you don't know this will happen until it happens.

So then do you have to just terminate the deal? This could otherwise be an excuse made by the malicious middleman to justify their change of details.

Should there be a penalty for this? Or a mutual agreement to cancel? What about the deposits for the robosats mediators?

Adjusting the amount is another idea:

Scenario 1. Scammer accepts the order and then finds a victim.

This can be mitigated by requiring the account number upfront before taking an order.

Scenario 2. Scammer finds a victim, gets their account number and then starts an order.

If the amount is randomised, it might be yet another obstacle for them... I can ask for your account number but wouldn't we need/want the amount before we trade info?

Solution: this might be overthinking it, but here's the idea. Take the order number and the account number and possibly a unique random number attached to the order and create a hash. Use that hash to find a number between 1 and 100.

Now we can set the sale price to $200.20 for an originally decided $200 sale. Or the other way around. However is easier to frame for users. Maybe it is $199.80 because sellers are more aware of the situation?

Robosats can help here by explaining that the amount agreed may vary upto $1 at the time of purchase.

[dipunm]

Ultimately what we are minimising the risk to is this:
Attacker must:

1. Find an offer they like
2. Find a victim
3. Create an order for a similar amount
4. Explain that they need their account number and that they might also change the amount compared to what was adverrised before payment can be received. (Red flags hopefully)
5. Take the robosats offer with the account number
6. Find the real amount
7. Wait for chat
8. Get the account number from maker
9. Pass this to the victim and ask them to make payment of expected amount.

This is gonna be really hard for the attacker.

For a plain robosats payment:

1. Find an offer
2. Enter your account number
3. Get shown the slightly modified amount
4. Accept
5. Wait for chat
6. Get account details
7. Pay

[clonmac]

I've used both Robosats and Bisq extensively and one reason why I think I experience far less triangulation scams like this on Bisq is due to the pre-registered and "aged" accounts. There are trade limits to any account that is not verified as well. If I take a trade on Bisq with a fiat account that has been verified for 100 days, then I know that I am not getting involved with a triangulation scam due to the fact that the account involved has been registered and verified for that long. If I am posting a trade, if I make my offer larger than a certain amount, then it required account verification and therefore provides that same amount of security and therefore also avoids triangulation scams as a results.

With Robosats, due to the account information being exchanged after the offer is accepted, I have found that there is a much greater risk of triangulation scams and I have seen this first hand far too frequently as a result.

I know Robosats values privacy with one-time use robots, but I think this is ripe for fraud like this. Having an account "age in" reduces the risk that the account is not owned by the person involved with the trade. Inputting the account details prior to accepting the trade helps, but as @dipunm mentioned in scenario 2, the scammer can just get the account details from a victim prior to accepting a trade. This is why having an account age-in reduces this risk because the scammer only has a finite amount of time to take advantage of the victim.

I agree that time is the most critical factor in this type of scam, but I also don't think it needs to be realtime communication between fiat payment systems and Robosats in order to prevent or inhibit this type of scam.

I like the idea of entering account details prior to entering a trade offer. Perhaps additionally, when creating a new trade offer, you can choose an option to opt for "additional security". This could be useful for high value trade offers. This additional security feature requires the trade to sit idle for 2 days before account details are revealed. Since the trade required account details prior to being accepted, this means the scammer would need account details for a couple days before submitting payment (unlikely). If the account is truly owned by the trade partner, this is not a problem though. This, in a way, mimics account verification/age similar to Bisq. After the 2 day wait period, the account details can be revealed allowing the fiat payment to be conducted and the trade to be completed. While these trades would take longer to complete, it would provide additional security against these types of scams that require faster reconciliation by the fraudster and their victims.

This would, however, require locking LN payments via HTLCs for longer durations.