Dual-Bank Verification

[HenrikJannsen]

Dual-Bank Verification (DBV)

A Decentralized Protection Mechanism Against Stolen Bank Account Fraud in Bisq

Summary

Dual-Bank Verification is a decentralized, privacy-preserving mechanism designed to mitigate stolen bank account fraud in Bisq trades.
The method requires the fiat-paying party (buyer) to demonstrate ownership of their bank identity by sending two independent fiat transfers from two separate bank accounts, both showing the same legal name.
This drastically increases assurance that the buyer is the legitimate owner of the accounts used for the trade, without introducing any central authority or persistent identity registry.

DBV is optional and fully configurable by the seller, enabling different risk tiers while maintaining Bisq’s trust-minimized and privacy-oriented model.

This idea was proposed in: bisq-network/proposals#83

---

Motivation

Stolen bank accounts used to fund fiat transfers are a major fraud vector in decentralized marketplaces.
Attackers often:

• gain access to a single bank account belonging to an unsuspecting victim, or
• socially engineer a single transfer from a vulnerable individual (Triangular scam).

They almost never have control over multiple independent bank accounts under the same legal name.

Requiring a second micro-transfer from another account under the same name makes these attacks economically or practically infeasible.

---

Goals

• Prevent fiat fraud involving stolen bank accounts.
• Maintain zero centralization and no KYC.
• Avoid any long-term identity storage.
• Keep the mechanism bilateral, ephemeral, and privacy-preserving.
• Introduce minimal friction to honest traders while significantly raising the bar for attackers.

---

Non-Goals

• Prevent “friendly-chargeback” scam.
• Establish a persistent reputation identity (though it could be part of that - but that will be handled in other proposals).
• Require external services or third-party verification.
• Automate name-matching across banks.

---

Protocol Overview

Participants

• Buyer – Pays fiat and receives BTC.
• Seller – Receives fiat and sends BTC.

Preconditions

• Seller selects a trade option requiring Dual-Bank Verification.
• Buyer is informed of the requirement before accepting the trade.

Steps

1. Seller Defines Micro-Verification Amount

   • A small arbitrary amount (e.g., $0.01–$0.99) defined by the seller or from data the buyer cannot control.
   • Must be unique to the trade instance.

2. Buyer Sends Primary Fiat Payment

   • Standard fiat transfer (e.g., SEPA, Zelle,...).
   • Transfer receipt shows buyer’s legal name.

3. Buyer Sends Verification Micro-Payment From a Secondary Account

   • Must originate from a different bank account under the buyer’s name.
   • Receipt must display:
     • identical or semantically equivalent legal name
     • micro-payment amount
     • timestamp

4. Seller Verifies

   • Confirms:
     • names match or are reasonably equivalent
     • both accounts appear independent
     • micro-payment amount matches the trade’s DBV amount
   • If verified, seller proceeds with BTC release.

---

Security Model

Threat Addressed: Stolen Bank Accounts

Attacker must control:

• one stolen account → easy
• two stolen accounts with the same victim name → extremely unlikely
• ability to initiate two transfers undetected → nearly impossible

DBV dramatically increases the difficulty of using compromised fiat accounts.

Attacker Models

1. Stolen Account Scammer (primary threat)

• Cannot pass DBV (highly effective).

2. Scammer using synthetic/fake identities

• Could open two KYC’d accounts under a fabricated identity.
• Expensive, slow, and untypical for opportunistic P2P scammers.

3. Legitimate buyer with only one account

• Cannot meet DBV requirements.
• Mitigation: DBV remains optional and seller-configurable.

---

Privacy Considerations

• No third-party identity or bank data is shared.
• No persistent identity is created.
• Seller sees only ephemeral receipts, same as traditional Bisq transfers.
• No central storage of names or bank information.

---

Seller Configuration Options

• Enable/Disable DBV.
• Define micro-payment amount.
• List accepted secondary payment rails (e.g., SEPA, ACH, PIX,...).
• Provide name-matching tolerance guidelines (optional UI suggestion).

---

UX Considerations

• Buyers are clearly informed before accepting the trade.
• UI should show a warning if the buyer has only one bank account.

---

Limitations

• Not all users have multiple bank accounts.
• Some micro-transfer systems hide the sender’s name (region-dependent).
• Receipt interpretation remains a manual verification step.
• Does not prevent “friendly chargebacks”.

---

Conclusion

Dual-Bank Verification is a pragmatic, decentralized anti-fraud mechanism that significantly reduces stolen-bank-account attacks without introducing centralization or compromising user privacy. It leverages natural real-world asymmetry: honest users often have ≥2 bank accounts, while scammers almost never control multiple accounts under the same identity.

It is simple, effective, cheap, and aligned with Bisq’s design principles.

---

Future Extensions

• Combine DBV with other protection systems like account age system and potential proof or trade system.
• Allow both payment accounts to be locally registered and be used for account age and account signing features.
• Instead of micro payment split the payment by roughly 50% still keep the requirement of distinct amounts for additional protection.

Note: This is an AI generated summary

[HenrikJannsen]

Addition:

We need to ensure that seller is trustworthy either by a binary option (like signed accounts in Bisq 1) or weighting the sellers signature by their trustworthiness parameters (reputation, has imported signed witness from Bisq 1, account age,...).

It also need to be harmonized with the way how we design account based identity data from other parts of the system.