출처 검증 리서치: Binance

Decision Matrix

Source Map

• Binance Support: What Is the Travel Rule? (binance-travel-rule)
• Binance Support: What Is Satoshi Test and Travel Rule Address Book Feature? (binance-satoshi-address-book)
• Binance Support: Crypto Deposit/Withdrawal FAQ (binance-deposit-withdrawal-hub)
• Binance Support: Travel Rule: Crypto Transfer Procedures (binance-travel-rule-procedure)

Control Notes

1. Jurisdiction scope

Jurisdiction scope is the part of the decision where the reader must turn a public source into an operating rule. In this package, it means where Travel Rule questions apply. The useful action is to check whether the user's region and counterparty route are in scope. The unresolved edge is future jurisdiction expansion, so this article does not convert that uncertainty into a promise, ranking, reward, approval, safety claim or future-availability claim.

For an operator, jurisdiction scope should be recorded before funds, account access, wallet recovery, API order flow, whitelist changes, cross-chain transfers or tokenized-asset decisions become material. The record can stay simple: the official source URL, the date checked, the product or network under review, and a non-secret note describing why the next step is acceptable. Screenshots should avoid balances, identity documents, API keys, recovery phrases, private keys, passphrases, verification codes and support-ticket private data.

2. Counterparty type

Counterparty type is the part of the decision where the reader must turn a public source into an operating rule. In this package, it means exchange, VASP, self-hosted wallet or third party. The useful action is to classify the beneficiary before submitting details. The unresolved edge is hidden intermediary review, so this article does not convert that uncertainty into a promise, ranking, reward, approval, safety claim or future-availability claim.

For an operator, counterparty type should be recorded before funds, account access, wallet recovery, API order flow, whitelist changes, cross-chain transfers or tokenized-asset decisions become material.

3. Address control

Address control is the part of the decision where the reader must turn a public source into an operating rule. In this package, it means whether the user controls a self-hosted address. The useful action is to complete only official verification steps. The unresolved edge is failed or expired Satoshi Test, so this article does not convert that uncertainty into a promise, ranking, reward, approval, safety claim or future-availability claim.

For an operator, address control should be recorded before funds, account access, wallet recovery, API order flow, whitelist changes, cross-chain transfers or tokenized-asset decisions become material.

4. Address-book data

Address-book data is the part of the decision where the reader must turn a public source into an operating rule. In this package, it means stored recipient and wallet information. The useful action is to keep address-book records current and non-secret. The unresolved edge is future recipient changes, so this article does not convert that uncertainty into a promise, ranking, reward, approval, safety claim or future-availability claim.

For an operator, address-book data should be recorded before funds, account access, wallet recovery, API order flow, whitelist changes, cross-chain transfers or tokenized-asset decisions become material.

5. Deposit information

Deposit information is the part of the decision where the reader must turn a public source into an operating rule. In this package, it means originator information requested for incoming transfers. The useful action is to obtain accurate sender information before deposit follow-up. The unresolved edge is sender cooperation, so this article does not convert that uncertainty into a promise, ranking, reward, approval, safety claim or future-availability claim.

For an operator, deposit information should be recorded before funds, account access, wallet recovery, API order flow, whitelist changes, cross-chain transfers or tokenized-asset decisions become material.

6. Withdrawal information

Withdrawal information is the part of the decision where the reader must turn a public source into an operating rule. In this package, it means beneficiary information requested for outgoing transfers. The useful action is to confirm name, address and relationship before withdrawal. The unresolved edge is additional review, so this article does not convert that uncertainty into a promise, ranking, reward, approval, safety claim or future-availability claim.

For an operator, withdrawal information should be recorded before funds, account access, wallet recovery, API order flow, whitelist changes, cross-chain transfers or tokenized-asset decisions become material.

7. Privacy boundary

Privacy boundary is the part of the decision where the reader must turn a public source into an operating rule. In this package, it means what personal data is shared for compliance. The useful action is to read Binance privacy and transfer wording before acting. The unresolved edge is counterparty data handling, so this article does not convert that uncertainty into a promise, ranking, reward, approval, safety claim or future-availability claim.

For an operator, privacy boundary should be recorded before funds, account access, wallet recovery, API order flow, whitelist changes, cross-chain transfers or tokenized-asset decisions become material.

8. Delay handling

Delay handling is the part of the decision where the reader must turn a public source into an operating rule. In this package, it means what to do if information is incomplete. The useful action is to pause instead of retrying blindly. The unresolved edge is support response timing, so this article does not convert that uncertainty into a promise, ranking, reward, approval, safety claim or future-availability claim.

For an operator, delay handling should be recorded before funds, account access, wallet recovery, API order flow, whitelist changes, cross-chain transfers or tokenized-asset decisions become material.

9. Evidence packet

Evidence packet is the part of the decision where the reader must turn a public source into an operating rule. In this package, it means official URL, checked date, route type and non-secret status. The useful action is to do not publish wallet addresses, names, IDs or codes. The unresolved edge is private account decision, so this article does not convert that uncertainty into a promise, ranking, reward, approval, safety claim or future-availability claim.

10. Stop rule

Stop rule is the part of the decision where the reader must turn a public source into an operating rule. In this package, it means when a transfer claim should not publish. The useful action is to stop if jurisdiction, counterparty, address control or data requirement is unclear. The unresolved edge is future Binance policy changes, so this article does not convert that uncertainty into a promise, ranking, reward, approval, safety claim or future-availability claim.

Known Unknowns

• future jurisdiction expansion
• hidden intermediary review
• failed or expired Satoshi Test
• future recipient changes
• sender cooperation
• additional review
• counterparty data handling
• support response timing
• private account decision
• future Binance policy changes

Practical Takeaway

The safest version of this article is the one that stays boring and exact. Binance's Travel Rule material turns crypto deposits and withdrawals into an information-quality workflow, not just a wallet-address workflow. Binance says users may need to provide originator or beneficiary information for transfers in jurisdictions where Travel Rule rules apply. Its Satoshi Test and Travel Rule Address Book FAQ says a self-hosted wallet can require a small verification transaction and that stored Travel Rule address information can pre-validate future transfers. The practical decision is to verify the jurisdiction, beneficiary type, address ownership, stored address details and privacy boundary before assuming a withdrawal or deposit will process normally. The user outcome is a clearer next inspection step, not a promise that a platform, API, transfer route or tokenized asset will work under every future condition.