Glossary

Travel rule

The travel rule is the obligation, in many jurisdictions, to pass certain originator and beneficiary information alongside a transfer of value above a threshold when that transfer moves between regulated providers. The sending provider records who is sending and who is receiving, and forwards that identifying context to the receiving provider so the information "travels" with the money instead of dropping off at the boundary between two services. It is a process and a legal obligation that can apply to a business — not a certification a payment provider holds, and not a setting toggled in an API.

01

What the travel rule is

The name comes from the idea that identifying information should travel alongside the value being transferred. When a regulated provider sends a transfer above a defined threshold to another regulated provider, the sender is required to collect and forward a set of details about the originator (the party sending) and the beneficiary (the party receiving), so the receiving side learns who is on the other end rather than seeing only an address and an amount. The rule originates in anti-money-laundering frameworks for traditional wire transfers and has been extended to providers that transmit crypto value, because a transfer that is anonymous end to end is exactly where illicit flows hide.

Three things shape whether the rule applies to a given transfer, and they have to be read together. It applies to transfers between regulated providers — the obligation attaches to the providers transmitting value, not to an individual moving their own funds. It applies above a threshold, a monetary floor below which the requirement does not bite, set by the jurisdiction. And it depends on the jurisdiction itself and on your role in the transaction: what counts as a regulated provider, what threshold applies, what fields you must record, and how they must be transmitted all vary by where you operate and whether you are the sending or receiving side. There is no single global version of the rule.

It helps to be precise about what the travel rule is not. It is not a certification or a license that a business can hold and display — it is an obligation that may apply to certain regulated providers, who must satisfy it on each qualifying transfer. It is not a status that makes a business "compliant" once met; it is one recurring requirement within a broader compliance process. And it is not a technical feature that confidentiality-enables or blocks a transaction — it is a recordkeeping and information-forwarding duty layered on top of the transfer itself.

02

Why it matters for crypto payments

If you accept crypto, value flows into and out of your account, and depending on your jurisdiction, your activity, and your role, the travel rule may be one of the obligations that comes with transmitting that value. It is worth understanding early because it can shape how some flows are structured — what information has to be captured, when, and from whom — rather than being something bolted on after a flow is already built. Treating it as an afterthought is how a payment project discovers a requirement late, when changing the flow is expensive.

The honest framing matters as much as the rule itself. Whether the travel rule applies to a specific transfer, at what threshold, what exactly you must record, and how you must forward it are legal and jurisdictional questions — they turn on facts about your business that only you and a qualified adviser have. A payment provider can support the operational side of such obligations through onboarding and process, but it cannot determine your legal posture for you, and no general explanation — including this one — is a substitute for advice from someone qualified to give it. The right place to settle whether and how the rule applies to you is your own counsel and the onboarding conversation, not a marketing page or an API setting.

03

The travel rule and halfin

halfin is digital-asset payment infrastructure, and it treats the travel rule the way it treats compliance generally — as a process it supports operationally, never as a certification or license it holds. The platform's compliance surface is concrete: businesses are verified at onboarding (KYB) before any money moves, the actions that move funds run through scoped API keys and operator approval, and outbound movement is recorded so it can be reviewed. That audit trail and the discipline around who can move funds are the operational foundations an obligation like the travel rule sits on top of — but supporting that foundation is not the same as making a regulatory claim, and halfin never describes itself as licensed or regulated as a status.

For a merchant, the practical takeaway is to keep the boundary clear. halfin runs the operational plumbing and keeps an accurate record; whether the travel rule applies to your transfers, what you must capture, and how you must report it remain yours to determine with your counsel. The questions that decide it — your jurisdiction, your activity, your role in each transfer — are the kind that get assessed in onboarding, where the specifics of your business can actually be evaluated, rather than answered by a general statement. Nothing here is legal advice; it is an explanation of the concept and of where halfin's responsibility starts and stops.

  • The travel rule = passing originator and beneficiary information alongside value transfers above a threshold, between regulated providers.
  • Whether it applies depends on your jurisdiction, the threshold, and your role in the transfer — there is no single global version.
  • It is an obligation a business may carry, not a certification or license a provider holds.
  • halfin supports such obligations operationally through KYB onboarding, scoped permissions, and an audit trail — but determining your posture is a legal and onboarding question, not an API setting, and nothing here is legal advice.